SISTEME DE GESTIUNE A BAZELOR DE DATE

1: SISTEME DE GESTIUNE A BAZELOR DE DATE RELAIONALE

1.1. Definiii, terminologie

Apariia i dezvoltarea calculatoarelor electronice au condus la amplificarea
activitilor legate de stocarea, interogarea i administrarea coleciilor de date. Astzi,
cele mai multe dintre activitile noastre zilnice necesit accesarea i actualizarea
informaiei dintr-o baz de date: extragerea unei sume de bani din contul bancar,
rezervarea unei camere de hotel, cumprarea unui bilet de avion, mprumutarea unei
cri de la bibliotec, pltirea facturilor de telefon, curent electric etc. Toate acestea se
pot face rapid i n siguran pentru c datele respective sunt bine organizate ntr-o
baz de date i administrate de un sistem de gestiune a bazelor de date.
Baz de date (BD) = o colecie de date aflate n relaie unele cu altele i
structurat astfel nct s poat servi unui anumit scop
= un set de date corelate i organizate n scopul prelucrrii lor rapide i concomitente
de ctre mai multe persoane.
Exemple
1) baza de date a unui muzeu, n care sunt nregistrate operele de art (grupate dup
tip, autor, tehnic de lucru) i expoziiile itinerante (descrise prin perioad, itinerariu,
responsabil, custozi participani);
2) baza de date a unui magazin de muzic, n care sunt nregistrate albumele de
muzic n funcie tipul de suport fizic (CD, caset etc.), stil, autori, soliti, anul apariiei
etc.
Observaie
Termenul "Database" (baz de date, n limba englez) a aprut pentru prima dat n
titlul unei conferine organizate la Santa Monica, SUA, n 1964: Development and
Management of Computer Centered DataBase.
Sistem de gestiune a bazei de date
Baza de date

Utilizatori

Programe i aplicatii

Figura 1: Structura simplificat a unei baze de date

Sistem de gestiune a bazelor de date (SGBD) = un ansamblu de programe care
permit crearea i administrarea unei baze de date. Prin urmare, un SGBD (Database
1

Management System) este un pachet software de nivel nalt care permite proiectarea,
construirea i administrarea bazelor de date dedicate rezolvrii problemelor din cele
mai variate domenii ale vieii reale.
Exemple
IMS, DB2 (pn la DB9, de la IBM), Ingres II (de la Computer Associates International
Inc.), Oracle 8i (de la Oracle Corporation), Ms Access (studiat n clasa a X-a), FoxPro
(de la Microsoft), Paradox, Visual dBase (de la Borland), Sybase Adapted Server
(de la Sybase Inc.), IRIS (de la Hewlett-Packard).
Atenie
Nu orice colecie de date este o baz de date. De exemplu, lista crilor dintr-o
bibliotec NU este o baz de date ci un simplu inventar de obiecte, o list, un tabel.
Prin urmare, fa de un inventar (un tabel), o baz de date are urmtoarele proprieti:

reprezint un anumit aspect al lumii reale, numit microuniversul bazei de date;

orice modificare care se produce in acest microunivers se reflect n baza de date (de
exemplu: cumprarea unei noi casete n vederea inchirierii, modificarea diferenei
permise ntre cursul de cumprare i cel de vnzare al valutei etc.);

este o colecie de date coerent din punct de vedere logic i avnd un neles
intrinsec (de exemplu: din baza de date asociat bibliotecii liceului nu vor face parte
crile de telefon sau lista de materiale didactice din laboratorul de chimie);

este proiectat, construit i populat cu date avnd permanent n vedere un

anumit scop; o baz de date este destinat utilizrii de ctre un anumit grup de
persoane i permite efectuarea unui anumit set de operaii.
Un SGBD foloseste in principiu trei limbaje: un limbaj de descriere al datelor fizice,
un limbaj de descriere al datelor logice si un limbaj de prelucrare al datelor. Aceste
limbaje pot fi de sine statatoare sau grefate pe un limbaj de programare general (de
exemplu, C, COBOL, PL/I etc.).
Arhitectura bazelor de date evidentiaza componentele acestora:

baza de date propriu-zisa in care se memoreaza datele;

sistemul de gestiune a bazei de date, care realizeaza gestiunea si

prelucrarea complexa a datelor;

un dictionar al bazei de date (metabaza de date ),ce contine informatii

despre date, despre structura acestora, statistici, documentatie;

mijloace hard utilizate (comune sau specializate);

reguli administrative destinate bunei functionari a intregului sistem.

personalul implicat (utilizatori finali, administrator, programatori, operatori).

Dintre cerintele care se impun unei baze de date remarcam :

sa furnizeze in timp util informatiile solicitate (timp de raspuns la o interogare );

sa asigure costuri minime deprelucrare si intretinere, redundanta minima;

sa aiba capacitatea de a satisface cu aceleasi date, necesitatiile informationale,

ale unui numar mare de utilizatori, sa permita adaptarea la cerinte noi, raspunsuri la
interogari neprevazute initial (flexibilitate );

sa permita exploatarea simultana a datelor de catre mai multi utilizatori

(sincronizare);

sa asigure securitatea datelor prin mecanisme de protectie impotriva accesului

neautorizat (confidentialitate);

sa contina facilitati destinate validari datelor si recuperarii lor in cazul unor

deteriorari accidentale (integritate);

sa permita valorificarea eforturilor anterioare si anticiparea nevoilor viitoare

(compatibilitate si expandabilitate);

sa permita, prin ierarhizarea datelor dupa criteriul frecventei acceselor,

reorganizari (eventual dinamice) care sporesc performantele bazei.

Cuvntul dat este de origine latin i provine de la verbul a da. n limba englez,
substantivul dat (date, la plural) se traduce prin datum (data, la plural). Exemple de
date sunt: cantitile de mere obinute anual ntr-o livad de pomi fructiferi, activitile
turistice propuse de ghid participanilor la o excursie; modificrile climatice suferite de o
regiune a globului terestru de-a lungul unui numr de ani, cursul bancar al unei valute
de-a lungul unei luni sau a unui an calendaristic etc.
Exist o diferen esenial ntre date, informaii i cunotine:
1. datele sunt informaii primare care au fost doar culese i inregistrate;
2. informaiile sunt date prelucrate, structurate (validate, corectate, organizate,
sortate, relaionate);
3. cunotinele sunt informaii contextualizate.
Arhitectura sistemelor de gestiune a bazelor de date este puternic determinat de
modelul de date al bazelor de date. Dincolo de definiiile date pn acum, ce este de
fapt o baz de date? Este un obiect (asemenea numerelor, funciilor, mulimilor)? Este
o metod (asemenea algoritmilor, procedurilor)?
O baz de date este n primul rnd un model al microuniversului la care se
refer.
Model = (n sens strict) un sistem teoretic sau material cu ajutorul cruia pot fi studiate
indirect proprietile i transformrile unui alt sistem, mai complex, cu care primul
sistem prezint o analogie;
= (n sens larg) ceea ce poate servi ca orientare pentru reproduceri (un tipar). (cf. DEX)
O baz de date ofer un anumit grad de abstractizare a datelor (asemenea celor mai
multe limbaje de programare), ascunznd detaliile de implementare, detalii care nu
sunt necesare celor mai muli dintre utilizatori. Cu alte cuvinte, programele specifice
unei baze de date nu depind de modul de stocare i accesare a datelor la nivel fizic.
Acest concept se numete independen a datelor, se realizeaz cu ajutorul unui
model de date (Data Model1) i este principalul mecanism care asigur partajarea
datelor din baza de date ntre diferitele aplicaii care le acceseaz.
Model de date = un ansamblu format din:
1) o colecie de concepte necesare pentru descrierea structurii bazei de date (a
tipurilor de date incluse n baza de date, a relaiilor dintre ele i a restriciilor
(Constraints) pe care trebuie s le respecte);
2) un set de operaii de baz (care s specifice modul de efectuare a extragerii i
actualizrii datelor din baza de date).

1.2. Modele de date: perspectiv istoric

Evoluia modelelor de date pentru bazele de date i SGBD-uri a fost sugestiv
sintetizat de R.G.G. Canttell n articolul su "What Are Next-Generation DB
Systems?", publicat n revista Communications of the ACM, n octombrie 1991: "Istoria
informaticii a cunoscut multe generaii de sisteme de gestiune a datelor, ncepnd cu
sistemele de fiiere indexate, continund apoi cu sistemele de tip ierarhic i de tip
reea, iar mai nou cu sistemele relaionale. Acum suntem pe punctul de a intra ntro nou generaie de sisteme de gestiune a bazelor de date care ofer administrare de
obiecte, i care accept tipuri de date mult mai complexe".
Cu toate c a generat o activitate de cercetare foarte susinut dar i o activitate
practic, industrial extrem de productiv, domeniul bazelor de date este unul dintre
cele mai tinere domenii ale informaticii. Este general acceptat faptul c "rdcinile" sale
trebuie cutate aproximativ acum 40 de ani2 n obiectivul fixat de Preedintele J.F.
Kennedy pentru programul Apollo: aducerea primului om pe Lun pn la sfritul
anilor '60. In acel moment nu exista nici un instrument informatic care s funcioneze
efectiv i care s poat administra uriaele volume de date implicate n programul
1

E.F. Codd este considerat a fi "printele" conceptului de model de date, n general, i al

conceptului de model de date relaional, n particular.
2
Data apariiei primului sistem comercial de gestiune a bazelor de date
3

spaial. Ca urmare, North American Aviation (NAA) primul contractor al proiectului, a

dezvoltat un software bazat pe o structur ierarhic (prile se agreg n componente
din ce n ce mai ample) denumit GUAM (Generalized Update Access Method). Spre
mijlocul anilor '60, IBM s-a alturat NAA dezvoltnd n continuare GUAM i producnd
unul dintre primele sisteme comerciale de gestiune a bazelor de date: IMS
(Information Management System). IBM a preluat modelul ierarhic pentru a respecta
cerina de stocare a datelor pe benzi magnetice (deci n acces secvenial). Ulterior,
aceast restricie a fost nlturat i IMS continu s fie principalul SGBD ieirarhic
utilizat de majoritatea calculatoarelor mainframe3.
Construirea bazelor de date a cunoscut o evoluie foarte rapid, trecnd prin mai
multe abordri, clasificate dup cum urmeaz:
sistemele de fiiere;
sistemele prerelaionale (sau "istorice"4): ierarhic i reea,
sistemul relaional;
sistemele postrelaionale: orientat obiect i hibrid (obiect-relaional);
sistemele semantice: multi-dimensional i logic (deductiv).
1.2.1. Modelele prerelaionale
Pot fi caracterizate ca modele de moment: au oferit soluii pentru problemele
vremii lor dar nu au avut un fundament teoretic puternic i riguros.
(I.) Sistemul de gestiune bazat pe fiiere, considerat de fapt un predecesor al
sistemelor de gestiune a bazelor de date, este o colecie de programe care realizeaz
fiecare cte "un serviciu" pentru utilizatorii datelor (de obicei: generarea de
rapoarte). Fiecare program i definea i i administra propriile date. Chiar dac a avut
numeroase dezavanataje (abordarea descentralizat n stocarea informaiilor, gradul
mare de redundan i dependen program-date), sistemul de gestiune bazat pe
fiiere a constituit un salt semnificativ fa de fiierele administrate manual: saltul de la
abordarea informaional la cea informatic.

(a)

(b)

Figura 1: Modele de baze de date: (a) ierarhic; (b) reea

(II.) Att n modelul ierarhic ct i n modelul reea, datele erau reprezentate ca
mulimi de inregistrri (n sensul limbajului de programare Pascal: colecii de date de
diferite tipuri: Integer, Boolean, Real etc.). Relaiile dintre ele erau reprezentate prin
3

Un calculator mainframe este un calculator cu capacitate de memorie i vitez de lucru foarte

mari, utilizat de marile corporaii pentru a stoca volume foarte mari de date i pentru a coordona
sute sau mii de terminale (inclusiv calculatoare personale) conectate la el. Operarea unui
mainframe necesit de obicei un personal specializat.
4
numite i navigante sau tradiionale (legacy systems)
4

legaturi de tip pointer (adrese de locaii fizice de memorie). Inregistrrile care formau
baza de date erau organizate:
n modelul ierarhic: ca o mulime de arbori;
n modelul reea: ca o mulime de grafuri.
Ambele modele prerelaionale permiteau accesul la date de-a lungul unor drumuri
(ci) predefinite, explicit stabilite la nivelul programelor de aplicaii (de unde i numele
de modele navigante). Ca urmare, orice modificare a structurii bazei de date antrena
modificarea acestor ci n programele deja scrise. Exemple: pentru modelul ierarhic:
IMS (amintit mai sus); pentru modelul reea: IDS II (de la Honeywell), IMAGE (de la
Hewlett Packard).
Aplicaie: Modelarea activitii didactice
Intr-o facultate, cadrele didactice desfoar activiti didactice de curs sau examen;
aceste activiti sunt pentru studeni i se desfoar n locaii (amfiteatre sau
laboratoare). De asemenea, cadrele didactice particip la proiecte de cercetare
tiinific. Figura 2 prezint modelul ierarhic al bazei de date; Figura 3 prezint modelul
reea.
Facultate

Student

Activitate didactic

Curs

Locaie

Cadru didactic

Examen

Proiect

Figura 2: Modelul ierarhic

Desfurare
Curs

Examen
Locaie

Inscriere
Activitate didactic

Facultate
Student
Predare

Proiect

Cadru didactic

Figura 3: Modelul reea

5

1.2.2. Modelul relaional

Considerat drept cel mai important eveniment din istoria bazelor de date,
apariia modelului relaional s-a produs n iunie 1970, odat cu publicarea n revista
Communications of the ACM a articolului fundamental al lui Edgar Frank Codd5 (de la
IBM Research Laboratory): "A Relational Model of Data for Large Shared Databanks".
n acest articol, autorul aplica o serie de concepte din algebra relaional pentru a
rezolva problemele legate de stocarea volumelor mari de date i enuna "celebrele" 12
reguli (condiii) pe care trebuie s le ndeplineasc un SGBD pentru a fi declarat
relaional.
S amintim ns existena unui precursor: modelul bazat pe teoria mulimilor,
propus de D.L. Childs n articolul su: "Feasability of a Set-Theoretical Data Structure",
aprut n 1968 n Proc. Fall Joint Computer Conference.
Cele mai importante prototipuri de sisteme de gestiune a bazelor de date de tip
relaional au fost:
System R, dezvoltat la San Jose Research Laboratory din California spre sfritul
anilor '70. Acest model a condus la:
o apariia unui limbaj structurat de interogare a bazelor de date: SQL,
o producerea mai multor SGBD-uri relaionale comerciale: DB2 i SQL/DS de la
IBM i, respectiv, ORACLE de la Oracle Corporation (n deceniul 9 al secolului
trecut);
INGRES (Interactive Graphics Retrival System), dezvoltat la Universitatea
Berkeley din California;
Peterlee Relational Test Vehicle, dezvoltat la IBM UK Centre din Peterlee, Marea
Britanie.
Numrul sistemelor relaionale comerciale a ajuns acum la cteva sute, dintre
care cele mai cunoscute sunt: DB2 (de la IBM), Ingres II (de la Computer Associates
International Inc.), Oracle 8i (de la Oracle Corporation), Ms Access, FoxPro (de la
Microsoft), Paradox, Visual dBase (de la Borland), Sybase Adapted Server (de la
Sybase Inc.). Succesul acestui model continu s fie att de mare nct multe sisteme
nerelaionale ofer acum i o interfa cu utilizatorii de tip relaional, indiferent de
modelul de date pe care se bazeaz de fapt.
Modelul relaional s-a dovedit a fi i un instrument didactic ideal de prezentare a
principiilor bazelor de date, tocmai datorit fundamentrii sale riguroase pe principii
logice i matematice.
Ce este de fapt un model relaional de date? Informal, l putem defini ca un model
n care:
datele sunt percepute de utilizatori ca nite tabele i numai ca nite tabele;
operaiile disponibile pentru utilizatori (spre exemplu, pentru obinerea informaiilor)
sunt operaii care genereaz noi tabele pe baza tabelelor vechi: operaia de selecie
(SELECT) extrage o submulime de rnduri dintr-o tabel, operaia de proiecie
(PROJECT) extrage o submulime de coloane, operaia de juxtapunere (JOIN)
asociaz dou tabele pe baza valorilor identice pe care le conin n anumite coloane,
de asemenea identice; ori, toate aceste submulimi rezultate pot fi privite i ele nsele
ca nite tabele.

E.F. Codd s-a nscut la 23 august 1923 n Portland, Marea Britanie, i a murit n 18 aprilie
2003, n Florida. A fcut studii de matematic i chimie la Oxford i s-a mutat n Statele Unite n
1948, pentru a lucra la IBM. A introdus termenul OLAP (OnLine Analytical Processing) i a
impus modelul relaional; a avut, de asemenea, contribuii n domeniul modelelor de
calculabilitate prin lucrrile sale privind automatele celulare. A obinut de dou ori Premiul
Turing: n 1981 i 1994.
6

(a)
(b)
(c)
Figura 4: Operaii cu tabele: (a) selecie; (b) proiecie, (c) asociere
Numele modelului (model relaional) provine de la conceptul matematic de
relaie. Aa cum o funcie f : {1, 2,,n} N R are mai multe reprezentri
convenionale, dintre care cea mai comod este cea de vector, tot astfel relaia poate
avea mai multe reprezentri, una dintre ele fiind tabela. Din acest motiv, cel puin la
nivel informal, termenii de relaie i tabel pot fi considerai sinonimi.
Principalele concepte cu care lucreaz modelul de date de tip relaional sunt
(exemplificarea se face pentru baza de date asociat unui liceu):

entitatea (Profesori, Elevi, PersonalAuxiliar, Clase etc.),

relaia dintre entiti (PredLa, AreDirigintePe, AreLocIn etc.),

atributul (Nume, GradDidactic, DataNaterii, NrLocuri, Locaie etc.).

1.2.3. Modelele postrelaionale
Chiar dac se regsete n descrierea unor situaii reale, cu o organizare
intrinsec piramidal, modelul ierarhic i-a atins rapid limitele. La fel, modelul relaional a
devenit impropriu pentru rezolvarea unor probleme din realitatea nconjurtoare care
presupun manipularea unor volume uriae de informaie, a unei mari varieti de tipuri
de date: hri meteorologice sau geografice necesare previziunilor meteorologice sau
dirijrii traficului, imagini transmise prin satelit utilizate n msurarea factorilor poluani,
date neconvenionale pentru proiectarea asistat de calculator n inginerie sau
arhitectur, serii dinamice implicate n tranzaciile bursiere sau bancare, stocarea
obiectelor binare mari (BLOBs = Binary Large Objects) necesare n digitalizarea
informaiei coninut n fiierele audio sau video. Au aprut astfel i s-au dezvoltat
modelele postrelaionale, de generaia a treia: modelul orientat obiect i modelul
obiect-relaional.
(I.) Modelul orientat obiect permite inglobarea semanticii obiectelor celor mai variate,
la fel ca n limbajele de programare orientate-obiect. De altfel, una dintre deosebirile
majore fa de modelul relaional const n distanarea de conceptul de independen
fa de limbajele de programare i dezvoltarea conceptului de integrare a limbajelor de
programare n sistemul de gestiune a bazei de date (invocarea unor funcii C++ mai
degrab dect inglobarea unui limbaj special pentru interogarea datelor, ca de exemplu
SQL). Acest fapt a fost determinat de:
utilizarea aproape exclusiv a limbajelor de programare orientate obiect pentru
dezvoltarea aplicaiilor software;
includerea n aproape orice aplicaie software a unei baze de date ca element
fundamental al acesteia.
Cele mai cunoscute prototipuri de baze de date orintate obiect sunt:
OPENOODB (de la Texas Instruments), IRIS (de la Hewlett Packard), iar ca variant
comercial: GEMSTONE/OPAL (de la GemStone Systems), VERSANT (de la Versant
Object Technology). Dei cu o cot de pia semnificativ inferioar sistemului relaional
(150 milioane dolari fa de 10 miliarde, numai n SUA n anul 1999), modelul orientat
obiect este creditat cu o cretere anual extrem de rapid: 50%.
n ciuda caracterului intuitiv i a altor avantaje evidente ale modelului orientat
obiect, modelul relaional continu s domine piaa sistemelor de gestiune a bazelor de
date. Motivele sunt numeroase: fundamentarea matematic riguroas, simplitatea,
volumul mare de date deja stocate dup acest model i costul enorm al migrrii spre un
model complet diferit.

(II) Modelul hibrid extinde modelul relaional oferind un set de tipuri de date mai
bogat, i include i orientarea obiect. Se incearc astfel combinarea avantajelor celor
dou abordri: cea relaional i cea orientat obiect. Astfel, atributele i instanele
entitilor pot avea tipuri complexe i pot evita unele dintre restriciile specifice
modelului relaional. De exemplu, n timp ce n modelul relaional fiecare atribut trebuie
s ia pentru fiecare instan a unei entiti o valoare i numai una din domeniul lui de
definiie, n modelul hibrid poate lua un subset de valori (de exemplu: pentru un angajat
oarecare, atributul Telefon poate lua ca valori numrul telefonului fix de acas i de la
servicu, al telefonului mobil propriu i de serviciu, dac angajatul dispune de toate
patru).
Cel mai cunoscut exemplu: Informix Universal Server care combin tehnologiile
relaionale i orientate obiect din dou produse preexistente: Informix i Illustra.
Principalele avantaje i dezavantaje ale modelelor de date (i ale sistemelor de
gestiune a bazelor de date corespunztoare) au fost sintetizate de M. Stonebraker prin
diagrama din Figura 7 (vezi [18]): modelul relaional permite realizarea chiar
simultan a unor interogri variate i rapide dar complexitatea datelor stocate nu
difer prea mult de complexitatea datelor memorate n baze de date de tip ierarhic sau
reea; cu modelul orientat obiect se poate stoca informaie variat i complex (de la
texte la sunete i imagini) dar viteza de interogare (n cazul imaginilor i mai ales al
sunetelor) este foarte sczut; modelul care pare s elimine toate dezavantajele i s
cumuleze toate avantajele modelelor anterioare este modelul obiect-relaional.

Faciliti de
interogare /
asistena multi-user

SGBD relaionale
SGBD prerelaionale

SGBD hibride
SGBD orientate obiect

Complexitatea datelor /
posibile extinderi

Figura 7: Clasificarea Michael Stonebraker pentru

sistemele de gestiune a bazelor de date

1.3. Arhitectura SGBD

Datele din baza de date pot fi descrise pe trei nivele: extern, conceptual i intern:
Nivelul extern:
imaginea fiecrui
utilizator asupra BD

Schema
extern 1

Schema
extern 2

Nivelul conceptual
(structura logic a BD):
ansamblul datelor stocate
n BD i a relaiilor dintre
ele (fr detalii de
implementare)

Schema
extern 3

Schema
conceptual

Nivelul intern:
implementarea fizic a BD
(structuri de date,
indexare, acces)

Schema
intern

Organizarea fizic a datelor,

coordonat de SGBD i
sistemul de operare

Baza
de date

Figura 5: Arhitectura ANSI6-SPARC7 pe 3 nivele pentru bazele de date

Nivelul extern reprezint modul n care utilizatorul percepe datele. Intruct anumite
pri din baza de date sunt relevante pentru unii utilizatori dar irelevante pentru alii
putem spune c o baz de date are attea nivele externe ci utilizatori o acceseaz.
Mai mult, exist entiti care dei snt reprezentate n baza de date nu apar la acest
nivel deoarece snt irelevante pentru anumii utilizatori.
Nivelul intern (nivelul fizic) reprezint modul n care SGDB-ul i sistemul de operare
percep datele. La acest nivel:
este descris reprezentarea fizic a bazei de date n calculator (sunt
specificate: spaiul de stocare a datelor, modul de stocare a acestora, structurile
de date, organizarea fiierelor etc.);
sunt utilizate funcii ale sistemului de operare pentru plasarea datelor pe
dispozitivele de stocare, pentru construirea indecilor, pentru citirea datelor etc.;
Nivelul conceptual (nivelul logic) realizeaz trecerea de la nivelul intern la nivelul
extern i asigur independena acestora. Acest nivel:
grupeaz percepiile tuturor utilizatorilor bazei de date (deoarece conine fiecare
viziune (view) din nivelul extern, direct sau indirect);
conine structura logic a bazei de date descris prin conceptele de entitate,
atribut i relaie, constrngeri referitoare la date, informaii de securitate i
integritate;

6
7

ANSI = American National Standards Institute

SPARC = Standards Planning and Requirements Committee
9

descrie datele stocate n baza de date i relaiile dintre ele dar nu conine detalii
referitoare modul de stocare a datelor pe suportul fizic (numrului de octei
ocupai pe disc etc.).
Scopul arhitecturii pe cele trei nivele este acela de separare a percepiei fiecrui
utilizator individual aspura datelor de modul de reprezentare fizic a acestora n baza
de date. Figura 2 ilustreaz acest lucru reprezentnd nivelul intern, nivelul conceptual
i dou vederi corespunztoare la nivelul extern: una aparinnd unui utilizator de PL/I,
cealalt aparinnd unui utilizator de COBOL.
Nivel extern (PL/I)

Nivel
(COBOL)

DCL 1 ANG,
2 ANG# CHAR(6),
2 SAL
FIXED BIN(31);
Nivel conceptual

extern

01 ANGAJ.
02 CODANGAJ
02 CODDEPT

PIC X(6).
PIC X(6).

ANGAJAT
COD_ANGAJAT
CHARACTER (6)
COD_DEPARTAMENT CHARACTER (4)
SALARIU
NUMERIC (5)
Nivel intern
STORED__ANG
PREFIX
ANG#
DEPT#
SALAR

BYTES=20
TYPE=BYTE(6), OFFSET=0
TYPE=BYTE(6), OFFSET=6, INDEX=ANGX
TYPE=BYTE(4), OFFSET=12
TYPE=FULLWORD, OFFSET=16

Figura 6: Exemplu de arhitectur pe 3 niveluri

Observaie
n timp ce nivelele extern i conceptual trebuie s urmeze acelai model (relaional,
orientat-obiect etc.), nivelul intern nu are nimic de a face cu modelul de date al bazei el constnd din nregistrri memorate, pointeri, indeci etc.
Intr-o baza de date sunt necesare trei nivele de independenta a datelor:
independenta fizica: asigura posibilitatea modificarii schemei fizice a datelor
fara ca aceasta sa oblige la modificarea schemei conceptuale, schemei logice si
a programelor de aplicatie.
independenta logica: asigura posibilitatea modificarii schemei conceptuale a
datelor fara ca aceasta sa oblige la modificarea schemei logice si a
programelor de aplicatie.
independenta fata de strategiile de acces: permite programului sa precizeze
data pe care doreste sa o acceseze, dar nu modul cum acceseaza aceasta data.
SGBD va stabili drumul optim de acces la date.

10

Schema
extern

Proiectarea la nivel logic / conceptual

Schema
conceptual

Schema
intern
Proiectarea la nivel fizic
Stocare
fizic

Figura 7: Modelarea datelor i arhitectura ANSI-SPARC

1.4. Modelul conceptual al bazelor de date relatioanle

A. Prima etap a modelrii conceptuale
Aa cum am vzut n paragraful anterior, proiectarea unei baze de date incepe
cu analiza situaiei reale care trebuie modelat prin baza de date. Aceast analiz
necesit un dialog ntre proiectantul bazei de date i viitorii ei utilizatori. Astfel, sunt
puse n evident:
cerinele utilizatorilor privind datele care trebuie stocate i administrate;
cerinele utilizatorilor privind operaiile care trebuie efectuate cu aceste date.
Etapa urmtoare const n realizarea modelului conceptual al bazei de date. n
cazul modelului relaional, se ncepe cu o descriere detailat a entititilor i atributelor,
a relaiilor dintre entiti i a condiiilor pe care trebuie s le ndeplineasc. Aceast
descriere poate mbraca mai multe forme schema conceptual, diagrama entitaterelaie (diagrama ER).
B. Entiti, atribute, cheie primar
Conform Dicionarului Explicativ al Limbii Romne: o entitate este un coninut de
sine stttor, o existen determinat (ca ntindere, importan, valoare etc.). In
literatura dedicat bazelor de date exist mai multe definiii pentru acest termen:
Definiii
Entitate = un "lucru" sau un "obiect" din lumea real care poate fi distins (deosebit) de
toate celelalte lucruri sau obiecte = un obiect (precum o rachet, un tablou), un
eveniment (precum naterea unei persoane, marcarea unui gol), o activitate (producia
de oel a unei uzine, nchirierea unei maini) din lumea real care poate fi descris()
prin caracteristici bine definite (despre care exist date care pot fi stocate).
Definiii

11

Entitate i Instan
Prin entitate nelegem mulimea tuturor elementelor de un anumit tip (care prezint
aceleai caracteristici distinctive).
Prin instan a unei entiti nelegem un singur element, bine individualizat, unic, din
mulimea elementelor care formeaz entitatea respectiv.
Observaie

Entitile dintr-o baz de date pot fi disjuncte sau nu; n al doilea caz avem de a
face cu subentiti (de exemlu, entitile Piloi i MecaniciDeBord sunt disjuncte i
sunt subentiti ale entitii PersonalNavigant).

Intr-o baz de date pot exista entiti a cror existen este determinat de
existena altora (de exemplu, entitatea PersoaneInIntretinere depinde de entitatea
Salariai); primele se numesc entiti dependente, celelalte se numesc entiti
principale.
Definiie
Atribut = o caracteristic a unei entiti.
Un atribut posed un nume i pentru fiecare instan a entitii poate lua o
valoare dintr-o mulime fixat de valori, numit domeniul de valori ale atributului.
Atributele se pot clasifica dup complexitate n:
atribute compuse i atribute simple sau elementare, dup cum ele se mai pot
descompune sau nu n alte atribute, de mai mic complexitate. Exist atribute care nu
pot fi dect simple (atributele Capital, Suprafat, Continent ale entitii Tari). Exist
ns atribute care pot fi considerate fie simple, fie compuse. De exemplu: atributul
DataNasterii cu valorile: 1 ianuarie 2000, 2 Mai 1990 etc. poate fi privit fie ca un atribut
simplu, fie ca unul compus din atributele Zi, Lun, An. Este indicat s l tratm ca un
atribut compus dac prevedem necesitatea de a avea acces direct la luna sau anul de
natere al unei persoane nregistrate n baza de date. Dac ns o astfel de necesitate
nu este probabil i dac dorim s simplificm structura entitii (i deci a bazei de
date) atunci este preferabil s l tratm ca atribut simplu;
Atributele se pot clasifica dup mulimea de valori n:
atribute cu valori unice i atribute cu valori multile, dup cum ele pot lua pentru
instanele entitii respective cte o singur valoare (de exemplu, atributele Capital,
Suprafat, Continent ale entitii Tri) sau, dimpotriv, pentru unele instane pot lua
cte o singur valoare, pentru altele mai multe valori iar pentru altete nici o valoare (de
exemplu, atributul OrasCuMinimum2MilioaneLocuitori al entitii Tri). Cnd este cazul,
se pot defini limite inferioare i/sau superioare pentru numrul de valori pe care le
poate lua un astfel de atribut pentru o instan oarecare (de exemplu, putem specifica
faptul c atributul NrTelefon al entitii Persoane poate lua minimum o valoare
telefonul de serviciu i maximum trei.
Atributele se pot clasifica dup stabilitate n:
atribute de baz i atribute derivate, dup cum ele au valori de sine stttoare
sau care pot fi calculate din valorile altor atribute. De exemplu, s considerm entitile
corelate Cri, cu atributul NumrAutori i Autori, cu atributul Titlu; atributul
NumrAutori este un atribut derivat: valorile pe care le ia pentru diferite instane ale
entitii Cri pot fi calculate pe baza numrului de apariii ale atributului Titlu pentru
diferite instane ale entitii Autori.
Utilizarea instanelor unei entiti ridic dou probleme foarte importante:
modul de adresare a fiecrei instane a unei entiti;
determinarea instanelor care se repet.
Pentru a simplifica referirea la instanele unei entiti s-a recurs la mecanismul
identificatorului unic (sau al cheii primare).
Definiie
Identificatorul unic (sau cheie primar) = un atribut sau cea mai mic mulime de
atribute ale unei entiti care iau, pentru fiecare instan a entitii respective, o valoare
i numai una. Atunci cnd nici un atribut sau grup de atribute ale entitii rezonabil de

12

numeros nu ia valori disticte pentru fiecare instan a acesteia se poate aduga un

atribut convenional care s ndeplineasc aceast condiie. De obicei, acest atribut
este denumit cu ajutorul prefixelor cod sau id.
C. Relaii
Oridecteori un atribut al unei entiti se refer la alt entitate din baza de date
se stabilete, de fapt, o relaie ntre cele dou entiti. Cnd proiectm baza de date,
aceste referiri nu ar trebui s fie reprezentate ca atribute ale entitilor ci ca relaii (att
n sensul real ct i n sensul matematic al cuvntului) ntre entiti. Atributele prin care
se stabilete aceast relaie se numesc chei sau cmpuri de legatur.
Definiie
Relaie ntr-o baz de date = o legtur logic ntre dou sau mai multe entiti.
Modelul conceptual al bazelor de date relaionale poate fi reprezentat printr-o
schem conceptual sau printr-o diagram entitate-relaie.
Relaiile sunt caracterizate prin grad i cardinalitate (sau tip).
Definiie
Gradul unei relaii = numrul de entiti care particip la relaia respectiv.
Dup grad, relaiile pot fi
binare (ntre dou entiti; de exemplu: relaia JoacIn este o relaie binar ntre
entitile Actori i Filme);
ternare (ntre trei entiti; de exemplu: relaia LanseazMelodia este o relaie
ternar ntre entitile Compozitori, Textieri i Soliti);
n-are (ntre mai multe entiti; de exemplu: relaia Monteaz este o relaie de gradul
cinci ntre entitile Regizori, Scenografi, DesigneriCostume, Actori i PieseDeTeatru).
Definiie Cardinalitatea (tipul) unei relaii binare =
= numrul de instane ale celor dou entiti care sunt asociate prin relaia respectiv.
S considerm dou entiti E1 i E2; dup cardinalitate (sau tip), relaiile dintre
cele dou entiti pot fi
1 1 (one-to-one);
1 m (one-to-many);
n m (many-to-many).
Definiie
Relaie 11 = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1 ii
corespunde o singura instan din entitatea E2 i reciproc.
Definiie
Relaie 1m = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1
(numit entitate dominant) ii pot corespunde mai multe instane din entitatea E2 dar
unei instane din E2 nu-i poate corespunde dect cel mult o instan din E1 .
Definiie
Relaie nm = o relaie ntre dou entiti E1 i E2 n care unei instane a entitii E1
ii pot corespunde mai multe instane din entitatea E2 i, reciproc, unei instane din
entitatea E2 i pot corespunde mai multe instane din entitatea E1 .
D. Modelul relaional: fundamentarea teoretic
Conceptul matematic aflat la baza modelului relaional al bazelor de date este cel
de relaie:
Definiie
Se numete relaie peste mulimile M1, M2, Mn orice submulime a produsului lor
cartezian: R M1, x M2, x x Mn
Exemplu

13

Fie mulimile Marca = {Dacia, Ford, Fiat, Audi, Opel, Volvo}, Tip = {benzin, motorin},
CapacCil = {1100, 1200, 1300, 1400, 1600}, NrLoc = {4,5}, NrUi = {2, 4, 5}. Atunci,
entitatea Automobil poate fi reprezentat ca o relaie peste aceste mulimi:
Automobil Marca x Tip x CapacCil x NrLoc x NrUi
Iat cteva instane ale acestei entiti: (Dacia, benzin, 1400, 5, 4), (Dacia, motorin,
1400, 5, 4), (Dacia, benzin, 1100, 5, 4), (Dacia, motorin, 1400, 5, 5), (Ford, motorin,
1400, 5, 5), (Ford, benzin, 1600, 5, 4), (Fiat, benzin, 1300, 5, 4), (Fiat, benzin,
1100, 5, 4), (Audi, motorin, 1600, 5, 4), (Opel, benzin, 1400, 5, 5), (Volvo, benzin,
1400, 5, 5), (Volvo, motorin, 1600, 5, 4).
Dac generalizm exemplul de mai sus obinem:
E A1 x A2 x x An
unde am notat cu E entitatea i cu A1, A2, , An mulimile de valori (domeniile)
atributelor sale. Un element al acestei relaii (adic un tuplu al produsului cartezian)
reprezint o instan ei a entitii E i const din valori particulare ale atributelor.
Pentru simplitatea reprezentrii, entitile nu sunt reprezentate ca mulimi de
tupluri (ca n exemplul nostru de mai sus) ci ca tabele (vezi Tabelul 4), tot aa cum, n
loc s notm cu <(3,5) instana relaiei de ordine < N X N dintre numerele naturale
3 i 5, scriem 3 < 5.
Marca
Dacia
Dacia
Dacia
Dacia
Ford
Ford
Fiat
Fiat
Audi
Opel
Volvo
Volvo

Tip
benzin
motorin
benzin
motorin
motorin
benzin
benzin
benzin
motorin
benzin
benzin
motorin

CapacCil
1400
1400
1100
1400
1400
1600
1300
1100
1600
1400
1400
1600

NrLoc
5
5
5
5
5
5
5
5
5
5
5
5

NrUi
4
4
4
5
5
4
4
4
4
5
5
4

Tabelul 4: O entitate, o relaie matematic, o tabel

Puterea i elegana modelului relaional este dat de faptul c i relaiile dintre entiti
pot fi reprezentate tot prin tabele.
E. Stabilirea relaiilor ntre entiti
La nivelul modelului conceptual, cardinalitatea relaiilor este o caracteristic
instrinsec a acestora; atunci cnd proiectm ns baza de date relaiile dintre entiti
trebuie definite n mod efectiv. Acest lucru se realizeaz n mod diferit pentru fiecare tip
de relaie.
Fie dou entiti U i V i fie T1 i T2 tabelele prin care sunt reprezentate
(conform conveniilor din paragraful anterior). Pentru simplitate, vom presupune c
entitile aflate n relaie sunt identificate prin chei primare formate dintr-un singur
atribut.
E.1. Rezolvarea relaiilor 1-1
Pentru a stabili o relaie 1-1 ntre dou entiti utilizm aceelai atribut pe post de cheie
primar pentru ambele entiti.

14

Figura 8: Implementarea unei relaii 1-1 n Ms Access

E.2. Rezolvarea relaiilor 1-m
n acest caz, trebuie s definim noiunea de cheie extern:
Fie dou entiti U i V (de exemplu: Clase i Elevi) avnd atributele a1 (cheie
primar), a2, , an i respectiv b1 (cheie primar), b2, , bm, a1, (de exemplu:
CodClas, Locaie, nrBanci, nrTable, respectiv CNP, Nume, Prenume, Adresa,
CodClas). Prin cheie extern nelegem un atribut al entitii V a crui mulime de
valori coincide cu mulimea valorilor cheii primare din entitatea U (aici: atributul
CodClas este cheie primar pentru entitatea Clase i cheie extern pentru entitatea
Elevi).
Pentru a stabili o relaie 1-m ntre dou entiti (aici relaia InCareInva ntre
entitile Clase i Elevi) procedm astfel:
(1.) includem n descrirea ambelor entiti un acelai atribut (aici: CodClas);
(2.) definim acest atribut drept cheie primar pentru entitatea principal i drept cheie
extern pentru entitatea secundar.
E.3. Rezolvarea relaiilor n-m
In acest caz, ne bazm pe faptul c n modelul relaional nu numai entitile ci i
relaiile dintre ele sunt relaii n sens matematic i, ca urmare, pot fi reprezentate prin
tabele. Am observat, de asemenea, c relaiile dintre entiti pot avea atribute (inclusiv
chei primare).
Pentru a o stabili o relaie n-m ntre dou entiti (aici: relaia Comand ntre
entitile Clieni i Furnizori) procedm astfel:

15

(1.) includem n descrierea relaiei (aici: Comand) pe post de chei externe dou
atribute care s corespund atributelor care funcioneaz drept chei primare pentru
cele dou entiti (aici: CodClient i CodFurnizor);
(2.) reducem astfel stabilirea unei relaii n-m (aici: relaia dintre Clieni i Furnizori) la
stabilirea a dou relaii 1-m (aici: relaiile dintre Clieni i Comand i respectiv
dintre Furnizori i Comand).

Figura 9: Implementarea unei relaii de tip n-m n Ms Access

F. Reguli de integritate pentru bazele de date
Dup modelarea bazei de date la nivel structural (definirea entitilor, a atributelor
lor i a relaiilor dintre ele) urmeaz nivelul operaional al modelrii:
stabilirea tipurilor de operaii care se pot efectua asupra datelor stocate (sortare,
cutare, vizualizare, adugare, tergere, modificare etc., prezentate mai jos);
verificarea respectrii regulilor de integritate (ceea ce va asigura corectitudinea i
consistena datelor).
Distingem urmtoarele tipuri principale de reguli integritate:
a entitilor;
a relaiior (numit i regula de integritate referenial);

16

La acestea se adaug i regulile de integritate impuse de situaia real modelat prin

baza de date, numite restriciile contextuale.
F.1. Valorea special Null a atributelor
Pentru a putea formula prima regul de integritate trebuie s analizm situaia
unei valori speciale pe care o pot lua atributele entitilor: valoarea Null.
Definiie
Null = valoarea pe care o ia un atribut pentru o instan a unei entiti atunci cnd
pentru respectiva instan:
nu exist o valoare,
exist o valoare dar nu a fost nregistrat (de exemplu, atributul
SerieNrCarteIdentitate),
nu tim dac exist sau nu o valoare (de exemplu, atributul NrApartament).
Prin urmare, aceast valoare artificial, care nu trebuie confundat cu valoarea
0 sau cu stringul vid a fost incorporat modelului relaional al bazelor de date pentru
a permite tratarea excepiilor i a datelor incomplete. In ciuda alternativei, mult mai
"nocive": introducerea unor date false, utilizarea valorii Null este inc destul de
controversat (E.F. Codd a susinut-o iar C.J. Date o respinge); exist SGBD-uri care
nu implementeaz valoarea Null.
F.2. Integritatea entitilor
Prima regul de integritate se aplic cheilor primare.
Definiie
Oricare ar fi entitatea E din baza de date, nici un atribut care face parte din cheia sa
primar nu poate lua valoarea Null pentru nici o instan a entitii.
Dac am permite ca un atribut din componena cheii primare a entitii s ia
valoarea Null, am contrazice cerina de minimalitate a cheii primare (ar insemna ca
restul atributelor care formeaz cheia i care iau numai valori din domeniile lor
respective de valori ar fi suficiente pentru a identifica n mod unic fiecare instan a
entitii).
F.3. Integritatea referenial
A doua regul de integritate se aplic cheilor externe.
Definiie
Fie dou entiti U i V relaionate; pentru orice instan a entitii V (secundar)
valoarea cheii externe trebuie s corespund valorii cheii primare a unei instane
oarecare a entitii U (principal) sau s fie Null.

Figura 10: Stabilirea integritii refereniale n Ms Access

17

F.4. Restricii contextuale

In etapa de analiz a situaiei reale care trebuie modelat prin baza de date, n
discuiile dintre proiectanii bazei de date i viitorii ei proprietari i utilizatori, pot aprea
informaii suplimentare privind restriciile pe care trebuie s le ndeplineasc datele
stocate i operaiile efectuate asupra lor.
Definiie
Restricii contextuale = reguli suplimentare privind modul de nregistrare a datelor i
de efectuare a operaiilor, specifice situaiei reale sau impuse de diferitele categorii de
participani de proiectarea, construirea, administrarea i utilizarea bazei de date.
1.5. Normalizarea bazelor de date
A. Introducere: definiii, terminologie
Normalizarea poate fi privit ca ultima etap n proiectarea unei baze de date.
Aa cum am vzut, acest proces de tip top-down ncepe cu identificarea
principalelor entiti i relaii; urmeaz ca acestea s fie examinate (inclusiv la nivelul
raporturilor dintre atributele care le caracterizeaz) n scopul eliminrii tuturor
"defectelor" lor i transformrii ntr-un set de relaii adecvat, coerent i bine structurat.
Aceast tehnic a fost iniiat tot de E.F. Codd (a se vedea [6]). El a propus
iniial trei seturi de reguli pe care o relaie trebuie s le satisfac pentru a fi coerent i
pe care le-a denumit prima (FN1), a doua (FN2), respectiv a treia (FN3) form normal
(dnd astfel i numele tehnicii nsi). Ulterior, R. Boyce a introdus, mpreun cu E.F.
Codd, o definiie mai tare a FN3 denumit forma normal Boyce-Codd (FNBC). In
fine, au mai fost definite nc dou forme normale: a patra (FN4) i a cincea (FN5)
form normal, care ns au n vedere situaii destul de rar intalnite.
S remarcm caracterul "progresiv" al acestor forme normale (ilustrat i prin
Figura 1): o relaie aflat n FN3 este automat n FN2 i deci i n FN1. De fapt,
cteodat din punct de vedere al performanelor n exploatare este preferabil ca
baza de date s fie lsat intr-o form normal inferioar (se execut procesul invers
normalizrii, denumit denormalizare a bazei de date).

Figura 11: Formele normale

Este justificat ntrebarea: cte forme normale mai ateapt s fie descoperite?
Rspunsul a fost dat de R. Fagin n 1981 (a se vedea [11]). In acest articol este
introdus o form normal care se bazeaz pe noiunile de domeniu de valori i cheie
primar (FN/DK)i se demonstreaz c o relaie este n FN/DK dac i numai dac nu
prezint anomalii la modificarea datelor. Aceast teorem arat c nu mai este nevoie
de nicio alt form normal (cel puin din punctul de vedere al eliminrii anomaliilor la
modificarea datelor).
Definiie

18

Normalizare = un proces prin care un set de relaii care ncalc anumite principii de
proiectare este nlocuit cu un alt set de relaii adecvat, coerent i bine structurat.
Acest proces se desfoar n mai multe etape: n fiecare etap se urmrete
eliminarea unui alt tip de defecte ale relaiilor astfel nct, pe msur ce relaiile trec n
forme normale superioare, ele devin din ce n ce mai puin vulnerabile fa de
anomaliile de actualizare a datelor.
Pentru a prezenta procesul de normalizare, este necesar s definim urmtoarele
dou concepte:
anomalie la actualizare,
dependen funcional.
Pentru simplificare, vom utiliza acolo unde este cazul reprezentarea prin
tabele a entitilor i relaiilor din baza de date.
B. Anomalii la actualizare
Unul dintre principalele obiective n proiectarea bazelor de date este eliminarea
redundanelor (a nregistrrii acelorai date de mai multe ori). Fie, de exemplu,
entitile :
Elevi {CNP, CodClas, Nume, Prenume, Adres};
Clase {CodClas, Locaie, NrBanci, NrTable};
EleviClase {CNP, Nume, Prenume, Adres, CodClas, Locaie, NrBanci, NrTable}.
Dac n baza de date includem tabelele Elevi i Clase nu vom avea redundane
n date; n schimb, dac includem tabelele Clase i EleviClase (sau Elevi i
EleviClase) redundana va fi evident.
Tabelele care conin date redundante pot genera probleme n momentul
actualizrii informaiei. Acestea se numesc anomalii la actualizare i sunt de trei
tipuri:
1. anomalii la adugare;
2. anomalii la tergere;
3. anomalii la modificare.
Le vom ilustra prin exemple pentru cazul n care n baza de date includem tabelele
Clase i EleviClase definite n schema conceptual de mai sus:
CodClas
XIB
XA
IXC

Locaie
Cam23
Cam12
Cam15

NrBanci
18
21
18

NrTable
3
2
2

(a) Entitatea Clase

CNP
1900530123
1900924456
2900225789
2900807246
1901010357

Nume
Savu
Rosu
Banu
Rona
Mares

Prn
Ion
R
M
C
D

Adr
B
CJ
B
AR
DJ

CodCl
IXC
XA
XA
IXC
XIB

Loc
Cam09
Cam15
Cam15
Cam09
Cam23

NrB
15
21
21
15
18

NrT
2
3
3
2
3

(b) Entitatea EleviClase

Figura 12: Dou relaii care pot produce anomalii de actualizare

19

(1.) Distingem dou tipuri de anomalii la adugare:

(a.)
CNP
1900530123
1900924456
2900225789
2900807246
1901010357
1900404135
2901010555

Nume
Savu
Rosu
Banu
Rona
Mares
Olaru
Manu

Prn
Ion
R
M
C
D
S
D

Adr
B
CJ
B
AR
DJ
TL
PL

CodCl
IXC
XA
XA
IXC
XIB
XIB
XIB

Loc
Cam09
Cam15
Cam15
Cam09
Cam23
Cam23
Cam23

NrB
15
21
21
15
18
18
18

NrT
2
3
3
2
3
3
2

Figura 13 : Repetarea datelor despre clas la

nregistrarea fiecrui nou elev trebuie s se fac exact
(b.)
CNP
1900530123
1900924456
2900225789
2900807246
1901010357
Nul

Nume
Savu
Rosu
Banu
Rona
Mares
Null

Prn
Ion
R
M
C
D
Nul

Adr
B
CJ
B
AR
DJ
Null

CodCl
XIB
XIB
XA
IXC
XIB
XE

Loc
Cam23
Cam23
Cam15
Cam09
Cam21
Cam11

NrB
18
18
21
15
21
16

NrT
3
3
3
2
3
2

Figura 14: Adugarea unei noi clase (n care nu exist nc

elevi) necesit introducerea valorii Null n celulele destinate
datelor despre elevi, deci inclusiv n cheia primar. Acest
lucru contravine regulii de integritate a entitilor
(2.) Anomalii la tergere
CodClas
XA
IXC
CNP
1900530123
1900924456
2900225789
2900807246
1901010357

Locaie
Cam12
Cam15
Nume
Savu
Rosu
Banu
Rona
Mares

Prn
Ion
R
M
C
D

NrBanci
21
18
Adr
B
CJ
B
AR
DJ

CodCl
XIB
XIB
XA
IXC
XIB

Loc
Cam23
Cam23
Cam15
Cam09
Cam21

NrTable
2
2
NrB
18
18
21
15
21

NrT
3
3
3
2
3

Figura 15: Datele despre clasa a XIB au fost terse din tabela Clase
dar datele elevilor din acea clas au rmas n tabela EleviClase

20

(3.) Anomalii la modificare

CodClas
XIB
XA
IXC

Locaie
Cam23
Cam12
Cam15

NrBanci
20
21
18

NrTable
4
2
2

Figura 16: In tabela Clase s-au operat modificri n datele

care descriu una dintre clase dar n tabela EleviClase au
rmas nc datele vechi despre respectiva clas
CNP
1900530123
1900924456
2900225789
2900807246
1901010357

Nume
Savu
Rosu
Banu
Rona
Mares

Prn
Ion
R
M
C
D

Adr
B
CJ
B
AR
DJ

CodCl
XIB
XIB
XA
IXC
XIB

Loc
Cam23
Cam23
Cam15
Cam09
Cam21

NrB
18
18
21
15
21

NrT
3
3
3
2
3

C. Dependene funcionale
Procesul de normalizare se bazeaz pe examinarea relaiilor dintre atributele
entitilor, oglindite prin conceptul de dependen funcional.
Definiie
Dependen funcional = o restricie care apare ntre atributele unei entiti la nivelul
semanticii (semnificaiei) acestora: fie a1 i a2 atributele unei entiti E; spunem c
atributul a2 este dependent funcional de atributul a1 dac fiecrei valori a atributului
a1 i corespunde o valoare i numai una a atributului a2 .
Observaie
Observm c unei valori a atributului a2 i pot corespunde mai multe valori ale
atributului a1. (putem spune c a1 este argumentul iar a2 este imaginea unei funcii
n sensul matematic al cuvntului).
Se pot afla n dependen funcional nu numai atribute individuale ci i grupuri de
atribute. Vom ignora dependenele triviale, adic dependenele a1 a2 n care a2
depinde funcional de un subset al a1.
Notm dependena funcional a atributelor a1 i a2 prin
a 1 a2
i o reprezentm grafic ca n Figura 7.
atributul a2 depinde

a1

a2
funcional de a1

Figura 17: Reprezentarea grafic a dependenei funcionale

Definiie
Determinantul unei dependene funcionale = atributul care, prin valorile sale,
determin valorile celuilalt atribut (adic: atributul aflat, n oricare dintre cele dou
reprezentri, n stnga sgeii).
Observaie
Examinarea dependenelor funcionale dintre atributele unei entiti ne permite s
determinm care dintre cheile candidate trebuie s fie aleas drept cheie primar: este

21

aleas cheia candidat care apare ca determinant n toate dependenele funcionale

identificate la nivelul entitii respective (a se vedea al doilea exemplu de mai sus.
D. Procesul de normalizare
Normalizarea unei baze de date este un proces care se desfoar n mai muli
pai. Fiecare pas (cu excepia aducerii bazei de date la FN1) presupune:
1. identificarea dependenelor funcionale;
2. verificarea ndeplinirii unor anumite proprieti denumite generic forme normale.
Pe msur ce procesul de normalizare progreseaz, relaiile care compun baza
de date (fie c acestea corespund unor entiti sau unor relaii dintre entiti) devin din
ce n ce mai riguroase (forma normal pe care o satisfac este mai restrictiv: a se
vedea Figura 1 de mai sus).
Din punctul de vedere al modelului relaional, singura form normal obligatorie
pentru toate relaiile din baza de date este FN1; dac ns dorim s evitm toate
anomaliile de actualizare (analizate mai sus) este necesar s continum procesul de
normalizare cel puin pn la FN3.
Observaie
Reamintim faptul c n modelul relaional, orice entitate i relaie dintre entiti este
modelat matematic prin conceptul de relaie i reprezentat convenional printr-o
tabel. In continuare, prin relaie vom nelege modelul matematic al unei entiti sau al
unei relaii ntre entiti, reprezentat convenional printr-o tabel, ca mai sus.
E. Prima form normal (FN1)
Dup definirea structurii i a operaiilor cu baza de date, urmeaz introducerea
datelor (crearea instanelor entitilor i a relaiilor dintre ele). Acest lucru nseamn
n principal transferarea datelor concrete din formularele de culegere a datelor n
tabelele asociate entitilor / relaiilor. Dup parcurgerea acestui pas, se obin de
obicei tabele nenormalizate, adic tabele n care unele celule conin mai multe
valori ale aceluiai atribut sau repet valori din alte celule.


Exemplu
Fie baza de date a unei firme de transport auto care se ocup cu transportul de
persoane; dintre entitile care apar intr-o astfel de baz de date enumerm: Angajai,
Vehicule, Garaje, Clieni, Trasee. S presupunem c formularele de culegere date
completate de eful fiecrui garaj conin (pe lng adresa garajului): tipul vehiculelor
deinute (limuzin, microbuz, autocar), numerele de nmatriculare ale acestora, datele
de identificare ale oferilor care le conduc. Transcrirea direct a datelor din aceste
formulare n tabela Garaje poate conduce la rezultatul din Figura 15.

Figura 18: Tabela Garaje11 n Ms Access

22

Dac examinm celulele din coloana tipAuto (precum i din coloana Soferi)
constatm c tabela Garaje se afl n form nenormalizat. Ca urmare, tabela
trebuie trecut n FN1.
Definiie
Relaie aflat n prima forma normal (FN1) = o relaie cu proprietatea c oricare
dintre celulele tabelei care o reprezint convenional conine o valoare i numai una (nu
exist atribute cu valori multiple).
Se cunosc dou metode de a aduce o relaie n FN1; o vom prezenta pe cea mai
eficient dintre ele (vom presupune c un singur atribut nu respect condiia din FN1):
Aducerea unei relaii la FN1
Fie E o entitate (aici: Garaje), a atributul su (aici: tipAuto) responsabil pentru forma
nenormalizat a tabelei T corespunztoare entitii (aici: tabela Garaje11).
Aducerea tabelei la FN1 necesit:
(1.) eliminarea atributului a din entitatea E / a coloanei corespunztoare din tabela
T (aici: a coloanei TipAuto din tabela Garaje11; denumim Garaje22 tabela astfel
rezultat);
(2.) crearea pornind de la atributul a a unei noi entiti E' ; fie T' tabela care o
reprezint (aici: pe baza atributului TipAuto crem entitatea Vehicule cu cheia primar
NrInmatr i atributele: TipAuto, Marca, NrStele, NrLocuri, Culoare);
(3.) stabilirea relaiei dintre cele dou entiti, relaie care este dup caz de tip 1-m
sau n-m (aici: relaia dintre entitile Garaje i Vehicule este de tip 1-m). Prin
urmare, cheia primar a entitii E trebuie s inclus cu rol de cheie extern
printre atributele entitii E' (aici: includem atributul CodGaraj cu rol de cheie
primar pentru entitatea Garaje pe post de cheie extern pentru entitatea Vehicule).

Figura 19: Tabela Garaje dup prima modificare

23

Figura 20: Tabela nou creat, Vehicule

Figura 21: Relaiile dintre noile tabele

Atenie
Intr-o relaie pot exista mai multe atribute cu valori multiple, deci care s fie fiecare la
rndul su responsabile pentru forma nenormalizat a relaiei (tabelei). In acest caz,
aducerea relaiei la FN1 se desfoare n tot atia pai cte astfel de atribute exist
(aici: noua tabel Garaje22 este tot n form nenormalizat din cauza atributului
Soferi). Prin urmare, vom proceda pentru acest atribut aa cum am procedat i pentru
atributul TipAuto: a se vedea Figura 12 (tabela Garaje33 aflat acum n FN1) i
Figura 13 (tabela Soferi nou creat) precum i Figura 14 (tabela de jonciune Conduc
prin care vom realiza relaia de tip nm dintre entitile nou create Soferi i
Vehicule).

24

Figura 22: Tabela Garaje33 (complet normalizat)

Figura 23: Tabela nou creat, Soferi

25

Figura 24: Tabela de jocntiune Conduce

Atenie
Procesul de aducere la FN1 a evideniat necesitatea inregistrrii unor informaii
noi: numerele de nmatriculare ale autovehiculelor (la primul pas), datele personale ale
oferilor (la al doilea pas). Pe de alt parte, n forma iniial, nenormalizat, tabela
Garaje11 coninea o serie de informaii auxiliare (ce tip de vehicule se afl n fiecare
garaj, ce oferi le conduc) care se pot pierde la normalizare. Acest lucru poate fi evitat
dac ntre noile entiti aprute prin normalizare se stabilesc relaiile corespunztoare
(aici: la primul pas s-a stabilit o relaie 1-m ntre entitatea Garaje modificat i
entitatea Vehicule nou creat, iar la pasul al doilea s-a stabilit o relaie nm ntre
entitile nou create Soferi i Vehicule, deoarece n principiu un ofer poate
conduce mai multe vehicule i un vehicul poate fi condus de mai muli oferi iar o
restricie contextual a bazei de date poate stipula ce vehicule poate conduce fiecare
ofer i ce oferi pot conduce fiecare vehicul. De aceea, am creat tabela de jonciune
Conduc cu atributele CNP, NrInmatr. Acestea sunt chei primare n tabelele Soferi
respectiv Vehicule i sunt chei externe n tabela Conduc, dar formeaz mpreun
cheia primar pentru tabela Conduc).

26

Figura 25: Setul de relaii rezultat dup incheierea operatiei

de aducere la FN1 a entitii Garaje
F. A doua form normal (FN2)
O relaie care este n FN1 dar nu este n FN2 poate suferi de anomalii de
modificare, ca n exemplul de mai jos.
Exemplu
Fie baza de date a unui institut de cercetri care are mai multe filiale i n care
salariaii sunt pltii n funcie de numrul de ore lucrate n cadrul unui proiect de
cercetare sau al altuia. Dintre entitile care apar ntr-o astfel de baz de date
enumerm: Filiale = {CodFil, NumeFil, LocFil}, Angajai = {CNP, CodFil, NumeAng,
Adresa, SalariuPeOra}, Proiecte = {CodPrj, TitluPrj, CodFil, DataPredrii}. Pe lng
acestea, am mai introdus n baza de date i entitatea AngajaiProiecte = {CNP,
NumeAng, CodPrj, TitluPrj, NrOre, DataPredrii} cu instanele din Figura 16.
S presupunem c data de predare a proiectului tr1 a fost devansat cu o lun; dac
nu operm aceast modificare n ambele nregistrri din tabel care se refer la acest
proiect atunci apare o anomalie de actualizare i baza de date ii pierde consistena.

27

Figura 26: Tabela AngajaiProiecte

Observaie
FN2 se refer numai la relaii a cror cheie primar este format din mai multe atribute
deoarece se bazeaz pe conceptul de dependen funcional complet.
Definiie
Dependena funcional complet
Fie a1 i a2 dou (mulimi de) atribute ale entitii E; spunem c a2 este complet
dependent funcional de a1 dac i numai dac a2 este dependent funcional de a1
dar nu este dependent funcional de nicio submulime proprie a lui a1.
Dac, dimpotriv, putem elimina un atribut din mulimea de atribute a1 iar a2 continu
s fie dependent funcional de a1 atunci spunem c a2 este doar parial dependent
funcional de a1.
Contraexemplu
S examinm relaia Vehicule din exemplul de mai sus: dependena funcional
NrInmatr, TipAuto CodGaraj
nu este complet: atributul CodGaraj este dependent funcional de un subset al
{NrInmatr, TipAuto }, i anume de NrInmatr.
Definiie
A doua form normal
O relaie este n FN2 dac i numai dac:
(1) este deja n FN1;
(2) oricare dintre atributele sale care nu fac parte din cheia primar este complet
dependent funcional de cheia primar.
Aducerea unei relaii la FN2
Fie E o entitate aflat n FN1; aducerea ei la FN2 necesit:
(1.) identificarea tuturor dependenelor funcionale dintre atributele entitii E;
(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:
o
fiecare dependen funcional complet definete o nou relaie;
o
din fiecare dependen funcional parial se elimin acea parte a cheii
primare care este rspunztoare de incompletitudinea dependenei i apoi se
definete noua relaie.
(3.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaii de legatur,
pierdute eventual prin inlocuirea entitii iniiale cu entitile normalizate).
Aducerea unei relaii la FN2
28

Ilustrm metoda de mai sus pentru entitatea AngajaiProiecte din Figura 17. La
prima vedere, fiecare dintre atributele entitii: NumeAng, titluPrj, nrOre, dataPredrii
depinde funcional de cheia primar a acesteia: CNP, codPrj. Aplicnd definiia
dependenei funcionale complete observm c numai atributul nrOre depinde
funcional complet de ambele atribute care formeaz cheia primar (a se vedea
dependena funcional d.f.1 din Figura 17). Celelalte dependene sunt pariale; din ele
obinem urmtoarele dependene complete: d.f.2 i d.f.3. Ca urmare, vom nlocui
entitatea AngajaiProiecte cu entitile AP1, AP2, AP3 (Figura 18) i vom stabili
relaiile dintre ele.
d.f.2
d.f.1
CNP

codPrj

nrOre

NumeAng

titluPrj

dataPredrii

d.f.3
Figura 27: Dependenele funcionale complete din entitatea AngajaiProiecte

AP1
CNP

AP2
codPrj

nrOre

CNP

NumeAng

AP3
codPrj

titluPrj

dataPredrii

Figura 27: Normalizarea entitii AngajaiProiecte

Figura 28: Relaiile dintre noile tabele aflate n FN2

29

G. A treia form normal (FN3)

O relaie care este n FN2 dar nu este n FN3 poate suferi de anomalii de
modificare, ca n exemplul de mai jos.
Exemplu
Fie baza de date a institutului de cercetri descris n paragraful anterior. S
presupunem c am mai introdus n baza de date i entitatea AngajaiFiliale = {CNP,
NumeAng, Adresa, Oras, CodFil, NumeFil, LocFil} cu instanele din Figura 20.
In cazul n care una dintre filiale ii schimb sediul (de exemplu filiala CercAero se
mut de la Hui la Iai), operarea modificrii numai n una dintre cele dou nregistrri
care se refer la filiala respectiv determin apariia unei anomalii de actualizare i
baza de date ii pierde consistena.

Figura 29: Tabela AngajaiFiliale

Observaie
FN3 se bazeaz pe conceptul de dependene funcionale tranzitive.
Definiie
Dependene funcioanle tranzitive
Fie a1 , a2 i a3 trei atribute ale unei entii E cu proprietatea c:
(1) a1 a2 i a2 a3
(2) a1 nu depinde funcional nici de a2 nici de a3
Atunci: a1 a3 ( a3 depinde funcional de a1 via a2 ).

Exemplu
S examinm relaia EleviClase din paragraful 4.2:
CNP

Nume

Prn

Adr

CodCl

Loc

NrB

NrT

1900530123

Savu

Ion

IXC

Cam09

15

1900924456

Rosu

CJ

XA

Cam15

21

2900225789

Banu

XA

Cam15

21

2900807246

Rona

AR

IXC

Cam09

15

1901010357

Mares

DJ

XIB

Cam23

18

Avem urmtoarele dependene funcionale: CNP CodCl i CodCl

Loc; atunci avem i CNP Loc via atributul CodCl deoarece atributul
CNP nu depinde funcional nici de CodCl nici de Loc.

30

Definiie
A treia form normal
O relaie este n FN3 dac i numai dac:
(1) este deja n FN2;
(2) nici unul dintre atributele sale care nu fac parte din cheia primar nu este, prin
tranzitivitate, dependent funcional de cheia primar.
Aducerea unei relaii la FN3
Fie E o entitate (aici: AngajaiFiliale) aflat n FN2 i a1 , a2 i a3 trei atribute ale
sale cu proprietatea c: a1 a2 i a2 a3 (aici: CNP, CodFil , LocFil : CNP
CodFil , CodFil LocFil):
Aducerea tabelei la FN3 necesit:
(1.) identificarea tuturor dependenelor tranzitive dintre atributele entitii E;
(2.) descompunerea relaiei E ntr-un numr de noi relaii astfel:
o
atributul a1 impreun cu toate atributele care depind funcional de el (deci
inclusiv a2 ) formeaz o nou relaie (aici: atributele CNP, NumeAng, Adresa,
Oras, codFil formeaz entitatea Ang1);
o
atributul a2 impreun cu atributul a3 i cu alte atribute care depind funcional
de a1 prin tranzitivitate formeaz o nou relaie (aici: atributul NumeFil se
adaug atributelor CodFil i LocFil pentru a forma entitatea Fil1);
(3.) definirea atributului a2 drept cheie primar a celei de-a doua entiti nou create;
(4.) stabilirea relaiilor dintre noile entiti (n scopul recuperrii informaiilor de
legatur, pierdute eventual prin inlocuirea entitii iniiale cu entiti normalizate).
CNP

NumeAng Adresa

Oras

CodFil

NumeFil

LocFil

Figura 30: Dependenele funcionale tranzitive din entitatea AngajaiFiliale

CodFil NumeFil LocFil
CNP

NumeAng

Adresa

Oras

CodFil

Figura 31: Normalizarea entitii AngajaiFiliale

Observaie
Observm c atributul care asigur tranzitivitatea (atributul notat a2) nu este nici cheie
primar n relaia respectiv nici mcar parte a cheii primare. Tocmai din acest motiv,
dependena a2 a3 nu este dezirabil la nivelul relaiei respective.

31

FN1

FN2

FN3

Condiie de verificat
Toate atributele relaiei
trebuie s fie atomice
Relaia este n FN1;
Cheia sa primar const
din mai multe atribute;
Toate atributele care nu
fac parte din cheia primar
sunt complet dependente
funcional de cheia primar
Relaia este n FN2;
Nici un atribut care nu
face parte dintr-o cheie
candidat nu este funcional
dependent de un alt atribut
care nu face nici el parte
dintr-o cheie candidat (nici
un atribut care nu face
parte
dintr-o
cheie
candidat nu este funcional
dependent
de
cheia
primar prin tranzitivitate)

Soluie (normalizare)
Fiecare atribut neatomic se
transform intr-o nou relaie
Fiecare parte a cheii primare,
mpreun cu atributele care
depind funcional complet de ea
formeaz o nou relaie;
Se stabilesc relaiile necesare
ntre noile relaii care au nlocuito pe cea iniial
Se pstreaz n relaia iniial
numai cheia primar i atributele
care depind funcional de ea
direct
(inclusiv
atributul
"incriminat");
Se creeaz cte o nou
relaie din fiecare atribut care nu
face parte din cheia primar
mpreun cu toate atributele
(care nu fac nici ele parte din
cheia primar a relaiei iniiale)
care sunt dependente funcional
de acesta;
Se stabilesc relaiile necesare
ntre noile relaii i relaia iniial
modificat

Tabelul 6: Recapitulare a primelor trei etape din procesul de normalizare

1.6. Trecerea de la modelul conceptual la modelul fizic
Dup cum ami observat n capitolele anterioare, regulile ce se pot extrage dintrun studiu de caz pot fi descrise prin elemente ale modelului conceptual: entiti,
atribute, identificatori unici, relaii ntre entiti.
Acest model poate fi utilizat pentru determinarea modelului fizic al oricrui tip de
baz de date.
La nivelul modelului fizic:

tabela este o structur utilizat pentru stocarea i organizarea datelor. Tabelele

sunt formate din linii i coloane;

fiecare coloan va reine date de un anumit tip i corespunde unui atribut al

entitii; numele atributului devine antetul unei coloane din tabel;

un rnd din tabel corespunde unui element al entitii (instan a entitii) i se

numete nregistrare. Aceasta va descrie complet proprietile unei instane;

cheie primar este reprezentat de o coloan sau o combinaie de coloane ale

cror valori sunt unice la nivelul tabelei i sunt completate obligatoriu. Cheile primare
provin din identificatorii unici ai entitii.
Crearea unei tabele se realizeaz n dou etape:
1.
n prima etap se stabilete structura tabelei, specificndu-se numele cmpurilor,
lungimile acestora, precum i tipul informaiilor care vor fi introduse n fiecare
cmp.
2.
n a doua etap se ncarc efectiv datele n tabel.

32

A. Exemplificare n limbajul de programare ACCESS

Dup definirea structurii putem trece la introducerea propriu-zis a datelor n
cmpurile tabelei, ncheind astfel operaia de creare (ulterior, tabela va putea fi folosit
n operaii de modificare a structurii sau de actualizare a datelor). Pentru aceasta:
Pas 1. se afieaz tabela n modul Datasheet View
Pas 2. se introduc direct datele n cmpurile corespunztoare (se plaseaz cursorul
n celul, se tasteaz valoarea i se acioneaz tasta ENTER). Se folosete tasta TAB
pentru a trece dintr-o celul n alta. Se folosesc tastele cu sgei pentru a parcurge
tabela pe orizontal i pe vertical.

B. Exemplificare n limbajul de programare FOXPRO

A) Introducerea datelor
Adugarea articolelor se face la sfritul tabelei
active. Adugarea unui articol vid se realizeaz cu ajutorul
comenzii APPEND BLANK. Un cmp vid are una din
valorile: zero pentru cmpul numeric, spaiu pentru
cmpul caracter, .F. (fals) pentru cmpurile logice,
valoarea {/ /} pentru dat calendaristic.
Structura tabelei se creeaz prin comanda (de exemplu:
tabela Elevi):
create table elevi (numr_matricol n(5), nume c(5),
prenume c(13), data_naterii d, clasa c(2) )
Se adaug nregistrrile folosind o structur de control
repetitiv cu numr cunoscut de pai (for), comenzi de
afiare pe ecran de elemente de control ncepnd de la o
linie i o coloan specificat (de tipul l, c say [introducei...
]) i comanda de tipul read (ce realizeaz adugarea
efectiv a datelor citite n nregistrarea vid).
for i=1 to 8 do
append blank
@4,4 say [numr matricol:] get numr_matricol
@5,4 say [nume:] get nume
@6,4 say [prenume:] get prenume
@7,4 say [data naterii:] get data_naterii
@8,4 say [clasa:] get clasa
read
end for
Introducerea datelor se poate realiza vizual
folosind oricare din editoarele Browse sau Edit, utiliznd
opiunile meniului View.
Salvarea informaiilor se poate realiza folosind
33

combinaia de taste Ctrl + W sau executnd clic pe butonul de nchidere al ferestrei de

editare.
Pentru adugarea vizuala de nregistrri vide la sfritul unei tabele se poate
utiliza opiunea Append New Record din meniul Table sau opiunea Append Mode din
meniul View.
B) Modificarea datelor
Comanda REPLACE este utilizat pentru modificarea valorilor din ultima tabel
selectat cu expresii ce pot fi evaluate n momentul executrii comenzii:
Forma general a comenzii REPLACE este:
REPLACE <cmp1> WITH <expresie 1> [,<cmp2> WITH <expresie2>]
[domeniu] [FOR <condiie>] [WHILE <condiie>]
Pentru actualizarea i vizualizarea datelor poate fi utilizat i comanda
BROWSE care va afia tabela activ pe linii i pe coloane (pe prima linie sunt afiate
denumirile cmpurilor din structura tabelei, iar n continuare sunt afiate liniile cu date).
C. Exemplificare n limbajul de programare ORACLE
A) Introducerea datelor
Comanda INSERT este utilizat pentru introducerea unei noi nregistrri ntr-o
tabel. Sintaxa general a acestei comenzi este:
INSERT INTO <nume_tabel>
[(nume_coloan1, [nume_coloan2, ... ])]
VALUES (expresie1, expresie2, ... )
Pentru adugarea unui nou articol poate fi utilizat metoda explicit (cnd sunt
specificate explicit cmpurile ce vor fi completate cu valorile din clauza VALUES) sau
metoda implicit (cnd nu se specific niciun cmp dar se cunoate structura tabelei i
cmpurile sunt completate cu valorile corespunztoare din clauza VALUES).
B) Modificarea datelor
Pentru modificarea valorilor existente ntr-un tabel se utilizeaz comanda
UPDATE care are urmtoarea sintax general:
UPDATE <nume tabel>
SET nume_coloan1 = expresie1,
nume_coloan2 = expresie2,
...
...
nume_coloann = expresien
[WHERE condiie]
Vom reveni asupra codului SQL.
2. INTEROGAREA BAZELOR DE DATE
2.1. Generaliti
Pentru utilizator, o interogare este o metod de a regsi anumite informaii
dintr-o baz de date, prin intermediul unei aplicaii de baze de date. Din punctul de
vedere al programatorului aplicaiei de baze de date, interogarea se exprim printr-o
comand echivalent expresiei de interogare, comand care se transmite sistemului
SGBD.

34

Din punct de vedere al sistemului de gestiune, o interogare este un program

(de exemplu, n limbajul SQL8) pe care l compileaz i apoi l execut. Ca orice
program, o interogare este prelucrat de ctre SGBD n mai multe faze: analiza
lexical, analiza sintactic i analiza semantic, pentru validarea interogrii, urmate de
generarea codului. De asemenea, dac exist mai multe soluii pentru aceeai
interogare, sistemul de gestiune selecteaz soluia optim.
Conceptual, subsistemul SGBD de prelucrare a interogrilor const din
urmtoarele componente:

Compilatorul de interogri, care efectueaz analiza lexical i sintactic a

interogrii; acesta valideaz din punct de vedere sintactic interogarea, adic verific
existena relaiilor, a vederilor, a indexurilor i a atributelor implicate n interogare i
utilizarea corect a acestora.

Optimizatorul de interogri, care efectueaz analiza semantic a interogrii i

selecteaz alternativa optim dintre mai multe soluii posibile de execuie a interogrii.

Generatorul de cod, care genereaz programul de execuie al interogrii,

conform optimizrilor efectuate.

Componenta de execuie (runtime), care execut programul interogrii.

Compilarea interogrii se realizeaz la fel ca orice compilare a programelor,
fr aspecte specifice sistemelor de baze de date. Optimizarea interogrilor este o
operaie specific sistemelor de gestiune i utilizeaz proprietile operaiilor relaionale
pentru a obine performane de execuie a interogrilor ct mai bune. Optimizarea este
efectuat de ctre SGBD, transparent, fr intervenia programatorului.
Interogarea (query) este operaia prin care se obin datele dorite dintr-o baz
de date, selectate conform unui anumit criteriu (condiie). Dat fiind c operaia de
interogare este cea mai important operaie de manevrare a datelor, de multe ori
limbajele de manevrare a datelor sunt denumite limbaje de interogare.
Pentru formularea conceptual a interogrilor n bazele de date relaionale sau dezvoltat dou limbaje abstracte de interogare: algebra relaional i calculul
relaional.

Algebra relaional (relational algebra) const dintr-o mulime de operaii care

au ca operanzi relaii, iar rezultatul este tot o relaie.

Calculul relaional (relational calculus) este bazat pe calculul predicatelor i

exprim o interogare formulnd o definiie a rezultatului dorit (de regul, o relaie)
printr-o expresie de calcul relaional.
Limbajele de interogare reale implementate n sistemele de baze de date
relaionale sunt limbaje definite pe baza unuia sau altuia din limbajele de interogare
abstracte, sau pe o combinaie a acestora. Astfel:

Limbajul SQL este n cea mai mare parte bazat pe algebra relaional, dar
mai conine i construcii derivate din calculul relaional.

Limbajul ISBL (Information System Base Language) al firmei IBM este bazat
n ntregime pe algebra relaional.

Limbajul QUEL al SGBD Ingres este bazat pe calculul relaional al tuplurilor.

Limbajul QBE (Query by Example), dezvoltat la firma IBM este bazat pe

calculul relaional al domeniilor.
Un limbaj de interogare real este denumit relaional complet dac
implementeaz toate operaiile prevzute de unul din limbajele de interogare abstracte.
n general, toate limbajele relaionale implementate n sistemele SGBD sunt limbaje
8

SQL (Structured Query Language) este un limbaj specializat pentru interogarea,

actualizarea si administrarea bazelor de date relationale. Ca sintaxa, instructiunile SQL
se termina cu ; (punct si virgula) iar parametrii din listele de parametri sunt separati prin
, (virgula). SQL fiind un limbaj structurat clauzele care compun instructiunile sale
trebuie sa respecte ordinea impusa de sintaxa.

35

relaionale mai mult dect complete, coninnd i operaii care nu sunt prevzute n
limbajele relaionale abstracte, ca de exemplu, efectuarea unor calcule aritmetice
asupra valorilor unor atribute (sum, medie, minim, maxim), funcii de tiprire a
relaiilor, etc.
Limbajul SQL este limbajul cel mai utilizat n sistemele relaionale.
2.2. Codul SQL
Ilustram
AssistRom.mdb:

codul

SQL

cu

ajutorul

unei

baze

de

date

Ms

Access,

Instructiunea SELECT
Efect:
Se returneaza informatia ceruta sub forma unui set de inregistrari.
Sintaxa:
SELECT [predicat] { * | tabel.* | [tabel.]camp1 [AS alias1] [, [tabel.]camp2
[AS alias2] [, ...]]}
FROM expresie_tabel [, ...] [IN baza_de_date_externa]
[WHERE... ]
[GROUP BY... ]
[HAVING... ]
[ORDER BY... ]
[WITH OWNERACCESS OPTION]
Instructiunea SELECT are urmatoarele parti:
predicat
36

este unul dintre urmatoarele predicate: ALL, DISTINCT, DISTINCTROW, sau TOP.
Predicatul folosit determina o restrictionare a numarului de inregistrari returnate. Daca
nu este specificat, se ia implicit predicatul ALL;
*(asterisc)
indica faptul ca trebuie selectate toate campurile din tabelele specificate;
tabel
numele tabelului care contine campurile care intereseaza pentru selectia inregistrarilor;
camp1, camp2
numele campurilor care contin datele ce trebuie returnate. Daca sunt indicate mai
multe campuri, atunci datele acestora sunt returnate conform ordinii din lista de
campuri;
alias1, alias2
nume de coloane care pot fi folosite ca antete pentru campuri in locul antetelor
respective din tabel;
expresie_tabel
o expresie care identifica unul sau mai multe tabele din care vor fi returnate date.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
baza_de_date_externa
numele BD care contine tabelul / tabelele specificate in expresie_tabel, daca acestea
nu fac parte din BD curenta;
Sintaxa minimala pentru instructiunea SELECT este:
SELECT campuri FROM tabel;
Clauzele WHERE,GROUP BY, HAVING, ORDER BY si WITH OWNERACCESS
OPTION au rolul de a organiza setul de inregistrari returnate si de a introduce restrictii
suplimentare asupra acestuia. Astfel,
daca trebuie eliminate inregistrarile duplicate sau afisate numai o parte dintre
inregistrari etc., atunci trebuie introdus un predicat adecvat: DISTINCTROW, TOPn
etc.,
daca trebuie afisate valorile unui camp atunci numele acestuia trebuie inserat dupa
verbul SELECT, in lista_de_campuri; daca mai multe campuri din tabele diferite au
acelasi nume ele atunci numele lor va fi precedat de numele tabelului,
daca interogarea se bazeaza pe un tabel si / sau interogare deja creata atunci
numele acestuia trebuie sa fie inclus in expresia_tabel a clauzei FROM,
daca inregistrarile returnate de interogare trebuie filtrate atunci criteriile de filtrare se
introduc prin clauza WHERE,
daca trebuie efectuata o grupare a inregistrarilor si o filtrare a inregistrarilor grupate
atunci campul sau campurile dupa care se grupeaza se introduc prin clauza GROUP
BY iar criteriile de filtrare prin clauza HAVING,
daca inregistrarile returnate de interogare trebuie sortate atunci campul-cheie de
sortare si ordinea de sortare se indica in clauza ORDER BY,
daca proprietarul BD se schimba atunci trebuie indicata noua valoare, Owners, in
clauza WITH_OWNERACCESS_OPTION.

37

Modul de lucru
Programul parcurge tabelul / tabelele specificate in parametrul expresie_tabel, extrage
coloanele indicate in parametrii camp1, camp2 etc., selecteaza inregistrarile care
verifica criteriul de selectie si sorteaza sau grupeaza inregistrarile rezultate in ordinea
specificata.
Observatie
Instructiunile SELECT este specifica interogarilor simple (de selectie); ea nu modifica
datele din BD. Verbul SELECT este, de obicei, primul cuvant dintr-o instructiune SQL.
Cele mai frecvent folosite instructiuni SQL sunt SELECT si SELECT INTO.
Exemple
Afisarea numelui si prenumelui clientilor firmei AsistRom
SELECT NumeClient, Prenume FROM Clienti;
Utilizarea asteriscului pentru a selecta toate campurile dintr-un tabel.
In exemplul de mai jos se selecteaza toate campurile din tabelul Clienti
SELECT * FROM Clienti;
Utilizarea operatorului . (punct) pentru cazul in care tabelele din clauza FROM contin
campuri cu acelasi nume. Atunci, toate campurile care apar in instructiunea SELECT
trebuie insotite de numele tabelului din care provin.
In exemplul de mai jos campul CodCentru apare si in tabelul Clienti si in tabelul
CentreCons; instructiunea SQL trebuie sa selecteze numele clientilor din tabelul
Clienti si denumirea completa a centrului din tabelul CentreCons (vezi codul SQL al
interogarii Q_SubQuery_Clienti_CentreCons din BD AsistRom )
SELECT
DISTINCTROW
Clienti.CodClient,
Clienti.NumeClient,
Clienti.Prenume,
(SELECT [NumeCentru] FROM [CentreCons]
WHERE [Clienti].[CodCentru] = [CentreCons].[CodCentru])
AS [Centrul de Consultanta]
FROM CentreCons INNER JOIN Clienti
ON CentreCons.CodCentru = Clienti.CodCentru;
Utilizarea clauzei AS pentru crearea in RecordSet (setul de inregistrari intoarse de
interogare) a unui nume de camp diferit de cel din tabel.
In exemplul de mai jos campul TelefonAcasa capata in RecordSet numele
NrTelefon
SELECT Clienti.TelefonAcasa AS NrTelefon FROM Clienti;
Aceasta manevra este recomandata mai ales in cazul utilizarii in interogare a functiilor
predefinite din categori Total sau a criteriilor care returneaza rezultate ambigui sau
duplicate. Clauza AS creeaza un nume alternativ pentru campulrezultat intors de
interogare. In exemplul de mai jos, clauza AS atribuie numele TotalNrClienti campului
in care se face numararea acestora
SELECT COUNT(CodClient) AS TotalNrClienti FROM Clienti;
Utilizarea clauzei AS pentru duplicarea unui camp in vederea efectuarii unor calcule.
In exemplul de mai jos, pretul actual al caietelor produse este returnat in campul
denumit CostActual iar in campul CostPropus este afisat noul pret al caietelor daca

38

pretul unitar creste cu 10% (vezi codul SQL al interogarii Q_AS_Produse din BD
AsistRom )
SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,
Produse.PretUnitar, Produse.Cantitate, [PretUnitar] * [Cantitate] AS Cost,
[Cost]*1.1 AS CostPropus FROM Produse;
In exemplul de mai jos sunt numarate produsele din tabelul Produse si este calculat
pretul unitar mediu si pretul unitar maxim (vezi Q_CountAvgMax_Produse din BD
AsistRom )
SELECT Count(*) AS NrTotalProduse, Avg(PretUnitar) AS [Pret Unitar
Mediu], Max([PretUnitar]) AS [Pret Unitar Maxim] FROM Produse;
Includerea unui text intre valorile numerice returnate.
In exemplul urmator sunt afisate pentru fiecare produs din tabelul Produse numele si
pretul sau unitar (aflate in campurile NumeProdus, respectiv PretUnitar), separate
de secventa are urmatorul pret unitar (vezi Q_ConcatText_Produse din BD
AsistRom )
SELECT NumeProdus, 'are urmatorul pret unitar,
PretUnitar
FROM
Produse;
Definirea unui filtru de selectie pentru inregistrarile returnate.
In exemplul urmator sunt afisate numele si prenumele clientilor absolventi ai
Universitatii din Bucuresti
SELECT [Prenume], [NumeClient] FROM [Clienti]
WHERE [Studii] = "Univ.Bucuresti";
In exemplul urmator sunt afisate numele si prenumele clientilor din tabelul Clienti care
au apelat la un centru de consultanta al carui cod se afla printre codurile din formularul
deschis CentreConsNoi
SELECT [Prenume], [NumeClient] FROM [Clienti]
WHERE [CodCentru] = Forms![CentreConsNoi]![CodCentru];
Selectarea inregistrarilor in vederea efectuarii unui calcul.
In exemplul urmator este calculat pretul unitar mediu numai pentru produsele al caror
pret unitar depaseste valoarea 5; acest pret mediu este afisat in campul nou creat
numit PretulUnitarMediuPeste5
SELECT Avg([PretUnitar]) AS [PretulUnitarMediuPeste5]
FROM [Produse] WHERE [PretUnitar] > 5;
Gruparea inregistrarilor in vederea efectuarii unui calcul la nivelul fiecarui grup de
inregistrari, dupa ce au fost eliminate inregistarile care nu verifica un criteriu de selectie
anumit.
In exemplul urmator este calculat pretul unitar mediu al produselor al caror pret unitar
depaseste
valoarea
5
la
nivelul
fiecarei
firme
(vezi
Q_GroupBy_Where_Produse_Firma din BD AsistRom )
SELECT Produse.CodFirma, Count(Produse.CodFirma) AS NumarProduse,
Avg(Produse.PretUnitar) AS PretulUnitarMediuPeste5 FROM Produse
WHERE

(((Produse.PretUnitar) > 5))

GROUP BY

Produse.CodFirma;

Gruparea inregistrarilor in vederea efectuarii unui calcul la nivelul fiecarui grup de

inregistrari si efectuarea acestui calcul numai pentru grupurile de inregistrari care
verifica un criteriu de selectie anumit.

39

In exemplul urmator este calculat numarul total de produse fabricat de fiecare firma,
numai daca firma respectiva produce cel putin doua sortimente distincte (vezi
Q_GroupBy_Having_Produse din BD AsistRom )
SELECT
Produse.CodFirma,
Count([Produse].[CodFirma])
AS
NumarProduse
FROM Produse
GROUP BY Produse.CodFirma
HAVING Count ([CodFirma]) >= 2;
Clauza FROM
Efect
Specifica tabelele sau interogarile care contin campurile enumerate in instructiunea
SQL.
Sintaxa
SELECT lista_de_campuri
FROM expresie_tabel [, ...] [IN baza_de_date_externa]
O instructiune SELECT care foloseste clauza FROM are urmatoarele parti:
lista_de_campuri
numele campurilor (inclusiv alias-uri) folosite in interogare si, eventual: functii
predefinite SQL, predicate de selectie SQL (ALL, DISTINCT, DISTINCTROW, or TOP)
sau alte optiuni ale instructiunii SELECT
expresie_tabel
o expresie care identifica unul sau mai multe tabele din care vor fi returnate date.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
baza_de_date_externa
drumul complet catre BD externa care contine toate tabelele din expresia_tabel.
Observatii
Clauza FROM este obligatorie pentru orice instructiune SELECT;
Ordinea numelor tabelelor in expresia-tabel nu este semnificativa;
Exemple
Afisarea numelui si prenumelui clientilor din tabelul Clienti
SELECT Prenume, NumeClient
FROM Clienti;
Afisarea tuturor informatiilor despre clienti (deci a tuturor campurilor din tabelul
Clienti)
SELECT * FROM Clienti;
Numararea clientilor (deci a valorilor din campul CodCentru din tabelul Clienti);
rezultatul este depus in campul NrTotalClienti
SELECT Count(CodCentru) AS NrTotalClienti FROM Clienti;

40

Calculul noului pret unitar al produselor firmelor-client in urma aplicarii unei cresteri de
10% (in tabelul Produse valorile din campul PretUnitar preturile actuale raman
neschimbate)
SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,
Produse.Cantitate, Produse.PretUnitar AS PretActual,
PretUnitar * 1.1 AS PretPropus FROM Produse;

Evident interogarea poate fi parametrizata si poate returna diferite preturi unitare

pentru diferite procente (vezi interogarea QProduse_From din BD AsistRom )
SELECT Produse.CodFirma, Produse.CodProdus, Produse.NumeProdus,
Produse.Cantitate, Produse.PretUnitar AS PretActual, [Procent] AS
[P%], [PretUnitar] * [Procent] AS PretPropus
FROM Produse WHERE ((([Procent]) = [Indicati procentul]));
Inserarea unui text explicativ intre
antetele unor campuri
SELECT Firma.NumeFirma, 'are ',
Firma.NrSalariati,
'salariati' FROM
Firma;

Clauza IN
Efect
Identifica tabele in orice BD externa creata cu o aplicatie compatibila cu MS Access:
FoxPro, dBASE etc.
Sintaxa pentru identificarea unui tabel-destinatie
[SELECT | INSERT] INTO destinatie IN
{drum | ["drum" "tip"] | ["" [tip; DATABASE = drum]]}
Sintaxa pentru identificarea unui tabel-sursa
FROM expresie_tabel IN
{drum| ["drum" "tip"] | ["" [tip; DATABASE = drum]]}
O instructiune SELECT care contine o clauza IN are urmatoarele parti:
destinatie
numele bazei de date externe in care sunt inserate informatiile;
expresie_tabel
o expresie care identifica unul sau mai multe tabele din care vor fi returnate date.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o

41

combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
drum
drumul complet catre directorul sau fisierul care contine tabelul;
tip
extensia specifica aplicatiei cu care a fost creata BD externa, daca este alta decat MS
Access.
Predicatele ALL, DISTINCT, DISTINCTROW, TOP
Efect
Specifica inregistrarile selectate de interogarile SQL
Sintaxa
SELECT [ALL | DISTINCT | DISTINCTROW | [TOP n [PERCENT]]]
FROM tabel
O instructiune SELECT care foloseste aceste predicate are urmatoarele parti:
ALL
Este predicatul implicit. Programul selecteaza toate inregistrarile care indeplinesc
criteriul specificat in instructiunea SQL.
Urmatoarele instructiuni SQL sunt echivalente si returneaza toate inregistrarile din
tabelul CentreCons (ordonate dupa valorile campului CodCentru)
SELECT ALL * FROM CentreCons ORDER BY CodCentru;
SELECT * FROM CentreCons ORDER BY CodCentru;
DISTINCT
Omite inregistrarile care contin aceleasi date in campurile selectate (pentru a fi incluse
in RecordSet, valorile campului din instructiunea SELECT trebuie sa fie unice; daca
apar mai multe campuri in instructiunea SELECT atunci combinatia valorilor lor pentru
fiecare inregistrare trebuie sa fie unica).
De exemplu, trebuie verificat daca fiecare centru de consultanta este activ (are cel
putin un client). Vom folosi urmatoarele premize: in tabelul Clienti exista un camp
numit CodCentru care contine codul centrului de consultanta la care s-a inregistrat
clientul (deci, vom baza interogarea pe tabelul Clienti); o inregistrare dintr-un tabel
este considerata fara duplicate (unica) numai in cazul in care combinatia valorilor din
toate campurile sale este unica la nivelul intregului tabel (deci, dintre toate campurile
tabelului Clienti vom include in interogare numai campul CodCentru); un camp dintrun tabel este considerat cu valori unice numai daca oricare dintre valorile sale nu se
repeta in nici-o inregistrare din tabel (deci, vom specifica in instructiunea SELECT
predicatul DISTINCT). Prin urmare, se foloseste codul:
SELECT DISTINCT CodCentru FROM Clienti;
Daca se elimina predicatul DISTINCT atunci sunt returnate toate valorile (cu duplicate
cu tot) din campul CodCentru.
DISTINCTROW
Omite inregistrarile duplicate, nu numai pe cele care contin campuri duplicate.
Problema de mai sus, listarea centrelor de consultanta care au cel putin un client poate
fi rezolvata mai complicat - si astfel: stiind ca tabelul CentreCons nu contine
inregistrari duplicate dar tabelul Clienti contine, se creeaza o interogare pe baza
tabelelor CentreCons si Clienti si se foloseste o instructiune SELECT cu predicatul
DISTINCTROW, adica
SELECT DISTINCTROW NumeCentru
FROM Clienti INNER JOIN CentreCons
ON Clienti.CodCentru = CentreCons.CodCentru
42

ORDER BY NumeCentru;
Daca se omite parametrul DISTINCTROW, interogarea produce, pentru fiecare centru,
atatea inregistrari cati clienti are centrul respectiv.
TOP n [PERCENT]
Returneaza un anume numar de inregistrari aflate pe primele sau pe ultimele locuri ale
unui set de inregistrari specificate intr-o clauza ORDER BY.
Sa presupunem ca trebuie returnate primele 2 firme din Bucuresti care au cel mai mare
numar de angajati (vezi QFirma_Topn din BD AsistRom )
SELECT TOP 2
NumeFirma, CodOras, NrSalariati FROM Firma
WHERE CodOras = "B" ORDER BY NrSalariati DESC;
Sa presupunem ca trebuie returnate primele 30% firme care au cel mai mare numar de
angajati
SELECT TOP 30 PERCENT
Firma.NumeFirma, Firma.NrSalariati FROM Firma
ORDER BY Firma.NrSalariati DESC;
Clauza GROUP BY
Efect
Combina intr-o inregistrare unica toate inregistrarile care au aceeasi valoare in
campurile specificate in instructiunea SELECT; daca instructiunea SELECT contine si
o functie predefinita SQL (SUM, COUNT etc.) este inclusa valoarea acesteia pentru
fiecare dintre inregistrarile astfel create.
Sintaxa
SELECT lista_de_campuri FROM expresie_tabel
[WHERE criterii_de_selectie]
GROUP BY lista_campurilor_grupate
O instructiune SELECT care contine clauza GROUP BY are urmatoarele parti:
lista_de_campuri
reprezinta numele (inclusiv alias-urile) campurilor din tabelul de baza din care se extrag
date si, eventual: functiile predefinite SQL, predicatele de selectie (ALL, DISTINCT
etc.) si alte optiuni ale instructiunii SELECT;
expresie_tabel
o expresie care identifica unul sau mai multe tabele ale caror date vor fi actualizate.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
criterii_de_selectie
reprezinta criteriile de selectie; daca instructiunea SELECT comporta si o clauza
WHERE atunci programul BD Microsoft Jet grupeaza valorile numai dupa ce aplica
criteriile WHERE asupra inregistrarilor;
lista_campurilor_grupate
consta din numele a maximum 10 campuri folosite pentru gruparea inregistrarilor;
ordinea de grupare este ordinea in care apar campurile in grila QBE.
Exemple
43

Se creeaza o interogare simpla pe baza tabelului Produse fara a se introduce in grila

QBE nici un camp se comuta in modul SQL View si se introduc pe rand instructiunile
SQL de mai jos:
Calculul pretului unitar mediu al tuturor caietelor produse de aceeasi firma
se selecteaza campul CodFirma se aplica functia predefinita Avg pretului unitar
se grupeaza inregistrarile dupa codul firmei
SELECT
CodFirma,
Avg(PretUnitar)
AS
AvgOfPretUnitar
FROM
Produse
GROUP BY CodFirma;
Calculul pretului unitar maxim pentru produsele din fiecare categorie
se selecteaza campul CodProdus se aplica
functia predefinita Max pretului unitar se
grupeaza dupa codul produsului
SELECT CodProdus, Max(PretUnitar)
AS MaxOfPretUnitar
FROM
Produse
GROUP BY
CodProdus;
Calculul numarului de produse fabricate de fiecare firma
se selecteaza campul CodFirma se aplica functia predefinita Count campului
CodProdus se grupeaza dupa codul firmei
SELECT CodFirma, Count(CodProdus) AS CountOfCodProdus
FROM Produse GROUP BY CodFirma;
Clauza WHERE
Efect
Specifica inregistrarile din tabelele enumerate in clauza FROM care vor fi afectate de o
instructiune SELECT, UPDATE sau DELETE.
Sintaxa
SELECT lista_de_campuri FROM expresie_tabel
WHERE criterii_de_selectie
O instructiune SELECT care comporta o clauza WHERE are urmatoarele parti:
lista_de_campuri
numele campurilor (inclusiv alias-uri) folosite in interogare si, eventual: functii
predefinite SQL, predicate de selectie SQL (ALL, DISTINCT, DISTINCTROW, or TOP)
sau alte optiuni ale instructiunii SELECT;
expresie_tabel
o expresie care identifica unul sau mai multe tabele ale caror date vor fi actualizate.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
criterii_de_selectie
o expresie pe care trebuie s-o satisfaca o inregistrare pentru a fi returnata in dynaset;
ea poate contine pana la 40 de operanzi combinati prin operatori logici.

Exemple

44

Afisarea firmelor care au mai mult de 50 salariati

SELECT NumeFirma, NrSalariati FROM Firma
WHERE NrSalariati >= 50;
Afisarea firmelor infiintate in anii 1996 si 1997
SELECT * FROM Firma
WHERE Start BETWEEN #01/01/96# AND #12/31/97# ;
 Asa cum am subliniat si mai sus, specificarea datei calendaristice din acest
exemplu convine intr-o BD creata in S.U.A; intr-o BD creata in Marea Britanie data
trebuie specificata astfel: #31/12/96# . Astfel de dificultati pot fi ocolite prin utilizarea
functiei predefinite DateValue care face automat conversiile impuse de setarile
internationale:
SELECT * FROM Firma
WHERE Start BETWEEN DateValue(#01/01/96#) AND
DateValue(#12/31/97#);
Clauza HAVING
Efect
Specifica inregistrarile grupate care vor fi afisate printr-o instructiune SELECT care
contine o clauza GROUP BY. Dupa ce clauza GROUP BY grupeaza inregistrarile,
clauza HAVING afiseaza numai acele inregistrari grupate care satisfac criteriul
introdus.
Sintaxa
SELECT
[WHERE
GROUP
HAVING

lista_de_campuri FROM expresie_tabel

criterii_de_selectie]
BY lista_campurilor_grupate
criterii_de_selectie_grup;

O instructiune SELECT care contine clauza GROUP BY are urmatoarele parti:

lista_de_campuri
reprezinta numele (inclusiv alias-urile) campurilor din tabelul de baza din care se extrag
date si, eventual: functiile predefinite SQL, predicatele de selectie (ALL, DISTINCT
etc.) si alte optiuni ale instructiunii SELECT;
expresie_tabel
o expresie care identifica unul sau mai multe tabele ale caror date vor fi actualizate.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
criterii_de_selectie
o expresie pe care trebuie s-o satisfaca o inregistrare pentru a fi returnata in dynaset;
ea poate contine pana la 40 de operanzi combinati prin operatori logici; daca
instructiunea SELECT comporta si o clauza WHERE atunci programul BD Microsoft Jet
grupeaza valorile numai dupa ce aplica criteriile WHERE asupra inregistrarilor;
lista_campurilor_grupate
consta din numele a maximum 10 campuri folosite pentru gruparea inregistrarilor;
ordinea de grupare este ordinea in care apar campurile in grila QBE;
criterii_de_selectie_grup
reprezinta criteriile pe care trebuie sa le satisfaca o inregistrare grupata pentru a fi
afisata; aceasta expresie poate contine pana la 40 de operanzi combinati prin operatori
logici.

Observatie
45

Clauza HAVING este optionala.

Exemple
Afisarea preturilor unitare maxime pe fiecare produs, indiferent de firma producatoare,
daca acest pret nu depaseste valoarea 5 iar firma este o asociatie familiala (codul ei
incepe cu A)
se creeaza o interogare pe baza tabelului Produse se selecteaza produsele prin
codul lor (precum si firma producatoare) se aplica functia predefinita Max datelor
privind pretul unitar se grupeaza inregistrarile pe produse se afiseaza numai
produsele cu pretul unitar maxim mai mic decat 5 si realizate de firme al caror cod
incepe cu litera A
SELECT Produse.CodProdus, Max(Produse.PretUnitar) AS PretMaxUnitar
FROM Produse
WHERE (((Left([CodFirma],1)) = "A"))
GROUP BY Produse.CodProdus
HAVING (((Max(Produse.PretUnitar)) <= 5));
Afisarea centrelor de consultanta care au cel putin un client nou
se creeaza o interogare pe baza tabelului Clienti se selecteaza centrele de
consultanta prin campul de cod se numara clientii noi prin insumarea valorilor
booleene din campul ClientNou (constantele predefinite TRUE / FALSE fiind
convertite la 1 / 0) se grupeaza pe centre de consultanta se afiseaza numai
inregistrarile grupate care au o valoare nenula in campul ClientNou
SELECT

CodCentru,

Sum(ClientNou)

AS

SumtOfClientNou

FROM

Clienti
GROUP BY CodCentru
HAVING Sum(ClientNou) <> 0
Clauza ORDER BY
Efect
Sorteaza, crescator sau descrescator, dupa unul sau mai multe campuri, inregistrarile
returnate de o interogare.
Sintaxa
SELECT lista_de_campuri FROM expresie_tabel
WHERE criterii_de_selectie
[ORDER BY camp1 [ASC | DESC ][, camp2 [ASC | DESC ]][, ...]]]
O instructiune SELECT care contine clauza ORDER BY are urmatoarele parti:
lista_de_campuri
reprezinta numele (inclusiv alias-urile) campurilor din tabelul de baza din care se extrag
date si, eventual: functiile predefinite SQL, predicatele de selectie (ALL, DISTINCT
etc.) si alte optiuni ale instructiunii SELECT;
expresie_tabel
o expresie care identifica unul sau mai multe tabele ale caror date vor fi actualizate.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
criterii_de_selectie
o expresie pe care trebuie s-o satisfaca o inregistrare pentru a fi returnata in dynaset;
ea poate contine pana la 40 de operanzi combinati prin operatori logici; daca

46

instructiunea SELECT comporta si o clauza WHERE atunci programul BD Microsoft Jet

grupeaza valorile numai dupa ce aplica criteriile WHERE asupra inregistrarilor;
camp1, camp2
numele campurilor care servesc drept chei de sortare.
Exemple
Afisarea clientilor firmei AsistRom in ordine alfabetica
SELECT Prenume, NumeClient FROM Clienti
ORDER BY NumeClient ASC;
Afisarea firmelor si clientilor firmei AsistRom in ordinea alfabetica a centrelor de
consultanta si apoi a numelui de familie
SELECT Prenume, NumeClient, CodCentru, CodFirma FROM Clienti
ORDER BY CodCentru ASC, NumeClient ASC;
Evidentierea centrelor de consultanta cu cea mai buna activitate, afisarea centrelor
de consultanta in ordinea descrescatoare a numarului de clienti
SELECT
Clienti.CodCentru,
Count(Clienti.CodCentru) AS NrClienti
FROM Clienti GROUP BY Clienti.CodCentru
ORDER BY Count(Clienti.CodCentru) DESC;
Operatia INNER JOIN
Efect
Combina inregistrarile din 2 tabele corelate daca au aceeasi valoare in campul de
legatura.
Sintaxa minimala
FROM
tabel1
tabel2.camp2

INNER JOIN

tabel2

ON

tabel1.camp1

oper_relat

Operatia INNER JOIN are urmatoarele parti:

tabel1, tabel2
numele tabelelor ale caror inregistrari sunt corelate;
camp1, camp2
numele campurilor de legatura; daca nu sunt numerice ele trebuie sa fie de acelasi tip
si sa contina acelasi fel de date dar nu trebuie sa aiba neaparat acelasi nume;
oper_relat
oricare dintre operatorii relationali: "=," "<," ">," "<=," ">=," sau "<>."
Observatii
Se poate folosi o operatie INNER JOIN in orice clauza FROM. Acest tip de asociere,
asocierea interna, este cel mai comun. De exemplu, daca trebuie afisati numai
clientii care s-au prezentat la un centru de consultanta, trebuie aplicata o operatie
INNER JOIN pentru a crea o asociere interna. Daca trebuie afisate toate centrele
de consultanta, indiferent daca au sau nu clienti, respectiv daca trebuie afisati toti
clientii indiferent daca s-au prezentat deja la un centru de consultanta sau nu,
trebuie aplicata o operatie LEFT JOIN respectiv RIGHT JOIN pentru a crea o
asociere externa.
Operatia INNER JOIN nu poate fi aplicata campurilor de tip Memo sau OLE Object si
nici campurilor numerice de tip diferit: unul Single, celalalt Double.
Exemple

47

Asocierea produselor cu numele patronului firmei producatoare pe baza campului

CodFirma, prezent in ambele tabele (intre care nu exista o corelatie stabilita la nivelul
BD) si gruparea acestora pe clienti si pe produse
SELECT
Produse.NumeProdus,
Clienti.NumeClient
FROM Produse INNER JOIN Clienti
ON Produse.CodFirma = Clienti.CodFirma
GROUP
BY
Clienti.NumeClient,
Produse.NumeProdus;
 Campul de legatura (aiciCodFirma) nu apare in
dynaset; pentru a-l afisa el trebuie inclus in lista de
campuri a instructiunii SELECT alaturi de celelalte
campuri.
Sintaxa operatiei pentru mai multe clauze ON
SELECT lista_campuri FROM tabel1 INNER JOIN tabel2
ON tabel1.camp1 oper_relat tabel2.camp1 AND
ON tabel1.camp2 oper_relat tabel2.camp2) OR
ON tabel1.camp3 oper_relat tabel2.camp3)];
Sintaxa operatiei pentru mai multe instructiuni JOIN imbricate
SELECT lista_campuri FROM tabel1 INNER JOIN
(tabel2 INNER JOIN [( ]tabel3
[INNER JOIN [( ]tabelx [INNER JOIN ...)]
ON tabel3.camp3 oper_relat tabelx.campx)]
ON tabel2.camp2 oper_relat tabel3.camp3)
ON tabel1.camp1 oper_relat tabel2.camp2;
Observatie
O asociere externa (RIGHT JOIN sau LEFT JOIN) poate fi imbricata intr-o asociere
interna, dar invers nu.

Exemplu
Afisarea numelui complet al clientilor,
al firmei si al centrului consultat
SELECT Clienti.Prenume & " "
& Clienti.NumeClient AS [Nume
Client],
Firma.NumeFirma
AS
[Nume
Firma],
CentreCons.NumeCentru
AS
[Nume Centru Cons]
FROM (CentreCons
INNER JOIN Clienti ON CentreCons.CodCentru = Clienti.CodCentru)
INNER JOIN Firma ON Clienti.CodFirma = Firma.CodFirma;
Operatiile LEFT JOIN si RIGHT JOIN

48

Efect
Combina inregistrarile din 2 tabele corelate folosite intr-o clauza FROM.
Sintaxa
FROM tabel1 [ LEFT | RIGHT ] JOIN tabel2
ON tabel1.camp1 oper_relat tabel2.camp2
Operatia LEFT | RIGHT JOIN are urmatoarele parti:
tabel1, tabel2
numele tabelelor ale caror inregistrari sunt corelate;
camp1, camp2
numele campurilor de legatura; daca nu sunt numerice ele trebuie sa fie de acelasi tip
si sa contina acelasi fel de date dar nu trebuie sa aiba neaparat acelasi nume;
oper_relat
oricare dintre operatorii relationali: "=," "<," ">," "<=," ">=," sau "<>."
Exemple
Afisarea tuturor firmelor, fie ca au produse fie ca nu au
(relatia 1 m se bazeaza pe campul CodFirma
SELECT
DISTINCT
Firma.NumeFirma,
Produse.NumeProdus FROM
Firma
LEFTJOIN
Produse
ON
Firma.CodFirma
=
Produse.CodFirma;
Afisarea tuturor produselor, fie ca este mentionata
firma producatoare fie ca nu (aceeasi relatie ca mai
sus)
SELECT
DISTINCT
Firma.NumeFirma,
Produse.NumeProdus FROM Firma
RIGHT JOIN Produse ON Firma.CodFirma = Produse.CodFirma ORDER BY
NumeFirma, NumeProdus;
Interogarea parametrizata
Definitie O interogare parametrizata este o interogare a carei executie consta in
afisarea unei casete-dialog predefinite in care utilizatorul poate introduce criteriul de
selectie sau valoarea care trebuie sa apara intr-un camp. Se poate folosi aceasta
facilitate si pentru criterii complexe: de exemplu, se poate crea o interogare
parametrizata prin care sa se afiseze inregistrarile a caror data calendaristica este
cuprinsa intre anumite limite.
Interogarile parametrizate sunt comode pentru construirea formularelor si rapoartelor.
De exemplu, un raport lunar al incasarilor se poate baza pe o interogare parametrizata;
cand se da comanda de listare a raportului, SGBD afiseaza caseta-dialog solicitand
luna la care trebuie sa se refere raportul; utilizatorul introduce informatia respectiva si
raportul corespunzator lunii este listat.
Pentru parametrizarea interogarilor cu criterii complexe se procedeaza analog, SGBD
afisand atatea casete-dialog cate ii sunt necesare pentru stabilirea criteriului de
interogare. Sa presupunem ca trebuie afisati clientii ai caror firme au fost infiintate intre
1995 si 1997. Pentru aceasta se creeaza mai intai o interogare simpla pe baza
tabelului Firma; in linia Criteria a campului Start se introduce criteriul parametrizat
Between [Data initiala:] And [Data finala:]; cand se executa interogarea se tasteaza in
prima caseta-dialog valoarea 1/1/95 (1 ianuarie 1995) iar in a doua caseta-dialog
valoarea 12/31/96 (31 decembrie 1996)
49

Tipuri de date SQL

SGBD defineste urmatoarele 13 tipuri de date primare pentru a fi folosite in codul SQL
(cu utilitate deosebita in crearea interogarilor parametrizate).
Tip de data
BINARY
BIT
TEXT
BYTE
COUNTER

SHORT
LONG
CURRENCY
SINGLE

DOUBLE

DATETIME
(vezi DOUBLE)
LONGTEXT
LONGBINARY
GUID

Memorare
1 caracter
pe byte
1 byte

Continutul campului de momorie de acest tip

Orice tip de data; nu necesita nici o conversie;
datele apar asa cum sunt introduse
Valori binare;
campuri care nu pot contine decat una din 2 valori
1 caracter 0 pana la 255 caractere
pe byte
1 byte
0 n 255
Un numar intreg pe care programul BD Microsoft Jet il
4 bytes
mareste automat cu o unitate pentru fiecare inregistrare
nou introdusa intr-un tabel;
corespunde tipului de data Long al campurilor din tabele
2 bytes
- 32,768 n 32,767
4 bytes
- 2,147,483,648 n 2,147,483,647
8 bytes
9.5 * 10 ** 15 x 9.5 * 10 ** 15
4 bytes
Un real x in virgula mobila simpla precizie,
- - 3,40 E 38 x - - 1,40 E -45, daca x <0
1,40 E 45 x 3,40 E 38, daca x 0
8 bytes
Un real x in virgula mobila dubla precizie,
- 1.79 E 308 x - 4.94 E 324, daca x<0
4.94 E 324 x 1.79 E 308, daca x 0
8 bytes
O ora sau o data calendaristica cuprinsa intre anii 100 si
9999
1 caracter 0 pana la 1.2 gigabytes
pe byte
Dupa caz
0 pana la 1.2 gigabytes (pentru obiecte OLE)
128 bits
Un numar de identificare unic folosit in apelul procedurilor
memorate pe server

Declaratia PARAMETERS
Efect
Specifica numele si tipul de date al fiecarui parametru dintr-o interogare parametrizata.
Sintaxa
PARAMETERS nume tip_de_data [, nume tip_de_data [, ...]]
O declaratie PARAMETERS are urmatoarele parti:
nume
numele parametrului. El este asignat proprietatii Name a obiectului si folosit pentru
identificarea parametrului respectiv in colectia Parameters. Acest nume apare in
caseta-dialog creata si afisata de SGBD la executarea interogarii parametrizate. De
aceea textele cu spatii trebuie incluse in paranteze drepte;
tip_de_data
un tip de data recunoscut de program.
Exemple
Declararea unei liste de parametri
50

PARAMETERS [Capital Social] Single, [Data Infiintarii Firmei] DateTime;

Utilizarea parametrilor in clauzele WHERE si HAVING (vezi interogarea
Qfirma_ParametersWH din BD AsistRom )
PARAMETERS [Capital Social] Single, [Data Infiintarii Firmei] DateTime;
SELECT NumeFirma, Capital FROM Firma
WHERE Capital > [Capital Social] AND Start >= [Data Infiintarii Firmei];
Afisarea tuturor clientilor fiecarui centru de consultanta
PARAMETERS [Tastati codul centrului, ASE, POLI, CRV sau TIM:] Text;
SELECT * FROM Clienti
WHERE CodCentru = [Tastati codul centrului, ASE, POLI, CRV sau TIM:];
Afisarea produselor in functie de codul categoriei din care fac parte
PARAMETERS [Dati codul categoriei:] Value;
SELECT CodCategorie, NumeProdus, Count([Comenzi].CodComanda)

AS

Tally
FROM Produse INNER JOIN [Comenzi]
ON Produse.CodProdus = [Comenzi].CodProdus
GROUP BY CodCategorie, NumeProdus
HAVING CodCategorie = [Dati codul categoriei:];
Interogarea de tip tabel intersectat (Crosstab Query)
Definitie O interogare de tip tabel intersectat sintetizeaza datele in mod cu totul diferit
fata de o interogarea simpla (de selectie) desi afiseaza rezultatul sub forma unei foi de
date. Ea este tot o interogare pentru calcule, dar acestea sunt mai complexe, deoarece
datele campului sunt grupate dupa 2 criterii simultan. De exemplu, daca trebuie
numarati clientii in functie de subiectul solicitat (plan de afaceri, asistenta etc.) si de
consultantul solicitat atunci o interogare de selectie ar duplica in mod inutil informatia,
si asa greu de urmarit.
O interogare Crosstab procedeaza astfel:
efectueaza calculul dorit (sumare, numarare, valoare medie etc.) asupra datelor din
campul corespunzator din tabelul de baza (aici campul CodClient din tabelul
Consultante); vom numi acest camp camp principal,
identifica cele doua campuri ale caror valori distincte la nivelul fiecarui camp vor
deveni valorile celor doua criterii astfel: valorile distincte ale primului camp devin
antete de coloane, valorile distincte ale celui de-al doilea camp devin etichete de
linii (aici, valorile campului Subiect : Asistenta, Consultanta, PlanDeAfaceri,
respectiv valorile campului CodConsultant : AZ, DM, IU, MS); vom numi
aceste campuri camp-antete respectiv camp-etichete,
afiseaza la intersectia liniei i cu coloana j rezultatul care verifica valoarea din eticheta
liniei i si valoarea din antetul coloanei j (aici, la intersectia liniei AZ cu coloana
Asistenta este afisat numarul clientilor care au solicitat Asistenta consultantului
AZ, de exemplu).
 Rezultatul obtinut cu o interogare Crosstab se poate obtine mai simplu cu ajutorul
unei tabele pivot din Ms Excel, importata sub forma unui tabel in BD Access. Pentru
crearea tabelei pivot se poate apela procedura de asistenta PivotTable Wizard.
In concluzie, o interogare Crosstab genereaza grupuri imbricate de inregistrari; ea are
nevoie de cel putin 3 campuri: unul pentru efectuarea calculelor, unul pentru antetele
de coloane si unul, doua sau trei campuri pentru etichetele de linii. Evident, este

51

preferabil ca in campul-antete sa existe un numar mic de valori distincte, altfel

rezultatele interogarii sunt greu de inteles.
Sintaxa instructiunii TRANSFORM este
TRANSFORM functie_predefinita_Totals SELECT_clauze
PIVOT camp_pivot [IN (lista_de_valori)];
unde:
functie_predefinita_Totals
este una dintre cele 9 functii din categoria Total; argumentul ei este numele campului
principal din interogarea Crosstab,
clauze
reprezinta clauzele dintr-o instructiune SELECT obisnuita
camp_pivot
reprezinta campul-antete,
lista_de_valori
reprezinta o lista optionala de valori literale de utilizat ca antete de coloana atunci cand
nu toate valorile din campul-antete convin sau cand ordinea alfanumerica de afisare a
lor nu convine.
Exemplu
Codul SQL al interogarii Crosstab este:
TRANSFORM Count(Consultante.CodClient) AS [The Value]
SELECT Consultante.CodConsultant, Count(Consultante.CodClient)
AS [Total Of CodClient]
FROM Consultante GROUP BY Consultante.CodConsultant
PIVOT Consultante.Subiect;
Interogarile actiune
Definitie O interogare-actiune este o interogare care modifica mai multe inregistrari
printr-o singura operatie (nu determina afisarea unor informatii pe ecran ci numai
modificarea datelor primare depuse in tabelele BD). Prin urmare, interogarile-actiune
nu modifica structura tabelelor, ci numai informatia continuta de acestea.
Clasificare
Exista 4 tipuri de interogari-actiune:
interogarea Update (Actualizare): modifica valorile din campul specificat intr-un tabel
sau in mai multe tabele;
interogarea MakeTable (CreareTabel): creeaza un tabel nou cu ajutorul unei parti
sau a tuturor inregistrarilor dintr-un tabel sau din mai multe tabele;
interogarea Append (Adaugare): adauga un grup de inregistrari aflate intr-un tabel
sau in mai multe tabele la baza unui tabel sau a mai multor tabele;
interogarea Delete (Stergere): sterge un grup de inregistrari dintr-un tabel sau din
mai multe tabele simultan.
Interogarile-actiune trebuie folosite ori de cate ori trebuie gestionata o selectie bine
definita de inregistrari printr-o singura manevra. Rezultatul obtinut prin utilizarea
interogarilor-actiune poate fi generat si printr-un program VBA care sa parcurga fiecare
inregistrare din tabel / BD, sa verifice indeplinirea unei conditii specificate si sa execute
actiunea respectiva (adaugare, stergere etc.) in functie de indeplinirea sau nu a
conditiei respective (asa cum procedeaza de altfel toate SGBD care nu dispun de
facilitati SQL).
Observatii
Executarea unei interogari-actiune poate fi intrerupta prin comanda CTRL + BREAK.
52

Interogarea Update (Actualizare)

Efect
Determina modificarea valorilor din campul specificat aflat intr-un tabel sau in mai
multe tabele. Noua valoare poate sa se bazeze pe continutul curent al campului de
modificat (sau al altor campuri) sau poate fi o constanta literala. De exemplu, pot fi
majorate cu 10% preturile tuturor produselor din tabelul Produse sau pot fi setate
toate pe valoarea 5.
Utilizare
Actualizarea unui numar mare de campuri aflate in acelasi tabel.
Actualizarea unor campuri care contin aceeasi informatie, aflate in tabele asociate.
Sintaxa instructiunii UPDATE
UPDATE expresie_tabel SET lista_de_valori
WHERE criterii_de_selectie;
unde:
expresie_tabel
o expresie care identifica unul sau mai multe tabele ale caror date vor fi actualizate.
Expresia poate fi un nume unic de tabel, numele unei interogari deja salvate sau o
combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere: INNER JOIN, LEFT
JOIN, sau RIGHT JOIN;
lista_de_valori
o expresie formata din numele campurilor de actualizat si valorile de actualizare
asociate fiecaruia (constante sau expresii)
criterii_de_selectie
o expresie pe care trebuie s-o satisfaca o inregistrare pentru a fi actualizata; ea poate
contine pana la 40 de operanzi combinati prin operatori logici. Numai inregistrarile care
satisfac criteriile de selectie vor fi actualizate.
O interogare Update actioneaza si asupra tabelelor asociate cu tabelele pe care
este proiectata sa le actualizeze, daca optiunea Cascade Update Related Fields a fost
selectata.
 Interogarea Update nu genereaza un dynaset care sa poata fi consultat inaintea
executarii interogarii (o interogare Update se poate afisa numai in modul SQL View,
pentru a introduce codul SQL al interogarii, sau in modul Design View, pentru a defini
interogarea in grila QBE si pentru a o executa). Operatia de actualizare poate fi
intrerupta (CTRL + BREAK) dar nu poate fi anulata. Ca atare, examinarea
inregistrarilor selectate pentru actualizare inainte de efectuarea operatiei reprezinta
ultima posibilitate de corectare a unor eventuale erori. Informatia anterioara poate fi
recuperata numai daca s-au facut copii de siguranta ale tabelelor implicate in operatia
de actualizare sau chiar ale intregii BD (cazul actualizarii tabelelor asociate). O alta
metoda de prevenire a actualizarilor eronate este crearea in prealabil a unei interogari
de selectie care sa contina inregistrarile de modificat.
Exemple
Actualizarea mai multor campuri simultan.
De exemplu, pretul produselor firmei AF Dana a scazut cu 15% ceea ce a permis ca
productia sa creasca la 1000 bucati din fiecare sortiment (pentru siguranta, inainte de
definirea interogarii Update, tabelul Produse a fost salvat cu numele ProduseCopie ;
vezi interogarea Q_Update_And_Produse din BD)
UPDATE Produse
SET Produse.PretUnitar = PretUnitar * 0.85, Produse.Cantitate = 1000
WHERE (((Produse.CodFirma) = "AFD"));

53

 Sa presupunem ca operatia de actualizare nu s-a incheiat cu rezultatul asteptat si

prin urmare, trebuie recuperat tabelul de baza in forma anterioara, cu ajutorul copiei
facute. Atunci, este preferabil ca refacerea tabelului sa se realizeze nu prin
redenumirea copiei cu numele tabelului ci prin copierea informatiei din tabelul-copie in
tabelul initial. Motivul este acela ca tabelul initial nu si-a alterat nici structura (deci
proprietatile campurilor, indecsii etc.) si nici mai ales relatiile cu celelate obiecte din
BD.
Actualizarea unor campuri
si tabele asociate.
Sa presupunem ca toate
firmele consultante aflate in
Bucuresti
au
urmat
exemplul firmei AF Dana.
Ca atare, are loc aceeasi
operatie de actualizare dar
criteriul de selectie se
schimba: el se bazeaza pe
relatia 1 m dintre tabelele
Firma
si
Produse
stabilita la nivelul campului
CodFirma
UPDATE Produse INNER JOIN Firma ON Produse.CodFirma = Firma.CodFirma SET
Produse.PretUnitar = PretUnitar * 0.85, Produse.Cantitate = 1000 WHERE
(((Firma.CodOras) = "B"));
Actualizarea campurilor cu criterii multiple.
Sa presupunem ca trebuie sa actualizam pretul unitar si nivelul productiei cu valorile de
mai sus numai pentru firmele din Bucuresti care au un capital social sub 500 milioane
lei
UPDATE Firma
INNER JOIN
Produse
ON Firma.CodFirma
Produse.CodFirma
SET Produse.PretUnitar = PretUnitar * 0.85, Produse.Cantitate = 1000
WHERE (((Firma.CodOras) = "B") AND ((Firma.Capital) <= 500));

Interogarea MakeTable (CreareTabel)

Efect
Creeaza un tabel nou din campurile / inregistrarile selectate, pentru a fi depus in BD
curenta sau pentru a fi exportat in alte BD (create cu SGBD sau cu alte aplicatii). Pot fi
folosite campuri / inregistrari dintr-un singur tabel / din mai multe tabele asociate / dintro interogare (noul tabel nu va mai fi insa normalizat).
Utilizare
Crearea unui tabel nou in aceeasi BD.
De exemplu, in BD AsistRom exista tabelele Clienti si Firma care au aceeasi
informatie in campurile CodClient, CodFirma, NumeClient, Adresa, CodOras,
CodPostal, NrTelefon (fiind firme mici, adresa firmei coincide cu adresa de acasa a
clientului); ca atare, dupa crearea tabelului Clienti tabelul Firma poate fi creat cu o
interogare MakeTable bazata pe informatia din campurile comune celor 2 tabele.
Crearea unei copii a unui tabel.
Rezultatul obtinut este echivalent cu cel obtinut mult mai rapid - prin utilizarea
comezii FILE SAVE AS sau a comenzilor EDIT COPY si EDIT PASTE.

54

Crearea unui tabel de siguranta in care sa fie depuse inregistrarile vechi, devenite
inutile, care urmeaza sa fie sterse.
De exemplu, inregistrarile din tabelul Produse corespunzatoare produselor iesite din
fabricatie pot fi depuse intr-un tabel creat astfel, inainte de a fi sterse din tabelul
Produse.
Crearea unui tabel temporar de catre un utilizator intr-o BD accesata in retea.
Sa presupunem ca BD AsistRom este folosita in retea; evident, expertii fiecarui centru
de consultanta sunt in primul rand interesati de informatia privitoare la proprii clienti. Ei
isi pot crea un tabel temporar extragand din tabelul Clienti inregistrarile care au in
campul CodCentru codul centrului respectiv si pot crea cu ele un tabel nou cu ajutorul
unei interogari MakeTable, la care pot renunta oricand. Daca operatiile de creare de
tabele temporare si de stergere a acestora (cu instructiunea SQL DROP TABLE
nume_tabel) se repeta frecvent atunci se impune compactarea cu regularitate a BD
Crearea rapoartelor care sa afiseze informatii inregistrate la un anumit moment de
timp.
De exemplu, trebuie afisate firmele care au solicitat asistenta firmei AsistRom chiar in
anul in care s-au infiintat. Se poate, evident, crea o interogare pe baza tabelului Firma
si apoi un raport bazat pe aceasta interogare. Raportul si interogarea vor contine insa
numai firmele create in 1997, si - intrucat ele se bazeaza pe datele curente din tabelul
Firma nu permit obtinerea informatiei similare cu privire la anul 1996, 1995 etc.
Stiind ca va fi solicitat un astfel de raport anual se poate crea o interogare MakeTable
pe baza tabelului Firma in fiecare an pe 31 Decembrie (filtrand inregistrarile dupa
campul Start). Apoi se poate crea raportul solicitat pe baza tabelului asociat anului
respectiv, iar tabelul provizoriu poate fi sters sau pastrat.
Accelerarea crearii formularelor si rapoartelor bazate prin intermediul unei interogari pe mai multe tabele.
Fiecare afisare a raportului presupune executia interogarii, deci consuma timp. Este
preferabila extragerea inregistrarilor necesare din tabelele respective si depunerea lor
intr-un tabel nou cu ajutorul unei interogari MakeTable si bazarea raportului pe acest
tabel. Dezavantajul este ca tabelul nou creat nu se actualizeaza automat la modificarea
tabelelor din care si-a extras inregistrarile.
Sintaxa instructiunii SELECT INTO
SELECT camp1[, camp2[, ...]] INTO tabel_nou [IN baza_de_date_externa]
FROM expresie_tabel
unde:
camp1, camp2
numele campurilor care trebuie copiate in noul tabel;
tabel_nou
numele noului tabel care trebuie creat
baza_de_date_externa
calea catre o BD externa
expresie_tabel
o expresie care identifica unul sau mai multe tabele din care provin datele pentru
crearea noului tabel. Expresia poate fi un nume unic de tabel, numele unei interogari
deja salvate sau o combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere:
INNER JOIN, LEFT JOIN, sau RIGHT JOIN;

Observatii

55

Datele din tabelul nou creat mostenesc numai tipul de data si dimensiunea campurilor
din tabelul de baza; ele nu mostenesc insa si celelalte proprietati ale campurilor si
nici setarea cheii primare.
Numele dat noului tabel nu trebuie sa coincida cu numele unui tabel existent deoarece
atribuirea numelui respectiv pentru noul tabel presupune stergerea tabelului deja
existent.
Exemple
Crearea unei copii de siguranta pentru tabelul Consultante, denumita ConsultanteBk

SELECT * INTO [ConsultanteBk] FROM Consultante;

Crearea unei copii de siguranta pentru acelasi tabel Consultante cu pastrarea
numelui si depunerea lui in alta BD Access, denumita CopieBD
SELECT Consultante.* INTO Consultante IN CopieBD.mdb
FROM Consultante;
Crearea unui tabel temporar, denumit ClientiPolizu, cu clientii centrului de consultanta
Polizu
SELECT Clienti.Prenume, Clienti.NumeClient INTO ClientiPolizu
FROM Clienti WHERE (((Clienti.CodCentru) = "POLI"));
Crearea unui nou tabel, numit SolicitariCons, pe baza tabelului Consultante si a unui
tabel creat ad-hoc, numit Experti si constand din 2 campuri: CodExpert si
NumeExpert (cele 2 tabele se afla in relatia 1 m);
SELECT Consultante.*, Experti.NumeExpert INTO
FROM Experti INNER JOIN Consultante
ON Experti.CodExpert = Consultante.CodConsultant;

SolicitariCons

Interogarea Append (Adaugare)

Efect
Adauga inregistrari la baza unui tabel.
Utilizare
Adaugarea unui grup de inregistrari aflate intr-un tabel sau in mai multe tabele la baza
unui tabel sau a mai multor tabele (de exemplu, trebuie adaugati noi clienti in tabelul
Clienti iar informatiile despre acestia pot fi importate sub forma unui tabel din alta BD
eventual creata cu alta aplicatie . Pentru a nu a avea doua tabele Clienti si pentru
a evita reintroducerea lor, aceste date pot fi adaugate la baza tabelului Clienti cu
ajutorul unei interogari Append);
Adaugarea unui grup de inregistrari aflate intr-un tabel la baza unui tabel sau a mai
multor tabele chiar si atunci cand acestea nu au acelasi numar de campuri:
interogarea Append adauga inregistrari cu aceeasi structura dar introduce
informatie numai in campurile care corespund (de exemplu, tabelul noilor clienti
importat in BD curenta nu contine campurile NrSalariati si ClientNou: interogarea
va adauga inregistrarile respective lasand aceste campuri vide);
Adaugarea unui grup de inregistrari filtrate, adica numai a acelor inregistrari care au
intr-un camp anumite valori (de exemplu, trebuie adaugati numai clientii unui
anumit centru de consultanta).
Sintaxa instructiunii INSERT INTO
cazul adaugarii unei singure inregistrari
INSERT INTO tabel_destinatie [(camp1[, camp2[, ...]])]
VALUES (valoare1[, valoare2[, ...]);

56

cazul adaugarii mai multor inregistrari odata:

INSERT INTO tabel-destinatie [IN baza_de_date_externa] [(camp1[, camp2[,
...]])]
SELECT [tabel-sursa.]camp1[, camp2[, ...]
FROM expresie_tabel;
unde:
tabel-destinatie
numele tabelului caruia/ interogarii careia i se adauga inregistrari;
baza_de_date_externa
calea catre o BD externa;
tabel_sursa
numele tabelului / interogarii din care fac parte inregistrarile care se adauga;
camp1, camp2
numele campurilor-destinatie, daca urmeaza argumentului tabel-destinatie, respectiv
numele campurilor-sursa, daca urmeaza argumentului tabel-sursa;
expresie_tabel
o expresie care identifica unul sau mai multe tabele din care provin datele pentru
crearea noului tabel. Expresia poate fi un nume unic de tabel, numele unei interogari
deja salvate sau o combinatie obtinuta prin oricare dintre cele 3 tipuri de asociere:
INNER JOIN, LEFT JOIN, sau RIGHT JOIN;
valoare1, valoare2
valorile de inserat in campurile specificate ale noii inregistrari; ordinea este esentiala:
valoare1 se introduce in camp1, valoare2 se introduce in camp2 etc. Valorile trebuie
separate prin virgule iar constantele literale trebuie incluse intre ghilimele.
Exemple
Adaugarea unei singure inregistrari.
Sa presupunem ca in tabelul Produse trebuie adaugat un nou produs executat de
firma Mara SNC; se foloseste urmatoarea interogare Append (vezi
Q_Append1Rec_Produse)
INSERT INTO Produse
(CodFirma, CodProdus, NumeProdus, PretUnitar, Cantitate)
VALUES (MSNC, c2, caiet matematica, 6, 600);
Adaugarea tuturor inregistrarilor dintr-un tabel-sursa.
Sa presupunem ca mai multi utilizatori lucreaza la crearea tabelului Produse; astfel,
pe langa tabelul Produse, in BD AsistRom exista si tabelul AlteProduse, ambele
avand aceeasi structura; pentru a introduce informatia din tabelul AlteProduse in
tabelul Produse fara a o retasta se foloseste urmatoarea interogare Append
INSERT INTO Produse SELECT * FROM AlteProduse;
Adaugarea acelor inregistrari din tabelul-sursa care verifica un criteriu de selectie.
Sa presupunem ca in BD AsistRom exista inca un tabel cu patroni de firme mici si
mijlocii care au trimis o scrisoare de solicitare de asistenta, numit ClientiPotentiali.
Acest tabel are aceeasi structura ca tabelul Clienti dar are un camp suplimetar numit
Solicitare, de tip boolean, cu valoarea implicita No. Periodic, acei clienti din tabelul
ClientiPotentiali care au si solicitat asistenta (campul Solicitare a primit valoarea
Yes) trebuie adaugati tabelului Clienti
INSERT INTO Clienti
SELECT ClientiPotentiali.* FROM ClientiPotentiali WHERE Solicitare =
Yes;
Interogarea Delete (Stergere)
57

Efect
Determina stergerea unui grup de inregistrari dintr-un tabel sau din mai multe tabele
simultan. O interogare Delete nu actioneaza asupra campurilor ci asupra inregistrarilor
in totalitate (de exemplu, pot fi sterse printr-o singura operatie toate informatiile
referitoare la centrele de consultanta din tabelul CentreCons care nu au nici un
client);
Utilizare
Stergerea unui grup de inregistrari dintr-un singur tabel.
Stergerea unui grup de inregistrari din mai multe tabele aflate in relatia 1 1 sau 1 m
atunci cand optiunea Cascade Delete Related Fields a relatiei nu a fost selectata
(daca insa criteriile de selectie se refera atat la campuri din tabelul 1 cat si la
campuri din tabelul m atunci interogarea trebuie executata de 2 ori deoarece ea
nu poate sterge printr-o singura operatie atat inregistrarile din tabelul principal cat si
pe cele din tabelul secundar).
Sintaxa instructiunii DELETE
DELETE [tabel.*] FROM tabel
WHERE criterii_de_selectie
unde:
tabel
numele optional al tabelului din care se sterg inregistrari
tabel
numele obligatoriu al tabelului din care se sterg inregistrari
criterii_de_selectie
o expresie pe care trebuie s-o satisfaca o inregistrare pentru a fi stearsa; ea poate
contine pana la 40 de operanzi combinati prin operatori logici. Numai inregistrarile care
satisfac criteriile de selectie vor fi sterse.
Exemplu
Stergerea inregistrarilor dintr-un tabel independent care verifica un criteriu de selectie.
De exemplu, trebuie sterse inregistrarile referitoare la produsele cu pret unitar mai
mare decat 6 unitati
DELETE * FROM Produse WHERE PretUnitar >= 6;
Interogarile specifice SQL
Definitie O interogare SQL este o interogare care modifca insasi structura unui tabel.
Ea nu poate fi creata decat cu ajutorul unei instructiuni SQL .
Clasificare
Exista urmatoarele tipuri de interogari SQL:
interogarea Union (de combinare): combina 2 sau mai multe tabele;
interogarea PassThrough (de transferare): permite aplicatiei SGBD sa transmita
altui SGBD instructiuni SQL si sa primeasca inapoi inregistrari;
interogarea DataDefiniton (de definire a datelor): defineste sau modifica structura
unui tabel.
Interogarea Union (Combinare)
Efect
Combina campurile (coloanele) corespunzatoare din 2 sau mai multe tabele sau
interogari intr-un singur camp (coloana) cu ajutorul unei operatii UNION.
De exemplu, daca fiecare centru de consultanta isi gestioneaza propriile tabele
Clienti, Firma, Consultante, Produse, acestea trebuie fuzionate periodic in tabele
unice; pentru aceasta, se creeaza o interogare Union care combina toate tabelele
58

Clienti, Firma, Consultante, respectiv Produse in un singur tabel Clienti , Firma,

Consultante, respectiv Produse; apoi, pe baza respectivelor interogari, se creeaza
noi tabele cu ajutorul interogarilor MakeTable.
Sintaxa operatiei UNION
[TABLE] query1 UNION [ALL] [TABLE] query2
[UNION [ALL] [TABLE] queryn [ ... ]]
unde
query1-n
pot fi: o instructiune SELECT, numele unei interogari sau numele unui tabel precedat
de cuvantul-cheie TABLE.
Exemple
Cea mai simpla interogare Union (afiseaza clientii si furnizorii unei firme)
TABLE Clienti UNION TABLE Furnizori;
Folosirea criteriilor de selectie in interogarile-argument (de exemplu, afisarea clientilor
din Timisoara si a furnizorilor din Brasov)
SELECT [NumeClient], [NumeFirma] FROM Clienti WHERE [CodOras] =
TM
UNION
SELECT [NumeFurnizor], [NumeFirma] FROM Furnizori
WHERE [CodOras] = BV;
 In selectarea inregistrarilor returnate de interogarile-argument pot diferi nu numai
valorile de selectie dar si criteriile, cu conditia ca numele campurilor sa provina din
prima interogare-argument (din prima instructiune SELECT).
Sortarea rezultatului intors de interogarea Union (de exemplu, afisarea clientilor si
furnizorilor in ordinea alfabetica a orasului in care isi au sediul)
SELECT [NumeFirma], [CodOras] FROM [Clienti]
UNION
SELECT [NumeFirma], [CodOras] FROM [Furnizori]
ORDER BY [CodOras];
Redenumirea campurilor in interogarea Union (in interogarea Union antetele campurilor
de nume pentru firme au alt nume)
SELECT [NumeFirma] AS [NumeFirma Client/Furnizor], [CodOras]
FROM [Clienti]
UNION
SELECT [NumeFirma] AS [NumeFirma Client/Furnizor], [CodOras]
FROM [Furnizori];
Folosirea tuturor acestor clauze intr-o interogare Union
SELECT
NumeFirma, Adresa,
NumeFurnizor
AS
Nume FROM
Furnizori
WHERE CodOras = CR
UNION SELECT NumeFirma, Adresa, NumeClient AS Nume FROM
Clienti
WHERE CodOras = CR
ORDER BY CodOras, Sursa;

59

Returnarea inregistrarilor duplicate intr-o interogare Union (de exemplu, returnarea

tuturor inregistrarilor din cele doua tabele Clienti si Furnizori, inclusiv duplicatele
pentru cazul in care aceeasi firma este si client si furnizor)
SELECT [NumeFirma], [CodOras] FROM [Clienti]
UNION ALL
SELECT [NumeFirma], [CodOras] FROM [Furnizori];
Returnarea tuturor inregistrarilor din primul tabel si numai a unui set de inregistrari
selectate din al doilea (vezi interogarea Q_UnionTS_OraseRef_OraseRef2 din BD
AsistRom )
TABLE [OraseRef] UNION
SELECT * FROM OraseRef2 WHERE CodOras >= "a" AND CodOras <=
"k"
ORDER BY CodOras DESC;
 Pentru a combina tabelul OraseRef cu tabelul OraseRef2 integral se poate folosi
oricare dintre interogarile Union de mai jos (vezi in BD AsistRom interogarile
Q_UnionTT_OraseRef_OraseRef2 si Q_Union_TS_OraseRef_OraseRef2)
TABLE [OraseRef] UNION TABLE [OraseRef2];
TABLE [OraseRef] UNION SELECT * FROM OraseRef2;
Interogarea PassThrough (de transferare)
Efect
Trimite comenzi direct bazelor de date accesabile din SGBDprin protocolul ODBC
(Object Database Connectivity Protocole = un protocol standard de accesare a
informatiei de pe serverele de baze de date SQL, de exemplu, de pe Microsoft SQL
Server) intr-un format compatibil cu serverul respectiv.
Utilizare
Obtinerea de informatii de pe serverul accesat;
Executarea procedurilor memorate pe serverul ODBC accesat.
Pentru crearea unei interogari PassThrough, a se vedea informatiile Help oferite de
aplicatia MS Access.
Interogarea DataDefinition (de definire date)
Efect
Creeaza sau modifica obiecte ale BD (tabele SGBD sau tabele SQL Server).
Interogarea DataDefinition creeaza structura noului tabel; pentru a-l completa cu
date se poate utiliza interogarea-actiune Append (cate una pentru fiecare inregistrare).
Sintaxa instructiunii CREATE INDEX
CREATE [ UNIQUE ] INDEX nume_index
ON nume_tabel (nume_camp [ASC | DESC][, nume_camp [ASC | DESC], .
.])
[WITH { PRIMARY | DISALLOW NULL | IGNORE NULL }]
unde:
nume_index
numele indexului care trebuie creat;
nume_tabel
numele tabelului din BD curenta care va contine indexul;
nume_camp

60

numele campului care trebuie indexat.

Observatii si exemple
Pentru a crea un index dintr-un singur camp trebuie specificat numele campului intre
paranteze, dupa numele tabelului. Pentru a crea un index dintr-un grup de campuri
trebuie specificate numele tuturor campurilor din grup.
Implicit, indexul creat este ordonat creascator; daca trebuie creat un index ordonat
descrescator trebuie specificata optiunea DESC in clauza ON.
CREATE INDEX AltIndex ON Experti ([Nume], [Prenume]);
CREATE INDEX IndexCalend ON Experti (DataNasterii, DataAngajarii);
Cu predicatul UNIQUE se defineste campul /grupul de campuri specificat ca index cu
valori unice (daca in campul /grupul de campuri specificat exista valori duplicate,
inregistrarile respective vor fi sterse automat de catre MS Access);
Cu predicatul PRIMARY se defineste campul /grupul de campuri specificat drept cheie
primara pentru tabelul respectiv (daca in campul /grupul de campuri specificat
exista valori duplicate sau nule, inregistrarile respective vor fi sterse automat de
catre MS Access; de asemenea, daca tabelul are deja o cheie primara aceasta nu
va fi inlocuita cu noua cheie ci operatia definita de instructiunea ALTER TABLE
respectiva nu se va realiza);
Clauza optionala WITH intr-o instructiune CREATE INDEX impreuna cu una dintre
urmatoarele 2 optiuni permite specificarea regulilor de validare a datelor. Astfel:
optiunea DISALLOW NULL nu permite introducerea valorilor nule in campul /
campurile de index al unei noi inregistrari;
optiunea IGNORE NULL nu permite includerea in index a inregistrarilor cu
valori nule in campul / campurile de index;
In exemplul urmator este creat un index cu valori unice si nenule din valorile campului
CodExpert al tabelului Experti din BD AsistRom
CREATE UNIQUE INDEX IndexExperti
ON Experti (CodExpert) WITH DISALLOW NULL;
Instructiunea CREATE INDEX este foarte utila pentru consultarea unui tabel dintr-o BD
aflata pe serverul SQL. Ea permite construirea unui pseudoindex pentru un tabel
dintr-o BD ODBC legat de BD curenta. Tabelele care nu au index sunt read only.
Crearea acestui pseudoindex nu le afecteaza pentru ca operatia nu este vizibila
pentru ele.
In exemplul urmator este creat un index pentru un tabel ODBC legat de BD AsistRom
(se presupune ca tabelul respectiv a fost deja legat de BD)
CREATE UNIQUE INDEX CodComanda
ON ComenziDetODBC (CodComanda);
Sintaxa instructiunii DROP
DROP {TABLE nume_ tabel | INDEX nume_index ON nume_tabel}
unde:
nume_tabel
numele tabelului care trebuie sters, respectiv al tabelului din care trebuie sters un
index;
nume_index
numele indexului care trebuie sters din tabel.
Observatii
Tabelul care trebuie sters sau din care trebuie sters un index trebuie in prealabil inchis.
Pentru a putea sterge un tabel / un index trebuie sterse toate legaturile care il implica.
Pentru stergerea unui index se mai poate folosi si instructiunea ALTER TABLE
Exemple

61

Stergerea unui tabel

DROP TABLE ProduseB;
Stergerea unui index
DROP INDEX IndexExperti ON Experti;
Sintaxa clauzei CONSTRAINT
O restrictie (constraint) este similara unui index dar poate fi folosita si pentru stabilirea
relatiei cu un alt tabel. Aceasta clauza poate fi folosita ininstructiunile CREATE TABLE
si ALTER TABLE pentru a crea sau a elimina restrictii. Exista 2 tipuri de clauze
CONSTRAINT: pentru un singur camp si pentru un grup de campuri.
Sintaxa clauzei CONSTRAINT pentru un singur camp
CONSTRAINT nume_restrictie {PRIMARY KEY | UNIQUE | NOT NULL |
REFERENCES nume_tabel_secundar
[(nume_camp_secundar1, nume_camp_secundar2)]}
Sintaxa clauzei CONSTRAINT pentru mai multe campuri
CONSTRAINT nume_restrictie
{PRIMARY KEY (cheie_primara1[, cheie_primara2 [, ...]]) |
UNIQUE (unic1[, unic2 [, ...]]) |
NOT NULL (nenul1[, nenul2 [, ...]]) |
FOREIGN KEY (ref1[, ref2 [, ...]]) REFERENCES nume_tabel_secundar
[(nume_camp_secundar1 [, nume_camp_secundar2 [, ...]])]}
unde:
nume_restrictie
numele restrictiei care trebuie creata;
cheie_primara1, cheie_primara2
numele campului / campurilor care trebuie definite drept cheie primara;
unic1, unic2
numele campului / campurilor care trebuie definite ca avand valori unice;
nenul1, nenul2
numele campului / campurilor care trebuie definite ca neavand valori nule;
ref1, ref2
numele campului / campurilor de cheie secundara care se afla in relatie cu campuri din
alt tabel;
nume_tabel_secundar
numele tabelului secundar care contine campurile nume_camp_secundar1,
nume_camp_secundar2;
nume_camp_secundar1, nume_camp_secundar2
numele campului / campurilor din tabelul secundar specificat prin ref1, ref2; aceasta
clauza poate fi omisa in cazul in care campul referit este chiar campul de cheie primara
al tabelului secundar.
Observatii
Clauza CONSTRAINT pentru camp unic trebuie folosita in instructiunile CREATE
TABLE si ALTER TABLE imediat dupa declararea tipului si dimensiunii campului
respectiv. Clauza CONSTRAINT pentru un grup de campuri poate fi folosita in
instructiunile CREATE TABLE si ALTER TABLE oriunde inafara listei de definitii de
campuri.
Cu predicatul FOREIGN KEY se defineste un camp / un grup de campuri drept cheie
secundara pentru tabelul secundar. Daca cheie primara a tabelului secundar
consta dintr-un grup de campuri trebuie folosita sintaxa clauzei CONSTRAINT

62

pentru un grup de campuri, specificandu-se - in aceeasi ordine - toate campurile de

legatura din tabelul principal si toate campurile de legatura din tabelul secundar
impreuna cu numele tabelului secundar. Daca insa campurile de legatura din
tabelul secundar sunt chiar campurile care formeaza cheia primara a tabelului
secundar, ele nu mai trebuie specificate.
Specificarea predicatului NOT NULL pentru un camp este echivalenta cu setarea
proprietatii Required a campului respectiv (in panelul de proprietati al ferestrei
Design View a tabelului) pe valoarea Yes.
Intrucat clauza CONSTRAINT nu poate aparea independent, exemplele de utilizare a
ei vor fi prezentate o data cu exemplele privind utilizarea instructiunilor CREATE
TABLE si ALTER TABLE.
Sintaxa instructiunii CREATE TABLE
CREATE TABLE nume_tabel (nume_camp1 tip [(dimensiune)] [NOT NULL]
[nume_index1]
[, nume_camp2
tip
[(dimensiune)]
[NOT NULL]
[nume_index2] [, ...]]
[, CONSTRAINT nume_index_de_grup_de_campuri [, ...]])
unde:
nume_tabel
numele tabelului care trebuie creat;
nume_camp1, nume_camp2
numele campului / campurilor din tabelul de creat (trebuie sa existe cel putin un camp);
tip
tipul de date al campului din noul tabel;
dimensiune
dimensiunea campului in caractere (numai pentru campurile de tip Text si Binary);
nume_index1, nume_index2
numele unor indecsi de un singur camp definiti cu ajutorul unei clauze CONSTRAINT;
nume_index_de_grup_de_campuri
numele unui index de mai multe campuri definit cu ajutorul unei clauze CONSTRAINT.
Observatie
Predicatul NOT NULL se poate aplica o singura data si unui singur camp. Intr-o clauza
CONSTRAINT cu nume se poate folosi clauza NOT NULL atat pentru un camp unic cat
si pentru un grup de campuri.
Exemple
Crearea unui tabel; de exemplu, tabelul Experti continand date despre angajatii firmei
de consultanta AsistRom ; instructiunea atribuie campului CodConsultant un index
si-l defineste drept camp de cheie primara
CREATE TABLE Experti
([CodConsultant] INTEGER, [Nume] TEXT, [Prenume] TEXT,
[DataNasterii] DATE, [DataAngajarii] DATETIME,
[Adresa] TEXT, [Telefon] TEXT, [Observatii] MEMO,
CONSTRAINT [Index1] PRIMARY KEY ([CodConsultant]));
Crearea unui tabel cu un index cu valori unice format din 3 campuri
CREATE TABLE Experti2
([Nume] TEXT, [Prenume] TEXT, [DataNasterii] DATETIME,
[DataAngajarii] DATETIME, [Adresa] TEXT, [Telefon] TEXT,
CONSTRAINT [Restrictie] UNIQUE ([Nume],[Prenume],[DataNasterii]));
Crearea unui tabel cu camp de cheie primara
CREATE TABLE UnTabel (Nume TEXT, Prenume TEXT, Id INTEGER
CONSTRAINT Restrictie PRIMARY KEY);

63

Sintaxa instructiunii ALTER TABLE

ALTER TABLE nume_tabel {ADD {COLUMN nume_camp tip[(dimensiune)]
[NOT NULL] [CONSTRAINT nume_index] |
CONSTRAINT nume_index_de_grup_de_campuri} |
DROP {COLUMN nume_camp I CONSTRAINT nume_ index} }
unde:
nume_tabel
numele tabelului care trebuie modificat;
nume_camp
numele campului care trebuie adaugat sau eliminat din tabel;
tip
tipul de date al campului;
dimensiune
dimensiunea campului in caractere (numai pentru campurile de tip Text si Binary);
nume_index
numele unui index de un singur camp definit cu ajutorul unei clauze CONSTRAINT;
nume_index_de_grup_de_campuri
numele unui index de mai multe campuri definit cu ajutorul unei clauze CONSTRAINT;
nume_index
numele indexului de mai multe campuri care trebuie eliminat.
Observatii si exemple
Clauza ADD COLUMN intr-o instructiune ALTER TABLE permite adaugarea unei
coloane la tabelul existent; trebuie specificate: numele campului, tipul de date si,
optional, dimensiunea. De exemplu, urmatoarea instructiune adauga campul
Observatii tabelului Experti din BD AsistRom
ALTER TABLE Experti ADD COLUMN Observatii TEXT(25);
Clauza DROP COLUMN intr-o instructiune ALTER TABLE permite eliminarea unui
camp din tabel; trebuie specificat numai numele tabelului. In exemplul urmator
tabelului Experti din BD AsistRom i se adauga si apoi i se sterge coloana
Salariu (fiecare operatie necesita o interogare ALTER TABLE distincta)
ALTER TABLE Experti ADD COLUMN Salariu CURRENCY;
ALTER TABLE Experti DROP COLUMN Salariu;
Clauza CONSTRAINT intr-o instructiune ALTER TABLE permite definirea unui index
pentru un camp din tabel. De exemplu, presupunand ca tabelul Experti nu are
camp de index, adaugam campul CodExpert si-l definim drept camp indexat (nu
camp de cheie primara; ca urmare, proprietatea Indexed a campului va fi setata pe
valoarea Yes (No Duplicates))
ALTER TABLE Experti ADD COLUMN CodExpert TEXT(4)
CONSTRAINT CodExpert UNIQUE;
Clauza ADD CONSTRAINT intr-o instructiune ALTER TABLE permite crearea unui
index de mai multe campuri. Clauza DROP CONSTRAINT intr-o instructiune
ALTER TABLE permite eliminarea unui index de mai multe campuri; trebuie
specificat numai numele indexuluiimediat dupa cuvantul-cheie CONSTRAINT. In
exemplul urmator este eliminata si apoi adaugata cheia secundara din campul
ConsultanteDet (acest tabel se afla in relatia 1 m cu tabelul Experti din BD
AsistRom , el continand detalii despre consultantele acordate de fiecare expert;
efectul acestor operatii se poate urmari in fereastra Relationships a BD AsistRom )

ALTER TABLE ConsultanteDet DROP CONSTRAINT CodCons;

ALTER TABLE ConsultanteDet ADD CONSTRAINT CodCons
FOREIGN KEY (CodExpert) REFERENCES Experti (CodExpert);
64

Cu o instructiune ALTER TABLE se poate elimina un singur camp / index.

Subinterogarea (Subquery)
Definitie O subinterogare consta dintr-o instructiune SELECT inclusa in alta interogare
de selectie sau in alta interogare-actiune. Ea poate fi introdusa in
linia Fields a grilei QBE din fereastra Design View pentru a defini un nou camp;
linia Criteria a grilei pentru a defini un criteriu de selctie pentru campul respectiv.
Utilizare
Verificarea existentei unor rezultate returnate de interogare (prin aplicarea clauzelor
EXISTS sau NOT EXISTS);
Gasirea tuturor valorilor din interogarea principala care sunt mai mari, mai mici,
respectiv egale cu valorile returnate de subinterogare (prin aplicarea clauzelor
ANY, IN sau ALL);
Crearea subinterogarilor imbricate.
Exemple de expresii care folosesc rezultatul unei subinterogari pentru definirea
criteriilor de selectie
Determinarea produselor al caror pret unitar coincide cu cel al caietelor dictando
produse de firma AF Dana in celula Criteria a campului PretUnitar din grila QBE
se introduce expresia:
(SELECT [PretUnitar] FROM [Produse]
WHERE [NumeProdus] = "caiet dictando"

AND

[CodFirma] = AFD)

Determinarea produselor al caror pret unitar depaseste pretul unitar mediu in celula
Criteria a campului PretUnitar din grila QBE se introduce expresia:
> (SELECT AVG([PretUnitar]) FROM [Produse])
Determinarea firmelor care produc caiete de matematica si de muzica in celula
Criteria a campului CodFirma se introduce expresia:
ALL (SELECT [CodFirma] FROM [Produse]
WHERE ([NumeProdus] LIKE "*caiet matematica*")
OR ([NumeProdus] LIKE "*caiet muzica*"))
Determinarea firmelor pentru care valoarea totala a productiei depaseste valoarea
medie intai se creeaza un camp nou introducand in prima celula Fields libera
expresia:
Total: [PretUnitar] * [Cantitate]
apoi se introduce in celula Criteria a acestuia expresia:
> ALL (SELECT AVG([PretUnitar] * [Cantitate]) FROM [Produse])
2.3. Algebra relaional
n algebra relaional (relational algebra) o interogare se formuleaz printr-o
expresie constnd dintr-o secven de identificatori (nume de relaii, nume de atribute),
constante i operatori. Pentru exprimarea unei interogri printr-o expresie de algebr
relaional, trebuie s fie precizate urmtoarele elemente:

Lista atributelor relaiei rezultat, care se numesc atribute de proiecie.

Lista relaiilor din care se extrag informaiile.

Condiia pe care trebuie s o ndeplineasc tuplurile relaiei rezultat.

n funcie de aceste elemente, se pot studia dou situaii de rezolvare a
interogarilor: interogri care se rezolv n cadrul unei singure relaii i interogri care se
rezolv folosind dou sau mai multe relaii ale bazei de date.

65

- Interogri ntr-o singur relaie - dac toate atributele care intervin n

interogare (atributele de proiecie i atributele din condiie) sunt atribute ale unei
singure relaii R, atunci interogarea se poate rezolva la nivelul acelei relaii, ca o
proiecie (pe atributele relaiei rezultat) a restriciei cu condiia impus asupra relaiei
date, prin expresia:
Q=

(R)
lista_atribute

conditie

- Interogri n dou sau mai multe relaii - n situaia n care atributele de

proiecie i atributele din condiia de interogare nu aparin unei singure relaii, pentru
rezolvarea interogrii trebuie s fie folosite toate acele relaiile care, mpreun, conin
aceste atribute. Conceptual, o astfel de interogare se rezolv construind mai nti o
relaie care s conin toate atributele necesare prin combinarea a dou sau mai multe
relaii folosind operaii de produs cartezian sau jonciuni, iar rezultatul interogrii se
obine prin restricia (cu condiia de interogare) i proiecia (pe atributele de proiecie) a
acestei relaii. Cazul cel mai frecvent de interogare necesit jonciunea natural a dou
sau mai multe relaii asociate, folosind perechea de atribute cheia strin - cheia
primar referit pentru fiecare operaie de jonciune:

(R >< S >< T...)

Q=
lista_atribute

conditie

Algebra relaional exprim interogrile prin aplicarea unor operatori

specializai (operatorii algebrei relaionale) asupra relaiilor. E.F. Codd a propus opt
operaii ale algebrei relaionale, grupate n dou categorii:
- Operaii pe mulimi: reuniunea (union), intersecia (intersection), diferena
(difference) i produsul cartezian (Cartesian product). Aceste operatii reprezint
adaptarea operatiilor corespunztoare din teoria mulimilor i acioneaz asupra
relaiilor vzute ca mulimi de elemente (tupluri), fr a lua n consideraie compoziia
fiecrui element.
- Operaii relaionale speciale: restricia (restriction), proiecia (projection),
jonciunea (join) i diviziunea (division). Aceste operaii iau n consideraie compoziia
tuplurilor, formate din valori ale atributelor relaiilor.
Toate aceste operaii trebuie s asigure proprietatea de nchidere, adic
rezultatul fiecrei operaii trebuie s fie tot o relaie. Aceast proprietate permite
efectuarea operaiilor imbricate: proiecia unei jonciuni dintre o relaie i restricia
aplicat altei relaii, etc.
Restricia i proiecia sunt operaii unare (au un singur operand, o relaie);
operatiile pe mulimi, jonciunea i diviziunea sunt operaii binare (au doi operanzi,
dou relaii).
A. Operaii pe mulimi
Reuniunea a dou relaii compatibile R i S este o relaie Q = R S care
U

conine toate tuplurile ce aparin fie relaiei R, fie relaiei S, fie ambelor relaii. Tuplurile
care aparin ambelor relaii se introduc n relaia rezultat o singur dat, adic nu se
duplic.
Intersecia a dou relaii compatibile R i S este o relaie Q = R S care
I

conine toate tuplurile care aparin att relaiei R ct i relaiei S

Diferena a dou relaii compatibile R i S este o relaie Q = R - S care
M

conine toate tuplurile care aparin relaiei R, dar nu aparin relaiei S.

n algebra relaional, produsul cartezian al relaiilor R(A ,A ,... A ) i
1

S(B ,B ,...B ) este o relaie Q (A ,A

1

.A ,B ,B ,...B ) = R S care are ca atribute toate

2,...

atributele primei relaii plus toate atributele celei de-a doua relaii. Pentru a se obine
tuplurile relaiei rezultat se combin (se concateneaz) valorile atributelor fiecrui tuplu
din prima relaie cu valorile atributelor tuturor tuplurilor din cea de-a doua relaie.
66

Operaia produs cartezian este conceptual comutativ, adic RS = SR,

dac se consider c atributele unei relaii nu sunt ordonate. Dac se consider
schema relaiei rezultat ca list a atributelor sale, atunci, prin convenie, atributele
primei relaii operand sunt primele n lista de atribute a relaiei rezultat, iar atributele
celei de-a doua relaii urmeaz n lista atributelor relaiei rezultat.
Operaia produs cartezian este asociativ, dac se consider c ordinea
atributelor ntr-o schem de relaie i ordinea tuplurilor ntr-o relaie nu este relevant:
R (S T) = (R S) T.
B. Operaii relaionale speciale
Pentru a lua n consideraie compoziia tuplurilor (combinaii de valori ale
atributelor) se impun anumite condiii atributelor acestora.
Restricia (restriction) este o operaie relaional unar care selecteaz dintre
tuplurile relaiei operand acele tupluri care ndeplinesc o condiie dat.
Observaie
Operaia de restricie se mai numete i selecie, dar este mai bine s fie
evitat aceast denumire deoarece se poate confunda cu instruciunea SELECT, care
are rolul de instruciune general de interogare.
Operaia de restricie se noteaz: (R), unde este o expresie logic
specificat asupra atributelor relaiei R. n relaia rezultat sunt selectate acele tupluri
ale relaiei R pentru care expresia are valoarea 1 (TRUE). Relaia rezultat are
aceleai atribute ca i relaia operand.
Expresia logic este format din una sau mai multe variabile logice v
conectate prin operatorii logici AND, OR, NOT, ca de exemplu:
= v AND (v OR v )...
1

Fiecare variabil logic v este rezultatul returnat de un operator de

comparaie. Se pot compara valorile a dou atribute sau se poate compara valoarea
unui atribut cu o constant.
O secven de restricii poate fi aplicat n orice ordine, adic:

cond1

(R)) =

cond2

cond2

(R))

cond1

Mai mult, se poate observa i demonstra c orice secven de restricii poate

fi nlocuit printr-o singur restricie n care expresia logic de condiie se obine prin
conjuncia (AND) tuturor condiiilor:

cond1

(..

cond2

(R)..)) =

condn

(R)

cond1 AND cond2...AND condn

Proiecia (projection) este o operaie relaional unar prin care se

selecteaz o submulime de atribute ale relaiei operand.
(nume_relatie). Relaia rezultat a
Notaia pentru proiecie este:
lista_atribute

operaiei de proiecie conine numai atributele din lista de atribute dat ca parametru,
care este o submulime nevid a mulimii atributelor relaiei operand.
Dac lista atributelor de proiecie este o cheie (sau conine o cheie) a relaiei
operand, atunci relaia rezultat are toate tuplurile distincte. n aceast situaie numrul
de tupluri ale relaiei rezultat este egal cu numrul de tupluri ale relaiei operand.
Dac lista de atribute nu este o cheie (sau nu conine o cheie) a relaiei
operand, atunci este posibil ca prin proiecie s se obin dou sau mai multe tupluri
identice, dar n relaia rezultat sunt eliminate tuplurile duplicat.
Jonciunea (cuplarea) - (join) este o operaie binar a algebrei relaionale
prin care se combin tuplurile a dou relaii ntr-o singur relaie.

67

Jonciunea se noteaz cu semnul >< i este o operaie foarte important n

bazele de date relaionale, deoarece ea permite realizarea asocierilor ntre relaii. n
continuare vor fi prezentate dou forme ale operaiei de jonciune: -jonciunea i
jonciunea natural.
-jonciunea a dou relaii R(A ,A ,...A ) i S(B ,B ,...B ) este o relaie
1

Q (A ,A ,... A ,B ,B ,...B ) = R >< S, n care fiecare tuplu este o combinaie a dou

J

tupluri, unul din relaia R (cu atributele A ,A ,....A ), iar cellalt din relaia S (cu
1

atributele B1,B2,...,Bm), combinaie care satisface condiia de jonciune . Forma

general a condiiei de jonciune este:
= cond AND cond ...AND cond ...AND cond
1

unde fiecare condiie parial (cond ) este o variabil logic, rezultat al unei operaii de
i

comparaie # (unde # poate fi unul din operatorii: =, , <, , >, ) asupra valorilor a
dou atribute A (care aparine relaiei R) i Bi (care aparine relaiei S), deci:
i

cond = A # B
i

Atributele Ai i Bi le cror valori se compar trebuie s fie definite pe domenii

compatibile. Tuplurile n care atributele din condiiile de jonciune au valori NULL nu
sunt luate n consideraie pentru calculul relaiei rezultat.
Operaia de -jonciune este asemntoare cu produsul cartezian, dat fiind c
tuplurile relaiei rezultat sunt combinaii ale tuplurilor relaiilor operand, cu numr de
atribute (gradul relaiei) egal cu suma numrului de atribute (gradul) ale celor doi
operanzi. Diferena esenial dintre jonciune i produsul cartezian este aceea c n
operaia de jonciune se combin numai tuplurile care ndeplinesc condiia de jonciune
, pe ct vreme n operaia produs cartezian n relaia rezultat se includ toate
combinaiile de tupluri din relaiile operand. Ca urmare, operaia de -jonciune poate fi
scris ca restricie cu condiia a produsului cartezian al celor dou relaii:
R >< S = (R S).

Cea mai utilizat form de -jonciune este echijonciunea, n care se

folosete numai operatorul de comparaie de egalitate (=).ntr-o echijonciune vor
exista ntotdeauna una sau mai multe perechi de atribute care au valori identice n
fiecare din tuplurile relaiei rezultat, i anume perechile de atribute care sunt comparate
pentru egalitate.
Jonciunea natural. Jonciunea natural este o echijonciune n care fiecare
pereche de atribute comparate pentru egalitate (n condiia de jonciune) se nlocuiete
cu unul singur. Se poate spune c jonciunea natural este o echijonciune urmat de o
proiecie pe reuniunea atributelor celor dou relaii.
Dat fiind c -jonciunea este o restricie a produsului cartezian al celor dou
relaii operand, rezult jonciunea natural ca o proiecie a unei restricii a produsului
cartezian al celor dou relaii.
Dac se noteaz relaiile operand cu R(A ,A ,...A ,B ,B ,...B ) i S(B ,B ,...B ,
1

C ,C ,...C ), cu atributele comune (B ,B ,...B ), rezultatul operaiei de jonciune natural

1

este relaia Q cu expresia:

J

Q = R >< S =
J

A1,.An,B1,.Bm,C1,.Ck

(R S)

(R.B1=S.B1 AND R.Bm=S.Bm)

Atributele (B1,B2,...,Bm) din cele dou relaii comparate pentru egalitate n

jonciunea natural se numesc atribute comune (sau atribute de jonciune) i trebuie s
fie definite pe domenii compatibile. Ele se consider identice (chiar dac au denumiri
diferite) i n reuniunea atributelor se introduc o singur dat.

68

Jonciunea natural se reprezint numai cu semnul ><, fr s mai fie nsoit

de condiia de jonciune, nelegnd prin aceasta c jonciunea are loc pe atributul (sau
atributele) comune ale celor dou relaii.
Diviziunea (division) este o operaie binar a algebrei relaionale prin care se
obine o relaie care conine atributele diferenei mulimilor de atribute ale relaiilor
operand.
Fie dou mulimi de atribute: A = {A ,A ,..A } i B = {B ,B ,..B } i dou relaii
1

R(A,B) i S(B) astfel nct mulimea atributelor relaiei S s fie o submulime a mulimii
atributelor relaiei R. Relaia Q obinut prin operaia de diviziune are ca atribute toate
D

atributele diferenei celor dou mulimi de atribute (adic acele atribute care aparin
relaiei R i nu aparin relaiei S) i conine acele tupluri t[A] care au proprietatea c
pentru orice tuplu s din S exist un tuplu t n R care are atributul B egal cu tuplul s. Se
poate scrie:
Q (A) = R S =
(R)
D

R.B = S.B

Algebra relaional este o colecie de operaii asupra relaiilor. Cele opt

operaii propuse de E.F.Codd (reuniunea, intersecia, diferena, produsul cartezian,
restricia, proiecia, jonciunea, diviziunea), la care se adaug operaia de redenumire a
atributelor, nu constituie o mulime minim de operaii ale algebrei relaionale,
deoarece o parte din operaii se pot exprima prin intermediul altora. Jonciunea este o
proiecie a unei restricii a produsului cartezian al celor dou relaii, iar diviziunea este o
proiecie a unei restricii asupra relaiei demprit. La fel, intersecia se poate exprima
printr-o expresie construit pe baza operaiei de diferen: R S = R (R S). Astfel
cele cinci operaii (reuniunea, diferena, produsul cartezian, restricia, proiecia) sunt
operaii primitive i constituie mulimea minim de operaii ale algebrei relaionale. Pe
baza lor se poate construi orice expresie a algebrei relaionale. Dar i celelalte trei
operaii (i n special jonciunea) sunt operaii deosebit de utile n formularea
interogrilor, astfel nct algebra relaional a pstrat toate cele opt operaii propuse de
E.F.Codd, la care s-a adugat operaia de redenumire a atributelor.
C. Implementarea interogarilor cu ajutorul limbajului SQL
SQL (limbaj de interogare structurat) este limbajul utilizat de majoritatea
sistemelor de baza de date relaionale. Limbajul SQL a fost dezvoltat ntr-un prototip de
sistem de management a bazelor de date relaionale - System R - de ctre IBM, la
mijlocul anilor 1970. n 1979, corporaia Oracle introduce prima implementare a SQL n
varianta comercial. Institutul Naional American de Standarde (ANSI) a adoptat SQL
ca limbaj standard pentru RDBMS n anul 1986. Organizaia Internaional de
Standarde (ISO) a adoptat deasemenea SQL ca limbaj standard pentru RDBMS. Toate
RDBMS-urile suport unele forme de SQL i toi vnztorii de RDBMS intenioneaz
s se alinieze la standardele ANSI.
Comanda principal care realizeaz n SQL interogarea datelor este
SELECT. Din punctul de vedere al algebrei relaionale, SQL - prin intermediul
instructiunii SELECT - implementeaz urmtoarele operaii:

Operaia de reuniune se exprim n limbajul SQL ca o reuniune a dou
tabele obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
UNION
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];
Cele dou liste de coloane din clauzele SELECT trebuie s conin atribute
compatibile. Tabelele din clauzele FROM, ca i condiiile din clauzele WHERE pot fi
identice sau diferite.

69


La fel ca i reuniunea, operaia de intersecie se exprim n SQL ca
intersecie a dou tabele obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
INTERSECT
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

Operaia de diferen se exprim n SQL ca diferen a dou tabele
obinute ca rezultat a dou comenzi SELECT, cu sintaxa:
SELECT lista_coloane1 FROM tabel1 [WHERE condiie1]
MINUS
SELECT lista_coloane2 FROM tabel2 [WHERE condiie2];

n limbajul SQL, produsul cartezian a dou tabele R i S se obine ca o
variant a instruciunii SELECT, ntr-una din formele:
SELECT * FROM R,S;
SELECT lista_coloane FROM R,S;
n prima form, limbajul SQL admite operaia produs cartezian i n situaia n
care n cele dou relaii operand exist dou atribute cu acelai nume, subnelegnduse c atributele rezultatului sunt ordonate, mai nti fiind atributele primei relatii, urmate
de atributele celei de-a doua relatii.
Pentru cea de-a dou form, atributele cu acelai nume trebuie s fie
calificate cu numele relaiei respective.

Restricia se exprim printr-o form particular a instruciunii SELECT,
n care lista de atribute este format din toate atributele unei singure relaii, iar clauza
WHERE este obligatorie i introduce condiia de restricie:
SELECT * FROM tabel WHERE conditie [clauze_secundare];
Deci in SQL restricia selecteaz o parte din liniile tabelului operand.

Operaia de proiecie se obine prin introducerea listei de coloane n
instruciunea SELECT ca lista a atributelor de proiecie. Sub forma:
SELECT DISTINCT lista_coloane FROM nume_tabel;
instruciunea SELECT reprezint o operaie de proiecie asupra relaiei nume_tabel pe
atributele date n lista_coloane.
Dac lipsete clauza DISTINCT i lista de atribute nu este o supercheie a
relaiei, rezultatul operaiei poate conine tupluri duplicat (deci nu este o relaie n
sensul definiiei din modelul relaional), astfel in SQL proiecia realizeaz o selecie a
coloanelor unui tabel.

-jonciunea se poate exprima direct cu o instruciune SELECT pe dou
sau mai multe tabele, condiia de jonciune fiind introdus prin clauza WHERE.

O jonciune natural se poate exprima n limbajul SQL numai n mod
explicit, adic trebuie ca lista de atribute a instruciunii SELECT s conin numai
atributele diferite din cele dou relaii (fiecare atribut de jonciune se introduce o
singur dat), iar n clauza WHERE trebuie introdus condiia de egalitate a atributelor
corespondente.

Diviziunea se exprim introducnd n instruciunea SELECT explicit lista
atributelor de proiecie i condiia de egalitate a atributelor corespondente din cele
dou relaii prin clauza WHERE.
Exist dou situaii de rezolvare a interogarilor: interogri care se rezolv n
cadrul unei singure relaii i interogri care se rezolv folosind dou sau mai multe
relaii ale bazei de date.

70

Interogrile ntr-o singur relaie se fac atunci cnd toate atributele care
intervin n interogare (atributele de proiecie i atributele din condiie) sunt atribute ale
unei singure relaii R i se poate rezolva la nivelul acelei relaii, ca o proiecie (pe
atributele relaiei rezultat) a restriciei cu condiia impus asupra relaiei date, prin
expresia:
Q=

(R)
lista_atribute

conditie

Interogri n dou sau mai multe relaii.n situaia n care atributele de

proiecie i atributele din condiia de interogare nu aparin unei singure relaii, pentru
rezolvarea interogrii trebuie s fie folosite toate acele relaiile care, mpreun, conin
aceste atribute.
Conceptual, o astfel de interogare se rezolv construind mai nti o relaie
care s conin toate atributele necesare prin combinarea a dou sau mai multe relaii
folosind operaii de produs cartezian sau jonciuni, iar rezultatul interogrii se obine
prin restricia (cu condiia de interogare) i proiecia (pe atributele de proiecie) a
acestei relaii.
Cazul cel mai frecvent de interogare necesit jonciunea natural a dou sau
mai multe relaii asociate, folosind perechea de atribute cheia strin - cheia primar
referit pentru fiecare operaie de jonciune:

(R >< S >< T...)

Q=
lista_atribute

conditie

D. Exemplificarea interogrilor folosind comenzi SQL pe o baz de date Oracle

Fie tabelele ANGAJATI, FURNIZORI, SECTII avnd urmtoarea structur i
coninut:
ANGAJATI

FURNIZORI

SECTII

Reuniunea tabelelor ANGAJATI si FURNIZORI se obtine cu:

SELECT Nume,Prenume FROM ANGAJATI WHERE Adresa = Bucuresti

UNION
SELECT Nume,Prenume FROM FURNIZORI;
Rezultatul acestei instructiuni este:
NUME

PRENUME
71

-------------------- -------------------Ionescu
Ion
Mihailescu
Dan
Pavelescu
Ioana
Petrescu
Ana
Popescu
Petre
Radu
Mihaela


Intersectia tabelelor ANGAJATI si FURNIZORI se obtine cu:

SELECT Nume,Prenume FROM ANGAJATI WHERE Adresa = Bucuresti

INTERSECT
SELECT Nume,Prenume FROM FURNIZORI;
Rezultatul acestei instructiuni este:

NUME
PRENUME
-------------------- -------------------Popescu
Petre
Diferenta pe tabelele ANGAJATI si FURNIZORI:

SELECT Nume,Prenume FROM ANGAJATI WHERE Adresa = Bucuresti

MINUS
SELECT Nume,Prenume FROM FURNIZORI;
Rezultatul acestei instructiuni este:
NUME
PRENUME
-------------------- -------------------Ionescu
Ion
Pavelescu
Ioana
Radu
Mihaela

Proiectia pe tabela ANGAJATI cu ajutorul clauzei DISTINCT:
SELECT DISTINCT Nume,Prenume FROM ANGAJATI;
elimina dublura Ionescu Ion
NUME
PRENUME
-------------------- -------------------Ionescu
Ion
Pavelescu
Ioana
Popescu
Petre
Radu
Mihaela

Produsul cartezian al tabelelor SECTII si ANGAJATI se obtine cu:
SELECT * FROM ANGAJATI,SECTII;
Rezultatul acestei instructiuni este:

72

IDANGAJAT NUME PRENUME DATANASTERII ADRESA FUNCIE SALARIU IDSECTIE IDSECTIE NUME
------------- ---------- ------------- ------------------ ---------- ----------- ----------- ------------ ---------------------------------------------- -------1
Ionescu
Ion
11.12.1960
Bucureti inginer 5000
1
1
Proiectare
2
Popescu Petre
10.04.1967
Bucureti arhitect 4500
1
1
Proiectare
3
Pavelescu Ioana
11.03.1970
Bucureti desenator 2500
1
1
Proiectare
4
Radu
Mihaela
04.06.1966
Bucureti contabil 3500
2
1
Proiectare
5
Ionescu
Ion
08.10.1965
Bucureti casier
2000
2
1
Proiectare
1
Ionescu
Ion
11.12.1960
Bucureti inginer 5000
1
2
Contabilitat
2
Popescu Petre
10.04.1967
BucurestI arhitect 4500
1
2
Contabilitat
3
Pavelescu Ioana
11.03.1970
BucurestI desenator 2500
1
2
Contabilitat
4
Radu
Mihaela
04.06.1966
Bucureti contabil 3500
2
2
Contabilitat
5
Ionescu
Ion
08.10.1965
Bucureti casier
2000
2
1
Proiectare


Jonctiunea naturala a tabelelor ANGAJATII si SECTII se obtine legand
coloanele IdSectie ale celor doua tabele:
SELECT IdAngajat,ANGAJATI.Nume,Prenume,DataNasterii,
Adresa,Salariu,SECTII.IdSectie,SECTII.Nume,Locatie
FROM ANGAJATI,SECTII
WHERE ANGAJATI.IdSectie = SECTII.IdSectie;
Rezultatul acestei instructiuni este:
IDANGAJAT NUME
PRENUME DATANASTERII ADRESA SALARIU IDSECTIE NUMESECTIE LOCAIE
--------------- --------------- --------------- ---------------------- ------------- --------------- -------------- ------------------- ------------1
Ionescu
Ion
11.12.1960
Bucureti 5000
1
Proiectare
Bucureti
2
Popescu Petre
10.04.1967
Bucureti 4500
1
Proiectare
Bucurest
3
Pavelescu Ioana
11.03.1970
Bucureti 2500
1
Proiectare
Bucurest
4
Radu
Mihaela
04.06.1966
Bucuresti 3500
2
Contabilitate
Ploiest
5
Ionescu
Ion
08.10.1965
Bucureti 2000
2
Contabilitate
Ploiesti


Interogare intr-o singur relatie: Care sunt numele,prenumele si salariul
angajailor in sectia cu numarul 1? Raspunsul la aceasta intrebare se obtine cu
urmatoarea interogare pe tabela ANGAJATI:
SELECT Nume,Prenume,Salariu FROM ANGAJATI WHERE IdSectie = 1;
Rezultatul este:
NUME
PRENUME
SALARIU
-------------------- -------------------- -----------------------Ionescu
Ion
5000
Popescu
Petre
4500
Pavelescu
Ioana
2500

Interogare n dou relaii: Care sunt numele,prenumele si salariul angajailor in
sectia cu numele Contabilitate? Raspunsul la aceasta intrebare se obtine cu o
interogare de tip jomctiune pe tabelele ANGAJATI si SECTII:
SELECT ANGAJATI.Nume,Prenume,Salariu
FROM ANGAJATI,SECTII
WHERE ANGAJATI.IdSectie = SECTII.IdSectie and SECTII.Nume=' Contabilitate';
Rezultatul este:
NUME
PRENUME
SALARIU
-------------------- -------------------- ----------------------Radu
Mihaela
3500
Ionescu
Ion
2000
2.4. Optimizarea interogrilor folosind limbajul SQL
n condiiile realizrii de aplicaii bazate pe tehnologia client/server i
destinate lucrului n reea, fie local sau Internet, este deosebit de important fiecare
aspect care determin mbuntirea performanelor unei baze de date. Pe lng

73

msurile ce pot fi luate n privina creterii capacitii hardware se pot cuta soluii
pentru a optimiza aplicaiile astfel nct s ruleze mult mai repede. :
Urmtoarele patru tehnici mbuntesc performanele interogrilor folosind
limbajul SQL pe o baza de date Oracle:

utilizarea clauzei WHERE n detrimentul clauzei HAVING.
Exemplu: Se dorete gruparea cantitilor vndute pe produse i se utilizeaz
clauza HAVING pentru a selecta numai anumite produse (produsele cu denumirile
Chocolade sau Tarte au sucre). Dac n loc de HAVING se utilizeaz WHERE, se
reduce numrul liniilor (nregistrrilor) care trebuie grupate, deci aceasta este maniera
mai eficient, n condiiile n care rezultatul este acelai.
SELECT Products.ProductName,
Sum([Order
Details].Quantity)
SumOfQuantity
FROM
Products INNER JOIN [Order
Details] ON Products.ProductID = [Order
Details].ProductID
WHERE
Products.ProductName=Chocolade Or
Products.ProductName=Tarte au sucre
GROUP BY Products.ProductName;

SELECT
Products.ProductName,
Sum([Order
Details].Quantity) SumOfQuantity
FROM Products INNER JOIN [Order
Details]
ON Products.ProductID = [Order
Details].ProductID
GROUP BY Products.ProductName
HAVING
Products.ProductName=Chocolade Or
Products.ProductName=Tarte au sucre;


utilizarea cuvntului cheie DISTINCT pentru a gsi o list de nregistrri distincte,
n loc de GROUP BY.
Exemplu: Dac se dorete selectarea numai a produselor pentru care s-au
nregistrat comenzi, trebuie aplicat un SELECT asupra tabelei ORDER DETAILS din
baza de date Northwind. Pentru a furniza o singur dat denumirea produsului, se
poate folosi DISTINCT sau GROUP BY, cu precizarea c prima variant este mai
eficient n cazul unei baze de date cu dimensiuni foarte mari (de ordinul milioanelor de
nregistrri):
SELECT
DISTINCT
Details].ProductID
FROM [Order Details];

[Order SELECT [Order Details].ProductID

FROM [Order Details]
GROUP BY [Order Details].ProductID;

utilizarea cererilor imbricate (SELECT n SELECT) n locul tabelelor temporare

Exemplu:
Fie urmtoarele tabele:
PRODUSE(CodProdus,DenumireProdus,PreUnitarRef);
COMENZI(NrComand,DataComenzii);
DETALII_COMENZI(NrComand,CodProdus,Cantitate,PreUnitar, Discount).
Se dorete realizarea unei interogri care s returneze informaii (cantitile)
despre cele mai recente 5 comenzi. Dintre urmtoarele dou variante de rezolvare a
acestei probleme se recomand cea de-a doua care, pe lng faptul c este mai
eficient, este i mai scurt dect prima.
Varianta 1: Crearea unei tabele temporare (COMENZI_TEMP) (A), introducerea
datelor n ea (B), crearea de relaii ntre tabela temporar i celelalte i returnarea
datelor (C) i renunarea la tabela temporar (D).
(A) CREATE TABLE
COMENZI_TEMP (NrComand INTEGER NOT NULL,
DataComenzii DATE NOT NULL);

(B)

INSERT INTO COMENZI_TEMP(NrComanda,DataComenzii)

74

(SELECT c.NrComand, c.DataComenzii

FROM COMENZI c ORDER BY c.DataComenzii DESC);
(C) SELECT p.DenumireProdus,SUM(dc.Cantitate) CantitateProdus
FROM COMENZI_TEMP t
INNER JOIN DETALII_COMENZI dc ON t.NrComand=dc.NrComand
INNER JOIN PRODUSE p ON dc.CodProdus=p.CodProdus
GROUP BY p.DenumireProdus
ORDER BY p.DenumireProdus;
(D) DROP TABLE COMENZI_TEMP;
Varianta 2: Se utilizeaz o cerere imbricat, respectiv o cerere care este apelat
n clauza FROM. Aceast variant evit operaiile de intrare/ieire ale primei variante i
totodat economisete spaiu pe disc, conducnd la acelai rezultat.
SELECT p.DenumireProdus, SUM(dc.Cantitate) CantitateProdus
FROM
(SELECT c.NrComand,c.DataComenzii FROM Comenzi c
ORDER BY c.DataComenzii DESC) t
INNER JOIN DETALII_COMENZI dc ON t.NrComand = dc.NrComand
INNER JOIN PRODUSE p ON dc.CodProdus = p.CodProdus
GROUP BY p.DenumireProdus ORDER BY p.DenumireProdus;

evitarea folosirii LEFT JOIN-urilor i valorilor NULL, n situaiile n care acest
lucru este posibil. Legturile la stnga sunt costisitoare deoarece implic identificarea
datelor cu valori NULL (non-date). O interogare care utilizeaz LEFT JOIN este mult
mai costisitoare dect una care folosete INNER JOIN. O procedur simpl de evitare
a ncetinirilor provocate de LEFT JOIN este de a proiecta baza de date astfel nct
acestea s fie ocolite.
Exemplu: Se dorete listarea tuturor produselor i a categoriilor lor, n situaia
n care anumite produse nu au categorie pe linia sa i pe coloana categoriei va aprea
o valoare NULL. Pentru a elimina acest lucru se poate crea o categorie cu valoarea
lipsa categorie. Procednd astfel, se poate utiliza un INNER JOIN pentru a selecta
toate produsele i categoriile lor. O alt modalitate care poate prea mai dificil
deoarece necesit doi pai, dar care d rezultate const n crearea unei machete de
tabel n care s fie stocate datele att din partea corespunztoare LEFT JOIN-ului,
ct i cele din cealalt tabel.

3. DATAWAREHOUSE
3.1. Introducere n depozitele de date
Conceptul original de depozit de date a fost definit de IBM ca fiind un depozit de
informaii i prezentat ca o soluie pentru accesarea datelor deinute n sisteme nonrelaionale. Datorit complexitii i problemelor de perfoman asociate cu
implementarea unor asemenea soluii, ncercrile de a crea un depozit de informaii au
fost respinse. De atunci conceptul de depozit de date a fost de mai multe ori abordat ,
dar numai n ultimii ani aceast soluie a fost vzut ca fiind una viabil i valoroas.
Ultimul i cel mai de succes avocat al depozitelor de date este William H. Inmon, care
a catigat titlul de printe al depozitelor de date datorit promovrii active a acestui
concept.
Conform definiiei lui William H. Inmon din 1993, un depozit de date este a
subject-oriented, integrated, time-variant and nonvolatile collection of data in support of
management's decision making process. Privind enunul cu ochiul unui matematician,
acesta ar putea fi descompus ntr-o definiie ("un depozit de date este o colectie de
date destinate fundamentrii deciziei manageriale") i o caracterizare ("o astfel de

75

colecie de date este (1) tematic, (2) integrat, (3) corelat cu contextul temporal i (4)
permanent").

3.2. Evoluia depozitelor de date

nc din anii 70 organizaiile i-au concentrat investiiile n sisteme informatice n
scopul automatizrii proceselor de afaceri. Eforturile n aceast direcie au generat
generaii de acronime care au fcut epoc i apoi au apus: MIS (Management
Information Systems), DSS (Decision Support Systems), EIS (Executive Information
Systems), MSS (Management Support Systems).
Depozitele de date, sub un nume sau altul, au aprut n gndirea comunitii
informatice la sfritul anilor 80. La nceputul anilor 90 ideea a captt contur, iar IBM
s-a grbit s protejeze n nume propriu termenul Information Warehouse. Cu toate
acestea, viziunea IBM se referea mai degrab la conectivitatea global a diverselor
surse de date, fiind un fel de "middleware generalizat" bazat pe arhitectura proprie
DRDA - Distributed Relational Database Architecture.
Ideea "depozitelor de date" nu este nou. Cu toate acestea, termenul Data
Warehouse a devenit un termen la mod", reprezentnd totodat o realitate
tehnologic pus n practic din ce n ce mai frecvent.
William H. Inmon, vicepresedintele firmei Prism Solutions, este printele
necontestat a noiunii n nelesul ei curent (Inmon deine de altfel trademark-ul
termenului Data Warehouse). Viziunea sa despre depozitele de informaii se
concentraz asupra rolului acestora de baz informaional a deciziei util oricrui
factor de conducere, pstrnd astfel un nivel nalt de generalitate i permind unor
multiple implementri s intre n sfera acestei noiuni.
Un alt nume important n acest cadru este cel al lui Earl Hadden, cel care a
enunat, a fundamentat i a experimentat cu succes o metodologie riguroas pentru
implementarea rapid a depozitelor de date (90 day winners). O serie de firme
comerciale i-au adus la rndul lor contribuia la clarificarea, dezvoltarea i
popularizarea noii tehnologii. Printre acestea se remarc Software AG, Oracle, Red
Brick Systems, Prism Solutions, MicroStrategy, etc.
n timp ce sistemele moderne de baze de date se dezvolt n multe direcii, o larg
familie de noi aplicaii au fost create i poart denumirea de sisteme de integrare a
informaiei. Aceste aplicaii preiau date care sunt stocate n dou sau mai multe baze
de date (sursele informaiei) i din acestea costruiesc o baza de date mare, posibil
virtual, care conine informaii din toate sursele, astfel ncat datele s poat fi
interogate n mod unitar.
Sursele pot fi baze de date convenionale sau alte tipuri de informaii precum
colecii de pagini web.
Exist mai multe modaliti prin care bazele de date sau alte surse de informaii,
eventual distribuite, pot fi fcute s lucreze mpreun. Cele mai cunoscute abordri
sunt:

Bazele de date asociate (Federated databases) sursele sunt independente, dar

una dintre surse le solicit celorlalte s ii furnizeze informaii

Depozitul de date (Warehousing) copii ale datelor din mai multe surse sunt
stocate ntr-o singur baz de date, numit depozit de date. Este posibil ca nainte de
stocarea n depozit, datele s fie procesate n anumite moduri, de ex. datele pot fi

76

filtrate, relaiile pot fi unite sau agregate. Depozitul de date se actualizeaz periodic, de
obicei acest proces desfurndu-se noaptea. ntrucat datele sunt copiate din surse,
acestea au nevoie de anumite transformri ca s fie conforme cu schema depozitului
de date.

Intermedierea (Mediation) reprezint o component software care suport o

baz de date virtual pe care utilizatorul o poate interoga ca i cum ar fi materializat
(construit fizic, precum un depozit de date). Mediatorul nu stocheaz date, ci mai
degrab translateaz interogarea utilizatorului n una sau mai multe interogri printre
sursele sale. Mediatorul sintetizeaz rspunsul la interogarea utilizatorului din
rspunsurile primite de la surse i apoi returneaz rspunsul utilizatorului.

3.3. Conceptul de depozit de date

Aa cum am artat mai sus, descrierea conceptului de data warehouse propus
de W. Inmon este compus dintr-o definiie i o caracterizare.
Vom ncepe cu definiia. Astfel, genul proxim l reprezint o colecie de date.
Datele din data warehouse provin n principal din datele capturate din sistemul
operaional, dar mai pot proveni din datele de arhiv (n perioada de constituire a
depozitului) precum i din surse externe, cum ar fi baze de date publice. Cteva
exemple posibile sunt: date demografice (obinute n urma unui recensmnt), date
statistice (furnizate de institute specializate), date de prognoz economic (furnizate de
instituii orientate pe studiul pieei), date obinute n urma unor sondaje de opinie etc.
Aceste date pot fi cumprate, pot fi preluate pe baz de abonament sau pot fi date
publice gratuite.
Diferena specific se refer la faptul c depozitele sunt destinate fundamentrii
deciziei manageriale. Spre deosebire de coleciile de date utilizate de sistemul
operaional - orientate spre optimizarea i sigurana procesrii datelor - datele dintr-un
depozit de date sunt organizate ntr-o manier care s permit analizarea lor, deci
extragerea semnificaiei economice pe care o reprezint. Rolul unui depozit de date
este de a oferi o imagine coerent asupra datelor relative la activitatea unei organizaii
i a contextului n care acesta acioneaz. Utilizarea acestei colecii poate consta din
extragerea unor rapoarte (la cerere sau pe baza unui "abonament" cu o anumit
periodicitate), extragerea unor date pentru a fi utilizate de aplicaiile de birotic
(programe de calcul tabelar, procesoare de text, programe de prezentare etc.), dar mai
ales pentru a fi utilizate de ctre aplicaii specializate de analiz. Acestea ar putea fi
mprite n dou categorii: instrumente de analiz on-line (OLAP - On Line Analytical
Processing - aplicaii axate pe analiz multidimensional) i instrumente pentru
"minerit" n date (data mining - aplicaii axate pe descoperirea unor abloane
semnificative n colecii de date).
Dar partea cea mai consistent a enunului lui W. Inmon const n caracterizarea
acestor colecii de date destinate analizei. n continuare le vom examina pe rnd.
A. Orientare tematic
S remarcm pentru nceput c datele operaionale sunt orientate pe aplicaii, n
sensul c organizarea lor este optimizat pentru a servi procesului tranzacional,
dinamicii sistemului. n contrast, depozitul de date este orientat pe subiectele
importante ale procesului economic, cum ar fi: clieni, furnizori, produse, activiti.

77

Un exemplu simplu poate fi edificator: o comand lansat de un client va fi

consemnat de sistemul operaional printr-un set de nregistrri care vor contine
informaii despre client, informaii despre produsele sau serviciile comandate, informatii
despre modul de transport i modul de plat etc. Atenia sistemului tranzacional este
orientat ctre consistena cheilor, astfel nct operaia s pstreze consistena. Multe
dintre datele eseniale din perspectiv operaional (numrul comenzii, poziiile liniilor
n cadrul comenzii etc.) sunt complet lipsite de relevan din perspectiv
informaional.
O consecin important a acestei orientri este redundana datelor. Dac n
sistemul operaional redundana este minimizat (prin procesul de normalizare) pentru
a evita anomaliile de actualizare, n depozitul de date redundana este creat n mod
intenionat (prin denormalizare i sintetizare) pentru a permite un acces tematic mai
facil.
B. Integrare
Este cel mai important aspect al depozitului de date i, n cele din urm, raiunea
pentru care acesta este creat. Datele sunt adunate aici pentru a rspunde nevoilor
informaionale ale ntregii organizaii, asigurnd faptul c rapoartele generate pentru
diverse compartimente vor conine aceleai rezultate. Sistemul operaional este de cele
mai multe ori format din subsisteme semi-independente, create la momente diferite, de
echipe diferite, n maniere diferite, rezultnd o babilonie care, dei funcional, este
imposibil de folosit pentru analiz.
Integrarea datelor provenind din sistemul operaional i din alte surse se refer la
numeroase aspecte:
Convenii unice privind denumirile datelor - n sistemul operaional acestea difer
de la aplicaie la aplicaie;
Modaliti unice de codificare - e suficient s ne gndim la nenumratele variante
de a codifica sexul: ('m', 'f'), (0, 1), (True, False) etc. Este evident c o aplicaie pentru
analiz va trebui s se bazeze pe o codificare consistent;
Sistem de uniti de msur consistent - lungimi, suprafee, volume, greuti,
temperaturi, etc, toate trebuie exprimate ntr-un set unic de uniti de msur;
Sistem stabil de reprezentare fizic a datelor - n aplicaiile tranzacionale este
posibil ca aceleai date s fie memorate n moduri diverse;
Convenii clare privind modul de reprezentare a datelor calendarisice, a timpului
etc.
C. Contextul temporal
Sistemul operaional al unei organizaii tinde mereu s reflecte realitatea curent.
Astfel, el se afl ntr-o continu evoluie iar datele pe care le conine sunt relevante
doar pentru momentul n care sunt accesate. Orizontul de timp pe care l acoper este
de regul de 60 pn la 90 de zile, deoarece dup acest interval tranzaciile efectuate
sunt arhivate, fiind considerate deja de domeniul istoriei, deci neinteresante din
perspectiv operativ.
Pentru nevoile analizei economice, dimpotriv, informaiile cu caracter istoric sunt
eseniale, deoarece ele pun n eviden tendine care reprezint fundamentul unei
prognoze corecte. Depozitul de date se constituie ntr-un istoric al sistemului
operaional, constituit dintr-o serie de "instantanee", imagini la diverse momente n
timp. Orizontul de timp pe care l acoper depozitul de date este de cel puin cinci ani,

78

ajungnd uneori la zece ani, n funcie de dinamica evoluiei pieei i, deci, de relevana
datelor cu caracter istoric pentru nevoile analizei.
Din punct de vedere tehnic, acesta implic faptul c orice nregistrare din
depozitul de date poate fi plasat n timp. Orice cheie de acces cuprinde i o variabil
temporal.
D. Permanena
Esena aplicaiilor operaionale este actualizarea continu a coleciilor de date,
actualizare realizat n general pe baz tranzacional. Orice tranzacie procesat
implic inserarea unor noi nregistrri, modificarea sau eventual tergerea altora etc.
Cu totul altfel stau lucrurile n cazul depozitului de informaii, unde o astfel de dinamic
lipsete. Practic, singura actualizare care se realizeaz aici este adugarea periodic a
unor date extrase din sistemele operative. Din punctul de vedere al aplicaiilor care
folosesc depozitul de date, accesul la date este doar pentru citire.
Din punctul de vedere al proiectrii, acest diferen este extrem de important. n
sistemul operaional, o tranzacie trebuie s duc colecia de date dintr-o stare
consistent ntr-o alt stare consistent, iar aceast implic mecanisme extrem de
complexe de meninere a integritii datelor, mai ales n situaia sistemelor intens
concureniale: mecanisme de jurnalizare, mecanisme de salvare/restaurare/refacere,
mecanisme de detectare a blocrilor circulare (deadlock) etc. n cazul depozitelor de
date aceste mecanisme sunt inutile, astfel c gradul de libertate ctigat poate fi utilizat
pentru optimizarea accesului la date prin denormalizare, sintetizare, statistici ale
accesrii datelor i reorganizare dinamic a indexrii etc.
Totui, indiferent de definiia depozitului de date, scopul principal al acestuia este
de a integra datele corporaiilor mari ntr-un singur depozit din care utilizatorii pot rula
diverse interogri, pot produce rapoarte i efectua analize.

3.5. Comparaie ntre sistemele OLTP i depozitele de date

Un sistem de management al bazelor de date construit pentru procesarea
tranzaciilor on line este privit, n general, ca fiind nepotrivit pentru depozitele de date,
deoarece fiecare sistem este conceput cu seturi de cerine diferite. De exemplu,
sistemele online transactional processing (OLTP) sunt construite pentru a maximiza
capacitatea de procesare a tranzaciilor, n timp ce depozitele de date sunt construite
pentru a fi suport n procesarea ad-hoc a interogrilor.
Cu toate c sistemul OLTP i depozitele de date au caracteristici diferite i sunt
construite pentru diferite scopuri, acestea sunt strns legate ntre ele ntrucat sistemele
OLTP constituie sursele pentru depozitele de date. O problem major a acestei relaii
o constituie faptul c datele deinute de sistemul OLTP pot fi inconsistente, fragmentate
i constituie subiect la schimbrii, coninnd duplicate sau elemente lips. n asemenea
situaii datele operaionale trebuie curate naintea introducerii n depozitul de date.
n timp ce sistemul OLTP deine date curente i detaliate, depozitul de date
conine date istorice, att detaliate, ct i sintetizate. De asemenea, n timp ce datele
din sistemul OLTP sunt dinamice, iar procesrile sunt repetitive, cele din depozitul de
date sunt statice iar procesrile ad hoc, nestructurate i euristice. Sistemul OLTP este
orientat pe aplicaii, ajut la luarea deciziilor zilnice i servete un numr mare de
utilizatori operaionali, n timp ce depozitele de date sunt orientate pe subiect, ajut la

79

luarea deciziilor strategice i servete un numr relativ mic de utilizatori care sunt, n
general, manageri.

3.6. Probleme asociate depozitelor de date

Problemele care pot s apar n contextul dezvoltrii i administrrii depozitelor
de date sunt urmtoarele:

subestimarea resurselor pentru ncrcarea datelor muli dezvoltatori

subestimeaz timpul necesar pentru extragerea, curarea i ncrcarea datelor n
depozit. Acest proces poate dura pan la 80% din timpul total al dezvoltrii, dei unelte
eficiente pentru managementul i curarea datelor pot reduce timpul alocat.

probleme ascunse legate de sistemele surs problemele ascunse asociate cu

sistemele surs care alimenteaz depozitul pot fi identificate dup caiva ani n care nu
au fost detectate. Dezvoltatorul trebuie s decid dac s rezolve problema n depozit
i/sau n sistemele surs. De exemplu, cand se introduc date de detaliu despre
proprieti noi anumite campuri permit valori nule, ceea ce poate conduce la
introducerea incomplet sau incorect a datelor, chiar i atunci cand acestea sunt
disponibile.
datele solicitate nu au fost capturate proiectele aferente depozitelor de date
adesea subliniaz cerine pentru date care nu au fost capturate de sistemele surs
existente. n acest caz oganizaia trebuie s decid dac s modifice sistemul OLTP
sau s creeze un sistem dedicat care s captureze informaia care lipsete.
cereri crescande ale utilizatorilor finali dup ce utilizatorii finali primesc uneltele de
interogare i de raportare, cererile din partea utilizatorilor finali pot s creasc n loc s
descreasc, acest fapt fiin posibil datorit nencrederii utilizatorilor n acurateea datelor
din depozit. Aceast problem poate fi parial ameliorat prin invstirea n unele unelte
mai puternice i mai uor de utilizat sau n pregtirea, respectiv instruirea mai
temeinic a utilizatorilor finali. Un alt motiv pentru creterea cererilor utilizatorilor
adresate persoanelor de la suport IT poate fi acela c din momentul n care depozitul
de date este on line crete i complexitatea interogrilor, nu numai numrul acestora.
omogenizarea datelor o scal larg a datelor care intr n depozit constituie un
adevrat exerciiu pentru designer-ul depozitului de date care trebuie s redea o
viziune consolidat i integrat a datelor organizaiei. Designer-ul poate fi tentat s
pun un accent mai mare pe similitudinile decat pe diferenele dintre datele utilizate n
diverse aplicaii.
cerere mare de resurse depozitele de date necesit spaii foarte mari pe suporturi
informatice. Multe baze de date relaionale utilizate pentru suportul deciziilor folosesc
scheme tip star, snowflake sau starflake (a se vedea cap.6), fiind astfel necesar
crearea unor tabele foarte mari. Combinarea tabelelor i a indecilor agregai poate
necesita mai mult spaiu decat datele organizate pe linii.
proprietatea datelor depozitul de date poate schimba atitudinea utilizatorilor finali
cu privire la proprietatea datelor. Astfel, date sensibile utilizate de departamente
precum vanzri sau marketing pot fi accesibile i altor persoane din cadrul organizaiei.
mentenan de un nivel calitativ nalt depozitele de date sunt sisteem care
necesit un nivel de mentenan nalt. Orice reorganizare a proceselor de business
sau a sistemelor surs poate afecta datele din depozit. Pentru a rmane o resurs de

80

ncredere, depozitul de date trebuie s raman consistent pentru organizaia pe care o

susine.
proiecte de lung durat dup ce este constituit, depozitul de date reprezint
singura surs de informare pentru organizaie. Crearea unui depozit de date poate
dura pan la trei ani, fapt ce poate determina unele organizaii s i constituie structuri
care se construiesc mai rapid, respectiv data marturi care s rspund cerinelor unor
anumite departamente ale organizaiei.
complexitatea integrrii cea mai important arie n organizarea depozitului de date
este integrarea. Aceasta nseamn c organizaiei i este necesar o perioad
semnificativ de timp pentru a determina cat de bine pot fi integrate n soluia final
diferitele unelte ale depozitului de date. Aceasta poate fi o sarcin dificil dat fiind
numrul de unelte pentru fiecare operaie din depozit, care trebuie integrat
corespunztor astfel ncat s depozitul s lucreze n beneficiul organizaiei.

3.7. Dousprezece reguli care definesc un depozit de date

n anul 1994, William H. Inmon i Chuck Kelly au creat o list cu dousprezece
reguli de care trebuie s se in cont la definirea unui depozit de date, astfel:
1. depozitul de date i mediul operaional trebuie s fie separate,
2. datele din depozitul de date trebuie s fie integrate,
3. depozitul de date conine date istorice referitoare la o lung perioad de timp,
4. datele din depozitul de date sunt date instantaneu capturate la un anumit moment
n timp,
5. datele din depozitul de date sunt orientate spre obiect,
6. datele din depozitul de date sunt n principal read-only cu actualizri de batch
periodice din datele operaionale. Nu sunt permise actualizri on-line,
7. ciclul de via al dezvoltrilor de depozite de date difer de dezvoltarea sistemelor
clasice. n timp ce dezvoltarea depozitului de date este condus de date, abordarea
clasic este condus de procese,
8. depozitul de date conine date cu mai multe nivele de detalii: date de detaliu
curente, date de detaliu vechi, date uor sintetizate i date puternic sintetizate,
9. mediul depozitului de date este caracterizat prin tranzacii de tip read-only aplicate
la seturi de date foarte mari. Mediul operaional este caracterizat prin numeroase
tranzacii de actualizare aplicate la un set mic de date la un moment dat,
10. mediul depozitului de date are un sistem care traseaz sursele datelor,
transformrile si stocarea acestora,
11. metadatele depozitului de date reprezint o component critic a mediului. Astfel,
metadatele identific i definesc toate toate elementele caracteristice ale datelor.
Metadatele furnizeaz sursa, transformarea, integrarea, stocarea, folosirea, relaiile i
istoricul fiecrui element al datelor,
12. depozitul de date conine un mecanism charge-back pentru utilizarea resurselor,
care impune utilizarea optim a datelor de ctre utilizatorul final.

3.8. Arhitectura depozitelor de date

A. Componentele unui depozit de date
Componentele principale ale unui depozit de date sunt:
- Datele operaionale sursa datelor din depozitul de date provine din:
81

- datele operaionale mainframe deinute n primele generaii de baze de date.

Se estimeaz c majoritatea datelor operaionale corporate sunt deinute n
asemenea sisteme,
o datele din departamentele organizaiei stocate n sisteme de fiiere precum
VSAM, RMS i baze de date relaionale precum Informix, Oracle etc,
o datele private deinute pe staiile de lucru i pe serverele private,
o sistemele externe precum Internet, baze de date comerciale sau bazele de date
asociate cu furnizorii i clienii organizaiei.
- Load manager-ul (denumit i componenta front-end) efectueaz toate operaiile
asociate cu extragerea i ncrcarea datelor n depozitul de date. Aceste operaiuni
includ simple transformri ale datelor astfel ncat s le pregteasc s intre n depozit.
Dimensiunea i complexitatea acestei componente variaz de la un depozit la altul i
poate fi construit folosind o combinaie de unelte de ncrcare de date i de programe
de costumizare a construirii, procurate de la mai muli furnizori de soft.
- Managerul depozitului de date aceast component efectueaz toate operaiile
asociate gestionrii datelor din depozit. Aceast component este construit folosind
unelte de management al datelor i programe de customizare procurate de la furnizorul
de soft. Operaiile efectuate de managerul depozitului de date includ:
o analiza datelor pentru a se asigura consistena acestora
o transformarea i fuzionarea datelor surs din locaiile de stocare temporar n
tabelele depozitului de date
o crearea indecilor i a view-urilor pe baza tabelelor
o generarea denormalizrilor (dac este necesar)
o generarea agregrilor (dac este necesar)
o back-up-ul i arhivarea datelor.
n unele cazuri managerul depozitului de date genereaz profile de interogri astfel
ncat s determine care indeci i agregri sunt mai potrivite. Un profil de interogri
poate fi generat pentru fiecare utilizator, pentru fiecare grup de utilizatori sau pentru
depozitul de date i se bazeaz pe informaia care descrie caracteristicile interogrilor,
precum frevena, tabela target i dimensiunea setului de rezultate.
- Managerul interogrilor (denumit i componenta back-end) efectueaz toate
operaiile asociate managementului interogrilor utilizatorului. Aceast component
este construit utilizand de obicei unelte ale furnizorului de soft pentru accesul
utilizatorilor finali la date, unelte de monitorizare a depozitelor de date, faciliti ale
bazelor de date i programe de customizare a construirii. Complexitatea managerului
interogrilor este determinat de facilitile furnizate de uneltele de acces ale
utilizatorilor finali la date i de bazele de date. Operaiile efectuate de aceast
component includ interogri directe asupra tabelelor i programarea execuiei
interogrilor.
n unele cazuri managerul interogrilor genereaz profile de interogri care s
permit managerului depozitului de date s determine care indeci i agregri sunt
potrivite.
- Uneltele de acces ale utilizatorului final scopul principal al depozitului de date
este acela de a furniza informaii utilizatorilor pentru a lua decizii strategice. Aceti
utilizatori interacioneaz cu depozitul de date prin intermediul uneltelor de acces.
Depozitul de date trebuie s suporte eficient analize ad-hoc i de rutin. Se pot obine
o

82

performane bune prin pre-planificarea cerinelor de jonciune, sintetizare i stabilire de

rapoarte periodice ctre utilizatorii finali. Dei definiiiile se pot suprapune pentru unele
aspecte, mprim aceste unelte n cinci categorii: unelte de raportare i interogare,
unelte de dezvoltare a aplicaiilor, unelte pentru sisteme de informaii executive, unelte
OLAP (on line analytical processing) i unelte de data mining.
- Datele detaliate n cele mai multe cazuri, datele detaliate nu sunt stocate on line,
ci sunt agregate la urmtorul nivel de detaliu. Totui datele detaliate sunt adugate la
depozit pentru a suplimenta datele agregate.
- Datele sintetizate (summarized) mai mult sau mai puin aceast zon a
depozitului stocheaz toate datele generate de managerul depozitului care sunt
predefinite ca fiind sintetizate mai mult sau mai puin. Aceast zon a depozitului
constituie subiectul schimbrii pe baze continue pentru a rspunde schimbrilor n
profilelor de interogare. Scopul sintetizrii informaiei este acela de a crete
performana interogrilor. Cu toate c sintetizarea presupune costuri operaionale
suplimentare iniiale, efortul merit datorit avantajelor ulterioare legate de
performan. Datele sintetizate sunt actualizate permanent pe msur ce date noi sunt
ncrcate n depozit.
- Arhivele i back-up-ul datelor aceast zon a depozitului de date stocheaz date
detaliate i date sintetizate n scopul arhivrii i crerii de copii. Chiar dac datele
sintetizate sunt generate din datele detalite, este necesar s se fac back-up-uri online
ale datelor sintetizate dac aceste date sunt pstrate pentru o perioad mai lung
decat cele detaliate. Datele sunt transferate pe benzi magnetice sau pe discuri optice.
- Metadatele - reprezint poate cea mai important component a depozitului de
date. Pentru a putea utiliza depozitul de date, utilizatorii trebuie s cunoasc ce date se
gsesc aici, iar metadatele nu sunt altceva dect date despre date, date care descriu
coninutul depozitului i furnizeaz trimiteri directe la date. Tot la nivelul metadatelor se
definesc i diverse vederi (views) asociate unor categorii specifice de utilizatori. Dar
metadatele nu sunt utile doar utilizatorului final. Ele sunt intens folosite pentru
administrarea depozitului de date, continnd informaii despre proveniena datelor,
algoritmii de agregare i nsumare, statistici privind utilizarea i multe altele.
Cnd se utilizeaz ntr-un depozit de date, metadatele sunt date care definesc
obiectele depozitului. Metadatele sunt create pentru numele de date i definiiile din
depozit. Metadatele adiionale sunt create pentru a asocia intervale de timp la datele
extrase i alte cmpuri care vor fi adugate prin curirea datelor sau prin procesele de
integrare.
Nivelul metadatelor trebuie s conin:
O descriere a structurii datelor din depozit, incluznd schema depozitului,
dimensiunile, ierarhiile, definiiile datelor derivate;
Metadatele operaionale, care includ date privind evoluia n timp (istoricul datelor i
secvena de transformare aplicat asupra lor), situaia datelor (active, arhivate sau
terse) i informaii de monitorizare (statistici privind utilizarea depozitului de date,
rapoarte de erori, mprtierea datelor etc.);
Algoritmi utilizai pentru nsumare, care includ msura i dimensiunea algoritmilor
definii, date despre granularitate, partiii, arii de subiecte, agregri, sintetizri, rapoarte
i filtre predefinite;

83

Transformrile datelor de la mediul operaional la depozitul de date i care includ

bazele de date, sursa i coninutul lor, partiionarea datelor, extragerea datelor,
curirea datelor, regulile de ntreinere i securitate a datelor;
Date relative la performanele sistemului care includ indicatori i profiluri care
mbuntesc accesul la date i performanele de cutare;
Metadate economice (business metadata), care includ termeni economici i
definiii, expresii i formule de calcul ale indicatorilor.
Metadatele se aplic pentru sursele de date, pentru programele i regulile de
extragere i transformare, pentru structura datelor i pentru coninutul propriu-zis al
depozitului de date. Importana metadatelor pentru depozitul de date reiese din faptul
c acestea stabilesc contextul depozitului de date, uureaz procesul de analiz,
menin i cresc calitatea datelor, dar i din faptul c sunt o form de auditare a
transformrii datelor.
Metadatele ajut administratorii i utilizatorii depozitului s localizeze i s
neleag secvenele de date att n sistemele sursa ct i n structura depozitului.
Dac metadatele care descriu formatul datelor din depozite sunt disponibile, atunci se
elimin orice ambiguitate legat de semnificaia datelor.
Metadatele menin i cresc calitatea datelor, fapt ce se realizeaz prin definirea
valorilor valide pentru fiecare cmp din depozit. nainte de a fi efectiv ncarcate n
depozit, datele pot fi revzute i erorile pot fi corectate, regulile de corecie a erorilor
pot fi documentate tot prin metadate. Se pot deosebi mai multe tipuri de metadate:
Metadate administrative. Acestea conin descrieri ale bazelor de date surs i ale
coninutului, ale obiectelor depozitului de date i ale regulilor folosite pentru a
transforma datele din sistemul surs n depozit. Printre exemple de astfel de metadate
menionm: descrirea tuturor sursele de date folosite, trecerea cmpurilor surs n
cmpuri destinaie, schema depozitului de date, structura datelor din back-end,
programe i instrumente back-end, reguli i formule de calcul, reguli de securitate i de
acces.
Metadate pentru utilizatorii finali. Aceste metadate au rolul de a ajuta pe utilizatori
s-i creeze propriile lor interogri i s interpreteze rezultatele. Pentru aceasta, ei au
nevoie s cunoasc definiiile datelor din depozit, descrierea lor, precum i orice
ierarhie care poate exista n diferite dimensiuni. Exemple de astfel de metadate sunt
urmtoarele: coninutul depozitului de date, rapoarte i interogri predefinite, definiiile
ierarhiilor, calitatea datelor, istoricul ncrcrii depozitului de date, reguli de eliminare.
Metadate pentru optimizare. Aceast categorie de metadate are rolul de a crete
performanele depozitului de date. Exemple de astfel de metadate sunt: definiiile
agregrilor i colecii de statistici.
Un depozit de date conine date pentru diferite perioade de timp i de aceea este
important s avem n vedere efectul pe care l poate avea timpul asupra regulilor de
trecere a cmpurilor surs n cmpuri destinaie, asupra agregrilor etc. Utilizatorii
trebuie s aib acces la metadatele corecte pentru perioada de timp pe care o
studiaz. Echipa IT are nevoie de aceste informaii pentru a putea ntretine depozitul
de date, iar ceea ce la prima vedere ar prea s fie o eroare n transformarea datelor
poate fi de fapt rezultatul schimbrii regulilor de transformare a datelor. De aceea este
important ca metadatele s fie corect gestionate din punct de vedere al versiunilor.

84

Dei n mod tradiional metadatele reprezint o component dezvoltat spre

sfrsitul ciclului de dezvoltare, la ora actual exist o tendin puternic de a atribui
metadatelor un rol mai important. Utilizatorii instrumentelor de extragere i
transformare pot specifica modul de trecere din cmpurile surs n cmpurile destinatie
i pot introduce toate regulile care guverzeaz transformarea. Tabelul surs-destinaie
poate servi ca baz pentru generarea codului de program folosit apoi la extragerea i
transformarea efectiv a datelor. Utilizatorii instrumentelor pentru calitatea datelor pot
specifica valorile valide pentru diferite secvene de date att n sistemele surs, ct i
n depozitul de date. Aceste instrumente pot folosi metadatele ca baz de pornire n
identificarea i corectarea erorilor. Utilizatorii specific metadatele referitoare la
schema depozitului de date (fapte, dimensiuni etc), iar aplicaiile pot folosi aceste
specificaii ca intrare pentru a genera efectiv schema (tabele, indecsi, agregri etc.).

3.9. Analiza multidimensional

Raiunea pentru care exist depozitul de date este de a permite realizarea unor
analize economice complexe, care s foloseasc ntreaga valoare pe care o posed
datele colectate. Altfel spus, s valorifice informaiile n decizii manageriale inteligente,
att la nivel strategic ct i la nivel tactic. Iar n acest proces instrumentele de analiz
au rolul principal.
Se disting dou modaliti prin care se poate valorifica informaia din depozitul de
date: "mineritul" n date (data mining) i analiza multidimensional.
Data mining este o tehnic aflat n plin dezvoltare, care vizeaz descoperirea
unor "abloane" (patterns) semnificative n structura datelor, care s indice n general
tendine ale pieei. Se utilizeaz tehnici complexe, de diverse facturi (inteligen
artificial, statistic matematic, etc) care vor constitui subiectul unor articole viitoare.
Se spune c data mining rspunde la ntrebri pe care analistul nici mcar nu i le
pune.
Analiza multidimensional, invocat, de regul, prin termenul OLAP (On Line
Analytical Processing) este o activitate mai apropiat de realitatea zilnic, ce rspunde
la ntrebri pe care managerii i le pun la modul concret. Singura trstur comun a
acestor ntrebri este caracterul lor multidimensional.
Exist totui cteva tipuri uzuale de ntrebri, care pot sugera complexitatea
instrumentelor care trebuie s furnizeze rspunsuri:
Raporturi multidimensionale. Exemplu: care este contribuia la vnzrile
sptmnale totale a produselor farmaceutice vndute prin magazinele situate n
regiunea Moldova ntre 4 i 10 februarie?
Comparaii. Exemplu: care este media abaterii procentuale de la planul de vnzri
n lunile acestui an comparativ cu anului trecut?
Clasificri i profiluri statistice. Exemplu: Care este volumul vnzrilor i media
profitului pentru primii 20% dintre distribuitori i care este contribuia acestora la totalul
vnzrilor pe trimestrul trecut?
Agregri libere. Exemplu: care sunt veniturile realizate n ultimele patru trimestre de
filialele judeene din regiunea Moldova?
Evaluri What-If. Exemplu: n ce msur ar influena profitul total o cretere cu 10
procente a vnzrilor n judeele din Banat?

85

Oricine a formulat vreodat interogri asupra bazelor de date este contient de faptul
c exprimarea unor asemenea intrebri depeste posibilitile oricrui instrument
user-friendy de raportare. Devine evident necesitatea unor instrumente specializate
OLAP.
A. Caliti
Un bun instrument OLAP trebuie:
S poat s susin analize sofisticate.
S poat fi utilizat eficient de diverse categorii de utilizatori. Managerii de pe
diverse nivele ierarhice nu formeaz o clas omogen de utilizatori din perspectiva
aptitudinilor i abilitilor tehnice. Pentru a putea fi eficient utilizat, trebuie s furnizeze
viziuni intuitive, multidimensionale asupra datelor, s permit o navigare liber i o
prezentare ct mai natural a rezultatelor.
S fie scalabil la volume orict de mari de date. Volumele depozitelor de date sunt
imense, iar creterea lor este continu.
S permit accesul concurent al unui mare numr de utilizatori. Depozitul de date
este centrul informaional al ntregii organizaii i este de presupus c o mare parte
dintre angajai l vor utiliza.
S fie uor de ntreinut i de configurat. Nevoile informaionale ale unei organizaii
evolueaz, iar instrumentele de analiz trebuie s se adapteze n mod continuu.
S fie bazate pe o arhitectur deschis. Evoluia tehnologic poate aduce
schimbri radicale n structura sistemului informaional, care ns nu trebuie s
afecteze instrumentaia utilizat pentru analiz.

B. Arhitectura
Fiind o tehnologie relativ nou, modelul care s-a impus pentru sistemele orientate
spre analiz multidimensional este unul de tip client/server pe trei niveluri.
Bazele de date formeaz nivelul cel mai de jos, responsabil cu stocarea i
regsirea datelor. De regul aplicaiile tranzacionale utilizeaz sisteme relaionale, dar
pentru depozitele de date se folosesc i sisteme multidimensionale. Dat fiind volumul
mare de date, este recomandabil ca SGBD-urile folosite s ofere suport pentru
prelucrri paralele (SMP i MPP; interogri, ncrcri i indexri paralele) i distribuite,
s dispun de mecanisme performante de indexare i de optimizare, s ofere un nalt
nivel de siguran.
Logica aplicaiei este susinut de un "motor analitic" (OLAP Engine), servind ca
server pentru instrumentele desktop. Din perspectiva SGBD-ului care administreaz
depozitul de date, motorul analitic este un client.
Logica prezentrii este reprezentat de instrumentele mnuite de utilizatorul final.
Acestea au acces la datele din depozit prin intermediul motorului analitic. Dac motorul
analitic este un instrument foarte specializat i care de regul este cumprat "de gata",
aplicaiile front-end folosite de utilizatorii finali sunt extrem de diverse. Exist aplicaii
generale care rspund suficient de bine nevoilor unei categorii largi de utilizatori, exist
instrumente specializate pe domenii (cum ar fi de pild analiza financiar) i, n fine,
exist posibilitatea de a dezvolta instrumente foarte specifice unor anumite nevoi,
utiliznd medii de dezvoltare comerciale (de pild Visual Basic) i interfeele de
programare furnizare de serverul OLAP.

86

C. Rolul motorului analitic

Principala sarcin a motorlui OLAP este de a prelua cererile exprimate de clieni i,
pe baza consultrii metadatelor, s genereze cererile necesare pentru obinerea
datelor ce vor fi redirectate ctre clienti. n plus, datelor obinute li se pot aplica la acest
nivel o serie de prelucrri9.
Generarea de interogri - se bazeaz pe criteriile furnizate de clieni sub forma
unor formule exprimate prin operatori logici. Pentru a genera interogrile (SQL sau
specifice SGBD-urilor multidimensionale), motorul OLAP dispune de algoritmi care
aplic criteriile asupra metadatelor, obinnd cile de acces la datele referite i
transformrile necesare. Urmeaz apoi optimizarea cererii n vederea obinerii unei
viteze optime.
Manipulrile matematice se aplic pentru a aduce datele la forma dorit de clieni.
Acestea constau de cele mai multe ori n calcularea unor metrici derivate pe baza unor
formule date, analize statistice complexe, etc.
Sintetizarea rezultatelor (cross-tabulation) este o alt sarcin a motorului analitic.
Dei depozitul de date conine i date deja agregate, adeseori utilizatorul dorete
consolidarea unor sinteze pe baza unor combinaii de atribute care nu au fost
prevzute. n aceast situaie, motorul analitic solicit depozitului toate datele necesare
la nivel de detaliu i realizeaz sintetizrile necesare.
D. Rolul aplicaiilor
Din punctul de vedere al utilizatorului final, aplicaia front-end pe care o folosete
trebuie s-i asigure dou funcionaliti importante: navigarea liber prin depozitul de
date n cutarea informaiilor relevante i posibiliti diverse de prezentare a datelor.
Aceste funcionaliti sunt strns legate ntre ele i este greu de spus care operaie
este de navigare i care de prezentare.
Specificarea criteriilor de selecie este primul pas n orice analiz. Utilizatorul
trebuie s poat exprima cu uurint criterii simple, bazate pe valori ale atributelor
i/sau pe valori ale metricilor. Aceste criterii simple trebuie s poat fi apoi combinate
prin operatori logici i trebuie s poat fi salvate n biblioteci pentru eventuale
reutilizri.
Schimbarea nivelului de agregare permite gsirea nivelului de granularitate optim
pentru analiz. Se poate adnci analiza spre nivele de detaliu (drill-down) pentru
anumite dimensiuni, n timp ce pentru alte dimensiuni se crete nivelul de agregare
(drill-up). De regul cile de navigare sunt date de ierarhiile de atribute
corespunztoare atributelor.
Specificarea modului de prezentare trebuie s permit analistului s gseasc
modalitile optime de valorificare vizual a datelor extrase. n afar de posibilitile
grafice tipice pentru prezentare, este important ca utilizatorul s poat vizualiza date
multidimensionale ntr-o manier tabelar. n acest sens se pot utiliza tabele complexe,
care s poat grupa coloane i linii exprimnd dimensiuni diferite (de pild timpul i
geografia) i nivele de agregare diferite.
Cu toate c definiia lui W. Inmon este suficient pentru a rspunde la ntrebarea
"ce este depozitul de date?", cteva aspecte legate de arhitectura tipic a unui astfel
de depozit pot crea o imagine mai concret i mai precis. n principiu este considerat
9

AIRINEI, D. - Depozite de date, Editura Polirom, 2003

87

comun, uzual, o structurare a datelor pe patru nivele, n funcie de nivelul de

agregare i de vechimea acestora.
Dac vom face o analogie cu un depozit adevrat, atunci este normal ca datele
cele mai utilizate s se gseasc la parter. Aici se vor gsi datele relativ recente, en
detail. Acestea sunt n principiu livrate utilizatorilor finali, de regul funcionari de
execuie. La primul etaj se vor afla date "semipreparate" printr-o sintetizare uoar,
destinate n principal managementului mediu. La al doilea etaj se vor afla date
preparate pentru nevoile managementului superior. Prepararea implic consolidare,
sintetizare i mpachetare n formate accesibile instrumentelor de analiz utilizate.
n fine, la subsol se vor afla date accesate cel mai rar. Este vorba de date avnd o
oarecare vechime (de regul peste doi-trei ani), n form detaliat. Datele istorice
folosite de obicei de managementul superior sunt disponibile ntr-o form sintetizat la
"etajul al doilea" (eventual i la primul).
Aceast structur este dinamic, datele intr n depozitul de date, circul pe diverse
nivele, i schimb forma i poziia .a.m.d. Dar aceste aspecte dinamice vor fi
analizate mai trziu.
Poate cea mai important component a depozitului de date o reprezint nivelul
metadatelor. Pentru a putea utiliza depozitul de date, utilizatorii trebuie s cunoasc ce
date se gsesc aici, iar metadatele, aa cum am prezentat la capitolul 2.1. nu sunt
altceva dect date despre date, date care descriu coninutul depozitului i furnizeaz,
asemenea fielor dintr-o bibliotec, trimiteri directe la date. Tot la nivelul metadatelor
se definesc i diverse vederi (views) asociate unor categorii specifice de utilizatori.
Dar metadatele nu sunt utile doar utilizatorului final. Ele sunt intens folosite pentru
administrarea depozitului de date, coninnd informaii despre proveniena datelor,
algoritmii de sintetizare, statistici de utilizare i multe altele.
Deoarece sursa celor mai multe date stocate n depozitul de informaii o constituie
mediul operaional, am putea crede c nivelul de redundan ntre cele dou sisteme
(cel operaional i cel informaional) este foarte ridicat. De asemenea faptul c ambele
sisteme se bazeaz pe operarea cu sisteme de gestiune a bazelor de date, c ambele
sisteme implic volume mari de date etc, pot accentua aceast impresie. Cteva
consideraii pe aceast tem pot fi edificatoare n ceea ce privete chiar definiia
depozitului de informaii.
n primul rnd trebuie s subliniem c din punct de vedere funcional cele dou
sisteme sunt disjuncte. Sistemul operaional proceseaz tranzacii n timp ce sistemul
informaional este exploatat prin interogri. Cerinele sunt diametral opuse. Orice
administrator de baze de date cunoate faptul c optimizrile viznd sigurana i
coerena datelor, eseniale ntr-un sistem tranzacional, conduc inevitabil la ncetinirea
dramatic a interogrilor, cu deosebire a celor ad-hoc, bazate pe criterii neprevzute
(acestea sunt cele specifice analizei economice). Reciproc, aceste interogri implicnd de regul volume mari de date i fiind adesea lipsite de suportul unor indeci
prestabilii - pot compromite performanele operaiilor tranzacionale pn sub limitele
acceptabile.
n ceea ce priveste datele propriu-zise, cteva aspecte pot fi edificatoare:
Filtrarea datelor la transferul din sistemul operaional n cel informaional face ca
doar datele relevante pentru analiza economic s treac acest prag.

88

Orizontul temporal al celor dou sisteme este diferit. Exist o suprapunere foarte
mic ntre cele dou.
Depozitul de date conine i date sintetizate, care nu exist niciodat n sistemele
operaionale.
La preluarea n depozitul de date, datele sunt supuse unor transformri radicale
att din punct de vedere fizic ct i logic.
Conform aprecierii lui W. Inmon, redundana datelor ntre cele dou sisteme are de
regul o rat mai mic de 1%. Dar chiar dac acest rat ar fi mult mai mare, valoarea
depozitului de date este imens, deoarece ofer managementului organizaiei o
imagine unic, coerent i semnificativ asupra datelor relevante din perspectiva
analizei economice.
Mai mult, instrumente specializate OLAP permit utilizatorilor s exploreze efectiv
aceast baz informaional, fr a avea nevoie de intermedierea unui serviciu
specializat. Iar ntr-un context economic n care o decizie luat dimineaa are deja
efecte sensibile la ora prnzului, "efectiv" nseamn de fapt "vital".

3.9. Fluxul informaiei n depozitul de date

Nu e suficient ca depozitul de date s existe. El trebuie s furnizeze informaiile
potrivite ctre oamenii potrivii, n forma potrivit.
Definiia depozitului de date, accentund contrastul ntre sistemul operaional i cel
informaional, ne-ar putea sugera niste imagini de genul urmtor: sistemul operaional
seamn cu ringul unei burse, cu o mulime de brokeri agitndu-se n jurul
calculatoarelor, a panourilor de afisare, fcndu-i semne neinteligibile ntre ei, rcnind
la telefoane, smulgnd nerbdtori hrtiile din faxuri etc. Dimpotriv, depozitul de date
este un spaiu linitit, respirnd atmosfera seren a unei biblioteci.
De fapt, lucrurile nu stau chiar aa. Depozitul de date are i el dinamica lui, chiar
dac nu att de agitat ca cea a sistemului operaional. Pentru a exprima aceast
dinamic se folosete adesea termenul "data warehousing", iar pentru a o descrie se
recurge la cele cinci fluxuri informaionale identificate de Richard Hackathorn
nelegerea modului n care aceste fluxuri acioneaz este cheia succesului
construciei i utilizrii unui depozit de date.
A. In-flow
Acesta este fluxul de intrare a datelor n depozit. Datele provin din sistemul
operaional precum i din surse externe. Actualizarea depozitului de date nu trebuie s
afecteze datele existente. Nimic nu se terge, nimic nu se suprascrie. Este vorba doar
despre adugarea unui nou "strat" de date. Actualizarea se face de regul n loturi
(batch), la intervale regulate, dar anumite cerine pot impune o actualizare n flux
continuu, reflectnd actualizri n sistemul operaional. De exemplu, o banc ar putea
s doreasc s pstreze un istoric al tuturor operaiunilor efectuate asupra unui cont
sau ar putea s se mulumeasc cu balane periodice (de pild la sfritul fiecrei zile).
Pentru datele provenind din aplicaiile tranzactionale se pune n primul rnd
problema selectrii i extragerii. Instrumentele folosite n acest scop trebuie s fie
capabile s exploateze la maximum middleware-ul disponibil pentru a accede la toate
datele i s poat s realizeze conversiile implicite la "transbordarea" ntre diverse
platforme.

89

Dar acesta este abia nceputul, deoarece datele trebuie s treac printr-un proces
complex de consolidare. Acest proces implic:
eliminarea datelor nerelevante (a cror semnificaie se leag de procesul
tranzacional, cum ar fi de pild numrul poziiei din factur);
conversia la codificri i reprezentri unitare (conform unor convenii clar
stabilite de administraia depozitului);
curirea datelor (prin eliminarea inconsistenelor i reconstituirea datelor parial
distruse, completarea informaiilor lips cu valori implicite etc);
reorganizarea datelor (adugarea informaiilor temporale unde este cazul,
denormalizare i rearanjare dup subiecte etc).
n afar de datele provenite din sistemul operaional, o cerin tot mai actual o
reprezint consolidarea i integrarea n depozitul de date a datelor provenind din alte
surse. Printre acestea se remarc datele non-relaionale cum ar fi texte, e-mail, foi de
calcul, imagini, obiecte multimedia, baze de date geografice, chiar i reguli comerciale
(business rules). De asemenea, alte surse de date externe pot fi sistemele
operaionale ale partenerilor de afaceri, bazele de date publice sau informaiile
furnizate pe baz de abonament (cotaii bursiere, buletine meteorologice etc).
B. Up-flow
Prin procesul de intrare n depozitul informaional, datele capt un plus de claritate
i de semnificaie. Dar odat ajunse n Data Warehouse ele nu rmn n acest stadiu,
ci se mbogesc n continuare printr-o serie de alte transformri. Aceste procese sunt
numite n mod generic up-flow i au rolul de a aduga valoare informaional datelor
colectate.
Principalele procedee utilizate n acest scop sunt:
Sintetizare. Datele intr n depozit la nivel de detaliu. Cu toate c instrumentele
de analiz pot aplica funcii de agregare, pentru optimizarea accesului la astfel de
informaii de sintez anumite astfel de operaii sunt realizate chiar de administraia
depozitului de informaii. Sintetizarea se realizeaz pe baza dimensiunilor cele mai
utilizate i poate implica nu doar nsumarea unor valori, ci i medii, valori
minime/maxime sau valori obinute prin procedee statistice complexe. Un exemplu
simplu este sintetizarea pe axa timpului. Dac granularitatea este, de pild, la nivelul
zilei, se pot precalcula totaluri sptmanale, lunare, trimestriale i anuale. De
asemenea se pot calcula medii, se pot determina zilele de minim sau maxim (pe lun,
pe trimestru, etc), se pot calcula dispersii etc.
mpachetare. Utilizarea informaiei din depozit nu se face doar on-line. Pentru
cea mai mare parte dintre nevoile informaionale ale organizaiei se utilizeaz sistemul
abonamentelor: un anumit beneficiar (un funcionar, un birou, un departament etc.) are
nevoie de anumite informaii, la un anume nivel de sintetizare, la anumite intervale de
timp. Aceste informaii pot fi livrate ca simple rapoarte, dar cel mai adesea ele trebuie
livrate n formate care s permit beneficiarului s le utilizeze n continuare pentru
analize, prezentri, raportri etc. Cel mai adesea datele se furnizeaz ca foi de calcul,
documente text, baze de date personale, eventual grafice, animaii etc., toate ntr-un
format propriu utilizatorului. De pild datele pot fi plasate n multiple file de calcul
tabelar, n diverse nivele de detaliere, continnd eventual i prezentri grafice.

90

 Distribuire. De cele mai multe ori diverse grupuri de utilizatori sunt interesate
doar de anumite categorii de date, astfel ncat pentru a crete disponibilitatea
informaiilor se realizeaz nite mici depozite departamentale, coninnd replici pariale
(cuprinznd doar datele de interes specific) ale depozitului central. Alt situaie
frecvent este cnd repartizarea teritorial a organizaiei impune multiplicarea
depozitului de date n mai multe locuri (de pild replicarea integral sau parial la
filialele din teritoriu). Pe msur ce tehnologiile de stocare i procesare distribuit se
maturizeaz, arhitectura centralizat a depozitelor de informatii va fi nlocuit de o
arhitectur distribuit.
C. Down-flow
Acest flux se refer la administrarea datelor i este destinat s menin "vitalitatea"
depozitului de date. Datorit faptului c se lucreaz cu volume imense de date (de
regul peste 500 GB), se impune o ierarhizare a prioritii datelor n funcie de gradul
lor de utilizare. n general, datele vechi nu se mai consult la nivel de detaliu: foarte
rare sunt cazurile n care cineva este interesat de numrul de buci dintr-un anumit
produs vndute ntr-o anumit zi a anului 1991 la un anumit magazin. Aceste date vor
fi transferate pe un suport mai lent (discuri optice, band magnetic, etc), pstrand la
nivelele de prioritate nalt doar anumite nivele de sintetizare.
n esent, acest flux trebuie s asigure c nici o informaie important nu se pierde
i totodat c informaiile mai puin actuale sau mai puin importante nu blocheaz n
mod inutil canalele de comunicaie i mediile de stocare cu acces rapid.
D. Out-flow
Ieirea datelor spre utilizatori reprezint asa-numitul out-flow. Prin aceast
deschidere, valoarea informaional creat prin data warehousing devine disponibil
pentru ntreaga organizaie, oferind un substanial suport pentru conducerea optim a
activitii. Ca i n cazul fluxul de intrare, fluxul de ieire este posibil doar cu suportul
unui middleware funcional. Spre deosebire de in-flow, unde legtura se fcea mai ales
ctre bazele de date ale sistemului tranzacional, n acest caz middleware-ul trebuie s
vizeze staiile de lucru ale clienilor. Out-flow reprezint "tejgheaua" depozitului de
date.
Exist dou activiti principale care formeaz acest flux:
Accesarea datelor. Aceast activitate se caracterizeaz prin faptul c iniiativa
aparine clientului, care solicit informaiile de care are nevoie. Cererile de acces la
date pot fi de natur ocazional (interogri ad-hoc), de rutin (zilnice, sptmnale etc)
sau, n unele cazuri, chiar n timp-real (continue).
Livrarea datelor. n acest caz iniiativa aparine depozitului de date, care trimite
din proprie iniiativ anumite date ctre anumii clieni. Data Warehouse face publice
diverse obiecte (business objects) care sunt actualizate periodic iar clienii pot s-i
aleag seturile de obiecte care le sunt cele mai utile i s le primeasc automat.
Acestea sunt de regul mpachetate n formate uzuale i pot fi reflectate automat n
documente (prin legturi dinamice de gen publish/subscribe sau DDE).
Deciziile luate pe baza analizei economice facilitate de informaia din depozitul de
date se vor concretiza n operaii economice, consemnate prin tranzacii n sistemul
operativ, care la rndul lui va crea viitoarele date de intrare n depozitul de date. Uneori

91

influena deciziilor poate fi estimat sau msurat tot prin instrumente de analiz. La
modul teoretic mcar, putem considera c acest flux este conectat la fluxul de intrare,
procesul decizional formnd un cerc nchis.
E. Meta-flow
Metadatele, fiind date despre date, descriu structura i coninutul depozitului de
date. Dar cum structura i coninutul au la rndul lor o dinamic, exprimat prin cele
patru fluxuri descrise pn acum, rezult c exist i o dinamic a metadatelor. n
principiu, acest meta-flow descrie i conecteaz cele patru fluxuri, fiind un meta-model
al dinamicii depozitului de date.
Depozitul de date nu este o aplicaie care s poat fi cumprat "de gata". Mai
mult, ea nu este proiectat odat pentru totdeauna. Adaptabilitatea sistemului
operaional la conditiile mereu noi ale activitii impune o adaptabilitate
corespunztoare a sistemului informaional. Dac apar schimbri n aplicaiile
organizaiei, ele trebuie s se reflecte n definiiile procedurilor de intrare asfel ncat s
nu afecteze ieirile. De asemenea, schimbrile n cerinele utilizatorilor trebuie s poat
fi rezolvate prin adaptarea corespunztoare a fluxurilor interne.
Exist dou aspecte importante legate de meta-flow:
meta-flow este instrumentul principal de administrare a depozitului de date.
Cum acest depozit este de fapt puntea dintre datele brute i instrumentele de analiz,
o bun proiectare a acestui flux trebuie s asigure imunitatea fiecrui subsistem n
parte la schimbri intervenite n celelalte.
meta-flow nseamn de fapt modelare, att a sistemului informatic, ct i a
activitii de ansamblu. Ispita perfeciunii ne-ar putea ndemna s ncepem proiectarea
unui Information Warehouse cu modelarea activitii ntregii organizaii i a sistemului
informatic. Probabil c dintre toate abordrile posibile, aceasta este cea mai
pguboas: practic, nu exist anse de a termina vreodat (cu att mai puin n timp
util) o astfel de analiz. Adevrata provocare a proiectrii i administrrii unui depozit
de date este de a obine rezultate imediate i de a permite o evoluie continu a
sistemului prin mbuntiri succesive. Iar cheia succesului n aceast direcie o
reprezint dinamica metadatelor.

3.10. Proiectarea depozitelor de date

n proiectarea bazelor de date utilizate pentru crearea unui depozit de date este
necesar s se neleag cum vor fi folosite datele. Bazele de date trebuie construite
astfel ncat s permit interogri ad hoc la care s se poat primi rspuns n condiii de
performan acceptabile.
Figura 1 reprezin o schema clasic de depozit de date, n fom de stea, n care
utilizatorii finali acceseaz direct datele derivate din mai multe sisteme surs, prin
intermediul depozitului de date. n aceast schem datele operaionale sunt curate i
procesate naintea introducerii n depozit.
O schem de jonciune stea suport dou tipuri de interogri: consultare i
jonciuni multiple. Operaia de consultare se realizeaz pe o singur tabel de fapte i
nu necesit jonciuni. O cerere de interogare tipic apare atunci cnd un utilizator final
solicit o list derulant. Interogrile de tip jonciune multipl apar dup o serie de
consultri i implic restricii plasate n cteva tabele dimensiune care sunt puse n

92

legtur simultan, prin operaia de jonctiune, cu tabela de fapte. Scopul este de a

aduce sute i mii de nregistrri de baz ntr-un set de rspunsuri de dimensiune mic.
Dimensiunile n acest caz sunt denormalizate, ele avnd date redundante care
elimin necesitatea unor legturi multiple ntre tabele. ntr-o schem stea nu exist
dect o singur legatur ntre tabela de fapte i dimensiuni. Optimizarea performanei
de rspuns la interogri este principalul avantaj al acestui model.
Schema de tip Fulg de Nea este o variant a modelului stea n care o parte din
tabelele dimensiune sunt normalizate, iar datele sunt distribuite n tabele suplimentare
(Figura 2). Rezult o schem reprezentat ntr-un grafic similar unui fulg de zpad.
Diferena ntre modelul stea i modelul fulg de nea este c tabelele dimensiune din
acesta pot fi pstrate n form normalizat, ceea ce determin o redundan redus.
Asemenea tabele sunt uor de ntreinut i astfel se economisete spaiu de stocare.
Totui aceast economie de spaiu este neglijabil n comparaie cu volumul foarte
mare de date din tabelul de fapte. Mai mult, structura fulg de nea poate reduce
performana extragerii de date deoarece sunt necesare mai multe jonciuni ntre tabele
la o singur interogare.
Cuburi de date - Un mod mai simplu de vizualizare a datelor este reprezentarea
ntr-un spaiu cartezian definit pe toate dimensiunile depozitului de date (Figurile 3 i
4). Acesta poate fi numit cub de date, fiind un spaiu de date logic i nu unul fizic.
Seciunile bidimensionale sunt numite tablouri. Axele cubului sunt reprezentate de
dimensiuni, la intersecia acestora fiind variabilele sau msurile
n analiza multidimensional cubul de date cu mai mult de trei dimensiuni poart
denumirea de cub n-dimensional sau hipercub (hypercub). Consiliul OLAP definete
cubul n-dimensional ca fiind un grup de celule de date aranjate dup dimensiunile
datelor. O matrice tridimensional poate fi vizualizat ca un cub cu fiecare dimensiune
formnd o fa a cubului. Tot n aceeai definiie se menioneaz c dimensiunile
tipice ale datelor dintr-o ntreprindere sunt timpul, msurile, produsele, regiunile
geografice, canalele de distribuie.

93

Figura 1

Figura 2
94

Figura 3 cub de date cu 3 dimensiuni

Figura 4 cub de date cu 4 dimensiuni

95

Concluzii
Pentru a rspunde la ntrebarea dac este sau nu necesar un depozit de date,
trebuie s ncepem prin a analiza modul de obinere a unui raport
ntr-un mediu IT
clasic prin comparaie cu un mediu IT cu aplicaii integrate (hub and spoke) i care
beneficiaz i de o component de depozit de date.
Aceast analiz simpl ar arta c diferenele de cost pentru obinerea i
executarea aceluiai tip de raport pot fi de cteva zeci de ori mai mici n favoarea
mediului IT ce conine un depozit de date. Motivele pentru care apar aceste diferene
in de costurile mai mari ntr-un mediu IT classic, de colectarea datelor prin implicarea
mai multor resurse, de timpul mai mare alocat acestei sarcini i, implicit, de dificultatea
respectrii unor termene.
Mai mult, mediul clasic este incapabil s ofere rspunsuri on line.
O alt diferen const n calitatea datelor, care, ntr-un mediu classic, au o
cantitate mare de balast, de informaii inutile i irelevante pentru raportul n discuie.
Aceste date sortate cu o granularitate mai mare fac raportul mai lung, mai ineficient i,
implicit, mai scump de obinut. Mediile IT clasice nu au fost gndite pentru optimizarea
rapoartelor, ci au fost orientate ctre procese, iar structura lor intern nu permite
aceasta.
Pe de alt parte obiectivul dezvoltrii depozitelor de date este optimizarea
sistemului de raportri i nu ar trebui s constituie o surpriz costurile mult mai mici. Nu
doar executarea raportului inseamn un cost redus pentru o arhitectura ce conine un
depozit de date, ci i dezvoltarea raportului ca munc suplimentar a departamentului
IT. n mediul clasic trebuie mai inti integrate datele i apoi executat raportul, n timp ce
ntr-un depozit de date acestea sunt deja integrate i disponibile imediat.
Cu un depozit de date, un analist are la dispoziie metadate care i reduc timpul de
cutate i identificare a informaiilor relevante i i permit s se concentreze
preponderent pe construirea raportului. Mai mult, ntr-un depozit de date un raport deja
realizat poate fi identificat imediat i folosit pentru generarea unuia nou, ceea ce
nseamn timp de reacie mai bun, lucru imposibil ntr-un mediu IT clasic. Un alt
element ce contribuie la reducerea costurilor ntr-un depozit de date este identificarea
simpl a istoricului datelor, a relevanei i a exactitii acestora, activitate de asemenea
dificil i consumatoare de timp. Mai mult, posibilitile de sintetizare dintr-un depozit
de date contribuie la reducerea costurilor.
Ultimul aspect important este acela c ntr-un mediu IT clasic exist riscul ca
realizarea raportului s nu fie posibil, n timp ce realizarea unui raport intr-un depozit
de date este o sarcin obinuit.
Dincolo de costurile obinerii i executrii raportului, exist diferene majore n
viteza de dezvoltare. ntr-un mediu clasic obinerea unui raport dureaz o perioad mai
mare de timp, n timp ce ntr-un depozit de date acesta se obine imediat sau chiar n
timp real. Alte aspecte de notat ar mai fi cele legate de modificrile care pot fi aduse
unui raport, mai ales c aceasta implic o munc de descoperire, fr ca finalitatea s
fie ntotdeauna evident. Depozitul de date este mediul ideal pentru un proces de
descoperire i schimbare frecvent, astfel nct un raport iniial este doar un punct de
plecare.

96

Datorit obiectivelor impuse de utilizarea depozitelor de date, n analiz se

desprind cteva caracteristici mai importante pe care acestea le dein:
Depozitul de date asigur accesul la datele organizaiei. Accesul trebuie s se
realizeze ntr-un timp ct mai scurt, la cerere i s fie performant. Datele ntr-un depozit
de date pot fi separate i combinate pentru a oferi un acces ct mai rapid i un timp de
rspuns ct mai mic sistemului. De asemenea, accesul presupune existena unor
utilitare care s fie foarte uor de folosit.
Datele dintr-un depozit de date trebuie s fie consistente. Consistena presupune
faptul c atunci cnd dou persoane solicit acelai set de informaii s primeasc
aceleai date, chiar dac ele au fost cerute la momente de timp diferite. Dac datele nu
au fost complet ncrcate, atunci utilizatorul va fi avertizat cu privire la acest lucru i
este sftuit s atepte pna cnd vor fi complet ncrcate.
Datele din depozite sunt utilizate direct n analize, fr alte prelucrri suplimentare.
Datele nu sunt doar centralizate, integrate i stocate ci, dup ce sunt extrase dintr-o
varietate de surse, sunt corectate din punct de vedere al erorilor, transformate, li se
asigur calitatea necesar i abia apoi devin utilizabile. Depozitele de date nu
reprezint doar datele, ci i un set de utilitare pentru a interoga, analiza i prezenta
informaiile.
Calitatea datelor din depozitele de date este un factor determinant pentru procesul
de analiz. Se ntlnete frecvent situaia n care datele nu sunt de bun calitate, nu
sunt extrase n ntregime sau au un caracter incert din punct de vedere al coninutului,
ceea ce face ca analiza ulterioar s conduc la rezultate eronate.
O consecin important a acestor caracteristici este redundana datelor. Dac n
modelul relaional redundana este eliminat (prin procesul de normalizare) n scopul
evitrii anomaliilor de actualizare, n depozitul de date redundana este creat n mod
intenionat prin denormalizare i agregare pentru a permite un acces mai rapid la date.
Integrarea datelor reprezint o alt consecin important a realizrii depozitului de
date si, n cele din urm, raiunea pentru care acesta este creat. Datele sunt ncrcate
pentru a rspunde nevoilor informaionale ale ntregii organizaii, asigurnd faptul c
rapoartele generate pentru diverse compartimente vor conine aceleai rezultate.
Sistemul operaional este de cele mai multe ori format din subsisteme semiindependente, create la momente diferite, de echipe diferite, n maniere diferite, ceea
ce face imposibil folosirea acestui sistem pentru analiz.
Integrarea datelor provenind din sistemul operaional i din alte surse se refer la
diferite aspecte: modaliti unice de codificare, sistem de uniti de msur consistent,
sistem stabil de reprezentare fizic a datelor, convenii clare privind modul de
reprezentare a datelor calendaristice, convenii unice privind denumirile i coninutul
acestora. O arhitectur complex este structurat pe patru niveluri distincte de
realizare a datelor, astfel: nivelul surselor de date, nivelul transformrii datelor, nivelul
depozitului de date, nivelul de prezentare i raportare a datelor
Prin urmare, putem concluziona c un depozit de date reprezint o modalitate de
integrare i organizare a datelor din surse omogene i neomogene, provenite din
sisteme tranzacionale, dar i din fiiere externe, integrate dup anumite criterii, supuse
unui proces de extragere, transformare i ncrcare, stocate agregat pe niveluri
ierarhice, destinate prelucrrilor i analizelor dinamice, fiind soluia optim de
organizare a datelor pentru sistemele informatice suport de decizie i executive.

97

4. BAZE DE DATE MULTIMEDIA

4.1. Generaliti
Baza de date reprezint o mulime structurat de date, accesibile cu ajutorul
calculatorului, care pot satisface, n timp minim i ntr-o manier selectiv, mai muli
utilizatori. Aceast mulime de date modeleaz un sistem sau un proces din lumea
real i servete ca suport unei aplicaii informatice.
Realizarea unei baze de date presupune analiza sistemului pentru care se
construieste baza de date, proiectarea structurii bazei, incarcarea datelor in baza,
exploatarea si intretinerea bazei.
Realizarea efectiva a unei aplicatii presupune stabilirea temei, analiza si proiectarea
aplicatiei, codificarea acestei, testarea modulelor, implementarea si apoi intretinerea
aplicatiei.
Pe msur ce volumul de date a crescut, modelele iniiale pentru proiectarea i
gestionarea informaiei nu au mai fost suficiente i locul acestora a fost luat de modelul
relaional, care a revoluionat lumea bazelor de date. Uurina cu care se poate
reprezenta o multitudine de aspecte ale realitii ntr-un model relaional i buna sa
fundamentare l-au fcut s devin cel mai popular model de baze de date.
n ultimii ani, s-a observat ns c modelul relaional, cu toate mbuntirile care Iau fost aduse, nu poate modela aspecte ale realitii contemporane, care abia acum au
nceput sa-i fac apariia. Documentele complexe, incluznd date compuse, care nu
se pot reprezenta relaional, imaginile i sunetele, aplicaiile software de mare amploare
au demonstrat incapacitatea conceptului relaional de a modela noile aspecte ale
realitii. Ca atare, cercetrile s-au ndreptat asupra unor modele care permit, cel puin
teoretic, studierea mai profund a unor aspecte complexe ale realitii. Unul dintre
acestea este modelul orientat obiect. Modelarea orientat obiect are aplicaii multiple n
toate domeniile importante ale realitii datorit puterii conceptelor de: clas,
ncapsulare, motenire, etc.
Combinarea tehnologiei bazelor de date relaionale cu cea a programrii orientate
obiect a permis implementarea conceptului de model obiect-relaional (hibrid).
Cuvntul multimedia provine de la cuvintele muli (mai multe) i media (medii
de transmitere i prezentare a informaiilor) i se refer la abilitatea de a achiziiona,
manipula, combina i reda informaii de la o mare varietate de medii, ce includ text,
grafic, animaie, sunet, imagine fix sau video. Multimedia nu este deci o tehnologie,
ci mai de grab un termen ce descrie un numr de tehnologii care lucreaz mpreun.
Aadar, noiunea de multimedia, definete integrarea ntr-o concepie unitar a
imaginilor, textelor i sunetelor care formeaz un document.
Baz de date multimedia = o baz de date care realizeaz o uniune ntre
disciplinele de regsire a informaiilor i de management al bazelor de date, care pn
acum erau considerate ca fiind dou discipline total diferite i disjuncte.
De aici rezult i numrul mare de aplicaii al acestora, i anume:
n informare - multimedia este modul cel mai rapid, eficient i ieftin n comparaie cu
alte medii de informare a publicului, cuprinznd adevrate enciclopedii electronice.
n administrarea documentelor i a nregistrrilor - n ntreprinderi i instituii
comerciale, acestea avnd nevoie de diverse documente, n funcie de specificul lor.

98

 n educaie i instruire - n regsirea materialelor pentru pregtirea tuturor

persoanelor.
n reclame - n mod practic nu exist nici o limit n folosirea informaiei multimedia
n astfel de aplicaii.
n controlul i monitorizarea proceselor n timp real - mpreun cu bazele de date
active, prezentrile multimedia de informaii au un rol efectiv n operaiile de
monitorizare i control n sistemele de transport, de supraveghere a pacienilor.
Pentru realizarea tuturor acestor aplicaii n condiii optime, bazele de date
multimedia trebuie ca, pe lng asigurarea unui timp minim de acces la date, s
garanteze i integritatea, securitatea i independena datelor.

4.2. Informaiile multimedia n format digital

Pentru a fi prelucrate cu ajutorul calculatorului, datele audio i video vor fi codificate
digital, fiierele obinute astfel putnd fi redate si prelucrate cu produse software
specifice (multimedia). De exemplu, sistemele de operare Windows sunt prevzute cu o
gam de accesorii multimedia pentru redarea si procesarea fiierelor audio-video
(Sound Recorder, CD Player, MIDI, Media Player).
A. Secvene de sunet
Undele audio vor fi convertite n form numeric (digital) de un convertor analogicnumeric specific. Procesul de transformare poate introduce erori (numite zgomote), dar
acestea sunt n general minore, nedetectabile de urechea uman. Convertirile digitale
al informatiilor sonore sunt necesare pentru prelucrrile sau transmisiile digitale ale
datelor sonore: accesarea acestora prin intermediul calculatoarelor sau retelelor de
calculatoare, convorbiri telefonice prin linii analogice si centrale digitale, crearea CDurilor audio etc.
Fisierele de sunet pot fi usor prelucrate pe calculator, prin intermediul unor
programe specifice, care permit utilizatorilor s nregistreze (memoreze), s redea, s
editeze sau s mixeze unde sonore provenite din surse multiple. Una din cele mai
cunoscute aplicaii pentru prelucrri muzicale este MIDI (Musical Instrument Digital
Interface), o interfat digital standard care simuleaz diverse instrumente muzicale i
efecte speciale, inclusiv sunete din natur sau produse de diverse aparate si asigur
gestiunea lor. MIDI este un echivalent informatic de redare/creare a unei partituri
sonore i poate fi folosit de ctre muzicieni ca un instrument de dezvoltare pentru
secvenele de sunet. Mesajele audio conin frecvent discursuri umane; pentru
transmiterea lor eficient pe cale digital, s-au creat sisteme de generare i transmisie
a vocii care folosesc modele de sisteme vocale ce reduc vocea la civa parametri
eseniali, cu proprieti fonetice particulare.
B. Secvente video - reprezentare si afisare
Derularea imaginilor video are la baz succedarea unui anumit numr de imagini
statice n fiecare secund. Dac se utilizeaz cel putin 25 de imagini pe secund,
ochiul uman nu sesizeaz faptul c imaginile sunt discrete, ci le percepe ca imagini
continue, n miscare. Acest principiu st la baza tuturor sistemelor de producere a
filmelor, inclusiv a televiziunii - care este n esen, analogic.

99

ntr-un sistem digital, fiecare cadru este reprezentat sub forma unei grile
dreptunghiulare de puncte luminoase numite pixeli. Pentru o imagine n alb i negru, un
bit (0 sau 1) este suficient pentru reprezentarea unui pixel. Nivelurile de gri (n numr
standard de 256) se pot reprezenta dac fiecare pixel este codificat pe 8 biti.
Sistemele color uzuale cu 256 de culori folosesc n consecin tot 8 biti pentru
reprezentarea unui pixel. Evident, pentru reprezentarea unui numr mai mare de culori
ar trebui utilizai mai muli bii n codificarea fiecrui pixel dar introducerea unui numr
mai mare de culori nu este relevant din moment ce ochiul uman nu ar putea distinge
diferene infime ntre dou nuane apropiate.
O imagine reinut prin codificarea fiecrui pixel coninut este de tip BiT-Map (hart
de bii) i are dimensiuni destul de mari. Un format de dimensiuni mult mai mici pentru
memorarea imaginilor i, n consecin, larg utilizat, este GIF. Exist programe care
permit conversia unor tipuri de reprezentri ale imaginilor n alte tipuri de reprezentri
conversia fiierelor de tip imagine static.
Configuraiile obinuite ale monitoarelor de calculator sunt: 640480 pixeli (VGA),
800600 pixeli (SVGA), 1024768 pixeli (XVGA). Aceast caracteristic, dat de
numrul de pixeli de pe ecran, se numete rezoluie. Raportul dintre numrul de pixeli
pe orizontal i vertical, important pentru simetria figurilor, se numete raport de
aspect i are valoarea 4/3.
Numrul de cadre derulate pe secund pentru imaginile animate, ca i n cazul
analogic, este de cel putin 25. Monitoarele de nalt calitate a calculatoarelor
redeseneaz ecranul de 75 de ori pe secund (sau chiar mai mult) iar pentru eliminarea
plpirii, acelai cadru de reafiseaz de cteva ori la rnd. Procesul de reafiare este
simplificat de faptul c ntr-un calculator imaginea ecranului este memorat.
C. Compresia datelor multimedia memorate si transmise
Informaiile multimedia au dimensiuni foarte mari; de aceea, pentru transmiterea lor
trebuie gsit o form comprimat echivalent sau foarte apropiat - cu o dimensiune
considerabil redus dar pstrnd n esen aceleai informaii. Un factor important n
buna funcionare a transmisiilor multimedia actuale l constituie aplicarea tehnicilor de
compresie dezvoltate n ultimele decenii.
Pstrarea ntr-o form comprimat a datelor multimedia are avantaje evidente si din
punctul de vedere al memoriei externe necesare pentru a le reine. n plus, trebuie s
existe produse soft capabile s prelucreze datele n acea form.
Compresia datelor transmise presupune aplicarea unui algoritm de codificare a
datelor nainte de a le emite i a unui algoritm de decodificare la destinaie (acesta din
urm va reconstrui forma iniial, sau o form foarte apropiat de aceasta, din datele
comprimate). Practic, este important ca algoritmul de decodificare s fie rapid i puin
costisitor din punctul de vedere al resurselor folosite fiindc ntr-o reea de calculatoare,
un fiier comprimat reprezentnd informaii multimedia poate fi accesat i transferat
repetat, de mai muli utilizatori. n cazul n care anumite informaii multimedia se
transmit n timp real - de exemplu, n videoconferine, codificarea rapid a datelor este
de asemenea important pentru a se asigura eficiena transmisiei.
Aceste necesiti, la care se adaug faptul c diferene minore n secvenele
multimedia sunt adesea imperceptibile de ctre om, dau o caracteristic important a
codificrilor / decodificrilor multimedia: procesul de codificare / decodificare nu trebuie

100

s fie perfect reversibil dar trebuie s fie rapid si s furnizeze o form comprimat
foarte apropiat de forma iniial, i de dimensiuni convenabile. Acceptarea unui numr
mic de informaii pierdute este foarte avantajoas pentru ratele de compresie uzual
necesare. Astfel, algoritmii de compresie cu pierderi mici de informaie n rezultat fa
de forma original sunt adesea preferai celor care furnizeaz o ieire absolut identic
dar sunt mai costisitori.
Urmrind aceste principii, n 1993 au fost adoptate dou standarde de codificare:
pentru compresia imaginilor statice cu tonuri continue - standardul JPEG (Joint
Photografic Experts Group) iar pentru filme - MPEG (Motion Picture Experts Group),
care folosete codificarea JPEG pentru fiecare cadru separat.
Aceste tipuri de codificri sunt foarte importante pentru eficiena memorrii i
transmiterii imaginilor statice i animate; de exemplu, o imagine va fi mult mai
convenabil memorat n format JPEG dect n format BMP.
D. Probleme care apar n bazele de date multimedia
Aplicaiile multimedia conin mii de imagini statice i dinamice, documente, texte,
segmente audio i video; organizarea acestora depinde de modelarea structurilor i a
coninutului de date.
O prim problem este generat de conflictul care apare ntre aplicarea tehnicilor
bazelor de date i a celor de regsire a informaiilor. n sistemele de baze de date,
modelarea coninutului de date nu este o problem deoarece datele au o structur
rigid. Pe de alt parte, regsirea informaiilor se ocup n special cu modelarea
contextului documentului (prin cuvinte cheie, indexuri, reele semantice, etc).
Design-ul conceptual, logic i fizic este urmtoarea problem care apare i la care
nu exist nc un rspuns clar.
Stocarea datelor multimedia pe suporturi standard; aceast etap prezint
probleme de reprezentare i compresie/decompresie. Tendina n prezent este de
arhivare a informaiilor astfel nct s se reduc dimensiunea zonei tampon n timpul
operaiilor de intrare/ieire. O modalitate de a elimina aceste probleme este folosirea
standardelor ca JPEG sau MPEG; pentru bitmap-uri exist BLOB (Binary Large Object)
care faciliteaz stocarea i regsirea datelor. Pentru documente exist deja aplicaii,
cum sunt Encode/Uuencode (Windows), Tar (Unix), etc., care realizeaz compresia/
decompresia acestora (deocamdat n stadiu incipient de dezvoltare).
Regsirea informaiilor este o problem mai ales n cazul imaginilor dinamice i al
segmentelor audio i video, deoarece de multe ori acestea conin informaiile relevante.
Pentru bazele de date regsirea se face cu ajutorul limbajului de interogare (SQL) i a
structurilor indexate. Problemele care apar se datoreaz n primul rnd navigatoarelor
(foarte diferite) cu care se lucreaz, deoarece fiecare interpreteaz n mod diferit
imaginile, n funcie de platforma pe care ruleaz. n al doilea rnd, exist o limitare
fizic a driverelor cu care se lucreaz pentru regsirea acestor tipuri de informaii; n
multe cazuri informaiile nu pot fi accesate, navigatorul anunnd printr-un mesaj soft-ul
necesar.
O alt problem care apare este cea a performanei. Pentru aplicaiile multimedia
ce conin simple documente i text, constrngerile de performan sunt subiectiv
determinate de ctre utilizatori. n cazul aplicaiilor cu imagine video n micare, sau
sincronizare audio-video, se poate vorbi de o limitare fizic.

101

Internetul
Un prim rspuns la aceste probleme a fost apariia Webului.
Accesarea publicaiilor Web se face cu ajutorul unor soft-uri numite browsere
(Mosaic fiind primul aprut, Internet Explorer, Netscape, etc.), iar scrierea lor se
realizeaz cu ajutorul limbajului HTML (HyperText Markup Language), bazat pe
legturile hipertext.
Pentru folosirea ntregii puteri a multimediei, sistemul trebuie s aib un model de
construcie care s-i permit utilizatorului folosirea de legturi ntre oricare dou noduri
arbitrare ale reelei. Legturile hypermedia realizeaz acest lucru i pot avea mai multe
forme:
pot fi nsoite de o descriere detaliat sau nu a lor
pot s porneasc de la un nod dat sau de la oricare nod
pot fi direcionate sau nedirecionate
La un sistem de informare bazat pe regsirea datelor multimedia, mecanismul de
interogare trebuie s aib acces att la legturi, ct i la informaiile asociate acestora.
Sistemul trebuie s fie facil att pentru definirea imaginilor nsoite de legturi, ca i
pentru definirea legturilor publice i private.
Ierarhizarea informaiilor este procedeul folosit n prezent n bazele de date
multimedia, fiind n acelai timp i primul pas pe care trebuie s-l fac cel ce creeaz
astfel de informaii. O legtur hipermedia generat automat nu prezint nici o
informaie despre nodurile intermediare care au fost conectate. Pe de alt parte,
legturile generate manual i informaiile asociate lor pot fi folosite la obinerea mai
multor informaii despre nodurile care se conecteaz. Se deprinde de aici concluzia c
este necear o prezentare ierarhizat, bazat pe legturi (bidirecionate) nsoite de
informaii a unei astfel de baze de date multimedia. n prezent, documentele multimedia
sunt prezentate ierarhizat prin intermediul limbajului HTML.
HTML-ul pe lng faptul c este un limbaj simplu i total independent de hardware,
permite realizarea tuturor acestor proprieti importante ale oricrui sistem ce folosete
informaii multimedia. Dar editorul HTML nu este WYSIWYG. n prezent exist
procesoare de documente Web care pot fi utilizate att la crearea ct i la formatarea
documentelor HTML, pstrnd caracteristicile acestuia. Dintre acestea cele mai
rspndite sunt: HotMetaL, HTML Assistant, Spider, WebAuthor.
Regsirea informaiei prin folosirea imaginilor indexate a fost rezolvat n mai multe
moduri, fr a da satisfacie total.
Prima abordare folosete tehnica de procesare a imaginilor la identificarea
automat a anumitor obiecte. O problem care apare aici se refer la scal (mrimea
imaginii). Tehnologiile permit ca n documente s se ncarce imaginea, ntr-o prim
faz, la scar redus, ceea ce ar rezolva oarecum problema stocrii acestora.
O alt metod se bazeaz pe una din urmtoarele tehnici de indexare manual a
termenilor i/sau expresiilor ce nsoesc imaginea repectiv:
clasificarea imaginilor ierarhic, dintr-o anumit categorie,
folosirea cuvintelor cheie (analog indexrii documentelor),
utilizarea schemei entitate-atribut-relatie (Leung 1992).
Realizarea tuturor acestor aplicaii n condiii optime nu trebuie s elimine
asigurarea cerinelor unei baze de date, cum sunt: timp minim de acces la date, s
garanteze integritatea, securitatea i independena datelor.

102

Instrumente folosite la realizarea documentelor multimedia

Primul instrument care s-a impus i pe baza cruia se construiesc n prezent
documentele multimedia este limbajul HTML. Acesta s-a dezvoltat treptat, deoarece i
lipseau posibilitile de a descrie publicaii electronice profesionale. Prima lui
formalizare, standardul HTML 2.0, dei mai performant, nu a reuit s satisfac
cerinele unei publicaii electronice profesionale. Despre folosirea unor editoare
WYSIWYG nici nu poate fi vorba, deoarece navigatoarele afieaz acelai document
destul de diferit, n funcie de platforma pe care lucreaz.
Dac ntr-o revist imaginile sunt statice, ntr-o revist electronic ele pot fi
alternate sau dinamice(slide-show). Documentele dinamice au fost ideea Netscape,
care le-a introdus pe pia o dat cu versiunea Netscape 1.0. Metoda, numit Client
Pull, i permite navigatorului s ncarce un document dup un numr de secunde, fr
nici o intervenie din partea utilizatorului.
Natura Web-ului se schimb rapid, de la pagini statice, la pagini a cror form i
coninut se schimb de fiecare dat cnd sunt ncrcate. Acest lucru este posibil
datorit unor limbaje special concepute pentru a putea fi folosite la scrierea de
programe care se insereaz direct n documentele HTML. Ele caracterizeaz ceea ce
numim situri Web din a doua generaie.
Primul dintre acestea, Java, a fost lansat de ctre firma Sun n 1995, printele lui
fiind James Gostling. Limbajul Java este o simplificare a limbajelor orientate pe obiecte,
de fapt a C++ -ului. Java pstreaz proprietile acestora, fiind flexibil, simplu, puternic,
independent de platforma hardware pe care ruleaz.
Cel mai dinamic dintre aceste limbaje pare a fi JavaScript. Dei nu este nc n
forma final, limbajul prezint avantajul scrierii unor programe simple direct n paginile
HTML, programe care pot fi interpretate local de ctre navigator. JavaScript
seamn cu Java, dar spre deosebire de acesta JavaScript are funcii i declaraii de
sine stttoare. Un alt avantaj al acestui limbaj este sigurana, deoarece nu poate fi
utilizat pentru a accesa i scrie pe discul clientului. Folosite mpreun cu HTML, Java i
CGI, duc la creterea performanelor Web-ului i a vitezei de lucru a navigatoarelor.
CGI (Common Gateway Interface) s-a impus ca cea mai eficient, stabil i uor de
neles modalitate de manipulare a informaiei generate n mod dinamic pe Web. Este
de fapt acea parte a server-ului Web care poate comunica cu alte programe care
ruleaz pe sistem. Cu ajutorul acestei interfee, serverul Web poate apela un program.
Cele mai rspndite aplicaii ale CGI-ului sunt:
prelucrarea datelor inserate n formulare (care necesit un rspuns),
interogarea unor baze de date pentru o anumit informaie (se realizeaz cu aa
numitele browsere: Google, Altavista, Yahoo, prin interogri SQL),
realizarea unor documente virtuale (documente HTML complexe, care conin text,
imagini, fiiere de sunet sau video).
Limbajul cel mai des utilizat pentru scrierea programelor este Perl, deoarece pare a
fi cel mai uor de utilizat pentru manipularea textelor i a matricelor. Exist i versiunea
WebForms, Q&D Software Development, a crei interfa grafic permite generarea
rapid i automat a formularelor i a scripturilor CGI n Perl.

103