Sunteți pe pagina 1din 536

SQL - III

Structured Query Language

Prof.dr. Bogdan IONESCU


Dept. Informatică de Gestiune
ASE Bucureşti
SGBD Access : SQL: UNION
Dacă se doreşte să se vizualizeze rezultatele mai multor interogări
SELECT în acelaşi timp, prin combinarea ieşirilor lor, poate fi
utilizată facilitatea UNION a limbajului de interogare SQL.

SELECT lista_campuri FROM tabela1


[WHERE listă_criterii_selecţie1]
[GROUP BY camp_de_grupare] [HAVING criteriul_de_agregare]
UNION [ALL]
SELECT listă_campuri FROM tabela2
[WHERE listă_criterii_selecţie2]
[GROUP BY camp_de_grupare]
[HAVING criteriul_de_agregare]
[UNION [ALL] SELECT listă_campuri FROM tabela3
….
[ORDER BY camp_criteriu_de_sortare [sens_sortare] ;
SGBD Access : SQL: UNION
SELECT [Cod Fiscal],[Denumire Client],Localitate,Telefon
FROM Clienti
UNION
SELECT [Cod Fiscal],[Denumire Client],Localitate,Telefon
FROM [Clienti Arad]
ORDER BY Localitate,[Denumire Client];
SGBD Access : SQL: UNION

A (a1, a2, a3, a4, a5, a6)


B (b1, b2, a1, b3)

SELECT DISTINCT a3 FROM A


UNION
SELECT DISTINCT b3 FROM B
ORDER BY a3 DESC ;
Este obţinută o listă a datelor din câmpurile a3 şi b3, fiecare valoare
fiind preluată o singură dată; datele sunt sortate descendent.
SGBD Access : SQL: CROSSTAB
CROSSTAB Query permite ca pe lângă selectarea datelor şi efectuarea
calculelor în linie sau prin funcţii agregat, să grupeze înregistrările pe
linie (antete de rânduri) şi pe coloană (titluri de coloană)

TRANSFORM funcţie agregat AS alias


Instrucţiune de selecţie cu grupare pe linie
PIVOT câmp antet coloană ;
Funcţia agregat operează asupra înregistrărilor, prin definirea
calculului aplicat elementelor de grup;
Instrucţiunea de selecţie serveşte pentru a specifica antetele
de rând ale rezultatelor interogării;
Câmpul antet coloană constituie câmpul sau expresia ce se
utilizează în definirea antetelor de coloane, pentru setul de
rezultate al interogării.
SGBD Access : SQL: CROSSTAB
A (a1, a2, a3, a4, a5, a6)
B (b1, b2, a1, b3)
TRANSFORM SUM (a6) AS Suma_a6
SELECT a2
FROM A
WHERE a6 NOT IN (a4, a5)
GROUP BY a2
PIVOT a5 ;

TRANSFORM AVG (b2) AS Medie_b2


SELECT a1
FROM A INNER JOIN B ON A.a1 = B.a1
WHERE b3 > a3
GROUP BY a1
PIVOT a2 ;
SQL: CROSSTAB
TRANSFORM funcţie agregat AS alias
Instrucţiune de selecţie cu grupare pe linie
PIVOT câmp antet coloană ;

TRANSFORM Sum([Cantitate]*[Pret f]) AS Valoare


SELECT Carti.[Denumire Carte]
FROM Facturi
INNER JOIN (Carti INNER JOIN [Continut Factura]
ON Carti.[Cod ISBN] = [Continut Factura].[Cod ISBN])
ON Facturi.[Numar Factura] = [Continut Factura].[Numar Factura]
WHERE ((([Continut Factura].Cantitate)>50))
GROUP BY Carti.[Denumire Carte]
PIVOT Month([Data Facturii]);
Să se calculeze
suma valorică a
vânzărilor de
carte pe luni
SGBD Access : SQL: PARAMETERS
Interogările parametabile se realizeaza prin utilizarea de parametrii a
căror valoare poate fi schimbată la fiecare execuţie a interogării, ceea ce
face ca blocul de cerere să fie uşor adaptabil la necesităţile utilizatorilor.

• Abordarea Explicită – Înainte de a fi utilizaţi în mod efectiv, parametrii


sunt definiţi printr-o declaraţie ce precedă interogarea propriu-zisă:
PARAMETERS
Nume_parametru Tip_dată [, ... n] ;
SELECT ... (interogarea care foloseşte parametrii declaraţi în
prealabil) ;
• Abordarea Implicită – Parametrii sunt utilizaţi în mod direct în
interogare, fără a fi declaraţi anterior.
Orice text ce nu coincide cu numele unui câmp din tabelele sursă este în
mod automat asimilat unui parametru;
Numele de parametrii care includ spaţii trebuie delimitate prin paranteze
drepte [ ].
SGBD Access : SQL: PARAMETERS
A (a1, a2, a3, a4, a5, a6)
B (b1, b2, a1, b3) PARAMETERS [Reper numeric] Integer,
[Reper dată] Date ,
SELECT DISTINCT a1, a2, a4
FROM A INNER JOIN B ON A.a1 = B.a1
WHERE b3 = [Reper dată]
AND b2 > [Reper numeric] ;

SELECT a2, SUM(a3) AS Total FROM A


GROUP BY a2
HAVING SUM(a3) BETWEEN
[Precizati limita inferioară]
AND
[Precizati limita superioară] ;
SGBD Access: SQL: PARAMETERS

SELECT Facturi.[Numar Factura], Carti.[Cod ISBN], [Continut


Factura].Cantitate, [Continut Factura].[Pret f], [Cantitate]*[Pret f] AS
Valoare, [Tastati Procent]*[Valoare]/100 AS Reducere
FROM Facturi
INNER JOIN (Carti INNER JOIN [Continut Factura] ON Carti.[Cod
ISBN] = [Continut Factura].[Cod ISBN]) ON Facturi.[Numar Factura]
= [Continut Factura].[Numar Factura]
WHERE (((Facturi.[Numar Factura])=[Tastati Nr_Fact])
AND ((Carti.[Cod ISBN])=[Tastati Cod_ISBN]));

Parameters
Reducere Percent,
Introduceti_Numar_factura LongInteger
Introduceti_Cod_ISBN LongInteger
SGBD Access : SQL: Crearea tabelelor
CREATE TABLE nume_tabelă
( nume-atribut1 tip_dată(mărime) [NOT NULL]
[,nume-atribut2 tip_dată(mărime) [NOT NULL]..]
[CONSTRAINT nume-atribut CHECK (nume-atribut <condiţie>…)]
[CONSTRAINT nume_index] {PRIMARY KEY|UNIQUE|NOT
NULL }]);

CREATE TABLE Carti


([Cod ISBN] Text(15) CONSTRAINT [Cod ISBN] Primary Key,
[Denumire Carte] Text(50), NOT NULL
[Data Apariţiei] Date NOT NULL,
[Stocul tiparit] Number, CONSTRAINT [Stocul tiparit] CHECK
([Stocul tiparit] BETWEEN 1000 AND 3000),
[Pret baza] Currency NOT NULL);
SGBD Access : SQL: Modificarea structurii

ALTER TABLE nume_tabelă


ADD nume-atribut tip_dată(mărime) [NOT NULL]
[CONSTRAINT nume-atribut CHECK (nume-atribut <condiţie>…)];

ALTER TABLE Carti


ADD [Nume coordonator lucrare] Text(25) NOT NULL;

SGBD Access : SQL: Ştergerea unei tabele

DROP TABLE nume_tabelă ;

DROP TABLE [Clienti Buzau];


SGBD Access : SQL: Manipularea datelor:
Interogări cu acţiune de CREARE de tabele

SELECT [domeniu] (câmp1, câmp2,....)


INTO nume tabelă nouă
FROM nume tabelă sursă
[WHERE criteriu de adăugare a înregistrărilor în tabela nouă];

SELECT [Cod Fiscal], [Denumire Client], Adresa, Localitate


INTO [Clienti din Bucuresti]
FROM Clienti
WHERE (Localitate="Bucuresti");
SGBD Access : SQL: Manipularea datelor
Interogări cu acţiune de ADĂUGARE de tupluri

INSERT INTO nume_tabelă (câmp1, câmp2,....)


VALUES (valoare_1, valoare_2,.....);

INSERT INTO [Clienti Arad] ([Cod Fiscal], [Denumire Client],


Adresa, Localitate)
VALUES ("r732469","SoftInfo SA","Str. Narciselor nr.5","Arad");
SGBD Access : SQL: Manipularea datelor
Interogări cu acţiune de ADĂUGARE de tupluri

INSERT INTO nume_tabelă_destinaţie (câmp1, câmp2,....)


SELECT [domeniu] (câmp1, câmp2,....)
FROM nume tabelă sursă
[WHERE criteriu de adăugare a înregistrărilor în tabela destinaţie];
INSERT INTO [Clienti din Bucuresti] ( [Cod Fiscal], [Denumire
Client], Adresa, Localitate )
SELECT [Cod Fiscal],[Denumire Client], Adresa,Localitate
FROM [Clienti Arad]
WHERE [Clienti Arad].[Denumire Client]) Like ("*SRL");
SGBD Access : SQL: Manipularea datelor:
Interogări cu acţiune de ŞTERGERE de tupluri

DELETE *
FROM nume_tabelă
[WHERE criteriu de ştergere a înregistrărilor];
DELETE *
FROM [Clienti Arad]
WHERE Telefon IS NULL;
SGBD Access : SQL: Manipularea datelor:
Interogări cu acţiune de MODIFICARE a valorilor

UPDATE nume_tabelă
SET nume_câmp=valoare_1
[,nume_câmp=valoare_2].....
[WHERE criteriu de actualizare a valorilor tuplurilor];

UPDATE Carti
SET [Pret baza] = [Pret baza]*1.15
WHERE (([Denumire Carte])="Baze de date")
AND ((Year([Data Aparitiei]))=2009);
Algebra relaţională

Algebra relaţională poate fi definită ca un set de operatori, care


prelucrează relaţii în scopul obţinerii altor relaţii.

Operatorii relaţionali se împart în :


•operatori de asamblare
• reuniunea;
• intersecţia;
• diferenţa;
• produsul cartezian
•operatori unari :
• proiecţia;
• selecţia
•operatori de extensie :
• compunerea;
18 • diviziunea
Algebra relaţională: Operatori de
Asamblare
Operatorii de asamblare sunt operatori binari, care primesc la
intrare două relaţii şi generează la ieşire o singură relaţie.
Operatori
Binari
Relaţie1 Relaţie3

Relaţie2

Operatorii de asamblare sunt:


•Reuniunea;
•Intersecţia;
•Diferenţa;
19 •Produsul cartezian.
Algebra relaţională: Operatori de Asamblare:R
Reuniunea a două relaţii R şi S, cu aceeaşi structură, unde R este
formată din n tupluri şi S este formată din m tupluri, are ca rezultat o a
treia relaţie T, având aceeaşi structură cu a relaţiilor sursă şi conţinând m
+n tupluri.
Relaţia R Relaţia S Relaţia T  (R reunit cu S)
A B C A B C A B C

a1 b1 c1 a3 b3 c3 a1 b1 c1
a2 b2 c2
a4 b4 c4
a2 b2 c2
a5 b5 c5
a3 b3 c3

Ex. Care sunt furnizorii care au livrat cel


a4 b4 c4
puţin unul dintre produsele A şi B = reuniunea
furnizorilor care au livrat A cu fz. care au livrat B a5 b5 c5
20
SELECT ….. UNION…..SELECT
Algebra relaţională: Operatori de Asamblare:I
Intersecţia a două relaţii R şi S cu aceeaşi structură este o relaţie T, (cu aceeaşi
structură), conţinând tuplurile identice aparţinând atât lui R cât şi lui S.

Relaţia R Relaţia T (R intersectat cu S)


Relaţia S
A B C
A B C A B C

a1 b1 c1 a3 b3 c3 a4 b4 c4

a2 b2 c2 a4 b4 c4
SELECT DISTINCT A, B, C FROM R
a4 b4 c4 a5 b5 c5 WHERE
A IN (SELECT A FROM S) AND
B IN (SELECT B FROM S) AND
Ex. Care sunt furnizorii care au
C IN (SELECT C FROM S)
livrat şi produsul A şi produsul B

Reprezentarea intersecției în cadrul SQL se


realizează in cadrul clauzei WHERE cu
ajutorul
21 operatorul IN și a subinterogărilor
Algebra relaţională: Operatori de Asamblare:D
Diferenţa a două relaţii R şi S având aceeasi structură (R-S), este o
relaţie T, cuprinzând mulţimea tuplurilor aparţinând lui R dar
neaparţinând lui S.
Diferenţa nu este comutativă. Atributele relaţiei “diferenţă” (T) sunt
cele ale primei relaţii (descăzutul), iar tuplurile care sunt extrase din
relaţia descăzut, nu se regăsesc în relaţia scăzător
Relaţia R Relaţia S Relaţia T  R-S
A B C A B C A B C
a1 b1 c1
a3 b3 c3
a2 b2 c2 a1 b1 c1
a4 b4 c4
Ex. Care sunt a2 b2 c2
a5 b5 c5
clienţii care au
cumpărat produsul
A, 22
fără a-l cumpăra
SELECT R.A FROM R
pe B WHERE A NOT IN (SELECT A FROM S)
Algebra relaţională: Operatori de Asamblare:PC
Produsul cartezian a două relaţii R şi S (RxS) este o relaţie T stocând
mulţimea perechilor obţinute prin concatenarea înregistrărilor
aparţinând lui R cu cele aparţinând lui S.

Relaţia T  RxS
Relaţia R Relaţia S
A B C D E
C D E
A B
a1 b1 c1 d1 e1
a1 b1 c1 d1 e1

c2 d2 e2 a1 b1 c2 d2 e2
a2 b2
c3 d3 e3 a1 b1 c3 d3 e3

Simpla enumerare a tabelelor în cadrul a2 b2 c1 d1 e1


clauzei FROM, fără specificarea a2 b2 c2 d2 e2
anumitor condiții, generează ca rezultat
produsul
23
cartezian al acelor tabele a2 b2 c3 d3 e3
SELECT * FROM R, S)
Algebra relaţională: Operatori Unari

•Operatorii unari se aplică asupra unei relaţii şi


generează o altă relaţie.
•Operatorii unari operează prin restricţii.

Operatori
Unari
Relaţie1 Relaţie2

Operatorii unari permit decuparea unei relaţii pe


orizontală : Selecţia şi pe verticală: Proiecţia
24
Algebra relaţională: Operatori Unari:Pr
Proiecţia unei relaţii R după anumite atribute, este relaţia R1 cu
structura R1 (Ai1, Ai2, … , Aip), ale cărei tupluri se obţin prin eliminarea
valorilor atributelor din R care nu apar în R1 şi prin suprimarea
tuplurilor identice (dubluri) .
Altfel spus, prin intermediul proiecţiei, dintr-un tabel cu un anumit
număr de coloane se obţine unul cu un număr mai mic de coloane
Relaţia R Relaţia R1
A B C D
A B
a1 b1 c1 d1 R1 (R;A,B)
a1 b1
a2 b2 c2 d2
a2 b2
a3 b3 c3 d3
a3 b2
25
Algebra relaţională: Operatori Unari:Sel
Selecţia relaţiei R faţă de criteriul Q este relaţia R1 cu aceeaşi structură
ca şi R, ale cărei tupluri satisfac criteriul specificat.

Altfel spus, prin operatorul de selecţie, dintr-un tabel cu un anumit


număr de coloane se obţine unul cu aceleaşi coloane, dar cu un număr
mai mic de rânduri.
 Selecţia triază dintr-o tabelă numai tuplurile ce satisfac o condiţie
precizată (printr-un predicat).
R1SELECTIE(R;A=a2
Relaţia R
OR A=a3) Relaţia R2
R1
A B R2SELECTIE(R;A=a2
a1 b1 AND B=b2) A B
a2 b2 a2 b2
a3 b3
26 a3 b3
Algebra relaţională: Operatori de
Extensie
Operatorii de extensie joacă un rol foarte important în
interogarea bazelor de date relaţionale.

Operatorii de extensie sunt:


•Compunerea (fuziunea / joncţiunea);
•Diviziunea.

27
Algebra relaţională: Operatori de
•Produsul cartezian era oExtensie: Joina două tabele.
fuziune necondiţionată
•COMPUNEREA reprezintă fuziunea a două relaţii care au o proprietate
comună.
Fie 2 relaţii R1(A1, A2, ...., An) şi R2(B1,B2,......Bm), care au 2 atribute
(comune) Ai şi Bj, definite pe acelaşi domeniu de valori, şi θ ansamblul
operatorilor de comparaţie {=, >, <, >=, <=, <>}ce pot fi aplicaţi celor
două atribute Ai şi Bj.
Theta-Compunerea relaţiei R1, prin Ai, cu relaţia R2, prin Bj (R1
►◄ θR2) este relaţia R3 ale cărei tupluri sunt obţinute prin concatenarea
fiecărui tuplu al relaţiei R1, cu tuplurile relaţiei R2, pentru care este
verificată condiţia θ instituită între Ai şi Bj.
Un caz particular al theta-compunerii este echi-compunerea, atunci când
operatorul de comparaţie θ este “=“
Echi-comp. pentru care există o denumire identică a atributelor de
28
legătură dintre cele 2 tabele  compunere naturală
Algebra relaţională: Operatori de Extensie: Join

•COMPUNEREA este echivalentă unui produs cartezian urmat de o


selecţie (şi eventual de o proiecţie).

Relaţia R3R1R2
Relaţia R1
A R1.B C R2.B D
A B C
a1 b1 c1 b1 d1
a1 b1 c1
a1 b1 c1 b2 d2

Relaţia R2 a1 b1 c1 b3 d3

B D
b1 d1 R4=Selecţie(R3, R1.B=R2.B)
b2 d2 A B C D
b3 d3 a1 29 b1 c1 d1
Algebra relaţională: Operatori de Extensie: Join

Cele 3 tipuri de joncţiuni prezentate (theta, echi, naturală) sunt de natură


internă şi prezintă 2 extensii:
• Compunerea externă;
• Semicompunerea

Compunerea externă include în tabela rezultat şi tupluri din una dintre


relaţii, sau din ambele relaţii, care prezintă valori ale atributului de
legătură ce nu se regăsesc în cealaltă relaţie
În cazul compunerii externe trebuie să se precizeze din care relaţie se vor
prelua tuplurile fără corespondent în cealaltă relaţie. Din acest punct de
vedere există:
 compunere externă la stânga (left outer join)
 compunere externă la dreapta (right outer join)
30  compunere externă totală (reuniunea celor 2 relaţii)
Algebra relaţională: Operatori de Extensie: Join

R1 R2 R3(R1,R1.C=R2.C,R2)
A B C C D E A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1 a1 b1 c1 c1 d1 e1
a3 b3 c3 c3 d2 e2
a2 b2 c2 c3 d2 e2
a3 b3 c3 c5 d3 e3 A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1
Left Outer JOIN
a2 b2 c2 Null Null Null
a3 b3 c3 c3 d2 e2

Right Outer JOIN A B R1.C R2.C D E


a1 b1 c1 c1 d1 e1
Null Null Null c5 d3 e3
Compunere totală a3 b3 c3 c3 d2 e2

31
Algebra relaţională: Operatori de
Extensie: Join
Semicompunerea a 2 tabele presupune selectarea tuplurilor din
prima tabelă care apar în joncţiune cu tuplurile din a doua tabelă

R1 R2 SemiCompunere
A B C C D E
A B C
a1 b1 c1 c1 d1 e1
a2 b2 c2 c3 d2 e2 a1 b1 c1
a3 b3 c3 c5 d3 e3 a3 b3 c3

R3(R1,R1.C=R2.C,R2)
A B R1.C R2.C D E
a1 b1 c1 c1 c1 d1
a3 b3 c3 c3 d2 e2
32
Algebra relaţională: Operatori de Extensie: Div
R1 Diviziunea relaţiei R1 prin relaţia R2 este relaţia R3 formată din
A B toate tuplurile care, concatenate cu fiecare tuplu din R2,
a1 b1 returnează întotdeauna un tuplu din R1 (R3 = R1 ÷ R2).
a2 b1
a3 b1
a1 b2 R2 Care dintre valorile
a3 b2
a4 b2
B R3
a1, a2, a3, a4 şi a5
a1 b3 b1 apar în relaţia R1, în
A
a3 b3 /
b2
tupluri, împreună cu
a5 b3 a1
toate valorile
a1 b4 b3 a3
a3 b4
atributului B
a4 b4
b4 (împărţitor) din R2,
a1 b5 b5 respectiv b1, b2, b3,
a2 b5
b4, b5 ?
a3
33 b5
a5 b5
Algebra relaţională: Operatori de Extensie: Div
Varianta de realizare prezentată presupune în prima etapă compunerea
R1 naturală a tabelelor „R1” și “R2” dupa elementul comun aferent
A B campului B.
a1 b1 Urmează apoi, obținerea printr-o proiecție doar a valorilor câmpului
a2 b1 A și reținerea, cu ajutorul selecției, doar a acelor înregistrări pentru
care numărul de duplicate este egal cu numărul de înregistrări din
a3 b1
tabelul împărțitor
a1 b2
a3 b2 SELECT A
R2
a4 b2 R3
B
FROM R1,R2
a1 b3
A WHERE R1.B=R2.B
a3 b3 /
b1
a5 b3 a1 GROUP BY A
a1 b4 b2
a3 HAVING
a3 b4
a4 b4
b3 Count(R1.B)=(SELECT
a1 b5 b4 COUNT(R2.B) FROM
a2 b5 R2;
b5
a3
34 b5
a5 b5
SQL - II

Structured Query Language

Prof.dr. Bogdan IONESCU


Dept. Informatică de Gestiune
ASE Bucureşti
SQL ➔ SELECT: INNER JOIN

O compunere internă
(INNER) sau echivalentă
(echicompunere) este aceea în
care liniile unui tabel sunt
combinate cu liniile altui tabel,
rezultând un număr total de
linii egal cu numarul de perechi
de inregistrari care au aceeasi
valoare in campul de legatura
(cazul 1 din Join Properties).
SGBD Access 2010: SQL ➔ SELECT: JOIN
LMD: Interogări de asociere (joncţiune / compunere) internă
Tabela A Tabela B Tabela C
a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1 c1 c2 c3 c4 C5 a1

Compunerile echivalente (EchiCompunerile) -> utilizează clauza WHERE (pt


selecţia înregistrărilor) asociată cu o egalitate a valorilor în câmpurile de legătură.

SELECT [domeniu] listă selecţie câmpuri din tabele diferite T1.a1,


FROM nume tabele T2.a1,
T1, T2,.....
[WHERE criteriu de compunere [şi de selecţie]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}]; .........

• A compus cu B şi A compus cu cu C SELECT A.a1, B.b2* B.b3


SELECT A.a1, A.a2, B.b1, C.c1, C.c3 AS Total
FROM A, B, C FROM A, B
WHERE A.a1=B.a1 AND A.a1=C.a1 WHERE A.a1=B.a1 AND
ORDER BY C.c3; A.a5>=10000;
SGBD Access 2010: SQL ➔ SELECT : JOIN
Tabela A Tabela B Tabela C

a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1 c1 c2 c3 c4 c5 b1

SELECT [domeniu] listă selecţie câmpuri din tabele diferite


FROM nume tabelă_1
{INNER/LEFT [OUTER]/RIGHT [OUTER] } JOIN nume tabelă_2
ON criteriu asociere
[WHERE criteriu de selecţie
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];

SELECT A.a5, B.b3, (A.a5*B.b3) AS [Produs] • A compus cu


FROM A rezultatul compunerii
dintre B şi C
INNER JOIN B ON A.a1=B.a1;
SELECT A.a1, A.a2, A.a5, B.b1, C.c1
FROM A
INNER JOIN B
(INNER JOIN C ON B.b1=C.b1)
ON (A.a1=B. a1 );
SELECT
Facturi.[Numar Factura],
[Continut Factura].[Cod ISBN],
[Continut Factura].Cantitate
FROM Facturi, [Continut Factura] Compunerea a
2 tabele
WHERE (WHERE)
Facturi.[Numar Factura] = [Continut
Factura].[Numar Factura];
Exemple:

SELECT
Facturi.[Numar Factura],
Carti.[Denumire Carte], Compunerea a 3 tabele
[Continut Factura].Cantitate, (WHERE)
Carti.[Pret fara TVA],
[Cantitate]*[Pret fara TVA]*(1-[Discount]) AS Valoare
FROM Facturi,Carti, [Continut Factura],
WHERE
Facturi.[Numar Factura] = [Continut Factura].[Numar Factura]
AND
Carti.[Cod ISBN] = [Continut Factura].[Cod ISBN];
Exemple:

Compunerea a 2 tabele
(INNER JOIN)

SELECT
Facturi.[Numar Factura],
[Continut Factura].[Cod ISBN],
[Continut Factura].Cantitate

FROM Facturi INNER JOIN [Continut Factura]

ON Facturi.[Numar Factura] = [Continut Factura].[Numar


Factura];
Exemple:

Compunerea a 3
tabele (INNER
JOIN)

SELECT
Facturi.[Numar Factura], Carti.[Denumire Carte],
[Continut Factura].Cantitate, Carti.[Pret fara TVA],
[Cantitate]*[Pret fara TVA]*(1-[Discount]) AS Valoare

FROM Facturi INNER JOIN (Carti INNER JOIN [Continut Factura]

ON Carti.[Cod ISBN] = [Continut Factura].[Cod ISBN])

ON Facturi.[Numar Factura] = [Continut Factura].[Numar Factura];


SQL ➔ SELECT: LEFT JOIN

Tabela A Tabela B
a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1

LEFT [OUTER] JOIN (1→n) include toate înregistrările din tabela A


(cardinalitate “1”) şi numai acele înregistrări din tabela B (cardinalitate
“n”) pentru care valorile atributelor cheie (a1) sunt egale.
SQL ➔ SELECT: RIGHT JOIN

RIGHT [OUTER] JOIN (1n) include toate înregistrările din


tabela “[Continut factura]” (cardinalitate “n”) şi numai acele
înregistrări din tabela “Carti” (cardinalitate “1”) pentru care valorile
atributelor cheie [Cod ISBN] sunt egale (cazul 3 din Join Properties).
SQL ➔ SubInterogări SELECT în SELECT în .....

O subinterogare sau o interogare imbricată presupune ca


setul de rezultate obţinut de la o interogare să constituie
argument pentru o alta (interogare în interogare).

Subinterogări construite pe o singură tabelă

SELECT [domeniu] listă selecţie câmpuri


FROM nume tabelă
[WHERE câmp / expresie > / < / >= / <= / <> / = / [IN]
(SELECT câmp
FROM nume tabelă
[WHERE criteriu de selecţie subinterogare])
[AND criterii_selecţie_interogare];
Care sunt facturile emise în aceeaşi zi cu factura 45698753 ?
SELECT Facturi.[Numar Factura]
FROM Facturi
WHERE [Data Facturii] IN (SELECT [Data Facturii]
FROM Facturi WHERE [Numar Factura] = 45698753);
Execuţia interogării se va derula în doi timpi:
 executarea subcererii SELECT [Data Facturii] FROM
Facturi WHERE [Numar Factura] = 45698753 se
materializează într-o singură tabelă intermediară cu o singură
linie.
Exemplu:

NUMĂRUL DE FACTURI EMISE CLIENŢILOR DUPĂ 01/05/2012

SELECT [Cod Fiscal], Count(*) AS NR


FROM
(SELECT * FROM Facturi
WHERE [Data Facturii]>#01/05/2012#)

GROUP BY [cod fiscal];


SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela A Tabela B

a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1

Subinterogări construite pe mai multe tabele


Legătura dintre tabele Legătura dintre tabele
se realizează prin se realizează printr-o
subinterogare (fără o compunere explicită
compunere explicită) (JOIN)

SELECT [domeniu] listă selecţie câmpuri


FROM nume tabelă_1
[WHERE tabelă_1.câmp legătură=ANY(SELECT câmp legătură
FROM nume tabelă_2
[WHERE criteriu de selecţie pentru subinterogare])

SELECT a1,a2,a5 Selectarea unor valori din A, pentru


FROM A o valoare restricţionată din B
WHERE A.a1=ANY(SELECT a1 FROM B WHERE b4>25000);
SQL ➔ SubInterogări SELECT în SELECT în .....
Selectarea unor valori
din Carti, pentru o
Legătura dintre tabele valoare restricţionată
se realizează prin din Continut Factura
subinterogare (fără o
compunere explicită)

SELECT Carti.[Cod ISBN], Carti.[Denumire Carte], Carti.[Pret fara TVA]


FROM Carti
WHERE Carti.[Cod ISBN] = ANY
(SELECT [Continut Factura]. [Cod ISBN]
FROM [Continut Factura]
WHERE [Continut Factura].Cantitate>100);
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela B
Tabela A
a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1

Subinterogări pentru care a fost construită o compunere


SELECT [domeniu] listă selecţie câmpuri
FROM nume tabelă_1,nume tabelă_2
[WHERE tabelă_1.câmp legătură=tabelă_2.câmp de legătură
AND
tabelă_1.câmp legătură=ANY(SELECT câmp de legătură
FROM nume tabelă_2
[WHERE criteriu de subinterogare])

SELECT a1,a2,a5
FROM A,B
WHERE A.a1=B.a1
AND
A.a1=ANY(SELECT a1 FROM B WHERE b4>25000);
SQL ➔ SubInterogări SELECT în SELECT în .....
Subinterogări pentru care a fost construită o compunere

Legătura dintre tabele


se realizează printr-o
compunere explicită
(JOIN)

SELECT Carti.[Cod ISBN], Carti.[Denumire Carte], Carti.[Pret fara TVA]


FROM Carti, [Continut Factura]

WHERE Carti.[Cod ISBN] = [Continut Factura].[Cod ISBN]

AND Carti.[Cod ISBN] = ANY


(SELECT [Continut Factura].[Cod ISBN]
FROM [Continut Factura]
WHERE [Continut Factura].Cantitate>100);
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela B Restricţionarea subinterogărilor agregate
b1 b2 b3 b4 b5 a1 prin clauza HAVING

În exemplele clasice, predicatele incluse în clauza


HAVING, comparau o expresie cu o constantă. În
cazul de faţă, se vor include în clauza HAVING
chiar subinterogări.

SELECT [domeniu] listă selecţie câmpuri şi/sau funcţii agregate


FROM nume tabelă
GROUP BY câmp de grupare
HAVING criteriu câmp de grupare > / < / >= / <= / <> / = /
(SELECT ... FROM...GROUP BY acelaşi câmp de grupare );
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela B (Facturi) Restricţionarea subinterogărilor
b1 b2 b3 b4 b5 a1
NrFact DataFact CodClient agregate prin clauza HAVING

Care este ziua in care au fost emise cele mai multe facturi ?
SELECT [domeniu] listă selecţie câmpuri şi/sau funcţii agregate
FROM nume tabelă
Se compară
GROUP BY câmp de grupare numărul de
HAVING criteriu câmp de grupare > / < / >= / <= / <> / = /
(SELECT ... FROM...GROUP BY acelaşi câmp de grupare );
facturi aferent
fiecărei zile cu
valorile extrase
SELECT b2, Count(b1) AS [Număr de facturi]
FROM B Se numără elementele de de
GROUP BY b2 tip b1 (număr factură), subinterogare
HAVING Count(b1) >= pentru fiecare dată (b2)
(Select MAX(Număr de facturi) FROM
Selectează numărul de
(SELECT Count(b1) elemente distincte de tip
FROM B b1 (nr.factura), adică
GROUP BY b2)); numărul de facturi ce
corespunde fiecarei zile
SQL ➔ SubInterogări SELECT în SELECT în .....
Care este oferta pe baza căreia s-au încheiat cele mai multe
contracte

SELECT CodOferta, Count(*) AS Nrcontracte


FROM Contract
GROUP BY CodOferta
HAVING Count(*) >=
(Select MAX([Nrcontracte]) FROM
(SELECT Count(NrContract) AS [Nrcontracte]
FROM Contract
GROUP BY CodOferta));
SQL ➔ SubInterogări SELECT în SELECT în .....
Care este oferta pe baza căreia s-au încheiat cele mai multe
contracte – DESCOMPUNERE :

Cate oferte au fost preluate de fiecare


contract in parte ?

Care sunt contractele care au preluat mai mult de 3 oferte ?


SQL ➔ SubInterogări SELECT în SELECT în .....
Care este oferta pe baza căreia s-au încheiat cele mai multe contracte
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela B Restricţionarea subinterogărilor agregate
b1
NrFact
b2
DataFact
b3 b4 b5 a1
CodClient
prin clauza HAVING

Care sunt zilele in care au fost emise mai multe facturi decât pe 13/02/2013 ?
SELECT [domeniu] listă selecţie câmpuri şi/sau funcţii agregate
FROM nume tabelă
GROUP BY câmp de grupare
HAVING criteriu câmp de grupare > / < / >= / <= / <> / = /
(SELECT ... FROM...GROUP BY acelaşi câmp de grupare );

SELECT b2, Count(b1) AS [Număr de facturi]


FROM B Se numără elementele de
GROUP BY b2 tip b1 (număr factură),
HAVING Count(b1) >= pentru fiecare dată (b2)
Select MAX(Număr de facturi) FROM
(SELECT Count(b1) AS [Număr de facturi] Selectează numărul de
FROM B elemente distincte de tip b1
(număr factură), aferente
WHERE b2=#13/03/2013#;
datei 13/03/2013
SQL ➔ SubInterogări SELECT în SELECT în .....
Care sunt zilele in care au fost incheiate mai multe contracte decât pe 13/02/2013 ?

SELECT DataContract, Count(NrContract) AS NrContractepeZi


FROM Contract
GROUP BY DataContract
HAVING Count(NrContract)>=
(SELECT
MAX (NrContractepeZi) FROM
(SELECT Count(NrContract) AS NrContractepeZi
FROM Contract
WHERE DataContract=#13/02/2013#));
Exemplu:
FACTURILE AL CĂROR NR. DE PRODUSE >
MEDIA

SELECT [Numar Factura], COUNT(*) AS NUMARPRODUSE


SELECT [domeniu] listă selecţie câmpuri şi/sau funcţii agregate
FROM [Continut Factura] FROM nume tabelă
GROUP BY [Număr Factura]) GROUP BY câmp de grupare
HAVING criteriu câmp de grupare > / < / >= / <= / <> / =
(SELECT ... FROM...GROUP BY);

HAVING COUNT(*)> X NUMĂRUL MEDIU DE PRODUSE DE PE O FACTURĂ

SELECT AVG(NUMARPRODUSE) AS MEDIE


FROM
X (SELECT [Numar Factura], COUNT(*) AS NUMARPRODUSE
FROM [Continut Factura]
GROUP BY [Număr Factura]);
SQL ➔ SubInterogări SELECT în SELECT în .....

În general, subinterogările conţin în instrucţiunea SELECT un


singur câmp rezultat.
… totusi, când subinterogarea furnizează prin setul dinamic de rezultate
mai multe înregistrări, pentru comparații în vederea utilizării acestor
rezultate, se pot utiliza cuvintele cheie:

• IN (verifică apartenenţa unei valori la o mulțime)


• ANY ori SOME (verifică dacă o valoare poate fi comparată cu un
element al unei mulțimi de valori)
• ALL (permite compararea unei valori cu toate elementele unei
mulţimi)
• EXISTS (verifică dacă subinterogarea returnează rezultate)
SQL ➔ SubInterogări SELECT în SELECT în .....
Utilizarea cuvântului cheie ALL: Să se afișeze codurile ofertelor cu cele
mai mici tarife negociate.

SELECT CodOferta, TarifNegociat


FROM Contract
WHERE TarifNegociat <=ALL
(SELECT TarifNegociat FROM Contract)
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela A Tabela B
a1 a2 a3 a4 a5 a6 b1 b2 b3 b4 b5 a1
CodClient NrFact CodClient

Care este clientul care a primit cele mai multe facturi ?


SELECT [domeniu] listă selecţie câmpuri şi/sau funcţii agregate
FROM nume tabelă
Predicatul ALL
GROUP BY câmp de grupare aferent clauzei
HAVING criteriu câmp de grupare > / < / >= / <= / <> / = / HAVING compară
(SELECT ... FROM...GROUP BY acelaşi câmp de grupare ); numărul de facturi
aferent fiecărui
client cu valorile
SELECT a1, Count(b1) AS [Număr de facturi] extrase de
FROM A INNER JOIN B ON A.a1=B.a1 subinterogare
GROUP BY a1 Se numără elementele de
tip b1 (număr factură),
HAVING Count(b1) >=ALL pentru fiecare client (a1)

(SELECT Count(b1) Selectează numărul de


FROM B elemente distincte de
tip a1 (CodClient)
GROUP BY a1;
SQL ➔ SubInterogări SELECT în SELECT în .....
Tabela B (Facturi)

b1 b2 b3 b4 b5 a1
NrFact CodClient

Tabela C (LiniiProduse) Tabela A (Clienti)


c1 c2 c3 c4 b1 a1 a2 a3 a4
CodProdus Nrfact CodClient

Care este clientul care a cumparat cele mai multe produse ?

Predicatul ALL
aferent clauzei
SELECT a1, Count(c1) AS [Număr de produse] HAVING compară
FROM A, B, C numărul de
WHERE A.a1=B.a1 AND B.b1=C.b1 produse aferent
GROUP BY a1 Se numără elementele de tip fiecărui client cu
HAVING Count(c1) >=ALL c1 (număr produse), pentru valorile extrase de
fiecare client (a1) subinterogare
(SELECT Count(c1) Selectează numărul de elemente
FROM B,C distincte de tip a1 (CodClient) ce
WHERE B.b1=C.b1 apar in combinatie cu produsele
GROUP BY a1; facturate
AUTORUL CARE A SCRIS CELE MAI
MULTE CĂRŢI

III. Selectarea elementelor de afişat: numele


autorului, CNP şi nr. de cărţi

SELECT AUTORI.CNP, AUTORI.[Nume Prenume], Count(*) AS NR


FROM AUTORI
INNER JOIN [AUTORI-CARTI]
ON AUTORI.CNP=[AUTORI-CARTI].CNP
GROUP BY AUTORI.CNP
II. Numărul maxim de cărţi scrise

HAVING ((Count(*)=(SELECT MAX(NR) AS MAXIM FROM


(SELECT CNP, COUNT(*) AS NR I. Câte cărţi a
FROM [Autori-Carti] scris fiecare
GROUP BY CNP)))); autor
SQL - I

Structured Query Language

Prof.dr. Bogdan IONESCU


Dept. Informatică de Gestiune
ASE Bucureşti
SGBD Access SQL

Limbajul SQL (Structured Query Language) este


un limbaj declarativ (neprocedural) care permite o comunicare
complexă şi rapidă a utilizatorului cu bazele de date, în funcţie de
cerinţele şi restricţiile informaţionale ale acestuia.
Printr-un limbaj declarativ (neprocedural) utilizatorul descrie
informaţiile pe care vrea să le obţină în urma interogării, fără a
preciza algoritmii necesari pentru obţinerea rezultatelor dorite.

SQL nu este un limbaj de programare sau de sistem, ci mai curând


face parte din categoria limbajelor de aplicaţii (orientate pe mulţimi)
pentru baze de date relaţionale.

Totuși, ultimele versiuni prezintă elemente caracteristice


limbajelor procedurale ce permit efectuarea de prelucrări complexe
asupra datelor prin implementarea, in diverse forme, a structurilor
clasice de programare.
SGBD Access SQL

Faptul că este un limbaj standard a condus la recunoaşterea


principalelor sale instrucţiuni de către mai multe SGBD-uri (Oracle,
Access, Dbase, INFORMIX, DB2, Visual FoxPro.)

Dialecte SQL:
T-SQL (Transact SQL) utilizat de Microsoft SQL Server,
PL/SQL (Procedural Language/Structured Query Language) - Oracle
SQL/PSM (SQL/Persistent Stored Module) utilizat în MySQL.

Dialectul SQL pentru Microsoft Access poate fi considerat o versiune


simplificată a limbajului T-SQL utilizat în Microsoft SQL Server, cu
anumite particularități specifice produselor din pachetul Office și cu
elemente de sintaxă mai permisive
SGBD Access: SQL
Pe lângă manipularea şi regăsirea datelor, SQL efectuează şi operaţii
complexe privind actualizarea şi administrarea bazei de date.
În funcţie de rolul lor în manipularea datelor şi tranzacţiilor,
instrucţiunile SQL, pot fi grupate în:

• instrucţiuni de definire a datelor care permit descrierea structurii


bazei de date;
• instrucţiuni de manipulare a datelor în sensul adăugării,
modificării şi ştergerii înregistrărilor;
• instrucţiuni de selecţie a datelor care permit consultarea bazei de
date;
• instrucţiuni de procesare a tranzacţiilor care privesc unităţile
logice de prelucrare şi constituie în fapt, operaţii multiple de
manipulare a datelor;
• instrucţiuni de control al cursorului;
• instrucţiuni privind controlul accesului la date.
SGBD Access: SQL

Cuvintele cheie ale “vocabularului” SQL (fraza SQL) sunt:


instrucţiunile, clauzele, funcţiile şi operatorii.

• Instrucţiunile: au cel mai important rol, deoarece determină


executarea unei acţiuni (SELECT; CREATE; INSERT; DELETE;
UPDATE).
• Clauzele restricţionează aria valorică a entităţilor ce participă la
interogare (WHERE; ORDER BY; GROUP BY; HAVING).

• Funcţiile îmbunătăţesc capacităţile SQL de a manipula datele


(Sum; Max; Avg; Count; Iif).

• Operatorii efectuează o comparare a valorilor selecţiei (=; >;


>=, >; >= And; Or; Not; Between; Like; In; .
Reguli de sintaxă ale unei fraze SQL: SGBD Access : SQL

 Limbajul SQL pentru Access nu face distincţie între majuscule şi


minuscule; Multi-linia este permisa.
• Orice frază SQL se va termina cu semnul “;” - optională în Access
• Se utilizează punctul (“.”) ca separator între numele tabelei şi
numele câmpului, atunci când o interogare are ca surse de date mai
multe tabele (SELECT Carti.Cod_ISBN);
• Se utilizează parantezele drepte (“[]”) pentru a încadra nume de
câmpuri interspaţiate sau purtătoare de caractere neaceptate de SQL
(SELECT Materiale.[Denumire Material])
• Se utilizează virgula (“,”) pentru a delimita elementele (parametri)
unei liste (SELECT Cod_Mat, Den_Mat, etc.)
• Elementele de tip şir de caractere se vor marca între
ghilimele(“text”), iar valorile de tip dată/timp se vor marca între #.
• Caracterele de înlocuire generice sunt “?” sau “*”
SGBD Access : SQL
Definirea unei interogări SQL în Access:
SGBD Access : SQL  SELECT
Limbajul de manipulare a datelor: Interogări (simple) de selecţie
SELECT [domeniu: DISTINCT/DISTINCTROW/TOP n] listă
câmpuri selectate / calculate
FROM nume tabelă(e)
[WHERE criteriu de selecţie]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];
Domeniul determină modalităţile de manipulare a înregistrărilor din
BD asupra căreia operează selecţia. Domeniul poate fi:
•DISTINCT elimină înregistrările care au valori duplicate în câmpurile
selectate (se va afişa doar o apariţie a datei multiple)
•DISTINCTROW elimină înregistrările duplicate în ansamblul lor (nu
numai pe acelea care au câmpuri duplicate atunci când în sursa de date
este formată din mai multe tabele;)
•TOP n afişează numai primele N înregistrări rezultate din interogare;
SGBD Access 2013: SQL  SELECT

SELECT [domeniu: DISTINCT/DISTINCTROW/TOP n] listă selecţie câmpuri


FROM nume tabelă(e)
[WHERE criteriu de selecţie]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];

Listă selecţie câmpuri reprezintă proiecţia BD, cuprinzând toate


câmpurile care vor apărea în tabela cu rezultatele interogării (,)
Clauza FROM nume tabelă precizează tabela sau tabelele (sau
interogări deja create) din care fac parte câmpurile ce fac obiectul
proiecţiei BD (,)
Clauza WHERE precizează criteriul de selecţie sub forma unei
expresii. Clauza este opţională şi nu operează cu funcţii totalizatoare
Clauza ORDER BY precizează criteriul de ordonare a înregistrărilor
selectate. Fiecare câmp precizat în Clauza ORDER BY constituie o
cheie de sortare (sensul sortării se precizează prin ASC (implicit) sau
DESC)
Algebra relaţională: Operatori Unari

•Operatorii unari se aplică asupra unei relaţii şi


generează o altă relaţie.
•Operatorii unari operează prin restricţii.

Operatori
Unari
Relaţie1 Relaţie2

Operatorii unari permit decuparea unei relaţii pe


orizontală : Selecţia şi pe verticală: Proiecţia
10
Algebra relaţională: Operatori Unari:Pr
Proiecţia unei relaţii R după anumite atribute, este relaţia R1 cu
structura R1 (Ai1, Ai2, … , Aip), ale cărei tupluri se obţin prin eliminarea
valorilor atributelor din R care nu apar în R1 şi prin suprimarea
tuplurilor identice (dubluri) .
Altfel spus, prin intermediul proiecţiei, dintr-un tabel cu un anumit
număr de coloane se obţine unul cu un număr mai mic de coloane
Relaţia R Relaţia R1
A B C D
A B
a1 b1 c1 d1 R1 (R;A,B)
a1 b1
a2 b2 c2 d2
a2 b2
a3 b3 c3 d3
a3 b2
11
Algebra relaţională: Operatori Unari:Sel
Selecţia relaţiei R faţă de criteriul Q este relaţia R1 cu aceeaşi structură
ca şi R, ale cărei tupluri satisfac criteriul specificat.

Altfel spus, prin operatorul de selecţie, dintr-un tabel cu un anumit


număr de coloane se obţine unul cu aceleaşi coloane, dar cu un număr
mai mic de rânduri.
 Selecţia triază dintr-o tabelă numai tuplurile ce satisfac o condiţie
precizată (printr-un predicat).
R1SELECTIE(R;A=a2
Relaţia R
OR A=a3) Relaţia R2
R1
A B R2SELECTIE(R;A=a2
a1 b1 AND B=b2) A B
a2 b2 a2 b2
a3 b3
12 a3 b3
SGBD Access 2013: SQL  SELECT : Exemple

Tabela A Selectarea tuturor atributelor din A

a1 a2 a3 a4 a5 a6
SELECT *
FROM A

Selectarea (fără dubluri) a lui a1 şi a5


Selectarea câmpurilor a1 şi a2 din A pentru care a5> 1000
SELECT DISTINCTROW a1,a2 SELECT DISTINCT a1,a5
FROM A FROM A
WHERE a5>1000;
Selectarea (fără dubluri a) lui a5 > 1000 şi a3=şir
SELECT DISTINCT a5
Selectarea lui a5 pt care a3 are o
FROM A
rădăcină precizată
WHERE a5>1000 AND a3=”text”; SELECT DISTINCT a5
FROM A
WHERE a3 LIKE ”*text”;
SGBD Access 2013: SQL  SELECT : Exemple

Selectarea (fără dubluri a) lui a5 <> (100,1000)


SELECT DISTINCT a5 Tabela A
FROM A a1 a2 a3 a4 a5 a6
WHERE a5
(NOT) BETWEEN 100 AND 1000

Selectarea lui a1 şi a rezultatului unui


produs dintre înregistrările tabelei A
Selectarea câmpurilor a2, a4 şi a5 din A pt.
care a2 să ia valorile 1500, 13000 şi 14000, SELECT DISTINCT a1, a2*a5
cu ordonare crescătoare a lui a1 şi
descrescătoare a lui a5
AS Valoare
FROM A
SELECT a2,a4,a5
FROM A
WHERE a2 IN(1500, 13000, 14000)
ORDER BY a2 ASC, a5 DESC;
SGBD Access 2013: SQL  SELECT : Exemple
Tabela A Obs. În lipsa opţiunii GRUP BY, la utilizarea
a1 a2 a3 a4 a5 a6 funcţiilor agregat, rezultatul va conţine o singură linie

SELECT funcţie_agregat1 AS [Alias], ...2,... Count (<>Null);


Sum Σ;
FROM nume tabelă(e) Min ; Avg;
WHERE criteriu de selecţie Max  Iif
Selectarea celei mai mari / mai mici / şi SELECT DISTINCTROW Max(a5)
medii valori a lui a5 din tabela A
AS [a5_Maxim], Min(a5) AS
[a5_Minim], Avg(a5) AS [a5_Medie]
Numărarea înregistrărilor din tabela A
FROM A
Selectarea rezultatului evaluării
unei condiţii, pentru care a2 este SELECT COUNT(*) AS [Număr de tupluri]
diferit de zero FROM A

SELECT a1, a5, a6, IIF(a5>=a6;a5-a6;a6-a5) AS [Rezultat evaluare]


FROM A
WHERE a2 IS NOT NULL;
SGBD Access 2013: SQL  SELECT
LMD: Interogări (complexe) de selecţie şi grupare
Funcţiile de grup (agregat) permit construirea unor interogări SQL
prin care utilizatorul poate să efectueze diverse calcule pentru
grupuri de înregistrări care au câmpuri de aceeaşi valoare.

SELECT [domeniu] [listă selecţie funcţie agregată(nume câmp) AS alias]


FROM nume tabelă(e)
WHERE criteriu de selecţie
[GROUP BY câmp(uri) de grupare]
[HAVING criteriul câmpului de grupare]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];

Listă selecţie se referă la una sau mai multe funcţii agregate care au
ca argumente nume de câmpuri ale tabelei(lor) bazei de date. Aceste
câmpuri trebuie să fie în mod obligatoriu numerice.
AS ALIAS asociază un pseudonim aferent rezultatului unui calcul
simplu sau unei funcţii agregat.
SGBD Access 2013: SQL  SELECT
LMD: Interogări (complexe) de selecţie şi grupare

SELECT [domeniu] [funcţie agregată(nume câmp) AS alias] [, listă selecţie]


FROM nume tabelă(e)
[GROUP BY câmp(uri) de grupare]
[HAVING criteriul câmpului de grupare]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];

Clauza GROUP BY precizează câmpul (câmpurile) pe baza căruia se


va efectua gruparea înregistrărilor. Astfel, se pot executa funcţiile
agregate descrise în lista de selecţie pentru fiecare dintre grupurile de
înregistrări ( cu linia de Total în QBE)
Clauza GROUP BY formează grupuri de tupluri ale unei relaţii, pe
baza valorilor comune luate de un atribut.
Rezultatul unei fraze SELECT ce conţine clauza GROUP BY se
obţine prin regruparea tuturor liniilor din tabelele enumerate în
FROM, extrăgându-se câte o singură apariţie pentru fiecare
valoare distinctă a coloanei sau a grupului de coloane
SGBD Access 2013: SQL  SELECT
LMD: Interogări (complexe) de selecţie şi grupare

Tabela A (Conţinut Factură)


SELECT a1, SUM(a3*a4) AS a5
FROM A
a1 a2 a3 a4 GROUP BY a1;
100 305 25 12,5
1.Se ordonează liniile tabelei A după a1;
100 208 10 20 2. Se constituie un grup pentru fiecare
valoare distinctă aferentă atributului a1;
100
85 30 10 3. Se aplică funcţia agregată SUM asupra
grupurilor;
101 208 8 20 4. Se obţine rezultatul, al cărui număr de
linii coincide cu valorile distincte ale lui a1
101 74 10 30
Tabela R
103 90 5 5
a1 a5=SUM(a3*a4)
103 74 25 30 100 812,5
101 460,0
103 775,0
SGBD Access 2013: SQL  SELECT
LMD: Interogări (complexe) de selecţie şi grupare

SELECT [domeniu] [funcţie agregată(nume câmp) AS alias] [, listă selecţie]


FROM nume tabelă(e)
[GROUP BY câmp(uri) de grupare]
[HAVING criteriul câmpului de grupare]
[ORDER BY listă câmpuri criterii de ordonare {ASC/DESC}];

HAVING se referă la restricţia aplicată câmpului de grupare.


Clauza WHERE acţionează înainte de gruparea înregistrărilor, în
timp ce HAVING activează restricţia după gruparea acestora.

Deci, prin asocierea clauzei HAVING la GROUP BY este posibilă


selectarea anumitor grupuri de tupluri ce îndeplinesc un criteriu
numai la nivel de grup.
SGBD Access 2013: SQL  SELECT
SELECT a1, SUM(a3*a4) AS a5
FROM A
Tabela A (Conţinut Factură) GROUP BY a1
a1 a2 a3 a4
HAVING SUM(a3*a4) >500;

100 305 25 12,5


Tabela R
a1 a5=SUM(a3*a4)
100 208 10 20 100 812,5
100
85 30 10 103 775,0
Tabela R1
101 208 8 20
a1 a5=SUM(a3*a4)
460
101 74 10 30 100 812,5

103 90 5 5 SELECT a1, SUM(a3*a4) AS a5


FROM A
103 74 25 30 WHERE a3>5
GROUP BY a1
HAVING SUM(a3*a4) >750;
SGBD Access 2013: SQL  SELECT
Tabela B

b1 b2 b3 b4 b5 a1

SELECT b1, b2, b4, b5, b3*b4 AS [produs b3 şi b4]


FROM B
WHERE b2=”ctiteriu text”
GROUP BY b5
HAVING Sum(b3*b4)>30;

SELECT b1, b2, Avg(b3) AS [medie b3], Count(*) AS [Total]


FROM B
GROUP BY b3,
HAVING Avg(b3)>25 AND
Count (*)>5
SGBD Access : Macros
Crearea și gestionarea obiectelor de tip macro
într-o bază de date Access
Obiectele de tip macroinstrucţiune
(Macros) sunt constituite dintr-un
ansamblu de acţiuni executabile
activabile :
• la un clic de mouse,
• ca urmare a unui eveniment
• printr-o combinaţie de taste.

Acţiunile unui obiect macro se aplică obiectelor dintr-o bază de date.


Ce sunt și când pot fi utilizate obiectele tip macro?

 Obiect macro: Instrument prin care este posibilă


automatizarea operațiunilor aferente unei baze de
date Access, constând dintr-o serie de acțiuni
predefinite, ce vor fi executate în ordinea în care au
fost descrise de utilizator.
 Acțiune macro:
– microprogram care, prin executarea sa, este capabil să
ducă la finalizare operațiunea pe care o definește.
– parțial personalizabilă prin argumentele sale.
Tipuri de obiecte macro
 După modul de stocare în cadrul unei
baze de date Access:
1. Obiecte tip macro autonome:
 Au o existență de sine stătătoare;
 Pot fi utilizate în scenarii multiple prin simpla lor apelare
prin nume.
2. Obiecte tip macro încapsulate:
 Sunt definite la nivel de formular, ca parte componentă a
acestuia sau aparținând unui control din formular.
 Sunt lansate în execuție la apariția unui eveniment
declanșator intern.
 Nu pot fi apelate din exteriorul formularului.
Tipuri de obiecte macro
 În funcție de gradul de complexitate:

1. Obiecte tip macro elementare:


 Create pentru efectuarea unei singure serii de acțiuni
definite într-o anumită ordine.
2. Obiecte macro cu condiții:
 Permit executarea acțiunilor definite în cadrul lor în
funcție de îndeplinirea uneia sau mai multor condiții.
3. Grupuri de obiecte macro:
 Înglobează mai multe serii de acțiuni, grupate sub nume
distincte.
SGBD Access : Macros

Acţiunile executabile prin MACRO pot viza :


• deschiderea unui obiect tip tabel, cerere, formular, raport;
• precizarea modului de acces la date la deschiderea unor
obiecte ale bazei de date
• filtrarea datelor afişate într-un obiect tabel sau formular;
• căutarea unei înregistrări potrivit unui anumit criteriu;
• configurarea imprimării sau imprimarea unui formular;
• iniţializarea conţinutului anumitor câmpuri;
• operațiuni automate de backup și restaurare a datelor.
• automatizarea importului/exportului de date;;
• executarea unei instrucţiuni (fraze) SQL
SGBD Access : Crearea obiectelor Macro
Crearea unui obiect macro -> din Ribbon bar se alege comanda Create
selectandu-se butonul Macro.

Ca efect, pe
ecran se
afişează
catalogul
acțiunilor
Macro
SGBD Access : Crearea obiectelor Macro

Comment poate conţine explicaţii


(comentarii) cu privire la acţiunea
selectată.

Group permite actiunilor sa fie grupate


sub un nume intr-un bloc.

If permite executia blocurilor logice, dacă


o condiție este evaluata cu TRUE.

Submacro permite colecțiilor de acțiuni macro să fie identificate


printr-un nume și să fie apelate prin RunMacro sau OnError.
SGBD Access : Crearea obiectelor Macro

Acţiunea OpenForm, la
execuţie va deschide pentru
adăugare formularul intitulat
Clienţi (acest formular trebuie
să fie creat înainte de a defini
obiectul macro care conţine
acţiunea de deschidere a lui).

Obiectul macro creat se salvează prin comanda Save As, moment în care
se redenumeşte obiectul macro prin tastarea numelui în zona de text
Macro Name din caseta de de dialog Save As.

Observaţie: Numele Autoexec se poate atribui unui singur obiect


macro dintr-o aplicaţie pentru a desemna macro ce se execută
automat la activarea aplicaţiei cu baze de date.
SGBD Access : Testare Macro
Un obiect macro trebuie testat pentru a vedea dacă acţiunile au fost
corect programate. Pentru testare, de regulă, se activează butonul ! Run
(meniul Design ataşat ribbonului.

 Apelarea prin butonul Run Macro din grupul de meniuri Database


Tools, precizând numele obiectului macro.

 La declanșarea unui eveniment al unui control sau formular la care


obiectul macro a fost atașat.
SGBD Access : Testare Macros
SGBD Access 2007: Testare Macros
SGBD Access : Modificare Macros

Pentru a modifica conţinutul unui obiect macro se deschide obiectul


macro în mod Design (clk dr pe meniul contextual al obiectului macro).
Modificările pot viza acţiunile existente, adăugarea de noi acţiuni,
suprimarea unor acţiuni existente sau schimbarea ordinii acestora.
Tipuri de Acţiuni Macro şi Grupuri de Acţiuni

Grupuri funcţionale de acţiuni


Acţiunile Access ce se pot utiliza la construirea de
macrocomenzi se pot grupa funcţional după cum urmează :

➢Intrări de date (Data Entry Operations)


➢Transfer date (Data Import/Export)
➢Obiecte (Database Objects)
➢Filtrare (Filter/Query/Search)
➢Grup Control Execuţie aplicaţie (Macro Commands)
➢Comenzi la nivel de sistem (System Commands)
➢Interfaţă cu utilizatorul (User Interface Commands)
➢Ferestre (Window Management)
Grupuri de Acţiuni : Intrări de date
Acţiunile din acest grup acţionează asupra
ÎNREGISTRĂRILOR.

Grupul conţine următoarele acţiuni :

1. Ștergerea unei înregistrări (DeleteRecord));


2. Modificarea unei înregistrări (EditListItems);
3. Salvarea unei înregistrări (SaveRecord)
Grupuri de Acţiuni Macros: Grup Obiecte
Acţiunile din acest grup acţionează asupra obiectelor (tabel,
interogare, formular, raport, macro sau modul),
controalelor sau proprietăţilor.
Grupul conţine următoarele acţiuni :
1. Deplasarea la un anume câmp sau control într-un
obiect tip formular, tabel sau interogare (GoToControl;
GoToRecord; GoToPage);
2. Deschiderea unui obiect al bazei de date (Open Table,
OpenQuery, OpenReport, OpenForm, etc);
3. Imprimarea unui obiect deschis (PrintObject;
PrintPreview);
4. Setarea proprietăţilor controalelor şi/sau formularelor
(SetProperty :Item / Expressions);
5. Selectarea unui obiect al bazei de date (SelectObject);
Grupuri de Acţiuni Macros: Grup Filtrare
Acţiunile din acest grup aplică filtre de selecție asupra înregistrărilor.
Grupul conţine următoarele acţiuni :
1. Filtrarea înregistrărilor afişate în obiectele: tabel, formular sau
raport (ApplyFilter) Filter Name / Where Condition);
2. Înlăturarea filtrelor (ShowAllRecords);
3. Deschiderea unui obiect de tip Query (OpenQuery)
4. Actualizarea înregistrărilor (Refresh);
5. Căutarea următoarei / anterioarei înregistrări (FindRecord);
6. Efectuarea unei noi căutări folosind argumentele celei mai
recente acţiuni (FindNextRecord)
7. Cautarea unei înregistrări într-un obiect tip tabel sau formular
(SearchForRecord);
8. Aplicarea unui filtru, interogare, clauză SQL WHERE
(SetFilter);
9. Aplică o sortare datelor unei tabele, formular sau raport
(SetOrderBy);
10. Actualizarea datelor afişate de un control (Requery)
Grupuri de Acţiuni Ferestre

1. Închidere fereastră (CloseWindow);


2. Maximizare fereastră (Maximize);
3. Minimizare fereastră (Minimize);
4. Deplasare fereastră (MoveAndSizeWindow)
5. Restaurare fereastra (RestoreWindow)
Grupuri de Acţiuni Transfer

1. Transfer general (.xls; .rtf; .txt; .htm) -


(ExportWithFormattinf);
2. Transfer către MailMerge (WordMailMerge)
3. Transfer de date de contact către/dinspre OutLook
(AddContactFrom Outlook / SaveAsOutlookContact);
Grupuri de Acţiuni SISTEM

1. Producerea unui semnal sonor de avertizare (Beep).


2. Închiderea bazei de date Access (CloseDatabase);
3. Afișare pointer (DisplayHourglassPointer);
5. Închiderea aplicaţiei Access (QuitAccess)
Grupuri de Acţiuni Macros: Grup Ctrl. Aplic.

1. Anularea evenimentului care a determinat executarea


macro-comenzii (CancelEvent)
2. Anularea mesajului de eroare produs de o
macrocomanda (ClearMacroError)
3. Administrarea erorilor (OnError)
4. Lansarea în execuţie a unei funcţii scrise în limbajul
VBA (RunCode);
5. Executarea unei macrocomenzi (RunMacro)
6. Executarea unei macrocomenzi de tip Datamacro
(RunDataMacro)
7. Oprirea executării unei macrocomenzi (StopMacro /
StopAllMacros)
Grupuri de Acţiuni Macros: Grup Interfaţă
1. Adăugarea de meniuri personalizate (AddMeniu);
2. Ascunderea/afişarea de bare cu instrumente
(ShowToolbar),
3. Setarea stării activ/inactiv a unui element din
meniuri (SetMeniuItem);
4. Afişarea unui mesaj pentru utilizator (MsgBox)
5. Anulează ultima acțiune a utilizatorului
(UndoRecord);
Evenimente la care răspund formularele

 La deschiderea/închiderea formularului:
OnOpen, OnLoad, OnUnload, OnClose, etc.
 La modificări survenite asupra datelor:
BeforeUpdate, AfterUpdate, BeforeInsert,
AfterInsert, OnDelete, etc.
 La acţiuni ale dispozitivelor periferice de intrare:
OnClick, OnDblClick, OnKeyPress,
OnMouseMove, etc.
 La detectarea expirării unei perioade de timp:
OnTimer
Grupuri de Acţiuni Macros: Exemplu
Grupuri de Macroinstrucţiuni

Un obiect macro poate conţine grupuri de acţiuni.

Astfel, fiecare grup este desemnat printr-un nume de


macro.

Toate acestea se vor memora în acelaşi obiect macro


definindu-se operaţiuni multiple într-o singură
locaţie.
Access poate conţine un număr nelimitat de obiecte
macro individuale definite prin nume unice la nivelul
grupului.
Grupuri de Macroinstrucţiuni: ShortCut

Ctrl+a
^a
Grupuri de Macroinstrucţiuni: ShortCut

Ctrl+q
Ctrl+r

^r
Condiţionarea executării acţiunilor
Executarea unora dintre acţiunile obiectelor macro poate fi condiţionată
folosind expresii condiţionale.
Mod de lucru : din panoul Action Catalog se alege If
SGBD Access: Modificare Macros
SGBD Access : Reports

Obiectele de tip raport (Reports) se


creează în etapa de exploatare a
bazelor de date.
Conţinutul lor poate fi vizualizat pe
ecran sau se poate lista la
imprimantă .
SGBD Access : Reports
1  Tabul Create.
Crearea 2  Se optează pentru una din variantele
Rapoartelor: de realizare a raportului din grupul de
optiuni Reports:

• Report Design – crearea raportului cade în sarcina exclusivă a utilizatorului;


• Report Wizard – utilizatorul va fi asistat la crearea raportului;
• BlankReport – crearea raportului cade în sarcina exclusivă a utilizatorului;
• Report – se creează automat un raport cu datele organizate sub forma
tabelară;
• Label – se generează rapoarte în format de “etichetă” prin urmarea unor etape
propuse de un asistent.
Crearea rapoartelor în ReportDesign
Report Design  Selectarea acestei opţiuni are ca efect generarea unui
raport gol, în care utilizatorul îşi poate defini propriile secţiuni şi controale.
Câmpurile sursei de date pot fi afişate prin preluarea lor din fereastra Field
List (butonul Add Existing Fields) în interiorul raportului (de obicei în
secţiunea Detail).

Antetul/Subsolul raportului
(Report Header/Footer)
DClk-Report Header/Footer

Antetul/Subsolul paginii (Page


Header/Footer) DClk-Page
Header/Footer
Raport : Situatia cartilor livrate in 2010 pe CLIENTI
Raport : Situatia cartilor livrate in 2010 pe CLIENTI
Grupuri: Situatia cartilor livrate in pe CLIENTI
Grupuri: Situatia cartilor livrate in pe CLIENTI

Editarea grupului “Luna”


pentru antet (Header)

Declararea grupului “Luna” Editarea grupului “Luna”


pentru subsol (Footer) pentru subsol (Footer)
Grupuri: Situatia cartilor livrate in pe CLIENTI

Antetul grupului “Luna”

Subsolul grupului “Luna”


Grupuri: Situatia cartilor livrate in pe CLIENTI
Editarea grupului
“Denumire client”
doar pentru antet
Detail (rând curent : Valoare=Cant*Pret)
Total Luna (Σ valoare)
Total Client (Σ Luna)=(Σ Σ valoare)
Total General (Σ Client)=(Σ Σ Luna) (Σ Σ Σ valoare)
SGBD Access : Reports: Proprietăţi
a.Format
Caption este utilizată pentru stabilirea unui titlu afişat
pe bara de titlu a ferestrei;
Page Header şi Page Footer sunt utilizate pentru
specificarea paginilor pe care se vor afişa antetul,
respectiv subsolul de pagină (variante: toate paginile;
toate, mai puţin prima; toate, mai puţin ultima; toate,
mai puţin prima şi ultima);
Picture permite specificarea fişierului afişat pe
fundalul raportului;
Picture Pages precizează paginile pe care se va afişa
fundalul ales.
b. Data
 Record Source precizează o tabelă, o interogare, ori o
frază SQL care va fi sursa de date a raportului;
 Filter se foloseşte pentru stabilirea unei condiţii-filtru pe
care trebuie s-o îndeplinească datele ce vor fi afişate în
raport;
 Filter on permite selectarea a două valori: Yes, ceea ce
presupune activarea criteriului specificat în Filter (se
aplică datelor) şi No, care anulează acţiunea filtrului;
 Order By, care precizează criterii de sortare, în ordinea
gradului de generalitate, cu virgulă între ele;
 Order By On poate cuprinde valorile Yes sau No,
activând sau dezactivând proprietatea Order By.
Access : Parametrarea rapoartelor

Parametrarea
obtinerii
raportului
Raport editat pentru clientul “Ion ComProd SRL” pentru un
client
Access : Parametrarea rapoartelor
SGBD Access : Parametrarea rapoartelor
SGBD Access : Reports: Proprietăţi
c. Event - proprietăţi de tip eveniment.
 On Open serveşte , în principal, la definirea de filtre;
 On Close poate realiza ştergerea fişierelor temporare create în
timpul execuţiei raportului. În general, acestora le sunt ataşate
funcţii ori proceduri.

d. Other – alte proprietăţi.


 Record Looks asigură blocarea informaţiilor dintr-un raport în
timpul afişării acestuia;
 Date Grouping permite utilizarea tipului implicit de dată sau a
tipului setat de utilizator;
 Fast Laser Printing, cu valoarea Yes, realizează o tipărire rapidă
a unui raport, etc.
SGBD Access : Subrapoarte: Proprietăţi

Proprietăţi ale secţiunilor rapoartelor (categoria


Data lipseşte) servesc la:
atribuirea unui nume fiecărei secţiuni
(Name);
efectuarea saltului la pagină nouă (Force
New Page);
ascunderea/afişarea anumitor date (Visible –
Yes/No);
SGBD Access : Reports: Wizard 1
1. Se alege sursa de date (tabel sau interogare) si se selectează
câmpurile ce vor fi afişate în raport, folosind butoanele de selecţie
SGBD Access : Reports: Wizard 2
2. Se aleg ierarhiile informationale ale datelor pornind
de la agregarile existente in sursa de date
SGBD Access : Reports: Wizard 3

3. Se
definesc
câmpurile de
grupare a
datelor, pe
niveluri de
imbricare
descendentă (de
la “mare” la
“mic”).
SGBD Access : Reports: Wizard 4

4.1 Se definesc
câmpurile după care vor fi
ordonate datele în cadrul
grupurilor (sunt admise 4
niveluri de sortare)

4.2 Se precizează
câmpurile din cadrul
grupului, pentru care se vor
calcula totaluri sau
subtotaluri şi se va alege
tipul de calcul aplicabil
acestora
SGBD Access : Reports: Wizard 5-6
5. Se stabileşte modul
de afişare, corespunzător
şabloanelor predefinite,
precum şi orientarea în
pagină

6. Se
stabileşte
titlul
raportului
SGBD Access : Reports: Wizard
SGBD Access : SubReports
Dacă se doreşte completarea informaţiilor dintr-un obiect de
tip raport cu alte informaţii conţinute de diferite alte rapoarte,
se poate genera un RAPORT PRINCIPAL în care se
integrează SUBRAPOARTE.
Acestea se pot insera atât în secţiunea de detaliu, cât şi în
celelalte secţiuni (inclusiv în cele de grup).
Ca şi în operaţiunea de creare a subformularelor, se utilizează
butonul din caseta de instrumente (controale) – Toolbox,
cu sau fără activarea Wizard-ului
.

De asemenea, se poate aduce subraportul pe suprafaţa de


lucru, într-una dintre secţiunile raportului principal, din
fereastra cu obiectele bazei de date, utilizând tehnica drag-
and-drop.
SGBD Access: Reports: Wizard

În cazul în care operaţiunea de creare de subraport se


desfăşoară fără Wizard, utilizatorul trebuie să verifice dacă
proprietăţile subraportului: Link Child Fields şi Link
Master Fields au primit numele aceluiaşi câmp de legătură
dintre raportul principal şi subraport.

•În acest exemplu, în cadrul raportului principal Facturi, a fost inserat


subraportul Continut Factura (câmpul de legătură: Numar Factura)
şi Facturi (câmpul de legătură: Numar Factura) .

•Întrucât date din subraport sunt încadrate implicit de o


linie, proprietăţii Border Style i s-a atribuit valoare
Transparent.
SGBD Access : Forms
Formularul (Form) este un obiect ce permite
introducerea datelor, afişarea acestora,
controlul actualizării datelor introduse în
tabele sau controlul întregii aplicaţii

Formularele asigură:
• Interfaţă prietenoasă cu utilizatorul
final, realizată prin intermediul diferitelor
controale (butoane, casete text, etc.) sau
altor elemente grafice incorporate;
• Actualizarea concomitentă a mai
multor tabele prin intermediul
subformularelor;
•Reguli de validare suplimentare celor
definite la nivelul tabelelor.
SGBD Access : Clasificare
După sursa de date:
Formulare legate (bound)- permit afişarea sau actualizarea datelor din
tabele;
Formulare nelegate (unbound)- destinate afişării sau editării unor date
care nu sunt stocate în tabele (mesaje, informaţii despre sistem, date
necesare unui raport etc.)
SGBD Access :
Vizualizarea formularelor
SGBD Access :
Vizualizarea formularelor
SGBD Access :
Vizualizarea formularelor
Access : Crearea formularelor

1.→ Tabul Create din fereastra bazei de date


2 → Se optează pentru una din variantele de
realizare a formularului
3→Se stabileşte sursa de date a formularului.
Crearea formularelor : 1
 Selectarea unei tabele (ca sursă a formularului)
din Panoul de navigare
Crearea formularelor : 1
 Click pe tabul Create + butonul Form din grupul
Forms
Crearea formularelor : 2
 Selectarea unei tabele (ca sursă a formularului)
din Panoul de navigare
 Click pe tabul Create + butonul Split Form din
grupul More Forms
Crearea formularelor : 3
 Selectarea unei tabele sau interogari (ca sursă
a formularului ) din Panoul de navigare
 Click pe tabul Create + butonul Multiple Items
din grupul More Forms
Crearea formularelor : 4
 Click pe tabul Create + butonul Blank Form
Crearea formularelor : 5
 Selectarea unei tabele (ca sursă a formularului)
din Panoul de navigare
 Click pe tabul Create + butonul Datasheet din
grupul More Forms
Crearea formularelor : 6
 Selectarea unei tabele (ca sursă a formularului)
din Panoul de navigare
 Click pe tabul Create + butonul Pivot Table din
grupul More Forms
Crearea formularelor : 7
 Selectarea unei tabele (ca sursă a formularului)
din Panoul de navigare
 Click pe tabul Create + butonul Pivot Chart din
grupul More Forms
Crearea formularelor : 8
 Click pe tabul Create + butonul Form Wizard
Crearea formularelor : 9
 Click pe tabul Create + butonul Form Design
din grupul Forms
Arhitectura formularelor
Controale
Formulare
Indicator Instrument folosit la proiectarea
(Select ) controalelor (selecţie, repoziţionare,
redimensionare, etc.)
Asistenţi Activează/dezactivează utilitarele Wizards folosite la
(Use Control generarea unor controale mai complexe (casete
Wizards) combinate, casete listă, grupuri de opţiune, etc.)

Eticheta Control cu conţinut fix, folosit pentru afişarea unor


(Label) mesaje. În general, Access generează câte o etichetă
pentru majoritatea controalelor definite de utilizator.

Caseta text Control utilizat pentru afişarea şi editarea datelor.


(Text Box)

Butonul de Serveşte la declanşarea unor acţiuni:


comandă
(Button)
Controale Formulare
Caseta listă Permite selectarea unei valori dintr-o listă.
(List Box)

Caseta combinată Îmbină proprietăţile unei casete text cu cele ale unei
(Combo Box) casete de tip listă (permite atât editarea unei valori,
cât şi selectarea acesteia dintr-o listă derulantă).
Caseta combinată este un control ce se foloseşte
frecvent pentru actualizarea cheilor externe.
Butonul-comutator Sunt controale folosite pentru editarea unor valori de
(Toggle Button), tip logic (Yes/No, On/Off, True/False).
Butonul de opţiune
(Option Button),
Caseta de validare
(Check Box)

Grupul de opţiune Este un control container folosit pentru afişarea unui


(Option Group) set de alternative şi poate grupa mai multe tipuri de
controale (buton de opţiune, casetă de validare etc.)
Controale Formulare
Delimitator de Controlul Page Break împarte formularul în mai multe pagini
pagină care pot fi vizualizate cu ajutorul tastelor <PageUp> şi
(Page Break) <PageDown>. Poate fi, de asemenea, folosit pentru salt la
pagină nouă, în cazul tipăririi formularului.
Index Controlul de tip Tab este un control container ce permite
(Control Tab) gruparea altor controale în mai multe pagini, atunci când
formularul conţine un număr prea mare de controale.
Linie Controalele servesc la trasarea diverselor figuri geometrice.
(Line)
Dreptunghi
(Rectangle)
Imagine Permite afişarea conţinutului unor fişiere grafice (.bmp, .gif,
(Image) .wmf, .pcx, etc.), pe fundalul formularului.

Obiect cadru Este un control ce va conţine un obiect (grafic, multimedia,


nelegat document etc.), importat dintr-o altă aplicaţie Windows
(Unbound Object (Word, Excel, Paint, Sound Recorder etc.) prin tehnologia
Frame) OLE (Object Linking and Embedding).
Obiect cadru legat Conţine un obiect stocat într-un câmp de tip OLE din tabela
(Bound Object sursă.
Frame)
Controale Formulare
Subformular Permite definirea unui subformular în cadrul formularului
(Subform) curent.

Attachement Permite atasarea de fisiere de respectivul control

Grafic Permite definirea unei reprezentari grafice pe baza unui


(Insert Chart) asistent de tipul Pivot Chart

Link Insereaza un link catre o pagina web, un desen, un


(Insert Hyperlink) program, un fisier, etc.)

Web Browser Insereaza un link catre o resursa webdefinita printr-un URL)


Control
Proprietăţile controalelor Formularelor
Proprietăţile unui control sunt afişate în fereastra Property Sheet, atunci
când controlul este selectat si activat.
Ca şi în cazul formularelor, proprietatile aferente controalelor sunt
grupate în patru categorii (Format, Data, Events, Other).
Proprietăţile controalelor Formularelor
Format, Data, Events, Other
Proprietăţile controalelor: Format(1)
• Format - specifică modelul (masca) de afişare a datelor (numai
pentru casetele text);
• Decimal Places - indică numărul de zecimale cu care vor fi
afişate datele (numai pentru casete text);
• Caption - conţine textul afişat de control (numai pentru
controalele needitabile: etichete, butoane etc.);
• Visible - determină afişarea sau nu a controlului în timpul
execuţiei formularului;
• Left - stabileşte coordonata orizontală a colţului stânga-sus al
controlului;
• Top - indică poziţia pe verticală a colţului stânga-sus;
• Width - stabileşte lăţimea controlului;
• Height - stabileşte înălţimea controlului;
• Back Style - determină modul de afişare: control normal sau
transparent;
Proprietăţile controalelor: Format(2)
• Back Color - stabileşte culoarea de fundal a controlului;
• Special efect -specifică efectele tridimensionale ale ctrl-ului;
• Border Style - indică tipul liniei folosit la trasarea bordurii
controlului (transparent, continuu, punctat etc.);
• Border Color - determină culoarea bordurii;
• Border Width - grosimea bordurii;
• Font Color - culoarea textului afişat de control;
• Font Name - tipul fontului aferent textului din control;
• Font Size - dimensiunea fontului;
• Picture - specifică numele şi calea fişierului grafic ce va fi
afişat în interiorul controlului (numai pentru butoane şi controale de
tip imagine);
• Text Align – stabileşte modul de aliniere a textului în interiorul
controlului.
Proprietăţile controalelor: Data(1)
• Control Source - conţine sursa de date a controlului şi poate fi:
Numele unui câmp (pentru controale legate);
O expresie de calcul precedată de semnul "=" (pentru casete
text nelegate).
Proprietăţile controalelor: Data(2)
Input Mask- indică formatul folosit la introducerea datelor
(numai pentru casete text)
• Default value - specifică valoarea implicită (valoarea prin
lipsă) a controlului.
Validation Rule - conţine regula după care se face validarea
datelor introduse în control. La execuţia formularului, mai întâi se
verifică regula de validare a controlului şi apoi cea a câmpului ataşat;
• Validation Text - specifică mesajul ce va fi afişat, atunci când
regula de validare este încălcată;
• Enabled - activează sau dezactivează controlul. Un control
dezactivat va fi inaccesibil la execuţia formularului;
• Locked - serveşte la protejarea datelor afişate de control
(controlul va deveni read-only).
Proprietăţile controalelor: Event
Proprietăţi din categoria Event - conţin denumirile funcţiilor,
procedurilor eveniment sau macro-urilor, ce vor fi executate la
declanşarea evenimentelor ataşate
Enter Proprietatea
GotFocus Exit Descriere LostFocus
Eveniment
eveniment
BeforeUpdate BeforeUpdate Apare înaintea salvării datelor din control în câmpul
ataşat acestuia (validarea datelor introduse în control).
Change On Change Se declanşează în momentul în care datele din control
(casetă text sau casetă combinată) sunt modificate.
Enter On Enter Evenimentul este înregistrat în momentul accesării controlului în
vederea editării datelor (înaintea activării sale).
Exit On Exit Declanşat, atunci când se părăseşte controlul curent în
vederea accesării altui control din formular.
Apare în momentul focalizării controlului. Diferă de evenimentul On
Got Focus On Got Focus
Enter prin aceea că se declanşează chiar şi atunci când utilizatorul
comută între o altă fereastră şi formularul curent.
Evenimentul este înregistrat la defocalizarea controlului (fie prin
Lost Focus On Lost Focus
trecerea la alt control din cadrul formularului, fie prin activarea altei
ferestre).
Proprietăţile controalelor: Other
• Name - conţine numele controlului. La creare, fiecare control
primeşte un nume unic, format din tipul său plus un număr de ordine
(ex.: TextBox5). Utilizatorul poate modifica acest nume, schimbându-l cu
unul mai sugestiv.;
• Status Bar Text - specifică mesajul afişat în bara de stare, în
momentul selectării controlului;
• Tab Stop - dacă este setată pe valoarea Yes, atunci controlul poate fi
accesat cu ajutorul tastei TAB;
• Tab Index - specifică numărul de ordine al controlului, în funcţie de
care acesta va fi accesat cu ajutorul tastei TAB. Toate controalele
editabile vor primi un număr de ordine unic, la creare. Acest număr poate
fi modificat fie prin această proprietate, fie prin opţiunea View-TabOrder
Liste derulante în Design View: ComboBox
Proprietăţile controlului ComboBox:
• Column Widths - (valorile sunt separate de caracterul
“;”) specifică dimensiunea fiecărei coloane din listă
• List Width - conţine lăţimea totală a listei derulante.
• Row Source Type- specifică tipul sursei de date pentru
valorile din listă (tabelă/interogare, valori definite de utilizator,
realizările unui câmp).
• Row Source- conţine denumirea tabelei, a interogării
(sunt admise şi fraze SQL Select) sau valorile predefinte de
utilizator (separate de caracterul “;”).
• Bound Column – va conţine numărul de ordine al
coloanei care va actualiza câmpul ataşat controlului (coloana
respectivă poate fi ascunsă).
Liste derulante prin Wizard: ComboBox
Liste derulante prin Wizard: ComboBox
Liste derulante prin Wizard: ComboBox

SELECT [Carti].[Cod ISBN], [Carti].[Denumire Carte], [Carti].[Tip


Carte], [Carti].[Colectia], [Carti].[Numar Pagini], [Carti].[Data
Aparitiei], [Carti].[Stocul tiparit], [Carti].[Pret baza]
FROM Carti
ORDER BY [Denumire Carte];
Liste derulante prin Wizard: ComboBox
Formulare si Subformulare

Rolul subformularelor este de a actualiza mai multe tabele prin


intermediul unei singure ferestre (formular). Subformularele sunt create
în general pentru anumite tabele dependente (tabele în care câmpul
comun este cheie externă), din cadrul unei relaţii de tip 1-n.
Definirea unui subformular presupune înglobarea (includerea)
unui formular în cadrul altui formular, primul devenind
subformular, iar al doilea formular principal.
Avantaje:
Posibilitatea actualizării mai multor tabele printr-un singur formular.
Sincronizarea automată a subformularului cu formularul principal:
• actualizarea automată a câmpului cheie externă din subformular, cu
valoarea deţinută de câmpul cheie primară din formularul
principal;
• filtrarea automată a înregistrărilor din subformular, în funcţie de
valoarea cheii primare din formularul principal.
Formulare si Subformulare
Formulare si Subformulare: Definire sbf
1) Se deschide în modul Design, formularul ce se doreşte a fi
formular principal;
2) Se activează fereastra bazei de date;
3) Folosind tehnica drag&drop, se "depune" formularul, ce se
doreşte a fi declarat subformular, în interiorul formularului
principal;
4) Se salvează formularul principal

Sincronizarea formular-subformular se realizează prin


intermediul câmpurilor de legătură: cheia primară din
sursa de date a formularului principal şi cheia externă
din sursa de date aferentă subformularului. Denumirile
acestor câmpuri sunt înscrise automat de Access în
proprietăţile Link Master Field şi Link Child Field
ale controlului de tip subform din formularul principal.
Formulare si Subformulare: Definire sbf
Formulare si Subformulare: Definire sbf
Formulare si Subformulare: Definire sbf
Formulare si Subformulare

Σ(Valoare)
Formulare si Subformulare
Pregătire formular: CLIENTI

Default View : Single Form


Views Allowed : Form
Scroll Bars : Neither
Navigation Buttons : No
Record Selectors : No
Border Style : Transparent
Formulare si Subformulare
Pregătire formular: FACTURI + subformular CLIENTI (optimizat)
Pregătire formular: CONŢINUT FACTURĂ
Pregătire formular: CONŢINUT FACTURĂ
Pregătire formular: CONŢINUT FACTURĂ
Formulare si Subformulare

?
Pregătire formular principal: FACTURĂ
Formulare si Subformulare
Expresii în Formulare şi Subformulare
Expresiile în formulare se editează:
•în caseta de text a controlului;
•în rubrica proprietăţii CONTROL SOURCE
Expresiile pot fi:
•Simple: =[nume_ctrl1]operator[nume_ctrl2]
•Complexe: =Funcţie([nume_ctrl1]operator[nume_ctrl2])

Dacă este referit un control situat în alt formular, acesta se identifică prin expresia
Forms![Nume_formular]![nume_ctrl]

=[Nume_ctrl_local]operatorForms![Nume_formular]![nume_ctrl]

Utilizarea într-o expresie de pe un formular a unor controale din


subformular, se realizează prin:
[Nume_subformular].Form![Nume_control]
Pentru expresiile complexe, se utilizează funcţiile totalizatoare scrise în
casetele de text situate în secţiunile centralizatoare Form Header/Footer
Proprietăţile Obiectelor de tip Forms
Proprietăţile formularului curent sunt împărţite în 4
categorii:
• Format – conţine atribute privitoare la dimensiune,
aspect, coordonatele de afişare ale formularului etc.;
• Data – grupează proprietăţi referitoare la sursa de date şi
înregistrările aferente;
• Event – conţine evenimentele ce pot fi tratate fie prin
proceduri sau funcţii scrise în limbajul VBA, fie prin macro-
uri. Proprietăţile acestei categori se numesc proprietăţi
eveniment şi au denumiri asemănătoare cu cele ale
evenimentelor cărora le sunt ataşate.
• Other – conţine diverse alte proprietăţi.
Proprietăţile Forms: Format
• Caption – conţine titlul formularului ce va apărea în bara de titlu a acestuia;
• Default View – specifică modul implicit de afişare, folosit la execuţia
formularului (Single Form, Tabular Form, Datasheet);
• View Allowed – reprezintă modurile de afişare ce sunt disponibile în timpul
execuţiei (Form, DataSheet, Both);
• Scroll Bars - setează barele de defilare vizibile în cursul execuţiei (bara
orizontală, bara verticală, amândouă sau nici una);
• Record Selectors – afişează sau nu selectorul de înregistrare în timpul
execuţiei formularului;
• Navigation Buttons – specifică dacă formularul va conţine butoanele de
navigare în cursul execuţiei sale;
• Dividing Lines – precizează dacă se afişează linii pentru delimitarea
secţiunilor formularului sau a înregistrărilor la execuţie;
• Auto Center – dacă este setată pe valoarea Yes, formularul va fi afişat, la
execuţie, în centrul ecranului;
Proprietăţile Forms: Format

• Border Style – specifică tipul bordurii. Setarea acestei proprietăţi va avea efect
şi asupra comportamentului formularului:
• None – formular fără bordură (formularul nu va putea fi redimensionat la
execuţie);
• Thin – bordură subţire (formularul nu va putea fi redimensionat);
• Sizable– bordura implicită (formularul poate fi redimensionat);
• Dialog – bordura subţire (formularul nu poate fi redimensionat iar bara de titlu
va conţine doar butonul pentru închidere Close obţinându-se astfel un formular de
tip Dialog Box).
• Control Box – indică prezenţa meniului sistem în bara de titlu;
• Min Max Buttons – dezactivează sau activează fie ambele, fie unul din
butoanele de minimizare şi maximizare din bara de titlu;
• Close Button – indică prezenţa butonului de închidere (Close) în bara de titlu;
Proprietăţile Forms: Format
• Width – specifică lăţimea formularului şi implicit a tuturor secţiunilor.
Această proprietate poate fi modificată în timpul proiectării formularului, dar şi în
cursul execuţiei acestuia (dacă bordura este de tip Sizable), cu ajutorul mouse-lui.
• Picture – poate conţine specificatorul unui fişier grafic, al cărui conţinut
va fi afişat pe fundalul formularului;
• Picture Type – specifică varianta OLE folosită:
Embedded (înglobat) – imaginea este inclusă în formular;
Linked (legat) – se creează doar o legătură către fişierul grafic
(formularul nu va afişa imaginea respectivă dacă fişierul este şters,
mutat etc.).
• Grid X – conţine numărul de subdiviziuni orizontale pe unitatea de
măsură (cm, inch, etc.). Grila (Grid) serveşte la alinierea automată a controalelor.
• Grid Y - conţine numărul de subdiviziuni verticale pe unitatea de măsură
(intervalul 1-64).
Proprietăţile Forms: Data

• Record Source – conţine sursa de date a formularului (tabel sau interogare).


Această proprietate poate conţine chiar şi o comanda SQL (numai selecţie).
• Filter – conţine criteriul de selecţie care se va aplica înregistrărilor din
formular. Condiţia de filtrare este o clauză SQL WHERE, însă fără să conţină
cuvântul WHERE. Notă: Pentru ca filtrul să fie activ, proprietatea FilterOn trebuie
setată pe valoarea True
• Order By – permite specificarea câmpurilor după care vor fi sortate
înregistrările din formular. Sintaxa = cu sintaxa clauzei SQL – OrderBy. Notă:
Pentru ca operaţia de ordonare să se execute automat la deschiderea formularului,
proprietatea OrderByOn → True.
• Data Entry – dacă este setată pe valoarea Yes, formularul nu va afişa, la
deschidere, înregistrările existente (proprietatea este utilă pentru formularele ce vor
permite numai adăugarea de înregsitrări).
• Record Locks – specifică dacă şi ce înregistrări vor fi blocate pentru alţi
utilizatori (blocarea se poate face fie pentru toate înregistrările, fie numai pentru
înregistrarea curentă).
Proprietăţile Forms: Event

Proprietăţi din categoria Event: conţin denumiri de funcţii, proceduri


eveniment sau macro-uri ce vor fi executate la apariţia evenimentelor
respective. Apar astfel trei posibilităţi

1.eveniment tratat printr-o funcţie - proprietatea


eveniment va conţine o expresie de forma:
=NumeFuncţie([ListaParametri])
Exemplu: Funcţia ActualizeazaContor (definită într-
un modul) poate fi ataşată proprietăţii On Current,
în vederea afişării înregistrării curente (atunci când
formularul nu conţine butoanele de navigare):

=ActualizeazaContor(
[Forms]![Carti],
[CrtRecord])
Proprietăţile Forms: Event
2.Eveniment tratat printr-o procedură
eveniment - proprietatea eveniment va conţine
expresia EventProcedure, iar editarea procedurii
se poate face prin acţionarea butonului
BuildWizard, la invocarea căruia Access deschide
editorul de module, în care generează o procedură
vidă sub forma:
Private Sub Form_numeEveniment
([ListăParametriFormali])

End Sub
Între cele două linii, utilizatorul poate insera
propriile instrucţiuni.
[Event Procedure]
3. Eveniment tratat printr-un macro: proprietatea
eveniment va conţine numele macro-ului
Macro1
Proprietăţile Forms: Event
Eveniment Proprietatea Descriere
eveniment

Current On Current Este înregistrat în momentul trecerii de la o înregistrare


la alta.
BeforeUpdate BeforeUpdate Apare înaintea salvării înregistrării curente în tabelă
(validarea datelor curente).
On Delete Evenimentul apare înaintea ştergerii înregistrării
Delete
curente şi poate fi folosit pentru obţinerea unei
confirmări cu privire la această operaţie.
On Open Apare înaintea afişării pe ecran a formularului, la
Open
deschiderea acestuia..
On Unload Este un eveniment declanşat înaintea închiderii formularului (cere
Unload confirmarea utilizatorului cu privire la închiderea formularului, atunci
când datele nu au fost salvate).

On Close Evenimentul este înregistrat în timpul închiderii formularului


Close (formularul este afişat pe ecran) şi poate fi folosit pentru deschiderea
altor formulare, pentru ştergerea obiectelor temporare generate în
timpul execuţiei formularului, etc.
Proprietăţile Forms: Event
Eveniment Proprietatea Descriere
eveniment

Activate On Activate Este declanşat la activarea formularului (fie la deschiderea lui, fie
la selectarea lui dintr-o altă fereastră) şi poate fi folosit, de
exemplu, pentru refacerea valorilor unei liste derulante, în urma
actualizării tabelei sursă printr-un alt formular.

On Click Apare la efectuarea unui clic pe selectorul de înregistrare sau pe


Click zona liberă a formularului (zona aflată în afara secţiunilor).

On Error Evenimentul este declanşat la apariţia unei erori în cursul execuţiei


Error formularului (de exemplu, eroarea generată la introducerea unei
valori ce nu respectă condiţiile de validare sau restricţia de
integritate). Este utilizat la interceptarea erorilor generate de
Access în vederea tratării lor.

On Timer Este un eveniment care apare la o anumită perioadă de timp,


Timer stabilită de utilizator prin proprietatea Timer Interval (valoarea
atribuită este în milisecunde). Poate fi utilizat pentru crearea
diferitelor efecte vizuale, pentru citirea/setarea unor variabile
globale etc.
SGBD Access: Interogarea
bazelor de date
SGBD Access : Query
Interogarea (Query) este un obiect ce permite
vizualizarea informaţiilor obţinute prin
selectarea şi prelucrarea datelor din una sau
mai multe tabele (sau interogări)
Rezultatul unei interogări se prezintă sub forma unei foi
de răspuns dinamic ce poartă numele de DynaSet
O foaie de răspuns dinamic nu are o existenţă proprie
după închiderea interogării. Dacă aceasta este salvată,
definiţia respectivei cereri este salvată sub forma unui
şir SQL
O interogare Acces poate fi utilizată pentru:
-regăsirea şi ordonarea datelor potrivit anumitor criterii de selecţie;
-efectuarea de calcule;
-actualizarea bazei de date (interogări de acţiune);
-pregătirea datelor pentru afişarea lor prin formulare şi/sau rapoarte
Interogarea bazelor de date

SELECŢIE;
CALCULE;
ACŢIUNE
CREAREA UNEI INTEROGĂRI DE SELECŢIE:
Meniul Create + butonul Query Wizard
Din fereastra New Query sunt afişate mai multe tipuri generare a interogărilor:
• asistentul pentru cereri simple de interogare (Simple Query Wizard)
•asistentul pentru interogări încrucişate (Crosstab Wizard)
•asistentul pentru căutarea înregistrărilor duplicat (Find Duplicates Query Wizard)
•asistentul pentru căutarea înregistrărilor nu au corespondent în cele două tabele
sursă (Find Unmatched Query Wizard)
Simple Query Wizard
Interogarea bazelor de date
1. Se alege meniul Create + butonul Query Design
2. Se alege sursa de date în fereastra Show Table
3. Utilizatorul selectează tabela sau tabelele sursă participante la interogare,
apăsând pentru inserare butonul Add
4. Se închide fereastra Show Table prin Close

Fereastra Select Query conţine


Zona superioară în care se
vizualizează sursele de date
precum şi relaţiile dintre
acestea (tehnica Drag&Drop)
Zona inferioară
(grila Query
Design) ce conţine
atributele interogării
Interogarea bazelor de date “Să se afişeze lista
facturilor emise pe anul ……, către clienţii din Bucureşti şi
Ploieşti, cărora li s-au livrat cărţi de programare”

Selecţie: * + D&D în Field


DClk etichetă tabela + D&D

Field: precizează numele atributului selectat


Table: precizează tabela participantă la interogare (sursa de date)
Sort: precizează sensul sortării pentru atributul în cauză
Show: permite sau inhibă afişarea câmpului
Criteria: permite precizarea criteriilor pe care se construieşte interogarea
Or: operator logic de selecţie
Executarea interogării:
•butonul View
•butonul Run
Interogarea bazelor de date: Criteria

Operatori; Constante; Identificatori; Funcţii


•Operatori :
Aritmetici: +, -, *, /, Mod, ^;
De atribuire şi comparare: =, >, <, >=, <=;
Logici: and, or, not;
De concatenare a şirurilor de caractere: &;
Alţi operatori: is null, is not null, like”*escu”, in(“a”, “b”, “c”), between

•Constante: numerice (125, 45.36);


text (“Ionescu”);
dată calendaristică (#12/31/2002#)
Interogarea bazelor de date: Criteria
Identificatori: Forms![Selectie carti]![Denumire carte]
Interogarea bazelor de date: Criteria
Identificatori: Forms![Selectie carti]![Denumire carte]
Interogarea bazelor de date: Criteria

Funcţii:
Iif(Condiţie;Actiune_If_True;Actiune_If_False)
Date(), Now(),
Month(), Year(), Day()
DateAdd(“şablon_dată”;număr;câmp_dată/”constantă_dată”)
DateDiff(“şablon_dată”;dată_1;data_2;prima_zi)
yyyy An
WeekDay(câmp_data;prima_zi)
q Trimestru
DateSerial(an;lună;zi) m Luna
y Nr.zi dintr-un an
DateValue(dată)
d Zi
DatePart(“şablon_dată”;dată) w Zi din săptămână
Nr. săptămână
Format(dată;”şablon_dată”) ww
Interogarea bazelor de date: Criteria

Funcţii:

Sum(), Avg(), Max(), Min(), Count(), Abs(), Int(), Round(camp,


zec),

DMax(câmp; tabela[;criteriu]), DMin, DCount, DAvg;

Len(), Trim(), Val(), Str(), Ucase(text), Lcase(Text)

=INSTR([număr;]șir de caracter/nume de câmp; text_căutat)


Left(câmp,nrcar), Right(câmp,nrcar), Mid(câmp;start;dimensiune)

=STRING(număr_de_multiplicări ; caracter)
IsNumeric(), IsNull(), IsBlank(),
First(), Last()
Câmpuri calculate (pe linie) în interogări de selecţie:
“Se simulează o majorare a preţului de 25% pentru cărţile apărute după data de
01 ianuarie 2012

Câmpuri calculate “în linie”:


Atrib_calculat:[Atr.1]op[Atr.n]opConstantă

Noul Pret: Round([Pret fara TVA]*1,2;2)

Data Aparitiei >#01.01.2012#


Câmpuri calculate (pe linie) în interogări de selecţie Iif:
“Se calculează valoarea fiecărei “linii de factură”, si se simuleaza aplicarea
unei reduceri comerciale de 15% pentru valorile de peste 500 lei”

Valoare: [Cantitate]*[Pret fara TVA]


IIF(conditie;actiune_1_True;actiune_2_False)
Reducere: IIf([Valoare]<500;0;[Valoare]*0,15)
Câmpuri calculate (pe linie) în interogări de selecţie Iif, IsNull:
“Se înlocuieşte valoarea de Null a numarului de pagini cu zero”

Test Numar pagini: IIf(IsNull([Numar Pagini]);0;[Numar Pagini])


Câmpuri calculate (în linie) în interogări de selecţie: Month, Year
“Se afişează valoarea cărţilor facturate în luna noiembrie 2011”
Câmpuri calculate (în linie) în interogări de selecţie:
“Se afişează facturile emise în luna curenta”

Year([Data scadentei])=Year(Now())
And
Month([Data scadentei])=Month(Now())
Câmpuri calculate (în linie) în interogări de selecţie: DatePart; Year
“Se afişează facturile emise în al treilea trimestru al anului 2011”

DatePart("q";[Data Facturii])=3
Câmpuri calculate (în linie) în interogări de selecţie: WeekDay
“Se afişează facturile emise în weekend, in 2011”

Weekday([Data Facturii];2)=6 Or Weekday([Data Facturii];2)=7


Câmpuri calculate (în linie) în interogări de selecţie: DateDiff
“Se afişează facturile din 2011, pentru care termenul de graţie este mai mare
decât o săptămâna”

DateDiff("ww";[Data Facturii];[Data scadentei];2)>1


Câmpuri calculate (în linie) în interogări de selecţie: DateAdd
“Se afişează facturile pentru care termenul de graţie este de 1 săptămână”

=DateAdd("ww";1;[Data Facturii])
Câmpuri calculate (în linie) în interogări de selecţie: DateSerial
“Se afişează facturile scadente în ultima zi a fiecărei luni”

=DateSerial(Year([Data scadentei]);Month([Data scadentei])+1;1)-1


Interogarea bazelor de date
LEFT / RIGHT / MID / VAL / STR
Câmpuri calculate (pe coloană) în interogări de selecţie prin sinteză:
“Se calculează valoarea facturilor emise în 2012”
Câmpuri calculate (pe coloană) în interogări de selecţie prin sinteză:
“Se calculează valoarea facturilor emise în 2012”
Câmpuri calculate (pe coloană) în interogări de selecţie prin sinteză:
“Se calculează valoarea facturilor emise în 2012 pe luni”
Câmpuri calculate (pe coloană) în interogări de selecţie prin sinteză:
“Se calculează valoarea totală a facturilor emise pe ani”
Câmpuri calculate (pe coloană) în interogări de selecţie prin sinteză:
“Se calculează pentru fiecare zi numărul de linii de factură, precum şi cantitatea totală
facturată”
Subinterogari
“Se afişeze facturile cărţilor livrate
într-o cantitate peste medie”
Subinterogari
“Autorii care au scris cele mai multe carti”

SELECT MAX(*) AS MAXIM


FROM

(SELECT CNP, COUNT(*) AS NR


FROM [AUTORI-CARTI]
GROUP BY CNP)
Interogările parametrabile conferă interactivitate cererilor, specificând
dinamic restricţiile la care trebuie să răspundă acestea
Interogările de analiză încrucişată (CrossTab) permit sintetizarea datelor,
oferind utilizatorului o viziune analitică multidimensională
1.Se elaborează o interogare de selecţie în modul Design, alegându-se tabelele
care participă la interogare;
2.Se activează comanda
Interogările de analiză încrucişată (CrossTab) permit sintetizarea datelor,
oferind utilizatorului o viziune analitică multidimensională
Interogari de tip ACTIUNE
INTEROGĂRI pentru crearea de noi tabele (Make Table)
Aceste interogări permit crearea unei tabele plecând de la datele stocate în altă
tabelă. Noua tabelă reprezintă selecţia aplicată asupra tabelei sursă
“Să se stocheze într-o nouă tabelă cărţile scrise de Ionescu Bogdan în ultimii 5 ani”
INTEROGĂRI pentru ADĂUGAREA TUPLURILOR (Append)
Aceste interogări permit adăugarea de noi tupluri într-o tabelă plecând de la
datele stocate în altă tabelă.

“Să se adauge în tabela CARTI MANUALE DE INFORMATICA toate tuplurile


provenite din tabela CARTI pentru o conditie data”
INTEROGĂRI pentru MODIFICAREA TUPLURILOR (Update)
Aceste interogări permit modificarea tuplurilor existente într-o tabelă.

“Se modifică cu 10% preţul de bază pentru manualul “Baze de date”, în anul 2009”
INTEROGĂRI pentru MODIFICAREA TUPLURILOR (Update)
Aceste interogări permit modificarea tuplurilor existente într-o tabelă.

“Se modifică cu 10% preţul de bază pentru manualul “Baze de date”, în anul 2009”
INTEROGĂRI pentru ŞTERGEREA TUPLURILOR (Delete)
Aceste interogări permit ştergerea tuplurilor existente într-o tabelă, potrivit
unui criteriu de selecţie.

“Să se şteargă clienţii din Arad”


SGBD Access
 Utilizează modelul relaţional în gestiunea bazelor de date
 Aplicaţia ACCESS conţine un ansamblu de colecţii de
obiecte tip
 Tabel (Table)
 Interogare (Query)
 Formular (Form)
 Raport (Report)
 Macro (Macro)
 Modul (Module)
 Dispune de o interfaţă prietenoasă pentru construirea
obiectelor tip şi de numeroşi asisteţi (Wizard-uri)
 Permite schimbul de date cu alte aplicaţii
 Permite lucru în reţele de calculatoare
 Permite programarea :
– Declarativă (QBE, SQL, acţiuni în obiecte macro)
– Procedurală (VBA)
prof.univ.dr. Ionescu Bogdan
SGBD Access : Obiecte
Tabela (Table) este un obiect definit de utilizator
în care sunt stocate datele primare (expresia
modelului relaţional)

Interogarea (Query) este un obiect ce permite


vizualizarea informaţiilor obţinute prin selectarea şi
prelucrarea datelor din una sau mai multe tabele (sau
interogări)

Formularul (Form) este un obiect ce permite


introducerea datelor, afişarea acestora sau controlul
întregii aplicaţii

Obiectele de tip raport (Report) se creează în


etapa de exploatare a bazelor de date. Conţinutul lor
Modulul (Module) este poate fi vizualizat pe ecran, sau se poate lista la
un obiect ce conţine imprimantă
proceduri definite de
utilizator şi scrise în Comanda Macro (Macro) este un obiect ce conţine o
limbajul de programare definiţie structurată a uneia sau a mai multor acţiuni, pe
VBA care
prof.univ.dr. Access
Ionescu le realizează ca răspuns la un anumit
Bogdan
eveniment
SGBD Access
Crearea tabelelor bazei de
date

prof.univ.dr. Ionescu Bogdan


SGBD Access
Crearea tabelelor BD

Numele atributului (Field Name) este


unic în cadrul tabelei şi poate fi compus din
substantive simple sau compuse în lungime
maximă de până la 64 caractere
Tipul de date sau natura atributului (Data Type):
•ShortTEXT admite caractere alfanumerice de lungime maximă a realizării
atributului de 255 caractere (implicit 50 car)
•LongText admite caractere alfanumerice şi este recomandat stocării blocurilor
mari de text (max 65.535 caractere)
•NUMBER - număr (se va defini tipul de număr în Field Size: 1,2,4,8 B)
•DATE/TIME (8B) memorează date de natură dată calendaristică şi timp
•CURRENCY precizează formatul monetar (max. 15,4 car =>8 B)
•AUTONUMBER (4B) generează automat o valoare numerică prin incrementare
cu 1 (New Values = Increment) sau generare automată (New Values=Random).
•Atributul ce conţine acest tip deIonescu
prof.univ.dr. date nu se actualizează.
Bogdan
SGBD Access
Crearea tabelelor BD

Tipul de date sau natura atributului (Data Type)


• YES / NO (1b) generează valori logice de “Adevărat” (True) sau “Fals” (False)
• OLE OBJECT (max 1GB) stochează imagini, desene, secv audio, video,
documente Word, foi de calcul Excel. Nu poate fi nici cheie, nici index.
• ATTACHEMENT (max 700 KB – 2GB, depinzand de gradul de compresie)
Stocheaza imagini digitale, fisiere Office si alte tipuri de fisiere binare
• HYPERLINK stochează şiruri de caractere ce reprezintă o adresă WEB
•CALCULATED permite crearea de atribute calculate.
• LOOKUP WIZARD realizează restricţiile de integritate referenţială. Atributele
cu proprietatea Lookup Wizard vor fi completate automat prin selecţie dintr-o listă
simplă de valori (List Box) sau dintr-o listă derulantă de valori (Combo Box)

prof.univ.dr. Ionescu Bogdan


SGBD Access
Crearea tabelelor BD
Proprietăţile
atributelor

Dimensiunea atributului (Field Size) permite modificarea dimensiunii implicite


corespunzătoare tipului de atribut definit

În cazul tipurilor numerice de date există următoarele subtipuri:

•BYTE (0 zec, 1 octet, interval de valori 0,255)


•INTEGER (0 zec, 2 octeţi, interval de valori -32768,32768)
•LONG INTEGER (0 zec, 4 octeţi, interval de valori -2.147.483.648,
2.147.483.648)
•SINGLE (7 zec, 4 octeţi, interval de valori -3,4*10 la puterea 38 , …..)
•DOUBLE (15 zec, 8 octeţi, interval de valori -1,797*10 la puterea 308)
•DECIMAL
SGBD Access
Crearea tabelelor BD
Proprietăţile
atributelor
Formatul de afişare (Format)
•Pentru atributele NUMERICE există formatele:
standard: (Decimal Places)
GENERAL NUMBER stabileşte numărul de
CURRENCY zecimale utilizat pt
FIXED afişarea unui număr.
STANDARD
PERCENT Valori posibile:
SCIENTIFIC
personalizate: Auto şi nr [0,15]
afiş_num_poz;afiş_num_neg;zero;Null
# ##0;-# ##0;”Zero”;”Necunoscut”
•Pentru atributele DATĂ şi ORĂ există:
standard:
personalizate: dddd w ww dd mmmm yyyy q
•Pentru atributele LOGICE există
prof.univ.dr. Ionescu Bogdan
SGBD Access
Crearea tabelelor BD
Proprietăţile
atributelor
Masca (şablonul) de introducere (Input Mask)
0 cifră obligatorie
9 cifră opțională
L literă obligatorie
? literă opțională Exemple:
>L<???
> majuscule 000-00-000 (nr registru comert)
>L0L 0L0 = T2F 8M4
< minuscule L????L?00L0 = GREENGR339M3
# o cifră cu semnul +sau - (040)-”00\-00000## =

A literă sau cifră obligatoriu


a literă sau cifră facultativ
: ; - / separatori pentru date calendaristice sau timp
. , separatori zecimali sau pentru mii
Password afişează * prof.univ.dr.
în momentul introducerii datelor
Ionescu Bogdan
SGBD Access
Crearea tabelelor BD
Proprietăţile atributelor
Eticheta atributelor (Caption)
permite definirea unei etichete
asociate atributului
Valoare implicită (Default Value)
permite definirea unei valori implicite pentru realizarea atributului
Regulă de validare (Validation Rule)
permite definirea unui set de restricţii pentru validarea domeniului pe
care operează atributul
Exemple : Like(“*SRL”) or Like(“*SA)
pret>10000 and preţ <100000 Like(“*/*/2016”)
“Buc” or “Kg” or “Tone” >=Date()
IN(Buc, Kg, Tone) Year([Data Facturii])=Year(Date())
is not Null sau <>Nullprof.univ.dr. Ionescu Bogdan
Mid([nume_atr];1;1)=“A”)
BETWEEN 10000 AND 100000
SGBD Access
Crearea tabelelor BD
Proprietăţile atributelor
Validation Text
permite specificarea mesajului care
se va afişa în momentul în care o
intrare nu respectă regula de validare
Required
permite prin Yes/No specificarea
faptului dacă atributul trebuie să
posede realizări în mod obligatoriu
Indexed
permite definirea unui fişier index pentru atributul
respectiv. Potrivit relaţiilor 1-1 şi 1-n, se vor alege
opţiunile No duplicates sauIonescu
prof.univ.dr. YesBogdan
duplicates
SGBD Access
Crearea tabelelor BD Validări
ÎNCRUCIŞATE
Proprietăţile Tabelelor

[Data scadentei]<=[Data Facturii]+30


prof.univ.dr. Ionescu Bogdan
Definirea relaţiilor între tabele
Pentru a accesa simultan datele din mai multe tabele într-
o bază de date este necesar a se defini legăturile dintre
tabele.

Cel mai indicat ar fi ca această operație să se efectueze


înainte de a se introduce datele în tabele şi înainte de
efectuarea interogărilor

Relaţiile standard pot fi:


1:1 sau 1:n sau m:n

prof.univ.dr. Ionescu Bogdan


Definirea relaţiilor între tabele:1-1 /1-n
Relaţiile 1:1 corespund situaţiilor în care unui tuplu dintr-o
tabelă în corespunde un singur tuplu dintr-o altă tabelă.
Altfel spus, unei realizări a câmpului cheie primară dintr-o tabelă
îi corespunde o singură realizare a unui atribut cu rol de cheie
externă din altă tabelă.

Relaţiile 1:n se stabilesc în cazul în care unui tuplu dintr-o tabelă


îi corespund mai multe tupluri din altă tabelă.
Deci, aceeași valoare a atributului cheie primară dintr-o tabelă se
regăsește ca realizare a atributului cu rol de cheie externă în mai
multe tupluri din altă tabelă.

Relaţiile m:n sunt asocieri libere, iar atributele lor cu rol de


cheie primară prezintă valori duplicate.

prof.univ.dr. Ionescu Bogdan


Definirea relaţiilor între tabele:1-1 /1-n
Stabilirea relaţiilor 1:1 şi 1:n au la bază respectarea restricțiilor de
INTEGRITATE REFERENŢIALĂ

Astfel, într-o tabelă, valorile pentru atributul cheie externă


trebuie să se regăsească în tabela în care atributul este
cheie primară

În prezenţa integrităţii referenţiale, mai întâi trebuie adăugate


tuplurile în tabela sursă înainte de a putea adăuga o valoare pentru
atributul celeilalte tabele pusă în relaţie cu tabela sursă

În plus, nu se poate şterge un tuplu din tabela sursă, dacă cealală


tabelă (cea legată) conţine tupluri cu care atributul legat referă
valoarea de şters
prof.univ.dr. Ionescu Bogdan
SGBD Access
Proprietăţile atributelor
Lookup Wizard = realizează integritatea
referenţială
Permite introducerea datelor în atributul
declarat cheie externă, prin preluarea dintr-o
listă derulantă a valorilor atributului cheie
primară dintr-un alt tabel legat
SGBD Access 2013
Proprietăţile atributelor
Lookup Wizard
Definirea relaţiilor între tabele:1-1 /1-n

prof.univ.dr. Ionescu Bogdan


Definirea relaţiilor între tabele:1-1 /1-n

Enforce Referential
Integrity se activează atunci când:
-atributul din tabela sursa este KP
-atributul din tabela destinatie este KExt
-cele două atribute sunt de acelaşi tip
-cele două tabele sunt în aceeaşi BD

Cascade Update/Delete Related


Fields interoghează utilizatorul
asupra posibilităţii efectuării de
actualizări / ştergeri în cascadă
(anularea unui tuplu din tabela
“tată” conduce automat la anularea
tuplurilor corespunzătoare
din tabela “fiu”) prof.univ.dr. Ionescu Bogdan
Definirea relaţiilor între tabele:1-1 /1-n

prof.univ.dr. Ionescu Bogdan


Algebra relaţională: Operatori de Extensie: Join
•Produsul cartezian era o fuziune necondiţionată a două tabele.
•COMPUNEREA reprezintă fuziunea a două relaţii care au o proprietate
comună.
Fie 2 relaţii R1(A1, A2, ...., An) şi R2(B1,B2,......Bm), care au 2 atribute
(comune) Ai şi Bj, definite pe acelaşi domeniu de valori, şi θ ansamblul
operatorilor de comparaţie {=, >, <, >=, <=, <>}ce pot fi aplicaţi celor
două atribute Ai şi Bj.
Theta-Compunerea relaţiei R1, prin Ai, cu relaţia R2, prin Bj
(R1 ►◄ θR2) este relaţia R3 ale cărei tupluri sunt obţinute prin
concatenarea fiecărui tuplu al relaţiei R1, cu tuplurile relaţiei R2,
pentru care este verificată condiţia θ instituită între Ai şi Bj.
Un caz particular al theta-compunerii este echi-compunerea,
atunci când operatorul de comparaţie θ este “=“
Echi-comp. pentru care există o denumire identică a atributelor de
legătură dintre cele 2 tabele  compunere naturală
prof.univ.dr. Ionescu Bogdan
Join
•COM PUNEREA este echivalentă unui produs cartezian urmat de
o selecţie (şi eventual de o proiecţie).

Relaţia R1
Relaţia R3R1R2
A B C A R1.B C R2.B D

a1 b1 c1 a1 b1 c1 b1 d1
a1 b1 c1 b2 d2
Relaţia R2 a1 b1 c1 b3 d3

B D
b1 d1 R4=Selecţie(R3, R1.B=R2.B)
b2 d2 A B C D
b3 d3 prof.univ.dr. Ionescu Bogdan
a1 b1 c1 d1
Join
Cele 3 tipuri de joncţiuni prezentate (theta, echi, naturală) sunt de
natură internă şi prezintă 2 extensii:
• Compunerea externă;
• Semicompunerea

Compunerea externă include în tabela rezultat şi tupluri din una


dintre relaţii, care prezintă valori ale atributului de legătură ce nu se
regăsesc în cealaltă relaţie
În cazul compunerii externe trebuie să se precizeze din care relaţie se vor
prelua tuplurile fără corespondent în cealaltă relaţie. Din acest punct de
vedere există:
 compunere externă la stânga (left outer join)
 compunere externă la dreapta (right outer join)
 compunere externă totalăBogdan
prof.univ.dr. Ionescu (reuniunea celor 2 relaţii)
Join
R1 R2 R3(R1,R1.C=R2.C,R2)
A B C C D E A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1 a1 b1 c1 c1 d1 e1
a3 b3 c3 c3 d2 e2
a2 b2 c2 c3 d2 e2
a3 b3 c3 c5 d3 e3 A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1
Left Outer JOIN
a2 b2 c2 Null Null Null
a3 b3 c3 c3 d2 e2

Right Outer JOIN A B R1.C R2.C D E


a1 b1 c1 c1 d1 e1
Null Null Null c5 d3 e3
Compunere totală a3 b3 c3 c3 d2 e2
prof.univ.dr. Ionescu Bogdan
Join

Semicompunerea a 2 tabele presupune selectarea tuplurilor din


prima tabelă care apar în joncţiune cu tuplurile din a doua tabelă

R1 R2 SemiCompunere
A B C C D E
A B C
a1 b1 c1 c1 d1 e1
a2 b2 c2 c3 d2 e2 a1 b1 c1
a3 b3 c3 c5 d3 e3 a3 b3 c3

R3(R1,R1.C=R2.C,R2)
A B R1.C R2.C D E
a1 b1 c1 c1 c1 d1
a3 b3 c3 c3prof.univ.dr.
d2 Ionescu
e2 Bogdan
Definirea relaţiilor între tabele:1-1 /1-n

ECHICOMPUN
EREA include
numai
tuplurile
în care valorile
atributelor cheie
sunt egale în
prof.univ.dr. Ionescu Bogdan ambele tabele
Definirea relaţiilor între tabele:1-1 /1-n
COMPUNEREA EXTERNĂ
se pun în legătură toate
înregistrările din tabela sursă
şi înregistrările din tabela
destinaţie care, care au valori
egale în câmpul de legătură

LEFT OUTER JOIN (1n) include toate înregistrările din


tabela “Cărţi” şi numai acele înregistrări din tabela
“Conţinut Factură” pentru care valorile atributelor cheie
(Cod ISBN) sunt egale.

RIGHT OUTER JOIN (1n) include toate înregistrările din


tabela “Conţinut Factură” şi numai acele înregistrări din
tabela “Cărţi” pentru care valorile atributelor cheie (Cod
ISBN) sunt egale.prof.univ.dr. Ionescu Bogdan
Teoria generală
a bazelor de date
 Baza de date este:
 Un ansamblu de date structurate
 Legate funcţional
 Stocate pe suporturi tehnice adresabile
 Accesate de mai mulţi utilizatori de o manieră
selectivă şi într-un timp oportun

1 - Prof.dr. Bogdan IONESCU


Modele de date: modelul RELAŢIONAL
 Un model de organizare bidimensională a datelor
în tabele
 Implementează schema relaţională (MRD)
 Tabele
 Relaţii între tabele
 Reguli de validare
 Algebra relaţională (Operatori relaţionali)
 Operatori de asamblare (Reuniunea, Intersecţia, Produsul
cartezian, Diferenţa)
 Operatori unari (Proiecţia, Selecţia)
 Operatori de extensie (Compunerea, Diviziunea)
 Un limbaj standard de gestiune a BDR
1 - Prof.dr. Bogdan IONESCU
Modele de date: modelul RELAŢIONAL

 Modelul relaţional introdus de Edgar


Codd în 1970 se fundamentează pe
noţiunea matematică de relaţie R(X1,X2,....Xn)
 unde, pentru fiecare element Xi se defineşte un
domeniu de valori
 Domeniul reprezintă mulţimea valorilor
posibile care definesc o anumită proprietate
aferentă unui obiect.
 Atributul reprezintă mulţimea valorilor
existente în coloana pe care o desemnează în
cadrul relaţiei.
1 - Prof.dr. Bogdan IONESCU
Modele de date: modelul RELAŢIONAL
 Relaţiile se reprezintă prin tabele care
sunt supuse următoarelor restricţii:
 În fiecare coloană, toate valorile sunt de
acelaşi tip;
 Ordinea liniilor (tuplurilor sau înregistrărilor)
nu este predefinită;
 Nu sunt admise înregistrări duplicate;

 Coloanele sunt identificate prin nume


distincte (atribute sau proprietăţi)
Tuplurile unei relaţii se pot identifica de o manieră unică
prin intermediul valorilor unuia sau mai multor atribute
care joacă rol de CHEIE1 - PRIMARĂ a relaţiei respective.
Prof.dr. Bogdan IONESCU
Modele de date: modelul RELAŢIONAL
 Se numeşte DOMENIU PRIMAR acel domeniu pe care este definit
un singur atribut drept cheie primară
 CHEIA EXTERNĂ: Fiind două relaţii R1 şi R2, cu atributele A1 şi
A2 chei primare definite pe un domeniu primar D, se spune că în
relaţia R1, A2 este cheie externă dacă, utilizând o parte din valorile
ei sau toate, pot fi regăsite tuplurile relaţiei R2
 (altfel spus, un atribut al unei relaţii este cheie externă, dacă se
regăseşte pe post de cheie primară în altă relaţie)

Relaţii

R1(A1,B1,C1,D1,A2) R2(A2,B2,C2,D2)
Cheie externă

Chei primare
1 - Prof.dr. Bogdan IONESCU
Modele de date: modelul RELAŢIONAL
Relaţii

R1(A1,B1,C1,D1,A2) R2(A2,B2,C2,D2)

Factura Clienţi
Nr_factură
Chei primare Cod_client
Data_factură Nume_client
Data_scadenţă Adresă
Cod_client Localitate

Cheie externă

Factura(Nr.Factura,Data_f,Data_s,Cod client)

Clienti(Cod client,Nume_cl,Adresa,Localitate)
1 - Prof.dr. Bogdan IONESCU
Modele de date: modelul RELAŢIONAL
 RESTRICŢIILE DE INTEGRITATE depind de
semantica valorilor domeniilor.
 Integritatea entităţii prin care valorile cheii primare
trebuie să fie diferite de zero;
 Integritatea referirii potrivit căreia valorile unei chei
externe trebuie să se refere la tuplurile unei alte relaţii
 ALTE RESTRICŢII care se aplică asupra domeniilor
(validări prin care se reflectă alte corelaţii de ordin
valoric)
 SCHEMA unei relaţii este formată din:
 Numele relaţiei
 Atributele relaţiei
 Restricţiile de integritate
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date
 Normalizarea se bazează pe următoarele concepte:
 Proces de normalizare

 Dependenţa funcţională

 Diagrama dependenţelor funcţionale

 Dependenţe Inter-Tabele şi Multivaloare

 Forme normale

 Matricea dependenţelor funcţionale

 Etapele proiectării MR prin normalizare

 Exemplul II (facturi către clienţi)


 Exemplul III (editură)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Procesul de normalizare
Normalizarea este un demers ce conduce la
construirea modelului relaţional al bazei de date
Se descompune o tabelă complexă în subtabele mai
mici şi mai uşor de manipulat

DD
+RG NORMALIZARE MRD

SCOP: Normalizarea garantează coerenţa bazei de date în timpul


operaţiilor de actualizare (CMS) de date (riscul de aparitie a
anomaliilor de actualizare si de stocare a datelor), evitând
redundanţele,
REZULTAT: Un model nedecompozabil ce respectă regulile de
definire semantică şi de integritate a datelor
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Procesul de normalizare
O bază de date normalizată trebuie să conţină tabele (relaţii) în
care să nu existe anomalii şi pierderi de informaţii.
De asemenea, o bază de date normalizată trebuie să respecte
atât restricţiile modelului relaţional cât cerinţele definite
de către utilizator.

Proiectarea unei baze de date relaţionale se poate realiza prin


următoarele metode:
1. Obţinerea modelului relaţional pe baza unui model
conceptual semantic (Merise, Entitate-Asociere)
2. Obţinerea modelului relaţional utilizând modelarea
obiectuala (OMT, UML ş.a.)
3. Obţinerea modelului relaţional prin normalizare
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Procesul de normalizare : ANOMALII
FurnizoriFacturi(SerieFactura, NumarFactura, DataFactura,
CodFurnizor, DenumireFurnizor, AdresaFurnizor)
Serie Numar Data Cod Denumire Adresă
factură factura factură furnizor furnizor furnizor
A01 1 01/01/2009 111 S.C. Alfa S.A. Bucureşti
A01 2 12/05/2009 112 S.C. Beta S.A. Braşov
A01 3 15/05/2009 112 S.C. Beta S.A. Braşov

1) Redundanţă pentru facturile emise de acelaşi


furnizor;
2) Anom alii la adăugare : se referă la faptul că
anumite date ce urmează a fi adăugate, fac parte din
tupluri incomplete (nu pot fi adăugaţi furnizori care
nu au emis facturi);
1 - Prof.dr. Bogdan IONESCU
Procesul de normalizare : ANOMALII
Serie Numar Data factură Cod Denumire Adresă furnizor
factură factura furnizor furnizor
A01 1 01/01/2008 111 S.C. Alfa S.A. Bucureşti
A01 2 12/05/2008 112 S.C. Beta S.A. Braşov
A01 3 15/05/2008 112 S.C. Beta S.A. Braşov

3) Anom alii la m odificare : se referă la faptul că e dificil să se


modifice o realizare, dacă ea se repetă în mai multe
tupluri (dacă un furnizor îşi schimbă numele, atunci, acesta
trebuie modificat în toate înregistrările aferente facturilor
emise de acel furnizor);
4) Anom alii la ştergere : constau în faptul că anumite
informaţii ce se doresc a fi şterse, fac parte dintr-un
tuplu ce conţine şi alte date care sunt utile în
continuare (de exemplu, ştergerea unei facturi din tabela
Furnizori-Facturi, conduce la eliminarea din baza de date a
furnizorului emitent). 1 - Prof.dr. Bogdan IONESCU
Dependenţa funcţională : unică
Dependenţele sunt legături logice, ce se stabilesc între
atributele modelului relaţional.
 Există o dependenţă funcţională între 2 atribute atunci când
cunoscând valoarea luată de către un atribut, se furnizează sistematic
valoarea pentru celălalt atribut : dependenţă simplă sau unică
 A -> B (B depinde funcţional de A, dacă la orice valoare a lui A
corespunde în orice moment o valoare unică a lui B)
 Exemple de dependenţe funcţionale: Tranzitivitate:
 Cod Produs -> Denumire produs Dacă A -> B şi B -> C, atunci
 Cod Produs -> Preţ de referinţă
A ->C
 Număr Comandă -> Dată Comandă
 Număr Comandă -> Cod Client -> Nume Client
 -> Cod Fiscal

Dacă un atribut sau un grup de atribute dintr-un tabel determină


funcţional celelalte atribute ale tabelului, rezultă că atributul sau
grupul de atribute constituie cheia
1 - Prof.dr. primară
Bogdan IONESCU a tabelului
Dependenţa funcţională : multiplă
 Dependenţa multiplă: există o dependenţă multiplă de la A
la B (A »B) atunci când o valoare a lui A determină mai
multe valori ale lui B;
 Exemple de dependenţe funcţionale multiple:
 SerieFactură » CodProdus
 DataFactură » NumarFactură

Dacă între două atribute A şi B există o dependenţă multivaloare


(A→→ B), atunci între A şi B există şi o dependenţă multiplă (A
»B).
 Dependenţa dublă (triplă): se identifică o dependenţă dublă
(triplă) acele dependenţe dintre un lanţ de atribute;
 Exemple de dependenţe funcţionale triple:
 Numarfactura » CodProdus → DenumireProdus

1 - Prof.dr. Bogdan IONESCU


Dependenţa funcţională completă

 Se numeşte dependenţă funcţională com pletă


(elem entară, totală, deplină), o dependenţă
funcţională de forma A→ B în care B este
dependent funcţional de A, fără să fie dependent
funcţional de nici una din componentele lui A.

 (NrFactură, CodProdus) → Cantitate


 NrFactură ≠ Cantitate
 CodProdus ≠ Cantitate
 Între grupul de atribute (NrFactură, CodProdus) şi
Cantitate există o dependenţă funcţională completă,
deoarece câmpul Cantitate depinde funcţional doar de
(NrFactură, CodProdus) fără să depindă funcţional de
NrFactură sau de CodProdus.
1 - Prof.dr. Bogdan IONESCU
Dependenţa funcţională partială
 O dependenţă funcţională A → B se numeşte
dependenţă funcţională parţială dacă şi numai
dacă B este dependent funcţional atît de A cât şi
de o parte a lui A.

 (NrFactură, CodProdus) → CodFurnizor


 NrFactură → CodFurnizor
 CodProdus ≠ CodFurnizor

 Între CodProdus şi CodFurnizor nu este o dependenţă


funcţională, deoarece un produs poate fi livrat de mai mulţi
furnizori.

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
Diagrama dependenţelor funcţionale
 Reprezentarea grafică a dependenţelor funcţionale

Cod Produs Denumire, UM, Preţ de referinţă

NrComandă Dată comandă, Cantitate

Cod Produs comandată

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
Dependenţe Inter-Tabele şi Multivaloare
 Dependenţe Inter-Tabele (1-1)
 Când la o valoare a atributului Cheie primară dintr-o tabelă, se
asociază o singură valoare a atributului Cheie primară dintr-o altă
tabelă, se poate spune că există o dependenţă funcţională între
tabele, exprimată prin dependenţa funcţională dintre atributele
chei primare aferente celor două tabele

CodProfesor CNP Profesor

 Dependenţe Multivaloare (1-n) (n-m)


 În cazul în care la o valoare a atributului Cheie primară dintr-o
tabelă, corespund mai multe valori ale altui atribut dintr-o altă
tabelă, se poate spune că există o dependenţă funcţională
multivaloare
Nr.factură Cod Produs

CodProfersor Cod Carte


1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Dependenţe Multivaloare
În relaţia
Lucrează(CodSectie, NumarInventarMijlocFix,
MarcaAngajat)
există dependenţe multivaloare, deoarece:
 într-o secţie lucrează mai mulţi muncitori, la mai multe
utilaje (mijloace fixe).
 Dacă fiecare muncitor lucrează la toate utilajele, atunci
există următoarele dependenţe multivaloare:
 CodSectie→ NumarInventarMijlocFix
 CodSectie→ MarcaAngajat
 Deci, dacă există tuplurile (Sectia1, MijFix1, 001) şi
(Sectia1, MijFix2, 002), atunci vor exista şi tuplurile
(Sectia1, MijFix1, 002) şi (Sectia1, MijFix2, 001).
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date :
DD+RG
Formele normale 1, 2, 3
 Dicţionar de date şi Reguli de 1FN
gestiune 2FN
Potrivit regulilor de gestiune coroborate

3FN
cu analiza informaţională referitoare la
aplicaţia de informatizat se declară într-un
tablou toate atributele disponibile
(Identificatorul + Denumirea în clar)
 1 FN
 O relaţie R este în 1FN atunci când atributele sale nu pot fi
descompuse în unităţi mai mici
 2 FN
 O relaţie R este în 2FN, dacă este în 1FN şi toate dependenţele
între cheia primară a lui R şi celelalte atribute a lui R sunt
elementare (atributele nu depind de o parte din cheie)
 3 FN
 O relaţie R este în 3FN, dacă este în 2FN şi dacă sunt eliminate
toate dependenţele funcţionale tranzitive (dacă nu există nici o
dependenţă funcţională 1 - între atributele
Prof.dr. Bogdan IONESCUnon-cheie)
Normalizarea Bazelor de Date : DD+RG
1 FN 1FN
 O relaţie R este în 1FN dacă toate
atributele sale conţin num ai valori
(realizări) atom ice (elem entare sau
indivizibile);
 În general, o valoare este considerată elementară,
atunci când descompunerea ei nu mai prezintă
interes pentru utilizatorii finali.
 Fiecare relaţie trebuie să conţină un identificator
care să o caracterizeze de o manieră unică
 O relaţie R este în 1FN dacă conţine valori
nerepetitive. În acest sens, o listă de valori
repetitive trebuie înlocuită cu un singur
atribut.
 Atributele descompuse trebuie să fie
stabile în timp (de exemplu, este preferabil
a se utiliza „data naşterii”, decât „vîrsta”).
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG

1FN

Persoana(CNP, Nume, Domiciliu) nu respectă FN1, dacă se


doreşte dezvoltarea unui sistem informatic în care să se
urmărească evidenţa persoanelor în funcţie de
localitate, stradă etc.

CNP Nume Domiciliu

1621018400230 Ionescu Ion Bucuresti, str. Stefan cel Mare,nr.2


2650305503507 Popescu Mirela Ploiesti, str. Viitorului, nr.4
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG

P entru aducerea relaţiei în 1FN 1FN


atributele com puse sunt
înlocuite cu atribute
elem entare

Persoana(CNP, Nume, Domiciliu)

Persoana(CNP, Nume, Localitate, AdresaDomiciliu)

Persoana(CNP, Nume, Localitate, Strada, …..)

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date : DD+RG

 1 FN 1FN
 De asem enea, FN1 ex clude
apariţia atributelor sau grupurilor
de atribute repetitive în cadrul
unei relaţii.

De exemplu, relaţia :
Comenzi(NumărComandă, Data, Material1, Material2)
nu respectă FN1, deoarece conţine atribute repetitive.
Numar Data Material1 Material2
Comandă
11 01/01/2008 Ciment Var
12 02/01/2008 Ciment Balastru
13 02/01/2008 Var Nisip
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG
P entru aducerea relaţiei în FN 1, 1FN
se parcurg urm ătoarele etape:
 Pentru grupul de atribute
repetitive, se form ează o altă
relaţie
 Cheia prim ară din noua relaţie, va
fi în vechea relaţie, cheie ex ternă.

Materiale (CodMaterial, DenumireMaterial)

Comenzi(NumărComanda, Data, Material1, Material2)

Comandă(NumărComanda, Data, CodMaterial)


1 - Prof.dr. Bogdan IONESCU
2 FN Normalizarea Bazelor de Date : DD+RG
 O relaţie R este în 2FN, dacă este în 1FN şi
dacă orice atribut noncheie se află în
1FN
dependenţă funcţională com pletă faţă de cheia
prim ară a relaţiei. 2FN
 FN2 interzice existenţa dependenţelor
funcţionale parţiale între atributele cu rol de
cheie primară şi celelalte atribute

Relaţia PieseComandate(NumărComandă, CodPiesă,


Cantitate, PreţUnitar, DenumirePiesă)
nu se află în FN2 pentru că între (Num ărCom andă,
CodPiesă) şi Denum irePiesă există o dependenţă
parţială:
(N um ărCom andă, CodP iesă) → Denum ireP iesă
CodP iesă → Denum ireP iesăNumăr CodPiesă Cantitate Pret Denumire
Comandă Unitar Piesă
1 01 100 20 P1
1 02 150 25 P2
1 - Prof.dr.2 Bogdan IONESCU
01 200 20 P1
Normalizarea Bazelor de Date : DD+RG
2 FN : Relaţia P ieseCom andate prezintă
următoarele anomalii: 1FN
 Redundaţă pentru câmpurile care depind 2FN
parţial de cheia primară. Realizările câmpului
Denum ireP iesă , se repetă inutil
 Anom alii la adăugare : nu se pot adăuga piese
dacă nu s-au făcut comenzi pentru acestea
 Anom alii la m odificare : dacă se modifică
denumirea unei piese, atunci trebuie modificate
toate înregistrările care conţin denumirea
piesei respective
 Anom alii la ştergere : ştergerea unei comenzi
poate conduce la ştergerea definitivă a unor
piese Număr CodPiesă Cantitate Pret Denumire
Comandă Unitar Piesă
1 01 100 20 P1
1 02 150 25 P2
2 01 200 20 P1
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG
2 FN : Pentru aducerea relaţiilor din FN1 în FN2, se parcurg 1FN
următoarele etape:
 Se identifică eventualele dependenţe funcţionale 2FN
parţiale
 Fiecare dependenţă funcţională parţială va genera
câte o relaţie nouă. Relaţia nou formată va avea
ca structură atributele participante în dependenţa
funcţională parţială.
 Atributele determinante devin chei externe în
relaţiile iniţiale şi chei primare în relaţiile nou
formate
Piese(CodPiesă, DenumirePiesă, PreţUnitar)

PieseComandate(NumărComandă, CodPiesă,
Cantitate, PreţUnitar, DenumirePiesă)

PieseComandate(NumărComandă, CodP iesă , Cantitate)


1 - Prof.dr. Bogdan IONESCU
3 FN Normalizarea Bazelor de Date : DD+RG
 O relaţie verifică FN3 dacă se află în
FN2 şi dacă toate atributele 1FN
noncheie sunt dependente 2FN
funcţional netranzitiv de cheia 3FN
prim ară a relaţiei (toate atributele
care nu aparţin cheii prim are să nu
depindă funcţional de un alt atribut.
 De exemplu, relaţia :
Comandă(NumărComandă, Data, CodClient,
DenumireClient) nu respectă FN3, pentru că între
Num ărCom andă şi Denum ireClient există o dependenţă
funcţională tranzitivă:

NumărComandă Data CodClient DenumireClient


1 01/01/2009 01 Ionescu
2 02/01/2009 02 Popescu
3 03/02/2009 02 Popescu
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG
O relaţie care nu respectă FN3 prezintă
următoarele anomalii: 1FN
 Redundanţă pentru atributele determinate 2FN
funcţional tranzitiv
3FN
 Anomalii la adăugare: nu se pot adăuga clienţi
care nu au întocmit comenzi
 Anomalii la modificare: dacă un client îşi
schimbă denumirea, atunci trebuie modificate
toate înregistrările în care apare acea
denumire de client
 Anomalii la ştergere: ştergerea unei comenzi
poate conduce la ştergerea definitivă a
clientului din relaţie

NumărComandă Data CodClient DenumireClient


1 01/01/2009 01 Ionescu
2 02/01/2009 02 Popescu
3 03/02/2009 02 Popescu
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : DD+RG
Pentru aducerea unei relaţii din FN2 în FN3:
 Se identifică eventualele dependenţe 1FN
funcţionale tranzitive 2FN
 Determinantul noncheie împreună cu 3FN
atributul sau atributele determinate
funcţional de către acesta, vor forma o nouă
relaţie
 Determinantul noncheie devine cheie
primară în relaţia nou formată şi cheie
externă în relaţia iniţială
Client(CodClient, DenumireClient)

Comandă(NumărComandă, Data, CodClient, DenumireClient)

Comandă(NumărComandă, Data, CodClient)


1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : 3FN
Forma normala BC Boyce-Codd
 Boyce-Codd
 O relaţie R este în forma BC dacă este în
3FN şi toate atributele non-cheie nu
generează dependenţe funcţionale

FNBC tratează toate dependenţele funcţionale noncheie, ea fiind


de fapt o generalizare a FN2 şi FN3.
Condiţii:
• Există mai multe chei candidate într-o relaţie;
• O parte din cheile candidate sunt compuse;
• Cheile candidate compuse au atribute în comun.
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date
Relaţia
Student(NrMatricol, CodFacultate, Specializare) nu respectă FNBC.

Dacă se presupune că un student nu se poate înscrie la mai multe specializări


în cadrul aceleiaşi facultăţi, dar se poate înscrie la mai multe facultăţi, iar
numărul matricol este stabilit independent în cadrul fiecărei facultăţi, relaţia
dispune de două chei candidate:
(NrMatricol, CodFacultate) → Specializare
(NrMatricol, Specializare) → CodFacultate
De asemenea mai există şi dependenţa Specializare → CodFacultate, în care
Specializare nu este cheie candidată (o specializare există la o singură
facultate). NrMatricol CodFacultate Specializare
010 CIG Specializare1Cig
011 CIG Specializare2Cig
... ... ...
011 FAB Specializare1Fab
012 FAB Specializare1Fab
013 FAB Specializare2Fab
... 1 - Prof.dr. Bogdan IONESCU
... ...
Normalizarea Bazelor de Date
Pentru aducerea unei relaţii în FNBC, se parcurg următoarele
etape:
• Se identifică cheile candidate din cadrul relaţiei
• Se identifică determinanţii care nu sunt chei candidate
• Fiecare determinant identificat la pasul 2 împreună cu
atributul determinat, va genera o nouă relaţie unde va fi
cheie primară. În vechea relaţie, acesta va deveni şi cheie
externă.
Parcurgând aceste etape, relaţia Student va deveni:
Student(NrMatricol, Specializare)

Student(NrMatricol, CodFacultate, Specializare)

Specializari(Specializare, CodFacultate)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : 3FN
Forma normala 4 Boyce-Codd
4 FN
4FN
 O relaţie R este în 4FN, dacă este în
forma BC şi dacă nu există
dependenţe funcţionale multivaloare
elementare în aceeaşi relaţie (unice)
Exemplu: o carte e scrisă de mai mulţi autori şi fiecare autor scrie
la toate capitolele. Adică, există toate combinaţiile posibile între
CodAutor şi NrCapitol.
Ca urmare, în relaţia Carte(CodCarte, CodAutor, NrCapitol) există
următoarele dependenţe multivaloare:
CodCarte→→ CodAutor/NrCapitol CodCarte CodAutor NrCapitol
111 Ionescu 1
111 Popescu 2
111 Ionescu 2
111 Popescu 1
1 - Prof.dr. Bogdan IONESCU ... ... ...
Normalizarea Bazelor de Date : 3FN
Forma normala 4 Boyce-Codd
4FN
Pentru aducerea unei relaţii în FN4:
• Se identifică dependenţele multivaloare
• Determinantul dependenţei (X) va forma
câte o relaţie cu fiecare atribut determinat (Y şi Z)
• În relaţiile nou formate cheile primare vor fi compuse din
determinant şi atributul determinat
CarteAutor(CodCarte, CodAutor)

Carte(CodCarte, CodAutor, NrCapitol)

CarteCapitol(CodCarte, NrCapitol)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : 3FN
Forma normala 5 Boyce-Codd
 5 FN 4FN
 O relaţie R este în 5FN, dacă este în 4FN
şi tratează cazurile în care există mai 5FN
multe dependenţe funcţionale
multivaloare care sunt interlegate între
ele

De exemplu, fie relaţia :


Aprovizionare(Factura, Material, Gestiune).
În această relaţie se manifestă dependenţe multivaloare
interlegate (FacturaMaterial, MaterialGestiune, FacturaGestiune),
dacă sunt îndeplinite condiţiile: F1
Factura Material
M1 G2
Gestiune

F1 conţine M1 F2 M2 G1

M1 se depozitează în G1 F1 M2 G1

F1 însoţeşte materialul în G1 F3
F3
M1
M3
G2
G2
Atunci, F1 conţine M1 care va fi depozitat în G1.
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date : 3FN
Forma normala 5 Boyce-Codd
Etape FN5: 4FN
• Se identifică dependenţele interlegate 5FN
• Fiecare dependenţă interlegata se
descompune conform proiecţiilor sale
(XYZ = XY * YZ * XZ)
• Pentru fiecare relaţie, cheia primară va fi
formată din atributele componente.

FacturaMaterial(Factura, Material)

Aprovizionare(Factura, Material, Gestiune) FacturaGestiune


(Factura, Gestiune)

MaterialGestiune(Material, Gestiune)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Matricea Dependenţelor Funcţionale

 Formalizarea procesului de normalizare este


operaţională prin Matricea Dependenţelor Funcţionale:
 MDF are pe linie toate atributele dicţionarului de date
 MDF are pe coloană toate atributele sau numai atributele
care pot avea rol de cheie primară
 Se notează 1 la intersecţia liniei cu coloana pentru care
există dependenţă funcţională
 Se notează cu „M” dependenţa multiplă
 Se notează 1T dependenţele funcţionale tranzitive
 Liniile care NU AU 1 desemnează fie atribute care nu sunt
dependente funcţional de un identificator simplu, fie desemnează
atribute parametru
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE
 Inventarierea atributelor (se vor selecta toate atributele referitoare la
facturile primite)
 Număr factură

 Dată factură

 Cod furnizor

 Denumire furnizor

 Adresa, etc.

 Se specifică regulile de gestiune şi algoritmii de calcul asociaţi (se vor


specifica diversele restricţii şi condiţii impuse datelor)
 O factură este emisă de un singur furnizor

 Codul materialului este unic

 O factură conţine mai multe produse aprovizionate

 Furnizorii pot fi numai persoane juridice

 Algoritmii de calcul: (Val_mat_fact=Cant_facturată*Preţ_unitar)


1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE
 Se întocmeşte dicţionarul datelor
 Un atribut poate fi înscris o singură dată în dicţionar

 Se elimină atributele sinonime (de ex. Cod furnizor = Simbol

furnizor)
 Dicţionarul datelor nu admite atribute derivate sau calculate

(Valoare, TVA)

Nr.crt Atribut În clar


1 CodFz Cod Furnizor
2 DenFz Denumire Furnizor
3 AdrFz Adresă Furnizor
4 NrFact Număr Factură
5 DataFact Dată
1 - Prof.dr. Bogdan Factură
IONESCU
Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE
 Se stabilesc dependenţele funcţionale între atribute prin
MDF
 Toate atributele sau grupurile de atribute determinante,
devin CHEI CANDIDATE (posibile chei ale relaţiei). Cheile
candidate aparţinând aceleiaşi relaţii sunt caracterizate prin
dependenţe funcţionale reciproce.
 Se stabilesc CHEILE PRIMARE dintre cheile candidate

CodFz DenFz AdrFz NrFact DataFact


CodFz NU 1 1
DenFz NU
AdrFz NU
NrFact 1 1T 1T NU 1
DataFact NU
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE
 Sau se stabilesc dependenţele funcţionale între atribute prin DDF

Denumire Furnizor

Cod Furnizor
Adresă Furnizor

Număr Factură Dată Factură

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE

 Pentru atributele izolate se vor căuta grupuri de


atribute ce pot constitui determinanţi ai acestora. Se
vor căuta mai întâi grupuri de chei primare, apoi
grupuri de atribute non-cheie, iar în final, dacă va fi
cazul, se vor adăuga chei surogat.
 Cu fiecare cheie primară şi cu atributele determinate
direct (fără tranzitivitate) se formează o nouă relaţie.
 Se stabilesc CHEILE EXTERNE

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
Etapele procesului de NORMALIZARE

 Dacă între două chei primare există o dependenţă


multiplă (reciprocă), atunci, această dependenţă
va genera o relaţie.
 Cheia primară a acestei relaţii va fi formată din
cele două atribute, care, individual vor avea şi rol
de chei externe (in alte realtii).

FURNIZOR(CodFz, DenFz, AdrFz)


FACTURĂ(NrFact, DataFact, CodFz)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
EXEMPLUL II: Evidenţa facturilor emise

CodCli,
NrFact, CLIENTI

DataFact
FACTURI Nume,
Adresa,
PRODUSE
Tel
CodProd,
DenProd,
CantFact,
Pret

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
EXEMPLUL II: Evidenţa facturilor emise
NrFact, DataFact, CodCli, Nume, Telefon, Adresa,
CodProd, DenProd, CantFact, Pret
FN1
 Descompunerea atributelor compuse ale
dicţionarului de date în atribute simple
 Precizarea identificatorului.

Dicţionarul datelor

(NrFact, DataFact,

CodCli, Nume, Telefon, Adresa, Localitate, CodPostal,

CodProd, DenProd, CantFact, PretRef, PretFact)

1 - Prof.dr. Bogdan IONESCU


Normalizarea Bazelor de Date:
EXEMPLUL II: Evidenţa facturilor emise
CLIENTI
 FN2 FACTURI
 Fiecare atribut non-cheie să
depindă de întreaga cheie FACTURAT
primară (dependenţe
elementare).
CLIENTI (CodCli, Nume,
Telefon, Adresa, CodPostal,
Localitate) PRODUSE
FACTURI(NrFact, DataFact, CodCli)
PRODUSE(CodProd, DenProd, PretRef)
FACTURAT(NrFact, CodProd, CantFact, PretFact)
1 - Prof.dr. Bogdan IONESCU
Normalizarea Bazelor de Date:
EXEMPLUL II: Evidenţa facturilor emise

• FN3
Eliminarea dependenţelor tranzitive
CLIENT (CodCli, Nume, Telefon, Fax, Adresa, CodPostal)
FACTURA(NrFact, DataFact, CodCli)
PRODUS(CodProd, DenProd, PretRef)
FACTURAT(NrFact, CodProd, CantFact, PretFact)
LOCALIZARE(CodPostal, Localitate)

1 - Prof.dr. Bogdan IONESCU


EXEMPLUL III: Enunţ + RG
O editură doreşte informatizarea activităţii legate de evidenţa
stocurilor de carte produse, a autorilor şi a facturilor către clienţi.

Reguli de gestiune:
a. Editura produce mai multe cărţi anual;
b. O carte primeşte un Cod ISBN la fiecare retipărire;
c. Cărţile sunt scrise de către autori. Un autor poate scrie mai
multe cărţi;
d. Clienţii editurii sunt numai persoane juridice;
e. O factură conţine cel puţin o carte şi o carte poate figura pe
mai multe facturi;
f. Preţul de vânzare se stabileşte în momentul producerii unei
cărţi, acesta fiind un preţ orientativ, rămânând neschimbat
până la epuizarea tirajului, preţul efectiv de vânzare fiind
negociat cu fiecare client;
1 - Prof.dr. Bogdan IONESCU
EXEMPLUL III – D.A.
1 Cod ISBN

Din studiul activităţii 2


3
Denumire carte
Data apariţiei
Stocul tipărit
editurii au rezultat 4
Preţul de bază
următoarele atribute:
5
7 Număr factură
8 Data factură

Se elimină “atributele” 9 Cantitatea facturată


Denumire Carte facturată
sinonime şi calculate
10

11 Pret Carte factură

12 Valoare Carte factură

CĂRŢI ? AUTORI 13 Total factură

Cod ISBN CNP autor


14 Cod Fiscal Client

15 Denumire Client
......... .........
? 16 Adresa client

17 Telefon

CLIENŢI
18 CNP autor
FACTURI 19 Nume Prenume
CF client Nr Factură 20 Data naşterii
......... ......... 21 Adresa autor
1 - Prof.dr. Bogdan IONESCU
CĂRŢI EXEMPLUL III – D.A.
Cod ISBN
.........
?

FACTURI
Nr Factură
.........

CĂRŢI CONŢINUT FACTURĂ FACTURI


Cod ISBN Nr Factură, Cod ISBN Nr Factură
......... ......... .........

1 - Prof.dr. Bogdan IONESCU


EXEMPLUL III – D.A.

CĂRŢI ? AUTORI
Cod ISBN CNP autor
......... .........

CĂRŢI AUTORI
AUTORI CĂRTI
Cod ISBN CNP autor
Cod ISBN, CNP autor
......... .........

1 - Prof.dr. Bogdan IONESCU


Matricea dependentelor functionale

Data factura

CNP autor
Cod fiscal
Cod ISBN
Denumire

Denumire
Pret carte
Cantitate

prenume
facturata
aparitiei

Telefon

nasterii
Adresa

Adresa
Pret de

factura

factura
Numar
Stocul

Nume
tiparit

client

client

client

autor
carte

baza
Data

Data
Cod ISBN 1 1 1 1
Den. carte
Data aparitiei
Stocul tiparit
Pret de baza
Numar factura 1 1 1T 1
T
1T
Data factura
Cantitate
facturata
Pret carte
factura
Cod fiscal
client 1 1 1
Denumire
client 1 1 1
Adresa client
Telefon
CNP autor 1 1 1

Nume prenume
Data nasterii
Adresa autor
Cod ISBN +
T T
1T
T T T
1T
T T
Numar factura 1 1 1 1 1 1 1 1 1
CNP +
Cod ISBN 1 - Prof.dr. Bogdan IONESCU
Matricea dependentelor functionale

Data factura

CNP autor
Cod fiscal
Cod ISBN
Denumire

Denumire
Pret carte
Cantitate

prenume
facturata
aparitiei

Telefon

nasterii
Pret de

Adresa

Adresa
factura

factura
Numar
Stocul
tiparit

Nume
client

client

client

autor
carte

baza
Data

Data
Cod ISBN 1 1 1 1
Numar factura 1 1 1T 1T 1T
Cantitate
facturata
Pret carte
factura

Cod fiscal client 1 1 1


CNP autor 1 1 1
Cod ISBN +
T
Numar factura 1 1T 1
T
1
T
1T 1 1 1T 1T 1
T
1T
CNP +
Cod ISBN

Se observă din matrice, că PretCarteFactura şi CantitateFacturată sunt atribute


izolate şi că nu există un grup de chei primare sau grup de atribute noncheie care
să le determine funcţional.

Astfel, se identifică grupul de atribute SerieFactură, NumarFactura si CodISBN,


vor determina funcţional cele două câmpuri izolate. Noua tabela va fi
ContinutFactura
(NumarFactura, SerieFactura, CodISBN) → CantitateFacturată
(NumarFactura, SerieFactură, CodISBN)→
1 - Prof.dr. Bogdan IONESCU
PretCarteFactura
AUTORI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare

CNP Number,LI Da Da

Nume prenume Text, 50 Da

Adresa Text, 100 Da

Data nasterii Date/Time Da <=Data curenta

AUTORI-CĂRŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare

CNP Number,LI Da Da

Cod ISBN Text,13,M Da Da

CĂRŢI CONŢINUT
Nume camp
FACTURĂ
Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare
Text,
Cod ISBN
13,M
Da Da
........
Denumire carte Text, 50 Da
Cod ISBN
Data aparitiei Date/Time Da <=Data curenta

Stocul tiparit Currency Da >0


........
Pret baza Currency Da 1 - Prof.dr. Bogdan IONESCU >0
FACTURI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala

Serie factura Text,5,M Da Da

Numar factura Number, LI Da

Cod Fiscal Number , LI Da Da

CONŢINUT FACTURĂ
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Serie factura Text,5,M Da Da Da

Numar factura Number, LI Da Da

Cod ISBN Text, 13,M Da Da

Cantitate fact Number, Int Da >0

Pret factura Currency Da >0

CLIENŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Cod fiscal Number, LI Da Da

Denumire client Text,50 Da Da

Adresa Text,100 Da
1 - Prof.dr. Bogdan IONESCU
Telefon Text,20
1 - Prof.dr. Bogdan IONESCU
MRD – Îmbunătățit prin adăugarea de noi reguli de gestiune

APROVIZIONAREA
Editura comandă tirajul fiecărei apariții editoriale ce urmează a fi tipărit
la o tipografie (ce are in acest exemplu calitatea de FURNIZOR).
Aceasta livreaza carti editurii, care atunci când le recepționează
întocmește Nota de Recepție și Constatare de Diferențe (NRCD).

FURNIZORI(CodFiscalFz, DenumireFurnizor, Adresa, Localitate, ..)

NRCD(Nr.NRCD, CodFiscalFz, DataAproviz, MijlocTransport, etc)

CARTI_APROVIZIONATE(Nr.NRCD, Cod_ISBN, CantitateIntrata,


PretAprovizionareFaraTVA, PretAprovizionareCuTVA – se calculează in
tabela)

CARTI(Cod_ISBN, ………………………….)
1 - Prof.dr. Bogdan IONESCU
MRD – Îmbunătățit prin adăugarea de noi reguli de gestiune

GENURI, COLECTII si DOMENII


Editura are ca obiect de activitate editarea de carti si manuale
universitare. Cărțile editate sunt împărțite pe tipuri sau genuri
(manual, culegere, carte specialitate, etc.). Aceste tipuri sunt utile
editurii, la acreditari si in relațiile cu Biblioteca Națională.
Cartile apartin unor colectii tematice (InfoBD, InfoProg, ContaGen), iar
colectiile apartin unui domeniu științific (sau de interes didactic), cum
ar fi : Analiza economica, Audit, Contabilitate, Informatica, Finante,
Management, Marketing, etc.
GENURI (CodGenLiterar, NumeGenLiterar)
COLECTII (CodColectie, Nume Colectie, Cod Domeniu)
DOMENII (Cod Domeniu, Nume Domeniu)
CARTI(Cod_ISBN, ………….., CodGenLiterar, CodColectie)
1 - Prof.dr. Bogdan IONESCU
MRD – Îmbunătățit prin adăugarea de noi reguli de gestiune

COORDONATORI
Cartile pot avea unul sau mai multi coordonatori.
Coordonatorii reprezinta autorii unei aparitii editoriale in raporturile
juridice cu editura. Coordonatorii pot fi sau nu, autori.

COORDONATORI(CNPCoordonator, NumeCoordonator, Adresa,


Localitate, Afiliere, etc)

COORDONATORI_CARTI(Cod_ISBN, CNPCoordonator)

CARTI(Cod_ISBN, ……….)
1 - Prof.dr. Bogdan IONESCU
CONTRIBUTIA AUTORILOR LA OPERA (I)
Cartile au mai multe capitole si sectiuni. Se defineste o sectiune ca fiind
un interval de pagini ce constituie o contributie cuantificabila a unui
autor. Un capitol poate avea mai multe sectiuni. Un autor poate scrie
intervale de pagini in cadrul unuia sau a mai multe capitole. Numarul de
pagini scrise reprezintă procent din opera si este important pentru
calculul drepturilor de autor.

Problema cuantificarii contributiei ar fi urmatoarea :


a) fiecare autor are o contributie totala intr-o carte sub forma unui
numar total de pagini, care reprezinta procent din opera

AUTORI(CNP Autor, ………………..)

CONTRIBUTIE_AUTORI(Cod_ISBN, CNP Autor, Nr.PaginiContributie)

CARTI(Cod_ISBN, …….)
1 - Prof.dr. Bogdan IONESCU
CONTRIBUTIA AUTORILOR LA OPERA (II)

b) Fiecare autor isi identifică contributia sub forma unui interval de


pagini, fie la nivel de capitol (ar mai interveni inca o tabela si ar fi de
exemplu : cap IV Ionescu pag 45-56; 73-80; Stanciu pag 23-37, etc), fie la
nivel de opera.

AUTORI(CNP Autor, ………………..)


CARTI(Cod_ISBN, ………….)

CAPITOL_CARTE(NrCapitol, NumeCapitol, Pag.Inceput, Pag.Sfarsit,


Cod_ISBN)

SECTIUNI_AUTORI(Cod_Sectiune, Nr.Capitol, Cod_ISBN, CNP Autor,


Pag.Inceput, Pag.Sfarsit)
1 - Prof.dr. Bogdan IONESCU
SECTIUNI(Cod_Sectiune, Nume_Sectiune)
MRD – Îmbunătățit prin adăugarea de noi reguli de gestiune

DREPTURI AUTOR (I)


Fiecare apariție editoriala este purtătoare de drepturi de autor.

Drepturile de autor sunt stabilite in forma procentuala din veniturile


nete inregistrate de carte la vanzarea sa (din pretul de vanzare, numit si
pretul de baza sau catalog se deduce comisionul vanzatorului).

CARTI(Cod_ISBN, ……………………., ProcentDrepturiAutor,……………)

1 - Prof.dr. Bogdan IONESCU


DREPTURI AUTOR (II)
Se abordează problema prin prisma CONTRACTULUI DE EDITARE. Acesta
ar specifica procentul drepturilor de autor si care este coordonatorul
lucrării. Coordonatorul reprezintă autorii intr-un contract de editare.
Rămâne de văzut dacă se face asocierea dintre fiecare carte si fiecare
autor, prin tabela intermediara AUTORI_CARTI sau se abordează aceeași
problemă prin Coordonator(i) carte care ii reprezintă pe autori,

CARTI(Cod_ISBN, ……………………., )

CONTRACT_EDITARE(Nr.ContractEditare, DataContractEditare, Tiraj


Total, Data primei aparitii, (ProcentDrepturiAutor) , Primul tiraj,
Cod_ISBN)

COORDONATORI_CARTI(Nr.ContractEditare (Cod_ISBN),
CNPCoordonator)
1 - Prof.dr. Bogdan IONESCU
COORDONATORI(CNPCoordonator, NumeCoordonator, …….)
FACTURAREA
Factura este unica la nivel de editura; O factura contine mai multe
carti livrate, iar o carte figurează pe mai multe facturi; Cota de TVA
este marcata pe factura, deoarece din punctul de vedere al editurii,
continutul facturii este omogen, adica se vand numai carti.
Altfel, daca se schimbă regula de gestiune si editura livreaza si altceva,
cu cote diferite de TVA, atunci se poate trece cota de TVA pe
CONTINUT FACTURA. Pe fiecare factura se marchează un delegat din
partea editurii
CLIENTI(CodFiscalClient, Nr_inreg.RC, ………………)
FACTURI(NrFactura, DataFactura, DataScadentei, Cota_TVA,
CodFiscalClient, CNP_Delegat)
CONTINUT_FACTURA(NrFactura, Cod_ISBN, Cantitate,
Reducere_comerciala)
DELEGAT(CNP_Delegat, CI_serie, CI_numar, ………..)
CARTI(Cod_ISBN, …………………………………….)
1 - Prof.dr. Bogdan IONESCU
INCASAREA

Pentru a evidentia platile facute de clienti pentru cartile primite, adica


incasarile editurii, putem aborda următoarea modelare :

CLIENTI(CodFiscalClient, Nr_inreg.RC, …………………)

INCASARE_CLIENT(TipDoc.Incasare-Nr.Doc.Incasare, , CodFiscalClient)

Iar pentru faptul ca unii clienti platesc partial facturile, se asociază


facturile cu incasarile.

FACTURA_INCASATA(NrFactura, TipDoc.Incasare-Nr.Doc.Incasare,
DataIncasarii, SumaIncasata)

FACTURI(NrFactura, DataFactura, DataScadentei,


1 - Prof.dr. Bogdan IONESCU …………………..)
Algebra relaţională

Algebra relaţională poate fi definită ca un set de operatori, care


prelucrează relaţii în scopul obţinerii altor relaţii.

Operatorii relaţionali se împart în :


•operatori de asamblare
• reuniunea;
• intersecţia;
• diferenţa;
• produsul cartezian
•operatori unari :
• proiecţia;
• selecţia
•operatori de extensie :
• compunerea;
• diviziunea
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Asamblare

Operatorii de asamblare sunt operatori binari, care


primesc la intrare două relaţii şi generează la ieşire o
singură relaţie.
Operatori
Binari
Relaţie1 Relaţie3

Relaţie2

Operatorii de asamblare sunt:


•Reuniunea;
•Intersecţia;
•Diferenţa;
•Produsul cartezian.
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Asamblare:R
Reuniunea a două relaţii R şi S, cu aceeaşi structură, unde R
este formată din n tupluri şi S este formată din m tupluri, are ca
rezultat o a treia relaţie T, având aceeaşi structură cu a relaţiilor
sursă şi conţinând m +n tupluri.
Relaţia R Relaţia S Relaţia T  (R reunit cu S)
A B C A B C A B C

a1 b1 c1 a3 b3 c3 a1 b1 c1
a2 b2 c2
a4 b4 c4
a2 b2 c2
a5 b5 c5
a3 b3 c3

Ex. Care sunt furnizorii care au a4 b4 c4


livrat cel puţin unul dintre produsele A
şi B = reuniunea furnizorilor care au a5 b5 c5
livrat A cu fz. care au livrat 1B- Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Asamblare:I
Intersecţia a două relaţii R şi S cu aceeaşi structură este o relaţie T,
(cu aceeaşi structură), conţinând tuplurile identice aparţinând atât
lui R cât şi lui S.
Relaţia T (R intersectat cu S)
Relaţia R Relaţia S
A B C A B C
A B C
a1 b1 c1 a3 b3 c3
a4 b4 c4
a2 b2 c2 a4 b4 c4

a4 b4 c4 a5 b5 c5

Ex. Care sunt furnizorii care au


Ex. Care sunt zilele în livrat şi produsul A şi produsul B =
care au fost cumpărate intersecţia tabelelor de furnizori care
autoturismele A şi B auBogdan
livratIONESCU
A cu fz. care au livrat B
1 - Prof.dr.
Algebra relaţională: Operatori de Asamblare:D
Diferenţa a două relaţii R şi S având aceeasi structură (R-S), este
o relaţie T, cuprinzând mulţimea tuplurilor aparţinând lui R dar
neaparţinând lui S.
Diferenţa nu este comutativă. Atributele relaţiei “diferenţă” (T)
sunt cele ale primei relaţii (descăzutul), iar tuplurile care sunt
extrase din relaţia descăzut, nu se regăsesc în relaţia scăzător
Relaţia R Relaţia S Relaţia T  R-S
A B C
A B C
a1 b1 c1
a3 b3 c3
A B C
a2 b2 c2
a4 b4 c4
a1 b1 c1
Ex. Care sunt clienţii
a5 b5 c5
care au cumpărat
produsul A, fără a-l a2 b2 c2
cumpăra pe B
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Asamblare:PC
Produsul cartezian a două relaţii R şi S (RxS) este o relaţie T
stocând mulţimea perechilor obţinute prin concatenarea
înregistrărilor aparţinând lui R cu cele aparţinând lui S.
Relaţia T  RxS
Relaţia R Relaţia S
A B C D E
C D E
A B a1 b1 c1 d1 e1
c1 d1 e1
a1 b1 a1 b1 c2 d2 e2
c2 d2 e2
a2 b2 a1 b1 c3 d3 e3
c3 d3 e3
a2 b2 c1 d1 e1

a2 b2 c2 d2 e2

a2 b2 c3 d3 e3
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori Unari

•Operatorii unari se aplică asupra unei relaţii şi


generează o altă relaţie.
•Operatorii unari operează prin restricţii.

Operatori
Unari
Relaţie1 Relaţie2

Operatorii unari permit decuparea unei relaţii pe


orizontală : Selecţia şi pe verticală: Proiecţia

1 - Prof.dr. Bogdan IONESCU


Algebra relaţională: Operatori Unari:Pr
Proiecţia unei relaţii R după anumite atribute, este relaţia R1 cu
structura R1 (Ai1, Ai2, … , Aip), ale cărei tupluri se obţin prin eliminarea
valorilor atributelor din R care nu apar în R1 şi prin suprimarea
tuplurilor identice (dubluri) .
Altfel spus, prin intermediul proiecţiei, dintr-un tabel cu un anumit
număr de coloane se obţine unul cu un număr mai mic de coloane
Relaţia R Relaţia R1
A B C D
A B
a1 b1 c1 d1 R1Π (R;A,B)
a1 b1
a2 b2 c2 d2
a2 b2
a3 b3 c3 d3
a3 b2
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori Unari:Sel
Selecţia relaţiei R faţă de criteriul Q este relaţia R1 cu aceeaşi structură
ca şi R, ale cărei tupluri satisfac criteriul specificat.

Altfel spus, prin operatorul de selecţie, dintr-un tabel cu un anumit


număr de coloane se obţine unul cu aceleaşi coloane, dar cu un număr
mai mic de rânduri.
 Selecţia triază dintr-o tabelă numai tuplurile ce satisfac o
condiţie precizată (printr-un predicat).
R1SELECTIE(R;A=a2
Relaţia R
OR A=a3) Relaţia R2
R1
A B R2SELECTIE(R;A=a2
a1 b1 AND B=b2) A B
a2 b2 a2 b2
a3 b3
a3 b3
1 - Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Extensie

Operatorii de extensie joacă un rol foarte important în


interogarea bazelor de date relaţionale.

Operatorii de extensie sunt:


•Compunerea (fuziunea / joncţiunea);
•Diviziunea.

1 - Prof.dr. Bogdan IONESCU


Algebra relaţională: Operatori de Extensie: Join
•Produsul cartezian era o fuziune necondiţionată a două tabele.
•COMPUNEREA reprezintă fuziunea a două relaţii care au o proprietate
comună.
Fie 2 relaţii R1(A1, A2, ...., An) şi R2(B1,B2,......Bm), care au 2 atribute
(comune) Ai şi Bj, definite pe acelaşi domeniu de valori, şi θ ansamblul
operatorilor de comparaţie {=, >, <, >=, <=, <>}ce pot fi aplicaţi celor
două atribute Ai şi Bj.
Theta-Compunerea relaţiei R1, prin Ai, cu relaţia R2, prin Bj
(R1 ►◄ θR2) este relaţia R3 ale cărei tupluri sunt obţinute prin
concatenarea fiecărui tuplu al relaţiei R1, cu tuplurile relaţiei R2,
pentru care este verificată condiţia θ instituită între Ai şi Bj.
Un caz particular al theta-compunerii este echi-compunerea,
atunci când operatorul de comparaţie θ este “=“
Echi-comp. pentru care există o denumire identică a atributelor de
legătură dintre cele 2 tabele  compunere
1 - Prof.dr. Bogdan IONESCU naturală
Algebra relaţională: Operatori de Extensie: Join
•COM PUNEREA este echivalentă unui produs cartezian urmat de
o selecţie (şi eventual de o proiecţie).

Relaţia R3R1R2
Relaţia R1
A R1.B C R2.B D
A B C
a1 b1 c1 b1 d1
a1 b1 c1
a1 b1 c1 b2 d2

Relaţia R2 a1 b1 c1 b3 d3

B D
b1 d1 R4=Selecţie(R3, R1.B=R2.B)
b2 d2 A B C D
b3 d3 a1 b1
1 - Prof.dr. Bogdan IONESCU
c1 d1
Algebra relaţională: Operatori de Extensie: Join
Cele 3 tipuri de joncţiuni prezentate (theta, echi, naturală) sunt de
natură internă şi prezintă 2 extensii:
• Compunerea externă;
• Semicompunerea

Compunerea externă include în tabela rezultat şi tupluri din una


dintre relaţii, sau din ambele relaţii, care prezintă valori ale atributului
de legătură ce nu se regăsesc în cealaltă relaţie
În cazul compunerii externe trebuie să se precizeze din care relaţie se vor
prelua tuplurile fără corespondent în cealaltă relaţie. Din acest punct de
vedere există:
 compunere externă la stânga (left outer join)
 compunere externă la dreapta (right outer join)
 compunere externă1 -totală (reuniunea celor 2 relaţii)
Prof.dr. Bogdan IONESCU
Algebra relaţională: Operatori de Extensie: Join
R1 R2 R3(R1,R1.C=R2.C,R2)
A B C C D E A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1 a1 b1 c1 c1 d1 e1
a3 b3 c3 c3 d2 e2
a2 b2 c2 c3 d2 e2
a3 b3 c3 c5 d3 e3 A B R1.C R2.C D E
a1 b1 c1 c1 d1 e1
Left Outer JOIN
a2 b2 c2 Null Null Null
a3 b3 c3 c3 d2 e2

Right Outer JOIN A B R1.C R2.C D E


a1 b1 c1 c1 d1 e1
Null Null Null c5 d3 e3
Compunere totală a3 b3 c3 c3 d2 e2

1 - Prof.dr. Bogdan IONESCU


Algebra relaţională: Operatori de Extensie: Join

Semicompunerea a 2 tabele presupune selectarea tuplurilor din


prima tabelă care apar în joncţiune cu tuplurile din a doua tabelă

R1 R2 SemiCompunere
A B C C D E
A B C
a1 b1 c1 c1 d1 e1
a2 b2 c2 c3 d2 e2 a1 b1 c1
a3 b3 c3 c5 d3 e3 a3 b3 c3

R3(R1,R1.C=R2.C,R2)
A B R1.C R2.C D E
a1 b1 c1 c1 c1 d1
a3 b3 c3 c3 d21 - Prof.dr.
e2 Bogdan IONESCU
Algebra relaţională: Operatori de Extensie: Div
R1 Diviziunea relaţiei R1 prin relaţia R2 este relaţia R3 formată
A B din toate tuplurile care, concatenate cu fiecare tuplu din R2,
a1 b1
b1 returnează întotdeauna un tuplu din R1 (R 3 = R1 ÷ R 2).
a2 b1
b1
a3 b1
b1
a1 b2
b2 R2 Care dintre valorile
a3 b2
b2
a4 b2
b2
B R3
a1, a2, a3, a4 şi a5
a1 b3
b3 b1 apar în relaţia R1, în
A
a3 b3
b3 / tupluri, împreună cu
b2 a1
a5 b3
b3
toate valorile
a1 b4
b4 b3 a3
a3 b4
b4
atributului B
a4 b4
b4
b4 (împărţitor) din R2,
a1 b5
b5 b5 respectiv b1, b2, b3,
a2 b5
b5
b4, b5 ?
a3 b5
b5
a5 b5
b5 1 - Prof.dr. Bogdan IONESCU
CONCEPEREA Bazelor de Date

1
Teoria generală
a bazelor de date
 Baza de date este:
– Un ansamblu de date structurate
– Legate funcţional
– Stocate pe suporturi tehnice adresabile
– Accesate de mai mulţi utilizatori de o manieră selectivă
şi într-un timp oportun

1 - Prof.dr. Bogdan
IONESCU
Conceperea bazelor de date

Pentru a concepe o bază de de date,


trebuie :
1. Proiectată, adică construită o schemă
conceptuală, modelată sub formă de entități
și asocieri;
2. Transformată schema conceptuală (E-A) în
schemă relațională;
3. Implementată schema relațională într-un
SGBD

3
Conceperea BDR

Normalizare

Problemă de Proiectare
informatizat Schema relaţională
BD MRD

Model E-A
Descrierea
datelor

Limbaj de Descriere a Datelor

Limbaj de Manipulare a Datelor

Manipularea
datelor

4
Relational model
Origine :
Edgar Frank
"Ted" Codd (1970)

Entity–Relationship model
Modelul R se
Origine : C.Bachman (1969), fundamentează pe
Peter Chen (1976). noţiunea matematică
Modelul E-A este un formalism grafic de relaţie
R(X1,X2,....Xn)
pentru modelarea datelor bazat pe: unde, pentru
- reprezentării grafice; fiecare element Xi
- concepte simple și ușor de formalizat : se defineşte un
- un lucru care poate fi identificat în mod domeniu de valori
distinct (Chen) = un obiect – ENTITĂȚI
- legături între aceste lucruri (obiecte) ->
ASOCIERI
5
Modelul Entitate – Asociere (Entity–
Relationship model)
 Este cel mai cunoscut model al claselor de modele
semantice,
– se identifică concepte semantice, de semnificație
pentru a descrie sisteme informaționale
– se imaginează un ansamblu de obiecte simbolice
care sunt utilizate pentru reprezentarea conceptelor
semantice
– se imaginează un ansamblu de reguli de
integritate formalizate pentru a conferi
semnificație acestor obiecte formale.
– se dezvoltă un ansamblu de operatori formali
pentru a manipula aceste obiecte formale
6
Modelul Entitate – Asociere
Modelul E-A operează în reprezentarea realității cu 3
concepte :
 Entitatea – sub forma unui lucru/obiect ce poate fi
identificat și descris de o manieră distinctă (Chen)
 Proprietatea (sau Atributul) :
– Entitățile (și asocierile) sunt descrise de
 caracteristici, numite și proprietăți;
 Un nume;
 Un tip de dată

 Asocierea :
– Legătură între entități
– Poate fi : unară (reflexivă sau recursivă), binară, ternară, n-
7 ară
Diagrama modelului E-A
CLIENTI
 Entitatea (Obiect)
– Este un obiect, un eveniment, un loc,
o persoană, un lucru – elemente identificabile
– Are o existență proprie;
– Poate reprezenta o noțiune concretă
(Clienți, Furnizori, Studenți, Cărți)
sau abstractă (Colecții, Învață, etc.)
– Este conformă unei nevoi de descriere informațională;
– Se reprezintă printr-un dreptunghi ce conține numele entității

8
Diagrama modelului E-A
CLIENTI
 Proprietățile (sau atributele) CUI_Client
– Descriu caracteristicile entităților Denumire_Client
Adresa_Client
și asocierilor (este o dată elementară); Telefon_Client
– Numele proprietății se scrie în Mail_Client
Localitate_Client
interiorul entității sau asocierii Tara_Client
corespondente ……………
– Proprietățile cu rol de identificator (numite și chei in
modelul relațional) sunt subliniate
 REGULI DE BAZĂ :
– O proprietate (aceeași, cu aceeași semnificație) nu
poate exista declarată în 2 obiecte diferite (entități).
– O entitate are cel puțin o proprietate.
9– O asociere poate avea sau nu proprietăți
Diagrama modelului E-A : Identificator
Într-o entitate fiecare înregistrare (ocurență, tuplu) trebuie să
fie identificată de o manieră unică.

Un Identificator este o proprietate (un atribut) / grup de


proprietăți (atribute) a cărei(or) valoare(i) identifică fără
ambiguitate o înregistrare a unei entități

În modelul relațional identificatorul unei entități este


echivalent cu cheia primară a unei relații
1. O entitate are un singur identificator = O tabelă are o singură
cheie primară.
2. Un identificator poate fi compus dintr-o singură proprietate sau
din mai multe;
3. Identificatorul unei entități nu trebuie să varieze în timp;
4. Se poate crea și un identificator artificial – fără legătură directă
10cu semantica entității (chei surogat)
Diagrama modelului E-A :
Identificatorul entității
– Dacă nu se găsește o proprietate cu rol de identificator
pentru o entitate, este posibil ca aceasta să nu aibă o
existență proprie și să fie o asociere.

11
Diagrama modelului E-A :
Identificatorul asocierii
 O asociere nu are un identificator explicit. Asocierea
depinde de entitățile de care aceasta este legată.
Identificatorul se deduce prin calculul produsului
cartezian al identificatorilor entităților asociate.
– pentru asocierea FACTURAT ce leagă FACTURI de
PRODUSE, identificatorul este produsul cartezian al
celor 2 entități participante

FACTURI PRODUSE
Facturat
NrFactura CodProdus
Data Factura DenProdus
Cantitate
Data Scadență PretBaza
……. ……..
12
Identificator în modelul RELAŢIONAL
Tuplurile unei relaţii se pot identifica de o manieră unică prin
intermediul valorilor unuia sau mai multor atribute care joacă rol
de CHEIE PRIMARĂ a relaţiei respective.
 CHEIA EXTERNĂ: Fiind două relaţii R1 şi R2, cu atributele A1 şi A2
chei primare, se spune că în relaţia R1, A2 este dacă, utilizând o
parte din valorile ei sau toate, pot fi regăsite tuplcheie externă urile
relaţiei R2
 (altfel spus, un atribut al unei relaţii este cheie externă, dacă se
regăseşte pe post de cheie primară în altă relaţie)

Relaţii

R1(A1,B1,C1,D1,A2) R2(A2,B2,C2,D2)
Cheie externă

Chei primare
Diagrama modelului E-A
Nume
 Asocierile (relațiile) asociere
– Legătură semantică între entități.
– Legătura nu are orientare (direcție) :
 Comenzile conțin produse comandate sau produsele pot fi
comandate.
– Sunt denumite de regulă printr-un verb sau un substantiv
– Entitățile participante la fiecare asociere sunt conectate la
asociere (prin linii continue).
– Sunt reprezentate de o elipsă (sau romb) ce conține numele
asocierii
– Fiecare linie este etichetată prin cardinalitatea (gradul)
asocierii.
Diagrama modelului E-A :Asocierile

CLIENTI
CUI_Client
Denumire_Client 1-n 1-1 CONTRACTE
Adresa_Client Nr_Contract
Telefon_Client Încheie
Data_Contract
Mail_Client ……………
Localitate_Client
Tara_Client
……………
O asociere poate lega una sau
mai multe entități, determinând
ROLUL acesteia.

15
Diagrama modelului E-A :
Asocierile

CĂRŢI 1-n 1-n AUTORI


Sunt scrise CNP autor
Cod ISBN
......... .........

16
PROIECȚIE ÎN RELAȚIONAL - Dependenţa funcţională : unică
Dependenţele sunt legături logice, ce se stabilesc între
atributele modelului relaţional.

 Există o dependenţă funcţională între 2 atribute atunci când


cunoscând valoarea luată de către un atribut, se furnizează
sistematic valoarea pentru celălalt atribut : dependenţă simplă sau
unică
– A -> B (B depinde funcţional de A, dacă la orice valoare a lui A
corespunde în orice moment o valoare unică a lui B)
– Exemple de dependenţe funcţionale: Tranzitivitate:
 Cod Produs -> Denumire produs Dacă A -> B şi B -> C, atunci
 Cod Produs -> Preţ de referinţă
A ->C
 Număr Comandă -> Dată Comandă
 Număr Comandă -> Cod Client -> Nume Client
 -> Cod Fiscal

Dacă un atribut sau un grup de atribute dintr-un tabel determină


funcţional celelalte atribute ale tabelului, rezultă că atributul sau grupul
de atribute constituie cheia primară a tabelului 1 - Prof.dr. Bogdan
IONESCU
Dependenţa funcţională : multiplă
 Dependenţa multiplă: există o dependenţă multiplă de la A la
B (A »B) atunci când o valoare a lui A determină mai multe
valori ale lui B;
– Exemple de dependenţe funcţionale multiple:
 SerieFactură » CodProdus
 DataFactură » NumarFactură

Dacă între două atribute A şi B există o dependenţă multivaloare (A→→


B), atunci între A şi B există şi o dependenţă multiplă (A »B).

 Dependenţa dublă (triplă): se identifică o dependenţă dublă


(triplă) acele dependenţe dintre un lanţ de atribute;
 Exemple de dependenţe funcţionale triple:
 SerieFactură » CodProdus → DenumireProdus
Dependenţa funcţională completă

 Se numeşte dependenţă funcţională completă


(elementară, totală, deplină), o dependenţă
funcţională de forma A→ B în care B este
dependent funcţional de A, fără să fie dependent
funcţional de nici una din componentele lui A.

 (NrFactură, CodProdus) → Cantitate


 NrFactură ≠ Cantitate
 CodProdus ≠ Cantitate
 Între grupul de atribute (NrFactură, CodProdus) şi Cantitate
există o dependenţă funcţională completă, deoarece câmpul
Cantitate depinde funcţional doar de (NrFactură,
CodProdus) fără să depindă funcţional de NrFactură sau de
1 - Prof.dr. Bogdan
CodProdus. IONESCU
Dependenţa funcţională partială

 O dependenţă funcţională A → B se numeşte


dependenţă funcţională parţială dacă şi numai
dacă B este dependent funcţional atît de A cât şi
de o parte a lui A.

 (NrFactură, CodProdus) → CodFurnizor


 NrFactură → CodFurnizor
 CodProdus ≠ CodFurnizor

 Între CodProdus şi CodFurnizor nu este o dependenţă funcţională,


deoarece un produs poate fi livrat de mai mulţi furnizori.

1 - Prof.dr. Bogdan
IONESCU
Normalizarea Bazelor de Date:
Diagrama dependenţelor funcţionale

 Reprezentarea grafică a dependenţelor funcţionale

Cod Produs Denumire, UM, Preţ de referinţă

NrComandă Dată comandă, Cantitate

Cod Produs comandată


Normalizarea Bazelor de Date:
Dependenţe Inter-Tabele şi Multivaloare
 Dependenţe Inter-Tabele (1-1)
– Când la o valoare a atributului Cheie primară dintr-o tabelă, se
asociază o singură valoare a atributului Cheie primară dintr-o altă
tabelă, se poate spune că există o dependenţă funcţională între
tabele, exprimată prin dependenţa funcţională dintre atributele
chei primare aferente celor două tabele
CodProfesor CNP Profesor

 Dependenţe Multivaloare (1-n) (n-m)


 În cazul în care la o valoare a atributului Cheie primară dintr-o
tabelă, corespund mai multe valori ale altui atribut dintr-o altă
tabelă, se poate spune că există o dependenţă funcţională
multivaloare
Nr.factură Cod Produs

CodProfersor Cod Carte 1 - Prof.dr. Bogdan


IONESCU
Normalizarea Bazelor de Date:
Dependenţe Multivaloare
În relaţia
Lucrează(CodSectie, NumarInventarMijlocFix,
MarcaAngajat)
există dependenţe multivaloare, deoarece:
 într-o secţie lucrează mai mulţi muncitori, la mai multe
utilaje (mijloace fixe).
 Dacă fiecare muncitor lucrează la toate utilajele, atunci
există următoarele dependenţe multivaloare:
 CodSectie→ NumarInventarMijlocFix
 CodSectie→ MarcaAngajat
 Deci, dacă există tuplurile (Sectia1, MijFix1, 001) şi
(Sectia1, MijFix2, 002), atunci vor exista şi tuplurile
(Sectia1, MijFix1, 002) şi (Sectia1, MijFix2, 001).
1 - Prof.dr. Bogdan
IONESCU
Diagrama modelului E-A :
OCURENȚĂ (Instanță, Realizare, Tuplu)
 OCURENȚĂ = Realizare particulară a unei entități, proprietăți sau
asocieri.

FACTURI PRODUSE
NrFactura Facturat
CodProdus
Data Factura Cantitate
DenProdus
Data Scadență Discount
PretBaza
……. ……..

 OCURENȚĂ a entității FACTURI : 683232, 12/03/2016, 30/03/2016;


 OCURENȚĂ a proprietății NrFactura : 683232.
 OCURENȚĂ a asocierii Facturat :23, 2% .

24
Diagrama modelului E-A :
CARDINALITĂȚI
 Cardinalitatea este noțiunea obligatorie a modelului ce permite
rezolvarea unor anomalii, cum ar fi lipsa realizării
corespunzătoare unei entități cu care entitatea curentă
formează o asociere:
– O comandă care nu are produse comandate;
– O factură care nu are produse facturate;
– O carte care nu are autori, etc..
 Deci este vorba de o RESTRICȚIE pe care o declarăm
modelului, în sensul prin care ”se împiedică nerealizarea unei
asocieri, adică faptul ca o comandă să nu aibă nici un produs”
 Pentru o ocurență (instanță) a unei entități, câte
ocurențe ale asocierii participă, cel mai mult și
cel mai puțin ?
25
Diagrama modelului E-A :
CARDINALITĂȚI : tipologii (roluri)

Rolul unei asocieri este definit prin 2 numere (min și MAX), ce reprezintă cel
mai mic număr și cel mai mare număr cu care o entitate participă la asociere
prin ocurențele sale.

0,1 0,1
1,1 1,1
0,n 0,n
1,n 1,n B
A
Asociere

— Întrebări bilaterale :
• Min : ”De câte ori – cel puțin – entitatea A este legată de B” ?
• Max : ”De câte ori – cel mult – entitatea A este legată de B” ?

26
Diagrama modelului E-A :
CARDINALITĂȚI : 1,1
 Asocierea de tip 1,1
– Un client încheie un singur contract.
– Un contract nu este încheiat decât de un singur client.

1,1 1,1
CLIENT Incheie CONTRACT

27
Diagrama modelului E-A :
CARDINALITĂȚI : 1,n
 Asocierea 1,n
– Un client comandă mai multe produse.
– Un produs dat este comandat de un singur client.

1,n 1,1
CLIENT Comandă PRODUS
0,n 0,1

– Pot fi clienți care nu au comandat niciun produs


(de exemplu comandă servicii, nu produse)
– Pot exista și produse necomandate (0,1).

28
Diagrama modelului E-A :
Dimensiunea asocierii
 Reprezintă numărul de entități participante la
asociere.
– Observații :
 Numărul de entități participante la asociere nu este
limitat. Totuși, un număr mare de entități participante
indică o analiză superficială și aproximativă.
 O asociere ”reflexivă” este o asociere prin ocurențe între
entitate și ea însăși.

29
Dimensiunea 3 – asociere ternară

 O agenție imobiliară închiriază clienților săi


suprafețe comerciale

CLIENT IMOBIL
NrClient 1,n 1,1 CodImobil
Nume Închiriază Adresă
Adresă Suprafață
……. ……..
1,1
CONTRACT
NrContract
DataContract
30 ……..
Dimensiunea 3 – asociere ternară
 Gestiunea consultaților unei clinici medicale

MEDIC ActMedical
Marcă 1,n 1,1 NrConsultație
Nume Practică DataConsult
Specialitate ……..
…….
1,n
PACIENT
Nr.Card.Sanatate
……..

31
Regulile asocierilor
 Dacă se identifică o ocurență a unei asocieri, atunci va
exista în mod obligatoriu și o ocurență a fiecărei
entități asociere.
 Două ocurențe ale unei entități nu pot participa la
aceeași ocurență a asocierii (decât dacă asocierea
este reflexivă).

32
SUBTIPURI de entități
 Un subtip sau o subentitate este o clasificare a unei
entităţi care are caracteristici comune cu entitatea
generală, precum atribute şi relaţii. .
 Subtipurile se reprezintă ca entităţi în interiorul altei
entităţi.
 Atributele şi relaţiile comune tuturor subtipurilor se vor
reprezenta la nivelul supertipului, sau superentităţii.
Atributele şi relaţiile supertipului vor fi moştenite de
către subtipuri.
 Un subtip poate avea la rândul său alte subtipuri
incluse.
33
SUBTIPURI de entități
Subtipurile trebuie să se
excludă reciproc. 1,n Departament
Conduce
“un angajat nu poate fi, IdDepartament
Este condus de
de exemplu, şi manager şi
secretară în acelaşi timp”. Lucrează ……..

1,1
ANGAJAT Manager
IdAngajat Secretară ……..
CNP …….. bonus
Adresa
DataNasterii
Reprezentant Vanzări
…………..
Zonă vanzări
Bonus vanzari
34
Relații exclusive (obligatorii)
Relaţiile se pot exclude reciproc, adică dintr-un grup de relaţii, la un
moment dat doar una dintre ele poate avea loc.

1,1 1,n Persoana fizică


Detine CNP
……..
Cont
IBAN
DataDeschiderii
SoldCont
Persoana juridică
CUI
Detine ……..
35
Relații exclusive (opționale)
De fiecare dată are loc cel mult una dintre relaţii.

Disciplina
Alege disciplina Facultativă
1
Student
CNP
………..

Disciplina
Facultativă
Alege disciplina n
36
Relații recursive
Fiecare angajat poate fi condus de către un
alt angajat

Condus….
/
Conduce…..
ANGAJAT
CNP
………..

37
Modelarea datelor istorice

ANGAJAT FIRME
CNP A lucrat la
CUI
……….. DataInceput
DataSfarsit
Salariu

38
Reguli asociate proprietăților (I)
 Aceeași proprietate nu poate exista decât asociată unui singur
obiect, fie el entitate, fie asociere.
 O proprietate trebuie să fie ELEMENTARĂ, atomică,
nedecompozabilă.
– Atomică =
 Atunci când proprietatea este constituită dintr-o agregare de proprietăți
elementare;
 Atunci când descompunerea lor nu mai prezintă interes informațional
 Atunci când admite valori repetitive de tip listă;

• O relaţie R este în 1FN dacă toate atributele sale


MCD
conţin numai valori (realizări) atomice
(elementare sau indivizibile);
• O relaţie R este în 1FN dacă conţine valori
nerepetitive. În acest sens, o listă de valori
repetitive trebuie înlocuită cu un singur atribut. MRD
• Atributele descompuse trebuie să fie stabile în
39timp. FN1
Forma Normală 1:

Persoana(CNP, NumePrenume, Domiciliu) nu respectă FN1,


dacă se doreşte dezvoltarea unui sistem informatic în care să
se urmărească evidenţa persoanelor în funcţie de localitate,
stradă etc.

CNP NumePrenume Domiciliu

1621018400230 Ionescu Ion Bucuresti, str. Stefan cel Mare,nr.2


2650305503507 Popescu Mirela Ploiesti, str. Viitorului, nr.4
Forma Normală 1:

Pentru aducerea relaţiei în 1FN atributele compuse


sunt înlocuite cu atribute elementare

Persoana(CNP, Nume, Domiciliu)

Persoana(CNP, Nume, Localitate, AdresaDomiciliu)

Persoana(CNP, Nume, Localitate, Strada, …..)


Forma Normală 1:
 1 FN
– De asemenea, FN1 exclude apariţia atributelor sau
grupurilor de atribute repetitive în cadrul unei relaţii.

De exemplu, relaţia :
Comenzi(NumărComandă, Data, Material1, Material2)
nu respectă FN1, deoarece conţine atribute repetitive.

Numar Data Material1 Material2


Comandă
11 01/01/2008 Ciment Var
12 02/01/2008 Ciment Balastru
13 02/01/2008 Var Nisip
1 - Prof.dr. Bogdan IONESCU
Forma Normală 1:
Pentru aducerea relaţiei în FN1, se parcurg
următoarele etape:
– Pentru grupul de atribute repetitive, se formează o altă
relaţie
– Cheia primară din noua relaţie, va fi în vechea relaţie,
cheie externă.

Materiale (CodMaterial, DenumireMaterial)

Comenzi(NumărComanda, Data, Material1, Material2)

Comandă(NumărComanda, Data, CodMaterial)


1 - Prof.dr. Bogdan IONESCU
Reguli asociate proprietăților (II)

 O proprietate trebuie să depindă în totalitate


(complet) de identificatorul său pentru a evita
redundanța valorilor într-o bază de date.
MCD
FN2
 O relaţie R este în FN2, dacă este în FN1 şi dacă
orice atribut noncheie se află în dependenţă
funcţională completă faţă de cheia primară a
relaţiei.
MRD
 FN2 interzice existenţa dependenţelor funcţionale
parţiale între atributele cu rol de cheie primară şi FN2
celelalte atribute
44 44
Forma Normală 2:

Relaţia PieseComandate(NumărComandă, CodPiesă,


Cantitate, PreţUnitar, DenumirePiesă)
nu se află în FN2 pentru că între (NumărComandă, CodPiesă)
şi DenumirePiesă există o dependenţă parţială:
(NumărComandă, CodPiesă) → DenumirePiesă
CodPiesă → DenumirePiesă

Număr CodPiesă Cantitate Pret Denumire


Comandă Unitar Piesă
1 01 100 20 P1
1 02 150 25 P2
2 01 200 20 P1

1 - Prof.dr. Bogdan
IONESCU
Forma Normală 2:
FN2 : Pentru aducerea relaţiilor din FN1 în FN2, se parcurg
următoarele etape:
 Se identifică eventualele dependenţe funcţionale parţiale
 Fiecare dependenţă funcţională parţială va genera câte o
relaţie nouă. Relaţia nou formată va avea ca structură
atributele participante în dependenţa funcţională parţială.

Piese(CodPiesă, DenumirePiesă, PreţUnitar)

PieseComandate(NumărComandă, CodPiesă,
Cantitate, PreţUnitar, DenumirePiesă)

PieseComandate(NumărComandă, CodPiesă, Cantitate)


1 - Prof.dr. Bogdan
IONESCU
Reguli asociate proprietăților (III)
 O proprietate trebuie să depindă în mod direct de
identificatorul său (fără a trece printr-o altă proprietate)
pentru a împiedica redundanțele și de a permite
actualizarea unei entități care este imbricată într-un
obiect (de tip entitate sau asociere)

FN3
MCD
 O relaţie verifică FN3 dacă se află în
FN2 şi dacă toate atributele noncheie
sunt dependente funcţional netranzitiv
de cheia primară a relaţiei (toate
atributele care nu aparţin cheii primare MRD
să nu depindă funcţional de un alt
47atribut. FN3 47
Forma Normală 3:

De exemplu, relaţia :


Comandă(NumărComandă, Data, CodClient,
DenumireClient) nu respectă FN3, pentru că între
NumărComandă şi DenumireClient există o
dependenţă funcţională tranzitivă:

NumărComandă Data CodClient DenumireClient


1 01/01/2009 01 Ionescu
2 02/01/2009 02 Popescu
3 03/02/2009 02 Popescu

1 - Prof.dr. Bogdan IONESCU


Forma Normală 3:
Pentru aducerea unei relaţii din FN2 în FN3:
 Se identifică eventualele dependenţe funcţionale
tranzitive
 Determinantul noncheie împreună cu atributul sau
atributele determinate funcţional de către acesta, vor
forma o nouă relaţie
 Determinantul noncheie devine cheie primară în relaţia
nou formată şi cheie externă în relaţia iniţială
Client(CodClient, DenumireClient)

Comandă(NumărComandă, Data, CodClient, DenumireClient)

Comandă(NumărComandă, Data, CodClient)


1 - Prof.dr. Bogdan IONESCU
Trecerea de la ”conceptual”, la
”relațional”, prin nivelul ”logic”
– O asociere de dimensiune mai mare ca 2 trebuie
să fie transformată
– O asociere purtătoare de proprietăți nu se poate
implementa ca atare

 NIVELUL LOGIC
– Este o reprezentarea a sistemului, utilă implementării într-o
bază de date pe calculator.
– Nu trebuie confundat modelul conceptual (de exemplu E-A)
cu modelul logic (de exemplu, relațional)
– Nu trebuie confundat modelul logic (de exemplu, relațional),
cu implementarea sa fizică pe calculator (cu un SGBD, de
exemplu Access)
50
Demersul conceperii unei baze de date prin
metoda E-A
1. Identificarea entităților cele mai expresive, naturale
(subiecte, complemente)
2. Identificarea asocierilor între entități (verbe care nu
reprezintă dependențe funcționale.
3. Identificarea atributelor și identificatorilor entităților și
asocierilor (complemente ale verbelor ce exprimă
dependențe funcționale).
4. Identificarea și formalizarea cardinalităților și a
rolurilor (se face distincție între singular și plural)
5. Enumerarea restricțiilor de integritate.

51
Reprezentare
FACTURI PRODUSE
IdFactura 1,n Linie 1,n IdProdus
Factura
Data Factura NumeProdus
NrZileGr Cantitate PretUnitar
……. Discount ……..
Conversie

Reprezentare

Implementare
52
Modele de date: modelul RELAŢIONAL

 Modelul relaţional introdus de Edgar


Codd în 1970 se fundamentează pe
noţiunea matematică de relaţie R(X1,X2,....Xn)
– unde, pentru fiecare element Xi se defineşte un domeniu de
valori
 O relație este o parte finită a unui produs cartezian
între n ansambluri de date (sau de domenii).
 Domeniul reprezintă mulţimea valorilor posibile
care definesc o anumită proprietate aferentă unui
obiect.
 Atributul reprezintă mulţimea valorilor existente în
coloana pe care o desemnează în cadrul relaţiei.
1 - Prof.dr. Bogdan
IONESCU
Modele de date: modelul RELAŢIONAL
 Relaţiilese reprezintă prin tabele care
sunt supuse următoarelor restricţii:
– În fiecare coloană, toate valorile sunt de
acelaşi tip;
– Ordinea liniilor (tuplurilor sau înregistrărilor)
nu este predefinită;
– Nu sunt admise înregistrări duplicate;
– Coloanele sunt identificate prin nume
distincte (atribute sau proprietăţi)
Tuplurile unei relaţii se pot identifica de o manieră unică prin
intermediul valorilor unuia sau mai multor atribute care joacă rol
de CHEIE PRIMARĂ a relaţiei respective. 1 - Prof.dr. Bogdan
IONESCU
Modele de date: modelul RELAŢIONAL
 Se numeşte DOMENIU PRIMAR acel domeniu pe care este definit
un singur atribut drept cheie primară
 CHEIA EXTERNĂ: Fiind două relaţii R1 şi R2, cu atributele A1 şi A2
chei primare definite pe un domeniu primar D, se spune că în relaţia
R1, A2 este cheie externă dacă, utilizând o parte din valorile ei sau
toate, pot fi regăsite tuplurile relaţiei R2
 (altfel spus, un atribut al unei relaţii este cheie externă, dacă se
regăseşte pe post de cheie primară în altă relaţie)

Relaţii

R1(A1,B1,C1,D1,A2) R2(A2,B2,C2,D2)
Cheie externă

Chei primare
1 - Prof.dr. Bogdan
IONESCU
Modele de date: modelul RELAŢIONAL
Relaţii

R1(A1,B1,C1,D1,A2) R2(A2,B2,C2,D2)

Factura Clienţi
Nr_factură
Chei primare Cod_client
Data_factură Nume_client
Data_scadenţă Adresă
Cod_client Localitate

Cheie externă

Factura(Nr.Factura,Data_f,Data_s,Cod client)

Clienti(Cod client,Nume_cl,Adresa,Localitate) 1 - Prof.dr. Bogdan


IONESCU
Modele de date: modelul RELAŢIONAL

 RESTRICŢIILE DE INTEGRITATE depind de


semantica valorilor domeniilor.
– Integritatea entităţii prin care valorile cheii primare trebuie
să fie diferite de zero;
– Integritatea referirii potrivit căreia valorile unei chei externe
trebuie să se refere la tuplurile unei alte relaţii
 ALTE RESTRICŢII care se aplică asupra domeniilor
(validări prin care se reflectă alte corelaţii de ordin
valoric)
 SCHEMA unei relaţii este formată din:
– Numele relaţiei
– Atributele relaţiei
– Restricţiile de integritate 1 - Prof.dr. Bogdan
IONESCU
Reguli de trecere de la MCD, la MRD
 REGULA 1 : Fiecare ENTITATE (în accepție
conceptuală) devine o RELAȚIE în care :
– Proprietățile entității devin atributele relației
– Identificatorul entității devine cheia primară a relației

58
Reguli de trecere de la MCD, la MRD
 REGULA 2 : O asociere de dimensiune 2 cu
cardinalitate 1,1 se rescrie astfel :
se aduce în relația ”fiu” cheia primară a relației
”mamă” (altfel spus, …..
Atributul astfel adăugat se numește cheie externă.
CLIENTI
1,n Emite 1,1 FACTURI
IdClient NrFactura
……. ……..
IdClient
Reguli de trecere de la MCD, la MRD

 REGULA 3 : O asociere de dimensiune 2 cu


cardinalitate de tip ”m-n” se rescrie astfel :
– Se creează o relație nouă ce conține ca atribute de
tip cheie primară identificatorul celor 2 entități
participante la asociere.
– La această cheie primară compusă (concatenată)
a noii relații se adaugă eventualele proprietăți ale
asocierii.

60
Reguli de trecere de la MCD, la MRD
 REGULA 4 : O asociere de dimensiune mai mare ca 2 se
rescrie urmând postularea regulii 3
MEDIC ActMedical
Marcă 1,n 1,1 NrConsultație
Nume Practică DataConsult
Specialitate ……..
…….
1,n
PACIENT
Nr.Card.Sanatate
……..
MEDIC(MarcăMedic, Nume, ...)
ActMedical(NrConsultatie, DataConsultatie, ….)
PACIENT(NrCardSanatate, NumePacient,…..)
PRACTICĂ(MarcăMedic,
61 NrConsultație, NrCardSanatate,
EXEMPLUL ”Editură” prin E-A
Reguli de gestiune:
a. Editura produce mai multe cărţi anual;
b. O carte primeşte un Cod ISBN la fiecare retipărire;
c. Cărţile sunt scrise de către autori. Un autor poate scrie mai multe
cărţi;
d. Clienţii editurii sunt numai persoane juridice;
e. O factură conţine cel puţin o carte şi o carte poate figura pe mai
multe facturi;
f. Preţul de vânzare se stabileşte în momentul producerii unei cărţi,
acesta fiind un preţ orientativ, rămânând neschimbat până la
epuizarea tirajului, preţul efectiv de vânzare fiind negociat cu
fiecare client;
g. Cărţile sunt facturate clienţilor (distribuitorilor en-gross, şi
comercianţilor individuali). Numărul unei facturi şi codul ISBN
sunt unice la nivel naţional;
h. Numele unei persoane juridice este considerat unic la nivel
1 - Prof.dr. Bogdan
naţional. IONESCU
EXEMPLUL ”Editură” prin E-A

CĂRTI(CodISBN, NumeCarte, ...)


AUTORI(CNPAutor, NumeAutor, ….)
CLIENȚI(IdClient, NumeClient,…..)
FACTURI(NrFactura, DataFactura,…..)

CĂRŢI ? AUTORI
Cod ISBN CNP autor
......... .........
?

CLIENŢI FACTURI
IdClient Nr Factură
......... ......... 1 - Prof.dr. Bogdan
IONESCU
EXEMPLUL ”Editură” prin E-A

CLIENȚI(IdClient, NumeClient,……………………………..)

IdClient
FACTURI(NrFactura, DataFactura,………………………..)

CLIENŢI 1,n 1,1 FACTURI


Emite
IdClient Nr Factură
......... .........

1 - Prof.dr. Bogdan
IONESCU
CĂRŢI
Cod ISBN
EXEMPLUL ”Editură” prin E-A
.........
?

FACTURI
Nr Factură
.........

CĂRŢI 1,n Facturare 1,n FACTURI


Cod ISBN
Nr Factură
......... Cantitate .........

ConținutFactură (CodISBN, NrCFactură, Cantitate,….)


1 - Prof.dr. Bogdan
IONESCU
EXEMPLUL ”Editură” prin E-A

CĂRŢI ? AUTORI
Cod ISBN CNP autor
......... .........

CĂRŢI 1,n Autori Cărti 1,n AUTORI


Cod ISBN CNP autor
......... .........

AutoriCarti (CodISBN, CNPAutor)


1 - Prof.dr. Bogdan
IONESCU
AUTORI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare

CNP Number,LI Da Da

Nume prenume Text, 50 Da

Adresa Text, 100 Da

Data nasterii Date/Time Da <=Data curenta

AUTORI-CĂRŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala

CNP Number,LI Da Da

Cod ISBN Text,13,M Da Da

CĂRŢI CONŢINUT
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare FACTURĂ
Cod ISBN Text, 13,M Da Da
........
Denumire carte Text, 50 Da
Cod ISBN
Data aparitiei Date/Time Da <=Data curenta

Stocul tiparit Currency Da >0


........
1 - Prof.dr. Bogdan
Pret baza Currency Da >0 IONESCU
FACTURI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala

Serie factura Text,5,M Da Da

Numar factura Number, LI Da

Cod Fiscal Number , LI Da Da

CONŢINUT FACTURĂ
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Serie factura Text,5,M Da Da Da

Numar factura Number, LI Da Da

Cod ISBN Text, 13,M Da Da

Cantitate fact Number, Int Da >0

Pret factura Currency Da >0

CLIENŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Cod fiscal Number, LI Da Da

Denumire client Text,50 Da Da

Adresa Text,100 Da 1 - Prof.dr. Bogdan


Telefon Text,20 IONESCU
1 - Prof.dr. Bogdan
IONESCU
MRD – Îmbunătățit prin adăugarea de noi reguli de gestiune

APROVIZIONAREA (I)
Editura comandă tirajul fiecărei apariții editoriale ce urmează a fi tipărit
la o tipografie (ce are in acest exemplu calitatea de FURNIZOR).
Aceasta livrează cărți editurii, care atunci când le recepționează
întocmește Nota de Recepție și Constatare de Diferențe (NRCD).
NRCD
FURNIZORI
CodFiscalFz
1,n 1,1 Nr.NRCD
Emite …
..Este emis

FURNIZORI(CodFiscalFz, DenumireFurnizor, Adresa, Localitate, ..)

NRCD(Nr.NRCD, DataAproviz, MijlocTransport, CodFiscalFz)


 APROVIZIONAREA (II)

Pe o Notă de Recepție și Constatare de Diferențe (NRCD) furnizorul


poate livra editurii mai multe cărți.
O carte poate figura pe mai multe Note de Recepție și Constatare de
Diferențe (NRCD)
NRCD
CĂRȚI Nr.NRCD
CodISBN 1,n Aprovizionare cărți 1,n
CantitateIntrată
PretAprovizionare

NRCD(Nr.NRCD, DataAproviz, MijlocTransport, CodFiscalFz)

CARTI_APROVIZIONATE(Nr.NRCD, Cod_ISBN, CantitateIntrata,


PretAprovizionareFaraTVA, PretAprovizionareCuTVA – se calculează in
tabela)

CARTI(Cod_ISBN, ………………………….) 1 - Prof.dr. Bogdan IONESCU


GENURI, COLECTII si DOMENII (I)
Editura are ca obiect de activitate editarea de carti si manuale
universitare. Cărțile editate sunt împărțite pe tipuri sau genuri (manual,
culegere, carte specialitate, etc.). Aceste tipuri sunt utile editurii, la
acreditari si in relațiile cu Biblioteca Națională.

CĂRȚI GENURI
CodISBN 1,1 Aparține genului
1,n CodGenLiterar
literar

GENURI (CodGenLiterar, NumeGenLiterar)


CARTI(Cod_ISBN, ………….., CodGenLiterar)
GENURI, COLECTII si DOMENII (II)
Cartile apartin unor colectii tematice (InfoBD, InfoProg, ContaGen), iar
colectiile apartin unui domeniu științific (sau de interes didactic), cum ar
fi : Analiza economica, Audit, Contabilitate, Informatica, Finante,
Management, Marketing, etc.
CĂRȚI COLECȚII
CodISBN 1,1 Aparține 1,n
colecțiilor CodColecție
Are

1,1
Aparține
domenilor
Are
COLECTII (CodColectie, Nume Colectie, Cod Domeniu )
1,n
DOMENII
DOMENII (Cod Domeniu, Nume Domeniu) CodDomeniu

CARTI(Cod_ISBN, ………….., CodGenLiterar, CodColectie)


COORDONATORI
Cartile pot avea unul sau mai multi coordonatori.
Coordonatorii reprezintă autorii unei aparitii editoriale in raporturile
juridice cu editura. Coordonatorii pot fi sau nu, autori.

CĂRȚI COORDONATORI
CodISBN 0,n Sunt coordonate
1,n CNPCoordonator
Coordonează

COORDONATORI(CNPCoordonator, NumeCoordonator, Adresa,


Localitate, Afiliere, etc)

COORDONATORI_CARTI(Cod_ISBN, CNPCoordonator)

CARTI(Cod_ISBN, ……….)
CONTRIBUTIA AUTORILOR LA OPERA (I)
Cărțile au mai multe capitole si sectiuni. Se defineste o sectiune ca fiind
un interval de pagini ce constituie o contributie cuantificabila a unui
autor. Un capitol poate avea mai multe sectiuni. Un autor poate scrie
intervale de pagini in cadrul unuia sau a mai multe capitole. Numarul de
pagini scrise reprezintă procent din opera si este important pentru
calculul drepturilor de autor.

Problema cuantificarii contributiei ar fi urmatoarea :


a) fiecare autor are o contributie totala intr-o carte sub forma unui
numar total de pagini, care reprezintă procent din opera

AUTORI(CNP Autor, ………………..)

CONTRIBUTIE_AUTORI(Cod_ISBN, CNP Autor, Nr.PaginiContributie)

CARTI(Cod_ISBN, …….)
CONTRIBUTIA AUTORILOR LA OPERA (II)
b) Fiecare autor isi identifică contributia sub forma unui interval de
pagini, fie la nivel de capitol (ar mai interveni inca o tabela si ar fi de
exemplu : cap IV Ionescu pag 45-56; 73-80; Stanciu pag 23-37, etc), fie la
nivel de opera.

AUTORI(CNP Autor, ………………..)


CARTI(Cod_ISBN, ………….)

CAPITOL_CARTE(NrCapitol, NumeCapitol, Pag.Inceput, Pag.Sfarsit,


Cod_ISBN)

SECTIUNI(Cod_Sectiune, Nume_Sectiune, CodISBN / NrCapitol)

SECTIUNI_AUTORI(Cod_Sectiune, Nr.Capitol, Cod_ISBN, CNP Autor,


Pag.Inceput, Pag.Sfarsit)
DREPTURI AUTOR (I)

Fiecare apariție editoriala este purtătoare de drepturi de autor.

Drepturile de autor sunt stabilite in forma procentuala din veniturile


nete inregistrate de carte la vanzarea sa (din pretul de vanzare, numit si
pretul de baza sau catalog se deduce comisionul vanzatorului).

CARTI(Cod_ISBN, ……………………., ProcentDrepturiAutor,……………)


DREPTURI AUTOR (II)
Se abordează problema prin prisma CONTRACTULUI DE EDITARE. Acesta
ar specifica procentul drepturilor de autor si care este coordonatorul
lucrării. Coordonatorul reprezintă autorii intr-un contract de editare.
Rămâne de văzut dacă se face asocierea dintre fiecare carte si fiecare
autor, prin tabela intermediara AUTORI_CARTI sau se abordează aceeași
problemă prin Coordonator(i) carte care ii reprezintă pe autori,
CARTI(Cod_ISBN, ……………………., )
EDIȚIE_CARTE(NrEdiție, Tiraj, DataApariției, Cod_ISBN)

CONTRACT_EDITARE(Nr.ContractEditare, DataContractEditare,
ProcentDrepturiAutor , Cod_ISBN)

COORDONATORI_CARTI(Nr.ContractEditare, CNPCoordonator)

COORDONATORI(CNPCoordonator, NumeCoordonator, …….)


FACTURAREA
Factura este unica la nivel de editura; O factura conține mai multe
cărți livrate, iar o carte figurează pe mai multe facturi; Cota de TVA
este marcata pe factură, deoarece din punctul de vedere al editurii,
conținutul facturii este omogen, adică se vând numai cărți.
Altfel, daca se schimbă regula de gestiune si editura livrează si altceva,
cu cote diferite de TVA, atunci se poate trece cota de TVA pe
CONTINUT FACTURA. Pe fiecare factura se marchează un delegat din
partea editurii.
CLIENTI(CodFiscalClient, Nr_inreg.RC, ………………)
FACTURI(NrFactura, DataFactura, DataScadentei, CodFiscalClient,
CNP_Delegat)
CONTINUT_FACTURA(NrFactura, Cod_ISBN, Cantitate,
Reducere_comerciala, Cota_TVA)
DELEGAT(CNP_Delegat, CI_serie, CI_numar, ………..)
CARTI(Cod_ISBN, …………………………………….)
INCASAREA
Pentru a evidentia platile facute de clienti pentru cartile primite, adica
incasarile editurii, putem aborda următoarea modelare :

CLIENTI(CodFiscalClient, Nr_inreg.RC, …………………)

TIP_DOCUMENT_INCASARE(Id_TipDoc_Incasare, Nume_Doc_Incasare)

INCASARE_CLIENT(Nr.Doc.Incasare, Id_TipDoc.Incasare, CodFiscalClient,


?????DataIncasarii, ?????SumaIncasata)
Iar pentru faptul ca unii clienti platesc partial facturile, se asociază
facturile cu incasarile.

FACTURA_INCASATA(NrFactura, Nr.Doc.Incasare, DataIncasarii,


SumaIncasata)

FACTURI(NrFactura, DataFactura, DataScadentei, …………………..)


Proiectarea unei baze de date pentru
Gestiunea activitatii unei edituri
Exemplu modelare E-A:

1
Reguli de gestiune:
a. Editura produce mai multe cărţi anual;
b. O carte primeşte un Cod ISBN la fiecare retipărire;
c. Cărţile sunt scrise de către autori. Un autor poate scrie mai multe
cărţi;
d. Clienţii editurii sunt numai persoane juridice;
e. O factură conţine cel puţin o carte şi o carte poate figura pe mai
multe facturi;
f. Preţul de vânzare se stabileşte în momentul producerii unei cărţi,
acesta fiind un preţ orientativ, rămânând neschimbat până la
epuizarea tirajului, preţul efectiv de vânzare fiind negociat cu
fiecare client;
g. Cărţile sunt facturate clienţilor (distribuitorilor en-gross, şi
comercianţilor individuali). Numărul unei facturi şi codul ISBN
sunt unice la nivel naţional;
h. Numele unei persoane juridice este considerat unic la nivel
naţional.
1 - Prof.dr. Bogdan
IONESCU
EXEMPLUL ”Editură” prin E-A

CĂRTI( )
AUTORI( )
CLIENȚI( )
FACTURI( )

CĂRŢI ? AUTORI

......... .........
?

CLIENŢI FACTURI

......... ......... 1 - Prof.dr. Bogdan


IONESCU
EXEMPLUL ”Editură” prin E-A

CLIENȚI(…………………………………………………..…..)

FACTURI(……………………………………………………..)

1 - Prof.dr. Bogdan
IONESCU
CĂRŢI
Cod ISBN
EXEMPLUL ”Editură” prin E-A
.........
?

FACTURI
Nr Factură
.........

CĂRŢI FACTURI
Cod ISBN
Nr Factură
.........
.........

_______________ (……………………………………………..)
1 - Prof.dr. Bogdan
IONESCU
EXEMPLUL ”Editură” prin E-A

CĂRŢI ? AUTORI
Cod ISBN CNP autor
......... .........

____________________ (………………………………………..)
1 - Prof.dr. Bogdan
IONESCU
AUTORI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare

CNP Number,LI Da Da

Nume prenume Text, 50 Da

Adresa Text, 100 Da

Data nasterii Date/Time Da <=Data curenta

AUTORI-CĂRŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala

CNP Number,LI Da Da

Cod ISBN Text,13,M Da Da

CĂRŢI CONŢINUT
Nume camp Tip date Obligatoriu Unic Integritate Reguli de
Referentiala validare FACTURĂ
Cod ISBN Text, 13,M Da Da
........
Denumire carte Text, 50 Da
Cod ISBN
Data aparitiei Date/Time Da <=Data curenta

Stocul tiparit Currency Da >0


........
1 - Prof.dr. Bogdan
Pret baza Currency Da >0 IONESCU
FACTURI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala

Serie factura Text,5,M Da Da

Numar factura Number, LI Da

Cod Fiscal Number , LI Da Da

CONŢINUT FACTURĂ
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Serie factura Text,5,M Da Da Da

Numar factura Number, LI Da Da

Cod ISBN Text, 13,M Da Da

Cantitate fact Number, Int Da >0

Pret factura Currency Da >0

CLIENŢI
Nume camp Tip date Obligatoriu Unic Integritate Reguli de validare
Referentiala
Cod fiscal Number, LI Da Da

Denumire client Text,50 Da Da

Adresa Text,100 Da 1 - Prof.dr. Bogdan


Telefon Text,20 IONESCU
1 - Prof.dr. Bogdan
IONESCU
Model imbunătățit prin adăugarea de noi reguli de gestiune

APROVIZIONAREA (I)
Editura comandă tirajul fiecărei apariții editoriale ce urmează a fi tipărit
la o tipografie (ce are in acest exemplu calitatea de FURNIZOR).
Aceasta livrează cărți editurii, care atunci când le recepționează
întocmește Nota de Recepție și Constatare de Diferențe (NRCD).

FURNIZORI(……………………………………………………………………………………...)

NRCD(……………………………………………………………………………………………….)
⚫ APROVIZIONAREA (II)

Pe o Notă de Recepție și Constatare de Diferențe (NRCD) furnizorul


poate livra editurii mai multe cărți.
O carte poate figura pe mai multe Note de Recepție și Constatare de
Diferențe (NRCD)

NRCD(………………………………………………………………………………………………)

_________________(……………………………………………………………………………
……………………………………………………………………………………………………………)

CARTI(……………………………………………………………………………………………….)
1 - Prof.dr. Bogdan IONESCU
GENURI, COLECTII si DOMENII (I)
Editura are ca obiect de activitate editarea de carti si manuale
universitare. Cărțile editate sunt împărțite pe tipuri sau genuri (manual,
culegere, carte specialitate, etc.). Aceste tipuri sunt utile editurii, la
acreditari si in relațiile cu Biblioteca Națională.

GENURI (………………………………………………………………………………………)

CARTI(………………………………………………………………………………………….)
GENURI, COLECTII si DOMENII (II)
Cartile apartin unor colectii tematice (InfoBD, InfoProg, ContaGen), iar
colectiile apartin unui domeniu științific (sau de interes didactic), cum ar
fi : Analiza economica, Audit, Contabilitate, Informatica, Finante,
Management, Marketing, etc.
CĂRȚI
CodISBN

COLECTII (……………………………………………………………………………………….)

DOMENII
(……………………………………………………………………………..…………)
CARTI(Cod_ISBN, ………….., CodGenLiterar, …………………………..…..)
COORDONATORI
Cartile pot avea unul sau mai multi coordonatori.
Coordonatorii reprezintă autorii unei aparitii editoriale in raporturile
juridice cu editura. Coordonatorii pot fi sau nu, autori.

CĂRȚI
CodISBN

COORDONATORI(…………………………………………………………………………)

____________________(………………………………………………………………..)

CARTI(Cod_ISBN, …………………………………………………………………………..)
CONTRIBUTIA AUTORILOR LA OPERA (I)
Cărțile au mai multe capitole si sectiuni. Se defineste o sectiune ca fiind
un interval de pagini ce constituie o contributie cuantificabila a unui
autor. Un capitol poate avea mai multe sectiuni. Un autor poate scrie
intervale de pagini in cadrul unuia sau a mai multe capitole. Numarul de
pagini scrise reprezintă procent din opera si este important pentru
calculul drepturilor de autor.

Problema cuantificarii contributiei ar fi urmatoarea :


a) fiecare autor are o contributie totala intr-o carte sub forma unui
numar total de pagini, care reprezintă procent din opera

AUTORI(CNP Autor, ………………..)

____________________(……………………………………………………………………)

CARTI(Cod_ISBN, …….)
CONTRIBUTIA AUTORILOR LA OPERA (II)
b) Fiecare autor isi identifică contributia sub forma unui interval de
pagini, fie la nivel de capitol (ar mai interveni inca o tabela si ar fi de
exemplu : cap IV Ionescu pag 45-56; 73-80; Stanciu pag 23-37, etc), fie la
nivel de opera.

AUTORI(CNP Autor, ………………..)


CARTI(Cod_ISBN, ………….)

CAPITOL_CARTE(NrCapitol, NumeCapitol, Pag.Inceput, Pag.Sfarsit,


………………………………….)

SECTIUNI(Cod_Sectiune, Nume_Sectiune, ………………………………………….)

_____________________(……………………………………………………………………
…………………………………………….., Pag.Inceput, Pag.Sfarsit)
DREPTURI AUTOR (I)

Fiecare apariție editoriala este purtătoare de drepturi de autor.

Drepturile de autor sunt stabilite in forma procentuala din veniturile


nete inregistrate de carte la vanzarea sa (din pretul de vanzare, numit si
pretul de baza sau catalog se deduce comisionul vanzatorului).

CARTI(Cod_ISBN, ……………………., ProcentDrepturiAutor,……………)


DREPTURI AUTOR (II)
Se abordează problema prin prisma CONTRACTULUI DE EDITARE. Acesta
ar specifica procentul drepturilor de autor si care este coordonatorul
lucrării. Coordonatorul reprezintă autorii intr-un contract de editare.
Rămâne de văzut dacă se face asocierea dintre fiecare carte si fiecare
autor, prin tabela intermediara AUTORI_CARTI sau se abordează aceeași
problemă prin Coordonator(i) carte care ii reprezintă pe autori,
CARTI(Cod_ISBN, ……………………., )
EDITIE(NrEditie……
_________________(…………………………………………, Tiraj, DataApariției,)

CONTRACT_EDITARE(Nr.ContractEditare, DataContractEditare,
ProcentDrepturiAutor , ……………………………..)

______________________(……………………………………………………………..)

COORDONATORI(CNPCoordonator, NumeCoordonator, …….)


FACTURAREA
Factura este unica la nivel de editura; O factura conține mai multe
cărți livrate, iar o carte figurează pe mai multe facturi; Cota de TVA
este marcata pe factură, deoarece din punctul de vedere al editurii,
conținutul facturii este omogen, adică se vând numai cărți.
Altfel, daca se schimbă regula de gestiune si editura livrează si altceva,
cu cote diferite de TVA, atunci se poate trece cota de TVA pe
CONTINUT FACTURA. Pe fiecare factura se marchează un delegat din
partea editurii.
CLIENTI(CodFiscalClient, Nr_inreg.RC, ………………)
FACTURI(NrFactura, DataFactura, DataScadentei, …………………………,
……………………………….)
__________________________(………………………………………….., Cantitate,
Reducere_comerciala, Cota_TVA)
DELEGAT(CNP_Delegat, CI_serie, CI_numar, ………..)
CARTI(Cod_ISBN, …………………………………….)
INCASAREA
Pentru a evidentia platile facute de clienti pentru cartile primite, adica
incasarile editurii, putem aborda următoarea modelare :

CLIENTI(CodFiscalClient, Nr_inreg.RC, …………………)

TIP_DOCUMENT_INCASARE(Id_TipDoc_Incasare, Nume_Doc_Incasare)

INCASARE_CLIENT(Nr.Doc.Incasare, Id_TipDoc.Incasare, CodFiscalClient,


?????DataIncasarii, ?????SumaIncasata)
Iar pentru faptul ca unii clienti platesc partial facturile, se asociază
facturile cu incasarile.

________________________(…………………………………………………..,
DataIncasarii, SumaIncasata)

FACTURI(NrFactura, DataFactura, DataScadentei, …………………..)


Baze de date financiar-bancare

ASISTE NT UNIV. DR. S ÎNZIANA RÎNDAȘ U SINZIANA .R IN DAS U @ C I G .AS E . RO


OBIECTIVE
Dezvoltarea abilităților de a culege, analiza și interpreta date și informații referitoare la problemele
economico-financiare
Formarea abilităților necesare pentru utilizarea bazelor de date din domeniile financiar, bancar,
asigurări și alte domenii conexe
Dezvoltarea competențelor și abilităților necesare pentru normalizarea bazelor de date operaționale
din domeniile financiar, bancar, asigurări și alte domenii conexe
Formarea abilităților pentru utilizarea bazelor de date vizând introducerea datelor, logica aplicațiilor și
raportarea informațională

Evaluare
Nota finală = 70% notă examen+30% notă seminar
Notă seminar = 50% interacțiuni, teme, proiecte și 50% test practic(în ultimele
două săptămâni)
MICROSOFT ACCESS INTRODUCERE
-sistem de gestionare a bazelor de date (SGBD) de la Microsoft;
- combină relaționalul cu o interfață grafică de utilizator și instrumente de dezvoltare software;
-soluție profesională cu automatizare avansată, validare a datelor , captarea erorilor și asistență pentru
mai mulți utilizatori (VBA);
-compatibilitatea relativă cu SQL ( limbaj de interogare structurat ) - cererile pot fi vizualizate grafic
sau editate ca instrucțiuni SQL;
-Folosit pentru crearea de tabele, interogări, formulare și rapoarte,
MICROSOFT ACCESS INTRODUCERE

Bază de
date de
utilizat
pentru
seminar
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS APLICAȚII PRACTICE
1. Crearea unui nou tabel numit Veterinari, care va conține: CNP, nume, prenume, specialitate,
data naștere, număr licență și număr de telefon;
2. Adăugarea de date în tabelul Veterinari;
3. Sortarea datelor din tabelul Pets după specie și rasă;
4. Crearea unui nou tabel numit Proceduri, care va conține codul procedurii, denumirea și
tariful.
Baze de date financiar-bancare

ASISTE NT UNIV. DR. S ÎNZIANA RÎNDAȘ U SINZIANA .R IN DAS U @ C I G .AS E . RO


OBIECTIVE
Dezvoltarea abilităților de a culege, analiza și interpreta date și informații referitoare la problemele
economico-financiare
Formarea abilităților necesare pentru utilizarea bazelor de date din domeniile financiar, bancar,
asigurări și alte domenii conexe
Dezvoltarea competențelor și abilităților necesare pentru normalizarea bazelor de date operaționale
din domeniile financiar, bancar, asigurări și alte domenii conexe
Formarea abilităților pentru utilizarea bazelor de date vizând introducerea datelor, logica aplicațiilor și
raportarea informațională

Evaluare
Nota finală = 70% notă examen+30% notă seminar
Notă seminar = 50% interacțiuni, teme, proiecte și 50% test practic(în ultimele
două săptămâni)
MICROSOFT ACCESS INTRODUCERE
-sistem de gestionare a bazelor de date (SGBD) de la Microsoft;
- combină relaționalul cu o interfață grafică de utilizator și instrumente de dezvoltare software;
-soluție profesională cu automatizare avansată, validare a datelor , captarea erorilor și asistență pentru
mai mulți utilizatori (VBA);
-compatibilitatea relativă cu SQL ( limbaj de interogare structurat ) - cererile pot fi vizualizate grafic
sau editate ca instrucțiuni SQL;
-Folosit pentru crearea de tabele, interogări, formulare și rapoarte,
MICROSOFT ACCESS INTRODUCERE

Bază de
date de
utilizat
pentru
seminar
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS INTRODUCERE
MICROSOFT ACCESS APLICAȚII PRACTICE
1. Crearea unui nou tabel numit Veterinari, care va conține: CNP, nume, prenume, specialitate,
data naștere, număr licență și număr de telefon;
2. Adăugarea de date în tabelul Veterinari;
3. Sortarea datelor din tabelul Pets după specie și rasă;
4. Crearea unui nou tabel numit Proceduri, care va conține codul procedurii, denumirea și
tariful.
Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
Aplicația practică 4
Compania Projects, specializată în domeniul managementul proiectelor, desfășoară activități pentru diferiți clienți persoane juridice.
Compania dorește informatizarea proceselor pentru gestiune proiectelor.
În vederea realizării sistemului informatic de gestiune pentru Project se rețin următoarele informații:
Compania oferă clienților servicii care au la bază contracte încheiate. Pentru clienți se rețin următoarele date: CUI, denumire, persoană de
contact, adresă, email și număr de telefon. Fiecare contract are un număr unic și se rețin informații despre data contractului, iar un contract
poate viza mai multe proiecte. Pentru proiecte se rețin următoarele informații: identificator unic de proiect, domeniul de activitate (producție
sau servicii), statusul (în derulare, finalizat sau achitat).
În cadrul proiectelor lucrează specialiști. Pentru aceștia se rețin următoarele date: CNP, nume complet, adresa și telefon și tariful orar, care
nu poate să fie mai mare de 500 de lei. Se dorește ca pentru fiecare angajat să se rețină nr de ore lucrate în cadrul fiecărui proiect.
Pentru fiecare proiect finalizat departamentul contabil emite o factură care conține următoarele informații: număr factură, data factură și
data scadentă.
Facturile sunt apoi plătite de către clienți și departamentul contabil înregistrează încasările. Încasările se realizează prin transfer bancar și se
rețin următoarele informații: id plată și data plată – o plată este efectuată pentru o singură factură și va acoperi în totalitate valoarea acesteia.

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 5
Federația Ecvestră Internațională (FEI) dorește realizarea unui sistem informatic pentru gestiunea competițiilor.
Sistemul va trebui să ofere informații privitoare la competiții și anume: codul competiei, numele competiției,
organizator, localitate, țara, data de început a competiției, data de sfârșit, taxa de înscriere [5000, 25000].
La o competiție un concurent participă cu un singur cal, dar la competiții diferite poate participa cu orice cal
dorește. Sistemul va trebui să rețină informații despre cai și anume: nume, nr. de identificare, rasă (ripițan, mustang,
andalusian, appaloosa). Pentru fiecare competiție sistemul va reține cu ce cal s-a înscris fiecare concurent. Despre
concurenți sistemul va reține numele, numărul de înregistrare la federația internațională, naționalitatea, data
nașterii. Sistemul va reține și locul ocupat de concurent la fiecare competiție.
Competițiile au sponsori, pentru fiecare dintre aceștia fiind stabilită o sumă pe care o plătesc (sumă ce poate varia
de la sponsor la sponsor și de la competiție la competiție). Pentru sponsori se rețin în sistem informații privind:
numele, cod de identificare, tip (organizație sportivă, companie). Un sponsor poate susține una sau mai multe
competiții cu sume diferite.

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 6
Compania AnaPan activează în domeniul alimentației publice și panificației.
AnaPan realizează o serie de preparate, pentru care sistemul reține codul produsului, denumirea, unitatea de măsură, greutatea și
termenul de valabilitate, exprimat în număr de zile.
Pentru realizarea preparatelor se utilizează materie primă, pentru care este nevoie ca sistemul de gestiune să memoreze codul
materiei prime, denumirea și unitatea de măsură. Materiile prime sunt achiziționate de la furnizorii companiei, pentru care sistemul
va reține codul de înregistrare fiscală, denumirea, telefon și email. Angajații companiei realizează preparatele și pentru angajați vom
reține marca de angajat, nume, prenume, CNP și telefon.
Pentru materiile prime achiziționate de la furnizori se va primi o factură, care va avea un număr și o dată.
Reguli de gestiune:
Un preparat are în compoziție mai multe materii prime, într-o anumită cantitate.
O materie primă poate să fie utilizată pentru mai multe preparate.
De la un furnizor pot fi achiziționate mai multe materii prime.
O materie primă poate fi achiziționată de la mai mulți furnizori.
Un angajat poate realiza mai multe preparate.
Un preparat poate fi realizat de mai mulți angajați.
O factură este primită de la un singur furnizor.
Un furnizor poate emite mai multe facturi, care vor conține unul sau mai multe produse.

DR. SÎNZIANA RÎNDAȘU


Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
TIPURI DE DEPENDENȚE
1. DEPENDENȚE FUNCȚIONALE
CNP  Nume de familie
IMEI  Model telefon
VIN  Model mașină
1.1 Dependență funcțională completă(elementară/totală/deplină)
(NrBon, CodProdus)  Cantitatea
(MarcăStudent, IdMaterie)  NotaExamen
1.2 Dependență funcțională parțială
(IdConsultație, IdMedic)  IdPacient; IdConsultațieIdPacient;
IdMedicIdPacient

DR. SÎNZIANA RÎNDAȘU


TIPURI DE DEPENDENȚE
2. DEPENDENȚE MULTIVALOARE
O companie încheie contracte cu clienții. Un contract poate să vizeze mai multe proiecte, iar toți angajații
companiei lucrează la toate proiectele active.
Astfel numărul contractului determină codurile proiectelor și mărcile angajaților.
NrContract   Marcă Angajat
NrContract   CodProiect
Astfel, dacă există tuplurile (Contract1, Angajat1, Proiect1) și (Contract1, Angajat2, Proiect2) atunci vor
exista și tuplurile (Contract1, Angajat2, Proiect1) și (Contract1, Angajat1, Proiect2)
3. DEPENDENȚE MULTIPLE
IdMedic -->>IdConsultație
IdPacient -->>IdConsultație

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
DR. SÎNZIANA RÎNDAȘU

FN1
dacă toate atributele sale conțin numai valori (realizări) atomice (elementare sau indivizibile);
dacă nu conține grupuri repetitive de atribute;

Departament(CodDepartament, Denumire, NumeAngajat1, Furnizori(Cod furnizor, Nume, Adresă)


PrenumeAngajat1, NumeAngajat2, PrenumeAngajat2...)

Departament(Cod department, Denumire) Furnizori(Cod furnizor, Nume, Țară, Oraș, District, Stradă, ... )
și
Angajat(IdAngajat, Nume, Prenume, CodDepartament)
FORMELE NORMALE
FN2
Dacă respectă FN1
Orice atribut noncheie se află în dependență funcțională completă față de cheia primară a relației.
Interzice existenta dependențelor funcționale parțiale între atributele cu rol de cheie primară şi celelalte
atribute.

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare, DenumireDisciplină, NumeStudent, PrenumeStudent)

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare)


Disciplină( CodDisciplină, DenumireDisciplină)
Student(NrMatricol, NumeStudent, PrenumeStudent)

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
FN3
Dacă respectă FN2
Dacă toate atributele noncheie sunt dependente funcțional netranzitiv de
cheia primară a relației
Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament, DenumireDepartament)

Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament)


și
Departament(CodDepartament, DenumireDepartament)

DR. SÎNZIANA RÎNDAȘU


Formele normale – aplicații
Ce forme normale respectă relațiile de mai jos?

1. Client(CodClient, Nume, Prenume, Domiciliu, Telefon)


2. Produs(CodProdus, DenumireProdus, CodFurnizor, DenumireFurnizor)
3. Rețetar(CodPreparat, CodIngredient, Cantitate, DenumireIngredient)
4. Departament(CodDepartament, DenumireDepartament, CodAngajat) – știind că în cadrul unui departament pot lucra mai mulți angajați.
5. Medicament(CodMedicament, Denumire, PrețVânzare, CodFurnizor)
6. Evaluarea(NrMatricolStudent, CodDisciplină, NotăEvaluare, DenumireDisciplină)
7. Carte(CotăCarte, CodAutor, NrPagini, CodEditură) – un autor poate scrie mai multe cărți, o carte putând fi scrisă de mai mulți autori, fiecare autor
scriind un număr de pagini pentru fiecare carte
8. Factură(NrFactură, DatăFactură, CodClient, NrTelefonClient)
9. BonFiscal(NrBon, DatăBon, CodCasier, DenumireProdus) – știind că prin intermediul unui bon fiscal pot fi vândute mai multe produse.
10. Disciplină(CodDisciplină, DenumireDisciplină, CodProfesor) – știind că o disciplină poate să fie predată de mai mulți profesori.
11. BonConsum(NrBonConsum, CodMaterial, CantitateConsumată)
12. Autovehicul(VIN, ModelAuto, CodProducător, ȚarăProducție) – știind că un producător poate fabrica autovehicule în mai multe țări
13. ContBancar(IBAN, TipCont, DatăDeschidere, CNPTitular)
14. MijlocFix(CodMijlocFix, DatăAchiziție, ValoareIntrare, CodGestiune) – știind că un mijloc fix este încadrat într-o singură gestiune
15. Consultație(IdConsultație, DatăConsultație, CodPacient, CodMedic)

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 1
Compania Depanero realizează reparații pentru electrocasnice.
Clienții companiei sunt persoane fizice, pentru care memorăm CNP, nume, prenume, numărul de telefon și adresa de email.
Clienții aduc în service produse electrocasnice, pentru care depanatorii alocă o etichetă, care va conține un număr unic. Se va
memora și tipul de electrocasnic și modelul.
Reparațiile sunt realizate de către depanatorii companiei, pentru care sistemul va reține marca de angajat, nume, prenume,
numărul de telefon, localitate, județ, strada și numărul.
La finalizarea unei reparații se va emite o factură pentru fiecare produs reparat, care va avea un număr și o dată de emitere, iar la
preluarea produsului clientul va face plata, pentru care se va reține numărul chitanței, data și suma.
Reguli de gestiune
Un produs poate fi reparat de mai mulți depanatori, iar sistemul va memora numărul de ore lucrate de fiecare depanator la
fiecare produs.
Un depanator poate repara mai multe produse.
Un client poate aduce mai multe produse, iar un produs aparține unui singur client
Pentru produs se va emite o singură factură, iar o factură vizează un singur produs.
Un client poate face mai multe plăți, o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 2
Compania Consulting SRL oferă servicii de consultanță fiscală companiilor.
Pentru clienți se va reține CUI, denumire, domeniul de activitate, email, număr de telefon și nume reprezentant.
Clienții încheie contracte pentru activitatea de consultanță, pentru care sistemul memorează numărul contractului și data.
Contractele vizează serviciile de consultanță ale companiei, care sunt prestate de către angajații companiei pentru care se va
reține marcă angajat, CNP, nume complet, adresă și număr de telefon.
Pentru serviciile de consultanță se vor memora codul serviciului, denumirea și tariful orar.
La finalizarea contractului se va emite o factură care va un avea număr unic, dată emitere și termen de plată (exprimat în nr. de
zile), iar clienții realizează plăți pentru care se va memora data plății, identificatorul unic și contul de destinație.
Reguli de gestiune
Un client poate încheia mai multe contracte, un contract aparține unui singur client.
Un contract poate viza mai multe servicii, un serviciu poate fi vizat de mai multe contracte.
La un contract pot lucra mai mulți angajați, un angajat poate lucra la mai multe contracte.
Un angajat poate presta mai multe servicii, un serviciu poate fi prestat de mai mulți angajați.
Pentru un contract se va emite o singură factură, o factură vizează un singur contract.
Un client poate face mai multe plăți și o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.
Sistemul va stoca numărul de ore prestate de fiecare angajat în cadrul fiecărui contract pentru fiecare serviciu.

DR. SÎNZIANA RÎNDAȘU


Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
TIPURI DE DEPENDENȚE
1. DEPENDENȚE FUNCȚIONALE
CNP  Nume de familie
IMEI  Model telefon
VIN  Model mașină
1.1 Dependență funcțională completă(elementară/totală/deplină)
(NrBon, CodProdus)  Cantitatea
(MarcăStudent, IdMaterie)  NotaExamen
1.2 Dependență funcțională parțială
(IdConsultație, IdMedic)  IdPacient; IdConsultațieIdPacient;
IdMedicIdPacient

DR. SÎNZIANA RÎNDAȘU


TIPURI DE DEPENDENȚE
2. DEPENDENȚE MULTIVALOARE
O companie încheie contracte cu clienții. Un contract poate să vizeze mai multe proiecte, iar toți angajații
companiei lucrează la toate proiectele active.
Astfel numărul contractului determină codurile proiectelor și mărcile angajaților.
NrContract   Marcă Angajat
NrContract   CodProiect
Astfel, dacă există tuplurile (Contract1, Angajat1, Proiect1) și (Contract1, Angajat2, Proiect2) atunci vor
exista și tuplurile (Contract1, Angajat2, Proiect1) și (Contract1, Angajat1, Proiect2)
3. DEPENDENȚE MULTIPLE
IdMedic -->>IdConsultație
IdPacient -->>IdConsultație

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
DR. SÎNZIANA RÎNDAȘU

FN1
dacă toate atributele sale conțin numai valori (realizări) atomice (elementare sau indivizibile);
dacă nu conține grupuri repetitive de atribute;

Departament(CodDepartament, Denumire, NumeAngajat1, Furnizori(Cod furnizor, Nume, Adresă)


PrenumeAngajat1, NumeAngajat2, PrenumeAngajat2...)

Departament(Cod department, Denumire) Furnizori(Cod furnizor, Nume, Țară, Oraș, District, Stradă, ... )
și
Angajat(IdAngajat, Nume, Prenume, CodDepartament)
FORMELE NORMALE
FN2
Dacă respectă FN1
Orice atribut noncheie se află în dependență funcțională completă față de cheia primară a relației.
Interzice existenta dependențelor funcționale parțiale între atributele cu rol de cheie primară şi celelalte
atribute.

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare, DenumireDisciplină, NumeStudent, PrenumeStudent)

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare)


Disciplină( CodDisciplină, DenumireDisciplină)
Student(NrMatricol, NumeStudent, PrenumeStudent)

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
FN3
Dacă respectă FN2
Dacă toate atributele noncheie sunt dependente funcțional netranzitiv de
cheia primară a relației
Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament, DenumireDepartament)

Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament)


și
Departament(CodDepartament, DenumireDepartament)

DR. SÎNZIANA RÎNDAȘU


Formele normale – aplicații
Ce forme normale respectă relațiile de mai jos?

1. Client(CodClient, Nume, Prenume, Domiciliu, Telefon)


2. Produs(CodProdus, DenumireProdus, CodFurnizor, DenumireFurnizor)
3. Rețetar(CodPreparat, CodIngredient, Cantitate, DenumireIngredient)
4. Departament(CodDepartament, DenumireDepartament, CodAngajat) – știind că în cadrul unui departament pot lucra mai mulți angajați.
5. Medicament(CodMedicament, Denumire, PrețVânzare, CodFurnizor)
6. Evaluarea(NrMatricolStudent, CodDisciplină, NotăEvaluare, DenumireDisciplină)
7. Carte(CotăCarte, CodAutor, NrPagini, CodEditură) – un autor poate scrie mai multe cărți, o carte putând fi scrisă de mai mulți autori, fiecare autor
scriind un număr de pagini pentru fiecare carte
8. Factură(NrFactură, DatăFactură, CodClient, NrTelefonClient)
9. BonFiscal(NrBon, DatăBon, CodCasier, DenumireProdus) – știind că prin intermediul unui bon fiscal pot fi vândute mai multe produse.
10. Disciplină(CodDisciplină, DenumireDisciplină, CodProfesor) – știind că o disciplină poate să fie predată de mai mulți profesori.
11. BonConsum(NrBonConsum, CodMaterial, CantitateConsumată)
12. Autovehicul(VIN, ModelAuto, CodProducător, ȚarăProducție) – știind că un producător poate fabrica autovehicule în mai multe țări
13. ContBancar(IBAN, TipCont, DatăDeschidere, CNPTitular)
14. MijlocFix(CodMijlocFix, DatăAchiziție, ValoareIntrare, CodGestiune) – știind că un mijloc fix este încadrat într-o singură gestiune
15. Consultație(IdConsultație, DatăConsultație, CodPacient, CodMedic)

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 1
Compania Depanero realizează reparații pentru electrocasnice.
Clienții companiei sunt persoane fizice, pentru care memorăm CNP, nume, prenume, numărul de telefon și adresa de email.
Clienții aduc în service produse electrocasnice, pentru care depanatorii alocă o etichetă, care va conține un număr unic. Se va
memora și tipul de electrocasnic și modelul.
Reparațiile sunt realizate de către depanatorii companiei, pentru care sistemul va reține marca de angajat, nume, prenume,
numărul de telefon, localitate, județ, strada și numărul.
La finalizarea unei reparații se va emite o factură pentru fiecare produs reparat, care va avea un număr și o dată de emitere, iar la
preluarea produsului clientul va face plata, pentru care se va reține numărul chitanței, data și suma.
Reguli de gestiune
Un produs poate fi reparat de mai mulți depanatori, iar sistemul va memora numărul de ore lucrate de fiecare depanator la
fiecare produs.
Un depanator poate repara mai multe produse.
Un client poate aduce mai multe produse, iar un produs aparține unui singur client
Pentru produs se va emite o singură factură, iar o factură vizează un singur produs.
Un client poate face mai multe plăți, o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 2
Compania Consulting SRL oferă servicii de consultanță fiscală companiilor.
Pentru clienți se va reține CUI, denumire, domeniul de activitate, email, număr de telefon și nume reprezentant.
Clienții încheie contracte pentru activitatea de consultanță, pentru care sistemul memorează numărul contractului și data.
Contractele vizează serviciile de consultanță ale companiei, care sunt prestate de către angajații companiei pentru care se va
reține marcă angajat, CNP, nume complet, adresă și număr de telefon.
Pentru serviciile de consultanță se vor memora codul serviciului, denumirea și tariful orar.
La finalizarea contractului se va emite o factură care va un avea număr unic, dată emitere și termen de plată (exprimat în nr. de
zile), iar clienții realizează plăți pentru care se va memora data plății, identificatorul unic și contul de destinație.
Reguli de gestiune
Un client poate încheia mai multe contracte, un contract aparține unui singur client.
Un contract poate viza mai multe servicii, un serviciu poate fi vizat de mai multe contracte.
La un contract pot lucra mai mulți angajați, un angajat poate lucra la mai multe contracte.
Un angajat poate presta mai multe servicii, un serviciu poate fi prestat de mai mulți angajați.
Pentru un contract se va emite o singură factură, o factură vizează un singur contract.
Un client poate face mai multe plăți și o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.
Sistemul va stoca numărul de ore prestate de fiecare angajat în cadrul fiecărui contract pentru fiecare serviciu.

DR. SÎNZIANA RÎNDAȘU


Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
TIPURI DE DEPENDENȚE
1. DEPENDENȚE FUNCȚIONALE
CNP  Nume de familie
IMEI  Model telefon
VIN  Model mașină
1.1 Dependență funcțională completă(elementară/totală/deplină)
(NrBon, CodProdus)  Cantitatea
(MarcăStudent, IdMaterie)  NotaExamen
1.2 Dependență funcțională parțială
(IdConsultație, IdMedic)  IdPacient; IdConsultațieIdPacient;
IdMedicIdPacient

DR. SÎNZIANA RÎNDAȘU


TIPURI DE DEPENDENȚE
2. DEPENDENȚE MULTIVALOARE
O companie încheie contracte cu clienții. Un contract poate să vizeze mai multe proiecte, iar toți angajații
companiei lucrează la toate proiectele active.
Astfel numărul contractului determină codurile proiectelor și mărcile angajaților.
NrContract   Marcă Angajat
NrContract   CodProiect
Astfel, dacă există tuplurile (Contract1, Angajat1, Proiect1) și (Contract1, Angajat2, Proiect2) atunci vor
exista și tuplurile (Contract1, Angajat2, Proiect1) și (Contract1, Angajat1, Proiect2)
3. DEPENDENȚE MULTIPLE
IdMedic -->>IdConsultație
IdPacient -->>IdConsultație

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
DR. SÎNZIANA RÎNDAȘU

FN1
dacă toate atributele sale conțin numai valori (realizări) atomice (elementare sau indivizibile);
dacă nu conține grupuri repetitive de atribute;

Departament(CodDepartament, Denumire, NumeAngajat1, Furnizori(Cod furnizor, Nume, Adresă)


PrenumeAngajat1, NumeAngajat2, PrenumeAngajat2...)

Departament(Cod department, Denumire) Furnizori(Cod furnizor, Nume, Țară, Oraș, District, Stradă, ... )
și
Angajat(IdAngajat, Nume, Prenume, CodDepartament)
FORMELE NORMALE
FN2
Dacă respectă FN1
Orice atribut noncheie se află în dependență funcțională completă față de cheia primară a relației.
Interzice existenta dependențelor funcționale parțiale între atributele cu rol de cheie primară şi celelalte
atribute.

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare, DenumireDisciplină, NumeStudent, PrenumeStudent)

Evaluare(NrMatricol, CodDisciplină, NotăEvaluare)


Disciplină( CodDisciplină, DenumireDisciplină)
Student(NrMatricol, NumeStudent, PrenumeStudent)

DR. SÎNZIANA RÎNDAȘU


FORMELE NORMALE
FN3
Dacă respectă FN2
Dacă toate atributele noncheie sunt dependente funcțional netranzitiv de
cheia primară a relației
Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament, DenumireDepartament)

Angajat(MarcăAngajat, NumeAngajat, PrenumeAngajat, DatăAngajare, CodDepartament)


și
Departament(CodDepartament, DenumireDepartament)

DR. SÎNZIANA RÎNDAȘU


Formele normale – aplicații
Ce forme normale respectă relațiile de mai jos?

1. Client(CodClient, Nume, Prenume, Domiciliu, Telefon)


2. Produs(CodProdus, DenumireProdus, CodFurnizor, DenumireFurnizor)
3. Rețetar(CodPreparat, CodIngredient, Cantitate, DenumireIngredient)
4. Departament(CodDepartament, DenumireDepartament, CodAngajat) – știind că în cadrul unui departament pot lucra mai mulți angajați.
5. Medicament(CodMedicament, Denumire, PrețVânzare, CodFurnizor)
6. Evaluarea(NrMatricolStudent, CodDisciplină, NotăEvaluare, DenumireDisciplină)
7. Carte(CotăCarte, CodAutor, NrPagini, CodEditură) – un autor poate scrie mai multe cărți, o carte putând fi scrisă de mai mulți autori, fiecare autor
scriind un număr de pagini pentru fiecare carte
8. Factură(NrFactură, DatăFactură, CodClient, NrTelefonClient)
9. BonFiscal(NrBon, DatăBon, CodCasier, DenumireProdus) – știind că prin intermediul unui bon fiscal pot fi vândute mai multe produse.
10. Disciplină(CodDisciplină, DenumireDisciplină, CodProfesor) – știind că o disciplină poate să fie predată de mai mulți profesori.
11. BonConsum(NrBonConsum, CodMaterial, CantitateConsumată)
12. Autovehicul(VIN, ModelAuto, CodProducător, ȚarăProducție) – știind că un producător poate fabrica autovehicule în mai multe țări
13. ContBancar(IBAN, TipCont, DatăDeschidere, CNPTitular)
14. MijlocFix(CodMijlocFix, DatăAchiziție, ValoareIntrare, CodGestiune) – știind că un mijloc fix este încadrat într-o singură gestiune
15. Consultație(IdConsultație, DatăConsultație, CodPacient, CodMedic)

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 1
Compania Depanero realizează reparații pentru electrocasnice.
Clienții companiei sunt persoane fizice, pentru care memorăm CNP, nume, prenume, numărul de telefon și adresa de email.
Clienții aduc în service produse electrocasnice, pentru care depanatorii alocă o etichetă, care va conține un număr unic. Se va
memora și tipul de electrocasnic și modelul.
Reparațiile sunt realizate de către depanatorii companiei, pentru care sistemul va reține marca de angajat, nume, prenume,
numărul de telefon, localitate, județ, strada și numărul.
La finalizarea unei reparații se va emite o factură pentru fiecare produs reparat, care va avea un număr și o dată de emitere, iar la
preluarea produsului clientul va face plata, pentru care se va reține numărul chitanței, data și suma.
Reguli de gestiune
Un produs poate fi reparat de mai mulți depanatori, iar sistemul va memora numărul de ore lucrate de fiecare depanator la
fiecare produs.
Un depanator poate repara mai multe produse.
Un client poate aduce mai multe produse, iar un produs aparține unui singur client
Pentru produs se va emite o singură factură, iar o factură vizează un singur produs.
Un client poate face mai multe plăți, o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.

DR. SÎNZIANA RÎNDAȘU


Aplicația practică 2
Compania Consulting SRL oferă servicii de consultanță fiscală companiilor.
Pentru clienți se va reține CUI, denumire, domeniul de activitate, email, număr de telefon și nume reprezentant.
Clienții încheie contracte pentru activitatea de consultanță, pentru care sistemul memorează numărul contractului și data.
Contractele vizează serviciile de consultanță ale companiei, care sunt prestate de către angajații companiei pentru care se va
reține marcă angajat, CNP, nume complet, adresă și număr de telefon.
Pentru serviciile de consultanță se vor memora codul serviciului, denumirea și tariful orar.
La finalizarea contractului se va emite o factură care va un avea număr unic, dată emitere și termen de plată (exprimat în nr. de
zile), iar clienții realizează plăți pentru care se va memora data plății, identificatorul unic și contul de destinație.
Reguli de gestiune
Un client poate încheia mai multe contracte, un contract aparține unui singur client.
Un contract poate viza mai multe servicii, un serviciu poate fi vizat de mai multe contracte.
La un contract pot lucra mai mulți angajați, un angajat poate lucra la mai multe contracte.
Un angajat poate presta mai multe servicii, un serviciu poate fi prestat de mai mulți angajați.
Pentru un contract se va emite o singură factură, o factură vizează un singur contract.
Un client poate face mai multe plăți și o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.
Sistemul va stoca numărul de ore prestate de fiecare angajat în cadrul fiecărui contract pentru fiecare serviciu.

DR. SÎNZIANA RÎNDAȘU


Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
Aplicația practică
Compania Depanero realizează reparații pentru electrocasnice.
Clienții companiei sunt persoane fizice, pentru care memorăm CNP, nume, prenume, numărul de telefon și adresa de email.
Clienții aduc în service produse electrocasnice, pentru care depanatorii alocă o etichetă, care va conține un număr unic. Se va
memora și tipul de electrocasnic și modelul.
Reparațiile sunt realizate de către depanatorii companiei, pentru care sistemul va reține marca de angajat, nume, prenume,
numărul de telefon, localitate, județ, strada și numărul.
La finalizarea unei reparații se va emite o factură pentru fiecare produs reparat, care va avea un număr și o dată de emitere, iar la
preluarea produsului clientul va face plata, pentru care se va reține numărul chitanței, data și suma.
Reguli de gestiune
Un produs poate fi reparat de mai mulți depanatori, iar sistemul va memora numărul de ore lucrate de fiecare depanator la
fiecare produs.
Un depanator poate repara mai multe produse.
Un client poate aduce mai multe produse, iar un produs aparține unui singur client
Pentru produs se va emite o singură factură, iar o factură vizează un singur produs.
Un client poate face mai multe plăți, o plată este făcută de un singur client.
O plată vizează o singură factură și va acoperi în totalitate suma de plată.

DR. SÎNZIANA RÎNDAȘU


Cerințe
1. Să se implementeze în MS Access modelul relațional obținut.
2. Să se realizeze legăturile dintre tabele.
3. Să se definească următoarele restricții de domeniu
◦ Realizările atributului CNP vor avea o lungime fixă și vor conține fix 13 caractere numerice și pot începe
cu 1,2,5 sau 6.
◦ Realizările atributului TipElectrocasnic pot lua doar următoarele valori: aparat frigorific, mașină de
spălat, climatizare.
◦ Realizările atributelor DataEmitereF și DataC nu pot să fie în viitor, dar nici devreme de 01/01/2015.
◦ Realizările atributului NrOreL nu pot fi 0 sau negative.
◦ Realizările atributului Suma vor fi mai mari de 100 de lei.
◦ Realizările atributului AdresăEmail vor respecta formatul adreselor de email.
◦ Realizările atributului NrTelefon vor fi formate din 10 cifre și vor începe cu cifra 0.

DR. SÎNZIANA RÎNDAȘU


Baze de date financiar-bancare

A S I S T E N T U N I V. D R . S Î N Z I A N A R Î N D A Ș U SINZIANA.RINDASU@CIG.ASE.RO
INTEROGĂRI – APLICAȚII
1. Realizați o interogare care să afișeze IdClient, numele complet și oraș.
2. Realizați o interogare care să afișeze codurile animalelor de companie, numele animalelor de companie și
numele posesorilor.
3. Realizați o interogare care să afișeze toate animalele de companie ale clientului Mikhail Wong.
4. Realizați o interogare care să afișeze toate animalele de companie din specia Feline.
5. Realizați o interogare care să afișeze toate animalele de companie ale unui client al cărui cod este introdus de
utilizator.
6. Realizați o interogare care să afișeze toate animalele de companie dintr-o rasă introdusă de utilizator.
7. Realizați o interogare care să afișeze toate datele veterinarilor care au specialitatea “Medicina preventiva”.
8. Realizați o interogare care să afișeze toate datele animalelor de companie al căror nume începe cu “C”.
9. Realizați o interogare care să afișeze vârsta în ani a fiecărui animal de companie.
10. Să se afișeze lista cu toate animalele din specia canine ale căror posesori sunt din București.
11. Să se afișeze lista cu toate animalele din specia feline ale căror posesori sunt din Ploiești.
12. Să se afișeze lista cu toate consultațiile efectuate în primul trimestru al anului 2021, împreună cu numele
veterinarului și al animalului de companie.
13. Realizați o interogare care să extragă numele și prenumele clienților din numele complet.
SGBD Access 2013:
Interogarea
bazelor de date
Exemple de interogari QBE

SELECŢIE;
CALCULE;
ACŢIUNE

Prof.dr. Bogdan Ionescu 1


Prof.dr. Bogdan Ionescu 2
“Se calculeaza perioada de promotie a fiecarei oferte”.

3
Prof.dr. Bogdan Ionescu
“Se aplică o micșorare a tarifului de bază cu 5% pentru serviciile prestate in anul curent, pentru care este înregistrată
o valabilitate de ofertei mai mare de 3 luni”.

4
Prof.dr. Bogdan Ionescu
Se calculează un extradiscount sub forma unei reduceri comerciale acordate în plus, în valoare de 50% pentru o
diferență între Tarif bază și Tarif negociat, mai mare de 3%. Atributul calculat Discount acordat se calculează ca fiind
diferența între Tarif bază şi Tarif negociat.

Prof.dr. Bogdan Ionescu 5


Este calculat un extradiscount de 2%, dacă inițial nu s-a acordat niciun discount, iar dacă acesta a fost acordat într-
un un procent mai mic de 3%, atunci discount-ul este suplimentat la o valoare de 50% din procentul de discount
acordat inițial.

Prof.dr. Bogdan Ionescu 6


Anumite valori nule ale rubricii DataSfarsitValab -dată limită a valabilității ofertei sunt înlocuite cu ultima zi a anului
curent, în cazul în care aceasta data lipsă are ca dată de început a valabilității ofertei anul curent

Prof.dr. Bogdan Ionescu 7


Se afișează clienții care au încheiat contracte care au încheiat contracte in luna ianuarie, 2013 și 2014

Prof.dr. Bogdan Ionescu 8


Se afișează clienții care au încheiat contracte care au încheiat contracte in luna ianuarie, 2013 și 2014

Prof.dr. Bogdan Ionescu 9


Se afișează clienții care au încheiat contracte care au încheiat contracte in luna curentă.

Prof.dr. Bogdan Ionescu 10


Se afișează clienții care au încheiat contracte in trimestrul 2 al anului curent.

Prof.dr. Bogdan Ionescu 11


Se afișează contractele care expiră în weekend.

Prof.dr. Bogdan Ionescu 12


Se afișează ofertele pentru care termenul de valabilitate este mai mare de 3 luni.

Prof.dr. Bogdan Ionescu 13


Se disociaza agregatului Nume Prenume (care a fost în prealabil rezultatul concatenării atributului NumeAng și
PrenumeAng).

Prof.dr. Bogdan Ionescu 14


Se extrage prenumele (unul sau mai multe) din elementul compozit „Nume şi prenume”

Prof.dr. Bogdan Ionescu 15


Se disociază Codul Numeric Personal (CNPAngajat) şi extrage din acesta elementele cu care se formează data
naşterii

Prof.dr. Bogdan Ionescu 16


SGBD Access 2013:
Interogarea
bazelor de date
Exemple de interogari QBE II
GROUP BY
SUB-QUERY
PARAMETERS
CROSSTAB
MAKE TABLE
UPDATE
DELETE
Prof.dr. Bogdan Ionescu 1
Prof.dr. Bogdan Ionescu 2
I. GROUP BY> Calculul veniturilor obtinute din serviciile ofertate clientilor. Gruparea datelor se face după cel mai
puțin cuprinzător element DescriereOfertă din suita de grupare, aplicând funcția de grup SUM la atributul
TarifNegociat.

Ʃ = 233

Prof.dr. Bogdan Ionescu 3


I. GROUP BY> Calculul veniturilor obtinute din serviciile ofertate clientilor. Gruparea datelor se face după cel mai
puțin cuprinzător element DescriereOfertă din suita de grupare, aplicând funcția de grup SUM la atributul
TarifNegociat.

Prof.dr. Bogdan Ionescu 4


I GROUP BY> Gruparea datelor după cel mai puțin cuprinzător element DescriereOfertă din suita de grupare,
aplicând funcția de grup SUM la atributul TarifNegociat.

Gruparea datelor pe
clienți pentru fiecare
ofertă în parte. Ʃ = 233

Prof.dr. Bogdan Ionescu 5


II GROUP BY> Gruparea datelor după DenumireClient.

Prof.dr. Bogdan Ionescu 6


III. GROUP BY> Calcularea sumelor încasate pe ani.

Prof.dr. Bogdan Ionescu 7


IV. SUBINTEROGARE> Afișarea clienților care au încheiat contracte cu valori peste medie.

Prof.dr. Bogdan Ionescu 8


IV. SUBINTEROGARE > Afișarea clienților care au încheiat contracte cu valori peste medie.

Prof.dr. Bogdan Ionescu 9


V. PARAMETERS > Afișarea clientilor care au incheiat contracte pentru care tariful negociat se situeaza intre 2 borne

Prof.dr. Bogdan Ionescu 10


VI. CROSSTAB > Afișarea clientilor care au incheiat contracte pentru care tariful negociat se situeaza intre 2 borne.

Prof.dr. Bogdan Ionescu 11


VI. CROSSTAB > Se calculeaza pentru fiecare an și lună în parte valoarea contractelor încheiate de angajați.

Prof.dr. Bogdan Ionescu 12


VII. Make Table> Se stochează într-o nouă tabelă contractele derulate pe cel puțin 3 luni, încheiate de angajații
Adochitei si Ionescu, în ultimii 3 ani”

Prof.dr. Bogdan Ionescu 13


VIII. UPDATE> Se prelungeste data valabilității ofertei cu 5 săptămâni pentru anul 2014S

Prof.dr. Bogdan Ionescu 14


VIII. UPDATE> Se prelungeste data valabilității ofertei cu 5 săptămâni pentru anul 2014S

Prof.dr. Bogdan Ionescu 15


IX. DELETE > Anularea din tabela Oferta a serviciilor ofertate clienților în anul 2013

Prof.dr. Bogdan Ionescu 16

S-ar putea să vă placă și