Baza de Date Cig

UNIVERSITATEA TEFAN CEL MARE SUCEAVA
FACULTATEA DE TIINE ECONOMICE I ADMINISTRAIE PUBLIC

SPECIALIZAREA : CONTABILITATE I INFORMATIC DE GESTIUNE
FORMA DE NVMNT : NVMNT LA DISTAN
PROF.UNIV.DR. VALERIU LUPU
BAZE DE DATE
CURS PENTRU NVMNT LA DISTAN
BAZE DE DATE
SUCEAVA 2010 2011
BAZE DE DATE
CUPRINS
1. Introducere
1.1. Evoluia organizrii datelor
1.1.1. Organizarea nregistrrilor n fiiere
1.1.2. Limitele tratrii bazate pe fiiere
1.1.3. Avantajele sistemelor de gestiune a bazelor de date
1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date
1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A
DATELOR
1.2.1. Independena datelor
1.2.2. Limbajele bazelor de date
1.2.2.1. Limbajul de definire a datelor
1.2.2.1.1. Definirea schemei n SQL
1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor
1.2.2.2. Limbajul de manipulare a datelor
1.2.2.2.1. Extragerea informaiilor din bazele de date
1.2.3. Alte caracteristici SQL
1.2.4. Query-By-Example (QBE)
1.3. SISTEME DE GESTIUNE A BAZELOR DE DATE
1.3.1. Componentele unui sistem de gestiune al bazelor de date
1.3.1.1. Componenta hardware
1.3.1.2. Componenta software
1.3.1.3. Date
1.3.1.4. Proceduri
1.3.1.5. Resursele umane
1.3.2. Componentele unui sistem de gestiune a bazelor de date
1.3.3. Funciile sistemelor de gestiune a bazelor de date
2. Modelarea datelor
2.1. Modele de date: reea, ierarhice, relaionale, obiectuale, hibrid
2.1.1. Istoricul bazelor de date
2.1.2. Funciile modelelor
2.1.3. Modele de date bazate pe nregistrri
2.1.3.1. Modelul ierarhic
2.1.3.2. modelul reea
2.1.3.3. modelul relational
2.1.4. Modele logice orientate pe obiecte
2.1.4.1. modelul entitate-relaie;
2.1.4.2. modelul orientat pe obiecte;
2.1.4.3. modelul obiectual-relaional;
2.1.5. Modele fizice de date
2.1.6. Avantajele bazelor de date relaionale
2.1.7. Chei
2.1.7.1. Cheia candidat
2.1.7.2. Cheia primar
2.1.7.3. Cheie alternativ
2.1.7.4. Cheie extern
3
BAZE DE DATE
2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server, distribuite

2.2.1. Introducere
2.2.2. Istoric
2.2.3. Modelul mainframe
2.2.4. Modelul integrat
2.2.4.1. Modelul File-server
2.2.4.2. Modelul Client-server
2.2.5. Baze de date distribuite
3.1. Bazele modelului relaional
3.1.1. Modelul conceptual
3.1.2. Modelul logic
3.1.3. Modelul fizic
3.2. normalizarea bazelor de date. Forme normale
3.2.1. Normalizarea
3.2.2. Forme normale
3.3. Regulile lui Codd
3.3.1. Regula informaiei
3.3.2. Regula de garantare a accesului
3.3.3. Valorile NULL
3.3.4. Catalog actualizat permanent pe baza modelului relaional
3.3.5. Regula de nelegere a sublimbajului de manipulare a datelor
3.3.6. Regula de actualizare a vederilor
3.3.7. Inserarea, actualizarea i eliminarea
3.3.8. Independena fizic de date
3.3.9. Independena logic de date
3.3.10. Independena integritii
3.4. Limbajul MYSQL
3.4.1. Descriere
3.4.2. Tipuri de operaii asupra bazelor de date
3.4.3. Tipuri de date in MySQL
3.4.4. Comenzi elementare MySQL
3.4.5. comenzi pentru interogarea bazelor de date
3.4.6. probleme rezolvate
3.4.7. probleme propuse
BAZE DE DATE
CONTINUT
1. INTRODUCERE N BAZE DE DATE
OBIECTIVE
Oferirea unei imagini sintetice i cuprinztoare a bazelor de date.

Cunoaterea evoluiei organizrii bazelor de date, bazat pe conceptul de dat, colecii de date i
fiiere.
Cunoaterea avantajelor bazelor de date.
Prezentarea interdependenelor n definirea i manipularea datelor prin intermediul limbajelor
bazelor de date.
Cunoaterea limbajului de definire a datelor utilizat la definirea structurii bazei de date.
Cunoaterea limbajului de manipulare a datelor utilizat la extragerea informaiilor prin
intermediul clauzelor (SELECT, FROM, WHERE, GROUP BY, HAVING), operaiilor
(RENAME, STRING, ORDER, DUPLICATE, SET, MODIFY) i funciilor agregat.
Oferirea de informaii referitoare la limbajul QBE (Query-By-Example).
Prezentarea sistemelor de gestiune a bazelor de date: definiie, obiective, componente, module i
funcii.
Data file 1
Data file 1
Application 1
Output 1
Application 2
Output 2
DBMS
Data file 1
2. MODELE I ARHITECTURI DE DATE

OBIECTIVE
Prezentarea n detaliu a modelelor de date: reea, ierarhic, relaional, obiect, hibrid.

Cunoaterea funciilor i componentelor modelului.
Deprinderea noiunilor i instrumentelor necesare comparrii modelelor bazate pe nregistrri
(reea, ierarhic, relaional) i a modelelor logice bazate pe obiecte (entitate-relaie, orientate pe
obiecte, orientate pe obiecte relaionale, binare, semantice, infologice i funcionale).
Cunoaterea avantajelor bazelor de date relaionale.
Cunoaterea rolului i importanei cheilor ntr-o baz de date.
Dezvoltarea unei vederi generale i implementarea cunotinelor specifice necesare comparrii
modelelor arhitecturale: mainframe, integrat, file-server, client-server i distribuit.
Logical child
relationship
Database 2
Database 1
5
BAZE DE DATE
3. MODELUL RELAIONAL DE DATE

OBIECTIVE
nsuirea noiunilor de baz ale unui model de date: definiii, clasificri.

nsuirea de cunotine referitoare la proiectarea modelului conceptual al unei baze de date n
cazul modelului relaional.
Crearea modelului logic de date pe baza modelului conceptual.
Utilizarea modelului fizic de date la descrierea reprezentrii datelor n ceea ce privete formatul,
nmagazinarea i calea de acces.
Proiectarea logic a unei baze de date cu ajutorul tehnicii normalizrii.
Cunoaterea conceptului de descompunere i a funciilor sale.
Cunoaterea dependenelor funcionale, multivalorice i de cuplare.
Cunoaterea formelor normale i utilizarea lor.
Prezentarea printelui modelului relaional; unde i n ce context Dr. E.F. Codd a creat cele 12
reguli.
nelegerea coninutului i importanei celor 12 reguli ale lui Codd.
FN 1
FN 2
FN 3
FNBC FN 4
FN 5
4. LIMBAJUL MYSQL AL BAZELOR DE DATE
OBIECTIVE
nsuirea de cunotine referitoare la limbajul de manipulare a datelor.
Utilizarea interogrilor simple i a interogrilor ce folosesc mai multe tabele.
Captarea de informaii referitoare la sistemele ce folosesc limbajul de interogare structurat al
datelor.
Definirea vederilor, cunoaterea rolurilor acestora precum i a modului lor de utilizare.
Cunoaterea de elemente referitoare la vederile simple, vederile agregat i vederile de validare.
Cunoaterea caracteristicilor vederilor.
Cunoaterea condiiilor n care se pot realiza actualizri n baza de date cu ajutorul vederilor.
CREATE VIEW v AS <expresie interogare>
BAZE DE DATE
Lucrari de laborator
1.
2.
3.
4.
5.
6.
Modelul Entitate-Relatie. Reprezentari.

Construirea unui model Entitate-Relatie.
Procesul de normalizare. 1a, a 2a si a 3a forma normala.
Procesul de normalizare. Forma normala Boyce-Codd si a 4a si a 5a forma normala.
Utilizarea MySQL. Adaugarea fisierelor si alegerea tipurilor de date.
Definirea relatiilor si setarea optiunilor de integritate referentiala. Lucrul cu interogari. Inserarea
si stergerea datelor din baza de date.
7. Utilizarea MySQL Server. Crearea tabelelor si relatiilor.
8. Utilizarea MySQL Server. Inserarea si stergerea datelor din baza de date.
9. Utilizarea MySQL Server. Obiecte din bazele de date.
10. Vederi. Crearea si stergerea vederilor.
BAZE DE DATE
1.1. Evoluia organizrii datelor

Societatea contemporan, caracterizat prin afluxul fr precedent de informaie de diferite tipuri i
pe diverse canale, necesit strategii i instrumente din ce in ce mai complexe pentru stocare,
procesare i, mai ales, interpretare. In acest context, se pune problema transformrii informaiei n
date i organizarea acestora ntr-o asemenea manier nct n orice moment s poat fi extrase, cu
promptitudine i exactitate, datele favorabile realizrii unui scop specific.
Datele sunt fapte culese din lumea real. Ele sunt preluate din msurtori i observaii i constituie
orice mesaj primit de un receptor sub o anumit form. O percepie a lumii reale poate fi privit ca o
serie de obiecte sau fenomene distincte sau interdependente.
Datele n sine nu au nici un fel de semnificaie. Mai mult dect att, nefiind altceva dect o niruire
de litere i cifre, ele pot primi diverse interpretri, cele mai multe dintre ele fiind, de obicei, greite.
Datele se refera la numere, fapte, diferite documente etc. Informaiile se refer la date organizate,
date care au fost filtrate i ordonate dup anumite criterii. Dorina oricrui utilizator este obinerea
de informaie i nu manipularea unor date seci. Un model de date corect alctuit ofer posibilitatea
transformrii informaiilor n date i a acestora napoi n informaii fr a denatura sensul lor iniial.
A obine informaie nseamn, de fapt, a introduce datele disponibile ntr-un anumit context
conferindu-le n acest fel o anume semnificaie. Ceea ce se nmagazineaz ntr-o baz de date, aa
cum am artat, sunt datele care au o natur static n sensul c ele rmn n aceeai stare pn n
momentul modificrii lor de ctre administratorul bazei de date prin intermediul unui proces manual
sau automat. Pentru ca datele s poat fi transformate n informaie ele trebuie organizate astfel
nct s poat fi prelucrate efectiv. Pentru a determina n cazul unei aplicaii modul de organizare a
datelor, trebuie determinate acele caracteristici ale datelor care permit extragerea esenei
nelesului lor.
O mulime formal i consistent de reguli definete un model de date.
Pentru o aplicaie particular a unui model de date, numele obiectelor bazei de date mpreun cu
proprietile lor i asocierile dintre ele se numete schem.
Un ansamblu de date organizat dup anumite criterii reprezint o colecie de date.
O colecie de obiecte care au identitate proprie i sunt caracterizate de o condiie de apartenen se
numete mulime.
Procesul de definire i structurare a datelor n colecii, gruparea lor precum i stabilirea elementelor
de legtur dintre componentele coleciei i ntre colecii reprezint organizarea datelor.
Fiierul este o colecie de date organizate pe criterii calitative, de prelucrare i de scop. Un fiier
reprezint o colecie de date aflate n asociere ce are o denumire i care este reprezentat, de obicei,
cu ajutorul unei secvene de bytes sub forma celor dou vederi:
Vederea logic: reprezint felul n care utilizatorul vede fiierul;
Vederea fizic: reprezint felul n care fiierul este stocat n memoria extern a
calculatorului.
Aceste dou vederi pot fi, evident, foarte diferite ntre ele.
O baz de date reprezint o colecie integrat i structurat de date operaionale nmagazinate pe un
mediu de stocare. Elsmari i Navathe definesc o baz de date sub forma unei colecii de date aflate
n asociere. Scopul unei baze de date este acela de a nmagazina datele n aa fel nct s se poat
obine informaia dorit n orice moment. Informaiile, spre deosebire de date, au un caracter
dinamic n sensul c ele se modific n funcie de datele nmagazinate n baza de date, dar i n
sensul c ele pot fi procesate i prezentate n diverse feluri.
BAZE DE DATE
Pentru a face diferena dintre date i informaii, Hernandez propune urmtoarea axiom:
Datele reprezint ceea ce se nmagazineaz; informaia reprezint ceea ce se extrage.
Cu alte cuvinte, datele trebuie extrase n aa fel din baza de date nct s capete semnificaie.
Evoluia n timp a metodelor de organizare a datelor e legat de soluiile tehnice de nmagazinare a
acestora i cuprinde nivelele:
1. Nivelul I - organizarea datelor n fiiere clasice;
2. Nivelul II - organizarea mixt n fiiere;
3. Nivelul III - organizarea datelor n bazele de date clasice;
4. Nivelul IV - organizarea datelor n bazele de date relaionale;
5. Nivelul V - organizarea datelor n baze de date distribuite.
n cadrul acestei evoluii se disting etapele:
Etapa I - este perioada caracterizat de nregistrarea datelor pe benzi magnetice. Aceast etap se
apropie mult de sistemul manual de organizare a datelor (ndosariere - datele sunt
organizate, n principal, sub form de fiiere secveniale datorit suportului magnetic
(benzi)). Programatorii erau nevoii s efectueze o serie de operaii de gestiune a
datelor, datorit puternicei legturi dintre aplicaii i date.
n aceast etap se remarc urmtoarele caracteristici:
- structura logic coincide cu cea fizic i, prin urmare, programatorul trebuie s
descrie i organizarea fizic a datelor pe suport, lucru incomod, la schimbarea
suportului;
- prelucrarea se face pe loturi;
- dependena aplicaiilor fa de date (o modificare n structura datelor sau a
dispozitivului de memorare implic modificri ale programelor de aplicaie i
recompilarea lor i, ca urmare, trebuie ca datele s fie redefinite n cadrul aplicaiei
ori de cte ori apare o modificare n structura bazei de date);
- redundan mare n memorarea datelor datorit faptului c aceleai date sunt
memorate separat pentru fiecare aplicaie ce are nevoie de ele;
- legturile dintre fiiere trebuie specificate n cadrul programelor aplicaie;
- fiecare aplicaie are propriile date i este singura care le poate folosi;
- programele realizeaz numai operaii simple de intrare/ieire.
Etapa a II-a - este caracterizat de nregistrarea datelor pe discul magnetic. Datele se pot organiza
acum att n fiiere secvenial-indexate ct i n fiiere cu acces direct. Anterior
acestei etape datele erau nmagazinate n fiiere obinuite, fie n format ISAM
(Indexed Sequential Access Method) fie n format VSAM (Virtual Storage Access
Method). Datele sunt nmagazinate i extrase acum n uniti numite blocuri sau
pagini. Spre deosebire de nmagazinarea n memoria RAM, timpul necesar
extragerii unei pagini difer n funcie de localizarea acesteia pe disc.
Caracteristicile corespunztoare acestei etape sunt:
- structura logic nu mai coincide cu cea fizic, ceea ce face ca programatorul s nu
mai fie nevoit s descrie i organizarea fizic a datelor pe suport, acest lucru fiind
fcut de ctre componentele specializate ale sistemului de operare;
- prelucrarea se face online sau n timp real;
- schimbarea unitii de memorare nu implic modificarea programelor;
- se menine redundan mare deoarece, de multe ori, aceleai date sunt pstrate n
mai multe fiiere;
- datele sunt nestructurate;
- mentenana bazei de date are un cost foarte ridicat;
9
BAZE DE DATE
-
se menine dependena aplicaiilor fa de date, accesul la date fiind foarte dificil;

datorit acestei dependene, aplicaiile noi sunt greu de proiectat;
se ofer o interfa de programare, numit API (Application Programming
Interface);
accesul se face la nivel de nregistrare i nu de cmp n cadrul nregistrrii;
nu se realizeaz accesul dup chei multiple;
controlul concurenei este limitat;
legturile ntre fiiere trebuie programate, ceea ce presupune definirea i
deschiderea fiecrui fiier, accesarea datelor din primul fiier, prin intermediul cii
de acces ce trebuie s apar n cadrul programului, dup care se acceseaz cel de-al
doilea fiier, .a.m.d.; deoarece aceste fiiere au un format fix, modificarea
structurii unui astfel de fiier reprezint un proces extrem de lent (mai nti se
transform datele, apoi fiierul trebuie redefinit n cadrul fiecrei aplicaii care l
acceseaz, fiind posibil chiar schimbarea cii de acces spre acesta n cadrul
fiecrei aplicaii).
Etapa a III-a - este caracterizat de apariia bazelor de date. Datele se pot organiza acum sub forma
unor fiiere integrate. Acestea permit realizarea mai multor fiiere logice pe baza
acelorai date fizice.
Caracteristici corespunztoare acestei etape sunt:
- organizarea fizic a datelor e independent de programele de aplicaii;
- se pot constitui fiiere logice n funcie de baza de date;
- se remarc un control integrat al datelor prin:
- reducerea redundanei datelor fiind posibil folosirea n comun a acelorai date
fizice de ctre mai multe aplicaii;
- accesul la date la nivel de cmp;
- eliminarea inconsistenelor;
- asigurarea controlului concurenei;
- asigurarea integritii datelor;
- gestiunea datelor;
- introducerea standardelor de disponibilitate a sistemelor;
- mbuntirea securitii datelor;
- asigurarea accesului la date dup chei multiple;
- organizarea datelor e realizat de o component software (data management);
- creterea independenei datelor, prin asigurarea transparenei detaliilor referitoare
la organizarea conceptual, structurile de stocare i strategiile de acces ale
utilizatorilor la:
- nivel logic:
- transparena organizrii conceptuale;
- transparena strategiilor logice de acces;
- nivel fizic:
- transparena organizrii nmagazinrii fizice;
- transparena cilor fizice de acces.
Etapa a IV-a - se caracterizeaz prin asigurarea independenei logice i fizice a datelor fa de
programele de aplicaie. Aceasta se realizeaz prin intermediul administratorului
de baze de date cu ajutorul descrierii datelor la un nivel logic global.
Caracteristicile specifice acestei etape sunt:
- datele sunt descrise la nivel logic global;
10
BAZE DE DATE
- existena unor fiiere inverse ce permit rspunsul rapid la ntrebri formulate de

utilizatori;
- mrirea gradului de protecie i securitate a datelor;
- n afara independenei fizice a datelor apare i independena logic prin
posibilitatea existenei unor modificri n structura logic fr a afecta aplicaiile;
- creterea controlului concurenei, prin existena mai multor vederi asupra datelor
oferite utilizatorilor;
- posibilitatea introducerii standardizrii prin centralizarea gestiunii datelor cu
ajutorul definiiilor n cadrul cataloagelor;
- creterea calitii datelor prin introducerea constrngerilor suplimentare n cadrul
bazei de date;
- redundana datelor este redus la minim.
1.1.1. Organizarea nregistrrilor n fiiere
Cea mai eficient i rapid cale de a lucra cu datele existente ntr-o baz de date ar fi aceea de
pstrare a tuturor acestor date n memoria intern a sistemului. Pstrarea tuturor datelor din baza de
date n memoria intern a sistemului nu se poate face datorit faptului c, pe de o parte memoria
intern este foarte scump, iar pe de alt parte aceasta este volatil, motiv pentru care datele trebuie
pstrate pe un suport magnetic extern. Prin urmare se impune stabilirea unei strategii de lucru cu
datele aflate n baza de date, dup cum urmeaz:
- datele utilizate n mod curent se pstreaz n memoria RAM a sistemului;
- restul datelor se pstreaz n memoria extern a sistemului (nmagazinare secundar);
- copiile de siguran a datelor se pstreaz pe benzi magnetice (nmagazinare teriar).
Pentru a organiza nregistrrile unei baze de date n cadrul fiierelor se pot folosi mai multe
modaliti:
- organizare n fiiere heap; n acest caz, orice nregistrare poate fi plasat oriunde se gsete loc
n cadrul fiierului, nefiind impus o anumit ordine;
- organizare secvenial; n acest caz nregistrrile sunt stocate ntr-o anumit ordine impus de
valoarea cheii de cutare a fiecrei nregistrri;
- organizare n fiiere hash; n acest caz se folosete o funcie hash care se aplic atributelor
fiecrei nregistrri; rezultatele obinute arat blocul din cadrul fiierului n care trebuie s se
afle o anumit nregistrare, fiind strns legate de structura de indexare folosit;
- organizarea fiierelor n grupuri; nregistrrile ce provin din mai multe tabele pot fi pstrate n
acelai fiier; nregistrrile asociate din tabele diferite sunt pstrate n acelai bloc astfel nct
operaiile de intrare/ieire pot parcurge nregistrrile asociate din toate tabelele.
n continuare se vor prezenta cteva caracteristici suplimentare ale fiierelor secveniale i ale celor
organizate n grupuri.
Organizarea secvenial a fiierelor
Un fiier secvenial este foarte util la prelucrarea nregistrrilor aflate ntr-o ordine predefinit pe
baza unei chei de cutare.
nregistrrile din cadrul unui astfel de fiier sunt asociate pe baza unor pointeri ce permit extragerea
rapid a datelor pe baza cheii de cutare. nregistrrile sunt nmagazinate fizic n ordinea stabilit pe
baza cheii de cutare, ceea ce duce la minimizarea numrului de blocuri ce trebuie accesate, ns
este dificil de pstrat aceast ordine pe msur ce se fac introduceri sau tergeri de nregistrri.
tergerile pot fi gestionate cu ajutorul lanului de pointeri, dar inserrile pun probleme dac nu
exist spaiu n locul n care trebuie plasate nregistrrile. n cazul n care spaiul necesar plasrii
11
BAZE DE DATE
unei noi nregistrri este disponibil n locul indicat, nregistrarea poate fi plasat n acel loc, altfel ea
trebuie plasat n alt loc, iar pointerii trebuie reorganizai. n aceast situaie anumite nregistrri nu
se vor afla n ordinea fizic specificat. Dac numrul de nregistrri care nu se afl n ordinea fizic
specificat este mic, nu vor exista probleme deosebite, dar dac acest numr crete prea mult
pointerii trebuie reorganizai, ceea ce presupune un mare consum de resurse i, prin urmare, astfel
de operaii trebuie efectuate numai atunci cnd sistemul nu este deloc sau este slab solicitat. Dac
inserrile se fac rar, fiierul poate fi pstrat n ordinea fizic stabilit iniial, reorganizarea
pointerilor fcndu-se la apariia oricrei noi inserri, caz n care nu mai sunt necesare cmpurile de
pointeri.
Organizarea fiierelor n grupuri
O situaie foarte bun se ntlnete atunci cnd, n bazele de date de mici dimensiuni, fiecare tabel
se afl ntr-un fiier separat, iar nregistrrile au o lungime fix, ceea ce va conduce la reducerea
dimensiunii programelor. Multe dintre sistemele de baze de date utilizate pe scar larg nu folosesc
n mod direct sistemul de operare pentru gestiunea fiierelor. n aceast situaie, bazei de date i este
alocat un singur fiier de mari dimensiuni, toate tabelele fiind pstrate n cadrul unui singur fiier. O
astfel de structur pune la un loc nregistrri din mai multe tabele, permind prelucrarea eficient a
jonciunilor. Dac nregistrrile nu pot fi plasate toate ntr-un singur bloc, cele rmase vor apare n
blocurile adiacente. Structura, cunoscut sub numele de grup, permite citirea celor mai multe dintre
nregistrri cu ajutorul unui singur bloc.
Utilizarea grupurilor este foarte util n cazul prelucrrii particulare a unui anumit tip de jonciuni,
dar poate conduce la scderea performanelor n cazul altor tipuri de interogri.
nmagazinarea metadatelor n catalog
Informaiile referitoare la obiectele bazei de date sunt pstrate n alte tabele cunoscute sub numele
de catalogul bazei de date, care conine:
- denumirile tabelelor;
- denumirile cmpurilor tabelelor;
- domeniile de valori i lungimea cmpurilor;
- denumirile u definiiile vederilor;
- constrngerile de integritate (informaii despre cheile primar i extern).
Catalogul mai conine date despre utilizatorii sistemului (numele i condiiile de acces ale
acestora), precum i (posibil) date descriptive i statistice, cum ar fi:
- numrul de nregistrri din fiecare tabel;
- metoda de stocare folosit n cazul fiecrui tabel (de exemplu, n grup).
De asemenea mai trebuie pstrate date referitoare indecii folosii n cadrul fiecrui tabel
(denumirea indexului, denumirea tabelului pe care se aplic indexul respectiv, tipul indexului,
cmpurile pe care se aplic indexul). Se poate spune c, de fapt, toate aceste date formeaz o alt
baz de date n miniatur. Baza de date poate fi folosit pentru a nmagazina date despre propria
structur, ceea ce va conduce la o structur mai complex a sistemului, permind utilizarea la
maxim a puterii bazei de date prin asigurarea accesului rapid la datele sistemului.
Modalitatea optim de reprezentare a datelor sistemului poate fi aleas de ctre proiectantul
sistemului, o posibil reprezentare fiind urmtoarea:
Schema catalogului sistemului = (nume tabel, numr de atribute).
Schema atributelor = (nume atribut, nume tabel, tip de dat, poziie, dimensiune).
Schema utilizatorului = (nume utilizator, cont de utilizator, cheia de criptare, grup).
Schema de indexare = (numele indexului, numele tabelului, tipul indexului, atributul indexului).
Schema vederii = (numele vederii, definirea vederii).
12
BAZE DE DATE
1.1.2. Limitele tratrii bazate pe fiiere

n general acestea sunt marcate de:
1. Separarea i izolarea datelor.
2. Dublarea datelor.
3. Dependena datelor.
4. Incompatibilitatea fiierelor.
5. Interogri statice.
Separarea i izolarea datelor

Cu sistemele de fiiere e dificil o prelucrare a datelor atunci cnd acestea sunt izolate n fiiere
separate. n acest caz programatorul trebuie s sincronizeze prelucrarea a dou sau mai multe fiiere
pentru a se asigura c datele extrase sunt cele corecte. Dificultatea este cu att mai mare cu ct
datele necesare se afl n mai multe fiiere.
Dublarea datelor
Se manifest prin faptul c aceleai date se pot afla n dou sau mai multe fiiere n funcie de
numrul aplicaiilor sau al utilizatorilor. n aceast situaie pot apare o serie de probleme, cum ar fi:
a) creterea costurilor prin creterea spaiului de memorare a datelor;
b) apariia inconsistenei datelor prin faptul c o anumit dat poate fi
memorat n mai multe locuri; atunci cnd exist mai multe copii ale
aceleiai date e posibil ca prin actualizarea unora dintre ele s existe valori
diferite ale acelorai date (inconsisten); inconsistena mai poate apare i la
introducerea greit a unor date;
c) imposibilitatea introducerii unor standarde;
d) imposibilitatea aplicrii restriciilor de securitate;
e) imposibilitatea meninerii integritii datelor (consisten i validare).
Dependena datelor
Structura fizic i stocarea fiierelor de date i nregistrrilor sunt definite n codul aplicaiei.
Aceasta nseamn c orice modificare efectuat n structura existent impune scrierea unui program
de tip exe-off (adic un program ce este rulat o singur dat, dup care poate fi nlturat). Acest
program trebuie:
a) s deschid fiierul iniial pentru a fi citit;
b) s creeze un fiier temporar cu noua structur;
c) s citeasc o nregistrare din fiierul iniial, s transforme datele pentru a le
ncadra n noua structur i s scrie fiierul temporar. Acest lucru trebuie
repetat pentru toate nregistrrile din fiierul iniial;
d) s tearg fiierul iniial;
e) s redenumeasc fiierul temporar cu numele fiierului iniial;
f) s modifice toate programele ce apeleaz fiierul iniial pentru a se conforma
noii structuri.
Toate aceste operaii necesit mult timp i sunt supuse pericolului de apariie a erorilor. Dac
structura unui fiier trebuie modificat, trebuie modificat i programul care l folosete, deoarece
programul tie prea multe lucruri despre structura acestuia. Diferena dintre conceptul de fiier i
cel de baz de date este reprezentat n figurile urmtoare:
13
BAZE DE DATE
Date fiier 1
Aplicaie 1
Rezultat 1
Aplicaie 2
Rezultat 2
Date fiier 1
Date fiier 1
Figura 1.1. Fiiere: dependena aplicaie/date
Date fiier 1
Date fiier 1
Aplicaie 1
Rezultat 1
Aplicaie 2
Rezultat 2
SGBD
Date fiier 1
Figura 1.2. Baze de date: independena aplicaie/date
Formate de fiiere incompatibile

Este posibil ca fiecare fiier s fie apelat de ctre un program scris ntr-un limbaj de programare
diferit. n acest caz se impune s se scrie un program de transformare a fiierelor ntr-un format
comun astfel nct s se poat face prelucrarea datelor din mai multe fiiere, deoarece fiecare limbaj
de programare necesit un anumit tip de fiier.
Interogarea static a programelor aplicaie

n cazul n care apar noi cereri de interogare a datelor aflate n fiiere, trebuie rescrise programele
existente, deoarece, altfel, nu se poate rspunde dect la ntrebrile existente. n cazul rescrierii
programelor pot apare urmtoarele deficiene:
a) documentaie limitat i dificil de ntreinut;
b) afectarea securitii i integritii datelor;
c) refacerea datelor dup defectarea sistemului e limitat sau inexistent;
d) accesul la fiiere e restrns la cte un utilizator odat.
n concluzie, limitrile tratrii bazate pe fiiere se datoreaz factorilor:
a) definiia datelor e ncorporat n programele aplicaie, n loc s fie stocat
separat i independent;
b) nu exist control al accesului i manipulrii datelor, n afara celui impus de
ctre programele aplicaie.
14
BAZE DE DATE
1.1.3. Avantajele sistemelor de gestiune a bazelor de date

Avantajele sistemelor de gestiune a bazelor de date fa de sistemele clasice, cu fiiere sunt
urmtoarele:
1. Controlul redundanei datelor
Risipa de spaiu care se face prin stocarea acelorai informaii n mai multe fiiere este mult
diminuat prin utilizarea bazelor de date, dar nu complet eliminat datorit altor cereri de
mbuntire a performanelor.
2. Coerena datelor
Dac un articol de date e nmagazinat de mai multe ori trebuie s se garanteze c toate copiile
acestuia vor fi actualizate dac se reactualizeaz o valoare a sa (valoarea articolului e aceeai pentru
toate copiile sale).
3. Mai multe informaii de la aceeai cantitate de date
Se pot obine prin integrarea fiierelor ce conin informaii diferite despre aceleai date.
4. Partajarea datelor
Datele pot fi utilizate de ctre mai muli utilizatori n acelai timp. De asemenea se pot face
modificri sau adugiri la baza de date existent fr a fi necesar definirea repetat a tuturor
cerinelor referitoare la acestea.
5. Integritatea crescut a datelor
Se refer la validitatea i coerena datelor nmagazinate i se exprim prin constrngeri (reguli de
coeren). Constrngerile se pot aplica articolelor de date din cadrul unei singure nregistrri sau
relaiilor dintre nregistrri.
6. Securitatea crescut
Se realizeaz prin atribuirea unor nume de utilizatori i parole ce permit identificarea persoanelor
autorizate s foloseasc baza de date i impun modalitatea de utilizare a acestor date.
7. Aplicarea standardelor
Se refer la formatul datelor, conveniile privind denumirile, documentarea, procedurile de
reactualizare, regulile de acces.
8. Reducerea costurilor
Prin realizarea integrrii se aloc fonduri centralizat i nu separat fiecrui departament.
9. Rezolvarea conflictelor
Fiecare utilizator va avea propriile cerine ce pot intra n conflict cu ale altora. Administratorul
bazei de date poate lua decizii ce duc la utilizarea optim a resurselor.
10. Creterea accesibilitii datelor i a capacitii de rspuns
Se realizeaz prin intermediul utilizrii limbajelor de programare din generaia a IV-a (ex. SQL,
QBE).
15
BAZE DE DATE
11. Creterea productivitii

Prin furnizarea unor funcii ce permit manipularea fiierelor i a introducerii limbajelor de
programare din generaia a IV-a ce reduc mult timpul de programare.
12. Independena datelor
Duce la creterea capacitii de ntreinere prin faptul c descrierile datelor sunt separate de
aplicaii.
13. Controlul concurenei este mbuntit
Se garanteaz c dac doi sau mai muli utilizatori acceseaz simultan aceleai date nu se pierd
informaii sau nu se altereaz integritatea acestora.
14. Asigurarea salvrii de siguran i a refacerii
Prin recuperarea ultimei stri coerente a bazei de date n cazul apariiei unei defeciuni hard sau
soft.
1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date

1. Complexitatea
Trebuie avute n vedere o serie de probleme referitoare la date care se manifest suplimentar fa de
cazul aplicaiilor clasice. Se face mai nti o analiz amnunit a datelor i apoi a aplicaiei propriuzise.
2. Dimensiunea
SGBD-urile ocup mult spaiu pe disc.
3. Costul
a) sistemelor SGBD;
b) elementelor hard achiziionate;
c) conversiei aplicaiilor existente la noul SGBD i noua configuraie hard.
4. Performana
Este mai redus n cazul utilizrii SGBD-urilor care au un caracter mai general, n locul unei
aplicaii simple bazat pe fiiere care apeleaz o singur funcie.
5. Efectul unei defeciuni
Este mult mai mare datorit centralizrii (o defeciune minor afecteaz toi utilizatorii).
1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A

DATELOR
Pornind de la lucrrile lui Codd referitoare la modelul relaional i la limbajele bazate pe algebra
relaional sau calculul relaional, comunitatea internaional a fcut, n timp, mari eforturi de
redefinire i mbuntire a acestor concepte. n acest sens au fost dezvoltate o serie de versiuni ale
limbajelor relaionale, cum ar fi SQL (Structured Query Language), QBE (Query-By-Example) i
QUEL (Query Language).
SQL i are originile n anul 1974 cnd IBM l-a folosit pentru prima dat n proiectul su de
cercetare System R care funciona pe sisteme mainframe VS/2 sub denumirea de Structured English
16
BAZE DE DATE
Query Language (sau SEQueL). Ulterior numele i-a fost schimbat n SQL (Structured Query
Language, pronunat sequel sau S-Q-L). Produsele ulterioare ale firmei IBM, SQL/DS i, apoi,
popularul DB2 folosesc acest limbaj. SQL se bazeaz pe calculul relaional ce are n vedere
utilizarea de variabile constituite din tupluri. n 1986, Institutul Naional American pentru Standarde
(ANSI) a elaborat i lansat standardele SQL contribuind astfel la extinderea acestuia n ntreaga
comunitate a productorilor de baze de date care, dei are numeroase variante, folosete totui
acelai set de comenzi i structuri de baz standardizate.
Instane i scheme
Bazele de date se modific des n decursul timpului. Datele aflate ntr-o baz de date la un anumit
moment dat alctuiesc o instan a acelei baze de date. Proiectul general al bazei de date este
denumit schema bazei de date. O schem reprezint o descriere a datelor conform modelului de
date propus. Schema bazei de date reprezint ceea ce n limbajele de programare clasice este
cunoscut sub numele de definirea tipurilor de date, iar instana unei baze de date este ceea ce n
limbajele de programare clasice este cunoscut sub denumirea de valoarea unei variabile.
Schema bazei de date reprezint descrierea general a bazei de date i conine:
- informaiile fizice de proiectare;
- informaii referitoare la utilizator;
- descrieri de nivel nalt ale tranzaciilor i aplicaiilor precum i legturile utilizatorilor cu ele;
- relaiile dintre date i tranzacii;
- statistici de utilizare.
n funcie de nivelul de abstractizare corespunztor exist urmtoarele tipuri de scheme:
1. Schema extern (subschema) se afl la nivel superior i corespunde unei valori a datelor. Ea
descrie vederile bazei de date ce se folosesc ntr-o anumit aplicaie i corespunde schemei
conceptuale. Schema reprezint vederea utilizatorilor asupra datelor (aplicaia).
2. Schema conceptual (logic) corespunde nivelului conceptual i descrie articolele, relaiile i
constrngerile dintre ele. Ea este o descriere abstract i integrat a tuturor datelor, independent
de sistemul de gestiune al bazelor de date folosit i trebuie s corespund schemei interne.
Schema reprezint perspectiva sistemului de gestiune al bazelor de date.
3. Schema intern se afl la nivel inferior i conine definiiile tuturor nregistrrilor stocate n
baza de date, metodele de reprezentare, cmpurile i indexurile datelor (descrie modul de
stocare fizic a datelor precum i structurile de acces la date). Schema reprezint perspectiva
realizrii sistemului/implementrii.
Sistemul de gestiune al bazelor de date efectueaz corespondene ntre cele trei tipuri de scheme
pentru a le corela. Dac se produce o modificare la nivel fizic, schema intern trebuie modificat,
dar schema conceptual poate rmne neatins. Corespondenele efectuate ntre vederile
utilizatorilor (nivelul extern) i stocarea fizic a datelor (nivelul intern) ajut la ascunderea
complexitii nivelului fizic, ceea ce face s creasc flexibilitatea i posibilitile de adaptare.
Sistemul SGBD trebuie s verifice dac fiecare schem extern poate fi derivat din schema
conceptual. Pentru a stabili corespondena dintre fiecare schem extern i cea intern, sistemul
trebuie s foloseasc informaiile din schema conceptual.
Schema relaional
Structura relaional a unei baze de date mai este cunoscut i sub denumirea de schem relaional
(sau metastructur datorit faptului c ea descrie structura datelor). O schem relaional reprezint
o descriere a unei colecii particulare de date, folosind un anumit model dat. Aceasta predefinete
posibilele stri ale bazei de date, n sensul c nici o stare a unei baze de date nu poate conine date
care s nu fie obinute n urma instanierii schemei respectivei baze de date i nici o stare a unei
baze de date nu poate conine o asociere ntre dou seturi de date dac aceast asociere nu a fost
definit n schema bazei de date. n plus, procedurile de manipulare a datelor trebuie s fie separate
17
BAZE DE DATE
de date. Modelul relaional al datelor este cel mai utilizat model pe plan mondial la ora actual.
Conceptul de baz ce fundamenteaz acest model este relaia, transformat ntr-un tabel ce conine
rnduri i coloane. Fiecare relaie are o schem ce descrie coloanele sau cmpurile tabelului. n
practic, schema bazei de date conine:
a. definiia tipurilor de date;
b. definiia relaiilor, specificnd pentru fiecare dintre ele:
- intensia (numele tuturor atributelor);
- cheia primar.
De obicei, ntr-un sistem relaional att schema conceptual ct i schema extern sunt relaionale.
Pentru a prezenta proiectul unei baze de date independent de orice limbaj de definire a datelor, de
obicei, se folosete o notaie general acceptat care are formatul:
<nume relatie>: <lista numelor atributelor>
O astfel de notaie este util n scopul clarificrii organizrii generale a bazei de date, dar nu
lmurete o serie de detalii referitoare, n special, la proprietile domeniilor de valori ale
atributelor. O definire mai complet care utilizeaz limbajul de definire a datelor se poate face cu
ajutorul notaiei originale propus de Codd, n care componentele sunt descrise n amnunt. Cu
ajutorul acestei notaii se pot crea entitile, atributele, domeniile de valori precum i cheile sub
forma unor entiti ale schemei bazei de date. Un astfel de limbaj definete doar structura acestor
entiti, nu i coninutul lor.
1.2.1. Independena de date

Reprezint faptul c nivelele superioare nu sunt afectate de modificrile fcute la nivelele
inferioare. Aceasta nseamn i faptul c vederea unui utilizator (schema extern) este complet
independent de vederea altui utilizator, ceea ce are un efect extrem de favorabil n cazul
modificrilor efectuate de ctre administratorul bazei de date (ce pot apare ca urmare a cererilor
venite din partea utilizatorului respectiv, ca urmare a necesitilor de adaptare a sistemului la noile
condiii sau ca urmare a dorinei de optimizare a funcionrii sistemului) care poate face modificri
ale vederii unui singur utilizator fr a afecta vederile celorlali utilizatori. Conform arhitecturii
propuse de organizaiile ANSI/SPARC se ofer dou nivele de independen a datelor:
1. Independena logic de date
2. Independena fizic de date.
Independena logic de date
Se refer la imunitatea schemelor externe fa de modificrile efectuate n schema conceptual.
Modificrile din schema conceptual pot fi:
a. adugarea sau eliminarea de noi entiti;
b. adugarea sau eliminarea de atribute;
c. adugarea sau eliminarea de relaii.
Independena logic de date nseamn c se pot face modificri n schema conceptual fr a fi
necesar schimbarea schemei externe existente sau rescrierea programelor de aplicaie. Modificrile
nu trebuie s afecteze toi utilizatorii ci doar pe aceia pentru care s-au fcut. Acetia trebuie
informai de acest lucru.
Independena fizic de date
Se refer la imunitatea schemei conceptuale fa de modificrile efectuate n schema intern.
Modificrile din schema intern pot fi:
a. organizare diferit a fiierelor;
b. structuri de stocare diferite;
c. dispozitive de stocare diferite;
d. indexuri sau algoritmi diferii.
18
BAZE DE DATE
Modificrile fcute n schema intern se fac cu scopul mbuntirii performanelor bazei de date.
Independena de date este un concept care rmne de multe ori un deziderat greu de realizat, chiar i
n cazul sistemelor din ce n ce mai performante ale zilelor noastre. Totui, bazele de date
relaionale, datorit limbajelor relaionale pe care le folosesc, ofer un nalt grad de independen
fa de date. Dei, aa cum am artat, ntr-un sistem relaional att schema conceptual ct i cea
extern sunt, ambele, relaionale, totui, schema conceptual se construiete cu ajutorul unor
instrumente ce au un caracter mult mai general dect cel oferit de modelul relaional.
Presupunnd, de exemplu, c o vedere nu mai este necesar unui utilizator, datorit faptului c
anumite atribute nu mai sunt de actualitate, alte atribute din baza de date prezentnd interes pentru
acesta, se poate efectua o modificare n clauza SELECT pentru a rspunde cererii de modificare.
Att timp ct fiecare vedere este definit separat n funcie de schema conceptual i att timp ct
schema conceptual nu se modific, orice vedere creat pe baza acelei scheme poate fi actualizat
fr a afecta celelalte vederi.
Independena de date se mai folosete i atunci cnd se dorete s se obin o independen a
vederilor utilizatorilor fa de schema conceptual. De obicei, dac relaiile i atributele la care se
face referire n definiia vederii nu sunt eliminate cu ocazia unei modificri, vederea nu va fi
afectat de modificare. n acest fel, cererile suplimentare de modificare pot fi efectuate fr teama
c ele ar putea afecta aplicaiile existente care folosesc acea baz de date.
n sfrit, independena de date se mai refer i la faptul c este posibil modificarea schemei prin
care se realizeaz nmagazinarea fizic a datelor, fr a afecta schemele conceptual, respectiv
extern.
1.2.2. Limbajele bazelor de date

Pentru a construi o baz de date un utilizator trebuie s:
a. defineasc schema bazei de date;
b. aplice o colecie de operatori pentru a crea, nmagazina, extrage i modifica datele.
Un sistem de gestiune al bazelor de date obinuit trebuie s ofere o serie de instrumente care s
uureze activitile specificate anterior. n acest sens, SQL trebuie s fie limbajul standard relaional
al bazei de date, avnd urmtoarele componente:
a. un limbaj de definire a datelor (Data Definition Language DDL), utilizat la definirea schemei
bazei de date
b. un limbaj de manipulare a datelor (Data Manipulation Language DML), care permite
utilizatorului manipularea obiectelor bazei de date i a relaiilor dintre acestea, n contextul
schemei bazei de date.
Aceste limbaje pot diferi de la un productor la altul n cadrul modelului pe care acetia l folosesc
datorit aspectelor legate de complexitate, funcionalitate i uurina n exploatare (interfaa
utilizator). De multe ori aceste limbaje sunt denumite sublimbaje de date deoarece nu includ
construcii pentru toate necesitile de calcul cum sunt cele asigurate de limbajele de nivel nalt.
Majoritatea sistemelor de gestiune a bazelor de date au ncorporat sublimbajul ntr-un limbaj de
programare de nivel nalt (ex. C++). n acest caz limbajul de nivel nalt este numit limbaj gazd.
1.2.2.1. Limbajul de definire a datelor

Permite administratorului bazei de date sau utilizatorului s descrie i s denumeasc entitile din
baza de date precum i relaiile ce pot exista ntre diferitele entiti. Limbajul de definire al datelor
reprezint o colecie de instruciuni utilizate pentru descrierea tipurilor de date. Administratorul
bazei de date trebuie s defineasc structura bazei de date cu ajutorul acestor tipuri de date. Acesta
este utilizat pentru a defini o schem a bazei de date sau pentru a modifica una existent.
Rezultatul compilrii instruciunilor din limbajul de definire a datelor reprezint un set de tabele
stocate n fiiere speciale denumite cataloage de sistem. Catalogul de sistem conine meta-datele
(datele care descriu obiectele din baza de date). Metadatele conin definiii ale nregistrrilor datelor
i altor obiecte cerute de sistemul de gestiune al bazei de date. Sistemul de gestiune al bazei de date
19
BAZE DE DATE
consult mai nti catalogul de sistem pentru a accesa corect datele. Teoretic, sunt trei limbaje de
definire a datelor:
- pentru schema extern;
- pentru schema conceptual;
- pentru schema intern.
Limbajul de definire a datelor conine comenzi necesare urmtoarelor operaii:
- definirea schemelor de relaie;
- eliminarea relaiilor;
- crearea indecilor;
- modificarea schemelor.
Limbajul de definire a datelor permite specificarea urmtoarelor informaii necesare n orice baz
de date:
- schema fiecrei relaii din baza de date;
- domeniul de valori asociat fiecrui atribut;
- constrngerile de integritate;
- setul de indeci care se creeaz pentru fiecare relaie n parte;
- informaii referitoare la securitatea sistemului i la modul de acces la acesta;
- structura de nmagazinare fizic pe disc a datelor.
1.2.2.1.1. Definirea schemei n SQL

O relaie n SQL se definete cu ajutorul sintaxei:
CREATE TABLE r (A1;D1;A2;D2; : : :;An;Dn,
i, : : : , constrangere_de_integritate1 i)
constrangere_de_integritate1
n care r reprezint numele relaiei, AI reprezint numele unui atribut, iar DI reprezint domeniul n
care ia valori acel atribut. Constrngerile de integritate permise sunt cheia primar (Aj1; : : :;Ajm) i
regulile de validare a domeniului de valori (check(P)).
O cheie primar trebuie s ndeplineasc dou condiii:
- valorile cheii primare trebuie s fie unice;
- ntr-o cheie primar nu trebuie s apar valori nule.
Standardul SQL-92 consider c apariia constrngerii not null n cheia primar este un fapt
redundant, dar standardul SQL-89 cere definirea explicit a acestui lucru. Regulile de validare a
domeniului de valori (check) se dovedesc a fi extrem de utile la creterea funcionalitii bazei de
date dar, uneori, sunt foarte costisitoare, aa cum se ntmpl, de exemplu, n cazul folosirii cheii
externe.
n cazul n care se dorete eliminarea unei relaii din baza de date trebuie folosit urmtoarea relaie:
DROP TABLE r
ceea ce nu este acelai lucru cu:

DELETE r
care pstreaz relaia, dar elimin toate tuplurile din ea.

Comanda de modificare a structurii unui tabel poate fi folosit pentru a aduga sau elimina atribute
din cadrul unei relaii r existente n baza de date:
ALTER TABLE r ADD A D
n care A reprezint atributul, iar D reprezint domeniul de valori ce trebuie atribuit acestuia.
20
BAZE DE DATE
ALTER TABLE r DROP A
n care A reprezint atributul care trebuie eliminat din baza de date.
1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor

SQL este un limbaj de interogare extrem de performant, datorit avantajului oferit de prelucrarea pe
seturi de nregistrri. Totui, el nu poate oferi procedurile necesare efecturii unei serii de activiti
i aciuni, cum ar fi: crearea de interfee grafice prietenoase, crearea i imprimarea de rapoarte,
interaciuni cu ali utilizatori, transferul datelor ntre baza de date i aplicaii. Din acest motiv este
necesar utilizarea unui limbaj de programare din generaia a treia care s realizeze conexiunea cu
baza de date i s efectueze sarcini dintre cele artate anterior.
Standardul SQL definete instruciunea EXEC care s poat fi folosit n astfel de situaii:
EXEC instructiune SQL
Instruciunile SQL admise sunt: DECLARE CURSOR, OPEN i FETCH care prelucreaz datele
din baza de date nregistrare cu nregistrare, precum i instruciunile de modificare, inserare sau
tergere a datelor.
Componenta dinamic SQL permite crearea i utilizarea de interogri SQL care s se modifice n
timpul rulrii aplicaiilor. De asemenea, n standardul SQL-92 sunt introduse module ce permit
definirea procedurilor n SQL.
1.2.2.2. Limbajul de manipulare a datelor

Asigur un set de procedee ce permit operaii de baz pentru manipularea datelor din baza de date.
Limbajul de manipulare a datelor asigur o colecie de operatori ce pot fi aplicai pentru a valida
instanele tipurilor de date n cadrul schemei i de a crea, modifica sau extrage astfel de instane. Cu
ajutorul acestor operatori se pot efectua urmtoarele operaii:
1. Regsirea datelor din baza de date (operaie principal).
2. Inserarea de date noi n baza de date.
3. Modificarea datelor existente.
4. tergerea de date din baza de date.
Exist dou tipuri de limbaje de manipulare a datelor:
Limabje de manipulare a datelor procedurale (specific modelelor reea i ierarhic) care permit
utilizatorului s comunice sistemului ce date sunt necesare i cum pot fi ele exact regsite. Aceste
limbaje prelucreaz informaia nregistrare cu nregistrare.
Limbaje de manipulare a datelor neprocedurale (specifice modelului relaional) care permit
utilizatorului s comunice sistemului ce date sunt necesare fr a specifica cum se regsesc datele.
Aceste limbaje prelucreaz informaia pe seturi de nregistrri i au urmtoarele caracteristici:
- confer o mai mare independen de date;
- cresc viteza de prelucrare a informaiei;
- sunt limbaje de generaia a patra (4GL - Fourth Generation Language).
Exemple de astfel de limbaje ce aparin generaiei a patra sunt:
- limbajul SQL;
- limbajul QBE;
- generatoare de formulare;
- generatoare de rapoarte;
- generatoare grafice;
- generatoare de aplicaii.
21
BAZE DE DATE
1.2.2.2.1. Extragerea informaiilor din bazele de date

Limbajul de manipulare a datelor permite extragerea datelor dintr-o baz de date. Structura de baz
a unei expresii SQL const din utilizarea clauzelor SELECT, FROM i WHERE.
SELECT este o clauz ce folosete o list a atributelor ce urmeaz a fi prezentate utilizatorului i
care corespunde operaiei de proiecie din algebra relaional.
FROM este o clauz ce corespunde produsului cartezian din algebra relaional i n care se
introduc relaiile din care urmeaz a fi extrase atributele ce apar n clauza SELECT.
WHERE este o clauz ce corespunde predicatului de selecie din algebra relaional.
n mod obinuit o interogare se prezint sub forma:
SELECT A1;A2; : : :;An
FROM r1; r2; : : :; rm
WHERE P
n care fiecare AI reprezint un atribut, fiecare ri reprezint o relaie, iar P este un predicat, ceea ce
este echivalent expresiei:
A1;A2;:::;An (_P (r1 _ r2 _ : : :_rm))
Dac se omite clauza WHERE, predicatul P are valoarea True. Lista atributelor poate fi nlocuit
printr-un caracter * pentru a le alege pe toate. Prin intermediul SQL se alctuiete produsul
cartezian pe baza relaiilor precizate, se poate efectua o selecie cu ajutorul unui predicat, dup care
se poate face o proiecie pe anumite atribute. Rezultatul unei interogri SQL este tot o relaie i, n
mod implicit, nregistrrile duplicat nu sunt eliminate. n lista de selecie se pot afla i operaii
aritmetice.
Clauza WHERE
Predicatele pot avea orice grad de complexitate i pot implica:
- conexiuni logice de tip and, or, sau not;
- expresii aritmetice ce conin constante sau valori ale tuplurilor;
- operatorul between utilizat pentru definirea domeniilor de valori ale variabilelor.
Clauza FROM
Clauza FROM n sine, definete un produs cartezian calculat pe baza relaiilor care sunt specificate
n cadrul acesteia. SQL nu ofer echivalentul jonciunii naturale, dar aceasta poate fi exprimat cu
ajutorul unui produs cartezian urmate de operaiile de selecie i proiecie. Variabilele, care n SQL
sunt reprezentate de tuplurile relaiilor, se definesc n clauza FROM, putnd fi folosite n cadrul
expresiilor.
Operaia de redenumire
Redenumirea reprezint un mecanism utilizat la schimbarea numelor relaiilor sau atributelor.
Pentru aceasta se poate folosi clauza AS ce poate s apar att n clauza SELECT ct i n clauza
FROM, sub forma:
Nume_vechi AS nume_nou
Operaii cu iruri
Cele mai frecvente operaii fcute cu irurile de caractere sunt cele n care se folosesc operatorii
Like sau Not Like cu scopul regsirii unor seturi de caractere specificate. Se mai pot folosi i o serie
de alte funcii caracter, cum ar fi concatenarea, extragerea subirurilor, determinarea lungimii unui
22
BAZE DE DATE
ir de caractere .a.m.d.
Ordonarea afirii nregistrrilor

SQL permite utilizatorului s controleze ordinea de apariie a tuplurilor prin folosirea clauzei
ORDER BY. Operaia de sortare poate fi foarte costisitoare i trebuie fcut numai n cazuri n care
chiar sunt necesare.
Tupluri duplicat
Limbajele formale de interogare se bazeaz pe relaiile matematice. Din acest motiv, n cadrul
relaiilor nu sunt permise nregistrrile duplicat dar, deoarece eliminarea acestora este extrem de
costisitoare SQL admite duplicatele. Dac se dorete eliminarea acestora se poate folosi clauza
DISTINCT, iar dac se dorete s se obin asigurarea c nregistrrile duplicat nu sunt eliminate se
folosete clauza ALL.
Operaii cu mulimi
SQL folosete n acest caz reuniunea, intersecia i diferena. Prin operaia de reuniune se elimin
duplicatele dar, dac nu se urmrete acest lucru se poate folosi clauza UNION ALL. n cazul
operaiei de diferen se poate face precizarea c standardul SQL din 1986 prevedea pentru aceast
operaie clauza MINUS, n timp ce standardul din 1992 a redenumit clauza care este folosit astzi
sub denumirea de EXCEPT.
Funcii agregat
SQL poate opera cu funcii pe grupuri de tupluri folosind clauza GROUP BY. Atributele respective
sunt folosite pentru a forma grupuri ce au aceleai valori, astfel nct SQL poate determina:
- valoarea medie (Avg);
- valoarea minim (Min);
- valoarea maxim (Max);
- suma total a valorilor (Sum);
- numrul total al nregistrrilor din grup.
Toate aceste funcii sunt denumite funcii agregat sau totalizatoare. Astfel de funcii ntorc drept
rezultat o singur valoare. Dac n aceeai interogare apare att clauza WHERE ct i clauza
HAVING, predicatul clauzei WHERE este aplicat primul. Acele tupluri care ndeplinesc condiia
impus se introduc n cadrul unor grupuri cu ajutorul clauzei GROUP BY. Clauza HAVING este
aplicat fiecrui grup care se formeaz. Grupurile ce ndeplinesc condiia impus prin clauza
HAVING sunt utilizate de clauza SELECT pentru a genera tuplurile rezultat. Dac nu exist o
clauz HAVING, tuplurile ce ndeplinesc condiia impus de clauza WHERE sunt tratate ca i cum
ar fi un singur grup.
Conceptul de NULL
Interogrile n care nu se cunosc toate valorile ce trebuie afiate pun probleme, deoarece o valoare
necunoscut nu poate fi comparat sau utilizat ca parte a unei funcii agregat. Toate comparaiile
care implic valori necunoscute sunt false prin definiie. Pentru a determina dac n setul de
rezultate se afl valori necunoscute se poate utiliza cuvntul cheie NULL n scopul efecturii unui
astfel de test. Toate funciile agregat, cu excepia funciei COUNT ignor tuplurile ce au valori
necunoscute.
23
BAZE DE DATE
Relaii obinute prin cuplare

n cadrul standardului SQL-92 se prevede faptul c fiecare operaie de cuplare trebuie s aibe un tip
de jonciune i o condiie de cuplare. Tipurile de jonciuni prevzute n standardul respectiv sunt
jonciunile interioare, jonciunile exterioare stnga, jonciunile exterioare dreapta i jonciunile
complete exterioare. Cuvintele cheie interior, respectiv exterior sunt opionale, deoarece tipul de
jonciune poate fi dedus din jonciunea propriu-zis. n standardul SQL-92 se mai introduc alte dou
noi tipuri de jonciuni:
a. jonciunea ncruciat (o jonciune interioar fr condiie de cuplare);
b. jonciune de uniune (o jonciune exterioar complet aplicat pe o condiie de cuplare fals, cum
ar fi de exemplu situaia n care jonciunea interioar nu conine nici o nregistrare).
Utilizarea unei condiii de cuplare este obligatorie n cazul jonciunilor exterioare, dar este opional
n cazul jonciunilor interioare (dac se omite, se obine un produs cartezian).
Subinterogri imbricate
Membru al unui set de nregistrri
Pentru a determina acest lucru se pot folosi operatorii In i Not In.
Comparaii ntre seturi de nregistrri

Pentru a compara elementele unei mulimi se pot folosi operatorii de comparaie. Se interzice
utilizarea funciilor agregat n cadrul altor funcii agregat, astfel nct, de exemplu, nu este acceptat
formula Max(Avg()).
Testarea relaiilor ce nu conin nregistrri

Se face cu ajutorul construciei EXISTS care returneaz valoarea True dac subinterogarea care este
folosit ca argument conine nregistrri.
Testarea absenei tuplurilor duplicat

Se face cu ajutorul construciei UNIQUE care ntoarce valoarea True dac subinterogarea din
argumentul funciei nu conine tupluri duplicat.
Relaii derivate
Standardul SQl-92 permite utilizarea unei subinterogri n cadrul clauzei FROM. Dac se ntmpl
acest lucru, relaiei rezultat trebuie s i se dea un nume, iar atributele trebuie redenumite.
Modificrile bazei de date

Limbajul de manipulare a datelor permite acest lucru, aa cum se va vedea din cele ce urmeaz.
tergeri
Eliminarea tuplurilor din cadrul unei relaii se exprim n mod asemntor unei interogri, cu
deosebirea c n locul afirii tuplurilor rezultat, acestea sunt eliminate din cadrul relaiei respective,
aa cum se poate vedea din sintaxa:
DELETE FROM r
WHERE P
Sunt eliminate acele tupluri din relaia r care ndeplinesc condiia specificat n predicatul P. Dac
se omite clauza WHERE, sunt eliminate toate tuplurile din cadrul relaiei. Se pot elimina doar
tuplurile dintr-o singur relaie la un moment dat, dar se poate asocia un numr nelimitat de relaii
cu ajutorul unei clauze SELECT-FROM-WHERE ce se poate introduce n cadrul unei clauze
WHERE a clauzei DELETE. O astfel de tehnic trebuie ns folosit cu pruden deoarece poate
24
BAZE DE DATE
duce la apariia de ambiguiti. Se recomand ca naintea utilizrii clauzei DELETE s se fac toate
testele necesare, marcndu-se tuplurile ce urmeaz a fi terse.
Inserri
Inserarea unei noi nregistrri n cadrul unei relaii se face fie prin specificarea unui tuplu, fie prin
utilizarea unei interogri al crei rezultat este setul de tupluri ce urmeaz a fi inserat. Valorile
atributelor tuplurilor inserate trebuie s respecte constrngerile de domeniu impuse.
nainte de a efectua o operaie de inserare se recomand evaluarea complet a unei instruciuni
SELECT corespondent pentru a evita apariia de probleme. Este posibil ca nu toate atributele
tuplurilor inserate s aibe valori i, prin urmare, n acest caz acestea trebuie s fie declarate ca fiind
necunoscute.
Actualizri
Operaia de actualizare permite modificarea anumitor valori n cadrul tuplurilor fr a fi necesar
modificarea lor complet. n general, clauza WHERE aplicat clauzei UPDATE poate conine orice
construcie corect acceptat ntr-o clauz SELECT obinuit. O clauz SELECT imbricat n
cadrul unei clauze UPDATE poate asocia o relaie care trebuie actualizat.
1.2.3. Alte caracteristici SQL

SQL face parte din categoria aa-numitelor limbaje de generaia a patra datorit puterii sale, a
conciziei i a procedurilor de nivel sczut pe care le conine. Produsele de baze de date conin un
limbaj special ce ajut programatorii de aplicaii s creeze abloane, interfee utilizator i rapoarte
de date. n limbajele de generaia a patra nu exist un standard unanim acceptat. Standardul SQL-92
definete sesiunile i mediile SQL. Sesiunea SQL reprezint un concept legat de tehnologia
client/server (conectare, deconectare, efectuare sau reluare a tranzaciilor), n timp ce mediul SQL
ofer fiecrui utilizator un identificator i o schem.
Ca limbaj neprocedural, SQL permite utilizatorilor s precizeze ce trebuie fcut fr a arta cum
trebuie fcut. Cererea fcut de ctre un utilizator este transformat de sistemul de gestiune a bazei
de date n detaliile tehnice necesare obinerii datelor. Din acest motiv, se spune c bazele de date
relaionale necesit mult mai puine eforturi de programare dect orice alt tip de baze de date sau
sistem de fiiere, ceea ce face ca limbajul SQL s fie relativ uor de nvat.
1.2.4. Query-By-Example (QBE)

Limbajele de interogare a datelor au fost dezvoltate la nceputul anilor aptezeci cnd interfeele
om-main erau, spre deosebire de cele din zilele noastre, limitate i rudimentare. De exemplu,
interaciunea avea loc prin intermediul unor procese alctuite din seturi de comenzi n care
comenzile (cereri de tipul ruleaz acest program pe acele date, evalueaz interogarea etc.) erau
pregtite pe calculatoare separate i puse la un loc n setul de comenzi care era apoi trimis spre
procesare. n timp ce avea loc procesarea datelor, ntre calculator i utilizator nu se producea nici o
interaciune. La terminarea procesului de prelucrare rezultatele erau imprimate, iar utilizatorul le
examina pentru a determina urmtoarea aciune ce trebuia ntreprins. Setul de comenzi era apoi
reluat pn cnd utilizatorul era mulumit de rezultat.
Spre deosebire de SQL, limbajul QBE se bazeaz pe calculul relaional. QBE a fost dezvoltat de
M.M. Zloof de la IBM Yorktown Heights Laboratory. n limbajul QBE o interogare este o
construcie elaborat pe un terminal interactiv ce afieaz imagini bidimensionale ce conin una sau
mai multe relaii prezentate sub forma unor formulare care se completeaz prin introducerea
valorilor n coloanele selectate (exemple). Sistemul rspunde la ntrebri prin parcurgerea datelor pe
baza unui exemplu dat afind rezultatele pe acelai ecran. De obicei, reprezentarea relaiilor este
uurat prin intermediul comenzilor interactive care sunt disponibile prin intermediul unor meniuri.
Selecia comenzilor din meniu se face n funcie de schema disponibil, eliminndu-se astfel erorile
25
BAZE DE DATE
legate de scrierea numelor tabelelor sau atributelor acestora, aa cum s-ar putea ntmpla n cazul
folosirii limbajului SQL. Interfaa oferit este un editor structurat pe baza unui limbaj grafic.
1.3. SISTEME DE GESTIUNE A BAZELOR DE DATE

Baza de date reprezint una sau mai multe colecii de date aflate n interdependen mpreun cu
descrierea datelor i a relaiilor dintre ele.
Colecia de date reprezint un ansamblu de date organizat dup anumite criterii i este format din
componentele:
a) o familie de caracteristici alctuit din atribute ce definesc aspecte ale obiectelor din lumea real;
b) un predicat aplicat familiei de caracteristici ce conduce la o submulime ce definete o relaie de
ordine ntre caracteristici;
c) o suit temporal T = {t0, t1, ..., tj, ...} ce definete un decalaj al timpului n intervale discrete;
d) afectarea la fiecare moment tj a unei relaii asociat predicatului.
Bazele de date sunt gestionate cu ajutorul unui program numit sistem de gestiune al bazelor de date.
Sistemul de gestiune a bazelor de date (SGBD) este un sistem de programe ce permite definirea,
crearea i ntreinerea bazei de date precum i accesul controlat la acesta.
Din punct de vedere conceptual, gestiunea bazelor de date se bazeaz pe ideea separrii structurii
bazei de date de coninutul acesteia. n sistemele de baze de date definirea datelor se separ de
programele aplicaie, astfel nct utilizatorii vd doar definiia extern a unui obiect fr a cunoate
modul n care e definit acesta i cum funcioneaz. n acest mod, definiia intern a obiectului poate
fi modificat fr a afecta utilizatorii acestuia dac nu se modific definiia extern. De exemplu,
dac sunt adugate noi structuri de date sau sunt modificate cele existente, atunci programele
aplicaie nu sunt afectate dac nu depind direct de ceea ce se modific.
Structura bazei de date reprezint o colecie de descrieri statice ale tipurilor de entiti mpreun
cu relaiile logice stabilite ntre ele.
Relaiile logice reprezint asociaiile dintre mai multe entiti.
O entitate este un obiect distinct ce trebuie reprezentat n baza de date.
Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se nregistreaz n baza de
date.
Scopul unui sistem de gestiune al unei baze de date este acela de a oferi un mediu care s fie i
convenabil, dar i eficient pentru a putea fi folosit la:
- extragerea informaiilor din baza de date;
- nmagazinarea datelor n baza de date.
Bazele de date sunt de obicei folosite la gestionarea unei mari cantiti de date, ceea ce presupune
existena urmtoarelor caracteristici:
- definirea structurilor (modelarea datelor);
- utilizarea unor mecanisme de manipulare a datelor;
- asigurarea securitii datelor n baza de date;
- asigurarea controlului concurenei n cazul utilizrii sistemului de ctre mai muli utilizatori
Orice sistem de gestiune al bazelor de date are urmtoarele componente:
Limbajul de definire a datelor

Cu ajutorul acestui limbaj se specific tipurile de date i structurile precum i constrngerile asupra
datelor. Instruciunile limbajului sunt compilate i transformate ntr-un set de tabele nmagazinate
ntr-un fiier special numit dicionar de date sau catalogul sistemului (descrierea datelor se
ntlnete sub denumirile de catalog de sistem, dicionar de date sau meta-date ceea ce nseamn
date despre date). Structura de nmagazinare a datelor precum i metodele de acces utilizate de
26
BAZE DE DATE
sistemul bazei de date sunt specificate cu ajutorul unui set de definiii folosit cu scopul ascunderii
detaliilor de implementare a schemelor bazei de date
Un limbaj de manipulare a datelor

Acest limbaj este folosit pentru a ajuta utilizatorul s acceseze i s foloseasc datele aflate n baza
de date ntr-un mod interactiv. Cu ajutorul acestui limbaj se pot:
- extrage date din baza de date;
- introduce date n baza de date;
- elimina date din baza de date;
- actualiza date din baza de date.
Administratorul bazei de date

Administratorul bazei de date este un program ce asigur interfaa dintre datele nmagazinate,
aplicaiile care folosesc aceste date i ntrebrile adresate sistemului cu ajutorul crora se extrag
datele necesare. De obicei, bazele de date necesit un spaiu mare de nmagazinare pe mediul de
stocare ales, ce poate ajunge de ordinul gigabytes-ilor. Pentru a putea fi prelucrate datele se
transfer din memoria extern n memoria intern a sistemului. Scopul sistemului bazei de date este
acela de a uura accesul la date, iar administratorul bazei de date este rspunztor de urmtoarele:
- asigur interaciunea cu administratorul de fiiere (trebuie s transfere instruciunile limbajului
de manipulare a datelor n comenzi de nivel sczut recunoscute de sistemul de fiiere);
- asigur integritatea datelor prin verificrile pe care le efectueaz n momentul actualizrii
datelor astfel nct acestea s nu ncalce constrngerile impuse i s fie consistente;
- asigur securitatea datelor prin accesul controlat la date pe care l ofer utilizatorilor (acetia nu
pot accesa orice fel de date dac nu le este permis acest lucru);
- creeaz copiile de siguran i asigur refacerea datelor, n cazul apariiei unei erori sau
defeciuni n baza de date, la starea la care acestea se aflau nainte de apariia erorii sau
defeciunii;
- asigur controlul concurenei pstrnd consistena datelor atunci cnd acestea sunt accesate n
acelai timp de mai muli utilizatori.
1.3.1. Componentele unui sistem de gestiune al bazelor de date

Acestea sunt:
1. Hardware
2. Software
3. Date
4. Proceduri
5. Resurse umane
1.3.1.1. Componenta hardware

Aceast component poate fi reprezentat de un singur calculator personal, un singur calculator
mainframe sau o reea de calculatoare.
De obicei, ntr-o reea de calculatoare, se aplic urmtoarea schem:
Se folosete un calculator principal pe care se afl programele back-end - adic partea din
sistemul de gestiune al bazei de date care administreaz i controleaz accesul la baza de date i mai
multe calculatoare aflate n diferite locaii pe care se afl programele front-end adic partea din
sistemul de gestiune al bazei de date ce constituie interfaa cu utilizatorul.
n aceast schem, numit client-server, programele back-end reprezint serverul iar cele front-end
reprezint clienii.
27
BAZE DE DATE
1.3.1.2. Componenta software

Aceast component este alctuit din:
- programele sistemului de gestiune al bazei de date;
- programele aplicaie scrise de obicei n limbaje de programare de generaia a III-a (C, Pascal,
Cobol) sau SQL ncorporat ntr-un limbaj de generaia a III-a;
- sistemul de operare;
- programe de reea.
Sistemul de gestiune al bazei de date poate avea ncorporate instrumente din generaia a IV-a, cum
ar fi SQL ce permit:
dezvoltarea rapid de aplicaii;
mbuntirea semnificativ a productivitii;
realizarea unor programe uor de ntreinut.
1.3.1.3. Date
Datele acioneaz ca o punte de legtur ntre componentele main (hardware i software) i
componenta uman. Baza de date conine att datele operaionale (setul de nregistrri pe care se
lucreaz) ct i metadatele. Structura bazei de date este numit schem.
1.3.1.4. Proceduri
Procedurile reprezint instruciunile i regulile aplicate n proiectarea i utilizarea bazei de date.
Acestea pot fi:
- deschiderea unei sesiuni de lucru n sistemul de gestiune al bazei de date;
- pornirea sau oprirea sistemului de gestiune al bazei de date;
- utilizarea unui program de aplicaie sau a unei funcii a sistemului de gestiune al bazei de date;
- efectuarea de copii de siguran;
- tratarea defeciunilor hardware i software;
- modificarea structurii unui tabel, reorganizarea bazei de date, mbuntirea performanelor,
arhivarea datelor.
1.3.1.5. Resursele umane

Resursele umane sunt reprezentate de:
1. Administratorul de date este responsabil de gestionarea resurselor de date i proiectarea
conceptual / logic a bazei de date.
2. Administratorul bazei de date este responsabil de realizarea fizic a bazei de date ce implic
proiectarea i implementarea acesteia. Administratorul bazei de date este o persoan care are n
rspundere controlul centralizat al datelor i al aplicaiilor ce folosesc aceste date. ndatoririle
administratorului bazei de date cuprind:
- definete schema bazei de date, ceea ce presupune scrierea unui set de definiii n limbajul de
definire a datelor care apoi s poat fi compilate de ctre un compilator DDL i transformate
ntr-un set de tabele pstrate n catalogul sistemului;
- definete structura de stocare i a metodele de acces prin scrierea unui set de definiii transferate
compilatorului;
- modific schema i organizarea fizic prin scrierea unui set de definiii utilizate de ctre
compilatorul DDL pentru a face modificrile cerute n tabele;
- asigur securitatea prin acordarea drepturilor de acces utilizatorilor pe baza unor conturi de
utilizator create n acest scop;
- verific respectarea constrngerilor de integritate ori de cte ori se introduc date n baza de date;
- monitorizeaz toate activitile utilizatorilor;
28
BAZE DE DATE
3.
a)
b)
4.
-
monitorizeaz creterea dimensiunilor bazei de date;

i formeaz o imagine de ansamblu asupra sistemului, urmrind prile tari i slabe ale acestuia;
asigur controlul concurenei prin alegerea tipului de blocare ce va fi folosit atunci cnd aceleai
date sunt folosite de mai muli utilizatori n acelai timp;
asigur fiabilitatea sistemului n cazul apariiei unor erori.
Proiectanii de baze de date care pot fi:
Proiectant de baze de date logice:
identific datele (entiti i atribute);
identific relaiile dintre date;
identific constrngerile;
identific regulile ce descriu principalele caracteristici ale datelor;
implic utilizatori n realizarea modelului de date.
Proiectant de baze de date fizice:
transpune modelul logic ntr-un set de tabele i constrngeri;
selecteaz structuri de stocare i metode de acces specific;
asigur securitatea datelor.
Utilizatorii finali care pot fi de urmtoarele categorii:
Programatorii de aplicaii. Acetia sunt profesionitii ce interacioneaz cu sistemul
folosind instruciuni scrise n limbajul de manipulare a datelor pe care le ncorporeaz
n cadrul unor interfee create n alte limbaje de programare. Precompilatorul DML
convertete apelurile scrise n limbajul de manipulare a datelor n proceduri specifice
limbajului gazd. Compilatorul limbajului gazd genereaz apoi codul obiect.
Utilizatori cu pregtire special. Acetia interacioneaz cu sistemul fr a scrie
programe, dar ei formuleaz cereri pentru a extrage date din baza de date cu ajutorul
instruciunilor specifice limbajului de manipulare a datelor. Aceste cereri sunt
transmise procesorului de interogare care desparte o instruciune specific limbajului
de manipulare a datelor n instruciuni specifice modulului de administrare a bazei de
date.
Utilizatori specializai. Acetia sunt utilizatori cu pregtire special care scriu programe
aplicaie specializate pentru diverse zone de interes (sisteme CAD, sisteme expert
etc.).
Utilizatori obinuii. Acetia sunt utilizatori care interacioneaz cu sistemul folosind
interfeele create de programatorii de aplicaii.
1.3.2. Componentele unui sistem de gestiune a bazelor de date

Sistemele de gestiune a bazelor de date sunt alctuite dintr-o serie de module ce ndeplinesc diverse
funcionaliti. Anumite funcionaliti sunt ndeplinite mpreun cu sistemul de operare pe care este
folosit sistemul respectiv. Principalele componente ale unui sisteme de gestiune al bazelor de date
sunt:
Administratorul de fiiere gestioneaz alocarea spaiului pe disc precum i structurile de date
utilizate la reprezentarea datelor pe disc. Acesta transmite cererea ctre metoda de acces
corespunztoare care fie citete datele din buffer-ul sistemului, fie le scrie n acesta.
Administratorul bazei de date accept interogrile i examineaz schemele externe i conceptuale
pentru a determina ce nregistrri sunt necesare pentru a satisface o anumit cerere, dup care
apeleaz administratorul de fiiere pentru a efectua cererea.
Procesorul de interogare transform interogrile ntr-o serie de instruciuni de nivel jos adresate
administratorului de baze de date.
29
BAZE DE DATE
Preprocesorul DML convertete instruciunile DML dintr-un program aplicaie n apeluri de

funcii standard ale limbajului gazd i interacioneaz cu procesorul de interogare pentru a genera
codul corespunztor.
Programatori
Programe
aplicaie
Preprocesorul
DML
Codul programului
obiect
Metode de
acces
Buffer
Utilizatori
Administratorul
bazei de date
Interogri
Schema bazei
de date
SGBD
Procesor de
interogare
Administrator
baza de date
Compilator
DDL
Administrator catalog
Administrator de
fiiere
Catalogul
sistemului
Baza de date
Figura 1.3. Componentele bazei de date

Compilatorul DDL transform instruciunile DDL ntr-un set de tabele ce conin meta-datele.
Tabelele sunt stocate n catalogul sistemului.
Administratorul de catalog gestioneaz accesul i ntreinerea catalogului sistem. Catalogul
sistemului este accesat de majoritatea componentelor sistemului de gestiune al bazei de date.
Una dintre cele mai importante funcii din cadrul sistemului de gestiune al bazelor de date o are
administratorul bazei de date. Acesta pstreaz interfaa cu programele aplicaie i interogrile
lansate de utilizatori.
30
BAZE DE DATE
Codul
programului obiect
Procesorul de
interogare
Controlul de autorizare
Verificatorul de
integritate
Procesorul
de comand
Administratorul
de tranzacii
Administratorul
de date
Metode de
acces
Buffer
Administratorul
de buffer
Administratorul de
catalog
Administratorul
bazei de date
Optimizatorul
de interogare
Planificatorul
Administratorul
de reconstituire
Administratorul
de fiiere
Catalogul
sistemului
Baza de date
Figura 1.4. Componentele administratorului bazei de date

Administratorul bazei de date are una dintre cele mai importante funcii n cadrul unui sistem de
gestiune al bazelor de date. Principalele componente ale acestuia sunt prezentate n figura 1.4.
Aceste componente pot fi urmtoarele:
- Procesorul de interogare este utilizat pentru a simplifica i uura accesul la date. Acesta
conine Evaluatorul de interogare care execut fiecare interogare pe baza unui plan.
- Administratorul de date este utilizat pentru a minimiza resursele necesare transferului de date
dintre memoria intern i cea extern. Administratorul de date este un program care ofer o
interfa ntre datele nmagazinate n baza de date i interogrile formulate prin intermediul
aplicaiilor. Conine urmtoarele componente:
31
BAZE DE DATE
Controlul de autorizare care verific dac utilizatorul are dreptul de a efectua operaia
cerut.
- Administratorul de fiiere.
- Administratorul de buffer care rspunde de transferul datelor dintre memoria principal
i dispozitivele de stocare secundare.
Administratorul de tranzacii este utilizat pentru a controla atomicitatea i concurena
tranzaciilor n scopul pstrrii consistenei i durabilitii bazei de date. O tranzacie
reprezint o colecie de operaii aplicate bazei de date care sunt efectuate toate deodat sub
forma unei singure uniti logice. Aceast component este alctuit din:
- Administratorul de tranzacii.
- Administratorul de blocare.
- Administratorul de reconstituire care garanteaz c baza de date rmne ntr-o stare
coerent dup ce n baza de date a aprut o eroare. Acesta este responsabil de reluarea
sau abandonarea unei tranzacii.
-
1.3.3. Funciile sistemelor de gestiune a bazelor de date

1. Stocarea, regsirea i reactualizarea datelor.
Este funcia fundamental a unui sistem de gestiune a bazelor de date. Sistemul trebuie s
ascund fa de utilizatori detaliile privind implementarea fizic intern.
2. Asigurarea unui catalog accesibil utilizatorului
Catalogul sistemului conine date despre scheme, utilizatori, aplicaii. Acesta trebuie s
stocheze:
a. denumirile, tipurile i dimensiunile articolelor de date;
b. denumirile relaiilor;
c. constrngerile de integritate asupra datelor;
d. numele utilizatorilor autorizai care au acces la date;
e. schemele externe, conceptuale, interne precum i transpunerile lor;
f. statistica utilizrii (de exemplu: frecvena tranzaciilor, contorizarea numrului de
accesri ale obiectelor din baza de date).
Utilizarea unui astfel de catalog de sistem asigur o serie de avantaje care sunt prezentate n
continuare:
- contribuie la controlul datelor ca resurse;
- se poate defini n sensul datelor;
- simplific comunicarea;
- identific utilizatorii;
- identific cu uurin redundana i incoerena;
- nregistreaz modificrile din baza de date;
- impactul unei modificri poate fi determinat nainte de implementare;
- mbuntete securitatea;
- mbuntete integritatea;
- monitorizeaz operaiile efectuate asupra bazei de date.
3. Asigurarea tranzaciilor
Tranzacia reprezint un set de aciuni prin care se acceseaz sau se modific coninuturile
bazei de date. Dac tranzacia eueaz (nu s-au efectuat toate modificrile, sau modificrile
nu s-au efectuat n toate cazurile) baza de date devine incoerent i, ca urmare, trebuie avut
n vedere un mecanism care s anuleze toate modificrile efectuate n cadrul tranzaciei i s
aduc baza de date n ultima stare coerent anterioar nceperii tranzaciei.
4. Asigurarea serviciilor de control concurente
32
BAZE DE DATE
Sistemul de gestiune al bazei de date trebuie s garanteze c nu vor avea loc interferene
atunci cnd mai muli utilizatori acceseaz baza de date.
33
BAZE DE DATE
5. Asigurarea serviciilor de reconstituire

n cazul n care n timpul funcionrii sistemului au avut loc defeciuni de natur hardware
sau software, acesta trebuie readus ntr-o stare coerent.
6. Asigurarea serviciilor de autorizare
n cazul n care n timpul funcionrii utilizatorii ncearc intenionat sau accidental s
acceseze date pe care nu au dreptul s le prelucreze, sistemul de gestiune al bazei de date
trebuie s intervin.
7. Asigurarea unui suport pentru comunicarea datelor
Utilizatorii trebuie s poat accesa o baz de date centralizat de la locaii aflate la distan.
8. Asigurarea serviciilor de integritate
Integritatea bazei de date se refer la corectitudinea i coerena datelor stocate i se exprim
sub forma unor constrngeri care reprezint regulile de coeren pe care baza de date nu are
voie s le ncalce.
9. Asigurarea serviciilor pentru promovarea independenei de date
Independena de date este obinut printr-un mecanism de vedere sau subschem. Completa
independen logic de date este dificil de obinut. De obicei se pot aduga entiti, atribute,
relaii, dar eliminarea lor nu este ntotdeauna posibil.
10. Asigurarea de servicii utilitare
Serviciile utilitare ajut la administrarea bazei de date. Cteva astfel de exemple sunt
urmtoarele:
- faciliti de import;
- faciliti de monitorizare, pentru urmrirea utilizrii;
- programe de analiz statistic;
- faciliti de reorganizare a indecilor;
- compactarea i realocarea spaiului eliberat prin ndeprtarea unor nregistrri din
dispozitivele de stocare.
2. Modelarea datelor
2.1. Modele de date: reea, ierarhice, relaionale, obiectuale, hibrid
naintea construirii unei baze de date este necesar elaborarea unui model de date utilizat pentru
reprezentarea datelor. Un astfel de model se dovedete a fi de mare ajutor la nelegerea datelor i la
luarea celor mai bune decizii de proiectare n cadrul modelului fizic.
Un model este o abstractizare i o structur ce simbolizeaz toate caracteristicile entitilor eseniale
ce prezint interes pentru utilizator, o reprezentare i o reflectare a lumii reale (Universul
Discursului).
Un model de date reprezint o colecie integrat de concepte necesare descrierii datelor, relaiilor
dintre ele, precum i a constrngerilor asupra datelor (Connolly .a. 1998). Modelul de date este
utilizat la descrierea schemei bazei de date, definind structura datelor, legturile dintre acestea,
semantica lor, precum i constrngerile impuse, dei nu este obligatoriu ca ntotdeauna acestea s
fie regsite n orice model de date. Pe scurt, un model de date este utilizat pentru a reprezenta date
despre date.
Modelele de date ofer nelegerea descriptiv necesar definirii schemelor logice i externe i sunt
utile descrierii formale a schemei bazei de date.
Schema logic a unei baze de date reprezint o descriere abstract a unei poriuni din realitatea
modelat mpreun cu instanele bazei de date.
Un model de date este alctuit din trei elemente de baz:
34
BAZE DE DATE
-
entiti;
atribute;
- relaii.
O entitate reprezint un obiect sau concept din lumea real, cum ar fi de exemplu un student sau un
curs descris n cadrul bazei de date.
Un atribut reprezint acele caracteristici ce descriu aspecte sau condiii ale unei entiti, cum ar fi
de exemplu numele studentului sau situaia acestuia.
Relaia stabilit ntre dou sau mai multe entiti reprezint o interaciune ntre acele entiti, cum
ar fi de exemplu asocierea dintre un student i cursul pe care l urmeaz.
Aa cum artau Elmasri i Navathe, modelele de date ajut la nelegerea datelor asociate logic.
2.1.1. Istoricul bazelor de date
n continuare se vor prezenta cteva dintre cele mai importante evenimente petrecute pe parcursul
dezvoltrii bazelor de date.
-
n anul 1961 Charles Bachman proiecteaz Integrated Data Store (IDS) predecesorul
modelului reea.
Spre sfritul anilor 60, IBM creeaz Information Management System: IMS bazat pe
modelul ierarhic.
Spre sfritul anilor 60, grupul CODASYL (Committee for Data System Languages) definete
/standardizeaz modelul reea.
n 1969 Edgar Codd cercettor la firma IBM construiete modelul relaional.
n ani 70 apar SEQUEL (SQL), QBE; QUEL, System R (DB2), Ingres.
n anul 1976, Peter Chen construiete modelul Entitate-Relaie.
n anii 80 apar sistemele de gestiune a bazelor de date printre care: DB2, Oracle, Sybase,
Informix, DBase, Paradox.
n anul 1986 a fost definit primul standard SQL.
ntre anii 1990 i 2000 apar concepte precum OODB, ORDB (Postgres), Data Warehouse,
OLAP, Data Mining, GIS, Mobile DB, Multimedia DB, Web DB, XML DB.
Inabilitatea bazelor de date de a lucra eficient n cadrul fiierelor obinuite cu date ce implic
utilizarea grupurilor repetitive de date a condus la dezvoltarea unei mari varieti de structuri de
baze de date, numite de obicei i modele de baze de date.
-
2.1.2. Funciile modelelor

Funciile modelelor sunt:
1. Reprezint obiecte, evenimente precum i asocierile dintre acestea.
2. Reprezint aspecte eseniale i inerente, ignornd proprietile accidentale.
3. Au n vedere ansamblul entitilor, atributelor i relaiilor dintre acestea.
4. Asigur regulile de baz i relaiile ce permit proiectanilor i utilizatorilor s comunice corect,
fr ambiguiti.
Un model de date este alctuit din urmtoarele componente:
1. Partea structural ce reprezint un set de reguli ce fundamenteaz baza de date.
35
BAZE DE DATE
2. Partea de manipulare ce definete tipurile de operaii ce se pot efectua n baza de date:

-
operaii utilizate pentru actualizarea sau regsirea datelor;
- operaii utilizate pentru modificarea structurii bazei de date.

3. Set de reguli de integritate ce garanteaz faptul c datele sunt corecte.
Exist trei modele de baze de date:
1. Modelul de date extern utilizat pentru a reprezenta vederea fiecrui utilizator, care mai este
cunoscut i sub denumirea de Univers al Discursului. Acest model este reprezentat prin
modelele de date bazate pe nregistrri.
2. Modelul de date conceptual care reprezint vederea logic independent de sistemul de gestiune
al bazelor de date ales i reprezentat prin modelele de date bazate pe obiecte.
3. Modelul de date intern utilizat pentru ca schema conceptual s poat fi neleas de ctre
sistemul de gestiune al bazei de date i reprezentat prin modelele de date fizice.
Fiecare model de date are propria reprezentare a datelor, dar ntotdeauna un model este alctuit
dintr-o intensie i o extensie.
Extensia unei relaii se refer la setul curent de nregistrri pe care l conine. Acest set de
nregistrri nu rmne acelai tot timpul existenei bazei de date, suferind diverse modificri, pe
msura introducerii, actualizrii sau tergerii de date.
Partea cu caracter permanent n cadrul unei baze de date o reprezint intensia sa sau schema bazei
de date. Intensia bazei de date descrie structura tuplurilor unei relaii. Operaiile limbajului de
manipulare a datelor pot fi efectuate numai n condiiile n care se cunoate aceast structur.
Cu alte cuvinte intensia unei baze de date reprezint tipurile de entiti, fiind considerat a fi
modelul conceptual al bazei de date, pe cnd extensia reprezint instanierile tipurilor de nregistrri
corespunztoare tipurilor de entiti precum i legturile dintre acestea.
2.1.3. Modele de date bazate pe nregistrri
Astfel de modele descriu datele la nivel conceptual. Spre deosebire de modelele orientate pe
obiecte, acestea sunt folosite cu scopul de a specifica structura logic general a bazei de date i de
a oferi un nivel ridicat al descrierii implementrii. Modelele sunt denumite n acest fel deoarece
baza de date este alctuit din nregistrri de acelai tip. Fiecare tip de nregistrare are un numr fix
de cmpuri, fiecare cmp avnd, de obicei, o lungime fix, ceea ce duce la simplificarea
reprezentrii. Aceste modele nu ofer un mecanism de reprezentare direct a codului din baza de
date. Pentru a efectua interogri i actualizri asupra bazei de date se folosesc o serie de limbaje
individuale separate asociate modelului. Din aceast categorie de modele fac parte:
-
modelul de date ierarhic;
modelul de date reea;
- modelul de date relaional.

Astzi, datorit dezvoltrii fr precedent a Internetului, din ce n ce mai mult, se impune un alt tip
de model, modelul de date semi-structurat, n format XML.
Modelul ierarhic
Din punct de vedere istoric, acesta a fost primul model de date ce a fundamentat un sistem de
gestiune al bazelor de date i a fost dezvoltat de ctre firma IBM pentru produsul su IMS care
utiliza limbajul DL/1.
Rdcina
Printe
Copil
Printe
36
Copil
Copil
BAZE DE DATE
Modelul ierarhic lucreaz cu grupuri repetitive prin utilizarea unei structuri de date ce se bazeaz pe
parcurgerea de sus n jos a unui arbore: datele aflate n nregistrrile primare reprezint ramurile
arborelui, n timp ce datele ce formeaz grupurile repetitive reprezint frunzele acestuia.
Avantajul modelului ierarhic este acela c metodele folosite la regsirea nregistrrilor asociate din
baza de date sunt mai simple dect cele folosite n modelul reea.
Intensia modelului de date ierarhic este reprezentat cu ajutorul unui arbore de definiie ce
reprezint o diagram a structurii de date n care sensul legturilor funcionale este ntotdeauna de la
nodul printe ctre nodul copil. O astfel de diagram este un graf orientat alctuit cu scopul
reprezentrii tipurilor de entiti i a relaiilor dintre acestea. Nodurile grafului corespund tipurilor
de entiti, iar arcele grafului reprezint legturile funcionale dintre tipurile de entiti.
Extensia modelului de date ierarhic se reprezint sub forma unui tabel n care fiecare linie a
tabelului este o nregistrare ce corespunde unei instanieri a tipului de entitate. n tabele sunt
permise duplicatele i, prin urmare, pot exista dou instanieri identice ale aceluiai tip de entitate.
Un singur tabel din baza de date are rolul de rdcin a arborelui n timp ce restul tabelelor
formeaz mulimea prinilor i copiilor arborelui.
Figura 2.1. Modelul ierahic
O relaie ntr-o baz de date ierarhic este reprezentat prin intermediul perechii printe/copil. n
acest tip de relaie, tabelul printe poate fi asociat cu unul sau mai multe tabele copil, dar un singur
tabel copil poate fi asociat doar cu un singur tabel printe. Aceste tabele sunt asociate n mod
explicit cu ajutorul unor pointeri sau pe baza unui aranjament fizic al nregistrrilor n tabele.
Utilizatorul acceseaz datele pornind din rdcina arborelui i parcurge un anumit drum unic pn
ajunge la datele cutate. O astfel de metod de acces cere utilizatorului o foarte bun cunoatere a
structurii bazei de date.
Un avantaj al utilizrii bazelor de date ierarhice este acela c utilizatorul poate extrage datele foarte
rapid datorit legturilor explicite definite n structura tabelelor. Un alt avantaj este acela c
integritatea referenial se obine prin crearea structurii i nu poate fi nclcat, ceea ce face ca o
nregistrare din tabelul copil s fie obligatoriu asociat unei nregistrri existente n tabelul printe,
iar o nregistrare tears din tabelul printe s impun eliminarea tuturor nregistrrilor asociate din
tabelul copil.
Probleme deosebite vor apare n momentul n care utilizatorul dorete s introduc o nregistrare n
tabelul copil care nu are asocieri cu nici o nregistrare din tabelul printe. Acest tip de baz de date
nu poate suporta asocierile complexe i, de aceea, deseori sunt probleme referitoare la redundana
datelor, deoarece este posibil s-i fie permis introducerea de date inconsistente. Aceast problem
poate fi ns rezolvat prin crearea a dou baze de date pentru a nlocui tipurile de relaii muli-lamuli, aa cum se prezint n figura de mai jos:
Relaie logic
copil
Baza de date 2
Baza de date 1
Figura 2.2. Rezolvarea relaiilor muli-la-muli

Dei bazele de date ierarhice ofereau un acces direct i rapid la date, dovedindu-i superioritatea
ntr-o multitudine de situaii specifice, devenise evident c era necesar introducerea unui nou
37
BAZE DE DATE
model de date pentru a remedia problemele tot mai presante referitoare la redundana datelor i la
rezolvarea asocierilor complexe dintre nregistrri.
Modelul reea
Modelul reea a fost creat, n special, ca o ncercare de a rezolva unele dintre problemele modelului
ierarhic.
Nod proprietar
1
Set structura
M
Nod membru
Figura 2.3. Modelul reea
Aa cum se poate observa din figura 2.3., structura unei baze de date de tip reea se poate reprezenta
cu ajutorul conceptelor de noduri i seturi. Un nod reprezint o colecie de nregistrri, n timp ce un
set stabilete i reprezint relaiile din cadrul unei bazei de date de tip reea. O astfel de construcie
transparent relaioneaz o pereche de noduri prin utilizarea unuia dintre ele sub denumirea de
proprietar, iar a celuilalt sub denumirea de membru.
Structura de tip set este o construcie ce stabilete i reprezint o relaie din cadrul bazei de date
reea (reprezint o mbuntire remarcabil fa de relaia printe/copil). O astfel de structur
suport o relaie de unu-la-muli, ceea ce nseamn faptul c o nregistrare din nodul proprietar
poate fi relaionat cu una sau mai multe nregistrri aparintoare nodului membru, dar unei
singure nregistrri din nodul membru i este asociat o singur nregistrare din nodul proprietar.
Mai mult dect att, o nregistrare aparintoare nodului membru nu poate exista fr s fie asociat
unei nregistrri existente n nodul proprietar.
ntre o pereche de noduri se pot defini unul sau mai multe seturi, iar un singur nod poate fi implicat
n seturi cu alte noduri din baza de date. Utilizatorul poate accesa date din cadrul unei baze de date
de tip reea prin cea mai potrivit structur de seturi. Spre deosebire de bazele de date ierarhice, n
care accesul trebuie s nceap cu nodul rdcin, n bazele de date de tip reea utilizatorul poate
accesa datele indiferent de nod pe baza structurilor de tip set.
CODASYL a dezvoltat limbajul Common Business-Oriented Language (COBOL) pentru a scrie
aplicaii ce folosesc datele din bazele de date de tip reea. Cu toate dezavantajele pe care le are,
modelul de baze de date propus de CODASYL mai are i astzi o larg rspndire n ntreaga lume.
Bazele de date CODASYL folosesc n locul termenului de tabel, termenul de tip de nregistrare, dar
caracteristicile acestuia nu difer cu nimic fa de cele ale unui tabel. Tipurile de nregistrri conin
pointeri la nregistrrile provenite din alte tipuri de nregistrri. Un pointer este o valoare ce
specific locaia unei nregistrri ntr-un fiier sau n memorie. De exemplu, nregistrarea ce conine
date referitoare la un student, conine un pointer la o not a acestuia, care n replic va conine un
pointer la o alt not ce aparine acelui student, .a.m.d. Termenul generic utilizat la descrierea
tipurilor de nregistrri bazate pe pointeri este lista de legtur. Pointerii asociaz nregistrrile ntro structur organizat, numit reea.
Bazele de date de tip reea au performane excelente n cazul regsirii seturilor de nregistrri ce
aparin unui anumit obiect, deoarece relaiile dintre nregistrri (pointeri) reprezint parte
constitutiv a bazei de date. n acelai timp, se permite utilizatorilor crearea de interogri mult mai
complexe dect cele ce se pot elabora prin intermediul bazelor de date ierarhice, dar viteza bazelor
de date de tip reea scade atunci cnd se dorete cutarea nregistrrilor pe baza unor criterii
38
BAZE DE DATE
specificate. Principalul dezavantaj al acestui tip de baze de date este legat de faptul c utilizatorul
este obligat s cunoasc foarte bine structura bazei de date pentru a se putea descurca cu structurile
de seturi. Totodat, aplicaiile ce lucreaz cu astfel de baze de date (n principal programele
COBOL) trebuie s actualizeze att valorile datelor ct i pointerii nregistrrilor ce se adaug, terg
sau se modific. Necesitatea actualizrii secveniale att a datelor ct i a pointerilor duce la
creterea complexitii proceselor n care sunt implicate tranzacii.
Un alt dezavantaj este acela c nu este uoar modificarea structurii bazei de date fr a afecta
programele aplicaie care lucreaz cu aceasta. Deoarece, aa cum s-a artat, o relaie este definit n
mod explicit sub forma unei structuri de tip set, aceasta nu poate fi modificat fr a afecta
programele aplicaie ce folosesc aceast structur la cutarea datelor. Dac se modific o astfel de
structur, trebuie modificate n mod corespunztor toate asocierile acesteia definite n programele
aplicaie.
Intensia modelului de baze de date de tip reea este un graf cu arce numerotate pentru a indica
drumul ce trebuie parcurs, deoarece un tip de entitate copil poate fi conectat la mai multe tipuri de
entiti printe sau la acelai tip de entitate printe prin mai multe arce.
Extensia acestui model este un tabel ce permite introducerea de nregistrri duplicat, dar
nregistrrile pot fi ordonate.
Modelul relaional
Acesta este cel mai folosit model de date folosit astzi n ntreaga lume, fiind un model de tip
entitate-relaie bazat pe elaborarea unui model conceptual. Modelul relaional al unei baze de date
permite extinderea bazelor de date la nivelul calculatoarelor personale nemaifiind obligatorie
utilizarea echipamentelor costisitoare cerute de minicalculatoare sau de calculatoarele de tip
mainfraime.
Modelul a fost dezvoltat de ctre Dr. E. F. Codd de la San Jose Research Laboratories ce
aparineau firmei IBM n anul 1970. Cele mai importante caracteristici ale modelului relaional sunt
simplitatea, suportul teoretic solid, precum i cele trei elemente componente de baz.
Un astfel de model este simplu deoarece el poate fi descris cu ajutorul unui numr mic de concepte
care se refer la relaii (structuri de date bidimensionale ce au proprieti speciale), rnduri (datele
aflate n cadrul relaiilor), coloane (cmpurile datelor din rndurile corespunztoare) i chei
(mecanismul de identificare i asociere a rndurilor aflate n unul sau mai multe tabele).
Modelul relaional are un suport teoretic foarte solid deoarece se bazeaz pe teoria matematic a
seturilor, ceea ce nseamn faptul c toate operaiile sunt ncheiate cu succes, iar rezultatele
operaiilor sunt predictibile.
Cele trei componente ale modelului relaional sunt:
a. componenta de structur a datelor (relaii cu proprieti speciale);
b. componenta de manipulare a datelor (operaii predefinite prin care tehnologia relaional
folosete un optimizator inteligent pentru a gsi calea de acces la date);
c. componenta de integritate a datelor (reguli necesare proteciei datelor la efectuarea unor operaii
incorecte).
Principalul avantaj al modelului relaional este acela c nu este necesar utilizarea att a pointerilor
ct i a datelor n cadrul tabelelor, folosind n schimb relaii pentru a accesa valori corespondente
din mai multe tabele.
O relaie const dintr-o asociere ntre nregistrrile aflate n dou tabele ce au aceleai valori ale
atributelor. Deoarece tabelele relaionale nu conin pointeri, datele aflate n astfel de tabele sunt
independente de metodele folosite de ctre sistemul de gestiune al datelor n lucrul cu nregistrrile
tabelelor.
39
BAZE DE DATE
Intensia modelului relaional este o schem relaional cu una sau mai multe scheme de relaie.
Fiecare schem de relaie are propriul nume i propriile atribute.
Extensia modelului relaional este un tabel ce nu permite nregistrri duplicat. Fiecare schem de
relaie introduce un tabel n schema relaional. Modelul de date relaional folosete tabele
bidimensionale ce reprezint entitile i const din rnduri i coloane. O coloan reprezint un
atribut al unei entiti ce mai poart i denumirea de cmp sau proprietate. Un rnd reprezint un
tuplu care este o instan a unui tip de entitate sau de relaie sau orice altceva din baza de date. De
obicei una dintre coloanele tabelului este numit cheie primar i are o valoare unic (Brown, The
Relational Model).
Simplitatea modelului bazei de date relaionale const din simplitatea conceptelor cu care opereaz:
structuri simple i abstracte de date, independena fizic de date, cadrul puternic, general i realist
oferit aplicaiilor .a.m.d.
Modelul relaional ofer o interfa flexibil ce este prevzut cu cele mai potrivite componente
necesare oricrui utilizator la toate nivelele, oferind o mare independen a datelor (produsul obinut
este relativ independent de implementarea intern).
Baza de date relaional const din unul sau mai multe relaii sau tabele. Principalele concepte ale
modelului relaional sunt:
1. Atributul este o coloan ce are un nume propriu i unic ntr-o relaie (cmp). Fiecare relaie
conine o list de atribute (sau coloane) definite pe un anumit domeniu.
2. Domeniul reprezint setul posibil de valori pe care l poate avea unul sau mai multe atribute.
Utilizatorul poate defini domeniul de definiie, dar numai n anumite produse i poate defini
propriile domenii.
3. Tuplu un rnd din cadrul unei relaii (nregistrare). Un rnd dintr-un tabel reprezint asocierea
dintre seturile de valori. Fiecare relaie conine un set de tupluri (sau rnduri).
4. Intensia structura unei relaii mpreun cu specificaiile i constrngerile de domeniu aplicate.
Se modific rar.
5. Extensia starea relaiei (valorile din cadrul unei relaii se pot modifica). Reprezint coninutul
curent al bazei de date ce corespunde schemei bazei de date i se modific frecvent.
6. Gradul numrul de atribute dintr-o relaie.
7. Cardinalitatea numrul de tupluri dintr-o relaie.
8. Baza de date relaional reprezint o colecie de relaii ce pot fi modificate (tabele). O astfel
de colecie este descris sub forma unui set de scheme de relaii din cadrul bazei de date, numite
scheme relaionale ale bazei de date. Relaiile sunt alctuite din dou pri:
-
instana un tabel cu rnduri i coloane;
- schema specific numele relaiei mpreun cu numele i tipul fiecrei coloane.

Termenul de relaie este folosit n sensul su matematic acceptat:
Se d o schem de relaie R = r(A 1, ..., An) pe un set de domenii {D 1, D2..., Dn}. O relaie n-ar r
reprezint un subset al produsului cartezian al acestor domenii: D1 x D2 x ... x Dn.
Proprietile unei relaii sunt:
-
relaiile sunt alctuite din rnduri i coloane;
ntr-o relaie nu are importan ordinea de apariie a rndurilor sau coloanelor;
ntre tabele nu exist o asociere explicit (nici una vizibil cuiva care acceseaz datele);
fiecare nregistrare poate fi identificat n mod unic;
fiecare rnd din cadrul unui tabel are acelai set de coloane;
fiecare coloan are un singur tip de dat (nu sunt acceptate redefiniri pentru diferite valori).
40
BAZE DE DATE
Datorit acestor proprieti i a fundamentului matematic, modelul relaional permite proiectanilor

concentrarea mai nti asupra semanticii datelor i a relaiilor dintre ele i abia apoi asupra
implementarii fizice a semanticii respective pentru a se adapta ct mai bine cerinelor i
specificaiilor impuse.
2.1.4. Modele logice orientate pe obiecte
Descriu datele la nivelele conceptual i extern oferind o flexibilitate ridicat. Astfel de modele pot
specifica n mod explicit constrngerile aplicate datelor i se bazeaz pe urmtoarele concepte:
- entitate un obiect sau concept din lumea real ce are identitate proprie;
- atribut un set de proprieti utilizate la descrierea entitilor;
- relaie o asociere ntre dou sau mai multe entiti.
Din aceast categorie fac parte:
a. modelul entitate-relaie;
b. modelul orientat pe obiecte;
c. modelul obiectual-relaional;
d. modelul binar;
e. modelul semantic de date;
f. modelul infologic;
g. modelul funcional de date.
Dintre acestea se remarc modelele urmtoare:
Modelul entitate-relaie
Se bazeaz pe o percepie a lumii reale ca fiind alctuit dintr-o colecie de obiecte de baz sau
concepte (entiti) mpreun cu relaiile care se stabilesc ntre ele. Fiecare entitate are asociat un set
de atribute care o descriu, iar o relaie reprezint o asociere dintre dou sau mai multe entiti.
Mulimile tuturor entitilor sau relaiilor de acelai tip sunt cunoscute sub denumirea de tipuri de
entiti sau relaii. Un alt element important n cadrul diagramelor entitate-relaie l reprezint
precizarea constrngerilor de cardinalitate care exprim numrul de entiti asociate altui tip de
entitate prin intermediul unui tip de relaie.
Modelul orientat pe obiecte

Un astfel de model este utilizat doar n scopuri speciale, cele mai cunoscute produse de acest tip
fiind: ObjectStore, Gemstone, Ontos, O2, Jasmine, Cache. Modelul se bazeaz pe o colecie de
obiecte, la fel ca n cazul modelului entitate-relaie.
Un obiect conine valorile nmagazinate n cadrul unor variabile instaniate n interiorul acestor
obiecte. Spre deosebire de modelul entitate-relaie, valorile sunt ele nsele obiecte. Astfel de obiecte
conin alte obiecte imbricate pn la un nivel oarecare.
Obiectul mai conine elemente de cod ce opereaz asupra acestuia i care se numesc metode.
Obiectele ce conin acelai tip de valori i aceleai metode sunt grupate n clase. O clas poate fi
interpretat ca fiind definiia de tip a obiectului respectiv.
Singura modalitate prin care un obiect poate accesa datele altui obiect este prin invocarea metodelor
acelui obiect, ceea ce este cunoscut sub numele de trimitere de mesaje ctre obiectul respectiv.
Prile interne ale obiectului respectiv, variabilele i metodele, nu sunt vizibile n exterior,
obinndu-se astfel dou nivele de abstractizare a datelor. Spre deosebire de entitile din modelul
entitate-relaie, fiecare obiect are un identificator unic indiferent de valorile pe care le conine.
Dou obiecte ce au aceleai valori sunt distincte (polimorfism). Distincia se menine i la nivelul
fizic prin atribuirea unui identificator unic al obiectului respectiv.
Modelul orientat pe obiecte are toate caracteristicile limbajului de programare orientat pe obiecte,
fcnd ca modelul relaional s fie cobort la stadiul de depozit de date.
41
BAZE DE DATE
Esenial pentru un astfel de model este faptul c proiectantul bazei de date poate opera cu fiecare
element al bazei de date, inclusiv cu setul de operaii ce manipuleaz datele din cadrul bazei de date
n cadrul aplicaiei scrise ntr-un limbaj orientat pe obiecte.
De aceast dat ns nu mai exist o separare clar ntre date i aplicaie. Spre deosebire de modelul
relaional, care are un suport teoretic extrem de solid, modelul orientat pe obiecte nu prezint o
astfel de caracteristic, ceea ce face s nu existe un consens n definirea lor. Totui, organizaia
OMG (Object Management Group) a depus mari eforturi, reuind s propun un model ce a devenit
standard pentru toate sistemele de gestiune a bazelor de date orientate pe obiecte.
Modelul obiectual-relaional
Acest model (cunoscut iniial sub numele de model de date relaional extins) a extins modelul
relaional prin introducerea unor serii de elemente i caracteristici specifice modelului obiectual,
cum ar fi: clase, ncapsulare, motenire. Cele mai cunoscute produse de pe pia sunt: Postgres,
Informix, DB2, Oracle.
Scopul acestei extinderi a fost acela de a permite bazelor de date relaionale s opereze cu tipuri
complexe de date, cum ar fi: imagini audio, video, elemente de proiectare. Modelul se afl nc la
stadiul incipient de dezvoltare, chiar dac este promovat de cei mai mari productori de pe pia de
produse de baze de date.
2.1.5. Modele fizice de date
Sunt modele utilizate la descrierea datelor la cel mai de jos nivel. Ele conin informaii despre
structura nregistrrilor, ordinea nregistrrilor, precum i cile de acces la date. Din aceast
categorie fac parte:
- modelul unificat al datelor;
- memoria cadru.
2.1.6. 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 ntrun 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.
42
BAZE DE DATE
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.
2.1.7. Chei
O cheie este un cmp ce are o valoare unic, corespunztoare fiecrei nregistrri dintr-un
tabel. Sunt mai multe tipuri de chei, fiecare avnd propriile caracteristici.
2.1.7.1. Cheia candidat

Este un atribut sau un set de atribute ce identific n mod unic un tuplu dintr-un tabel.
2.1.7.2. Cheia primar

Reprezint una dintre cheile candidat desemnate n cadrul unui tabel. Orice tabel trebuie s aiba o
cheie primar.
O cheie primar trebuie s fie:
1. Stabil. Valoarea unei chei primare nu trebuie s se modifice sau s devin nul pe tot parcursul
existenei unei entiti (Brooks, 1992). O cheie primar stabil ajut la pstrarea unui model
stabil (Whitener, 1989). De exemplu, dac se analizeaz nregistrarea datelor unui student,
valoarea cheii primare nu trebuie s se modifice n timp, aa cum se ntmpl cu valorile din
cmpul n care se pstreaz vrsta acestuia.
2. Minimal. Cheia primar trebuie s fie alctuit dintr-un numr minim de cmpuri ce sunt
capabile s asigure unicitatea.
3. Centrat pe date, nu pe informaii. Nu trebuie s apar grupri de caracteristici n cadrul unei
valori a unei chei ce pstreaz meta-informaii adiionale, deoarece nu se respect principiul
atomicitii atributelor, crescnd astfel posibilitatea ca valorile cheii primare s se modifice.
4. Definitiv. n momentul introducerii unei noi nregistrri, trebuie s existe posibilitatea
introducerii unei valori. Cheia primar acioneaz ca un mecanism de constrngere suplimentar
a entitii deoarece nu poate fi introdus o instan a unui tip de entitate dac aceasta nu are o
valoare permis n cheia primar.
5. Accesibil. Oricine dorete s creeze, citeasc, sau tearg o nregistrare trebuie s poat
vizualiza valoarea cheii primare (Whitener, 1989).
2.1.7.3. Cheie alternativ

Este o cheie candidat ce nu a fost desemnat drept cheie primar. Ea poate deveni cheie primar
dac cheia primar aleas iniial nu mai corespunde la un moment dat.
2.1.7.4. Cheie extern

Exist doar n situaia n care se stabilesc dou sau mai multe relaii ntre tabelele bazei de date. Un
atribut al unui tabel trebuie s existe i n cellalt tabel legat de primul printr-o relaie.
2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server,

distribuite
2.2.1. Introducere
De mult timp se cocheta cu ideea crerii unei baze de date universale, adic o baz de date care s
conin informaii din ct mai multe domenii i care s poat fi accesat de un numr ct mai mare
de persoane. Pn cu puin timp n urm acest ideal se meninea n domeniul viselor. Odat cu
apariia a ceea ce numim astzi World Wide Web un astfel de vis a devenit realitate.
43
BAZE DE DATE
nc din cele mai vechi timpuri oamenii au avut nevoie de informaii. O dat cu informaia a aprut
i necesitatea schimbului de informaii. Pentru aceasta era nevoie de un suport material care s
stocheze informaia i s o transmit mai departe. S-a nceput cu cioplirea informaiilor n piatr i
s-a continuat cu alte i alte soluii pn n zilele noastre, cnd asistm la decderea unui suport
(hrtia) i ridicarea altuia (suportul electromagnetic).
Odat cu evoluia omenirii, informaia a crescut ca dimensiune, punndu-se, prin urmare, problema
stocrii unei mari cantiti de date. De asemenea, o alt problem este regsirea informaiei i, odat
cu aceasta, rapiditatea obinerii rezultatului. nc din zorii civilizaiei IT s-a observat c - pe lng
calculele ce erau preponderente n tehnologia informatic embrionar - computerele s-ar preta i la
nmagazinarea i exploatarea volumelor mari de informaii. Astfel, ncepnd cu anul 1948 s-au fcut
mai multe studii, cercetri i experimente privind stocarea datelor, iar de-a lungul timpului s-au
manifestat mai multe modele, arhitecturi i tehnologii privind bazele de date. Acceptnd un punct
de vedere oarecum teoretic, fr ns a intra in detalii aride, vom trece in revist principalele modele
de concepie i organizare a bazelor de date, dup care ne vom ocupa de arhitecturile de
implementare a sistemelor de gestiune a bazelor de date (SGBD).
2.2.2. Istoric
Pn spre anii 80 contau doar mainframe-urile, minisistemele i supercomputerele, bazele de date
fiind foarte mari (rspunznd unor cerine dure impuse de beneficiari pretenioi, pentru c doar
acetia aveau puterea financiar de a achiziiona tehnica motivat de probleme complexe i critice este uor s ne imaginm baze de date referindu-se la sute de mii sau milioane de entiti).
Tendinele forau mereu limite, iar de aici derivau problematici provocatoare privind performana,
accesibilitatea i mentenabilitatea. Prin anii 70, modelul relaional s-a cristalizat ca soluie viabil,
iar lupta concurenial dintre marii juctori de pe piaa bazelor de date se va da pn in vremea
noastr pe arena SGBDR i SQL.
Mult timp modelul de organizare centralizat (datele sunt depozitate pe un sistem central de unde
utilizatorii le acceseaz) a raspuns cel mai bine cerinelor de exploatare a bazelor de date. i astzi
pentru aproape orice mediu departamental (sau grup de lucru) organizarea centralizat a
informaiilor - i nu ne referim neaprat la baze de date (de exemplu, sistemele de gestiune i
control al circulaiei documentelor - unde documentele pot fi orice: documentaii, proiecte, desene
CAD, arhive etc.) - constituie o prim opiune.
Odat cu rspndirea i dezvoltarea calculatoarelor s-au deschis i orizonturile, iar ca o prima
tendin s-a dovedit necesitatea descentralizrii i interoperrii. Proliferarea diverselor platforme
(hardware i/sau sisteme de operare) au forat definirea de standarde de schimb de date i de
comunicaii, precum i dezvoltarea reelelor eterogene.
Iar pentru c lucrurile se ntmplau odat cu afluxul calculatoarelor personale, inevitabil
programatorii s-au gndit la ceva intre SGBD i spreadsheet, iar de aici la apariia unor baze de date
desktop de genul lui dBASE n-a fost dect pasul materializrii.
Evoluia ramurii desktop a bazelor de date s-a fcut in paralel cu mainstream-ul, dar influenndu-se
reciproc. Cele mai evidente tendine se pot descrie pe scurt astfel: bazele de date mici doreau s-i
dezvolte funcionaliti de sistem relaional (s poat defini relaii i s ncorporeze SQL) i s-i
extind limitele, iar cele mari i-au aplecat atenia asupra accesibilitii, materializat prin interfee
utilizator facile chiar i pentru activitile administrative (o interfa de calitate ajunge deseori un
argument de pia).
2.2.3. Modelul mainframe

Modelul centralizat iniial presupunea c baza de date este organizat i stocat integral pe un
sistem performant (denumit mainframe, sistem sau minisistem n funcie de criterii hardware) de
unde poate fi accesat de mai multe console utilizator (terminale de acces cu putere de calcul redus
44
BAZE DE DATE
conectate la calculatorul central) prin intermediul unor aplicaii de exploatare rezidente tot pe
mainframe.
Modelul s-a dovedit performant i sigur att n implementare, ct i n utilizare, dar au existat i
cteva puncte sensibile. Problema delicat la mainframe-uri nu este numrul de utilizatori suportai
(cum am fi tentai s credem), ci faptul c aplicaiile au o infrastructur rigida, a cror extindere
determin implicaii dure de organizare i administrare, pe lng creterile nedorite ale traficului de
date prin reea.
Extincia dinozaurilor n-a fost deloc complet: muli nc mai fac fa aplicaiilor critice (care nici
nu pot fi ntrerupte fr pierderi), iar interoperabilitatea cu arhitecturile moderne nu-i incomodeaz
deloc, ba parca-i retriesc o a doua tineree...
2.2.4. Modelul integrat

Un mediu software independent, instalat pe un singur calculator, include att baza de date propriuzis, ct i interfaa de acces la date (un prim exemplu de astfel de mediu integrat este dBASE),
astfel c singurul utilizator va fi beneficiarul. Accesarea datelor se face fie printr-un limbaj de
generaia IV (4GL) sau printr-un macrolimbaj, fie prin elemente de interfa (comenzi la prompter,
dialoguri QBE, comenzi menu). Datele fiind organizate tabelar, exista posibilitatea de a proiecta
aplicaii relaionale.
Uzual, astfel de medii ngduie dezvoltarea de aplicaii nerelaionale, ceea ce se mai numete i
organizare plat sau bidimensional, spre deosebire de organizarea relaional, care este
multidimensional (atenie, exist pericolul confuziei cu denumirea de baza de date
multidimensional care corespunde uzual domeniului date warehouse sau aplicaiilor DSS decision support system - i OLAP - On-Line Analytical Processing, deservind analize economice
necesare deciziilor manageriale, adic extragerii ad-hoc de informaii sintetice, unde
dimensionalitatea are un caracter mai abstract i mai dinamic i nu contravine modului de stocare).
ntr-un sistem nerelaional (revenind la mediul independent), datele care altfel s-ar preta organizrii
n nomenclatoare (tabele cu nregistrri unice, legate de celelalte tabele prin relaii unu-la-n) cunosc
un grad excesiv de redundan, iar actualizarea lor presupune un efort considerabil. (Redundana
datelor, adic faptul c baza de date conine aceleai date stocate de mai multe ori, ridic att
problema spaiului ocupat, ct mai ales dificultatea asigurrii consistenei si actualitii).
2.2.4.3. Modelul File-server

n sistemele de gestiune a bazelor de date folosite astzi, se ntlnesc dou concepte ce definesc
modul de acces al clienilor la o baz de date centralizat. Primul este conceptul file-server n care
serverul lucreaz numai cu fiierele de date, fiind impropriu ca aplicaia s cear un transfer de date.
Cel de-al doilea concept este modelul client-server, n care serverul nelege natura datelor
cerute, fiind pregtit s execute astfel de cereri.
Soluia oferit de modelul file-server implic utilizarea unui server de fiiere centralizat aflat
undeva pe o reea, care pune la dispoziia clientului uniti de disc logic cu fiiere partajate. Serverul
de fiiere nu are cunotine despre cererile logice care se prelucreaz, dar acioneaz sub forma unui
disc ce poate fi accesat prin intermediul unei reele pentru a transfera date de la/spre client. Toate
aplicaiile ruleaz la client. Exemple de astfel de produse sunt FoxPro, dBase, MS Access. O baz
de date de acest tip are o fiabilitate foarte sczut deoarece ea se pstreaz sub forma unui fiier
ntr-un sistem de fiiere, fiind uor de distrus dac se produce o eroare n timpul unei prelucrri sau
a unei pierderi de conexiune n timpul efecturii unei tranzacii.
2.2.4.4. Modelul Client-server

n modelul client-server avem de a face cu o baz de date centralizat care prelucreaz cererile
logice provenite de la client.
45
BAZE DE DATE
Un astfel de server nelege att natura cererii ct i structura i localizarea datelor, majoritatea
calculelor fiind efectuate de motorul bazei de date.
Clientul are doar o interfa grafic cu care poate accesa baza de date de pe server, folosind aplicaii
pentru a transmite comenzi SQL serverului bazei de date, rezultatele fiind primite sub form de
tabele. Exemple de astfel de produse sunt: ORACLE, SQL Server, DB2, Sybase i Informix. Prin
inerea sub control, de ctre un server, a tuturor fiierelor bazelor de date, arhitectura client-server
ofer o fiabilitate ridicat i o serie de alte caracteristici avantajoase ce nu pot fi oferite de
arhitectura file-server, cum ar fi:
1. Copie de siguran ce poate fi creat n timpul lucrului prin utilizarea unui planificator
automat ce face copii ale bazelor de date fr a fi necesar ntreruperea conexiunii cu
utilizatorii.
2. Tranzacii sigure prin jurnalizarea tranzaciilor, astfel nct actualizrile efectuate prin
intermediul unei tranzacii pot fi n orice moment refcute sau anulate, ajungndu-se astfel la
ultima stare consistent anterioar nceperii tranzaciei respective, indiferent dac eroarea se
produce la client sau la server. Dei motorul Microsoft Jet i fiierele .mdb ofer posibilitatea
efecturii de tranzacii, acestea nu sunt gestionate prin intermediul unui jurnal separat, iar datele
pot fi distruse fr a mai fi posibil refacerea lor.
3. Fiabilitate i protecie sporit a datelor. O baz de date n model file-server poate fi
reparat, n cazul apariiei unei erori, dar n acest caz utilizatorul trebuie deconectat, lucru care
se ntmpl foarte rar n cazul modelului client-server.
4. Procesarea mai rapid a interogrilor. Dac se folosete un fiier .mdb prin intermediul unei
reele, trebuie ncrcat motorul Jet al bazei de date la clientul la care se face cererea de
prelucrare. n acest fel traficul pe reea este foarte mare, fiind necesar transportul unei mari
cantiti de date, mai ales atunci cnd baza de date este foarte mare. n cazul modelului clientserver, prelucrrile se efectueaz direct pe server, care de obicei, este mult mai performant
dect maina clientului. Prelucrarea pe server duce la o ncrcare mult mai mare a acestuia dect
n cazul modelului file-server, dar traficul pe reea va fi substanial sczut. Prezentnd un
exemplu cu 5 utilizatori, se constat faptul c n situaia modelului file-server este posibil
blocarea reelei, deoarece toate bazele de date trebuie aduse pe calculatorul local. Din acest
motiv, atunci cnd utilizatorii pun ntrebri complexe serverului se poate ca reeaua s nu mai
fac fa solicitrilor.
n concluzie, soluiile file-server nu sunt recomandate ntreprinderilor de mari dimensiuni sau
aplicaiilor extinse, preferndu-se n acest caz soluia client-server care scade traficul de pe reea
i asigur o fiabilitatea mult crescut a sistemelor.
n acelai timp, suntem ispitii s credem, ca un reflex al superficialitii (acesta fiind unul dintre
marile riscuri actuale ale informatizrii), c dac se implementeaz o baza de date ce depete - s
zicem - un milion de nregistrri, baza de date desktop (mediu integrat) nu mai face fa i trebuie s
ne orientam ctre un alt tip de SGBDR. Pentru operarea n regim monoutilizator lucrurile nu se
prezint chiar aa: performanele (viteze de accesare i procesare a datelor) sunt ct se poate de
comparabile dac este vorba de un hardware bine echilibrat (un PC care s suporte fr probleme un
SGBDR mare va favoriza i baza de date integrat). n acest caz altele sunt criteriile care ne
orienteaz catre SGBDR-uri mari organizate in model client/server:
- operarea multiuser concurenial (considerat punctual, nici aici avantajele nu sunt nete deoarece
un FoxPro/LAN cu file-server face fa onorabil);
- descongestionarea traficului prin reea datorit transmiterii doar a datelor int (adic un minim);
- controlul drepturilor utilizatorilor i monitorizarea activitii (conectare i aplicaii);
- implementri unice de logic centralizat (reguli, proceduri, declanatoare - existente doar la
nivelul serverului);
- gestionarea tranzaciilor, aspect care devine capital/critic atunci cnd se administreaz un sistem
complex de date distribuite sau un mediu OLTP (on-line transactions processing); ceva mai recent sub influena Internetului - tranzaciile au loc prin comunicaie asincron (conversaionala) sau chiar
fr confirmare ("fire-and-forget);
46
BAZE DE DATE
- serverul asigura integritatea, consistena i actualitatea datelor (propagri de actualizri prin

mecanismele de integritate referenial);
- optimizarea organizrii fizice a datelor (colaborarea la un nivel ct mai jos cu sistemul de operare
i cu sistemul de fiiere) i optimizarea accesului la date. (Un exemplu de colaborare la nivel fizic
este posibilitatea SGBD-urilor de a face duplicri ale datelor - copiile de siguran fiind unul dintre
primele niveluri ale toleranei la defectri. Desigur ca i un LAN desktop - Novell, Windows NT poate face mirroring, ins nuanele difer.)
- recuperarea datelor n caz de blocare/cdere a sistemului i refacerea tranzaciilor neterminate;
- jurnalizarea acceselor, tranzaciilor i a sesiunilor de lucru sau de administrare;
- economicitatea upgrade-ului: ridicarea performanelor globale rezid n principal n creterea
puterii calculatorului pe care ruleaz serverul bazei de date, privind mai puin calculatoarele client
pe care se afla software-ul front-end etc.
Client si server pot fi vzute i ca dou procesoare distincte rulnd pe maini diferite (mai rar pe
aceeai main), bazate eventual (dar nu obligatoriu) pe acelai sistem de operare. Comunicaia prin
care partea "client a aplicaiei solicit servicii prii server se face prin mesaje (messagepassing), fiind complet transparent utilizatorului. Posturile de lucru pot fi uzual PC-uri, laptop-uri,
staii UNIX sau Macintosh, iar serverul poate fi un mainframe, un server departamental sau chiar un
PC bine dopat. Software-ul bazelor de date implementate prin arhitectura client/server se prezint
generic astfel: SGBD-urile asigur partea de server, iar aplicaiile de exploatare a datelor se afl
uzual la nivelul client (sculele de editare a aplicaiilor utilizator aparin de productorii SGBD-urilor
implementate sau pot fi din familia celor bazate pe specificaii deschise: ODBC, JDBC, Embeded
SQL, DCOM, OLE etc.).
Repartizarea datelor i a aplicaiei (logicii) ntre straturile "client i "server nu este preimpusa,
fiecare implementare fiind susceptibila de un optim.
Arhitectura client/server dovedete suplee (modularitatea i scalabilitatea oferind disponibilitate
crescut la reorganizri i extinderi) i deschidere (chiar se consider ca ea a aprut din necesitatea
de a asigura o deschidere i interoperabilitate superioare modelului centralizat cu mainframe).
Modelul client/server a fost i el susceptibil de perfecionri de principiu, iar una dintre cele mai
interesante este impunerea de niveluri/straturi intermediare intre client i server (n-tier), ca raspuns
la dilema legata de poziionarea programelor de aplicaie (logica de operare/afacere): care dintre
pri trebuie sa fie mai "groase, clientul sau serverul? ntruct avantajele locale erau permanent
necomplementare, s-a dezvoltat ideea unui strat intermediar, concretizat ntr-un server de aplicaii
interpus ntre clientul subire i serverul bazei de date (middle-tier), ambele capete fiind astfel
descongestionate de partea de logica. Interesant este i observaia unor analiti care asociau
tendina modern de accentuare a clientului subire cu revenirea la modelul mainframe cu terminale
"chioare. Oricum, cerinele actuale privind deschiderea mediilor informaionale determin diluarea
graniei dintre modele, reelele eterogene fiind vzute ca soluia cea mai viabil de a menine
echilibrul ntre permanentele inovaii i conservarea investiiilor anterioare.
ns cele mai deranjante dezavantaje ale arhitecturii client/server deriv din complexitatea ei
(cerine asupra personalului implicat: nelegerea conceptual a arhitecturii de ctre persoanele de
decizie, precum i cunotine aprofundate pentru cei care implementeaz/dezvolt efectiv
sistemul/aplicaiile) i din standardizarea insuficient.
Majoritatea serviciilor Internetului se desfoar n regim client/server (banala navigare nseamn
un utilizator accesnd datele dintr-un site-server prin intermediul unei aplicaii client, care este
browserul de Web), astfel c devine natural implicarea SGBDR-urilor n aplicaii Internet (de
genul e-business sau e-commerce). S ne imaginm urmtorul scenariu: un furnizor de produse i
organizeaz un catalog de produse (magazin virtual) pe care utilizatorii l pot consulta prin
navigatorul de acas. Lucrurile se desfoar prin pagina HTML pe care serverul de Internet o
trimite clientului, la rndul ei respectiva pagina acionnd ca ablon (formular/form) de accesare a
informaiilor comerciale din baza de date deservit de un server legat la site-server (cel mai frecvent
baza de date conine i imagini dac nu chiar i alte date multimedia). Iar daca utilizatorul va
47
BAZE DE DATE
comanda din produsele expuse completnd un formular din pagina Web (controlat printr-un script),
se declaneaz o alt serie de comunicaii ntre client i server.
2.2.6. Baze de date distribuite

Adevratul sens al atributului "distribuit n contextul SGBD-urilor corespunde nu faptului c
sistemul permite accesarea datelor de la distan (prin reea), ci acelor implementri care ngduie
aplicaiilor i utilizatorilor s trateze baza de date ca pe un singur depozit logic chiar dac datele
constituente sunt repartizate n mai multe locaii ale reelei (transparena complet a localizrii
datelor). Totui problema este delicat i pentru c - din punctul de vedere al analizei - se poate
oricnd crea o aplicaie care s trateze unitar tabele de date situate pe calculatoare diferite. Dar
pentru c adevrata baz de date se dorete independent de limbaje (sau de mediile de dezvoltare)
sunt de apreciat acele SGBD-uri care conin integrate funcionaliti care s asigure distribuirea
datelor n nodurile reelei.
innd cont c de obicei volumul i complexitatea datelor spulber idealul "un computer foarte
performant cumulnd ntreaga baza de date i deservind toi utilizatorii ntreprinderii/organizaiei
i trebuie gsit o soluie de compromis, devine foarte interesant colecia de criterii practice de
distribuire a datelor n cazul fiecrei implementri, particularitile cernd un optim jalonat de
urmtoarele aspecte:
- nu trebuie niciodat pierdut din vedere dezideratul vitezei;
- limita de stocare i puterea calculatoarelor gazda;
- limita de transfer a reelei;
- preferabil ca fiecare aplicaie s acceseze uzual un singur depozit al bazei de date (fr a
mpiedica accesarea cu frecven redusa a celorlalte noduri ale reelei);
- folosirea funciilor two-phase-commit existente pentru a asigura integritatea datelor
actualizate distribuit;
- planificarea, controlul i minimizarea duplicrii de obiecte ale bazei de date;
- corelarea organizrii cu facilitile de optimizare distribuit ale SGBD-ului.
Cercetatorul Chris Date (coleg de proiecte cu E.F. Codd) a enunat cele 12 cerine ideale crora
trebuie s li se supun bazele de date distribuite; dintre acestea 9 sunt urmtoarele:
0. Autonomia local: datele locale sunt deinute i administrate local - nici un post nu depinde
de altele pentru a funciona.
1. Toate posturile sunt egale: nici un post nu se bazeaz pe o staie central.
Funcionare nentrerupt: nu trebuie s fie necesar o oprire planificat (instalrile/tergerile
efectuate la un post nu afecteaz funcionarea celorlalte).
2. Transparena amplasrii: utilizatorii nu sunt obligai s tie unde sunt amplasate datele
pentru a le extrage. Transparena fragmentrii: relaiile dintre componentele bazei de date
pot fi fragmentate pentru stocare, dar acest lucru rmne transparent pentru utilizator.
3. Transparena duplicrii: relaiile i fragmentele pot fi reprezentate fizic prin copii multiple
stocate separat, dar transparent pentru utilizator.
4. Prelucrarea interogrilor distribuite: operaiile de citire/scriere se pot desfura la mai multe
posturi, permind optimizarea locala i global a interogrilor.
5. Actualizrile distribuite: tranzaciile singulare pot executa codul la mai multe posturi.
6. Independena de hardware: toate calculatoarele particip ca membri egali.
7. Independena de sistemul de operare: sunt suportate mai multe sisteme de operare
conectabile la reea. Independena de reea: sunt suportate mai multe reele prin protocoale
comune.
8. Independena de bazele de date: se asigur accesul uniform (interfaare unic) pentru datele
provenind din SGBD-uri diferite.
3.1. Bazele modelului relaional

48
BAZE DE DATE
Conceptul de baz de date introduce termenul de abstractizare a datelor prin mascarea fa de

utilizator a detaliilor legate de tehnica de stocare a datelor n calculator. Principalul instrument
folosit la realizarea acestui scop este modelul de date, care este alctuit dintr-un set de concepte ce
pot fi utilizate la descrierea structurii bazei de date, cum ar fi de exemplu, tipurile de date, relaiile
i constrngerile stabilite pentru datele reprezentate.
Exist trei tipuri de modele de date: modelul de date conceptual, modelul de date logic i
modelul de date fizic.
3.1.1. Modelul conceptual

Folosete o serie de concepte, cum ar fi entitate, relaie i atribut pentru a descrie ct mai fidel
modul n care este perceput de ctre utilizator realitatea ce urmeaz a fi reprezentat n cadrul unei
baze de date. Pentru a realiza un model conceptual ct mai corect se folosesc o serie de instrumente
ce ajut n modelare, dintre care cel mai folosit este diagrama entitate-relaie. De obicei, proiectarea
unui model conceptual respect urmtorul algoritm:
Pasul 1. Identificarea tipurilor de entiti. Const din identificarea i documentarea
principalelor tipuri de entiti din punct de vedere al beneficiarului bazei de date. n acest
scop este necesar citirea cu atenie a tuturor specificaiilor i cerinelor acestuia, urmat de
crearea unei liste a potenialelor tipuri de entiti. Tipurile de entiti reprezint obiectele sau
conceptele ce prezint cel mai mare interes n cadrul sistemului. De obicei, se creeaz mai
multe tipuri de entiti dect este necesar, urmnd ca ulterior s se recurg la o rafinare a
acestora, eliminndu-se unele dintre ele.
Pasul 2. Eliminarea tipurilor de entiti duplicat. n primul rnd trebuie s se obin
asigurarea c, ntr-adevr, fiecare tip de entitate utilizat reprezint un tip distinct de entitate
i nu nume diferite ale aceluiai tip de entitate. Este foarte important s nu se cad n
capcana definirii unui tip de entitate care s reprezinte ntregul sistem. De exemplu, la
modelarea unei biblioteci, tipurile de entiti pot fi crile, autorii, cititorii etc., dar n nici un
caz nu poate fi definit un tip de entitate biblioteca deoarece aceasta reprezint ntregul
sistem.
Pasul 3. Identificarea tipurilor de relaii. n cadrul acestei etape se recurge la identificarea
i documentarea celor mai importante tipuri de relaii ce se pot stabili ntre tipurile de entiti
rmase dup parcurgerea pasului anterior. n acest scop se examineaz fiecare tip de entitate
n parte pentru a putea determina poziia i legturile acesteia n cadrul sistemului. n acelai
timp se face o analiz a cardinalitii i a participrii fiecrui tip de entitate, identificndu-se
totodat constrngerile impuse tipurilor de entiti participante.
Pasul 4. Identificarea i asocierea atributelor corespunztoare fiecrui tip de entitate
sau relaie. n aceast etap trebuie obinut asigurarea c tipurile de entiti sunt cu
adevrat necesare i nu sunt atribute ale altor tipuri de entiti. De exemplu, telefonul poate
fi o entitate de sine stttoare sau un atribut exprimat sub forma unui numr de telefon
atribuit tipului de entitate Studeni.
Pasul 5. Stabilirea domeniilor de valori ale atributelor. Se realizeaz printr-o analiz
amnunit a situaiilor ce pot apare, documentndu-se fiecare hotrre luat.
Pasul 6. Stabilirea atributelor cheie candidat i primar. Dac n cadrul analizei se
identific mai multe chei candidat, se stabilete cheia primar, documentndu-se hotrrea
luat.
Pasul 7. Specializare/generalizarea tipurilor de entiti. Aceasta etap este una opional
n cadrul modelului relaional i are ca efect stabilirea superclaselor, respectiv a subclaselor
tipurilor de entiti, dac este cazul.
Pasul 8. Construirea diagramelor entitate-relaie. Prin parcurgerea acestei etape se
asigur o mai bun nelegere a realitii care se modeleaz.
Pasul 9. Eliminarea tipurilor de relaii duplicat.
Pasul 10. Revizuirea diagramei entitate-relaie mpreun cu beneficiarul bazei de date.
49
BAZE DE DATE
Modelarea realizat cu ajutorul unei diagrame entitate-relaie este un proces iterativ. De obicei, nu
exist o singur soluie i, ca urmare, nici o singur diagram de acest fel. Din acest motiv se
practic crearea mai multor diagrame entitate-relaie urmat de rafinarea fiecrei variante din care
se va alege ulterior, mpreun cu beneficiarul bazei de date, diagrama optim. De remarcat este
faptul c, de cele mai multe ori, nu se poate spune c o variant este mai bun dect alta, dar unele
variante pot oferi soluii mai bune dect altele.
Implementarea tipurilor de relaii n cadrul tabelelor

Dndu-se o relaie R care se stabilete ntre dou tipuri de entiti E i F se impun urmtoarele
reguli:
- dac relaia E-R-F este de tip unu-la-muli, cheia primar a relaiei F se introduce n relaia E;
- dac relaia E-R-F este de tip unu-la-unu, cheia primar a relaiei E se introduce n relaia F,
sau cheia primar a relaiei F se introduce n relaia E;
- dac relaia E-R-F este de tip muli-la-muli, se creeaz o nou relaie ce conine cheile primare
att ale lui E ct i ale lui F;
- dac relaia R are atribute, acestea trebuie transferate n cadrul unei relaii folosindu-se cheile
externe.
3.1.2. Modelul logic

Acest model folosete concepte ce mai pot fi nelese nc de ctre utilizator, dar care presupun
reprezentri referitoare la modul n care utilizatorul dorete s vizualizeze datele. n continuare
tehnicile de nmagazinare a datelor rmn transparente utilizatorului. Proiectul logic al unei baze de
date relaionale creeaz i valideaz modelul logic de date local. Scopul urmrit este acela de a
construi un model logic de date bazat pe modelul conceptual de date creat anterior, dup care se
trece la validarea acestui model cu ajutorul tehnicii normalizrii. Un astfel de model parcurge, de
regul, urmtorul algoritm:
Pasul 1. Transformarea modelului conceptual local n model logic local de date. n acest
scop se trece la rafinarea modelului conceptual de date local, prin eliminarea caracteristicilor
incomode:
a. eliminarea relaiilor muli-la-muli;
b. eliminarea relaiilor complexe;
c. eliminarea relaiilor recursive;
d. eliminarea relaiilor ce conin atribute;
e. revizuirea relaiilor unu-la-unu.
Pasul 2. Stabilirea relaiilor corespunztoare modelului logic de date. n aceast etap se
creeaz i documenteaz fiecare relaie, inclusiv cheile primare i externe.
Pasul 3. Validarea modelului folosind tehnica normalizrii.
Pasul 4. Validarea modelului n cazul folosirii tranzaciilor. Trebuie s se obin
asigurarea c modelul de date creat suport tranzaciile cerute de ctre beneficiarul bazei de
date.
Pasul 5. Stabilirea constrngerilor de integritate. n acest scop trebuie identificate:
a. datele necesare;
b. integritatea referenial;
c. constrngerile de domeniu impuse atributelor;
d. constrngerile logice;
e. integritatea entitii.
Pasul 6. Revizuirea modelului logic local mpreun cu beneficiarul bazei de date.
Pasul 7. Construirea i validarea modelului logic global de date. Scopul acestei etape
este acela de a realiza, pe baza modelelor logice locale de date un singur model logic global
ce poate fi utilizat la reprezentarea realitii care se modeleaz.
50
BAZE DE DATE
Pasul 9. Unificarea modelelor logice locale n cadrul unui singur model loc global. Se
urmresc:
- revederea numelor tipurilor de entiti i a cheilor primare;
- revederea numelor relaiilor;
- aducerea n cadrul unui singur model a tipurilor de entiti din cadrul modelelor
logice locale;
- introducerea n cadrul modelului logic global a tipurilor de entiti specifice
fiecrei vederi logice locale;
- aducerea n cadrul unui singur model a tipurilor de relaii din cadrul modelelor
logice locale;
- cutarea tipurilor de entiti i relaii lips;
- verificarea cheilor externe;
- verificarea constrngerilor de integritate;
- crearea modelului logic global de date;
- actualizarea documentaiei.
Pasul 10. Validarea modelului logic global. Se face prin utilizarea normalizrii.
Pasul 11. Prevederea modificrilor ce trebuie efectuate n vederea dezvoltrilor
ulterioare.
Pasul 12. Revizuirea modelului logic global mpreun cu beneficiarul bazei de date.
3.1.3. Modelul fizic

Acest tip de model descrie reprezentarea datelor n formatul, modul de acces i ordinea real n care
acestea sunt pstrate. Fiecare cmp dintr-un tabel are un anumit tip de dat. Standardul SQL-92
suport o varietate foarte larg de tipuri de date dintre care enumerm:
- char(n) sau character(n): ir de caractere de lungime fix, stabilit de utilizator;
- varchar(n) sau character varying: ir de caractere de lungime variabil a crui lungime maxim
este stabilit de ctre utilizator;
- int sau integer: tipul ntreg a crui lungime depinde de sistem;
- smallint: tip ntreg de dimensiuni mai mici a crui lungime depinde de sistem;
- numeric(p, d): un numr zecimal a crui precizie este stabilit de ctre utilizator, ce const dintrun numr total de cifre (p), dintre care d reprezint cifrele de la partea zecimal; de exemplu,
numeric(3, 1) permite stocarea numrului 1.22 exact aa cum apare i nu n formatul 1.2;
- real sau double precision: numere reale a cror precizie depinde de sistem;
- float(n): numr real a crui precizie este stabilit de ctre utilizator (n cifre);
- date: tip de dat calendaristic;
- time: exprim ora unei zile n ore, minute i secunde.
SQL-92 permite efectuarea de calcule aritmetice i de comparaii pe diverse intervale numerice,
folosind operatori de transformare a tipurilor (cast).
3.2. normalizarea bazelor de date. Forme normale

3.2.1. Normalizarea
Normalizarea reprezint proiectul logic al unei baze de date. Principalul obiectiv al unui proiect
logic este dezvoltarea schemelor relaionale corecte. n acest scop trebuie:
- evitate datele redundante;
- evitate anomaliile de modificare;
- asigurat reprezentarea relaiilor dintre atribute;
- facilitat verificarea actualizrilor care nu trebuie s foreze integritatea bazei de date.
Normalizarea este un proces de reducere a redundanelor i cretere a stabilitii unei baze de date.
Existena redundanelor ntr-o baz de date produce urmtoarele efecte defavorabile:
51
BAZE DE DATE
- pierdere inutil de spaiu;

- scderea performanelor de cost;
- apariia inconsistenelor;
- imposibilitatea reprezentrii datelor.
Normalizarea presupune determinarea locului n care trebuie plasate anumite date n cadrul
tabelelor bazei de date, stabilind totodat relaiile dintre acestea. Prin cuvntul norm se nelege
respectarea unui standard i reprezint setul de condiii impuse i cunoscute sub denumirea de
forme normale. Pentru a respecta aceste reguli trebuie identificate condiiile care trebuie respectate
n scopul evitrii nclcrii integritii datelor impunndu-se n acest scop descompunerea relaiilor.
Denormalizarea este procesul invers, opus normalizrii efectuat cu scopul mbuntirii
performanelor bazei de date.
Normalizarea este, cu alte cuvinte, un proces de descompunere a unui tabel n dou sau mai
multe tabele cu scopul eliminrii redundanelor care genereaz anomalii de actualizare. n
timpul procesului de normalizare, structura tabelelor se testeaz cu ajutorul formelor normale care
impun regulile de descompunere.
O form normal reprezint, cu alte cuvinte, un set specific de reguli ce pot fi utilizate n
scopul testrii structurii unui tabel pentru a obine asigurarea c structura respectiv nu
pune probleme la introducerea sau extragerea datelor.
Formele normale folosite n mod curent sunt Prima, A doua, A treia form normal, Forma normal
Boyce-Codd, A patra i A cincea form normal.
Descompuneri
Fie U o schem de relaie. Un set de scheme de relaii {R1 , R2 , ... , Rn} reprezint o descompunere a
lui U dac i numai dac:
U = R1 R2 Rn
i dac la reunire nu se pierde informaie.
O descompunere {R, T} a lui U se face fr pierdere de informaie (referitor la setul de
constrngeri) dac:
U = R T
n cazul oricrei instane a R, T, i U. Altfel, descompunerea se spune a fi cu pierdere de informaii.

Un caz mai general este ns:
UR
Dei descompunerea unui tabel n tabele mai mici este de dorit dintr-un anumit punct de vedere, n
scopul reducerii redundanelor i evitrii anomaliilor, totui o astfel de ntreprindere implic
anumite riscuri care, n principal, se manifest sub dou aspecte:
- posibila pierdere de informaie;
- posibila pierdere a dependenelor.
Se prezint n continuare un exemplu de pierdere de informaie.
Descompunerea R = {A, B}
A
A(r)
52
B(r)
BAZE DE DATE
R1 = {A} R2 = {B}
A ( r)
B ( r)
A
Proprietile descompunerii
O schem relaional R care are o mulime de dependene funcionale F se descompune n relaiile
R1 i R2.
1. Lipsa pierderii de informaie.
Se verific dac cel puin una dintre urmtoarele dependene se afl n F+
R1 R2 R1
R1 R2 R2
Dac nu, descompunerea se poate face cu pierdere.
2. Pstrarea dependenelor.
Fie Fi o mulime de dependene din F+ ce conine doar atributele relaiei Ri (cu notaia: Fi =
Ri ( F + ) ).
Se verific dac (F1 F2)+= F+. Dac se modific o relaie nu trebuie s se verifice dac se
pstreaz dependenele n celelalte relaii.
3. Eliminarea redundanelor.
Dependene funcionale
Dependenele funcionale sunt constrngeri aplicate mulimii de relaii din baza de date. Acestea
permit exprimarea unor fapte din lumea real. Noiunea generalizeaz ideea de supercheie. K este o
supercheie a relaiei R dac n orice situaie n care t1[K] = t2[K], t1[R] = t2[R].
Dependenele funcionale permit exprimarea constrngerilor ce nu pot fi exprimate prin intermediul
supercheilor (cheia primar, cheia candidat). O mulime F de dependene funcionale poate fi
folosit n dou moduri:
- pentru a specifica constrngerile aplicate relaiilor;
- pentru a verifica dac relaiile mai sunt valabile n cazul aplicrii mulimii de dependene
funcionale.
Un atribut A este dependent funcional de o mulime de atribute B dac i numai dac:
- valoarea lui A este determinat numai prin intermediul valorilor lui B;
- valorile lui B determin n mod unic o valoare a lui A
Dependena funcional se reprezint astfel:
BA
ceea ce nseamn c o valoare a lui B afecteaz valoarea lui A. O valoare a lui A nu afecteaz o
valoare a lui B. B reprezint determinantul, A reprezint dependentul/determinatul.
Dependenele funcionale sunt utilizate n scopul verificrii corectitudinii unei relaii.
53
BAZE DE DATE
Exemple:
a. K este o supercheie a relaiei R dac K R astfel nct pentru orice t1[k] = t2[k], t1[R]= t2[R]. K
determin funcional toate atributele dintr-un tuplu al lui R.
b. Eliminarea redundanelor (dependena parial, dependena tranzitiv, dependena funcional
propriu-zis, aseriunile logice ce implic dependene funcionale).
c. Verificarea constrngerilor aplicate pe un set de relaii.
d. Verificarea corectitudinii modelului entitate-relaie.
e. Verificarea reprezentrilor ntlnite n diagramele entitate-relaie (atribute ale unor entiti
incorect alese, stabilirea de constrngeri de cardinalitate eronate, lipsa tipurilor de relaie unu-lamuli corespunztoare tipului de entitate ales sau existena atributelor multivaloare).
Dndu-se o relaie R care are o mulime de dependene funcionale F, i o cheie K se impune
identificarea atributelor independente:
1. Cheia trebuie s identifice toate atributele unei relaii i dac un atribut depinde doar de o parte
a cheii, atunci se spune c el este parial dependent de cheie.
2. Dac un atribut depinde de o cheie n mod tranzitiv, atunci el depinde n mod direct de alt
atribut i, ca urmare, este independent de cheie. Atributul este dependent tranzitiv fa de cheie
3. Dependenele funcionale sunt transparente modelului entitate-relaie.
Clasa dependenelor funcionale

Clasa reprezint n matematic mulimea elementelor distincte ale unei mulimi.
Definiie: Fie F o mulime de dependee. Clasa dependenelor funcionale corespunztoare mulimii
F (F+), este alctuit din toate dependenele funcionale generate de dependenele mulimii F.
Exemplu:
R = {A, B, C, D}
F= {A B, A C, CD A}
Elementele mulimii F+ sunt:
A BC
CD B
AD B
AD ABCD
+
Dac R F atunci este o supercheie (cheie candidat, cheie primar) a lui R.
Axiomele lui Armstrong ajut la determinarea clasei dependenelor funcionale.
Reflexivitatea: Dac atunci (oricare ar fi mulimile de atribute i ).
Exemplu: {D} {D,C}, astfel nct DC D
Augmentarea: Dac atunci .
Exemplu: dac C D, atunci BC BD
Tranzitivitatea: Dac i atunci .
Exemplu: dac C D i D E, atunci C E.
Axiomele lui Armstrong sunt necesare i suficiente. Sunt necesare pentru c genereaz numai
dependene funcionale corecte i sunt suficiente deoarece genereaz toate dependenele funcionale
posibile (F+) pe baza unei mulimi date, F.
Mai exist i alte proprieti suplimentare:
Reuniunea: Dac i atunci .
Exemplu: dac C D i C B atunci C BD
Descompunerea: Dac atunci i .
Exemplu: dac C BD atunci C B i C D
Pseudotranzitivitatea: Dac i atunci .
Exemplu: dac C D i AD B atunci CA B
Aceste proprieti sunt necesare.
54
BAZE DE DATE
Dependene multivalorice
Urmtorul pas necesar este cel de determinare a tuturor dependenelor multivalorice care sunt
generate n mod logic de o mulime dat de dependene multivalorice.
Fie R o schem de relaie i R , R . n relaia R exist o dependen multivaloric
dac n orice relaie r( R), oricare ar fi perechile de tupluri t1 i t2 din r pentru t1[] = t2[],
exist tuplurile t3 i t4 n r astfel nct:
t1[] = t2[] = t3[] = t4[]
t3[] = t1[]
t3[ R -] = t2[ R - ]
t4[] = t2[]
t4[ R -] = t1[ R -]
Reprezentarea tabelar a dependenei multivalorice este:
t1
t2
t3
t4
a1 ai
a1 ai
a1 ai
a1 ai
ai+1aj
bi+1bj
ai+1aj
bi+1bj
R--
aj+1an
bj+1bn
bj+1bn
aj+1an
Fie R o schem de relaie cu o mulime de atribute ce se pot divide n trei submulimi nevide, A, B,
C. A B (A l multidetermin pe B) dac i numai dac pentru toate relaiile posibile r( R)
{a1 , b1 , c1} r i {a1 , b2 , c2} r rezult
{a1 , b1 , c2} r i {a1 , b2 , c1} r
Definiia de mai sus presupune formalizarea noiunii prin care unei valori oarecare a lui A i este
asociat o mulime de valori ale lui B i o mulime de valori ale lui C, iar mulimile B i C sunt
independente una fa de alta.
Dependenele multivalorice sunt utilizate n dou moduri:
1. Pentru a verifica corectitudinea relaiilor n cazul apariiei unei mulimi de dependene
funcionale i multivaloare.
2. Pentru a specifica constrngerile aplicate mulimii de relaii.
Dac o relaie r nu satisface o dependen multivaloric, se poate crea o alt relaie r care satisface
dependena multivaloric prin adugarea de tupluri relaiei r.
Aici se folosete acelai concept ca i n cazul dependenelor funcionale. Fie D o mulime de
dependene funcionale i multivalorice. Mulimea D+ a lui D reprezint mulimea tuturor
dependenelor funcionale i multivalorice generate de D. Mulimea D+ se poate calcula pe baza
mulimii D, cu ajutorul definiiilor formale ale dependenelor funcionale i multivalorice dar,
pentru a determina mulimea dependenelor, sunt mai uor de folosit regulile de inferen.
Urmtoarea list de reguli de inferen aplicate dependenelor funcionale i multivalorice este
necesar i suficient (primele trei reguli reprezint axiomele lui Armstrong):
1. Reflexivitatea. Dac reprezint mulimea atributelor i , atunci .
2. Augmentarea. Dac i nu este o mulime de atribute, atunci .
3. Tranzitivitatea. Dac i , atunci .
4. Complementaritatea. Dac , atunci R - - .
5. Augmentarea multivaloric. Dac , iar R i , atunci .
6. Tranzitivitatea multivaloric. Dac i , atunci - .
55
BAZE DE DATE
7. Duplicarea. Dac , atunci .

8. Cuplarea. Dac , iar , exist astfel nct R, iar = i
.
, atunci
Pstrarea dependenelor
Problema pstrrii dependenelor, atunci cnd vorbim despre dependenele multivalorice, nu este la
fel de simpl ca n cazul dependenelor funcionale. O descompunere a schemei R n schemele
R1,R2, . . .,Rn este o descompunere cu pstrarea dependenelor, corespunztoare mulimii D a
dependenelor funcionale i multivalorice dac, pentru fiecare mulime de relaii r1(R1), r2(R2), . . . ,
rn(Rn) oricare ar fi i, ri satisface Di (restricia mulimii D pe Ri), exist o relaie r(R) care satisface
mulimea D i pentru care ri = Ri(r), oricare ar fi i.
Dac se d o mulime de dependene funcionale i multivalorice, proiectul bazei de date ar
trebui s ndeplineasc urmtoarele trei criterii:
1. S fie adus la forma normal 4.
2. S pstreze dependenele.
3. S nu piard informaie.
Dac nu pot fi ndeplinite toate cele trei criterii, se poate ajunge la un compromis, cerndu-se
respectarea doar a primelor dou criterii.
Dependenele de cuplare (jonciune)

Proprietatea de lips a pierderilor datorate cuplrilor este una dintre proprietile necesare
obinerii unui proiect corespunztor al unei baze de date, datorit faptului c dac aceast
proprietate nu se respect se pierde informaie. Dup ce relaiile au fost testate n raport cu
dependenele funcionale i multivalorice, este obligatoriu s se foloseasc aceste dependene
pentru a arta c descompunerile nu au pierderi de informaie datorate cuplrilor.
Fie R o schem de relaie i R1, R2, . . ., Rn o descompunere a lui R. Dependena de cuplare *(R1,
R2, . . . , Rn) este folosit pentru a restrnge mulimea relaiilor la acelea pentru care R1, R2, . . .,Rn
nu reprezint o descompunere cu pierdere de cuplare a lui R. Formal, dac R = {R1, R2 . . . Rn}, se
spune c o relaie r(R) satisface dependena de cuplare *(R1, R2, . . .,Rn) dac:
r = R1 (r ) R2 (r ) ... Rn (r )
O dependen de cuplare este trivial dac una dintre relaiile Ri este chiar R. Fie dependena de
cuplare *(R1, R2) pe schema R. O astfel de dependen impune ca pentru toate r(R),
r = R1 (r)
R2 (r)
Fiecare dependen de cuplare de forma *(R1, R2) este, din acest motiv, echivalent cu o dependen
multivaloric. Exist ns dependene de cuplare care nu sunt echivalente cu nici o dependen
multivaloric. Cel mai simplu exemplu de astfel de dependen l reprezint schema:
R = {A, B, C}
cu dependena de cuplare:
*((A, B), (B, C), (A, C))
care nu este echivalent cu nici o mulime de dependene multivalorice.
Aa cum dependena multivaloric reprezint o modalitate prin care se demonstreaz independena
unei perechi de relaii, dependena de cuplare este o modalitate de a demonstra c elementele unei
56
BAZE DE DATE
mulimi de relaii sunt independente unele fa de altele. Noiunea de independen a relaiilor este
o consecin natural a modului general de definire a unei relaii.
n cazul dependenelor funcionale i multivalorice, este posibil folosirea unui set de reguli
necesare i suficiente. Din pcate un set de reguli asemntor nu exist i n cazul dependenelor
de cuplare.
3.2.2. Forme normale

Sunt proprieti sau constrngeri aplicate unei scheme de relaie cu scopul de a atinge anumite
obiective, cum ar fi reducerea redundanelor. Exist 6 forme normale aplicate de obicei:
Prima form normal (sau FN 1).
A doua form normal (sau FN 2).
A treia form normal (sau FN 3).
Forma normal Boyce Codd (sau FNBC).
A patra form normal (sau FN 4).
A cincea form normal (sau FN 5).
Fiecare dintre cele 6 forme normale este mai restrictiv ca predecesoarea sa. Astfel, de exemplu, o
schem de relaie aflat n forma normal trei este i n forma normal doi, aa cum se reprezint n
figura de mai jos:
FN 1
FN 2
FN 3
FNBC FN 4
FN 5
Figura 3.1. Forme normale

Scopul formelor normale este acela de a elimina redundanele din cadrul relaiilor prin
descompunerea acestora n dou sau mai multe relaii, fr ns a pierde informaie, ceea ce
nseamn faptul c este posibil, n orice moment, revenirea la relaia originar doar pe baza
relaiilor obinute din descompunere.
Prima form normal (FN 1)

Scopul formei normale unu este acela de a simplifica structura unei relaii prin obinerea asigurrii
c ea nu conine date care mai pot fi descompuse sau date generatoare de valori repetitive, ceea ce
nseamn faptul c nici un atribut nu poate avea o mulime de valori. Prin aciunea specific de
descompunere, atributele ce nu respect aceste condiii sunt plasate n relaii separate, pstrndu-se
atribute de legtur care au acelai tip de dat i aceeai dimensiune. Fiecare tabel are o cheie
primar. De asemenea, o schem relaional R se afl n forma normal unu dac i numai dac
fiecare atribut se afl la nivel atomic.
57
BAZE DE DATE
A doua form normal (FN 2)

O dependen funcional X Y se spune c este o dependen funcional complet dac prin
eliminarea unui atribut din X se pierde aceast dependena.
De exemplu, AB C este o dependen funcional complet numai dac C depinde funcional att
de B ct i de A.
O schem relaional se afl n forma normal doi dac i numai dac fiecare atribut care nu face
parte din cheie depinde funcional de ntreaga cheie. Cu alte cuvinte, o relaie se afl n forma
normal doi dac i numai dac se afl n forma normal unu i dac depinde funcional de ntreaga
cheie. Altfel relaia trebuie descompus.
i
A treia form normal (FN 3)

O relaie se afl n forma normal trei dac i numai dac se afl n forma normal doi i dac
fiecare atribut care nu face parte din cheie nu depinde tranzitiv de aceasta. Prin urmare, fiecare
atribut care nu face parte din cheie nu poate depinde funcional dect de aceasta. Pentru a ajunge din
forma normal doi n forma normal trei este necesar s:
- se determine dependenele funcionale dintre atribute;
- se descompun relaia n alte relaii, fr a pierde ns informaie.
Forma normal Boyce-Codd

O schem de relaie R se afl n FNBC dac, pentru toate dependenele funcionale ce au loc n R i
sunt de forma X Y n care R X i R Y sunt ndeplinite condiiile:
- X Y este trivial.
- X este o cheie candidat a schemei de relaie R astfel nct X R.
Cu alte cuvinte, fiecare atribut trebuie s depind de cheie, de ntreaga cheie i de nimic altceva.
FNBC este o generalizare a formelor normale doi i trei.
De remarcat este faptul c nu ntotdeauna este posibil descompunerea n FNBC cu pstrarea
dependenelor.
Forma normal patru (FN 4)

Forma normal patru se bazeaz pe conceptul de dependen multivaloric. O dependen
multivaloric apare doar n relaiile ce au cel puin trei coloane. Dac una dintre coloane are rnduri
ale cror valori corespund unei singure valori ale unui rnd dintr-o alt coloan, atunci se spune c a
aprut o dependen multivaloric. O relaie se afl n forma normal patru dac i numai dac se
afl n forma normal Bozce-Codd i dac nu are dependene funcionale multivalorice.
A cincea form normal (FN 5)

A cincea form normal se bazeaz pe conceptul de dependen de cuplare. Dependena de cuplare
este o proprietate ce garanteaz c nu se genereaz nregistrri false la reunirea relaiilor obinute
prin descompunere.
O relaie se afl n forma normal cinci dac ea nu poate fi descompus n alte relaii fr a pierde
informaie. Cu alte cuvinte, dac se adaug un rnd suplimentar unei relaii care nu se afl n forma
normal cinci i dac aceast relaie se descompune n alte relaii, prin refacerea relaiei iniiale se
obin nregistrri false.
O dependen de cuplare (jonciune) JD(R1, R2, ... ,Rn) reprezint o constrngere aplicat relaiei R,
care arat faptul c fiecare instan r(R) trebuie s aibe pierdere de informaie prin descompunerea
n relaiile R1, R2, ... , Rn.
58
BAZE DE DATE
O dependen multivaloric reprezint un caz special al unei dependene de cuplare n care n = 2.

Dependena de cuplare JD(R1, R2,..., Rn) este o dependen de cuplare trivial dac unele relaii Ri =
R.
O schem de relaie R se afl n forma normal cinci referitor la o mulime F de dependene
funcionale, multivalorice, i de cuplare dac pentru fiecare dependen de cuplare netrivial
JD(R1, R2, ... , Rn) din F, fiecare Ri este o supercheie a lui R.
3.3. Regulile lui Codd
Edgar F. Codd a murit n data de 18 aprilie 2003, la vrsta de 79 de ani. Codd a fost un cercettor,
angajat al firmei IBM, care a dezvoltat pentru prima oar, n 1970, modelul relaional al bazelor de
date n care prezint operaiile ce pot fi efectuate asupra unei baze de date cu scopul obinerii
accesului rapid i corect la acestea. Un model al unei baze de date are n vedere modul de stocare a
datelor ct metodologia folosit la extragerea i actualizarea acestora. Pe parcursul anilor 60-70
Codd a cutat s rezolve problemele induse de modelul ierarhic al bazelor de date care se folosea la
IBM n acea perioad. Rezultatul acestor cercetri s-a materializat n promovarea modelului
relaional ca o soluie alternativ a modelului ierarhic care se bazeaz pe teoria matematic a
mulimilor.
Spre deosebire de sistemele ierarhice rigide, bazele de date relaionale sunt uor de parcurs,
manipulat i modificat. n principiu, acestea se bazeaz pe conceptul de tabel bidimensional (numit
i relaie), fiecare tabel fiind alctuit din nregistrri (rnduri orizontale, numite i tupluri) i
cmpuri (coloane verticale numite i atribute). n esen, o baz de date relaional este alctuit
dintr-o colecie de tabele bidimensionale n care coloanele unui tabel pot conine asocieri cu
rndurile altor tabele n scopul corespondenei datelor.
La nceput IBM nu a luat n consideraie ideile revoluionare ale angajatului su, datorit marilor
investiii fcute n produsul de baze de date ierarhice, IMS, pe care ncercau s-l promoveze masiv
pe pia. i astfel s-au scurs 7 ani de la lucrrile lui Codd pn cnd Larry Ellison ce conducea o
companie ce ulterior avea s devin ORACLE a creat primul produs comercial de baze de date
relaionale. n 1981 IBM a realizat produsul SQL/DS, primul lor produs relaional, urmat n 1983 de
celebrul DB2.
n 1985 Codd a publicat o list de reguli care definesc simplu i concis o baz de date relaional
ideal, aceste reguli devenind standardul de evaluare a sistemelor relaionale, fiind n acelai timp i
un ghid de proiectare a tuturor sistemelor de baze de date relaionale. Dup publicarea lucrrii,
Codd a afirmat c va fi foarte greu, dac nu imposibil de creat un sistem care s satisfac n
totalitate setul de reguli, lucru care rmne valabil i astzi. La cele mai multe dintre sistemele
relaionale de baze de date regulile 6, 9, 10, 11 i 12 sunt foarte greu de respectat. n continuare se
va face o scurt trecere n revist a fiecreia dintre cele 12 reguli.
3.3.1. Regula informaiei

Toate informaiile transferate n cadrul unei baze de date relaionale trebuie reprezentate n mod
explicit la nivel logic ntr-o singur modalitate, sub form de valori n cadrul unor tabele. Aceasta
este, ceea ce se numete, reprezentare logic a datelor. Fiecare linie sau tuplu dintr-un tabel (relaie)
reprezint intrri n coloane modelul aplicndu-se la fel n ntregul tabel astfel nct fiecare rnd are
acelai format.
Fiecare linie din cadrul tabelului este identificat prin intermediul valorii unei coloane sau
combinaii de coloane, numit cheia primar. Fiecare rnd din cadrul tabelului poate fi accesat prin
intermediul unei chei externe. Un sistem de gestiune a bazelor de date relaionale trebuie s
manipuleze datele folosind doar instrumente specifice modelului relaional. Din acest motiv, att
datele ct i metadatele (datele despre date) trebuie pstrate n tabelele bazei de date.
3.3.2. Regula de garantare a accesului

Fiecare dat stocat ntr-o baz de date relaional trebuie s poat fi logic accesibil utilizatorului
prin apelarea numelui tabelului n care se afl, prin valoarea cheii primare i prin numele unei
59
BAZE DE DATE
coloane aparintoare tabelului respectiv. Accesul la date trebuie s se fac simplu, fr a exista
ambiguiti n exprimare. Modelul relaional nu se preocup de aspectele fizice ale extragerii datelor
din tabele. Aceast regul afirm faptul c utilizatorul trebuie s aibe acces la datele stocate n baza
de date doar prin intermediul numelor i valorilor. Cheia primar, prin care se identific n mod unic
o anumit nregistrare din cadrul unui tabel, reprezint elementul fundamental al modelului
relaional. ntr-un tabel nu poate exista dect o singur cheie primar care nu are voie s primeasc
valori NULL.
3.3.3. Valorile NULL

Valorile NULL (diferite de irul de lungime zero sau de numrul zero) sunt utilizate n cadrul
sistemelor de gestiune a bazelor de date relaionale pentru a reprezenta informaia lips sau
indisponibil la un moment dat, indiferent de tipul de dat i sunt obligatorii n orice sistem complet
relaional. De asemenea, astfel de reprezentri trebuie s poat fi manipulate ntr-un mod sistematic
i fr echivoc de ctre orice sistem de gestiune al bazelor de date relaionale (Date, 1991).
O valoare NULL poate apare oriunde n cadrul sistemului de gestiune al bazelor de date relaional,
dar nu poate fi atribuit nici unei chei primare, majoritatea sistemelor admind specificarea
conceptului de cmp nenul sub forma unei constrngeri ce interzice folosirea valorilor NULL n
cmpul respectiv (Parkhurst, 2002).
3.3.4. Catalog actualizat permanent pe baza modelului relaional

Descrierea bazei de date este reprezentat, la nivel logic, n acelai fel ca i datele obinuite, astfel
nct utilizatorii autorizai pot folosi acelai limbaj relaional pentru a pune ntrebri referitoare la
structura acesteia. Sistemul trebuie s suporte existena unui catalog relaional accesibil
utilizatorilor autorizai prin intermediul aceluiai limbaj de interogare folosit i n cazul datelor
obinuite (Date, 1991).
O baz de date relaional trebuie s se autodescrie (Moore).
Catalogul reprezint locul n care alturi de alte lucruri se pstreaz toate schemele (externe,
conceptuale, interne), dar i toate corespondenele (extern/conceptual, conceptual/intern). Cu
alte cuvinte, catalogul conine informaii detaliate (numite i metadate) despre obiectele de interes
ale bazei de date i ale ntregului sistem (Date, 2000).
3.3.5. Regula de nelegere a sublimbajului de manipulare a datelor

Un sistem relaional poate folosi mai multe limbaje sau moduri de folosire a terminalelor, dar acesta
trebuie s suporte cel puin un limbaj relaional care:
1. are sintax liniar;
2. poate fi folosit att interactiv ct i din cadrul altor programe aplicaie;
3. suport:
- operaii de definire a datelor (inclusiv definirea i folosirea vederilor);
- operaii de manipulare a datelor (extrageri de date, dar i actualizri);
- constrngeri de integritate i securitate;
- operaii de gestiune a tranzaciilor (nceput, sfrit, reluare).
(Date, 1991).
n realitate toate sistemele comerciale de gestiune a bazelor de date relaionale folosesc limbajul
structurat de interogare (SQL).
3.3.6. Regula de actualizare a vederilor

Toate vederile care sunt teoretic actualizabile, pot fi actualizate de ctre sistem. Fiecare vedere
trebuie s suporte acelai set de reguli de manipulare prin care se poate accesa n mod direct la fel
ca i un tabel obinuit (Parkhurst, 2002).
60
BAZE DE DATE
O vedere este un tabel virtual, care provine din cel puin un tabel de baz i genereaz o serie de
reprezentri ale datelor vizibile utilizatorilor. Tabelele de baz sunt tabelele reale ale bazei de date,
cu reprezentare concret n mediul de stocare. Deoarece vederile nu nmagazineaz date ci
interogri, acestea sunt numite tabele virtuale (Johnson, 1997).
Date a luat n discuie dou principii importante ce trebuie avute n vedere la actualizarea unei
vederi:
Principiul interschimbabilitii care afirm faptul c nu trebuie s se fac nici un fel de deosebire
ntre tabelele de baz i vederi i
Principiul relativitii bazei de date prin care tabelele bazei de date sunt considerate a fi tabele de
baz din punct de vedere al utilizatorului (Date, 2000).
3.3.7. Inserarea, actualizarea i eliminarea

Datele pot fi extrase din cadrul unei baze de date relaionale sub forma unor mulimi de date
alctuite pe baza rndurilor din unul sau mai multe tabele. Operaiile de inserare, actualizare i
tergere trebuie s fie aplicate pe orice astfel de mulime la fel cum se aplic i pe un singur rnd
dintr-un tabel (Parkhurst, 2002).
3.3.8. Independena fizic de date

Acest lucru se refer la faptul c programele aplicaie nu trebuie s fie afectate dac au loc
modificri n reprezentarea stocrii datelor sau n metodele de acces la date. Programele aplicaie
sunt imune la modificrile ce au loc n reprezentarea loc fizic sau n metodele de acces la date
(Avery). Aceasta nseamn faptul c structura fizic a datelor nu trebuie s provoace probleme
utilizatorului care lucreaz cu acele date.
3.3.9. Independena logic de date

Programele aplicaie nu trebuie s fie afectate atunci cnd au loc modificri n structura tabelelor
bazei de date, dac modificrile nu le afecteaz n mod direct. O vedere a utilizatorului asupra
datelor nu trebuie s fie afectat nici ea n cazul modificrii structurii logice a unei baze de date (de
exemplu, adugarea de coloane noi n tabele sau de tabele noi n baza de date) (Avery).
Date a definit independena logic de date ca reprezentnd imunitatea utilizatorilor i a
programelor acestora la modificrile efectuate n structura logic a unei baze de date. n esen,
asupra unei baze de date au loc dou tipuri de operaii: de adugare de coloane sau tabele i de
modificare a structurii tabelelor sau bazei de date. Nici una dintre cele dou operaii nu trebuie s
afecteze utilizatorii sau programele acestora.
Operaia de adugare
De multe ori, unei baze de date trebuie s i se adauge fie coloane noi n cadrul tabelelor, fie tabele
noi datorit apariiei de date suplimentare ce trebuie implementate n baza de date original. Ca
urmare se pot identifica dou tipuri de adugri:
1. extinderea tabelelor prin apariia de atribute noi, de un anumit tip de dat specificat;
2. extinderea bazei de date prin apariia de tabele noi necesare introducerii de noi entiti n
baza de date.
Operaia de reorganizare a structurii bazei de date
Uneori, apare necesitatea de modificare a structurii bazei de date, nu din cauza apariiei de date noi,
ci din apariia nevoii de reamplasare a anumitor date n mod diferit n cadrul tabelelor, coninutul
acestora rmnnd identic cu cel originar. (Date, 2000).
3.3.10. Independena integritii

Constrngerile de integritate specifice unei anumite baze de date relaionale trebuie s poat fi
definite n sublimbajul relaional al datelor i nmagazinate n catalog, nu n programul aplicaie. De
61
BAZE DE DATE
asemenea trebuie s fie posibil modificarea unor astfel de constrngeri aa cum cere logica
aplicaiei fr a afecta celelalte aplicaii (Date, 1991).
Constrngerile de integritate sunt reguli prin care sistemul de gestiune al bazelor de date mpiedic
baza de date s ajung ntr-o stare inconsistent. Potrivit celor afirmate de ctre Date n 2001, regula
de aur a independenei integritii este: Nu trebuie s fie permis nici un fel de operaie care s
lase o anumit valoare ntr-o stare care s contrazic predicatul impus. n acest fel nu poate avea
loc nici o tranzacie care ar ncerca s lase baza de date ntr-o stare care s nu corespund
propriei condiii impuse.
Constrngerile de integritate sunt:
1. Constrngeri NOT NULL
Aceast constrngere este preferat de standardul ISO n comenzile CREATE i ALTER TABLE.
Constrngerea interzice nmagazinarea n baza de date a valorilor NULL, ceea ce nseamn c nu se
permite ca anumite coloane s fie goale (Connolly et al., 1999).
2. Clauza UNIQUE
Clauza UNIQUE specific una sau mai multe coloane care identific n mod unic fiecare
nregistrare din cadrul unui tabel. n acelai timp, fiecare coloan ce apare n clauza UNIQUE
trebuie s fie declarat ca fiind NOT NULL.
SQL anuleaz orice operaie de inserare sau actualizare care are tendina de a genera valori duplicat
n cheile candidat. ntr-un tabel nu este permis dect o singur cheie primar, iar clauza UNIQUE
se folosete numai dac a fost aleas cheia primar i este necesar ca valorile altei coloane s fie
unice.
3. Clauza PRIMARY KEY (integritatea entitii)
Cheia primar a unui tabel trebuie s conin o valoare unic nenul pentru fiecare nregistrare
introdus n tabel. Standardul ISO impune integritatea entitii prin intermediul clauzei cheii
primare ce apare n instruciuni precum CREATE sau ALTER TABLE (Connolly et al., 1999).
4. FOREIGN KEY (integritatea referenial)
O cheie extern este un cmp dintr-un tabel ce corespunde coloanei cheie candidat dintr-un alt tabel.
O valoare a cheii externe trebuie s aib o valoare corespondent n tabelul printe. Tabelul ce
conine cheia extern se numete tabelul referit, copil sau extern, n timp ce tabelul ce conine cheia
candidat se numete tabelul de referin, primar, sau printe (Rennhackkamp, 1996).
Integritatea referenial are semnificaia faptului c nici o baz de date relaional nu poate conine
valori necorespunztoare ale cheii externe. Cheie extern necorespunztoare reprezint o valoare a
cheii externe dintr-un tabel referit pentru care nu exist valoare n tabelul de referin. Cu alte
cuvinte, constrngerea specific faptul c dac B l refer pe A, atunci A trebuie s existe. Date
afirm faptul c, de multe ori, nu este posibil utilizarea unei interogri convenabile pentru a obine
un anumit rspuns. Din acest motiv, trebuie s se poat specifica o aciune referenial de tipul
CALL proc(), n care proc reprezint procedura creat de utilizator (Date, 2000).
Actualizrile bazei de date au loc ntotdeauna la nivel atomic, ceea ce nseamn totul sau nimic,
chiar dac sunt implicate actualizri pe mai multe valori, ca n cazul aciunii refereniale
CASCADE (Date, 2000).
Standardul ISO propune introducerea cheii externe prin intermediul clauzei FOREIGN KEY ce
apare n cadrul comenzilor de creare sau modificare a structurii unui tabel. De exemplu, dac
tabelul B are o cheie extern care face referire la o coloan din tabelul A, integritatea referenial
interzice introducerea unei valori n tabelul B care nu are corespondent n tabelul A. n plus, regulile
de integritate referenial pot avea n vedere i faptul c ori de cte ori se elimin o valoare din
tabelul A, valorile corespunztoare din tabelul B pot fi i ele eliminate, ceea ce este cunoscut sub
denumirea de tergere n cascad. Regulile de integritate referenial mai pot specifica i faptul c
ori de cte ori se modific o valoare din tabelul A, toate valorile corespunztoare din tabelul B sunt
i ele modificate automat, ceea ce este cunoscut sub denumirea de actualizare n cascad
(Webopedia, Referential Integrity).
SQL prevede urmtoarele opiuni ce pot fi alese n astfel de situaii (Connolly et al., 1999):
62
BAZE DE DATE
1. CASCADE: prin tergerea unei nregistrri din tabelul printe automat se elimin toate
nregistrrile corespunztoare din tabelul copil. Deoarece nregistrrile eliminate pot conine o cheie
candidat utilizat drept cheie extern n alt tabel, regulile cheii externe se aplic i n tabelul
respectiv, .a.m.d.
2. SET NULL: terge nregistrarea din tabelul printe i provoac setarea coloanelor cheie extern
din tabelul copil la valoarea NULL, dar o astfel de operaie este posibil numai dac coloanele cheii
externe nu au setat opiunea NOT NULL.
3. SET DEFAULT: terge nregistrarea din tabelul printe i provoac setarea fiecrei componente
a cheii externe din tabelul copil la valoarea implicit specificat, dar operaia este valabil numai
dac coloanele cheii primare au setat opiunea DEFAULT.
4. NO ACTION: resping operaia de tergere din tabelul printe, fiind opiunea implicit dac nu se
introduc explicit reguli pentru ON DELETE.
5. Constrngerea CHECK
Exist dou tipuri de constrngeri CHECK. Una dintre ele este denumit constrngere de domeniu,
deoarece stabilete mulimea de valori pe care o poate lua un atribut, iar cealalt se numete
constrngerea logic utilizat cu scopul de a pune n eviden anumite condiii suplimentare
(Connolly et al, 1999).
Standardul ISO prevede astfel de constrngeri ce pot fi introduse n cadrul comenzilor de creare sau
modificare a unui tabel. Clauza CHECK permite definirea unei constrngeri pe o coloan sau pe
ntregul tabel. n cazul utilizrii clauzei la nivel de coloan, aceasta nu poate face referire dect la
coloana respectiv (Connolly et al, 1999).
Cel puin urmtoarele dou constrngeri trebuie s existe n orice baz de date relaional:
a. Integritatea entitii: nici o component a cheii primare nu are voie s aibe valoarea NULL.
b. Integritatea referenial: pentru fiecare valoare nenul a cheii externe din baza de date
relaional, trebuie s existe o valoare corespunztoare din acelai domeniu de valori i de
acelai tip (cheia primar).
63
BAZE DE DATE
3.4. LIMBAJUL MYSQL
3.4.1. DESCRIERE
Bazele de date sunt folosite pentru stocarea informatiilor in vederea furnizarii ulterioare in functie
de solicitarea primita.
MySQL este un sistem de baze de date functional independent.
In PHP exista functii pentru toate operatiile executate asupra bazelor de date MySQL.
Administrarea MySQL se poate face din linie de comanda sau folosind browserul si accesand
aplicatia numita PHPMyAdmin scrisa in PHP.
3.4.2. Operaii asupra bazelor de date
Cele mai uzuale operatii cu bazele de date sunt:
Comanda Semnificatie
CREATE creaza o baza de date sau un tabel
DROP
sterge o baza de date sau un tabel
INSERT
adauga inregistrari intr-un tabel
DELETE sterge inregistrari dintr-un tabel
UPDATE updateaza inregistrarile dintr-un tabel
SELECT
selecteaza un tabel
ALTER
alterarea unui tabel
3.4.3. Tipuri de date MySQL
In MySQL spatiul alocat pe discul serverului este functie de tipul de date. Cateva din tipurile de
date folosite in bazele de date MySQL sunt:
Tip
Semnificatie
int()
numar intreg
32 biti
Bigint()
numar intreg
64 biti
tinyint()
numar intreg (-128 la 127 sau 0 la 255)
8 biti
mediumint() numar intreg
24 biti
smallint() numar intreg
16 biti
char()
sectiune cu lungime fixa de la 0 la 255 caractere
varchar()
sectiune cu lungime variabila de la 0 la 255 caractere
float()
numar mic cu virgula flotanta
Double
numar mare cu virgula flotanta
Text
sir cu maximum 65535 caractere
date()
data in format YYYY-MM-DD
Date
data in format YYYY-MM-DD HH:MM:SS
Time
ora in format HH:MM:SS
Pentru ca baza de date sa fuctioneze mai bine coloanelor li s-au adaugat modificatori de coloana.
Tipul de date intregi incep de la valori negative la pozitive. Daca se adauga optiunea UNSIGNED,
care este un modificator de coloana, nu vor mai fi valori negative ci vor incepe de la 0.
64
BAZE DE DATE
Alti
modificatori
sunt:
AUTO_INCREMENT functioneaza cu orice tip intreg. La fiecare rand nou adaugat in baza de
date numarul asociat va fi incrementat.
NULL
inseamna
fara
valoare
(diferit
de
spatiu
sau
zero).
NOT
NULL
inseamna
ca
orice
inregistrare
va
fi
considerata
ceva.
PRIMARY KEY este rolul primei coloane din tabel, totodata reprezentand elementul de referinta
pentru fiecare linie.
3.4.4. Comenzi elementare MySQL
Cele mai frecvent utilizate comenzi MySQL sunt prezentate n coloana de mai jos. Ele sunt mult
mai multe, dar aici nu doresc dect s fac o scurt prezentare, urmnd ca voi s studiai n detaliu
comenzile utiliznd manualul oficial pe care l gsii la adresa http://dev.mysql.com/doc/
SHOW DATABASES;
# afieaz o list cu numele bazelor de date
existente
USE numele_bazei_de_date
# alegerea bazei de date cu care lucrm n
continuare
SHOW TABLES;
# afieaz tabelele existente n baza curent
SHOW COLUMNS;
# afieaz informaii despre coloanele unui tabel
CREATE DATABASE numele_bazei;
# creaz o baz de date cu numele respectiv
CREATE TABLE tabel_unu (camp_a TEXT);
# creaz tabelul 'tabel_unu' cu un cmp numit
'camp_a' al crui tip este TEXT
CREATE TABLE tabel_unu (camp_a TEXT, # creaz tabelul 'tabel_unu' cu un cmp numit
camp_b INT, camp_c TINYINT);
'camp_a' al crui tip este TEXT, un cmp numit
'camp_b' n care datele de pe coloana respectiv
vor fi numere ntregi i n cmpul 'camp_c' vor fi
introduse doar numere ntre -128 i 127
DROP TABLE tabel_unu;
# terge tabelul numit 'tabel_unu'
DROP DATABASE numele_bazei;
# terge baza de date cu numele 'numele_bazei'
INSERT INTO tabel (camp1, camp2, camp3)# introduce n tabelul cu numele 'tabel', n
VALUES (valoarea1, valoarea2, valoarea3);
'campul1' 'valoarea1', n 'campul2' 'valoarea2' i
n 'campul3' 'valoarea3'. Iata cum ar arta n
format tabelar:
campul1
campul2
campul3
valoarea1
valoarea2
valoarea3
INSERT INTO tabel (camp1, camp2) VALUES# Se poate omite una din coloane, dac avem 5
(valoarea1, valoarea2);
coloane, dar vrem s introducem numai n 3,
specificm cmpul i valoarea doar pentru cele pe
care le vrem, restul le ignorm.
campul1
campul2
campul3
valoarea1
valoarea2
INSERT INTO tabel
valoarea2, valoarea3);
VALUES
INSERT INTO tabel VALUES

valoarea2, '');
SELECT * FROM tabel;
(valoarea1,# o variant simplificat care se poate aplica doar

cnd introducem valori n toate cmpurile
tabelului (nu se poate omite)
(valoarea1,# identic ca cea dinainte, doar c n lipsa unei
valori se pun ghilimele.
# Afieaz tot (*) ce exist n tabelul cu numele
'tabel'
65
BAZE DE DATE
SELECT campul1 FROM tabel;
# afieaz coninutul cmpului 'campul1' din

tabelul 'tabel'
SELECT campul1, campul2 FROM tabel
# afieaz coninutul cmpurilor 'campul1' i
'campul2' din tabelul 'tabel'
SELECT * FROM tabel WHERE campul1 = # afieaz cmpurile a cror coninut este la fel cu
'valoare1';
'valoare1'
SELECT campul1, campul2 FROM tabel# caut i afieaz toate nregistrrile n care
WHERE campul2 LIKE 'valoare2';
'campul2' este asemntor cu 'valoare2'
WHERE campul2 LIKE 'valoare2%';
'campul2' ncepe cu 'valoare2'
WHERE campul2 LIKE '%valoare2';
'campul2' se termin cu 'valoare2'
WHERE campul2 LIKE '%valoare2%';
'campul2' se aseamn cu 'valoare2' oriunde n
cadrul textului.
SELECT
*
FROM
tabel
WHERE# afieaz toate cmpurile care conin 'valoarea1'
campul1=valoare1
AND
campul2
LIKEi se aseamn cu 'valoare2'
'%valoare2%';
SELECT campul1, campul2 FROM tabel# caut i afieaz toate cmpurile care difer de
WHERE campul1 != valoarea3;
'valoarea3'
SELECT campul1, campul2 FROM tabel# caut i afieaz toate cmpurile care nu ncep
WHERE campul2 NOT LIKE 'valoarea3%';
cu 'valoare3'
SELECT campul1 FROM tabel ORDER BY # afieaz coninutul cmpului 'campul1' n ordine
campul1 ASC;
cresctoare
SELECT campul1, campul2 FROM tabel ORDER# afieaz coninutul cmpului 1 n ordine
BY campul1 ASC, campul2 DESC;
cresctoare i cmpul 2 n ordine descresctoare.
SELECT count(*) FROM tabel;
# afieaz cte nregistrri sunt n total n tabel
SELECT count (*) FROM tabel WHERE# cte nregistrri sunt n tabel al cror 'camp1'
campul1=variabila1;
este 'variabila1'
SELECT camp1 FROM tabel GROUP BY camp1 # afieaz coninutul cmpului 1 grupat dup
ORDER BY camp1 ASC;
'camp1' ascendent
SELECT * FROM tabel LIMIT 0,3;
# afieaz din tabel ncepnd de la prima
nregistrare nc 3.
SELECT * FROM tabel LIMIT 10,5;
# afieaz ncepnd de la nregistrarea 10 nc 5
nregistrri din tabel
DELETE FROM tabel WHERE conditii;
# terge nregistrarea din tabel. Sintaxa este la fel
ca la comanda SELECT.
UPDATE tabel SET coloana1='noua valoare a# pentru actualizarea coninutului unei nregistrri
coloanei 1', coloana2='noua valoare a coloanei 2'din tabel. Sintaxa este la fel ca la comanda
WHERE conditii;
SELECT. (se terge valoarea veche i se scrie cea
nou)
ALTER TABLE tabel ADD dat TEXT;
# adugare la tabelul existent a unei coloane
numit 'dat' de tip text.
ALTER TABLE tabel CHANGE dat data TEXT; # redenumete coloana numit 'dat' cu numele
'data'
ALTER TABLE tabel CHANGE data data# modific tipul coloanei 'data' din 'TEXT' n
DATE;
coloana de tip 'DATE'
ALTER TABLE tabel ADD nr MEDIUMINT# adaug o coloan numita 'nr' dupa 'coloana1' n
UNSIGNED AFTER coloana1;
tabelul 'tabel'
INDECSI
# vezi descrierea de mai jos
Dei MySQL are suport pentru diacritice i setul de caractere 8859-2, este preferabil s nu folosii
diacritice n numele bazelor de date, tabelelor sau cmpurilor. De asemenea, nu putei folosi ca
66
BAZE DE DATE
nume de tabel sau de cmp cuvinte rezervate (nume de funcii, tipuri de caractere din MySQL
precum CREATE, DROP sau COLUMN). Se pot folosi nume de tabele care conin spaii dar n
practic trebuie s ncadrai numele ntre back-ticks ` (semnul ` l gsii pe tasta aflat imediat sub
Escape i nainte de 1).
Exemplu:
CREATE
TABLE
`tabel
al
carui
nume
are
spatii`
(`camp
1`,
TEXT);
SHOW COLUMNS FROM `tabel al carui nume are spatii`;
Semnul * este definit n MySQL ca nsemnnd tot/toate.
Semnul % este folosit n interogrile MySQL dac vrem s gsim cuvntul oriunde n cadrul
textului. Mai exact:
%cuvant_cautat - dac vrem s afieze toate cuvintele care se termin cu 'cuvantul_cautat' (pot fi i
cteva caractere)
cuvant_cautat%
afieaz
toate
cuvintele
care
ncep
cu
'cuvantul_cautat'
%cuvant_cautat% - afieaz toate cuvintele care conin 'cuvantul_cautat' oriunde n text.
Putem afla cte nregistrri sunt pentru un criteriu de selecie cu ajutorul lui count(). Putem afla
astfel cte nregistrri sunt n total n tabel sau cte nregistrri sunt n tabel al cror cmp este cel
cautat...
Cu ajutorul instruciunii GROUP BY putem "grupa" rezultatele astfel nct s nu vedem duplicatele
i s vedem doar valorile unice. Pentru a limita numrul ncepnd de la nregistrarea 10 nc 5
nregistrri).
Pentru tergerea nregistrrilor dintr-un tabel se folosete comanda DELETE. Pentru tergerea unui
tabel sau a unei baze de date comanda este DROP.
Comanda UPDATE se folosete cnd vrem s modificm coninutul unei nregistrri fr a o terge.
Dac dorim s schimbm structura unui tabel existent sau s adugm alte coloane folosim
comanda ALTER TABLE.
INDECSI - Cel mai folosit tip de index este id-ul. Id-ul este un numr unic de identificare pentru un
element distinct (un rnd) al unui tabel. Un exemplu de id din viaa real este numerotarea cd-urilor.
Cnd avei un cd nou l numerotai i l punei n raft la sfrit iar n catalog putei s l punei sortat
dup titlu sau dup numrul de ordine. La fel i ntr-o baz de date, putei crea un cmp care s
introduc automat un nr pentru fiecare rnd nou adugat n baza de date i la afiare putei s l
folosii
(de
exemplu
la
vizualizarea
ultimilor
10
vizitatori
folosii
id-ul).
Pentru a creea un index avem urmtoarele comenzi:
S zicem c avem o baz de date numit lista cu un cmp caseta i adugm cmpul id_casete comanda este urmtoarea:
ALTER TABLE `caseta` ADD ìd_caseta` INT;
ALTER TABLE `caseta` CHANGE ìd_caseta` ìd_caseta` INT(11) UNSIGNED NOT NULL;
ALTER TABLE `caseta` ADD PRIMARY KEY (id_caseta);
ALTER TABLE `caseta` CHANGE ìd_caseta` ìd_caseta` INT(11) UNSIGNED DEFAULT "0"
NOT NULL AUTO_INCREMENT;
i din acest moment, orice caset nou introdus va avea automat un nr de ordine. Este posibil ca
toat niruirea de comenzi de mai sus s se poat face printr-o singur linie de cod, dar este mai
sigur s facei cte o modificare n parte dect toate odat, pentru a detecta eventualele erori. Este
bine s creai un id la nceputul tabelului, cnd nu avei intrri n baza de date, pentru a face
incrementarea automat, altfel e posibil s v dea erori. Cu ajutorul id-ului putei afia de exemplu
noutaile, cu o comand de genul - afieaz ultimele 10 intrri sortate dup id..., tiind c
ntotdeauna ultima intrare are numrul cel mai mare...
Ct de mare poate fi un tabel?
MySQL stocheaz fizic datele unui tabel ntr-un fiier pe hard disc i cu ct tabelul e mai mare, cu
att mrimea acestui fiier crete. Versiunea 3.22 a MySQL are o limit de 4 GB pentru mrimea
unui tabel. n versiunile superioare aceast limit este extins pn la 8 milioane TB pentru tipul de
tabel MyISAM. Cu toate acestea, sistemele de operare pot avea propriile limitri ale mrimii
67
BAZE DE DATE
fiierelor. Mrimea impicit a tabelelor MySQL este de aproximativ 4 GB. Putei verifica mrimea
maxim pentru un tabel cu ajutorul
3.4.5. COMENZI PENTRU INTEROGAREA BAZELOR DE DATE.

FRAZA SELECT
n SQL o interogare se formuleaz printr-o fraz SELECT. Aceasta prezint trei clauze
principale: SELECT, FROM i WHERE.
SELECT corespunde operatorului proiecie din algebra relaional, fiind utilizat
pentru desemnarea listei de atribute (coloanele) din tabela-rezultat;
FROM este cea care permite enumerarea relaiilor din care vor fi extrase informaiile
aferente consultrii;
prin WHERE se desemneaz predicatul selectiv al algebrei relaionale, relativ la
atribute ale relaiilor care apar n clauza FROM.
La modul general o consultare simpl n SQL poate fi prezentat astfel:
SELECT C1, C2, ..., Cn
FROM R1, R2, ..., Rm
WHERE P
Execuia unei fraze SELECT se concretizeaz n obinerea unei tabele (relaii) rezultat.
Acest poate fi o tabel propriu-zis sau o tabel temporar (care, de obicei, nu poate fi actualizat),
dar i o tabel derivat (imagine). Uneori tabela rezultat poate fi obinut sub "forma" unei
variabile-tablou.
Ci - reprezint coloanele (care sunt atribute sau expresii de atribute) tabelei-rezultat;
Rj - sunt relaiile ce trebuie parcurse pentru obinerea rezultatului;
P - este predicatul (condiia) simplu sau compus ce trebuie ndeplinit de tupluri pentru a fi
incluse n tabela-rezultat.
Cnd clauza WHERE este omis, se consider implicit c predicatul P are valoarea logic
"adevrat".
Dac n locul coloanelor C1, C2, ... Cn apare simbolul "*", n tabela-rezultat vor fi incluse
toate coloanele (atributele) din toate relaiile specificate n clauza FROM. De asemenea, n tabelarezultat, nu este obligatoriu ca atributele s prezinte nume identic cu cel din tabela enumerat n
clauza FROM. Schimbarea numelui se realizeaz prin opiunea AS.
Rezultatul unei fraze SELECT l vom considera ca fiind sub forma unei tabele oarecare.
Trebuie avut n vedere, ns, c rezultatul interogrii poate fi obinut i sub forma unei tabele
temporare sau chiar a unei variabile-tablou (matrice). n unele SGBD-uri, cum ar fi FoxPro,
formatul general al frazei SELECT conine i clauza INTO.
SELECT
FROM
INTO destinaie
WHERE
68
BAZE DE DATE
Destinaie specific dac se va obine o tabel "normal", o tabel temporar (tabel care se
terge automat la nchiderea sa) sau o variabil-tablou. Dac clauza INTO nu este utilizat, atunci n
urma interogrii se obine o tabel temporar cu numele predeterminat (Query).
Uneori, tabela rezultat ("normal" sau temporar) "ncalc" poruncile modelului relaional.
Conform restriciei de entitate, ntr-o relaie nu pot exista dou linii identice. Or, n SQL, tabela
obinut dintr-o consultare poate conine dou sau mai multe tupluri identice.
Spre deosebire de algebra relaional, n SQL nu se elimin automat tuplurile identice
(dublurile) din tabela-rezultat. Pentru aceasta este necesar utilizarea opiunii DISTINCT:
SELECT DISTINCT C1, C2, ..., Cn
FROM R1, R2, ..., Rm
WHERE P
LOCALITI
CodPosta
Localitate
l
6600
Iai
5300
Focani
5725
Pacani
6750
Tg. Frumos
CLIENI
CodClien
t
1001
1002
1003
1004
1005
1006
1007
1008
Jude
Iai
Vrancea
Iai
Iai
NumeClient
TEXTILA SA
MODERN SRL
OCCO SRL
FILATURA SA
INTEGRATA SA
AMI SRL
AXON SRL
ALFA SRL
Adresa
Bld. Copou, 87
Bld. Grii, 22
NULL
Bld. Unirii, 145
I.V.Viteazu, 115
Galaiului, 72
Silvestru, 2
Prosperitii, 15
CodPostal
6600
5300
6600
5300
5725
6750
6600
5725
FACTURIEMISE
NrFactur CodClient
111111
1003
111112
1001
111113
1004
111114
1003
111115
1008
111116
1008
111117
1006
111118
1007
111119
1005
111120
1003
111121
1001
111122
1007
111123
1006
Data
17.06.2000
17.06.2000
18.06.2000
18.06.2000
18.06.2000
19.06.2000
20.06.2000
23.06.2000
24.06.2000
24.06.2000
24.06.2000
24.06.2000
25.06.2000
ValoareTotal
17000000
2850000
5850000
28500000
35700000
8700000
11000000
15000000
47250000
3000000
4250000
8750000
6600000
69
TVAColectat
2714286
455042
934034
4550420
5700000
1389076
1756303
2394958
7544118
478992
678571
1397059
1053782
BAZE DE DATE
111124
111125
111126

1004
1003
1002
25.06.2000
30.06.2000
01.07.2000
38650000
12850500
54250000
6171008
2051761
8661765
Figura nr. 6.1. Baza de date utilizat n exemple
n concluzie, o fraz SELECT, n forma n care a fost prezentat, corespunde:

unei selecii algebrice (clauza WHERE - P)
unei proiecii (SELECT - Ci)
unui produs cartezian (FROM - R1 R2 ... Rm)
i conduce la obinerea unei noi relaii (tabele-rezultat) cu n coloane, fiecare coloan fiind:
un atribut din R1, R2, ..., Rm sau
o expresie calculat pe baza unor atribute din R1, R2, ..., Rm.
n exemplele incluse n acest capitol se va utiliza baza de date prezentat n figura 6.1.
Exemplu
Care este, pentru fiecare factur emis, valoarea fr TVA ?

SELECT NrFactur, ValoareTotal - TVAColectata AS ValFaraTVA
FROM FACTURIEMISE
Tabela rezultat din figura 6.2 conine dou atribute: NrFactur i ValFaraTVA. Ultimul este
un cmp calculat.
Figura nr. 6.2. Exemplu de cmp calculat (ValFaraTVA)
Interogri care utilizeaz operatorii asambliti din algebra relaional

Reuniunea
SELECT *
FROM R1
UNION
SELECT *
FROM R2
70
BAZE DE DATE
Operatorul pentru reuniune este deci UNION. De remarcat c, la reuniune, SQL elimin
automat dublurile, deci nu este necesar utilizarea clauzei DISTINCT. Operatorul UNION este
prezent n toate SGBD-urile importante.
Intersecia
Pentru realizarea interseciei a dou tabele, R1 i R2 se utilizeaz operatorul INTERSECT:
SELECT *
FROM R1
INTERSECT
SELECT *
FROM R2
Dac n produsele profesionale, precum DB2 (IBM) sau Oracle operatorul este prezent, n
schimb multe din cele din categoria uoar, precum Visual Fox Pro, INTERSECT rmne un
deziderat, funcionalitatea sa realizndu-se prin subconsultri (operatorii IN i EXISTS) sau, uneori,
prin jonciune.
Diferena
Diferena dintre tabelele R1 i R2 se realizeaz utiliznd operatorul MINUS sau EXCEPT.
Fraza SELECT urmtoare funcioneaz n Oracle.
SELECT *
FROM R1
MINUS
SELECT *
FROM R2
n DB2 MINUS trebuie nlocuit cu EXCEPT, iar n Visual FoxPro exist nici MINUS i nici
EXCEPT, astfel nct, ca i n cazul interseciei, este necesar a se recurgere la ali operatori, precum
IN sau EXISTS.
Produsul cartezian
n SQL nu exist operator explicit pentru efectuarea produsului cartezian. Dac n clauza
FROM apar dou relaii, R1 i R2, atunci, n lipsa unei condiii de jonciune formulat n clauza
WHERE, tabela rezultat va conine liniile obinute din produsul cartezian R1 R2.
SELECT *
FROM R1, R2
Interogri care utilizeaz operatorii relaionali din algebra relaional

Selecia
Exemplu 1
Care sunt localitile din judeul Iai n care firma are clieni ?
Tabela n care se afl rezultatul i asupra creia se aplic predicatul de selecie este LOCALITI.
Predicatul este Jude = "Iai". Fraza SELECT va avea forma:
71
BAZE DE DATE
SELECT *
FROM LOCALITI
WHERE Jude = "Iai"
Rezultat:
CodPostal
6600
5725
6750
Localitate
Iai
Pacani
Tg. Frumos
Jude
Iai
Iai
Iai
Exemplu 2
Care dintre facturile emise dup 23.06.98 prezint valoarea mai mare sau egal cu 3 000 000 lei ?
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND ValoareTotala >= 3000000
Rezultat:
NrFactur
CodClient
111119
1005
111124
1004
111126
1002
Data
24.06.2000
25.06.2000
01.07.2000
ValoareTotal
4 725 000
3 850 000
5 425 000
TVAColectat
850 500
693 000
976 500
Dup cum se observ, operatorul AND a fost utilizat pentru a introduce un "I" logic, dup
cum OR se utilizeaz pentru SAU logic. n SQL, pentru comparare, n afara operatorilor "clasici"
specificai mai sus, pot fi utilizai i ali operatori, dintre care n acest paragraf ne vom opri la:
BETWEEN (ntre, cuprins ntre),
LIKE (ca i, la fel ca),
IN (n) i
IS NULL.
Operatorul BETWEEN
Acest operator permite specificarea unui interval de valori n care trebuie s se ncadreze
cmpul/expresia testat. Acest interval se refer la valori numerice sau la date calendaristice.
Exemplu 3
Se reformuleaz ultima interogare:
Care sunt facturile emise dup 23.06.2000 i care au valoarea cuprins ntre 3 000 000 i
4 000 000 lei ?
Fr operatorul BETWEEN fraza SELECT se scrie:
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND
ValoareTotala >= 3000000 AND ValoareTotala <= 4000000
Utiliznd operatorul BETWEEN se poate scrie:
SELECT *
FROM FACTURIEMISE
WHERE Data > {23.06.2000} AND ValoareTotala BETWEEN 3000000 AND 4000000
Operatorul LIKE
Acest operator se folosete pentru a compara un atribut de tip ir de caractere (ex.
NumeClient, Adresa, Localitate) cu un literal (constant de tip ir de caractere). Astfel, dac se
72
BAZE DE DATE
dorete obinerea unei tabele-rezultat care s conin numai clienii ai cror nume ncepe cu litera
M, putem scrie predicatul din clauza WHERE sub forma: NumeClient LIKE "M%". Deoarece dup
litera M apare semnul "%", se vor extrage din tabela CLIENI toate tuplurile pentru care valoarea
atributului NumeClient ncepe cu litera M, indiferent de lungimea acestuia (ex. MELCRET,
MIGAS, MITA, MATSUSHITA etc.). Despre semnul "%" se spune c este un specificator
multiplu, joker sau masc.
Un alt specificator multiplu utilizat n multe versiuni SQL este liniua de subliniere ("_").
Spre deosebire de "%", "_" substituie un singur caracter. Diferena dintre cei doi specificatori
multipli este pus n eviden n exemplele urmtoare.
Exemplu 4
Care sunt clienii ai cror nume este format din apte caractere, ncepe cu litera A i sunt societi
cu rspundere limitat (SRL-uri) ?
SELECT *
FROM CLIENI
WHERE NumeClient LIKE "A__ SRL"
Rezultatul va fi cel din figura 6.3.
Figura nr. 6.3. Utilizarea specificatorului multiplu "_"
Dac s-ar fi utilizat simbolul "%":
SELECT *
FROM CLIENI
WHERE NumeClient LIKE "A%SRL",
rezultatul ar fi fost cel din figura 6.4.
Figura nr. 6.4. Utilizarea specificatorului multiplu "%"
n concluzie, "_" nlocuiete (substituie) un singur caracter, n timp ce "%" nlocuiete un ir

de caractere de lungime variabil (ntre 0 i n caractere). Cei doi specificatori multipli pot fi utilizai
mpreun.
Operatorul IN
Format general:
expresie1 IN (expresie2, expresie3, ...)
Rezultatul evalurii unui predicat ce conine acest operator va fi "adevrat" dac valoarea
expresiei1 este egal cu (cel puin) una din valorile: expresie2, expresie3, ... Este util atunci cnd
condiiile de selecie sunt mai complexe.
73
BAZE DE DATE
Exemplu 6
Care sunt localitile din judeele Iai i Vaslui?
Fr utilizarea operatorului IN interogarea se scrie:
SELECT *
FROM LOCALITI
WHERE Jude = "Iai" OR Jude = "Vaslui"
Utiliznd operatorul IN:
SELECT *
FROM LOCALITI
WHERE Jude IN ("Iai", "Vaslui")
Operatorul IS NULL
O valoare nul este o valoare nedefinit. Este posibil ca la adugarea unei linii ntr-o tabel,
valorile unor atribute s fie necunoscute. n aceste cazuri valoarea atributului pentru tuplul respectiv
este nul. Reamintim c, prin definiie, nu se admit valori nule pentru grupul atributelor care
constituie cheia primar a relaiei.
Exemplu 7
Dac se dorete aflarea clienilor pentru care nu s-a introdus adresa, interogarea se poate scrie:
SELECT *
FROM CLIENTI
WHERE Adresa IS NULL
Cum n baza noastr de date, numai clientului OCCO SRL nu-i cunoatem adresa, rezultatul
interogrii este cel din figura 6.5.
Figura nr. 6.5. Extragerea valorilor NULLe
Observaii
d. Valoarea NULL nu se confund cu valoarea zero (pentru atributele numerice) sau cu valoarea
"spaiu" (pentru atributele de tip ir de caractere)
e. Operatorul NULL se utilizeaz cu IS i nu cu semnul "=". Dac s-ar utiliza forma expresie =
NULL i nu expresie IS NULL, rezultatul evalurii va fi ntotdeauna fals, chiar dac expresia
nu este nul !
Proiecia. Opiunea ORDER BY

Coloanele tabelei-rezultat al consultrii sunt specificate n clauza SELECT, fiind separate prin
virgul.
Exemplu 1
Care sunt judeele n care firma are clieni ?
Este necesar parcurgerea relaiei LOCALITI, singurul atribut care intereseaz fiind Jude.
Deoarece SQL nu elimin dublurile automat, dac se dorete ca n tabela-rezultat o localitate s
figureze o singur dat, se utilizeaz opiunea DISTINCT:
SELECT DISTINCT Jude
FROM LOCALITI
74
BAZE DE DATE
Exemplu 2
Care este denumirea fiecrei localiti i judeul n care se afl ?
SELECT Localitate, Jude
FROM LOCALITI
Prezentarea localitilor n ordinea alfabetic a numelui acestora este posibil prin apelnd la
clauza ORDER BY:
SELECT Localitate, Jude
FROM LOCALITI
ORDER BY Localitate
Pentru ordonarea liniilor tabelei-rezultat n funcie de jude i, n cadrul aceluiai jude, n

ordinea invers a localitii (de la Z la A), fraza SELECT se formuleaz astfel:
SELECT *
FROM LOCALITI
ORDER BY Jude ASCENDING, Localitate DESCENDING
Figura nr. 6.6. Clauza ORDER BY
Opiunile ASCENDING (cresctor) i DESCENDING (descresctor) indic deci modul n

care se face ordonarea tuplurilor tabelei-rezultat al interogrii.
Prioritatea de ordonare este stabilit prin ordinea atributelor specificate n ORDER BY:
ordonarea "principal" se face n funcie de valorile primului atribut specificat; n cadrul grupelor de
tupluri pentru care valoarea primului atribut este identic, ordinea se stabilete dup valoarea celui
de-al doilea atribut specificat .a.m.d.
Dac n ORDER BY lipsesc opiunile ASCENDING/DESCENDING, ordonarea se face
cresctor.
onciunea
SQL nu prezint clauze sau operatori speciali pentru realizarea theta-jonciunii, echijonciunii sau jonciunii naturale. Dar, aa cum am vzut, o jonciune este o combinaie de produs
cartezian i selecie.
Exemplu 1
Revenind la exemplele din algebra relaional, echi-jonciunea tabelelor FURNIZOR1 i
FURNIZOR2 n SQL se realizeaz prin fraza SELECT:
SELECT *
FROM FURNIZOR1, FURNIZOR2
WHERE FURNIZOR1.CodF = FURNIZOR2.CodF
Observaie:
n SQL2, echijonciunea poate fi realizat prin clauza INNER JOIN plasat n clauza FROM. Astfel,
ultima fraz SELECT se poate redacta, n SQL2, fr clauza WHERE:
SELECT *
75
BAZE DE DATE
FROM FURNIZOR1 INNER JOIN FURNIZOR2 ON

FURNIZOR1.CodF = FURNIZOR2.CodF
Exemplu 2
Care sunt clienii din municipiul Focani ?
SELECT *
FROM CLIENI INNER JOIN LOCALITI
ON CLIENI.CodPostal = LOCALITI.CodPostal
WHERE Localitate=Focsani
Produsul cartezian al tabelelor CLIENI i LOCALITI este prezentat n figura 6.7.
Figura nr. 6.7. Produsul cartezian CLIENI LOCALITI
Din cele 32 de linii sunt selectate cele care ndeplinesc condiia de jonciune, CLIENI.CodPostal = LOCALITI.CodPostal, i pe cea suplimentar - Localitate=Focsani. n final,
rezultatul este cel din figura 6.8.
Figura nr. 6.8. Rezultatul final al jonciunii i al seleciei suplimentare
Exemplu 3
Care sunt facturile emise clienilor din judeul Iai ?
SELECT NrFactura
FROM FACTURIEMISE, CLIENI, LOCALITI
WHERE FACTURIEMISE.CodClient = CLIENI.CodClient
76
BAZE DE DATE
AND CLIENI.CodPostal = LOCALITI.CodPostal

AND Jude=Iai
Soluia este echivalent cu urmtoarea:
SELECT NrFactura
FROM FACTURIEMISE FE INNER JOIN CLIENI C
ON FE.CodClient = C.CodClient
INNER JOIN LOCALITI L
ON C.CodPostal = L.CodPostal
WHERE Jude=Iai
Exemplu 4
Care sunt facturile emise n aceeai zi ca i factura 111113 ?
Problema propus poate fi rezolvat relativ uor folosind o subconsultare, dup cum va fi prezentat
n paragraful urmtor. Pn una-alta, soluia pe care o avem n acest moment la ndemn se bazeaz
pe autojonciune. Autojonciune nseamn jonciunea unei tabele cu ea-nsi, practic, jonciunea a
dou instane ale unei aceleai tabele:
SELECT FE1.NrFactura, FE1.Data
FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2

ON FE1.Data= FE2.Data AND FE2.NrFactura=111113
Soluia de mai sus conduce la rezultatul din figura 6.9. S vedem prin ce mecanism.
Figura nr. 6.9. Facturile emise n aceeai zi ca i 111113
Jonciunea celor dou instane, FE1 i FE2, ale tabelei FACTURIEMISE dup condiia
FE1.Data = FE2.Data:
SELECT *
FROM FACTURIEMISE FE1 INNER JOIN FACTURIEMISE FE2
ON FE1.Data= FE2.Data
conduce la un rezultat precum cel din figura 6.10.
77
BAZE DE DATE
Figura nr. 6.10. Auto-jonciunea, dup valorile Data, tabelei FACTURIEMISE
Din cele 38 de linii, prin predicatul FE2.NrFactura=111113 rmn numai 3, cele din figura
6.9.
Exemplu 5
Care sunt clienii crora NU le-am ntocmit facturi pe 18/06/2000 ?
La aceast problem se pot formula mai multe soluii. Una ar fi bazat pe diferena dintre toi
clienii (extrai din tabela CLIENI) i cei crora le-am trimis facturi pe 18 iunie. innd seama c
numele clientului este cheie alternativ, deci unic, se poate scrie:
SELECT NumeClient
FROM CLIENTI
MINUS
SELECT NumeClient
FROM CLIENTI INNER JOIN FACTURIEMISE
ON
CLIENTI.CodClient=FACTURIEMISE.CodClient
Data={^2000/06/18}
AND
O asemenea soluie funcioneaz n Oracle (folosind funcia de conversie TO_DATE pentu

constant), DB2 (nlocuind, n plus, MINUS cu EXCEPT), nu ns i n Visual FoxPro. Avnd n
vedere c nu avem cunotine privind subconsultrile, putem recurge la un artificiu bazat pe o form
interesana a jonciunii, i anume jonciunea extern.
S examinm fraza SELECT urmtoare i rezultatul acesteia din figura 6.11.
SELECT *
FROM CLIENTI C LEFT OUTER JOIN FACTURIEMISE FE
ON C.CodClient=FE.CodClient AND Data={^2000/06/18}
78
BAZE DE DATE
Figura nr. 6.11. O jonciune extern
Prima observaie: n rezultat sunt incluse toi clienii, adic, toate nregistrrile din tabela
CLIENI. A doua observaie: jonciunea nu mai este de tip INNER i LEFT OUTER, adic extern
la stnga. Cum dintre CLIENI i FACTURIEMISE, cea de la stnga este prima, rezult c n
rezultat sunt extrase toate liniile din aceasta, chiar dac nu au linii corespondente n tabela din
dreapta. n cazul nostru, TEXTILA SA, MODERN SRL, INTEGRATA SA, AMI SRL AXON
SRL nu au fcut cumprturi de la firma noastr pe 18 iunie 2000. Ne dm seama de acest lucru
observnd c pe liniile coresponde acestora, valorile atributelor preluate din FACTURIEMISE sunt
NULL.
Astfel nct, pentru a rspunde punctual la problema pus, ar trebui extrase liniile n care, n
urma jonciunii externe, FE.NrFactur (sau oricare alt atribut din FE) este NULL. Paradoxal sau nu,
fraza urmtoare nu obine rezultatul scontat n VFP:
SELECT *
WHERE FE.NrFactura IS NULL
n schimb, se poate folosi un artificiu prin ntrebuinarea funciei NVL:

SELECT *
WHERE NVL(FE.NrFactura,0) = 0
Funcia NVL convertete valorile nule ale atributului NrFactura n 0. Principial, soluia bazat
pe NVL are acelai mecanism ca i precedenta interogare. Cu singura diferen c funcioneaz,
dup reiese din figura 6.12.
Figura nr. 6.12. Clienii fr facturi pe 18 iunie 2000
Firete, pentru a obine numai numele clienilor, este necesar nlocuirea asteriscului din
clauza SELECT cu atributul NumeClient.
Ar mai fi de adugat c exist trei tipuri de jonciune extern: la stnga (LEFT OUTER
JOIN), la dreapta (RIGHT OUTER JOIN) i total (FULL OUTER JOIN). La jonciunea extern
la dreapta sunt extrase liniile echi-jonciunii plus liniile tabelei din dreapta ce nu ndeplinesc
79
BAZE DE DATE
condiia formulat prin predicatul de jonciune. Jonciunea extern total reprezint, n fapt,
reuniunea (cu eliminarea dublurilor) jonciunilor la stnga i la dreapta.
Sub-consultri. Operatorul IN
O alt facilitate deosebit de important a limbajului SQL o constituie posibilitatea includerii
(imbricrii) a dou sau mai multe fraze SELECT, astfel nct pot fi formulate interogri cu mare
grad de complexitate.
Operatorul IN poate fi utilizat i pentru includerea unei fraze SELECT ntr-o alt fraz
SELECT.
Exemplu 1
Care sunt facturile emise n aceeai zi n care a fost ntocmit factura 111113 ?
SELECT *
FROM FACTURIEMISE
WHERE Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113)
Sub-consultarea
SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111114
are ca rezultat o tabel alctuit dintr-o singur coloan (Data) i o singur linie ce conine
valoarea atributului Data pentru factura 111113, ca n figura 6.13:
Figura nr. 6.13. Rezultatul sub-consultrii
Clauza WHERE Data IN determin cutarea n tabela FACTURIEMISE a tuturor tuplurilor

(liniilor) care au valoarea atributului Data egal cu una din valorile tuplurilor (n cazul nostru, egal
cu valoarea tuplului) din tabela obinut prin "sub-consultare" (n cazul nostru, tabela din figura
6.13). Cu alte cuvinte, n acest caz WHERE Data IN va selecta toate facturile pentru care data
emiterii este 18/06/2000 figura 6.14.
Figura nr. 6.14. Facturile emise n aceeai zi ca i 111113
Exemplu 2
Care sunt facturile emise n alte zile dect cea n care a fost ntocmit factura 111113?
SELECT *
FROM FACTURIEMISE
80
BAZE DE DATE
WHERE Data NOT IN

(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113)
S-a utilizat negaia, testndu-se non-apartenena la o relaie creat printr-o sub-fraz SELECT
(vezi figura nr. 6.15).
Figura nr. 6.15. Facturile emise n alte zile dect factura 111113
Exemplu 3
Care sunt clienii crora li s-au trimis facturi ntocmite n aceeai zi cu factura 111113?
SELECT DISTINCT NumeClient
FROM CLIENI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE
WHERE Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactur=111113))
Am ilustrat modul n care pot fi imbricate (nlnuite, incluse) trei fraze SELECT. Soluia
este valabil n SGBD-urile profesionale (DB2, Oracle), nu ns i n VFP, n care orice
interogare poate fi desfutata pe maximum dou nivele (SELECT-ul principal, plus un nivel de
sub-consultri). Pentru a reduce numrul straturilor de corelare, se poate folosi, n acest caz,
jonciunea:
SELECT DISTINCT NumeClient
FROM CLIENI, FACTURIEMISE
WHERE CLIENI.CodClient=FACTURIEMISE.CodClient
AND Data IN
(SELECT Data
FROM FACTURIEMISE
WHERE NrFactura=111113)
Rezultatul din figura 6.16 demonstreaz c soluia este viabil.
81
BAZE DE DATE
Figura nr. 6.16. Clieni pentru care exist mcar o factur

ntocmit n aceeai zi cu 111113
Se poate reine, ca regul general, c aproape orice consultare poate fi redactat n mai multe
moduri, n funcie de experiena i imaginaia celui care o formuleaz.
Funcii de agregare: COUNT, SUM, AVG, MAX, MIN

Formatul general al unei fraze SELECT ce conine funcii predefinite este:
SELECT funcia-predefinit1, ... , funcia-predefinitN
FROM list-tabele
WHERE condiii
Rezultatul oricrei fraze SELECT este o nou relaie (tabel). n lipsa opiunii GROUP
BY, dac n clauza SELECT este prezent o funcie predefinit, tabela rezultat va conine o singur
linie.
Funcia COUNT contorizeaz valorile unei coloane, altfel spus, numr, ntr-o relaie, cte
valori diferite de NULL are coloana specificat.
Exemplu 1
Ci clieni are firma ?

SELECT COUNT (CodClient) AS Nr_Clienti
FROM CLIENTI
n funcia COUNT se poate utiliza ca argument, n locul numelui unei coloane, semnul *; n
acest caz se va determina cte linii are tabela la care se aplic funcia respectiv.
Exemplu 2
La ci clieni s-au trimis facturi ?

SELECT COUNT ()
FROM CLIENTI
WHERE CodClient IN
(SELECT CodClient
FROM FACTURIEMISE)
Rezultatul corect poate fi ns obinut i prin utilizarea clauzei DISTINCT astfel:
SELECT COUNT (DISTINCT CodClient)

FROM FACTURIEMISE
Funcia SUM calculeaz suma valorilor unei coloane.

Exemplu 3
Care este valoarea total a facturilor emise ?

SELECT SUM (ValoareTotala) AS Total_FP
FROM FACTURIEMISE
82
BAZE DE DATE
Figura 6.17. Totalul vnzrilor
Exemplu 4
Care este totalul valorii facturilor trimise clientului AXON SRL ?

SELECT SUM (ValoareTotala) AS Total_FE_AXON
FROM FACTURIEMISE, CLIENTI
WHERE FACTURIEMISE.CodClient = CLIENTI.CodClient
AND NumeClient = "AXON SRL"

Funciile MAX i MIN. Determin valorile maxime, respectiv minime ale unei coloane n
cadrul unei tabele.
Exemplu 5
Care este cea mai mic valoare a unei facturi emise ?

SELECT MIN(ValoareTotala)
FROM FACTURIEMISE
Exemplu 6
Care este factura emis ce are cea mai mare valoare ?

SELECT NrFactura, ValoareTotala
FROM FACTURIEMISE
WHERE ValoareTotala =
(SELECT MAX (ValoareTotala)
FROM FACTURIEMISE)
Subconsultarea extrage valoarea total maxim a unei facturi, valoare ce va fi utilizat ca
argument pentru SELECT-ul principal. Rezultatul este cel din figura 6.18.
Figura nr. 6.18. Factura cea mai valoroas
Atenie ! Varianta urmtoare nu este corect:

SELECT NrFactura, MAX(ValoareTotala )
FROM FACTURIEMISE
Dac n Oracle sau DB2 la execuia acestei interogri se afieaz un mesaj de eroare, n
Visual FoxPro nu, aa c unii utilizatori s-ar putea baza pe rezultatul afiat.
Gruparea tuplurilor. Clauzele GROUP BY i HAVING

SQL permite utilizarea clauzei GROUP BY pentru a forma grupe (grupuri) de tupluri ale
unei relaii, pe baza valorilor comune ale unei coloane. n frazele SELECT formulate pn n acest
paragraf, prin intermediul clauzei WHERE au fost selectate tupluri din diferite tabele.
83
BAZE DE DATE
Prin asocierea unei clauze HAVING la o clauz GROUP BY este posibil selectarea
anumitor grupe de tupluri ce ndeplinesc un criteriu.
Rezultatul unei fraze SELECT ce conine clauza GROUP BY este o tabel care va fi
obinut prin regruparea tuturor liniilor din tabelele enumerate n FROM, care prezint o aceeai
valoare pentru o coloan sau un grup de coloane.
Formatul general este:
SELECT coloan 1, coloan 2, ...., coloan m
FROM tabel
GROUP BY coloan-de-regrupare
Exemplu 1
Care este totalul zilnic al valorii facturilor emise ?

SELECT Data, SUM (ValoareTotala) AS Total_Zilnic
FROM FACTURIEMISE
GROUP BY Data
n acest caz tabela-rezultat va avea un numr de linii egal cu numrul de date calendaristice
distincte din tabela FACTURIEMISE. Pentru toate facturile aferente unei zile se va calcula suma
valorilor, datorit utilizrii funciei SUM(ValoareTotala).
Succesiunea pailor este urmtoarea:
1. Se ordoneaz liniile tabelei FACTURIEMISE n funcie de valoarea atributului Data figura 6.19.
Figura nr. 6.19. Pasul 1 al gruprii
2. Se formeaz cte un grup pentru fiecare valoare distinct a atributului Data - vezi figura
6.20.
84
BAZE DE DATE
Figura nr. 6.20. Al doilea pas al gruprii
3. Pentru fiecare din cele nou grupuri se calculeaz suma valorilor atributului
ValoareTotala. Tabela rezultat va avea nou linii, ca n figura 6.21.
Figura nr. 6.21. Rezultatul final al gruprii
Exemplu 2
Care este numrul facturilor emise pentru fiecare client ?

SELECT NumeClient, COUNT(NrFactura)
FROM FACTURIEMISE INNER JOIN CLIENTI
ON FACTURIEMISE.CodClient = CLIENTI.CodClient
GROUP BY FACTURIEMISE.CodClient
Pn la standardul SQL99 i publicarea Amendamentului OLAP la acest standard, n SQL nu

pot fi calculate, prin GROUP BY, subtotaluri pe mai multe niveluri. Pentru aceasta este necesar
scrierea de programe n SGBD-ul respectiv.
Clauza HAVING permite introducerea unor restricii care sunt aplicate grupurilor de tupluri,
deci nu tuplurilor "individuale", aa cum "face" clauza WHERE. Din tabela rezultat sunt eliminate
toate grupurile care nu satisfac condiia specificat.
Clauza HAVING "lucreaz" mpreun cu o clauz GROUP BY, fiind practic o clauz
WHERE aplicat acesteia.
Formatul general este:
85
BAZE DE DATE
SELECT coloan 1, coloan 2, .... , coloan m

FROM tabel
GROUP BY coloan-de-regrupare
HAVING caracteristic-de-grup
Exemplu 3
Pentru facturile emise intereseaz valoarea zilnic a acestora (n funcie de data la care au
fost ntocmite, dar numai dac aceasta (valoarea zilnic) este de mai mare de cinci
milioane lei.
SELECT Data, SUM(ValoareTotala)
FROM FACTURIEMISE
GROUP BY Data
HAVING SUM(ValoareTotala) > 15000000
La execuia acestei fraze, se parcurg cei trei pai prezentai la exemplul 1, apoi, din cele nou tupluri
obinute
prin
grupare,
sunt
extrase
numai
cele
care
ndeplinesc
condiia
SUM(ValoareTotala)>15000000. Rezultatul final este cel din figura 6.22.
Figura 6.22. Rezultatul consultrii - exemplul 3
Exemplu 4
S se afieze ziua n care s-au ntocmit cele mai multe facturi.

SELECT Data
FROM FACTURIEMISE
GROUP BY Data
HAVING COUNT(*) >= ALL
(SELECT COUNT(*)
FROM FACTURIEMISE
GROUP BY Data)
Din pcate, nici acest tip de interogare (prezena subconsultrilor n clauza HAVING) nu este
agreat de Visual FoxPro, astfel nct este necesar utilizarea mai multor fraze SELECT i salvarea
rezultatelor intermediare fie n tabele derivate (view-uri), fie n cursoare (NR_PE_ZILE) care, n
VFP sunt tabele temporare a cror via este limitat de nchiderea lor, explicit sau implicit:
SELECT Data, COUNT(*) AS Nr ;
FROM FACTURIEMISE ;
INTO CURSOR NR_PE_ZILE ;

GROUP BY Data
SELECT Data, Nr ;
FROM NR_PE_ZILE ;
WHERE Nr >= ;
(SELECT MAX(Nr) ;
FROM NR_PE_ZILE)
86
BAZE DE DATE
Coninutul cursorului NR_PE_ZILE, precum i rezultatul final sunt cele din figura 6.23.
Figura 6.23. Obinerea n VFP a zilei cu cele mai multe facturi
COMENZI PENTRU ACTUALIZAREA BAZELOR DE DATE

SQL prezint comenzi specifice pentru modificarea coninutului unei tabele, nelegnd prin
aceasta trei aciuni prin care se actualizeaz baza:
a) adugarea de noi linii la cele existente ntr-o tabel,
b) tergerea unor linii,
c) modificarea valorii unui atribut.
Adugarea de nregistrri
Exemplu 1
S presupunem c, la un moment dat, ntreprinderea vinde produse i firmei RODEX SRL care are
sediul pe strada Sapienei, nr.44 bis, n localitatea Iai.
Acest nou client trebuie "introdus" n baza de date, operaiune care n SQL, se realizeaz prin
comanda:
INSERT
INTO CLIENI
VALUES (1009, RODEX SRL, Sapienei, 44 bis, 6600)
Fraza INSERT de mai sus poate fi scris i sub forma
INSERT
INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal)
VALUES (5009, RODEX SRL, Sapienei 44 bis, 6600).
Dup cum se observ, dup numele tabelei (CLIENI) au fost enumerate toate atributele
pentru care se introduc valori prin clauza VALUES. Dac nu s-ar fi cunoscut adresa clientului
RODEX, atunci fraza INSERT ar fi avut una din formele:
INSERT
INTO CLIENI (CodClient, NumeClient, Adresa, CodPostal)
VALUES (5009, "RODEX SRL", NULL, 6600)
sau
87
BAZE DE DATE
INSERT
INTO CLIENI (CodClient, NumeClient, CodPostal)
VALUES (5009, RODEX SRL, 6600)
n noua linie a tabelei CLIENI valoarea atributului Adresa va fi NULL.
tergerea de nregistrri
Operaiunea de eliminarea a una sau mai multe linii dintr-o tabel, pe baza unui predicat, se
realizeaz n SQL prin comanda DELETE care are sintaxa:
DELETE
FROM nume-tabel
WHERE predicat
Exemplu 2
S se elimine din tabela CLIENI linia aferent clientului MODERN SRL (cod 1002).
DELETE
FROM CLIENI
WHERE CodClient = 1002
Exemplu 3
S se tearg datele referitoare la fiecare vnzare de produs pentru clienii din oraul Focani.
DELETE
FROM FACTURIEMISE
WHERE CodClient IN
(SELECT CodClient
FROM CLIENI, LOCALITI
WHERE CLIENI.CodPostal=LOCALITI.CodPostal AND

Localitate = "Focani"))
Nici aceast form nu funcioneaz n VFP. n general, tergerea unor linii trebuie privit cu
mult circumspecie, deoarece atunci cnd linia de ters conine valori ale unor atribute ce apar n
alte tabele ca i chei strine, exist riscul pierderii integritii refereniale.
Standardul SQL92 (nu i dialectul SQL din VFP) permite la crearea unei tabele descrierea
aciunii care se va derula la tergerea unei linii printe n cazul n care exist linii-copil. Spre
exemplu, se poate refuza tergerea de linii din tabela CLIENI, dac la crearea tabelei
FACTURIEMISE se specific:
CREATE TABLE FACTURIEMISE
(NrFactura DECIMAL(8) NOT NULL,
DataFactura DATE,
CodClient
DECIMAL(6) NOT NULL,
ValoareTotala DECIMAL(15) not NULL,
TVAColectata DECIMAL(14) ,
PRIMARY KEY (NrFactura),
FOREIGN KEY (CodClient) REFERENCES CLIENTI
ON DELETE RESTRICT)
Modificarea valorilor unor atribute

Pentru modificarea valorilor unuia sau multor atribute dintr-o tabel, comanda utilizat este
UPDATE care are formatul general:
UPDATE tabel
88
BAZE DE DATE
SET atribut = expresie

WHERE predicat
Ca rezultat, vor fi modificate valorile atributului specificat, noile valori ale acestuia fiind
cele care rezult n urma evalurii expresiei; modificarea se va produce pe toate liniile tabelei care
ndeplinesc condiia specificat n predicat.
Exemplu 4
n tabela CLIENI, fiecrui client i-a fost atribuit un cod unic, ncepnd cu 1001. Dac din diferite
motive, se dorete ca "numerotarea" clienilor s nceap de la 3001, pstrndu-se ordinea, se
poate articula fraza UPDATE urmtoare:
UPDATE CLIENI
SET CodClient = CodClient + 2000
Exemplul este suficient de neinspirat, deoarece n practic modificarea codului clienilor
antreneaz modificarea valorilor acestui atribut n toate tabelele n care apare (n cazul nostru
FACTURIEMISE), datorit faptului c este o cheie strin.
3.4.6. Aplicaii rezolvate
Se consider o aplicaie de gestiune economic care ruleaz ntr-o entitate economic. Baza de date
(gest_ec) conine urmtoarele tabele:
PRODUSE
Cod depozit Cod
Denumire
Stoc
Data curenta Unitate de
(CODD)
Produs
Produs
(STOC)
(DATACRT) msur
(CODP)
(DENP)
(UM)
Int(11)
Int(11)
Varchar(60) Double(12,3) date
Varchar(3)
PRETURI
Cod produs
(CODP)
INT(11)
COMENZI
nr.comand
(NRCOM)
Int(11)
Pret maxim
Pret minim
Data de inceput
(PRETMAX)
(PRETMIN)
(DATAI)
DOUBLE(12,2) DOUBLE(12,2) DATE
Cod produs
(CODP)
Int(10)
Cod client
(CODCL)
Int(10)
Data livrarii
(DATAL)
date
DEPOZITE
Cod depozit(CODD)
Denumire depozit (DEND)
Int(10)
Varchar (50)
SALARIATI
Marca
Nume
(MARCA) (NUME)
Functie
(FUNCT)
Int(10)
Char(50)
Char(20)
CLIENI
Cod client
CODL
Denumire
client
Cod fiscal Registrul

CODFISC comertului
Cod
depozit
(CODD)
Int(10)
Salariu
(SALA)
Int(10)
89
Data de sfrit
(DATASF)
DATE
Cantitate
Pret
(CANT)
(PRET)
Double(10,2) Double(10,2)
Nr. De salariai
(NRSAL)
Int(2)
Venit
suplimentar
(VENS)
Int(10)
Cod
superior
(CODS)
Int(10)
Adresa
Telefon
Sold
(ADRESA) (TELEFON) (SOLD)
BAZE DE DATE
Int(10)
(DENCL)
Char(50)

Char(20)
(REGCOM)
Char(20)
Char(50)
Char(10)
Double(12,3)
1. S se creeze tabelele
CREATE TABLE PRODUSE (CODD INTEGER NOT NULL, CODP INTEGER NOT NULL,
DENP VARCHAR(50) NOT NULL, STOC DOUBLE(10,3), DATACRT DATE, UM
VARCHAR(3), PRIMARY KEY (CODD,CODP), FOREIGN KEY (CODD) REFERENCES
DEPOZITE(CODD), FOREIGN KEY (CODP) REFERENCES PRETURI(CODP) );
CREATE TABLE PRETURI (CODP INTEGER NOT NULL PRIMARY KEY, PRETMAX
DOUBLE(10,2) NOT NULL, PRETMIN DOUBLE(10,2) NOT NULL, DATAI DATE NOT
NULL, DATASF DATE
NOT NULL, FOREIGN KEY (CODP) REFERENCES
COMENZI(CODP));
CREATE TABLE COMENZI (NRCOM INTEGER NOT NULL, CODP INTEGER NOT NULL,
CODC INTEGER NOT NULL, DATAL DATE, CANT DOUBLE(10,3) NOT NULL, PRET
DOUBLE(10,2) NOT NULL, FOREIGN KEY (CODC) REFERENCES CLIENTI(CODC));
CREATE TABLE DEPOZITE (CODD INTEGER NOT NULL PRIMARY KEZ, DEND
VARCHAR(50) NOT NULL, NRSAL INTEGER NOT NULL , DATACRT DATE, UM
VARCHAR(3), FOREIGN KEY (CODD) REFERENCES SALARIATI(CODD));
CREATE TABLE SALARIATI (MARCA INTEGER NOT NULL PRIMARY KEY, NUME
VARCHAR(50) NOT NULL, FUNCT VARCHAR(20), CODD INTEGER NOT NULL, SALA
INTEGER NOT NULL, CODS INTEGER NOT NULL);
CREATE TABLE CLIENTI (CODC INTEGER NOT NULL PRIMARY KEY , DENC
VARCHAR(50) NOT NULL, CODFISCAL VARCHAR(20) NOT NULL, REGCOM
VARCHAR(20) NOT NULL, ADRESA VARCHAR(50) NOT NULL, TELEFON VARCHAR(20)
NOT NULL, SOLD DOUBLE(10,2));
2. sa se insereze in tabela SALARIATI urmatoarele inregistrari
Marca Nume
Funct
Codd
Sala
Vens
Cods
1111 AVRAM ION
VANZATOR 100000
21200
1000
1000
1222 BARBU DAN
VANZATOR 120000
20750
2000
1000
1000 COMAN RADU SEF DEP
130000
35000
2500
1000
3500 DAN ION
VANZATOR 160000
24500
3550
2500
2500 VLAD VASILE
SEF DEP
160000
36500
1500
2500
3700 MANU DAN
VANZATOR 160000
27500
2500
2500
2650 VLAD ION
VANZATOR 120000
25060
3500
1000
Insert into salariati set marca=1111,nume=AVRAM ION,funct=vanzator, codd=100000,
sala=21200, vens=1000, cods=1000; sau
Insert into salariati value (1111,AVRAM ION,vanzator,100000,21200,1000,1000);
3. S se selecteze toate coloanele din tabela SALARIATI.
SELECT * FROM SALARIATI;
4. Sa se selecteze coloanele MARCA,NUME,SALA,VENS din tabela SALARIATI;
Select marca,nume,sala,vens from SALARIATI ;
5. Sa se selecteze NUME din tabela SALARIATI
SELECT NUME FROM SALARIATI ;
6. Sa se selecteze coloana FUNCT din tabela SALARIATI in variantele utilizarii si neutilizarii
clauzei distinct.
90
BAZE DE DATE
A. SELECT FUNCT FROM SALARIATI ;

B. SELECT DISTINCT FUNCT FROM SALARIATI;
7. Sa se selecteze toate inregistrarile privind salariatii al caror salariu este mai mare de 15000 lei.
SELECT * FROM SALARIATI WHERE SALA>15000 ;
9. sa se selecteze coloanele MARCA,NUME si veniturile totale (SALA+VENS) pentru angajatii
care au un salariu mai mare ca 35000 lei.
SELECT MARCA,NUME, SALA+VENS FROM SALARIATI WHERE SALA>35000 ;
10. Sa se selecteze coloanele NUMA si FUNCT pentru salariatii care au functia de vanzator.
Select nume,funct from salariati where funct= vanzator
11. Sa se selecteze coloanele MARCA,NUME, CODD din tabela SALARIATI, daca venitul este
mai mare decat salariul.
Select MARCA,NUME,CODD from SALARIATI where vens>sala ;
12. sa se selecteze si afiseze campurile MARCA,NUME, SALARIU pentru salariatii ale caror
venituri suplimentare sunt mai mari ca 1500 lei si lucreaza in subordinea superiorului cu codul
1000.
Select MARCA,NUME,SALA from salariati where vens>1500 and cods=1000 ;
13. sa se afiseze toate coloanele pentru salariatii cu functia vanzator, care au salariul mai mare ca
20000 lei si lucreaza in subordinea superiorului cu codul 1000.
Select * from SALARIATI where sala>20000 and cods=1000 ;
14. sa se afiseze coloana NUME pentru angajatii care au salariul mai mic ca 21000 lei.
Select NUME from salariati where sala < 21000 ;
15. sa se selecteze inregistrarile pentru care functia este SEF DEP sau salariul este mai mare ca
35000 lei.
Select * from salariati where funct = SEF DEP or sala>35000 ;
16. sa se selecteze inregistrarile pentru care functia este vanzator si nu lucreaza in sbordinea
superiorului cu codul 1000.
Select * from salariati where funct = vanzator and cods!=1000 ;
17. sa se selecteze toti salariatii care lucreaza in subordinea superiorului cu codul 1000 , precum si
cei care au salariul mai mic de 30000 lei sau functia de vanzator.
Select * from salariati where funct= vanzator or sala <30000 and cods=1000 ;
18. sa se selecteze toate inregistrarile care contin date despre angajatii a caror functie este cea de sef
de deposit sau care au un salariu de 35000 lei si lucreaza in subordinea superiorului cu codul 1000.
Select * from salariati where funct= sef dep or (sala=35000 and cods=1000);
19. sa se selecteze marca si numele salariatilor care lucreaza in subordinea superiorului cu marca
1000 si care au functia de sef de deposit sau sau salariul in valoare de 35000 lei.
Select * from salariati where (funct= sef dep or sala=35000) and cods=1000 ;
20. sa se afiseze valorile coloanelor marca, nume, funct privind angajatii care lucreaza in
subordinea superiorului cu marca 1000 si au functia de sef de deposit sau vanzator.
Select * from salariati where (funct= sef dep or funct= vanzator ) and cods=1000 ;
21. sa se selecteze MARCA,NUME, FUNCT pentru salariatii care au functia de sef de deposit sau
pentru cei care lucreaza in subordinea superiorului cu marca 1000 si au functia de vanzator.
Select * from salariati where funct= sef dep or (funct= vanzator and cods=1000) ;
23. sa se selecteze toti angajatii din tabela SALARIATI care nu au functia de vanzator.
Select * from SALARIATI where not(funct=vanzator) ;
24. sa se selecteze valorile coloanelor MARCA,NUME, FUNCT,SALA+VENS pentru angajatii
care au salariul cuprins intre 24500 si 36000.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where sala between 24500 and
36000 ;
25. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care au
salariul mai mic decat 24500 si mai mare decat 36000.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where sala not between 24500
and 36000 ;
91
BAZE DE DATE
26. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care

lucreaza in depozitul cu codurile 100000 sau 160000
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where codd in
(100000,160000);
27. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii care au alta
functie decat cea de vanzator.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where funct not in (vanzator);
28. sa se selecteze campurile NUME,MARCA,FUNCT si veniturile suplimentare pentru angajatii
al caror nume incepe cu litera C
Select MARCA,NUME,FUNCT, VENS from SALARIATI where nume like C%;
29. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror
nume se termina cu litera N.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like %N;
30. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror
nume este format din noua caractere, pe ultima pozitie fiind N.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like ________N;
31. sa se selecteze angajatii al caror nume are pe pozitia a treia litera M.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like __M%;
32. 30. sa se selecteze campurile MARCA,NUME, FUNCT,SALA+VENS pentru angajatii al caror
nume este format din noua caractere.
Select MARCA,NUME,FUNCT,SALA+VENS from SALARIATI where nume like _________;
33. Sa se selecteze salariatii care nu venit suplimentar.
Select * from salariati where vens is null ;
3.4.7. Probleme propuse
1.Sa se afiseze codul produsului, data de sfirsit si a unui nou termen de valabilitate a unui pret dat,
calculat prin adaugarea a trei luni. Sa se selecteze doar produsele al caror cod este mai mic decit 13333 si
data de sfirsit este mai mare decit data curenta plus trei luni.
2.Sa se afiseze numele, marca, raportul VENS/SALA si veniturile totale pentru sefii de depozite. Ordonarea
datelor sa fie facuta crescator dupa valorile raportului mentionat.
3. Sa se afiseze media anuala a veniturilor totale (SALA+VENS) pentru salariatii cu functia 'VINZATO'.
4. Sa se selecteze codul produsului, data de sfarsit, data curenta, valorile expresiilor TRUNC(DATSF+90)TRUNC(SYSDATE) si DATASF+90. Selectia sa se realizeze pentru produsele cu codul mai mare ca13333
si data de sfirsit plus 90 de zile mai mare decit data curenta.
5. Sa se selecteze salariatii al caror nume are o lungime de noua caractere.
6. La selecteze coloanele CODP, DATASF la produsele cu codul mai mare ca 13333, afisand primele trei
litere de la zi, luna in litere si anul cu patru cifre.
7. Sa se selecteze marca si numele salariatilor care lucreaza in subordinea superiorului cu marca 1000 si au
functia sef de depozit sau salariul in valoare de 3500000 de lei.
8. Din tabela COMENZI (definita prin etichetele T1 si T2) sa se selecteze CODP, CODC, in conditiile in
care valoarea comenzii este mai mare ca 500000 lei. (JOIN -ul unei tabele pe ea insasi).
9. Sa se selecteze coloanele NUME, MARCA, VENS, SALA+VENS din tabela SALARIATI, in conditiile in
care codul superiorului este 1000.
10. Sa se afiseze cimpurile CODP, DENP, STOC si CANT, utilizand criteriul egalitatii OUTERJOIN, pe campul comun CODP (se afiseaza datele despre datele despre acele produse pentru care
exista comenzi dar nu sunt in nomenclatorul de produse). Liniile sa fie ordonate crescator dupa
campul CODP.
11.Sa se afiseze numele si marca acelor angajati al caror nume se pronunta asemanator cu DORU DAN.
12. Sa se selecteze campurile NUME si FUNCT ale salariatilor cu functia identica cu a lui RADU IOANA.
13. Sa se selecteze codul produsului, data maxima admisa de practicare a unui pret si data curenta pentru
acele produse care indeplinesc conditia ca DATASF+10 sa fie mai mare decit SYSDATE,
14. Sa se selecteze cimpurile MARCA, NUME, SALA, VENS pentru salariatii care au alta functie decat cea
de vanzator.
92
BAZE DE DATE
15. Sa se selecteze crescator dupa salariu, angajatii cu functia vinzator, si pentru care marca superiorului
este 1000.
16. Sa se selecteze si afiseze valoarea medie zilnica a comenzilor ce trebuie onorate in perioada 01-03 Iulie
2005.
17. Sa se afiseze primele 5 carcatere din nume, marca si primul carcater din functie, pentru toti angajatii.
18. Sa se afiseze o situatie finala prin care sa fie redate cimpurile NUME si MARCA angajatului reunite
intr-un camp comun, denumit "INFORMATIE" si cimpul venituri totale anuale denumit VENIT_ANUAL.
Selectia este ceruta pentru angajatii cu codul superiorului egal cu 1000.
19. Sa se selecteze campurile NUME si CODD ale angajatilor cu codul superiorului 1000 si care au
aceeasi functie cu DORU DAN. Sa se afiseze numai salariatii pentru care exista corespondenta de
CODD in tabelele DEPOZITE si SALARIATI. Datele sa fie ordonate crescator dupa valorile CODD si
NUME.
20.Sa se selecteze cimpurile CODP, DENP, PRET, PRETMAX, PRETMIN pentru produsele al caror pret
negociat este cuprins intre pretul maxim si pretul minim. Ordonarea sa se faca crescator dupa campul CODP.
21. Din tabela COMENZI (definita prin etichetele T1 si T2) sa se selecteze CODP, CODC, in conditiile in
care valoarea comenzii este mai mare ca 500000 lei. (JOIN -ul unei tabele pe ea insasi).
22. Sa se afiseze toate coloanele pentru salariatii cu functia vanzator, care au salariul mai mare ca 3500000
lei si lucreaza in subordinea superiorului cu codul 1000.
23. Sa se selecteze coloanele CODP, DATASF la produsele cu codul mai mare ca 13333, afisind ziua si luna
in litere iar anul cu patru cifre.
24. Sa se selecteze coloanele MARCA, NUME, CODD, VENS ordonate crescator dupa codul depozitului si
veniturile suplimentare.
25. Sa se selecteze toate coloanele din tabela SALARIATI.
26.Sa se afiseze valoarea totala a salariilor si veniturilor suplimentare pentru salariatii cu functia 'VINZATO'.
27. Sa se selecteze salariatii al caror nume are o lungime de noua caractere.
28. se selecteze coloanele MARCA, NUME, CODD din tabela SALARIATI, daca venitul suplimentar este
mai mare decat salariul.
29. Sa se selecteze din tabela PRETURI valorile cimpului CODP si DATASF. Data de sfirsit (DATASF) sa
se prezinte insotita de timpul intern, exprimat in diverse forme de afisare.
30. Sa se afiseze numarul de valori nenule inregistrate in coloana VENS din tabela SALARIATI.
Referinte bibliogafice
1. Moraru, S., Perniu, L. Web-applications on databases in electrical domain, Ed. Lux Libris,
2004.
2. Connolly, T., Begg, C., Strachan, A. Baze de date, Ed. Teora, 2000.
3. Connolly, T., Begg, C., Strachan, A. Database Systems A Practical Approach to Design,
Implementation and Management, Addison Wesley Longman Limited 1995, 1998
4. Florescu, V. and co. Databases. Practical and Teoretical Approach, Infomega, 2001
5. Velicanu, M., Lungu, I., Bodea C., Ioni, C., Bdescu G. Database Management Systems,
Editura Petrion, 2000
6. Popescu, I. Database Design, Editura Tehnic, 2001
7. Sabu G., Avram V. Computer Systems and Databases, Editura Oscar Print
8. Henderson, K. The Gurus Guide to Transact-SQL, Addison Wesley, 2000
9. Waymire, R., Sawtell, R. Sams Teach Zourself Microsoft SQL Server 2000 in 21 Days, Sams
Publishing, 2001
10. Henderson, K. The Gurus Guide to SQL Server Stored Procedures, XML, and HTML
Addison Weslwey, 2002
11. Reingruber, M. C., Gregory W. The Data Modeling Handbook, John Wiley & Sons, 1994.
12. Martin J. An end users guide to Data Base, Prentice Hall, 1981
13. Carter J. The relational database, Chapman & Hall, 1995
14. Fleming, von Halle, The Handbook of RelationalDatabase Design, Addison-Wesley.
15. Chen, P. P. The entity-relationship model: toward a unified view of data, ACM Trans. on
Database Systems, 1976.
16. Batini, C., S. Ceri, S. B. Navathe, C. Batini Conceptual Database Design: an
Entity/Relationship Approach, Addison-Wesley, Reading MA, 1991.
93
BAZE DE DATE
17. R. Jennings, P. Hipson Database Developer's Guide with Visual C++ 4, Second Edition,
Sams Publishing, 1996
18. Date, C.J. An Introduction to Database Systems (5th ed.). CA: AddisonWesley, 1991.
19. Date, C.J. An Introduction to Database Systems (7th ed.). CA: AddisonWesley, 2000.
20. Elmasri, R., Navathe, S.B. Fundamentals of Database Systems (3rd ed.).
CA: Addison-Wesley, 2000.
21. Johnson, J.L. Database: Model, Languages, Design. NY: Oxford University
Press, 1997.
22. Robson, W. Strategic Management & Information Systems (2nd ed).
Pitman, 1997.
23. Avery, B. The Relational Model, Kingston University, [PDF document] URL
http://www.kingston.ac.uk/~ku12492/MBIT/model.pdf.
24. Brown, C.E. The Relational Model, Database learning module,
http://www2.bus.orst.edu/faculty/brownc/lectures/db_tutor/relational_model.
htm#3.1%20Rela-tional%20Data%20Model%20Concepts.
25. Bull, M. Codds Rules for RDBMS, MB-online publication. West Yorkshire,
2002, URL http://hometown.aol.com/mbaddenda/art120.html.
26. Parkhurst, T. Codds 12 rules. DATA MANAGEMENT STRATEGIES,
http://www.itworld.com/nl/db_mgr/09022002/pf_index.html, 2002, Feb. 9.
27. Rennhackkamp, M. Relational Integrity Control, DBMS online Server side.
http://www.dbmsmag.com/9606d17.html, 1996 June.
28. Webopedia, Referential Integrity,
http://www.webopedia.com/TERM/r/referential_integrity.html.
29. Codd, E. "Is Your DBMS Really Relational?" and "Does Your DBMS Run By the Rules?"
ComputerWorld, October 14 and October 21, 1985.
30. Hernandez J. M. Database Design for Mere Mortals, Addison Wesley, 1996
31. Davies, C.T., Recovery Semantics for a DB/DC System, In Proc. ACM Annual Conference,
1973.
32. Eswaran, K.P., Gray, J.N., Lorie, R.A., Traiger, I.L. The Notions of Consistency and
Predicate Locks in a Database System, CACM 19,11, 1976
33. Scheuerl, S, J.G. Modelling Recovery in Database Systems, School of Mathematical and
Computational Sciences University of St Andrews, 1997
34. Yovits, M. C. Advances in Computers, Vol. 38. (Ed.), Academic Press, 1994.
35. Hernandez, M. J. Database design for mere mortals : a hands-on guide to relational database
design, 2nd ed., Addison Wesley, 2003.
94

Baza de Date Cig

Încărcat de

Informații document

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

Baza de Date Cig

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEFAN CEL MARE SUCEAVA

FACULTATEA DE TIINE ECONOMICE I ADMINISTRAIE PUBLIC

PROF.UNIV.DR. VALERIU LUPU

CURS PENTRU NVMNT LA DISTAN

SUCEAVA 2010 2011

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server, distribuite

CURS PENTRU NVMNT LA DISTAN

Oferirea unei imagini sintetice i cuprinztoare a bazelor de date.

2. MODELE I ARHITECTURI DE DATE

Prezentarea n detaliu a modelelor de date: reea, ierarhic, relaional, obiect, hibrid.

CURS PENTRU NVMNT LA DISTAN

3. MODELUL RELAIONAL DE DATE

nsuirea noiunilor de baz ale unui model de date: definiii, clasificri.

4. LIMBAJUL MYSQL AL BAZELOR DE DATE

CREATE VIEW v AS <expresie interogare>

CURS PENTRU NVMNT LA DISTAN

Modelul Entitate-Relatie. Reprezentari.

CURS PENTRU NVMNT LA DISTAN

1.1. Evoluia organizrii datelor

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

se menine dependena aplicaiilor fa de date, accesul la date fiind foarte dificil;

CURS PENTRU NVMNT LA DISTAN

- existena unor fiiere inverse ce permit rspunsul rapid la ntrebri formulate de

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

1.1.2. Limitele tratrii bazate pe fiiere

Separarea i izolarea datelor

CURS PENTRU NVMNT LA DISTAN

Figura 1.1. Fiiere: dependena aplicaie/date

Figura 1.2. Baze de date: independena aplicaie/date

Formate de fiiere incompatibile

Interogarea static a programelor aplicaie

CURS PENTRU NVMNT LA DISTAN

1.1.3. Avantajele sistemelor de gestiune a bazelor de date

CURS PENTRU NVMNT LA DISTAN

11. Creterea productivitii

1.1.4. Dezavantajele sistemelor de gestiune a bazelor de date

1.2. INDEPENDENA DATELOR. LIMBAJELE DE DEFINIRE I MANIPULARE A

CURS PENTRU NVMNT LA DISTAN

CURS PENTRU NVMNT LA DISTAN

1.2.1. Independena de date

CURS PENTRU NVMNT LA DISTAN

1.2.2. Limbajele bazelor de date

1.2.2.1. Limbajul de definire a datelor

CURS PENTRU NVMNT LA DISTAN

1.2.2.1.1. Definirea schemei n SQL

ceea ce nu este acelai lucru cu:

care pstreaz relaia, dar elimin toate tuplurile din ea.

CURS PENTRU NVMNT LA DISTAN

ALTER TABLE r DROP A

n care A reprezint atributul care trebuie eliminat din baza de date.

1.2.2.1.2. Utilizarea interogrilor SQL n cadrul aplicaiilor

1.2.2.2. Limbajul de manipulare a datelor

CURS PENTRU NVMNT LA DISTAN

1.2.2.2.1. Extragerea informaiilor din bazele de date

CURS PENTRU NVMNT LA DISTAN

Ordonarea afirii nregistrrilor

CURS PENTRU NVMNT LA DISTAN

Relaii obinute prin cuplare

Comparaii ntre seturi de nregistrri

Testarea relaiilor ce nu conin nregistrri