Cuprins:

Cap. 1. Introducere........................................................................................2
Cap. 2. Tema de Proiect: Summit sporting goods.3
Cap. 3. Schema conceptuala..4
3.1. Noiuni teoretice...4
3.2. Schema conceptual.....................................................................6
Cap. 4. Schema logic...................................................................................7
4.1. Noiuni teoretice...........................................................................7
4.2. Schema logic...............................................................................8
Cap. 5. Normalizarea Bazelor de Date...........................................................9
5.1. Noiuni teoretice............................................................................9
5.2. Normalizarea Bazei de Date........................................................10
Cap. 6. Denormalizarea Bazelor de Date......................................................10
6.1. Noiuni teoretice..........................................................................10
6.2. Denormalizarea Bazei de Date....................................................10
Cap. 7. Sisteme de gestiune a bazelor de date: MySQL...............................11
7.1. Noiuni teoretice..........................................................................11
7.2. Aplicaii.......................................................................................12
Cap. 8. Concluzii..........................................................................................21

BIBLIOGRAFIE .....................................................................................22
 Capitolul 1. Introducere

O baz de date reprezint un ansamblu de date integrat, anume structurat i dotat

cu o descriere a acestei structuri. Descrierea structurii poart numele de dicionar de date
sau metadate i creaz o interdependen ntre datele propriu-zise i programe.
Baza de date poate fi privit ca o colecie de fiiere interconectate care conin
nucleul de date necesare unui sistem informatic. Astfel, poate fi considerat drept un model
al unor aspecte ale realitii unei uniti economice, modelat prin intermediul datelor.
Diferitele obiecte din cadrul realitii ce prezint interes sunt denumite clase sau entiti.
Pentru aceste obiecte sunt achiziionate i memorate date referitoare la diferite
caracteristici (atribute).
Baza de date se constituie ca un ansamblu intercorelat de colecii de date, prin care
se realizeaz reprezentarea unei realiti.
Datele constituie orice mesaj primit de un receptor, sub o anumit form.
Informaiile reprezint cantitatea de noutate adus de un mesaj din exterior
(realitate).
Un fiier este un ansamblu de nregistrri fizice, omogene din punct de vedere al
coninutului i al prelucrrii.
O nregistrare fizic este o unitate de transfer ntre memoria intern i cea extern
a calculatorului.
O nregistrare logic este unitatea de prelucrare din punct de vedere al
programului utilizator.
O nregistrare se compune din cmpuri (atribute) care descriu anumite aspecte ale
realitii. Cmpurile sunt nregistrri logice.

O baz de date trebuie s asigure:

abstractizarea datelor (baza de date fiind un model al realitii),
integrarea datelor (baza de date este un ansamblu de colecii de date intercorelate, cu
redundan controlat),
integritatea datelor (se refer la corectitudinea datelor ncrcate i manipulate astfel
nct s se respecte restriciile de integritate),
securitatea datelor (limitarea accesului la baza de date),
partajarea datelor (datele pot fi accesate de mai muli utilizatori, eventual n acelai
timp),
independena datelor (organizarea datelor s fie transparent pentru utilizatori,
modificrile n baza de date s nu afecteze programele de aplicaii).
De obicei o baz de date este memorat ntr-unul sau mai multe fiiere. Bazele de
date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date.
Cel mai rspndit tip de baze de date este cel relaional, n care datele sunt
memorate n tabele. Pe lnga tabele, o baz de date relaional mai poate conine: indeci,
proceduri stocate, declanatori, utilizatori i grupuri de utilizatori, tipuri de date,
mecanisme de securitate i de gestiune a tranzaciilor etc.
Alte tipuri de baze de date sunt modelul ierarhic, modelul orientat pe obiecte i,
mai nou, modelul XML.

2
 Capitolul 2. Tema de Proiect: Summit Sporting Goods

Sunt managerul unei companii care realizeaz articole sportive en-gros i care
primete comenzi de la magazine cu profil i le furnizeaz acestora produsele dorite.
Magazinele sunt clienii notri(unii dintre angajaii notri prefer s-i numeasc astfel). n
acest moment avem 15 clieni din toat lumea, dar ncercm s mrim numrul de
cumprtori cu 10% n fiecare an, ncepnd din acest an. Doi dintre cei mai mari clieni ai
notri sunt Big Johns Sports Emporium din San Francisco, CA, USA i Womansports din
Seattle, Washington, USA. Pentru fiecare client noi trebuie s avem un ID i un nume. Mai
trebuie s avem o adres(incluznd oraul, statul, codul potal i ara) i numrul de telefon.
Avem depozite n diferite regiuni pentru a le livra clinenilor notri ct mai repede
comenzile. Pentru fiecare comand trebuie s avem un ID. Trebuie s avem data comenzii,
data cnd a fost livrat comanda i modul de plata, cnd aceast informaie este disponibil.
n acest moment am mprit lumea n 5 regiuni: America de Nord, America de Sud,
Orientul Mijlociu, Asia i Europa. Avem nevoie doar de ID i de nume pentru aceastea.
ncercam s atribuim fiecrui client o regiune astfel ncat s tim cea mai buna locaie de la
care s livrm fiecare comand. Fiecare depozit trebuie s aib un ID. Trebuie s aib i o
adres(incluznd oraul, statul, codul potal i ara) i numrul de telefon. n acest moment
avem doar un depozit pe regiune, dar sperm s avem mai multe ct de curand.
Administrez ordinea n care sunt realizate articolele sportive en-gros ale afacerii
nostre. Departmentul meu este responsabil pentru plasearea i livrarea comenzilor cnd
clienii notri sun. Pentru fiecare departament trebuie s avem un ID i un nume. Uneori,
clieii pur i simplu ne trimit un e-mail cnd sunt grbii, dar, de cele mai multe ori, ne sun
sau ne trimit un fax cu comenzile lor. Sperm s extindem afacerea prin oferirea ct mai
rapid$ a informaiilor privind comenzile primite. Credei c aceast aplicaie poate fi pus
pe internet(pe site-ul nostru)?
Putem promite s livrm chiar a doua zi, att timp ct articololele respective sunt n
stoc( sau invetariate) la unul dintre depozitele noastre. Cnd informia este disponibil,
punem la dispoziie cantitatea pe care o avem n stoc, momentul n care poate fi facut din
nou comanda, cantitatea maxim de articole pe care o avem n stoc, un motiv pentru care
nu avem articolul respectiv n stoc i data cnd o s l avem din nou n stoc. Cnd produsele
sunt livrate vrem s trimitem automat, prin fax, informaiile legate de livrarea respectiv,
prin sistemul nostru de livrare. Nu, nu eu administrez acea regiune. Departamentul meu
doar i asigur pe clienii notri c au informaiile corecte despre suma pe care trebuie s o
plteasc i verific, de asemenea, dac contul lor este ntr-o stare bun de a face
tranzacii. Putem, de asemeanea, nregistra informaii generale despre un client.
Noi ne asigurm c toate articolele pe care le-au cerut clienii notri sunt n stoc.
Pentru fiecare articol avem un ID. Trebuie, de asemenea, s avem preul fiecrui articol,
cantitatea i cantitatea livrat, dac aceast informaie este disponibil. Dac sunt n stoc,
vrem s procesm comanda i vrem s le spunem clienilor notri ce ID are comanda
respectiv i cat de mult nseamn comanda lor total. Dac articolele nu sunt n stoc,
clientul ne spune dac ar tebui s ateptm pn putem s livrm toat comanda sau dac ar
trebui s o livrm parial.
Departamentul de contabilitate este responsabil cu meninrea de informaii despre
clienii notri, n special cu atribuirea de ID-uri noilor clieni. Departamentul meu are voie

3
s actualizeze informaii despre clieni, doar cnd o comand este pus i cnd modul de
plat sau adresa de livrare s-au schimbat. Nu, noi nu suntem responsabili pentru colecii.
Cu acestea se ocup contabilii, cred de asemenea c reprezentanii de vnzri se implic
deoarece comenzile lor depind de clienii care pltesc! Pentru fiecare reprezentant de
vnzri sau angajat trebuie s tim un ID i numele de familie. Ocazional, avem nevoie s
tim prenumele, ID-ul de utilizator, data de incepere, titlul i salariul. Este posibil s vrem
s aflm rata de vnzare a angajatului i orice alt informaie despre el.
Personalul nostru este bine instruit n ceea ce privete linia noastr de produse.
inem sedine frecvente despre marketing pentru ca ei s ne informeze despre noi produse
aprute. Din acest lucru rezult o mai buna satisfacere a clienilor notri pentru c cei care
se ocup cu primirea comenzilor pot s raspund la mai multe ntrbari. Acest lucru este
posibil pentru c avem de-a face cu civa clieni seleci i meninem o linie de producie de
specialitate. Pentru fiecare produs trebuie s tim ID-ul i numele. Ocazional, mai trebuie
s tim descrierea, preul sugerat i unitatea de vnzare a produsului. Am vrea, de
asemenea, s avem posibilitatea de a avea descrieri foarte amnunite ale produselor
noastre i poze cu acestea, cnd este necesar.

Capitolul 3. Schema conceptual

3.1. Noiuni teoretice

Proiectarea unei baze de date const n proiectarea schemei conceptuale (logice) i

fizice a acesteia, astfel nct s raspund cerinelor utilizatorilor pentru un anumit set de
aplicaii. n general, se consider c proiectarea unei baze de date se poate diviza n
urmatoarele faze:
1. Colectarea si analiza cerinelor.
2. Proiectarea conceptual a bazei de date.
3. Alegerea unui SGBD.
4. Proiectarea logic a bazei de date.
5. Proiectarea fizic a bazei de date.

n faza de proiectare conceptual a bazelor de date se proiecteaz schema

conceptual i schemele externe ale bazei de date.

Modelul Entitate-Asociere (Entity-Relationship Model) este un model conceptual

de nivel nalt al unei baze de date, care definete mulimile de entiti i asocierile dintre
ele, dar nu impune nici un mod specific de structurare i prelucrare a datelor.

Elementele eseniale ale modelului Entitate-Asociere sunt entitile (entities) i

asocierile dintre acestea (relationships). O entitate (entity) este "orice poate fi identificat n
mod distinctiv"; o entitate se refer la un aspect al realitii obiective care poate fi deosebit
de restul universului i poate reprezenta un obiect fizic, o activitate, un concept etc. Orice

4
entitate este descris prin atributele sale. Un atribut (attribute ) este o proprietate care
descrie un anumit aspect al unei entiti. Toate entitile similare, care pot fi descrise prin
aceleai atribute, aparin aceluiai tip de entitate (entity type), iar colecia tuturor entitilor
de acelai tip dintr-o baz de date constitue o mulime de entiti (entities set).
n general, n modelul E-A se folosete aceeai denumire att pentru un tip de
entitate ct i pentru mulimea entitilor de acel tip. De exemplu, tipul de entitate
angajat (al unei instituii) reprezint orice persoan angajat a instituiei, care are o
anumit funcie i primete un anumit salariu. Acest tip de entitate poate fi descris prin mai
multe atribute, dintre care o parte sunt atribute de identificare a persoanei (Nume,
Prenume, DataNasterii, Adresa) , iar altele sunt atribute legate de activitatea acesteia n
instituia respectiv (Functie,Salariu).
n proiectarea bazelor de date se consider dou categorii de entiti: entiti
normale (obinuite -regular entities) i entiti slabe (dependente -weak entities).
Entitile normale au o existen proprie n cadrul modelului, n timp ce entitile slabe nu
pot exista dect daca exist o entitate normal (puternic) cu care sunt asociate.

O asociere (relationship ) este o coresponden ntre entiti din doua sau mai
multe mulimi de entiti. Gradul unei asocieri este dat de numrul de mulimi de entiti
asociate. Asocierile pot fi binare (de gradul 2, ntre 2 mulimi de entiti) sau multiple (ntre
k mulimi de entiti, k> 2).

Asocierile binare sunt, la rndul lor, de trei categorii, dup numarul elementelor
din fiecare dintre cele doua mulimi puse n coresponden de asocierea respectiv. Fiind
date dou mulimi de entiti, E1 i E2, se definesc urmatoarele categorii de asocieri binare:

Asocierea unul-la-unul (one-to-one) este asocierea prin care unui element

(entitate) din mulimea E1 i corespunde un singur element din mulimea E2, si reciproc; se
noteaza cu 1:1.

Asocierea unul-la-multe (one-to-many) este asocierea prin care unui element

din mulimea E1 i corespund unul sau mai multe elemente din mulimea E2, dar unui
element din E2 i corespunde un singur element n multimea E1; se noteaza cu 1:N.

Asocierea multe-la-multe (many-to-many) este asocierea prin care unui

element din mulimea E1 i corespund unul sau mai multe elemente din mulimea E2, i
reciproc; se noteaza cu M:N.

Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezint modelul

Entitate-Asociere prin mulimile de entiti i asocierile dintre acestea. Exist numeroase
variante de notaii pentru redarea diagramei E-A. Una dintre cele mai folosite notaii
reprezint un tip de entitate printr-un dreptunghi, iar atributele tipului de entitate prin elipse
conectate printr-o linie continu la acesta. Pentru entitatile puternice se utilizeaz un
dreptunghi ncadrat cu o linie simpla, iar pentru entitatile slabe se utilizeaza un dreptunghi
ncadrat cu linie dubla. O asociere ntre doua sau mai multe tipuri de entiti se reprezint
printr-un romb conectat prin link-uri (linii continue, formate din unul sau mai multe
segmente) la tipurile de entiti asociate. O asociere poate s aib sau nu un nume; dac are
un nume, acesta poate fi nscris n rombul respectiv sau n vecintatea acestuia. Categoria

5
asocierii se noteaz prin nscrierea multiplicitii pe fiecare link care conduce la un tip de
entitate. Este posibil ca o asociere s prezinte ea nsi atribute, i aceste atribute se
reprezint prin elipse conectate la asocierea respectiv.

3.2. Schema conceptual

Fig. 1. Schema conceptual a bazei de date pentru Summit Sporting Goods

Diagrama Entitate-Legatur

6
 Capitolul 4. Schema logic
4.1. Noiuni teoretice

n faza de proiectare logic a unei baze de date se realizeaz schema conceptuala

global i schemele conceptuale (vederile) externe pentru sistemul SGBD (sistem de
gestiune al bazelor de date) ales, pornind de la schema conceptual i schemele externe de
nivel nalt independente de SGBD. Aceast faz de proiectare logic poate fi realizat n
doua sub-faze: transpunerea schemei conceptuale n modelul de date al sistemului
SGBD ales, dar independent de sistemul de gestiune propriu-zis i rafinarea schemei
conceptuale i a schemelor externe obinute anterior, astfel nct s se utilizeze unele (sau
ct mai multe) din facilitile oferite de sistemul SGBD ales (modul de generare a cheilor
primare, definirea constrngerilor, etc.).
Aceste dou sub-faze se pot realiza mpreun, folosind unul din instrumentele de
proiectare oferite de sistemul SGBD ales. Rezultatul acestei faze de proiectare l constituie,
aadar, schema conceptual i schemele externe ale bazei de date, dependente de sistemul
SGBD ales i de modelul de date al acestuia. Pentru transpunerea modelului Entitate-
Asociere (reprezentat prin diagrama E-A) n model relaional se parcurg n principal doua
etape: proiectarea relaiilor i proiectarea asocierilor.

Proiectarea relaiilor
Mulimile de entiti puternice (normale) din diagrama E-A devin relaii, cu
atributele date de atributele entitilor. n astfel de relaii, cheia primar se definete fie ca o
cheie natural (combinaie de atribute care definesc n mod unic un tuplu al relaiei), fie ca
o cheie primar artificial. Mulimile de entiti slabe din diagrama E-A devin, de regul,
relaii aflate n asociere N:1 cu relaia coresunztoare mulimii de entiti de care acestea
depind. Pentru realizarea acestei asocieri, n relaia dependent se adaug o cheie strain
care refer cheia primar a relaiei referite (puternice). Cheia primar a unei relaiii
dependente poate fi o combinaie formata din atributul cheie strain si alte atribute care
asigur posibilitatea de identificare unic a unui tuplu, sau poate fi o cheie artificial.
Mulimile de entiti care sunt subtipuri ale unui tip de entitate dat devin relaii aflate n
asociere 1:1 cu relaia corespunztoare mulimii de entiti de tipul respectiv (supertip).
Pentru realizarea acestei asocieri, n relaia corespunztoare subtipului de entiti se
definete o cheie strain care refer cheia primar din relaia corespunztoare supertipului
de entitai; aceast cheie strain este n acelai timp i cheie primar n relaia corespunz-
toare subtipului de entiti.

Proiectarea asocierilor
Asocierea binar N:1 dintre dou mulimi de entiti puternice din diagrama E-A se
realizeaz n modelul relaional prin intermediul unei chei strine n prima relaie (cea cu
multiplicitatea N a asocierii) care refer cheia primar (sau o cheie candidat) din relaia
referit (cea cu multiplicitatea 1 a asocierii). Asocierea binar M:N dintre dou mulimi de
entiti din diagrama E-A se realizeaz n modelul relaional prin intermediul unei noi
relaii, numit relaie de asociere. Aceast nou relaie se afl n asociere M:1, respectiv
N:1 cu fiecare din cele dou relaii date prin intermediul a dou chei strine care refer
cheile primare (sau chei candidate) din relaiile date. Cheia primar a unei relaii de

7
asociere poate fi o cheie artificial sau poate fi compus din cheile strine care refer cele
dou relaii asociate, eventual mpreun cu alte atribute ale relaiei, care caracterizeaz
asocierea respectiv.
Asocierea binar 1:1 ntre dou mulimi de entiti puternice se poate transpune n
modelul relaional n dou moduri: fie prin intermediul unei chei strine (ca un caz
particular al unei asocieri N:1), fie printr-o relaie de asociere (ca un caz particular al unei
asocieri M:N).
Asocierea binara 1:1 dintre o mulime de entiti de un subtip i mulimea de entiti
supertip din diagrama Entitate-Asociere este tot o asociere binar cu raportul de
cardinalitate 1:1 ntre relaiile corespunztoare n modelul relaional. Acest tip de asociere
se realizeaz prin definirea n relaia corespunztoare subtipului de entiti a unei chei
strine care refer cheia primar din relaia corespunztoare supertipului de entiti; aceast
cheie strin este n acelai timp i cheie primar n relaia corespunzatoare subtipului de
entiti.
Asocierea multipl M:N:P:... dintre mai mult de dou mulimi de entiti din
diagrama E-A se realizeaz n mod asemntor cu asocierea binar, prin intermediul unei
noi relaii care se afl n asociere M:1, N:1, P:1 etc, cu fiecare din relaiile date. Aceast
asociere este realizat prin intermediul mai multor chei strine, fiecare cheie strain
referind cheia primar (sau o cheie candidat) dintr-una din relaiile date.

4.2. Schema logic

Conversia n schema logic a schemei conceptuale din Fig. 1 (pag. 6) este

urmtoarea:
Tabele rezultate din entiti sunt urmtoarele: Client, Comanda, Regiune, Depozit,
Departament, Stoc, Angajat, Produs, AdresaC (adresa clientului), AdresaD (adresa
depozitului). n total 10 tabele.
Pentru fiecare tabel exist un numr de atribute, dup cum urmeaza:
1. Client: id_client (cheie primar), nume, nr_tel, id_adresac (cheie strain);
2. Comanda: id_comanda (cheie primar), data_livrarii, data_comenzii,
mod_de_plata;
3. Regiune: id_regiune (cheie primar), nume, client_pe_regiune;
4. Depozit: id_depozit (cheie primar), nr_tel, id_adresad (cheie strain);
5. Departament: id_departament (cheie primar), nume;
6. Stoc: id_stoc (cheie primar), nume, cantitate_stoc (cheie strain);
7. Angajat: id_angajat (cheie primar), nume, prenume, id_utilizator, salariu,
rata_de_vanzare, id_departament(cheie strain) ;
8. Produs: id_produs (cheie primar), nume, pret, unitate_de_vanzare, descriere;
9. AdresaC: id_adresac (cheie primar), oras, stat, cod_postal, tara;
10. AdresaD: id_adresad (cheie primar), oras, stat, cod_postal, tara;
Relaiile dintre entiti vor fi transformate n chei strine dac este nevoie.

8
 Capitolul 5. Normalizarea Bazelor de Date
5.1. Noiuni teoretice

n trecut normalizarea era utilizat pentru proiectarea unei BD. n prezent,

proiectare unei BD se realizeaz cu ajutorul schemei conceptuale i schemei logice, iar
normalizarea intervine asupra tabelelor obinute pe baza schemei logice eliminnd unele
probleme care pot apare n procesul de proiectare iniial: redundana n date, anomalii la
actualizare.
Normalizarea: reprezint procesul de descompunere a unui tabel relaional n mai
multe tabele care satisfac anumite reguli i care stocheaza aceleai date ca i tabelul iniial,
astfel ncat s fie eliminate redundana n date i anomaliile la actualizare.

Un tabel relaional se poate afla n 6 situaii diferite numite forme normale:

- prima form normal;
- a 2-a form normal;
- a 3-a form normal;
- forma normal Boyce-Codd;
- a 4-a form normal;
- a 5-a form normal.

Prima form normal (1NF - First Normal Form)

Definiie: Un tabel relaional este n 1NF dac fiecarei coloane i corespunde o valoare
indivizibil (atomic). Deci orice valoare nu poate fi compus dintr-o mulime de valori
(atributele compuse) i nu sunt admise atributele repetitive.

A doua form normal (2NF - Second Normal Form)

Definiie: Un tabel relaional R este n a doua form normal (2NF) dac i numai dac:
- R este n 1NF;
- Orice coloan care depinde parial de o cheie a lui R este inclus n acea cheie.
Deci, 2NF nu permite dependeele funcionale pariale fa de cheile tabelului, cu excepia
dependenelor triviale, de incluziune.

A treia form normal (3NF - Third Normal Form)

Definitie_1: Un tabel relaional R este n a treia form normal (3NF) dac i numai dac:
- R este n 2NF
- Pentru orice coloan A neconinut n nici o cheie a lui R, dac exist un set de
coloane X astfel ncat X -> A, atunci fie X conine o cheie a lui R, fie A este inclus in X.
Definiie_2: Un tabel relaional R este n a treia form normal (3NF) dac i numai dac:
- R este n 2NF
- Orice coloan neconinut n nici o cheie a lui R nu este dependent tranzitiv de nici o
cheie a lui R.

Forma normal Boyce-Codd (BCNF Boyce-Codd Normal Form)

Definiie: Un tabel relaional R este n forma normal Boyce-Codd (BCNF) dac i numai
dac pentru orice dependen funcional total X -> A, unde X este un subset de coloane
ale lui R, iar A este o coloan neconinut n X, X este o cheie a lui R.

9
 A 4-a form normal (4NF Fourth Normal Form)
Definiie: Fie R un tabel relaional, X i Y dou submulimi de coloane ale lui R i Z = R
X Y mulimea coloanelor din R care nu sunt nici n X nici n Y. Spunem c exist o
dependen multivaloare Y de X sau c X determin multivaloare pe Y (notaia folosit:
X->->Y), dac, pentru orice valoare a coloanelor lui X, sunt asociate valori pentru
coloanele din Y care nu sunt corelate n nici un fel cu valorile coloanelor lui Z.

A 5-a form normal (5NF Fifth Normal Form)

Definiie pentru 5NF: Un tabel relaional R este n 5NF dac i numai dac orice join-
dependen ( R1, R2, ., Rn) este consecina cheilor candidate ale lui R, adic fiecare dintre
R1, R2, ., Rn include o cheie candidat a lui R.

5.2. Normalizarea Bazei de Date

Baza de date pentru Summit Sporting Goods nu trebuie normalizat deoarece

respect cele 5 forme normale i nu conine redundan n date i anomalii la actualizare.

Capitolul 6. Denormalizarea Bazelor de Date

6.1. Noiuni teoretice

Denormalizarea unei baze de date reprezint procesul invers operaiei de

normalizare i duce la creterea redundanei datelor. Prin aceasta se dorete, n principal,
creterea performanei i simplificarea programelor de interogare a datelor.

Obs.: - Denormalizarea se face numai dup o normalizare corect.

- Denormalizarea se face printr-o selectare strategic a structurilor care aduc
avantaje semnificative.
- Denormalizarea trebuie nsoit de msuri suplimentare de asigurare a integritii
datelor.

6.2. Denormalizarea Bazei de Date

Deoarece nu a fost nevoie de o normalizare a bazei de date pentru Summit

Sporting Goods , nu este nevoie nici de o denormalizare a acesteia.

10
 Capitolul 7. Sisteme de gestiune a bazelor de date: MySQL
7.1. Noiuni teoretice

Un SGBD (Sistem de Gestiune a Bazelor de Date) sau DBMS (DataBase

Management System) este un sistem software care gestioneaz toate procesele dintr-o baz
de date i care permite utilizatorului s interacioneze cu aceasta.

Principalele funciuni ale unui SGBD sunt:

- stocarea datelor;
- definirea structurilor de date;
- manipularea datelor;
- interogarea (extragerea i prelucrarea) datelor;
- asigurarea securitii datelor;
- asigurarea integritii datelor;
- accesul concurent la date cu pstrarea consistenei acestora;
- asigurarea unui mecanism de recuperare a datelor;
- asigurarea unui echanism de indexare care s permit accesul rapid la date.

SGBD sunt de 4 tipuri:

a) SGBD ierarhic
Modelul ierarhic stocheaz datele n structuri de tip arbore. Se consider c ntre date exist
o relaie de tip printe-copil. Nivelul superior al arborelui (rdcina) poate avea orice
numr de descendeni care i ei, la rndul lor, au ali descendeni etc. n prezent, modelul
ierarhic este depit i nu se mai folosete aproape deloc.

b) SGBD reea (n prezent este puin folosit)

Datele sunt stocate sub form de nregistrri cu legturi multiple i complexe ntre ele. Este
o extindere a celui ierarhic. Aici un copil poate avea mai muli prini sau chiar niciunul.
Caracteristicile principale ale SGBD reea sunt:
- reprezentare date complexe
- extrem de puin flexibil
- design extrem de complicat

c) SGBD relaional
Reprezint cea mai simpl structur pe care o poate avea o baz de date. Datele sunt
organizate n tabele formate din nregistrri i cmpuri. n acest caz bazele de date
relaionale sunt foarte flexibile i uor de mnuit. Cele mai populare baze de date
relaionale: Oracle, Acces, Informix i Sybase. Altele : SQL server i DB2.

d) SGBD orientat pe obiect

Este tipul cel mai nou de SGBD fiind introdus conceptul de obiect. Integreaz principiile
programrii orientate pe obiect (C++, Actor etc.) cu cele ale bazelor de date. Gestioneaz

11
obiecte complexe (date neconvenionale) (texte, grafice, hri imagini sunete); obiecte
dinamice (programe, simulri). Tehnologia este la nceput (Oracle 8 i 9)

MySQL este un sistem de gestiune a bazelor de date relaional, produs de

compania suedeza MySQL AB i distribuit sub Licena Public General GNU. Este cel
mai popular SGBD open-source la ora actual, fiind o component cheie a stivei LAMP
(Linux, Apache, MySQL, PHP).

7.2. Aplicaii

Exemple de interogri ale bazei de date pentru Summit Sporting Goods :

Comanda SELECT:

1. select * from Client;

12
 2. select id_produs, nume, pret from Produs;

Operatori Aritmetici:

select id_stoc, nume, cantitate_stoc, cantitate_stoc*10 from Stoc;

13
 Aliasuri de coloane:

select nume, cantitate_stoc " cantitatea disponibila " from Stoc;

Prevenirea selectrii nregistrrilor duplicate:

select distinct tara from AdresaC;

14
 Clauza ORDER BY:

select nume, cantitate_stoc from stoc

order by cantitate_stoc;

Clauza WHERE:

select * from Comanda

where id_comanda = 22;

Operatori relaionali:

Operatorii relaionali sunt: = egal; <> i != diferit; > mai mare; < mai mic; >= mai mare
sau egal; <= mai mic sau egal.

15
 1. select * from Produs
where pret < 25;

2. select * from AdresaC

where tara != 'Japonia';

Operatori SQL:

Exist patru tipuri de operatori SQL, care pot opera cu toate tipurile de date: BETWEEN. .
.AND. . . ; IN ; LIKE ; IS NULL.

16
 select * from Angajat
where id_angajat between 18 and 24;

Condiii multiple de interogare (operatorii AND i OR):

select id_regiune, nume, client_pe_regiune from Regiune

where id_regiune = 1 or client_pe_regiune = 2;

Funcii caracter: concat, lower, upper, length etc.

select upper(nume) from Departament;

17
 Funcii referitoare la mai multe nregistrri: count, min, max, cum, avg etc.

select min(cantitate_stoc), max(cantitate_stoc), avg(cantitate_stoc),COUNT(*)

from Stoc;

Produsul a dou sau mai multe tabele:

select * from Depozit, AdresaD;

Jonciuni: jonciuni echivalente (EQUI-JOIN) sau jonciuni interne (INNER JOIN),

jonciuni neechivalente, jonciuni externe (OUTER JOIN), autojonciuni .

select c.nume, a.tara

from Client c, AdresaC a
where c.id_client = a.id_adresac;

18
 Subinterogri:

select nume, prenume, salariu from Angajat

where salariu = (select min(salariu)
from Angajat);

Comanda INSERT:

1. insert into Comanda (id_comanda, data_livrarii, data_comenzii,

mod_de_plata) values (27, '20-Dec-2011', '18-Dec-2011', 'plata online');

19
 2. select * from Comanda
where id_comanda = 27;

Comanda UPDATE:

1. update Stoc set cantitate_stoc = 3000

where cantitate_stoc = 1000;

2. select * from Stoc

where id_stoc = 1;

20
 Capitolul 8. Concluzii

O baz de date este o colecie organizat de date. Nu ne putem imagina o afacere de

succes n ziua de azi far implementarea bazelor de date, deoarece acestea ofer un real
control asupra datelor, permind regsirea, sortarea, analizarea i rezumarea datelor,
precum i raportarea imediat a rezultatelor.

Avantajele bazelor de date relaionale sunt urmtoarele:

- Integritate ncorporat la mai multe nivele. Integritatea datelor este integrat n cadrul
modelului la nivel de cmp pentru a asigura precizia datelor. La nivel de tabel asigur
faptul c o nregistrare nu mai poate fi introdus nc o dat n baza de date, precum i
detectarea lipsei valorilor din cmpurile cheie primar. La nivel de relaie asigur
validitatea acestora ntre tabele. La nivel logic, asigur acurateea logic a datelor.
- Independena logic i fizic a datelor de programele aplicaie: nici modificrile
efectuate de ctre utilizator modelului logic al bazei de date, nici modificrile efectuate
de ctre productorul bazei de date implementrii fizice a acesteia, nu vor afecta
programele aplicaiilor care utilizeaz baza de date.
- Garanteaz consistena i precizia datelor: datele sunt consistente i precise datorit
multiplelor nivele de integritate ce pot fi introduse n baza de date.
- Extragerea cu uurin a datelor din baza de date. n urma comenzilor introduse de
ctre utilizator, datele din baza de date pot fi extrase fie dintr-un singur tabel, fie dintr-
o multitudine de tabele asociate prin intermediul relaiilor, ceea ce ofer posibilitatea
prezentrii datelor ntr-un numr nelimitat de moduri.

Acestea i alte avantaje au adus beneficii extrem de importante comunitii de

afaceri i tuturor acelora care au nevoie de colectarea i nmagazinarea de date.
Deocamdat, bazele de date relaionale dein supremaia pe piaa acestor produse, fiind
alese n cele mai multe dintre cazuri. Pn de curnd, cel mai mare dezavantaj al bazelor de
date relaionale l reprezenta faptul c programele aplicaie care le foloseau erau foarte
lente n execuie. Problema nu era una a bazelor de date relaionale, ci tehnologiei
deficitare de care se dispunea la momentul introducerii modelului. ncepnd cu anii 90
paii nainte fcui att n domeniul hardware ct i software au fcut ca o astfel de
problem s fie din ce n ce mai puin vizibil.

21
BIBLIOGRAFIE

1. Viorel Stoian, Notie de Curs, 2011

2. http://ro.wikipedia.org/wiki/Baz%C4%83_de_date
3. http://civile.utcb.ro/cmat/cursrt/bd.pdf
4. http://inf.ucv.ro/~popirlan/bd/laborator3.pdf
5. http://facultate.regielive.ro/cursuri/calculatoare/sistem-de-gestiune-a-
bazelor-de-date-107959.html
6. http://office.microsoft.com/ro-ro/access-help/notiuni-de-baza-despre-
proiectarea-bazelor-de-date-HA001224247.aspx
7. http://ro.wikipedia.org/wiki/MySQL
8. http://office.microsoft.com/ro-ro/training/get-to-know-access-
RZ006118141.aspx?section=2
9. http://www.google.ro/url?sa=t&rct=j&q=avantajele%20bazelor%20de
%20date&source=web&cd=10&ved=0CGUQFjAJ&url=http%3A%2F
%2Fwww.seap.usv.ro%2Fidd%2Fcursuri%2FCurs_7_rom.doc&ei=-
CsIT-znJsKI4gSK-
OSNCA&usg=AFQjCNEg2BftqTf0vcIOr8qlcljpoTXJkg&cad=rja

22