Baze de Date

1.
BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE1

1.1 Metode de organizare a datelor
1.1.1 Organizarea datelor în fișiere de date
Un fișier de date reprezintă un ansamblu de înregistrări fizice omogene din punct de vedere al naturii,
conținutului și criteriilor de prelucrare.
Organizarea datelor în fișiere de date prezintă următoarele caracteristici:
- este specifică anilor 1960 -1970 și este utilizată în cadrul limbajelor de programare Cobol, Pascal, Basic etc.;
- descrierea datelor este realizată în cadrul programelor;
- lipsa unor facilități în corelarea datelor din mai multe fișiere;
- inexistența unor formalisme pentru descriere și validarea datelor;
Materiale.dat Materiale.cbl
101 Ciment Kg 10000 ...
102 Var Kg 15000 Cod 9(3)
Denumire X(6)
UM X(3)
Pret 9(5)
1 – adaptare dupa Gabriel Cozgarea - Baze de date. Microsoft ACCESS, Editura ASE, Bucuresti, 2018
Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 1
1.1.2 Organizarea datelor în baze de date
O bază de date reprezintă un ansamblu structurat de date corelate logic, accesibile prin intermediul
calculatorului electronic de unul sau mai mulți utilizatori simultan în timp real.
Organizarea datelor în baze de date prezintă următoarele caracteristici:

- asigură independența datelor de programe;
- o bază de date conține atât datele, cât și descrierile acestora;
- asigură coerența datelor;
- existența unor formalisme riguroase pentru descrierea și validare datelor (modelul Entitate-Asociere, Merise,
UML etc.);
- performanțe ridicate în procesarea datelor;
- reducerea la minim a redundanțelor;
- viziune unitară și globală asupra colecțiilor de date.

1.2 Niveluri de reprezentare a bazelor de date
În vederea asigurării unei separări logice a datelor față de

programe, s-a recurs, conform arhitecturii ANSI/SPARC[1], la
Nivelul
reprezentarea bazelor de date pe trei niveluri diferite: extern
Schema Schema Schema
externă 1 externă 2 … externă n
- Nivelul extern ‒ redă subsetul de date vizibil de către fiecare
utilizator (schema externă).
- Nivelul conceptual ‒ conține o sinteză a schemelor descrise Nivelul
Schema conceptuală
conceptual
în nivelul extern (schema conceptuală).
- Nivelul intern (fizic) ‒ descrie modul în care schema
conceptuală se regăsește pe suportul tehnic de date (schema Nivelul
intern Schema internă
internă).
Arhitectura ANSI/SPARC a bazelor de date
Urmând logica nivelelor introduse de ANSI/SPARC, rezultă că, pentru o bază de date se pot defini:
✓ mai multe scheme externe;
✓ o singură schemă conceptuală;
✓ o singură schemă internă.
[1] ANSI/SPARC ‒ American National Standards Institute, Standards Planning And Requirements Committee.

1.2.1 Modele conceptuale de reprezentare a datelor
• Modelul ierarhic descrie schema conceptuală a bazei de date sub forma unui graf arborescent (cu un singur nod
rădăcină) în care nodurile reprezintă colecții de date, iar legăturile dintre acestea trebuie să fie de tipul 1÷N (unu
la mai mulți) sau 1÷1 (unu la unu).
• Modelul rețea reprezintă o extensie a modelului ierarhic și descrie schema conceptuală prin intermediul unei
rețele. În modelul rețea, spre deosebire de cel ierarhic, un nod copil poate avea mai mulți părinți. Cu alte cuvinte,
modelul rețea permite realizarea unei legături de tip M÷N (mulți la mai mulți).
• Modelul relațional este fondat pe teoria matematică a relațiilor și pe calculul relațional. Acest model descrie
schema conceptuală cu ajutorul noțiunii de relație. O relație are mai multe coloane (numite atribute) și mai multe
linii (numite tupluri). Facturi
NumărFactura Data CodFurnizor

1010 05-01-2018 4050
1020 01-02-2020 4010
Furnizori
CodFurnizor Denumire Adresa

4010 S.C. Alfa Bucuresti
4020 S.C. Beta Sibiu
4050 S.C. Gama Brasov

• Modelul orientat pe obiecte descrie schema conceptuală cu ajutorul obiectelor care conțin atât datele, cât și
prelucrările asociate acestora. Un obiect reprezintă o abstractizare a unei entități din lumea reală.
Factura 128
125
+ NumărFactură : Long 121 AB03
+ Serie: String Date AB02
AB01 02/02/2020
+ Data : Date 01/02/2020
+ Explicatii: String 01/01/2020 Cumpărare mijloace
Primire materiale
+ValoareFactură(): Double Primire mărfuri fixe
+ValoareTVA(): Double Operaţii ...
...
+TotalFactură(): Double ...
Clasa Factură Obiecte Factură
• Modelul obiect relațional reprezintă o extensie a modelului relațional și îmbină facilitățile acestuia cu cele ale
modelului orientat pe obiecte.

1.2.2 Nivelul fizic al bazei de date
În cadrul acestui nivel este descrisă structura în care datele se
regăsesc pe suporturile tehnice de date. Datele stocate pe un suport 001.100.10 CodFurnizor Denumire Localitate 001.251.33 01 Alfa S.A. București
tehnic pot fi reprezentate sub formă de înregistrări logice, fiecare

Adrese fizice
Înregistrări logice
înregistrare fiind identificată printr-o adresă fizică (locaţie), având (cilindru, pistă, sector)
în componență mai multe câmpuri (caracteristici). O adresă fizică Reprezentarea datelor pe suportul tehnic de date
este formată din cilindru, pistă și sector.
Pentru accesarea datelor stocate pe suporturile tehnice de date există următoarele metode:
•Metoda secvențială – presupune parcurgerea tuturor înregistrărilor logice începând cu prima înregistrare, până la
înregistrarea care conține valoarea căutată (dacă există) sau până la ultima înregistrare (dacă valoarea căutată nu
există).
•Metoda indexată – se bazează pe căutări într-un tabel de indecși, folosind algoritmi pentru căutări în mulțimi
ordonate. Această metodă permite regăsirea mult mai rapidă a unei informații, decât metoda secvențială.

Pentru fiecare câmp pentru care se realizează indexarea, Suportul tehnic de date
sistemul va asocia câte un tabel cu indecși. În general, un tabel de …01 Alfa S.A. București 001.251.33…
…03 Gama S.A. Brașov 001.253.10…
indecși este format din două câmpuri ce vor conține: …02 Beta S.A. Timișoara 001.258.22…
• realizările ordonate, crescător sau descrescător, aferente Tabela cu indecși

Realizări Adrese fizice
câmpului indexat; 01 001.251.33
• adresele fizice aferente înregistrărilor care conțin realizările 02 001.258.22
03 001.253.10
câmpului indexat.
1.3 Sisteme de gestiune a bazelor de date

Un sistem de gestiune a bazelor de date (SGBD) reprezintă un pachet de programe care asigură gestiunea
bazelor de date. În funcție de modelele conceptuale de reprezentare a datelor utilizate, SGBD-urile pot fi: ierarhice,
rețea, relaționale, orientate obiect și obiect relațional.
Principalele funcții ale unui SGBD sunt următoarele:
• Descrierea datelor. SGBD-ul trebuie să includă o componentă pentru fiecare dintre diversele limbaje de descriere
a datelor (Limbaj pentru Descrierea Datelor – LDD).

• Manipularea datelor. Orice SGBD trebuie să dețină o componentă care să interpreteze și să trateze limbajul de
manipulare a datelor (LMD).
• Coerența datelor.
• Securitatea datelor.
• Partajarea datelor și accesul concurent la baza de date.
• Repararea bazei de date, salvarea și restaurarea datelor în cazul întreruperilor neprevăzute ale sistemului.
Limbajele de manipulare a datelor pot fi:
- declarative, care permit utilizatorului să declare de ce informații
are nevoie;
- procedurale, care obligă utilizatorul să descrie procedurile sau funcțiile pentru obținerea informațiilor
necesare.

2. MODELUL RELAŢIONAL2
2.1. Structura unei relaţii (tabel)
Conform modelului relațional, o relație este caracterizată prin următoarele concepte:
✓ Atributul – reprezintă o coloană a relației ce are un nume unic în cadrul acesteia. Numărul de atribute din cadrul unei
relații formează gradul acesteia.
✓ Tuplul – reprezintă o linie din cadrul relației. Ordinea tuplurilor din cadrul unei relații este nesemnificativă, iar
numărul acestora definește cardinalitatea relației.
✓ Valoarea – se referă la o realizare a unui atribut. O valoare a unui atribut poate fi și nulă (specifică absența unei
valori). Un tuplu este format din succesiunea de valori aferente atributelor relației.
✓ Domeniul – reprezintă mulțimea valorilor posibile pe care le poate primi un atribut. O valoare a unui atribut trebuie
să aparțină domeniului definit.
Orice relație deține următoarele proprietăți:
✓ Să fie normalizată.
✓ Atributele nu sunt ordonate de la stânga la dreapta.
✓ Tuplurile nu sunt ordonate.
✓ Nu există tupluri duplicat.
Anumite atribute ale unei relații pot avea un rol mai aparte, atât la nivelul intern (al relației), cât și la nivelul
întregului model. Aceste atribute „speciale” se mai numesc și chei și sunt grupate în următoarele categorii:
✓ Cheile candidate se referă la acele atribute sau grupuri de atribute care îndeplinesc următoarele condiții:
▪ Unicitate – într-o relație nu există două tupluri distincte cu aceeași valoare a cheii. Cu alte cuvinte, cheia
candidată are valori unice și, din acest motiv, permite identificarea tuplurilor din cadrul relației.
▪ Ireductibilitate – niciun atribut component al cheii nu are proprietatea de unicitate.
▪ Nenule – valorile primite de atributul sau atributele care formează cheia candidată trebuie să fie nenule.
Această constrângere mai poartă denumirea de restricție a entității.
Fiecare relație definită în cadrul modelului relațional deține cel puțin o cheie candidată.
✓ Cheia primară. Orice relație a modelului relațional trebuie să dețină o cheie primară. Aceasta se alege dintre
cheile candidate identificate în cadrul relației, în funcție de tipurile de date aferente și lungimea acestora, de
constanța lor în timp etc. În diagrame, cheile primare pot fi subliniate cu o linie continuă, prefixate cu caracterul
diez sau scrise cu caractere aldine.
De exemplu, fie cheile candidate CodFurnizor și DenumireFurnizor. Cheia primară va fi CodFurnizor,
deoarece acest atribut are lungimea mai mică, astfel încât regăsirea informațiilor se va realiza într-un timp mai
scurt.
✓ Chei alternative. Cheile candidate rămase după alegerea cheii primare, dacă există, sunt numite chei alternative.
✓ Chei externe reprezintă un atribut sau un grup de atribute cu rol de cheie primară într-o altă relație aflată în
legătură cu relația inițială. În cadrul diagramelor, cheile externe pot fi subliniate cu o linie întreruptă sau scrise cu
caractere cursive.
Exemplu:
1. Reprezentarea minimală a M.R.: FURNIZOR(CodFurnizor, Denumire, Localitate)
FACTURA(Serie, NrFactura, Data, CodFz)
2. Reprezentarea maximală a M.R.:
Factura cheie externă
Serie NumarFactura Data CodFz
cheie primară
AAA01 1 1-10-2018 4012
AAA02 2 2-10-2020 4013
domeniu realizare Furnizori

CodFz Denumire Localitate
4011 S.C. Alfa S.A. Sibiu
cheie primară 4012 S.C. BETA S.A. Sibiu
4013 S.C. GAMA S.A. Fagaras
Înregistrare/tuplu
În urma implementării modelului relațional într-un SGBD, se vor folosi termenii de tabel, câmp și înregistrare,
asociați relației, atributului și respectiv tuplului.
2.2 Legături între tabele

Legăturile dintre relații sunt asocieri logice care asigură coerența datelor și obținerea informațiilor compuse din
două sau mai multe relații.
Prin intermediul cheii externe și a cheii primare corespondente se realizează legătura dintre două relații. În cadrul
unei legături, cele două relații se vor numi diferit:
− relația (tabela) principală sau părinte este relația în care atributul comun are rol de cheie primară;
− relația (tabela) secundară sau copil este relația în care atributul comun are rol de cheie externă.
Integritatea referenţială definește condițiile cerute pentru realizarea și menținerea unei legături între două relații.
Pentru a se asigura integritatea referenţială, cheia externă trebuie să accepte numai realizările cheii primare
corespondente.

Exemplu:
1. Legătură între două tabele fără respectarea integrităţii referenţiale.
Factura
AAA01 1 1-10-2018 4012 Tuplu orfan
AAA02 2 2-10-2020 4014
Furnizori
4012 S.C. BETA S.A. Sibiu
2. Legătură între două tabele cu respectarea integrităţii referenţiale.
Factura
AAA01 1 1-10-2018 4012
AAA02 2 2-10-2020 4013
Furnizori
4012 S.C. BETA S.A. Sibiu
Legături între tabele:
a) 11 - oricărui tuplu din relația principală îi corespunde cel mult un tuplu din relația secundară, iar unui tuplu din
relația copil îi corespunde un singur tuplu din relația părinte.
Cerere (Numar, Data, CodClient)
11
Contract (Numar, Data, Valoare, NrCerere)

b) 1n - unui tuplu din relația principală îi corespund mai multe tupluri din relația secundară, iar unui tuplu din
relația copil îi corespunde un singur tuplu din relația părinte.
Furnizor (CodFurnizor, Denumire, Adresa)

1n
Factură (Serie, NrFactură, Data, CodFurnizor)
Legăturile de tip m ÷ n (mulți la mulți) pot fi realizate, în cadrul unui SGBD, numai indirect, prin intermediul unei
alte relații, pornind de la ideea că orice legătură de tip m ÷ n se va descompune în două legături de tip 1 ÷ n.

Factură(Serie, NrFactura, Data, CodFurnizor) mn
Material(CodMaterial, Denumire, UM)
MaterialFacturat(Id, SerieNrFactură, CodMaterial)

2.3 Algebra relaţională1
Algebra relațională reprezintă o colecție de operatori care acționează asupra unor relații în vederea obținerii
altor relații. Operatorii relaționali pot fi grupați în două categorii:
• Operatori generali cu mulțimi: reuniunea, intersecția, diferența și produsul cartezian;
• Operatori relaționali specifici: selecția, proiecția, compunerea și diviziunea.
a)Operatorii generali cu mulțimi:

❖Reuniunea a două relații R1 și R2, care au aceeași structură, reprezintă o relație R3 ce conține toate tuplurile din
R1 și R2. Prin reuniune sunt eliminate tuplurile duplicate. Gradul relației R3 va fi egal cu cel al relației R1 și,
respectiv, al relației R2.
R1  R2 = R3{t | tR1  tR2}
❖Intersecția a două relații R1 și R2, cu aceeași structură, reprezintă o relație R3 ce conține acele tupluri care sunt
prezente atât în R1, cât și în R2. Gradul relației R3 este egal cu cel al relațiilor R1 și R2.
R1  R2 = R3{t | tR1  tR2}
❖Diferența dintre relațiile R1 și R2, care au aceeași structură, reprezintă o relație R3, ce conține toate tuplurile care
apar în R1, dar nu și în R2. Relația R3 va avea același grad cu cel al relațiilor inițiale.
R1 - R2 = R3{t | t R1  tR2}
❖ Produsul cartezian a două relații R1 și R2 reprezintă o relație R3 ce va conține toate combinațiile posibile,
realizate între tuplurile celor două relații. Gradul relației R3 este format din gradul relației R1 plus gradul relației
R2.
Disciplina (R1)
Cod Denumire
R3=Disciplină x Student
PSI Proiectarea SI
Cod Denumire Marca Nume
TAO Tehnologia aplicatiilor
Office PSI Proiectarea SI 01 Ionescu
Student (R2) PSI Proiectarea SI 02 Popescu
Marca Nume
TAO Tehnologia aplicatiilor 01 Ionescu
01 Ionescu Office
TAO Tehnologia aplicatiilor 02 Popescu
02 Popescu Office

b) Operatori specifici:
❖ Selecția aplicată asupra relației R1 cu n tupluri, are ca rezultat o relație R2, cu aceeași structură, dar cu m tupluri
(m<=n) care îndeplinesc o anumită condiție. În cadrul condiției se pot utiliza operatori logici (AND, OR, NOT),
operatori de atribuire și comparare (<>, >, <, =, >=, <=), operatori aritmetici (+, -, *, /), precum și alți operatori (Is,
Like, In etc.).
Factura
Serie Numar Data CodFurnizor
AB01 01 01.01.2018 1011 Selecţia furnizorilor cu sediul în Bucureşti

AB02 02 02.01.2018 1012  relaţia (Furnizori-S)
Furnizor
Cod Denumire Localitate Furnizori-S=Select Localitate=Bucuresti (Furnizor)
1011 S.C. Alfa Bucuresti CodFz Denumire Localitate
1012 S.C. Beta Bucuresti 1011 S.C. Alfa Bucuresti
1013 S.C. Gama Brasov 1012 S.C. Beta Bucuresti

❖ Proiecția unei relații R1 cu gradul n, o constituie o relație R2, cu Furnizor-P=  Denumire, Localitate (Furnizor)
gradul m (m<n). Relația R2 va conține tuplurile lui R1 din care sunt Denumire Localitate
eliminate valorile atributelor care nu apar în R2, precum și tuplurile
S.C. Alfa Bucuresti
duplicate.
S.C. Beta Bucuresti
Proiecţia furnizorilor pe atributele Denumire, Localitate  (Furnizor-P): S.C. Gama Brasov
❖ Compunerea.
Fie relațiile R1 și R2 care satisfac cerințele produsului cartezian (nu au un atribut sau un grup de atribute comun).
Compunerea relațiilor R1 (după atributul A) și R2 (după atributul B) generează o relație nouă cu următorul conținut:
R1 JOIN A  B R2= (R1 x R2) Where A  B
Altfel spus, relația obținută prin compunere va conține acele tupluri, care aparțin produsului cartezian al celor două
relații, pentru care condiția de compunere A  B este îndeplinită.
În funcție de tipul operatorului , compunerea se numește:
✓ Echicompunere, dacă  este operatorul „=”. În acest caz, în relația rezultată vor fi prezente două atribute (sau
grupuri de atribute) ale căror valori vor fi egale în fiecare tuplu. Dacă respectivele atributele (sau grupuri de
atribute) au aceeași denumire și sunt de același tip, compunerea se numește naturală.
✓  - compunere, dacă  este un operator diferit de egalitate (>, <. <>, <=, >=).

Echicompunerea tabelelor Furnizor JOIN Cod=CodFurnizor Factura
Factura si Furnizor:
Serie Numar Data CodFurnizor Cod Denumire Localitate
AB01 01 01.01.2018 1011 1011 S.C. ALFA Bucuresti
AB02 02 02.01.2018 1012 1012 S.C. BETA Bucuresti
➢ Compunerea externă (OUTER JOIN) dintre relațiile R1 și R2 are ca rezultat o relație R3 ce va conține atât
tuplurile produsului cartezian dintre cele două relații sursă care îndeplinesc condiția de compunere, cât și
tuplurile fără corespondent din R1 și R2.
În funcție de relația din care sunt preluate toate tuplurile (cu sau fără corespondențe), compunerea externă poate
fi de două tipuri:
- La stânga (LEFT JOIN) – relația R3 va conține toate tuplurile din R1 și acele tupluri din R2 care îndeplinesc
condiția de compunere;
- La dreapta (RIGHT JOIN) – relația R3 va deține toate tuplurile din R2 și acele tupluri din R1 care
îndeplinesc condiția de compunere.

➢ LEFT JOIN
Furnizor LEFT JOIN Cod=CodFurnizor Factura
NULL NULL NULL NULL 1013 S.C. GAMA Brasov
➢ RIGHT JOIN
Furnizor RIGHT JOIN Cod=CodFurnizor Factura


❖ Diviziunea presupune împărțirea unei relații R1 de grad m + n, denumită deîmpărțit, la o relație R2 de grad m,
denumită împărțitor, rezultatul fiind o relație R3 de grad n, numită cât, ce conține toate tuplurile care concatenate
cu fiecare tuplu din R2 va returna un tuplu din R1. Produsul cartezian al relațiilor R3 și R2 trebuie să fie un subset
al tuplurilor deținute de relația R1.
Marfă-Factură
Serie Număr Data CodMarfă
Diviziunea tabelei Marfă-Factură cu tabela Factură
A1 1 1/1/2017 M1  tabela Marfă
A1 1 1/1/2017 M2
Marfă
A2 2 2/1/2017 M1 CodMarfă
A2 2 2/1/2017 M2 M1
A2 2 2/1/2017 M3 M2
Factură
Serie Număr Data
A1 1 1/1/2017
A2 2 2/1/2017

3. CONCEPEREA BAZELOR DE DATE RELAŢIONALE1
3.1. Metode de proiectare a bazelor de date relaţionale
Scopul procesului de normalizare este obținerea unei baze de date care să respecte cerințele definite de către
utilizator și să fie formată din relații ce nu conțin redundanțe sau anomalii la actualizare.
Conceperea modelului relațional se poate realiza prin următoarele variante:

a) Prin intermediul unui model conceptual semantic, cum ar fi modelul Entitate-Asociere (Entity-
Relationship) sau derivate ale acestuia: modelele statice din metodologiile OMT (Object Modeling
Technique), OOD (Object Oriented Design), diagrama claselor din UML (Limbajul Unificat de
Modelare) etc.
b) Prin procesul de normalizare.
3.2. Dependenţe
Dependențele reprezintă legături logice ce se pot stabili între atribute și au o importanță crucială în procesul de
normalizare a bazelor de date.
3.2.1. Dependenţele funcţionale

Fie R o relație, iar X și Y submulțimi arbitrare ale mulțimii atributelor lui R. Spunem că Y este dependent funcțional
de X (se scrie X→Y și se citește „X determină funcțional pe Y”) dacă și numai dacă fiecărei valori a lui X îi
corespunde o singură valoare pentru Y.
Exemple: CodFurnizor → DenumireFurnizor

CodMaterial → DenumireMaterial
➢ Se numește dependență funcțională completă, o dependenţă funcțională de forma X → Y, în care Y este dependent
funcțional de X, fără să fie dependent funcțional de niciuna din componentele lui X. Dependența funcțională
completă mai este numită, în literatura de specialitate, dependenţă funcțională elementară, totală sau deplină.
Exemplu: (NumărComandă, CodProdus) → Cantitate
NumărComandă→Cantitate
CodProdus→Cantitate

➢ O dependenţă funcțională (X → Y) este parțială dacă și numai dacă Y este dependent funcțional atât de X, cât și de
o componentă a lui X.
(NumărComandă, CodProdus) → CodClient

NumărComandă → CodClient
CodProdus → CodClient
Proprietăţi ale dependenţelor funcţionale:

• Reflexivitate: X → X Exemplu: CodClient → CodClient
•Tranzitivitate: Dacă X → Y şi Y → Z, atunci X → Z

Exemplu: NrFactura → CodFz, CodFz → DenumireFz, NrFactura → DenumireFz
3.2.2. Dependenţe multivaloare: A → → B

Fie relația R și X, Y, Z submulțimi ale atributelor lui R. Spunem că Y este multidependent față de X (X →→ Y) dacă
și numai dacă mulțimea de valori Y care corespunde unei perechi de valori XZ depinde numai de valoarea X și este
independentă de valoarea Z.

Exemplu:
Fie R1{CodSectie, NumarInventarMijlocFix, MarcaAngajat}
CodSectie → → NumarInventarMijlocFix
CodSectie → → MarcaSalariat
Daca exista tulurile (Sectia1, MijFix1, 001) si (Sectia1, MijFix2, 002),

atunci exista si tuplurile (Sectia1, MijFix1, 002) si (Sectia1, MijFix2, 001).
Alte tipuri de dependențe:
1. Dependențe simple (unice): un atribut A determina atributul B (A→B) atunci când o realizare a lui A determina o
singura realizare a lui B.
Exemplu: MarcaAngajat → DenumireAngajat
2. Dependența multiplă: exista o dependenta multipla de la A la B (A ―»B) atunci când o realizare a lui A determina
mai multe realizari ale lui B.
Exemple: NumărComandă―» CodProdus; DataComandă ―» NumărComandă

3.3. Forme normale
Formele normale sunt reguli, restricții care trebuie respectate pentru eliminarea redundanței și anomaliilor ce pot
apărea în cadrul relațiilor unui model relațional.
Exemplu:
Serie Număr DataFactura CodFurnizor Denumire Adresa
Factura Factura
AB01 01 01-01-2020 1011 S.C. ALFA Bucureşti
AB02 02 20-02-2020 1012 S.C. BETA Brasov
AB03 03 21-02-2020 1012 S.C. BETA Brasov
O relație care nu a fost supusă procesului de normalizare poate prezenta următoarele proprietăți nedorite:
a) redundanţă
b) anomalii la adăugare
c) anomalii la modificare
d) anomalii la ştergere

FN1:
O relație verifică prima formă normală (FN1) dacă și numai dacă fiecare tuplu conține exact o valoare pentru fiecare
atribut.
Exemple:
1. Persoane{Cod, Denumire, Domiciliu} respecta FN1?
- Respecta FN1 daca nu exista cerinte de grupare/selectare a informațiilor în funcție de localitate, stradă etc.
- Nu respecta 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. Persoană
Cod Denumire Localitate Adresă
=> Relatia care respecta FN1: 01 Ionescu Bucuresti str. Stefan cel
Mare,nr.2
02 Popescu Ploiesti str. Viitorului, nr.4
2. Comenzi{Numar, Data, Marfuri} nu respecta FN1.
Comenzi Comandă MarfăComandă

Numar Data Marfuri Relatiile Comandă Numar Data Numar Marfa
11 01/01/2018 Ciment, Var si MarfăComandă 11 01/01/2018 11 Ciment
12 02/01/2018 Ciment respectă FN1: 12 02/01/2018 11 Var
13 02/01/2018 Var, Nisip 13 02/01/2018 12 Ciment
13 Var
13 Nisip
FN2:
O relație se află în FN2 dacă respectă FN1 și dacă orice atribut noncheie se află în dependență funcțională
completă față de cheia primară a relației.
Exemplu:
MaterialeComandate{NumărComandă, CodMaterial, Cantitate, PreţUnitar, DenumireMaterial} nu se află în FN2
deoarece:
(NumărComandă, CodMaterial) → DenumireMaterial

CodMaterial→ DenumireMaterial
Relatia MaterialeComandate se descompune în următoarele relaţii care respecta FN2:
MaterialComandat{NumărComandă, CodMaterial, Cantitate, PreţUnitar} şi

Material{CodMaterial, DenumireMaterial}

FN3:
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.
Exemplu:
Comenzi{NumărComandă, Data, CodClient, DenumireClient} nu respectă FN3.
NumărComandă → CodClient→ DenumireClient
T
Relaţia Comenzi se descompune în următoarele relaţii care respecta FN3:
Comandă{NumărComandă, Data, CodClient} şi

Client{CodClient, DenumireClient}

3.4. Conceperea bazelor de date prin normalizare
Conceperea bazelor de date prin normalizare se poate realiza prin următoarele variante:
o descompunerea unei relații inițiale în mai multe relații normalizate;
o compunerea unei mulțimi de atribute în relații utilizând matricea sau graful dependențelor.
3.4.1. Conceperea bazelor de date prin descompunerea relației inițiale

Relația inițială reprezintă o relație care este alcătuită din toate atributele identificate, necesare conceperii bazei de
date. Normalizarea presupune descompunerea acestei relații inițiale în alte relații, prin trecerea graduală a acesteia
prin fiecare formă normală (FN1, FN2, FN3, FNBC, FN4 și FN5).
Exemplu: În vederea obținerii unei baze de date necesare evidentei
facturilor se cunosc urmatoarele informatii: Reguli de gestiune:
1. O factură este emisă de un furnizor
Dictionarul de atribute
2. Un furnizor poate emite mai multe facturi
1 SerieFactura 7 CodMaterial
3. O factură conţine mai multe materiale
2 DataFactura 8 DenumireMaterial
4. Un material poate figura în mai multe facturi
3 NumarFactura 9 UM
5. În cadrul unei factura, un material este prezent o
4 CodFurnizor 10 PreţFacturare
singura dată
5 DenumireFurnizor 11 CantitateFacturată
6. Valoare=PreţFacturare*CantitateFacturata
6 LocalitateFurnizor 12 Valoare
R {SerieFactura, NumarFactura, DataFactura, CodFurnizor, DenumireFurnizor, LocalitateFurnizor, CodMaterial,
DenumireMaterial, UM, PreţFacturare, CantitateFacturată }
▪ FN1: 
▪ FN2: 
1. (SerieFactura, NumarFactura, CodMaterial) →DataFactura
(SerieFactura, NumarFactura) →DataFactura
2. (SerieFactura, NumarFactura, CodMaterial) → CodFurnizor
(SerieFactura, NumarFactura) → CodFurnizor
3. (SerieFactura, NumarFactura, CodMaterial) → DenumireFurnizor
(SerieFactura, NumarFactura) →Denumirefurnizor
4. (SerieFactura, NumarFactura, CodMaterial) → LocalitateFurnizor
(SerieFactura, NumarFactura) → LocalitateFurnizor
5. (SerieFactura, NumarFactura, CodMaterial) → DenumireMaterial
CodMaterial→ DenumireMaterial
6. (SerieFactura, NumarFactura, CodMaterial) → UM
CodMaterial→ UM

Următoarele relații respecta FN2:
MaterialeFacturate{SerieFactura, NumarFactura, CodMaterial, PreţFacturare, CantitateFacturată }

FacturiFurnizori {SerieFactura, NumarFactura, DataFactura, CodFurnizor, DenumireFurnizor, LocalitateFurnizor}
Materiale{CodMaterial, DenumireMaterial, UM}
▪ FN3: 
1. (SerieFactura, NumarFactura) →CodFurnizor →DenumireFurnizor

(SerieFactura, NumarFactura) →DenumireFurnizor
2. (SerieFactura, NumarFactura) →CodFurnizor →LocalitateFurnizor
(SerieFactura, NumarFactura) →LocalitateFurnizor
Modelul relational final:

MaterialeFacturate{SerieFactura, NumarFactura, CodMaterial, PreţFacturare, CantitateFacturată }
Facturi {SerieFactura, NumarFactura, DataFactura, CodFurnizor}
Furnizori{CodFurnizor, DenumireFurnizor, AdresaFurnizor}
Materiale{CodMaterial, DenumireMaterial, UM}

3.4.2 Conceperea bazelor de date prin matricea dependenţelor1
În completarea matricei se au în vedere următoarele dependențe:

➢ dependența funcţională/simplă (se va nota în matrice cu „1”);
➢ dependența multiplă (se va nota în matrice cu „M”);
➢ dependențele funcționale tranzitive și, eventual, dependențele multiple tranzitive (se vor nota în matrice cu
„1T” și, respectiv, cu „MT”).
Pentru obținerea modelului relațional utilizând matricea dependențelor se vor aplica următoarele reguli:
1. Atributele vor fi preluate din documentele primare, rapoarte etc. și se vor adăuga în dicționarul de atribute.
Se vor elimina atributele calculate și cele sinonime, iar atributele compuse se vor descompune în atribute
atomice.
2. Se identifică atributele care îndeplinesc condițiile cheilor candidate.
3. Dintre cheile candidate se vor alege cheile primare.
4. Se vor identifica tipurile de dependențe (1, M, 1T, MT ) între fiecare cheie primară și restul atributelor definite
în dicționarul de atribute.
1- Adaptare dupa Cozgarea Gabriel, Baze de date. Microsoft Access, Editura ASE, 2018

5. Pentru atributele izolate se caută determinanți formați din:
• grupuri de chei primare;
• grupuri de chei primare și atribute noncheie;
• grupuri de atribute noncheie.
Dacă, în final, mai rămân atribute izolate, atunci se poate apela la chei surogat.
6. Se stabilesc relațiile în funcție de următoarele reguli:

▪ Fiecare determinant împreună cu atributele determinate, vor forma câte o relație nouă.
▪ Dacă între două chei primare există o dependență multiplă reciprocă, atunci această dependență va genera o
relație nouă. Cheia primară a acestei relații va fi formată din cele două atribute (grupuri de atribute), iar
individual vor avea rol de chei externe.
7. Se elimină eventualele relații derivate. Relațiile derivate conțin informații ce se pot obține prin aplicarea
operatorilor relaționali asupra relațiilor modelului relațional.

Exemplu:
Dictionarul de atriubute
1 SerieFactura
2 DataFactura Reguli de gestiune:
3 NumarFactura 1. O factură este emisă de un furnizor
4 CodFurnizor 2. Un furnizor poate emite mai multe facturi
5 DenumireFurnizor 3. O factură conține mai multe materiale

6 LocalitateFurnizor 4. Un material poate figura în mai multe facturi
7 CodMaterial 5. Pe o factură, un material este prezent o singura data
8 DenumireMaterial 6. Valoare = PreţFacturare * CantitateFacturata
9 UM
10 PreţFacturare
11 CantitateFacturată
12 Valoare

Matricea dependenţelor funcţionale:
Atribute 1 2 3 4 5 6 7 8 9 10 11
1. SerieFactură - 1 1 1T 1T M - - M M
2. NumărFactură - - - - - - - - - -
3. DataFactură - - - - - - - - - -
4. CodFurnizor M - - 1 1 M - - - -
5. DenumireFurnizor - - - - - - - - - -
6. LocalitateFurnizor - - - - - - - - - -
7. CodMaterial M - - M - - 1 1 M M
8. DenumireMaterial - - - - - - - - - -
9. UM - - - - - - - - - -
10. PreţFacturare - - - - - - - - - -
11. CantitateFacturată - - - - - - - - - -
SerieFactură,NumarFactura,CodMaterial - - - - - - - - - 1 1
▪ Cheile primare sunt (SerieFactură, NumărFactură), CodFurnizor și CodMaterial.

▪ Se stabilesc dependențele (1, 1T, M și, eventual, MT) care există între aceste chei primare și restul atributelor.
▪ Atributele PrețFacturare și CantitateFacturată sunt izolate (nu sunt determinate funcțional de nicio cheie primară).
Determinantul acestor atribute, format din atributele (SerieFactură, NumărFactura, CodMaterial), se adaugă în matrice.
▪ Între cheile primare (SerieFactură, NumărFactură) și CodMaterial, respectiv CodFurnizor și CodMaterial există dependențe
multiple reciproce.

Modelul relational:
Fiecare cheie primară împreună cu atributele determinate funcțional netranzitiv de către aceasta generează
câte o relație nouă.
Relațiile identificate din matricea dependențelor sunt următoarele:
Factura (SerieFactura, NumărFactură, Data, CodFurnizor)
Furnizor (CodFurnizor, DenumireFurnizor, LocalitateFurnizor)
Material (CodMaterial, DenumireMaterial, Um)
MaterialFacturat (SerieFactura, NumarFactura,CodMaterial, CantitateFacturată, PreţFacturare)
FacturaMaterial (SerieFactura, NumarFactura, CodMaterial) Relatie derivata
FurnizorMateriale (CodFurnizor, CodMaterial) Relatie derivata
Modelul relațional final este format din relațiile (tabelele) Factura, Furnizor, Material și MaterialFacturat.

4. IMPLEMENTAREA MODELULUI RELAŢIONAL ÎN
S.G.B.D. MICROSOFT ACCESS1
4.1. S.G.B.D. Microsoft Access - caracteristici generale.
Sistemul de gestiune a bazelor de date (SGBD) Microsoft Access reprezintă o componentă a pachetului Microsoft Office destinată
gestionării bazelor de date relaționale.
O bază de date Access este salvată sub forma unui fişier (cu extensia .accdb) si conţine următoarele obiecte:
1. Tabele (Tables)
2. Legături (Relationships)
3. Indecşi (Indexes)
4. Formulare (Forms)
5. Interogări (Querys)
6. Rapoarte (Reports)
7. Obiecte de tip Macro (Macros)
8. Module (Modules)
După lansarea aplicaţiei, utilizatorul are la dispoziţie urmatoarele posibilităţi:

A. Crearea unei baze de date (Blank database).
B. Crearea unei aplicații pe baza unui șablon (templates).
C. Deschiderea unei baze de date creată anterior (Open Other Files).
1– Adaptare după Gabriel Cozgarea Baze de date. Microsoft Access, Editura ASE, 2018

4.2. Obiecte de tip tabel
Obiectele table sunt destinate stocării datelor în structuri conforme cu modelul relaţional.
4.2.1. Crearea obiectelor tabel

Pentru crearea unui obiect de tip tabel, utilizatorul are la dispoziție următoarele opțiuni (meniul Create):
- Table – permite crearea unei tabele în modul Datasheet View.
- Table Design - utilizatorul poate crea o tabelă prin definirea explicită a câmpurilor și a proprietăților aferente.
- SharePoint Lists - permite crearea de tabele prin importul de date din liste SharePoint sau prin linkuri către acestea.
- se pot crea tabele și prin importul de date sau legătura (link-ul) către o sursă de date (meniul External Data).
Prin opţiunea Design View se stabilesc pentru fiecare câmp următoarele proprietăţi:
A. Numele câmpului (Field Name) trebuie să nu înceapă cu un spațiu, să prezinte o lungime maximă de 64 de caractere și să nu
conțină următoarele caractere speciale: punctul (.), semnul exclamării (!) și parantezele drepte ([]).
B. Tipul de date al câmpului (Data Type). Utilizatorul trebuie să precizeze tipul de date aferent câmpului create: Short Text,
Long Text, Number, Date/Time, Currency - valori numerice în virgulă fixă (4 zecimale), AutoNumber, Yes/No, Ole Object-
stochează obiecte (foi calcul Excel, documente Word etc.), Hyperlink - realizări alfanumerice ce reprezintă adrese URL (Internet
/Intranet) sau adrese UNC), Attachment – se pot atașa imagini, fișiere, documente etc., Calculated – permite crearea de campuri
calculate, Lookup Wizard.
C. Descrierea câmpului (opţional) - informaţii suplimentare referitoare la câmp.

D. Alte proprietăţi: Fereastra Access pentru descrierea tabelei în modul Design View:
- Field Size – precizează dimensiunea maximă pentru câmpurile
de tip Number, AutoNumber și Short Text.
- Input Mask – definește formatul folosit pentru introducerea
datelor.
- Caption - permite definirea unei etichete ce va fi afișată în locul
denumirii câmpului în momentul introducerii datelor.
- Default Value - definește o valoare implicită a câmpului care va
fi generată automat la adăugarea unei noi înregistrări.
- Validation Rule - permite implementarea unei restricții de
integritate aferentă câmpului curent.
- Validation Text - permite definirea unui mesaj care va fi afișat
atunci când nu este respectată restricția de integritate stabilită
prin proprietatea Validation Rule.
- Required - precizează dacă este obligatorie sau nu (prin setarea
proprietății cu valoarea Yes sau No) introducerea unei valori în
cadrul câmpului respectiv.
- Indexed – specifică tipul indexului asociat câmpului : “No”,
Introducerea datelor în tabela Client (modul Datasheet View):
“Yes (Duplicates OK)”, “Yes (No Duplicates)”.
- Allow Zero Length ‒ permite sau nu introducerea unui șir de
lungime zero. Această proprietate se utilizează în asociere cu
proprietatea Required și este valabilă pentru câmpurile de tip
Text (Short Text și Long Text) și Hyperlink.

Cele mai importante proprietăţi ale tabelei sunt (Design->Properties):
✓ Validation Rule - permite stabilirea unei restricții de integritate la nivel de tabelă.
✓ Validation Text - permite descrierea unui mesaj care va fi afișat atunci când nu se
respectă restricția implementată la proprietatea precedentă
✓ Filter - definește un criteriu de selecție a înregistrărilor ce vor fi afișate în modul
Datasheet View
✓ Order by - conține denumiri ale câmpurilor, separate prin virgulă, după care sunt
ordonate înregistrările din cadrul tabelei.
Definirea cheii primare în cadrul unei

tabele se realizează astfel:
- se selectează câmpul sau câmpurile
respective;
- se alege opțiunea Primary Key din
meniul Design sau din meniul contextual
aferent câmpului/câmpurilor.

4.2.2. Definirea relațiilor dintre tabele.
➢ Legătura dintre două tabele se realizează prin intermediul câmpurilor comune, respectiv cheie primară și cheie externă.
Acestea trebuie să fie compatibile din punct de vedere al tipului de date.
➢ Din fereastra Show Table se vor selecta tabelele participante la relaţie.
În Access se pot implementa doar legăturile de tip 1÷1 și 1÷N:

- Pentru a realiza o legătură de tip 1÷1, cheia externă corespondentă (din tabela secundară) trebuie indexată cu opțiunea Yes
(No Duplicates).
- Pentru a realiza o legătură de tip 1 ÷ N, cheia externă corespondentă (din tabela secundară) poate rămâne neindexată sau,
dacă se dorește indexarea ei, trebuie folosită opțiunea Yes (Duplicates OK).
La crearea sau editarea unei legături,
utilizatorul are la dispoziție următoarele opțiuni
✓ Impunerea integrității referențiale (Enforce
Referential Integrity)
✓ Actualizarea în cascadă a câmpurilor
asociate (Cascade Update Related Fields)
✓ Ștergerea în cascadă a înregistrărilor
asociate (Cascade Delete Related Records)
✓ Tipul de compunere (Join Type)

5. OBIECTE DE TIP INTEROGARE (QUERY) 1
Interogările sunt obiecte destinate:

- regăsirii unor informații în baza de date
- obținerii unor date derivate (calculate) din datele stocate în tabele
- actualizării datelor din tabele
- sintetizării/agregării datelor
✓Rezultatul unei interogări îl reprezintă un set dinamic de date.

✓Sursa de date a unei interogări poate fi formată din tabele și/sau alte interogări.
Tipuri de interogări:
1. Interogări de selecţie
2. Interogări acţiune
3. Interogări de analiză încrucişată
1 – adaptare dupa Gabriel Cozgarea - Baze de date. Microsoft Access, Editura ASE, 2018

5.1. Crearea unei interogări.
Modalități de creare a unei cereri:

✓ Query Design - permite definirea explicită a elementelor ce vor compune
interogarea, precum și a tipului acesteia.
✓ Query Wizard:
▪ Simple Query Wizard - permite crearea în mod asistat a unei
interogări de selecție;
▪ Crosstab Query Wizard - asigură crearea în mod asistat a unei
interogări de analiză încrucișată;
▪ Find Duplicates Query Wizard - permite elaborarea în mod asistat
a unei interogări ce va selecta numai înregistrările duplicate din
sursa de date;
▪ Find Unmatched Query Wizard - permite crearea asistată a unei
interogări ce va selecta numai înregistrările unui tabel ce nu au
corespondențe în alt tabel.
5.2. Interogări de selecţie

Pentru elaborarea unei interogări de selecție se poate alege fie opțiunea Simple Query Wizard din fereastra New Query, fie
opțiunea Query Design din meniul Create.

Fereastra Query poate fi împărțită în două zone:
A. Zona destinată sursei de date, care va conține tabelele, interogările,

precum și relațiile dintre acestea;
B. Grila interogării (Query), care are următoarea structură pe verticală:
– Field – conține numele câmpului selectat;
– Table – precizează sursa de date (tabelă/interogare)
a câmpului;
– Sort – adaugă sau nu câmpul curent în criteriul de
sortare al interogării;
– Show – permite sau nu afișarea valorilor câmpului;
– Criteria – indică criteriul de selecție (filtrare) aferent
câmpului curent;
– Or – permite definirea unui criteriu de selecție
alternativ celui din Criteria.
Etape:
a. selectarea sursei de date
b. definirea legăturilor temporare pentru tabelele și/sau interogările izolate
c. alegerea câmpurilor ce vor forma interogarea
d. stabilirea câmpurilor ale căror valori vor fi afișate în cadrul interogării
e. definirea criteriilor de selecție aferente interogării

Crearea câmpurilor calculate.
Interogările de selecție pot conține și câmpuri calculate. Acestea sunt definite
conform următoarei sintaxe:
Nume câmp: expresie de calcul
Exemplu:
Sa se afle valoarea aferenta fiecarui produs comandat.
Gruparea datelor
Microsoft Access permite elaborarea unor interogări în cadrul cărora se pot folosi funcții de grup (agregat), care se vor aplica
seturilor de înregistrări (opțiunea Totals din meniul Design).
Funcţii de grup:
▪ Sum() – calculează suma unui set de valori;
▪ Count() – returnează numărul de valori existente într-un set de date;
▪ Min() – determină valoarea minimă dintr-un set de date;
▪ Max() – determină valoarea maximă dintr-un set de date;
▪ First() – returnează prima valoare existentă într-un set de date;
▪ Last() – returnează ultima valoare dintr-un set de date;
▪ Avg() – calculează media aritmetică a unui set de valori.
Exemple:
1. Sa se afle cate comenzi a întocmit fiecare client.
2. Se doreşte obţinerea valorii totale aferente
comenzilor întocmite în ianuarie 2019.
3. Se doreste afisarea comenzilor a caror

valoare totala depaseste suma de 1000 Ron.

5.3. Interogări acţiune:
Interogările acțiune au la bază tot o sursă de date (tabele şi/sau interogări) ce poate fi folosită pentru:
- creare de tabele (Make Table) - utilizatorul poate crea o tabelă având ca sursă o interogare de selecție. Câmpurile din
noua tabelă vor prelua, de la cele din tabelele sursă, tipul de date și dimensiunile acestora, fără a importa și eventualele
restricții. Crearea tabelei este urmată de adăugarea înregistrărilor rezultate din interogarea de selecție. Noua tabelă nu va avea
definită nicio cheie primară.
- adăugare de înregistrări (Append Query) într-o altă tabelă - permit utilizatorului să adauge noi înregistrări în tabele
pornind de la cele stocate în alte tabele.
- ştergere de înregistrări (Delete Query) - permit utilizatorului să șteargă înregistrări din tabele, în funcție de anumite
criterii.
- modificarea înregistrărilor (Update Query) din tabelele sursă - Aceste interogări permit modificarea valorilor
câmpurilor din cadrul unui set de înregistrări care îndeplinesc anumite condiții.
5.4. Parametrizarea interogărilor apare necesară atunci când se

doreşte ca o interogare să fie executată în condiţii diferite.
Exemplu:
Se doreşte sa se afișeze numai comenzile aferente unui client
anume ce va fi specificat la executarea interogării.

5.5. Interogări de analiză încrucișată
Interogările de analiză încrucișată sunt destinate obținerii unor situații sintetice asemănătoare tabelelor pivot.
Principala caracteristică a acestor cereri o reprezintă setarea câmpurilor ce vor fi afișate pe liniile și coloanele interogării:
✓ În linia Crosstab se va selecta clauza Row Heading pentru câmpurile ce vor fi afișate pe linie;
✓ În linia Crosstab se va selecta clauza Column Heading pentru câmpurile ce vor fi afișate pe coloană;
✓ În linia Crosstab se va selecta clauza Value pentru câmpurile ale căror valori vor fi afișate la intersecția dintre linii și coloane
Exemplu:
Să se afișeze numărul de comenzi întocmite de clienți, în fiecare lună.

6. LIMBAJUL SQL1 – partea I
SQL (Structured Query Language) este un limbaj neprocedural, declarativ creat de IBM în 1970
în scopul gestionării bazelor de date relaţionale.
➢ În 1986 limbajul SQL a fost adoptat ca limbaj standard în domeniul bazelor de date
relaţionale.
➢ Este implementat de majoritatea sgbd-lor relaţionale (Oracle, dBase IV, FoxPro, Informix,
SysBase, Interbase, Access etc.) în diverse variante compatibile cu versiunea standard.
Limbajul SQL dispune de comenzi pentru:

✓ descrierea datelor (Limbaj de descriere a datelor – LDD);
✓ manipularea datelor (Limbaj de manipulare a datelor – LMD).
Orice interogare Microsoft Access este transformată și salvată intern în limbaj SQL, format
disponibil și utilizatorului prin accesarea opțiunii SQL View. Pentru elaborarea unei interogări în
limbajul SQL se deschide obiectul respectiv în modul SQL View, selectând opțiunea cu același
nume din meniul Home sau Design.

6.1. Comenzi SQL pentru descrierea datelor
6.1.1. CREATE TABLE - permite crearea unei tabele într-o bază de date.
Sintaxa:
CREATE TABLE nume_tabel ( câmp1 tip [(mărime)]
[CONSTRAINT nume_index {PRIMARY KEY|UNIQUE|NOT NULL }]
[,..])
Exemplu: Sa se creeze tabela Material.
CREATE TABLE Material (CodMaterial Number

CONSTRAINT iCodMat PRIMARY KEY, Denumire Text, UM Text)
6.1.2. ALTER TABLE - permite modificarea structurii unui tabel.
Sintaxa:
ALTER TABLE nume_tabel
{ADD COLUMN câmp1 tip[(mărime)] |
ALTER COLUMN câmp2 tip[(mărime)] |
DROP COLUMN câmp3 }

Exemplu: Se adaugă câmpul PreţStandard în tabela Material.
ALTER TABLE Material ADD COLUMN PretStandard Currency
6.1.3. DROP TABLE - permite ștergerea unui index asociat unei tabele sau a unei tabele din
baza de date.
Sintaxa:
DROP TABLE nume_tabel
Exemplu: Sa se steargă tabela Material din BD.
DROP TABLE Material
6.2. Comenzi SQL pentru manipularea datelor
6.2.1. INSERT INTO - permite adăugarea unei înregistrări în cadrul unei tabele.
Sintaxa:
INSERT INTO nume_tabel [(câmp1[, ...])] VALUES (valoare1[,...])
Exemplu: Se adaugă o înregistrare în tabela Material.

INSERT INTO Material VALUES (301, ”Ciment”, ”Kg”)
6.2.2. UPDATE - permite modificarea înregistrărilor dintr-un tabel.
Sintaxa:
UPDATE nume_tabel SET câmp1= expresie [, …] [WHERE condiţie]
Exemplu: Se dorește dublarea preţului standard pentru materialele ce au un pret standard

<10000.
UPDATE Material SET PretStandard=PretStandard*2

WHERE PretStandard<10000
6.2.3. DELETE - permite ștergerea unor înregistrări dintr-o tabelă, care îndeplinesc anumite
condiții.
Sintaxa:
DELETE [*] FROM nume_tabel WHERE condiţie
Exemplu: Să se șteargă toate comenzile intcomite in anul 2018.
DELETE FROM Comanda WHERE YEAR(DataComanda)=2018

6.2.4. SELECT - permite obținerea unei cereri de selecție.
Sintaxa:
SELECT [ALL / DISTINCT / DISTINCTROW / TOP N [PERCENT]]
{* / câmp1 [AS etichetă_câmp] [,…]}
FROM nume_tabel1 [AS etichetă_tabel] [,…]
WHERE condiţie_înregistrări_negrupate
GROUP BY câmp1 [,…]
HAVING condiţie_înregistrări_grupate
ORDER BY câmp1 [ASC / DESC] [,…]
Exemple:
1. Să se afle localităţile din care provin studenţii unei facultăţi (o localitate

este returnată o singură dată):
SELECT DISTINCT Localitate FROM Student
2. Sa se afle clientii care au intocmit comenzi (un client se afisează o singură dată):
SELECT DISTINCTROW Client.CodClient, Denumire, Localitate, Adresa

FROM Client, Comanda WHERE Client.CodClient=Comanda.CodClient

3. Să se afișeze primele 10 comenzi intocmite in anul 2018:
SELECT TOP 10 * FROM Comanda WHERE Year(Data)=2018
ORDER BY Data
4. Sa se afle valorile aferente produselor comandate:
SELECT Comanda.Numar, Data, CodProdus, Cantitate*Pret AS Valoare
FROM Comanda, ProduseComandate
WHERE Comanda.Numar = ProduseComandate.NumarComanda
Gruparea datelor:
În cadrul unei cereri, gruparea datelor se realizează prin specificarea câmpurilor de grupare în
clauza GROUP BY. Pentru câmpurile selectate care nu participă la gruparea datelor este
necesară folosirea funcțiilor agregat (Sum(), Avg(), Min(), Max(), Count(), First(), Last()).
Interogările cu grupuri de date nu sunt actualizabile.
Exemplu:
Sa se afle clientii care au intocmit cel putin 2 comenzi in anul 2020.
SELECT Client.CodClient, FIRST(Denumire) AS [Nume client], Count(Numar) As
[Numar Comenzi]
FROM Client, Comanda
WHERE Client.CodClient=Comanda.CodClient
GROUP BY Client.CodClient
HAVING Count(Numar)>=2

6. LIMBAJUL SQL1 – partea II
Selecţii complexe
Acele interogări care au ca sursă de date mai multe tabele, se numesc selecții complexe. Criteriul
de compunere a înregistrărilor poate fi definit prin:
▪ Clauza WHERE – în această situație, interogarea nu va fi actualizabilă.
▪ Clauza FROM – în acest caz, interogarea poate fi actualizabilă.
Exemple:
▪ clauza WHERE:
SELECT * FROM Client, Comanda
WHERE Client.CodClient=Comanda.CodClient
▪ clauza FROM:
1. Joncţiuni interne (INNER JOIN):
SELECT * FROM Client INNER JOIN Comanda ON
Client.CodClient=Comanda.CodClient
2. Compunerile externe (OUTER JOIN) :
A. Outer Left Join:
SELECT * FROM Client LEFT JOIN Comanda ON
B. Outer Right Join:
SELECT * FROM Client RIGHT JOIN Comanda ON

Exemplu: Care sunt clientii care nu au intocmit comenzi?
SELECT Client.Codclient, Denumire
FROM Client LEFT JOIN Comanda ON Client.CodClient=Comanda.CodClient
WHERE Numar IS NULL
Selecţii reuniune (UNION)

Aceste interogări permit reunirea înregistrărilor care provin din tabele sau interogări de selecție
diferite.
Sintaxa:
[TABLE] Interogare1
UNION [ALL] [TABLE] Interogare2
[UNION [ALL]
[TABLE] InterogareN [ … ]]
Exemplu: Fie tabelele
Furnizor(CodFurnizor, Denumire, Adresa, ContBancă)
Client (CodClient, Denumire, Adresa)
Se cere interogarea SQL care sa afiseze toţi partenerii societăţii:
SELECT CodFurnizor AS CodPartener, Denumire, Localitate, Adresa FROM Furnizor
UNION
SELECT CodClient, Denumire, Localitate, Adresa FROM Client
ORDER BY CodPartener

6.3. Imbricarea cererilor (Subinterogări/subcereri)
O subinterogare se referă la o cerere SELECT ce este plasată în cadrul altei comenzi SQL.
O cerere SELECT poate fi utilizată pentru a returna una sau mai multe înregistrări, ce vor
fi folosite într-o comandă INSERT ... INTO, SELECT ... INTO, DELETE, UPDATE,
SELECT sau în cadrul altei subinterogări.
Atunci când subinterogarea returnează mai multe înregistrări, pentru comparații, se pot
utiliza următorii operatori:
• IN – testează apartenența unei valori la o mulțime;
• ANY/SOME – compară o valoare cu oricare element al unei mulțimi;
• ALL – compară o valoare cu toate elementele unei mulțimi;
• EXISTS – verifică dacă o mulțime conține cel puțin un element.
6.3.1. Utilizarea subcererilor SELECT in cadrul comenzii INSERT INTO
Sintaxa:
INSERT INTO NumeTabel [(CâmpD1[, CâmpD2[, …]])] [IN BDExternă]
SELECT CâmpS1[, CâmpS2[, …] FROM ExpresieTabele
Exemplu:
Se doreste adăugarea înregistrărilor contabile din anul precedent din tabela
OperaţiiContabile(IdOperatie, NrOperatie, DataOperatie, Explicatii) în tabela Arhiva
(care are aceeaşi structură).

INSERT INTO Arhiva
SELECT * FROM OperaţiiContabile
WHERE Year(DataOperatie) =Year(Date( ))-1
6.3.2 Utilizarea subcererilor SELECT in cadrul comenzii DELETE
Exemplu: Se doreste stergerea tuturor comenzilor intocmite de clientii din Brasov.
DELETE FROM Comanda WHERE CodClient IN (SELECT CodClient From

Client WHERE Localitate="Brasov")
6.3.3. Utilizarea subcererilor SELECT in cadrul comenzii UPDATE

Exemplu:
Fie modelul relational:
Produse (CodProdus, Denumire, PretStandard)
ProduseFacturate (CodProdus, SerieFactura, CantFacturata, Pret)
Se cere interogarea SQL prin care se reduce cu 50% preţul standard de vânzare al produselor ce
au avut o vânzare mai mică decât media vânzărilor totale.
UPDATE Produse SET PretStandard=PretStandard / 2
WHERE CodProdus IN ( SELECT CodProdus FROM ProduseFacturate
GROUP BY CodProdus
HAVING SUM(CantFacturata*Pret) <
( SELECT AVG(CantFacturata*Pret) FROM ProduseFacturate ))

6.3.4. Utilizarea subcererilor SELECT in cadrul comenzii SELECT
Exemple:
1. Sa se afle clientii care nu au intocmit comenzi în luna martie 2020.
SELECT * FROM Client

WHERE CodClient NOT IN
(SELECT CodClient
FROM Comanda
WHERE Data BETWEEN #01/03/2020# AND #31/03/2020#)
2. Sa se afle clientii de la care s-au primit cele mai multe comenzi.
SELECT CodClient, COUNT(Numar) As NumarComenzi

FROM Comanda
GROUP BY CodClient
HAVING COUNT(Numar) >= ALL
(SELECT COUNT(Numar) FROM Comanda GROUP BY CodClient)

7. OBIECTE DE TIP FORMULAR (FORMS)1
Formularele sunt obiecte Microsoft Access utilizate pentru realizarea interfeței cu utilizatorul, fiind destinate actualizării sau
consultării bazelor de date.
În funcție de sursa de date, formularele se clasifică astfel:
✓ Formulare legate (bound) – sunt acele formulare care au o sursă de date ce poate fi formată dintr-un tabel sau o interogare.
✓ Formulare nelegate (unbound) – reprezintă acele formulare care nu sunt legate la o sursă de date, dar care conțin diferite
controale necesare afișării unor informații sau administrării aplicației.
Microsoft Access pune la dispoziția utilizatorilor următoarele tipuri de formulare:
– Single form – afișează numai înregistrarea curentă;
– Tabular form – afișează mai multe înregistrări concomitent;
– Datasheet form – afișează mai multe înregistrări în format asemănător foilor de calcul;
– Split form – reprezintă un formular divizat în două secțiuni.
Un formular Access poate fi deschis în următoarele moduri:
✓ Form View – este utilizat atunci când se dorește lansarea în execuție a formularului.
✓ Layout View – oferă utilizatorului o vedere orientată-vizual, în sensul că fiecare control plasat în cadrul formularului va
afișa date reale.
✓ Design View – utilizatorul își proiectează formularul având la dispoziție o imagine detaliată a structurii obiectului Access.
În acest format, sunt vizibile secțiunile formularului, se pot seta/modifica toate proprietățile formularului, controalelor etc.
1 – preluare din Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018

7.1. Crearea unui formular.
Pentru realizarea unui formular, Microsoft Access oferă utilizatorului următoarele posibilități (meniul Create):
➢ Form – generează un formular ce va conține toate câmpurile din sursa de date (tabel, interogare, formular, raport) selectată
din panoul de navigare.
➢ Form Design – generează un formular, gol, deschis în modul Design View.
➢ Blank Form – creează un formular fără controale sau formatări ce va fi deschis în modul Layout View.
➢ Form Wizard – permite crearea unui formular în mod asistat.
➢ Navigation – asigură generarea unor formulare, în diferite variante, care permit utilizatorilor să
navigheze către diverse obiecte de tip Form și / sau Report.
➢ Alte tipuri de formulare generate de catre MS Access: Multiple Items, Datasheet, Split Form,
Formular modal.
În cursul proiectării unui formular se pot utiliza următoarele ferestrele:
1. Fereastra Form – conţine zona formularului și are următoarea structură: Bara de titlu Secțiunile formularului Barele de defilare
- elementele ferestrei (bara de titlu, bordura, bare de defilare, etc.)

- secţiuni:
- antetul formularului (Form Header) conține informații despre datele afișate (titlul
formularului etc.)
- antetul de pagină (Page Header) este vizibil doar atunci când formularul este
Zona Zona din afara
tipărit la imprimantă formularului formularului
- detaliu (Detail) va conține toate controalele necesare afișării și/sau editării datelor
- subsolul de pagină (Page Footer) este afișat doar la tipărirea formularului
- subsolul formularului (Form Footer) poate conține diferite informații despre datele
afișate sau diferite controale
2. Fereastra de proprietati
a. Proprietăţi din categoria Format: conține proprietăți prin care se asigură formatarea formularului
sau controlului (mod de afișare, dimensiune etc.). Cele mai uzuale proprietăți sunt următoarele:
• Caption – indică titlul formularului, ce va fi afișat în bara de titlu a acestuia.
• Default View – precizează modul implicit de afișare (Single Form, Continuous Forms, Datasheet,
Split Form).
• Record Selectors – afișează sau nu selectorul de înregistrare.
• Navigation Buttons – precizează dacă sunt sau nu afișate butoanele de navigare.
b. Proprietăţi din categoria Data: precizează proprietăți referitoare la sursa de date. Cele mai importante proprietăți sunt:
• Record Source – indică sursa de date a formularului, care poate fi o tabelă, o interogare sau o comandă SQL care descrie o
cerere de selecție.
• Filter – permite definirea unui criteriu de selecție ce se va aplica asupra înregistrărilor afișate în cadrul formularului.
• Filter On Load – dacă este setată cu Yes, proprietatea Filter devine activă, iar înregistrările vor fi filtrate
la deschiderea formularului.
• Order By – permite definirea câmpurilor după care vor fi sortate înregistrările din cadrul formularului.
• Order By On Load – dacă este setată cu Yes, proprietatea Order By devine activă, iar înregistrările vor fi
sortate la deschiderea formularului.
• Data Entry – dacă este setată cu Yes, formularul va fi folosit doar pentru adăugarea de înregistrări. La
deschiderea formularului, nu vor fi afișate înregistrările existente în baza de date.
• Record Locks – precizează modul în care înregistrările accesate de formular vor fi blocate pentru ceilalți
utilizatori.
c. Proprietăţi din categoria Events – indică evenimente ce pot fi tratate cu ajutorul obiectelor de tip Macro sau
procedurilor/funcțiilor scrise în limbajul VBA. Cele mai uzuale evenimente sunt :
• On Current – evenimentul se declanșează în momentul în care se trece de la o înregistrare la alta sau dacă se dorește
actualizarea sursei de date (Requery).
• After Update – acest eveniment se declanșează după actualizarea datelor.
• Before Update – apare înainte de actualizarea datelor.
• Before Insert – evenimentul se manifestă atunci când utilizatorul introduce primul caracter într-o
înregistrare nouă (înainte ca aceasta să fie creată efectiv).
• After Insert – acest eveniment se declanșează după adăugarea unei înregistrări noi.
• On Delete – evenimentul se declanșează înainte de ștergerea efectivă a unei înregistrări.
• On Open – apare atunci când se deschide un formular, dar înainte de a se afișa prima
înregistrare.
• On Close – evenimentul se declanșează atunci când formularul este închis.
d. Proprietăţi din categoria Other: conține alte proprietăți. Cele mai importante proprietăți sunt:
• Modal – permite setarea formularului ca modal (nu permite accesarea altor ferestre din cadrul
aplicației, până când acesta nu este închis) sau nemodal (permite accesarea altor ferestre din cadrul
aplicației).
• Ribbon Name – indică numele Ribbon-ului care va fi afișat la deschiderea formularului.
• Toolbar – precizează bara de instrumente ce va fi afișată la execuția formularului.
• Menu Bar – indică numele meniului definit de utilizator ce va fi afișat la deschiderea formularului.

7.2. Controale:
Controalele reprezintă obiecte grafice destinate editării sau afișării datelor. Unele dintre acestea pot fi construite în mod
asistat (Wizard). Pentru activarea asistentului, se selectează opțiunea Use Control Wizards din lista controalelor afișată în meniul
Design.
După sursa de date, controalele se pot clasifica astfel:
• controale legate (Bound) – reprezintă acele controale care au o sursă de date;
• controale nelegate (Unbound) – sunt controalele care nu au o sursă de date.
Cele mai uzuale controale sunt următoarele:
Denumire Buton Descriere
Caseta text (Text Box) Se folosește pentru editarea sau afișarea datelor.
Eticheta (Label) Se utilizează pentru afișarea datelor constante.
Butonul de comandă (Button) Controlul este utilizat pentru declanșarea unor acțiuni.
Caseta combinată (Combo Box) Permite fie editarea valorilor, fie introducerea acestora dintr-o listă
derulantă. Acest control este folosit cu precădere pentru actualizarea
câmpurilor cu rol de cheie externă sau a celor care acceptă un număr
limitat de valori (de exemplu, UnitateDeMăsură, CotăTVA etc.).
Caseta listă (List Box) Acest control este utilizat pentru selectarea unei valori dintr-o listă.
Subformular/Subraport (Subform/Subreport) Permite crearea unui subformular sau subraport în cadrul unui
formular/raport.
Proprietățile unui control sunt afișate în fereastra Property Sheet, dacă, în prealabil, acesta a fost selectat.
Cele mai importante proprietăți ale unui control sunt următoarele:
a. Proprietăți din categoria Format:

✓ Format – precizează formatul de afișare al valorilor din cadrul controlului. Această proprietate
este prezentă numai la controalele Text Box și Combo Box.
✓ Visible – precizează dacă obiectul-control este sau nu vizibil în timpul execuției formularului.
✓ Height – indică înălțimea controlului.
✓ Top – stabilește coordonata verticală a colțului din stânga-sus a controlului.
✓ Left – precizează coordonata orizontală a colțului stânga-sus a controlului.
b. Proprietăți din categoria Data:

✓ Control Source – precizează sursa de date a controlului. Aceasta poate fi denumirea unui câmp sau o expresie de calcul
precedată de semnul egal (=).
✓ Input Mask – definește formatul pentru introducerea datelor. Această proprietate poate fi utilizată doar pentru casetele text.
✓ Default Value – stabilește valoarea implicită a controlului.
✓ Validation Rule – precizează o restricție de integritate pe care trebuie să o îndeplinească valoarea introdusă în cadrul
controlului.
✓ Validation Text – permite definirea unui mesaj ce va fi afișat utilizatorului, atunci când
restricția implementată la proprietatea precedentă nu este respectată.
✓ Enabled – activează sau dezactivează controlul respectiv.
✓ Locked – asigură protecția datelor. Dacă proprietatea este setată cu Yes, controlul va deveni
read-only.
c. Proprietăți din categoria Event:

✓ Before Update – evenimentul se declanșează înainte de salvarea datelor din control în câmpul
care reprezintă sursa de date a acestuia.
✓ After Update – se declanșează după salvarea datelor din control în câmpul aferent.
✓ On Exit – acest eveniment se declanșează atunci când se părăsește controlul.
d. Proprietăți din categoria Other:
✓ Name – indică denumirea controlului în funcție de care acesta este accesat de aplicație.
✓ Status Bar Text – conține un mesaj ce va fi afișat în bara de stare, atunci când controlul este
activ (deține focusul).

7.3. Subformulare
Subformularele reprezintă formulare incluse în
alte formulare, numite formulare principale.
Utilizarea subformularelor prezintă următoarele
avantaje:
- permit actualizarea mai multor tabele simultan;
- subformularul afișează numai înregistrările
corespondente celei afișate în formularul
principal;
- cheia externă din subformular se actualizează
automat cu valoarea aferentă cheii primare din
formularul principal.
Fiind date două formulare F1 și F2, pentru
definirea lui F2 ca subformular al lui F1 se
parcurg următoarele etape:
1. Se deschide F1 în mod Design.
2. Folosind procedeul drag and drop se
depune formularul selectat în panoul de navigare
în cadrul formularului principal
3. Se salvează F1 (formularul principal)

8. OBIECTE DE TIP RAPORT1
8.1. Caracteristici generale
Rapoartele sunt destinate afișării sau tipăririi datelor din tabele sau interogări.
Rapoartele pot fi clasificate astfel:
După sursa de date:
▪ Rapoarte legate – sunt rapoartele care au o sursă de date ce poate fi formată dintr-o tabelă sau o interogare.
▪ Rapoarte nelegate – sunt rapoartele care nu au o sursă de date.
După modul de afișare a datelor:
▪ Rapoarte de tip Columnar – sunt rapoartele în care datele sunt afișate pe coloană.
▪ Rapoarte de tip Tabular – datele sunt afișate sub formă de tabel.
▪ Rapoarte de tip Justified – sunt rapoartele care utilizează lățimea paginii pentru a afișa datele cât mai compact posibil.
Un raport poate fi deschis în următoarele moduri:
1. Report View – reprezintă modul implicit de afișare atunci când se execută dublu-click pe un raport în panoul de navigare.
2. Layout View – este un format în care, deși raportul este în execuție, se pot efectua aproape toate modificările admise în Design
View.
3. Design View – oferă o vedere detaliată a raportului în care se pot efectua toate operațiile de concepere a acestuia.
4. Print Preview – afișează raportul în formatul în care va fi și tipărit.
1 – preluare din Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018

8.2. Crearea rapoartelor:
Microsoft Access oferă utilizatorilor următoarele variante pentru crearea rapoartelor (meniul Create):
✓Report: se generează un raport simplu ce va conține toate câmpurile din sursa de date
selectată din panoul de navigare.
✓Report design: se creează un raport gol, ce va fi deschis în modul Design View.
✓Blank Report: se generează un raport gol, ce va fi deschis în format Layout View.
✓Report Wizard: permite realizarea unui raport de tip Columnar, Tabular sau Justified în mod asistat (Wizard).
✓Labels: generează rapoarte de dimensiuni reduse ce pot fi folosite în diferite scopuri (etichete pentru corespondență,
etichetare produse etc.).
Pentru realizarea unui raport prin varianta Report Wizard se parcurg următoarele etape (opțiunea Report Wizard din meniul Create):
1. Se selectează sursa de date (tabelă sau interogare) și câmpurile care vor fi afișate în cadrul raportului.
2. Opțional, se selectează câmpurile după care se vor grupa datele.
3. Selectarea câmpurilor după care se vor ordona datele în cadrul raportului.
4. Precizarea modului de afișare a datelor în cadrul raportului.
5. Stabilirea titlului raportului și a modului de vizualizare.
Elaborarea unui raport prin varianta Report Design presupune parcurgerea următoarelor etape:
1. Selectarea opțiunii Report Design din meniul Create
2. Precizarea sursei de date a raportului
3. Stabilirea câmpurilor de grupare și/sau sortare a datelor
4. Plasarea controalelor aferente câmpurilor din sursa de date
5. Formatarea controalelor plasate în cadrul raportului
6. Stabilirea titlului raportului
7. Salvarea raportului
8.3. Proprietăţile rapoartelor
Proprietățile unui raport pot fi setate prin intermediul ferestrei Property Sheet. Cele mai uzuale
proprietăți sunt următoarele:
a).Proprietăţi din categoria Format:
✓ Caption – permite definirea titlului ce va fi afișat în bara de titlu a raportului.
✓ Default View – indică modul implicit de afișare al raportului, care poate fi Report View sau
Print Preview.
✓ Picture – precizează fișierul grafic ce va fi afișat pe fundalul raportului.
b). Proprietăţi de tip Data:

✓ Record Source – precizează sursa de date a raportului, care poate fi
o tabelă, o interogare sau o comandă SQL care descrie o cerere
de selecție.
✓ Filter – indică un criteriu de selecție ce se va aplica asupra datelor din raport.
✓ Filter On Load – activează sau nu condiția de selecție, precizată la proprietatea anterioară, în
momentul deschiderii raportului.
✓ Order By – precizează câmpurile după care vor fi ordonate datele în cadrul raportului. Dacă
sunt mai multe câmpuri, acestea vor fi separate prin virgulă.
✓ Order By On Load – activează sau dezactivează proprietatea anterioară la deschiderea
raportului.
c) Proprietăţi eveniment:
✓ On Open – evenimentul se declanșează la deschiderea raportului, înainte de afișarea acestuia.
✓ On No Data – acest eveniment se declanșează atunci când sursa raportului nu conține date.
✓ On Close – evenimentul apare la închiderea raportului.
d). Alte (Other) proprietăţi:

✓ Record Locks – permite blocarea înregistrărilor din sursa de date a raportului în timpul
afișării/tipăririi acestuia.
✓ Modal – prin setarea cu valoarea Yes a acestei proprietăți, raportul va deveni modal.

8.4. Rapoarte și subrapoarte
➢ Subrapoartele sunt rapoarte incluse în cadrul altor rapoarte numite rapoarte principale.
➢ Legătura dintre raportul principal și subraport se realizează, la fel ca în cazul subformularelor, prin intermediul câmpurilor de
legătură precizate la proprietățile Link Master Fields și Link Child Fields.
Exemplu: Să se realizeze un raport care să afișeze comenzile aferente clienților.
Design View Print Preview

9. OBIECTE DE TIP MACRO1
Un obiect de tip macro (macrocomandă) conține un set de acțiuni care sunt executate automat de către Microsoft Access
Un obiect tip macro:
✓ este constituit dintr-o succesiune de linii (fiecare linie reprezintă o acţiune de executat);
✓ are ca scop automatizarea unor acţiuni asupra unor obiecte ale bazei de date.
Obiectele de tip macro se clasifică în două categorii:

✓ macrocomenzi de date;
✓ macrocomenzi standard.
Macrocomenzi de date
Macrocomenzile de date se pot crea folosind opțiunea Create Data Macros din meniul Design, atunci când o tabelă este deschisă
în modul Design View. Dacă se dorește redenumirea sau ștergerea unei macrocomenzi de date, se alege opțiunea Rename/Delete
Macros din meniul Design.
Există două tipuri principale de macrocomenzi de date:

▪ Macrocomenzi de date bazate pe evenimente: sunt acele obiecte macro care sunt declanșate de
evenimentele (After Insert, After Update, After Delete, Before Delete, Before Change) care se
manifestă în cadrul unui tabel, mai precis la adăugarea, modificarea sau ștergerea de înregistrări.
Macrocomenzile de date bazate pe evenimente sunt destinate implementării restricțiilor de integritate
aferente bazei.
1 – Adaptare dupa Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018
▪ Macrocomenzi de date independente: sunt obiectele de tip macro de date care pot fi apelate din orice altă macrocomandă de
date sau macrocomandă standard. O macrocomandă de date independentă este asociată cu un anumit tabel, dar nu și cu un
anumit eveniment. Pentru crearea unei macrocomenzi de date independente se selectează opțiunea Create Data Macros /
Create Named Macro, iar pentru modificarea acesteia se alege opțiunea Create Data Macros / Edit Named Macro din meniul
Design.
Principalele actiuni2 ce pot fi utilizate in macrocomenzile de date sunt:
▪ CreateRecord - permite crearea unei inregistrari;

▪ EditRecord - asigura editarea unei inregistrari;
▪ ForEachRecord - permite implementarea unei structuri repetitive;
▪ LookupRecord - filtreaza un set de inregistrari in functie de o conditie;
▪ DeleteRecord - permite stergerea unei inregistrari;
▪ ExitForEachRecord - iesire din structura ForEachRecord;
▪ RaiseError - atentioneaza sistemul in cazul aparitiei unei erori;
▪ StopMacro - opreste executia unui obiect macro.
2 – pentru detalii, vezi Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018
Macrocomenzi standard
Obiectele de tip macro standard pot fi atașate evenimentelor formularelor, rapoartelor sau controalelor. Aceste obiecte macro
se mai pot executa și independent, prin selectarea opțiunii Run fie din meniul Design (dacă obiectul este deschis în Design View),
fie din meniul contextual aferent. Pentru crearea unei macrocomenzi standard se selectează opțiunea Macro din meniul Create.
Spre deosebire de macrocomenzile de date, aceste obiecte macro sunt vizibile în panoul de navigare.
Principalele grupuri de acțiuni3 ce pot fi utilizate în cadrul macrocomenzilor standard sunt:
▪ Actiuni pentru modificarea datelor (DeleteRecord, EditListItems, SaveRecord);

▪ Actiuni pentru exportul, importul, trimiterea si primirea datelor prin mail;
▪ Actiuni ce permit lucrul cu obiecte din baza de date (GoToControl, GoToPage, OpenForm,
OpenReport etc.);
▪ Actiuni ce permit filtrarea, interogarea si cautarea inregistrarilor (FindRecord, Requery,
OpenQuery etc.);
▪ Actiuni ce permit lucrul cu obiecte macro (CancelEvent, RunMacro, StopMacro etc.);
▪ Actiuni ce au efect asupra sistemului de baza de date (CloseDatabase, QuitAccess, Beep).
3 – pentru detalii, vezi Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018
Exemple:
1. Fie tabelele Comandă și DocPlată. Sa se realizeze un Rezolvare:
obiect Data Macro care sa permita implementarea urmatoarei
restrictii:
DocPlata.Data >= Comanda.Data
2. In cadrul formularului Comanda se dorește realizarea unui

buton de comandă prin care să se deschidă formularul Client.

10. SECURITATEA ŞI INTEGRITATEA BAZELOR DE DATE1
10.1. Integritatea semantică
Datele stocate în cadrul unui SGBD trebuie să fie coerente, adică să fie conforme cu realitatea. Pentru
aceasta, datele trebuie să respecte anumite restricții (constrângeri) de integritate.
Restricțiile de integritate suportate de modelul relațional pot fi grupate în următoarele categorii:

A.Restricții de integritate statice ‒ reprezintă acele restricții care se verifică permanent. La rândul lor,
acestea pot fi de mai multe tipuri:
A.1.Restricții de domeniu reprezintă constrângeri pe care trebuie să le îndeplinească valorile acceptate
de atribute:
A.1.1. Restricțiile de format se referă la faptul că un atribut al unei relații acceptă doar valori din
tipul specificat (numeric, text, dată calendaristică etc.).
A.1.2. Restricțiile identificate în regulile de gestiune:
a. Restricții impuse unui singur atribut: sunt acele constrângeri care precizează faptul că realizările
acestuia se află într-un interval de valori posibile.
Exemplu: [Dată factură] >= 01/01/2017.
1– preluare din Gabriel Cozgarea, Baze de date. Microsoft Access, Ed. ASE, 2018

b. Restricții care se referă la valorile mai multor atribute ce provin din aceeași relație.
De exemplu, pentru relația Contract (Număr, DatăEmitere, DatăExpirare, Valoare) se poate
defini următoarea restricție de integritate: DatăExpirare >= DatăEmitere.
c. Restricții care vizează valorile mai multor atribute ce provin din relații diferite.
De exemplu, fie relațiile Factură (SerieFactură, NumărFactură, DatăFactură, CodFurnizor)
și DispozițiePlată (NumărDispozițiePlată, DatăDispozițiePlată, Sumă, SerieFactură,
NumărFactură). Pentru aceste relații se poate defini următoarea restricție de integritate:
DatăDispozițiePlată >= DatăFactură.
d. Restricții care se aplică asupra unor valori obținute pe baza unor operații de sintetizare.
De exemplu, media de vârstă a angajaților unei societăți comerciale trebuie să fie mai mică
de 50 de ani.
A.2.Nenulitatea. În cadrul unui model relațional, unele atribute nu pot accepta valoarea NULL. În
această categorie se înscriu, în primul rând, cheile candidate. Desigur, restricția poate fi valabilă, în
funcție de specificul aplicației, și pentru alte atribute (dată factură, preț de achiziție, simbol cont etc.).
A.3. Atomicitatea. Această restricție se referă la faptul că toate atributele definite în cadrul modelului
relațional trebuie să fie atomice, în sensul că ele nu se mai descompun.
A.4. Unicitatea. Într-o relație nu pot exista tupluri care conțin aceleași valori pentru toate atributele.
Orice relație trebuie să dețină o cheie primară care permite identificarea tuplurilor.
A.5. Integritatea referenţială
A.6. Dependența funcțională
B. Restricții de integritate dinamice ‒ sunt acele constrângeri ce privesc trecerea de la o stare la
alta a unui tuplu în urma efectuării modificărilor aferente.
10.2. Conceptele de tranzacţie şi de stare coerentă a bazei de date
➢Tranzacţia reprezintă o tehnică prin care este asigurată coerenţa bazei de date în cursul
actualizării acesteia.
➢O bază de date se numeşte coerentă dacă respectă toate restricţiile impuse de reflectarea fidelă a
realităţii.
Tranzacţia reprezintă un set de operaţii de actualizare care fie se execută toate, fie nici una.
O tranzacţie poate fi:
❑ Salvată (commited) - toate operaţiile tranzacţiei au fost încheiate cu succes, iar baza de date este
actualizată cu noile modificări.
❑ Derulată înapoi (rollback) – toate operaţiile tranzacţionate sunt anulate, iar baza de date este
restaurată la starea dinaintea tranzacţiei.

11. FACILITĂȚI MICROSOFT ACCESS PENTRU DEZVOLTAREA APLICAȚIILOR1
Pentru dezvoltarea aplicațiilor, Microsoft Access oferă facilități pentru:
• importul și exportul datelor;
• salvarea bazei de date în diferite versiuni și formate;
• compactarea și repararea bazei de date;
• protejarea bazei de date;
• împărțirea bazei de date în două fișiere;
• analiza și documentarea bazei de date;
• personalizarea interfeței
1. Importul și exportul de date
Cu ajutorul opțiunilor din meniul External Data, Microsoft Access oferă utilizatorilor posibilitatea de a importa sau
exporta date în diferite formate: Microsoft Excel, Microsoft Access, fișiere text, XML, PDF sau XPS etc.
1– Adaptare dupa Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018

2. Salvarea bazei de date în diferite versiuni și formate
O bază de date se poate salva:

▪ diferite versiuni Microsoft Access (2000, 2002-2003, 2016),
▪ ca șablon de bază de date (Template)
▪ ca o bază de date compilată (Make ACCDE).
De asemenea, se poate realiza o împachetare a bazei de date cu aplicarea unei semnături digitale (Package and
Sign), realizarea unei copii de rezervă a bazei de date în scopul prevenirii pierderilor de informații (Back Up
Database) sau partajarea bazei de date prin salvarea ei pe un server de management al documentelor (SharePoint).

3. Compactarea și repararea bazei de date
Microsoft Access oferă utilizatorilor opțiunea Compact and Repair Database din meniul File sau din meniul
Database Tools.
Compactare - se elimină spațiul neutilizat din cadrul bazei de date (motiv pentru care dimensiunea acesteia este
micșorată).
Reparare - sunt recuperate tabelele, indecșii asociați, interogările sau alte date disponibile.
4. Protejarea bazei de date

• Stabilirea unei parole de acces pentru baza de date, utilizând opțiunea Encrypt with Password din meniul File.
Eliminarea parolei de acces se poate realiza folosind opțiunea Decrypt Database din meniul File.
• Conversia bazei de date în format ACCDE se realizează folosind opțiunea Save As / Save Database As / Make
ACCDE din meniul File

5. Scindarea bazei de date
Cu ajutorul opțiunii Access Database, din meniul Database Tools, se pot separa tabelele unei aplicații de restul
obiectelor, acestea fiind salvate în două fișiere separate.
Această opțiune folosește utilitarul Database Splitter și

se utilizează, de regulă, în cazul aplicațiilor cu mai
mulți utilizatori
6. Analiza și documentarea bazei de date
Microsoft Acces dispune de instrumente atât pentru

optimizarea unei baze de date desktop, cât și pentru
realizarea automată a documentației aferente
aplicației. Instrumentul Performance Analyzer
realizează o analiză a performanțelor, oferă soluții și
chiar realizează optimizarea bazei de date (Analyze
Performance din meniul Database Tools)
Documentația aferentă aplicației conține informații
despre obiectele bazei de date și se poate realiza selectând
opțiunea Database Documenter din meniul Database
Tools.
7. Personalizarea interfeței
Personalizarea interfeței cu utilizatorul presupune atât particularizarea formularelor și a rapoartelor, cât și a
meniului aplicației. Formularele și rapoartele pot fi personalizate în funcție de preferințele utilizatorului (sunt
disponibile chiar câteva template-uri pentru conceperea acestora). Meniul2 aplicației poate fi personalizat, în general, în
două moduri:
A. prin crearea unui formular afișat automat la deschiderea aplicației, care permite navigarea către celelalte
formulare și rapoarte;
B. prin realizarea unui meniu al aplicației de tip bandă (Ribbon).
2 – Pentru detalii, vezi Gabriel Cozgarea, Baze de date. Microsoft Access, Editura ASE, 2018

12. ARHITECTURA CLIENT-SERVER
Arhitecturile client-server se bazează pe dialogul dintre două categorii de entităţi, entitatea Client şi entitatea server
dispuse într-o reţea de calculatoare. Cele două entităţi pot fi regăsite pe calculatoare diferite sau pe acelaşi calculator.
➢ Clientul este entitatea care asigură interfaţa cu utilizatorul. Clientul lansează cereri de executare a unor operaţii
către server şi se ocupă de punerea într-o anumită formă a datelor primite de la server.
➢ Serverul recepţionează, interpretează şi execută operaţiile lansate de client.
Server SGBD
Client
Cerere client
Baza de date
Răspuns
server
Utilizarea sistemelor client-server oferă următoarele avantaje:

➢ această arhitectură poate fi folosită indiferent de sistemul de operare sau de mediul de dezvoltare;
➢ accesul permanent la date, indiferent de locația aplicației client;
➢ trafic redus în rețeaua locală, deoarece o parte din operații sunt executate pe stația de lucru client;
➢ se asigură securitatea datelor, independența logică și fizică a acestora;
➢ reducerea dimensiunii aplicației.

Baze de Date

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze de Date

Încărcat de

Drepturi de autor:

Formate disponibile

1.

BAZE DE DATE ŞI SISTEME DE GESTIUNE A BAZELOR DE DATE1

Organizarea datelor în baze de date prezintă următoarele caracteristici:

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 2

În vederea asigurării unei separări logice a datelor față de

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 3

NumărFactura Data CodFurnizor

CodFurnizor Denumire Adresa

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 4

Clasa Factură Obiecte Factură

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 5

tehnic pot fi reprezentate sub formă de înregistrări logice, fiecare

este formată din cilindru, pistă și sector.

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 6

• realizările ordonate, crescător sau descrescător, aferente Tabela cu indecși

1.3 Sisteme de gestiune a bazelor de date

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 7

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 8

domeniu realizare Furnizori

2.2 Legături între tabele

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 12

Contract (Numar, Data, Valoare, NrCerere)

Furnizor (CodFurnizor, Denumire, Adresa)

Factură (Serie, NrFactură, Data, CodFurnizor)

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 14

Material(CodMaterial, Denumire, UM)

MaterialFacturat(Id, SerieNrFactură, CodMaterial)

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 15

a)Operatorii generali cu mulțimi:

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 2

AB01 01 01.01.2018 1011 Selecţia furnizorilor cu sediul în Bucureşti

1011 S.C. Alfa Bucuresti CodFz Denumire Localitate

1012 S.C. Beta Bucuresti 1011 S.C. Alfa Bucuresti

1013 S.C. Gama Brasov 1012 S.C. Beta Bucuresti

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 3

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 4

AB01 01 01.01.2018 1011 1011 S.C. ALFA Bucuresti

AB02 02 02.01.2018 1012 1012 S.C. BETA Bucuresti

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 5

AB01 01 01.01.2018 1011 1011 S.C. ALFA Bucuresti

AB02 02 02.01.2018 1012 1012 S.C. BETA Bucuresti

NULL NULL NULL NULL 1013 S.C. GAMA Brasov

Furnizor RIGHT JOIN Cod=CodFurnizor Factura

AB01 01 01.01.2018 1011 1011 S.C. ALFA Bucuresti

AB02 02 02.01.2018 1012 1012 S.C. BETA Bucuresti

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 6

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 7

3.1. Metode de proiectare a bazelor de date relaţionale

Conceperea modelului relațional se poate realiza prin următoarele variante:

3.2.1. Dependenţele funcţionale

Exemple: CodFurnizor → DenumireFurnizor

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 2

(NumărComandă, CodProdus) → CodClient

Proprietăţi ale dependenţelor funcţionale:

•Tranzitivitate: Dacă X → Y şi Y → Z, atunci X → Z

3.2.2. Dependenţe multivaloare: A → → B

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 3

Daca exista tulurile (Sectia1, MijFix1, 001) si (Sectia1, MijFix2, 002),

Alte tipuri de dependențe:

Exemple: NumărComandă―» CodProdus; DataComandă ―» NumărComandă

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 4

Baze de date - Conf. Univ. Dr. Cozgarea Gabriel 5

Comenzi Comandă MarfăComandă