1.

GENERALITI DESPRE BAZE DE DATE

1.1. Introducere
Baza de date este un ansamblu structurat de date coerente, fr

redondan inutil, astfel nct acestea pot fi prelucrate eficient de mai

muli utilizatori ntr-un mod concurent.
Baza de date este o colecie de date persistente, care sunt folosite de
ctre sistemele de aplicaii ale unei anumite ntreprinderi. Datele din baza
de date persist deoarece, dup ce au fost acceptate de ctre sistemul de
gestiune pentru introducerea n baza de date, ele pot fi terse din baz
numai printr-o cerere explicit adresat sistemului de gestiune.
Aici, termenul de ntreprindere este un cuvnt generic, utilizat
pentru a desemna orice organizaie independent, de natur tehnic,
comercial, tiinific sau de alt tip. ntreprinderea poate fi, de exemplu, un
spital, o banc, o facultate, o fabric, un aeroport etc. Fiecare ntreprindere
are regulile proprii de funcionare i conine o mulime de date
referitoare la modul su de operare.
Datele din baza de date pot fi att integrate, ct i partajate.
Noiunea de integrat se refer la faptul c baza de date poate fi considerat
ca o unificare a mai multor fiiere, iar prin partajare se nelege c baza de
date poate fi partajat concurent ntre diferii utilizatori.
Un sistem de gestiune a bazelor de date (SGBD Data Base
Management System) este un produs software care asigur interaciunea cu
o baz de date, permind definirea, consultarea i actualizarea datelor din
baza de date. Toate cererile de acces la baza de date sunt tratate i
controlate de ctre SGBD. Organizarea datelor n baze de date constituie o
form de centralizare a acestora. Aceasta implic existena unui
administrator al bazei de date (DBA Data Base Administrator)
care este o persoan sau un grup de persoane ce rspund de ansamblul
activitilor (analiz, proiectare, implementare, exploatare, ntreinere etc.)
legate de baza de date. Atribuiile unui administrator pot fi grupate n patru
mari categorii: atribuii de proiectare, atribuii administrative, atribuii
operative i atribuii de coordonare.
Concepte ale bazelor de date relaionale
n aceast parte se face o prezentare general a conceptelor bazelor
de date relaionale.
O baz de date relaional este o colecie de informaii
interrelaionate gestionate ca o singur unitate.

A ceast definiie este foarte larg, deoarece exist mari diferene

ntre concepiile diferiilor productori care pun la dispoziie sisteme de
baze de date. De exemplu, Oracle Corporation definete o baz de date ca
fiind o colecie de fiiere fizice gestionate de o singur instan (copie) a
produsului software pentru baze de date, n timp ce Microsoft definete o
baz de date SQL Server ca fiind o colecie de date i alte obiecte.
Un obiect al bazei de date este o structur de date denumit, stocat
n baz de date, cum ar fi un tabel, o vizualizare sau un index.
Exist mari diferene ntre implementrile furnizorilor de baze de
date. n majoritatea sistemelor de baze de date, datele sunt stocate n mai
multe fiiere fizice, dar n Microsoft Access toate obiectele bazei de date,
mpreun cu datele care aparin unei baze de date sunt stocate ntr-un
singur fiier fizic.(Un fiier este o colecie de nregistrri nrudite stocate ca
o singur untiate de sistemul de operare al calculatorului.) Totui, unul
dintre principalele avantaje ale bazelor de date relaionale este faptul c
detaliile de implementare fizic sunt separate de definiiile logice ale
obiectelor bazei de date, astfel nct majoritatea utilizatorilor bazei de date
nu au nevoie s tie unde (i cum) sunt stocate obiectele bazei de date n
sistemul de fiiere al calculatorului.
Sistem de gestionare a bazei de date (DBMS sau SGBD)
Un sistem de gestionare a bazei de date (DBMS database
management system) este un produs software furnizat de productorul
bazei de date. Produse software precum Microsoft Access, Microsoft SQL
Server, Oracle Database,Sybase, DB2,INGRES, MySQL i Postgre SQL
fac parte din categoria DBMS sau, mai corect, DBMS relaionale
(RDBMS).
RDBMS-urile sunt cunoscute i sub numele de SGBD-uri. Ambele
prescurtri vor fi folosite n acest expunere.
Sistemul DBMS pune la dispoziie toate serviciile de baz necesare
pentru organizarea i ntreinerea bazei de date, inclusiv urmtoarele:
- Transferarea datelor n i din fiierele fizice de date, n funcie de
cerine.
- Gestionarea accesului concurenial la date al mai multor
utilizatori, inclusiv prevenirea conflictelor care ar putea fi
cauzate de actualizrile simultane.
- Gestionarea tranzaciilor, astfel nct toate modificrile fcute
asupra bazei de date printr-o tranzacie s fie executate ca o
singur unitate. Cu alte cuvinte, dac tranzacia reuete, toate

modificrile efectuate de tranzacie sunt nregistrate n baz de

date; dac tranzacia eueaz, nici una dintre modificri nu este
nregistrat n baz de date.Totui, reinei ca unele sisteme
RDBMS nu asigur suportul pentru tranzacii.
- Accept un limbaj de interogare, care reprezint sistemul de
comenzi folosit de utilizator pentru a obine date din baz de
date. SQL este principalul limbaj folosit pentru sistemele DBMS
relaionale.
- Funcii pentru salvarea bazei de date i pentru refacerea bazei de
date n urma erorilor.
- Mecanisme de securitate pentru mpiedicarea accesului neautorizat
la date i modificarea acestora.

Ce este o baz de date relaional ?

O baz de date relaional este o baz de date care respect modelul

relaional, dezvoltat de Dr.E.F.Codd. Modelul relaional prezint datele sub
forma familiarelor tabele bidimensionale, similar cu o foaie de calcul
tabelar. Spre deosebire de o foaie de calcul tabelar, nu este obligatoriu ca
datele s fie stocate ntr-o form tabelar, iar modelul permite i
combinarea tabelelor (crearea uniunilor (joining), n terminologia
relaional) pentru formarea vizualizarilor, care sunt prezentate tot ca tabele
bidimensionale. Flexibilitatea extraordinar a bazelor de date relaionale
este dat de posibilitatea de a folosi tabelele independent sau n combinaii,
fr nici o ierarhie sau secven predefinit n care trebuie s se fac
accesul la date.

Dicionarul datelor (catalog de sistem), structurat i administrat

ca o baz de date (metabaz de date), contine date despre date, furnizeaz

descrierea tuturor obiectelor unei baze de date, starea acestor obiecte,
diversele constrngeri de securitate i de integritate etc. Dicionarul poate fi
interogat, la fel, ca orice alt baz de date.

1.2. Gestiunea bazelor de date

Un sistem de baze de date presupune urmtoarele componente
principale, care definesc arhitectura acestuia:
baza de date propriu-zis n care se memoreaz datele;
sistemul de gestiune a bazei de date, care realizeaz gestionarea i
prelucrarea complex a datelor;
un dicionar al bazei de date (metabaza de date), ce conine
informaii despre date, structura acestora, statistici, documentaie;
mijloace hardware (comune sau specializate);
reglementri administrative destinate bunei funcionri a
sistemului;
personalul implicat (utilizatori finali, administratorul datelor,
administratorul bazei de date, proiectani, programatori de
aplicaii).
Se pot identifica patru categorii de persoane implicate n mediul
bazelor de date:
administratorii de date i baze de date,
proiectanii (designeri) de baze de date,
programatorii de aplicaii,
utilizatorii finali.
Administratorul de date (DA) este un manager, nu un tehnician, ce:
decide care date trebuie stocate n baza de date;
stabilete regulile de ntreinere i de tratare a acestor date dup ce
sunt stocate. De exemplu, o regul ar putea fi aceea prin care se
stabilesc pentru utilizatori privilegii asupra informaiilor din baza
de date, cu alte cuvinte o anumit politic de securitate a datelor.
Administratorul bazei de date (DBA) este responsabil cu
implementarea deciziilor administratorului de date i cu controlul general al
sistemului, la nivel tehnic. El este un profesionist n domeniul IT, care:
creeaz baza de date real;
implementeaz elementele tehnice de control;
este responsabil cu asigurarea funcionrii sistemului la
performane adecvate, cu monitorizarea performanelor;
furnizeaz diverse servicii tehnice etc.
Proiectanii de baze de date pot acoperi att aspectul fizic, ct i cel
logic al concepiei.
Proiectantul de baze de date care abordeaz direcia logic trebuie s
posede o cunoatere complet i amnunit a modelului real de proiectat i
a regulilor de funcionare ale acestuia. Practic, acesta proiecteaz

conceptual baza de date, iar modelul creat este independent de programele

de aplicaii, de limbajele de programare. De asemenea, va proiecta logic
baza de date, proiectare care este ndreptat spre un anumit model de date
(relaional, orientat obiect, ierarhic etc.).
Proiectantul de baze de date fizice preia modelul logic de date i
stabilete cum va fi realizat fizic. Acesta trebuie s cunoasc
funcionalitile SGBD-ului, avantajele i dezavantajele fiecrei alternative
corespunztoare unei implementri. Practic, se face transpunerea modelului
logic ntr-un set de tabele supuse unor constrngeri, se selecteaz structuri
de stocare i metode de acces specifice, astfel nct s se asigure
performane, se iau msuri privind securitatea datelor.
Utilizatorii finali sunt cei care acceseaz interactiv baza de date.
Aceasta a fost proiectat, implementat, ntreinut pentru a satisface
necesitile informaionale ale clienilor. Utilizatorii finali pot fi utilizatori
simpli, care nu cunosc nimic despre baza de date, despre SGBD, dar
acceseaz baza prin intermediul unor programe de aplicaie. n general,
aceast clas de utilizatori alege anumite opiuni din meniul aplicaiei.
Exist utilizatori finali sofisticai, care sunt familiarizai cu structura bazei
de date. Ei pot utiliza limbaje speciale pentru a exploata posibilitile
oferite de baza de date.
Programatori de aplicaii sunt responsabili de scrierea programelor
aplicaie ce confer funcionalitatea cerut de utilizatorii finali. Programele
pot fi scrise n diferite limbaje de programare (C++, PL/SQL, Java etc.).

Cerine minimale care se impun unei baze de date:

asigurarea unei redundane minime n date;

furnizarea n timp util a informaiilor solicitate (timpul de rspuns
la o interogare);
asigurarea unor costuri minime n prelucrarea i ntreinerea
informaiei;
capacitatea de a satisface, cu aceleai date, necesiti
informaionale ale unui numr mare de utilizatori,
posibilitatea de adaptare la cerine noi, rspunsuri la interogri
neprevzute iniial (flexibilitate);
exploatarea simultan a datelor de ctre mai muli utilizatori
(sincronizare);
asigurarea securitii datelor prin mecanisme de protecie mpotriva
accesului neautorizat (confidenialitate);

nglobarea unor faciliti destinate validrii datelor i recuperrii

lor n cazul unor deteriorri accidentale, garantarea (att ct este
posibil) c datele din baza de date sunt corecte (integritate);
posibilitatea de valorificare a eforturilor anterioare i anticiparea
nevoilor viitoare (compatibilitate i expandabilitate);
permisivitatea, prin ierarhizarea datelor dup criteriul frecvenei
acceselor, a unor reorganizri (eventual dinamice) care sporesc
performanele bazei.
n cadrul unei baze de date putem vorbi de patru niveluri de
abstractizare i de percepie a datelor: intern, conceptual, logic i
extern. Datele exist doar la nivel fizic, iar celelalte trei niveluri reprezint
virtualizri ale acestora.
Nivelul fizic (intern) este descris de schema fizic a datelor (bit,
octet, adres);
Nivelul conceptual este descris de schema conceptual a datelor
(articol, nregistrare, zon) i reprezint viziunea programatorilor
de sistem asupra datelor;
Nivelul logic este descris de una din schemele logice posibile ale
datelor i reprezint viziunea programatorului de aplicaie asupra
datelor;
Nivelul virtual (extern) reprezint viziunea utilizatorului final
asupra datelor.
Independena datelor cuprinde dou aspecte fundamentale: o
modificare a structurii fizice nu va afecta aplicaia i reciproc, modificri
ale aplicaiei vor lsa nealterat structura fizic de date.
Independena fizic: posibilitatea modificrii schemei fizice a
datelor fr ca aceasta s implice modificarea schemei conceptuale,
a schemei logice i a programelor de aplicaie. Este vorba despre
imunitatea programelor de aplicaie fa de modificrile modului n
care datele sunt stocate fizic i accesate.
Independena logic: posibilitatea modificrii schemei conceptuale
a datelor fr ca aceasta s implice modificarea schemei logice i a
programelor de aplicaie. Prin independena logic a datelor se
urmrete a se crea fiecrui utilizator iluzia c este singurul
beneficiar al unor date pe care, n realitate, le folosete n comun
cu ali utilizatori.
Independen fa de strategiile de acces permite programului s
precizeze data pe care dorete s o acceseze, dar nu modul cum acceseaz
aceast dat. SGBD-ul va stabili drumul optim de acces la date.

n limbajele de programare uzuale declaraiile i instruciunile

executabile aparin aceluiai limbaj. n lumea bazelor de date, funciile de
declarare i de prelucrare a datelor sunt realizate cu ajutorul unor limbaje
diferite, numite limbaje pentru baze de date.
Limbaje pentru definirea datelor (DDL Data Description
Language). Descrierea concret a unui DDL este specific fiecrui
sistem de gestiune, dar funciile principale sunt aceleai. La nivel
conceptual, DDL realizeaz definirea entitilor i a atributelor
acestora, sunt precizate relaiile dintre date i strategiile de acces la
ele, sunt stabilite criterii difereniate de confidenialitate i de
validare automat a datelor utilizate.
Limbaje pentru prelucrarea datelor (DML Data Manipulation
Language). Operaiile executate n cadrul unei baze de date
presupun existena unui limbaj specializat, n care comenzile se
exprim prin fraze ce descriu aciuni asupra bazei. n general, o
comand are urmtoarea structur: operaia (calcul aritmetic sau
logic, editare, extragere, deschidere-nchidere, adugare, tergere,
cutare, reactualizare etc.), criterii de selecie, mod de acces
(secvenial, indexat etc.), format de editare. Exist limbaje DML
procedurale, care specific cum se obine rezultatul unei comenzi
DML i limbaje neprocedurale, care descriu doar datele ce vor fi
obinute i nu modalitatea de obinere a acestora.
Limbaje pentru controlul datelor (DCL Data Control Language).
Controlul unei baze de date se refer la asigurarea confidenialitii
i integritii datelor, la salvarea informaiei n cazul unor
defeciuni, la obinerea unor performane, la rezolvarea unor
probleme de concuren.
Limbajele universale nu se utilizeaz frecvent pentru gestionarea
unei baze de date, dar exist aceast posibilitate. De exemplu, sistemul
Oracle este dotat cu precompilatoare (C, Pascal, ADA, Cobol, PL/1,
Fortran) care ajut la incorporarea de instruciuni SQL sau blocuri PL/SQL
n programe scrise n alte limbaje, de nivel nalt, numite limbaje gazd.
Sistemul de gestiune a bazelor de date interacioneaz cu programele
de aplicaie ale utilizatorului i cu baza de date, oferind o mulime de
faciliti. Realizarea optim a acestor faciliti este asigurat de
obiectivele fundamentale ale unui sistem de gestiune. Cteva dintre
aceste obiective vor fi enumerate n continuare.
Independena fizic. Obiectivul esenial este acela de a permite
realizarea independenei structurilor de stocare n raport cu

structurile de date din lumea real. Se definete mulimea de date

indiferent de forma acesteia din lumea real, innd seama doar de
a realiza un acces simplu la date i de a obine anumite
performane.
Independena logic. Grupul de lucru care exploateaz baza de date
poate s utilizeze diferite informaii de baz (nu aceleai), pentru ai construi entiti i relaii. Fiecare grup de lucru poate s
cunoasc doar o parte a semanticii datelor, s vad doar o
submulime a datelor i numai sub forma n care le dorete.
Aceast independen asigur imunitatea schemelor externe fa de
modificrile fcute n schema conceptual.
Prelucrarea datelor de ctre neinformaticieni. Neinformaticienii
vd datele independent de implementarea lor i pot exploata aceste
date prin intermediul unui sistem de meniuri oferit de aplicaia pe
care o exploateaz.
Administrarea centralizat a datelor. Administrarea datelor
presupune definirea structurii datelor i a modului de stocare a
acestora. Administrarea este n general centralizat i permite o
organizare coerent i eficace a informaiei.
Coerena datelor. Informaia trebuie s satisfac constrngeri
statice sau dinamice, locale sau generale.
Neredundana datelor. Fiecare aplicaie posed datele sale proprii
i aceasta conduce la numeroase dubluri. De asemenea,
organizarea nejudicioas a relaiilor poate s genereze redundan
n date. Administrarea coerent a datelor trebuie s asigure
neduplicarea fizic a datelor. Totui, nu sunt excluse nici cazurile
n care, pentru a realiza performane referitoare la timpul de acces
la date i rspuns la solicitrile utilizatorilor, s se accepte o
anumit redundan a datelor.
Partajabilitatea datelor. Aceasta permite ca aplicaiile s partajeze
datele din baza de date n timp i simultan. O aplicaie poate folosi
date ca i cum ar fi singura care le utilizeaz, fr a ti c alt
aplicaie, concurent, le poate modifica.
Securitatea i confidenialitatea datelor. Datele trebuie protejate de
un acces neautorizat sau ru intenionat. Exist mecanisme care
permit identificarea i autentificarea utilizatorilor i exist
proceduri de acces autorizat care depind de date i de utilizator.
Sistemul de gestiune trebuie s asigure securitatea fizic i logic a
informaiei i s garanteze c numai utilizatorii autorizai pot
efectua operaii corecte asupra bazei de date.

Sistemele de gestiune a bazelor de date au, din nefericire, i

dezavantaje dintre care se remarc:
complexitatea i dimensiunea sistemelor pot s creasc
considerabil, datorit necesitii extinderii funcionalitilor
sistemului;
costul, care variaz n funcie de mediu i funcionalitatea oferit,
la care se adug cheltuieli periodice de ntreinere;
costuri adiionale pentru elemente de hardware;
costul conversiei aplicaiilor existente, necesar pentru ca acestea
s poat funciona n noua configuraie hardware i software;
impactul unei defeciuni asupra aplicaiilor, bazei de date sau
sistemului de gestiune.

Structura unui sistem de gestiune a bazelor de date este de

complexitate variabil, iar nivelul real de funcionalitate difer de la produs

la produs. n orice moment apar noi necesiti, care cer o nou
funcionalitate, astfel nct aceasta nu va putea deveni niciodat static. n
general, un SGBD trebuie s includ cel puin cinci clase de module:
programe de gestiune a bazei de date (PGBD), care realizeaz
accesul fizic la date ca urmare a unei comenzi;
module pentru tratarea limbajului de definire a datelor, ce permit
traducerea unor informaii (care realizeaz descrierea datelor, a
legturilor logice dintre acestea i a constrngerilor la care sunt
supuse), n obiecte ce pot fi apoi exploatate n manier procedural
sau neprocedural;
module pentru tratarea limbajului de prelucrare a datelor
(interpretativ, compilativ, generare de programe), care permit
utilizatorilor inserarea, tergerea, reactualizarea sau consultarea
informaiei dintr-o baz de date;
module utilitare, care asigur ntreinerea, prelucrarea, exploatarea
corect i uoar a bazei de date;
module de control, care permit controlul programelor de aplicaie,
asigurarea confidenialitii i integritii datelor, rezolvarea unor
probleme de concuren, recuperarea informaiei n cazul unor
avarii sau defeciuni hardware sau software etc.

10

Modulele PGBD asigur accesul fizic la date ca urmare a unei

comenzi. Cum lucreaz aceste module?
gsesc descrierea datelor implicate n comand;
identific datele i tipul acestora;
identific informaii ce permit accesul la structurile fizice de
stocare (fiiere, volume etc.);
verific dac datele sunt disponibile;
extrag datele, fac conversiile, plaseaz datele n spaiul de memorie
al utilizatorului;
transmit informaii de control necesare execuiei comenzii, n
spaiul de memorie al utilizatorului;
transfer controlul programului de aplicaie.
Prin urmare, din punct de vedere conceptual:
utilizatorul lanseaz o cerere de acces;
SGBD-ul accept cererea i o analizeaz;
SGBD-ul inspecteaz pe rnd, schema intern corespunzatoare
utilizatorului, schema conceptual, definiia structurii de stocare i
corespondenele corespunztoare;
SGBD-ul execut operaiile necesare n baza de date stocat.

1.3. Arhitectura sistemelor de gestiune a bazelor de date

Asigurarea independenei fizice i logice a datelor impune adoptarea
unei arhitecturi de baze de date organizat pe trei niveluri:
nivelul intern (baza de date fizic);
nivelul conceptual (modelul conceptual, schema conceptual);
nivelul extern (modelul extern, subschema, vizualizarea).
Nivelul central este nivelul conceptual. Acesta corespunde structurii
canonice a datelor ce caracterizeaz procesul de modelat, adic structura
semantic a datelor fr implementarea pe calculator. Schema conceptual
permite definirea tipurilor de date ce caracterizeaz proprietile elementare
ale entitilor, definirea tipurilor de date compuse care permit regruparea
atributelor pentru a descrie entitile modelului i legturile ntre aceste
entiti, definirea regulilor pe care trebuie s le respecte datele etc.
Nivelul intern corespunde structurii interne de stocare a datelor.
Schema intern permite descrierea datelor unei baze sub forma n care sunt

11

stocate n memoria calculatorului. Sunt definite fiierele care conin aceste

date, articolele din fiiere, drumurile de acces la aceste articole etc.
La nivel conceptual sau intern, schemele descriu o baz de date. La
nivel extern schemele descriu doar o parte din date care prezint interes
pentru un utilizator sau un grup de utilizatori. Schema extern reprezint o
descriere a unei pri a bazei de date ce corespunde viziunii unui program
sau unui utilizator. Modelul extern folosit este dependent de limbajul
utilizat pentru prelucrarea bazei de date. Schema extern permite asigurarea
unei securiti a datelor. Un grup de lucru va accesa doar datele descrise n
schema sa extern, iar restul datelor sunt protejate mpotriva accesului
neautorizat sau ru intenionat.
Pentru o baz de date particular exist o singur schem intern, o
singur schem conceptual, dar exist mai multe scheme externe.
n afar de aceste trei niveluri, arhitectura presupune i anumite
corespondene dintre acestea:
corespondena conceptual-intern definete relaia dintre nivelul
conceptual i baza de date stocat, specificnd modul n care
nregistrrile i cmpurile conceptuale sunt reprezentate la nivel
intern;
corespondena extern-conceptual definete relaia dintre o anumit
vizualizare extern i nivelul (vizualizarea) conceptual,
reprezentnd cheia independenei logice de date;
corespondena extern-extern permite definirea unor vizualizri
externe n funcie de altele, fr a necesita o definiie explicit a
corespondenei cu nivelul conceptual.
Arhitectura funcional de referin propus de grupul de lucru
ANSI/X3/SPARC este axat pe dicionarul datelor i cuprinde dou pri:
prima, permite descrierea datelor (compoziia dicionarului
datelor);
a doua, permite prelucrarea datelor (interogarea i reactualizarea
bazei de date).
n fiecare parte se regsesc cele trei niveluri: intern, conceptual i
extern. Acestea nu sunt neaprat distincte pentru orice SGBD.
Interfeele numerotate din figura 1.1, ce descriu arhitectura de
referin a unui SGBD, corespund urmtoarelor transformri:
a) Limbaj de descriere a datelor conceptuale, format surs permite
administratorului ntreprinderii s defineasc schema conceptual,
format surs.

12

Limbaj de descriere a datelor conceptuale, format obiect se

obine din compilarea celui precedent i permite aranjarea schemei
obiect n dicionarul datelor.
c) Limbaj de descriere a datelor conceptuale, format editare
permite administratorilor aplicaiilor i a bazelor s consulte
schema conceptual pentru a defini reguli de coresponden.
d) Limbaje de descriere a datelor externe, format surs permit
administratorilor aplicaiilor s defineasc scheme externe
corespunznd schemei conceptuale. Deoarece sistemele de
gestiune pot suporta mai multe modele externe, pot exista mai
multe limbaje de descriere a datelor externe.
e) Limbaje de descriere a datelor externe, format obiect corespund
formelor compilate ale celor precedente i permit aranjarea
schemelor externe (obiect) n dicionarul datelor.
f) Limbaj de descriere a datelor interne, format surs permite
administratorului bazei de date s defineasc schema intern i
regulile de coresponden cu schema conceptual.
g) Limbaj de descriere a datelor interne, format obiect corespunde
formei compilate a celui precedent i permite aranjarea schemei
interne (obiect) n dicionarul datelor.
h) Limbaje de prelucrare a datelor externe, format surs permit
programatorilor de aplicaii sau utilizatorilor neinformaticieni s
manipuleze date externe (view).
i) Limbaje de prelucrare a datelor externe, format obiect corespund
formelor compilate ale celor precedente.
j) Limbaj de prelucrare a datelor conceptuale, format obiect produs
de procesorul de transformare extern/ conceptual pentru a
manipula datele externe.
k) Limbaj de prelucrare a datelor interne, format obiect produs de
procesorul de transformare conceptual/intern pentru a gestiona
datele interne.
l) Limbaj de stocare a datelor, format obiect corespunde interfeei
cu sistemul de stocare a datelor.
m) Interfaa cu memoria secundar permite efectuarea de
intrri/ieiri n/din unitatea de memorie secundar.
n) Interfaa de acces la dicionarul datelor permite diverselor
procesoare de transformare s acceseze scheme obiect i reguli de
coresponden.
b)

13

Procesoarele din figura 1.1 au urmtoarele funcii:

procesorul schemei conceptuale compileaz schema conceptual i
dac nu sunt erori depune schema compilat n dicionarul datelor;
procesorul schemei externe compileaz schemele externe i
regulile de coresponden extern i dac nu sunt erori aranjeaz
schema compilat i regulile de coresponden n dicionarul
datelor;
procesorul schemei interne are rol similar pentru schema intern;
procesorul de transformare extern/conceptual transform
manipulrile externe n manipulri conceptuale i invers, datele
conceptuale n date externe;
procesorul de transformare conceptual/intern transform
manipulrile conceptuale n manipulri interne i invers, datele
interne n date conceptuale;
procesorul de transformare intern/stocare transform manipulrile
interne n primitive ale sistemului de stocare i invers, elibereaz
datele stocate ntr-un format corespunztor schemei interne.

14
administrator
ntreprindere

a
c

procesor
schema
conceptual

administratorul
aplicaiilor

procesor
schema
intern

DESCRIERE

administratorul
bazei de date

dicionarul
datelor

procesor
schema
extern

procesor
intern/
alocare

procesor
conceptual/
intern

procesor
extern/
conceptual

sistem
de
alocare

program
aplicaii
extern

h
m
programator
aplicaie

PRELUCRARE

utilizatori

memorii
secundare

Fig. 1.1. Arhitectura de referin a unui SGBD.

Gardarin a propus o arhitectur funcional apropiat de arhitectura
sistemelor de gestiune actuale care are la baz doar dou niveluri:
schema, care corespunde integrrii schemelor interne i
conceptuale;
vizualizarea, care este o schem extern.

15

Sistemul de gestiune gestioneaz un dicionar de date care este

alimentat prin comenzi de definire a schemei i prin comenzi de definire a
vizualizrilor.
Aceste comenzi, precum i cererile de prelucrare sunt analizate i
tratate de un procesor numit analizor. Analizorul realizeaz analiza
sintactic i semantic a cererii i o traduce n format intern. O cerere n
format intern care face referin la o vizualizare este tradus n una sau mai
multe cereri care fac referin la obiecte ce exist n baza de date
(modificarea cererilor).
n cadrul acestei arhitecturi exist un procesor, numit translator,
care realizeaz modificarea cererilor, asigur controlul drepturilor de acces
i controlul integritii n cazul reactualizrilor.
Componenta cheie a sistemului de gestiune este procesorul
optimizor care elaboreaz un plan de acces optim pentru a trata cererea.
Acest procesor descompune cererea n operaii de acces elementare i alege
o ordine de execuie optimal. De asemenea, evalueaz costul planului de
acces naintea execuiei sale.
Planul de acces ales i elaborat de optimizor este executat de un
procesor numit executor. La acest nivel este gestionat controlul
concurenei.

1.4. Evoluia bazelor de date

Istoria bazelor de date i a sistemelor de gestiune a bazelor de date
poate fi rezumat n trei generaii:
sisteme ierarhice i reea,
sisteme relaionale,
sisteme avansate (orientate obiect, relaionale orientate obiect,
deductive, distribuite, multimedia, multibaze, active, temporale,
decizionale, magazii de date etc.).

Baze de date ierarhice i reea

Pentru modelele ierarhice i reea, datele sunt reprezentate la nivel de
articol prin legturi ierarhice (arbore) sau de tip graf. Slaba independen
fizic a datelor complic administrarea i prelucrarea acestora. Limbajul de
prelucrare a datelor impune programatorului s specifice drumurile de
acces la date.

16

Baze de date relaionale

A doua generaie de SGBD-uri este legat de apariia modelelor
relaionale (1970), care trateaz entitile ca nite relaii. Piaa actual de
baze de date este acoperit n majoritate de sisteme relaionale. Bazele de
date relaionale sunt caracterizate de:
structuri de date simple, intuitive,
inexistena pointerilor vizibili pentru utilizator,
constrngeri de integritate,
operatori aplicai relaiilor care permit definirea, cutarea i
reactualizarea datelor.
Dezvoltarea unei aplicaii riguroase utilizand o baz de date
relaionale necesit cunoaterea a trei niveluri de instrumente, eterogene
din punct de vedere conceptual:
nivelul instrumentelor grafice (interfaa);
nivelul aplicaie, cu limbajele sale de dezvoltare;
nivelul SGBD, cu standardul SQL (Structured Query Language) ce
permite definirea, prelucrarea i controlul bazei de date.
Baze de date orientate obiect
Bazele de date relaionale nu folosesc ns obiecte complexe i
dinamice, nu realizeaz gestiunea datelor distribuite i nici gestiunea
cunotinelor. A treia generaie de SGBD-uri, sistemele avansate, ncearc
s depeasc aceste limite ale sistemului relaional.
Suportul obiectelor complexe i dinamice i prelucrarea acestora este
dificil pentru sistemele relaionale, deoarece tipul datelor este limitat la
cteva domenii alfanumerice, iar structura datelor este simpl. Sistemele
relaionale nu modeleaz obiecte complexe ca grafuri, liste etc. Un obiect
complex poate s fie descompus n relaii, dar apar dificulti att la
descompunerea, ct i la refacerea acestuia prin compunere. De asemenea,
limbajele modelului relaional permit prelucrarea cu dificultate a obiectelor
complexe.
Un sistem relaional nu suport obiecte dinamice care incorporeaz
att partea de date (informaii) efective, ct i o parte relativ la tratarea
acestora.
mbinarea tehnicii limbajelor orientate obiect cu a bazelor de date a
permis realizarea bazelor de date orientate obiect. Acestea permit
organizarea coerent a obiectelor partajate ntre utilizatori concureni.
Sistemele de gestiune de baze de date orientate obiect (SGBDOO) prezint
o serie de avantaje:

17

realizeaz o modelare superioar a informaiei,

furnizeaz posibiliti superioare de deducie (ierarhie de clase,
motenire),
permit luarea n considerare a aspectelor dinamice i integrarea
descrierii structurale i comportamentale,
asigur mbuntirea interfeei cu utilizatorul.
Cu toate avantajele incontestabile oferite de SGBDOO-uri,
impunerea lor pe piaa bazelor de date nu a fost uoar. Cteva motivaii a
acestei situaii:
absena unei fundamentri teoretice face imposibil definirea unui
SGBDOO de referin;
gestiunea obiectelor complexe este mai dificil dect accesul la
relaii prin cereri SQL;
utilizatorii au investit sume uriae n sistemele relaionale i nu le
pot abandona cu uurin. Trecerea la noua tehnologie orientat
obiect implic investiii mari i nu pstreaz aproape nimic din
vechile soluii.
Baze de date relaionale orientate obiect
Simplitatea modelului relaional, combinat cu puterea tehnologiei
orientate obiect a generat un domeniu nou i promitor n lumea bazelor de
date, i anume bazele de date relaionale orientate obiect.
Construcia unui sistem de gestiune de baze de date relaionale
orientate obiect (SGBDROO) trebuie s porneasc de la cele existente.
Aceasta se poate realiza n dou moduri: dezvoltnd un sistem relaional
prin adugarea caracteristicilor obiectuale necesare sau pornind de la un
sistem orientat obiect i adugnd caracteristicile relaionale.
Baze de date deductive
O relaie este o mulime de nregistrri ce reprezint fapte.
Cunotinele sunt aseriuni generale i abstracte asupra faptelor.
Cunotinele permit s raionezi, ceea ce permite deducerea de noi fapte,
plecnd de la fapte cunoscute. Un SGBD relaional suport o form limitat
de cunotine, i anume constrngerile de integritate, iar restul trebuie
integrate n programele de aplicaie. Aceasta genereaz probleme deoarece
cunotinele trebuie codificate n programe i apare imposibilitatea de a
partaja cunotine ntre utilizatori. Totul se complic dac exist un volum
mare de fapte.

18

Bazele de date deductive, utiliznd programarea logic, gestioneaz

cunotine relativ la baze de date care, n general, sunt relaionale. Bazele
de date deductive permit deducerea de noi informaii, plecnd de la
informaiile stocate n baza de date. Un SGBD deductiv posed:
un limbaj de definire a datelor care permite definirea structurii
predicatelor sub form de relaii i constrngeri de integritate
asociate;
un limbaj de prelucrare a datelor care permite efectuarea
reactualizrilor asupra datelor i formularea unor cereri;
un limbaj de reguli de deducie care permite ca, plecnd cu
predicatele definite anterior, s se specifice cum pot fi construite
predicate derivate.

Baze de date distribuite

Un sistem distribuit este un ansamblu de maini ce sunt
interconectate printr-o reea de comunicaie i utilizate ntr-un scop global.
Administrarea i prelucrarea datelor distribuite, situate pe diferite
calculatoare i exploatate de sisteme eterogene este obiectivul fundamental
al bazelor de date distribuite.
Bazele de date distribuite sunt sisteme de baze de date cooperante
care rezid pe maini diferite, n locuri diferite. Aceast mulime de baze de
date este exploatat de utilizator ca i cum ar fi o singur baz de date.
Programul de aplicaie care exploateaz o baz de date distribuite poate
avea acces la date rezidente pe mai multe maini, fr ca programatorul s
cunoasc localizarea datelor.
Modelul relaional a rmas instrumentul principal prin care se
realizeaz prelucrarea datelor distribuite.
Cteva dintre argumentele pentru a justifica aceast afirmaie sunt:
bazele relaionale ofer flexibilitate de descompunere n vederea
distribuirii;
operatorii relaionali pot fi folosii pentru combinaii dinamice ale
informaiilor descentralizate;
limbajele sistemelor relaionale sunt concise i asigur o economie
considerabil a transmiterii datelor. Ele fac posibil, pentru un nod
oarecare al reelei, s analizeze intenia unei tranzacii, s o
descompun rapid n componente ce pot fi realizate local i
componente ce pot fi transportate altor noduri.

19

Calculatoare i maini baze de date

Soluia pentru a descentraliza prelucrarea datelor, n scopul evitrii
saturrii memoriei i a procesoarelor calculatorului central, a fost apariia
calculatoarelor baze de date i a mainilor baze de date. Descentralizarea
presupune transferarea unei pri din funciile unui SGBD ctre un
calculator periferic (calculator backend) adic deplasarea algoritmilor de
cutare i a celor de actualizare a datelor mai aproape de memoria
secundar. Acest calculator periferic permite utilizarea optim a resurselor
i realizarea paralelismului n tratarea cererilor de informaii.
Calculatorul periferic poate fi un calculator clasic, dar cu un software
specific de SGBD (calculator baz de date) sau poate fi o main cu
hardware specializat n gestiunea bazelor de date (main baz de date).
Mainile baze de date sunt nzestrate cu arhitecturi paralele special adaptate
pentru gestionarea unui volum mare de date. Tratarea paralel a cererilor
permite reducerea timpului total de execuie a acestora.
O execuie n paralel solicit, fie descompunerea unui program n
module, care pot fi executate n paralel (descompunere funcional), fie
descompunerea datelor n subgrupe, astfel nct toate procesoarele s
execute acelai lucru, dar pe date diferite. Performanele tratrii paralele
depind de modul n care sunt efectuate descompunerile.
Multibaze de date
Diferite departamente ale unei organizaii mai mari pot folosi diferite
sisteme de gestiune. Cu toate c fiecare sistem este dezvoltat pentru a
satisface nevoile propriului su departament, informaiile cu care lucreaz
pot fi utile i altor departamente. De aceea, pentru ca organizaia s
funcioneze bine, trebuie s existe o modalitate global da a vedea datele
din fiecare sistem. Exist dou caracteristici ale unor astfel de sisteme care
fac acceasarea datelor n acest mediu integrat greoaie, uneori chiar
imposibil:
autonomie fiecare SGBD are o autonomie complet, ceea ce
nseamn c fiecare manager are control deplin asupra sistemului;
eterogenitate sistemele pot opera pe diferite platforme, cu diferite
modele de date i limbajele de interogare.
Una dintre soluiile folosite pentru a depi dificultile ntmpinate n
respectarea autonomiei i a eterogenitii este utilizarea sistemelor multibaze
de date.

20

Un sistem multibaze de date (SMB) este alctuit din mai multe sisteme
de baze de date privite integrat, n care se construiesc una sau mai multe
scheme globale pe baza schemelor fiecrei baze de date componente, astfel
nct s se poat realiza accesul uniform i integrat la fiecare din bazele de
date componente. Fiecare schem global este construit pe baza unui model
particular de date. De exemplu, se poate construi o schem global ce are la
baz modelul relaional pentru utilizatorii care sunt familiarizai cu acest
model, dar se poate construi o schem global bazat pe modelul orientat
obiect pentru utilizatorii bazelor de date orientate obiect.
Pentru o schem global dat, un sistem multibaze de date const din
sistemele componente mpreun cu un sistem front-end, care suport un
singur model de date i un singur limbaj de interogare. Principalele sarcini ale
sistemului front-end sunt gestionarea schemei globale i procesarea cererilor
globale.
Un avantaj major al acestui model, fa de altele, este faptul c o
singur interogare poate accesa date din mai multe baze de date ntr-un mod
integrat, fr s afecteze nici o aplicaie care este scris utiliznd una dintre
bazele de date componente.
Baze de date cu suport decizional
Sistemele informatice, n particular bazele de date, au ajuns la
maturitate. Marile companii au acumulat o mare cantitate de informaii din
domeniul lor de activitate, pe care le pstreaz n tabele istorice i sunt
nefolositoare sistemelor operaionale ale companiei, care funcioneaz cu
date curente. Analizate, aceste date ar putea oferi informaii despre tendine
i evoluii care ar putea interesa compania. Pentru a putea analiza aceste
mari cantiti de date este nevoie de tehnologii i instrumente speciale.
Ideea de a analiza colecii de date provenind din sistemele
operaionale ale companiei sau din surse externe pentru a le folosi ca suport
n procesul de decizie nu aparine ultimului deceniu, dar baze de date care
s funcioneze eficient dup aceste criterii au fost studiate i implementate
n ultimii ani. Principalul scop al acestor baze de date a fost de a ntmpina
nevoile sistemelor operaionale, a cror natur este inerent tranzacional.
Sistemele tranzacionale sunt interesate, n primul rnd, s controleze
la un moment dat o singur tranzacie. De exemplu, ntr-un sistem bancar,
atunci cnd clientul face un depozit, sistemul operaional bancar este
responsabil de a nregistra tranzacia ntr-un tabel al tranzaciilor i de a
crete nivelul curent al contului clientului, stocat n alt tabel.

21

Un sistem operaional tipic opereaz cu evenimente predefinite i,

datorit naturii lor, necesit acces rapid la date. Uzual, fiecare tranzacie
opereaz cu cantiti mici de date.
De-a lungul timpului, nevoile sistemelor operaionale nu se schimb
mult. Aplicaia care nregistreaz tranzacia, ca i cea care controleaz
accesul utilizatorului la informaie (partea de raportare a sistemului
bancar), nu se modific prea mult. n acest tip de sistem, informaia
necesar n momentul n care un client iniiaz o tranzacie trebuie sa fie
actual. nainte ca o banc s aprobe un mprumut este nevoie s se asigure
de situaia financiar stabil a clientului n acel moment, i nu cu un an
nainte.
n ultimii ani s-au pus la punct principii i tehnologii noi care s
serveasc procesului de analiz i administrare a datelor. O baz de date
optimizat n acest scop definete o Data Warehouse (magazie de date), iar
principiul pe care l urmeaz este cunoscut sub numele de procesare
analitic (OLAP On Line Analytical Processing). Spre deosebire de
acesta, principiul pe care se bazeaz sistemele tranzacionale a fost numit
procesare tranzacional (OLTP On Line Transactional Processing).
Aplicaiile unei Data Warehouse trebuie s ofere rspunsuri unor
ntrebri de tipul: Care zi din sptmn este cea mai aglomerat? Ce
clieni, cu care avem relaii intense, nu au beneficiat de reduceri de
preuri?. O caracteristic a bazelor de date analitice este c interogrile la
care acestea trebuie s rspund sunt ad-hoc, nu sunt predefinite, iar baza
de date trebuie optimizat astfel nct s fie capabil s rspund la orice
fel de ntrebare care poate implica mai multe tabele.
n aceast abordare, organele generale de decizie necesit accesul la
toate datele organizaiei, oriunde s-ar afla acestea. Pentru o analiz
corespunztoare a organizaiei, afacerilor, cerinelor, tendinelor este
necesar nu numai accesarea valorilor curente din baza de date, ci i a
datelor istorice. Prin urmare, pentru a facilita acest tip specific de analiz a
informaiei a fost creat magazia de date, care conine informaii extrase
din diverse surse, ntreinute de diverse uniti operative, mpreun cu
istoricul i rezumatul tranzaciilor.
Sursele de date pentru o magazie cuprind:
date operaionale, pstrate n baze de date ierarhice, de prima
generaie;
date departamentale, pstrate n sisteme de fiiere patentate;

22

date cu caracter personal, pstrate pe staii de lucru i servere

personale;
sisteme externe (baze de date comerciale, Internet etc.)
Data warehouse este o colecie de date:
orientate spre subiect (principalele subiecte ale modelului sunt
clienii, produsele, vnzrile, n loc de domeniile de activitate),
nevolatile (datele nu sunt reactualizate, nlocuite n timp real, ci
sunt adugate ca un supliment al bazei),
integrate (transpunerea datelor provenite din diverse surse de
informaii se face ntr-un format consistent),
variabile n timp (concentrarea depozitului de date se face asupra
schimbrilor care au loc n timp).
Administrator Depozit de date

Utilitare
cereri,
rapoarte

META-FLUX
Sursa 1
Date operationale

FLUX
INTERN

Metadate
Date cu nivel
mare de agregare
Administrator
incarcare date

Administrator
cereri
FLUX
Date cu nivel
EXTERN
mic de agregare FLUX
ASCENDENT
Date detaliate
SGBD

Sursa n
Date operationale

Utilitare
OLAP

Utilitare
Data mining

Administrator Depozit de date

Arhive/ date
backup

FLUX
DESCENDENT

Utilitare pentru
accesul
utilizatorilor finali

Fig 1.2. Arhitectura unui depozit de date

nmagazinarea datelor se concentreaz asupra gestionrii a cinci
fluxuri de informaii:

23

fluxul intern, care reprezint procesele asociate extragerii i

ncrcrii datelor din fiierele surs n magazia de date;
fluxul ascendent, care reprezint procesele asociate adugrii de
valoare datelor din magazie, cu ajutorul mpachetrii i distribuirii;
fluxul descendent, care reprezint procesele asociate arhivrii,
salvrii, refacerii datelor din magazie;
fluxul extern, care reprezint procesele asociate punerii la dispoziie
a datelor pentru utilizatorii finali;
meta-fluxul, care reprezint procesele asociate gestionrii metadatelor (date despre date).
n arhitectura depozitului de date intervin cteva componente
specifice acestei structuri.
Administratorul pentru ncrcarea datelor (componenta front-end)
realizeaz toate operaiile asociate cu obinerea (extragerea) i
ncrcarea datelor operaionale ntr-un depozit de date.
Administratorul depozitului de date realizeaz toate operaiile
legate de administrarea datelor din depozit. Operaiile realizate de
componenta de administrare a depozitului de date includ: analiza
datelor pentru a asigura consistena acestora; transformarea i
mutarea datelor surs din structurile temporare de stocare n
tabelele depozitului de date; crearea de indeci i vizualizri asupra
tabelelor de baz; generarea denormalizrii (dac este necesar);
generarea agregrilor; crearea arhivelor i a backup-urilor.
Administratorul cererilor (componenta back-end) realizeaz toate
operaiile legate de administrarea cererilor utilizator. Aceast
component este construit folosind utilitarele de acces la date
disponibile utilizatorilor finali, utilitarele de monitorizare a
depozitului de date, facilitile oferite de sistemul de baze de date
i programele personalizate.
n zona ce include date agregate sunt stocate toate agregrile
predefinite de date, pe diferite niveluri. Scopul, meninerii
acestora, este de a mri performana cererilor care necesit
agregri. Datele agregate sunt actualizate permanent, pe msur ce
sunt ncrcate noi informaii n depozit.
Scopul principal al depozitelor de date este de a oferi informaii
necesare utilizatorilor pentru luarea deciziilor strategice de
marketing. Aceti utilizatori interacioneaz cu depozitul de date
prin diferite utilitare de acces (utilitare pentru rapoarte i cereri,

24

utilitare pentru dezvoltarea aplicaiilor, utilitare pentru procesarea

analitic on-line (OLAP), utilitare data mining) etc.
Instrumentele de acces pentru utilizatorii finali ai magaziilor de date:
prelucrarea analitic on-line;
extensiile limbajului SQL;
instrumentele de extragere a datelor.
Prelucrarea analitic on-line (OLAP) reprezint sinteza, analiza i
consolidarea dinamic a unor volume mari de date multidimensionale.
Serverele de baze de date OLAP utilizeaz structuri multidimensionale
pentru stocarea datelor i a relaiilor dintre date. Aceste structuri pot fi
vizualizate prin cuburi de date i cuburi n cadrul cuburilor etc. Fiecare
latur a cubului reprezint o dimensiune. Serverele de baze de date OLAP
multidimensionale accept operaiile analitice uzuale: consolidarea
(gruparea), parcurgerea n jos (inversul consolidrii), tranarea, tierea.
OLAP necesit o modalitate de agregare a datelor conform mai multor
grupri diferite, n numr foarte mare, iar utilizatorii trebuie s le aib n
vedere pe toate.
Instrumentele OLAP presupun organizarea informaiei ntr-un model
multidimensional care este susinut de o baz de date:
multidimensional (MOLAP), n care datele sunt stocate
conceptual n celulele unui tablou multidimensional;
relaional (ROLAP), proiectat pentru a permite
interogri multidimensionale.
n acest context, a devenit o necesitate extinderea limbajului SQL
prin operaii puternice, necesare pentru rezolvarea noului tip de abordare.
Au fost introduse noi funcii numerice (limita inferioar, limita superioar
etc.), noi funcii statistice (distribuie, distribuie invers, corelaie etc.), noi
operatori de agregare, extensii ale clauzei GROUP BY etc.
De exemplu, RISQL (Red Brick Intelligent SQL), proiectat pentru
analitii din domeniul afacerilor, permite: ordonare dup rang (pe diferite
niveluri - de exemplu, gruparea filialelor n trei categorii pe baza venitului
generat n anul precedent), partajarea pieei, compararea anului curent cu
cel precedent etc.
O alt problem esenial este extragerea datelor i utilizarea
acestora pentru luarea de decizii cruciale n domeniul afacerilor.
Descoperirea unor noi corelaii, tipare, tendine, prin extragerea unor
cantiti mari de date folosind strategia inteligenei artificiale este una din
modalitile de rezolvare.
Extragerea datelor presupune capacitatea de a construi modele mai
degrab previzibile, dect retrospective. Modelarea predictiv utilizeaz

25

informaii pentru a forma un model al caracteristicilor importante ale unui

fenomen.
Tehnicile asociate operaiilor fundamentale de extragere sunt:
modelarea predictiv (clasificarea cu ajutorul unei reele neurale
sau al unei inducii de tip arbore i previziunea valorilor, utiliznd
tehnici de regresie);
segmentarea bazei de date (comasarea demografic i comasarea
neural care se deosebesc prin metodele uilizate pentru a calcula
distana dintre nregistrri, prin intrrile de date permise);
analiza legturilor (descoperirea asocierilor, descoperirea tiparelor,
descoperirea secvenelor de timp similare);
detectarea deviaiilor (statistici i vizualizri pentru identificarea
mprtierii datelor, utiliznd tehnici moderne de vizualizare
grafic). n aceast clas pot fi considerate, de exemplu, detectarea
fraudelor privind utilizarea crilor de credit, preteniile de
despgubire ale asigurailor etc.
n concluzie, spre deosebire de un sistem OLTP, Data Warehouse
este o baz de date a crei structur este proiectat pentru a facilita analiza
datelor. Un sistem de suport decizional urmrete, n primul rnd, obinerea
de informaii din baza de date, n timp ce unul OLTP urmrete
introducerea de informaii n baza de date. Datorit acestor diferene,
structura optim a unei Data Warehouse este radical diferit de cea a unui
sistem OLTP.
Depozitele de date i sistemele OLTP sunt supuse unor cerine
diferite, dintre care cele mai semnificative se refer la operaii, actualizarea
datelor, proiectare, operaii tipice i date istorice.
Operaii. Depozitele sunt create pentru a permite interogri ad hoc.
Ele trebuie s fie suficient de flexibile pentru a putea rspunde
interogrilor spontane ale utilizatorilor. Sistemele OLTP suport
numai operaii predefinite. Aplicaiile pot fi optimizate sau create
special numai pentru acele operaii.
Actualizarea datelor. Utilizatorii finali ai unui depozit de date nu
fac n mod direct actualizri ale depozitului. n sistemele OLTP,
utilizatorii realizeaz, de obicei, n mod individual procedurile de
modificare a bazei de date. n acest fel, baza de date OLTP este
ntotdeauna la zi i reflect starea curent a fiecrei tranzacii.
Proiectare. Depozitele de date folosesc, n mod uzual, scheme
denormalizate, n timp ce sistemele OLTP folosesc scheme
normalizate pentru a optimiza performanele operaiilor.

26

Operaii tipice. O simpl interogare a depozitului de date poate

scana mii sau chiar milioane de nregistrri (de exemplu, cererea
Care sunt vnzrile totale ctre toi clienii din luna trecut?), n
timp ce o operaie tipic OLTP acceseaz doar o parte mai mic
din nregistrri.
Date istorice. Depozitele de date stocheaz datele pe o perioad
lung de timp, luni sau ani. Acest lucru ofer suport pentru analiza
istoric a informaiei. Sistemele OLTP rein date istorice att timp
ct este necesar pentru a ndeplini cu succes cerinele tranzaciilor
curente.
Sistemele OLTP
Pstreaz date curente

Data Warehouse
Pstreaz date istorice
Stocheaz date detaliate, agregate uor
Stocheaz date detaliate
sau puternic
Datele sunt dinamice
Datele sunt n mare msur statice
Prelucrare ad-hoc, nestructurat i
Prelucrare repetitiv
euristic
Nivel nalt de transfer al Nivel mediu sau sczut de transfer al
tranzaciilor
tranzaciilor
Tipar de utilizare previzibil Tipar de utilizare imprevizibil
Conduse prin tranzacii

Conduse prin analiz

Susin deciziile de zi cu zi
Deservesc un numr mare
de utilizatori
Orientate spre aplicaii

Susin deciziile strategice

Deservesc un numr relativ redus de
utilizatori din administraie
Orientate spre subiect

Fig. 1.3. OLTP versus Data Warehouse

O baz de date OLAP poate fi relaional, dar datorit naturii ei
orientate spre dimensiuni, au fost dezvoltate pentru gestionarea acestor
baze de date construcii multidimensionale, mai potrivite pentru o raportare
flexibil. Spre deosebire de bazele de date relaionale, structura unei baze
de date multidimensionale nu implic tabele, linii i coloane, ci obiecte de
urmtoarele tipuri: variabile, dimensiuni, niveluri, ierarhii, atribute.
Data Warehouse, care cuprinde de obicei informaii despre o
ntreag companie, poate fi submprit n baze de date departamentale,
numite rafturi de date (Data Marts). De exemplu, poate exista un Data

27

Mart al departamentului financiar, un altul al departamentului vnzri i un

altul pentru departamentul marketing.
Construcia unei astfel de baze de date poate fi abordat n dou
moduri.
O prim abordare este de a construi mai nti un schelet al bazei de
date la care se lipesc ulterior rafturile de date. Aceasta necesit o
analiz prealabil a ntregului i o delimitare a blocurilor
componente. Ea cere un timp mai lung de dezvoltare, dar rezultatul
este o baz de date unitar.
A doua metod este de a construi mai nti rafturi specifice, efortul
constnd, n acest caz, n asocierea acestora. Aceast soluie ofer
mai rapid, aplicaii funcionale utilizatorilor, dar au de suferit
unitatea i portabilitatea aplicaiilor finale.
Utilizatorii trebuie s-i schimbe optica asupra bazelor de date pentru
a fi capabili s foloseasc puterea i flexibilitatea instrumentelor analitice
de care dispun. Instrumentele OLAP au evoluat ca o modalitate de a
rezolva interogrile complicate necesare procesului de analiz a datelor.
Combinaia ntre bazele de date multidimensionale i instrumentele
analitice prietenoase face uoar analiza, sinteza i consolidarea datelor.
n ultimii ani, marii productori de sisteme de gestiune a bazelor de
date relaionale, precum Oracle, au introdus n produsele lor construcii
care s faciliteze accesul la datele din sistemele fundamentale pentru luarea
de decizii. Astfel, noile versiuni de SGBD-uri ale firmelor mari prevd o
modalitate mai inteligent de a realiza operaia de compunere ntre dou
sau mai multe tabele, metode de indexare noi, potrivite pentru marile
cantiti de date statice cu care opereaz sistemele Data Warehouse,
capacitatea de a detecta i optimiza interogri de un tip special,
posibilitatea de a folosi mai multe procesoare pentru a rezolva o interogare.
Un sistem Data Warehouse are un efect fundamental asupra
utilizatorilor. Ei pot manevra mult mai flexibil sistemul, au posibiliti
elevate pentru interogarea datelor, dar ei trebuie s tie cum s prelucreze i
s vizualizeze datele i cum s le foloseasc n procesul de decizie.
Un efort ce trebuie fcut pentru construirea unui sistem de suport
pentru decizii (DSS Decision Support System) const n procesul de
descoperire a informaiilor utile din baza de date. Acest proces, numit Data
Mining sau Knowledge Discovery in Databases (KDD), proceseaz mari
cantiti de date, a cror corelare nu este neaprat evident, n vederea
descoperirii de tendine i tipare.

28

1.5. Arhitecturi multi-user pentru sisteme de gestiune a

bazelor de date
Arhitecturile uzuale care sunt utilizate pentru implementarea
sistemelor de gestiune a bazelor de date multi-user sunt: teleprocesarea,
arhitectura fiier-server arhitectura client-server.
Teleprocesarea este arhitectura tradiional, ce cuprinde un
calculator cu o singur unitate CPU i un numar de terminale care sunt
incapabile s funcioneze singure. Terminalele trimit mesaje la programele
aplicaie ale utilizatorilor, care la rndul lor, utilizeaz serviciile SGBD.
Aceast arhitectur a plasat o greutate teribil asupra calculatorului
central, care pe lng rularea programelor de aplicaii i ale SGBD-ului,
mai trebuie s preia i din munca terminalelor (de exemplu, formatarea
datelor pentru afiarea pe ecran).
Arhitectura fiier-server, presupune deja c procesarea este
distribuit n reea (de obicei o reea local LAN). Arhitectura cuprinde
fiierele cerute de aplicaii i SGBD-ul. Aplicaiile i funciile SGBD sunt
executate pe fiecare staie de lucru, solicitnd cnd este nevoie fiiere de pe
server-ul de fiiere. Dintre dezavantaje se remarc:
existena unui trafic intens pe reea;
necesitatea unei copii complete a SGBD-ului pe fiecare
staie de lucru;
acelai fiier poate fi accesat de mai multe SGBD-uri,
ceea ce implic un control complex al integritii, simultaneitii,
reconstituirii.
Arhitectura client-server se refer la modul n care interacioneaz
componentele software pentru a forma un sistem. Exist un proces client,
care necesit resurse i un proces server, care ofer resurse.
n arhitectura client-server, clientul (front end) emite, prin
intermediul reelei locale, o cerere SQL care este executat pe server (backend); acesta trimite ca rspuns ansamblul nregistrrilor rezultat. ntr-o
astfel de interaciune mainile sunt eterogene, iar protocoalele de reea pot
fi distincte.
n contextul bazelor de date, client-ul:
administreaz interfaa cu utilizatorul i logica aplicaiei;
accept i verific sintaxa intrrilor utilizatorilor;
proceseaz aplicaiile;
genereaz cerinele pentru baza de date i le trimite server-ului;

29

transmite rspunsul napoi la utilizator.

n contextul bazelor de date, server-ul:
primete i proceseaz cerinele clienilor pentru baza de date;
verific autorizarea;
garanteaz respectarea constrngerilor de integritate;
efectueaz procesarea interogare-reactualizare i trimite clientului
rspunsul;
realizeaz optimizarea interogrilor;
asigur controlul concurenei dintre mai multi clieni care se ignor
(mecanisme de blocare);
intreine dictionarul datelor;
ofer acces simultan la baza de date;
asigur robusteea n cazul defeciunilor;
ofer controlul reconstituirii etc.
Arhitectura tradiional client-server pe dou etaje (straturi)
presupune:
client-ul responsabil, n primul rand, de prezentarea datelor ctre
client;
server-ul responsabil, n primul rand, de furnizarea serviciilor
ctre client.
Arhitectura client-server pe trei etaje presupune trei straturi,
fiecare fiind rulat, potenial, pe o platform diferit.
stratul (client) format din interfaa cu utilizatorul, care este rulat pe
calculatorul utilizatorului final;
stratul (server de aplicaie), ce manevreaz logica aplicaiilor i
prelucrrii datelor, i care poate servi mai muli clieni (conectare
la celelalte dou straturi se face prin reele locale LAN sau de mare
suprafa WAN);
stratul (server-ul de baze de date), care se ocup cu validarea
datelor i accesarea bazei de date (stocheaz date necesare stratului
din mijloc).
Arhitectura se potrivete natural mediului Web. Un browser Web
acionnd drept client i un server Web fiind server de aplicaie.
Middleware este un strat, evident software, ntre aplicaia postului
client i server-ul de baze de date, constituit dintr-o interfa de programare
a aplicaiilor (API - Application Programming Interface) i un protocol de
reea.

30

API descrie tipul de interaciune dintre o aplicaie client i un server

la distan, via un protocol de comunicaie i de formatare a datelor. Scopul
existenei interfeei de programare a aplicaiilor este de a oferi o interfa
unic mai multor server-e de baze de date.
Este convenabil ca sistemele de baze de date s fie considerate ca
fiind formate dintr-un server (sistemul SGBD nsi) i un set de clieni
(aplicaiile). Frecvent, clienii i server-ul pot fi rulate pe calculatoare
diferite, realizndu-se un tip simplu de procesare distribuit. n general,
fiecare server poate deservi mai multi clieni, iar fiecare client poate accesa
mai multe server-e. Dac sistemul ofer transparen total (fiecare client
se poate comporta ca i cum ar comunica cu un singur server, de pe un
singur calculator) atunci este vorba despre un sistem de baze de date
distribuite.

1.6. Tehnologia Web i sistemele SGBD

Internet = o colecie mondial de reele de calculatoare.
Intranet = un sit Web sau un grup de sit-uri care aparin unei
organizaii, accesibil numai pentru membrii acesteia.
Extranet = o reea intranet care este parial accesibil utilizatorilor
externi autorizai.
Reea Web (World Wide Web) = un sistem bazat pe hipermedii care
pune la dispoziie un mijloc simplu, de tip indicare-clic de rsfoire a
informaiilor pe Internet, folosind hiperlegturile.
HTTP = protocolul utilizat pentru a transfera pagini Web prin
intermediul Internetului.
HTML = limbajul de formatare a documentelor utilizat n
proiectarea majoritii paginilor Web.
Adresa URL = ir de caractere alfanumerice care reprezint adresa
unei resurse pe Internet i modul n care trebuie accesat resursa.
Interfaa de poart comun (CGI) = definete modul n care
scripturile comunic cu server-ul Web. Este tehnica de baz de integrare a
bazelor de date n reeaua Web.
n mediul Web funcioneaz modelul three tier format din:
un strat de interfa cu utilizatorul (client),
un strat de logic a afacerii i prelucrare a datelor (server de
aplicaii),
un sistem SGBD (server de baze de date) distribuit pe calculatoare
diferite.
Avantajele reelei Web ca platform de baze de date:
avantagele SGBD;

31

simplitate;
independena de platform;
interfaa grafic cu utilizatorul;
acces transparent n reea;
standardizare (HTML standard de facto).
Arhitectura de calcul n reea a sistemului Oracle (NCA Network
Computing Architecture) se axeaz n principal pe furnizarea
extensibilitii pentru mediile distribuite. Arhitectura este construit pe
baza tehnologiei CORBA pentru manipularea obiectelor. Este o structur
three tier care se bazeaz pe utilizarea de:
cartue de software care permit utilizatorilor s adauge
funcionaliti individuale n aplicaii (cartuele pot fi construite
n Java, C/C++, Visual Basic, SQL i pot fi conectate la oricare
din cele 3 straturi);
protocoale deschise i interfee standardizate care permit
comunicarea ntre cartue (distribuite ntr-o reea) prin
intermediul unui program magistral (ICX);
clieni extensibili, server-e de aplicaie, server-e de baze
de date;
dezvoltarea i administrarea integrat a cartuelor.
Un cartus utilizeaza un limbaj de definire a interfetelor (IDL)
pentru a putea fi identificat de alte obiecte intr-un sistem distribuit. De
exemplu, PL/SQL este un astfel de cartus.

Arhitectura multitier a sistemului Oracle9i

Arhitectura cu mai multe niveluri (multitier) conine urmtoarele

elemente:
unul sau mai muli client-i care iniiaz operaii;
unul sau mai multe server-e de aplicaii care execut pri ale
operaiilor;
un server de baze de date care stocheaz datele folosite de operaii.
Client-ul, care poate fi un browser Web sau un proces user, iniiaz o
cerere pentru a executa o operaie referitoare la informaiile stocate n baza
de date. Conectarea la server-ul bazei de date se face printr-unul sau mai multe
server-e de aplicaii.
Server-ul de aplicaii constituie interfaa dintre client-i i server-ul
bazei de date, asigurnd accesul la informaii. De asemenea, el include un
nivel adiional pentru securitate. Server-ul de aplicaii i asum identitatea
client-ului, atunci cnd execut, pe server-ul de baze de date, operaiile
solicitate de acesta.
Arhitectura multitier permite folosirea unui server de aplicaii pentru

32

acreditarea client-ului, conectarea la server-ul de baze de date i execuia

operaiilor iniiate de client. Privilegiile server-ului de aplicaii sunt limitate
pentru a preveni execuia operaiilor nedorite sau inutile n timpul unei
operaii client.
Server-ul de baze de date pune la dispoziia server-ului de aplicaii
informaiile necesare pentru soluionarea operaiilor lansate de ctre client.
De asemenea, acesta face distincia ntre operaiile pe care server-ul de
aplicaii le cere n favoarea client-ului i cele pe care le solicit n nume
propriu.

Oracle9i Developer Suite

HTTP

Clienti HTTP

Oracle9i Application
Server

Oracle9i Database

Nivel 1

Nivel 2

Nivel 3

Fig. 1.4. Arhitectura three-tier a sistemului Oracle9i

2 MODELAREA
ENTITATE - RELAIE
Proiectarea bazelor de da te orientate ob iect
MODEL AREA BAZELO R D E DAT E

2.1. Preliminarii
Un model este o reprezentare a obiectelor i evenimentelor lumii reale i
a asocierilor dintre ele. De fapt, el reprezint o abstracie asupra aspectelor
semnificative ale unei ntreprinderi, ale unui sistem real, ignornd proprietile
accidentale. Modelul este cel pe care utilizatorii trebuie s-l cunoasc;
implementarea unui model este cea pe care utilizatorii nu este necesar s o
cunoasc. Diferena dintre model i implementare este, de fapt, un caz special i
important al deosebirii uzuale dintre logic i fizic.
Modelele se impun prin sintaxa i prin semantica lor i, din acest punct
de vedere, exist trei tipuri fundamentale de modele:
modele care descriu aspectele statice ale procesului modelat;
modele care descriu aspectele dinamice ale procesului modelat;
modele care descriu aspectele funcionale ale procesului modelat.
Un model de date reprezint o colecie integrat de concepte necesare
descrierii:
datelor,
relaiilor dintre ele,
constrngerilor existente asupra datelor sistemului real analizat.
Modelarea unei baze de date permite trecerea de la percepia unor fapte
din lumea real la reprezentarea lor prin date. Modelul de date trebuie s
reflecte fidel fenomene ale lumii reale, s urmreasc evoluia acestei lumi i
comunicarea dintre fenomenele lumii reale.
Modelul trebuie s asigure conceptele de baz care permit proiectantului
bazei de date i utilizatorilor s comunice, fr ambiguiti, cunotinele lor
privind funcionarea i organizarea modelului real analizat. Prin urmare, un
model de date trebuie s reprezinte datele i s le fac nelese.
n esen, modelul de date are trei componente:
o mulime de reguli conform crora sunt construite bazele de date
(partea structural);
o mulime de operaii permise asupra datelor, care sunt utilizate pentru
reactualizarea sau regsirea datelor (partea de prelucrare);
o mulime de reguli de integritate, care asigur coerena datelor.
Abordarea general a problemei modelrii semantice a datelor se face n
patru etape.

58

PROIECTAREA BAZELOR DE DATE

Se identific o mulime de concepte semantice care sunt utile n

descrierea lumii reale. Se presupune c lumea real (modelul real
analizat) este format din entiti care au anumite proprieti, c
fiecare entitate are o identitate, c exist legturi, corelaii ntre
entiti. Conceptul de corelaie, ca i cel de entitate, este util, n mod
intuitiv, la descrierea modelului.
Se caut o mulime de obiecte formale, simbolice care sunt utilizate
pentru reprezentarea conceptelor semantice anterioare.
Se dau reguli de integritate formale i generale (constrngeri) care s
reflecte restriciile la care este supus modelul.
Se definete o mulime de operatori formali prin care pot fi prelucrate
i analizate obiectele formale.

2.2. Modelul entitate-relaie

Una dintre cele mai cunoscute abordri ale modelrii semantice (cu
siguran una dintre cele mai utilizate) este cea bazat pe modelul entitaterelaie (E/R). Acesta a fost introdus de ctre Peter.P. Chen n 1976 i rafinat
de atunci n diverse moduri de ctre acesta i de muli ali cercettori, ca un
model de date conceptual, pentru a uura proiectarea bazelor de date. Pentru
reprezentarea grafic a modelului sunt utilizate diagramele E/R, care sunt
modele neformalizate pentru reprezentarea unui model, unui sistem din lumea
real.
Diagramele E/R constituie o tehnic de reprezentare a structurii logice a
bazei de date, ntr-o manier grafic. Aceste diagrame ofer un mijloc simplu i
inteligibil de comunicare a caracteristicilor importante ale designului unei
anumite baze de date.
Diagrama E/R este un model de date conceptual de nivel nalt,
independent de platforma hardware utilizat i de tipul SGBD-ului. Modelul
este constituit din concepte care descriu structura bazei de date i tranzaciile de
regsire sau reactualzare asociate.
Popularitatea modelului E/R ca modalitate de abordare a proiectrii
bazelor de date poate fi atribuit n principal tehnicii de realizare a diagramelor
E/R. Aceast tehnic, ca i modelul E/R nsui, a evoluat de-a lungul timpului
datorit noilor problematici care au aprut n proiectarea bazelor de date.
Baza de date poate fi definit ca o mulime de date ce modeleaz un
sistem real. Acest sistem este format din obiecte legate ntre ele. Modelul
E/R mparte elementele unui sistem real n dou categorii: entiti i relaii
(legturi, asocieri) ntre aceste entiti. Entitiile i legturile au anumite
caracteristici, numite atribute. Nu trebuie confundat conceptul de relaie,
n sensul de asociere, care intervine n definirea diagramei E/R cu
conceptul de relaie care este specific modelului relaional.

Modelarea entitate-relaie

59

Studiu de caz
Exemplele din acest capitol se refer la proiectarea unui model de date ce
furnizeaz informaii despre prezentri de mod, evenimente care reprezint
momente importante n lumea caselor de mod.
Vom prezenta modelul de date, restriciile pe care trebuie s le respecte i
vom ncerca, ntr-o manier didactic, s construim diagrama E/R
corespunztoare. Vom considera, n abordarea iniial, anumite situaii care nu
sunt optime, n sensul c pot genera redundan, anomalii la reactualizri sau nu
permit rezolvarea anumitor interogri asupra modelului. Vom ncerca s artm
care sunt deficienele modelului, situaiile care le-au generat i cum pot fi
corectate (parial sau total) anomaliile respective.
Modelul de date va gestiona informaii legate de organizarea i
funcionarea prezentrilor de mod. Exist firme organizatoare care se ocup de
buna desfurare a acestor prezentri. O firm organizatoare poate fi contactat
prin angajai specializai pe diferite domenii (financiar, social, publicitate,
securitate, sisteme de iluminare, coregrafie, sisteme de sonorizare, cazare,
primiri/plecri aeroport etc.).
Firme specializate sunt angajate pentru soluionarea problemelor legate
de securitate, publicitate, asigurri, iar restul problemelor sunt rezolvate cu
salariaii proprii ai caselor de mod i a firmei organizatoare. Modalitile de
securitate, asigurri, publicitate proprii caselor de mod, modelelor sau
ageniilor de modele nu intr n proiectarea modelului.
Prezentrile pot fi sponsorizate, considerndu-se doar informaiile
referitoare la persoane (fizice sau juridice) care au contribuit efectiv la
finanarea prezentrilor de mod. Mai exact, nu sunt inclui sponsorii posibili.
La aceste evenimente particip case de mod, care prezint vestimentaii
concepute de creatorii casei respective. Creatorii pot fi cei care concep
vestimentaia (designeri) sau cei care o realizeaz efectiv, incluznd croitori,
lucrtori care se ocup cu broderia sau cu realizarea diverselor accesorii.
n cadrul prezentrii de mod, vestimentaiile sunt purtate de manechine
care aparin anumitor agenii de modele. Casele de mod angajeaz modele care
s le prezinte vestimentaiile cu prilejul acestor evenimente. Modelul de date
prezint i un istoric al activitii manechinelor (n cadrul diverselor agenii).
Casele de mod angajeaz pentru o prezentare stiliti care se ocup cu
machiajul i coafura modelelor.
De asemenea, modelul analizeaz informaii legate de localizarea i
accesarea firmelor de publicitate, a persoanelor de contact din firmele
organizatoare, a caselor de mod, a ageniilor i a modelelor, a sponsorilor, a
societilor de asigurare i a firmelor care asigur securitatea evenimentelor.
Modelul de date respect anumite restricii de funcionare.
Casele de mod pot fi organizatori de prezentri.
Chiar dac o cas de mod este organizator, ea apeleaz la serviciile
unei firme specializate n organizarea unor astfel de evenimente.

60

PROIECTAREA BAZELOR DE DATE

Un model sau un stilist este angajat (temporar) pentru o prezentare, de

o singur cas de mod.
O cas de mod poate angaja mai multe modele i mai muli stiliti
pentru o prezentare.
Orice prezentare de mod are un organizator unic, care poate apela la
serviciile altor instituii specializate (securitate, asigurri, publicitate).
Pentru organizator s-a considerat un singur cont n/din care se pot face
plile.
O cas de mod poate avea mai muli designeri, dar un designer poate
lucra pentru o singur cas de mod.
Pentru contactarea unei persoane fizice sau juridice s-a considerat cte
un singur numr de telefon fix, telefon mobil, fax i o singur adres de
mail.
Pentru localizarea unei persoane fizice sau juridice s-a considerat o
singur adres de baz.
Sunt luai n considerare doar angajaii firmei de paz i protecie care
particip efectiv la asigurarea securitii prezentrilor de mod.
Creatorii de accesorii pot fi angajai permaneni ai unei case de mod.
Dac pentru anumite vestimentaii sunt necesare accesorii create de
specialiti care nu aparin casei de mod, acetia vor fi considerai
angajai special pentru evenimentul respectiv.
S-a considerat c proprietarul unei case de mod fie este unic, fie, dac
sunt mai muli, va fi considerat drept proprietar cel care deine numrul
maxim de aciuni.
Entitate
Entitatea este un obiect sau un concept, care este semnificativ pentru
modelul real analizat. O entitate poate fi dependent (slab), existena sa
depinznd de alt entitate sau independent (tare), caz n care ea nu depinde de
existena altei entiti.
Entitatea poate fi persoan, loc, concept, activitate etc. Prin urmare, ea
poate fi un obiect cu existen fizic, real sau poate fi un obiect cu existen
conceptual, abstract.
Pentru o analiz didactic a problematicii abordate, construirea
diagramelor E/R, se vor considera i aspecte ale modelului real analizat, care nu
apar n diagrama final.
Pentru modelul de date referitor la prezentrile de mod, structurile
PUBLICITATE, ORGANIZATOR, PERS_CONTACT, PREZENTARE,
SPONSOR, FIRMA_PUB, CASA_MODA, CREATOR, VESTIMENTATIE,
MODEL, ACCESORIU, LOCALIZARE, AGENTIE, ISTORIC, FIRMA_SEC,
ANGAJAT_SEC,SOCIETATE_ASIG, ANGAJAT_TEMP, INFO_CONTACT,
LOCATIE reprezint entiti.
Observaii
Entitile devin tabele n modelele relaionale.
n general, entitile se scriu cu litere mari.

Modelarea entitate-relaie

61

Entitile sunt substantive, dar nu orice substantiv este o entitate.

Trebuie ignorate substantivele nerelevante.
Cheia primar identific unic o entitate i face distincie ntre valori
diferite ale entitii. Aceasta trebuie s fie unic i cunoscut la orice
moment. Cheia primar trebuie s fie controlat de administratorul
bazei, s nu conin informaii descriptive, s fie simpl, fr
ambiguiti, s fie stabil, s fie familiar utilizatorului astfel nct
acesta s o poat folosi cu uurin.
Pentru fiecare entitate este obligatoriu s se dea o descriere detaliat.
Nu pot exista, n aceeai diagram, dou entiti cu acelai nume, sau
o aceeai entitate cu nume diferite.
Vom prezenta entitile modelului de date, dnd o descriere complet a
fiecreia. De asemenea, pentru fiecare entitate se va preciza cheia primar.
Toate entitile care vor fi prezentate sunt independente, cu excepia
entitilor dependente ACCESORIU, ISTORIC i a subentitii MODEL.
ORGANIZATOR = firm (persoan juridic) specializat, care se ocup cu
organizarea i buna desfurare a unei prezentri de mod. Ea poate apela la
societi specializate pentru rezolvarea problemelor ce apar n organizarea
prezentrii de mod sau poate oferi servicii proprii pentru desfurarea optim a
evenimentului. Cheia primar a entitii este cod_organizator.
PERS_CONTACT = persoan fizic, aparinnd firmei organizatoare, care este
responsabil cu un anumit domeniu de activitate specific organizrii prezentrii
de mod. Ea poate fi contactat pentru diversele probleme care privesc
prezentarea, fiind punctul de legtur dintre direciile din firma organizatoare i
cele din societile externe, care se ocup efectiv cu realizarea tuturor
problemelor ce apar n organizarea evenimentului. Atributul cod_pers_contact
reprezint cheia primar a entitii.
SPONSOR = persoan fizic sau juridic ce contribuie financiar sau n alt
manier la desfurarea prezentrii de mod. Cheia primar a acestei entiti
este cod_sponsor.
FIRMA_PUB = persoan juridic ce asigur publicitatea evenimentului. Firma
organizatoare poate apela la mai multe firme de publicitate. Cheia primar a
acestei entiti este cod_firma_pub.
PUBLICITATE = activitatea efectiv de publicitate asigurat de o firm de
publicitate. Firmele de publicitate asigur diferite modaliti de realizare a
publicitii (pres, televiziune, radio etc.). Cheia primar a acestei entiti este
cod_publicitate.
FIRMA_SEC = persoan juridic ce asigur securitatea prezentrii de mod. Se
consider c o singur firm asigur securitatea evenimentului. Cheia primar a
acestei entiti este cod_firma_sec.

62

PROIECTAREA BAZELOR DE DATE

ANGAJAT_SEC = persoan fizic, angajat a unei firme de securitate, care

particip efectiv la asigurarea serviciilor de paz i protecie a prezentrilor de
mod. Cheia primar a acestei entiti este cod_angajat.
SOC_ASIG = persoan juridic responsabil de asigurarea (din punctul de
vedere al societii organizatoare) tuturor activitilor pe care le implic
prezentarea de mod. Se consider c firma organizatoare apeleaz la o singur
societate de asigurri. Modelul de date nu ia n considerare asigurrile fcute de
ageniile de modele pentru angajatele sale, asigurrile ncheiate chiar de ctre
modele sau asigurrile contractate de casele de mod. Cheia primar a acestei
entiti este cod_soc_asig.
PREZENTARE = evenimentul efectiv al prezentrii de mod. Modelul de date
consider doar prezentri de mod semnificative din lumea caselor de mod.
Cheia primar a acestei entiti este cod_prezentare.
CASA_MODA = persoan juridic a crei activitate const n crearea de
vestimentaii i accesorii pentru aceste vestimentaii. Cheia primar a entitii
este cod_casa_moda.
CREATOR = persoan fizic, angajat (permanent sau special) a unei case de
mod, care creeaz efectiv vestimentaiile sau accesoriile acestora prezentate n
cadrul evenimentului respectiv. Cheia primar a entitii este cod_creator.
VESTIMENTATIE = vestimentaia conceput i realizat de creatorii unei case
de mod. Cheia primar a entitii este cod_vestimentatie.
ACCESORIU = entitate dependent de VESTIMENTATIE, care conine
informaii referitoare la accesoriile unei anumite vestimentaii. Cheia primar a
entitii este compus din cod_accesoriu i cod_ vestimentatie.
ANGAJAT_TEMP = persoan fizic, angajat temporar pentru o anumit
prezentare de ctre o cas de mod, fie pentru realizarea machiajului i a
coafurii modelelor care vor prezenta vestimentaii n cadrul prezentrii (stilist),
fie pentru a purta creaiile acesteia la prezentarea respectiv (model). Cheia
primar a entitii este cod_angajat_temp.
MODEL = subentitate a entitii ANGAJAT_TEMP, ce conine informaii
specifice manechinelor. Cheia primar a entitii este cod_angajat_temp.
AGENTIE = agenia de modele care se ocup cu gestionarea activitilor
(participare la prezentri de mod, contracte pentru reclama diverselor produse
etc.) modelelor sale. Cheia primar a entitii este cod_agentie.
ISTORIC = entitate dependent de MODEL, care conine istoricul angajrilor
unui model la diferite agenii. Cheia primar a entitii este compus din
cod_model i data_angajare.
LOCALIZARE = identific localizarea unei persoane fizice (sponsor, persoan
de contact, model, creator, stilist), juridice (firm de publicitate, securitate,
asigurri, organizator, cas de mod, agenie de modele) sau eveniment
(prezentare de mod). Cheia primar a entitii este cod_localizare.

Modelarea entitate-relaie

63

LOCATIE = entitate care identific locaia n care se desfoar o anumit

prezentare de mod. Cheia primar a entitii este cod_locatie.
INFO_CONTACT = identific modalitatea de contact a unei persoane fizice
(sponsor, persoan de contact, angajat temporar, creator) sau juridice (firm de
publicitate, securitate, asigurri, organizator, cas de mod, agenie de modele).
Cheia primar a entitii este cod_info_contact.
Relaie
Relaia (asocierea) este o comunicare ntre dou sau mai multe entiti. O
valoare a unei relaii este o comunicare ntre valorile entitilor pe care le leag.
Relaia exprim un raport care exist ntre aceste entiti. Gradul unei
relaii este dat de numrul de entiti participante ntr-o relaie (de exemplu,
relaie binar, ternar, cvadrupl, n-ar).
Existena unei relaii este subordonat existenei entitilor pe care le
leag. ntre dou entiti pot exista mai multe relaii.
O relaie n care aceeai entitate particip mai mult dect o dat n diferite
roluri definete o relaie recursiv. Uneori, aceste relaii sunt numite unare.
Observaii
n modelul relaional, relaiile devin tabele speciale sau coloane
speciale care refer chei primare.
Relaiile sunt verbe, dar nu orice verb este o relaie.
Pentru fiecare relaie este important s se dea o descriere detaliat.
n aceeai diagram pot exista relaii diferite cu acelai nume. n acest
caz, ele sunt difereniate de ctre entitile care sunt asociate prin
relaia respectiv.
Pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i
minim) relaiei, adic numrul de tupluri ce aparin relaiei.
Asupra entitilor participante ntr-o relaie pot fi impuse constrngeri
care trebuie s reflecte restriciile care exist n lumea real asupra relaiilor. O
clas de constrngeri, numite constrngeri de cardinalitate, este definit de
numrul de nregistrri posibile pentru fiecare entitate participant (raport de
cardinalitate). Cel mai ntlnit tip de relaii este cel binar, iar n acest caz
rapoartele de cardinalitate sunt, n general, one-to-one (1:1), one-to-many (1:n)
sau many-to-many (m:n).
De exemplu, n modelul analizat este definit relaia organizeaza care
leag entitile ORGANIZATOR i PREZENTARE, relaie care poate fi scris
sub forma ORGANIZATOR_organizeaza_PREZENTARE, pentru a percepe mai
uor asocierile existente. Relaia are cardinalitatea minim 1:1 i cardinalitatea
maxim 1:n.
Vom prezenta relaiile modelului de date, dnd o descriere complet a
fiecreia. De fapt, denumirile acestor legturi sunt sugestive, reflectnd

64

PROIECTAREA BAZELOR DE DATE

coninutul acestora i entitile pe care le leag. Pentru fiecare relaie se va

preciza cardinalitatea minim i maxim.
FIRMA_PUB_face_PUBLICITATE = relaie care leag entitile FIRMA_PUB
i PUBLICITATE, reflectnd legtura dintre acestea (ce publicitate face o
anumit firm de publicitate). Ea are cardinalitatea minim 1:1 (o firm de
publicitate trebuie s realizeze cel puin o publicitate i o publicitate trebuie
fcut de cel puin o firm de publicitate) i cardinalitatea maxim 1:n (o firm
de publicitate poate asigura mai multe publiciti, iar o publicitate poate fi
fcut de o singur firm specializat).
PUBLICITATE_se_face_PREZENTARE = relaie care leag entitile
PUBLICITATE i PREZENTARE, reflectnd legtura dintre acestea (pentru o
prezentare, ce publicitate se face). Relaia are cardinalitatea minim 1:1 i
cardinalitatea maxim 1:n.
ORGANIZATOR_are_PERS_CONTACT = relaie dintre ORGANIZATOR i
PERS_CONTACT, reflectnd legtura dintre acestea (ce persoane din firma
organizatoare pot fi contactate pentru soluionarea diverselor probleme). Ea are
cardinalitatea minim 1:1 i cardinalitatea maxim 1:n.
FIRMA_SEC_are_ANGAJAT_SEC = relaie dintre entitile FIRMA_SEC i
ANGAJAT_SEC, reflectnd legtura dintre acestea (ce angajai, implicai n
aciunea de paz a prezentrilor de mod, au firmele de securitate). Ea are
cardinalitatea minim 1:1 i cardinalitatea maxim 1:n.
ANGAJAT_SEC_paza_PREZENTARE = relaie de tip many-to-many dintre
entitatea PREZENTARE i ANGAJAT_SEC, reflectnd legtura dintre acestea
(ce angajai ai firmei de securitate asigur buna desfurare a prezentrilor de
mod). Ea are cardinalitatea minim 1:1 i cardinalitatea maxim m:n.
SOC_ASIG_asigura_PREZENTARE = relaie dintre entitatea PREZENTARE i
SOC_ASIG, reflectnd legtura dintre acestea (ce societate este angajat pentru
asigurarea diverselor aspecte din cadrul prezentrii de mod). Ea are
cardinalitatea minim 1:1 i cardinalitatea maxim 1:n.
CASA_MODA_participa_PREZENTARE = relaie de tip many-to-many dintre
entitile CASA_MODA i PREZENTARE (ce case de mod particip la
prezentri). Ea arat i dac respectivele case particip, sau nu, ca organizator la
prezentari. Relaia are cardinalitatea minim 1:1 i cardinalitatea maxim m:n.
CASA_MODA_lucreaza_CREATOR = relaie dintre entitile CASA_MODA i
CREATOR (la ce case de mod lucreaz creatorii). Relaia are cardinalitatea
minim 1:1 i cardinalitatea maxim 1:n.
CREATOR_creeaza_VESTIMENTATIE = relaie dintre entitile CREATOR i
VESTIMENTATIE (ce creatori realizeaz vestimentaiile). Relaia are
cardinalitatea minim 1:0 i cardinalitatea maxim1:n.

Modelarea entitate-relaie

65

VESTIMENTATIE_are_ACCESORIU = relaie dintre entitile ACCESORIU i

VESTIMENTATIE (ce accesorii au vestimentaiile). Relaia are cardinalitatea
minim 1:0 i cardinalitatea maxim 1:n.
MODEL_prezint_VESTIMENTATIE = relaie ce leag entitile MODEL i
VESTIMENTATIE (ce vestimentaii au fost purtate de modele). Relaia are
cardinalitatea minim 1:1 i cardinalitatea maxim 1:n.
CREATOR_face_ACCESORIU = relaie ce leag entitile CREATOR i
ACCESORIU (ce creatori au realizat accesoriile). Relaia are cardinalitatea
minim 1:0 i cardinalitatea maxim 1:n.
PREZENTARE_prezinta_VESTIMENTATIE = relaie care leag entitile
PREZENTARE i VESTIMENTATIE (ce vestimentaii au fost prezentate la
evenimentele de mod). Relaia are cardinalitatea minim 1:1 i cardinalitatea
maxim 1:n.
PREZENTARE_are_LOCATIE = relaie ce leag entitile PREZENTARE i
LOCATIE (ce prezentri de mod se desfoar ntr-o locaie). Deoarece ntr-o
locaie pot s fie mai multe prezentri, relaia are cardinalitatea minim 1:1 i
cardinalitatea maxim n:1.
MODEL_lucreaza_AGENTIE = relaie dintre entitile MODEL i AGENTIE
(la ce agenie este angajat un model). Relaia are cardinalitatea minim 1:1 i
cardinalitatea maxim n:1.
MODEL_are_ISTORIC = relaie dintre entitile MODEL i ISTORIC (istoricul
activitii unui model, prin diferite agentii). Relaia are cardinaliatea minim 1:0
i cardinalitatea maxim 1:n.
ISTORIC_refera_AGENTIE = relaie ce leag entitile ISTORIC i AGENTIE
(la ce agenie se refer fiecare nregistrare din istoricul unui model). Relaia are
cardinalitatea minim 1:1 i cardinalitatea maxim 1:n.
SPONSOR_finanteaza_PREZENTARE = relaie de tip many-to-many dintre
entitile SPONSOR i PREZENTARE, reflectnd legtura dintre acestea (ce
sponsori finaneaz prezentrile de mod). Relaia are cardinalitatea minim 0:1
i cardinalitatea maxim m:n.
PERS_CONTACT_are_LOCALIZARE = relaie ce leag entitile
LOCALIZARE i PERS_CONTACT (localizarea unei persoane de contact).
innd cont de restriciile impuse modelului, relaia are cardinalitatea minim
1:1 i cea maxim 1:1. O astfel de relaie este definit i pentru entitile
FIRMA_PUB,
FIRMA_SEC,
PREZENTARE,
ORGANIZATOR,
CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR,
LOCATIE i AGENTIE, care sunt legate de entitatea LOCALIZARE,
permind astfel localizarea tuturor structurilor modelului.
PERS_CONTACT_are_INFO_CONTACT
=
relaie
care
leag
INFO_CONTACT i PERS_CONTACT (modalitatea de accesare a unei
persoane de contact). innd cont de restriciile impuse modelului, relaia are
cardinalitatea minim 1:1 i cea maxim 1:1. O astfel de relaie este definit i

66

PROIECTAREA BAZELOR DE DATE

pentru
entitile
FIRMA_PUB,
FIRMA_SEC,
ORGANIZATOR,
CASA_MODA, SPONSOR, ANGAJAT_TEMP, SOC_ASIG, CREATOR,
LOCATIE i AGENTIE, care sunt legate de entitatea INFO_CONTACT,
permind astfel accesarea tuturor structurilor modelului.
ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA = relaie
de tip 3 ce leag entitile ANGAJAT_TEMP, PREZENTARE i
CASA_MODA, reflectnd cine a fost angajat temporar, de ce cas de mod,
pentru ce prezentare. Denumirea acestei relaii va fi primeste.
Atribut
Atributul este o proprietate descriptiv a unei entiti sau a unei relaii. De
exemplu, numele unei case de mod este un atribut al entitii CASA_MODA,
iar data la care o cas de mod particip la o prezentare este un atribut al relaiei
particip ce leag entitile PREZENTARE i CASA_MODA.
Atributele pot fi simple (de exemplu, suma cu care este pltit un model de
ctre o cas de mod pentru o prezentare), compuse (de exemplu, adresa unei
firme de publicitate), cu valori multiple (de exemplu, numerele de telefon ale
unei persoane de contact), derivate (de exemplu, vrsta unei persoane se obine
din data naterii).
Observaii
Trebuie fcut distincia ntre atribut care uzual devine coloan n
modelele relaionale i valoarea acestuia, care devine valoare n coloane.
Atributele sunt substantive, dar nu orice substantiv este atribut.
Fiecrui atribut trebuie s i se dea o descriere complet n
specificaiile modelului (exemple, contraexemple, caracteristici).
Pentru fiecare atribut trebuie specificat numele, tipul fizic (integer,
float, char etc.), valori posibile, valori implicite, reguli de validare,
constrngeri, tipuri compuse.
n continuare vor fi prezentate, parial, atributele entitilor i relaiilor
dnd o descriere a fiecruia, a caracteristicilor i a constrngerilor pe care
trebuie s le ndeplineasc. Semnificaia unor atribute a cror denumire nu este
semnificativ sau care include mai multe caracteristici dect denumirea va fi
comentat pe parcursul lucrrii.
Entitatea independent ANGAJAT_TEMP are ca atribute:
cod_angajat_temp = variabil de tip ntreg, de lungime maxim 5, care
reprezint codul unui angajat temporar.
nume = variabil de tip caracter, de lungime maxim 25, care reprezint numele
angajatului.
prenume = variabil de tip caracter, de lungime maxim 25, care reprezint
prenumele angajatului.
data_nastere = variabil de tip dat calendaristic, care reprezint data naterii
angajatului respectiv.
sex = variabil de tip caracter, lund valorile m sau f, de lungime 1, care
reprezint sexul angajatului.

Modelarea entitate-relaie

67

nationalitate = variabil de tip caracter, de lungime maxim 12, care reprezint

naionalitatea unui angajat temporar.
cod_localizare = variabil de tip ntreg, de lungime maxim 5, care reprezint
codul localizrii angajatului. Atributul trebuie s corespund la o valoare a cheii
primare din tabelul LOCALIZARE.
cod_info_acces = variabil de tip caracter, de lungime maxim 5, care
reprezint codul informaiei de acces pentru angajatul respectiv. Atributul
trebuie s corespund la o valoare a cheii primare din tabelul
INFO_CONTACT.
tip = variabil de tip caracter, de lungime 10, care reprezint funcia pentru care
a fost angajat persoana respectiv. De exemplu, poate s fie model, stilist sau
eventual poate lua alte valori.
Subentitatea MODEL are ca atribute:
cod_angajat_temp = variabil de tip ntreg, de lungime maxim 5, care
reprezint codul modelului.
cod_agentie = variabil de tip ntreg, de lungime maxim 5, care reprezint
codul ageniei la care este angajat n prezent modelul. Atributul trebuie s
corespund la o valoare a cheii primare din tabelul AGENTIE.
inaltime = variabil de tip numeric, de lungime 3, care reprezint nlimea
modelului n centimetri.
nr_pantof = variabil de tip numeric (real), care reprezint numrul pe care l
poart la pantof modelul respectiv.
info = variabil de tip text, care include informaii speciale despre model
(dimensiuni, greutate, preferine, elemente confideniale, palmares etc.).
Entitatea PUBLICITATE are atributele: cod_publicitate, cod_firma_pub,
cod_prezentare, tip, nume, suma, observatii. Atributul tip poate lua valorile
radio, televiziune, presa, panouri publicitare etc. Atributul nume este legat de
atributul tip n sensul c poate reprezenta numele postului de radio, al celui de
televiziune, al publicaiei care face publicitatea.
Entitatea FIRMA_PUB are atributele: cod_firma_pub, nume, info, director,
observatii, nume_pers_contact, cod_localizare, cod_info_acces.
Entitatea ORGANIZATOR are atributele: cod_organizator, denumire, banca,
cont, informatii, cod_localizare, cod_info_acces.
Entitatea PERS_CONTACT are atributele: cod_pers_contact, cod_organizator,
nume, prenume, directie, cod_localizare, cod_info_acces.
Entitatea PREZENTARE are atributele: cod_prezentare, denumire, data_start,
data_final, cod_organizator, cod_soc_asig, cod_locatie.
Entitatea SPONSOR are atributele: cod_sponsor, tip, nume, info, cod_localizare,
cod_info_acces. Atributul tip poate lua valorile persoana fizic sau persoana
juridic. n primul caz, atributul nume va reprezenta numele i prenumele
persoanei fizice, iar n cel de al doilea caz, va reprezenta numele societii.

68

PROIECTAREA BAZELOR DE DATE

Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri,

proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces.
Entitatea CREATOR are atributele: cod_creator, nume, prenume, data_nastere,
data_angajare, cod_casa_moda, tip, mod_angajare, info, cod_localizare,
cod_info_acces. Atributul tip poate lua valorile designer, croitor, broder,
creator_accesorii. Atributul mod_angajare poate lua valorile permanent sau
special.
Entitatea VESTIMENTATIE are atributele: cod_vestimentatie, denumire,
valoare, descriere, cod_creator, cod_model, cod_prezentare.
Entitatea ACCESORIU are atributele: cod_vestimentatie, cod_accesoriu, tip,
descriere, valoare, cod creator.
Entitatea AGENTIE are atributele: cod_agentie, nume, data_creare, director,
cifra_afaceri, info, cod_localizare, cod_info_acces.
Entitatea ISTORIC are atributele: cod_model, data_angajare, data_final,
cod_agentie, conditii.
Entitatea LOCALIZARE are atributele: cod_localizare, adresa, cod_postal, oras,
tara.
Entitatea LOCATIE are atributele: cod_locatie, denumire, tip, capacitate,
cod_localizare, cod_info_acces. Atributul tip reprezint tipul locaiei respective
i poate lua valorile: hotel, esplanad, teatru, mall etc.
Entitatea INFO_CONTACT are atributele: cod_info_contact, telefon_mobil,
mail, telefon_fix, fax.
Entitatea FIRMA_SEC are atributele: cod_firma_sec, nume_firma, tip_servicii,
director, observatii, cod_localizare, cod_info_acces.
Entitatea ANGAJAT_SEC are atributele cod_angajat, nume, prenume,
data_nastere, specializare, nivel, observatii, cod_localizare, cod_firma_sec,
cod_info_acces.
Entitatea SOC_ASIG are atributele: cod_soc_asig, conditii, suma, director,
observatii, nume_pers_contact_firma, cod_localizare, cod_info_acces.
Relaia CASA_MODA_participa_PREZENTARE are ca atribute:
cod_prezentare = variabil de tip ntreg, de lungime maxim 5, care reprezint
codul prezentrii. Atributul trebuie s corespund la o valoare a cheii primare
din tabelul PREZENTARE.
cod_casa_moda = variabil de tip ntreg, de lungime maxim 5, care reprezint
codul casei de mod. Atributul trebuie s corespund la o valoare a cheii
primare din tabelul CASA_MODA.
tip = variabil de tip caracter, de lungime maxim 15, care reprezint
modalitatea n care o cas de mod particip la o prezentare, n sensul c poate
fi organizator sau neorganizator.

69

Modelarea entitate-relaie

data = variabil de tip dat calendaristic reprezentnd ziua n care defileaz

modelele casei de mod. Atributul nu este multiplu, deoarece s-a presupus c
defilarea unei case de mod are loc ntr-o singur zi.
Relaia SPONSOR_finanteaza_PREZENTARE are ca atribute: cod_sponsor,
cod_prezentare, data_emitere, suma, banca, cont_emitent, cod_ordin_plata.
Relaia ANGAJAT_SEC_paza_PREZENTARE are atributele: cod_angajat,
cod_prezentare, tip_paza, dotare, observaii.
Relaia ANGAJAT_TEMP_primeste_la_PREZENTARE_de_la_CASA_MODA
are ca atribute: cod_angajat_temp, cod_casa_moda, cod_prezentare suma,
data_achitare, cont, banca.
Nu s-au introdus atributele cont i banca la entitatea ANGAJAT_TEMP,
deoarece modelul de date nu-i propune s furnizeze informaii complete
referitoare la toate conturile i bncile modelelor, stilitilor etc. Se consider
doar banca i contul n care casa de mod depune bani pentru prezentarea la
care acetia au fost angajai.
2.3. Diagrama entitate- relaie
Pentru proiectarea diagramei entitate-relaie au fost stabilite anumite
reguli (care nu sunt unice):
entitile sunt reprezentate prin dreptunghiuri;
relaiile dintre entiti sunt reprezentate prin arce neorientate;
atributele care reprezint chei primare trebuie subliniate sau marcate
prin simbolul #, plasat la sfritul numelui acestor atribute;
cardinalitatea minim este indicat n paranteze, iar cardinalitatea
maxim se scrie fr paranteze;
nu este necesar s fie specificate, n cadrul diagramei, toate atributele.
Vom comenta cteva cazuri speciale de entiti, relaii, atribute i modul
lor de reprezentare n cadrul diagramei entitate-relaie.
Dependena. Exist entiti, numite entiti dependente care nu pot
exista n mod independent. De exemplu, se observ c entitatea
ACCESORIU depinde de VESTIMENTATIE, iar LOCATIE depinde
de entitatea PREZENTARE. Cheia primar a unei entiti dependente
include cheia primar a sursei (cod_vestimentatie) i cel puin o
descriere a entitii (cod_accesoriu). Entitatea dependent se deseneaz prin dreptunghiuri cu linii mai subiri.
Motenirea atributelor. O subentitate (subclas) este o submulime
a unei alte entiti, numit superentitate (superclas). De exemplu,
ANGAJAT_TEMP este o superentitate pentru MODEL, iar MODEL
este o subentitate pentru ANGAJAT_TEMP. Subentitatea se
deseneaz prin dreptunghiuri incluse n superentitate. Exist o relaie

70

PROIECTAREA BAZELOR DE DATE

ntre o subentitate i o superentitate, numit ISA, care are

cardinalitatea maxim 1:1 i minim 1:0.
Cheile primare, atributele i relaiile unei superentiti sunt valabile
pentru orice subentitate. Afirmaia reciproc este fals. De exemplu,
un informatician, considerat ca subentitate a entitii
PERS_CONTACT, poate avea ca atribute limbajele de programare
cunoscute i nivelul de cunoatere a acestora, dar aceste atribute nu
sunt semnificative pentru o persoan de contact care coordoneaz
asigurarea securitii prezentrii de mod. Cheia primar a subentitii
INFORMATICIAN este cod_pers_contact, care este cheia primar a
superentitii PERS_CONTACT.
Specializare. Dup valorile unor atribute clasificatoare se pot
determina clase. Un grup de subentiti reciproc exclusive definete o
clas. Clasele se aliniaz n desen vertical. De exemplu, pentru
entitatea PUBLICITATE, dup valorile atributului tip, pot fi definite
subentitile PANOURI_PUBLICITARE, PRESA, TELEVIZIUNE,
RADIO, fiecare avnd atributele sale proprii.
Generalizare. Din entiti similare care au mai multe atribute comune
se pot crea superentiti. Aceste superentiti conin atributele comune,
iar atributele speciale sunt asignate la subentiti. Pentru noile
superentiti se introduc chei primare artificiale. De exemplu, din
entitile FIRMA_PUB, FIRMA_SEC i SOC_ASIG se poate crea
superentitatea FIRMA avnd drept atribute: cod_firma (cheie primar
artificial), informaii de accesare, informaii de localizare, director,
observatii.
ntr-o diagram E/R se pot defini relaii recursive. De exemplu, poate
fi definit relaia PERS_CONTACT_supervizeaza_PERS_CONTACT.
Unele relaii sunt relative la dou entiti i le numim de tip 2, iar dac
relaiile implic mai mult de dou entiti, le vom numi de tip 3. Trei
relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie de tip
3 n trei relaii de tip 2, poate s apar informaie incorect.
Trebuie excluse din model relaiile indirecte pentru c ele pot conduce
la redundan n baza de date.
Atributele derivabile trebuie eliminate i introduse expresii prin care
aceste atribute pot fi calculate.
Uneori apare o incertitudine referitoare la faptul c o anumit
informaie poate fi considerat o relaie sau un atribut. O relaie poate
fi reprezentat ca un atribut, sau putem folosi relaii n loc de atribute.
Dac un atribut al unei entiti reprezint cheia primar a unei alte
entiti, atunci el refer o relaie.
Uneori este greu de stabilit dac informaia analizat reprezint o
entitate sau o relaie. Dac exist o incertitudine, se cerceteaz cheia
primar. Dac aceast cheie combin cheile primare a dou entiti,
atunci se definete o relaie. Cheia primar a relaiei organizeaza

Modelarea entitate-relaie

71

combin atributele cod_organizator i cod_prezentare, care reprezint

cheile primare ale entitilor ORGANIZATOR i PREZENTARE.
Prin urmare, ORGANIZATOR_organizeaza_PREZENTARE va defini
o relaie i nu o entitate.
Un atribut indirect este inoportun. El nu descrie real relaia sau
entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt,
un atribut indirect este un caz special de relaie indirect care trebuie
eliminat pentru c introduce redundan n date.
Exist atribute opionale, a cror valoare este uneori necunoscut,
alteori neaplicabil. Aceste atribute trebuie introduse la subentiti.
Algoritmul pentru proiectarea diagramei E/R cuprinde urmtoarele etape:
1. identificarea entitilor din cadrul sistemului analizat;
2. identificarea relaiilor (asocierilor) dintre entiti i stabilirea cardinalitii;
3. identificarea atributelor aferente entitilor i asocierilor dintre
entiti;
4. stabilirea atributelor de identificare a entitilor, adic stabilirea
cheilor.
Relaiile reflect legturi naturale care exist ntre componentele
sistemului. Aceeai realitate poate fi ns perceput diferit de ctre diveri
analiti pentru un acelai sistem, putnd fi obinute modele structurale distincte.
O diagram E/R pentru modelul comentat n aceast seciune este reprezentat
n figura 2.1. Diagrama este corect, dar este optimizabil.
Construirea diagramei conceptuale, obinerea schemelor relaionale i
normalizarea acestora vor genera un model relaional care va elimina anumite
clase de anomalii ce pot s apar n proiectarea modelului de date.
Deficiene ale modelului E/R
n proiectarea unui model de date pot aprea diverse probleme datorit
unei interpretri eronate a sensului unei relaii. Aceste probleme sunt denumite
capcane de conectare.
Unele dintre aceste capcane pot s nu fie semnificative pentru modelul
particular considerat, n timp ce altele cer restructurarea modelului. Exist dou
clase importante de capcane: de ntrerupere i n evantai.
O capcan de ntrerupere poate s apar acolo unde modelul sugereaz
existena unei relaii ntre entiti, dar nu exist o cale ntre anumite apariii ale
entitilor. Aceast capcan poate s apar acolo unde exist o relaie cu
participare parial (0 la cardinalitatea minim), care face parte din calea dintre
entitile ce sunt legate.
O capcan n evantai poate s apar acolo unde modelul ia n considerare
o relaie ntre entiti, dar calea dintre anumite apariii ale entitilor este
ambigu. Aceste capcane apar cnd dou sau mai multe relaii one_to_many
provin din aceeai entitate.

72

PROIECTAREA BAZELOR DE DATE

INFO_CONTACT
1
are
1
are M(1)
PERS_CONTACT
ORGANIZATOR 1
1
M(1)
are
1
organizeaza
LOCALIZARE

FIRMA_PUB
1
face
M(1)
M(1)
PUBLICITATE

FIRMA SEC
1

LOCATIE
1
are
are
M(1)
M(1)
M(1)
M(1) paza M(1) 1
M(1) finanteaza M(0)
ANGAJAT SEC
PREZENTARE
SPONSOR
M(1) 1
M(1)
SOC ASIG

se_face

asigura

participa

M(1)
CASA_MODA
prezinta
1

primeste

lucreaza
M(1)
1 CREATOR
1

ANGAJAT_TEMP
MODEL 1(0) ISA
M(1)
1
1

creeaza prezinta
face

M(1) M(0)
VESTIMENTATIE
1
are
M(0)
M(0)
ACCESORIU

lucreaza_la
M(1) are

1
AGENTIE
1

M(0)
ISTORIC M(1)

refera

Fig. 2.1. Diagrama E/R.

Practic, aceste capcane genereaz situaiile n care, aa cum a fost
proiectat modelul de date, el nu poate s rspund la anumite interogri. De
exemplu, pentru a afla pentru ce prezentare de mod a fost creat o anumit
vestimentaie, a fost necesar introducerea unei legturi ntre entitile
PREZENTARE i VESTIMENTATIE, care ns a generat redundan n
modelul de date.
Modelul E/R extins
Conceptele de baz ale modelrii entitate-relaie nu sunt suficiente pentru
a reprezenta cerinele aplicaiilor actuale, care sunt mult mai complexe. Au fost
propuse, n acest sens, mai multe modele de date semantice. Modelul E/R
susinut cu concepte semantice adiionale definete modelul E/R extins (EER).

Modelarea entitate-relaie

73

Acesta include toate conceptele modelului original, mpreun cu conceptele

adiionale de specializare, generalizare i categorie. Aceste noi concepte au fost
deja nominalizate n acest capitol.
Superclasa (superentitatea) este o entitate care include subclase
(subentiti) distincte, ce trebuie reprezentate n modelul de date. Subclasa are
un rol distinct i, evident, este membr a unei superclase. O subclas, fiind o
entitate, poate s posede propriile subclase. O entitate mpreun cu subclasele
ei, subclasele acestora i aa mai departe definete o ierarhie de tip (ierarhie de
specializare). De exemplu, ANGAJAT_TEMP reprezint o superclas pentru
entitatea MODEL.
Specializarea este procesul de maximizare a diferenelor dintre membrii
unei entiti, prin identificarea caracteristicilor distinctive ale acestora.
Specializarea constituie o abordare de sus n jos n definirea unei mulimi de
superclase i a subclaselor lor. Pot exista diverse specializri ale aceleiai
entiti, bazate pe diferite caracteristici de difereniere.
Dac subclasele unei specializri sunt disjuncte, atunci o entitate poate fi
membr doar a unei subclase a acesteia (constrngere de disjuncie).
O specializare cu participare total specific faptul c fiecare entitate din
superclas trebuie s fie membr a unei subclase din specializare (constrngere
de participare).
De exemplu, specializarea contractelor de angajare poate fi cu participare
total dac fiecare angajat din PERS_CONTACT este fie angajat cu contract
permanent cu norm ntreag, fie cu contract temporar cu norm incomplet.
O specializare cu participare parial specific faptul c nu este necesar ca
o entitate s aparin vreunei subclase a acesteia. De exemplu, exist salariai n
PERS_CONTACT care nu aparin niciunei subentiti ale acesteia.
Generalizarea este procesul de minimizare a diferenelor dintre entiti,
prin identificarea caracteristicilor comune ale acestora. Generalizarea reprezint
o abordare de jos n sus, care are ca rezultat identificarea unei superclase
generalizate din subclasele iniiale.
Orice relaie superclas/subclas (inclusiv cele ale unei subclase
partajate) dintr-o ierarhie de specializare/generalizare are o singur superclas.
Totui, anumite situaii necesit modelarea unei relaii superclas/subclas cu
mai mult dect o superclas distinct. n acest caz, subclasa definete o
categorie. Categoria este procesul de modelare a unei singure subclase, cu o
relaie care implic mai mult dect o singur superclas distinct.

2.4. Modelare orientat pe obiecte cu UML

Un limbaj de modelare reprezint o modalitate de a comunica despre un
sistem i de a exprima diversele modele produse n cadrul procesului de analiz
i dezvoltare a sistemului. Limbajul furnizeaz o notaie care permite
reprezentarea unui design.

74

PROIECTAREA BAZELOR DE DATE

Limbajul este format dintr-un set de concepte, principii i reguli de

utilizare a acestora, cu scopul de a reprezenta modelele produse n diferite etape
de dezvoltare a sistemului. Fr un limbaj de modelare, este dificil colaborarea
i comunicarea dintre membrii echipei pe parcursul proiectrii sistemului.
Ca orice limbaj, un limbaj de modelare are o sintax i o semantic, iar
pentru semantica modelului trebuie aleas sintaxa cea mai expresiv. De cele
mai multe ori, un limbaj de modelare este un limbaj grafic (diagramatic).
Dac pentru utilizatori, limbajele de modelare uureaz munca de
realizare a sistemelor software, pentru realizatorii acestora sarcinile sunt
multiple i dificile. Pentru ca un limbaj de modelare s se impun, el trebuie s
asigure o bun specificare a conceptelor sale i a modului de reprezentare a
acestora. n acest scop, limbajele trebuie s asigure suport pentru modelatori, n
vederea rafinrii treptate a soluiei i a captrii semanticii procesului.
The Unified Modeling Language (UML) este, aa cum semnific i
numele, un limbaj vizual de modelare i de comunicare despre sistem. UML nu
este un limbaj de programare, deoarece nu dispune de ntreg sprijinul semantic
i vizual pentru a defini un astfel de limbaj. nlocui limbajele de programare.
UML este un limbaj pentru modelarea orientat pe obiecte, cu suport pentru
modelare vizual, funcionnd ca o modalitate de a comunica i de a exprima
cunotine.
UML este un limbaj grafic de modelare pentru specificarea, vizualizarea,
construcia i documentarea componentelor unui sistem software (pentru
ntreprinderi, telecomunicaii, sisteme bancare i financiare, transporturi etc.)
sau pentru modelarea organizaional a unor sisteme non-software (din justiie,
medicin, afaceri etc.).
UML nu este un limbaj de programare, dar modelele exprimate n UML
pot fi implementate uor n limbaje de programare orientate pe obiecte (C++,
Java, C#) sau n baze de date relaionale. Este posibil nu numai generarea
codului dintr-un model UML, dar i ingineria invers, constnd n construirea
dintr-un cod dat a unui model UML.
UML este un limbaj de modelare pentru documentare, deoarece permite
realizarea tuturor documentelor necesare nelegerii modelului i diagramelor
utilizate pe tot parcursul ciclului de via al unui proces de realizare a unui
sistem. Documentele componentelor sistemului conin specificarea cerinelor,
arhitecturii i proiectrii sistemului; elaborarea codului surs, planuri de
dezvoltare i de management al proiectului.
n concluzie, UML nu este un limbaj de programare vizual, dar este un
model de limbaj de modelare vizual; nu este o metodologie, dar este o notaie
pentru aceasta; nu este un proces, dar ofer suport complet pentru construcia i
dezvoltarea acestuia.
Este important de menionat c UML este un limbaj de modelare, i nu o
metod. Majoritatea metodelor conin att un limbaj de modelare, ct i un
proces. Limbajul de modelare furnizeaz, dup cum am mai subliniat, doar
notaia pentru reprezentarea unui design. Procesul cuprinde, ns, paii care
trebuie s fie urmai pentru a realiza un design.

Modelarea entitate-relaie

75

UML cuprinde tehnici specifice mai multor metode de dezvoltare

(proiectare) i este suficient de logic, de expresiv pentru a putea fi utilizat
mpreun cu orice metod sau proces de dezvoltare.
Ca orice limbaj, UML are sintaxa i semantica sa. Cu ajutorul alfabetului
i al cuvintelor limbajului, se pot scrie propoziii (fragmente din diagrame)
despre subiectul de analizat. Propoziiile se pot grupa n paragrafe (diagrame
UML).
Paragrafele, la rndul lor, se pot grupa n seciuni (moduri de vizualizare)
i, n final, seciunile se pot organiza n documente. Documentele UML sunt
modelele sistemului.
Sintaxa limbajului UML implic diagrame, n timp ce semantica lui se
bazeaz pe paradigma orientrii pe obiecte. Din punct de vedere al modelrii
orientate pe obiecte, entitile (conceptele) se numesc clase, iar relaiile dintre
ele se numesc asocieri.
Diagrama este o reprezentare grafic a unei mulimi de elemente, de
obicei folosindu-se forme geometrice pentru a reprezenta entiti i linii pentru a
reprezenta asocieri. n UML, diagrama este o proiecie a sistemului,
reprezentnd o parte a sistemului sau chiar ntregul sistem dintr-un anumit punct
de vedere. Acelai element poate aprea n toate diagramele, n cteva diagrame
sau n nicio diagram.
UML conine 9 tipuri de diagrame, fiecare reflectnd una sau mai multe
dintre cele 5 tipuri de vizualizri posibile asupra unui sistem software.
Diagrama claselor descrie structura unui sistem n general. n
componena ei intr clase, stereotipuri i relaiile dintre acestea.
Diagrama obiectelor descrie structura unui sistem la un anumit
moment. Acest tip de diagram este o variant a diagramei claselor
care, n locul unei clase, prezint mai multe instane ale ei, fiind
format din obiecte i legturi dintre ele.
Diagrama cazurilor de utilizare descrie funcionalitatea unui sistem,
prezentnd actorii externi, cazurile de utilizare identificate numai din
punct de vedere al actorilor (comportamentul sistemului, aa cum este
perceput de utilizatorii lui), precum i relaiile dintre actori i cazurile
de utilizare. Un actor poate fi orice sau oricine interacioneaz cu
sistemul (trimite sau recepioneaz mesaje de la sistem sau schimb
informaii cu acesta). Actorul are un rol n cadrul unui sistem, nu este
un utilizator individual al acestuia i, din acest motiv, el este o entitate
(o clas), nu o instan. Un caz de utilizare este iniiat mereu de un
actor i furnizeaz o valoare actorului.
Diagrama componentelor (diagrama de implementare) descrie
structura fizic a codului n termenii componentelor de cod i relaiilor
dintre acestea.
Diagrama de desfurare (de exploatare) indic arhitectura fizic pe
care este implementat sistemul, calculatoarele, nodurile sistemului i
conexiunile dintre ele.

76

PROIECTAREA BAZELOR DE DATE

Diagrama secvenelor este o diagram de interaciune, care prezint

colaborarea dinamic dintre un numr de obiecte, punnd accentul pe
secvenele de mesaje trimise ntre acestea pe msura scurgerii
timpului.
Diagrama de colaborare este tot o diagram de interaciune, dar care,
pe lng interaciunea dintre obiecte (schimbul de mesaje), prezint
obiectele i legturile dintre ele.
Diagrama de stare descrie ciclul de via al unui element (al
obiectelor, subsistemelor i sistemelor), prin specificarea strilor n
care se gsete elementul i a evenimentelor care i modific starea.
Diagrama de activitate prezint activitile i responsabilitile
elementelor sistemului, fiind utilizat pentru modelarea funciilor
sistemului. Ea are ca elemente constitutive stri de aciune i mesaje
care vor fi trimise sau recepionate ca parte a aciunii realizate.
n UML, diagramele fac parte din dou categorii.
Diagrame dinamice sau comportamentale descriu comportamentul
i interaciunile dintre diverse entiti ale sistemului informatic. Din
aceast categorie, fac parte diagramele de secven, colaborare, stare i
activitate.
Diagrame statice sau structurale - descriu structura, responsabilitile
sistemului informatic, componentele executabile ale sistemului,
locaiile fizice de execuie i nodurile de stocare a datelor. Din aceast
categorie, fac parte diagramele claselor, obiectelor, cazurilor de
utilizare, componentelor i diagramele de exploatare.
Pe lng structura static i comportamentul dinamic, pentru
caracterizarea complet a unui sistem este necesar i funcionalitatea acestuia,
care poate fi analizat folosind diagramele cazurilor de utilizare.
Din punct de vedere al modelrii sistemelor orientate pe obiecte din
perspectiva UML, aspectele statice sunt: clasele i relaiile dintre clase,
interfeele, topologia hardware necesar execuiei aplicaiei.
Seciunile UML sau modurile de vizualizare sunt grupuri de diagrame
care se adreseaz unei anumite mulimi de entiti. Toate diagramele UML pot
fi organizate n vizualizri. Fiecare vizualizare este descris folosind un numr
de diagrame ce conin informaii referitoare la un anumit aspect particular al
sistemului.
Exist 5 tipuri importante de vizualizri asupra unui sistem software.
Modul de vizualizare structural (logic) al arhitecturii unui sistem
se refer la cerinele funcionale ale acestuia, adic prezint serviciile
furnizate de sistem utilizatorilor si. Vizualizarea logic trateaz din
interior sistemul i descrie att structura intern a acestuia, format din
clase, obiecte i relaii, ct i colaborrile, legturile care apar n urma
schimbului de mesaje ntre obiecte, pentru a realiza funcionalitatea
dorit. Notaia UML este dedicat, n mare parte, reprezentrii

Modelarea entitate-relaie

77

arhitecturii logice (clase, asocieri, obiecte, legturi, generalizri,

polimorfism, pachete etc.)
Modul de vizualizare a componentelor sistemului (implementare)
se concentreaz pe descrierea componentelor care implementeaz
sistemul, dependenele care exist ntre ele, resursele alocate acestora,
precum i rezolvarea unor probleme legate de reutilizarea,
portabilitatea codului i informaii administrative.
Modul de vizualizare a cazurilor de utilizare surprinde
funcionalitatea sistemului, aa cum este ea perceput de actorii
externi care interacioneaz cu sistemul, precum i de utilizatorii
acestuia, de diferii membri ai echipei realizatoare sau de ctre alte
sisteme. n componena acestui mod intr diagramele cazurilor de
utilizare pentru descrierea static a aspectului funcional i ocazional.
Se pot folosi i diagrame de activitate pentru a ncapsula latura
dinamic a funcionalitii.
Modul de vizualizare comportamental este util pentru gestionarea
eficient a resurselor, pentru execuii paralele i tratri asincrone ale
unor evenimente din sistem, precum i pentru rezolvarea unor
probleme legate de comunicare i sincronizare.
Modul de vizualizare a desfurrii (mediu) se refer la
desfurarea fizic a sistemului, indicnd ce calculatoare i ce tipuri de
noduri vor fi folosite pentru implementarea sistemului, cum sunt
acestea conectate, precum i ce procese se vor executa n fiecare nod.

UML ofer, pe lng elementele de baz, i unele faciliti care permit

organizarea i extinderea diagramelor. Aceste faciliti pot fi simple notaii sau
pot fi elemente de extindere a limbajului UML. Dintre facilitile cele mai
importante se remarc pachetele, notele, stereotipurile i proprietile.
Pachetul reprezint un mecanism de grupare a elementelor de
modelare. n UML, un pachet definete un mecanism de organizare a
elementelor n grupuri legate semantic.
Nota cuprinde ipotezele i deciziile aplicate n timpul analizei i al
proiectrii. Notele sunt corespondentul comentariilor din limbajele de
programare.
Stereotipul este un concept introdus n UML, care permite extinderea
elementelor de baz pentru a crea noi elemente. Un stereotip
reprezint un neles specific asociat unui element.
Proprietatea este un element de extindere UML, care lrgete
proprietile i semantica unui element UML.
Modelarea unui sistem privete modelarea aspectelor sale funcionale,
statice i dinamice. Pentru ca un sistem s aib succes, n primul rnd trebuie ca
cerinele sistemului s fie exprimate ntr-o manier care s permit o uoar
nelegere, indiferent de nivelul de pregtire informatic a celor implicai n

78

PROIECTAREA BAZELOR DE DATE

proiect, iar n al doilea rnd trebuie ca membrii echipei de dezvoltare s poat

asimila cu uurin modificrile care apar pe parcurs n cerine.
Aceste condiii sunt rezolvate n diagrama cazurilor de utilizare, care are
rolul de a reprezenta n form grafic funcionalitile pe care trebuie s le
ndeplineasc sistemul n faza sa final. Pentru crearea modelului cazurilor de
utilizare, trebuie identificai actorii, cazurile de utilizare, relaiile dintre actori i
relaiile dintre cazurile de utilizare. Realizarea acestor faze presupune discuii
ntre utilizatori i analitii de sistem.
Cazul de utilizare poate fi privit ca un instrument de stimulare a
posibililor utilizatori n exprimarea propriilor puncte de vedere. Adeseori,
utilizatorii tiu mai multe dect pot s explice i nu le este uor s se pronune
clar cum vor folosi sistemul. Cazurile de utilizare ajut la ndeprtarea acestui
impediment.
Discuiile iniiale trebuie s duc la descoperirea actorilor i a cazurilor
de utilizare care descriu cerinele funcionale n termeni generali i care pot
stabili frontierele domeniului studiat. Urmtoarele discuii au ca scop
nelegerea, n detaliu, a domeniului studiat, ceea ce duce la evitarea introducerii
unor cazuri de utilizare, care ar ngreuna procesul de analiz.
Un caz de utilizare este o descriere a unei funcionaliti pe care o ofer
sistemul, o colecie de scenarii referitoare la utilizarea unui sistem. Un scenariu
descrie o succesiune de evenimente introduse de un actor, care poate fi o
persoan, un dispozitiv hardware sau chiar trecerea timpului. Deci, actorii sunt
entitile care iniiaz o secven de evenimente (un scenariu). Rezultatul
secvenei de evenimente trebuie s fie concretizat n ceva utilizabil de ctre
actorul ce a iniiat secvena sau de ctre alt actor.
Diagrama cazurilor de utilizare are ca elemente de modelare actorii,
cazurile de utilizare, relaiile dintre cazurile de utilizare.
Detaliile despre fiecare caz de utilizare pot fi date n documente text sau
pot fi folosite tehnici noi, de modelare dinamic, de exemplu diagramele de
activitate sau diagramele de interaciune, pentru a specifica secvenele de pai
ale cazului de utilizare.
Construirea unei diagrame a cazurilor de utilizare are drept obiective:
s capteze i s descrie cerinele funcionale ale sistemului, cerine
rezultate n urma discuiilor purtate de clieni i/sau utilizatori ai
sistemului cu dezvoltatorii acestuia;
s ofere o descriere clar i consistent a ceea ce va trebui s fac
sistemul, adic folosirea modelului pentru comunicarea cerinelor
tuturor persoanelor implicate n construirea sistemului, i s constituie
un punct de plecare pentru alte activiti (design, testare i
implementare);
s constituie o baz pentru realizarea textelor de verificare, ce decid
dac funcionalitatea final concord cu cerinele iniiale ale
sistemului;

Modelarea entitate-relaie

79

s permit transformarea cerinelor funcionale n viitoare clase i

operaii.
Diagramele UML pot fi desenate i administrate utiliznd un utilitar
CASE (Computer Edit Software Engineering). Aceste utilitare sunt deosebit de
utile n cazul unor diagrame complexe. Totui, dac diagrama este prea
complicat, atunci este necesar partiionarea ei n mai multe diagrame sau
reprezentarea la un nivel superior de abstractizare.
Exemple de utilitare CASE care permit realizarea diagramelor UML sunt
reprezentate de: Microsoft Office Visio, IBM Rational Rose Professional Data
Modeler, Altova UModel, Borland Together, Visual Paradigm for UML,
ArgoUML etc.
Interesul pentru suportul modelrii bazelor de date cu ajutorul UML a
condus la crearea unor profile specifice. Un profil constituie o propunere a unei
comuniti i regrupeaz o mulime de elemente UML care se aplic unui
context particular i care conserv metamodelul UML. IBM Rational Rose
include un astfel de profil adaptat bazelor de date.
Exist o diferen ntre un model (de exemplu, modelul conceptual de
date) i un formalism (n care este descris un model). Astfel, putem vorbi despre
modelarea conceptual a datelor urmnd formalismul entitate-relaie sau
formalismul UML. Notaia exprim doar aspectul referitor la reprezentare.
Pe lng formalismul entitate-relaie, considerat standardul de facto
pentru modelarea datelor, o opiune alternativ este oferit de ctre UML.
Acesta include primitive pentru modelarea datelor, iniial concepute pentru
reprezentarea structurii claselor unei aplicaii orientate obiect, dar care pot fi
folosite pentru specificarea modelului de date al domeniului unei aplicaii. n
particular, diagramele de clase UML pot fi utilizate ca alternativ la diagramele
entitate-relaie.
Diferena major dintre o diagram de clase UML i o diagram entitaterelaie este reprezentat de diferena dintre o clas i o entitate: o clas este o
generalizare a noiunii de entitate, care permite proiectantului s specifice nu
numai atribute, ci i funcii (numite metode) aplicabile instanelor clasei. Astfel,
aceast diferen face ca UML s fie mai general dect modelul entitate-relaie,
iar proiectantul poate exploata diagramele de clase UML pentru a realiza
aceeai specificaie pe care o poate obine cu ajutorul modelului entitate-relaie.

80

PROIECTAREA BAZELOR DE DATE

Fig. 2.2. Diagrama de clase corespunztoare unei restricii a modelului.

Diagramele de clase UML au mai multe caracteristici dect diagramele
entitate-relaie, cum ar fi posibilitatea de a specifica reguli de derivare pentru
atribute i relaii utiliznd limbajul OCL (Object Constraint Language).
Pentru exemplificarea utilizrii formalismului UML, vom considera o
restricie a modelului utilizat pe parcursul acestei lucrri i vom construi
diagrama de clase corespunztoare. Construcia diagramei a fost realizat cu
ajutorul programului Microsoft Visio i este prezentat n figura 2.2 . Din
motive de spaiu, a fost redus numrul de atribute precizate pentru fiecare clas
din cadrul diagramei.

81

Modelarea entitate-relaie

Prezentm cteva observaii referitoare la construcia acestui model

utiliznd o diagram de clase UML. Unele observaii au caracter general,
amintind anumite noiuni UML necesare nelegerii construciei modelului.
Tabelul urmtor stabilete echivalenele dintre formalismele
modelului entitate-relaie i al notaiei UML:
Entitate-relaie
Tip entitate

Clas

Asociere (relaie)

Asociere (relaie)

Entitate

Obiect

Cardinalitate

Multiplicitate

Model
date

conceptual

UML

de Diagram de clase

Descrierea claselor n UML se divide n trei compartimente care

conin respectiv numele clasei, atributele acesteia i signatura
metodelor clasei. n cazul reprezentrii unui model relaional de date
nu exist metode, deci al treilea compartiment este vid.
Cardinalitile din modelul entitate-relaie propus de Chen i
multiplicitile din formalismul UML sunt poziionate identic pe axa
de reprezentare a relaiei.
Asocierile dispun de anumite caracteristici, dintre care se remarc:
nume, roluri, clase de asociere.
Numele unei asocieri este dat de o form verbal activ sau pasiv.
Acest nume este plasat n mijlocul liniei reprezentnd relaia
respectiv. De exemplu, asocierea organizeaza dintre clasele
Organizator i Prezentare este reprezentat n diagrama de clase prin
acest nume plasat pe linia care conecteaz cele dou clase.
Numele asocierii poate fi nsoit de un triunghi ndreptat ctre clasa
desemnat de forma verbal, cu scopul de a indica sensul de citire a
relaiei. De exemplu, n cazul asocierii creeaza se precizeaz c relaia
se citete dinspre clasa Creator ctre clasa Vestimentatie.
Extremitatea unei asocieri poate indica un rol. Acesta descrie modul n
care clasele sunt percepute prin intermediul relaiei respective. Un rol
este n general desemnat printr-o form nominal sau verbal. De
exemplu, asocierea lucreaza dintre clasele Casa_moda i Creator este
reprezentat att prin nume, ct i prin rolurile angajat i firma.
n UML, asocierile one to one (1:1) au multiplicitatea 0..1 sau 1 la
fiecare extremitate; asocierile one to many (1:N) au multiplicitatea *
sau 1..* la o extremitate i 0..1 sau 1 la cealalt extremitate; asocierile
many to many (N:N) au multiplicitatea * sau 1..* la fiecare
extremitate.

82

PROIECTAREA BAZELOR DE DATE

O asociere many to many cu atribute este reprezentat n UML printr-o

clas de asociere. Aceasta conine atributele asocierii i este conectat
printr-o linie punctat la linia reprezentnd relaia. De exemplu,
asocierii dintre clasele Sponsor i Prezentare i este ataat clasa de
asociere Finanteaza.
ntre clasele Angajat_temp i Model exist o asociere de generalizare,
corespunztoare relaiei ISA (is a). Generalizarea este reprezentat
printr-o sgeat, al crei vrf este un triunghi gol, dinspre subclas
ctre superclas.
ntre clasele Vestimentatie i Accesoriu exist o relaie de agregare
compus. Agregarea reprezint n UML o asociere care nu este
simetric i pentru care o extremitate are un rol predominant fa de
cealalt. Aceast asociere privete un singur rol al su. Agregarea
aparine mai degrab etapei de concepie detaliat dect celei de
modelare. Astfel, ea se va traduce la nivelul codului SQL prin
declanatori sau constrngeri.
Exist dou forme de agregare: compus i partajat. Compunerea
exprim o relaie de apartenen mai puternic, aprnd atunci cnd
relaia este de tipul compune sau face parte din. Reprezentarea
compunerii se face prin intermediul unui romb plin, poziionat lng
clasa care reprezint ntregul. Multiplicitatea extremitii agregat nu
poate depi 1.
Agregarea partajat presupune c un obiect poate face parte din mai
multe agregate, iar ntregul se poate modifica n timp.O astfel de
relaie se reprezint prin intermediul unui romb gol, poziionat lng
clasa care reprezint ntregul.
Relaiile de grade strict mai mari dect 2 sunt reprezentate n UML cu
ajutorul unui romb (ca n figura 2.2) sau prin intermediul unei clase cu
stereotip. Stereotipurile constituie un mecanism de extensibilitate al
UML. Ele permit extinderea vocabularului UML astfel nct s poat
fi definite noi elemente ale modelului, derivate din cele existente dar
cu proprieti specifice domeniului problemei. Reprezentarea grafic a
unui stereotip se face prin plasarea numelui su, ncadrat ntre
caracterele << i >> deasupra numelui unui alt element.
n exemplul considerat, asocierea primeste este ternar, constituind
totodat o clas de asociere. Reprezentarea acestei relaii de gradul 3
prin intermediul unei clase cu stereotip are forma indicat n figura
2.3.

Modelarea entitate-relaie

Fig. 2.3. Asociere UML de tipul 3 cu stereotip.

83

Diagrame entitate-relaie
Diagrama E/R model neformalizat pentru reprezentarea unui
sistem din lumea real. Este un model de date conceptual de nivel nalt
dezvoltat de Chen (1976) pentru a facilita proiectarea bazelor de date.
Modelul de date conceptual este independent de:
tipul SGBD-ului;
platforma hardware utilizata.
Modelul conceptual este constituit din concepte care descriu:
structura bazei de date;
tranzactii de regasire si reactualizare asociate.

Entitate: persoan, loc, concept, activitate, eveniment care este

semnificativ pentru ceea ce modelm.

DEPARTAMENT

SARCINA
lucreaza_in

conduce
apartine_la

SALARIAT

atasat_la

PROIECT

Observaii:
Entitile devin tabele n modelele relaionale.
n general, entitile se scriu cu litere mari.
Entitile sunt substantive, dar nu orice substantiv este o entitate.
Pentru fiecare entitate este obligatoriu s se dea o descriere
detaliat.
Nu pot exista, n aceeai diagram, dou entiti cu acelai nume,
sau o aceeai entitate cu nume diferite.
Cheia primar este un identificator unic n cadrul entitii, fcnd
distincie ntre valori diferite ale acesteia.

Cheia primar:
trebuie s fie unic i cunoscut la orice moment;
trebuie s fie controlat de administratorul bazei;
trebuie s nu conin informaii descriptive, s fie simpl, fr
ambiguiti;
s fie stabil;
s fie familiar utilizatorului.

Relaie (asociere): o comunicare ntre dou sau mai multe entiti.

Existena unei relaii este subordonat existenei entitilor pe care le leag.

Gradul (tipul) unei relatii este dat de numarul entitatilor participante la
relatia respectiva.
Observaii:

n modelul relaional, relaiile devin tabele speciale sau coloane

speciale care refer chei primare.
Relaiile sunt verbe, dar nu orice verb este o relaie.

Pentru fiecare relaie este important s se dea o descriere

detaliat.
n aceeai diagram pot exista relaii diferite cu acelai nume. n
acest caz, le difereniaz entitile care sunt asociate prin relaia
respectiv.
Pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i
minim) relaiei, adic numrul de tupluri ce aparin relaiei.
Se pot afla cardinalitatile cu verbele :

poate (cardinalitate maxim) trebuie (cardinalitate minima)

Exemplu:
Ci salariai pot lucra ntr-un departament? Muli!
n cte departamente poate lucra un salariat? In cel mult unul!

Relaia SALARIAT_lucreaza_in_DEPARTAMENT are cardinalitatea

maxim many-one (n:1).
Exemplu:
Ci salariai trebuie s conduc un departament? Cel puin unul!
Cte departamente trebuie s conduc un salariat? Zero!

Relaia SALARIAT_conduce_DEPARTAMENT are cardinalitatea minim

one-zero (1:0).

Atribut: proprietate descriptiv a unei entiti sau a unei relaii.

Atributele pot fi simple, compuse, cu valori multiple, derivate.
Observaii:
Trebuie fcut distincia ntre tipul atributului (devine coloan n
modelele relaionale) i valoarea acestuia (devine valoare n
coloane).

Atributele sunt substantive, dar nu orice substantiv este atribut.

Fiecrui atribut trebuie s i se dea o descriere complet (exemple,
contraexemple, caracteristici).
Pentru fiecare atribut trebuie specificat numele, tipul fizic
(integer, float, char etc.), valori posibile, valori implicite, reguli
de validare, tipuri compuse.

Pentru proiectarea diagramei entitate-relaie au fost stabilite

anumite reguli (nu sunt unice):
1. entitile sunt reprezentate prin dreptunghiuri;
2. relaiile dintre entiti sunt reprezentate prin arce neorientate;
3. atributele care reprezint chei primare trebuie subliniate sau
marcate prin simbolul #, plasat la sfritul numelui acestor
atribute;
4. cardinalitatea minim este indicat n paranteze, iar cardinalitatea
maxim se scrie fr paranteze;
5. nu trebuie specificate toate atributele.

SALARIAT
cod_salariat
nume
prenume
sex
salariu
1

conduce
1(0)

M(0)

atasat_la
data_initiala
functia

M(0)

PROIECT
nr_proiect
descriere
buget_alocat
1

M(0)

apartine_la

lucreaza_in
1

DEPARTAMENT
cod_departament
nume
nr_cladire

SARCINA
nr_proiect
nr_sarcina
data_inceperii
stare

Diagrama E/R.

Cazuri speciale de entiti, relaii, atribute i modul lor de

reprezentare n cadrul diagramei entitate-relaie.
1.

2.

3.

4.

5.
6.

7.

8.

9.

10.

Entitate dependent nu poate exista n mod independent

(SARCINA depinde de PROIECT). Cheia primar a unei entiti
dependente include cheia primar a sursei (nr_proiect) i cel puin o
descriere a entitii (nr_sarcina). Entitatea dependent se deseneaz
prin dreptunghiuri cu linii mai subiri.
Motenirea atributelor. Subentitate (subclas) submulime a unei
alte entiti, numit superentitate (superclas) (SALARIAT < >
PROGRAMATOR). Subentitatea se deseneaz prin dreptunghiuri
incluse n superentitate. Exist o relaie ntre o subentitate i o
superentitate, numit ISA, care are cardinalitatea maxim 1:1 i
minim 1:0. Cheile primare, atributele i relaiile unei superentiti
sunt valabile pentru orice subentitate. Afirmaia reciproc este fals.
Generalizare. Din entiti similare care au mai multe atribute comune
se pot crea superentiti. Aceste superentiti conin atributele
comune, iar atributele speciale sunt asignate la subentiti. Pentru
noile superentiti se introduc chei primare artificiale.
Specializare. Dup valorile unor atribute clasificatoare se pot
determina clase. Un grup de subentiti reciproc exclusive definete o
clas. Clasele se aliniaz n desen vertical.
ntr-o diagram E/R se pot defini relaii recursive.
Unele relaii sunt relative la dou entiti i le numim de tip 2, iar
dac relaiile implic mai mult de dou entiti, le vom numi de tip 3.
Trei relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie
de tip 3 n trei relaii de tip 2, pot aprea informaii incorecte.
Trebuie excluse din model relaiile indirecte deoarece ele pot conduce
la redundan n baza de date.
Atributele derivabile trebuie eliminate i introduse expresii prin care
aceste atribute pot fi calculate.
Relaie sau atribut? Dac un atribut al unei entiti reprezint cheia
primar a unei alte entiti, atunci el refer o relaie (cod_departament
n tabelul SALARIAT).
Entitate sau relaie? Se cerceteaz cheia primar. Dac aceasta
combin cheile primare a dou entiti, atunci este vorba de o relaie.
(cheia primar a relaiei asociat_la combin cod_salariat cu
nr_proiect, prin urmare, SALARIAT_asociat la_PROIECT va defini o
relaie i nu o entitate).

11.

12.

Un atribut indirect este inoportun. El nu descrie real relaia sau

entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt,
un atribut indirect este un caz special de relaie indirect care trebuie
eliminat pentru c introduce redundan n date (numrul cldirii n
care lucreaz un salariat este un atribut al entitii DEPARTAMENT
i nu este o caracteristic a entitii SALARIAT).
Exist atribute opionale, a cror valoare este uneori necunoscut,
alteori neaplicabil. Aceste atribute trebuie introduse la subentiti
(comisionul pentru deplasare i zona de lucru sunt atribute specifice
unui agent teritorial i trebuie introduse la subentitatea
AGENT_TERITORIAL).
Algoritmul pentru proiectarea diagramei entitate-relaie:
1. identificarea entitilor din cadrul sistemului analizat;
2. identificarea relaiilor dintre entiti i stabilirea cardinalitii;
3. identificarea atributelor aferente entitilor i asocierilor dintre
entiti;
4. stabilirea atributelor de identificare a entitilor (stabilirea
cheilor).
SALARIAT
cod_salariat
nume
ISA
1

1(0)

ISA
1

1(0)

1
conduce
1(0)

job_cod
AGENT_TERITORIAL
zona
comision

M(0)

PROGRAMATOR
limbaj
nivel

atasat_la
data_initiala
functia

PROIECT
nr_proiect
descriere
M(0) buget_alocat
1

apartine_la
1(0)
M(1)

M(0)
lucreaza_in

1(0)

casatorit

DEPARTAMENT
cod_departament
nume
nr_cladire

Diagrama E/R.

SARCINA
nr_proiect
nr_sarcina
data_inceperii
stare

Modelul EER (modelul E/R extins) = Diagrama E/R + concepte

aditionale (subclas, superclas, motenire, specializare, generalizare).

Gestiunea activitilor de mprumut dintr-o bibliotec

S-a presupus (restrictiv) c ntr-o zi un cititor nu poate mprumuta,
de mai multe ori, aceeai carte. Modelul prezint anomalii (de exemplu,
cheia primar de la entitatea carte)! A fost gndit n aceast manier cu
scop pur didactic.
Entitile i relaiile care intervin n acest model sunt urmtoarele:
1. CARTE (entitate independent) orice carte care se gsete n
inventarul bibliotecii. Cheia primar este atributul codel.
2. CITITOR (entitate independent) orice cititor care poate
mprumuta cri. Cheia primar este atributul codec.
3. DOMENIU (entitate independenta) domeniul cruia i aparine
o carte. Cheia primar este atributul coded.
4. IMPRUMUTA relaie avnd cardinalitatea m:m care leag
entitile CITITOR i CARTE.
5. APARTINE relaie
care leag atributele CARTE i
DOMENIU. Relaia are cardinalitatea maxim m:1, iar
cardinalitatea minim 1:1.

CARTE
codel#
titlu
autor
pret
nrex

M(0)

M(1)
imprumuta

M(0)
apartine

CITITOR
codec#
nume
dep

DOMENIU
coded#
intdom

Gestiunea activitilor de editare dintr-o editur

Se analizeaza activitatea dintr-o editur referitoare la culegerea
textelor, realizarea elementelor grafice, machetarea unor publicaii.

SALARIAT
cod_salariat#
tip
nume job
ISA
1

1(0)

M(0)

GRAFICIAN
tip

TEHNOREDACTOR
tip_editor

ISA
1

M(1)

1(0)

scrie

FRAME
nr_publicatie#
nr_capitol#
nr_frame#
M(0)
include
1

M(0)

1 realizeaz

CAPITOL
nr_publicatie#
nr_capitol#
M(1)
cuprinde
1

ISA
1

1(0)

REDACTOR_SEF
experienta

M(0)
coordoneaza

PUBLICATIE
nr_publicatie#
stil
limba

Gestiunea activitilor unei firme de construcii

Baza de date construit prin acest model, furnizeaz informaii legate
de obiective de execuie, investitori, executani, antiere, contracte etc.
necesare unui manager al unei firme de construcii

8
SANTIER
nr_santier#
specialitate
sef

CONTRACTANT
cod_contractant#
adresa
telefon
cont
banca

tip_contractant

M(0)
executa

SUBANTREPENOR
nume
nume_adm
functie_adm
1

ISA

LUCRARE
M( cod_obiectiv#
1) cod_lucrare#

adresa

1(0)

M(1)
necesita

INVESTITOR
tip_investitor

ISA
1

ISA

executa

PERS_FIZICA
nume
prenume
bi

1
investeste_in

OBIECTIV_
INVESTITIE
M(1) cod_obiectiv#
denumire
adresa

1(0)

1
atasat_la

ISA

PERS_JURIDICA
tip_juridic
nume
functie

CONTRACT
nr_contract#
M(1) tip_contract
data_avans

incheie
1

Tabelele din cursurile Oracle Education. Tabelele emp, dept,

salgrade modeleaz gestiunea salariailor unei firme.
Tabelul emp(empno#, ename, job, mgr, hiredate, sal, com, deptno)
conine informaii despre salariaii unei firme. Pentru fiecare salariat sunt
definite urmtoarele atribute: empno: codul salariatului; ename: numele
salariatului; job: funcia; mgr: codul efului; hiredate: data angajrii; sal:
salariul; com: comisionul; deptno: codul departamentului n care lucreaz.
Tabelul dept (deptno#, dname, loc) conine informaii despre
departamentele n care lucreaz salariaii. Atributele sale reprezint:
deptno: codul departamentului; dname: numele departamentului; loc:
localitatea unde funcioneaz departamentul.
Tabelul salgrade(grade#, losal, hisal) conine informaii despre
grilele de salarizare. Atributele tabelului au urmtoarea semnificaie: grade:
codul grilei de salarizare; losal: limita inferioar a grilei de salarizare;
hisal: limita superioar a grilei de salarizare.

Ordonarea informaiilor cu privire la descoperirile de

monede antice din Romania
EVENIMENT

petrecut_in

PUNCT

gasita_in

ARTICOL

publicata

stantata_cu

MONEDA

STANTA

inclusa_in

pastrata_la

TEZAUR

MUZEU

STANA (nr_stan, mprat emitent, valoare nominal, an emitere,

monetria, legenda de pe avers, legenda de pe revers) == > atribute ale
entitii STANTA
Completai cardinalitatea!

Evidena colilor de oferi din Romania

SCOALA

CLIENT

cod_scoala#

cod_client#

INSTRUCTOR

EXAMEN

cod_instructor#

cod_examen#

MASINA
cod_masina#

EXAMINATOR
cod_examinator#

Completai relaiile (lucreaza_la, conduce, sustine, asista, instruieste) dintre

entiti i specificai cardinalitatea!

10

Campionatele de fotbal ale diferitelor ri

ECHIPA
Cod_echipa#
Nume
Oras

M(1)

2
joaca

M(1)

MECI
Tara#
Nr_etapa#
Cod_meci#

M(1)
apartine_de
1

ETAPA
Tara
Nr_etapa
M(1)
atasata_la
1

CAMPIONAT
Tara#

sustine

M(1)

SPONSOR
Cod_sponsor#
Nume

11

Modelul relaional
Modelul relaional a fost conceput i dezvoltat de E.F. Codd. El este
un model formal de organizare conceptual a datelor, destinat reprezentrii
legturilor dintre date, bazat pe teoria matematic a relaiilor. Modelul
relaional este alctuit numai din relaii i prin urmare, orice interogare
asupra bazei de date este tot o relaie.
Caliti:
este simplu;
riguros din punct de vedere matematic;

nu este orientat spre sistemul de calcul.

Modaliti pentru definirea unui SGBD relaional:

prezentarea datelor n tabele supuse anumitor operaii de tip

proiecie, selecie, reuniune, compunere, intersecie etc.

un sistem de baze de date ce suport un limbaj de tip SQL

Structured Query Language;

un sistem de baze de date care respect principiile modelului

relaional introdus de E.F. Codd.

Caracteristicile unui model relaional:

structura relaional a datelor;

operatorii modelului relaional;

regulile de integritate care guverneaz folosirea cheilor n model.

Aceste trei elemente corespund celor trei componente ale ingineriei

software: informaie, proces, integritate.

Structura datelor
Definirea noiunilor de domeniu, relaie, schem relaional, valoare
null i tabel vizualizare (view).
Conceptele utilizate pentru a descrie formal, uzual sau fizic
elementele de baz ale organizrii datelor sunt date n urmtorul tabel:
Formal
relaie
tuplu
atribut
domeniu

Uzual
tablou
linie
coloan
tip de dat

Fizic
fiier
nregistrare
cmp
tip de dat

12

Domeniu mulime de valori care poate fi definit fie enumernd

elementele componente, fie definind o proprietate distinctiv a domeniului
valorilor.
Fie D1, D2, ..., Dn domenii finite, nu neaprat disjuncte. Produsul
cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de
mulimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn.
Numrul n definete aritatea tuplului.
O relaie R pe mulimile D1, D2, ..., Dn este o submulime a produsului
cartezian D1 D2 ... Dn, deci este o mulime de tupluri. Caracteristicile
unei relaii comentat curs!
Caracteristicile unei relatii:
are o denumire unica;
fiecare celula contine o valoare atomica;
fiecare atribut are nume unic;
toate valorile unui atribut apartin aceluiasi domeniu;
ordinea atributelor nu are importanta;
nu exista dubluri ale tuplurilor;
teoretic, ordinea tuplurilor nu are importanta.
Definirea unei relaii se refer la mulimi care variaz n timp. Pentru a
caracteriza o relaie este necesar existena un element invariant n timp:
structura relaiei (schema relaional). Mulimea numelor atributelor
corespunztoare unei relaii R definete schema relaional a relaiei
respective. Vom nota schema relaional prin R(A1, A2, ..., An). Exemplu!
Putem reprezenta o relaie printr-un tabel bidimensional n care fiecare
linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu din
produsul cartezian. O coloan corespunde de fapt unui atribut. Numrul
atributelor definete gradul (aritatea) relaiei, iar numrul de tupluri din
relaie definete cardinalitatea relaiei.
Exemplu (crearea unui tabel n SQL):
CREATE TABLE salariat
cod_salariat
nume
prenume
sex
salariu
sot
job_cod
cod_departament

(
SMALLINT,
VARCHAR(25),
VARCHAR(20),
CHAR(1),
INTEGER,
SMALLINT,
VARCHAR(6),
SMALLINT );

13

Cnd se insereaz tupluri ntr-o relaie, de multe ori un atribut este

necunoscut sau neaplicabil. Pentru a reprezenta acest atribut a fost
introdus o valoare convenional n relaie, i anume valoarea null.
Tabelul vizualizare (view, filtru, relaie virtual, vedere) constituie
un filtru relativ la unul sau mai multe tabele, care conine numai informaia
necesar unei anumite abordri sau aplicaii.
Vizualizarea este virtual deoarece datele pe care le conine nu sunt
n realitate memorate ntr-o baz de date. Este memorat numai definiia
vizualizrii. Vizualizarea nu este definit explicit, ca relaiile de baz, prin
mulimea tuplurilor componente, ci implicit, pe baza altor relaii prin
intermediul unor expresii relaionale. Stabilirea efectiv a tuplurilor care
compun vizualizarea se realizeaz prin evaluarea expresiei atunci cnd
utilizatorul se refer la acest tabel.
Exemplu (crearea unei vizualizri n SQL):
CREATE VIEW programator(nume,departament)
AS SELECT nume,cod_departament
FROM
salariat
WHERE
job_cod=programator;

Reguli de integritate aseriuni pe care datele coninute n baza

de date trebuie s le satisfac.

Trebuie fcut distincia ntre:

regulile structurale inerente modelrii datelor;
regulile de funcionare specifice unei aplicaii particulare.
Exist trei tipuri de constrngeri structurale (de cheie, de referin, de
entitate) ce constituie mulimea minimal de reguli de integritate pe care
trebuie s le respecte un SGBD relaional. Restriciile de integritate
minimale sunt definite n raport cu noiunea de cheie a unei relaii.
O mulime minimal de atribute ale cror valori identific unic un
tuplu ntr-o relaie reprezint o cheie pentru relaia respectiv.
Fiecare relaie are cel puin o cheie. Una dintre cheile candidat va fi
aleas pentru a identifica efectiv tupluri i ea va primi numele de cheie
primar. Cheia primar nu poate fi reactualizat. Atributele care reprezint
cheia primar sunt fie subliniate, fie urmate de semnul #.
O cheie identific linii i este diferit de un index care localizeaz
liniile. O cheie secundar este folosit ca index pentru a accesa tupluri. Un
grup de atribute din cadrul unei relaii care conine o cheie a relaiei poart
numele de supercheie.

14

Fie schemele relaionale R1(P1, S1) i R2(S1, S2), unde P1 este cheie
primar pentru R1, S1 este cheie secundar pentru R1, iar S1 este cheie
primar pentru R2. n acest caz, vom spune c S1 este cheie extern (cheie
strin) pentru R1.
Modelul relaional respect trei reguli de integritate structural.
Regula 1 unicitatea cheii. Cheia primar trebuie s fie unic i
minimal.

Regula 2 integritatea entitii. Atributele cheii primare trebuie

s fie diferite de valoarea null.

Regula 3 integritatea referirii. O cheie extern trebuie s fie ori

null n ntregime, ori s corespund unei valori a cheii primare
asociate.

Proiectarea modelului relaional (exemple curs!)

Transformarea entitilor

Entitile independente devin tabele independente. Cheia

primar nu conine chei externe.

Entitile dependente devin tabele dependente. Cheia primar a

entitilor dependente conine cheia primar a entitii de care
depinde (cheie extern) plus unul sau mai multe atribute
adiionale.

Subentitile devin subtabele. Cheia extern se refer la

supertabel, iar cheia primar este aceast cheie extern (cheia
primar a subentitii PROGRAMATOR este cod_salariat care
este o cheie extern).

Transformarea relaiilor

Relaiile 1:1 i 1:n devin chei externe. Relaia conduce devine

coloan n tabelul DEPARTAMENT, iar relaia lucreaza_in
devine coloan n tabelul SALARIAT. Simbolul indic
plasamentul cheii externe, iar simbolul exprim faptul c
aceast cheie extern este coninut n cheia primar. Relaia 1:1
plaseaz cheia extern n tabelul cu mai puine linii.

Relaia m:n devine un tabel special, numit tabel asociativ, care

are dou chei externe pentru cele dou tabele asociate. Cheia
primar este compunerea acestor dou chei externe plus
eventuale coloane adiionale. Tabelul se deseneaz punctat.

15

Relaiile de tip trei devin tabele asociative. Cheia primar este

compunerea a trei chei externe plus eventuale coloane adiionale.

Transformarea atributelor

Un atribut singular devine o coloan.

Atributele multiple devin tabele dependendente ce conin cheia

primar a entitii i atributul multiplu. Cheia primar este o
cheie extern, plus una sau mai multe coloane adiionale.

Entitile devin tabele, iar atributele lor devin coloane n aceste

tabele. Ce devin atributele relaiilor? Pentru relaii 1:1 i 1:n,
atributele relaiilor vor aparine tabelului care conine cheia
extern, iar pentru relaii m:n i de tipul trei, atributele vor fi
plasate n tabelele asociative.
SALARIAT

PROIECT

cod_salariat#

conduce

nr_proiect#

lucreaza_in

apartine_la

DEPARTAMENT

SARCINA

cod_departament#

SALARIAT
cod_salariat#

nr_proiect#
nr_sarcina#

atasat_la
cod_salariat#
nr_proiect#

PROIECT
nr_proiect#

TELEFON
SALARIAT

cod_salariat#
nr_telefon#

cod_salariat#

Cele patru tipuri de tabele (independente, dependente, subtabele i

asociative) se deosebesc prin structura cheii primare.

16

Tabel
Independent
Subtabel
Dependent
Asociativ

Reprezint
entitate independent
subentitate
entitate dependent
atribute multiple
relaie m:n
relaii de tip 3

Cheie primar
nu conine chei externe
o cheie extern
o cheie extern i una sau mai
multe coloane adiionale
dou sau mai multe chei externe
i (opional) coloane adiionale

Diagrama conceptual pentru proiectarea modelului relaional

comentat a fost construit din diagrama E/R prin adugarea tabelelor
asociative i prin marcarea cheilor externe.

SALARIAT
cod_salariat#
salariu
nume
sex

job_cod
ATASAT_LA
cod_salariat#
nr_proiect#
functie

AGENT_TERITORIAL
zona
comision

PROIECT
nr_proiect#
descriere
buget_alocat

PROGRAMATOR
limbaj
nivel
apartine_la

conduce

lucreaza_in

DEPARTAMENT
cod_departament#
nume
nr_cladire

casatorit

TELFON
cod_salariat#
nr_telefon#

SARCINA
nr_proiect#
nr_sarcina#
data_inceperii
stare

Schemele relaionale corespunztoare acestei diagrame conceptuale

sunt urmtoarele:
SALARIAT(cod_salariat#, nume, prenume, sex, job_cod, cod_sot,
forma_plata, nr_depart);

17

DEPARTAMENT(cod_departament#, nume, numar_cladire,

cod_sal);
ATASAT_LA(cod_salariat#, nr_proiect#, functia);
PROIECT(nr_proiect#, descriere, buget_alocat);
SARCINA(nr_proiect#, nr_sarcina, data_inceperii, stare);
AGENT_TERITORIAL(cod_salariat#, zona, comision);
PROGRAMATOR(cod_salariat#, limbaj, nivel);
TELEFON(cod_salariat#, nr_telefon#).

Gestiunea activitilor unei firme de construcii

CONTRACTANT(cod_contractant#,
tip_contractant);

adresa,

telefon,

cont,

banca,

SUBANTREPRENOR(cod_contractant#, nume, nr_reg_comert,

nume_adm, functie_adm);
INVESTITOR(cod_contractant#, tip_investitor);
PERS_FIZICA(cod_contractant#, nume, prenume, bi);
PERS_JURIDICA(cod_contractant#, tip_juridic, nume, reprez_legal,
functie);
CONTRACT(nr_contract#, tip_contract, data_incheiere, garantie,
val_investitie, durate_executie, cont, banca, perioada, avans, data_avans,
cod_contractant);
SANTIER(nr_santier#, specialitate, sef);
OBIECTIV_INVESTITIE(cod_obiectiv#, denumire, adresa, adc,
nr_cert_urb, nr_aut_constr, nr_contract, cod_contractant);
LUCRARE(cod_lucrare#, cod_obiectiv#, tip_lucrare, nume, data_inc,
data_sf, nr_santier, cod_contractant);

18

CONTRACTANT
cod_contractant#
adresa
telefon
cont
banca

tip_contractant
SUBANTREPENOR
nume
nume_adm
funcie_adm

executa

LUCRARE
cod_lucrare#
cod_obiectiv# executa

ANTIER
nr_antier#
specialitate ef

necesita

INVESTITOR
tip_investitor

OBIECTIV_INVESTITIE
cod_obiectiv#
denumire
adresa

PERS_FIZICA
nume
prenume
bi

investeste_in

atasat_la

CONTRACT
PERS_JURIDICA
tip_juridic
nume
functie

nr_contract#
tip_contract
data_avans
incheie

19

Gestiunea activitilor de editare dintr-o editur

SALARIAT
cod_salariat#
nume
job
GRAFICIAN
tip

REALIZEAZA
cod_salariat#
nr_publicatie#
nr_capitol#
nr_frame#

FRAME
nr_publicatie#
nr_capitol#
nr_frame#
tip
include

TEHNOREDACTOR
tip_editor

scrie

REDACTOR_SEF
experienta

CAPITOL
nr_publicatie#
nr_capitol#
dimensiune

coordoneaza
TELEFON
cod_salariat#
nr_telefon#

LIMBA
cod_salariat#
limba_cun#

cuprinde

PUBLICATIE
nr_publicatie#
stil

SALARIAT(cod_salariat#, nume, prenume, vechime, salariu, job);

GRAFICIAN(cod_salariat#, tip);
TEHNOREDACTOR(cod_salariat#, tip_platforma, tip_editor, viteza);
REDACTOR_SEF(cod_salariat#, experienta);
LIMBA(cod_salariat#, limba_cunos#);
TELEFON(cod_salariat#, nr_telefon#);
REALIZEAZA(cod_salariat#, nr_frame#, nr_publicatie#, nr_capitol#,
data_inc, data_lim);
FRAME(nr_frame#, nr_publicatie#, nr_capitol#, tip, dim, format);
CAPITOL(nr_publicatie#, nr_capitol#, dimensiune, cod_salariat);
PUBLICATIE(nr_publicatie#, stil, beneficiar, autor, cod_salariat, cost,
titlu, limba).

20

Algebra relaional
Limbajul de definire a datelor (LDD) precizeaz entitile, relaiile
dintre ele, atributele, structura atributelor, cheile, constrngerile, prin
urmare definete structura obiectelor bazei de date (schema bazei).
Limbajul de prelucrare a datelor (LMD) dintr-o baz de date
relaionale cuprinde aspecte referitoare la introducerea, eliminarea,
modificarea i cutarea datelor.
Introducerea datelor permite adugarea de tupluri la o relaie.
Tuplurile pot fi introduse de utilizator sau pot fi obinute din alte
relaii existente n baza de date.

Eliminarea datelor permite tergerea tuplurilor ce satisfac

condiii date.

Modificarea datelor permite reactualizarea tuplurilor ce

satisfac condiii date cu noi valori ale atributelor sau cu rezultate
ale unor operaii aritmetice efectuate asupra unor valori existente.

Cutarea datelor permite gsirea tuplurilor sau a unor pri ale

tuplurilor ce satisfac condiii date.

Modelul relaional ofer dou mulimi de operatori pe relaii:

algebra relaional (filtrele se obin aplicnd operatori specializai
asupra uneia sau mai multor relaii din cadrul bazei relaionale);
calculul relaional (filtrele se obin cu ajutorul unor formule
logice pe care tuplurile rezultatului trebuie s le satisfac).
Algebra relaional a fost introdus de E.F. Codd ca o mulime de
operaii formale acionnd asupra unor relaii i avnd ca rezultat alte
relaii. Baza teoretic pentru limbajele de interogare relaionale o constituie
operatorii introdui de Codd pentru prelucrarea relaiilor.
Operatorii modelului relaional definesc operaiile care se pot efectua
asupra relaiilor n scopul realizrii funciilor de prelucrare asupra BD.
Operatorii sunt numai pentru citire (nu actualizeaza operanzi)!!!
Scopul fundamental al algebrei relationale este de a permite scrierea
expresiilor relationale. Expresiile servesc ca o reprezentare de nivel
superior, simbolic, a inteniilor utilizatorului i pot fi supuse unei
diversiti de reguli de transformare (optimizare).
Relaiile sunt nchise fa de algebra relaional (operanzii i

21

rezultatele sunt relaii ieirea unei operaii poate deveni intrare pentru
alta) posibilitatea imbricrii expresiilor n algebra relaional).
Operatorii algebrei relaionale sunt:

operatori tradiionali pe mulimi (UNION, INTERSECT,

PRODUCT, DIFFERENCE);

operatori relaionali speciali (PROJECT, SELECT, JOIN,

DIVISION).

Calculul relaional reprezint o adaptare a calculului predicatelor la

domeniul bazelor de date relaionale. Ideea de baz este de a identifica o
relaie cu un predicat. Pe baza unor predicate iniiale, prin aplicarea unor
operatori ai calculului cu predicate (conjuncia, disjuncia, negaia,
cuantificatorul existenial i cel universal) se pot defini noi relaii.
Calculul relaional poate s fie orientat pe tupluri sau orientat pe
domenii.
Echivalena dintre algebra relaional i calculul relaional a fost
demonstrat de J.D.Ullman. Aceast echivalen arat c orice relaie
posibil de definit n algebra relaional poate fi definit i n cadrul calcului
relaional, i reciproc.
Operatorii (unari sau binari) algebrei relaionale realizeaz
urmtoarele funcii:
SELECT (selecie) extrage tupluri ce satisfac o condiie specificat;
PROJECT (proiecie) extrage atributele specificate;
DIFFERENCE (diferen) extrage tupluri care apar ntr-o relaie, dar
nu apar n cealalt;
PRODUCT (produs cartezian) genereaz toate perechile posibile de
tupluri, primul element al perechii fiind luat din prima relaie, iar cel deal doilea element din cealalt relaie;
UNION (reuniune) reunete dou relaii;
INTERSECT (intersecie) extrage tupluri care apar n ambele relaii;
DIVISION (diviziune) extrage valorile atributelor dintr-o relaie, care
apar n toate valorile atributelor din cealalt relaie;
JOIN (compunere) extrage tupluri din mai multe relaii corelate:
NATURAL JOIN (compunere natural) combin tupluri din dou
relaii, cu condiia ca atributele comune s aib valori identice;
SEMI-JOIN (semi-compunere) selecteaz tupluri ce aparin unei
singure relaii, care sunt corelate cu tupluri din cea de a doua relaie;

22

-JOIN (-compunere) combin tupluri din dou relaii (nu neaparat

corelate), cu condiia ca valorile atributelor specificate s satisfac o
anumit condiie;
OUTER JOIN (compunere extern) combin tupluri din dou relaii,
astfel nct condiiile de corelare s fie satisfcute. Tuplurile din orice
relaie care nu satisfac aceste condiii sunt completate cu valori null.
Pentru operatorii UNION, INTERSECT i DIFFERENCE, se
presupune c sunt aplicai numai la relaii avnd aceeai aritate, iar ordinea
(nu numele) atributelor este aceeai.

Operatorul PROJECT
Proiecia este o operaie unar care elimin anumite atribute ale unei
relaii producnd o submulime pe vertical a acesteia. Suprimarea unor
atribute poate avea ca efect apariia unor tupluri duplicate, care trebuie
eliminate.
Prin proiecie se construiete dintr-o relaie R, o nou relaie:
a) tergnd din R atributele care nu sunt menionate n parametrii
proieciei;
b) eliminnd dublurile care apar dup tergere.
Pentru a reprezenta operatorul proiecie sunt utilizate diferite notaii:
A1, ..., Am (R)

PROJECT (R, A1, ..., Am)

R[A1, ..., Am]

unde A1, A2, ..., Am sunt parametrii proieciei relativ la relaia R.
Exemplu. S se obin o list ce conine numele, prenumele i sexul
angajailor.
1. Proiecie n algebra relaional:
Rezultat = PROJECT(SALARIAT, nume, prenume, sex)
2.

Proiecie cu dubluri n SQL:

SELECT
FROM
3.

nume, prenume, sex

salariat;

Proiecie fr dubluri n SQL:

SELECT
FROM

DISTINCT nume, prenume, sex

salariat;

23

Operatorul SELECT
Selecia (restrictia) este o operaie unar care produce o submulime
pe orizontal a unei relaii R. Aceast submulime se obine prin
extragerea tuplurilor din R care satisfac o condiie specificat.
Sunt utilizate diferite notaii:
condiie(R)

R[condiie]

SELECT(R, condiie)

RESTRICT(R, condiie).

Exemplu. S se obin informaii complete despre angajaii de sex

masculin.
1.

Selecie n algebra relaional:

Rezultat = SELECT(SALARIAT, sex = m)

2.

Selecie n SQL:

SELECT
FROM
WHERE

*
salariat
sex = m;

Operatorul UNION
Reuniunea a dou relaii R i S este mulimea tuplurilor aparinnd
fie lui R, fie lui S, fie ambelor relaii.
Sunt utilizate notaiile:
RS
UNION(R, S)
OR(R, S)
APPEND(R, S).
Exemplu. S se obin lista cu numele persoanelor fizice i a
subantreprenorilor.
SELECT
FROM
UNION
SELECT
FROM

nume
subantreprenor
nume
pers_fizica;

24

Operatorul DIFFERENCE
Diferena a dou relaii R i S este mulimea tuplurilor care aparin
lui R, dar nu aparin lui S. Diferena este o operaie binar necomutativ
care permite obinerea tuplurilor ce apar numai ntr-o relaie.
Sunt utilizate diferite notaii:
RS
DIFFERENCE(R, S)
REMOVE(R, S)
MINUS(R, S).
Exemplu. S se obin lista cu numrul contractului, tipul
contractului, valoarea investiiei i durata lucrrii pentru contractele de
subantrepriz pentru care valoarea investiiei nu depete 60000$.
1. Diferen n algebra relaional:

R=PROJECT(SELECT(CONTRACT, tip_contract=T),
nr_contract, tip_contract, val_investitie, durata_lucrare);
S=PROJECT(SELECT(CONTRACT, val_investitie > 60000),
nr_contract, tip_contract, val_investitie, durata_lucrare);
Rezultat = DIFFERENCE(R, S)
2. Diferena n SQL:

SELECT

nr_contract,tip_contract,
val_investitie,durata_lucrare
contract
tip_contract

FROM
WHERE
MINUS
SELECT
nr_contract,tip_contract,
val_investitie,durata_lucrare
FROM
contract
WHERE
val_investitie>60000;
Evident diferena se poate referi la tabele diferite! Implementai
cererea prin care se listeaz toate oraele n care se afl o filial, dar nici o
proprietate.

Operatorul INTERSECT
Intersecia a dou relaii R i S este mulimea tuplurilor care aparin
i lui R i lui S. Operatorul INTERSECT este un operator binar, comutativ,
derivat:

25

R S = R (R S)
R S = S (S R).
Sunt utilizate diferite notaii:
INTERSECT(R, S)
RS
AND(R, S).
n anumite dialecte SQL exist operator special (INTERSECT), care
realizeaz aceast operaie. Operatorii INTERSECT i DIFFERENCE pot
fi simulai n SQL (n cadrul comenzii SELECT) cu ajutorul opiunilor
EXISTS, NOT EXISTS, IN, != ANY.
Exemplu. Utiliznd tabelele agent_teritorial i programator s se
obin lista codurilor salariailor care sunt programatori, dar care lucreaz i
ca ageni teritoriali.
1.

Intersecie n algebra relaional:

R = PROJECT(AGENT_TERITORIAL, cod_salariat);
S = PROJECT(PROGRAMATOR, cod_salariat),
Rezultat = INTERSECT(R, S).
2.

Intersecie n SQL:

SELECT
cod_salariat
FROM
agent_teritorial
INTERSECT
SELECT
cod_salariat
FROM
programator;
3.

Simularea interseciei n SQL:

SELECT
cod_salariat
FROM
programator p
WHERE EXISTS
(SELECT cod_salariat
FROM
agent_teritorial a
WHERE
p.cod_salariat=a.cod_salariat);

Operatorul PRODUCT
Fie R i S relaii de aritate m, respectiv n. Produsul cartezian al lui R
cu S este mulimea tuplurilor de aritate m + n unde primele m componente
formeaz un tuplu n R, iar ultimele n componente formeaz un tuplu n S.
Sunt utilizate diferite notaii:

26

RS
PRODUCT(R, S)
TIMES(R, S).
Exemplu. S se obin lista tuturor posibilitilor de investiie n
diverse obiective de ctre o firm care este persoan juridic.
1.

Produs cartezian n algebra relaional:

R = PROJECT(PERS_JURIDICA, nume, cod_contractant);

S = PROJECT(OBIECTIV_INVESTITIE, denumire);
Rezultat = PRODUCT(R, S).
2.

Produs cartezian n SQL:

SELECT
FROM

cod_contractant, nume, denumire

obiectiv_investitie, pers_juridica;

Operatorul DIVISION
Diviziunea este o operaie binar care definete o relaie ce conine
valorile atributelor dintr-o relaie care apar n toate valorile atributelor din
cealalt relaie.
Sunt utilizate diferite notaii:
DIVIDE(R, S)
DIVISION(R, S)
R S.
Diviziunea conine acele tupluri de dimensiune n m la care, adugnd
orice tuplu din S, se obine un tuplu din R.
Operatorul diviziune poate fi exprimat formal astfel:
R(n) S(m) = {t(n-m) s S, (t, s) R} unde n > m i S .
Operatorul DIVISION este legat de cuantificatorul universal () care
nu exist n SQL. Cuantificatorul universal poate fi ns simulat cu ajutorul
cuantificatorului existenial () utiliznd relaia:
x P(x) x P(x).
Prin urmare, operatorul DIVISION poate fi exprimat n SQL prin
succesiunea a doi operatori NOT EXISTS.
Exemplu. S se obin codurile salariailor ataai tuturor proiectelor
pentru care s-a alocat un buget egal cu 1000.
1.

Diviziune n algebra relaional:

27

R = PROJECT(ATASAT_LA, cod_salariat, nr_proiect);

S = PROJECT(SELECT(PROIECT, buget = 1000), nr_proiect);
Rezultat = DIVISION(R, S).
2.

Diviziune n SQL:

SELECT
UNIQUE cod_salariat
FROM
atasat_la sx
WHERE NOT EXISTS
(SELECT *
FROM
proiect pp
WHERE
proiect.buget=1000
AND NOT EXISTS
(SELECT *
FROM
atasat_la bb
WHERE
pp.nr_proiect=bb.nr_proiect
AND bb.cod_salariat=sx.cod_salariat));
3.

Simularea diviziunii cu ajutorul funciei COUNT:

SELECT
cod_salariat
FROM
atasat_la
WHERE
nr_proiect IN
(SELECT nr_proiect
FROM
proiect
WHERE
buget=1000)
GROUP BY cod_salariat
HAVING
COUNT(nr_proiect)=
(SELECT COUNT(*)
FROM
proiect
WHERE
buget=1000);

Operatorul JOIN
Operatorul de compunere (uniune) permite regsirea informaiei din
mai multe relaii corelate. Operatorul combin produsul cartezian, selecia
i proiecia.

Operatorul NATURAL JOIN

Operatorul de compunere natural (NATURAL JOIN) combin

tupluri din dou relaii R i S, cu condiia ca atributele comune s aib
valori identice.
Algoritmul care realizeaz compunerea natural este urmtorul:
1.

se calculeaz produsul cartezian R S;

28

2.

3.

pentru fiecare atribut comun A care definete o coloan n R i o

coloan n S, se selecteaz din R S tuplurile ale cror valori
coincid n coloanele R.A i S.A (atributul R.A reprezint numele
coloanei din R S corespunztoare coloanei A din R);
pentru fiecare astfel de atribut A se proiecteaz coloana S.A, iar
coloana R.A se va numi A.

Operatorul NATURAL JOIN poate fi exprimat formal astfel:

JOIN(R, S) = i1,...,im (R.A1 = S.A1) ... (R.Ak = S.Ak)(R S),
unde A1, ..., Ak sunt atributele comune lui R i S, iar i1, ..., im reprezint lista
componentelor din R S (pstrnd ordinea iniial) din care au fost
eliminate componentele S.A1, ..., S.Ak.
Exemplu. S se obin informaii complete despre angajai i
departamentele n care lucreaz.
1.

Operatorul de compunere natural n algebra relaional:

Rezultat = JOIN(SALARIAT, DEPARTAMENT).

2.

Operatorul de compunere natural n SQL:

SELECT
FROM
WHERE

*
salariat, departament
nr_depart = cod_departament;

Operatorul -JOIN
Operatorul -JOIN combin tupluri din dou relaii (nu neaprat
corelate) cu condiia ca valorile atributelor specificate s satisfac o
anumit condiie specificat explicit n cadrul operaiei.
Operatorul -JOIN este un operator derivat, fiind o combinaie de
produs scalar i selecie:
JOIN(R, S, condiie) = condiie (R S)
Exemplu. S se afieze pentru fiecare salariat, codul acestuia i grila
sa de salarizare.
SELECT
empno, level
FROM
salgrade, emp
WHERE
sal BETWEEN losal AND hisal;
Exemplu. S se obin informaii despre contractani (codul i banca)
i obiectivele de investiie asociate acestora (denumire, numr certificat de
urbanizare) cu condiia ca obiectivele s nu fie la aceeai adres ca i
contractanii.

29

1.

Operatorul -JOIN n algebra relaional:

R = PROJECT(CONTRACTANT, cod_contractant, banca);

S = PROJECT(OBIECTIV_INVESTITIE, denumire, nr_cert_urb);
Rezultat = JOIN(R, S, OBIECTIV_INVESTITIE.adresa <>
CONTRACTANT.adresa).
2.

Opratorul -JOIN n SQL:

SELECT
FROM
WHERE

cod_contractant,banca, nr_cert_urb,
denumire
contractant a,obiectiv_investitie b
b.adresa <> a.adresa;

Operatorul SEMI-JOIN
Operatorul SEMI-JOIN conserv atributele unei singure relaii
participante la compunere i este utilizat cnd nu sunt necesare toate
atributele compunerii. Operatorul este asimetric.
Tupluri ale relaiei R care particip n compunerea (natural sau
-JOIN) dintre relaiile R i S.
SEMI-JOIN este un operator derivat, fiind o combinaie de proiecie
i compunere natural sau proiecie i -JOIN:
SEMIJOIN(R, S) = M (JOIN(R, S))
SEMIJOIN(R, S, condiie) = M (JOIN(R, S, condiie)),
unde am notat prin M atributele relaiei R.
Exemplu. S se obin informaii referitoare la persoanele fizice
(nume, buletin) care investesc n obiective cu caracter recreativ.
1.

Operatorul SEMI-JOIN n algebra relaional:

R = SELECT(OBIECTIV_INVESTITIE, denumire = cabana OR

denumire = casa de vacanta)
S = JOIN(PERS_FIZICA, R)
Rezultat = PROJECT(S, nume, buletin).
2.

SELECT
FROM
WHERE
AND

Operatorul SEMI-JOIN n SQL:

nume,bi
pers_fizica a,obiectiv_investitie b
a.cod_contractant = b.cod_contractant
(denumire=cabana)OR (denumire= casa
de vacanta);

30

Operatorul OUTER JOIN

Operaia de compunere extern combin tupluri din dou relaii
pentru care sunt satisfcute condiiile de corelare. n cazul aplicrii
operatorului JOIN se pot pierde tupluri, atunci cnd exist un tuplu n una
din relaii pentru care nu exist nici un tuplu n cealalt relaie, astfel nct
s fie satisfcut relaia de corelare.
Operatorul elimin acest inconvenient prin atribuirea valorii null
valorilor atributelor care exist ntr-un tuplu din una dintre relaiile de
intrare, dar care nu exist i n cea de-a doua relaie.
Practic, se realizeaz compunerea a dou relaii R i S la care se
adaug tupluri din R i S, care nu sunt coninute n compunere, completate
cu valori null pentru atributele care lipsesc.
Compunerea extern poate fi: LEFT, RIGHT, FULL. De exemplu,
OUTER JOIN LEFT reprezint compunerea n care tuplurile din R, care nu
au valori similare n coloanele comune cu relaia S, sunt de asemenea
incluse n relaia rezultat.
Exemplu. S se obin informaii referitoare la persoanele fizice care
sunt investitori (chiar dac nu au investit n obiective industriale) i la
obiectivele de investiie industriale (chiar i cele care nu sunt construite de
persoane fizice).
R = SELECT(OBIECTIV_INVESTITIE, denumire = 'industrial')
Rezultat = OUTERJOIN(PERS_FIZICA, R).
Operatorii algebrei relaionale pot fi reprezentai grafic cu ajutorul
unor simboluri speciale. curs!
Operaii adiionale: complement, despicare, nchidere tranzitiv.
Funcii asociate: MIN, MAX, COUNT, AVG, SUM, VAR, STD etc.

31

Evaluarea i optimizarea interogrilor

Procesarea interogrilor
O expresie a algebrei relaionale este constituit din relaii legate
prin operaii din algebra relaional. O expresie se poate reprezenta grafic
cu ajutorul unui arbore, numit arbore algebric, n care nodurile corespund
operatorilor din cadrul expresiei respective.
Evaluarea unei expresii presupune efectuarea prelucrrilor indicate
de operatorii din expresie n ordinea apariiilor sau n ordinea fixat prin
paranteze. Rezultatul evalurii unei expresii este o relaie derivat din
relaiile menionate ca operanzi n cadrul expresiei.
Dou expresii sunt echivalente, dac n urma evalurii lor se obine
ca rezultat aceeai relaie.
Exemple referitoare la moduri echivalente de exprimare a unei cereri
(vor fi rezolvate la curs!).
1. Informaii despre salariaii care nu contribuie la machetarea nici
unei publicaii, dar au retribuia mai mare dect o valoare dat.
2. Codul i numele subantreprenorilor care au realizat lucrri
specializate la obiective case de vacan sau cabane.
3. Codurile i telefoanele investitorilor, valoarea si durata de execuie
a investitiilor a caror valoare este ntre dou limite specificate.
4. Perioada de desfurare i preul ofertelor care ncep dup 1
ianuarie 2003 i sunt:
sejururi la munte;
excursii n care autocarele sunt conduse de oferi angajai dup 1
mai 1987 i supravegheate de ghizi ce cunosc limba englez care
au fcut specializare n Suedia.
n majoritatea sistemelor de gestiune, i n special n cele relaionale,
interfaa cu utilizatorul este de tip neprocedural. Utilizatorul definete datele
pe care dorete s le vizualizeze fr a da algoritmii de acces. Sistemul
trebuie s converteasc cererea utilizatorului:
ntr-o cerere optimal;
n proceduri de acces optimal la datele fizice.
Garantarea absolut a performanelor optime pentru procesorul
limbajului relaional este imposibil. Corect ar fi utilizarea cuvntului
ameliorare n locul cuvntului optimizare.

32

Evaluarea unei interogri se efectueaz n trei etape.

Analiza cererii presupune studierea sintactic i semantic a cererii

pentru a verifica corectitudinea sa i a simplifica criteriul de
cutare.

Ordonanarea presupune descompunerea cererii ntr-o mulime de

operaii elementare i determinarea unei ordini optimale a acestor
operaii. Operaiile sunt, n general, cele ale algebrei relaionale. La
sfritul etapei se obine un plan de execuie pentru cerere.

Execuia presupune efectuarea (paralel i/sau secvenial)

operaiilor elementare furnizate de planul de execuie pentru a
obine rezultatul cererii.

Presupunem c utilizatorul transmite sistemului de gestiune o cerere

exprimat prin ordine SQL. Pentru a rspunde cererii, SGBD-ul trebuie s
neleag cererea utilizatorului. Cererea trebuie s fie corect sintactic, datele
trebuie s fie disponibile utilizatorului i trebuie localizate analiznd diferite
drumuri de acces la ele. Aceste funcii sunt realizate de SGBD cu ajutorul a
dou module funcionale care comunic permanent:

analizorul cererilor, care asigur verificarea sintactic i

semantic a cererii, localizarea datelor implicate n cerere (gsirea
adresei blocurilor ce conin datele), furnizarea planului de execuie.

administratorul datelor (executorul), care execut efectiv cererea

(primete planurile de execuie furnizate de modulul de optimizare
i le execut). Execuia presupune cutarea blocurilor ce conin
datele i transferul blocurilor n memoria cache.

Ideea general:
cerere arbore algebric (nu este unic) plan de executie optimizare
Un plan de execuie implic o secven de pai pentru evaluarea cererii
(n mod obinuit, fiecare pas din planul de execuie corespunde unei operaii
relaionale) precum i metoda care va fi folosit pentru evaluarea operaiei.
De obicei, pentru o operaie relaional dat, exist mai multe metode ce pot
fi folosite pentru evaluarea acesteia.
Dou planuri de execuie diferite care au ntotdeauna acelai rezultat se
numesc echivalente. Planuri de execuie echivalente pot avea diferite
costuri. Scopul optimizrii cererilor este de a gsi, printre diversele planuri
de execuie echivalente, pe acela de cost minim. ntr-un sistem centralizat,
costul evalurii unei cereri este suma a dou componente, costul I/O
(transferuri de date) i costul CPU (verificare de condiii, operaii join etc.).

33

Ordinea de execuie a operaiilor

O interogare const dintr-un numr de operaii. Ordinea n care se
efectueaz operaiile are un rol important n evaluarea costului necesar
realizrii interogrii.
Exist dou modaliti de abordare pentru a determina ordinea de
execuie a operaiilor:
algebric;
bazat pe estimarea costului.
Ambele folosesc o mulime de reguli care permit transformarea unui
plan de execuie (reprezentat ca o expresie scris n termenii algebrei
relaionale) n altul, echivalent.
Optimizarea cererilor bazat pe algebra relaional se realizeaz n
dou etape:
se exprim cererile sub forma unor expresii algebrice relaionale;
se aplic acestor expresii transformri algebrice care conduc la
expresii echivalente, dar care vor fi executate mai eficient.
Procesul de transformare a cererilor se realizeaz conform unei
strategii de optimizare care poate s fie:
independent de modul de memorare a datelor (strategie general);
dependent de modul de memorare (strategie specific unui anumit
SGBD).

Proprietile operatorilor algebrei relaionale

Proprietatea 1. Comutativitatea operaiilor de join i produs cartezian:
JOIN(R1, R2) = JOIN(R2, R1)
R1 R2 = R2 R1
Proprietatea 2. Asociativitatea operaiilor de join i produs cartezian:
JOIN(JOIN(R1, R2), R3) = JOIN(R1, JOIN(R2, R3))
(R1 R2) R3 = R1 (R2 R3)
Proprietatea 3. Compunerea proieciilor:
A1,...,Am (B1,...,Bn (R)) = A1,...,Am (R),
unde {A1, A2,...,Am } {B1, B2,...,Bn}.
Proprietatea 4. Compunerea seleciilor:
cond1 (cond2 (R)) = cond1cond2 (R) = cond2 (cond1 (R)),
unde am notat prin cond condiia dup care se face selecia.

34

Proprietatea 5. Comutarea seleciei cu proiecia:

A1,...,Am (cond (R)) = cond (A1,...,Am (R)),
unde condiia dup care se face selecia implic numai atributele A1,...,Am.
Dac condiia implic i atributele B1,...,Bn, care nu aparin mulimii
{A1,...,Am}, atunci:
A1,...,Am (cond (R)) = A1,...,Am (cond (A1,...,Am,B1,...,Bn (R)))
Proprietatea 6. Comutarea seleciei cu produsul cartezian:
Dac toate atributele menionate n condiia dup care se face selecia
sunt atribute ale relaiei R1, atunci:
cond (R1 R2) = cond (R1) R2
Dac condiia este de forma cond1cond2 i dac cond1 implic
numai atribute din R1, iar cond2 implic numai atribute din R2, atunci
cond (R1 R2) = cond1 (R1) cond2 (R2)
Dac cond1 implic numai atribute din R1, iar cond2 implic atribute
att din R1 ct i din R2, atunci:
cond (R1 R2) = cond2 (cond1 (R1) R2)
Proprietatea 7. Comutarea seleciei cu reuniunea:
cond (R1 R2) = cond (R1) cond (R2)
Proprietatea 8. Comutarea seleciei cu diferena:
cond (R1 R2) = cond (R1) cond (R2)
Proprietatea 9. Comutarea proieciei cu reuniunea:
A1,...,Am (R1 R2) = A1,...,Am (R1) A1,...,Am (R2)
Proprietatea 10. Comutarea proieciei cu produsul cartezian:
Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1
i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin
B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci:
A1,...,Am (R1 R2) = B1,...,Bn (R1) C1,...,Ck (R2)
Proprietatea 11. Compunerea proieciei cu operaia join:
Dac A1,...,Am este o list de atribute ce apar n schemele relaionale R1
i R2 i dac lista este format din atribute aparinnd lui R1 (notate prin
B1,...,Bn) i din atribute aparinnd lui R2 (notate prin C1,...,Ck) atunci:
A1,...,Am (JOIN(R1,R2,D)) = A1,...,Am (JOIN(D,B1,...,Bn(R1), D,C1,...,Ck(R2),D),
unde am notat prin JOIN(R1, R2, D) operaia de compunere natural ntre R1
i R2 dup atributul comun D.

35

Proprietatea 12. Compunerea seleciei cu operaia join:

cond (JOIN (R1, R2, D)) = cond (JOIN (D,A (R1), D,A (R2), D)),
unde A reprezint atributele care apar n condiia dup care se face selecia.

Reguli de optimizare frecvent folosite:

Regula de optimizare 1. Seleciile se execut ct mai devreme
posibil. Motivaia acestei reguli este c seleciile reduc substanial
dimensiunea relaiilor. Regula de transformare 4 poate fi folosit
pentru a separa dou sau mai multe selecii n selecii individuale
care pot fi distribuite join-ului sau produsului cartezian folosind
comutarea seleciei cu join-ul.
Regula de optimizare 2. Produsurile carteziene se nlocuiesc cu joinuri, ori de cte ori este posibil. Un produs cartezian ntre dou relaii
este de obicei mult mai scump (ca i cost) dect un join ntre cele
dou relaii, deoarece primul genereaz concatenarea tuplurilor n
mod exhaustiv i poate genera un rezultat foarte mare. Aceast
transformare se poate realiza folosind legtura dintre produs
cartezian, join i selecie.
Regula de optimizare 3. Dac sunt mai multe join-uri atunci cel care
se execut primul este cel mai restrictiv. Un join este mai restrictiv
dect altul dac produce o relaie mai mic. Se poate determina care
join este mai restrictiv pe baza factorului de selectivitate sau cu
ajutorul informaiilor statistice. Algebric, acest lucru se poate realiza
folosind regula de transformare 2.
Regula de optimizare 4. Proieciile se execut la nceput pentru a
ndeprta atributele nefolositoare. Dac un atribut al unei relaii nu
este folosit n operaiile ulterioare atunci trebuie ndeprtat. n felul
acesta se va folosi o relaie mai mic n operaiile ulterioare. Aceasta
se poate realiza folosind comutarea proieciei cu join-ul.
Exemple curs!!!

36

Regulile lui Codd

Caracteristici ale modelului relaional:
nu exist tupluri identice;
ordinea liniilor i a coloanelor este arbitrar;
articolele unui domeniu sunt omogene;
fiecare coloan definete un domeniu distinct i nu se poate repeta n
cadrul aceleiai relaii;
toate valorile unui domeniu corespunztoare tuturor cazurilor nu mai
pot fi descompuse n alte valori (sunt atomice).
Avantajele modelului relaional:
fundamentare matematic riguroas;
independen fizic a datelor;
posibilitatea filtrrilor;
existena unor structuri de date simple;
realizarea unei redundane minime;
suplee n comunicarea cu utilizatorul neinformatician.
Ca limite ale modelului relaional putem meniona:
rmne totui redundan,
ocup spaiu,
apar fenomene de inconsisten,
nu exist mecanisme pentru tratarea optim a cererilor recursive,
nu lucreaz cu obiecte complexe,
nu exist mijloace perfecionate pentru exprimarea constrngerilor de
integritate,
nu realizeaz gestiunea totala a datelor distribuite,
nu realizeaz gestiunea cunotinelor.
n anul 1985, E.F. Codd a publicat un set de 13 reguli n raport cu
care un sistem de gestiune a bazelor de date poate fi apreciat ca relaional.
Nici un sistem de gestiune a bazelor de date pus n vnzare pe piaa
comercial nu respect absolut toate regulile definite de Codd, dar acest
lucru nu mpiedic etichetarea acestor sisteme drept relaionale.

37

Nu trebuie apreciat un SGBD ca fiind relaional sau nu, ci msura n

care acesta este relaional, deci numrul regulilor lui Codd pe care le
respect.
Regula 1 regula gestionrii datelor. Un SGBD relaional trebuie s
fie capabil s gestioneze o baz de date numai prin posibilitile sale
relaionale.
Regula 2 regula reprezentrii informaiei. ntr-o baz de date
relaional, informaia este reprezentat la nivel logic sub forma unor
tabele ce poart numele de relaii.
Regula 3 regula accesului garantat la date. Fiecare valoare dintr-o
baz de date relaional trebuie s poat fi adresat n mod logic printr-o
combinaie format din numele relaiei, valoarea cheii primare i numele
atributului.
Regula 4 regula reprezentrii informaiei necunoscute. Un sistem
relaional trebuie s permit utilizatorului definirea unui tip de date numit
null pentru reprezentarea unei informaii necunoscute la momentul
respectiv.
Regula 5 regula dicionarelor de date. Asupra descrierii bazelor de
date (informaii relative la relaii, vizualizri, indeci etc.) trebuie s se
poat aplica aceleai operaii ca i asupra datelor din baza de date.
Regula 6 regula limbajului de interogare. Trebuie s existe cel
puin un limbaj pentru prelucrarea bazei de date.
Regula 7 regula de actualizare a vizualizrii. Un SGBD trebuie s
poat determina dac o vizualizare poate fi actualizat i s stocheze
rezultatul interogrii ntr-un dicionar de tipul unui catalog de sistem.
Regula 8 regula limbajului de nivel nalt. Regulile de prelucrare
asupra unei relaii luat ca ntreg sunt valabile att pentru operaiile de
regsire a datelor, ct i asupra operaiilor de inserare, actualizare i
tergere a datelor.
Regula 9 regula independenei fizice a datelor: Programele de
aplicaie i activitile utilizatorilor nu depind de modul de depunere a
datelor sau de modul de acces la date.
Regula 10 regula independenei logice a datelor. Programele de
aplicaie trebuie s fie transparente la modificrile de orice tip efectuate
asupra datelor.
Regula 11 regula independenei datelor din punct de vedere al
integritii. Regulile de integritate trebuie s fie definite ntr-un sublimbaj
relaional, nu n programul de aplicaie.

38

Regula 12 regula independenei datelor din punct de vedere al

distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reea de
comunicaii de date, nu trebuie s afecteze programele de aplicaie.
Regula 13 regula versiunii procedurale a unui SGBD. Orice
component procedural a unui SGBD trebuie s respecte aceleai
restricii de integritate ca i componenta relaional.
Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de
un SGBD operaional, s-au formulat criterii minimale de definire a unui
sistem de gestiune relaional.
Un SGBD este minimal relaional dac:
toate datele din cadrul bazei sunt reprezentate prin valori n tabele;
nu exist pointeri observabili de ctre utilizator;
sistemul suport operatorii relaionali de proiecie, selecie i
compunere natural, fr limitri impuse din considerente interne.
Un SGBD este complet relaional dac este minimal relaional i
satisface n plus condiiile:
sistemul suport restriciile de integritate de baz (unicitatea cheii
primare, constrngerile refereniale, integritatea entitii).
sistemul suport toate operaiile de baz ale algebrei relaionale.

NORMALIZAREA RELAIILOR
n procesul modelrii unei baze de date relaionale, o etap important
o reprezint normalizarea relaiilor conceptuale (Codd, 1972), adic
obinerea de relaii molecularefr a pierde nimic din informaie pentru a
elimina:
redundana;

anomaliile reactualizrii informaiilor.

Tehnica normalizrii permite obinerea unei scheme conceptuale

rafinate printr-un proces de ameliorare progresiv a unei scheme conceptuale
iniiale a bazei de date relaionale. Dup fiecare etap de ameliorare, relaiile
bazei de date ating un anumit grad de perfeciune, deci se afl ntr-o anumit
form normal. Trecerea unei relaii dintr-o form normal n alta, presupune
eliminarea unei anumit tip de dependene nedorite, care sunt transformate n
dependene admisibile, adic dependene care nu provoac anomalii.

39

Procesul de ameliorare a schemei conceptuale trebuie:

s garanteze conservarea datelor, adic n schema conceptual

final trebuie s figureze toate datele din cadrul schemei iniiale;

s garanteze conservarea dependenelor dintre date, adic n

schema final fiecare dependen trebuie s aib determinantul i
determinatul n schema aceleiai relaii;

s reprezinte o descompunere minimal a relaiilor iniiale,

adic nici una din relaiile care compun schema final nu trebuie
s fie coninut ntr-o alt relaie din aceast schem.

Exist dou metode pentru a modela baze de date relaionale fr

anomalii sau pierderi de informaie.
Schema descompunerii pleac de la o schem relaional
universal ce conine toate atributele BD. Schema se descompune
prin proiecii succesive n subrelaii. Descompunerea se oprete
cnd continuarea ei ar duce la pierderi de informaie. Algoritmii
de descompunere se bazeaz, n general, pe descrierea formal a
dependenei dintre atribute.

Schema sintezei pleac de la o mulime de atribute

independente. Utiliznd proprieti de semantic i legturi ntre
atribute se pot compune noi relaii, astfel nct, acestea s nu
sufere de anumite anomalii. Algoritmii se bazeaz, n general, pe
teoria grafurilor pentru a reprezenta legtura ntre atribute.

Dependene funcionale
O relaie universal este o relaie ce grupeaz toate atributele care
modeleaz sistemul real cercetat. Fie E, mulimea dependenelor
considerate de proiectantul bazei pentru o schem relaional sau pentru o
relaie universal. Plecnd de la o mulime de proprieti formale ale
dependenelor, proprieti considerate drept reguli de deducie (axiome),
poate fi obinut mulimea maximal de dependene asociate lui E. Aceast
mulime definete nchiderea lui E.
Fie E mulimea dependenelor unei relaii i p1, p2, ..., pr, r 1,
proprieti formale ale acestor dependene. Dac exist o mulime E, astfel
nct orice dependen a mulimii E este derivabil din E prin aplicarea
proprietilor p1, p2, ..., pr, atunci mulimea E definete acoperirea lui E
pentru proprietile p1, p2, ..., pr.
E este o acoperire minimal pentru E, dac nu exist nici o
submulime proprie, nevid a lui E care s fie o acoperire pentru E.

40

Evident, E i E au nchideri identice, deci dispun de acelai potenial

informaional!
Fie R(A1, A2, ..., An) o schem relaional i fie X, Y submulimi de
atribute ale lui R. X determin funcional Y sau Y depinde funcional (FD)
de X, dac pentru orice relaie r (valoare curent a lui R) nu exist dou
tupluri care s aib aceleai valori pentru atributele lui X i s aib valori
diferite pentru cel puin un atribut din Y. Cu alte cuvinte, o valoare a lui X,
determin unic o valoare a lui Y.
Notaia utilizat pentru desemnarea dependenei funcionale este X
Y. X este numit determinant, iar Y este numit determinat (sau
dependent). Dependena funcional X Y este trivial dac Y X.
Comparnd toate submulimile de atribute ale unei relaii i
determinnd legturile dintre ele, se pot obine toate dependenele
funcionale pe care o relaie le satisface. Aceast abordare nu este eficient,
consumnd mult timp.
Exist posibilitatea ca, tiind anumite dependene funcionale i
utiliznd reguli de deducie, s fie obinute toate dependenele funcionale.
Fie X, Y, Z, W mulimi de atribute ale unei scheme relaionale R i fie
urmtoarele axiome:
Ax1 reflexivitate. X X. Mai general, dac Y X, atunci X Y.
Ax2 creterea determinantului. Pot fi considerate urmtoarele
formulri echivalente pentru aceast axiom.
1.

Dac X Y i X Z, atunci Z Y.

2.

Dac X Y i W Z, atunci X Z Y W.

3.

Dac X Y atunci X Z Y Z.

4.

Dac X Y atunci X Z Y.

Ax3 tranzitivitate. Dac X Y i Y Z, atunci X Z.

O mulime de axiome este complet dac i numai dac plecnd de
la o mulime de dependene E se pot obine toate dependenele nchiderii
lui E, utiliznd axiomele mulimii.
O mulime de axiome este nchis dac i numai dac plecnd de la
o mulime de dependene E, nu poate fi dedus cu ajutorul axiomelor o
dependen care nu aparine nchiderii lui E. (nu obin altele!)
Ullman a demonstrat c axiomele Ax1 Ax3, numite axiomele lui
Amstrong, reprezint o mulime nchis i complet de axiome. Consecina

41

acestui rezultat este c nchiderea lui E reprezint mulimea

dependenelor deduse din E, prin aplicarea axiomelor lui Amstrong!!!
Nu toate dependenele funcionale sunt folositoare pentru modelarea
relaional. O dependen funcional X Y se numete dependen
funcional total (FT), dac i numai dac nu exist nici o submulime
proprie X X, astfel nct X Y. Dac exist o submulime proprie X
X, astfel nct X Y, atunci dependena funcional X Y este parial.
n axioma Ax2, dependena Z Y este o dependen funcional parial.
n cazul dependenei funcionale totale, axiomele lui Amstrong se
reduc la o axiom unic i anume pseudo-tranzitivitatea:
dac X Y i W Y Z, atunci W X Z.
Aceast axiom este o regul de deducie complet pentru total
dependene:

pseudo-tranzitivitatea implic tranzitivitatea (W = );

reflexivitatea nu poate fi utilizat pentru a obine dependene
totale;
reflexivitatea i pseudo-tranzitivitatea implic creterea.

Dac F este o mulime de dependene funcionale totale, atunci

nchiderea pseudo-tranzitiv F+ a acestei mulimi este reuniunea
mulimilor dependenelor funcionale totale care pot fi obinute din F
folosind axioma de pseudo-tranzitivitate.
Dou mulimi de dependene funcionale totale sunt echivalente
dac au nchideri pseudo-tranzitive identice. Pentru a modela scheme
relaionale se consider mulimi minimale de dependene funcionale totale,
capabile s genereze toate nchiderile pseudo-tranzitive. Aceste mulimi
definesc acoperiri minimale.
O mulime de dependene funcionale totale F* asociat unei mulimi
de atribute A definete o acoperire minimal dac satisface urmtoarele
proprieti:
nici o dependen funcional din F* nu este redundant;
toate dependenele funcionale totale ntre submulimi ale lui A
sunt n nchiderea pseudo-tranzitiv a lui F*.
Orice mulime de dependene totale are cel puin o acoperire minimal.
Alegerea acoperirii minimale este punctul de start n modelarea schemelor
relaionale.

42

Dependenele funcionale ntre atributele bazei pot fi reprezentate

grafic. Fie A = {A1, A2, ..., An} o mulime de atribute i fie o mulime de
dependene funcionale {Xi Aj}, unde Xi este o submulime a lui A.
Graful dependenelor funcionale este un graf direcionat bipartit,
definit astfel:
1. pentru fiecare atribut Aj exist un singur nod avnd eticheta Aj;
2.
3.

pentru fiecare dependen funcional de forma Ai Aj, exist un

arc de la Ai la Aj;
pentru fiecare dependen funcional de forma Xi Aj, unde
mulimea Xi este definit de Xi = {Ai1, ..., Aip} cu p > 1, exist un
nod auxiliar etichetat prin Xi i o mulime de arce plecnd de la
Ai1, ..., Aip pentru a obine pe Xi i printr-un arc adiional de la Xi la
Aj. Nodurile Xi se reprezint prin dreptunghiuri.

Exemplu:
1. Graful dependenelor funcionale pentru schema relaional
CONSUMATOR_DE_VIN(W#, localitate, varsta, calitate, regiune, tara, D#,
nume, data, cantitate) i acoperirea minimal.
localitate
W#
calitate
varsta
regiune
tara
data

cantitate

D#
nume
localitate
W#
calitate
varsta

43

regiune
tara
data

cantitate

D#
nume

2. Graful dependenelor funcionale pentru schema relaional

OBIECTIV_INVESTITIE. Dependentele sunt deduse din regulile impuse de
beneficiar!
aria_construita
denumire
nr_certificat_urbanizare
cod_obiectiv#

adresa
nr_contract

nr_aut_construtie
cod_contractant

Necesitatea normalizrii
Anomaliile care apar n lucrul cu baza de date se produc datorit
dependenelor care exist ntre datele din cadrul relaiilor bazei de date.
Dependenele sunt plasate greit n tabele!!!
Avion
A#
1
2
3
4
5
6

nume
AIRBUS
AIRBUS
AIRBUS
CAR
B707
B707

capacitate
250
250
250
100
150
150

localitate
PARIS
PARIS
LONDRA
PARIS
LONDRA
LONDRA

Constrngere:
toate avioanele cu acelai nume au aceeai capacitate.
Datorit dependenei introduse pot exista: anomalii la inserare,
modificare sau tergere, redundan n date, probleme de reconexiune.

44

1.
2.

3.

4.

5.

Redundan logic. Cuplul (AIRBUS, 250) apare de trei ori.

Anomalie la inserie. S-a cumprat un B727 cu 150 locuri. El
poate fi inserat n relaia AVION doar dac se definete o nou
valoare pentru cheia primar.
Anomalie la tergere. Dac este tears nregistrarea pentru care
A# este 4, atunci se pierde informaia c un avion CAR are
capacitatea 100.
Anomalie la modificare. Dac se modific capacitatea lui B707
de la 150 la 170, atunci costul modificrii este mare pentru a
modifica toate nregistrrile, iar dac se modific doar o
nregistrare atunci constrngerea nu va mai fi verificat.
Problema reconexiunii. Considerm schemele relaionale:
AVION1 = PROJECT(AVION, A#, nume)
AVION22 = PROJECT(AVION, nume, capacitate, localitate)
AVION3 = JOIN(AVION1, AVION2).
Se observ c schema AVION3 este diferit de AVION.
Apare un tuplu nou: (3, AIRBUS, 250, PARIS).

Anomaliile au aprut datorit dependenei funcionale (constrngerii)

introduse anterior!!!
Normalizarea are drept scop:

suprimarea redundanei logice,

evitarea anomaliilor la reactualizare,

rezolvarea problemei reconexiunii.

Exist o teorie matematic a normalizrii al crei autor este E.F.

Codd. Soluia: construirea unor tabele standard (forme normale).
Normalizarea este procesul reversibil de transformare a unei relaii, n
relaii de structur mai simpl. Procesul este reversibil n sensul c nici o
informaie nu este pierdut n timpul transformrii. O relaie este ntr-o form
normal particular dac ea satisface o mulime specificat de constrngeri.
Procesul normalizrii se realizeaz plecnd de la o relaie universal ce
conine toate atributele sistemului de modelat, plus o mulime de anomalii.
Orice form normal se obine aplicnd o schem de descompunere. Exist
dou tipuri de descompuneri.

Descompuneri
ce
conserv
dependenele.
Aceast
descompunere presupune desfacerea relaiei R n proieciile R1,
R2, ..., Rk, astfel nct dependenele lui R sunt echivalente (au

45

nchideri pseudo-tranzitive identice) cu reuniunea dependenelor

lui R1, R2, ..., Rk.

Descompuneri fr pierderi de informaie (L-join). Aceast

descompunere presupune desfacerea relaiei R ntr-o mulime de
proiecii R1, R2, ..., Rj, astfel nct pentru orice realizare a lui R
este adevrat relaia:
R = JOIN(B1 (R), B2 (R), ...,Bj (R))

unde, pentru 1 k j, Bk reprezint mulimea atributelor corespunztoare

proieciei Rk (Rk = Bk (R)). Prin urmare, relaia iniial poate fi reconstruit
considernd compunerea natural a relaiilor obinute prin descompunere.
Formele normale sunt obinute prin descompuneri fr pierderi de
informaie.
O descompunere fr pierdere de informaie, utilizat n procesul
normalizrii, este dat de regula Casey-Delobel:
Fie R(A) o schem relaional i fie , , o partiie a lui A.
Presupunem c determin funcional pe . Atunci:
R(A) = JOIN((R), (R)).
mulimea atributelor care intervin n dependenele funcionale;
reprezint reuniunea determinantului cu restul atributelor lui A.
Relatia universala
FN1
FN2
FN3

BCNF
FN4

FN5

Pentru exemplul analizat anterior:

= {nume},
= {capacitate},
= {A#, localitate}.
Aplicnd Casey-Delobel se obin schemele:
AVION1(nume#, capacitate)
AVION2)A#, nume, localitate).

46

Se observ c anomaliile comentate au disprut!

AVION1
Nume
AIRBUS
CAR
B707

Capacitate
150
100
150

AVION2
A#
Nume
1
AIRBUS
2
AIRBUS
3
AIRBUS
4
CAR
5
B707
6
B707

Localitate
PARIS
PARIS
LONDRA
PARIS
LONDRA
LONDRA

Forma normal (FN1)

O relaie este n prima form normal dac fiecrui atribut care o
compune i corespunde o valoare indivizibil (atomic).
Exemplu: variante pentru a implementa FN1 pentru tabelul MASINA:
Persoana

Vehicul

Eu

R25 - W14 - R21

Tu

205

El

R5 - 305

noi

BX - 305 - R12 - R25

Varianta 1
Persoana
Eu
Eu
Eu
Tu
El
El
Noi
Noi
Noi
Noi

Vehicul
R25
W14
R21
205
R5
305
BX
305
R12
R25

47

Varianta 2
Persoana

Prima

Doi

Trei

Eu

R25

W14

R21

Tu

205

El

R5

305

Noi

BX

305

R12

Patru

R25

Varianta 3 (4 tabele)
Masina 31 (similar se definesc Masina_32, Masina_33, Masina_34)..
Persoana

Vehicul

Eu

R25

Tu

205

El

R5

Noi

BX

Masina_34
Persoana

Vehicul

Noi

R25

Forma normal 2 (FN2)

O relaie R este n a doua form normal dac i numai dac:

relaia R este n FN1;

fiecare atribut care nu este cheie (nu particip la cheia primar)

este dependent de ntreaga cheie primar.

atasat_la
Cod_salariat#
S1
S1
S1
S3
S5

Job_cod
Programator
Programator
Programator
Vanzator
Inginer

Nr_proiect#
P1
P2
P3
P3
P3

Nr_proiect#
P1
P2
P3
P3

Functia
Supervizor
Cercetator
Auxiliar
Supervizor

Functia
Supervizor
Cercetator
Auxiliar
Supervizor
Supervizor

atasat_2a
Cod_salariat#
S1
S1
S1
S3

Suma
60
25
10
60

Suma
60
25
10
60
60

48

S5

P3

Supervizor

60

atasat_2b
Cod_salariat#
S1
S3
S5

Job_cod
Programator
Vanzator
Inginer

A doua condiie exprim necesitatea total dependenei de cheia

primar. Aceast form normal interzice manifestarea unor dependene
funcionale pariale n cadrul relaiei R!!!
Pentru a obine o relaie FN2 se poate aplica regula Casey-Delobel.
Fie relaia R(K1, K2, X, Y), unde K1 i K2 definesc cheia primar, iar X i Y
sunt mulimi de atribute, astfel nct K1 X. Din cauza dependenei
funcionale K1 X care arat c R nu este n FN2, se nlocuiete R (fr
pierdere de informaie) prin dou proiecii R1(K1, K2, Y) i R2(K1, X).
K1

K2

Exemplu. Presupunem c un antier poate executa mai multe lucrri

de baz i c o lucrare poate fi executat de mai multe antiere.
LUCRARE(cod_obiectiv#, cod_lucrare#, nume);
SANTIER(nr_santier#, specialitate, sef);
EXECUTA(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere,
functie, conducator, data_inceput, data_sfarsit).
Pentru relaia EXECUTA sunt evidente dependenele:
{cod_obiectiv#, cod_lucrare#} {data_inceput, data_sfarsit},
{cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere, functie,
conducator}.

49

Relaia EXECUTA este n FN1, dar nu este n FN2 deoarece

atributele data_inceput i data_sfarsit nu depind de numrul antierului,
deci nu depind de ntreaga cheie primar. Pentru a obine o relaie n FN2
se aplic regula Casey Delobel i relaia EXECUTA se desface n:
EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere,
functie, conducator)
EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_inceput,
data_sfarsit).

Forma normal 3 (FN3)

Intuitiv, o relaie R este n a treia form normal dac i numai dac:

relaia R este n FN2;

fiecare atribut care nu este cheie (nu particip la o cheie) depinde

direct de cheia primar.

Fie R o relaie, X o submulime de atribute ale lui R i A un atribut al

relaiei R. A este dependent tranzitiv de X dac exist Y astfel nct X Y
i Y A (A nu aparine lui Y i Y nu determin pe X). X nu este dependent
funcional de Y sau A!
De exemplu, dac K1, K2, K3 A1 i dac K1, K2, A1 A2, atunci
K1, K2, K3 K1, K2, A1 i K1, K2, A1 A2. Prin urmare, A2 este dependent
tranzitiv de K1, K2, K3.
Formal, o relaie R este n a treia form normal dac i numai dac:

relaia R este n FN2;

fiecare atribut care nu este cheie (nu particip la o cheie) nu este

dependent tranzitiv de nici o cheie a lui R.

O relaie este n FN3 dac i numai dac fiecare atribut (coloan)

care nu este cheie, depinde de cheie, de ntreaga cheie i numai de cheie.
Pentru a obine o relaie FN3 se poate aplica regula Casey-Delobel.
Fie relaia R(K, X1, X2, X3), unde atributul X2 depinde tranzitiv de K,
iar K este cheia primar a lui R. Presupunem c K X1 X2. Din cauza
dependenei funcionale X1 X2 care arat c R nu este n FN3, se
nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K, X1, X3)
i R2(X1, X2).
K

X1
X3

X2

50

Exemplu: Tabelul atasat_2a nu este in FN3. De ce?

atasat_3a
Cod_salariat#
S1
S1
S1
S3
S5

Nr_proiect#
P1
P2
P3
P3
P3

Functia
Supervizor
Cercetator
Auxiliar
Supervizor
Supervizor

atasat_3b
Functia
Supervizor
Cercetator
Auxiliar

Suma
60
25
10

Exemplu. n tabelul EXECUTA1(cod_obiectiv#, cod_lucrare#,

nr_santier#, descriere, functie, conducator) continu s existe redundan n
date.
Atributul conducator depinde indirect de cheia primar prin
intermediul atributului functie. ntre atributele relaiei exist dependenele:
{cod_obiectiv#, cod_lucrare#, nr_santier#} {descriere},
{cod_obiectiv#, cod_lucrare#, nr_santier#} {functie} {conducator}.
Pentru a aduce relaia EXECUTA_1 n FN3 se aplic regula CaseyDelobel. Relaia se desface, prin eliminarea dependenelor funcionale
tranzitive, n proieciile:
EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_santier#, descriere, functie)
EXECUTA12(functie, conducator).

Schema de sintez pentru obinerea lui FN3

Algoritmul de sintez construiete o acoperire minimal F a
dependenelor funcionale totale. Se elimin atributele i dependenele
funcionale redundante. Mulimea F este partiionat n grupuri Fi, astfel
nct n fiecare grup Fi sunt dependene funcionale care au acelai membru
stng i nu exist dou grupuri avnd acelai membru stng. Fiecare grup Fi
produce o schem FN3. Algoritmul realizeaz o descompunere ce conserv
dependenele.
Algoritm SNF3 (aducerea unei relaii n FN3 prin utilizarea unei
scheme de sintez):

51

1.
2.

3.

4.

5.

6.

Se determin F o acoperire minimal a lui E (mulimea

dependenelor funcionale).
Se descompune mulimea F n grupuri notate Fi, astfel nct n
cadrul fiecrui grup s existe dependene funcionale avnd
aceeai parte stng.
Se determin perechile de chei echivalente (X, Y) n raport cu F
(dou mulimi de atribute X, Y sunt chei echivalente dac n
mulimea de dependene E exist att dependena X Y, ct i
dependenta Y X).
Pentru fiecare pereche de chei echivalente: se identific grupurile
Fi i Fj care conin dependenele funcionale cu partea stng X i
respectiv Y; se formeaz un nou grup de dependene Fi j, care va
conine dependenele funcionale avnd membrul stng (X, Y); se
elimin grupurile Fi i Fj, iar locul lor va fi luat de grupul Fi j.
Se determin o acoperire minimal a lui F, care va include toate
dependenele X Y, unde X i Y sunt chei echivalente (celelalte
dependene sunt redundante).
Se construiesc relaii FN3 (cte o relaie pentru fiecare grup de
dependene funcionale).

Se observ c algoritmul solicit

determinarea unei acoperiri minimale (algoritmii EAR i EDF);
determinarea nchiderii (A + ) unei mulimi de atribute A n raport
cu mulimea de dependene funcionale E (algoritm AIDF).
Determinarea acoperirii minimale presupune eliminarea atributelor i
dependenelor redundante. Acoperirea minimal nu este unic i depinde de
ordinea n care sunt eliminate aceste atribute i dependene redundante.
Algoritm EAR (elimin atributele redundante din determinantul
dependenelor funcionale)
Pentru fiecare dependen funcional din E i pentru fiecare atribut
din partea stng a unei dependene funcionale:
Pas1. Se elimin atributul considerat.
Pas2. Se calculeaz nchiderea prii stngi reduse.
Pas3. Dac nchiderea conine toate atributele din determinantul
dependenei, atunci atributul eliminat la pasul 1 este redundant i rmne
eliminat. n caz contrar, atributul nu este redundant i se reintroduce n
partea stng a dependenei funcionale.

52

Algoritm EDF (elimin dependenele funcionale redundante din E)

Pentru fiecare dependen funcional X Y din E:
Pas1. Se elimin dependena din E.
Pas2. Se calculeaz nchiderea X + , n raport cu mulimea redus de
dependene.
Pas3. Dac Y este inclus n X + , atunci dependena X Y este
redundant i rmne eliminat. n caz contrar, se reintroduce n E.
Algoritm AIDF (determin nchiderea lui A)
Pas1. Se caut dac exist n E dependene X Y pentru care
determinantul X este o submulime a lui A, iar determinatul Y nu este
inclus n A.
Pas2. Pentru fiecare astfel de dependen funcional se adaug
mulimii A atributele care constituie determinatul dependenei.
Pas3. Dac nu mai exist dependene funcionale de tipul de la pasul
1, atunci A + = A.
Exemplu:
Fie dependenele funcionale:
f1: F N;

f2: F P;

F4: P C; f5: P T;

f3: P, F, N U;
f6: C T;

f7: N F.

Pas1 (suprimarea atributelor redundante). Atributul A i este

redundant n dependena funcional A 1 , A 2 , A i , A n Z, dac
dependena funcional A1 , A 2 , A i 1 , A i + 1 A n Z poate fi
generat plecnd de la mulimea iniial de dependene (E) i de la
axiomele considerate.
f1: F N;

f3: P, F, N U sau N, P, F U;

Aplicnd axioma de pseudotranzitivitate se obine:

F, P, F U P, F U
Pas2 (suprimarea dependenelor funcionale redundante).
Dependena funcional f este redundant n E dac E + = (E - f) + , unde E +
reprezint nchiderea lui E.
Se observ c f5 este redundant (poate fi obinut din f4 i f6). La
sfritul etapei se obine:
f1: F N;

f2: F P;

f3: P, F U; P este redundant =>F-->U

53

f4: P C; f6: C T;

f7: N F.

Pas3 (gruparea dependenelor avnd acelai membru stng).

F1 = {f1, f2, f3}; F2 = {f4}; F3 = {f6}; F4 = {f7}
Pas4 (regruparea mulimilor F i si F j dac exist dependene de
forma X Y i Y X, unde X reprezinta partea stanga a dependenei lui
F i i Y este partea stng a dependenei lui F j .
Din F1 i F4 se obine:
G1 = {f1, f2, f3, f7}; G2 = {f4}; G3 = {f6}.
Pas5 (generarea relaiilor FN3).
R1(F#, N, P, U); R2(P#, C); R3(C#, T).
De remarcat: R1 nu este in BCNF! De ce? Exista dependenta N -->F.
Exerciiu:
Presupunem c o parte din activitiile de pe un aeroport sunt
caracterizate de atributele:
A -- numr zbor;
B -- tip avion;
C -- aeroport plecare;
D -- aeroport sosire;
E -- linia aerian;
F -- ora plecrii;
G -- capacitate;
H -- numr locuri rezervate;
I -- data;
J -- tarif;
K -- prestaii la bord.
ntre aceste atribute exist legturi exprimate prin dependenele:
A BEFG
ACDI H
CD J
CDF K
BG
CF ABE
AC D
ABD C
EG B

54

Aplicnd algoritmul de sintez se obin relaiile:

R1(B#, G)
R2(E#, G#, B)
R3(A#, B, E, F)
R4(C#, D#, J)
R5(A#, C#, I#, H)
R6(A, C, D, F, K) n care cheile primare pot s fie oricare dintre:
AD sau AC sau CF.
ncercai s justificai acest rezultat!!!

Forma normal Boyce-Codd (BCNF)

Determinantul este un atribut sau o mulime de atribute
neredundante, care constituie un identificator unic pentru alt atribut sau alt
mulime de atribute ale unei relaii date.
Intuitiv, o relaie R este n forma normal Boyce-Codd dac i
numai dac fiecare determinant este o cheie candidat.
Formal, o relaie R este n forma normal Boyce-Codd dac i
numai dac pentru orice dependen funcional total X A, X este o
cheie (candidat) a lui R.
Regula Casey Delobel pentru R(K1#, K2#, X) presupunnd c exist
dependena: X K2. R1(K1#, X) i R2(X#, K2)
K1

K2

Exemplu:
ADRESA(cod_parsoana#, telefon#, adresa)
cod_persoana

adresa

55

telefon

n dependena adresa telefon se observ c determinantul nu este

o cheie candidat. Relaia ADRESA se desface n:
ADRESA_1(cod_persoana#, adresa);
ADRESA_2(adresa#, telefon).
Relaiile sunt n BCNF, se conserv datele, dar nu se conserv
dependenele (s-a pierdut cod_persoana, telefon adresa).
Exemplu:
Relaia INVESTESTE_IN leag entitile INVESTITOR i
OBIECTIV_INVESTITIE. Ea are schema relaional:
INVESTESTE_IN(cod_contractant#, cod_obiectiv#, nr_contract,
cota_parte). ntre atributele relaiei exist dependenele:
{cod_contractant#, cod_obiectiv#} {nr_contract, cota_parte},
{nr_contract} {cod_obiectiv}.
Se aplic regula Casey-Delobel i se aduce relaia n BCNF.
INVESTESTE_IN_1(cod_obiectiv, nr_contract#);
INVESTESTE_IN_2(cod_contractant#, nr_contract, cota_parte).
Pentru ca o relaie s fie adus n BCNF nu trebuie n mod
obligatoriu s fie n FN3. Se pot aduce n BCNF i relaii aflate n FN1 sau
FN2. Acest lucru este posibil ntruct dependenele funcionale pariale i
cele tranzitive sunt tot dependene noncheie, adic dependene ai cror
determinani nu sunt chei candidat. Presupunem c R este o relaie ce
conine atributele A.
Algoritm TFBCNF (aducerea unei relaii R din FN1 n BCNF)
1. Dac relaia conine cel mult dou atribute, atunci R este n
BCNF i algoritmul s-a terminat.
2. Dac relaia conine mai mult de dou atribute, se consider toate
perechile (X, Y) de atribute distincte din A.
+
3. Se determin A1 , nchiderea mulimii A1 = A {X, Y}.
+
4. Dac pentru orice pereche (X, Y), X A1 atunci relaia R este n
BCNF i algoritmul s-a terminat.
5. n caz contrar (pentru cel puin o pereche (X, Y), X aparine lui
A1+), relaia R nu este n BCNF.

56

6.

Se reduce progresiv schema relaiei i se reia algoritmul,

exploatnd relaia redus. Orice relaie obinut prin reducerea lui
R i care este n BCNF se consider ca fcnd parte din
descompunerea lui R n procesul aducerii sale n BCNF.

Forma normal 4 (FN4)

FN4 elimin redundanele datorate relaiilor m:n, adic datorate
dependenei multiple.
Intuitiv, o relaie R este n a patra form normal dac i numai dac
relaia este n BCNF i nu conine relaii m:n independente.
Fie R o relaie definit pe o mulime de atribute A = {A1, A2, ..., An}
i fie X, Y, Z A. Se spune c X multidetermin pe Z sau c Z este
multidependent de X :
dac pentru fiecare valoare a lui Z n R exist numai o valoare
pentru perechea (X, Y);
dac valoarea lui Z depinde numai de valoarea lui X.
Acest tip de dependen, numit i multivaloare sau multidependen
(MVD) se noteaz prin X Z.
Intuitiv, multidependena reprezint situaia n care valoarea
unui atribut (sau a unei mulimi de atribute) determin o mulime de
valori a altui atribut (sau mulimi de atribute)!!!
Multidependena X Y poate fi gndit ca o regul de deducie:
dac tuplurile <x, y, z> i <x, y, z> sunt n relaie la un moment r, atunci la
momentul r sunt n relaie i tuplurile <x, y, z> i <x, y, z>.
x

y'

z'

x
x

y
y'

z'
z

Orice dependen funcional este o multidependen. Afirmaia

invers nu este adevrat. Dac X Y (FD), atunci pentru oricare dou

57

tupluri <x, y, z> i <x, y, z>, se obine y = y. Prin urmare n relaie apar
tuplurile <x, y, z> i <x, y, z> i deci X Y (MVD).
Fie W, V, X, Y i Z submulimi de atribute ale unei scheme relaionale
R. Fiind dat o mulime T de multidependene exist o mulime complet
de axiome (Ax1Ax8) care permit obinerea tuturor multidependenelor ce
se pot deduce din mulimea T:
Ax1. Dac Y X, atunci X Y.
Ax2. Dac X Y, atunci X Z Y Z.
Ax3. Dac X Y i Y Z, atunci X Z.
Ax4. Dac X Y, atunci X R {X Y}.
Ax5. Dac X Y i V W, atunci W X V Y.
Ax6. Dac X Y i Y Z, atunci X (Z Y).
Ax7. Dac X Y, atunci X Y.
Ax8. Dac X Y, Z W, W Y i Y Z = , atunci X W.
O multidependen elementar este o multidependen care are
pri stngi i drepte minimale (nu exist X X i Y Y a.i. X Y).
Formal, relaia R este n a patra form normal dac i numai dac:
R este n BCNF;
orice dependen multivaloare este o dependen funcional.
O relaie BCNF este n FN4 dac pentru orice multidependen
elementar de forma X Y, X este o supercheie a lui R. Aducerea
relaiilor n FN4 presupune eliminarea dependenelor multivaloare atunci
cnd sunt mai mult de una n cadrul unei relaii.
Regula de descompunere n relaii FN4. Fie R(X, Y, Z) o schem
relaional care nu este n FN4 i fie X Y o multidependen
elementar care nu este de forma CHEIE atribut. Aceast relaie
este descompus prin proiecie n dou relaii:
R = JOIN(XY(R), XZ(R)).
Aplicnd recursiv aceast regul, se obin relaii FN4.
Exemplu. Fie relaia INVESTITIE(cod_contractant#, denumire,
telefon) i presupunem c un investitor poate avea mai multe numere de
telefon i c poate investi n mai multe obiective. ntre atributele relaiei
exist multidependenele:
cod_contractant# denumire;
cod_contractant# telefon.

58

Relaia INVESTITIE este n BCNF. Pentru a aduce relaia n FN4 o

vom descompune prin proiecie n dou relaii:
INVESTITIE_1(cod_contractant#, denumire),
INVESTITIE_2(cod_contractant#, telefon).
INVESTITIE = JOIN(INVESTITIE_1, INVESTITIE_2).

Forma normal 5 (FN5)

FN5 i propune eliminarea redundanelor care apar n relaii m:n
dependente. n general, aceste relaii nu pot fi descompuse. S-a artat c o
relaie de tip 3 este diferit de trei relaii de tip 2. Exist totui o excepie, i
anume, dac relaia este ciclic
Intuitiv, o relaie R este n forma normal 5 dac i numai dac:
1. relaia este n FN4;
2. nu conine dependene ciclice.
Dependena funcional i multidependena permit descompunerea
prin proiecie, fr pierdere de informaie, a unei relaii n dou relaii.
Regulile de descompunere (FN1 FN4) nu dau toate descompunerile
posibile prin proiecie ale unei relaii. Exist relaii care nu pot fi
descompuse n dou relaii dar pot fi descompuse n trei, patru sau mai
multe relaii fr a pierde informaii. Pentru a obine descompuneri L-join
n trei sau mai multe relaii, s-a introdus conceptul de join-dependen sau
dependen la compunere (JD).
Fie {R1, R2, ..., Rp} o mulime de scheme relaionale care nu sunt
disjuncte i a cror reuniune este R.
R satisface join-dependena *{R1, R2, ..., Rp} dac la fiecare moment
al lui R are loc egalitatea:
R = JOIN(1(R), 2(R), ..., p(R))
unde k reprezint mulimea atributelor corespunztoare lui Rk(1 k p).
Join-dependena *{R1, R2, ..., Rp} are loc n R, dac R1, R2, ..., Rp este
o descompunere L-join a lui R. Pentru p = 2 se regsete multidependena.
O join-dependen *{R1, R2, ..., Rp} n care una dintre Ri este chiar R,
definete o join-dependen trivial.
Join-dependena generalizeaz multidependena. ntr-adevr,
multidependena X Y n relaia R(X, Y, Z) (deci i X Z),
corespunde join-dependenei *{X Y, X Z}. Invers, join-dependena
*{R1, R2} corespunde multidependenei R1 R2 R1 (R1 R2).

59

Formal, o relaie R este n FN5 dac i numai dac orice joindependen *{R1, R2, ..., Rp} care are loc n R fie este trivial, fie conine o
supercheie a lui R (adic, o anumit component Ri este o supercheie a lui
R). Cu alte cuvinte, o relaie R este n FN5 dac orice join-dependen
definit pe R este implicat de cheile candidat ale lui R.
ntre mulimile de atribute X, Y i Z din cadrul relaiei R exist o joindependen dac exist multidependene ntre fiecare dintre perechile de
mulimi (X, Y), (Y, Z) i (X, Z).
Aducerea n FN5 prin eliminarea join dependenelor!
Exemplu.
Fie schema R(furnizor, cod_consumabil, cantitate, pret).
Reguli:

un furnizor produce mai multe consumabile;

nu toi furnizorii produc aceleai consumabile;

preul unui consumabil de la un furnizor este variabil i nu

depinde de cantitate.

Furnizor
F1
F2
F2
F2

Cod_consumabil
1
1
1
2

Cantitate
500
100
500
500

Pret
100
80
100
100

Relaia este n FN4, dar exist redundan n date. Relaia se

descompune prin proiecie n:
R1(furnizor#, cod_consumabil#)
R2(furnizor#, cantitate, pret)
R3(cod_consumabil#, cantitate, pret).
S-au eliminat redundanele:
(F2,1) pentru R1;
(F2, 500, 100) pentru R2;
(1, 500, 100) pentru R3.
Se observ c:
JOIN(R1, R2) R;
JOIN(R1, R3) R;
JOIN(R3, R2) R;
JOIN(R1, R2, R3) = JOIN(R1, JOIN(R2, R3)) = R

60

Exist join dependena:

*{R1(furnizor,
cod_consumabil),
R3(cod_consumabil, cantitate, pret)}

R2(furnizor,

cantitate,

pret),

Exemplu.
Fie schema relaional:
EXECUTANT(nr_santier#, cod_obiectiv#, cod_lucrare#, data_inceput,
data_sfarsit). Un antier poate executa mai multe lucrri referitoare la
acelai obiectiv sau poate executa o lucrare pentru un obiectiv n intervale
de timp distincte. Se presupune c mai multe antiere pot executa aceeai
lucrare, n acelai interval de timp sau n intervale de timp distincte.
Relaia, datorit dependenelor formulate anterior, nu este n FN5. Ea
se poate desface prin proiecie n trei relaii:
EX1(nr_santier#, cod_obiectiv#, cod_lucrare#);
EX2(nr_santier#, data_inceput, data_sfarsit);
EX3(cod_obiectiv#, cod_lucrare#, data_inceput, data_sfarsit).
Sunt evidente relaiile:
EXECUTANT JOIN(EX1, EX2),
EXECUTANT JOIN(EX1, EX3),
EXECUTANT JOIN(EX2, EX3),
EXECUTANT = JOIN(JOIN(EX1, EX2), EX3).

Concluzii:
1.

2.

3.

4.

FN1 FN2 elimin redundanele datorate dependenei netotale

a atributelor care nu particip la o cheie, fa de cheile lui R. Se
suprim dependenele funcionale care nu sunt totale.
FN2 FN3 elimin redundanele datorate dependenei
tranzitive. Se suprim dependenele funcionale tranzitive.
FN3 BCNF elimin redundanele datorate dependenei
funcionale. Se suprim dependenele n care partea stng nu
este o supercheie.
BCNF FN4 elimin redundanele datorate multidependenei.
Se suprim toate multidependenele care nu sunt i dependene
funcionale.

61

5.

6.

7.

FN4 FN5 elimin redundanele datorate dependentei. ciclice.

Se suprim toate join-dependenele care nu sunt implicate de o
cheie.
BCNF, FN4 i FN5 corespund la regula c orice determinant este
o cheie, dar de fiecare dat dependena cu care se definete
determinantul este alta i anume dependena funcional,
multidependena sau join-dependena).
Descompunerea unei relaii FN2 n FN3 conserv datele i
dependenele, pe cnd descompunerea unei relaii FN3 n BCNF
i, respectiv, a unei relaii BCNF n FN4 conserv doar datele.

Cateva observaii i concluzii

PROIECTAREA BAZELOR DE DATE

referitoare

la

Proiectarea conceptual a bazei de date -- construirea

reprezentrii conceptuale a bazei de date, care include identificarea tipurilor

importante de entiti, relaii, atribute.
1) identificarea tipurilor de entiti (E);
2) identificarea tipurilor de relaii (R);
3) identificarea i asocierea atributelor (A) cu tipurile de E sau R;
4) determinarea domeniilor atributelor;
5) determinarea atributelor chei candidat i chei primare;
6) specializarea i generalizarea tipurilor de entiti;
7) desenarea diagramei E/R;

8) revizuirea modelului de date conceptual local, mpreun cu

utilizatorul, pentru a garanta c modelul este o reprezentare
corect a punctului de vedere al utilizatorului asupra sistemului
real analizat.

Proiectarea logic a bazei de date -- transpunerea reprezentrii

conceptuale n structura logic a BD, care include proiectarea relaiilor.

1) transpunerea modelului conceptual local n modelul de date logic

local:

62

eliminarea relaiilor M:N (nlocuirea prin relaii de tip 1:M sau

prin tabele asociative);
eliminarea relaiilor complexe (nlocuirea prin relaii de tip
1:M);
eliminarea relaiilor recursive (nlocuirea prin relaii
dependente);
eliminarea atributelor multiple (nlocuirea prin relaii
dependente;
reexaminarea relaiilor 1:1 (sunt ntr-adevr 2 relaii distincte?);
eliminarea relaiilor redundante.

2) extragerea relaiilor din modelul de date logic local pentru a

reprezenta entitile i relaiile (legturile);
3) normalizarea relaiilor;
4) validarea modelului conform tranzaciilor utilizatorului pentru a
garanta c acesta accept i rezolv operaiile cerute de ctre
model (se verific faptul c modelul furnizeaz toate informaiile
cerute de fiecare tranzacie i se reprezint schematic calea
urmat de fiecare tranzacie, direct n diagrama E/R);
5) desenarea diagramei conceptuale;
6) definirea constrngerilor de integritate;
7) revizuirea modelului de date conceptual local, mpreun cu
utilizatorii;
8) construirea i validarea modelului de date logic global prin
combinarea modelelor locale:
mbinarea modelelor locale (revizuirea E, R, A, CP, CE,
constrngeri, revizuirea denumirilor, cutarea entitilor i
relaiilor care lipsesc, reactualizarea documentaiei);
normalizarea modelului;
validarea modelului conform tranzaciilor utilizatorului;
verificarea n vederea dezvoltrii ulterioare;
desenarea diagramei conceptuale finale;
revizuirea modelului de date conceptual global, mpreun cu
utilizatorii.
Modaliti pentru asigurarea integritii refeniale!!!
Se specific constrngeri de existen care definesc condiiile n care
o cheie candidat sau o cheie extern poate fi inserat, tears sau
reactualizat.

63

Exemplu: DOMENIU_contine_CARTE (1:M)

1) Inserare n relaia "copil" (carte) - se verific dac domeniul crii
inserate este null sau corespunde unui domeniu existent.
2) tergerea n relaia "copil" (fr probleme).
3) Reactualizarea n relaia "copil" (similar cazului 1).
4) Inserarea n relaia "printe" (domeniu) se face fr probleme.
5) Reactualizarea cheii primare n relaia "printe" (dac exist o
apariie n tabelul "copil" care face referin la vechea valoare a
cheii, atunci se pierde integritatea refenial). Se pot aplica
strategii pentru a asigura integritatea refenial (vezi 6).
6) tergerea unei apariii din relaia "printe" (se pierde integritatea
referenial dac se terge un domeniu de carte, dar exist cel
puin o carte din domeniul respectiv). Exist 5 strategii care pot fi
luate n considerare.
NO ACTION (nici o aciune)- nu se poate terge un domeniu
dac exist o carte n domeniul respectiv;
CASCADE - se terge domeniul i automat se terg toate crile
din domeniu .a.m.d.;
SET NULL - se terge domeniul, iar toate criile din domeniul
respectiv vor avea codul domeniului setat null;
SET DEFAULT - setare la o valoare prestabilit;
NO CHECK - cnd este ters un domeniu de carte, nu se face
nimic pentru a garanta c integritatea refenial este meninut
(nici o verificare).
Proiectarea fizic a bazei de date -- implementarea fizic a structurii
logice ntr-o capacitate de stocare secundar corespunztoare SGBD-ului
int. Se descriu structurile de stocare i metodele de acces utilizate pentru
realizarea unui acces eficient la date.
1) Transformarea relaiilor extrase din modelul de date logic global
ntr-o form care s poat fi implementat n SGBD-ul relaional
int (LDD).
2) Proiectarea (definirea) constrngerilor sistemului real modelat n
SGBD-ul int (CONSTRAINT, declanatori).
3) Proiectarea reprezentrii fizice - determinarea organizrii
fiierelor i a metodelor de acces (indeci) care vor fi utilizate
pentru a stoca relaiile de baz (modul n care relaiile i tuplurile
vor fi pstrate n cadrul capacitii de stocare secundare).

64

4) Introducerea unei redundane controlate (denormalizarea).

5) Estimarea necesarului de spaiu pe disc cerut de baza de date.
6) Proiectarea mecanismelor de securitate:
proiectarea vizualizrilor (VIEW);
proiectarea regulilor de acces la relaiile de baz i la vizualizri
(privilegii, role-uri).
7) Monitorizarea nentrerupt i reglarea sistemului operaional
pentru obinerea unor performane maxime (micorarea
configuraiei hardware, timpi de rspuns mai sczui, transfer
eficient etc.).
Comentm pasul 4 referitor la considerarea introducerii unei
redundane controlate (denormalizare). NU exist reguli fixe!!! Pasul 4
presupune:
considerarea datelor derivate (calculate);
considerarea dublrii atributelor i gruprii relaiilor.
Considerarea datelor derivate
De exemplu, n relaia PROPRIETATE_DE INCHIRIAT apare drept
cmp, codul persoanei care a tranzacionat nchirierea. Prin urmare, s-ar
putea calcula pentru fiecare angajat, cte proprieti a nchiriat SAU se poate
introduce n tabelul PERSONAL, un cmp calculat (derivat) ce conine
numrul proprietilor nchiriate de acesta.
Considerarea dublrii atributelor i gruprii relaiilor
Dublarea atributelor sau gruparea relaiilor are ca scop reducerea
numrului de join-uri necesare pentru efectuarea unei interogri.
FILIALA (nr_fil#, strada, zona, oras, codpostal, tel, fax)
Relaia nu este n FN3 deoarece codpostal determin funcional
atributele zona i oras. Aplic FN3 i se obine:
FIL(nr_fil#, strada, codpostal, tel, fax
COD_P(zona, oras, codpostal#)
Nu este convenabil, deoarece rareori vom accesa adresa filialei, fr
informaii referitoare la zona i ora. Prin urmare, preferm FN2.
Vom analiza cteva situaii concrete de denormalizare.
combinarea relaiilor de tip 1:1
dublarea atributelor care nu sunt chei n relaii 1:M

65

SELECT
FROM
WHERE

p.*, ptr.nume
proprietate_de_inchiriat p, proprietar ptr
p.nrptr=ptr.nrptr AND nrfil='S3';

Atributul nrptr este codul proprietarului. Dac se va dubla atributul

nume din relaia proprietate_de_inchiriat, atunci interogarea devine:
SELECT
FROM
WHERE

p.*
proprietate_de_inchiriat p
nrfil='S3';

Avantaje sau dejavantaje ?!? Depinde de problemele care pot aprea.

tabele de referin (tabele de cutare)
Acestea conin, de obicei, un cod i o descriere. De exemplu se poate
defini un tabel cutare "printe" pentru tipul de proprietate i modifica
tabelul proprietate_de_inchiriat ("copil") astfel:
TIP_PROPRIETATE(tip, descriere)
PROPRIETATE_DE_INCHIRIAT(nrpte, strada, zona, oras,
coppostal, tipul, nrcamere, chirie, nrptr, nrfiliala, nrpersonal)
Avantaje:
dac este modificat descrierea, atunci se va modifica o singur
dat, n tabelul de cutare;
se reduce dimensiunea relaiei "copil";
dublarea atributelor cheii externe ntr-o relaie de tip 1:M
pentru simplificarea join-urilor
S se enumere proprietarii de proprieti de nchiriat dintr-o filial.
SELECT
FROM
WHERE

ptr.nume
proprietate_de_inchiriat p, proprietar ptr
p.nrptr=ptr.nrptr AND p.nrfil='S3';

Dac se dubleaz cheia extern nrfiliala n relaia PROPRIETAR,

adic se introduce o relaie direct ntre FILIALA i PERSONAL, atunci
cererea devine:
SELECT
FROM
WHERE

p.nume
proprietar p
nrfil='S3';

ATENIE! Sunt necesare constrngeri suplimentare asupra cheilor

externe. De exemplu, dac un proprietar ar nchiria prin mai multe filiale
(atribut multiplu), atunci modificrile nu mai sunt valabile.
De remarcat c singurul motiv pentru care relaia
proprietate_de_inchiriat conine atributul nrfiliala const n faptul c este

66

posibil ca o proprietate s nu aib alocat un membru de personal, mai ales la

nceput, cnd este preluat iniial de ctre agenie.
Dublarea atributelor n relaiile de tip M:N, pentru reducerea
join-urilor.
Presupunem c relaia M:N dintre chirias i proprietate_de_inchiriat
a fost descompus prin introducerea relaiei intermediare VIZITARE.
Care sunt chiriaii care au vizitat proprieti, dar mai au de fcut
comentarii asupra uneia dintre ele? Personalul de la agenie are nevoie de
atributul strada atunci cnd vorbete cu chiriaii.
SELECT
FROM

p.strada, c.*, v.data

chirias c, vizitare v, proprietate_de_inchiriat p

WHERE v.nrpte = p.nrpte

AND c.nrch = v.nrch AND comentarii IS NULL;
Atributul nrpte este codul proprietii, iar nrch este codul chiriaului.
Dac se introduce atributul strada n relaia VIZITARE, atunci
cererea devine:
SELECT
FROM
WHERE

v.strada, c.*, v.data

chirias c, vizitare v
c.nrch = v.nrch AND comentarii IS NULL;

Comentm pasul 3! Proiectarea reprezentrii fizice

Scopul este de a stoca datele n mod eficient. Pentru msurarea
eficienei poate fi analizat:
capacitatea de stocare pe disc;
timpul de rspuns;
transferul de tranzacii (numrul de tranzacii care pot fi efectuate
ntr-un anumit interval de timp).
Pentru mbuntirea performanelor trebuie ca proiectantul s
cunoasc cum interacioneaz cele 4 componente hardware (memoria
principal, CPU, discul I/O, reeaua) i modul cum acestea afecteaz
performanele sistemului.
Principiile de baz ale distribuirii datelor pe unitile de disc:
fiierele sistemului de operare s fie separate de cele ale BD;
fiierele principale ale BD s fie separate de fiierele de indexare;
fiierul jurnalului de recuperare s fie separat de restul BD.
n aceast etap se face i analizarea tranzaciilor, adic cunoaterea
funcionalitii acestora i analizarea celor mai importante dintre acestea.

67

Pentru fiecare tranzacie trebuie detrminat:

frecvena estimat cu care va fi rulat;
relaiile i atributele accesate;
tipul de acces (inserare, interogare, tergere sau rectualizare);
atributele care apar n predicate (condiii);
atributele care apar n join-uri;
constrngerile de timp impuse tranzaciilor.

Limbaje pentru prelucrarea datelor relaionale

Unul dintre cele mai mari merite ale modelului relaional este c prin
intermediul multiplelor sale limbaje de interogare (neprocedurale) permite
utilizatorului, chiar i neinformatician, s indice rezultatul care l
intereseaz, fr a preciza modul n care este obinut acest rezultat.
O relaie poate fi definit ca o mulime, sau ca un predicat. Conform
dualitii definiiei unei relaii, limbajele de prelucrare a datelor relaionale
pot fi grupate n:

limbaje algebrice - bazate pe teoria mulimilor (SEQUEL, SQL);

limbaje predicative - fondate pe calculul predicatelor.

Limbajele predicative pot fi:

orientate pe tupluri (QUEL, ALPHA);
orientate pe domenii (pot fi non-grafice (ILL, FQL) sau grafice).
Limbajele grafice pot fi:

cu variabile domeniu explicite (QBE);

fr variabile domeniu explicite (LAGRIF, CUPID, VGQF).

SQL este limbajul standard de descriere a datelor i acces la

informaiile din baza de date. SQL nu este un limbaj unic (cu excepia
standardului care este puin utilizat), existnd peste o 100 de dialecte. Au
fost concepute i dezvoltate diferite versiuni ale standardului SQL de ctre

68

ANSI, IBM, Microsoft, Borland, etc. Din pcate, lipsa unui standard unic
SQL are drept consecine creterea costurilor programelor de gestiune a
bazelor de date i ngreunarea ntreinerii arhitecturilor client/server.
Un grup de specialiti n baze de date s-au reunit sub numele SAG
(SQL Access Group) cu scopul de a construi un limbaj SQL comun i de a
realiza pentru fiecare dialect un program de conversie din dialect n SQL, i
invers.
Rezultatul a fost c n:

1992, Microsoft a lansat ODBC (Open Database Connectivity)

care este o mulime de primitive bazate pe activitatea lui SAG;

1994 Borland a lansat IDAPI (Integrated Database Application

Programming Interface) care este o bibliotec de funcii SQL ce
se pot integra ntr-un program gazd.

Limbaje algebrice
n abordarea algebric, o relaie este considerat ca o mulime de
tupluri, iar o baz de date este considerat ca o mulime de relaii pe care
sunt definii operatorii algebrici.
Exist dou tipuri de operatori algebrici: mulime (intersecie,
reuniune, diferen, produs cartezian) i relaionali (proiecie, selecie,
diviziune, compunere). Operatorii selecie, proiecie, produs cartezian,
reuniune i diferen sunt ireductibili i sunt considerai drept operatori de
baz, iar operatorii intersecie, diviziune i compunere pot fi dedui din
operatorii anteriori i sunt considerai operatori derivai.
Operatorii limbajului algebric permit exprimarea unor cereri
nerecursive. Dac cererea este recursiv este necesar un operator special i
anume nchiderea tranzitiv a unei relaii.

SEQUEL (Structured English as a Query Language) este un

limbaj algebric definit pentru prototipul relaional SYSTEMR. Operaia

fundamental a limbajului este SELECT, care are forma general clasic.
Operatorii clasici UNION, INTERSECTION, DIFFERENCE i
INCLUSION sunt implementai n limbaj. SEQUEL este singurul limbaj
relaional care are integrat nchiderea tranzitiv. Limbajul permite
reactualizri asupra bazelor (UPDATE, INSERT, DELETE) i calculul
unor funcii elementare (COUNT, SUM, AVG, MAX, MIN). Conceptul de
partiionare a fost de asemenea introdus n SEQUEL i realizat cu ajutorul
clauzelor GROUP BY i HAVING.
O extensie comercial a acestui limbaj, adoptat de aproape toate
SGBD i considerat drept standard n prelucrarea datelor relaionale, este
SQL.

69

Limbaje predicative
Limbajele predicative se bazeaz pe calculul predicatelor. Cererile
sunt exprimate sub forma unor mulimi de tupluri sau valori pentru care se
specific, sub forma unor predicate, proprietile pe care trebuie s le
ndeplineasc.

QUEL este un limbaj predicativ orientat pe tupluri, utilizat de

sistemul INGRES. Limbajul QUEL poate fi utilizat independent sau inclus
n limbajul de programare C. Limbajul este caracterizat de:
declararea unei variabile tuplu pentru fiecare relaie (prin
RANGE),
absena cuantificatorilor n expresii,
utilizarea unor operatori speciali pe mulimi,
integrarea operaiilor aritmetice.
Exemplu.
S se listeze numele cititorilor care au mprumutat cri scrise de
Cioran.
RANGE OF a IS carte
RANGE OF b IS cititor
RANGE OF v IS imprumuta
RETRIEVE b.nume
WHERE (b.codec = v.codec)
AND (v.codel = a.codel)
AND (a.autor = Cioran)
Limbajul accept comenzi de inserare (APPEND), reactualizare
(REPLACE), suprimare (DELETE), precum i funcii de calcul (MAX, MIN,
SUM, COUNT, AVG). Cuantificatorul existenial este reprezentat implicit
prin declaraia RANGE, iar cuantificatorul universal este simulat cu ajutorul
funciei COUNT.
Exemplu.
S se listeze numele cititorilor care au mprumutat toate crile din
bibliotec scrise de Cioran.
RANGE OF a IS carte
RANGE OF b IS cititor
RANGE OF v IS imprumuta
RETRIEVE b.nume
WHERE
COUNT (v.codel
WHERE (b.codec=v.codec)

70

AND (a.codel=v.codel)
AND (a.autor=Cioran))
=
COUNT (a.codel WHERE (a.autor=Cioran))

QBE (Query By Example) este un limbaj predicativ orientat pe

domenii. Limbajul dispune de primitive de programare grafic a cererilor

de date i a fost conceput pentru utilizatorii neiniiai. Utilizatorii, pentru a
manipula datele, completeaz o mulime de cmpuri predefinite pe un ecran
special.
Exemplu.
S se obin titlurile crilor scrise de Cioran, din care exist n
bibliotec mai mult de 10 exemplare.

Carte Codel

Titlu
P.X

Autor
'Cioran'

Pret

Nrex
>10

Coded

Dac utilizatorul dorete i tiprirea, atunci indic rezultatul care l

intereseaz sub forma unei variabile domeniu (notat n acest exemplu prin
X) prefixat de P (print).
Dac condiia care apare n interogare este complex sau se dorete
simplificarea scrierii unei cereri, se poate utiliza o caset special (box
condition) n care se introduce condiia.
n limbaj sunt admise funciile COUNT, MAX, MIN, AVG, SUM,
iar pentru eliminarea dublurilor a fost introdus operatorul UNIQUE.
Exemplu.
S se obin pentru fiecare autor, preul celei mai scumpe cri i
numrul exemplarelor scrise de acesta, care s gsesc n bibliotec (tabelul
sortat!!!).
Carte

Codel

Titlu

Autor
GROUP BY

Pret
MAX

Nrex
SUM

Coded

n QBE exist posibilitatea de a crea o nou relaie care poate fi o

schem virtual care reflect modificrile din relaiile de baz sau o
imagine n care modificrile nu sunt stocate.
Exemplu.
Codurile crilor scrise de Popa sau care au titlul Geometrie.

71

Algebric:
R1 = SELECT(carte, autor = 'Popa')
R2 = SELECT(carte, titlu = Geometrie')
R3 = R1 R2
Rezultat = PROJECT (R3, codel)
SEQUEL:
SELECT
FROM
WHERE
OR

codel
carte
autor = Popa
titlu = Geometrie

QBE:
Carte

Codel
Titlu
Autor
Pret Nrex Coded
P.X
'Popa'
P.Y
'Geometrie'
Exemplu.
Numele cititorilor care au mprumutat cel putin o carte scrisa de
Cioran.
Algebric:
R1 = PROJECT(cititor, codec, nume)
R2 = SELECT(carte, autor = 'Cioran')
R3 = PROJECT(R2, codel)
R4 = PROJECT(imprumuta, codel, codec)
R5 = JOIN(R4, R3, codel)
R6 = JOIN(R5, R1, codec)
Rezultat = PROJECT(R6, nume)
QBE:
Cititor

Imprumuta

Codec
Y
Codel
Z

Carte Codel Titlu

Z

Nume
P.X
Codec
Y
Autor
'Cioran'

SEQUEL:
SELECT
FROM
WHERE

nume
cititor
codec IS IN

Dataim

Pret

Dep

Datares

Nrex

Dataef

Coded

72

SELECT
codec
FROM
imprumuta
WHERE
codel IS IN
SELECT
codel
FROM
carte
WHERE
autor = Cioran

Utilizarea limbajelor de prelucrare a datelor relaionale

n contextul limbajelor de programare
Dou abordri:
integrarea,

extensia.

Integrarea LMD-ului ntr-un limbaj de programare.

Se consider limbajul de prelucrare independent de limbajul de
programare i exist construcii speciale care permit utilizarea acestuia n
limbajul gazd. De exemplu, comenzile SQL pot fi integrate n limbajul
PL/1. Ele sunt prefixate de caracterul $ pentru a le distinge de comenzile
PL/1. Pentru a realiza integrarea, este necesar fie o precompilare a
cererilor, fie o interpretare la execuie. Precompilatoarele actuale acoper
majoritatea limbajelor semnificative existente. Alegerea unui precompilator
particular depinde de domeniul aplicaiei.
Extensia limbajului de programare cu un LMD
Se consider un limbaj de programare i se realizeaz extensii ale
acestuia cu clauze specifice limbajelor de prelucrare a datelor.
Un exemplu tipic este extensia PASCAL/R care permite definirea unui
nou tip de date, i anume tipul RELATION. De exemplu, relaia carte este
definit:
TYPE car = RECORD
codel: TEXTE;
titlu: TEXTE;
autor: TEXTE;
nrex: INTEGER;
pret: INTEGER;
coded: TEXTE
END;
abc = RELATION OF car;
VAR carte: abc;

73

Exemplu.
S se obin o relaie avnd numele rezultat, ce conine toate crile
scrise de Cioran care au preul mai mare de 150000.
VAR rezultat: abc;

BEGIN
rezultat:=[];
FOR EACH x IN carte DO
IF(x.autor = Cioran) AND (x.pret >= 150000)
THEN rezultat:=rezultat + [x]
END;
Relaia rezultat poate fi construit i direct prin atribuirea:
rezultat := [EACH (x) IN carte:
(x.autor = Cioran) AND (x.pret >= 150000)];

PROIECTAREA BAZELOR DE DATE

RELAIONALE
3.1. Preliminarii
Modelul relaional a fost conceput i dezvoltat de E.F. Codd. El este
un model formal de organizare conceptual a datelor, destinat reprezentrii
legturilor dintre date, bazat pe teoria matematic a relaiilor. Este modelul
cel mai accesibil pentru utilizatorul bazei de date deoarece structura sa fizic
este aceeai cu cea a datelor care trebuie prelucrate. n general, datele se
prezint sub forma unor tabele (relaii) n care liniile constituie
nregistrri, iar coloanele sunt atribute ce caracterizeaz aceste
nregistrri.
Obiectivele modelului relaional, considerate de ctre E.F. Codd, sunt
urmtoarele:
s permit un grad nalt de independen a datelor;
s furnizeze baze solide pentru tratarea semanticii, coerenei i
problemelor de redundan a datelor;
s permit dezvoltarea limbajelor de prelucrare a datelor.
Spre deosebire de modelul ierarhic i reea unde apar dou elemente,
i anume tipul entitii i relaiile dintre dou entiti, modelul relaional
este alctuit numai din relaii i prin urmare, orice interogare asupra bazei
de date este tot o relaie. Modelul relaional a fost definit cu o deosebit
rigoare matematic, furniznd un mijloc performant de studiu al
proprietilor logice ale unui sistem de baze de date. Referitor la partea de
prelucrare a datelor, modelul relaional este orientat spre mulimi, n timp ce
modelele ierarhic i reea sunt orientate spre fiiere.
Pentru modelele ierarhic i reea, programatorul trebuie s proiecteze
programe care s acceseze baza de date, nregistrare cu nregistrare, utiliznd
legturi fizice ntre nregistrri. Modelul relaional a permis introducerea
unor limbaje neprocedurale de prelucrare a datelor. Modelul relaional nu
este orientat spre sistemul de calcul, deci modelul nu include regulile,
structurile i operaiile referitoare la implementarea fizic a unui sistem de
baze de date. De fapt, unul dintre obiectivele modelului este acela de a face
o distincie ntre aspectele fizice i logice ale unei baze de date
(independena datelor).

Modelul relaional, dei are unele imperfeciuni, a fost adoptat n

ultimele decenii de majoritatea programatorilor din domeniu, tocmai datorit
acestor trei caliti: este simplu, riguros din punct de vedere matematic i nu
este orientat spre sistemul de calcul.
Definirea unui SGBD relaional impune analizarea caracteristicilor pe
care trebuie s le prezinte un model de date pentru a fi considerat relaional.
Exist diferite modaliti pentru a defini acest concept:
prezentarea datelor n tabele supuse anumitor operaii de tip
proiecie, selecie, reuniune, compunere, intersecie etc. (definiie
simpl);
un sistem de baze de date ce suport un limbaj de tip SQL
Structured Query Language (definiie practic);
un sistem de baze de date care respect principiile modelului
relaional introdus de E.F. Codd (definiia folosit cel mai
frecvent).
E.F. Codd a publicat un set de 13 reguli, numite reguli de fidelitate, n
raport cu care un SGBD poate fi apreciat ca relaional. Ulterior, cele 13
reguli de fidelitate ale lui Codd au fost extinse la un numr de 100. Trebuie
remarcat c nu exist un SGBD care respect toate regulile definite de Codd.
Nu trebuie s apreciem un SGBD ca fiind relaional sau nu, ci msura n care
acesta este relaional, deci numrul regulilor de fidelitate pe care le respect.

3.2. Caracterisicile modelului relaional

Dintre principalele caracteristici ale modelului relaional se remarc:
nu exist tupluri identice;
ordinea liniilor i a coloanelor este arbitrar;
articolele unui domeniu sunt omogene;
fiecare coloan definete un domeniu distinct i nu se poate repeta
n cadrul aceleiai relaii;
toate valorile unui domeniu corespunztoare tuturor cazurilor nu
mai pot fi descompuse n alte valori (sunt atomice).
Comparativ cu celelalte modele de date, modelul relaional are
avantaje remarcabile dintre care se remarc:
fundamentarea matematic riguroas,
independena fizic a datelor,
posibilitatea filtrrilor,
2

 existena unor structuri de date simple,

minimizarea redundanei,
supleea n comunicarea cu utilizatorul neinformatician etc.
Ca limite ale modelului relaional pot fi menionate:
rmne totui redundan,
ocup spaiu,
apar fenomene de inconsisten,
nu exist mecanisme pentru tratarea optim a cererilor recursive,
nu lucreaz cu obiecte complexe,
nu exist mijloace perfecionate pentru exprimarea constrngerilor
de integritate,
nu realizeaz gestiunea cunotinelor etc.
Un model relaional este caracterizat de trei elemente:
structura relaional a datelor (caracteristica structural),
operatorii modelului relaional (caracteristica de asigurare a
prelucrrii),
regulile de integritate care guverneaz folosirea cheilor n model
(caracteristica de asigurare a integritii).
Aceste trei elemente corespund celor trei componente ale ingineriei
software: informaie, proces, integritate.
3.2.1. Structura datelor
Conceptelor descrise formal drept relaie, tuplu sau atribut, le
corespund uzual denumirile tabel, linie sau coloan, iar fizic fiier,
nregistrare sau cmp.
Un domeniu este o mulime de valori care se poate defini fie
enumernd elementele componente, fie specificnd o proprietate distinctiv
a valorilor. Domeniului i corespunde, att uzual ct i fizic, conceptul de
tip de date.
Un tip de date este o mulime de valori, i anume mulimea tuturor
valorilor care satisfac o anumit constrngere a tipului. Un tip de date poate
fi definit de ctre sistem sau de ctre utilizator. De asemenea, fiecare tip are
asociat un set de operatori care pot fi aplicai valorilor tipului respectiv.
Tipurile constrng operaiile prin faptul c este necesar ca operanzii unei
operaii s fie de tipurile definite pentru operaia respectiv.

Tipurile pot fi orict de simple sau de complexe. Se pot distinge tipuri

de date ale cror valori sunt numere, iruri, date calendaristice, nregistrri
audio sau video, hri, puncte geometrice etc.
Orice tip de date este scalar (atomic, ncapsulat) sau nescalar. Tipul
nescalar are componente vizibile utilizatorului i direct accesibile.
Trebuie fcut distincia ntre un tip i reprezentarea sa fizic,
deoarece tipurile sunt legate de model, iar reprezentarea fizic este un aspect
legat de implementare.
Fie D1, D2, ..., Dn domenii finite, nu neaprat disjuncte. Produsul
cartezian D1 D2 ... Dn al domeniilor D1, D2, ..., Dn este definit de
mulimea tuplurilor (V1, V2, ..., Vn), unde V1 D1, V2 D2, ..., Vn Dn.
Numrul n definete aritatea tuplului.
O relaie R pe mulimile D1, D2, ..., Dn este o submulime a produsului
cartezian D1 D2 ... Dn, deci este o mulime de tupluri. Exist un alt mod
de a defini relaia, i anume ca o mulime finit de funcii. Asociem fiecrui
domeniu Di un atribut Ai i definim relaia R = {f1, f2, ..., fm}, unde
fi : {A1, A2, ..., An} D1 D2 ... Dn i fi(Aj) Dj pentru orice valori ale
lui i i j. n aceast definiie nu mai este restricionat ordinea.
Definirea unei relaii ca o mulime de tupluri sau ca o mulime de funcii
se refer la mulimi care variaz n timp (se adaug, se terg sau se modific
elemente). Pentru a caracteriza o relaie este necesar existena unui element
invariant n timp, iar acest invariant este dat de structura relaiei (schema
relaional). Mulimea numelor atributelor corespunztoare unei relaii R
definete schema relaional a relaiei respective. Vom nota schema
relaional prin R(A1, A2, ..., An).
De exemplu, pentru modelul de date analizat n aceast lucrare,
VESTIMENTATIE(cod_vestimentatie,
cod_designer,
cod_model,
cod_prezentare, denumire, valoare, descriere) reprezint o schem relaional.
Putem reprezenta o relaie printr-un tabel bidimensional n care fiecare
linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu din
produsul cartezian. O coloan corespunde unui atribut. Numrul atributelor
definete gradul relaiei, iar numrul de tupluri din relaie definete
cardinalitatea relaiei.
Bazele de date relaionale sunt percepute de ctre utilizatori ca o
mulime de tabele. Tabelul reprezint structura logic dintr-un sistem
relaional, nu structura fizic. La nivel fizic, sistemul poate stoca datele n
diferite moduri, folosind fiiere secveniale, indexri, nlnuiri de pointeri etc.,
cu condiia s poat realiza corespondena dintre reprezentarea stocat i
tabelele de la nivelul logic.

Bazele de date relaionale respect principiul informaiei (principiul

reprezentrii uniforme), care afirm c ntregul coninut informaional al bazei
este reprezentat ntr-un mod unic, i anume, ca valori explicite ale celulelor
unui tabel. Aceast modalitate de reprezentare este singura disponibil, la nivel
logic, ntr-un sistem relaional.
Cnd se insereaz tupluri ntr-o relaie, de multe ori valoarea unui
atribut este necunoscut sau nu este aplicabil tuplului respectiv. Pentru a
reprezenta valoarea acestui atribut a fost introdus o valoare convenional
n relaie, i anume null. De fapt, null nu reprezint o valoare, ci absena
uneia. Un null nu este acelai lucru cu o valoare numeric egal cu zero sau
cu un ir de caractere vid. Zerourile i spaiile libere (irul vid) sunt valori,
pe cnd null semnific absena unei valori. Prin urmare, null trebuie tratat n
mod diferit fa de alte valori i trebuie neles c termenul valoare nul
este depreciativ.
Evident, este necesar o aritmetic i o logic (polivalent) nou
(fig.3.1) care s cuprind acest element. De exemplu, ce valoare are 10 >
null ? Rspunsul este null. n general, rezultatul operaiilor aritmetice sau
logice este null cnd unul din operanzi este null. Prin urmare, null = null
are valoarea null, iar null este null.
ntroducerea null-urilor n modelul relaional constituie o problem
controversat, dei Codd trateaz null ca parte integrant a modelului. Alii
consider aceast abordare greit i prematur. Trebuie remarcat c nu toate
sistemele relaionale accept null-urile.
AND

Null

OR

Null

Null

Null

Null

Null F

Null

Null T

Null Null

Fig. 3.1. Tabele de adevr pentru operatorii AND i OR

Tabelul vizualizare (view, filtru, relaie virtual, vedere) constituie un
filtru asupra tabelului iniial, care conine numai informaia necesar unei
anumite abordri sau aplicaii. De fapt, vizualizarea este o expresie
relaional creia i se atribuie un nume.
5

Dac baza de date conine tabele reale depuse pe disc, o vizualizare

este virtual deoarece datele pe care le conine nu sunt n realitate memorate
ntr-o baz de date. Este memorat numai definiia vizualizrii. Vizualizarea
nu este definit explicit, ca relaiile de baz, prin mulimea tuplurilor
componente, ci implicit, pe baza altor relaii obinute prin intermediul unor
expresii relaionale. Stabilirea efectiv a tuplurilor care compun vizualizarea
se realizeaz prin evaluarea expresiei atunci cnd utilizatorul se refer la
acest tabel.
Utilizarea vizualizrilor este avantajoas, deoarece:
asigur securitatea tabelului iniial (care este protejat de tergeri,
modificri etc.) prin capacitatea de a ascunde datele;
permit vizualizarea simultan a acelorai date de ctre diveri
utilizatori;
sunt concise, punnd la dispoziie capaciti macro;
asigur independena logic fa de date (imunitatea programelor
de aplicaie fa de modificrile din structura logic a bazei de
date).
Exist totui limitri n utilizarea acestor tabele, n special legate de
problema reactualizrii. De exemplu, coloanele calculate nu pot fi
reactualizate. De asemenea, inserarea, reactualizarea i tergerea nu sunt, n
general, recomandate i sunt permise numai cu anumite restricii care sunt
specifice fiecrui SGBD. De exemplu, Oracle9i rezolv problema dificil a
reactualizrii vizualizrilor, n anumite situaii, utiliznd o clas special de
declanatoare (TRIGGER de tip INSTEAD OF).
3.2.2. Reguli de integritate
Regulile de integritate sunt aseriuni pe care datele coninute n baza
de date trebuie s le satisfac. Trebuie fcut distincia ntre regulile
structurale care sunt inerente modelrii datelor i regulile de funcionare
(comportament) care sunt specifice unei aplicaii particulare.
Exist trei tipuri de constrngeri structurale (de cheie, de referin, de
entitate) ce constituie mulimea minimal de reguli de integritate pe care
trebuie s le respecte un SGBD relaional. Restriciile de integritate
minimale sunt definite n raport cu noiunea de cheie a unei relaii.
O mulime minimal de atribute ale cror valori identific unic un
tuplu ntr-o relaie reprezint o cheie pentru relaia respectiv.

Prin urmare, o cheie a unei relaii R este o mulime K de atribute,

astfel nct:
(1) pentru orice dou tupluri t1, t2 ale lui R t1(K) t2(K);
(2) nu exist nicio submulime proprie a lui K avnd proprietatea (1).
Fiecare relaie are cel puin o cheie. Dac exist diferite chei posibile,
ele se numesc chei candidat. Una dintre cheile candidat va fi aleas pentru a
identifica efectiv tupluri i ea va primi numele de cheie primar. Cheia
primar nu poate fi reactualizat. Restul cheilor candidat vor purta numele de
chei alternative sau secundare. Atributele care reprezint cheia primar pot fi
subliniate sau urmate de semnul #.
O cheie identific linii i este diferit de un index care localizeaz
liniile. O cheie secundar este folosit ca index pentru a accesa tupluri. Un
grup de atribute din cadrul unei relaii care conine o cheie a relaiei poart
numele de supercheie.
Fie schemele relaionale R1(P1, S1) i R2(S1, S2), unde P1 este cheie
primar pentru R1, S1 este cheie secundar pentru R1, iar S1 este cheie
primar pentru R2. n acest caz, vom spune c S1 este cheie extern (cheie
strin) pentru relaia R1.
De exemplu, cod_casa_moda este cheie extern pentru relaia
CREATOR i este cheie primar pentru relaia CASA_MODA. Cheia
primar poate conine cheia extern. De exemplu, relaia ACCESORIU are
cheia primar format din atributele cod_accesoriu i cod_vestimentatie, iar
atributul
cod_vestimentatie
fiind
cheie
primar
n
relaia
VESTIMENTATIE, devine cheie extern n relaia ACCESORIU.
Modelul relaional respect trei reguli de integritate structural.

Regula 1 unicitatea cheii. Cheia primar trebuie s fie unic i

minimal.
Regula 2 integritatea entitii. Atributele cheii primare trebuie s
fie diferite de null.
Regula 3 integritatea referirii. O cheie extern trebuie s fie ori
null n ntregime, ori s corespund unei valori a cheii primare
asociate.

Uneori constrngerile de integritate sunt implementate procedural,

folosind o clas de proceduri (declanatori) precompilate, stocate mpreun
cu baza de date i invocate automat ori de cte ori are loc un anumit
eveniment. Aceste proceduri nu reprezint o modalitate recomandat de
implementare a constrngerilor de integritate deoarece, fiind proceduri, sunt

mai dificil de optimizat de ctre sistem i, de asemenea, sunt executate doar

atunci cnd apare evenimentul specificat (declanator).
Declanatorii trebuie utilizai cu precauie, sau deloc, dac exist o
modalitate alternativ de rezolvare a problemei respective. Ei pot crea
probleme practice datorit fenomenului declanatori n cascad (lan de
declanatori). De asemenea, dac acelai eveniment determin pornirea mai
multor declanatori diferii, atunci ordinea n care pornesc poate fi
important sau poate fi chiar nedefinit. Exist posibilitatea ca un
declanator s se declaneze singur, recursiv. Dac sunt disponibile, soluiile
declarative sunt de preferat celor procedurale.
3.2.3. Operatorii modelului relaional
Operatorii modelului relaional definesc operaiile care se pot efectua
asupra relaiilor n scopul realizrii funciilor de prelucrare asupra bazei de
date. Modelul relaional ofer dou mulimi de operatori pe relaii, i anume:
algebra relaional i calculul relaional. La rndul su, calculul relaional
este de dou tipuri: orientat pe tupluri sau orientat pe domenii.
Operatorii algebrei relaionale sunt fie operatori tradiionali pe
mulimi (UNION, INTERSECT, PRODUCT, DIFFERENCE), fie operatori
relaionali speciali (PROJECT, SELECT, JOIN, DIVISION). Aceti
operatori vor fi analizai n seciunea 3.4.
Calculul relaional reprezint o adaptare a calculului predicatelor la
domeniul bazelor de date relaionale. Ideea de baz este de a identifica o
relaie cu un predicat. Pe baza unor predicate iniiale, prin aplicarea unor
operatori ai calculului cu predicate (conjuncia, disjuncia, negaia,
cuantificatorul existenial i cel universal) se pot defini noi relaii.
Variabilele care apar n construciile calculului relaional orientat pe domenii
sunt variabile definite asupra domeniilor, iar cele care apar n construciile
calculului relaional orientat pe tupluri sunt variabile definite asupra
relaiilor, adic valorile acestora reprezint tupluri.
Echivalena dintre algebra relaional i calculul relaional a fost
demonstrat de J.D.Ullman. Aceast echivalen arat c orice relaie posibil
de definit n algebra relaional poate fi definit i n cadrul calcului
relaional, i reciproc.

3.3. Proiectarea modelului relaional

Problema proiectrii bazelor de date poate fi enunat n urmtoarea
manier: fiind dat un volum de informaii care trebuie reprezentat ntr-o baz
de date, cum se poate alege o structur logic adecvat pentru acesta?
Proiectarea bazelor de date este mai mult o art, dect o tiin. Exist
cteva principii tiinifice care pot fi invocate pentru a rezolva problema, dar
exist multe aspecte legate de proiectare pe care aceste principii nu le
abordeaz i evident, nu le rezolv. Teoreticienii i practicienii au propus
metodologii de proiectare mai mult sau mai puin riguroase, dar gsirea
proiectrii logice optime rmne o problem complex i dificil. Pot exista
criterii obiective care s favorizeze o abordare n raport cu celelalte. n
capitolul 2 s-a prezentat o abordare (proiectarea modelului E/R) care are
meritul c este frecvent utilizat n practic.
n practic, se ncearc obinerea unei scheme conceptuale corecte,
adic realizarea proiectrii logice abstracte independent de hardware, de
sistemul de operare, de SGBD, de limbaj, de utilizator etc. Este important
att obinerea structurilor de date corecte, ct i realizarea integritii datelor.
De asemenea, trebuie ca designul s fie robust, n sensul c nu va fi invalidat
prin ivirea unor noi cerine ale aplicaiei, care nu au fost prevzute n
momentul proiectrii iniiale.
Pentru rafinarea proiectrii modelului de date, pentru obinerea
schemei conceptuale a bazei de date relaionale, se pleac de la o form de
modelare semantic special a datelor, mai precis de la diagrama E/R.
Ideea general este de a reprezenta entitile i legturile dintre
acestea sub forma unor tabele speciale (relaii). Vor fi prezentate 9 reguli
care arat maniera n care se transform entitile, relaiile i atributele
acestora, n vederea obinerii schemei conceptuale.
Ca formalism, n diagrama conceptual, simbolul indic
plasamentul cheii externe. Dac simbolul este subliniat (), se exprim i
faptul c respectiva cheie extern este coninut n cheia primar.

3.3.1. Transformarea entitilor

Entitile independente devin tabele independente. Cheia primar

nu conine chei externe. De exemplu, entitatea independent
PREZENTARE genereaz un tabel independent pentru care
atributul cod_prezentare reprezint cheia primar.
Entitile dependente devin tabele dependente. Cheia primar a
entitilor dependente conine cheia primar a entitii de care
depinde (cheie extern) plus unul sau mai multe atribute
adiionale. De exemplu, cheia primar a entitii dependente
ACCESORIU este format din atributul cod_vestimentatie, care
reprezint cheia primar a entitii de care depinde
(VESTIMENTATIE), plus atributul adiional cod_accesoriu.
Subentitile devin subtabele. Cheia extern se refer la
supertabel, iar cheia primar este aceast cheie extern. De
exemplu, cheia primar a subentitii MODEL este cod_angajat
care este o cheie extern (cheie primar a entitii
ANGAJAT_TEMP).
3.3.2. Transformarea relaiilor

Relaiile 1:1 i 1:n devin chei externe. De exemplu, relaia creeaza

(CREATOR_creeaza_VESTIMENTATIE) devine coloan n
tabelul VESTIMENTATIE. Atributul cod_creator, care este cheie
primar n tabelul CREATOR, va fi cheie extern n tabelul
VESTIMENTATIE. Relaia 1:1 plaseaz cheia extern n tabelul cu
mai puine linii.
Relaia m:n devine un tabel special, numit tabel asociativ, care are
dou chei externe pentru cele dou tabele asociate. Cheia primar
este compunerea acestor dou chei externe plus eventuale coloane
adiionale. Un tabel asociativ se deseneaz punctat. De exemplu,
relaia participa (CASA_MODA_participa_PREZENTARE), care
este de tip m:n, devine tabel asociativ avnd cheia primar format
din atributele cod_casa_moda i cod_prezentare.
Relaiile de tip trei devin tot tabele asociative. De exemplu, relaia
primeste ce leag entitile ANGAJAT_TEMP, PREZENTARE i
CASA_MODA, devine tabel asociativ. Cheia primar a tabelului
este compunerea a trei chei externe: cod_angajat, cod_casa_moda
10

i cod_prezentare. Practic, n acest caz, este preferabil s fie

introdus o cheie primar artificial.

3.3.3. Transformarea atributelor

Un atribut singular devine o coloan.

Atributele multiple devin tabele dependendente ce conin cheia
primar a entitii i atributul multiplu. Cheia primar este format
dintr-o cheie extern, plus una sau mai multe coloane adiionale.
De exemplu, o persoan de contact poate cunoate mai multe limbi
strine. n acest caz, atributul limba_cunoscuta este multiplu i va
genera tabelul dependent LIMBA.
Entitile devin tabele, iar atributele lor devin coloane n aceste
tabele. Ce devin atributele relaiilor? Pentru relaii 1:1 i 1:n,
atributele relaiilor vor aparine tabelului care conine cheia
extern, iar pentru relaii m:n i de tipul trei, atributele vor fi
plasate n tabelele asociative.

Tabel
Reprezint
Independent entitate independent
Subtabel
subentitate
entitate dependent
Dependent
Atribut multiplu
relaie m:n
Asociativ
relaie de tip 3

Cheie primar
nu conine chei externe
o cheie extern
o cheie extern i una sau mai
multe coloane adiionale
dou sau mai multe chei externe
i (opional) coloane adiionale

Fig. 3.2. Clasificarea tabelelor

11

INFO CONTACT

LIMBA
FIRMA_PUB

cunoaste
ORGANIZATOR

face

are

are

PERS CONTACT
are

PUBLICITATE
organizeaza
FIRMA_SEC

LOCATIE

se_face

are

ANGAJAT_SEC

SOC ASIG

LOCALIZARE

are
PAZA

PREZENTARE

asigura

FINANTEAZA

SPONSOR

PARTICIPA

PRIMESTE

CASA MODA
prezinta
lucreaza

ANGAJAT_TEMP

MODEL

CREATOR

creeaza prezinta
face

VESTIMENTATIE

lucreaza_la

are

AGENTIE

are

ACCESORIU

refera

Fig. 3.3. Diagrama conceptual.

12

ISTORIC

Cele patru tipuri de tabele (independente, dependente, subtabele i

asociative) se deosebesc prin structura cheii primare (figura 3.2.).
n figura 3.3 este prezentat diagrama conceptual pentru proiectarea
modelului relaional comentat. Ea a fost construit din diagrama E/R prin
adugarea tabelelor asociative i prin marcarea cheilor externe.
n continuare va fi prezentat modalitatea efectiv de trecere de la
diagrama entitate-relaie la diagrama conceptual pentru modelul de date
real analizat n capitolul 2.
Entitile independente PERS_CONTACT, ORGANIZATOR,
PREZENTARE,
PUBLICITATE,
SPONSOR,
FIRMA_PUB,
CASA_MODA,
CREATOR,
ANGAJAT_TEMP,
ACCESORIU,
LOCALIZARE, FIRMA_SEC, ANGAJAT_SEC, SOCIETATE_ASIG,
INFO_CONTACT, AGENTIE, LOCATIE devin tabele independente.
Cheile primare ale fiecrei entiti au fost specificate n capitolul 2.
Entitile dependente ISTORIC i ACCESORIU, care intervin n
model, devin tabele dependente, iar cheile primare au fost specificate n
capitolul 2.
Subentitatea MODEL devine subtabel, avnd aceeai cheie primar cu
superentitatea ANGAJAT_TEMP, adic atributul cod_angajat.
Relaiile de tip one-to-one i one-to-many devin chei externe.
Relaia PERS_CONTACT_are_LOCALIZARE devine cheie extern n
tabelul PERS_CONTACT. Dac restricia c o persoan de contact are o
singur localizare este eliminat, atunci cardinalitatea relaiei devine 1:n, iar
atributul cod_pers_contact devine cheie extern n tabelul LOCALIZARE.
Toate comentariile anterioare rmn valabile i pentru entitile
FIRMA_PUB,
FIRMA_SEC,
PREZENTARE,
ORGANIZATOR,
CASA_MODA, SPONSOR, SOC_ASIG, CREATOR, LOCATIE,
ANGAJAT_TEMP i AGENTIE, care sunt legate de entitatea
LOCALIZARE, permind astfel localizarea tuturor structurilor modelului.
Relaia PERS_CONTACT_are_INFO_CONTACT devine cheie extern n
tabelul PERS_CONTACT. Dac restricia c pentru o persoan de contact
exist o singur posibilitate de contactare este eliminat, atunci
cardinalitatea relaiei devine 1:n, iar atributul cod_pers_contact devine cheie
extern n tabelul INFO_CONTACT. Toate comentariile anterioare rmn
valabile
i
pentru
entitile
FIRMA_PUB,
FIRMA_SEC,
ANGAJAT_TEMP, PREZENTARE, ORGANIZATOR, CASA_MODA,
SPONSOR, SOC_ASIG, CREATOR, LOCATIE i AGENTIE, care sunt
legate de entitatea INFO_CONTACT, permind astfel accesarea tuturor
structurilor modelului.
13

Relaia FIRMA_PUB_face_PUBLICITATE devine cheie extern n tabelul

PUBLICITATE.
Relaia PUBLICITATE_se_face_pentru_PREZENTARE devine cheie
extern n tabelul PUBLICITATE.
Relaia ORGANIZATOR_are_PERS_CONTACT devine cheie extern n
tabelul PERS_CONTACT.
Relaia FIRMA_SEC_are_ANGAJAT_SEC devine cheie extern n tabelul
ANGAJAT_SEC.
Relaia SOC_ASIG_asigura_PREZENTARE devine cheie extern n tabelul
PREZENTARE.
Relaia CASA_MODA_lucreaza_CREATOR devine cheie extern n tabelul
CREATOR.
Relaia CREATOR_creeaza_VESTIMENTATIE devine cheie extern n
tabelul VESTIMENTATIE.
Relaia VESTIMENTATIE_are_ACCESORIU devine cheie extern n tabelul
ACCESORIU.
Relaia MODEL_prezint_VESTIMENTATIE devine cheie extern n tabelul
VESTIMENTATIE.
Relaia CREATOR_face_ACCESORIU devine cheie extern n tabelul
ACCESORIU.
Relaia PREZENTARE_prezinta_VESTIMENTATIE devine cheie extern n
tabelul VESTIMENTATIE.
Relaia PREZENTARE_are_LOCATIE devine cheie extern n
PREZENTARE.
Relaia MODEL_lucreaza_AGENTIE devine cheie extern n tabelul
MODEL.
Relaia MODEL_are_ISTORIC devine cheie extern n tabelul ISTORIC.
Relaia ISTORIC_refera_AGENTIE devine cheie extern n tabelul
ISTORIC.
Relaiile de tip many-to-many devin tabele asociative, avnd dou
chei externe pentru cele dou tabele asociate.
Relaia ANGAJAT_SEC_paza_PREZENTARE devine tabel asociativ
(PAZA).
SPONSOR_finanteaza_PREZENTARE
devine
tabel
asociativ
(FINANTEAZA).
CASA_MODA_participa_PREZENTARE
devine
tabel
asociativ
(PARTICIPA).
Relaiile de tipul trei (adic cele care leag cel puin trei entiti)
devin tabele asociative, avnd chei externe pentru fiecare dintre tabelele
asociate.

14

Relaia primeste, care leag entitile ANGAJAT_TEMP, PREZENTARE i

CASA_MODA, devine tabel asociativ (PRIMESTE). n acest caz, s-a
considerat o cheie primar artificial (atributul cod_primeste). Tabelul
asociativ are drept chei externe atributele: cod_angajat, cod_casa_moda i
cod_prezentare.
Atributele multiple devin tabele dependendente ce conin cheia
primar a entitii i atributul multiplu.
Atributul limba_cunoscuta este multiplu (relativ la entitatea
PERS_CONTACT) i va genera tabelul dependent LIMBA. Acesta va avea
drept cheie primar atributele cod_pers_contact i limba_cunoscuta. Tabelul
mai conine trei atribute ce reprezint nivelul de cunoatere (scris, citit,
vorbit) a limbii.
Atributele entitilor devin coloane n tabelele corespunztoare. Pentru
relaii 1:1 i 1:n, atributele relaiilor vor aparine tabelului care conine cheia
extern, iar pentru relaii m:n i de tipul trei, atributele vor fi plasate n
tabelele asociative.
Tabelul asociativ PRIMESTE va avea ca atribute, pe lng cele ce constituie
cheia primar, suma, data_achitare, cont, banca.
Schemele relaionale corespunztoare diagramei conceptuale din
figura 3.3. sunt urmtoarele:
MODEL(cod_angajat#, cod_agentie, inaltime, nr_pantof, info)
ANGAJAT_TEMP(cod_angajat#, nume, prenume, data_nastere,
nationalitate, sex, cod_localizare, cod_info_acces, tip)
PUBLICITATE(cod_publicitate#, cod_firma_pub, cod_prezentare, tip,
nume, suma, observatii)
FIRMA_PUB(cod_firma_pub#, nume, info, director, observatii,
cod_localizare, nume_pers_contact, cod_info_acces)
ORGANIZATOR(cod_organizator#, denumire, banca, cont, cod_info_acces,
informatii, cod_localizare)
PERS_CONTACT(cod_pers_contact#, cod_organizator, nume, prenume,
directie, cod_localizare, cod_info_acces)
PREZENTARE(cod_prezentare#, denumire, data_start, data_final,
cod_soc_asig, cod_organizator, cod_locatie)
LOCATIE(cod_locatie#, denumire, tip, cod_localizare, cod_info_acces,
capacitate)
SPONSOR(cod_sponsor#, tip, nume, info, cod_localizare, cod_info_acces)
15

CASA_MODA(cod_casa_moda#, nume, cifra_afaceri, proprietar, director,

istoric, data_creare, cod_localizare, cod_info_acces)
CREATOR(cod_creator#, nume, prenume, data_nastere, data_angajare, tip,
mod_angajare, info, cod_casa_moda, cod_localizare, cod_info_acces)
VESTIMENTATIE(cod_vestimentatie#, denumire, valoare, descriere,
cod_creator, cod_model, cod_prezentare)
ACCESORIU(cod_vestimentatie#, cod_accesoriu#, cod_creator, descriere,
tip, valoare)
AGENTIE(cod_agentie#, nume, data_creare, director, cifra_afaceri, info,
cod_localizare, cod_info_acces)
ISTORIC(cod_model#, data_angajare#, data_final, cod_agentie, conditii)
LOCALIZARE(cod_localizare#, adresa, cod_postal, oras, tara)
INFO_CONTACT(cod_info_acces#, telefon_fix, telefon_mobil, mail, fax)
FIRMA_SEC(cod_firma_sec#, nume_firma, tip_servicii, director,
cod_localizare, cod_info_acces, observatii)
ANGAJAT_SEC(cod_angajat#, nume, prenume, data_nastere, specializare,
nivel, observatii, cod_info_acces, cod_firma_sec)
PAZA(cod_angajat#, cod_prezentare#, tip_paza, dotare, observatii)
SOC_ASIG(cod_soc_asig#, conditii, suma, director, observatii,
cod_localizare, nume_pers_contact_firma, cod_info_acces)
PARTICIPA(cod_prezentare#, cod_casa_moda#, tip, data)
FINANTEAZA(cod_sponsor#, cod_prezentare#, suma, banca, cont_emitent,
data_emitere, cod_ordin_plata)
PRIMESTE(cod_primeste#, cod_angajat, cod_prezentare, cod_casa_moda,
data_achitare, suma, cont, banca)
LIMBA(cod_pers_contact#,
niv_vorbit)

limba_cunoscuta#,

16

niv_scris,

niv_citit,

3.4. Regulile lui Codd

Un SGBD relaional ndeplinete funciile unui SGBD, dar cu anumite
particulariti care decurg din concepia de organizare a datelor, respectiv
din modelul relaional. Fiecare SGBD relaional implementeaz modelul
relaional ntr-o manier proprie, care l difereniaz de restul sistemelor
relaionale. Caracterizarea unui SGBD relaional se poate realiza la nivelul
clasei sistemelor relaionale, n sensul caracterizrii globale, unitare n raport
cu celelalte tipuri de SGBD-uri, sau la nivelul SGBD-ului relaional
individual n sensul caracterizrii particularitilor sale, n raport cu alte
SGBD-uri relaionale.
Realizarea funciilor SGBD-urilor relaionale se face cu ajutorul unor
mecanisme de lucru specifice, care le separ de sistemele nerelaionale.
Dintre mecanismele de lucru de care dispune un SGBD relaional se pot
meniona:
un limbaj relaional pentru descrierea datelor la nivel fizic, logic i
conceptual;
un limbaj relaional pentru prelucrarea datelor;
mecanisme pentru controlul integritii semantice a datelor;
mecanisme pentru optimizarea cererilor de date;
mecanisme pentru asigurarea coerenei datelor;
utilitare pentru generarea de rapoarte, pentru generarea de
aplicaii, pentru generarea unor statistici referitoare la starea i
activitatea bazei de date etc.
n anul 1985, E.F. Codd a publicat un set de 13 reguli n raport cu care
un sistem de gestiune a bazelor de date poate fi apreciat ca relaional. Niciun
sistem de gestiune a bazelor de date pus n vnzare pe piaa comercial nu
respect absolut toate regulile definite de Codd, dar acest lucru nu mpiedic
etichetarea acestor sisteme drept relaionale. Nu trebuie apreciat un SGBD
ca fiind relaional sau nu, ci msura n care acesta este relaional, deci
numrul regulilor lui Codd pe care le respect.
Regulile lui Codd au fost i sunt cauza multor controverse. Unii le
consider doar un exerciiu academic, alii pretind c produsele lor satisfac
majoritatea regulilor. De fapt, discuiile n jurul acestor reguli au generat o
cunoatere mai bun a caracteristicilor eseniale ale unui SGBD relaional,
att din punctul de vedere al utilizatorilor, ct i din cel al productorilor de
software.

17

Regulile pot fi organizate n urmtoarele cinci domenii de

funcionalitate: reguli fundamentale, reguli structurale, reguli de integritate,
reguli de prelucrare a datelor i reguli privind independena datelor.
Regula 1 regula gestionrii datelor. Un SGBD relaional trebuie s
fie capabil s gestioneze o baz de date prin posibilitile sale relaionale.
Practic, nicio implementare curent de SGBD nu respect aceast regul,
deoarece implementrile conin att caracteristici relaionale ct i
nerelaionale.
Regula 2 regula reprezentrii informaiei. ntr-o baz de date
relaional, informaia este reprezentat la nivel logic sub forma unor
tabele ce poart numele de relaii. Este regula cea mai important i
conform lui Codd, un SGBD care nu respect aceast regul, nu poate fi
considerat relaional. Chiar i meta-datele, coninute n catalogul de sistem,
trebuie s fie stocate ca relaii.
Regula 3 regula accesului garantat la date. Fiecare valoare dintr-o
baz de date relaional trebuie s poat fi adresat n mod logic printr-o
combinaie format din numele relaiei, valoarea cheii primare i numele
atributului.
Regula 4 regula reprezentrii informaiei necunoscute. Un sistem
relaional trebuie s permit utilizatorului definirea unui tip de date numit
null pentru reprezentarea unei informaii necunoscute la momentul
respectiv. ntr-un SGBD relaional trebuie s putem face diferena ntre
valoarea zero, un ir vid de caractere i o valoare necunoscut.
Regula 5 regula dicionarelor de date. Asupra descrierii bazelor de
date (informaii relative la relaii, vizualizri, indeci etc.) trebuie s se
poat aplica aceleai operaii ca i asupra datelor din baza de date.
Descrierea bazei de date este reprezentat la nivel logic sub forma unor
tabele care pot fi accesate n acelai mod ca i datele efective. Prin urmare
exist un singur limbaj de prelucrare att a meta-datelor, ct i a datelor.
Regula 6 regula limbajului de interogare. Trebuie s existe cel puin
un limbaj pentru prelucrarea bazei de date. n general, toate implementrile
SQL respect aceast regul. Limbajul permite utilizatorilor s defineasc
relaii i vizualizri, s prelucreze datele interactiv sau prin intermediul
programului, s regseasc informaia i s o poat actualiza, s verifice i s
corecteze datele de intrare, s implementeze constrngeri, s stabileasc
limite pentru tranzacii etc.
Regula 7 regula de actualizare a vizualizrii. Un SGBD trebuie s
poat determina dac o vizualizare poate fi actualizat i s stocheze
rezultatul interogrii, ce definete vizualizarea, ntr-un dicionar de tipul
18

unui catalog de sistem. Trebuie s existe un mecanism prin care s se poat

determina dac anumite vizualizri pot fi actualizate sau nu. Regula
stabilete c toate vizualizrile care sunt teoretic reactualizabile pot fi
reactualizate i de ctre sistemul de gestiune. Nu au fost nc descoperite
condiiile pentru identificarea tuturor vizualizrilor care pot fi teoretic
reactualizate.
Regula 8 regula limbajului de nivel nalt. Capacitatea de tratare a
unei relaii de baz sau a unei vizualizri ca pe un singur operand se aplic
att pentru operaiile de regsire a datelor, ct i asupra operaiilor de
inserare, actualizare i tergere a datelor. Un SGBD relaional nu trebuie s
oblige utilizatorul s caute ntr-o relaie, tuplu cu tuplu, pentru a regsi
informaia dorit. Operaiile de prelucrare a datelor pot s fie aplicate att n
mod interactiv ct i prin program, ntr-un limbaj gazd.
Regula 9 regula independenei fizice a datelor. Programele de
aplicaie i activitile utilizatorilor nu depind de modul de depunere a
datelor sau de modul de acces la date. ntr-un SGBD relaional trebuie s se
separe aspectul fizic al datelor (stocare sau acces la date) de aspectul logic al
datelor.
Regula 10 regula independenei logice a datelor. Programele de
aplicaie trebuie s fie transparente la modificrile de orice tip efectuate
asupra datelor. Orice modificare efectuat asupra unei relaii nu trebuie s
afecteze operaiile de prelucrare a datelor.
Regula 11 regula independenei datelor din punct de vedere al integritii. Regulile de integritate trebuie s fie definite ntr-un sublimbaj
relaional de date, nu n programul de aplicaie. SQL permite definirea de
restricii privind integritatea datelor i stocarea lor n catalogul de sistem. Cu
ct sunt mai multe constrngeri de integritate care pot fi ntreinute mai
degrab de ctre SGBD, dect n cadrul fiecrui program aplicaie, cu att
garantarea calitii datelor este mai bun.
Regula 12 regula independenei datelor din punct de vedere al
distribuirii. Distribuirea datelor pe mai multe calculatoare dintr-o reea de
comunicaii de date nu trebuie s afecteze programele de aplicaie. ANSISQL nu menioneaz regula n specificaiile sale, deoarece este destul de
greu de respectat. De observat c regula nu cere ca SGBD-ul s accepte o
baz de date distribuite pentru a fi relaional, dar stabilete c limbajul de
interogare va rmne acelai atunci cnd se va introduce aceast capacitate,
iar datele vor fi distribuite.

19

Regula 13 regula versiunii procedurale a unui SGBD. Orice

component procedural a unui SGBD trebuie s respecte aceleai restricii
de integritate ca i componenta relaional. De exemplu, dac n partea de
prelucrare a datelor a limbajului relaional valoarea dintr-o coloan este de
tipul not null, orice alt metod procedural de accesare a acestei coloane nu
trebuie s permit introducerea unui null n aceast coloan. Prin urmare,
regulile de integritate exprimate ntr-un limbaj relaional de un anumit nivel
nu pot fi distruse de un limbaj de nivel inferior.
Deoarece regulile lui Codd sunt prea severe pentru a fi respectate de
un SGBD operaional, s-au formulat criterii minimale de definire a unui
SGBD relaional.
Un SGBD este minimal relaional dac:
toate datele din cadrul bazei sunt reprezentate prin valori n tabele;
nu exist pointeri observabili de ctre utilizator;
sistemul suport operatorii relaionali de proiecie, selecie i
compunere natural, fr limitri impuse din considerente interne.
Un SGBD este complet relaional dac este minimal relaional i
satisface n plus condiiile:
sistemul suport restriciile de integritate de baz (unicitatea cheii
primare, constrngerile refereniale, integritatea entitii);
sistemul suport toate operaiile de baza ale algebrei relaionale.

20

4. NORMALIZAREA RELAIILOR
4.1. Preliminarii
n procesul modelrii unei baze de date relaionale, o etap important o
reprezint normalizarea relaiilor conceptuale. Aceasta presupune obinerea de
relaii moleculare, fr a pierde nimic din informaie, avnd scopul de a
elimina redundana i anomaliile reactualizrii informaiilor. Tehnica
normalizrii permite determinarea unei scheme conceptuale rafinate, printr-un
proces de ameliorare progresiv a unei scheme conceptuale iniiale a bazei de
date relaionale. Dup fiecare etap de ameliorare, relaiile bazei de date ating
un anumit grad de perfeciune, deci se afl ntr-o anumit form normal.
Trecerea unei relaii dintr-o form normal n alta presupune eliminarea unui
anumit tip de dependene nedorite, care sunt transformate n dependene
admisibile, adic dependene care nu provoac anomalii.
Procesul de ameliorare progresiv a schemei conceptuale trebuie s
satisfac urmtoarele cerine:
s garanteze conservarea datelor, adic n schema conceptual
final trebuie s figureze toate datele din cadrul schemei iniiale;
s garanteze conservarea dependenelor dintre date, adic n
schema final fiecare dependen trebuie s aib determinantul i
determinatul n schema aceleiai relaii;
s reprezinte o descompunere minimal a relaiilor iniiale, adic
nici una din relaiile care compun schema final nu trebuie s fie
coninut ntr-o alt relaie din aceast schem.
Exist dou metode pentru a modela baze de date relaionale fr
anomalii sau pierderi de informaie.
Schema descompunerii pleac de la o schem relaional
universal care conine toate atributele bazei de date. Schema se
descompune prin proiecii succesive n subrelaii. Descompunerea
se oprete atunci cnd continuarea ei ar duce la pierderi de
informaie. Algoritmii de descompunere se bazeaz, n general, pe
descrierea formal a dependenei dintre atribute.
Schema sintezei pleac de la o mulime de atribute independente.
Utiliznd proprieti de semantic i legturi ntre atribute se pot
compune noi relaii, astfel nct acestea s nu sufere de anumite
anomalii pe care dorim s le evitm. Algoritmii de sintez se
bazeaz n general pe teoria grafurilor pentru a reprezenta
legturile ntre atribute.
21

4.2. Dependene funcionale

Unul dintre conceptele principale asociate normalizrii este cel de
dependen funcional, care descrie formalizat legturile dintre atribute.
Dependena funcional este o proprietate a semanticii atributelor dintr-o
relaie. Semantica indic modul n care sunt legate atributele i specific
dependenele dintre ele. Atunci cnd exist o dependen funcional, ea este
specificat ca o constrngere ntre atribute.
O relaie universal este o relaie ce grupeaz toate atributele care
modeleaz sistemul real cercetat. Fie E, mulimea dependenelor considerate
de proiectantul bazei pentru o schem relaional sau pentru o relaie
universal.
Plecnd de la o mulime de proprieti formale ale dependenelor,
proprieti considerate drept reguli de deducie (axiome), poate fi obinut
mulimea maximal de dependene asociate lui E. Aceast mulime definete
nchiderea lui E.
Fie R(A1, A2, ..., An) o schem relaional i fie X, Y submulimi de
atribute ale lui R. X determin funcional Y sau Y depinde funcional (FD)
de X, dac pentru orice relaie r (valoare curent a lui R) nu exist dou
tupluri care s aib aceleai valori pentru atributele lui X i s aib valori
diferite pentru cel puin un atribut din Y. Cu alte cuvinte, o valoare a lui X
determin unic o valoare a lui Y. Notaia utilizat pentru desemnarea
dependenei funcionale este X Y. Altfel spus:
Definitie: Fie R un tabel relational si X si Y dou submultimi de coloane
ale lui R. Spunem c X determin functional pe Y sau c Y depinde
functional de X dac nu exist dou rnduri n tabelul R care s aib aceleasi
valori pentru coloanele din X si s aib valori diferite pentru coloanele din Y.
Dependena funcional X Y reprezint o constrngere aplicat
tuplurilor relaiei R, n sensul c oricare dou tupluri din R care au aceeai
valoare pentru X trebuie s ia aceeai valoare i pentru Y.
Dac pentru fiecare valoare a lui X exist cel mult o valoare a lui Y,
spunem c X este determinant iar Y este determinat.
Comparnd toate submulimile de atribute ale unei relaii i
determinnd legturile dintre ele, se pot obine toate dependenele
funcionale pe care o relaie le satisface. Aceast abordare nu este eficient,
consumnd mult timp. Exist posibilitatea ca, tiind anumite dependene
funcionale i utiliznd reguli de deducie, s fie obinute toate dependenele
funcionale.
22

Fie X, Y, Z, W mulimi de atribute ale unei scheme relaionale R i fie

urmtoarele reguli de inferen (axiome) prin care noi dependene
funcionale pot fi deduse din cele date:
Ax1 reflexivitate. X X. Mai general, dac Y X, atunci X Y.
Ax2 creterea determinantului. Pot fi considerate trei formulri echivalente pentru aceast axiom.
1. Dac X Y i X Z, atunci Z Y.
2. Dac X Y i W Z, atunci X Z Y W.
3. Dac X Y atunci X Z Y Z.
Ax3 tranzitivitate. Dac X Y i Y Z, atunci X Z.
4.3. Necesitatea normalizrii
Anomaliile care apar n lucrul cu baze de date se produc datorit
dependenelor care exist ntre datele din cadrul relaiilor bazei. Aceste
anomalii fac extrem de dificil lucrul cu baza de date. Aceste anomalii vor fi
comentate cu ajutorul unui exemplu.
Se consider o vizualizare (VP) asupra schemei relaionale
PREZENTARE ce conine doar atributele cod_prezentare#, denumire,
luna_start, cod_organizator. Aceste atribute reprezint pentru fiecare
prezentare de mod: codul acesteia, denumirea, luna n care ncepe prezentarea
i codul organizatorului.
Se consider constrngerea: toate prezentrile de mod cu acelai
nume ncep n aceeai lun.
cod_prezentar
e
1
2
3
4
5

denumire

luna_start

primavara
primavara
primavara
iarna
toamna

mai
mai
mai
martie
august

cod_organizato
r
11
37
11
32
11

Fig. 4.1. Vizualizarea VP

Datorit dependenei introduse pot exista: anomalii la inserare,
modificare sau tergere, redundan n date, probleme de reconexiune.
1. Redundan logic. Cuplul (primavara, mai) apare de trei ori.

23

2.

3.

4.

Anomalie la inserie. Dac se dorete includerea unei prezentri

de mod, care va incepe n luna aprilie i va avea denumirea
veselie, atunci perechea (veselie, aprilie) poate fi inserat n
relaia VP doar dac se definete o nou valoare pentru cheia
primar.
Anomalie la tergere. Dac este tears nregistrarea pentru care
codul prezentrii are valoarea 4, atunci se pierde informaia c
prezentarea avnd denumirea iarna a nceput n luna martie.
Anomalie la modificare. Dac se modific luna de nceput a
prezentrii primavara de la mai la februarie, atunci costul
modificrii este mare pentru a modifica toate nregistrrile, iar
dac se modific doar o nregistrare atunci constrngerea nu va
mai fi verificat.

Anomaliile au aprut datorit dependenei funcionale (constrngerii)

introduse anterior.
Normalizarea are drept scop: suprimarea redundanei logice, evitarea
anomaliilor la reactualizare, rezolvarea problemei reconexiunii. Exist o
teorie matematic a normalizrii al crei autor este E.F. Codd. Soluia lui
E.F. Codd este construirea unor tabele standard (forme normale).
Normalizarea este procesul reversibil de transformare a unei relaii, n
relaii de structur mai simpl. Procesul este reversibil n sensul c nicio
informaie nu este pierdut n timpul transformrii. O relaie este ntr-o form
normal particular dac ea satisface o mulime specificat de constrngeri.
Procesul normalizrii se realizeaz plecnd de la o relaie universal ce
conine toate atributele sistemului de modelat, plus o mulime de anomalii.
Orice form normal se obine aplicnd o schem de descompunere.
4.4. Forme normale
Formele normale ale relaiilor din baze de date relaionale sunt
definite n raport cu anomaliile care pot aprea n lucrul cu aceste relaii,
deci n funcie de dependenele nedorite care se manifest n cadrul relaiilor.
Pe msur ce relaia este transformat n forme superioare, devine din
ce n ce mai restrictiv ca format i mai puin expus anomaliilor la
reactualizare. Altfel spus:
Definitie: Normalizarea reprezint procesul de descompunere a unui
tabel relational n mai multe tabele care satisfac anumite reguli si care
stocheaz aceleasi date ca si tabelul initial astfel nct s fie eliminate
redundanta n date si anomaliile la actualizare.

24

Prima form normal (FN1)

O relaie este n prima form normal dac fiecrui atribut care o
compune i corespunde o valoare indivizibil (atomic). n plus, un tuplu nu
trebuie s conin atribute sau grupuri de atribute repetitive.
Aceast form figureaz ca cerin minimal n majoritatea sistemelor
relaionale.
Algoritm AFN1 (aducerea unei relaii n FN1 prin eliminarea
atributelor compuse i a celor repetitive)
1. Se introduc n relaie, n locul atributelor compuse, componentele
acestora.
2. Se plaseaz grupurile de atribute repetitive, fiecare n cte o nou
relaie.
3. Se introduce n schema fiecrei noi relaii de la pasul 2 cheia
primar a relaiei din care a fost extras atributul repetitiv.
4. Se stabilete cheia primar a fiecrei noi relaii create la pasul 2.
Aceasta este compus din cheia introdus la pasul 3, precum i din
atribute proprii ale acestor noi relaii.
Forma normal 2 (FN2)
O relaie R este n a doua form normal dac i numai dac:
relaia R este n FN1;
fiecare atribut care nu este cheie (nu particip la cheia primar)
este dependent de ntreaga cheie primar.
A doua condiie exprim necesitatea dependenei totale de cheia
primar. Aceast form normal interzice manifestarea unor dependene
funcionale pariale n cadrul relaiei R.
Pentru a obine o relaie FN2 se poate aplica regula Casey-Delobel.
Fie relaia R(K1, K2, X, Y), unde K1 i K2 definesc cheia primar, iar X i Y
sunt mulimi de atribute, astfel nct K1 X. Din cauza dependenei
funcionale K1 X care arat c R nu este n FN2, se nlocuiete R (fr
pierdere de informaie) prin dou proiecii R1(K1, K2, Y) i R2(K1, X).
Caracterul reversibil al normalizrii
Prin caracter reversibil al normalizrii se ntelege faptul c descompunerea
se face fr pierdere de informatie, adic tabelul initial poate fi reconstituit
prin compunerea natural, pe atribute comune, a tabelelor rezultate.
25

Pentru un tabel R care se descompune prin proiectie n mai multe tabele: R1,
R2, Rn, conditia de descompunere fr pierdere de informatie presupune
ca n urma operatiei de compunere natural a tabelelor R1, R2, Rn s se
obtin tabelul R.
Regula Casey-Delobel (caz particular de descompunere fr pierdere de
informatie):
Fie un tabel R(X, Y, Z) care se descompune prin proiectie n tabelele R1(X,
Y) si R2(X, Z) unde prin X notm setul de coloane comune ale tabelelor R1
si R2, iar prin Y si Z, coloanele specifice lui R1, respectiv R2. Conditia de
descompunere fr pierdere de informatie presupune ca tabelul R s fie
obtinut prin compunerea natural a tabelelor R1 si R2.
n SQL:
SELECT R1.X, R1.Y, R2.Z
FROM R1, R2
WHERE R1.X = R2.X
Algoritm AFN2 (aducerea unei relaii n FN2 prin eliminarea dependenelor funcionale pariale din cadrul unor relaii aflate n FN1)
1. Pentru fiecare dependen funcional parial se creeaz o nou
relaie avnd schema format din determinantul i determinatul
acestei dependene.
2. Se elimin din cadrul relaiei iniiale atributele care formeaz
determinatul dependenei pariale.
3. Dac n relaia iniial exist mai multe dependene pariale cu
acelai determinant, pentru acestea se creeaz o singur relaie cu
schema format din determinant (luat o singur dat) i din
determinaii dependenelor considerate.
4. Se determin cheia primar a fiecrei noi relaii create. Aceasta va
conine atributele din determinantul dependenei funcionale
pariale care au stat la baza constituirii relaiei.
5. Dac noile relaii create conin dependene pariale, atunci se face
transfer la pasul 1, altfel procesul de aducere la FN2 s-a terminat.

26

Exemplu
Fie schema relaional PARTICIPA (cod_prezentare#,
cod_casa_moda#, tip, data, data_start, data_final, denumire)
Pentru relaia PARTICIPA sunt adevrate dependenele:
{cod_prezentare} {data_start, data_final, denumire}
{cod_prezentare, cod_casa_moda} {data, tip}
Relaia PARTICIPA este n FN1, dar nu este n FN2 deoarece
atributele data_start, data_final i denumire nu depind de codul casei de
mod, deci nu depind de ntreaga cheie primar.
Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i
relaia PARTICIPA se proiecteaz n dou relaii:
PARTI1(cod_prezentare#, data_start, data_final, denumire)
PARTI2(cod_prezentare#, cod_casa_moda#, data, tip).
Not (reamintim C2):
Entitatea PREZENTARE are atributele: cod_prezentare, denumire,
data_start, data_final, cod_organizator, cod_soc_asig, cod_locatie.
Entitatea CASA_MODA are atributele: cod_casa_moda, nume, cifra_afaceri,
proprietar, director, istoric, data_creare, cod_localizare, cod_info_acces.
Atribute ale relatiei PARTICIPA
tip = variabil de tip caracter, de lungime maxim 15, care reprezint
modalitatea n care o cas de mod particip la o prezentare, n sensul c
poate fi organizator sau neorganizator.
data = variabil de tip dat calendaristic reprezentnd ziua n care defileaz
modelele casei de mod. Atributul nu este multiplu, deoarece s-a presupus c
defilarea unei case de mod are loc ntr-o singur zi.
Alt Exemplu:
Fie tabelul VANZARI care se foloseste la nregistrarea tranzactiilor unui
magazin ce vinde articole la comand.
VANZARI (cod_client#, cod_comanda#, cod_articol#, nume_client,
nr_telefon, data, nume_articol, cost_articol, cantitate)
A1 C1 P1 Popescu 415355 08.10.04 camasa 400000 2
A1 C1 P3 Popescu 415355 08.10.04 tricou 200000 1
27

A2 C2 P1 Ionescu 596322 09.10.04 camasa 400000 3

A2 C2 P3 Ionescu 596322 C2 09.10.04 tricou 200000 2
A2 C2 P2 Ionescu 596322 09.10.04 pantaloni 800000 1
A1 C3 P3 Popescu 415355 10.10.04 tricou 200000 3
A3 C4 P1 Marinescu 546229 C4 10.10.04 P1 camasa 400000 1
Tabelul de mai sus prezint urmtoarele deficiente:
a) redundante n date:
- informatia (P1, camasa, 400000) este specificata de 3 ori
- informatia (A1, Popescu, 415355) este specificata de 3 ori
- informatia (A2, Ionescu, 196322) este specificata de 3 ori
- s. a. m. d.
b) anomalii la actualizare:
- anomalie la insertie
Dac magazinul achizitioneaz un nou articol (P4, pantofi, 980000)
informatia nu poate fi introdus n tabel (un nou tuplu) pentru c s-ar
introduce o valoare Null n cheia primar (cod_comanda).
- anomalie la stergere
Dac este anulat articolul P2 n cadrul comenzii C2 se pierde informatia
referitoare la numele si costul articolului respectiv.
- anomalie la modificare
Dac se modific numrul de telefon al unui client, modificarea trebuie
facut n toate tuplurile (liniile) unde apare numele acelui client.
n tabelul VANZARI exist urmtoarele dependente functionale n
care determinantul nu este cheie a tabelului:
(cod_articol) (nume_articol, cost_articol)
(cod_comanda) (data, cod_client, nume_client, nr_telefon)
(cod_client) (nume_client, nr_telefon)
Pentru a obine o relaie n FN2 se aplic regula Casey Delobel i
relaia VANZARI se proiecteaz n trei relaii:
VANZARI1(cod_articol# nume_articol, cost_articol)
VANZARI2(cod_comanda#, data, cod_client, nume_client, nr_telefon)
VANZARI3(cod_client #, nume_client, nr_telefon)

28

Forma normal 3 (FN3)

Intuitiv, o relaie R este n a treia form normal dac i numai dac:
relaia R este n FN2;
fiecare atribut care nu este cheie (nu particip la o cheie) depinde
direct de cheia primar.
Fie R o relaie, X o submulime de atribute ale lui R i A un atribut al
relaiei R. A este dependent tranzitiv de X dac exist Y astfel nct X Y i
Y A (unde A nu aparine lui Y i Y nu determin pe X). De exemplu, dac
au loc dependenele K1, K2, K3 A1 i K1, K2, A1 A2, atunci K1, K2, K3
K1, K2, A1 i K1, K2, A1 A2. Prin urmare, A2 este dependent tranzitiv de K1,
K2, K3.
Formal, o relaie R este n a treia form normal dac i numai dac:
relaia R este n FN2;
fiecare atribut care nu este cheie (nu particip la o cheie) nu este
dependent tranzitiv de nicio cheie a lui R.
A doua condiie interzice utilizarea dependenelor funcionale tranzitive
n cadrul relaiei R.
Prin urmare, o relaie este n FN3 dac i numai dac fiecare
atribut care nu este cheie depinde de cheie, de ntreaga cheie i numai de
cheie.
Pentru a obine o relaie FN3 se poate aplica regula de descompunere
Casey-Delobel. Fie relaia R(K, X1, X2, X3), unde atributul X2 depinde
tranzitiv de K, iar K este cheia primar a lui R. Presupunem c K X1
X2. Din cauza dependenei funcionale X1 X2 care arat c R nu este n
FN3, se nlocuiete R (fr pierdere de informaie) prin dou proiecii R1(K,
X1, X3) i R2(X1, X2).
Dependena tranzitiv poate fi mai complex. Fie K1 o parte a cheii K.
Tranzitivitatea poate fi de forma K Y X2 unde Y = {K1, X1}. n acest
caz, R poate fi descompus n R1(K, X1, X3) i R2(K1, X1, X2).
Algoritm AFN3 (aducerea unei relaii FN2 n FN3 prin eliminarea
dependenelor funcionale tranzitive)
1. Pentru fiecare dependen funcional tranzitiv se transfer
atributele implicate n dependena tranzitiv ntr-o nou relaie.
2. Se determin cheia primar a fiecrei noi relaii create la pasul 1.
3. Se introduc n relaia iniial, n locul atributelor transferate, cheile
primare determinate la pasul 2.
29

4.

Se reanalizeaz relaia iniial. Dac n cadrul ei exist noi

dependene tranzitive, atunci se face transfer la pasul 1, altfel
procesul de aducere la FN3 s-a terminat.

Exemplu
Fie schema relaional PREZENT(cod_prezentare#, data_start,
data_final, denumire, cod_locatie, capacitate, cod_info_acces).
Pentru relaia PREZENT sunt adevrate dependenele:
{cod_prezentare} {data_start, data_final, denumire, cod_locatie}
{cod_locatie} {capacitate, cod_info_acces}
Relaia PREZENT este n FN2, dar nu este n FN3 deoarece atributele
capacitate, cod_info_acces depind indirect de cheia primar, prin
intermediul atributului cod_locatie.
Pentru a obine o relaie n FN3 se aplic regula Casey-Delobel i
relaia PREZENT se proiecteaz n dou relaii, prin eliminarea
dependenelor funcionale tranzitive.
PREZENT1(cod_prezentare#, data_start, data_final, denumire, cod_locatie)
PREZENT2(cod_locatie#, capacitate, cod_info_acces)
Forma normal Boyce-Codd (BCNF)
Determinantul este un atribut sau o mulime de atribute neredundante,
care constituie un identificator unic pentru alt atribut sau alt mulime de
atribute ale unei relaii date.
Intuitiv, o relaie R este n forma normal Boyce-Codd dac i numai
dac fiecare determinant este o cheie candidat.
Formal, o relaie R este n forma normal Boyce-Codd dac i numai
dac pentru orice dependen funcional total X A, X este o cheie a lui
R.
Algoritm ABCNF (aducerea unei relaii FN3 n BCNF prin
eliminarea dependenelor funcionale ai cror determinani nu sunt chei
candidat)
1. Dac relaia conine unul sau cel mult dou atribute, atunci nu pot
exista dependene noncheie i deci relaia este n BCNF.
2. Dac relaia conine mai mult de dou atribute, se caut dac ea
conine dependene noncheie. Dac nu exist astfel de dependene,
relaia este n BCNF.
3. Pentru fiecare dependen noncheie X Y se creeaz dou relaii.
Una dintre ele va avea schema format din atributele {X, Y}, iar
30

4.

cealalt va avea schema format din toate atributele relaiei

iniiale, mai puin Y.
Se reiau paii 1, 2, 3 pentru relaiile obinute la pasul 3.

Exemplu
Se consider relaia FINANTEAZA1, ce leag entitile
PREZENTARE i SPONSOR. Ea are cardinalitatea many to many i va
genera un tabel asociativ. Se presupune c acest tabel are schema
relaional:
FINANTEAZA1(cod_prezentare#, cod_sponsor#, nume_prezentare,
cod_ordin_plata).
Pentru exemplul analizat se presupune c numele prezentrilor sunt
unice. Prin urmare, n orice moment fiecare prezentare are un cod unic i
un nume unic. Cheile candidat sunt {cod_prezentare, cod_sponsor},
respectiv {nume_prezentare, cod_sponsor}.
ntre atributele relaiei exist dependenele:
{cod_prezentare, cod_sponsor} {cod_ordin_plata}
{cod_prezentare} {nume_prezentare}
Tabelul nu este n BCNF deoarece conine doi determinani,
cod_prezentare i nume_prezentare, care nu sunt chei candidat pentru
tabelul respectiv. Ambele atribute sunt determinani deoarece fiecare l
determin pe cellalt.
Soluia problemei const n divizarea relaiei n dou proiecii
conform tehnicii Casey-Delobel.
PREZENTARE(cod_prezentare#, nume_prezentare)
FINANTEAZA(cod_prezentare#, cod_sponsor#, cod_ordin_plata)
Forma normal 4 (FN4)
Dac BCNF elimin redundanele datorate relaiilor singulare, FN4
elimin redundanele datorate relaiilor m:n, adic datorate dependenei
multiple.
Intuitiv, o relaie R este n a patra form normal dac i numai dac
relaia este n BCNF i nu conine relaii m:n independente.
Exemplu
Fie schema relaional
PERS_CONTACT(cod_pers#, limba_cunoscuta, nr_telefon).
Se presupune c o persoan de contact poate cunoate mai multe limbi
strine i poate avea mai multe numere de telefon. ntre atributele relaiei
exist multidependenele:
31

cod_pers# limba_cunoscuta
cod_pers# nr_telefon.
Pentru a aduce relaia PERS_CONTACT (care este n BCNF) n FN4,
aceasta se va diviza n dou proiecii :
PERS_CONTACT1(cod_pers#, limba_cunoscuta)
PERS_CONTACT1(cod_pers#, nr_telefon).
Forma normal 5 (FN5)
Semnificaia lui FN5 este mai mult academic, ea aprnd rar n
practic. A cincea form normal i propune eliminarea redundanelor care
apar n relaii m:n dependente. n general, aceste relaii nu pot fi
descompuse. S-a artat c o relaie de tip 3 este diferit de trei relaii de tip
2. Exist totui o excepie, i anume, dac relaia este ciclic.
Intuitiv, o relaie R este n forma normal 5 dac i numai dac:
1. relaia este n FN4;
2. nu conine dependene ciclice.
Exemplu
Se consider o relaie ce conine informaii despre creatori,
vestimentaiile create de acetia i accesoriile corespunztoare. Se consider
schema
relaional
CREARE(cod_vestimentatie#,
cod_creator#,
cod_accesoriu#).
Se presupune c fiecare creator poate crea una sau mai multe
vestimentaii. Fiecare vestimentaie poate fi creat de unul sau mai muli
creatori. Similar, fiecare creator este responsabil de crearea unuia sau a mai
multor accesorii, iar fiecare accesoriu este creat de unul sau mai muli
creatori. Fiecare accesoriu apare n una sau mai multe vestimentaii, iar
fiecrei vestimentaii i se ataeaz unul sau mai multe accesorii.
Mai mult chiar, dac creatorul C creeaz vestimentaia V, iar
accesoriul A este ataat lui V, iar C este este responsabil de A, atunci C
creeaz accesoriul A pentru vestimentaia V.
innd seama de constrngerile impuse modelului se obin
dependenele:
{cod_vestimentatie#, cod_creator#} {cod_accesoriu}
{cod_vestimentatie#, cod_accesoriu#} {cod_creator}
{cod_accesoriu#, cod_creator#} {cod_vestimentatie}.
Datorit dependenelor formulate anterior, relaia nu este n FN5. Ea
se poate rupe prin proiecie n trei relaii:
CREARE1(cod_vestimentatie#, cod_creator#)
32

CREARE2(cod_vestimentatie#, cod_accesoriu#)
CREARE3(cod_creator#, cod_accesoriu#).
n acest caz, sunt evidente relaiile:
CREARE JOIN(CREARE1, CREARE2)
CREARE JOIN(CREARE1, CREARE3)
CREARE JOIN(CREARE2, CREARE3)
CREARE = JOIN(JOIN(CREARE1, CREARE2), CREARE3).
Concluzii:
1. FN1 FN2 elimin redundanele datorate dependenei netotale a
atributelor care nu particip la o cheie, fa de cheile lui R. Se
suprim dependenele funcionale care nu sunt totale.
2. FN2 FN3 elimin redundanele datorate dependenei tranzitive.
Se suprim dependenele funcionale tranzitive.
3. FN3 BCNF elimin redundanele datorate dependenei
funcionale. Se suprim dependenele n care partea stng nu este
o supercheie.
4. BCNF FN4 elimin redundanele datorate multidependenei. Se
suprim toate multidependenele care nu sunt i dependene
funcionale.
5. FN4 FN5 elimin redundanele datorate dependenei ciclice. Se
suprim toate join-dependenele care nu sunt implicate de o cheie.
6. BCNF, FN4 i FN5 corespund la regula c orice determinant este
o cheie, dar de fiecare dat dependena cu care se definete determinantul este alta i anume dependena funcional,
multidependena sau join-dependena.
7. Descompunerea unei relaii FN2 n FN3 conserv datele i
dependenele, pe cnd descompunerea unei relaii FN3 n BCNF
i, respectiv, a unei relaii BCNF n FN4 conserv doar datele.

33

Partea a II-a. LIMBAJUL SQL

n aceast tema: se prezint conceptele limbajului SQL n 5 lecii,

dup cum urmeaz:
INTRODUCERE. Concepte SQL
LECIA 1. Limbajul de definire a datelor - DDL
LECIA 2. Limbajul de interogare a datelor - DQL
LECIA 3. Combinarea datelor din mai multe tabele Uniuni
LECIA 4. Limbajul de manipulare a datelor DML
LECIA 5. Limbajul de control al datelor DCL
Introducere. Concepte SQL
SQL a devenit limbajul universal pentru bazele de date relaionale
i este acceptat de aproape toate sistemele SGBD moderne. Fr ndoial,
acceptarea pe scar larg este rezultatul timpului i eforturilor depuse
pentru dezvoltarea caracteristicilor limbajului i a standardelor, crescnd
nivelul de portabilitate a codului SQL ntre diferitele produseSGBD.
Ce este SQL?
SQL (Structured Query Language
-limbaj structurat de
interogare) este un limbaj standard folosit pentru crearea, actualizarea i
regsirea informaiilor stocate n baze de date prin intermediul sistemelor
de gestionare a bazelor de date ( SGBD-uri).
Numele limbajului poate fi pronunat pe litere (es-q-el) sau la fel ca
i cuvntul englezesc sequel". O interogare (query) este o simpl cerere
transmis ctre baza de date, la care aceasta rspunde ntr-o anumit
form. SQL este limbajul folosit cel mai frecvent pentru interogarea
bazelor de date. SQL este considerat un limbaj neprocedural sau
declarativ, ceea ce nseamn c-i spunei calculatorului ce rezultate vrei,
far s-i spunei cum s le obin. De exemplu, dac vrei s obinei
media numerelor de pe o coloan, folosii funcia AVG. Nu este nevoie s
numrai valorile din coloan i s mprii suma acestora la numrul
obinut - procesorul limbajului SQL din SGBD se ocup de toate aceste
lucruri n locul dumneavoastr.
Este important s nelegi c SQL nu este un limbaj procedural, ca
C, Pascal, Basic, FORTRAN, COBOL sau Ada. Un limbaj procedural
folosete o serie de instruciuni executate secvenial. De asemenea,
limbajele procedurale includ instruciuni care pot modifica secvena de

execuie, prin ramificarea la alte poriuni ale procedurii sau prin

parcurgerea ciclic a unui set de instruciuni din procedur. Muli
productori de sisteme SGBD ofer extensii procedurale ale limbajului
SQL de baz, cum ar fi Oracle PL/SQL (Procedural Language/SQL) sau
Microsoft Transact-SQL, dar reinei c acestea sunt extensii SQL care
formeaz noi limbaje - codul SQL pe care-1 conin rmne neprocedural.
De asemenea, SQL nu trebuie confundat cu limbajele orientate spre
obiecte, precum Java i C++.
Simplu spus, SQL este un limbaj neprocedural pentru gestionarea
i ntreinerea bazelor de date relaionale, nu un limbaj potrivit pentru
programarea general a aplicaiilor, cum ar fi sistemele de prelucrare a
comenzilor sau a plilor.
SQL este deseori folosit n combinaie cu limbajele procedurale sau
orientate spre obiecte menionate anterior pentru a manipula stocarea i
extragerea datelor, folosind instruciuni din limbajul de programare cu
destinaie general pentru alte sarcini de programare, precum prezentarea
datelor pe o pagin web sau furnizarea rspunsurilor la informaiile
introduse de utilizatori de la tastatur sau mouse. Atunci cnd este
necesar interacionarea cu baza de date, instruciunile din limbajul
procedural formeaz instruciunea SQL, o transmit ctre SGBD n
vederea prelucrrii, primesc rezultatele returnate de SGBD i le
prelucreaz ntr-un mod corespunztor.
Folosind SQL putei transforma ntrebri obinuite :Din ce oras
sunt studentii notri? n instruciuni pe care le nelege soft-ul pentru baze
de date: SELECT oras FROM studenti.
SQL se poate folosi nu numai pentru interogare, dar i pentru a
aduga, a modifica sau a terge nregistrri din bazele de date.
Majoritatea SGBD -urilor populare, ca de exemplu Microsoft
Accsess, Oracle i MySQL , asigur suport pentru SQL, chiar dac acest
nivel de suport difer de la produs la produs.
Conectarea la baza de date
Atunci cnd folosii limbajul SQL pe un calculator personal, cu o
copie personal a unui sistem SGBD, precum Microsoft Access sau
Oracle Personal Edition, toate componentele bazei de date ruleaz pe
acelai sistem de calcul. Totui, acest aranjament nu este potrivit pentru
bazele de date care trebuie s fie folosite n comun de mai muli
utilizatori. Ca urmare, sunt mult mai frecvent ntlnite situaiile n care
baza de date este instalat ntr-un aranjament client/server.
ntr-un aranjament client/server:

 Sistemul ruleaz pe un server, care este un sistem de calcul

partajat. Pentru scopurile acestei definiii, un sistem mainframe poate fi
considerat un server de dimensiuni mari.
Fiierele care compun baza de date din punct de vedere fizic sunt
stocate pe discuri conectate la serverul de baze de date.
Utilizatorii care au acces la baza de date folosesc staii de lucru,
numite clieni. Clientul trebuie s aib o conexiune de reea la baza de
date, care poate fi o reea privat, instalat acas sau la birou, ori o reea
public, precum Internet.
Componentele software furnizate de productorul SGBD ruleaz
pe staiile de lucru alte clienilor pentru a oferi utilizatorilor posibilitatea
s introduc instruciuni SQL, s le transmit sistemului SGBD n
vederea prelucrrii i s vad rezultatele returnate de DBMS. n general,
acest software se numete client SQL.
Reinei c nimic nu v oprete s instalai clientul SQL pe acelai
calculator cu sistemul SGBD. De fapt, muli dezvoltatori care utilizeaz
sisteme SGBD precum MySQL, Microsoft SQL Server i Oracle fac n
mod obinuit acest lucru, deoarece este foarte convenabil s aib ntregul
mediu de dezvoltare pe un singur calculator, cum ar fi un laptop. Totui,
n momentul n care este necesar accesul partajat al mai multor utilizatori,
este mult mai convenabil i mai eficient s avei o singur copie a
sistemului SGBD pe un server partajat i s avei numai clientul SQL
instalat pe staia de lucru a fiecrui client.
n funcie de interfaa cu utilizatorul de pe staia de lucru client,
clienii SQL sunt clasificai n trei categorii: n linia de comand, grafici
i bazai pe web. O interfa n linia de comand se bazeaz exclusiv pe
intrri i ieiri de tip text, cu comenzile introduse de la tastatur i
rspunsurile afiate ca mesaje de tip text. Principalul avantaj al
interfeelor n linia de comand este c pot fi rulate pe aproape orice
sistem de operare. De exemplu, clientul SQL*Plus rulat ntr-o fereastr de
comand Microsoft Windows.

O interfa grafic cu utilizatorul (GUI - Graphical User Interface)

ruleaz sub un tip oarecare de sistem bazat pe ferestre, cum ar fi :
X Window System, Mac OS sau Microsoft Windows, i afieaz datele
sau opiunile comenzilor folosind elemente grafice, precum pictograme,
butoane i casete de dialog. n figura de mai jos se prezint clientul
SQL*Plus(unul din clienii SQL furnizai de ORACLErulat ca aplicaie
GUI sub Microsoft Windows.

O interfa bazat pe web ruleaz pe serverul de baze de date,

folosind un browser web de pe staia de lucru client pentru a interaciona
cu utilizatorul bazei de date. Din punct de vedere tehnic, un client SQL
bazat pe web nici nu este o aplicaie client, deoarece nu exist nici o
component software specific productorului SGBD rulat pe staia de
lucru a clientului. Totui, aproape ntotdeauna exist componente
furnizate de productorul SGBD care sunt descrcate n fundal de
browser-ul web pentru a asista n procesul de reprezentare grafic a
formularelor web folosite pentru introducerea instruciunilor SQL i
afiarea rezultatelor.
Tabelul urmtor prezint clieni SQL oferii de diferii productori
SGBD. n aceast curs nu prezentm toate detaliile referitoare la fiecare
client SQL pe care ai putea s-1 folosii, aa c v rog s consultai
documentaia productorului SGBD pentru informaii despre instalarea i
utilizarea clienilor SQL disponibile pentru sistemul SGBD pe care-1
folosii

Productor

SGBD

Client SQL

Descriere
Microsoft Access este o baz de date de uz
personal, cu clientul SQL integrat n

Microsoft

Access

Nu exist
DBMS, toate fiind rulate local pe staia de
lucru a utilizatorului.
Client SQL care ruleaz ca aplicaie n

Microsoft

SQL Server

iSQL

linia de comand ntr-un nucleu de

comenzi Microsoft Windows.

Microsoft

SQL Server Query Analyzer

Client SQL care ruleaz ca

aplicaie Microsoft Windows.
Client

SQL

care

ruleaz

ca

aplicaie n linia de comand sub

MySQL

MySQL

MySQL

diferite sisteme de operare, inclusiv

Microsoft Windows, Linux, Mac OS
X i diferite implementri Unix.
Client

Oracle

Oracle

iSQL*Plus

SQL

bazat

pe

web

acceptat n versiunile Oracle 9i

si mai noi.
Client

SQL

care

ruleaz

ca

aplicaie Microsoft Windows sau

ca aplicaie n linia de comand
Oracle

Oracle

SQL*Plus

sub diferite sisteme de operare,

inclusiv
Linux,

Microsoft
Mac

OS

Windows,
X,

diferite

implementri Unix i altele.

Client

SQL

scris

Java

disponibil n Oracle 8i i 9i, dar

Oracle

Oracle

SQL Worksheet
nlocuit de iSQL*Plus n Oracle
10g.
Clientul SQL care ruleaz ca aplicaie
n linia de comand ntr-un nucleu de
comenzi

Sybase

Sybase

Microsoft

Windows.

Asemnrile cu Microsoft SQL Server

iSQL

nu

sunt

ntmpltoare

primele

versiuni Microsoft SQL Server erau

bazate pe sistemul SGBDSybase.

Un scurt istoric al limbajului SQL

Ctre sfritul anilor '70, un grup de cercettori de la IBM au
dezvoltat o baz de date relaional, numit System/R, bazat pe lucrrile
Dr. E. F. Codd. n System/R a fost inclus un limbaj, numit SEQUEL
(Structured English Query Language), pentru manipularea i extragerea
datelor. Acronimul SEQUEL" a fost ulterior condensat n abrevierea
SQL", atunci cnd s-a descoperit c SEQUEL" era marc nregistrat a
companiei Hawker-Siddeley Aircraft din Marea Britanie.
Dei IBM a creat prima implementare SQL, dou alte produse, cu
nume diferite pentru limbajele de interogare, au fost lansate pe pia ca
primele produse pentru baze de date relaionale, Oracle, furnizat de
Relational Software, i INGRES, furnizat de Relational Technology. IBM
a lansat n 1982 produsul SQL/DS, cu limbajul de interogare numit acum
SQL (Structured Query Language). Dac programarea structurat era
expresia la mod n anii '80, cuvntul structured" din SQL nu avea nici o
legtur cu programarea structurat, deoarece SQL nu este un limbaj de
programare procedural.
Comitetele de standardizare a limbajului SQL au fost formate de
ANSI (American National Standards Institute) n 1986 i ISO
(International Organization for Standardization) n 1987. Din fericire,
comitetele create de cele dou organizaii au colaborat pentru dezvoltarea
unui standard SQL comun, la nivel mondial. Doi ani mai trziu, au fost
publicate primele specificaii ale standardului, numite SQL-89. Dup trei
ani, specificaiile originale au fost extinse, sub forma standardului SQL92, care avea aproximativ 600 de pagini. A treia generaie a fost numit
SQL-99 sau SQL3. Cele mai multe produse SGBD sunt construite pe
baza standardului SQL-92 (numit acum SQL2). SQL3 include multe
caracteristici obiectuale, necesare pentru folosirea limbajului SQL cu o
baz de date relaional orientat spre obiecte, precum i extensii de
limbaj care fac din SQL un limbaj de programare complet (adugnd
cicluri, ramificri i construcii de comutare, de tip case). Cea mai recent
generaie, numit SQL:2003, introduce caracteristici legate de XML i
alte mbuntiri. Aceste standarde nu sunt gratuite. Standardul SQL:2003
poate fi cumprat de la ISO (www.iso.org) sau ANSI (webstore.ansi.org).
Pentru cei care au un buget mai restrns, este disponibil o versiune
apropiat de cea final la Whitemarsh Information Systems Corporation
(www.wiscorp.com/SQLStandards.html). Aproape toi furnizorii au
adugat extensii la dialectul" SQL propriu, n parte deoarece doreau s
diferenieze produsele proprii i n parte deoarece cerinele pieei i forau
s implementeze caracteristici nainte a aprea standarde pentru acestea.
Un astfel de exemplu este acceptarea tipurilor de date
TIMESTAMP i DATE. Datele calendaristici sunt foarte importante
6

pentru prelucrarea datelor comerciale, dar dezvoltatorii produselor SGBD

originale erau academicieni i oameni de tiin, nu specialiti n
prelucrri comerciale, aa c aceast cerin nu a fost anticipat. Ca
rezultat, primele dialecte SQL nu asigurau un suport special pentru datele
calendaristice. Pe msur ce au aprut produsele comerciale, furnizorii au
rspuns cererilor lansate de clienii importani i au adugat n grab
suportul pentru date calendaristice. Din nefericire, din cauza grabei
fiecare a fcut-o n felul propriu. Codul SQL este foarte compatibil i
portabil ntre produsele diferiilor furnizori, dar sistemele complete de
baze de date pot fi rareori transferate far anumite ajustri.
SQL a sistemului Oracle este o extensie a normei SQL89 i o
implementare a normei SQL92.
Convenii de sintax SQL
Aceast seciune prezint conveniile generale de sintax folosite
pentru construia instruciunilor SQL. Totui, reinei c exist o mulime
de extensii i variaii ntre diferiii productori. Pentru simplitate,
termenul implementare este folosit pentru referirea fiecrei versiuni SQL
a fiecrui productor (cu alte cuvinte, Oracle 9i, Oracle 10g, Microsoft
SQL Server 7, Microsoft SQL Server 2000 i Microsoft SQL Server 2005
conin implementri diferite ale limbajului SQL).
Conveniile de sintax SQL sunt mai uor de neles folosind un
exemplu simplu. Instruciunea de mai jos returneaz valorile Movie ID i
Movie Title pentru toate filmele din magazinul de produse video pentru
care categoria MPAA este PG":
SELECT FILM_ID, TITLU_FILM
FROM FILM
WHERE MPAA_RATING_COD = 'PG';
Conveniile de baz sunt urmtoarele:
Fiecare instruciune ncepe cu o comand, de obicei sub forma
unui singur cuvnt, care aproape ntotdeauna este un verb (n limba
englez) care descrie o aciune. n acest exemplu, instruciunea ncepe cu
comanda SELECT, care este descris n detaliu n lecia 3.
Fiecare instruciune se termin cu un delimitator, care este, de
obicei, un caracter punct i virgul (;). Unele implementri permit
schimbarea delimitatorului cu un alt caracter. Mai mult, unele
implementri, cum ar fi cea din Oracle, nu execut o instruciune SQL
creia-i lipsete delimitatorul de sfrit, n timp ce alte implementri
consider acest delimitator opional.
Instruciunile sunt construite ntr-o manier similar cu
propoziiile din limba englez, cu unul sau mai multe spaii pentru
7

separarea elementelor de limbaj. Un element de limbaj, asemntor cu un

cuvnt dintr-o propoziie, poate fi un cuvnt cheie (SELECT, FROM,
WHERE), numele unui obiect al bazei de date (FILM, FILM_ID,
TITLU_FILM), un operator (=) sau o constant ('PG') care apare ntr-o
instruciune.
Instruciunile sunt scrise ntr-o form liber, ceea ce nseamn c
nu exist reguli stricte privind poziia elementelor de limbaj pe o linie sau
locul n care se poate face trecerea la o linie nou. Totui, n general nu
este o idee bun s mprii un element de limbaj pe mai multe linii. Din
punct de vedere logic, instruciunea de mai jos este identic cu cea
prezentat la nceputul acestei seciuni, dar nu este la fel de uor de citit i
de neles:
SELECT FILM_ID, TITLU_FILM FROM FILM WHERE
MPAA_RATING_COD ='PG';
Instruciunile sunt organizate ntr-o serie de clauze i, de obicei,
clauzele trebuie s apar ntr-o anumit ordine atunci cnd sunt folosite
(multe clauze sunt opionale). n exemplul nostru, exist trei clauze,
fiecare ncepnd cu un cuvnt cheie (SELECT, FROM, WHERE).
Elementele de limbaj SQL pot fi scrise cu litere mari, cu litere
mici sau n combinaii. Totui, n majoritatea implementrilor i n
conformitate cu standardele ANSI/ISO, toate minusculele sunt
transformate n majuscule n vederea prelucrrii. Aceasta nu nseamn c
datele nu pot conine litere mici, ci c numele obiectelor din baza de date
(tabele, coloane etc.) i comenzile trebuie s fie scrise cu litere mari.
Excepii notabile sunt Microsoft SQL Server i Sybase, care permit
modul de lucru cu diferenierea literelor mari de cele mici, caz n care
numele de obiecte scrise diferit sunt tratate ca nume diferite. n MySQL,
diferenierea literelor mari de cele mici n numele obiectelor este legat
de capacitatea sistemului de operare de a face aceast difereniere.
Virgulele sunt folosite pentru separarea articolelor dintr-o list. n
exemplul nostru, numele a dou coloane sunt specificate ntr-o list
separat prin virgule (FILM_ID, TITLU_FILM). Spaiile care urmeaz
dup virgule sunt opionale - putei aduga orice numr de spaii, inclusiv
zero.
irurile de caractere care apar n instruciunile SQL trebuie s
fie ncadrate cu apostrofuri (unele implementri SQL permit i folosirea
ghilimelelor). Constantele numerice nu sunt niciodat ncadrate cu
apostrofuri. Dac n irul de caractere trebuie s apar un caracter
apostrof, sunt inserate dou apostrofuri unul lng cellalt. De exemplu,
dac vrei s gsii n baza de date un film numit Sophie's Choice, vei
scrie clauza WHERE astfel:
WHERE TITLU_FILM = 'Sophie''s Choice'
8

 Numele obiectelor bazei de date sunt formate folosind numai

litere, cifre i liniue de subliniere. Caracterul underscore (liniua de
subliniere) este folosit, de obicei, ca separator ntre cuvinte, pentru
mbuntirea lizibilitii. Aa cum am menionat anterior, unele
implementri permit folosirea numelor care fac diferena ntre literele
mari i cele mici, cum ar fi PersonMiddleName, un stil numit deseori
scriere de tip cmil", dar acest stil nu este recomandabil dac dorii ca
instruciunile SQL s fie portabile pe alte implementri. n definitiv, un
nume precum PERSONMIDDLENAME" nu este foarte uor de citit.
In fiecare implementare SQL este definit un set de cuvinte
rezervate, care sunt cuvinte cu o semnificaie specific pentru procesorul
SQL al sistemului SGBD i, care urmare, nu trebuie folosite ntr-un alt
context - de exemplu ca nume pentru obiectele bazei de date. Scopul
acestei restricii este de a evita interpretarea greit a instruciunilor SQL
de ctre SGBD. Aa cum probabil bnuii, lista cuvintelor rezervate difer
semnificativ de la o implementare SQL la alta, aa c este bine s
consultai documentaia implementrii pe care o folosii pentru a v
familiariza cu aceste cuvinte.
Un comentariu pe o singur linie ncepe cu dou liniue de
desprire (--). Cele dou liniue se pot afla la nceputul unei linii, ceea ce
nseamn c ntreaga linie este considerat comentariu, sau oriunde n
cadrul liniei, caz n care restul liniei, pn la sfrit, este considerat
comentariu. De exemplu:
-- Acesta este un comentariu pe o singur linie n SQL.
Un comentariu pe mai multe linii ncepe cu combinaia dintre o
diagonal la dreapta (slash) i un asterisc (/*) i continu pn la
ntlnirea combinaiei invers (*/). Avei grij s terminai corect
comentariile, altfel multe linii SQL pe care le-ai scris vor fi tratate de
ctre SGBD ca i cum ar fi comentarii. Iat un exemplu de comentariu pe
mai multe linii:
/* Acesta este un comentariu pe mai multe linii.
Continu pn la ntlnirea combinaiei de caractere care
marcheaz sfritul comentariului. */
Sistemul impune anumite restricii asupra identificatorilor.
Numele unui obiect nu poate depi 30 de caractere, cu
excepia numelui bazei de date care este limitat la 8 caractere i
a numelui legturii unei baze care poate ajunge la 128 caractere.
Nu se face distincie ntre litere mici i litere mari.
Numele trebuie s nceap printr-un caracter alfabetic i nu
poate fi un cuvnt cheie rezervat; poate s conin literele mari
i mici ale alfabetului englez, cifrele 0 - 9 i caracterele $, _, #.
9

Un utilizator nu trebuie s defineasc dou obiecte cu acelai

nume.
n general este bine ca numele unui obiect s fie descriptiv i
fr prescurtri excesive.

Categorii de instruciuni SQL

Instruciunile SQL sunt mprite n categorii, dup funciile pe
care le ndeplinesc. Unii experi consider aceste categorii ca fiind
limbaje separate sau sublimbaje. Totui, n SQL acestea au aceeai
sintax de baz i respect aceleai reguli, aa c eu le consider categorii
de instruciuni din acelai limbaj.
Categoriile de instruciuni, descrise n seciunile urmtoare, sunt:
Limbajul de definire a datelor (DDL sau LDD Data
Definition Language)
Limbajul de interogare a datelor (DQL-Data Query Language)
Limbajul de manipulare a datelor (DML sau LMD - Data
Manipulation Language)
Limbajul pentru controlul datelor (DCL sau LCDData
Control Language)
Comenzile pentru controlul tranzaciilor (Transaction Control
Commands)

Limbajul de definire a datelor (DDL)

Limbajul de definire a datelor (DDL - Data Definition Language)
include instruciuni SQL care permit utilizatorului bazei de date s creeze
i s modifice structura obiectelor bazei de date, cum ar fi tabele,
vizualizri i indexuri. Instruciunile SQL care folosesc comenzile
CREATE, ALTER i DROP sunt considerate parte a DDL. Este
important s nelegei c instruciunile DDL afecteaz containerele care
stocheaz datele n baza de date, nu datele propriu-zise. Ca urmare, exist
instruciuni DDL pentru crearea, tergerea i modificarea tabelelor, dar
nici una dintre aceste instruciuni nu ofer posibilitatea de a crea sau
modifica rnduri de date din tabelele respective.
Instruciunile LDD au efect imediat asupra bazei de date i
nregistreaz informaia n dicionarul datelor. De asemenea, LDD contine
instructiunile RENAME, TRUNCATE si COMMENT.

10

Limbajul de interogare a datelor (DQL)

Limbajul de interogare a datelor (DQL - Data Query Language)
include instruciuni SQL care permit obinerea datelor din baza de date.
Dei reprezint o parte foarte important a limbajului SQL, DQL este
format din instruciuni care folosesc o singur comand: SELECT. Unii
furnizori i autori clasific instruciunile DQL i DML n aceeai
categorie.
Limbajul de manipulare a datelor (DML)
Limbajul de manipulare a datelor (DML - Data Manipulation
Language) include instruciuni SQL care permit utilizatorului bazei de
date s adauge date n baza de date (sub forma rndurilor din tabele), s
tearg date i s modifice datele existente n baza de date. Instruciunile
SQL care folosesc comenzile INSERT, UPDATE i DELETE sunt
considerate parte a DML.
Limbajul pentru controlul datelor (DCL)
Limbajul pentru controlul datelor (DCL Data Control Language)
include instruciuni SQL care permit administratorilor s controleze
accesul la datele din baza de date i folosirea diferitelor privilegii ale
sistemului DBMS, cum ar fi privilegiul de oprire i pornire a bazei de
date. Instruciunile SQL care folosesc comenzile GRANT si ALTER sunt
considerate parte a DCL.
Comenzile pentru controlul tranzaciilor
O tranzacie n baza de date este un set de comenzi pe care
utilizatorul bazei de date vrea sa le trateze ca pe o unitate funcionala de
tip totul sau nimic, ntelegnd prin aceasta c intreaga tranzactie trebuie
sa reuseasca sau sa esueze. Comenzile pentru cotrolul tranzaciilor
(Transaction Control Commands ) nu respect cu exactitate sintaxa
instruciunilor SQL , dar afecteaza puternic comportamentul
instructiuunilor SQL incluse n tranzacii.

Lecia 1:Limbajul de definire a datelor

La nivel logic, o baz de date Oracle este alctuit din scheme. O
schem este o mulime de structuri logice de date, numite obiecte. Ea
aparine unui utilizator al bazei de date i poart numele su.

11

Specificarea bazelor de date i a obiectelor care le compun se

realizeaz prin intermediul limbajului de definire a datelor (DDL).
Definirea unui obiect presupune crearea, modificarea i suprimarea sa.
Limbajul de definire a datelor cuprinde instruciunile SQL care permit
realizarea acestor operaii (CREATE, ALTER, DROP).
Instruciunile DDL au efect imediat asupra bazei de date i
nregistreaz informaia n dicionarul datelor. De asemenea, DDL contine
instructiunile RENAME, TRUNCATE si COMMENT.
n cadrul unei scheme se pot defini obiecte de tip: tabel (table),
vizualizare (view), vizualizare materializat (materialized view), secven
(sequence), index (index), sinonim (synonym), grupare (cluster),
procedur (procedure) i funcie (function) stocat, declanator (trigger),
pachet stocat (package), legtur a bazei de date (database link),
dimensiune (dimension) etc.
Se vor prezenta n
definirea i gestionarea
Instruciunile CREATE,
limbajului SQL numit
Definition Language).

continuare instruciunile SQL folosite pentru

obiectelor dintr-o baz de date relaional.
ALTER i DROP formeaz o categorie a
limbaj de definire a datelor (DDL Data

Se prezint DDL naintea DQL, DML deoarece trebuiesc create

obiectele bazei de date nainte de a insera date n baza de date.
Convenii de sintax
Instruciunile SQL DDL au mai multe opiuni dect alte
instruciuni SQL. Urmtoarele convenii sunt pentru a prezenta sintaxa
instruciunilor DDL:
Cuvintele cheie i cuvintele rezervate din SQL sunt scrise cu
majuscule, cum ar fi CREATE TABLE.
Informaiile pe care ar trebui s fie furnizate la scrierea
instruciunilor sunt scrise cu italic, cum ar fi nume_coloan.
Elementele opionale sunt ncadrate n paranteze ptrate, cum ar
fi [WITH TIME ZONE].
Opiunile dintr-o list de elemente posibile sunt separate de o
bar vertical (simbolul logic pentru sau"), cum ar fi TABLE |
VIEW | INDEX. Se pot ntlni uneori ca list de elemente
opionale, cum ar fi [NULL | NOT NULL].
Elementele de grup care sunt explicate sau analizate ulterior pe
componente (de obicei dup descrierea unui tip principal de
instruciune) sunt ncadrate de caracterele mai mic dect" i

12

mai mare dect", cum ar fi <specificaii_pentru_coloan>.

Un element care se poate repeta este urmat de trei puncte, cum ar
fi. [,<restricie_pentru_tabel>...].
Toate celelalte simboluri, n special virgulele i parantezele, fac
parte din sintaxa SQL obligatorie i, ca urmare, trebuie s fie incluse aa
cum sunt scrise aici.

Tipuri de date
O coloan este cea mai mic unitate denumit care poate fi referit
ntr-o baz de date relaional. Fiecare, coloan trebuie s aib asociate
un nume unic i un tip de date. Un tip de date este o categorie pentru
formatul folosit de o anumit coloan. Tipurile de date asigur cteva
avantaje importante:
Restricionarea, datelor din coloana respectiv la caracterele care
au sens pentru tipul de date specificat.
Asigurarea unor comportamente utile pentru utilizatorul datelor.
De exemplu, dac se scade un numr dintr-un alt numr, se
obine ca rezultat un numr; dar dac se scade o dat dintr-o alt
dat, se obine ca rezultat diferena n zile dintre cele dou date
calendaristice.
Creterea eficienei sistemului SGBD la stocarea datelor din
coloane.
SQL accept trei categorii de tipuri de date: tipuri predefinite,
tipuri construite i tipuri definite de utilizator.
Tipurile de date predefinite sunt cele furnizate de ctre productor
ca parte nativ a sistemului SGBD(vor fi tratate n continuare).
Tipurile de date construite, cunoscute i ca tipuri de colecii, conin
matrice sau seturi de tipuri de date predefinite, n scopul reprezentrii n
SGBD a construciilor de date orientate spre obiect.
Tipurile de date definite de utilizator permit utilizatorului bazei de
date s defineasc propriile tipuri de date, adaptate unor scopuri specifice.
Ultimele dou tipuri de date nu vor fi tratate , fiind prea
complicate pentru inteniile cursului.
Tipuri de date predefinite din standardul SQL:2003
Majoritatea implementrilorSQL accept cea mai mare parte parte

13

a tipurilor de date definite de standardul SQL:2003.

Avem urmtoarele clase de tipuri:
Tipuri de date pentru caractere, tipuri de date numerice,
tipuri de date temporale i tipuri de date pentru obiecte mari.
Tipuri de date pentru caractere
Tipurile de date pentru caractere conin iruri de caractere, adic
litere, cifre i alte simboluri permise de sistemul de calcul pe care se afl
baza de date.
Tipurile de date stardard pentru caractere sunt:
Caracter cu lungime fix - Un ir de caractere cu lungime finit.
Sintaxa SQL este:
CHARACTER(lungime) | CHAR(lungime)
Exemplu: CNP CHAR(13)
Caracter naional - Acest tip de date poate fi folosit pentru
traducerea irurilor de caractere n diferite limbi. Sintaxa SQL
este:
NATIONAL CHARACTER(lungime) | NCHAR(lungime)
Exemplu: TITLU_FILM NCHAR(50)
Caracter variabil - Un ir de caractere cu lungime variabil,
specificnd lungimea maxim a irurilor de caractere stocate.
Sintaxa SQL este:
CHARACTER VARYING(lungime_maxim) |
VARCHAR(lungime_maxim)
Exemplu: NUME_CLIENT VARCHAR(125)
Caracter naional variabil O variant a tipului de date pentru
iruri de caractere cu lungime variabil, stocata ntr-un set de
caractere al unei anumite limbi. Sintaxa SQL este:
NATIONAL CHARACTER VARYING(lungime_maxim) |
NVARCHAR (lungime_maxim)
Exemplu: TITLU_FILM NVARCHAR(100)
Tipuri de date numerice

14

Acestea sunt utile mai ales pentru atributele folosite n calcule.

Toate tipurile numerice au o precizie (un numr de cifre). De asemenea
unele tipuri numerice au i o scal (numrul de cifre aflate n dreapta
punctului zecimal). Tipurile ntregi i tipurile numerice care include o
scal sunt numite tipuri numerice exacte, n timp ce numerele reale care
nu include o scal (numerele cu virgul mobil) sunt numite numerice
aproximative.
Tipurile numerice standard sunt:
Numeric - Un tip numeric exact care include o precizie i o
scal. Sintaxa SQL este:
NUMERIC (precizie, scal)
Exemplu: PLATA_PE_ORA_ANGAJAT NUMERIC(5,2)
Zecimal - Un tip numeric exact care include o precizie i o scal.
Diferena fa de Numeric, const n faptul c precizia este mai
mare , avnd scopul de a permite maparea tipului peste un tip al
al platformei pe care ruleaz SGBD. Sintaxa SQL este:
DECIMAL(precizie, scal)
Exemplu: PLATA_PE_ORA_ANGAJAT DECIMAL(5,2)
ntreg - Un tip numeric exact care include numai precizia, scris
INTEGER sau INT. Numerele ntregi nu au cifre zecimale, aa
c scala nu este necesar, deoarece este ntotdeauna zero.
Sintaxa SQL este:
INTEGER (precizie) | INT (precizie)
Exemplu: ID_CONT_CLIENT INTEGER
ntreg mic - O variant a tipului INTEGER, scris SMALLINT,
care stocheaz numere mai mici i, ca urmare, ocup mai puin
spaiu. Sintaxa SQL este:
SMALLINT (precizie)
Exemplu: ID_CONT_CLIENT SMALLINT
ntreg mare - O variant a tipului INTEGER, scris BIGINT,
care stochez numere mai mari i ocup mai mult spaiu.
Sintaxa SQL este:
BIGINT (precizie)
Exemplu: ID_CONT_CLIENT BIGINT
Numr n virgul mobil - Un tip numeric aproximativ, cu
precizia mai mare sau egal cu precizia specificat. Specificarea
15

preciziei este opional. Este scris FLOAT. Sintaxa SQL este:

FLOAT (precizie)
Exemple: RATA_DOBANDA FLOAT(16)
RATA_DOBANDA FLOAT
Numr real - Un tip numeric aproximativ, cu precizie definit de
implementare. Sintaxa SQL este:
REAL
Exemplu: RATA_DOBANDA REAL
Numr real cu precizie dubl - Un tip numeric aproximativ, cu
precizie definit de implementare, dar mai mare sau egal cu
precizia definit pentru tipul REAL. Sintaxa SQL este:
DOUBLE PRECISION | DOUBLE
Exemplu: RATA_DOBANDA DOUBLE PRECISION

Tipuri de date temporale (tipuri pentru date i ore)

Aceste tipuri stocheaz date care msoar timpul, ntr-un mod
oarecare.
Tipurile de date temporale conin urmtoarele componente, numite
de standard, cmpuri (fields) :
Numele cmpului (cuvnt cheie
SQL)

Definiie
Anul calendaristic, pe dou sau
patru cifre
Luna din an
Ziua din lun
Ora din zi
Minutul din or
Secunda din minut
Valoarea orei cu diferena de fus
orar
Valoarea minutului cu diferena
de fus orar

YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
TIMEZONE_HOUR
TIMEZONE_MINUTE

Cmpurile TIMEZONE_HOUR i TIMEZONE_MINUTE sunt

incluse n toate tipurile de date temporale pentru care este specificat
cuvntul cheie WITH TIMEZONE.

16

Tipurile de date temporale sunt:

Data - O dat calendaristic, incluznd cmpurile YEAR,
MONTH i DAY. Sintaxa SQL este:
DATE [WITH TIMEZONE]
Exemplu: DATA_NASTERE DATE
Ora - Un tip de date pentru or, incluznd cmpurile HOUR,
MINUTE i SECOND. Sintaxa SQL este:
TIME [WITH TIMEZONE]
Exemplu: TIMPUL_DEMARARE TIME
Marc temporal - Un tip de date combinat pentru dat i or,
incluznd cmpurile YEAR, MONTH, DAY, HOUR, MINUTE
i SECOND. Sintaxa SQL este:
TIMESTAMP [WITH TIMEZONE]
Exemplu: DATA_TIMP_ NASTERE TIMESTAMP
Interval - Un interval de timp, incluznd cmpurile
specificate printr-un calificator de interval (internal qualifier),
care reprezint precizia intervalului. Sintaxa SQL este:
INTERVAL cmp_de_start TO
cmp_de_sfrit|INTERVAL cmp
Exemple:
DURATA_PROIECT INTERVAL YEAR TO DAY
TIMP_LUCRU INTERVAL HOUR TO MINUTE
ZILE_VACANTA INTERVAL DAY
Tipuri de date pentru obiecte mari- LONG
Obiectele mari permit stocarea unor date care depesc cu mult
posibilitile de stocare ale tipurilor de date prezentate pn acum,
ajungnd deseori la dimensiuni de civa megaoctei. Deoarece
manipularea obiectelor mari este un subiect avansat, care nu vace obiectul
cursului, se vor prezenta aceste tipuri fr sintaxa lor.
Obiect mare pentru caractere - Un obiect mare pentru
caractere, scris n SQL sub foma CLOB.
Obiect mare pentru caractere, n format naional - Un obiect
mare pentru caractere, stocat ntr-o anumit limb, scris n SQL
sub forma NLOB.
Obiect mare binar - Un obiect mare care conine date binare,
cum ar fi o imagine sau o secven sonor, scris n SQL sub
forma BLOB.
17

Exist restricii referitoare la folosirea tipului de date LONG.

ntr-un tabel poate s fie o singur coloan de tip LONG.
Nu pot fi comparate dou iruri de caractere de tip LONG.
O coloan de tip LONG nu poate fi parametru ntr-o procedur.
O funcie nu poate ntoarce ca rezultat o valoare de tip LONG.
O coloan de tip LONG nu poate fi folosit n clauzele WHERE,
ORDER BY, GROUP BY, CONNECT.
Operatorii sau funciile Oracle nu pot fi folosii n SQL pentru a
modifica coloane de tip LONG.
O coloan de tip LONG nu poate fi indexat.
Un alt tip de date
Exist un tip standard de date care nu este ncadrat n nici una
dintre categoriile prezentate anterior:
Boolean - Stocheaz o valoare logic adevrat sau fals.
Sintaxa SQL este:
BOOLEAN
Exemplu: CLIENT_PREFERAT BOOLEAN

Extensii pentru tipuri de date i diferene fa de standard

Microsoft Access
Microsoft Access este baza de date care respect n cea mai mic
msur standardul, din toate sistemelm SGBD frecvent folosite.
Tipurile de date acceptate de Microsoft Access sunt:
Text - Echivalent cu tipul de date standard VARCHAR. Poate
stoca pn la 255 de caractere.
Memo - Conine iruri cu cel mult 65535 de caractere, dar este
definit fr specificarea unei dimensiuni.
Number - Echivalent cu tipul de date standard NUMERIC, dar
precizia i scala sunt stabilite folosind meniul derulant Field Size
(Mrimea cmpului). Numerele ntregi pot fi definite alegnd
valoarea zero (0) pentru parametrul Decimal Places (Poziii
zecimale).
Date/Time - Aproximativ echivalent cu tipul de date standard
TIMESTAMP, dar poate stoca orice date i or valide ntre anii
100 i 9999.

18

 Currency - Un tip de date numeric echivalent cu tipul NUMERIC

(19,4), adic un numr cu 15 cifre n stnga punctului zecimal i
cel mult 4 cifre n dreapta punctului zecimal.
AutoNumber - Un cmp pe 4 sau 16 octei (n funcie de valoarea
Field Size) incrementat automat cu o unitate de fiecare dat cnd
n tabel este inserat un nou rnd.
Yes/No - Aproximativ echivalent cu tipul de date standard
BOOLEAN. Totui, Microsoft Access permite ca acest tip de
date s fie formatat ca Yes/No, On/Off sau True/False.
OLE Object - Similar cu tipul de date standard BLOB, acest tip de
date permite stocarea unui obiect Microsoft OLE cu dimensiunea
maxim de 1GB (gigaoctet).
Hyperlink Un tip de date specializat care poate conine o adres
web din Internet.
Lookup wizard - Un tip de date specializat care creeaz o legtur
ntre o coloan din tabelul curent i coninutul unei coloane dintrun alt tabel. Acest tip de date poate fi folosit pentru legarea
dinamic a tabelelor la crearea formularelor n Microsoft Access.

Oracle
Oracle SQL accept urmtoarele tipuri de date standard:
BLOB -Obiecte binare mari, cu dimensiunea maxim de (4GB-1)
x (dimensiunea unui bloc din baza de date).
CHAR - iruri de caractere cu lungime fix, coninnd cel mult
2000 de octei.
CLOB - Obiecte de tip caracter mari, cu dimensiunea maxim de
(4GB- 1) x (dimensiunea unui bloc din baza de date).
DATE - Funcioneaz ca tipul standard de date DATE, dar din
punct de vedere tehnic seamn mai mult cu tipul DATETIME,
deoarece poate stoca att data, ct i ora. Accept date de la 1
ianuarie 4712 .e.n. la 31 decembrie 9999 e.n. Opional, poate fi
inclus i ora, n ore, minute i secunde. Dac partea opional
este omis, este stocat cu valoarea zero, echivalent cu miezul
nopii.
DECIMAL - Implementat ca NUMBER(precizie,scal).
DOUBLE PRECISION - Implementat ca NUMBER.
FLOAT - Implementat ca NUMBER.
INTEGER - Implementat ca NUMBER(38).

19

 INTERVAL - Un interval de timp, dar sunt acceptate din

standard numai variantele INTERVAL YEAR TO MONTH i
INTERVAL DAY TO SECOND.
NCHAR - iruri de caractere cu lungime fix ntr-o limb
naional, cu dimensiunea maxim de 2000 de octei.
NCLOB - iruri de caractere cu lungime fix ntr-o limb
naional, cu dimensiunea maxim de (4GB-1) x (dimensiunea
unui bloc din baza de date).
NUMERIC - Implementat NUMBER(precizie,scal).
NVARCHAR - Date de tip caracter cu lungime variabil ntr-o
limb naional, cu dimensiunea maxim de 4000 de octei .
REAL - Implementat ca NUMBER.
SMALLINT - Implementat ca NUMBER(38).
TIMESTAMP - Data i ora n ani, luni, zile, ore, minute i
secunde.
VARCHAR - Date de tip caracter cu lungime variabil,
coninnd cel mult 4000 de caractere.
Oracle ofer urmtoarele extensii la tipurile de date standard:
BFILE - O valoare de localizare a unui fiier binar de dimensiuni
mari, stocat n afara bazei de date.
LONG - Date de tip caracter cu lungime variabil, cu
dimensiunea maxim de 2GB.
LONG RAW - Date binare, cu dimensiunea maxim de 2GB.
NUMBER - Date numerice, cu cel mult 38 de cifre. Poate stoca
valori ntregi sau n virgul mobil.
NVARCHAR2 - Identic cu NVARCHAR.
RAW - Date binare, cu dimensiunea maxim de 2000 de octeli.
ROWID - ir de caractere codat Base 64*, reprezentnd adresa
unic a unui rnd n tabelul din care face parte.
UROWID - ir de caractere codat Base 64, reprezentnd adresa
logic a unui rnd ntr-un tabel indexat.
VARCHAR2 - Identic cu VARCHAR, dar Oracle recomand
folosirea folosirea acestui tip n loc de VARCHAR, deoarece
Oracle e posibil s schimbe la un moment dat implementarea
tipului VARCHAR.
Precizari si exemple
Pentru memorarea datelor numerice, tipurile cele mai frecvent
folosite sunt: NUMBER, INTEGER, FLOAT, DECIMAL.

20

Pentru memorarea irurilor de caractere, cele mai frecvent tipuri

de date utilizate sunt: CHAR, NCHAR, VARCHAR2 , NVARCHAR2 i
LONG.
Informaii relative la timp sau dat calendaristic se obin
utiliznd tipul DATE. Pentru fiecare dat de tip DATE sunt depuse:
secolul, anul, luna, ziua, ora, minutul, secunda. Pentru o coloan de tip
DATE sistemul rezerv 7 bytes, indiferent dac se memoreaz doar
timpul, sau doar data calendaristic.
Formatul implicit al datei se definete cu ajutorul parametrului de
iniializare NLS_DATE_FORMAT. n general, acest parametru este setat
la forma DD-MON-YY. Dac nu este specificat timpul, timpul implicit
este 12:00:00.
Oracle9i introduce noi tipuri de date pentru timp:
TIMESTAMP(precizie_fraciuni_secund) cuprinde
valori pentru anul, luna i ziua unei date calendaristice, dar i valori
pentru or, minut, secund
INTERVAL YEAR (precizie_an) TO MONTH stocheaz o
perioad de timp specificat n ani i luni, unde precizie_an reprezint
numrul de cifre din cmpul YEAR.
INTERVAL DAY (zi) TO SECOND (prec_frac_sec)
stocheaz o perioad de timp reprezentat n zile, ore, minute i secunde.
Exemple
S se creeze un tabel cu trei coloane, inceput, durata_1, durata_2.
Coloana inceput va cuprinde valori ce reprezint momente de timp,
inclusiv fraciunile de secund corespunztoare. Valorile coloanei
durata_1 vor fi intervale de timp specificate n numr de zile, ore, minute
i secunde. Coloana durata_3 va conine intervale de timp precizate n
numr de ani i luni. S se insereze o nregistrare n acest tabel.
CREATE TABLE TIMP (
inceput TIMESTAMP,
durata_1 INTERVAL DAY(2) TO SECOND(3),
durata_2 INTERVAL YEAR TO MONTH );
Exemple date inserate 1.
INSERT INTO timp
21

VALUES (TIMESTAMP '2009-10-31 09:26:50.30',

INTERVAL '23 7:44:22' DAY TO SECOND,
INTERVAL '19-02' YEAR TO MONTH);

Ex. 2
INSERT INTO timp
VALUES (TIMESTAMP '2010-02-20 09:20:40.20',
INTERVAL '23 7:44:22' DAY TO SECOND,
INTERVAL '200-02' YEAR TO MONTH);

INTERVAL '200-02' da eroare, deoarece implicit precizia pentru

an este 2, iar 200 are 3 digiti
Ex.3
INSERT INTO timp
VALUES (TIMESTAMP '2010-01-25 09:26:50.30',
INTERVAL '23 7:44:22' DAY TO SECOND,
INTERVAL '20-100' YEAR TO MONTH);

22

INTERVAL '20-100' eroare, deoarece 100 de luni adauga ani

Ex.4
INSERT INTO timp
VALUES (TIMESTAMP '2010-01-25 09:26:50.30',
INTERVAL '23 2:2:2' DAY TO SECOND,
INTERVAL '20-10' YEAR TO MONTH);

Ex.5
INSERT INTO timp
VALUES (TIMESTAMP '2010-01-25 09:26:50.30',
INTERVAL '23 2:2:2' DAY TO SECOND,
INTERVAL '20-12' YEAR TO MONTH);

INTERVAL '20-12' eroare deoarece 12 luni fac un an si depasesc

intervalul de 20 ani
Ex.6
23

INSERT INTO timp

VALUES (TIMESTAMP '2010-01-25 09:26:50.30',
INTERVAL '23 2:2:2' DAY TO SECOND,
INTERVAL 120 MONTH);
Se observ ca executnd instructiunea:
SELECT * from timp ;
Ca durata_2 are valoarea 10;

Ex.7
INSERT INTO timp
VALUES (TIMESTAMP '2010-01-25 09:26:50.30',
INTERVAL '360' SECOND,
INTERVAL 144 YEAR);

24

Se observa c inregistrarea introdusa are :

Durata_1 este de 6 min(360 sec) si
Durata_2 de 12 ani(144 de zile)
Ex.8
INSERT INTO timp
VALUES (TIMESTAMP '2010-01-25 09:00:00.30',
INTERVAL '20' DAY(2),
INTERVAL 10 YEAR);

Se observa c inregistrarea introdusa are :

Durata_1 de 20 zile si 0 secunde( fiind un INTERVAL DAY TO
SECOND) si
Durata_2 este 10 ani si 0 luni (fiind un INTERVAL YEAR TO
MONTH)

25

Exemplu
CREATE TABLE exemplu
(durata INTERVAL YEAR(3) TO MONTH);
INSERT INTO exemplu
VALUES (INTERVAL '120' MONTH);
SELECT TO_CHAR(SYSDATE+durata, 'DD-monFROM exemplu;

Exemplu
CREATE TABLE noi_carti
(codel NUMBER,
start_data TIMESTAMP);
INSERT INTO noi_carti
VALUES (1,TIMESTAMP '2009-10-31 09:26:50.30');
SELECT codel ,start_data
FROM noi_carti;

INSERT INTO noi_carti

VALUES (5, timestamp '12-02-08 0:0:0');
26

YYYY')

Pentru informatii de tip TIMESTAMP, numarul maxim de digiti

pentru fractiuni de secunda este 9, implicit este 6.
Rezultatele cererii:
1
31-OCT-09 09.26.50.300000 AM
5
08-FEB-12 12.00.00.000000 AM
Pentru informatii de tip DATE, formatul implicit ar fi fost
MON-RR
Valori valide pentru date
calendaristice
De la -4712 la 9999 (cu excepia
YEAR
anului 0).
MONTH
De la 01 la 12.
De la 01 la 31 (limitat de valorile
cmpurilor MONTH i YEAR,
DAY
corespunztor regulilor
calendarului curent).
HOUR
De la 00 la 23.
MINUTE
De la 00 la 59.
De la 00 la 59.9(n), unde 9(n)
SECOND
este precizia fraciunilor de
secund.
De la 12 la 13 (prevede
TIMEZONE_HOUR schimbrile datorate trecerilor la
ora de var sau iarn).
TIMEZONE_MINU
De la 00 la 59.
TE
Cmp

DD-

Valori valide pentru

intervale
Orice valoare ntreag.
De la 0 la 11.
Orice valoare ntreag.
De la 0 la 23.
De la 0 la 59.
De la 0 la 59.9(n), unde
9(n) este precizia
fraciunilor de secund.
Nu se aplic.
Nu se aplic.

Sistemul Oracle permite construcia de expresii folosind valori de

tip dat calendaristic i interval. Operaiile care pot fi utilizate n aceste
expresii i tipul rezultatelor obinute sunt urmtoarele:
Data + Interval, Data Interval, Interval + Data, iar rezultatul
este de tip dat calendaristic;
Data Data, Interval + Interval, Interval Interval, Interval *
Number, Number * Interval, Interval / Number, iar rezultatul este de tip
interval.

27

Modele de format
Un model de format este un literal caracter care descrie formatul
valorilor de tip DATE sau NUMBER stocate ntr-un ir de caractere.
Atunci cnd se convertete un ir de caractere ntr-o dat calendaristic
sau ntr-un numr, modelul de format indic sistemului cum s
interpreteze irul respectiv.
n instruciunile SQL se poate folosi un model de format ca
argument al funciilor TO_CHAR i TO_DATE. n felul acesta se poate
specifica formatul folosit de sistemul Oracle pentru a returna sau a stoca
o valoare n/din baza de date. Un model de format nu schimb
reprezentarea intern a valorii n baza de date.
O parte dintre elementele cel mai frecvent ntlnite ale unui format
de tip numeric sunt sintetizate n tabelul urmtor.
Element Exemplu Descriere
, (virgul) 9,999

. (punct)

99.99

$9999
0999;
9990

0
9

9999

C999

99D99

EEEE

9.9EEEE

L999

MI

9999MI

S9999;
9999S

Plaseaz o virgul n poziia specificat. ntr-un model de

format numeric pot fi precizate mai multe virgule, dar o
virgul nu poate aprea n partea dreapt a punctului
zecimal.
Plaseaz un punct zecimal n poziia specificat. ntr-un
format numeric, se poate specifica cel mult un punct
zecimal.
Include semnul $ n faa unei valori.
Plaseaz zerouri n faa sau la sfritul valorii.
ntoarce valoarea cu numrul specificat de cifre. Valoarea
va avea un spaiu, respectiv un minus n fa dac este
pozitiv, respectiv negativ.
Plaseaz n poziia specificat simbolul ISO pentru
monede(valoarea curent a parametrului
NLS_ISO_CURRENCY).
Plaseaz n poziia specificat caracterul zecimal, care este
valoarea curent a parametrului
NLS_NUMERIC_CHARACTER. Valoarea implicit este
punctul. Se poate specifica cel mult un caracter zecimal
ntr-un model de format numeric.
Returneaz o valoare folosind notaia tiinific.
ntoarce n poziia specificat simbolul monedei locale
(valoarea curent a parametrului NLS_CURRENCY).
Plaseaz semnul minus la sfritul valorilor negative i un
spaiu la sfritul celor pozitive. Acest element poate fi
specificat numai pe ultima poziie a modelului de format
numeric.
Plaseaz semnele plus sau minus la nceputul sau la
sfritul valorii. Acest element poate aprea doar pe prima

28

sau ultima poziie a modelului de format numeric.

Modelele de format pentru date calendaristice pot fi utilizate n

cadrul urmtoarelor funcii de conversie:
TO_DATE, pentru a converti o valoare de tip caracter, care este
ntr-un alt format dect cel implicit, ntr-o valoare de tip DATE;
TO_CHAR, pentru a converti o valoare de tip DATE, care este
ntr-un alt format dect cel implicit, ntr-un ir de caractere.
SYSDATE, pentru aflarea datei curente. De exemplu
SELECT SYSDATE FROM dual;
Un model de format pentru date calendaristice este alctuit dintrunul sau mai multe elemente specifice. Scrierea cu litere mari sau mici a
cuvintelor, abrevierilor sau a numeralelor romane este respectat n
elementul de format corespunztor.
De exemplu, modelul de format DAY produce cuvinte cu
majuscule, cum ar fi FRIDAY, iar Day i day au ca rezultat
Friday, respectiv friday.
ntr-un model de format pentru date calendaristice se pot preciza
semne de punctuaie i literale caracter, incluse ntre ghilimele. Toate
aceste caractere apar n valoarea returnat pe locul specificat n modelul
de format.
Element

Explicaie

AD sau A.D.

Indicatorul AD (Anno Domini) cu sau fr puncte.

BC sau B.C.

Indicatorul BC (Before Christ) cu sau fr puncte.

Numrul zilei din sptmn (1-7). Duminica este considerat prima

zi a sptmnii.

DAY

Numele zilei completat cu spaii, pn la lungimea de 9 caractere.

DD

Numrul zilei din lun (1-31).

DDD

Numrul zilei din an (1-366).

DY

Numele zilei din sptmn, printr-o abreviere de 3 litere.

FF

Fraciunile de secund.

HH sau HH12

Ora din zi (1-12).

HH24

Ora din zi (0-23).

MI

Minutele din or (0-59).

MM

Luna din an (01-12).

MON

Numele lunii, printr-o abreviere de 3 litere.

29

MONTH

Numele lunii completat cu spaii, pn la lungimea de 9 litere.

RM

Luna n cifre romane (I-XII).

RR

Anul cel mai apropiat de data curent.

RRRR

Accept intrarea att cu 2, ct i cu 4 cifre. Dac anul de intrare se d

cu 2 cifre, furnizeaz acelai lucru ca i formatul RR.

SS

Secundele din minut (0-59).

SSSSS

Secundele trecute de la miezul noptii (0-86399).

TZH

Ora regiunii.

TZM

Minutul regiunii.

Y,YYY

Anul scris cu virgul dup prima cifr.

YEAR sau SYEAR Anul n litere (S prefixeaz anii i.Hr. cu semnul minus).
YYYY sau SYYYY

Anul cu 4 cifre.

YYY, YY sau Y

Ultimele cifre ale anului.

Modificatorii FM i FX pot fi utilizai n modelele de format din

cadrul funciei TO_CHAR, controlnd completarea cu spaii i verificarea
exact a formatelor. Un modificator poate s apar ntr-un model de
format de mai multe ori. n acest caz, efectele sale sunt active pentru
poriunea din model care ncepe la prima apariie i apoi dezactivate
pentru poriunea din model care urmeaz celei de-a doua apariii .a.m.d.
Modificatorul FM (Fill Mode) suprim completarea cu spaii n
valoarea returnat de funcia TO_CHAR, iar FX (Format eXact) impune
corespondena exact dintre argumentul de tip caracter i modelul de
format precizat pentru data calendaristic respectiv.
Exemplu:
SELECT nume, TO_CHAR(data_ang,Month FMDD,YYYY) angajare
FROM angajati
WHERE TO_CHAR(data_ang, YYYY)=2009;
Nume
Pop
Ene

Angajare
January 21,2009
October 10,2009

Exemplu
SELECT nume, TO_CHAR(data_ang, DDTH of Month YYYY)
angajare
FROM angajati
WHERE TO_CHAR(data_ang, YYYY)=2009;

30

Nume
Pop
Ene

Angajare
21st of January 2009
10TH of October 2009

Exemplu
SELECT TO_CHAR(data_ang, fmDDspth Month.Year) angajare
FROM angajati
WHERE id_ang=100;
Angajare
Twenty_NineTH July, Two Thousand Nine
Exemplu
SELECT sesiune incepe pe || TO_DATE(20-09-2010,DD-MMYYYY) from dual;
Sesiunea incepe pe 20-09-2010
(Afieaz formatul standard pentru dat)
Valoarea null, reprezentnd lipsa datelor, nu este egal sau diferit
de nici o alt valoare, inclusiv null.
Totui, exist dou situaii n care sistemul Oracle consider dou
valori null ca fiind egale: la evaluarea funciei DECODE i dac valorile
null apar n chei compuse. Dou chei compuse care conin valori null sunt
considerate identice dac toate componentele diferite de null sunt egale.
Pseudocoloane

O pseudocoloan se comport ca i o coloan a unui tabel, dar nu

este stocat efectiv ntr-un tabel. Se pot face interogri asupra
pseudocoloanelor, dar nu se pot insera, actualiza sau terge valorile
acestora.
LEVEL returneaz nivelul liniilor rezultat ale unei cereri
ierarhice.
CURRVAL i NEXTVAL sunt pseudocoloane utile n lucrul cu
secvene i sunt tratate n seciunea corespunztoare acestora.
ROWID returneaz adresa unei linii din baza de date, furniznd
modul cel mai rapid de a accesa linia respectiv. n sistemul Oracle,
valorile acestei pseudocoloane conin urmtoarele informaii necesare
pentru a localiza o linie: numrul obiectului, blocul de date, fiierul de
date, linia n cadrul blocului de date. Valorile pseudocoloanei ROWID
sunt de tipul ROWID sau UROWID.
ROWNUM returneaz numrul de ordine al liniilor rezultate n

31

urma execuiei unei cereri. Pseudocoloana poate fi utilizat pentru a

limita numrul de linii returnate. Dac este folosit clauza ORDER BY
ntr-o subcerere, iar condiia n care apare ROWNUM este plasat n
cererea de nivel superior, atunci condiia va fi aplicat dup ordonarea
liniilor.
Exemplu:
S se afieze informaii despre operele de art avnd cele mai mici
10 coduri.
SELECT *
FROM (SELECT * FROM opera ORDER BY
WHERE ROWNUM < 11;

cod_opera)

Instruciuni DDL (Data Definition Language)

Instruciunile DDL (Data Definition Language) definesc obiectele
bazei de date, dar nu insereaz i nu actualizeaz date n obiectele
respective. n SQL, exist trei comenzi de baz pentru instruciunile
DDL:
CREATE - Creeaz n baza de date un nou obiect, de tipul
specificat n instruciune : CREATE DATABASE, CREATE TABLE,
CREATE INDEX i CREATE VIEW.
ALTER - Modific definiia unui obiect existent n baza de
date, de tipul specificat n instruciune : ALTER TABLE, ALTER
DATABASE, ALTER SYSTEM, ALTER USER, ALTER SESSION.
D R O P - terge (distruge) un obiect existent n baza de date, de
tipul specificat n instruciune.
Instruciunea CREATE DATABASE
Definirea unei baze de date difer destul de mult de la o
implementare la alta. Sintaxa general pentru instruciunea CREATE
DATABASE este:
CREATE DATABASE nume bazadedate [opiuni_specifice
_productorul]
n Oracle, instruciunea CREATE USER creaz n baza de date o
schem, cere este aproximativ echivalent cu o baz de date.
32

Standardul SQL prevede i o instruciune CREATE SCHEMA,

care permite crearea unor grupuri de obiecte din baza de date, pentru
simplificarea administrrii.

MPAA_RATING
MPAA_COD_RATING
MPAA_DESCRIERE_VARSTE

PK

FILM_LIMBA
FILM_ID
COD_LIMBA

PK,FK1
PK,FK2

FILM
FILM_ID
FILM_COD_GEN
MPAA_COD_RATING
FILM_NUME
RETAIL_PRET_VHS
RETAIL_PRET_DVD
AN_PRODUS

FILM_COPII
FILM_ID
NUMAR_COPIE
DATA_CUMPARARE
DATA_VANZARE
FORMAT_MEDIA

PK
FK1
FK2

PK,FK1
PK

FILM_GEN
FILM_COD_GEN
FILM_DESCRIERE_GEN

PK

FILM_INCHIRIERE
FILM_ID
PK,FK1
NUMAR_COPIE
PK,FK1
TRANZACTIE_ID
PK,FK2
DATA_INTOARCERE
COST_INCHIRIERE
COST_INTARZIERE_SAU_PIERDERE
DATA_RETURNARE

LIMBA
COD_LIMBA
NUME_LIMBA

CLIENT_COD_PERSOANA
CLIENT_CONT_ID
PERSOANA_ID

PERSOANA
PERSOANA_ID
PERSOANA_PRENUME
PERSOANA_NUME_MIJLOCIU
PERSOANA_NUME
PERSOANA_ADRESA_1
PERSOANA_ADRESA_2
PERSOANA_ADRESA_ORAS
PERSOANA_ADRESA_JUDET_PROV
PERSOANA_ADRESA_COD_POSTAL
PERSOANA_ADRESA_TARA
PERSOANA_TELEFON
NASTERE_DATA
MOARTE_DATA

PK

PK,FK1
PK,FK2

CLIENT_CONT
CLIENT_CONT_ID
PK
CLIENT_HOLD_IND
DATA_INSCRIS
DATA_TERMINAT
CLIENT_DEPOZIT_SUMA
CARD_CREDIT_LA_DOSAR_INDIC
COPIL_INCHIRIERE_PERMIS_INDIC

CLIENT_TRANZACTIE
TRANZACTIE_ID
CLIENT_CONT_ID
ANGAJAT_PERSOANA_ID
TRANZACTIE_DATA
VANZARI_TAXA

ANGAJAT
PERSOANA_ID
SUPERVISOR_PERSOANA_ID
ANGAJAT_TAXA_ID
ANGAJAT_JOB_CATEGORIE
ANGAJAT_RATA_PE_ORA
ANGAJARE_DATA
INCHIDERE_DATA

PK

33

PK
FK1

PK,FK1

Exemplu de Diagrama conceptual

Exemplele din lucrare se refer la un model de gestiune a operelor
de art dintr-un muzeu. Diagrama entitate-relaie (E/R) corespunztoare
modelului analizat este prezentat n figura 2.1.
Schemele relaionale corespunztoare diagramei conceptuale sunt:
OPERA(cod_opera#, tip, titlu, cod_artist, data_crearii,
data_achizitiei, valoare, cod_galerie, cod_sala,
material, stil,
dim1, dim2, stare);
GALERIE(cod_galerie#, nume_galerie, nume_cladire, adresa);
SALA(cod_sala#, cod_galerie#, nume_sala, suprafata);
SECURITATE(cod_opera#, sistem#, descriere, valoare,
data_inst, firma, executant);
POLITA_ASIG(cod_opera, cod_polita#, descriere, firma,
valoare, semnat_contract);
SPECIALIST(cod_specialist#, nume, prenume, experienta,
autorizatie, tip, loc);
ARTIST(cod_artist#, nume, prenume, an_nastere, an_moarte,
nationalitate, observatii);
SURSA_BIBLIO(cod_sursa#, tip, titlu);
ARTICOL(cod_sursa#,
nume_revista,
nr_revista,
data,
pag_revista);
CARTE(cod_sursa#, an, editura, ISBN);
AUTOR(cod_autor#, nume, prenume, descriere, job, adresa);
EXPOZITIE(cod_expo#, nume_expo, tip);
STUDIAZA(cod_opera#, cod_specialist#, data#, operatia,
metode, rezultat, plata);
MENTIONATA_IN(cod_opera#, cod_sursa#, pagina#);
FIGUREAZA_IN(cod_opera#,
cod_expo#,
cond_speciale,
localitate, data_inceput);
EDITATA_DE(cod_sursa#, cod_autor#);
ORGANIZATA_DE(cod_organizator#, cod_expozitie#);
ORGANIZATOR(cod_organizator#,
nume, tip_organizator,
adresa).
Numele atributelor corespunztoare relaiilor menionate sunt
sugestive, astfel nct semnificaia lor este evident. Se pot face
urmtoarele precizri:
cmpul tip din tabelul opera este un ir de caractere ce
reprezint categoria n care se ncadreaz opera de art
respectiv (pictur, sculptur, grafic, tapiserie etc.);

34

 material este un cmp de tip ir de caractere, ale crui valori

specific materialul din care a fost conceput opera de art
(hrtie, pnz, bronz, aram, piatr etc.);
stil este un atribut de tip ir de caractere ce precizeaz stilul n
care se ncadreaz opera de art respectiv (clasic, renascentist,
contemporan, impresionist etc.);
dim1, dim2 sunt coloane numerice care specific dimensiunile
operei;
stare este un atribut de tip ir de caractere care precizeaz starea
fizic a operei de art respective (medie, bun, foarte bun etc.);
cmpul tip din tabelul specialist precizeaz calificarea unui
specialist (expert, restaurator, evaluator etc.);
loc reprezint ara care a emis autorizaia corespunztoare unui
specialist;
operatia specific aciunea la care este supus opera de art
(lipire, retuare, curare etc.);
atributul metode specific procedeele utilizate n realizarea
operaiei (infraroii, ultrasunete, raze X etc.);
cmpul rezultat reine informaii asupra expertizei efectuate
(dac opera de art este un fals, nivelul restaurrii etc.);
cmpul tip din tabelul sursa_biblio precizeaz categoria
publicaiei n care apar referine la opera de art respectiv
(articol, studiu, monografie etc.);
cmpul job specific profesia autorului unei surse bibliografice
(profesor, expert, artist, jurnalist etc.);
atributul observatii conine informaii referitoare la artiti
(pseudonim, curentul artistic de care aparin etc.);
cmpul tip din tabelul expozitie precizeaz categoria din care
face parte o expoziie (fix, itinerant, temporar etc.).

35

GALERIE
cod_galerie
#

inclusa_in

M(1)

SALA
cod_sala#
cod_galerie#

1
cuprinsa_in

M(1)
1

ARTIST

creata_de

M(1)

SECURITATE

protejata_prin

M(0)

asigurata_de

M(0)

sistem#

OPERA
cod_opera#

cod_artist#

cod_opera#

POLITA_ASIG
cod_polita#

M(1)
M(1)

M(1)

mentionata_in

studiaza

M(0)
M(0)

SURSA_BIBLIO
cod_sursa#
tip

SPECIALIST
cod_specialist#

ARTICOL

CARTE

figureaza_in

M(0)

EXPOZITIE

M(1)

organizata_de

M(1)

ORGANIZATOR

M(1)
editata_de

cod_expo#

cod_organizator#

M(1)

AUTOR
cod_autor
#

Figura 2.1. Diagrama E/R a modelului de gestiune a operelor de

art dintr-un muzeu

36

Asupra modelului considerat sunt definite anumite restricii.

Conform acestora, o oper de art poate:
avea fie un singur autor, fie autor necunoscut;
avea mai multe sisteme de securitate instalate;
fi asigurat la mai multe firme;
fi menionat n aceeai surs bibliografic, la pagini diferite.

Instruciunea CREATE TABLE

CREATE TABLE este una din instruciunile fundamentale din
SQL. Modelul relaional cere ca toate datele stocate s fie ancorate ntrun tabel, aa c posibilitatea de a stoca orice ntr-o baz de date ncepe
ntotdeauna cu crearea unui tabel.
Crearea unui tabel const din generarea structurii sale, adic
atribuirea unui nume tabelului i definirea caracteristicelor sale (se
definesc coloanele, se definesc constrngerile de integritate, se specific
parametrii de stocare etc.).
n Oracle9i tabelele pot fi create n orice moment, chiar i n
timpul utilizrii bazei. Structura unui tabel poate fi modificat online. Nu
este necesar s se specifice dimensiunea acestuia. Totui, din
considerente administrative, este important s se cunoasc estimativ ct
spaiu va utiliza tabelul.
Sintaxa de baz pentru instruciunea CREATE TABLE este:
CREATE TABLE nume_tabel
(<definiie_coloan>
[,<definiie_coloan> ...])
[,<restricietabel>... ];
Definirea coloanelor n SQL DDL
Sintaxa de baz folosit pentru definirea coloanelor unui tabel este:
<definiie_coloan>
nume coloan tip_de_date
[DEFAULT expresie]
[NULL | NOT NULL]

37

[<restricie_coloan>]
Componentele din definiia unei coloane sunt:
Numele coloanei - Numele coloanei trebuie s fie unic n cadrul
tabelului.
Tipul de date - Tipul de date trebuie s fie un tip de date valid
pentru implementarea SGBD
Restrictiile coloanei care sunt prezentate n continuare
Structura unui tabel poate fi creat n urmtoarele patru moduri:

fr a indica cheile;
indicnd cheile la nivel de coloan;
indicnd cheile la nivel de tabel;
prin copiere din alt tabel.

Exemplu : Gestiunea activitilor de mprumut dintr-o bibliotec

M(0)

M(1)
CARTE
codel#
titlu
autor
pret
nrex
coded

imprumuta

M(0)
apartine

CITITOR
codec#
nume
dep

DOMENIU
coded#
intdom

1. Crearea structurii unui tabel fr a indica cheile:

CREATE TABLE

carte

(codel

CHAR(5),

titlu

VARCHAR2(30),

autor

VARCHAR2(30),

pret

NUMBER(8,2),

nrex
coded

NUMBER(3),
CHAR(5));

2. Crearea structurii unui tabel indicnd cheile la nivel coloan:

38

CREATE TABLE
(codel
titlu
autor
pret
nrex
coded

carte
CHAR(5) PRIMARY KEY,
VARCHAR2(30),
VARCHAR2(30),
NUMBER(8,2),
NUMBER(3),
CHAR(5) NOT NULL
REFERENCES domeniu(coded));

Constrngerea de cheie primar sau extern ce presupune?

CREATE TABLE carte
(codel
CHAR(5) PRIMARY KEY,
titlu
VARCHAR2(30),
autor
VARCHAR2(30),
pret
NUMBER(8,2),
nrex
NUMBER(3),
coded
CHAR(5) NOT NULL
REFERENCES domeniu(coded)
ON DELETE CASCADE);
CREATE TABLE domeniu
(coded
CHAR(5) PRIMARY KEY,
den_dom VARCHAR2(30));
CREATE TABLE cititor
(codec
CHAR(5) PRIMARY KEY,
den_cititor VARCHAR2(30));

Opiunea ON DELETE CASCADE specific c suprimarea oricrui

domeniu de carte din tabelul domeniu este autorizat i implic
suprimarea automat a tuturor crilor din domeniul respectiv care se
gsesc n tabelul carte.
3. Crearea structurii unui tabel indicnd cheile la nivel de tabel:
CREATE TABLE carte
(codel
CHAR(5),
titlu
VARCHAR2(30),
autor
VARCHAR2(30),
pret
NUMBER(8,2),
nrex
NUMBER(3),
coded
CHAR(5) NOT NULL,
PRIMARY KEY (codel),
FOREIGN KEY (coded)

39

REFERENCES domeniu (coded));

Dac cheia primar are mai mult de o coloan atunci cheile trebuie
indicate la nivel de tabel.
CREATE TABLE imprumuta
(codel
CHAR(5),
codec
CHAR(5),
dataim DATE DEFAULT SYSDATE,
datares DATE,
dataef
DATE,
PRIMARY KEY (codel, codec, dataim),
FOREIGN KEY (codel)
REFERENCES carte(codel),
FOREIGN KEY (codec)
REFERENCES cititor(codec));
INSERT INTO domeniu
VALUES(I, Informatica);
INSERT INTO carte
VALUES(bnat1, Baza_de_Date, Popescu_Ioana, 300.50, 100,I);
4. Crearea structurii unui tabel prin copiere din alt tabel:
CREATE TABLE
carte_info
AS SELECT codel, titlu, autor
FROM
carte
WHERE
coded = I;

40

Constrngeri
Constrngerea este un mecanism care asigur c valorile unei
coloane sau a unei mulimi de coloane satisfac o condiie declarat. Unei
constrgeri i se poate da un nume unic. Dac nu se specific un nume
explicit atunci sistemul automat i atribuie un nume de forma SYS_Cn,
unde n reprezint numrul constrngerii. Constrngerile pot fi terse, pot
fi adugate, pot fi activate sau dezactivate, dar nu pot fi modificate.
Restriciile coloanelor
Restriciile unei coloane limiteaz ntr-un mod oarecare valorile ce
pot fi stocate ntr-o coloan a unui tabel. Restriciile coloanelor pot avea
oricare dintre urmtoarele forme:
Exemplu, crearea tabelului CONT_CLIENT, din baza de date a
magazinului de produse video.
CREATE TABLE CONT_CLIENT
(
ID_CONT_CLIENT INTEGER NOT NULL,
STARE_CONT_CLIENT CHAR(1) DEFAULT N NOT NULL
CHECK (STARE_CONT_CLIENT IN (Y, N)),
DATA_INSCRIERE DATE NOT NULL,
DATA_INCHEIERE DATE NULL,
SUMA_DEPOZIT_CLIENT NUMERIC(5,2) NULL,
IND_CREDIT_CARD CHAR(1) NOT NULL
CHECK (IND_CREDIT_CARD IN (Y, N)),
INDIC_PERMIS_INCHIRIERE_COPIL CHAR(1) NOT NULL
CHECK(INDIC_PERMIS_INCHIRIERE_COPIL IN(Y,N)),
PRIMARY KEY (ID_CONT_CLIENT)
);
Descriere tabel:
ID_CONT_CLIENT - cheie primara
STARE_CONT_CLIENT de tip DA/NU, care indica daca un cont este sau nu
blocat.(inchirierile nu sunt permise pt conturile blocate)
DATA_INSCRIERE - data la care s-a deschis contul in magazin
DATA_INCHEIERE - daca contul a fost inchis contine data; daca contul e activ
contine NULL
41

SUMA_DEPOZIT_CLIENT pt clientii care nu au carte de credit, suma lasata ca

depozit in magazin
IND_CREDIT_CARD - de tip DA/NU, care indica daca un client a lasat inf despre
carte de credit, pt a garanta platile asociate contului.
INDIC_PERMIS_INCHIRIERE_COPIL
- de tip DA/NU, care indica daca
uncopil<18 ani are voie sa inchirieze filme folosind acest cont

Clauza DEFAULT - O expresie care este aplicat coloanei atunci

cnd n tabel este inserat un nou rnd, care nu conine o valoare
explicit pentru coloana respectiv. Expresia poate fi orice expresie
valid. Sintaxa SQL cu o clauz DEFAULT este:
[DEFAULT expresie]
Exemplu:
STARE_CONT_CLIENT CHAR(1) DEFAULT 'N' NOT NULL
(la creare are val N , adica contul nu e blocat)
Restricia NULL | NOT NULL - Specificarea cuvntului cheie
NULL permite stocarca valorilor nule ntr-o coloan, n timp ce NOT
NULL nu permite stocarca valorilor nule n coloana respectiv. O
restricie NOT NULL poate fi scris i sub forma unei restricii
CHECK cu condiia IS NOT NULL.
Sintaxa SQL i cteva exemple:
NULL | NOT NULL
Exemple:
DATA_INSCRIERE DATE NOT NULL
DATA_INCHEIERE DATE NULL
Restricia CHECK - O restricie de verificare (check) poate fl
folosit pentru impunerea unei reguli care poate fi aplicat unei
singure coloane a unui tabel. Condiia inclus n restricie trebuie s
fie ndeplinit ori de cte ori datele din coloana respectiv a
tabelului sunt modificate n caz contrar, sistemul SGBD va
respinge modificarea i va afia un mesaj de eroare.
Sintaxa restriciei CHECK i un exemplu:
[CONSTRAINT nume restricie] CHECK (condiie)
Exemplu:
IND_CREDIT_CARD CHAR(1) NOT NULL,
CHECK (CREDIT_CARD_INDIC IN (Y, N))
Clauz NOT NULL poate fi rescris i sub forma unei restricii
CHECK:
ID_CONT_CLIENT INTEGER

42

CONSTRAINT CK_CUST _ACCT _ID

CHECK (ID_CONT IS NOT NULL)
Restricia UNIQUE - O restricie UNIQUE impus asupra unei
coloane garanteaz unicitatea valorilor din coloana respectiv a
tabelului. Sintaxa:
[CONSTRAINT nume_restricie] UNIQUE
Exemplu:
ID_CONT_CLIENT INTEGER UNIQUE
Restricia PRIMARY KEY - O restricie de cheie primar
(PRIMARY KEY) impus asupra unei coloane declar coloana
respectiv ca fiind cheia primar a tabelului, ceea ce nseamn c n
coloana respectiv nu pot exista valori nule, iar valorile trebuie s fie
unice n cadrul tabelului.
Sintaxa :
(CONSTRAINT nume_restricie] PRIMARY KEY
Exemplu:
ID_CONT_CLIENT INTEGER PRIMARY KEY
Restricia referential (FOREIGN KEY) - O restricie
referenial impus asupra unei coloane (numit i restricie de cheie
extern) definete relaia dintre o cheie extern i o cheie primar.
Sintaxa:
[CONSTRAINT nume_restricie]
REFERENCES nume_tabel(nume_coloan)
[ON DELETE CASCADE | ON DELETE SET NULL]
Exemplu:
MPAA_CODE_RATING din tabelul FILME este cheie extern
pentru tabelul MPPA_RATING, care are cmpurile:
MPAA_CODE_RATING i MPAA__RATING _DESCRIERE
MPAA_COD_RATING CHAR (5) NOT NULL
REFERENCES MPPA_RATING(MPAA_CODE_RATING)
Clauza opional ON DELETE spune sistemului SGBD ce s fac
atunci cnd este ters rndul referit din tabelul printe cu opiunea de
a terge toate rndurile care conin cheia extern (CASCADE) sau de a
insera valori nule pentru toate cheile externe (SET NULL).

43

Restriciile tabelelor
Restricia unei coloane poate fi rescris i ca restricie a ntregului
tabel, astfel nct clauza care definete restricia s apar n instruciunea
CREATE TABLE dup definiiile tuturor coloanelor, nu dup definiia
unei coloane. Principalul avantaj al restriciilor la nivelul tabelului este c
pot referi mai multe coloane.
Restricia CHECK
[CONSTRAINT nume_restricie] CHECK (condiie)
Restricia de mai jos mpiedic stocarea unei valori negative n
coloana SUMA_DEPOZITE_CLIENT . Operatorul OR permite stocarea
valorilor nule , deoarece o valoare nulA nu este mai mare sau egal cu
zero.

Exemplu:
CONSTRAINT CK_SUMA_DEPOZITE_CLIENT
CHECK (SUMA_DEPOZITE_CLIENT >= 0 OR
SUMA_DEPOZITE_CLIENT IS NULL)

Restricia UNIQUE
[CONSTRAINT nume_restricie) UNIQUE (nume_coloan
[,nume coloan...])
Conform acestei restricii , combinaia de coloane
ID_CONT_CLIENT i DATA_INSCRIERE trebuie s fie unic
n rndurile din tabel.
Exemplu:
CONSTRAINT UK_DATA_INSCR_CONT_CL
UNIQUE (ID_CONT_CLIENT, DATA_INSCRIERE )

Restricia PRIMARY KEY

[CONSTRAINT nume_restricie]
PRIMARY KEY (nume_coloan [,nume_coloan...])
Restricia de mai jos este chiar definiia cheii primare din tabelul
CONT_CLIENT [
Exemplu:
CONSTRAINT PK_CONT_CLIENT
PRIMARY KEY (ID_CONT_CLIENT)

Restricia referenial (FOREIGN KEY)

44

Spre deosebire de forma pentru restricia referenial a coloanei,

aceasta poate referi mai multe coloane.
[CONSTRAINT nume_restricie]
FOREIGN KEY (nume_coloan [,nume coloan...])
REFERENCES nume_tabel (nume_coloan [,nume_coloan...
[ON DELETE CASCADE |ON DELETE SET NULL]
Exemple de constrngeri la nivel de coloan i tabel pentru
gestiunea crilor dintr-o bibliotec.
Exemple:
1. S se defineasc o constrngere la nivel de coloan prin care s
se specifice cheia primar i cheia extern.
CREATE TABLE carte
(codel CHAR(5)
CONSTRAINT cp_carte PRIMARY KEY,
Titlu
VARCHAR2(30),
autor
VARCHAR2(30),
pret
NUMBER(8,2),
nrex
NUMBER(3),
coded
CHAR(5)
CONSTRAINT nn_coded NOT NULL
CONSTRAINT ce_coded
REFERENCES domeniu(coded));
2. S se defineasc o constrngere la nivel de tabel prin care s se
specifice cheia primar i cheia extern.
CREATE TABLE carte
(codel

CHAR(5),

titlu
VARCHAR2(30),
autor
VARCHAR2(30),
pret
NUMBER(8,2),
nrex
NUMBER(3),
coded
CHAR(5) NOT NULL,
CONSTRAINT cp_carte PRIMARY KEY (codel),
CONSTRAINT ce_coded FOREIGN KEY (coded)
REFERENCES domeniu(coded));

45

Observaii:
Liniile ce nu respect constngerea sunt depuse automat ntr-un
tabel special.
Constrngerile previn tergerea unui tabel dac exist
dependene.
Constrngerile pot fi create o dat cu tabelul sau dup ce acesta
a fost creat.
Constrngerile pot fi activate sau dezactivate n funcie de
necesiti.
Constrngeri declarative pot fi: constrngeri de domeniu,
constrngerea de integritate a entitii, constrngerea de integritate
referenial.
Constrngerile de domeniu definesc valori luate de un atribut
(DEFAULT, CHECK, UNIQUE, NOT NULL).
constrngerea (coloan) DEFAULT ;
constrngerea (coloan sau tabel) CHECK ; constrngerea CHECK la
nivel de tabel poate compara coloane ntre ele, poate face referin la
una sau mai multe coloane, dar nu poate conine subcereri.
Constrngerea la nivel de coloan nu poate referi alte coloane ale
aceluiai tabel.
CREATE TABLE carte
(codel
CHAR(5),
nrex
NUMBER(3),
pret
NUMBER(8,2)
CONSTRAINT alfa
CHECK (pret < nrex),);
La execuia acestei comenzi apare mesajul: ORA 02438: Column
check constraint cannot reference other columns.
Dac dup NUMBER(8,2) se adaug o virgul, atunci
constrngerea va fi la nivel de tabel, iar n aceste caz este permis
referirea altei coloane.
constrngerea (coloan sau tabel) UNIQUE ;
constrngerea declarativ NOT NULL poate fi doar la nivel coloan.
Constrngerea de integritate a entitii precizeaz cheia primar
a unui tabel. Cnd se creeaz cheia primar se genereaz automat un
index unic. Valorile cheii primare sunt distincte i diferite de valoarea
null.

46

Constrngerea de integritate referenial asigur coerena ntre

cheile primare i cheile externe corespunztoare. Cnd este definit o
cheie extern sistemul Oracle verific:

dac a fost definit o cheie primar pentru tabelul referit de

cheia extern;
dac numrul coloanelor ce compun cheia extern corespunde
numrului de coloane a cheii primare;
dac tipul i lungimea fiecrei coloane a cheii externe
corespunde cu tipul i lungimea fiecrei coloane a cheii
primare.

Aceast constrngere poate fi definit la nivel de coloan sau tabel

i asigur coerena ntre cheile primare i cheile externe corespunztoare.
Constrngerea FOREIGN KEY desemneaz o coloan sau o combinaie
de coloane drept cheie extern i stabilete relaia cu o cheie primar sau
o cheie unic din acelai tabel sau din altul.
O cheie extern compus poate fi definit doar la nivel de tabel.
Cheia extern se definete n tabelul copil, iar tabelul care
conine coloana referit reprezint tabelul printe. Valoarea unei chei
externe trebuie s fie egal cu o valoare existent n tabelul printe sau
s fie null. Cheile externe se bazeaz pe valorile datelor i sunt pointer-i
logici.
Cheile externe se definesc folosind urmtoarele cuvinte cheie:
FOREIGN KEY este utilizat ntr-o constrngere la nivel de
tabel pentru a defini coloana din tabelul copil;
REFERENCES identific tabelul printe i coloana
corespunztoare din acest tabel;
ON DELETE CASCADE determin ca, odat cu tergerea unei
linii din tabelul printe, s fie terse i liniile dependente din
tabelul copil;
ON DELETE SET NULL determin modificarea automat a
valorilor cheii externe la valoarea null, atunci cnd se terge
valoarea printe.
Definiiile i numele constrngerilor definite se pot fi consulta prin
interogarea vizualizrilor USER_CONSTRAINTS i ALL_CONSTRAINTS
din dicionarul datelor (Desc USER_CONSTRAINTS;)

Modificarea structurii unui tabel

47

Comanda care realizeaz modificarea structurii tabelului (la nivel de

coloan sau la nivel de tabel), dar nu modificarea coninutului acestuia,
este ALTER TABLE.

Instruciunea ALTER TABLE

Instruciunea ALTER TABLE ajut s se fac modificri asupra
tabelelor create. Utilizarea instruciunii ALTER TABLE este un alt
domeniu n care au un rol important stilul i preferinele personale.
Muli administratori de baze de date prefer s foloseasc instrucuni
CREATE TABLE ct mai simple, evitnd s defineasc
restricii n instruciunile CREATE TABLE.
Acetia adaug dup instruciunea CREATE TABLE
instruciuni ALTER TABLE prin care specific toate restriciile necesare
(cheie primar, cheie extern, unicitate, verificare). Dezavantajul
acestei metode este acela c necesit scrierea unei cantiti mai mari
de cod. Pe de alt parte, instruciunea CREATE TABLE este mult
mai uor de neles fr restricii, iar scrierea separat a restriciilor
simplific refolosirea instruciunilor.
Comanda ALTER TABLE permite:
adugarea (ADD) de coloane, chei (primare sau externe),
constrngeri ntr-un tabel existent;
modificarea (MODIFY) coloanelor unui tabel;
specificarea unei valori implicite pentru o coloan existent;
activarea i dezactivarea
constrngeri;
suprimarea unei coloane;

(ENABLE,

DISABLE)

unor

suprimarea (DROP) cheii primare, a cheii externe sau a unor

constrngeri.
Comanda ALTER TABLE are urmtoarea sintax simplificat:
ALTER TABLE [<nume_schema>.] <nume_tabel>
[ADD
(<nume_coloana> <tip_date>, <constrngere>) |
MODIFY
(<nume_coloana_1>,, <nume_coloana_n>) |
DROP
<clauza_drop>,]
[ENABLE | DISABLE <clause>];

48

 Adugarea unei coloane la un tabel. Definirea coloanei se face cu

aceeai sintax ca i n cazul instruciunii CREATE TABLE. Nu se
poate specifica unde s apar coloana, ea devenind ultima coloan a
tabelului.
ALTER TABLE nume_tabel
ADD ( <definiie_co1oan>
[,<definiie_co1oan>
Exemplu:
ALTER TABLE CONT_CLIENT
ADD (DATA_CLIENT DATE,
INTRODUSE_DE VARCHAR(50));
ALTER TABLE CITITOR
ADD (ADRESA VARCHAR(50));
ALTER TABLE carte
ADD(rezumat LONG);

Modificarca definiiei unei coloane. Majoritatea SGBD-urilor

nu permit s scdei precizia unei coloane dac tabelul conine
date i foarte puine permit s se schimbe tipul de date al unei
coloane existente. Sunt acceptate creterea preciziei unei coloane,
adugarea sau modificarea valorii prestabilite pentru o coloan, i
trcerea de la NULL la NOT NULL sau invers.
ALTER TABLE nume_tabel
MODIFY [COLUMN] (<definiie coloan>
[,<definiie_co1oan> ...]);
Exemplu:
ALTER TABLE CONT_CLIENT
MODIFY (SUMA_DEPOZIT_CLIENT NUMERIC(7,2)
DEFAULT 0 NOT NULL);

49

 Adugarea unei restricii. Definiia restriciei este identic cu

definiia unei restricii care ar putea aprea ntr-o instruciune
CREATE TABLE.
ALTER TABLE nume_tabel
ADD CONSTRAINT <definiie_restricie>;
Exemplu:
ALTER TABLE CONT_CLIENT
ADD CONSTRAINT CK_SUMA_DEPOZIT_CLIENT
CHECK (SUMA_DEPOZIT_CLIENT >= 0
OR SUMA_DEPOZIT_CLIENT IS NULL);

Dac pun o valoare negativ la suma, atunci apare eroare .

CREATE TABLE carte

(CODEL char(5),
);
ALTER TABLE carte
ADD CONSTRAINT cheie_prim PRIMARY KEY (codel);
tergerea cheii primare a unui tabel.
Dac cheia primar este referit de restricii refereniale, trebuie
mai nti terse restriciile respective.
ALTER TABLE nume_tabel DROP PRIMARY KEY;
Dac exist o CE care refer o CP i dac se ncearc tergerea cheii
primare, aceast tergere nu se poate realiza (tabelele sunt legate
prin declaraia de cheie extern). tergerea este totui permis dac
50

n comanda ALTER apare opiunea CASCADE, care determin i

tergerea cheilor externe ce refer cheia primar.
ALTER TABLE domeniu
DROP PRIMARY KEY CASCADE;
tergerea cheii externe se face ca si pentru tergerea cheii
primare
ALTER TABLE
carte
ADD CONSTRAINT
beta
FOREIGN KEY (coded) REFERENCES domeniu;
Schimbarea cheii primare. Este destul de complicat procesul
schimbrii cheii primare fr a afecta modul de proiectare a bazei
de date. Schimbarea se face n dou etape: se terge cheia
primar i apoi se recreeaz.
ALTER TABLE carte
ADD (PRIMARY KEY(codel));
ALTER TABLE carte
DROP PRIMARY KEY;
ALTER TABLE carte
ADD
PRIMARY KEY(titlu, autor));
Redenumirea unei coloane.
Dintre bazele de date care accept aceast sintax este numai
Oracle, ncepnd cu versiunea 8.0
ALTER TABLE nume_tabel
RENAME COLUMN nume_vechi_coloan TO nume
_nou_coloan;
ALTER TABLE timp
RENAME COLUMN durata_1 TO dur_1;
ALTER TABLE timp
RENAME COLUMN durata_2 TO dur_2;

51

 Pentru a activa
constrngeri:
ALTER TABLE
ENABLE

(ENABLE)

sau

dezactiva

(DISABLE)

nume_tabel
nume_constrangere;

ALTER TABLE
DROP CONSTRAINT

carte
beta;

ALTER TABLE
ADD CONSTRAINT

cititor

cp_cititor
PRIMARY KEY (codec)
DISABLE;
ALTER TABLE
cititor
ENABLE CONSTRAINT cp_cititor;
Stergerea unei coloane se face ca i a unei constringeri;
ALTER TABLE nume_tabel
DROP nume_coloana;
ALTER TABLE CONT_CLIENT
DROP (DATA_CLIENT ,INTRODUSE_DE );

Observaii
Nu se poate specifica poziia unei coloane noi n structura tabelului. O
coloan nou devine automat ultima n cadrul structurii tabelului.

52

 Modificarea unei coloane presupune schimbarea tipului de date, a

dimensiunii sau a valorii implicite a acesteia. O schimbare a valorii
implicite afecteaz numai inserrile care succed modificrii.
Dimensiunea unei coloane numerice sau de tip caracter poate fi
mrit, dar nu poate fi micorat dect dac acea coloan conine
numai valori null sau dac tabelul nu conine nici o linie.
Tipul de date al unei coloane poate fi modificat doar dac valorile
coloanei respective sunt null.
Alte opiuni ale comenzii ALTER TABLE, care au aprut ncepnd cu
versiunea Oracle8i, sunt SET UNUSED i DROP UNUSED
COLUMNS:
ALTER TABLE nume_tabel
ET UNUSED [ ( ] nume_coloan [ ) ];
ALTER TABLE nume_tabel
DROP UNUSED COLUMNS;
Opiunea SET UNUSED permite marcarea uneia sau mai multor
coloane ca fiind nefolosite, cu scopul de a fi terse atunci cnd
necesitile sistemului impun acest lucru. Coloanele nefolosite sunt tratate
ca i cum ar fi fost suprimate, dei datele acestora rmn n liniile
tabelului. Dup ce o coloan a fost marcat UNUSED, utilizatorul nu mai
are acces la aceasta prin intermediul cererilor. n plus, numele i tipurile
de date ale coloanelor nefolosite nu vor fi afiate cu comanda DESCRIBE
din SQL*Plus. Utilizatorul poate s adauge tabelului o nou coloan
avnd acelai nume cu cel al unei coloane nefolosite.
DROP UNUSED COLUMNS terge din tabel toate coloanele
marcate ca fiind nefolosite. Acest lucru se poate utiliza pentru eliberarea
spaiului de pe disc corespunztor coloanelor nefolosite din tabel. Dac
tabelul nu conine nici o coloan nefolosit, instruciunea nu ntoarce o
eroare i nu are nici un efect.
Atunci cnd se elimin o coloan dintr-un tabel folosind opiunea
DROP a comenzii ALTER TABLE, vor fi suprimate i coloanele din tabel
care sunt marcate cu opiunea SET UNUSED.

Suprimarea unui tabel

Pentru tergerea unui tabel este utilizat comanda DROP TABLE:
DROP TABLE [nume_schema.]nume_tabel
[CASCADE CONSTRAINTS];
Clauza CASCADE CONSTRAINTS permite suprimarea tuturor
constrngerilor de integritate referenial corespunztoare cheilor primare
i unice din tabelul supus tergerii. Dac se omite aceast clauz i exist
53

constrngeri de integritate referenial, sistemul returneaz o eroare i nu

suprim tabelul.
Suprimarea unui tabel presupune:
0suprimarea definiiei sale n dicionarul datelor;
0suprimarea indecilor asociai;
0suprimarea privilegiilor conferite n legtur cu tabelul;
0recuperarea spaiului ocupat de tabel;
0permanentizarea tranzactiilor in asteptare;
0invalidarea (dar nu suprimarea) funciilor, procedurilor,
vizualizrilor, secventelor, sinonimelor referitoare la tabel.
Odat executat, instruciunea DROP TABLE este ireversibil. Ca
i n cazul celorlalte instruciuni ale limbajului de definire a datelor,
aceast comand nu poate fi anulat (ROLLBACK).

Instruciunea DROP
Instruciunea DROP este cea mai simpl dintre instruciunile DDL.
Sintaxa de baz este:
Pentru tergerea unui tabel este utilizat comanda DROP TABLE:
DROP TABLE [nume_schema.]nume_tabel
[CASCADE CONSTRAINTS];
Clauza CASCADE CONSTRAINTS permite suprimarea tuturor
constrngerilor de integritate referenial corespunztoare cheilor primare
i unice din tabelul supus tergerii. Dac se omite aceast clauz i exist
constrngeri de integritate referenial, sistemul returneaz o eroare i nu
suprim tabelul.
Suprimarea unui tabel presupune:
0suprimarea definiiei sale n dicionarul datelor;
0suprimarea indecilor asociai;
0suprimarea privilegiilor conferite n legtur cu tabelul;
0recuperarea spaiului ocupat de tabel;
0permanentizarea tranzactiilor in asteptare;
0invalidarea (dar nu suprimarea) funciilor, procedurilor,
vizualizrilor, secventelor, sinonimelor referitoare la tabel.
Odat executat, instruciunea DROP TABLE este ireversibil. Ca
i n cazul celorlalte instruciuni ale limbajului de definire a datelor,
aceast comand nu poate fi anulat (ROLLBACK).

54

Tipul de obiect specific tipul obiectului care urmeaz s fie ters, cum ar
fi INDEX, TABLE sau VIEW.
Opiunile de tergere sunt specifice fiecrui SGBD. Sintaxa este diferit
de la un productor la altul PostgreSQL i MySQL folosesc n acest
scop cuvntul cheie CASCADE, n timp ce n Oracle trebuie s se
foloseasc CASCADE CONSTRAINTS.
Exemplu:
DROP TABLE COD_CLIENT;
DROP TABLE COD_CLIENT CASCADE CONSTRAINTS; (Oracle)
DROP INDEX IX_TITLU_FILM;
Pentru tergerea ntregului coninut al unui tabel i eliberarea
spaiului de memorie ocupat de acesta, sistemul Oracle ofer
instruciunea:
TRUNCATE TABLE nume_tabel;

Fiind o instruciune DDL, aceasta nu poate fi anulat ulterior

(printr-o operaie ROLLBACK). Ea reprezint o alternativ a comenzii
DELETE din limbajul de prelucrare a datelor(DML). De remarcat c
instruciunea DELETE nu elibereaz spaiul de memorie. Comanda
TRUNCATE este mai rapid deoarece nu genereaz informaie
ROLLBACK i nu activeaz declanatorii asociai operaiei de tergere.
Dac tabelul este printele unei constrngeri de integritate referenial,
el nu poate fi trunchiat. Pentru a putea fi aplicat instruciunea
TRUNCATE, constrngerea trebuie s fie mai nti dezactivat.
In DDL, informaiile despre tabele se gsesc n vizualizarea
USER_TABLES.
Dintre cele mai importante coloane ale acesteia, se remarca le
obtinem cu instructiunea:
55

DESCRIBE USER_TABLES;

TABLE_NAME
TABLESPACE_NAME
CLUSTER_NAME
PCT_FREE
PCT_USED
INI_TRANS
NITIAL_EXTENT
NEXT_EXTENT
MIN_EXTENTS
MAX_EXTENTS
PCT_INCREASE
BACKED_UP
NUM_ROWS
BLOCKS
EMPTY_BLOCKS
AVG_SPACE
AVG_ROW_LEN
TABLE_LOCK
PARTITIONED
TEMPORARY
NESTED

Numele tabelului
Spaiul tabel n care se afl tabelul
Numele cluster-ului din care face parte tabelul
Procentul de spaiu pstrat liber n interiorul fiecrui
bloc
Procentul de spaiu ce poate fi utilizat n fiecare bloc
Numrul iniial de tranzacii concurente n interiorul
unui bloc
Dimensiunea spaiului alocat pentru prima extensie
Dimensiunea spaiului alocat pentru urmtoarea
extensie
Numrul minim de extensii ce se aloc la crearea
unui tabel
Numrul maxim de extensii ce se aloc la crearea
unui tabel
Procentul cu care crete dimensiunea unei extensii
Y sau N, dup cum tabelului i-a fost fcut o copie de
siguran de la ultima modificare
Numrul de nregistrri din tabel
Numrul de blocuri utilizate de tabel
Numrul de blocuri ce nu conin date
Spaiul mediu liber din tabel
Lungimea medie, n octei, a unei linii
ENABLED (activat) sau DISABLED (dezactivat):
este activat sau nu blocarea tabelului
YES sau NO, indic dac tabelul este partiionat (sau
nu)
Y sau N, indic dac tabelul este temporar (sau nu)
YES sau NO, indic dac tabelul este imbricat (sau
nu)

Exemplu:
SELECT TABLE_NAME, NUM_ROWS, NESTED
FROM USER_TABLES;
Exemplu:
SELECT 'DROP TABLE ' || OBJECT_NAME || ';'
FROM USER_OBJECTS
WHERE OBJECT_TYPE = 'TABLE';

56

Instruciunea CREATE INDEX

Indexurile sunt instrumente puternice, deoarece permit sistemului
s gsesc datele mult mai repede, tot aa cum indexul unei cri ne
permite s gsim mai rapid ceea ce ne intereseaz. De asemenea,
indexurile pe coloanele cheilor externe cresc mult peformanele la unirea
tabelelor. Sistemul SGBD ntreine automat indexul, dar activitatea de
ntreinere consum din resursele calculatorului.
Pentru mbuntirea performanelor unor interogri, trebuie luat
n considerare crearea unui index. De asemenea, un index poate fi utilizat
pentru a impune unicitatea valorilor unei coloane sau ale unei colecii de
coloane.
Un index este un obiect al schemei, care conine cte o intrare
pentru fiecare valoare ce apare n coloanele indexate ale unui tabel sau
grupare i determin accesul rapid i direct la nregistrri, prin utilizarea
unui pointer.
Indecii sunt utilizai i ntreinui automat de ctre server-ul
Oracle. Odat creat, un index nu necesit o aciune direct din partea
utilizatorului.
Un index poate fi creat asupra:
uneia sau mai multor coloane ale unui tabel nepartiionat,
partiionat, organizat pe baz de index sau ale unui cluster;
unuia sau mai multor atribute de tip scalar ale unui obiect dintr-

57

un tabel sau cluster;

unui tabel imbricat.
Indecii sunt independeni din punct de vedere logic i fizic de
tabelul pe care l indexeaz. Aceasta nseamn c indecii pot fi creai sau
suprimai la orice moment fr a avea vreun efect asupra tabelelor de
baz sau asupra altor indeci.
Un index este un obiect al schemei unei baze de date care:
crete viteza de execuie a cererilor;
garanteaz c o coloan conine valori unice.
Un index trebuie s aib cel puin o coloan, dar, nu exist o limit
superioar a numrului de coloane.
Server-ul Oracle utilizeaz identificatorul ROWID pentru regsirea
liniilor n structura fizic a bazei de date. Indexul, din punct de vedere
logic, este compus dintr-o valoare cheie i din identificatorul adres
ROWID.
select rowid, cod_artist,nume,prenume from artist;
ROWID
COD_ARTIST NUME
PRENUME
------------------ ---------- ------------------------------ -----------AAAHkEAAJAAAAbPAAA
1 Grigorescu
Dan
AAAHkEAAJAAAAbPAAB
2 ene
ana
select * from artist where rowid='AAAHkEAAJAAAAbPAAA';
COD_ARTIST NUME
PRENUME
-------------------- ----------------------- -----------------------1
Grigorescu
Dan
Cheia indexului poate fi coloana unui tabel sau concatenarea mai
multor coloane (numrul maxim de coloane care pot defini cheia
indexului este 32). Coloanele care apar n cheia indexului trebuie
declarate NOT NULL n tabel.
Indecii sunt utilizai i ntreinui automat de ctre server-ul
Oracle. Odat creat indexul, el nu necesit o aciune direct din partea
utilizatorului.
Indecii pot fi creai n dou moduri:
automat, de server-ul Oracle (PRIMARY KEY, UNIQUE);
58

 manual, de ctre utilizator (CREATE INDEX).

Server-ul Oracle creeaz automat un index unic atunci cnd se
definete o constrngere PRIMARY KEY sau UNIQUE asupra unei
coloane sau unui grup de coloane. Numele indexului va fi acelai cu
numele constrngerii.
Indecii, fiind obiecte ale schemei bazei, beneficiaz de procesul de
definire a unui obiect.
Crearea unui index (care nu este obligatoriu unic) pe una sau mai
multe coloane ale unui tabel se face prin comanda:
CREATE[{UNIQUE | BITMAP} ] [UNIQUE] INDEX <nume_index>
ON [<nume_schema>.] <nume_tabel>
(<nume_col> [ASC | DESC], <nume_col> [ASC | DESC], );

Cuvntul cheie opional UNIQUE definete indexul ca unic,

nsemnnd c nu pot exista dou rnduri din tabel cu exact acceai
combinaie de valori n coloanele specificate. Aceast clauz nu poate
fi specificat alturi de clauza BITMAP sau pentru un index
domeniu.
Clauza BITMAP determin crearea indexului cu o hart de bii
(bitmap) pentru fiecare cheie distinct, n loc de a indexa separat fiecare
linie. Fiecare bit din bitmap corespunde unei valori ROWID posibile.
Dac un bit este setat, nseamn c linia avnd valoarea ROWID
corespunztoare acestuia conine valoarea cheii. Reprezentarea intern a
bitmap-urilor este adecvat aplicaiilor cu niveluri sczute ale
tranzaciilor concurente (de exemplu, aplicaii data warehouse).
Cuvntul cheie opional ASC creeaz indexul n ordine cresctoare,
n timp ce DESC creeaz indexul n ordine descresctoare. Dac nu este
specificat nici una dintre cele dou opiuni, ordinea prestabilit este
cresctoare.
Cnd este creat un index, un segment de date este rezervat automat
n spaiul tabel. Alocarea de memorie este controlat prin clauzele
INITIAL_EXTENT, PCT_INCREASE, PCT_FREE, NEXT, care pot s
apar n comanda CREATE INDEX.
Exemplu:
1) S se creeze un index descresctor relativ la coloana adresa din
tabelul cititor.
CREATE INDEX cititor_idx

59

ON cititor (adresa DESC);

CREATE INDEX cit_den
ON cititor (DEN_CITITOR);
2) S se afieze informaiile referitoare la indexul cititor_idx.
SELECT TABLE_NAME
FROM USER_INDEXES
WHERE INDEX_NAME=CITITOR_IDX;
SELECT TABLE_NAME
FROM USER_INDEXES
WHERE INDEX_NAME=CIT_DEN;

3) S se afieze toate indexurile(numele tabelelor, numele indexului si

daca a fost sau nu generat)
SELECT TABLE_NAME, INDEX_NAME, TABLE_TYPE
FROM USER_INDEXES;
4)S se creeze un index explicit, referitor la cheia primara a unui tabel.
Pentru a schimba numele unei chei altul decit cel dat de sistem oracle,
Sys_Cn;
CREATE TABLE exem
( cod_id NUMBER(6)
PRIMARY KEY USING INDEX
(CREATE INDEX cod_id_idx ON exem (cod_id)),
nume VARCHAR2(20));
Mai muli indeci asupra unui tabel nu implic ntotdeuna
interogri mai rapide. Fiecare operaie LMD care este permanentizat
asupra unui tabel cu indeci asociai presupune actualizarea indecilor
respectivi.
Prin urmare, este recomandat crearea de indeci numai n
anumite situaii:
coloana conine o varietate mare de valori;
coloana conine un numr mare de valori null;
una sau mai multe coloane sunt utilizate frecvent mpreun ntro clauz WHERE sau ntr-o condiie de join;
tabelul este mare i este de ateptat ca majoritatea interogrilor
asupra acestuia s regseasc mai puin de 2-4% din linii.

60

Crearea unui index nu este recomandat n urmtoarele cazuri:

tabelul este mic;
coloanele nu sunt utilizate des n cadrul unei condiii dintr-o
cerere;
majoritatea interogrilor regsesc mai mult de 2-4% din liniile
tabelului;
tabelul este actualizat frecvent;
coloanele indexate sunt referite n expresii.
In concluzie, ce tabele sau ce coloane trebuie (sau nu) indexate?
indexai tabelele pentru care interogrile selecteaz un numr redus
de rnduri (sub 5%);
indexai tabelele care sunt interogate folosind clauze SQL simple;
nu indexai tabelele ce conin puine nregistrri (accesul secvenial
este mai simplu);
nu indexai tabelele care sunt frecvent actualizate, deoarece
tergerile, inserrile i modificrile sunt ngreunate de indeci;
indexai coloanele folosite frecvent n clauza WHERE sau n clauza
ORDER BY;
nu indexai coloanele ce conin date asemntoare (puine valori
distincte);
Exemplu:
Pentru a asigura c server-ul Oracle utilizeaz indexul i nu
efectueaz o cutare asupra ntregului tabel, valoarea funciei
corespunztoare expresiei indexate trebuie s nu fie null n interogrile
ulterioare crerii indexului. Urmtoarea instruciune garanteaz utilizarea
indexului dar, n absena clauzei WHERE, server-ul Oracle ar putea
cerceta ntreg tabelul.
SELECT * FROM artist
WHERE UPPER(nume) IS NOT NULL
ORDER BY UPPER(nume);
Exemplu:
S se creeze tabelul artist, specificndu-se indexul asociat cheii
primare.
CREATE TABLE artist(
cod_artist NUMBER
PRIMARY KEY USING INDEX
(CREATE INDEX artist_cod_idx
ON artist(cod_artist)),

61

nume
prenume

VARCHAR2(30) NOT NULL,

VARCHAR2(30));

INSERT INTO ARTIST

VALUES(1,Grigorescu,Dan);
INSERT INTO ARTIST
VALUES(2,ene,ana);
INSERT INTO ARTIST
VALUES(4,Adam,Horia);
(trebuie creat privilegiu din Security ..query rewrite)
CREATE INDEX up_nume_id
ON artist(UPPER(nume));
Indexul creat prin instruciunea precedent faciliteaz prelucrarea
unor interogri precum:
SELECT * FROM artist
WHERE UPPER(nume) = 'ene';
tergerea unui index se face prin comanda:
DROP INDEX nume_index [ON [nume_schema.] nume_tabel]
Pentru a suprima indexul trebuie ca acesta s se gseasc n schema
personal sau s ai privilegiul de sistem DROP ANY INDEX.
Pentru a reconstrui un index se pot folosi dou metode:
se terge indexul (DROP INDEX) i se recreeaz (CREATE
INDEX);
se utilizeaz comanda ALTER INDEX cu opiunea REBUILD.
Modificarea parametrilor de stocare a indecilor (STORAGE),
alocarea (ALLOCATE EXTENT) i dealocarea (DEALLOCATE
UNUSED) manual a spaiului utilizat de un index se pot realiza cu
ajutorul comenzii ALTER INDEX. ncepnd cu Oracle9i, este posibil
modificarea structurii indecilor prin comanda ALTER INDEX.
Validarea unui index, adic verificarea integritii indexului
specificat pentru un tabel, se face prin comanda:
VALIDATE INDEX nume_index [ON nume_tabel] [WITH LIST]
VALIDATE INDEX artist_cod_idx;
Informaii referitoare la indeci i la coloanele care i definesc pot
fi regsite n vizualizrile USER_INDEXES, respectiv
62

USER_IND_COLUMNS din dicionarul datelor. Dintre coloanele

tabelului USER_INDEXES se remarc, dnd
Desc USER_INDEXES;
INDEX_NAME
INDEX_TYPE
TABLE_OWNER
TABLE_NAME
TABEL_TYPE
UNIQUENESS
TABLESPACE_NAME
INITIAL_EXTENT
NEXT_EXTENT
MIN_EXTENTS
MAX_EXTENTS
PCT_INCREASE
BLEVEL
LEAF_BLOCKS
DISTINCT_KEYS
STATUS
NUM_ROWS
PARTITIONED
GENERATED

Numele indexului
Tipul indexului (NORMAL, LOB, CLUSTER etc.)
Proprietarul tabelului indexat
Numele tabelului indexat
Tipul tabelului indexat (TABLE, CLUSTER etc.)
Starea de unicitate (UNIQUE, NONUNIQUE)
Spaiul tabel n care este stocat indexul
Spaiul alocat pentru prima extensie
Spaiul alocat pentru urmtoarea extensie
Numrul minim de extensii alocate
Numrul maxim de extensii
Procentul cu care cresc extensiile
Nivelul din B-arbore. Acesta arat adncimea indexului de
la ramuri la frunze
Numrul de blocuri frunz din index
Numrul de chei distincte n index
Starea indexului (VALID, INVALID, DIRECT_LOAD)
Numrul de linii utilizate. Acesta nu trebuie s includ
valorile NULL din tabelul de baz
Determin dac indexul este partiionat (YES sau NO)
Determin dac sistemul a generat numele indexului (Y)
sau utilizatorul (N)

SELECT TABLE_NAME, INDEX_NAME, TABLE_TYPE

FROM USER_INDEXES;

63

Pentru a vedea informatiile din USER_IND_COLUMNS, avem

Desc USER_IND_COLUMNS;

Exemplu:
S se obin informaii referitoare la indecii tabelului carte.

64

SELECT
FROM
WHERE
AND

a.index_name, a.column_name,
a.column_position poz, b.uniqueness
user_indexes b, user_ind_columns a
a.index_name = b.index_name
a.table_name = CITITOR;

Secvene
Multe aplicaii necesit utilizarea de numere unice ca valori ale
cheilor primare. Pentru a obine astfel de numere, se pot implementa n
aplicaie uniti de program corespunztoare sau se pot utiliza secvene.
De obicei, secvenele sunt utilizate pentru crearea de valori ale
cheii primare care trebuie s fie unice pentru fiecare linie. Secvena este
incrementat sau decrementat de ctre o rutin intern Oracle. Numerele
secvenei sunt stocate i generate independent de tabele. Prin urmare,
aceeai secven poate fi utilizat pentru mai multe tabele.
O secven este un obiect al bazei de date, creat de utilizator. Acest
obiect poate fi folosit de mai muli utilizatori pentru a genera numere
ntregi unice n sistemele multi-utilizator, evitnd apariia conflictelor i a
blocrii.
O secven poate fi creat de un utilizator i poate fi partajat de
mai muli utilizatori.
65

Crearea unei secvene se face cu ajutorul comenzii:

CREATE SEQUENCE [<nume_schema>.]<nume_secventa>
[INCREMENT BY n] [START WITH m]
[{MAXVALUE n | NOMAXVALUE}]
[{MINVALUE n|NOMINVALUE}]
[{CACHE k | NOCACHE}]
Opiunea INCREMENT BY specific diferena dintre valorile
succesive ale secvenei. Dac aceast opiune este omis, numerele
generate de secven vor fi incrementate prin valoarea 1.
Opiunea START WITH specific primul numr care va fi generat
de secven. Dac aceast opiune este omis, secvena ncepe de la
valoarea 1.
Opiunile MAXVALUE, MINVALUE precizeaz valoarea maxim,
respectiv minim pe care o poate genera secvena. Opiunile
NOMAXVALUE, NOMINVALUE sunt implicite. NOMAXVALUE
specific valoarea maxim de 1027 pentru o secven cresctoare i -1
pentru o secven descresctoare. NOMINVALUE specific valoarea
minim 1 pentru o secven cresctoare i -1026 pentru o secven
descresctoare.
Opiunile CYCLE i NOCYCLE specific dac secvena continu s
genereze numere dup obinerea valorii maxime sau minime. NOCYCLE
este opiunea implicit. Se recomand s nu fie utilizat opiunea CYCLE
dac secvena este folosit pentru generarea de chei primare, cu excepia
cazului n care exist un mecanism care terge liniile vechi din tabel mai
repede dect cicleaz secvena.
CACHE k precizeaz numrul de valori pe care server-ul Oracle le
prealoc i le pstreaz n memorie. n mod implicit, acest numr de
valori este 20. Opiunea CACHE pemite accesul mai rapid la valorile
secvenei care sunt pstrate n memorie. Aceste valori sunt generate la
prima referin asupra secvenei. Fiecare valoare din secven se
furnizeaz din secvena memorat. Dup utilizarea ultimei valori
prealocate secvenei, urmtoarea solicitare a unei valori determin
ncrcarea unui alt set de numere n memorie. Pentru a nu fi prealocate i
reinute n memorie astfel de valori, se utilizeaz opiunea NOCACHE.
O secven este referit ntr-o comand SQL cu ajutorul pseudocoloanelor:
NEXTVAL refer valoarea urmtoare a secvenei;
CURRVAL refer valoarea curent a secvenei.
66

NEXTVAL i CURRVAL pot fi folosite n:

clauza VALUES a unei comenzi INSERT;
clauza SET a unei comenzi UPDATE;
lista SELECT a unei subcereri dintr-o comanda INSERT;
lista unei comenzi SELECT.
NEXTVAL i CURRVAL nu pot fi folosite n:
subinterogare in SELECT, DELETE sau UPDATE;
interogarea unei vizualizri;
comand SELECT cu operatorul DISTINCT;
comand SELECT cu clauza GROUP BY, HAVING sau ORDER
BY;
clauza WHERE a unei comenzi SELECT;
condiia unei constrngeri CHECK;
valoarea DEFAULT a unei coloane ntr-o comand CREATE
TABLE sau ALTER TABLE;
comand SELECT care este combinat cu alt comand SELECT
printr-un operator mulime (UNION, INTERSECT, MINUS).

Din dicionarul datelor pot fi obinute informaii despre secvene

folosind vizualizarea USER_SEQUENCES.

1)

2)

S se creeze o secven domeniuseq care s fie utilizat pentru a

insera noi domenii n tabelul domeniu i s se insereze un nou
domeniu.
S se afieze informaiile referitoare la secvena domeniuseq.
CREATE SEQUENCE domeniuseq
START WITH 4
INCREMENT BY 1;
INSERT INTO domeniu
VALUES (domeniuseq.NEXTVAL,Arta);

67

SELECT INCREMENT_BY,MAX_VALUE, MIN_VALUE

FROM
USER_SEQUENCES
WHERE SEQUENCE_NAME = 'DOMENIUSEQ;
Modificarea unei secvene se face prin comanda ALTER
SEQUENCE. Sintaxa comenzii este similar instruciunii CREATE
SEQUENCE , dar:
noua valoare maxim pentru MAXVALUE nu poate fi mai mic
dect valoarea curent;
opiunea START WITH nu poate fi modificat de comand.
Exemplu: S se schimbe pasul secventei de la 1 la 2
ALTER SEQUENCE DOMENIUSEQ
INCREMENT BY 2;

Suprimarea unei secvene se face cu ajutorul comenzii:

DROP SEQUENCE [<nume_schema>.]<nume_secventa>;
Dup ce a fost tears, secvena nu mai poate fi referit. Pentru a
putea terge sau modifica secvena trebuie fie s fi proprietarul acesteia,
fie s ai privilegiul de sistem DROP ANY SEQUENCE, respectiv
privilegiul ALTER SEQUENCE.
DROP SEQUENCE domeniuseq;

Sinonime

68

Oracle ofer posibilitatea de a atribui mai multe nume aceluiai

obiect. Aceste nume adiionale sunt numite sinonime (synonymes). Ele
sunt utile deoarece permit simplificarea formulrii cererii i referirea la
obiecte, fr a fi nevoie s se specifice proprietarii obiectelor sau
localizarea acestora(schema).
Spre deosebire de alias a crui durat de via este limitat la
cererea ce conine alias-ul, sinonimele sunt salvate n dicionarul datelor
i pot fi reutilizate.
Sistemul Oracle permite crearea de sinonime pentru obiecte de
tipul: tabel, vizualizare, secven, funcie, procedur, pachet, clieu,
sinonim.
Crearea unui sinonim se realizeaz prin comanda:
CREATE [PUBLIC] SYNONYM [schema.]nume_sinonim
FOR [schema.]obiect
Exemplu:
CREATE SYNONYM artist1 FOR artist;
SELECT * from user_objects;
SELECT * from artist1;
CREATE SYNONYM domeniu1seq for domeniuseq;
Administratorul bazei poate produce i poate suprima sinonime
publice sau private, iar utilizatorii pot genera sau suprima doar sinonime
private. Pentru suprimarea unui sinonim din baza de date se utilizeaz
comanda:
DROP [PUBLIC] SYNONYM [schema.]nume_sinonim

69

Vizualizri

O vizualizare (view) nu conine date i poate fi interpretat ca

o fereastr prin care informaiile din tabele pot fi consultate i
modificate. Un astfel de obiect al bazei de date extrage rezultatul
unei cereri i l trateaz ca pe un tabel. Prin urmare, o vizualizare
poate fi considerat drept o cerere stocat sau un tabel virtual.
O vizualizare este o interogare SQL stocat, care poate fi referit
de instruciunile SQL DML i DQL ca i cum ar fi un tabel real. Unii
consider c vizualizrile sunt tabele virtuale", deoarece se
comport la fel ca tabelele, dar nu exist ca tabele fizice.
Numele vizualizrii trebuie s respecte aceleai reguli de denumire
ca i tabelele i alte obiecte ale bazei de date.
Interogarea SQL inclus n definiia vizualizrii poate fi orice
instruciunea SQL SELECT valid.
Vizualizarea (view) este un tabel logic (virtual) relativ la date din
una sau mai multe tabele sau vizualizri. Vizualizarea este definit
plecnd de la o cerere a limbajului de interogare a datelor, motenind
caracteristicile obiectelor la care se refer. Vizualizarea, fiind virtual, nu
solicit o alocare de memorie pentru date. Ea este definit n DD cu
aceleai caracteristici ca i un tabel.
Spre deosebire de tabele, pentru coninutul vizualizrii nu se aloc
spaiu de stocare. Spaiul ocupat de o vizualizare este doar cel alocat
definiiei acesteia (cererii stocate) din dicionarul datelor. Tabelele din
care cererea stocat selecteaz date se numesc tabele de baz ale
vizualizrii. Ele pot fi tabele sau chiar vizualizri, inclusiv vizualizri
materializate.
Textul cererii care definete vizualizarea este salvat n DD. Nucleul
Oracle determin fuzionarea cererii relative la vizualizare cu comanda de
definire a vizualizrii, analizeaz rezultatul fuziunii n zona partajat i
execut cererea.
Oracle transform cererea referitoare la o vizualizare ntr-o cerere
relativ la tabelele de baz. Vizualizarea este memorata in DD sub forma
unui SELECT.
Dac sunt utilizate clauzele UNION, GROUP BY i CONNECT BY,
atunci Oracle nu determin fuzionarea, el va rezolva vizualizarea i apoi
va aplica cererea rezultatului obinut.

70

O vizualizare reflect la orice moment coninutul exact al tabelelor

de baz. Orice modificare efectuat asupra tabelelor se repercuteaz
instantaneu asupra vizualizrii. tergerea unui tabel implic invalidarea
vizualizrilor asociate tabelului i nu tergerea acestora.
Vizualizrile sunt definite pentru:
furnizarea unui nivel mai nalt de securizare a bazei;
simplificarea formulrii unei cereri;
mascarea complexitii datelor;
afiarea datelor ntr-o alt reprezentare dect cea a tabelelor de
baz;
asigurarea independenei datelor;
asigurarea confidenialitii anumitor informaii;
definirea constrngerilor de integritate;
restricionarea acesului la date.
Vizualizrile pot fi simple i complexe. O vizualizare simpl
extrage date dintr-un singur tabel, nu conine funcii sau grupri de date i
asupra ei pot fi efectuate operaii LMD.
O vizualizare este considerat complex dac extrage date din mai
multe tabele, conine funcii sau grupri de date i nu permite ntotdeauna
(prin intermediul su) operaii LMD asupra tabelelor de baz.
Operaiile LMD asupra vizualizrilor complexe sunt restricionate
de urmtoarele reguli:
nu se poate insera, actualiza sau terge o linie dintr-o vizualizare
dac aceasta conine funcii grup, clauza GROUP BY, cuvntul
cheie DISTINCT sau pseudocoloana ROWNUM;
nu se poate aduga sau modifica o linie dintr-o vizualizare, dac
aceasta conine coloane definite prin expresii;
nu pot fi adugate linii printr-o vizualizare, dac tabelul de baz
conine coloane care au constrngerea NOT NULL i nu apar n
lista SELECT a vizualizrii.
Pentru a obine informaii referitoare la vizualizrile definite, se pot
interoga vizualizrile USER_VIEWS i ALL_VIEWS din dicionarul
datelor. Textul instruciunii SELECT care definete o vizualizare este
stocat ntr-o coloan de tip LONG, numit TEXT.
Atunci cnd datele sunt accesate prin intermediul unei vizualizri,
server-ul Oracle efectueaz urmtoarele operaii:
recupereaz definiia acesteia din USER_VIEWS;
verific privilegiile de acces la tabelele ei de baz;
convertete cererea ntr-o operaie echivalent asupra tabelelor
de baz.

71

Crearea unei vizualizri se realizeaz cu ajutorul comenzii:

CREATE [OR REPLACE][FORCE | NOFORCE] VIEW
[<nume_schema>.]<nume_view> [(<alias>[,<alias>])]
AS <cerere_SELECT>
[WITH {CHECK OPTION [CONSTRAINT <nume_constrangere>] |
READ ONLY }];
OR REPLACE recreeaz vizualizarea dac aceasta deja exist.
FORCE creeaz vizualizarea chiar dac tabelul de baz nu exist sau
chiar dac vizualizarea face referin la obiecte care nc nu sunt
create. Dei vizualizarea va fi creat, utilizatorul nu poate s o
foloseasc.
NO FORCE este implicit i se refer la faptul c vizualizarea este
creat numai dac tabelele de baz exist.
Cererea este o comand SELECT care poate s conin alias pentru
coloane.
WITH CHECK OPTION specific faptul c reactualizarea datelor din
tabele (inserare sau modificare) se poate face numai asupra datelor
selectate de vizualizare (care apar n clauza WHERE).
WITH READ ONLY asigur c nici o operaie LMD nu poate fi
executat asupra vizualizrii.
Exemplu:
S se genereze o vizualizare care conine informaii referitoare la
mprumutul crilor i n care s fie implementat constrngerea c orice
carte, care exist ntr-un singur exemplar, poate fi mprumutat maximum
15 zile.
CREATE VIEW imprumutare
AS SELECT
*
FROM
imprumuta
WHERE
codel NOT IN
(SELECT codel
FROM
carte
WHERE nrex = 1)
OR datares - dataim < 15
WITH CHECK OPTION;
Cererea care definete vizualizarea poate fi complex, incluznd
join-uri, grupri i subcereri, ns nu poate conine clauza ORDER BY.
Dac este necesar, aceast clauz poate fi specificat la interogarea
vizualizrii. Interogarea unei vizualizri este similar celei unui tabel.

72

Numrul coloanelor specificate n definiia vizualizrii trebuie s fie egal

cu cel din lista asociat comenzii SELECT.
Asupra cererii care definete vizualizarea se impun urmtoarele
restricii:
nu pot fi selectate pseudocoloanele CURRVAL i NEXTVAL ale
unei secvene;
dac sunt selectate pseudocoloanele ROWID, ROWNUM sau
LEVEL, acestora trebuie s li se specifice alias-uri;
dac cererea selecteaz toate coloanele unui tabel, utiliznd
simbolul *, iar ulterior se adaug coloane noi tabelului,
vizualizarea nu va conine acele coloane pn la recrearea sa
printr-o instruciune CREATE OR REPLACE VIEW;
pentru vizualizrile obiect, numrul i tipul elementelor
selectate de cerere trebuie s coincid cu cel al atributelor de pe
primul nivel al tipului obiect.
Aportul versiunii Oracle9i n ceea ce privete instruciunea
CREATE VIEW const n posibilitatea:
crerii de subvizualizri ale vizualizrilor obiect;
definirii de constrngeri asupra vizualizrilor.
Exemplu:
a) S se creeze o vizualizare care conine numele i prenumele
artistului, numrul operelor sale i valoarea medie a acestora.
CREATE VIEW artist_nr_val(nume, numar_opere, val_medie)
AS SELECT a.nume || ' ' || a .prenume "Nume si prenume",
COUNT(o. cod_opera) numar, AVG(o.valoare) medie
FROM opera o, artist a
WHERE o.cod_artist = a.cod_artist
GROUP BY o.cod_artist, a.nume, a.prenume;
b) S se creeze vizualizarea sculptura ce va conine codul operei,
data achiziiei, codul artistului i stilul operelor al cror tip este
sculptura.
CREATE OR REPLACE VIEW sculptura
(cod_sculptura, informatii, cod_sculptor, stil)
AS SELECT cod_opera,
'Sculptura ' || titlu ||
' a fost achizitionata la data ' ||
data_achizitiei, cod_artist, stil
FROM opera
WHERE tip = 'sculptura';

73

Modificarea unei vizualizri presupune modificarea definiiei

acesteia. Pentru a nlocui o vizualizare trebuie avut privilegiul de
sistem necesar pentru distrugerea i crearea acesteia. nlocuirea se
poate face n dou moduri.
Vizualizarea poate fi distrus (DROP VIEW) i apoi recreat
(CREATE) cu noua definiie. Atunci cnd este distrus, toate
privilegiile sunt retrase. Aceste privilegii trebuie s fie create
pentru noua vizualizare.
Vizualizarea poate fi recreat prin redefinire cu instruciunea
CREATE VIEW, dar cu clauza OR REPLACE. Aceast metod
conserv toate privilegiile curente.
In Oracle9i este posibila adaugarea de constrangeri unei vizualizari
prin comanda ALTER VIEW.
Modificarea unui vizualizri are urmtoarele efecte:

definiia vizualizrii din DD este actualizat;

nici unul din obiectele de baz nu este afectat de nlocuire;

toate restriciile care existau n vizualizarea original sunt

distruse;
toate vizualizrile i programele PL/SQL dependente de
vizualizarea nlocuit devin invalide.

Suprimarea unei vizualizri se realizeaz prin comanda DROP

VIEW care terge definiia vizualizrii din baza de date.
DROP VIEW <nume_view> [CASCADE CONSTRAINT];
tergerea vizualizrii nu va afecta tabelele relativ la care a fost
definit vizualizarea. Aplicaiile i vizualizrile care se bazeaz pe
vizualizarea suprimat devin invalide. Pentru a suprima o vizualizare,
utilizatorul trebuie s aib privilegiul DROP ANY VIEW sau s fie
creatorul vizualizrii respective.
Similar opiunii corespunztoare din comanda DROP TABLE,
clauza CASCADE CONSTRAINTS permite suprimarea tuturor
constrngerilor de integritate referenial corespunztoare cheilor primare
i unice din vizualizarea supus tergerii. Dac se omite aceast clauz i
74

exist astfel de constrngeri, instruciunea DROP VIEW va eua.

Recompilarea unei vizualizri permite detectarea eventualelor
erori referitoare la vizualizare, naintea executrii vizualizrii. Dup
fiecare modificare a tabelelor de baz este recomandabil ca vizualizarea
s se recompileze:
ALTER VIEW <nume_view> COMPILE;
Reactualizarea
tabelelor
corespunztoare a vizualizrilor!!!

implic

reactualizarea

Reactualizarea vizualizrilor implic reactualizarea

tabelelor de baz? NU! Exist restricii care trebuie
respectate!!!
Nu pot fi modificate date din vizualizare sau adaugate date prin
vizualizare, daca aceasta contine coloane definite prin expresii.
Nu pot fi nserate, terse sau actualizate date din vizualizri ce
conin: operatorul DISTINCT; clauzele GROUP BY, HAVING,
START WITH, CONNECT BY; pseudo-coloana ROWNUM; funcii
grup; operatori de mulimi.
Nu pot fi inserate sau actualizate date care ar nclca constrngerile
din tabelele de baz.
Nu pot fi inserate sau actualizate valorile coloanelor care rezult
prin calcul.
Nu se pot face operaii LMD asupra coloanelor calculate cu
DECODE.
Alturi de restriciile prezentate anterior, aplicabile tuturor
vizualizrilor, exist restricii specifice, aplicabile vizualizrilor bazate pe
mai multe tabele.
Regula fundamental este c orice operaie INSERT, UPDATE
sau DELETE pe o vizualizare bazat pe mai multe tabele poate modifica
datele doar din unul din tabelele de baz. In care???
Un tabel de baz al unei vizualizri este protejat prin cheie (key
preserved table) dac orice cheie selectat a tabelului este de asemenea i
cheie a vizualizrii. Deci, un tabel protejat prin cheie este un tabel ale
crui chei se pstreaz i la nivel de vizualizare. Pentru ca un tabel s fie
protejat prin cheie nu este necesar ca tabelul s aib toate cheile selectate
n vizualizare. Este suficient ca, atunci cnd cheia tabelului este selectat,
aceasta s fie i cheie a vizualizrii.
Asupra unui join view pot fi aplicate instruciunile INSERT,
UPDATE sau DELETE, doar dac sunt ndeplinite urmtoarele condiii:
instruciunea LMD afecteaz numai unul dintre tabelele de baz;
75

 n cazul instruciunii UPDATE, toate coloanele care pot fi

reactualizate trebuie s corespund coloanelor dintr-un tabel
protejat prin cheie (n caz contrar, Oracle nu va putea identifica
unic nregistrarea care trebuie reactualizat);
n cazul instruciunii DELETE, rndurile unei vizualizri pot fi
terse numai dac exist un tabel n join protejat prin cheie i
numai unul (n caz contrar, Oracle nu ar ti din care tabel s
tearg);
n cazul instruciunii INSERT, toate coloanele n care sunt inserate
valori trebuie s provin dintr-un tabel protejat prin cheie.
ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS
i USER_UPDATABLE_COLUMNS sunt vizualizri din DD ce conin
informaii referitoare la coloanele vizualizrilor existente, care pot fi
reactualizate.
Exmplu:
1. S se creeze un view ce conine cmpurile nume, prenume, job din
tabelul salariat.
2. S se insereze, s se actualizeze i s se tearg o nregistrare n
acest view. Ce efect vor avea aceste aciuni asupra tabelului de
baz?
CREATE VIEW

vederea2

AS SELECT
FROM

nume, prenume, job

salariat;

Nu se pot face inserari deoarece view-ul nu conine cheia primar!

INSERT INTO vederea2
VALUES
('Popescu','Valentin','grafician');
va genera eroarea:
ORA-01400: cannot insert NULL into
("SCOTT"."SALARIAT"."COD_SALARIAT")
Actualizarea job-ului salariatului avnd numele "Popescu":
UPDATE

vederea2

SET
WHERE
SELECT

job = 'programator'
nume = 'Popescu';
nume, prenume, job FROM

salariat;

tergerea nregistrrii referitoare la salariatul avnd numele

"Popescu":
DELETE
WHERE

vederea2
nume = 'Popescu';

76

Operaiile care se realizeaz asupra view-ului se realizeaz i n

tabelul salariat. Pentru un caz mai general, cnd view-ul conine cheia
extern a tabelului de baz, sunt permise modificri ale view-ului, dac
acestea nu afecteaz cheia extern.
Exemplu:
S se creeze un view care conine cmpurile nume, prenume, job
din tabelul salariat. S se introduc n view doar persoanele care sunt
graficieni.
CREATE VIEW vederea21
AS SELECT
nume, prenume, job
FROM
salariat
WHERE
job = 'grafician'
WITH CHECK OPTION;
S se creeze o vizualizare care s conin cod_salariat, nume,
prenume din tabelul salariat i coloana tip din tabelul grafician. Apoi s
se insereze, s se actualizeze i s se tearg o nregistrare din acest view
(vizualizarea conine cheia primar cod_salariat din tabelele salariat i
grafician).
CREATE VIEW vederea4
AS SELECT
s.cod_salariat,nume,prenume,tip
FROM
salariat s, grafician g
WHERE
s.cod_salariat=g.cod_salariat;
n cazul inserrii unei nregistrri pentru care se specific toate
cmpurile:
INSERT INTO
vederea4
VALUES
(30,'Popescu','Valentin','artist plastic');
va apare urmtoarea eroare:
ORA-01776: cannot modify more than one base TABLE
through a join view
Pot fi inserate date doar ntr-un tabel de baz (n oricare, dar n
unul singur) prin intermediul view-ului, astfel:
INSERT INTO vederea4 (cod_salariat, nume)
VALUES
(30, 'Popescu');
Comanda pentru tergerea unei nregistrri:
DELETE
vederea4
WHERE
cod_salariat = 3;
va genera urmtoarea eroare:

77

ORA-01752: cannot delete from

exactly one key-preserved TABLE.

view

without

Modificarea unei nregistrri se face prin secvena care urmeaz.

Toate actualizrile care se fac n view se fac i n tabelele de baz.
UPDATE
SET
WHERE

vederea4
tip = 'designer'
cod_salariat = 3;

Exemplu:
Care dintre coloanele unei vizualizri sunt actualizabile?
SELECT

column_name, updatable

FROM
WHERE

user_updatable_columns
table_name = 'vederea4';

Exemplu:
1. S se creeze un view (vederea3) care s conin, pentru fiecare
categorie de salariat, salariile medii i numrul de angajai din
tabelul salariat.
2. S se insereze, s se actualizeze i s se tearg o nregistrare n
view.
CREATE VIEW vederea3 (nr, job, salmed)
AS SELECT
COUNT(*), job, AVG(salariu)
FROM
salariat
GROUP BY
job;
Nu se pot face inserri, actualizri sau tergeri ntr-un view ce
conine funcii grup. Dup oricare din aceste operaii apare acelai mesaj:
ORA-01732: data manipulation operation not legal
on this view
Exemplu:
S se creeze o vizualizare care s conin coloanele
cod_contractant, adresa, telefon din tabelul contractant i coloanele
nr_contract, tip_contract, data_incheiere din tabelul contract. S se
insereze o nregistrare n vizualizare.
CREATE VIEW vederea44
AS SELECT
c.cod_contractant, adresa, telefon,
co.nr_contract, tip_contract,
data_incheiere
FROM
contractant c, contract co
WHERE
c.cod_contractant=co.cod_contractant;
La inserarea unei nregistrri creia i se specific valorile tuturor
cmpurilor din ambele tabele:
78

INSERT INTO

vederea44(cod_contractant, adresa,
nr_contract,
data_incheiere)
VALUES
(200, 'Str. Marmurei, 14', '6235',
TO_DATE('January 03,2002','Month
dd,yyyy'));
se obine eroarea:
ORA-01779: cannot modify a column which maps to a
non key-preserved TABLE
Cele dou tabele de baz, contractant i contract, se afl ntr-o
relaie one-to-many, iar view-ul creat conine cheile primare din ambele
tabele.
Doar tabelul contract este protejat prin cheie i, prin urmare, doar
el poate fi modificat prin intermediul view-ului. Aceasta, deoarece ar
putea exista mai multe nregistrri n view, cu aceeai valoare
corespunztoare cmpului cod_contractant (CP n contractant).
Exact aceeai eroare se obine dac ncercm inserarea unei
nregistrri n vederea44, specificnd fie i numai un cmp provenind din
tabela contractant (indiferent dac el conine sau nu CP).
Singura operaie de inserare permis este aceea efectuat prin
specificarea cheilor provenind doar din tabelul contract. Astfel, prin
executarea comenzii:
INSERT INTO vederea44(nr_contract, tip_contract)
VALUES
('6234', 0);
este creat o nregistrare, dar este modificat i tabelul contract. Dac la
inserie nu se specific cheia primar din contract:
INSERT INTO vederea44(tip_contract)
VALUES
(1);
ORA-01400: mandatory (NOT NULL) column is missing
or NULL during insert
Cererea din definiia vizualizrii poate fi restricionat prin clauzele
WITH READ ONLY i WITH CHECK OPTION. Opiunea WITH READ
ONLY asigur c nu pot fi efectuate operaii LMD asupra vizualizrii.
Constrngerea WITH CHECK OPTION garanteaz faptul c va fi
permis, prin intermediul vizualizrii, numai inserarea sau actualizarea de
linii accesibile acesteia (care sunt selectate de cerere). Prin urmare,
aceast opiune asigur constrngeri de integritate i verificri asupra
validitii datelor inserate sau actualizate.
Opiunea WITH CHECK OPTION nu poate funciona dac:
exist o cerere imbricat n cadrul subcererii vizualizrii sau n
vreuna dintre vizualizrile de baz;

79

 operaiile de inserare, tergere i modificare se fac prin

intermediul declanatorilor INSTEAD OF.
Cuvntul cheie CONSTRAINT permite numirea constrngerii
WITH CHECK OPTION. n absena acestei clauze, constrngerea va avea
un nume implicit de forma SYS_Cn, unde n este un numr ntreg unic.
Exemplu:
S se creeze o vizualizare ce conine artitii de naionalitate
romn, care au opere expuse n muzeu. Definiia vizualizrii nu va
permite modificarea naionalitii unui artist sau inserarea unui artist
avnd alt naionalitate dect cea romn.
CREATE VIEW artist_roman
AS SELECT
* FROM
artist
WHERE
nationalitate = 'romana'
WITH CHECK OPTION CONSTRAINT artist_roman_ck;

UPDATE
SET
WHERE

artist_roman
nationalitate = 'engleza'
cod_artist = 25;

ncercarea de actualizare a unei linii prin instruciunea anterioar

va genera eroarea ORA-01402: view WITH CHECK OPTION whereclause violation.
Exemplu:
S se creeze o vizualizare asupra tabelului galerie care s nu
permit efectuarea nici unei operaii LMD.
CREATE VIEW viz_galerie
AS SELECT
cod_galerie, nume_galerie
FROM
galerie
WITH READ ONLY;
DELETE FROM viz_galerie
WHERE cod_galerie = 10;
ncercarea de tergere a unei linii din vizualizarea viz_galerie
determin apariia erorii ORA-01752: cannot delete from view without
exactly one key-preserved table. Dac se ncearc modificarea sau
inserarea unei linii prin intermediul unei vizualizri asupra creia a fost
definit o constrngere WITH READ ONLY, server-ul Oracle genereaz
eroarea ORA-01733: virtual column not allowed here.
Exemplu:
S se creeze o vizualizare care conine codul i titlul operelor de
art, codul i numele artitilor care le-au creat, precum i codul galeriilor
unde sunt expuse. S se afle dac este posibil adugarea unei noi
nregistrri prin intermediul acestei vizualizri.

80

CREATE VIEW opera_artist

AS SELECT o.cod_opera, o.titlu, o.cod_galerie,
a.cod_artist, a.nume
FROM
opera o, artist a
WHERE o.cod_artist = a.cod_artist;
Instruciunea urmtoare afieaz numele coloanelor i valorile
YES/NO, dup cum aceste coloane sunt, sau nu, modificabile.
SELECT COLUMN_NAME, UPDATABLE
FROM
USER_UPDATABLE_COLUMNS
WHERE TABLE_NAME = 'OPERA_ARTIST';
Se va obine c doar primele trei coloane ale vizualizrii sunt
modificabile.
Indexul primar al coloanei cod_artist din tabelul artist nu este unic
n vizualizarea opera_artist. Prin urmare, tabelul artist nu este keypreserved, iar coloanele sale nu sunt modificabile.
Instruciunea urmtoare va genera eroarea ORA-01776: cannot
modify more than one base table through a join view.
INSERT INTO opera_artist
VALUES
(200, 'Poeme de l''ame', 20, 147,
'Janmot');
n schimb, instruciunea urmtoare va fi executat cu succes,
ntruct adaug o nregistrare n tabelul de baz opera, ale crui coloane
sunt modificabile.
INSERT
INTO
cod_galerie)

opera_artist

(cod_opera,

titlu,

VALUES (200, 'Poeme de l''ame', 20);

Constrngeri asupra vizualizrilor

ncepnd cu versiunea Oracle9i pot fi specificate constrngeri
pentru vizualizri. Se pot defini constrngeri la nivel de vizualizare,
respectiv la nivel de coloan sau atribut. Constrngerile asupra
vizualizrilor constituie o submulime a constrngerilor specifice
tabelelor.
Pot fi specificate explicit numai constrngerile UNIQUE,
PRIMARY KEY i FOREIGN KEY. Constrngerea de tip CHECK poate fi
realizat prin precizarea clauzei WITH CHECK OPTION n comanda care
definete vizualizarea.
Constrngerile asupra vizualizrilor pot fi definite numai n modul
DISABLE NOVALIDATE. Aceste cuvinte cheie trebuie specificate la
declararea constrngerii, nefiind permis precizarea altor stri.
Exemplu:
81

S se creeze o vizualizare care conine codurile, numele i adresele

galeriilor. Se va impune unicitatea valorilor coloanei adresa i
constrngerea de cheie primar pentru coloana corespunztoare codului
galeriei.
CREATE VIEW viz_galerie(
cod_gal, nume, adresa UNIQUE DISABLE NOVALIDATE,
CONSTRAINT
cp_viz
PRIMARY
KEY
(cod_gal)
DISABLE
NOVALIDATE)
AS SELECT cod_galerie, nume_galerie, adresa
FROM galerie;

Informaii despre obiectele bazei de date

Pot fi obinute consultnd DD(Dicionarul de Date). Dintre ele se
remarc:
definiiile tuturor obiectelor din baza de date;
spaiul alocat i spaiul utilizat n prezent de obiectele schemei;
constrngerile de integritate;
numele utilizatorilor bazei;
privilegiile i rolurile acordate fiecrui rol;
alte informaii generale despre baza de date.
Tabelul USER_CATALOG conine informaii despre tabelele i
vizualizrile definite de un utilizator particular. Acest tabel poate fi referit
i prin sinonimul su public CAT.
Tabelul USER_OBJECTS conine informaii despre toate obiectele
definite de utilizatorul curent. Tabelul are urmtoarea schem relaional:
USER_OBJECTS (object_name, object_id, object_type, created,
last_ddl_time, timestamp, status)
Vizualizrile cele mai importante ale dicionarului datelor conin:
descrierea tabelelor definite de utilizatori (USER_ALL_TABLES),
informaii despre constrngerile definite de
utilizator(USER_CONSTRAINTS),
informaii despre legturile bazei de date (USER_DB_LINKS),
erorile curente ale obiectelor depozitate (USER_ERRORS),
informaii despre indecii creai de utilizator (USER_INDEXES),
informaii despre tabelele utilizatorului (USER_TABLES) etc.

82

Vizualizrile din dicionarul datelor referitoare la tabele conin:

USER_TAB_COLUMNS|COLS informaii despre coloanele
tabelelor,
USER_CONS_COLUMNS informaii despre constrngeri la nivel
coloan,
USER_TAB_COMMENTS informaii despre comentarii la nivel
tabel,
USER_COL_COMMENTS informaii despre comentarii la nivel
coloan,
USER_TAB_PARTITIONS informaii despre partiiile tabelelor.

83

Limbajul de interogare a datelor(DQL)

Limbajul SQL de interogare a datelor (DQL Data Query
Language) include o singur comand SELECT, care este cea mai
folosit pentru a obine date din baza de date, astfel nct acestea s fie
prelucrate de o anumit aplicaie sau s fie afiate. Rezultatul unei
instruciuni SELECT, numit i set de rezultate, este returnat sub forma
unui tabel. Deoarece SQL este un limbaj neprocedural, se specific
rezultatele pe care le dorii s le obinei, nu i modul lor de obinere.
Instruciunea SELECT de baz
Cererea (interogarea) este realizat de instruciunea SELECT. Cu ajutorul
ei pot fi extrase submulimi de valori att pe vertical (coloane), ct i pe
orizontal (linii) din unul sau mai multe tabele. Sintaxa comenzii este
simpl, apropiat de limbajul natural.
SELECT
FROM
[WHERE
[GROUP BY
[HAVING
[ORDER BY

[ALL | DISTINCT]
{* | list de atribute selectate | expr AS alias}
{ [schema.]tabel [alias_tabel] }
condiie]
list de expresii
condiie]]
{expresie | poziie | c_alias} [ASC | DESC]]

Forma elementar a instruciunii SELECT conine dou clauze:

SELECT [DISTINCT] - Specific lista de coloane care
urmeaz s fie returnate n setul de rezultate, separate prin virgule. Se
poate folosi simbolul asterisc (*) n locul listei de coloane pentru a selecta
toate coloanele dintr-un tabel sau dintr-o vizualizare. Cuvntul cheie
DISTINCT poate fi adugat dup cuvntul cheie SELECT pentru a
elimina rndurile duplicate din rezultatele interogrii.
FROM - Specific lista tabelelor sau vizualizrilor din care
urmeaz s fie selectate datele. n locul numelor reale ale tabelelor sau
vizualizrilor se poate folosi sinonime, adic pseudonime pentru tabele
sau vizualizri definite n baza de date.
Prezena clauzelor SELECT i FROM este obligatorie deoarece acestea
specific coloanele selectate, respectiv tabelele din care se vor extrage
datele. Tabelele specificate n clauza FROM pot fi urmate de un alias,
care va reprezenta numele folosit pentru referirea tabelului respectiv n
cadrul instruciunii.

Eliminarea duplicatelor se poate realiza folosind clauza

DISTINCT. Dac nu se specific parametrul DISTINCT, parametrul ALL
este implicit i are ca efect afiarea dublurilor.
Simbolul * permite selectarea tuturor atributelor din
tabelele asupra crora se execut cererea. Atributele sau expresiile din
lista clauzei SELECT pot conine alias-uri, care vor reprezenta numele
cmpurilor respective n cadrul tabelului furnizat ca rezultat de
instruciunea SELECT.
Clauza WHERE poate fi folosit pentru a impune anumite
condiii liniilor din care se vor extrage atributele specificate n clauza
SELECT.
Clauza GROUP BY grupeaz nregistrrile dup anumite
cmpuri; n cazul prezenei acestei clauze, clauza HAVING poate impune
restricii suplimentare asupra rezultatului final.
Ordonarea nregistrrilor se poate face cu ajutorul clauzei
ORDER BY. Cu ajutorul parametrilor ASC i DESC se poate specifica
ordonarea cresctoare, respectiv descresctoare a nregistrrilor. Pentru o
secven cresctoare valorile null sunt afiate ultimele. Dac nu se face
nici o specificaie, atunci ordinea de returnare este la latitudinea serverului.

n
exemplul
urmtor
se
selecteaz
coloanele:
COD_GEN_FILM, MPAA_RATING_COD i TITLU_FILM din
tabelul FILM.
SELECT COD_GEN_FILM, COD_ RATING, TITLU_FILM
FROM FILM;
Pseudonime pentru numele coloanelor
In setul de rezultate din interogri numele coloanelor din tabel
apare automat ca titlu de coloane n interogare. Dac se dorete un alt
nume pentru coloanele unei interogri se folosesc pseudonime.
Pseudonimele (aliases) specificate devin numele coloanelor din setul
de rezultate. Pseudonimele nu exist dect dup rularea instruciunii SQL,
aa c nu pot fi folosite n alte pri ale instruciunii SQL. Pseudonimul
unei coloane este specificat prin plasarea cuvntului cheie AS" dup
numele coloanei n lista SELECT (cu cel puin un spaiu nainte i dup),
urmat de numele dorit pentru a fi atribuit coloanei n setul de rezultate.
SELECT COD_GEN_FILM AS GEN, MPAA_RATING_COD AS
RATING, TITLU_FILM AS FILM
FROM FILM;

Dac n interiorul alias-ului apare un spaiu liber sau caractere

speciale, atunci alias-ul trebuie scris ntre ghilimele.
SELECT
FROM

dateresdataim numar zile

imprumuta;

Sortarea rezultatelor
Rezultatele interogrilor sunt deseori mult mai utile dac se
specific pentru rndurile returnate o ordine care s aib o semnificaie
pentru persoana sau aplicaia care folosete informaiile. n SQL, acest
lucru este fcut prin adugarea n instruciunea SELECT a clauzei ORDER
BY, cu o list de una sau mai multe coloane care vor fi folosite pentru
sortarea rndurilor n ordine ascendent sau descendent, n conformitate cu
valorile datelor din coloane. De asemenea, se ine seama de urmtoarele
aspecte:
Ordinea prestabilit pentru fiecare coloan este ascendent, dar se
poate aduga cuvntul cheie ASC dup numele coloanei pentru obinerea
unei ordonri ascendente sau cuvntul cheie DESC pentru obinerea unei
ordonri descendente.
Nu este obligatoriu ca numele coloanelor din lista ORDER BY s
fie incluse i n lista de rezultate (adic n lista SELECT).
Motorul SQL din SGBD va gsi cea mai bun cale de ordonare a
coloanelor. n general, sortarea datelor este un proces costisitor din punct
de vedere al resurselor de calcul, aa c majoritatea sistemelor SGBD
folosesc un index pentru accesul la rnduri n ordinea dorit, presupunnd
c exist, i fac o sortare propriu-zis numai ca ultim soluie.
Se poate folosi pseudonimele coloanelor n clauza ORDER BY,
dar dac se face acest lucru se foreaz motorul SQL s sorteze rezultatele
abia dup rularea interogrii.
n locul coloanelor, se poate specifica n lista de ordonare poziia
relativ a coloanelor. De exemplu, clauza ORDER BY 1,2 va sorta
rezultatele n ordine ascendent dup primele dou coloane din setul de
rezultate. Numrul specificat nu are nici o legtur cu poziia coloanei n
tabelul sau vizualizarea surs. Aceast opiune nu este agreat n
programarea SQL formal, deoarece dac ulterior cineva modific
interogarea, este posibil s amestece coloanele din lista SELECT, fr si dea seama c astfel schimb i coloanele folosite pentru sortarea
rezultatelor.
Exemplu:
SELECT MPAA_RATING_COD AS RATING,
COD_GEN_FILM AS GEN, TITLU_FILM AS FILM

FROM FILM
ORDER BY MPAA_RATING_COD, COD_GEN_FILM ;
Dac dorim s ordonm acum cresctor dup rating i descresctor
dup gen, atunci instruciunea de mai sus modificat va fi
SELECT MPAA_RATING_COD AS RATING,
COD_GEN_FILM AS GEN, TITLU_FILM AS FILM
FROM FILM
ORDER BY
MPAA_RATING_COD ASC, COD_GEN_FILM DESC;
Observaie:
Oracle va afia titlu de coloana la dimensiunea maxim a valorilor
din coloana(de ex. dac n coloana RATING val cea mai mare este de 5
caractere, interogarea va afia RATIN). n noua versiune de SQL produs
de Oracle, iSQL*Plus, nu mai prescurteaz.
Exemplu :
SELECT titlu, autor, pret, coded as domeniu
from carte
order by coded, autor;
SELECT titlu, autor, pret, coded as domeniu
from carte
order by coded desc, pret;
Se observa ca domeniu este trunchiat la 5 caractere, DOMEN

Utilizarea clauzei WHERE pentru filtrarea rezultatelor

SQL folosete clauza WHERE pentru a filtra rndurile ce urmeaz
s fie afiate. O interogare fr o clauz WHERE returneaz un set de
rezultate care conine toate rndurile din tabelele sau vizualizrile referite
n clauza FROM. Dac este inclus o clauz WHERE, sunt folosite
regulile algebrei booleene, evalund clauza WHERE pentru fiecare rnd
de date. n rezultatele interogrii sunt afiate numai rndurile pentru care
clauza WHERE este evaluat la valoarea logic adevrat".
Operatorii utilizai n clauza WHERE se impart n patru categorii:
-

Operatori de comparare
Operatori conjuctivi
Operatori logici
Operatori aritmetici
Operatori de comparare

Operatorii de comparare sunt folosii n clauza WHERE pentru

compararea a dou valori, avnd ca rezultat o valoare logic de adevrat" sau fals".
Cele dou valori comparare pot fi constante furnizate n clauza WHERE, valori ale
unor coloane din baza de date sau combinaii ale celor dou. Operatorii de comparare
care pot fi folosii n clauza WHERE sunt prezentai n tabelul urmtor:

Operator
=
<
<=
>
>=
!=
<>

Descriere
Egal cu
Mai mic dect
Mai mic sau egal
Mai mare dect
Mai mare sau egal
Diferit de
Diferit de (standard ANSI)

Exemple din schema FILM:

S se afieze toate filmele pentru care RATING are valoarea PG-13.

SELECT MPAA_RATING_COD AS RATING, TITLU_FILM
FROM FILM
WHERE MPAA_RATING_COD = 'PG-13'
ORDER BY TITLU_FILM;

S se afieze filmele pentru care COD_RATING are alt valoare dect

PG-13.
SELECT COD_RATING AS RATING, TITLU_FILM
FROM FILM
WHERE COD_RATING <> 'PG-13'
ORDER BY TITLU_FILM;

S se afieze toate filmele cu preul de vnzare cu amnuntul pentru

formatul DVD(DVD Retail Price) mai mare de 25.00, n ordinea
cresctoare a preurilor.
SELECT PRET_VANZARE_DVD, TITLU_FILM
FROM FILM
WHERE PRET_VANZARE_DVD >= 25.00
ORDER BY PRET_VANZARE_DVD DESC;
Exemple pe schema BIBLIOTECA

S se obtin codul crtii care are data restituirii >..

SELECT codel
FROM
imprumuta
WHERE
datares >= 05oct09;

S se obin titlurile i numrul de exemplare ale crilor care au

nrex>100 ;
SELECT titlu, nrex
FROM
carte
WHERE
nrex>100;

Operatori conjunctivi
Uneori sunt necesare condiii multiple pentru a ngusta setul de
rezultate al unei interogri. Atunci cnd sunt folosite mai multe condiii,
ele trebuie s fie combinate din punct de vedere logic n clauza WHERE,
iar aceasta este sarcina operatorilor conjunctivi. Aceti operatori sunt:
AND (I) - Clauza WHERE este evaluat ca adevrat" dac
toate condiiile conectate cu operatorul AND sunt adevrate.
OR (SAU) - Clauza WHERE este evaluat ca adevrat" dac
oricare din condiiile conectate cu operatorul OR este adevrat.
Operatorul AND are prioritate mai mare i, ca urmare, este evaluat
naintea operatorilor OR.
Exemple de folosire a operatorilor conjunctivi:

S se afieze toate filmele pentru care categoria RATING este PG13 i preul de vnzare cu amnuntul pentru formatul DVD este
19.99 sau mai mic, n ordinea cresctoare a preurilor.
SELECT COD_RATING AS RATING,
PRET_VANZARE_DVD AS PRET, TITLU_FILM
FROM FILM
WHERE COD_RATING = 'PG-13'
AND PRET_VANZARE_DVD <= 20.00
ORDER BY PRET_VANZARE_DVD;

S se afieze toate filmele pentru care categoria RATING este PG13 sau preul de vnzare cu amnuntul pentru formatul DVD este
19.99 sau mai mic, n ordinea cresctoare a preurilor.
SELECT COD_RATING AS RATING,
PRET_VANZARE_DVD AS PRET,
TITLU_FILM
FROM FILM
WHERE COD_RATING = 'PG-13' OR
PRET_VANZARE_DVD <= 20
ORDER BY PRET_VANZARE_DVD;

Afiai toate filmele pentru care categoria RATING este PG-13 i

sunt din genul dram sau aciune/aventur.
SELECT COD_RATING AS RATING,
PRET_VANZARE_DVD AS PRET, TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM= 'ActAd'
OR COD_GEN_FILM = 'Drama'
AND COD_RATING = 'PG-13'
ORDER BY COD_GEN_FILM, COD_RATING;

S se adauge parantezele necesare, astfel nct s obinem filmele

cu categoria PG-13 i genul aciune/aventur sau dram.
SELECT COD_GEN_FILM AS GEN,
COD_RATING AS RATING, TITLU_FILM
FROM FILM
WHERE (COD_GEN_FILM = 'ActAd'
OR COD_GEM_FILM = 'Drama')
AND COD_RATING='PG-13'
ORDER BY COND_GEN_FILM, COD_RATING;
Operatori logici

Operatorii logici folosesc cuvinte cheie n locul simbolurilor la

formarea expresiilor de comparare. La oricare dintre aceti operatori poate
fi adugat cuvntul cheie NOT, pentru a inversa valoarea logic a
comparaiei.

IS NULL
Operatorul IS NULL este folosit pentru a determina dac o valoare
este nul.
Exemple:
S se gseasc toate conturile de clieni active, adic toate conturile
pentru care coloana DATATERMINATA conine o valoare nul:
SELECT ID_CONT_CLIENT
FROM CONT_CLIENT
WHERE DATA_INCHEIERE IS NULL;

S se gseasc toate conturile inactive, adic toate conturile pentru

care coloana DATATERMINAT conine o alt valoare dect
NULL:
SELECT ID_CONT_CLIENT
FROM CONT_CLIENT
WHERE DATA_INCHEIERE IS NOT NULL;

BETWEEN
Operatorul BETWEEN este folosit pentru a determina dac o
valoare se ncadreaz ntr-un interval special. Intervalul este specificat
folosind o valoare minim i o valoare maxim, fiind un interval inclusiv,
ceea ce nseamn c include i valori specificate.
Exemple:
S se afieze toate filmele cu preul de vnzare cu amnuntul pentru
formatul DVD ntre 14.99 i 19.99, ordonate cresctor dup pre.
SELECT TITLU_FILM, PRET_VANZARE_DVD
FORM FILM
WHERE PRER_VANZARE_DVD BETWEEN 14.99 AND 19.99
ORDER BY PRER_VANZARE_DVD;

S se afieze toate filmele pentru care preul de vnzare cu amnuntul

pentru formatul DVD nu este n intervalul 14.99-19.99, ordonate
cresctor dup pre.
SELECT TITLU_FILM, PRET_VANZARE_DVD
FORM FILM
WHERE PRET_VANZARE_DVD NOT BETWEEN 14.99 AND 19.99
ORDER BY PRET_VANZARE_DVD;
S se afieze toate conturile de clieni n luna ianuarie 2009.
SELECT ID_CONT_CLIENT, DATA_INSCRIERE
FROM CONT_CLIENT
WHERE DATA_INSCRIERE BETWEEN 2009/01/01
AND 2009/01/31;
9

Tabelul DUAL se afl n schema SYS i poate fi accesat de ctre

toi utilizatorii. Tabelul este util atunci cnd se afieaz valoarea unei
constante, pseudocoloane sau expresii care nu este construit pe baza
datelor vreunui tabel. n general, tabelul DUAL este utilizat pentru a
completa sintaxa instruciunii SELECT, ntruct clauzele SELECT i
FROM sunt obligatorii.
S se afieze data i ora curent.
SELECT TO_CHAR(SYSDATE,DD/MM/YY HH24:MI:SS)
FROM DUAL;

LIKE
Operatorul LIKE este folosit pentru a compara o valoare de tip
caracter cu un tipar*(pattern), returnnd valoarea logic adevrat dac
valoarea de tip caracter se ncadreaz n tipar i fals" n caz contrar.
Pentru definirea tiparului pot fi folosite dou caractere de nlocuire:
Liniua de subliniere (_) - Caracterul liniu de subliniere poate fi
folosit drept caracter de nlocuire poziional, ceea ce nseamn c se
potrivete cu orice caracter aflat pe poziia respectiv n irul de
caractere evaluat.
Procent (%) - Simbolul procent (%) poate fi folosit drept caracter
de nlocuire nepoziional, ceea ce nseamn c se potrivete cu
orice numr de caractere, indiferent de lungime, reprezentnd orice
secven de zero sau mai multe caractere, i _, reprezentnd un
singur caracter.
Exemple de tipare:
Tipar
Now%
N_w

Interpretare
Se potrivete cu orice ir de caractere care incepe cu
Now".
Se potrivete cu orice ir de caractere format din
exact trei caractere, care ncepe cu N" i se termin
cu w".

10

%N-w%

%Now%
%Now

Se potrivete cu orice ir de caractere care conine

litera N", urmat de orice alt caracter, urmat de litera
w" (1a nceputul, la sfritul sau undeva n mijlocul
irului de caractere)
Se potrivete cu orice ir de caractere care conine
Now" (1a inceput, la sfrit sau n mijloc).
Se potrivete cu orice ir de caractere care se termin
cu Now".

Datele din bazele de date relaionale fac ntotdeauna diferenierea

literelor mari de cele mici. O liter mica din date nu se potrivete cu o
liter mare din tiparul unei clauze LIKE, i invers.
Exemple de utilizare a operatorului LIKE:
S se afieze toate titlurile de filme care conin irul de caractere
on":
SELECT TITLU_FILM
FROM FILM
WHERE TITLU_FILM LIKE '%on%';
Dac se intenioneaz s se gseasc titlurile care conin cuvntul
on", nu literele on" din alte cuvinte, ar fi trebuit s includ n
tipar i spatiile necesare, ca n exemplul urmtor:
Exemple
S se afieze cartile ale cror titlu conine cuvntul Baza, sau
pentru care al treilea caracter din autor este p.
SELECT titlu, autor
FROM carte
WHERE titlu LIKE '%Baza%' OR

autor LIKE '__p%';

11

IN
Operatorul IN este folosit pentru a determina dac o valoare face
parte dintr-o list de valori. Lista poate fi specificat ca valori literale,
folosind o list de valori separate prin virgule i ncadrate ntre paranteze,
sau poate fi selectat din baza de date folosind o subselecie (o
subinterogare), care este o interogare n cadrul unei alte interogri.
Exemple de utilizare a operatorului IN:
S se afieze toate filmele pentru care COD_GEN_FILM este
Drama, Forgn.
SELECT COD_GEN_FILM AS GEN, TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM IN ('Drama', 'Forgn')
ORDER BY COD_GEN_FILM, TITLU_FILM;
S se afieze toate filmele pentru care descrierea genului conine
cuvntul and". Avei nevoie de o subinterogare prin care s
gsii toate valorile COD_GEN_FILM care conin cuvntul
and" n descriere. Operatorul IN este apoi folosit pentru a gsi
filmele care au unul dintre codurile selectate de subinterogare.
SELECT COD_GEN_FILM AS GEN, TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM IN
(SELECT COD_GEN_FILM
FROM GEN_FILM
WHERE GEN_FILM DESCRIPTION LIKE '% and %')
ORDER BY COD_GEN_FILM AS GEN, TITLU_FILM;
S se afieze toate cartile din domeniile Isi M.
SELECT TITLU, AUTOR
FROM CARTE
WHERE CODED IN(I,M);

12

EXISTS
Operatorul EXISTS este folosit pentru a detemina dac o
subinterogare conine nregistrri. Dac n setul de rezultate al
subinterogrii nu exist nici un rnd, operatorul returneaz valoarea
false; dac setul de rezultate conine cel puin un rnd, valoarea devine
adevrat.
Exemple de utilizare a operatorului EXIST:
Proprietarul magazinului a auzit c filmul The Last Samurai se
nchiriaz bine att n format DVD, ct i-n format VHS i vrea s
se asigure c n inventarul magazinului exist o copie VHS.
Tabelul FILM_COPIAT conine un rnd pentru fiecare copie a
unui film din inventarul magazinului, aa c putei folosi o
subinterogare pentru a afla dac exist copii VHS ale filmului n
inventar. De cele mai multe ori, operatorul EXISTS este folosit in
conjuncie cu o form mai complex de subinterogare, numit
subinterogare corelat. (correlated subquery),n care valorile
datelor din interogarea extern (ID_FILM, n acest caz) sunt
comparate cu rndurile din interogarea inten.
SELECT ID_FILM, TITLU_FILM
FROM FILM M
WHERE TITLU_FILM = 'The Last Samurai'
AND EXISTS
(SELECT ID_FILM
FROM FILM_COPIAT C
WHERE M. ID_FILM = C. ID_FILM);
Dac inversai logica, folosind operatorul NOT EXISTS, putei
afia titlul filmului numai dac nu exist o copie VHS n inventar.
SELECT ID_FILM, TITLU_FILM
FROM FILM M
WHERE TITLU_FILM = 'The Last Samurai'
AND NOT EXISTS
(SELECT ID_FILM
FROM FILM_COPIAT C
WHERE M. ID_FILM = C. ID_FILM);

13

Operatori aritmetici
n SQL, operatorii aritmetici sunt folosii pentru efectuarea
calculelor matematice la fel ca i n formulele dintr-o foaie de calcul
tabelar sau ntr-un limbaj de programare, precum Java sau C. Cei patru
operatori aritmetici din SQL sunt:
Operator
+
*
/

Descriere
Adunare
Scdere
nmulire
mprire

Ca i n cazul operatorilor conjunctivi, dac se amestec operatorii

aritmetici n aceeai instruciune SQL fr a folosi paranteze, ordinea n
care sunt evaluate operaiile este determinat de prioritatea predefinit.
Din fericire, prioritatea operatorilor din SQL este cea pe care o folosim n
operaiile matematice obinuite.
Exemple de utilizare a operatorilor aritmetici:
Ct v-ar costa s cumprai copiile VHS i DVD ale filmului The Last
Samurai?
SELECT PRET_VANZARE_VHS + PRET_VANZARE _DVD
AS COST
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';
Ct v-ar costa aceeai achiziie dac ai avea un bon valoric de 8 ron?
SELECT (PRET_VANZARE _VHS + PRET_VANZARE _DVD) - 8
AS COST
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';
Dac taxele sunt de 8.25% (0.0825), ct reprezint taxele de vnzare
din costul achiziiei anterioare?
SELECT (PRET_VANZARE _VHS+ PRET_VANZARE _DVD) *
0.0825 AS TAX
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';
Care este costul mediu pentru o copie a filmului The Last Samurai?
SELECT (PRET_VANZARE_VHS+PRET_VANZARE _DVD) / 2
AS AVG_COST
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai'

14

Funcii SQL elementare

O funcie este un tip special de program, care returneaz o singur
valoare de fiecare data cnd este apelat. Termenul provine de la
conceptul matematic al unei funcii. n SQL, funciile necesit
ntotdeauna specificarea unei expresii, care deseori include numele unei
coloane. Cel mai des, funciile sunt folosite n lista de coloane a unei
instruciuni SELECT, sunt apelate pentru fiecare rnd prelucrat de
interogare i, ca urmare, returneaz o singur valoare pentru fiecare rnd
din setul de rezultate. Uneori este folosit termenul funcie de coloan,
pentru a indica faptul c o funcie este aplicat unei coloane dintr-un tabel
sau o vizualizare. Un numr de funcii sunt furnizate de productorul
DBMS i se pot scrie propriile funcii, folosind un limbaj special livrat
mpreun cu sistemul DBMS, cum ar fi PL/SQL pentru Oracle sau
Transact SQL pentru Microsoft SQL Server i Sybase Adaptive Server.
Atenie la folosirea funciilor SQL n condiiile WHERE. n cele
mai multe situaii, pentru o coloan creia i este aplicat o funcie nu
poate fi folosit indexarea. Ca urmare, n cazul tabelelor mari, utilizarea
funciilor n condiiile WHERE poate duce la probleme de performan cu
adevrat memorabile.
Funciile pot fi clasificate n multe moduri, dar majoritatea
specialitilor le mpart dup ceea ce fac.
Funcii pentru caractere
Funciile pentru caractere sunt numite astfel deoarece manipuleaz
date de tip text.
Concatenarea irurilor de caractere
Funcia de concatenare a irurilor de caractere reunete mai multe
iruri de caractere pentru a forma o singur valoare n rezultatele
interogrii. Funcia standard de concatenare a irurilor de caractere din
SQL este apelat cu dou bare verticale (||), dar exist i excepii, cum ar
fi Microsoft SQL Server, care folosete semnul plus (+) pentru
concatenarea irurilor de caractere.
Exemple de concatenare a irurilor de caractere:
Magazinul de produse video vrea s trimit fiecrui client o
scrisoare care ncepe cu formula "Client", plus prenumele i
numele persoanei. Numele sunt stocate n tabelul PERSON. Soluia
acestei cerinte n Oracle:
SELECT 'Client' || NUME_PERSOANA||
' ' || NUME_FAMILIE_PERSOANA AS SALUT_CLIENT
FROM PERSOANA;
15

Aceeai soluie, modificat pentru a funciona n Microsoft SQL

Server :
SELECT Client' + NUME_PERSOANA +
' ' + NUME_FAMILIE_PERSOANA AS SALUT_CLIENT
FROM PERSOANA;
<nume angajat> castiga <salariu> lunar, dar doreste <salariu de 3
ori mai mare>
SELECT last_name||'castiga'||salary||'lunar, dar doreste'||salary*3 "salariul
ideal"
FROM employees;
UPPER
Funcia UPPER este deseori folosit n condiiile WHERE.
Funcia UPPER transform literele dintr-un ir de caractere n litere mari.
Numerele i caracterele speciale sunt lsate ca stare.
Exemple:
S se afieze comediile (COD_GEN_FILM = 'Comdy') scriind
titlurile cu majuscule.
SELECT UPPER(TITLU_FILM) AS TITLU_FILM
FROM FILM
WHERE COD_GEN_FILM = 'Comdy';
S presupunem c nu v amintii dac valorile COD_GEN_FILM
au fost stocate cu litere mari, litere mici sau combinaii ale
acestora. Dac n condiia WHERE transformai valorile n litere
mari, putei obine rezultatele corecte indiferent de modul de
stocare.
SELECT UPPER(TITLU_FILM) AS TITLU_FILM
FROM FILM
WHERE UPPER(COD_GEN_FILM) = 'COMDY';
LOWER
Funcia LOWER este inversa funciei UPPER transform
literele dintr-un * de caractere n litere mici.
Exemple de utilizare a funciei LOWER:
S se afieze comediile (GEN_COD_FILM = 'Comedy') scriind
titlurile cu minuscule.
SELECT LOWER(TITLU_FILM) AS TITLU_FILM
FROM FILM
WHERE GEN_COD_FILM = 'Comedy';

16

 Se poate folosi funcia LOWER ntr-o clauz WHERE, atunci cnd

nu titi sigur ce tip de litere obine textul pe care vrei s-1
comparai. Afiai toate filmele care au n titlu cuvntul of ",
indiferent dac este scris cu litere mari sau mici.
SELECT TITLU_FILM
FROM FILM
WHERE LOWER(TITLU_FILM) LIKE ' % of %'
OR LOWER(TITLU_FILM) LIKE 'of % '
OR LOWER(TITLU_FILM) LIKE ' % of ';
SUBSTR
Funcia SUBSTR apare n majoritatea implementrilor SQL, dar
uneori are un nume puin diferit. De exemplu, funcia se numete
SUBSTRING n Microsoft SQL Server, Sybase Adaptive Server i
MySQL, dar SUBSTR n Oracle i D132. Funcia returneaz o poriune a
irului de caractere, n funcie de parametrii furnizai, care specific
numele coloanei, poziia de nceput a subirului n datele coloanei i
lungimea subirului returnat (numrul de caractere). Dei este o utilizare
mai puin obinuit, funcia SUBSTR accept i un ir de caractere literal
n locul numelui unei coloane. Iat forma general a funciei, urmat de
un exemplu:
SUBSTR (numele coloanei, poziia de nceput, lungimea subirului
n tabelul PERSON, unele persoane au al doilea nume n ntregime,
alii au numai initiale. Afiati numele complet al persoanelor al
cror nume de familie ncepe cu litera B", sub forma unui singur
ir de caractere care conine prenumele, iniiala i numele de
familie.
SELECT NUME_PERSOANA || ' ' ||
SUBSTR(PRENUME_PERSOANA, 1, 1) || ' . ' ||
NUME_FAMILIE_PERSOANA AS NUME_INTREG
FROM PERSOANA
WHERE SUBSTR(NUME_FAMILIE_PERSOANA, 1, 1)='B'
Observai folosirea funciei SUBSTR n clauza WHERE pentru a
elimina din rezultate persoanele al cror nume de familie nu ncepe cu
litera B". Ar trebui s v putei deja gndi la alte moduri de a face acest
lucru, prin folosirea operatorului LIKE.

17

LENGTH
Funcia LENGTH returneaz lungimea unui ir de caractere.
Microsoft SQL Server i Sybase Adaptive Server folosesc numele LEN
pentru versiunea proprie a acestei funcii.
Exemple:
S se afieze lungimea titlului pentru filmul a crui valoare
ID_FILM este 1. Presupunem c folosii o baz de date oracle,
DB2 sau MySQL.

SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH

FROM FILM
WHERE ID_FILM = 1;

SELECT TITLU_FILM, LENGTH (TITLU_FILM) AS LENGTH

FROM FILM
WHERE LENGTH (TITLU_FILM) < 10;
Funii matematice
Funciile matematice manipuleaz valori numerice, n conformitate
cu regulile matematicii.
ROUND
Funcia ROUND rotunjete o valoare la un numr specificat
de zecimale. Valoarea numeric este furnizat prin primul parametru, iar
numrul de zecimale prin cel de-al doilea. n continuare este prezentat
formatul general al funciei ROUND.
ROUND (expresie numeric, numr de poziii zecimale)
Care este costul mediu al unei copii a filmului The Last Samurai,
rotunjit la dou zecimale?
SELECT ROUND((PRET_VANZARE_VHS +
PRET_VANZARE _DVD) / 2, 2) AS AVG_COST
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';
Alte funcii matematice
Tabelul care urmeaz prezint funciile matematice cel mai
des ntlnite. Pentru toate, sintaxa general este aceeai:
NUME_FUNCTIE (expresie)

18

Funcie
ABS
COS
EXP
POWER
SIN
TAN

Descriere
Valoarea absolut a unui numr dat
Cosinusul trigonometric al unui unghi specificat n radiani
Valoarea exponenial a unui numr dat
Ridic un numr la o putere (numrul i puterea sunt fumizate
ca parametri)
Sinusul trigonometric al unui unghi specificat n radiani
Tangenta trigonometric a unui unghi specificat n radiani

Funcii de conversie
Funciile de conversie transform date dintr-un tip de date n altul.
CAST
Funcia CAST transform date dintr-un tip de date n altul. Iat
sintaxa general a funciei CAST, urmat de un exemplu:
CAST (expresie AS tip de date)
Afiati preul pentru formatul DVD al filmului The Last Samurai,
cu un simbol dolar n faa sumei. Valoarea numeric trebuie s fie
convertit ntr-un ir de caractere pentru a putea fi concatenat cu o
valoare literal coninnd simbolul dolar.
SELECT '$' ||
CAST(PRET_VANZARE _DVD
AS
VARCHAR(6)) AS PRET
FROM FILM
WHERE TITLU_FILM = 'The Last Samurai';

Funcii de agregare i gruparea rndurilor

O funcie de agregare (aggregate functions) este o funcie care
combin mai multe rnduri de date ntr-un singur rnd. Tabelul urmtor
prezint funciile de agregare acceptate n majoritatea implementrilor
SQL:
Funcie Descriere
AVG
Calculeaz valoarea medie pentru o coloan sau o
expresie.
COUNT Numr valorile dintr-o coloan.
MAX
Gsete valoarea maxin dintr-o coloan.
MIN
Gsete valoarea minim dintr-o coloan.
SUM
nsumeaz valorile dintr-o coloan.
Exemple:
Care este preul mediu al unui DVD?

19

SELECT ROUND(AVG(PRET_VANZARE _DVD),2) AS

AVG_PRET
FROM FILM;
Cte filme exist n tabelul FILM?
SELECT COUNT(*) AS NUM_FILM
FROM FILM;
Cte genuri diferite de filme sunt reprezentate n tabelul FILM?
SELECT COUNT(DISTINCT COD_GEN_FILM) AS NUM_GEN
FROM FILM;
Care sunt lungimea minim i maxim a titlurilor filmelor?
SELECT MIN(LENGTH(TITLU_FILM)) AS MIN_LENGTH,
MAX(LENGTH(TITLU_FILM)) AS MAX_LENGTH
FROM FILM;
Clauza GROUP BY
GROUP BY cere sistemului DBMS s grupeze rndurile selectate
de interogare pe baza valorilor din una sau mai multe coloane i s aplice
funcia (sau funciile) de agregare fiecrui grup, returnnd un rnd pentru
fiecare grup din setul de rezultate.
Sistemul DBMS va ordona rndurile selectate de interogare dup
coloanele din clauza GROUP BY, aa c grupurile vor fi returnate n
ordine ascendent, exceptnd cazul n care se adug o clauz ORDER
BY care specific un alt mod de ordonare.
Iat un exemplu:
Afiati fiecare cod de gen, mpreun cu numrul de filme asociate
fiecrui cod.
SELECT COD_GEN_FILM AS GEN, COUNT(*) AS COUNT
FROM FILM
GROUP BY COD_GEN_FILM;
Ce se ntmpl dac scoatei clauza GROUP BY din aceast
interogare? Sistemul DBMS retumeaz un mesaj de eroare i, din
nefericire, mesajul de eroare este deseori destul de criptic. Functia
COUNT(*) este o functie de agregare i, n absenta clauzei GROUP BY,
retumeaz un singur rnd de date.
Exemplele care urmeaz arat modul general de constituire a
subansamblelor virtuale folosind clauza GROUP BY. Fiecare expresie
care apare n SELECT trebuie s aib aceeai valoare pentru toate liniile
care aparin aceleiai partiii. Numele coloanelor din GROUP BY nu
trebuie s figureze obligatoriu n lista de la SELECT.
Clauza WHERE are prioritate fata de GROUP BY. Nu se poate
utiliza alias de coloana in clauza GROUP BY.
20

Pentru a returna informatie corespunxatoare fiecarui grup, pot fi

utilizate functiile agregat. Acestea pot aparea in clauzele SELECT,
ORDER BY si HAVING. Se poate utiliza functie grup in clauza WHERE?
Este corect WHERE AVG(sal) > 200? NU!
Cand se utilizeaza GROUP BY, server-ul sorteaza implicit
multimea rezultata in ordinea crescatoare a valorilor coloanelor dupa care
se realizeaza gruparea.
Grupurile sunt formate si functiile grup sunt calculate, inainte ca
clauza HAVING sa fie aplicata grupurilor.
Exemplu:
S se obin numrul de cte ori a fost mprumutat fiecare carte.
SELECT codel, COUNT(*)
FROM
imprumuta
GROUP BY codel;
Exemplu:
Pentru fiecare domeniu de carte s se obin numrul crilor din
domeniu, media preurilor i numrul total de exemplare.
SELECT coded,COUNT(*), AVG(pret),SUM(nrex)
FROM
carte
GROUP BY coded;
Dac n comanda SELECT apar atribute coloan (nu funcii grup) i
se utilizeaz clauza GROUP BY atunci aceste coloane trebuie obligatoriu
s apar n clauza GROUP BY.
Exemplu:
S se obin pentru fiecare autor, media preurilor crilor din
bibliotec.
SELECT autor, AVG(pret)
FROM
carte
GROUP BY
autor;
Exemplu:
Pentru departamentele n care salariul maxim depete 5000$ s
se obin codul acestor departamente i salariul maxim pe departament.
SELECT

deptno, MAX(sal)

FROM
GROUP BY
HAVING

emp
deptno
MAX(sal)>5000;

21

Exemplu:
SELECT

MAX(AVG(pret))

FROM
GROUP BY

carte
autor;

Exemplu:
S se afieze numele i salariul celor mai prost pltii angajai
din fiecare departament.

SELECT
FROM
WHERE

ename, sal

emp
(deptno, sal) IN
(SELECT deptno, MIN(sal)
FROM emp
GROUP BY deptno);

Exemplu:
S se obin pentru fiecare carte, codul su i numrul de
exemplare care nu au fost nc restituite.
SELECT
FROM

codel, COUNT(*)
imprumuta

WHERE
dataef IS NULL
GROUP BY codel;
Exemplu:
S se obin numrul crilor mprumutate cel puin o dat.
SELECT COUNT(DISTINCT codel)
FROM

imprumuta;

Exemplu:
S se afieze numrul crilor mprumutate cel puin de dou ori
(pentru fiecare carte mprumutat mai mult dect o dat s se obin
numrul de cte ori a fost mprumutat).
SELECT
FROM
GROUP BY
HAVING

COUNT(COUNT(codel))
imprumuta
codel
COUNT(*)>1;

22

n cererea anterioar COUNT(codel), reprezint numrul care arat

de cte ori a fost mprumutat fiecare carte, iar COUNT(COUNT(codel)),
reprezint numrul total al crilor mprumutate.
Exemplu:
Pentru fiecare departament codul dep si numarul de angajati.
1 select department_id, count(*)
2 from employees
3* group by department_id
SQL> /
DEPARTMENT_ID COUNT(*)
------------- ---------10
1
20
2
30
6
40
1
50
45
60
5
70
1
80
34
90
3
100
6
110
2
1
12 rows selected.
Pentru departamentele cu mai mult de un angajat se afiseaza codul dep si
numarul de angajati.
1 select department_id, coun
2 from employees
3 group by department_id
4* having count(*)>1
SQL> /
DEPARTMENT_ID COUNT(*)
------------- ---------20
2
30
6
50
45
60
5
80
34
90
3
23

100
110

6
2

8 rows selected.
Se afiseaza numarul departamentelor cu mai mult de un angajat.
1 select count(count(*))
2 from employees
3 group by department_id
4* having count(*)>1
SQL> /
COUNT(COUNT(*))
--------------8
Exemplu:
Sa se afiseze numrul de cri imprumutate din fiecare domeniu.
SELECT d.intdom, COUNT(*)
FROM domeniu d, carte c, imprumuta I
WHERE c.codel = i. codel
AND c.coded = d.coded
GROUP BY intdom;

Exemplu:
Lista codurilor cititorilor care au mai mult de 3 cri nerestituite la
termen.

SELECT

codec

FROM
imprumuta
WHERE
dataef IS NULL AND datares < SYSDATE
GROUP BY codec
HAVING COUNT(*) > 2;
Exemplu:
Pentru fiecare domeniu de carte care conine cel puin o carte i
unde preul oricrei cri nu depete o valoare dat, s se obin: codul
domeniului, numrul crilor din domeniu i numrul mediu de
exemplare.
SELECT coded, COUNT(*), AVG(nrex)
FROM
carte
GROUP BY coded
24

HAVING
AND

COUNT(*) >= 1
MAX(pret) < &pret_dat;

Exemplu:
Codurile domeniilor care nu contin carti.
SELECT
coded
FROM
carte
GROUP BY coded
HAVING COUNT(*) = 0;
Nu este corect, deoarece se iau in considerare NUMAI codurile
domeniilor care apar in tabelul CARTE.
SELECT
intdom
FROM
domeniu d
WHERE 0 = (SELECT COUNT(*)
FROM carte
WHERE coded = d.coded);
Urmatoarea cerere este corecta?
SELECT intdom
FROM
domeniu d,(SELECT coded, COUNT(*) a
FROM carte
GROUP BY coded) b
WHERE b.coded = d.coded)
AND b.a = o;
Exemplu:
n ce interogri este necesar utilizarea cuvntului cheie
HAVING?
A.
B.
C.
D.

cnd este necesar s eliminm linii duble din rezultat;

cnd este necesar s ordonm mulimea rezultat;
cnd este necesar s efectum un calcul pe grup;
cnd este necesar s restricionm grupurile de linii returnate.

Operatori pentru interogri compuse

Uneori este util s se ruleze interogri multiple i s se combine
rezultatele ntr-un singur set de rezultate.
UNION
Operatorul UNION adaug rndurile din setul de nregistrri al
unei interogri la cel al unei alte inregistrri i, n acelai timp, elimin
rndurile duplicate, ntr-un mod similar cu cel al cuvntului cheie

25

DISTINCT. Operaia este permis numai dac interogrile sunt

compatibile din punctul de vedere al uniunii, ceea ce nseamn c au
acelai numr de coloane i c tipurile de date ale coloanelor
corespondente sunt compatibile.
Iat un exemplu:
Afiai pe o singur coloan toate valorile nenule pentru taxa de
inchiriere i taxa de ntrziere din tabelul FILM_NCHIRIAT.
SELECT INCHIRIAT_FEE AS FEE
FROM FILM_INCHIRIAT
WHERE INCHIRIAT _FEE IS NOT NULL
UNION
SELECT LATE_OR_LOSS_FEE AS FEE
FROM FILM_INCHIRIAT
WHERE LATE _OR_ LOSS FEE IS NOT NULL;
UNION ALL
UNION ALL funcioneaz la fel ca i operatorul UNION,
exceptnd faptul c rndurile duplicate nu sunt eliminate.
INTERSECT
Operatorul INTERSECT gsete valorile selectate dintr-o
interogare, care apar i ntr-o alt interogare. n esen, gsete intersecia
valorilor din cele dou interogri. Totui, doar un numr mic de sisteme
DBMS (cele mai importance fiind Oracle i DB2) implementeaz acest
operator. Nu-1 vei gsi n Microsoft SQL Server sau MySQL.
Iat un exemplu:
Exist n tabelul FILM filme pentru care preul pentru DVD este
egal cu preul pentru VHS?
SELECT INCHIRIAT_FEE AS FEE
FROM FILM_ INCHIRIAT
WHERE INCHIRIAT _FEE IS NOT NULL
INTERSECT
SELECT LATE_OR_LOSS_FEE AS FEE
FROM FILM_ INCHIRIAT
WHERE LATE OR_ LOSS FEE IS NOT NULL

EXCEPT
EXCEPT este operatorul standard ANSI/ISO care gsete
diferenele dintre dou seturi de rezultate, returnnd, n esen, valorile

26

din prima interogare care nu apar n cea de-a doua interogare. Foarte
puine sisteme DBMS implementeaz acest operator. n unele
implementri, precum Oracle, operatorul se numete MINUS, nu
EXCEPT.

27

Cereri multi relaie

Comanda SELECT ofer posibilitatea de a consulta informaii care provin
din mai multe tabele. Operatorii care intervin n astfel de cereri pot fi:
operatori pe mulimi (UNION, UNION ALL, INTERSECT, MINUS);
operatori compunere care implementeaz diferite tipuri de JOIN.
Exist dou moduri de realizare a cererilor multi-relaie:
forma procedural, n care trebuie indicat drumul de acces la informaie
prin imbricarea de comenzi SELECT;
forma relaional, n care drumul de acces la informaie este n sarcina
sistemului.
Exemplu:
S se obin, utiliznd aceste dou forme, codurile i titlurile crilor
mprumutate.
a) Forma procedural (imbricare de comenzi SELECT):
SELECT codel, titlu
FROM
carte
WHERE
codel IN (SELECT DISTINCT codel
FROM imprumuta);
b) Forma relaional:
SELECT carte.codel, titlu
FROM
carte, imprumuta
WHERE
carte.codel = imprumuta.codel;

Operatori pe mulimi sau Operatori pentru interogri

compuse (UNION, UNION ALL, INTERSECT, MINUS)
Uneori este util s se ruleze interogri multiple i s se combine rezultatele
ntr-un singur set de rezultate.
Operatorii pe mulimi combin rezultatele obinute din dou sau mai multe
interogri. Cererile care conin operatori pe mulimi se numesc cereri compuse.
Exist patru operatori pe mulimi: UNION, UNION ALL, INTERSECT i
MINUS(n unele implementeri oracle operatorul MINUS se numete EXCEPT).
Toi operatorii pe mulimi au aceeai preceden. Dac o instruciune SQL
conine mai muli operatori pe mulimi, server-ul Oracle evalueaz cererea de la
stnga la dreapta (sau de sus n jos). Pentru a schimba aceast ordine de evaluare,
se pot utiliza paranteze.

n mod implicit, pentru toi operatorii cu excepia lui UNION ALL, rezultatul
este ordonat cresctor dup valorile primei coloane din clauza SELECT.
Pentru o cerere care utilizeaz operatori pe mulimi, cu excepia lui UNION
ALL, server-ul Oracle elimin liniile duplicat.
n instruciunile SELECT asupra crora se aplic operatori pe mulimi,
coloanele selectate trebuie s corespund ca numr i tip de date. Nu este necesar
ca numele coloanelor s fie identice. Numele coloanelor din rezultat sunt
determinate de numele care apar n clauza SELECT a primei cereri.
n cazul n care cererile componente selecteaz date de tip caracter, tipul
de date al valorii returnate poate fi CHAR, dac valorile selectate de ambele
cereri sunt de tip CHAR, sau VARCHAR2, dac valorile selectate de cel puin
una din cele dou cereri sunt de tip VARCHAR2.
Observaii:
Comenzile SELECT, care intervin n cereri ce conin operatori pe mulimi,
trebuie s satisfac anumite condiii:
toate comenzile SELECT trebuie s aib acelai numr de coloane;
opiunea DISTINCT este implicit (excepie UNION ALL);
numele coloanelor sunt cele din prima comand SELECT;
dimensiunea coloanei implicit este cea mai mare dintre cele dou coloane;
sunt admise combinaii de forma:
1.
SELECT1 UNION SELECT2 INTERSECT SELECT3 i ordinea de
execuie este de la stnga la dreapta;
2.
SELECT1 UNION (SELECT2 INTERSECT SELECT3) i ordinea
este dat de paranteze.
UNION
Operatorul UNION adaug rndurile din setul de nregistrri al unei
interogri la cel al unei alte interogri i, n acelai timp, elimin rndurile
duplicate, ntr-un mod similar cu cel al cuvntului cheie DISTINCT.
Operatorul UNION returneaz deci toate liniile selectate de dou cereri,
eliminnd duplicatele. Operaia este permis numai dac interogrile sunt
compatibile din punctul de vedere al uniunii, ceea ce nseamn c au acelai numr
de coloane i c tipurile de date ale coloanelor corespondente sunt compatibile.
Acest operator nu ignor valorile null i are preceden mai mic dect operatorul
IN.

Exemplu:
S se afieze pe o singur coloan toate valorile nenule pentru taxa de
inchiriere i taxa de ntrziere din tabelul FILM_NCHIRIAT.
SELECT taxa_inchiriat AS TAXA
FROM FILM_INCHIRIAT
WHERE taxa_inchiriat IS NOT NULL UNION
SELECT taxa_intarziere AS TAXA
FROM FILM_INCHIRIAT
WHERE taxa_intarziere IS NOT NULL;

Exemplu:
S se afieze codurile operelor de art pentru care a fost ncheiat o poli
de asigurare sau care beneficiaz de un sistem de securitate. Fiecare cod va fi
afiat o singur dat.
SELECT
FROM
UNION
SELECT
FROM

cod_opera
polita_asig
cod_opera
securitate;

Uneori, pentru a respecta regula conform creia expresiile din clauzele

SELECT trebuie s concorde ca numr i tip de date, se pot utiliza coloane
artificiale i funcii de conversie pentru tipurile de date.
Exemplu:
S se listeze codul operelor de art, codul i numele artitilor.
SELECT
FROM
UNION
SELECT
FROM

cod_opera, cod_artist, TO_CHAR(null) nume

opera
TO_NUMBER(null), cod_artist, nume
artist;

UNION ALL
Operatorul UNION ALL funcioneaz la fel ca i operatorul UNION,
exceptnd faptul c rndurile duplicate nu sunt eliminate.
Precizrile fcute asupra operatorului UNION sunt valabile i n cazul
operatorului UNION ALL. n cererile asupra crora se aplic UNION ALL nu poate
fi utilizat cuvntul cheie DISTINCT.

Exemplu:
S se determine codul operelor de art pentru care s-a ncheiat o poli de
asigurare sau pentru care s-a achiziionat un sistem de securitate. S se afieze
firma i data contractrii, respectiv a instalrii sistemului. ntruct o oper poate
avea mai multe polie de asigurare sau mai multe sisteme de securitate
ncheiate, respectiv instalate la aceeai firm i dat, nu se vor suprima liniile
duplicat. Rezultatul va fi ordonat dup codul operelor.
SELECT cod_opera, firma, semnat_contract
FROM polita_asig
UNION ALL
SELECT cod_opera, firma, data_inst
FROM polita_asig
ORDER BY cod_opera;
Clauza ORDER BY poate aprea numai o singur dat ntr-o cerere compus.
Dac se utilizeaz, clauza trebuie plasat la sfritul cererii i accept nume de
coloane, alias-uri sau notaia poziional. Numele de coloane i alias-urile din
clauza ORDER BY trebuie s fie din lista SELECT a primei instruciuni.
INTERSECT
Operatorul INTERSECT gsete valorile selectate dintr-o interogare, care
apar i ntr-o alt interogare. n esen, gsete intersecia valorilor din cele dou
interogri. Acest operator nu ignor valorile null.
Totui, doar un numr mic de sisteme DBMS (cele mai importance fiind
Oracle i DB2) implementeaz acest operator. Nu-1 vei gsi n Microsoft SQL
Server sau MySQL.
Exemplu:
Exist n tabelul FILM filme pentru care preul pentru DVD este egal cu
preul pentru VHS?
SELECT taxa_inchiriat AS TAXA
FROM FILM_INCHIRIAT
WHERE taxa_inchiriat IS NOT NULL
INTERSECT
SELECT taxa_intarziere AS TAXA
FROM FILM_INCHIRIAT
WHERE taxa_intarziere IS NOT NULL;

Exemplu:
S se afieze codul operelor de art, respectiv data la care s-a ncheiat o
poli de asigurare i s-a instalat un sistem de securitate.
SELECT cod_opera, semnat_contract
FROM polita_asig
INTERSECT
SELECT cod_opera, data_inst
FROM securitate;
Exemplu:
S se obin, utiliznd operatorul INTERSECT, codurile crilor din care sunt
mai puin de 15 exemplare i care au fost mprumutate de cel puin trei ori.
SELECT codel
FROM
carte
WHERE
nrex < 15
INTERSECT
SELECT codel
FROM
imprumuta
GROUP BY codel
HAVING COUNT(*) > 3;
MINUS
Operatorul MINUS sau EXCEPT gsete diferenele dintre dou seturi de
rezultate, returnnd, n esen, valorile din prima interogare care nu apar n cea dea doua interogare. Pentru ca operatorul MINUS s funcioneze, este necesar ca
toate coloanele din clauza WHERE s se afle i n clauza SELECT. Foarte puine
sisteme DBMS implementeaz acest operator. n unele implementri, precum
Oracle, operatorul se numete MINUS, nu EXCEPT.
Exemplu:
S se determine codul i valoarea operelor de art al cror pre nu este de
20 de ori mai mare dect valoarea poliei de asigurare.
SELECT cod_opera, valoare

FROM opera
MINUS
SELECT cod_opera, valoare*20
FROM polita_asig;
Exemplu:
S se afieze codurile cititorilor care nu au mprumutat cri.
SELECT codec
FROM
cititor
MINUS
SELECT DISTINCT codec
FROM
imprumuta;
Operatorii pe mulimi pot fi utilizai n subcereri. Coloanele care apar n
clauza WHERE a interogrii trebuie s corespund, ca numr i tip de date, celor
din clauza SELECT a subcererii.
Exemplu:
S se determine codul operelor de art, codul autorilor i titlul pentru
operele a cror valoare este mai mare dect 5000 sau pentru cele avnd valoarea
de 20 de ori mai mare dect cea a poliei de asigurare.
SELECT cod_opera, cod_artist, titlu
FROM opera
WHERE (cod_opera, valoare)
IN (SELECT cod_opera, valoare
FROM opera
WHERE valoare > 5000
UNION
SELECT cod_opera, valoare*20
FROM polita_asig);

Operaia de compunere (JOIN)

S-au prezentat pn acum instruciuni SQL care selecteaz date dintr-un
singur tabel. Deseori, este util s se combine date din tabele multiple ntr-o singur
interogare. De exemplu, n listingul celor trei coloane ale tabelului FILM din
figura urmtoare, observai valorile afiate pentru coloan FILM_GEN_COD.
Atunci cnd s-a proiectat baza de date pentru magazinul de produse video, s-au
folosit coduri n locul descrierilor complete pentru genurile filmelor n tabelul
FILM. Din discuia despre procesul de normalizare, s-a evitat anomalia de
actualizare dac se schimb descrierea unui gen, nu este nevoie s actualizm
acea descriere pentru toate filmele asociate genului respectiv n tabelul FILM. n
timpul normalizrii, descrierea genurilor a fost mutat n tabelul, FILM_GEN, iar
coloan FILM_GEN_COD a devenit cheie extern n tabelul FILM, referind
coloan cheie primar (cu acelai nume) din tabelul FILM_GEN. S-a optat pentru
folosirea unui cod mnemonic pentru codurile genurilor.
Tabelul FILM (trei coloane)
FILM_COD
FILM_GEN_COD
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Drama
ActAd
Comedie
ActAd
ActAd
ActAd
Drama
ActAd
ActAd
Drama
Rmce
Comedie
Comedie
Drama
Drama
Comedie
Rmce
Drama
ActAd
Forgn

FILM_TITLU

Mystic River
The Last Samurai
Something's Gotta Grve
The Italian
Kill Bill: Voi. 1
Pirates of the Caribbean: Trie Curse of the Black Pearl
Big Fish
Man on Fire
Master and Commander The Far Side of the World
LosI n Translation
Two Weeks Notice
50 First Dates
Matchstick Men
Cold Mountain
Road to Perdition
The School of Rock
13 Going on30
Monster
The Day After Tomorrow
Das Boot

Evident, nu putei afia pe pagina web a magazinului de produse video,

tabelul FILM aa cum este prezentat n figura de mai sus - trebuie s obinei
descrierea complet a genurilor din tabelul FILM_GEN. Aceasta este ideea
capitolului de fa: combinarea datelor din mai multe tabele ntr-o singur
interogare. Figura urmtoare prezint un listing al tabelului FILM_GEN.
Tabelul FILM_GEN
FILM_GEN_COD
ActAd
Anime
ChFam
Class
Comedie
Doc
Drama
Forgn
Hor
Indep
Music
Rmce
SciFi
Sport
Thriller

FILM_GEN_DESCRIERE
Actiune
Animatie
Copii i Familie
Clasic
Comedie
Documentar
Drama
Strain
Horror
Independent
Muzical
Romance(Romantic, Idila)
Stiintifico-Fantastic
Sport
Groaza

Uniuni (join)
O uniune (join) este o operaie ntr-o baz de date relaionale care combin
coloane din dou sau mai multe tabele n rezultatele unei singure interogri. O
uniune apare de fiecare dat cnd clauza FROM a unei instruciuni SELECT
specific numele mai multor tabele.
De exemplu:
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM, FILM_GEN
ORDER BY FILM_ID;

FILM_ID
GEN
FILM_TITLU
1
Actiune i Aventura
Mystic River
1
Animatie
Mystic River
1
Clasic
Mystic River
1
Documentar
Mystic River
1
Strain
Mystic River
1
Independent
Mystic River
1
Groaza
Mystic River
1
Sport
Mystic River
1
SF
Mystic River
1
Musical
Mystic River
1
Horror
Mystic River
1
Drama
Mystic River
1
Comedie
Mystic River
1
Copii i Familie
Mystic River
1
Actiune i Aventura
The Last Samurai
2
Thriller
The Last Samurai
2
Sport
The Last Samurai
2
SF
The Last Samurai
2
Romantic
The Last Samurai
2
Musical
The Last Samurai
2
Independent
The Last Samurai
2
Horror
The Last Samurai
2
Animatie
The Last Samurai
2
Copii i Familie
The Last Samurai
2
Documentar
The Last Samurai
2
Strain
The Last Samurai
2
Drama
The Last Samurai
2
Comedie
The Last Samurai
2
Clasic
The Last Samurai
..
...
...............
Setul de rezultate al interogrii a fost trunchiat dup primele dou titluri de
filme. Problema este c am cerut bazei de date s uneasc tabelele, dar nu i-am
spus care este corespondena dintre rndurile celor dou tabele. Rezultatul este
cunoscut sub numele de produs cartezian (dup numele filozofului i
matematicianului francez Rene Descartes) i, n bazele de date relaionale, este un
set de rezultate obinut prin uniunea dintre fiecare rnd al unui tabel cu fiecare rnd
dintr-un alt tabel.

Soluia este s specificm cum se va face unirea tabelelor. Trebuie indicat ce

coloane ar trebui s se potriveasc pentru a uni dou rnduri din cele dou tabele,
n mod normal, cele dou coloane vor fi cheia primar dintr-un tabel i cheia
extern din cellalt tabel, dar pot exist i excepii. Pentru a realiza acest lucru
trebuie s se fac o o uniune standard relaional, cunoscut i sub numele de
uniune de egalitate (equijoin).
Join-ul este operaia de regsire a datelor din dou sau mai multe tabele, pe
baza valorilor comune ale unor coloane. De obicei, aceste coloane reprezint cheia
primar, respectiv cheia extern a tabelelor.
Condiia de join se scrie n clauza WHERE a instruciunii SELECT. ntr-o
instruciune SELECT care unete tabele prin operaia de join, se recomand ca
numele coloanelor s fie precedate de numele tabelelor pentru claritate i
pentru mbuntirea timpului de acces la baza de date. Dac acelai nume de
coloan apare n mai mult de dou tabele, atunci numele coloanei se prefixeaz
obligatoriu cu numele tabelului corespunztor. Pentru a realiza un join ntre n
tabele, va fi nevoie de cel puin n 1 condiii de join.
Equijoin-ul corespunde situaiei n care valorile de pe coloanele ce apar n
condiia de join trebuie s fie egale. Un astfel de join mai poart numele de join
simplu sau inner join. Un nonequijoin este o condiie de join care conine ali
operatori dect operatorul egalitate. Un self join realizeaz compunerea unui tabel
cu el nsui.

Uniuni de egalitate (equijoin)

Avem o uniune de egalitale (equijoin), numit i uniune intern (inner join),
atunci cnd legm una sau mai multe coloane dintr-un tabel (de obicei, o cheie
extern) cu coloane similare dintr-un alt tabel (de obicei, cheia primar), folosind
condiia de egalitale, aceasta fiind cea mai des folosit form de uniune. Totusi,
termenul uniune de egalitate (equijoin) este rareori folosit n afara mediilor
academice, find preferate denurmirile uniune intern (inner join) sau uniune
standard (standard join).
Exist dou modaliti de specificare a coloanelor corespondente: folosind
clauza WHERE sau folosind clauza JOIN. Clauza JOIN a fost adugat relativ
recent n standardul SQL, aa c programatorii mai vechi sunt obisnuii cu metoda
bazat pe clauza WHERE.

Realizarea uniunilor folosind clauza WHERE

Folosirea clauzei WHERE pentru unirea tabelelor seamn cu folosirea
acesteia pentru eliminrea rndurilor de care nu avei nevoie din setul de rezultate.
Totui, exist unele diferene.
n clauza WHERE :
Se compar o coloan cu o alt coloan, nu o coloan cu o constant sau o
expresie.
Atunci cnd coloanele din cele dou tabele au acelai nume (o soluie
recomandat) trebuie s specificati numele complet al coloanelor (adic numele cu
calificator), astfel nct motorul SQL s tie care dintre cele dou coloane este
referit. Motorul SQL cere s se refere toate coloanele specificate ntr-o
instruciune SQL. Aceasta nu nseamn numai coloanele din clauza WHERE, ci
din orice alt loc al instrucunii, inclusiv n lista SELECT. Cea mai simpl form de
calificator este chiar numele tabelului, separat cu caracterul punct de numele
coloanei. n continuare este prezentat un exemplu de uniune realizat prin clauza
WHERE, cu numele coloanelor specificate complet, folosind numele tabelelor.
Observai c interogarea selecteaz coloanele FILM_ID i FILM_TITLU din
tabelul FILM i genul corespunztor (FILM_GEN_DESCRIERE) din tabelul
FILM_GEN.
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM, FILM_GEN
WHERE FILM.FILM_GEN_COD= FILM_GEN.FILM_GEN_COD
ORDER BY FILM_ID;
FILM_ID

FILM_GEN

FILM_TITLU

Drama

Mystic River

Actiune i Aventura

The Last Samurai

Comedie

Something's Gotta Give

Actiune i Aventura

The Italian Job

Actiune i Aventura

Kill Bill Vol. 1

6
7
8
9
10
11
12

Actiune i Aventura
Drama
Actiune i Aventura
Actiune i Aventura
Drama
Romantic
Comedie

Pirates of the Caribbean

Big Fish
Man on Fire
Master and Commander
Lost n Translation
Two Weeks Notice
50 First Dates

13
14
15
16
17
18
19
20

Comedie
Drama
Drama
Comedie
Romantic
Drama
Actiune i Aventura
Strain

Matchstick Men
Cold Mountain
Road to Perdition
The School of Rock
13 Going on 30
Monster
The Day After Tomorrow
Das Boot

Exemplu:
S se obin codurile i titlurile crilor mprumutate.
SELECT carte.codel, titlu
FROM
carte, imprumuta
WHERE
carte.codel = imprumuta.codel;
Folosirea numelor complete ale tabelelor pentru specificarea coloanelor
poate fi obositoare i consumatoare de timp, mai ales deoarece numele tabelelor
pot avea 30 sau mai multe caractere n sistemele DBMS moderne. Din aceast
cauz, n SQL este permis i folosirea pseudonimelor (aliases) pentru numele
tabelelor. Acestea funcioneaz la fel ca i pseudonimele coloanelor din clauza
SELECT, exceptnd faptul c nu este folosit cuvntul cheie AS" (n cele mai
multe implementri SQL) - doar lsai un spaiu ntre numele tabelului i
pseudonim n lista FROM. Dei unii folosesc mnemonice pentru pseudonimul
tabelelor, este mult mai des ntlnit folosirea secvenelor de majuscule (adic A",
B,C i aa mai departe). Dup ce se asociaz un pseudonim unui nume de tabel
n clauza FROM, trebuie s folosii pseudonimul n locul numelui de tabel n
ntreaga instruciune SQL. Folosirea pseudonimelor n clauza SELECT poate prea
puin ciudat la nceput deoarece folosii un pseudonim nainte de a-l defini (clauza
SELECT precede clauza FROM i s-ar putea s par mai simplu s completai
clauza FROM nainte de a completa lista de coloane din clauza SELECT atunci
cnd scriei instruciunile SQL.
Exemplul urmtor prezint instruciunea anterioar, dup adugarea
pseudonimelor pentru numele tabelelor. Dei nu era necesar, pseudonimele au fost
adugate i n lista de coloane din clauzele SELECT i ORDER BY, pentru a va
arta cum sunt folosite.

Exemplu:
SELECT A.FILM_ID, B.FILM_GEN_DESCRIERE AS GEN, A.FILM_TITLU
FROM
FILM A, FILM_GEN B
WHERE A.FILM_GEN_COD = B.FILM_GEN_COD
ORDER BY A.FILM_ID;
Exemplu:
a) S se afieze informaii despre operele de art achiziionate n 2008 i
galeriile n care au fost expuse.
SELECT cod_opera, titlu, o.cod_galerie, nume_galerie, adresa
FROM opera o, galerie g
WHERE o.cod_galerie = g.cod_galerie
AND TO_CHAR(data_achizitiei, 'yyyy') = '2008';
b) S se afieze informaii referitoare la operele de art, artitii care le-au
creat i galeriile n care sunt expuse.
SELECT cod_opera, titlu, data_crearii,
a.cod_artist, nume, prenume,
g.cod_galerie, nume_galerie, adresa
FROM opera o, galerie g, artist a
WHERE o.cod_artist = a.cod_artist
AND
o.cod_galerie = g.cod_galerie;
S-ar putea ca tabelele legate prin operaia de compunere s nu aib coloane
comune (non-equijoin). n acest caz n clauza WHERE nu apare operatorul
egalitate i sunt folosii operatorii: <=, >=, BETWEEN.
Un self join realizeaz compunerea unui tabel cu el nsui.
Exemplu:
S se obin pentru fiecare salariat numele, salariul i grila de salarizare (
join).
SELECT
FROM
WHERE

e.name, e.sal, s.grade

emp e, salgrade s
e.sal BETWEEN s.lasal AND s.hisal;

Exemplu:
S se obin titlurile i preurile crilor mai scumpe dect cartea avnd titlul
Baze de date, al crui autor este POPA (self join).
SELECT
FROM
WHERE
AND
AND

x.titlu, x.pret
carte x, carte y
x.pret > y.pret
y.titlu = Baze de date
y.autor = POPA;

Realizarea uniunilor folosind clauza JOIN

Clauza JOIN este scris ca o referin de tabel din clauza FROM i combin
lista de tabele din clauza FROM i condiia de legtur scris anterior n clauza
WHERE ntr-o singur clauz. Sintaxa general a clauzei JOIN pentru o uniune
intern, urmat de cteva exemple.
Sintaxa corespunztoare standardului SQL3 este urmtoarea:
SELECT tabel_1.nume_coloan, tabel_2.nume_coloan
FROM tabel_1
[CROSS JOIN tabel_2]
| [NATURAL JOIN tabel_2]
| [JOIN tabel_2 USING (nume_coloan) ]
| [JOIN tabel_2 ON (tabel_1.nume_coloan = tabel_2.nume_coloan) ]
| [LEFT | RIGHT | FULL OUTER JOIN tabel_2
ON (tabel_1.nume_coloan = tabel_2.nume_coloan) ];
Clauza ON permite specificarea unei condiii similare cu cea din clauza
WHERE .
Clauza USING specific numele coloanelor folosite pentru legarea
rndurilor. Totui, clauza USING acioneaz numai atunci cnd coloanele pe care
se face legtur au nume identice n ambele tabele. JOIN tabel_2 USING
nume_coloan efectueaz un equijoin pe baza coloanei cu numele specificat n
sintax. Aceast clauz este util dac exist coloane avnd acelai nume, dar
tipuri de date diferite. Coloanele referite n clauza USING trebuie s nu conin
calificatori (s nu fie precedate de nume de tabele sau alias-uri) n nici o apariie a
lor n instruciunea SQL. Clauzele NATURAL JOIN i USING nu pot coexista n
aceeai instruciune SQL.

JOIN tabel_2 ON tabel_1.nume_coloan = tabel_2.nume_coloan

efectueaz un equijoin pe baza condiiei exprimate n clauza ON. Aceast clauz
permite specificarea separat a condiiilor de join, respectiv a celor de cutare sau
filtrare (din clauza WHERE).

Exemple:
JOIN cu condiie ON:
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM JOIN FILM_GEN ON
FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD
ORDER BY FILM_ID;
JOIN cu pseudonime n loc de nume de tabele:
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM A JOIN FILM_GEN B ON
A.FILM_GEN_COD = B.FILM_GEN_COD
ORDER BY FILM_ID;
JOIN folosind cuvntul cheie USING (n locul condiiei ON) o scurtatur
elegant atunci cnd coloanele din cele dou tabele au acelai nume (nu e
recunoscut de toate SGBD-urile).
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM JOIN FILM_GEN USING (FILM_GEN_COD)
ORDER BY FILM_ID;
JOIN cu cheie extern pe mai multe coloane.
Aceast interogare afieaz lista cu copiile filmelor din tabelul FILM_COPY
care nu au fost vndute (coloan DATA_VANZARE conine o valoare nul dac
nu a fost vndut) i care au fost nchiriate (uniune cu tabelul FILM_INCHIRIAT)
dar nu au fost nc returnate (coloan RETUR_DATA conine o valoare nul pn
la returnarea filmului).
SELECT FILM_ID, COPY_NUMAR, DATA_RETURNARII
FROM FILM_COPY JOIN FILM__INCHIRIAT
USING (FILM_ID, COPY_NUMAR)

WHERE DATA_VANZARE IS NULL

AND RETUR_DATA IS NULL;
FILM _ID
2
3
5
5
10
17

COPY_NUMAR
2
2
1
2
1
1

DATA_RETURNARII
02/27/2009
03/04/2009
02/27/2009
02/19/2009
03/04/2009
03/04/2009

Instruciunile care folosesc clauza JOIN sunt mai scurte. Interogarea

precedent scris folosind condiii de legtur n clauza WHERE. Se remarc
faptul c n acest caz trebuie specificat numele complet al coloanelor FILM_ID i
COPY_NUMAR, pentru a evita referirea ambigu a lor. Instruciunea de mai jos
afieaz aceleai rezultate ca i instruciunea anterioar.
SELECT A.FILM_ID, A.COPY_NUMAR, DATA_RETURNARII
FROM FILM_COPY A, FILM_INCH B
WHERE A.FILM_ID = B.FILM_ID
AND A.COPY_NUMAR = B.COPY_NUMAR
AND DATA_VANZARE IS NULL
AND RETURN_DATA IS NULL;
Uniuni naturale
O uniune natural (natural join) se bazeaz pe toate coloanele cu acelai
nume din dou tabele, n esen, toate uniunile de egalitate sunt uniuni naturale.
Totui, sintaxa unei uniuni naturale este mult mai simpl, deoarece nu este necesar
s specificai o condiie sau o list de coloane - se nelege de la sine care sunt
coloanele folosite. Nu toate SGBD-urile accept aceast sintax pentru clauza
JOIN (accepta sigur Oracle i MySQL ).
Exemplu: uniunea tabelelor FILM i FILM_GEN, rescris sub forma unei
uniuni naturale:
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM NATURAL JOIN FILM_GEN
ORDER BY FILM_ID;

Uniunile pot implica mai mult de dou tabele. Exemplul urmtor prezint o
uniune natural care obine coloana FILM_ID din tabelul FILM, coloana
FILM_GEN_DESCRIERE din tabelul FILM_GEN
i din tabelul
MPAA_RATING, coloana MPAA_RATING_DESCRIERE , pentru primele trei
filme din tabelul FILM. Folosirea clauzei WHERE permte s se elimine din setul
de rezultate rndurile de care nu avem nevoie.
Exemplul folosete dou clauze JOIN. Prima clauz JOIN cere motorului
SQL s lege tabelele FILM i FILM_GEN, iar a dou clauz JOIN i cere s lege
rndurile deja unite (n esen, un set de rezultate intermediar) cu tabelul
MPAA_RATING.
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN,
MPAA_RATING_COD AS RATING, MPAA_RATING_DESCRIERE AS
RATING_DESC
FROM FILM NATURAL JOIN FILM_GEN NATURAL JOIN
MPAA_RATING
WHERE
FILM_ID < 4 ORDER BY FILM_ID;

FILM_ID

RATING

RATING_DESC

Sub 17 ani acompaniati de parinti

Aciune si Aventura R

Sub 17 ani acompaniati de parinti

Comedie

Cu acordul strict a parintilor

GEN

Drama

PG-13

Dac se folosete o implementare SQL care nu accept uniunile naturale,

aceeai interogare scris folosind cuvintele cheie JOIN i ON este:
SELECT A.FILM_ID, B.FILM_GEN_DESCRIERE AS GEN,
C.MPAA_RATING__COD AS RATING,
C.MPAA_RATING__DESCRIERE AS
RATING_DESC
FROM FILM A JOIN FILM_GEN B ON
A.FILM_GEN_COD = B.FILM_GEN_COD
JOIN MPAA_RATING C ON
A.MPAA_RATING_COD = C.MPAA_RATING_COD
WHERE FILM_ID < 4 ORDER BY FILM_ID;

Exemple la schema galerii de arta

a) S se determine titlul operelor de art expuse n galeriile avnd codul 10
sau 30, respectiv numele i prenumele artitilor care le-au realizat.
SELECT
FROM
WHERE

titlu, nume, prenume

opera NATURAL JOIN artist
cod_galerie IN (10, 30);

Folosind clauza USING, acest exemplu poate fi rescris astfel:

SELECT titlu, nume, prenume
FROM opera JOIN artist USING (cod_artist)
WHERE cod_galerie IN (10, 30);
Urmtoarea cerere va returna eroarea ORA-25154: column part of USING
clause cannot have qualifier, ntruct coloana specificat n clauza USING apare,
n clauza WHERE, precedat de un alias de tabel.
SELECT o.titlu, a.nume, a.prenume
FROM opera o
JOIN artist a USING (cod_artist)
WHERE a.cod_artist IN (50,60);
b) S se afieze titlurile operelor de art, firmele la care sunt asigurate i
descrierea polielor de asigurare corespunztoare.
SELECT o.titlu, p.firma, p.descriere
FROM opera o JOIN polita_asig p ON
(o.cod_opera = p.cod_opera);

Uniuni externe (outer joins)

Toate uniunile pe care le-am descris pn acum sunt uniuni exclusiv (uniuni
interne), ceea ce nseamn c singurele rnduri care apar n setul de rezultate sunt
cele pentru care a fost gsit o legtur n toate tabelele unite.
Exist situaii n care se dorete s includei n rezultatele interogrii i
rnduri pentru care nu exist o legtur. De exemplu, dac se dorete o list cu
toate genurile de filme, mpreun cu toate titlurile asociate cu fiecare gen?

O uniune extern (outer join) - pentru care un nume mai potrivit ar fi uniune
inclusiv - include n setul de rezultate i rndurile pentru care nu exist legturi
din cel puin unul dintre tabele. Atunci cnd exist rnduri fr legturi, datele
selectate din tabelul n care nu a fost gsit o legtur primesc valoarea nul.
Un outer join este utilizat pentru a obine n rezultat i nregistrrile care nu
satisfac condiia de join. Operatorul pentru outer join este semnul plus inclus ntre
paranteze (+), care se plaseaz n acea parte a condiiei de join care este deficient
n informaie. Efectul acestui operator este de a uni liniile tabelului care nu este
deficient n informaie i crora nu le corespunde nici o linie n cellalt tabel cu o
linie cu valori null. Operatorul (+) poate fi plasat n orice parte a condiiei de join,
dar nu n ambele pri.
O condiie care presupune un outer join nu poate utiliza operatorul IN i nu
poate fi legat de alt condiie prin operatorul OR.
Exemplu:
Se presupune c tabelul artist conine i artiti care nu au opere expuse n
muzeu. S se afieze artitii i operele acestora, inclusiv cei care nu au opere
corespunztoare n tabelul opera.
SELECT a.cod_artist, nume, prenume, cod_opera, titlu
FROM artist a, opera o
WHERE a.cod_artist = o.cod_artist (+);
Exist trei tipuri de baz:
Uniune extern ctre stnga (left outer join). Returneaz toate rndurile
din tabelul din stnga (cel specificat primul n clauza JOIN), mpreun cu toate
rndurile din tabelul din dreapta pentru care poate fi gsit o legtur.
(asemnatoare interogrilor din tabele aflate in relaia 1:m)
Uniune extern ctre dreapta (right outer join). Returneaz toate rndurile
din tabelul din dreapta (cel specificat al doilea n clauza JOIN), mpreun cu toate
rndurile din tabelul din stnga pentru care poate fi gsit o legtur, n esen, o
uniune extern ctre stnga poale fi rescris ca o uniune extern ctre dreapta
inversnd ordinea de specificare a tabelelor i nlocuind cuvntul cheie LEFT cu
RIGHT.
Uniune extern complet (full outer join). Returneaz toate rndurile din
ambele tabele. Acest tip de uniune este cel mai puin probabil s fie acceptat de
toate implementari;e SQL. Aceast uniune nu este acelai lucru cu un produs
cartezian, care leag fiecare rnd dintr-un tabel cu fiecare rnd din cellalt tabel. O
uniune extern complet leag fiecare rnd dintr-un tabel cu zero sau mai multe
rnduri corespondente din cellalt tabel.

Este folosit mai mult pentru tabelele aflate in relaia m:m

Sintaxa general pentru o uniune extern este:
nume_tabel {RIGHT | LEFT | FULL} [OUTER] JOIN nume_tabel {
ON condiie | USING (nume_coloan [ ,nume_coIoan. ..]) }
Exemple de uniuni externe:

S se afieze toate descrierile genurilor de filme, mpreun cu filmele

asociate fiecrui gen. n setul de rezultate rndurile care nu au nici o valoare n
coloan FILM_TITLU - acestea sunt genurile de filme care nu au filme asociate.
Dac implementarea DBMS nu accept uniuni realizate cu cuvntul cheie USING,
modificai instruciunea astfel nct s utilizeze cuvntul cheie ON, ca n exemplul
care urmeaz dup acesta.
SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM_GEN LEFT OUTER JOIN FILM
(FILM_GEN_COD);
GEN

FILM_TITLU

Actiune i Aventura
Actiune i Aventura
Actiune i Aventura

Kill Bill: Vol. 1

Man on Fire
Pirates of the
Caribbean
Master and
Commander
The Day After
Tomorrow
The Last Samurai
The Italian Job

Actiune i Aventura
Actiune i Aventura

Actiune i Aventura
Actiune i Aventura
Anime
and
Animation
Copii i Familie
Clasic
Comedie
50 First Dates
Comedie
Matchstick Men
Comedie
The School of Rock

USING

Comedie
Documentar
Drama
Drama
Drama
Drama
Drama
Drama
Strain
Horror
Independent
Musical
Romantic
Romantic

Something's Gotta
Give
Big Fiah
Road to Perdition
Mystic River
Monster
Cold Mountain
Lost n Translation
Das Boot

13 Going on 30
Two Weeks Notice

Interogarea anterioar, rescris ca uniune extern ctre dreapta,

cu condiie ON.

SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU

FROM FILM RIGHT OUTER JOIN FILM_GEN
ON FILM.FILM_GEN_COD =FILM_GEN.FILM_GEN_COD;

Interogarea anterioar, rescris ca uniune extern complet. Deoarece

fiecare film trebuie s aib asociat un gen, aceast interogare va produce aceleai
rezultate ca i uniunea extern ctre dreapta din interogarea anterioar. Totui, dac
genurile filmelor ar fi opionale, uniunea extern complet v-ar fi permis s afiai
att genurile care nu au filme asociate, ct i filmele care nu au genuri asociate.
SELECT FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM FULL OUTER JOIN FILM_GEN
ON FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD;
Afiai descrierile genurilor care nu au nume asociate. Exist i alte
moduri de a face acest lucru, dar exemplul de fa folosete faptul c rndurile
pentru care nu exist legturi returneaz valori nule pentru a selecta numai genurile
care nu au nume asociate.

SELECT FILM_GEN_DESCRIERE AS GEN

FROM FILM RIGHT OUTER JOIN FILM_GEN
ON FILM.FILM_GEN_COD = FILM_GEN.FILM_GEN_COD
WHERE FILM_TITLU IS NULL;
GEN
Animatie
Copii i Familie
Clasic
Documentar
Horror
Independent
Musical
SF
Special Interes
Sport
Thriller
Ca rspuns la cererile clienilor, mai muli productori de baze de date
relaionale au introdus uniunile externe inainte de standardizarea clauzei JOIN.
Seciunile urmtoare prezint cteva implementri specifice ale sintaxei uniunii
externe. Aceste soluii particulare sunt prezentate aici numai pentru c s-ar putea s
le intlnii n instruciuni SQL mai vechi
Exemplu:
a) S se afieze titlurile operelor de art i firmele la care acestea sunt
asigurate. Se vor lua n considerare i operele de art pentru care nu au fost
ncheiate polie de asigurare.
SELECT
titlu, firma
FROM
opera o
LEFT OUTER JOIN polita_asig p ON (o.cod_opera = p.cod_opera);
b) S se afieze artitii (nume, prenume) i operele acestora, inclusiv cei
care nu au opere expuse n cadrul muzeului.
SELECT
nume, prenume, titlu
FROM
opera o
RIGHT OUTER JOIN artist a ON (o.cod_artist = a.cod_artist);

c) S se afieze numele i prenumele artitilor, precum i titlurile operelor

create de acetia. Se vor afia i artitii care nu au opere expuse n cadrul muzeului,
precum i titlurile operelor al cror autor este necunoscut.
SELECT
nume, prenume, titlu
FROM
opera o
FULL OUTER JOIN artist a ON (o.cod_artist = a.cod_artist);
Specificarea condiiilor suplimentare ale unei interogri poate fi fcut att
n clauza WHERE, ct i n clauza ON. Urmtoarea instruciune este corect i are
acelai efect dac n locul operatorului AND ar aprea clauza WHERE.
SELECT o.titlu, p.firma, p.descriere
FROM opera o
JOIN polita_asig p ON (o.cod_opera = p.cod_opera)
AND
o.cod_opera = 180;
S se obin titlurile crilor i numele domeniului cruia i aparin,
remarcnd si situaiile n care domeniul nu ar avea cri (dac domeniul este
fr cri atunci apare null la titlul crii).
SELECT titlu, intdom
FROM
carte, domeniu
WHERE carte.coded(+) = domeniu.coded;
Exemplu:
Considerm c tabelele dept i emp au urmtorul coninut:
dept
emp
deptno dname
empno
deptno
1
algebra
101
null
2
analiza
102
null
103
null
105
1
106
1
Interogarea urmtoare furnizeaz lista tuturor salariailor si informatii
despre departamentele in care lucreaza, inclusiv a celor care nu sunt asignai
nici unui departament (right outher join).
SELECT a.deptno, a.dname, b.empno, b.deptno
FROM
dept a, emp b

WHERE a.deptno(+) = b.deptno;

Rezultatul cererii anterioare va fi:
a.deptno a.dname
b.empno
b.deptno
101
102
103
1
algebra
105
1
1
algebra
106
1
Interogarea urmtoare afieaz lista departamentelor, inclusiv a celor
care nu au salariai (left outer join).
SELECT a deptno, a.dname, b.empno, b.deptno
FROM
dept a, emp b
WHERE a.deptno = b.deptno(+);
Rezultatul cererii anterioare va fi:
a.deptno a.dname
b.empno
b.deptno
1
algebra
105
1
1
algebra
106
1
2
analiza
null
null
Interogarea urmtoare produce ca rezultat departamentele, chiar i cele
fr funcionari, i funcionarii, chiar i cei care nu sunt asignai nici unui
departament (full outer join).
SELECT NVL(TO_CHAR(b.empno),***) id,
NVL(a.dname,***) nume_dep
FROM
dept a, emp b
WHERE a.deptno = b.deptno(+)
UNION
SELECT NVL(TO_CHAR(b.empno),***) id,
NVL(a.dname,***) nume_dep
FROM
dept a, emp b
WHERE a.deptno(+) = b.deptno;
Rezultatul cererii va fi:
id
nume_dep
***
analiza
101
***
102
***
103
***
105
algebra
106
algebra

c) S se afieze numele i prenumele artitilor, precum i titlurile operelor

create de acetia. Se vor afia i artitii care nu au opere expuse n cadrul muzeului,
precum i titlurile operelor al cror autor este necunoscut.
SELECT
nume, prenume, titlu
FROM
opera o
FULL OUTER JOIN artist a ON (o.cod_artist = a.cod_artist);
Specificarea condiiilor suplimentare ale unei interogri poate fi fcut att
n clauza WHERE, ct i n clauza ON. Urmtoarea instruciune este corect i are
acelai efect dac n locul operatorului AND ar aprea clauza WHERE.
SELECT o.titlu, p.firma, p.descriere
FROM opera o
JOIN polita_asig p ON (o.cod_opera = p.cod_opera)
AND
o.cod_opera = 180;
Uniuni ncruciate (cross joins)
O uniune ncruciat (cross join) nu este altceva dect sintaxa standard
pentru un produs cartezian. Interogarea care unea tabelele FILM i FILM_GEN i
obinea un produs cartezian
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM, FILM_GEN
ORDER BY FILM_ID;
poate fi rescris ca mai jos, folosind o uniune ncruciat:
SELECT FILM_ID, FILM_GEN_DESCRIERE AS GEN, FILM_TITLU
FROM FILM CROSS JOIN FILM_GEN
ORDER BY FILM_ID;

Subinterogri
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile
(numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune
SELECT care contine o instruciune SELECT subordonat. De obicei,
subinterogrile sunt folosite n clauza WHERE, ca modalitate de limitare a
rndurilor returnate n setul de rezultate al interogrii externe. Aceasta poate fi o
modalitate foarte flexibil de selectare a datelor.

O regul esenial de sintax este ca subinterogarea s fie ncadrat de

paranteze.
Orice operaie efectuat cu o subinterogare poate fi facut i printr-o uniune.
Subinterogri necorelate
O subinterogare necorelat (noncorrelated subselect) este o subinterogare n
care interogarea intern nu face nici o referire la interogarea extern care o conine.
Aceasta nseamn c poate fi rulat mai inti interogarea intern, apoi setul de
rezultate obinut poate fi folosit n interogarea extern.
Exemple:
Afiai toate limbile n care nu exist nici un film n inventarul magazinului
de produse video.
SELECT LIMBA_COD, LIMBA_NUME
FROM LIMBA
WHERE LIMBA_COD NOT IN
(SELECT DISTINCT LIMBA_COD
FROM FILM_LIMBA)
ORDER BY LIMBA_COD
LIMBA_COD
Ja
Ko
ni
ru
zh

LIMBA_NUME
Japoneza
Coreana
Olandeza
Rusa
Chineza

Interogarea intern returneaz o list cu codurile de limb asociate

filmelor n tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile
duplicate din setul de rezultate .
Interogarea intern rulat independent, pentru a v ajuta s nelegei
cum funcioneaz:
SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA;
LIMBA_COD
------------------------------------------de
(Germana)
en
(Engleza)
es
(Spaniola)

fr

(Franceza)

Proprietarul magazinului vrea s vad efectul recentei creteri de preuri

i are nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit
mai mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat
interogarea:
SELECT DISTINCT TRANZACTIE_ID
FROM FILM_INCHIRIAT
WHERE INCHIRIAT_TAXA>
(SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT)
Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea
extern gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care
valoarea INCHIRIAT_TAXA depete media.
Cuvntul cheie DISTINCT elimin tranzaciile duplicate.
Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului
dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i
adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern.
Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru
folosind nc o subinterogare. Iat cum arat interogarea:
SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA
FROM CLIENT_TRANZACTIE
WHERE TRANZACTIE_ID IN
(SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH,
WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA)
FROM FILM_INCHIRIAT)
TRANZACTIE_ID TRANZ_DATA
9
03/01/2005
10
03/01/2005
Subinterogri corelate
O subinterogare corelat (correlated subselect) este o subinterogare n care
interogarea intern refer valorile furnizate de interogarea extern. Aceste
subinterogari sunt mult mai puin eficiente dect subinterogrile necorelate,

deoarece interogarea intern trebuie s fie apelat pentru fiecare rnd gsit de
interogarea extern.
Exemplu:
Proprietarul magazinului vrea s transmit prin pot un cupon valoric
tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de
nchiriere.
SELECT DISTINCT CLIENT_CONT_ID
FROM CLIENT_TRANZACTIE A
WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA)
FROM FILM_INCHIRIATB
WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID)
CLIENT_CONT_ID
2
7
9
Observai pseudonimele asociate numelor de tabele din interogrile
intern i extern, precurn i folosirea acestora n clauza WHERE a interogrii
interne. Acesta este elementul de identificare al unei subinterogri corelate.
Interogarea extern selecteaz o lista de valori CLIENT_CONT_ID distincte din
tabelul CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii
interne, care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia
respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci
clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul
CLIENT_ID este adugat n setul de rezultate.
Vizualizri n linie
Foarte puine implementri, printre care Oracle, permit folosirea unei
subinterogri n clauza FROM a unei interogri, ntr-o construcie numit
vizualizare n linie (inline view). Aceast construcie permite care setul de rezultate
al unei interogri s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit.
Iat un exemplu:
Aceast interogare afl numrul maxim de nchirieri ale unui singur film;
SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR
FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR
FROM FILM_INCHIRIAT GROUP BY FILM_ID)

MAX_INCH_NUMAR
5
Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare
FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR
din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist
nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar
s le unii cu alte tabele sau vizualizri.

Subinterogri (Subcereri)
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile
(numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune
SELECT care conine o instruciune SELECT subordonat.
De cele mai multe ori, pentru a implementa anumite interogri, nu este
suficient o singur cerere SELECT ci sunt necesare subcereri.
Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele ,
SELECT, WHERE, HAVING, FROM, numit instruciune printe.
Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine
unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt
specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul
dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor
care ntorc o singur linie (single-row subquery).
Utiliznd subcereri, se pot construi interogri complexe pe baza unor
instruciuni simple. Subcererile mai sunt numite instruciuni SELECT imbricate
sau interioare.

Subcererea returneaz o valoare care este utilizat de ctre instruciunea

printe. Utilizarea unei subcereri este echivalent cu efectuarea a dou cereri
secveniale i utilizarea rezultatului cererii interne ca valoare de cutare n cererea
extern (principal).
Subcererile pot fi utilizate n urmtoarele situaii:
pentru a furniza valori care intervin n condiiile din clauzele WHERE,
HAVING i START WITH ale instruciunilor SELECT;
pentru a defini o mulime de linii care urmeaz s fie inserat n tabelul
destinaie al unei instruciuni INSERT sau CREATE TABLE;
pentru a defini o mulime de linii care urmeaz s fie inserate ntr-o
vizualizare sau vizualizare materializat, prin intermediul unei
instruciuni CREATE VIEW sau CREATE MATERIALIZED VIEW;
pentru a defini una sau mai multe valori care urmeaz s fie atribuite unor
linii existente ntr-o instruciune UPDATE;
pentru a defini un tabel asupra cruia va opera cererea extern (plasarea
subcererii n clauza FROM sau n instruciunile INSERT, UPDATE,
DELETE).

Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt

a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY.
De obicei, subinterogrile sunt folosite n clauza WHERE, ca modalitate de
limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta
poate fi o modalitate foarte flexibil de selectare a datelor.
O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze.
Orice operaie efectuat cu o subinterogare poate fi fcut i printr-o uniune.
Exemplu:
S se obin numele i salariul angajailor, avnd salariul minim.
SELECT
FROM
WHERE

name, sal
angajati
sal=(SELECT
FROM

MIN(sal)
angajati);

Exemplu:
S se obin job-ul pentru care salariul mediu este minim. Sa se afiseze si
salariul mediu.
SELECT
job, AVG(sal)
FROM
angajati
GROUP BY job
HAVING AVG(sal)=(SELECT MIN(AVG(sal))
FROM
angajati
GROUP BY
job);
Operatorul ANY presupune c este adevrat condiia dac comparaia este
adevrat pentru cel puin una din valorile returnate. Sunt evidente relaiile:
< ANY mai mic ca maximul;
> ANY mai mare ca minimul;
= ANY IN.
Pentru operatorul ALL se presupune c este adevrat condiia, dac
comparaia este adevrat pentru toate elementele listei returnate. Pentru operatorul
ALL sunt evidente relaiile:
< ALL mai mic ca minimul;
> ALL mai mare ca maximul;
! = ALL NOT IN.

Exemplu:
WHERE codec > ALL (C1, C2) este superior tuturor elementelor din list;
WHERE codec > ANY (C1, C2) este superior cel puin unui element din
list.
Exemplu:
S se obin salariaii al cror salariu este mai mare ca salariile medii din
toate departamentele.
SELECT
FROM
WHERE

nume, job
angajati
sal > ALL(SELECT
FROM
GROUP BY

AVG(sal)
angajati
cod_dep);

Exist subcereri care au ca rezultat mai multe coloane (multiple-column

subquery). Aceste interogri au urmtoarea sintax general:
SELECT
FROM
WHERE

col,col,
tabel
(col,col,) IN (SELECT
col,col,
FROM
tabel
WHERE
condiie);

Dac una din valorile returnate de subcerere este valoarea null atunci cererea
nu ntoarce nici o linie. Prin urmare, dac valoarea null poate s fac parte din
rezultatul subcererii nu trebuie utilizat operatorul NOT IN. Problema nu mai apare
dac se utilizeaz operatorul IN.

Exemplu:
S se obin salariaii care nu au subordonai.
SELECT
FROM
WHERE

a.nume
angajati a
a.cod_ang NOT IN (SELECT m.mgr
FROM angajati m);

n acest caz, instruciunea SQL nu ntoarce nici o linie deoarece una din
valorile furnizate de subcerere este valoarea null.

Subinterogri necorelate (nesincronizate)

O subinterogare necorelat (noncorrelated subselect) este o subinterogare n
care interogarea intern nu face nici o referire la interogarea extern care o conine.
Subcererile necorelate returneaz o valoare care este utilizat de cererea
extern (cererea principal). Cererile care conin subcereri necorelate sunt evaluate
n modul urmtor:
cererea intern este executat prima i determin o valoare (sau o
mulime de valori);
cererea extern se execut o singur dat, utiliznd valorile returnate de
cererea intern.
n general, o cerere imbricat, necorelat are urmtoarea form:
SELECT
FROM
WHERE

lista_select
nume_tabel
expresie operator (SELECT lista_select
FROM
nume_tabel);

n aceast sintax, identificatorul operator poate fi de tip:

single-row operator (>, =, >=, <, <>, <=), care poate fi utilizat dac
subcererea returneaz o singur linie;
multiple-row operator (IN, ANY, ALL), care poate fi folosit dac
subcererea returneaz mai mult de o linie.
Operatorul ANY, care este sinonim cu operatorul SOME, determin
compararea unei valori cu fiecare valoare returnat de o subcerere. Astfel, <ANY
are semnificaia mai mic dect maximul; >ANY nseamn mai mare dect
minimul; =ANY este echivalent cu operatorul IN. Operatorul ALL compar o
valoare cu toate valorile returnate de o subcerere. Astfel, <ALL are semnificaia
mai mic dect minimul, iar >ALL este echivalent cu mai mare dect maximul.
Operatorul NOT poate fi utilizat n combinaie cu IN, ANY i ALL.
n utilizarea unei subcereri se impun anumite reguli.
Subcererea trebuie inclus ntre paranteze.
Pentru claritate, subcererea se plaseaz n partea dreapt a operatorului de
comparaie.
nainte de versiunea Oracle8i, subcererile nu puteau s conin clauza
ORDER BY. ncepnd cu Oracle8i, clauza ORDER BY poate fi utilizat i
este chiar obligatorie n subcerere pentru a efectua analiza top-n (cererea
care efectueaz analiza top-n returneaz cele mai mari sau cele mai mici
n valori ale unei coloane).
Operatorul folosit trebuie s fie conform cu tipul cererii. Cererea va

genera o eroare dac este utilizat un operator single-row n faa unei

subcereri care returneaz mai mult de o linie. De asemenea, dac
subcererea nu returneaz nici o linie, apare o eroare.
Server-ul Oracle nu impune nici o limit asupra numrului de subcereri.
Limita acestora depinde de dimensiunea buffer-ului pe care l utilizeaz cererea.
Exemple:
Afiai toate limbile n care nu exist nici un film n inventarul magazinului de
produse video.
SELECT LIMBA_COD, LIMBA_NUME
FROM LIMBA
WHERE LIMBA_COD NOT IN
(SELECT DISTINCT LIMBA_COD
FROM FILM_LIMBA)
ORDER BY LIMBA_COD
LIMBA_COD
Ja
Ko
ni
ru
zh

LIMBA_NUME
Japoneza
Coreana
Olandeza
Rusa
Chineza

Interogarea intern returneaz o list cu codurile de limb asociate filmelor n

tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile duplicate din
setul de rezultate .
Interogarea intern rulat independent, pentru a v ajuta s nelegei cum
funcioneaz:
SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA;
LIMBA_COD
------------------------------------------de
(Germana)
en
(Engleza)
es
(Spaniola)
fr
(Franceza)

 Proprietarul magazinului vrea s vad efectul recentei creteri de preuri i are

nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit mai
mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat
interogarea:
SELECT DISTINCT TRANZACTIE_ID
FROM FILM_INCHIRIAT
WHERE INCHIRIAT_TAXA>
(SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT)
Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea extern
gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care valoarea
INCHIRIAT_TAXA depete media.
Cuvntul cheie DISTINCT elimin tranzaciile duplicate.
Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului
dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i
adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern.
Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru
folosind nc o subinterogare. Iat cum arat interogarea:
SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA
FROM CLIENT_TRANZACTIE
WHERE TRANZACTIE_ID IN
(SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH,
WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA)
FROM FILM_INCHIRIAT)
TRANZACTIE_ID TRANZ_DATA
9
03/01/2005
10
03/01/2005
Exemplu(din galeria de arta):
a) S se afieze titlul, codul artistului i valoarea operelor create de artistul
cruia i aparine opera avnd codul 180 i care se afl expuse n aceeai galerie cu
operele al cror cod este 100 sau 110. Se presupune c o oper are un singur autor.
SELECT titlu, cod_artist, valoare
FROM opera
WHERE cod_artist = (SELECT cod_artist

AND

FROM opera
WHERE cod_opera = 180)
cod_galerie IN (SELECT cod_galerie
FROM opera
WHERE cod_opera IN (100, 110));

b) S se determine artistul pentru care valoare medie a operelor sale de art

este minim.
SELECT cod_artist, AVG(valoare)
FROM opera
GROUP BY cod_artist
HAVING AVG(valoare) = (SELECT MIN(AVG(valoare))
FROM opera
GROUP BY cod_artist);
c) Pentru fiecare artist, s se afieze titlul i valoarea celei mai ieftine opere
de art expuse n muzeu.
SELECT titlu, cod_artist, valoare
FROM opera
WHERE valoare IN (SELECT MIN(valoare)
FROM opera
GROUP BY cod_artist);
d) S se afieze operele de art care nu sunt expuse n galeria avnd codul
30 i a cror valoare este mai mic dect a unei opere din galeria 30.
SELECT cod_opera, titlu, valoare
FROM opera
WHERE valoare < ANY (SELECT valoare
FROM opera
WHERE cod_galerie = 30)
AND
cod_galerie <> 30;
Dac operatorul ANY se nlocuiete cu operatorul ALL, cererea precedent
returneaz operele care nu sunt expuse n galeria 30 i a cror valoare este mai
mic dect a oricrei opere din galeria respectiv.
e) S se afieze cele mai scumpe 3 opere de art din muzeu.
SELECT ROWNUM "Nr.Crt", titlu, valoare
FROM (SELECT titlu, valoare
FROM
opera
ORDER BY valoare DESC)

WHERE ROWNUM <= 3;

Exemplu:
Din punct de vedere logic, urmtoarea cerere ar trebui s returneze titlurile
operelor care nu sunt expuse n galeriile unde se afl lucrrile artistului avnd
codul 60.
SELECT titlu
FROM opera
WHERE cod_galerie NOT IN (SELECT cod_galerie
FROM opera
WHERE cod_artist = 60);
Dac pentru una dintre opere valoarea coloanei cod_galerie este null,
ntreaga cerere nu va returna nici o linie, chiar dac exist nregistrri cu
proprietatea cerut. Justificarea este c toate condiiile n care unul dintre operanzi
este null au, de asemenea, valoarea null. Prin urmare, ori de cte ori este posibil ca
n rezultatul subcererii s apar valori null, nu trebuie folosit operatorul NOT IN.
Operatorul NOT IN este echivalent cu <>ALL. Dac se utilizeaz operatorul IN, nu
mai este nici o problem dac n rezultatul subcererii apar valori null. Operatorul
IN este echivalent cu =ANY.
Exemplu:
S se afieze titlurile operelor care sunt expuse n galeriile unde se afl
lucrrile artistului avnd codul 60.
SELECT titlu
FROM opera
WHERE cod_galerie IN (SELECT cod_galerie
FROM opera
WHERE cod_artist = 60);
Pentru a evita obinerea de valori null n rezultatul unei cereri care utilizeaz
operatorul NOT IN, se poate specifica o condiie n subcerere:
SELECT titlu
FROM opera
WHERE cod_galerie NOT IN (SELECT cod_galerie
FROM opera
WHERE cod_artist = 60
AND
cod_galerie IS NOT NULL);

Subcereri (Subinterogri) corelate (incuibarite sau sincronizate)

O subinterogare corelat (correlated subselect) este o subinterogare n care
interogarea intern refer valorile furnizate de interogarea extern.
Subcererile corelate sunt utilizate pentru procesarea linie cu linie a
interogrilor. O subcerere este corelat dac face referin la o coloan dintr-un
tabel specificat n instruciunea printe. O astfel de subcerere este evaluat o dat
pentru fiecare linie procesat de instruciunea printe, care poate fi SELECT,
UPDATE sau DELETE.
Subcererile corelate permit compararea valorilor unei linii cu date
determinate pe baza acestor valori.
Cererile corelate se execut astfel:
cererea extern determin o linie candidat;
cererea intern este executat utiliznd valoarea liniei candidat;
valorile rezultate din cererea intern sunt utilizate pentru calificarea sau
descalificarea liniei candidat;
paii precedeni se repet pn cnd nu mai exist linii candidat.
Forma general a unei subcereri corelate este urmtoarea:
SELECT nume_coloan_1[, nume_coloan_2 ]
FROM nume_tabel_1 extern
WHERE expresie operator
(SELECT nume_coloan_1 [, nume_coloan_2 ]
FROM
nume_tabel_2
WHERE expresie_1 = extern.expresie_2);

Exemplu:
Proprietarul magazinului vrea s transmit prin pot un cupon valoric
tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de
nchiriere.
SELECT DISTINCT CLIENT_CONT_ID
FROM CLIENT_TRANZACTIE A
WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA)
FROM FILM_INCHIRIATB
WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID)
CLIENT_CONT_ID

2
7
9
Observai pseudonimele asociate numelor de tabele din interogrile intern
i extern, precurn i folosirea acestora n clauza WHERE a interogrii interne.
Acesta este elementul de identificare al unei subinterogri corelate. Interogarea
extern selecteaz o lista de valori CLIENT_CONT_ID distincte din tabelul
CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii interne,
care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia
respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci
clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul
CLIENT_ID este adugat n setul de rezultate.
Vizualizri n linie
Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri
n clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie
(inline view). Aceast construcie permite care setul de rezultate al unei interogri
s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit. Iat un exemplu:
Aceast interogare afl numrul maxim de nchirieri ale unui singur film;
SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR
FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR
FROM FILM_INCHIRIAT GROUP BY FILM_ID)
MAX_INCH_NUMAR
5
Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare
FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR
din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist
nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar
s le unii cu alte tabele sau vizualizri.
Exemplu de subcereri corelate pentru galeria de arta):
a) S se afieze informaii despre operele de art a cror valoare depete
valoarea medie a celor expuse n aceeai galerie.

SELECT titlu, valoare, cod_galerie

FROM opera o
WHERE valoare > (SELECT AVG(valoare)
FROM opera
WHERE cod_galerie = o.cod_galerie);
b) S se afieze codul, numele i prenumele artitilor care au cel puin dou
opere de art expuse n muzeu.
SELECT cod_artist, nume, prenume
FROM artist a
WHERE 2 <= (SELECT COUNT(*)
FROM opera
WHERE cod_artist = a.cod_artist);
Server-ul Oracle evalueaz subcererea corelat precedent urmnd
succesiunea de pai prezentat n continuare.
1) Selecteaz o linie din tabelul specificat n cererea extern (aceasta va fi
linia candidat curent).
2) Reine valoarea coloanei referite n subcerere din aceast linie candidat
(n cazul subcererii de mai sus, coloana referit n subcerere este
a.cod_artist).
3) Efectueaz subcererea, considernd condiia acesteia ca facnd referin
la valoarea liniei candidat din cererea extern (n exemplul precedent,
funcia COUNT(*) este evaluat pe baza valorii lui a.cod_artist
determinat la pasul 2).
4) Evalueaz clauza WHERE a cererii externe pe baza rezultatelor returnate
de cererea intern la pasul 3. Adic, se determin dac linia candidat este
selectat n rezultatul cererii (n exemplul precedent, numrul de opere
ale unui artist, evaluat de subcerere, este comparat cu 2 n clauza WHERE
a cererii externe, iar dac aceast condiie este satisfcut, linia
corespunztoare artistului respectiv va face parte din rezultat).
5) Procedura se repet pentru urmtoarele linii candidat din tabel, pn cnd
sunt procesate toate liniile tabelului.
Operatorul EXISTS
n instruciunile SELECT imbricate, este permis utilizarea oricrui operator
logic. Pentru a testa dac valoarea recuperat de cererea extern exist n mulimea
valorilor regsite de cererea intern corelat, se poate utiliza operatorul EXISTS.
Dac subcererea returneaz cel puin o linie, operatorul returneaz valoarea TRUE.
n caz contrar, va fi returnat valoarea FALSE.

Operatorul EXISTS asigur c nu mai este continuat cutarea n cererea

intern dup ce aceasta regsete o linie.
Exemplu:
a) S se determine codul, numele i prenumele artitilor care au cel puin o
oper de art expus n muzeu.
SELECT cod_artist, nume, prenume
FROM artist a
WHERE EXISTS (SELECT 'x'
FROM opera
WHERE cod_artist = a.cod_artist);
ntruct nu este necesar ca instruciunea SELECT interioar s returneze o
anumit valoare, se poate selecta o constant. De altfel, din punct de vedere al
performanei, selectarea unei constante asigur mai mult rapiditate dect
selectarea unei coloane.
Ca alternativ a lui EXISTS, poate fi utilizat operatorul IN. Exemplul
precedent poate fi rezolvat prin instruciunea urmtoare:
SELECT cod_artist, nume, prenume
FROM artist
WHERE cod_artist IN (SELECT cod_artist
FROM opera);
b) S se determine operele care nu sunt menionate n nici o surs
bibliografic.
SELECT cod_opera, titlu
FROM opera o
WHERE NOT EXISTS (SELECT 'x'
FROM mentionata_in
WHERE cod_opera = o.cod_opera);
Acest exemplu poate fi rezolvat i printr-o subcerere necorelat, utiliznd
operatorul NOT IN:
SELECT cod_opera, titlu
FROM opera
WHERE cod_opera NOT IN (SELECT cod_opera
FROM ment_in
WHERE cod_opera IS NOT NULL);

Clauza WITH
Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta
s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere
ntr-o instruciune SELECT complex. Acest lucru este util atunci cnd o cerere
face referin de mai multe ori la acelai bloc de cerere, care conine operaii join i
funcii agregat. Folosind clauza WITH, server-ul Oracle regsete rezultatele unui
bloc de cerere i le stocheaz n spaiul tabel temporar al utilizatorului, ceea ce
poate determina mbuntirea performanelor.
Exemplu:
Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i
valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a
operelor este mai mare dect media valorilor totale ale operelor tuturor artitilor.
WITH
val_artist AS (SELECT nume, SUM(valoare) AS total
FROM opera o, artist a
WHERE o.cod_artist = a.cod_artist
GROUP BY nume),
val_medie AS (SELECT SUM(total)/COUNT(*) AS medie
FROM val_artist)
SELECT *
FROM val_artist
WHERE total > (SELECT medie
FROM val_medie)
ORDER BY nume;
Intern, clauza WITH este tratat ca o vizualizare inline (subcerere n clauza
FROM) sau ca un tabel temporar. Optimizorul alege decizia adecvat pe baza
costului sau beneficiului stocrii temporare a rezultatelor clauzei WITH.
Observaii:
Clauza WITH poate fi folosit numai pentru instruciuni SELECT.
Un nume de cerere este vizibil tuturor blocurilor din clauza WITH
definite ulterior (inclusiv subcererilor acestora). De asemenea, un nume
de cerere este vizibil cererii principale i subcererilor acesteia.
Cnd un nume de cerere coincide cu numele unui tabel, numele blocului
de cerere are preceden asupra numelui tabelului.
Clauza WITH poate conine mai mult dect o singur cerere. n acest caz,
cererile sunt separate prin virgule.

2.4.4. Funcii grup i clauza GROUP BY

Clauza GROUP BY este utilizat pentru a diviza liniile unui tabel n grupuri.
Pentru a returna informaia corespunztoare fiecrui astfel de grup, pot fi utilizate
funciile agregat. Ele pot aprea n clauzele SELECT, ORDER BY i HAVING.
Server-ul Oracle aplic aceste funcii fiecrui grup de linii i returneaz un singur
rezultat pentru fiecare mulime.
Dintre funciile grup definite n sistemul Oracle, se pot enumera: AVG,
SUM, MAX, MIN, COUNT, STDDEV, VARIANCE, DENSE_RANK, RANK, FIRST,
LAST, GROUP_ID, GROUPING, GROUPING_ID etc. Tipurile de date ale
argumentelor funciilor grup pot fi CHAR, VARCHAR2, NUMBER sau DATE.
Funciile AVG, SUM, STDDEV i VARIANCE opereaz numai asupra valorilor
numerice. Funciile MAX i MIN pot opera asupra valorilor numerice, caracter sau
de tip dat calendaristic.
Toate funciile grup, cu excepia lui COUNT(*), ignor valorile null.
COUNT(expresie) returneaz numrul de linii pentru care expresia dat nu are
valoarea null. Funcia COUNT returneaz un numr mai mare sau egal cu zero i
nu ntoarce niciodat valoarea null.
Cnd este utilizat clauza GROUP BY, server-ul sorteaz implicit mulimea
rezultat n ordinea cresctoare a valorilor coloanelor dup care se realizeaz
gruparea.
n clauza GROUP BY a unei cereri se pot utiliza operatorii ROLLUP i
CUBE. Acetia sunt disponibili ncepnd cu versiunea Oracle8i.
Operatorul ROLLUP
Operatorul ROLLUP produce o mulime care conine liniile obinute n urma
gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori
agregat i superagregat corespunztoare expresiilor din clauza GROUP BY.
Operatorul ROLLUP poate fi folosit pentru extragerea de statistici i informaii
totalizatoare din mulimile rezultate. Acest operator poate fi util la generarea de
rapoarte, diagrame i grafice.
Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie,
de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP
BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii
n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se
bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se
numesc linii superagregat.
Dac n clauza GROUP BY sunt specificate n coloane, pentru a produce
subtotaluri fr operatorul ROLLUP ar fi necesare n + 1 instruciuni SELECT

conectate prin UNION ALL. Aceasta ar face execuia cererii ineficient deoarece
fiecare instruciune SELECT determin accesarea tabelului. Operatorul ROLLUP
determin rezultatele efectund un singur acces la tabel i este util atunci cnd sunt
implicate multe coloane n producerea subtotalurilor.
Exemplu:
S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre
acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze
valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor
expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din
galeriile avnd codul mai mic dect 50, indiferent de codul autorului.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);
Instruciunea precedent va avea un rezultat de forma:
COD_GALERIE

COD_ARTIST
10
10
10
40
40

50
60
50

SUM(VALOARE)
14000
10000
24000
8080
8080
32080

n rezultatul prezentat anterior se pot distinge 3 tipuri de linii.

1) Prima linie reprezint suma operelor artistului care are codul 50, expuse
n galeria avnd codul 10. n mod similar se interpreteaz a doua i a
patra linie din rezultat.
2) Linia a treia i a cincea din rezultat conin valoarea total a operelor din
galeria al crei cod este 10, respectiv 40. Aceste linii se disting prin faptul
c valoarea coloanei cod_artist este null.
3) Ultima linie conine suma valorilor tuturor operelor din galeriile al cror
cod este 10 sau 40. Valoarea afiat este obinut prin nsumarea valorilor
de pe a treia, respectiv a cincea linie. ntruct aceast linie corespunde
totalului general, ea conine valoarea null pe toate coloanele, cu excepia

cmpului SUM(valoare).
Operatorul CUBE
Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor
combinaiilor posibile ale expresiilor specificate i returneaz cte o linie
totalizatoare pentru fiecare grup. Acest operator este folosit pentru a produce
mulimi de rezultate care sunt utilizate n rapoarte. n vreme ce ROLLUP produce
subtotalurile doar pentru o parte dintre combinaiile posibile, operatorul CUBE
produce subtotaluri pentru toate combinaiile posibile de grupri specificate n
clauza GROUP BY, precum i un total general.
Dac exist n coloane sau expresii n clauza GROUP BY, vor exista 2n
combinaii posibile superagregat. Din punct de vedere matematic, aceste
combinaii formeaz un cub n-dimensional, de aici provenind numele operatorului.
Pentru producerea de subtotaluri fr ajutorul operatorului CUBE ar fi necesare 2n
instruciuni SELECT conectate prin UNION ALL.
Exemplu:
S se afieze valoarea total a operelor de art ale unui autor, expuse n
cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze
valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50,
valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a
operelor din galeriile avnd codul mai mic dect 50.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY CUBE(cod_galerie, cod_artist);
Instruciunea precedent va genera un rezultat de forma urmtoare:
COD_GALERIE

COD_ARTIST
10
10
10
40
40

50
60
50
50
60

SUM(VALOARE)
14000
10000
24000
8080
8080
22080
10000

32080
n plus fa de rezultatul corespunztor operaiei ROLLUP, operatorul CUBE
a produs linii care reprezint suma valorilor operelor pentru fiecare artist care a
expus n galerii avnd codul mai mic dect 50. Aceste linii se disting prin faptul c
valoarea coloanei cod_galerie este null.
Funcia GROUPING
Funcia GROUPING poate fi utilizat alturi de operatorii CUBE i
ROLLUP pentru a arta modul cum a fost obinut o valoare totalizatoare. Aceast
funcie accept un singur argument, care trebuie s fie una dintre expresiile
specificate n clauza GROUP BY.
O valoare null a expresiei din argumentul funciei GROUPING poate
proveni din tabelul de baz (valoare null stocat) sau poate fi o valoare null creat
de operaia ROLLUP sau CUBE ca rezultat al unei funcii grup asupra expresiei
respective.
Funcia GROUPING returneaz valoarea 0 sau 1. Valoarea 0 returnat de
funcia GROUPING pe baza unei expresii poate indica fie c expresia a fost
utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o
valoare null stocat. Valoarea 1 returnat de funcia GROUPING pe baza unei
expresii poate indica fie c expresia nu a fost utilizat pentru calculul valorii
agregat, fie c valoarea null a expresiei este creat de ROLLUP sau CUBE ca
rezultat al gruprii.
Valorile returnate de funcia GROUPING sunt utile pentru:
determinarea nivelului de agregare al unui subtotal dat, adic a grupului
sau grupurilor pe care se bazeaz subtotalul respectiv;
identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat.
Exemplu:
SELECT cod_galerie, cod_artist, SUM(valoare),
GROUPING(cod_galerie), GROUPING(cod_artist)
FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);
SUM
GROUPING
GROUPING
(VALOARE) (COD_GALERIE) (COD_ARTIST)
50
14000
0
0

COD_GALERIE COD_ARTIST
10

10
10
40
40

60
50

10000
24000
8080
8080
32080

0
0
0
0
1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma

valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula
aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist.
Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au
valoarea 0 pentru prima linie din rezultat.
Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10.
Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie,
astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0,
respectiv 1.
Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile
avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist
nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare
expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0.
Clauza GROUPING SETS
GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite
specificarea unor grupri multiple de date. Utilizarea acestei opiuni faciliteaz
analiza datelor n mai multe dimensiuni.
Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure
instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii
ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin
operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este
ineficient ntruct necesit mai multe parcurgeri ale acelorai date.
Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi
de grupri. Au loc urmtoarele echivalene:
CUBE(a, b, c)

GROUPING SETS
((a, b, c), (a, b), (a, c), (b, c), (a),
(b), (c), ())
ROLLUP(a, b,
GROUPING SETS
c)
((a, b, c), (a, b), (a), ())
Exemplu:
Considernd galeriile al cror cod este mai mic dect 50, s se calculeze
media valorilor operelor:

0
1
0
1
1

pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist;

pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie
corespunztori.
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera
WHERE cod_galerie < 50
GROUP BY GROUPING SETS
((cod_galerie, cod_artist),
(cod_artist, TO_CHAR(data_achizitiei, 'yyyy')));
Mulimea rezultat este constituit din valorile medii pentru fiecare dintre
cele dou grupuri i are forma urmtoare:
COD_GALERIE COD_ARTIST
10
50
10
60
40
50
50
50
60
60

an a

2000
2002
2001
2003

Valoare medie
3500
2500
2020
2380
2300
2000
3000

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune

compus:
SELECT cod_galerie, cod_artist, NULL "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY cod_galerie, cod_artist
UNION ALL
SELECT NULL, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare)
FROM opera
GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy');
n absena unui optimizor care analizeaz blocurile de cerere i genereaz
planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz
(opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea

extensiei GROUPING SETS.

Concatenarea gruprilor
Concatenarea gruprilor reprezint o modalitate concis de a genera
combinaii de grupri. Acestea se specific prin enumerarea mulimilor de grupri
(grouping sets) i a operaiilor ROLLUP, CUBE separate prin virgul. De exemplu,
expresia GROUP BY GROUPING SETS(a, b), GROUPING SETS(c, d) definete
gruprile (a, c), (a, d), (b, c), (b, d).
Concatenarea mulimilor de grupri este util att pentru uurina dezvoltrii
cererilor, ct i pentru aplicaii. Codul SQL generat de aplicaiile OLAP implic
deseori concatenarea mulimilor de grupri, n care fiecare astfel de mulime
definete gruprile necesare pentru o dimensiune.
Exemplu:
S se determine media valorilor operelor lund n considerare urmtoarele
grupri: (cod_galerie, cod_artist, an_achizitie), (cod_galerie, cod_artist),
(cod_galerie, an_achizitie), (cod_galerie).
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') an_achizitie,
AVG(valoare)
FROM opera
GROUP BY cod_galerie, ROLLUP(cod_artist),
CUBE(TO_CHAR(data_achizitiei, 'yyyy'));

PROBLEME-SUBCERERI
De cele mai multe ori, pentru a implementa anumite interogri, nu este
suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt
comenzi SELECT ncapsulate n oricare din clauzele SELECT, WHERE, HAVING,
FROM.
Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine
unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt
specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul
dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor
care ntorc o singur linie (single-row subquery).
Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt
a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY.
Exemplu:
S se obin numele salariailor, salariile, codul departamentului n care
lucreaz i salariul mediu pe departament pentru toi angajaii care au salariul mai
mare ca media salariilor din departamentul n care lucreaz (folosirea subcererii n
clauza FROM).
SELECT a.nume, a.sal, a.cod_dep, b.salavg
FROM angajati a, (SELECT dept ,avg(sal) salavg
FROM angajati
GROUP BY cod_dep) b
WHERE
a. cod_dep =b. cod_dep
AND
a.sal>b.salavg
Exemplu:
S se obin lista celor mai scumpe cri.
SELECT
titlu
FROM
carte
WHERE
pret = (SELECT
FROM carte);

MAX(pret)

Exemplu:
S se obin lista scriitorilor care au n bibliotec un numr de exemplare
mai mare dect numrul mediu al crilor din bibliotec.
SELECT
FROM

DISTINCT autor
carte

WHERE

nrex > (SELECT AVG(nrex)

FROM
carte);

Exemplu:
S se obin informaii despre crile al cror pre depete media preurilor
crilor ce aparin aceluiai domeniu
SELECT
FROM
WHERE

*
carte c
pret > (SELECT AVG(pret)
FROM
carte
WHERE
coded = c.coded);

Exemplu:
S se obin lista cititorilor care au mprumutat cel puin o carte.
SELECT
FROM
WHERE

nume
cititor
codec IN (SELECT DISTINCT codec
FROM imprumuta);

Exemplu:
S se obin codurile cititorilor care nu au mprumutat niciodat cri.
SELECT
FROM
WHERE

codec
cititor
codec NOT IN
(SELECT
DISTINCT codec
FROM imprumuta);

Exemplu:
S se obin lista cititorilor care sunt n ntrziere cu predarea crilor.
SELECT
FROM
WHERE

nume
cititor
codec IN (SELECT
FROM
WHERE
AND

DISTINCT codec
imprumuta
dataef IS NULL
dares<SYSDATE);

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte scris de
ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec IN
(SELECT

DISTINCT codec

FROM
imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE autor=ZOLA));
Exemplu:
S se obin numele cititorilor care nu au mprumutat nici o carte scris de
ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec NOT IN
(SELECT DISTINCT codec
FROM imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE autor=ZOLA));

Operatorul IN poate fi nlocuit cu = ANY (un element este n list dac i

numai dac este egal cu un element al listei), iar operatorul NOT IN poate fi
nlocuit prin !=ALL.
Exemplu:
S se obin codurile cititorilor care au mprumutat o carte de algebr.
SELECT
DISTINCT codec
FROM
imprumuta
WHERE
codel IN
(SELECT codel
FROM
carte
WHERE coded=
(SELECT coded
FROM domeniu
WHERE intdom=ALGEBRA));
Exemplu:
S se obin cititorii care au mprumutat numai cri scrise de ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec NOT IN
(SELECT DISTINCT codec
FROM
imprumuta
WHERE codel NOT IN

(SELECT codel
FROM carte
WHERE autor=ZOLA));
Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte de
informatic (procedural).
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT DISTINCT codec
FROM
imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE coded=
(SELECT coded
FROM domeniu
WHERE intdom= INFORMATICA)));
Exemplu:
S se obin numele cititorilor i titlurile crilor de informatic mprumutate
de aceti cititori (relational).
SELECT
FROM
WHERE
AND
AND
AND

nume, titlu
cititor, carte, imprumuta, domeniu
imprumuta.codel = carte.codel
carte.coded = domeniu.coded
imprumuta.codec = cititor.codec
intdom = INFORMATICA;

Subcererile pot fi executate corelat (cu sincronizare) sau ncuibrit (fr

sincronizare).
Subcererile fr sincronizare sunt caracterizate de faptul c se execut
cererea cea mai interioar care ntoarce un rezultat ce este transmis cererii de nivel
superior, care ntoarce un rezultat s.a.m.d.
Subcererile cu sincronizare sunt caracterizate de faptul c evaluarea
subcererii face referin la o coloan a cererii principale, iar evaluarea cererii
interioare se face pentru fiecare linie a cererii (principale) care o conine.

Exemplu:
S se obin, utiliznd sincronizarea subcererii cu cererea principal, titlurile
crilor care au toate exemplarele mprumutate (se selecteaz un titlu din carte i
pentru acest titlu se numr cte exemplare sunt mprumutate).
SELECT
FROM
WHERE

titlu
carte
nrex=(SELECT
FROM
WHERE
AND

COUNT(*)
imprumuta
codel = carte.codel
dataef IS NULL);

Exemplu:
S se obin codurile cititorilor i codul ultimei cri mprumutate.
SELECT
FROM
WHERE

codec, codel
imprumuta i
dataim>=ALL (SELECT dataim
FROM
imprumuta
WHERE codec=i.codec);

Pentru aceast interogare, clauza WHERE putea fi scris i sub forma:

WHERE

dataim=(SELECT MAX(dataim)
FROM
imprumuta
WHERE
codec=i.codec);

Exemplu:
S se obin lista codurilor crilor mprumutate i codul primului cititor care
a mprumutat aceste crti.
SELECT
FROM
WHERE

codel,codec
imprumuta i
dataim<=ALL (SELECT dataim
FROM imprumuta
WHERE i.codel=codel);

Exemplu:
S se obin codurile crilor din care cel puin un exemplar este mprumutat.
SELECT
FROM
WHERE

codel
carte
EXISTS
(SELECT codel
FROM
imprumuta

WHERE
AND

codel = carte.codel
dataef IS NULL);

Operatorul WHERE EXISTS (subcerere) presupune c predicatul este

adevrat dac subcererea ntoarce cel puin un tuplu, iar WHERE NOT EXISTS
(subcerere) presupune c predicatul este adevrat dac subcererea nu ntoarce nici
un tuplu. EXISTS i NOT EXISTS cer sincronizarea subcererii.
Exemplu:
S se obin titlurile crilor care sunt momentan mprumutate.
Soluia 1 (cu sincronizare):
SELECT
titlu
FROM
carte
WHERE
EXISTS
(SELECT *
FROM
WHERE
AND

imprumuta
codel = carte.codel
dataef IS NULL);

Soluia 2 (fr sincronizare):

SELECT
titlu
FROM
carte
WHERE
codel IN
(SELECT DISTINCT codel
FROM
imprumuta
WHERE
dataef IS NULL);
Exemplu:
S se obin codurile crilor care nu au fost mprumutate niciodat.
Soluia 1 (cu sincronizare)
SELECT
codel
FROM
carte
WHERE
NOT EXISTS
(SELECT
FROM
WHERE

codel
imprumuta
codel = carte.codel);

Soluia 2 (fr sincronizare)

SELECT
FROM
WHERE

codel
carte
codel NOT IN
(SELECT DISTINCT codel

FROM

imprumuta);

Exemplu:
S se obin lista salariailor avnd salariul minim n departamentul n care
lucreaz.
SELECT
FROM
WHERE

ename,sal
emp e
sal=(SELECT
FROM
WHERE

MIN(sal)
emp
deptno=e.deptno);

Exemplu:
S se obin numele primilor trei salariai avnd retribuia maxim (ideea
rezolvrii este de a verifica dac numrul salariailor care au leafa mai mare dect
leafa salariatului considerat, este mai mic dect 3).
SELECT
FROM
WHERE

ename
emp a
3>(SELECT COUNT(*)
FROM
emp
WHERE
sal > a.sal);

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin aceleai cri ca
i cititorul avnd codul C19 (ideea problemei este de a selecta cititorii pentru care
este vid lista crilor mprumutatede C19 mai puin lista crilor mprumutate de
acei cititori).
SELECT
nume
FROM
cititor
WHERE
NOT EXISTS
(SELECT codel
FROM imprumuta
WHERE codec=C19
MINUS
SELECT codel
FROM imprumuta
WHERE codec= cititor.codec);
Dac problema era modificat n sensul c cel puineste nlocuit prin cel
mult atunci trebuiau inversate interogrile legate prin MINUS.

Exemplu:
S se obin codurile cititorilor care au mprumutat aceleai cri ca i
cititorul avnd un cod specificat.
Rezolvarea problemei se bazeaz pe ideea: A = B A B i B A (AB) = i (B-A) = A-B i B-A nu furnizeaz nici un tuplu rezultat.
SELECT
codec
FROM
imprumuta i
WHERE
NOT EXISTS
(SELECT codel
FROM
imprumuta
WHERE codec=i.codec
MINUS
SELECT codel
FROM
imprumuta
WHERE codec=&ccc)
AND
NOT EXISTS
(SELECT codel
FROM
imprumuta
WHERE codec=&ccc
MINUS
SELECT codel
FROM
imprumuta
WHERE codec=i.codec)
AND
codec!=&ccc);
Ultimul operator (AND), asigur s nu apar n rezultat cititorul specificat.
n cazul formei relaionale de rezolvare a cererii, drumul de acces la
informaie este n sarcina SGBD-lui i prin urmare nu mai apar cereri imbricate.
Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte.
Soluia 1 (forma relaional):
SELECT
DISTINCT nume
FROM
cititor,imprumuta
WHERE
cititor.codec=imprumuta.codec;
Soluia 2 (forma procedural):
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT DISTINCT codec
FROM
imprumuta);

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin dou cri.
Soluia 1 (forma relaional):
SELECT
nume
FROM
cititor, imprumuta
WHERE
cititor.codec=imprumuta.codec
GROUP BY nume
HAVING COUNT(*)>1;
Soluia 2 (forma procedural):
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT codec
FROM
imprumuta
GROUP BY codec
HAVING COUNT(*)>1);
Exemplu:
S se afieze numele, prenumele, salariul lucrtorilor, codurile publicaiilor
la care lucreaz i salariul mediu pe publicaie pentru toi angajaii care au salariul
mai mare dect media salariului pe publicaia respectiv.
SELECT

s.nume, s.prenume, s.salariu,

p.nr_publicatie, a.salariu_mediu
FROM
salariat s, publicatie p,
(SELECT p1.nr_publicatie,AVG(salariu) salariu_mediu
FROM publicatie p1, salariat s1
WHERE p1.cod_salariat = s1.cod_salariat
GROUP BY p1.nr_publicatie) a
WHERE
p.nr_publicatie = a.nr_publicatie
AND
s.cod_salariat = p.cod_salariat
AND
s.salariu > a.salariu_mediu;
Exemplu:
S se obin numele salariailor care nu cunosc nici o limb strin.
SELECT nume, prenume
FROM
salariat
WHERE
NOT EXISTS
(SELECT *
FROM limba
WHERE limba.cod_salariat = salariat.cod_salariat
AND limba_cun IS NOT NULL);
Exemplu:

S se afieze graficienii care au ntrziat s predea frame-urile.

a) cu sincronizare:
SELECT nume, prenume
FROM
salariat
WHERE
EXISTS
(SELECT *
FROM
realizeaza r
WHERE
salariat.cod_salariat=r.cod_salariat
AND
data_lim < SYSDATE);
b) fr sincronizare:
SELECT nume, prenume
FROM
salariat
WHERE
cod_salariat IN
(SELECT DISTINCT cod_salariat
FROM
realizeaza
WHERE data_lim < SYSDATE);
Exemplu:
S se determine revistele coordonate de redactori efi care nu cunosc limba
n care sunt scrise. Se tie c n urma inspectrii vizuale a rezultatului interogrii se
poate decide schimbarea redactorilor efi ai revistelor respective, de aceea se
dorete blocarea nregistrrilor gsite.
SELECT p.nr_publicatie
FROM
salariat s, publicatie p
WHERE
s.cod_salariat = p.cod_salariat
AND
p.limba NOT IN
(SELECT limba_cun
FROM
limba
WHERE limba.cod_salariat = s.cod_salariat)
FOR UPDATE OF p.cod_salariat;

Subinterogri
O caracteristic foarte puternic a limbajului SQL sunt subinterogrile
(numite i selecii), care, aa cum sugereaz i numele, se refer la o instruciune
SELECT care conine o instruciune SELECT subordonat.
De cele mai multe ori, pentru a implementa anumite interogri, nu este
suficient o singur cerere SELECT ci sunt necesare subcereri.
Subcererile sunt comenzi SELECT ncapsulate n oricare din clauzele ,
SELECT, WHERE, HAVING, FROM, numit instruciune printe.
Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine
unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt
specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul
dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor
care ntorc o singur linie (single-row subquery).
Utiliznd subcereri, se pot construi interogri complexe pe baza unor
instruciuni simple. Subcererile mai sunt numite instruciuni SELECT imbricate
sau interioare.
Subcererea returneaz o valoare care este utilizat de ctre instruciunea
printe. Utilizarea unei subcereri este echivalent cu efectuarea a dou cereri
secveniale i utilizarea rezultatului cererii interne ca valoare de cutare n cererea
extern (principal).
Subcererile pot fi utilizate n urmtoarele situaii:
pentru a furniza valori care intervin n condiiile din clauzele WHERE,
HAVING i START WITH ale instruciunilor SELECT;
pentru a defini o mulime de linii care urmeaz s fie inserat n tabelul
destinaie al unei instruciuni INSERT sau CREATE TABLE;
pentru a defini o mulime de linii care urmeaz s fie inserate ntr-o
vizualizare sau vizualizare materializat, prin intermediul unei
instruciuni CREATE VIEW sau CREATE MATERIALIZED VIEW;
pentru a defini una sau mai multe valori care urmeaz s fie atribuite unor
linii existente ntr-o instruciune UPDATE;
pentru a defini un tabel asupra cruia va opera cererea extern (plasarea
subcererii n clauza FROM sau n instruciunile INSERT, UPDATE,
DELETE).

Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt

a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY.
De obicei, subinterogrile sunt folosite n clauza WHERE, ca modalitate de
limitare a rndurilor returnate n setul de rezultate al interogrii externe. Aceasta
poate fi o modalitate foarte flexibil de selectare a datelor.
O regul esenial de sintax este ca subinterogarea s fie ncadrat de paranteze.
Orice operaie efectuat cu o subinterogare poate fi fcut i printr-o uniune.
Subinterogri necorelate
O subinterogare necorelat (noncorrelated subselect) este o subinterogare n
care interogarea intern nu face nici o referire la interogarea extern care o conine.
Subcererile necorelate returneaz o valoare care este utilizat de cererea
extern (cererea principal). Cererile care conin subcereri necorelate sunt evaluate
n modul urmtor:
cererea intern este executat prima i determin o valoare (sau o
mulime de valori);
cererea extern se execut o singur dat, utiliznd valorile returnate de
cererea intern.
n general, o cerere imbricat, necorelat are urmtoarea form:
SELECT
FROM
WHERE

lista_select
nume_tabel
expresie operator (SELECT lista_select
FROM
nume_tabel);

n aceast sintax, identificatorul operator poate fi de tip:

single-row operator (>, =, >=, <, <>, <=), care poate fi utilizat dac
subcererea returneaz o singur linie;
multiple-row operator (IN, ANY, ALL), care poate fi folosit dac
subcererea returneaz mai mult de o linie.
Operatorul ANY, care este sinonim cu operatorul SOME, determin
compararea unei valori cu fiecare valoare returnat de o subcerere. Astfel, <ANY
are semnificaia mai mic dect maximul; >ANY nseamn mai mare dect
minimul; =ANY este echivalent cu operatorul IN. Operatorul ALL compar o
valoare cu toate valorile returnate de o subcerere. Astfel, <ALL are semnificaia
mai mic dect minimul, iar >ALL este echivalent cu mai mare dect maximul.
Operatorul NOT poate fi utilizat n combinaie cu IN, ANY i ALL.
n utilizarea unei subcereri se impun anumite reguli.
Subcererea trebuie inclus ntre paranteze.

Pentru claritate, subcererea se plaseaz n partea dreapt a operatorului de

comparaie.
nainte de versiunea Oracle8i, subcererile nu puteau s conin clauza
ORDER BY. ncepnd cu Oracle8i, clauza ORDER BY poate fi utilizat i
este chiar obligatorie n subcerere pentru a efectua analiza top-n (cererea
care efectueaz analiza top-n returneaz cele mai mari sau cele mai mici
n valori ale unei coloane).
Operatorul folosit trebuie s fie conform cu tipul cererii. Cererea va
genera o eroare dac este utilizat un operator single-row n faa unei
subcereri care returneaz mai mult de o linie. De asemenea, dac
subcererea nu returneaz nici o linie, apare o eroare.
Server-ul Oracle nu impune nici o limit asupra numrului de subcereri.
Limita acestora depinde de dimensiunea buffer-ului pe care l utilizeaz cererea.
Exemple:
Afiai toate limbile n care nu exist nici un film n inventarul magazinului de
produse video.
SELECT LIMBA_COD, LIMBA_NUME
FROM LIMBA
WHERE LIMBA_COD NOT IN
(SELECT DISTINCT LIMBA_COD
FROM FILM_LIMBA)
ORDER BY LIMBA_COD
LIMBA_COD
Ja
Ko
ni
ru
zh

LIMBA_NUME
Japoneza
Coreana
Olandeza
Rusa
Chineza

Interogarea intern returneaz o list cu codurile de limb asociate filmelor n

tabelul FILM_LIMBA. Cuvntul cheie DISTINCT elimin rndurile duplicate din
setul de rezultate .
Interogarea intern rulat independent, pentru a v ajuta s nelegei cum
funcioneaz:

SELECT DISTINCT LIMBA_COD FROM FILM_LIMBA;

LIMBA_COD
------------------------------------------de
(Germana)
en
(Engleza)
es
(Spaniola)
fr
(Franceza)
Proprietarul magazinului vrea s vad efectul recentei creteri de preuri i are
nevoie de o list a tranzaciilor (TRANZACTIE_ID) n care clientul a pltit mai
mult dect taxa medie (INCHIRIAT_TAXA) pentru un film. Iat cum arat
interogarea:
SELECT DISTINCT TRANZACTIE_ID
FROM FILM_INCHIRIAT
WHERE INCHIRIAT_TAXA>
(SELECT AVG(INCHIRIAT_TAXA) FROM FILM_INCHIRIAT)
Interogarea intern calculeaz media taxelor de nchiriere, iar interogarea extern
gsete apoi toate rndurile din tabelul FILM_INCHIRIAT pentru care valoarea
INCHIRIAT_TAXA depete media.
Cuvntul cheie DISTINCT elimin tranzaciile duplicate.
Rezultatele interogrii anterioare ar fi mai utile pentru proprietarul magazinului
dac ar include i data tranzaciei. O modalitate de a realiza acest lucru este i
adugm o uniune cu tabelul CLIENT_TRANZACTIE n interogarea extern.
Totui, deoarece tocmai ai nvat despre subinterogari, s facem acelai lucru
folosind nc o subinterogare. Iat cum arat interogarea:
SELECT TRANZACTIE_ID, TRANZACTIE_DATA AS TRANZ_DATA
FROM CLIENT_TRANZACTIE
WHERE TRANZACTIE_ID IN
(SELECT DISTINCT TRANZACTIE_ID FROM FILM_INCH,
WHERE INCH_TAXA > (SELECT AVG ( INCHIRIAT_TAXA)
FROM FILM_INCHIRIAT)
TRANZACTIE_ID TRANZ_DATA
9
03/01/2005
10
03/01/2005

Exemplu(din galeria de arta):

a) S se afieze titlul, codul artistului i valoarea operelor create de artistul
cruia i aparine opera avnd codul 180 i care se afl expuse n aceeai galerie cu
operele al cror cod este 100 sau 110. Se presupune c o oper are un singur autor.
SELECT titlu, cod_artist, valoare
FROM opera
WHERE cod_artist = (SELECT cod_artist
FROM opera
WHERE cod_opera = 180)
AND
cod_galerie IN (SELECT cod_galerie
FROM opera
WHERE cod_opera IN (100, 110));
b) S se determine artistul pentru care valoare medie a operelor sale de art
este minim.
SELECT cod_artist, AVG(valoare)
FROM opera
GROUP BY cod_artist
HAVING AVG(valoare) = (SELECT MIN(AVG(valoare))
FROM opera
GROUP BY cod_artist);
c) Pentru fiecare artist, s se afieze titlul i valoarea celei mai ieftine opere
de art expuse n muzeu.
SELECT titlu, cod_artist, valoare
FROM opera
WHERE valoare IN (SELECT MIN(valoare)
FROM opera
GROUP BY cod_artist);
d) S se afieze operele de art care nu sunt expuse n galeria avnd codul
30 i a cror valoare este mai mic dect a unei opere din galeria 30.
SELECT cod_opera, titlu, valoare
FROM opera
WHERE valoare < ANY (SELECT valoare
FROM opera
WHERE cod_galerie = 30)
AND
cod_galerie <> 30;
Dac operatorul ANY se nlocuiete cu operatorul ALL, cererea precedent

returneaz operele care nu sunt expuse n galeria 30 i a cror valoare este mai
mic dect a oricrei opere din galeria respectiv.
e) S se afieze cele mai scumpe 3 opere de art din muzeu.
SELECT ROWNUM "Nr.Crt", titlu, valoare
FROM (SELECT titlu, valoare
FROM
opera
ORDER BY valoare DESC)
WHERE ROWNUM <= 3;
Exemplu:
Din punct de vedere logic, urmtoarea cerere ar trebui s returneze titlurile
operelor care nu sunt expuse n galeriile unde se afl lucrrile artistului avnd
codul 60.
SELECT titlu
FROM opera
WHERE cod_galerie NOT IN (SELECT cod_galerie
FROM opera
WHERE cod_artist = 60);
Dac pentru una dintre opere valoarea coloanei cod_galerie este null,
ntreaga cerere nu va returna nici o linie, chiar dac exist nregistrri cu
proprietatea cerut. Justificarea este c toate condiiile n care unul dintre operanzi
este null au, de asemenea, valoarea null. Prin urmare, ori de cte ori este posibil ca
n rezultatul subcererii s apar valori null, nu trebuie folosit operatorul NOT IN.
Operatorul NOT IN este echivalent cu <>ALL. Dac se utilizeaz operatorul IN, nu
mai este nici o problem dac n rezultatul subcererii apar valori null. Operatorul
IN este echivalent cu =ANY.
Exemplu:
S se afieze titlurile operelor care sunt expuse n galeriile unde se afl
lucrrile artistului avnd codul 60.
SELECT titlu
FROM opera
WHERE cod_galerie IN (SELECT cod_galerie
FROM opera
WHERE cod_artist = 60);
Pentru a evita obinerea de valori null n rezultatul unei cereri care utilizeaz
operatorul NOT IN, se poate specifica o condiie n subcerere:
SELECT titlu
FROM opera

WHERE cod_galerie NOT IN (SELECT cod_galerie

FROM opera
WHERE cod_artist = 60
AND
cod_galerie IS NOT NULL);

Subcereri (Subinterogri) corelate

O subinterogare corelat (correlated subselect) este o subinterogare n care
interogarea intern refer valorile furnizate de interogarea extern.
Subcererile corelate sunt utilizate pentru procesarea linie cu linie a
interogrilor. O subcerere este corelat dac face referin la o coloan dintr-un
tabel specificat n instruciunea printe. O astfel de subcerere este evaluat o dat
pentru fiecare linie procesat de instruciunea printe, care poate fi SELECT,
UPDATE sau DELETE.
Subcererile corelate permit compararea valorilor unei linii cu date
determinate pe baza acestor valori.
Cererile corelate se execut astfel:
cererea extern determin o linie candidat;
cererea intern este executat utiliznd valoarea liniei candidat;
valorile rezultate din cererea intern sunt utilizate pentru calificarea sau
descalificarea liniei candidat;
paii precedeni se repet pn cnd nu mai exist linii candidat.
Forma general a unei subcereri corelate este urmtoarea:
SELECT nume_coloan_1[, nume_coloan_2 ]
FROM nume_tabel_1 extern
WHERE expresie operator
(SELECT nume_coloan_1 [, nume_coloan_2 ]
FROM
nume_tabel_2
WHERE expresie_1 = extern.expresie_2);

Exemplu:
Proprietarul magazinului vrea s transmit prin pot un cupon valoric
tuturor clienilor care au pltit mai mult de 15$ pentru o singur tranzacie de
nchiriere.
SELECT DISTINCT CLIENT_CONT_ID

FROM CLIENT_TRANZACTIE A
WHERE 15 < (SELECT SUM (INCHIRIAT_TAXA)
FROM FILM_INCHIRIATB
WHERE A.TRANZACTIE _ID = B.TRANZACTIE_ID)
CLIENT_CONT_ID
2
7
9
Observai pseudonimele asociate numelor de tabele din interogrile intern
i extern, precurn i folosirea acestora n clauza WHERE a interogrii interne.
Acesta este elementul de identificare al unei subinterogri corelate. Interogarea
extern selecteaz o lista de valori CLIENT_CONT_ID distincte din tabelul
CLIENT_TRANZACTIE. Fiecare valoare gsit este transmis interogrii interne,
care este rulat pentru a calcula suma taxelor de nchiriere din tranzacia
respectiv. Dac suma taxelor de nchiriere este mai mare sau egal cu 15, atunci
clauza WHERE din interogarea extern ia valoarea logic adevrat", iar rndul
CLIENT_ID este adugat n setul de rezultate.
Vizualizri n linie
Foarte puine implementri, printre care Oracle, permit folosirea unei subinterogri
n clauza FROM a unei interogri, ntr-o construcie numit vizualizare n linie
(inline view). Aceast construcie permite care setul de rezultate al unei interogri
s fie tratat ca i cum ar fi un tabel sau o vizualizare predefinit. Iat un exemplu:
Aceast interogare afl numrul maxim de nchirieri ale unui singur film;
SELECT MAX(INCHIRIAT_NUMAR) AS MAX_INCHIRIAT_NUMAR
FROM (SELECT FILM_ID, NUMAR(*) AS INCHIRIAT_NUMAR
FROM FILM_INCHIRIAT GROUP BY FILM_ID)
MAX_INCH_NUMAR
5
Interogarea intern calculeaz numrul de nchirieri pentru fiecare valoare
FILM_ID. Interogarea extern selecteaz valoarea maxim INCHIRIAT_NUMAR
din interogarea intern, tratat ca i cum ar fi o vizualizare predefinit. Nu exist
nici o limit n privina modurilor de utilizare a vizualizrilor n linie - putei chiar
s le unii cu alte tabele sau vizualizri.

Exemplu de subcereri corelate pentru galeria de arta):

a) S se afieze informaii despre operele de art a cror valoare depete
valoarea medie a celor expuse n aceeai galerie.
SELECT titlu, valoare, cod_galerie
FROM opera o
WHERE valoare > (SELECT AVG(valoare)
FROM opera
WHERE cod_galerie = o.cod_galerie);
b) S se afieze codul, numele i prenumele artitilor care au cel puin dou
opere de art expuse n muzeu.
SELECT cod_artist, nume, prenume
FROM artist a
WHERE 2 <= (SELECT COUNT(*)
FROM opera
WHERE cod_artist = a.cod_artist);
Server-ul Oracle evalueaz subcererea corelat precedent urmnd
succesiunea de pai prezentat n continuare.
1) Selecteaz o linie din tabelul specificat n cererea extern (aceasta va fi
linia candidat curent).
2) Reine valoarea coloanei referite n subcerere din aceast linie candidat
(n cazul subcererii de mai sus, coloana referit n subcerere este
a.cod_artist).
3) Efectueaz subcererea, considernd condiia acesteia ca facnd referin
la valoarea liniei candidat din cererea extern (n exemplul precedent,
funcia COUNT(*) este evaluat pe baza valorii lui a.cod_artist
determinat la pasul 2).
4) Evalueaz clauza WHERE a cererii externe pe baza rezultatelor returnate
de cererea intern la pasul 3. Adic, se determin dac linia candidat este
selectat n rezultatul cererii (n exemplul precedent, numrul de opere
ale unui artist, evaluat de subcerere, este comparat cu 2 n clauza WHERE
a cererii externe, iar dac aceast condiie este satisfcut, linia
corespunztoare artistului respectiv va face parte din rezultat).
5) Procedura se repet pentru urmtoarele linii candidat din tabel, pn cnd
sunt procesate toate liniile tabelului.

Operatorul EXISTS
n instruciunile SELECT imbricate, este permis utilizarea oricrui operator
logic. Pentru a testa dac valoarea recuperat de cererea extern exist n mulimea
valorilor regsite de cererea intern corelat, se poate utiliza operatorul EXISTS.
Dac subcererea returneaz cel puin o linie, operatorul returneaz valoarea TRUE.
n caz contrar, va fi returnat valoarea FALSE.
Operatorul EXISTS asigur c nu mai este continuat cutarea n cererea
intern dup ce aceasta regsete o linie.
Exemplu:
a) S se determine codul, numele i prenumele artitilor care au cel puin o
oper de art expus n muzeu.
SELECT cod_artist, nume, prenume
FROM artist a
WHERE EXISTS (SELECT 'x'
FROM opera
WHERE cod_artist = a.cod_artist);
ntruct nu este necesar ca instruciunea SELECT interioar s returneze o
anumit valoare, se poate selecta o constant. De altfel, din punct de vedere al
performanei, selectarea unei constante asigur mai mult rapiditate dect
selectarea unei coloane.
Ca alternativ a lui EXISTS, poate fi utilizat operatorul IN. Exemplul
precedent poate fi rezolvat prin instruciunea urmtoare:
SELECT cod_artist, nume, prenume
FROM artist
WHERE cod_artist IN (SELECT cod_artist
FROM opera);
b) S se determine operele care nu sunt menionate n nici o surs
bibliografic.
SELECT cod_opera, titlu
FROM opera o
WHERE NOT EXISTS (SELECT 'x'
FROM mentionata_in
WHERE cod_opera = o.cod_opera);
Acest exemplu poate fi rezolvat i printr-o subcerere necorelat, utiliznd
operatorul NOT IN:
SELECT cod_opera, titlu
FROM opera

WHERE

cod_opera NOT IN (SELECT cod_opera

FROM ment_in
WHERE cod_opera IS NOT NULL);

Instruciuni LMD corelate

Subcererile corelate pot fi utilizate pentru actualizarea sau tergerea de
nregistrri dintr-un tabel pe baza liniilor altui tabel. Forma general a unei
instruciuni corelate UPDATE, respectiv DELETE, este urmtoarea:
UPDATE nume_tabel_1 alias_1
SET
nume_coloan = (SELECT
FROM
WHERE

expresie
nume_tabel_2 alias_2
alias_1.nume_coloan =
alias_2.nume_coloan);

DELETE FROM nume_tabel_1 alias_1

WHERE
expresie operator
(SELECT expresie
FROM
nume_tabel_2 alias_2
WHERE alias_1.nume_coloan =
alias_2.nume_coloan);
Exemplu:
Se presupune c valorile operelor sunt mrite cu 20% din costul ultimei
polie de asigurare ncheiate. S se actualizeze corespunztor valoarea operelor
care beneficiaz de cel puin o poli de asigurare.
UPDATE opera
SET valoare = (SELECT opera.valoare +
polita_asig.valoare*0.20
FROM polita_asig
WHERE cod_opera = opera.cod_opera
AND semnat_contract =
(SELECT MAX(semnat_contract)
FROM polita_asig
WHERE cod_opera = opera.cod_opera))
WHERE opera.cod_opera IN (SELECT DISTINCT cod_opera
FROM polita_asig);
Exemplu:
Pentru fiecare autor care are mai mult de 10 creaii expuse n muzeu, s se

tearg ultima oper creat de acesta.

DELETE FROM opera o1
WHERE
cod_artist =
(SELECT cod_artist
FROM opera o2
WHERE cod_artist = o1.cod_artist
AND data_crearii =
(SELECT MAX(data_crearii)
FROM opera
WHERE cod_artist = o2.cod_artist)
AND 10 >
(SELECT COUNT(*)
FROM opera
WHERE cod_artist = o2.cod_artist));
Clauza WITH
Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta
s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere
ntr-o instruciune SELECT complex. Acest lucru este util atunci cnd o cerere
face referin de mai multe ori la acelai bloc de cerere, care conine operaii join i
funcii agregat. Folosind clauza WITH, server-ul Oracle regsete rezultatele unui
bloc de cerere i le stocheaz n spaiul tabel temporar al utilizatorului, ceea ce
poate determina mbuntirea performanelor.
Exemplu:
Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i
valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a
operelor este mai mare dect media valorilor totale ale operelor tuturor artitilor.
WITH
val_artist AS (SELECT nume, SUM(valoare) AS total
FROM opera o, artist a
WHERE o.cod_artist = a.cod_artist
GROUP BY nume),
val_medie AS (SELECT SUM(total)/COUNT(*) AS medie
FROM val_artist)
SELECT *
FROM val_artist
WHERE total > (SELECT medie
FROM val_medie)
ORDER BY nume;
Intern, clauza WITH este tratat ca o vizualizare inline (subcerere n clauza

FROM) sau ca un tabel temporar. Optimizorul alege decizia adecvat pe baza

costului sau beneficiului stocrii temporare a rezultatelor clauzei WITH.
Observaii:
Clauza WITH poate fi folosit numai pentru instruciuni SELECT.
Un nume de cerere este vizibil tuturor blocurilor din clauza WITH
definite ulterior (inclusiv subcererilor acestora). De asemenea, un nume
de cerere este vizibil cererii principale i subcererilor acesteia.
Cnd un nume de cerere coincide cu numele unui tabel, numele blocului
de cerere are preceden asupra numelui tabelului.
Clauza WITH poate conine mai mult dect o singur cerere. n acest caz,
cererile sunt separate prin virgule.
Subcereri scalare
Subcererile scalare n SQL returneaz valoarea unei singure coloane
corespunztoare unei linii. Dac subcererea returneaz 0 linii, valoarea subcererii
scalare este null. Dac subcererea returneaz mai mult de o linie, server-ul
genereaz o eroare.
Subcererile scalare erau acceptate n Oracle8i doar n anumite cazuri, cum ar
fi clauzele FROM i WHERE ale instruciunii SELECT sau clauza VALUES a
instruciunii INSERT. Utilitatea subcererilor scalare a fost extins n Oracle9i.
Astfel, ele pot aprea n:
condiiile i expresiile care fac parte din DECODE sau CASE;
toate clauzele instruciunii SELECT, cu excepia lui GROUP BY;
n partea stng a operatorului, n clauzele SET i WHERE ale
instruciunii UPDATE.
Subcererile scalare nu sunt permise n urmtoarele situaii:
ca valori implicite pentru coloane sau ca expresii hash pentru grupri;
n clauza RETURNING a instruciunilor LMD;
n clauza GROUP BY, constrngerile de tip CHECK, condiiile WHEN;
n instruciunile care nu sunt legate de cereri, cum ar fi CREATE
PROFILE.
Exemplu:
S se afieze codul, titlul operelor i numele artistului doar dac acesta este
Brncui. n caz contrar, se va afia irul alt artist.
SELECT cod_opera, titlu,
(CASE WHEN cod_artist =
(SELECT cod_artist
FROM artist
WHERE nume = 'Brancusi')

THEN 'Brancusi'
ELSE 'Alt artist' END) artist
FROM opera;
2.4.4. Funcii grup i clauza GROUP BY
Clauza GROUP BY este utilizat pentru a diviza liniile unui tabel n grupuri.
Pentru a returna informaia corespunztoare fiecrui astfel de grup, pot fi utilizate
funciile agregat. Ele pot aprea n clauzele SELECT, ORDER BY i HAVING.
Server-ul Oracle aplic aceste funcii fiecrui grup de linii i returneaz un singur
rezultat pentru fiecare mulime.
Dintre funciile grup definite n sistemul Oracle, se pot enumera: AVG,
SUM, MAX, MIN, COUNT, STDDEV, VARIANCE, DENSE_RANK, RANK, FIRST,
LAST, GROUP_ID, GROUPING, GROUPING_ID etc. Tipurile de date ale
argumentelor funciilor grup pot fi CHAR, VARCHAR2, NUMBER sau DATE.
Funciile AVG, SUM, STDDEV i VARIANCE opereaz numai asupra valorilor
numerice. Funciile MAX i MIN pot opera asupra valorilor numerice, caracter sau
de tip dat calendaristic.
Toate funciile grup, cu excepia lui COUNT(*), ignor valorile null.
COUNT(expresie) returneaz numrul de linii pentru care expresia dat nu are
valoarea null. Funcia COUNT returneaz un numr mai mare sau egal cu zero i
nu ntoarce niciodat valoarea null.
Cnd este utilizat clauza GROUP BY, server-ul sorteaz implicit mulimea
rezultat n ordinea cresctoare a valorilor coloanelor dup care se realizeaz
gruparea.
n clauza GROUP BY a unei cereri se pot utiliza operatorii ROLLUP i
CUBE. Acetia sunt disponibili ncepnd cu versiunea Oracle8i.
Operatorul ROLLUP
Operatorul ROLLUP produce o mulime care conine liniile obinute n urma
gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori
agregat i superagregat corespunztoare expresiilor din clauza GROUP BY.
Operatorul ROLLUP poate fi folosit pentru extragerea de statistici i informaii
totalizatoare din mulimile rezultate. Acest operator poate fi util la generarea de
rapoarte, diagrame i grafice.
Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie,
de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP
BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii

n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se

bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se
numesc linii superagregat.
Dac n clauza GROUP BY sunt specificate n coloane, pentru a produce
subtotaluri fr operatorul ROLLUP ar fi necesare n + 1 instruciuni SELECT
conectate prin UNION ALL. Aceasta ar face execuia cererii ineficient deoarece
fiecare instruciune SELECT determin accesarea tabelului. Operatorul ROLLUP
determin rezultatele efectund un singur acces la tabel i este util atunci cnd sunt
implicate multe coloane n producerea subtotalurilor.
Exemplu:
S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre
acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze
valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor
expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din
galeriile avnd codul mai mic dect 50, indiferent de codul autorului.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);
Instruciunea precedent va avea un rezultat de forma:
COD_GALERIE

COD_ARTIST
10
10
10
40
40

50
60
50

SUM(VALOARE)
14000
10000
24000
8080
8080
32080

n rezultatul prezentat anterior se pot distinge 3 tipuri de linii.

1) Prima linie reprezint suma operelor artistului care are codul 50, expuse
n galeria avnd codul 10. n mod similar se interpreteaz a doua i a
patra linie din rezultat.
2) Linia a treia i a cincea din rezultat conin valoarea total a operelor din
galeria al crei cod este 10, respectiv 40. Aceste linii se disting prin faptul
c valoarea coloanei cod_artist este null.
3) Ultima linie conine suma valorilor tuturor operelor din galeriile al cror

cod este 10 sau 40. Valoarea afiat este obinut prin nsumarea valorilor
de pe a treia, respectiv a cincea linie. ntruct aceast linie corespunde
totalului general, ea conine valoarea null pe toate coloanele, cu excepia
cmpului SUM(valoare).
Operatorul CUBE
Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor
combinaiilor posibile ale expresiilor specificate i returneaz cte o linie
totalizatoare pentru fiecare grup. Acest operator este folosit pentru a produce
mulimi de rezultate care sunt utilizate n rapoarte. n vreme ce ROLLUP produce
subtotalurile doar pentru o parte dintre combinaiile posibile, operatorul CUBE
produce subtotaluri pentru toate combinaiile posibile de grupri specificate n
clauza GROUP BY, precum i un total general.
Dac exist n coloane sau expresii n clauza GROUP BY, vor exista 2n
combinaii posibile superagregat. Din punct de vedere matematic, aceste
combinaii formeaz un cub n-dimensional, de aici provenind numele operatorului.
Pentru producerea de subtotaluri fr ajutorul operatorului CUBE ar fi necesare 2n
instruciuni SELECT conectate prin UNION ALL.
Exemplu:
S se afieze valoarea total a operelor de art ale unui autor, expuse n
cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze
valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50,
valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a
operelor din galeriile avnd codul mai mic dect 50.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY CUBE(cod_galerie, cod_artist);
Instruciunea precedent va genera un rezultat de forma urmtoare:
COD_GALERIE

COD_ARTIST
10
10
10
40
40

50
60
50
50
60

SUM(VALOARE)
14000
10000
24000
8080
8080
22080
10000

32080
n plus fa de rezultatul corespunztor operaiei ROLLUP, operatorul CUBE
a produs linii care reprezint suma valorilor operelor pentru fiecare artist care a
expus n galerii avnd codul mai mic dect 50. Aceste linii se disting prin faptul c
valoarea coloanei cod_galerie este null.
Funcia GROUPING
Funcia GROUPING poate fi utilizat alturi de operatorii CUBE i
ROLLUP pentru a arta modul cum a fost obinut o valoare totalizatoare. Aceast
funcie accept un singur argument, care trebuie s fie una dintre expresiile
specificate n clauza GROUP BY.
O valoare null a expresiei din argumentul funciei GROUPING poate
proveni din tabelul de baz (valoare null stocat) sau poate fi o valoare null creat
de operaia ROLLUP sau CUBE ca rezultat al unei funcii grup asupra expresiei
respective.
Funcia GROUPING returneaz valoarea 0 sau 1. Valoarea 0 returnat de
funcia GROUPING pe baza unei expresii poate indica fie c expresia a fost
utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o
valoare null stocat. Valoarea 1 returnat de funcia GROUPING pe baza unei
expresii poate indica fie c expresia nu a fost utilizat pentru calculul valorii
agregat, fie c valoarea null a expresiei este creat de ROLLUP sau CUBE ca
rezultat al gruprii.
Valorile returnate de funcia GROUPING sunt utile pentru:
determinarea nivelului de agregare al unui subtotal dat, adic a grupului
sau grupurilor pe care se bazeaz subtotalul respectiv;
identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat.
Exemplu:
SELECT cod_galerie, cod_artist, SUM(valoare),
GROUPING(cod_galerie), GROUPING(cod_artist)
FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);
SUM
GROUPING
GROUPING
(VALOARE) (COD_GALERIE) (COD_ARTIST)
50
14000
0
0

COD_GALERIE COD_ARTIST
10

10
10
40
40

60
50

10000
24000
8080
8080
32080

0
0
0
0
1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma

valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula
aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist.
Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au
valoarea 0 pentru prima linie din rezultat.
Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10.
Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie,
astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0,
respectiv 1.
Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile
avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist
nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare
expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0.
Clauza GROUPING SETS
GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite
specificarea unor grupri multiple de date. Utilizarea acestei opiuni faciliteaz
analiza datelor n mai multe dimensiuni.
Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure
instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii
ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin
operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este
ineficient ntruct necesit mai multe parcurgeri ale acelorai date.
Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi
de grupri. Au loc urmtoarele echivalene:
CUBE(a, b, c)

GROUPING SETS
((a, b, c), (a, b), (a, c), (b, c), (a),
(b), (c), ())
ROLLUP(a, b,
GROUPING SETS
c)
((a, b, c), (a, b), (a), ())
Exemplu:
Considernd galeriile al cror cod este mai mic dect 50, s se calculeze
media valorilor operelor:

0
1
0
1
1

pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist;

pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie
corespunztori.
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera
WHERE cod_galerie < 50
GROUP BY GROUPING SETS
((cod_galerie, cod_artist),
(cod_artist, TO_CHAR(data_achizitiei, 'yyyy')));
Mulimea rezultat este constituit din valorile medii pentru fiecare dintre
cele dou grupuri i are forma urmtoare:
COD_GALERIE COD_ARTIST
10
50
10
60
40
50
50
50
60
60

an a

2000
2002
2001
2003

Valoare medie
3500
2500
2020
2380
2300
2000
3000

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune

compus:
SELECT cod_galerie, cod_artist, NULL "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY cod_galerie, cod_artist
UNION ALL
SELECT NULL, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare)
FROM opera
GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy');
n absena unui optimizor care analizeaz blocurile de cerere i genereaz
planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz
(opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea

extensiei GROUPING SETS.

Coloane compuse
O coloan compus este o colecie de coloane care sunt tratate unitar n
timpul calculelor asupra grupurilor. Pentru a specifica o coloan compus, aceasta
se include ntre paranteze. n operaia ROLLUP(a, (b, c), d), coloanele b i c
formeaz o coloan compus i sunt tratate unitar.
n general, coloanele compuse sunt utile pentru operaiile ROLLUP, CUBE
i GROUPING SETS. De exemplu, n CUBE sau ROLLUP coloanele compuse pot
determina eliminarea agregrii de pe anumite niveluri.
Clauza GROUP BY ROLLUP(a, (b, c)) este echivalent cu urmtoarea
instruciune compus (n care se precizeaz doar forma clauzelor GROUP BY):
GROUP BY a, b, c UNION ALL
GROUP BY a
UNION ALL
GROUP BY ( )
Astfel, (b, c) sunt tratate unitar i operaia ROLLUP nu va fi efectuat asupra
grupurilor n care coloanele b i c nu apar simultan. Acest lucru este similar
situaiei n care este definit un alias x pentru (b, c), iar specificaia clauzei GROUP
BY este GROUP BY ROLLUP(a, x).
n instruciunea precedent, GROUP BY () reprezint instruciunea SELECT
cu valori null pentru coloanele a i x. Aceast clauz este folosit pentru generarea
totalurilor generale:
SELECT
null, null, coloan_agregat
FROM
nume_tabel
GROUP BY ();
Urmtorul tabel prezint cteva specificaii care utilizeaz operatorii
ROLLUP, CUBE, GROUPING SETS, mpreun cu instruciunile compuse
echivalente acestora:
GROUP BY ROLLUP(a, b, c)

GROUP BY CUBE( (a, b), c)

GROUP BY a, b, c
ALL
GROUP BY a, b
ALL
GROUP BY a
GROUP BY a, b, c
ALL
GROUP BY a, b

UNION
UNION

UNION
UNION

ALL
GROUP BY c UNION ALL
GROUP BY()
GROUP BY GROUPING SETS(a, b, GROUP BY a UNION ALL
c)
GROUP BY b UNION ALL
GROUP BY c
GROUP BY GROUPING SETS
GROUP BY a UNION ALL
(a, b, (b, c) )
GROUP BY b UNION ALL
GROUP BY b, c
GROUP BY GROUPING SETS( (a, b, GROUP BY a, b, c
c) )
GROUP BY GROUPING SETS(a, GROUP BY a UNION ALL
(b), ())
GROUP BY b UNION ALL
GROUP BY ()
GROUP BY GROUPING SETS (a, GROUP BY a UNION ALL
ROLLUP(b, c))
GROUP BY ROLLUP(b, c)
Exemplu:
S se afieze urmtoarele informaii:
valoarea medie a operelor de art din fiecare galerie;
valoarea medie a operelor de art pentru fiecare galerie, iar n cadrul
acesteia pentru fiecare artist i fiecare an de achiziie;
media general a tuturor valorilor operelor de art.
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY ROLLUP
(cod_galerie,
(cod_artist, TO_CHAR(data_achizitiei, 'yyyy')));
Exemplul precedent poate fi rezolvat utiliznd cererea compus prezentat
mai jos. Folosirea coloanelor compuse este recomandat pentru asigurarea unei
execuii eficiente.
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy'),
AVG(valoare) "Valoare medie"
FROM opera

GROUP BY cod_galerie, cod_artist,

TO_CHAR(data_achizitiei, 'yyyy')
UNION ALL
SELECT cod_galerie, TO_NUMBER(null), TO_CHAR(null),
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY cod_galerie
UNION ALL
SELECT TO_NUMBER(null), TO_NUMBER(null), TO_CHAR(null),
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY ();
Concatenarea gruprilor
Concatenarea gruprilor reprezint o modalitate concis de a genera
combinaii de grupri. Acestea se specific prin enumerarea mulimilor de grupri
(grouping sets) i a operaiilor ROLLUP, CUBE separate prin virgul. De exemplu,
expresia GROUP BY GROUPING SETS(a, b), GROUPING SETS(c, d) definete
gruprile (a, c), (a, d), (b, c), (b, d).
Concatenarea mulimilor de grupri este util att pentru uurina dezvoltrii
cererilor, ct i pentru aplicaii. Codul SQL generat de aplicaiile OLAP implic
deseori concatenarea mulimilor de grupri, n care fiecare astfel de mulime
definete gruprile necesare pentru o dimensiune.
Exemplu:
S se determine media valorilor operelor lund n considerare urmtoarele
grupri: (cod_galerie, cod_artist, an_achizitie), (cod_galerie, cod_artist),
(cod_galerie, an_achizitie), (cod_galerie).
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') an_achizitie,
AVG(valoare)
FROM opera
GROUP BY cod_galerie, ROLLUP(cod_artist),
CUBE(TO_CHAR(data_achizitiei, 'yyyy'));
Funcii analitice
Funciile analitice calculeaz o valoare agregat pe baza unui grup de
nregistrri. Ele difer de funciile agregat prin faptul c, pentru fiecare grup, pot fi
returnate mai multe linii rezultat.

Aceste funcii reprezint ultimul set de operaii efectuat la procesarea unei

interogri, naintea clauzei ORDER BY. Din acest motiv, o funcie analitic poate
aprea numai n lista SELECT sau n clauza ORDER BY.
Exemplu:
Pentru fiecare oper de art, s se afle numrul de creaii ale cror valori
sunt cu cel mult 1000 mai mici i cu cel mult 2000 mai mari dect valoarea operei
respective.
SELECT titlu, valoare,
COUNT(*) OVER (ORDER BY valoare
RANGE BETWEEN 1000 PRECEDING
AND 2000 FOLLOWING) AS nr_dom
FROM opera;
Cuvntul cheie OVER indic faptul c funcia opereaz pe mulimea de
rezultate a cererii, adic dup evaluarea celorlalte clauze. Opiunea RANGE
definete, pentru fiecare linie, o fereastr (o mulime de linii). Funcia analitic
va fi aplicat tuturor liniilor din aceast mulime.
2.4.5. Interogri ierarhice
Interogrile ierarhice permit regsirea datelor pe baza unei relaii ierarhice
care exist ntre liniile tabelului. O baz de date relaional nu stocheaz
nregistrrile n mod ierarhic. Dac exist o relaie ierarhic ntre liniile unui tabel,
un proces de parcurgere a unui arbore (tree walking) permite construirea ierarhiei.
O cerere ierarhic este o metod de raportare, n ordine, a ramurilor arborelui.
n tabelul opera, se poate imagina o structur arborescent pe baza valorilor
echivalente ale anilor corespunztori coloanelor data_crearii i data_achizitiei.
Relaia printe-copil a unei structuri arborescente permite controlul
direciei n care este parcurs ierarhia i stabilirea rdcinii ierarhiei.
Clauzele instruciunii SELECT care intervin n formularea unei cereri
ierarhice sunt START WITH i CONNECT BY. Acestea au fost prezentate mpreun
cu instruciunea SELECT, la nceputul acestui capitol.
Pseudocoloana LEVEL poate fi util ntr-o cerere ierarhic. Aceasta
determin lungimea drumului de la rdcin la un nod.
Operatorul PRIOR face referin la linia printe. Plasarea acestui operator
determin direcia interogrii, dinspre printe spre copil (top-down) sau invers
(bottom-up). Traversarea top-down, respectiv bottom-up a arborelui se realizeaz
prin specificri de forma urmtoare:

CONNECT BY PRIOR cheie_parinte = cheie_copil;

CONNECT BY PRIOR cheie_copil = cheie_parinte;
Operatorul PRIOR poate fi plasat n faa oricrui membru al condiiei
specificate n clauza CONNECT BY.
Liniile printe ale interogrii sunt identificate prin clauza START WITH.
Pentru a gsi liniile copil, server-ul evalueaz expresia din dreptul operatorului
PRIOR pentru linia printe, i cealalt expresie pentru fiecare linie a tabelului.
nregistrrile pentru care condiia este adevrat vor fi liniile copil. Spre
deosebire de START WITH, n clauza CONNECT BY nu pot fi utilizate subcereri.
Exemplu:
a) S se afieze codul, titlul, data crerii i data achiziiei operelor, astfel
nct fiecare oper s fie urmat de cele achiziionate n anul crerii sale. Prima
linie afiat va fi cea corespunztoare operei avnd codul 110.
SELECT cod_opera, titlu, data_crearii, data_achizitiei
FROM
opera
START WITH cod_opera = 110
CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =
TO_CHAR(data_achizitiei, 'yyyy');
b) Se cer aceleai informaii ca la punctul a), cu deosebirea c prima linie
afiat va fi cea corespunztoare operei avnd valoarea maxim.
SELECT 'In anul in care a fost creata "'|| titlu ||
' " s-a achizitionat "' ||
PRIOR titlu || '"' "traversare bottom-up "
FROM
opera
START WITH valoare = (SELECT MAX(valoare)
FROM opera)
CONNECT BY PRIOR TO_CHAR(data_achizitiei, 'yyyy') =
TO_CHAR(data_crearii, 'yyyy');
c) S se afieze codul, titlul, data crerii i data achiziiei operelor, astfel
nct fiecare oper s fie urmat de cele achiziionate n anul crerii sale. Se vor
considera doar operele a cror valoare este mai mare dect 7000. Prima linie afiat
va fi cea corespunztoare operei create cel mai recent.
SELECT cod_opera, titlu, data_crearii, data_achizitiei,
valoare
FROM
opera
START WITH data_crearii = (SELECT MAX(data_crearii)
FROM opera)

CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =

TO_CHAR(data_achizitiei, 'yyyy')
AND valoare > 7000;
n clauza CONNECT BY, coloana data_crearii este evaluat pentru linia
printe, iar coloanele data_achizitiei i valoare sunt evaluate pentru linia
copil.
d) S se afieze ierarhia sub forma unui raport, folosindu-se indentri.
Fiecare linie a tabelului va fi considerat drept rdcin.
SELECT LEVEL,
LPAD(titlu, LENGTH(titlu) + (LEVEL * 2) - 2, '_')
succesiune
FROM
opera
CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =
TO_CHAR(data_achizitiei, 'yyyy');
Exemplu:
a) S se afieze codul, titlul, data crerii i data achiziiei operelor de art
expuse n muzeu, astfel nct fiecare oper s fie urmat de cele achiziionate n
anul crerii acesteia. Prima linie afiat va fi cea corespunztoare operei pictorului
Nicolae Grigorescu, achiziionat cel mai recent. Rezultatul nu va conine operele
create n anul 1970, dar va conine operele achiziionate n acest an.
WITH opera_ng AS
(SELECT cod_opera, data_achizitiei
FROM opera
WHERE cod_artist = (SELECT cod_artist
FROM artist
WHERE INITCAP(nume) = 'Grigorescu'
AND INITCAP(prenume) = 'Nicolae'))
SELECT cod_opera, titlu, data_crearii, data_achizitiei
FROM
opera
WHERE
TO_CHAR(data_crearii, 'yyyy') != 1970
START WITH (cod_opera, data_achizitiei) IN
(SELECT cod_opera, data_achizitiei
FROM opera_ng
WHERE data_achizitiei =
(SELECT MAX(data_achizitiei)
FROM opera_ng))
CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =

TO_CHAR(data_achizitiei, 'yyyy');
b) S se afieze informaiile solicitate la punctul a), cu deosebirea c prima
linie listat este cea al crei cod este 110. Se vor elimina din rezultat liniile
corespunztoare operelor create sau achizionate n anul 1970.
SELECT cod_opera, titlu, data_crearii, data_achizitiei
FROM
opera
START WITH cod_opera = 110
CONNECT BY PRIOR TO_CHAR(data_crearii, 'yyyy') =
TO_CHAR(data_achizitiei, 'yyyy')
AND TO_CHAR(data_crearii, 'yyyy') != 1970;

Curs6_IP
Subcereri
De cele mai multe ori, pentru a implementa anumite interogri, nu este
suficient o singur cerere SELECT ci sunt necesare subcereri. Subcererile sunt
comenzi SELECT ncapsulate n oricare din clauzele SELECT, WHERE, HAVING,
FROM.
Dac subcererea urmeaz clauzei WHERE sau HAVING, ea poate conine
unul dintre operatorii ALL, ANY, IN (=ANY), EXIST, NOT IN (!=ALL) care sunt
specifici cererilor care ntorc mai multe linii (multiple-row subquery) sau unul
dintre operatorii de comparare (=, <, >, >=, <=, <>) care sunt specifici cererilor
care ntorc o singur linie (single-row subquery).
Subcererile trebuie incluse ntre paranteze i trebuie plasate n partea dreapt
a operatorului de comparare. Subcererea nu poate conine clauza ORDER BY.
Exemplu:
S se obin numele i salariul angajailor, avnd salariul minim.
SELECT
FROM
WHERE
Exemplu:

ename, sal
emp
sal=(SELECT
FROM

MIN(sal)
emp);

S se obin job-ul pentru care salariul mediu este minim. Sa se afiseze si

salariul mediu.
SELECT
job, AVG(sal)
FROM
emp
GROUP BY job
HAVING AVG(sal)=(SELECT
FROM
GROUP BY

MIN(AVG(sal))
emp
job);

Operatorul ANY presupune c este adevrat condiia dac comparaia este

adevrat pentru cel puin una din valorile returnate. Sunt evidente relaiile:
< ANY mai mic ca maximul;
> ANY mai mare ca minimul;
= ANY IN.
Pentru operatorul ALL se presupune c este adevrat condiia, dac
comparaia este adevrat pentru toate elementele listei returnate. Pentru operatorul
ALL sunt evidente relaiile:
< ALL mai mic ca minimul;
> ALL mai mare ca maximul;
! = ALL NOT IN.
Exemplu:
WHERE codec > ALL (C1, C2) este superior tuturor elementelor din list;
WHERE codec > ANY (C1, C2) este superior cel puin unui element din
list.
Exemplu:
S se obin salariaii al cror salariu este mai mare ca salariile medii din
toate departamentele.
SELECT
FROM
WHERE

ename, job
emp
sal > ALL(SELECT
FROM
GROUP BY

AVG(sal)
emp
deptno);

Exist subcereri care au ca rezultat mai multe coloane (multiple-column

subquery). Aceste interogri au urmtoarea sintax general:
SELECT

col,col,

FROM
WHERE

tabel
(col,col,) IN (SELECT col,col,
FROM
WHERE

tabel
condiie);

Exemplu:
S se obin numele, numrul departamentului, salariul i comisionul tuturor
funcionarilor ale cror salarii i comisioane coincid cu salariile i comisioanele
unor salariai din departamentul 7.
SELECT
FROM
WHERE

ename, deptno, sal, com

emp
(sal,NVL(com,-1)) IN
(SELECT
sal,NVL(com,-1)
FROM
emp
WHERE
deptno = 7);

Rezultatul acestei interogri este diferit de rezultatul urmtoarei interogri:

SELECT
FROM
WHERE

AND

ename, deptno, sal, com

emp
sal IN (SELECT sal
FROM
emp
WHERE
deptno=7)
NVL(com,-1) IN (SELECT NVL(com,-1)
FROM emp
WHERE deptno=7);

Dac una din valorile returnate de subcerere este valoarea null atunci cererea
nu ntoarce nici o linie. Prin urmare, dac valoarea null poate s fac parte din
rezultatul subcererii nu trebuie utilizat operatorul NOT IN. Problema nu mai apare
dac se utilizeaz operatorul IN.

Exemplu:
S se obin salariaii care nu au subordonai.
SELECT
FROM
WHERE

e.ename
emp e
e.empno NOT IN (SELECT m.mgr
FROM emp m);

n acest caz, instruciunea SQL nu ntoarce nici o linie deoarece una din
valorile furnizate de subcerere este valoarea null.

Exemplu:
S se obin numele salariailor, salariile, codul departamentului n care
lucreaz i salariul mediu pe departament pentru toi angajaii care au salariul mai
mare ca media salariilor din departamentul n care lucreaz (folosirea subcererii n
clauza FROM).
SELECT a.ename,a.sal,a.deptno,b.salavg
FROM emp a,(SELECT deptno,avg(sal) salavg
FROM emp
GROUP BY deptno) b
WHERE
a.deptno=b.deptno
AND
a.sal>b.salavg
Exemplu:
S se obin lista celor mai scumpe cri.
SELECT
titlu
FROM
carte
WHERE
pret = (SELECT
FROM carte);

MAX(pret)

Exemplu:
S se obin lista scriitorilor care au n bibliotec un numr de exemplare
mai mare dect numrul mediu al crilor din bibliotec.
SELECT
FROM
WHERE

DISTINCT autor
carte
nrex > (SELECT AVG(nrex)
FROM
carte);

Exemplu:
S se obin informaii despre crile al cror pre depete media preurilor
crilor ce aparin aceluiai domeniu
SELECT
FROM
WHERE

*
carte c
pret > (SELECT AVG(pret)
FROM
carte
WHERE
coded = c.coded);

Exemplu:
S se obin lista cititorilor care au mprumutat cel puin o carte.
SELECT
FROM
WHERE

nume
cititor
codec IN (SELECT DISTINCT codec
FROM imprumuta);

Exemplu:
S se obin codurile cititorilor care nu au mprumutat niciodat cri.
SELECT
FROM
WHERE

codec
cititor
codec NOT IN
(SELECT
DISTINCT codec
FROM imprumuta);

Exemplu:
S se obin lista cititorilor care sunt n ntrziere cu predarea crilor.
SELECT
FROM
WHERE

nume
cititor
codec IN (SELECT
FROM
WHERE
AND

DISTINCT codec
imprumuta
dataef IS NULL
dares<SYSDATE);

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte scris de
ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec IN
(SELECT DISTINCT codec
FROM
imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE autor=ZOLA));

Exemplu:
S se obin numele cititorilor care nu au mprumutat nici o carte scris de
ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec NOT IN
(SELECT DISTINCT codec
FROM imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE autor=ZOLA));

Operatorul IN poate fi nlocuit cu = ANY (un element este n list dac i

numai dac este egal cu un element al listei), iar operatorul NOT IN poate fi
nlocuit prin !=ALL.
Exemplu:
S se obin codurile cititorilor care au mprumutat o carte de algebr.
SELECT
DISTINCT codec
FROM
imprumuta
WHERE
codel IN
(SELECT codel
FROM
carte
WHERE coded=
(SELECT coded
FROM domeniu
WHERE intdom=ALGEBRA));
Exemplu:
S se obin cititorii care au mprumutat numai cri scrise de ZOLA.
SELECT
FROM
WHERE

nume
cititor
codec NOT IN
(SELECT DISTINCT codec
FROM
imprumuta
WHERE codel NOT IN
(SELECT codel
FROM carte
WHERE autor=ZOLA));

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte de
informatic (procedural).
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT DISTINCT codec
FROM
imprumuta
WHERE codel IN
(SELECT codel
FROM
carte
WHERE coded=
(SELECT coded

FROM domeniu
WHERE intdom= INFORMATICA)));
Exemplu:
S se obin numele cititorilor i titlurile crilor de informatic mprumutate
de aceti cititori (relational).
SELECT
FROM
WHERE
AND
AND
AND

nume, titlu
cititor, carte, imprumuta, domeniu
imprumuta.codel = carte.codel
carte.coded = domeniu.coded
imprumuta.codec = cititor.codec
intdom = INFORMATICA;

Subcererile pot fi executate corelat (cu sincronizare) sau ncuibrit (fr

sincronizare).
Subcererile fr sincronizare sunt caracterizate de faptul c se execut
cererea cea mai interioar care ntoarce un rezultat ce este transmis cererii de nivel
superior, care ntoarce un rezultat s.a.m.d.
Subcererile cu sincronizare sunt caracterizate de faptul c evaluarea
subcererii face referin la o coloan a cererii principale, iar evaluarea cererii
interioare se face pentru fiecare linie a cererii (principale) care o conine.
Exemplu:
S se obin, utiliznd sincronizarea subcererii cu cererea principal, titlurile
crilor care au toate exemplarele mprumutate (se selecteaz un titlu din carte i
pentru acest titlu se numr cte exemplare sunt mprumutate).
SELECT
FROM
WHERE

titlu
carte
nrex=(SELECT
FROM
WHERE
AND

COUNT(*)
imprumuta
codel = carte.codel
dataef IS NULL);

Exemplu:
S se obin codurile cititorilor i codul ultimei cri mprumutate.
SELECT
FROM
WHERE

codec, codel
imprumuta i
dataim>=ALL (SELECT dataim
FROM
imprumuta
WHERE codec=i.codec);

Pentru aceast interogare, clauza WHERE putea fi scris i sub forma:

WHERE

dataim=(SELECT MAX(dataim)
FROM
imprumuta
WHERE
codec=i.codec);

Exemplu:
S se obin lista codurilor crilor mprumutate i codul primului cititor care
a mprumutat aceste crti.
SELECT
FROM
WHERE

codel,codec
imprumuta i
dataim<=ALL (SELECT dataim
FROM imprumuta
WHERE i.codel=codel);

Exemplu:
S se obin codurile crilor din care cel puin un exemplar este mprumutat.
SELECT
FROM
WHERE

codel
carte
EXISTS
(SELECT
FROM
WHERE
AND

codel
imprumuta
codel = carte.codel
dataef IS NULL);

Operatorul WHERE EXISTS (subcerere) presupune c predicatul este

adevrat dac subcererea ntoarce cel puin un tuplu, iar WHERE NOT EXISTS
(subcerere) presupune c predicatul este adevrat dac subcererea nu ntoarce nici
un tuplu. EXISTS i NOT EXISTS cer sincronizarea subcererii.
Exemplu:
S se obin titlurile crilor care sunt momentan mprumutate.
Soluia 1 (cu sincronizare):
SELECT
titlu
FROM
carte
WHERE
EXISTS
(SELECT *
FROM
WHERE
AND
Soluia 2 (fr sincronizare):

imprumuta
codel = carte.codel
dataef IS NULL);

SELECT
FROM
WHERE

titlu
carte
codel IN
(SELECT DISTINCT codel
FROM
imprumuta
WHERE
dataef IS NULL);

Exemplu:
S se obin codurile crilor care nu au fost mprumutate niciodat.
Soluia 1 (cu sincronizare)
SELECT
codel
FROM
carte
WHERE
NOT EXISTS
(SELECT
FROM
WHERE

codel
imprumuta
codel = carte.codel);

Soluia 2 (fr sincronizare)

SELECT
FROM
WHERE

codel
carte
codel NOT IN
(SELECT DISTINCT codel
FROM imprumuta);

Exemplu:
S se obin lista salariailor avnd salariul minim n departamentul n care
lucreaz.
SELECT
FROM
WHERE

ename,sal
emp e
sal=(SELECT
FROM
WHERE

MIN(sal)
emp
deptno=e.deptno);

Exemplu:
S se obin numele primilor trei salariai avnd retribuia maxim (ideea
rezolvrii este de a verifica dac numrul salariailor care au leafa mai mare dect
leafa salariatului considerat, este mai mic dect 3).
SELECT
FROM
WHERE

ename
emp a
3>(SELECT COUNT(*)
FROM
emp

WHERE

sal > a.sal);

Exemplu:
S se obin numele cititorilor care au mprumutat cel puin aceleai cri ca
i cititorul avnd codul C19 (ideea problemei este de a selecta cititorii pentru care
este vid lista crilor mprumutatede C19 mai puin lista crilor mprumutate de
acei cititori).
SELECT
nume
FROM
cititor
WHERE
NOT EXISTS
(SELECT codel
FROM imprumuta
WHERE codec=C19
MINUS
SELECT codel
FROM imprumuta
WHERE codec= cititor.codec);
Dac problema era modificat n sensul c cel puineste nlocuit prin cel
mult atunci trebuiau inversate interogrile legate prin MINUS.

Exemplu:
S se obin codurile cititorilor care au mprumutat aceleai cri ca i
cititorul avnd un cod specificat.
Rezolvarea problemei se bazeaz pe ideea: A = B A B i B A (AB) = i (B-A) = A-B i B-A nu furnizeaz nici un tuplu rezultat.
SELECT
codec
FROM
imprumuta i
WHERE
NOT EXISTS
(SELECT codel
FROM
imprumuta
WHERE codec=i.codec
MINUS
SELECT codel
FROM
imprumuta
WHERE codec=&ccc)
AND
NOT EXISTS
(SELECT codel
FROM
imprumuta
WHERE codec=&ccc

AND

MINUS
SELECT codel
FROM
imprumuta
WHERE codec=i.codec)
codec!=&ccc);

Ultimul operator (AND), asigur s nu apar n rezultat cititorul specificat.

n cazul formei relaionale de rezolvare a cererii, drumul de acces la
informaie este n sarcina SGBD-lui i prin urmare nu mai apar cereri imbricate.
Exemplu:
S se obin numele cititorilor care au mprumutat cel puin o carte.
Soluia 1 (forma relaional):
SELECT
DISTINCT nume
FROM
cititor,imprumuta
WHERE
cititor.codec=imprumuta.codec;
Soluia 2 (forma procedural):
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT DISTINCT codec
FROM
imprumuta);
Exemplu:
S se obin numele cititorilor care au mprumutat cel puin dou cri.
Soluia 1 (forma relaional):
SELECT
nume
FROM
cititor, imprumuta
WHERE
cititor.codec=imprumuta.codec
GROUP BY nume
HAVING COUNT(*)>1;
Soluia 2 (forma procedural):
SELECT
nume
FROM
cititor
WHERE
codec IN
(SELECT codec
FROM
imprumuta
GROUP BY codec
HAVING COUNT(*)>1);
Exemplu:
S se afieze numele, prenumele, salariul lucrtorilor, codurile publicaiilor
la care lucreaz i salariul mediu pe publicaie pentru toi angajaii care au salariul
mai mare dect media salariului pe publicaia respectiv.

SELECT

s.nume, s.prenume, s.salariu,

p.nr_publicatie, a.salariu_mediu
FROM
salariat s, publicatie p,
(SELECT p1.nr_publicatie,AVG(salariu) salariu_mediu
FROM publicatie p1, salariat s1
WHERE p1.cod_salariat = s1.cod_salariat
GROUP BY p1.nr_publicatie) a
WHERE
p.nr_publicatie = a.nr_publicatie
AND
s.cod_salariat = p.cod_salariat
AND
s.salariu > a.salariu_mediu;
Exemplu:
S se obin numele salariailor care nu cunosc nici o limb strin.
SELECT nume, prenume
FROM
salariat
WHERE
NOT EXISTS
(SELECT *
FROM limba
WHERE limba.cod_salariat = salariat.cod_salariat
AND limba_cun IS NOT NULL);
Exemplu:
S se afieze graficienii care au ntrziat s predea frame-urile.
a) cu sincronizare:
SELECT nume, prenume
FROM
salariat
WHERE
EXISTS
(SELECT *
FROM
realizeaza r
WHERE
salariat.cod_salariat=r.cod_salariat
AND
data_lim < SYSDATE);
b) fr sincronizare:
SELECT nume, prenume
FROM
salariat
WHERE
cod_salariat IN
(SELECT DISTINCT cod_salariat
FROM
realizeaza
WHERE data_lim < SYSDATE);
Exemplu:

S se determine revistele coordonate de redactori efi care nu cunosc limba

n care sunt scrise. Se tie c n urma inspectrii vizuale a rezultatului interogrii se
poate decide schimbarea redactorilor efi ai revistelor respective, de aceea se
dorete blocarea nregistrrilor gsite.
SELECT p.nr_publicatie
FROM
salariat s, publicatie p
WHERE
s.cod_salariat = p.cod_salariat
AND
p.limba NOT IN
(SELECT limba_cun
FROM
limba
WHERE limba.cod_salariat = s.cod_salariat)
FOR UPDATE OF p.cod_salariat;
Clauza WITH
Cu ajutorul clauzei WITH se poate defini un bloc de cerere nainte ca acesta
s fie utilizat ntr-o interogare. Clauza permite reutilizarea aceluiai bloc de cerere
ntr-o instruciune SELECT complex.
Utiliznd clauza WITH, s se scrie o cerere care afieaz numele artitilor i
valoarea total a operelor acestora. Se vor considera artitii a cror valoare total a
operelor este mai mare dect media valorilor operelor tuturor artitilor.
WITH
val_artist AS (SELECT nume, SUM(valoare) AS total
FROM opera o, artist a
WHERE o.cod_artist = a.cod_artist
GROUP BY nume),
val_medie AS (SELECT SUM(total)/COUNT(*) AS medie
FROM val_artist)
SELECT *
FROM val_artist
WHERE total > (SELECT medie
FROM val_medie)
ORDER BY nume;
Subcereri scalare
Subcererile scalare n SQL returneaz valoarea unei singure coloane
corespunztoare unei linii. Dac subcererea returneaz 0 linii, valoarea subcererii
scalare este null. Dac subcererea returneaz mai mult de o linie, server-ul
genereaz o eroare.
Subcererile scalare erau acceptate n Oracle8i doar n anumite cazuri, cum ar
fi clauzele FROM i WHERE ale instruciunii SELECT sau clauza VALUES a
instruciunii INSERT. Utilitatea subcererilor scalare a fost extins n Oracle9i.

Astfel, ele pot aprea n:

condiiile i expresiile care fac parte din DECODE sau CASE;
toate clauzele instruciunii SELECT, cu excepia lui GROUP BY;
n partea stng a operatorului, n clauzele SET i WHERE ale
instruciunii UPDATE.
Exemplu:
S se afieze codul, titlul operelor i numele artistului doar dac acesta este
Brncui. n caz contrar, se va afia irul alt artist.
SELECT cod_opera, titlu,
(CASE WHEN cod_artist =
(SELECT cod_artist
FROM artist
WHERE nume = 'Brancusi')
THEN 'Brancusi'
ELSE 'Alt artist' END) artist
FROM opera;
Operatorul ROLLUP
Operatorul ROLLUP produce o mulime care conine liniile obinute n urma
gruprii obinuite i linii pentru subtotaluri. Acest operator furnizeaz valori
agregat i superagregat corespunztoare expresiilor din clauza GROUP BY.
Operatorul ROLLUP creeaz grupri prin deplasarea ntr-o singur direcie,
de la dreapta la stnga, de-a lungul listei de coloane specificate n clauza GROUP
BY. Apoi, se aplic funcia agregat acestor grupri. Dac sunt specificate n expresii
n operatorul ROLLUP, numrul de grupri generate va fi n + 1. Liniile care se
bazeaz pe valoarea primelor n expresii se numesc linii obinuite, iar celelalte se
numesc linii superagregat.
Daca in clauza GROUP BY sunt specificate n coloane, atunci pentru a
produce subtotaluri in n dimensiuni ar fi necesare n+1 operatii SELECT legate prin
UNION ALL. Aceasta ar fi total ineficient, deoarece fiecare SELECT ar implica o
parcurgere a tabelului. Operatorul ROLLUP are nevoie de o singura parcurgere a
tabelului.
Exemplu:
S se afieze codurile de galerii mai mici dect 50, iar pentru fiecare dintre
acestea i pentru fiecare autor care are opere expuse n galerie, s se listeze
valoarea total a lucrrilor sale. De asemenea, se cere valoarea total a operelor
expuse n fiecare galerie. Rezultatul va conine i valoarea total a operelor din
galeriile avnd codul mai mic dect 50, indiferent de codul autorului.

SELECT cod_galerie, cod_artist, SUM(valoare)

FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);
Instruciunea precedent va avea un rezultat de forma:
COD_GALERIE COD_ARTIST SUM(VALOARE)
10
50
14000
10
60
10000
10
24000
40
50
8080
40
8080
32080

Operatorul CUBE
Operatorul CUBE grupeaz liniile selectate pe baza valorilor tuturor
combinaiilor posibile ale expresiilor specificate i returneaz cte o linie
totalizatoare pentru fiecare grup. El produce subtotaluri pentru toate combinaiile
posibile de grupri specificate n GROUP BY, precum i un total general.
Daca exista n coloane sau expresii in clauza GROUP BY, vor exista 2 n
combinatii posibile superagregat. Matematic, aceste combinatii formeaza un cub
n-dimensional.
Pentru producerea de subtotaluri fara ajutorul operatorului CUBE ar fi
necesare 2 n instructiuni SELECT legate prin UNION ALL.
Exemplu:
S se afieze valoarea total a operelor de art ale unui autor, expuse n
cadrul fiecrei galerii avnd codul mai mic dect 50. De asemenea, s se afieze
valoarea total a operelor din fiecare galerie avnd codul mai mic dect 50,
valoarea total a operelor fiecrui autor indiferent de galerie i valoarea total a
operelor din galeriile avnd codul mai mic dect 50.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY CUBE(cod_galerie, cod_artist);
COD_GALERIE COD_ARTIST SUM(VALOARE)

10
10
10
40
40

50
60
50
50
60

14000
10000
24000
8080
8080
22080
10000
32080

Funcia GROUPING
Aceasta funcie este util pentru:
determinarea nivelului de agregare al unui subtotal dat, adic a grupului
sau grupurilor pe care se bazeaz subtotalul respectiv;
identificarea provenienei unei valori null a unei expresii calculate, dintruna din liniile mulimii rezultat.
Functia returneaz valoarea 0 sau 1. Valoarea 0 poate indica fie c expresia a
fost utilizat pentru calculul valorii agregat, fie c valoarea null a expresiei este o
valoare null stocat.
Valoarea 1 poate indica fie c expresia nu a fost utilizat pentru calculul
valorii agregat, fie c valoarea null a expresiei este o valoare creat de ROLLUP
sau CUBE ca rezultat al gruprii.
Exemplu:
SELECT cod_galerie, cod_artist, SUM(valoare),
GROUPING(cod_galerie), GROUPING(cod_artist)
FROM opera
WHERE cod_galerie < 50
GROUP BY ROLLUP(cod_galerie, cod_artist);

SUM
GROUPING
GROUPING
(VALOARE) (COD_GALERIE) (COD_ARTIST)
50
14000
0
0
60
10000
0
0
24000
0
1

COD_GALERIE COD_ARTIST
10
10
10

40
40

50

8080
8080
32080

0
0
1

Pe prima linie din acest rezultat, valoarea totalizatoare reprezint suma

valorilor operelor artistului avnd codul 50, n cadrul galeriei 10. Pentru a calcula
aceast valoare au fost luate n considerare coloanele cod_galerie i cod_artist.
Prin urmare, expresiile GROUPING(cod_galerie) i GROUPING(cod_artist) au
valoarea 0 pentru prima linie din rezultat.
Pe linia a treia se afl valoarea total a operelor din galeria avnd codul 10.
Aceast valoare a fost calculat lund n considerare doar coloana cod_galerie,
astfel nct GROUPING (cod_galerie) i GROUPING(cod_artist) au valorile 0,
respectiv 1.
Pe ultima linie din rezultat se afl valoarea total a operelor din galeriile
avnd codul mai mic dect 50. Nici una dintre coloanele cod_galerie i cod_artist
nu au intervenit n calculul acestui total, prin urmare valorile corespunztoare
expresiilor GROUPING(cod_galerie) i GROUPING(cod_artist) sunt 0.
Clauza GROUPING SETS
GROUPING SETS reprezint o extensie a clauzei GROUP BY care permite
specificarea unor grupri multiple de date.
Aceast extensie, aprut n sistemul Oracle9i, permite scrierea unei singure
instruciuni SELECT pentru a specifica grupri diferite (care pot conine operatorii
ROLLUP i CUBE), n loc de mai multe instruciuni SELECT combinate prin
operatorul UNION ALL. De altfel, reuniunea rezultatelor mai multor cereri este
ineficient ntruct necesit mai multe parcurgeri ale acelorai date.
Operatorii ROLLUP i CUBE pot fi considerai cazuri particulare de mulimi
de grupri. Au loc urmtoarele echivalene:
CUBE(a, b, c)

GROUPING SETS
((a, b, c), (a, b), (a, c), (b, c), (a), (b), (c),
())
ROLLUP(a, b,
GROUPING SETS
c)
((a, b, c), (a, b), (a), ())
Exemplu:
Considernd galeriile al cror cod este mai mic dect 50, s se calculeze

0
1
1

media valorilor operelor:

pentru fiecare galerie i, n cadrul acesteia, pentru fiecare artist;
pentru fiecare artist i, n cadrul acestuia, pentru anii de achiziie
corespunztori.
SELECT cod_galerie, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy') "an achizitie",
AVG(valoare) "Valoare medie"
FROM opera WHERE cod_galerie < 50
GROUP BY GROUPING SETS
((cod_galerie, cod_artist),
(cod_artist, TO_CHAR(data_achizitiei, 'yyyy')));
Mulimea rezultat este constituit din valorile medii pentru fiecare dintre
cele dou grupuri ((cod_galerie, cod_artist) si (cod_artist, an_achizitie)) i are
forma urmtoare:
COD_GALERIE COD_ARTIST
10
50
10
60
40
50
50
50
60
60

An achizitie

2000
2002
2001
2003

Valoare medie
3500
2500
2020
2380
2300
2000
3000

Exemplul precedent poate fi rezolvat i prin urmtoarea instruciune

compus:
SELECT cod_galerie, cod_artist, NULL "An achizitie",
AVG(valoare) "Valoare medie"
FROM opera
GROUP BY cod_galerie, cod_artist
UNION ALL
SELECT NULL, cod_artist,
TO_CHAR(data_achizitiei, 'yyyy'), AVG(valoare)
FROM opera
GROUP BY cod_artist, TO_CHAR(data_achizitiei, 'yyyy');
n absena unui optimizor care analizeaz blocurile de cerere i genereaz
planul de execuie, cererea precedent va parcurge de dou ori tabelul de baz

(opera), ceea ce poate fi ineficient. Din acest motiv, este recomandat utilizarea
extensiei GROUPING SETS.

Limbajul de manipulare a datelor DML

n aceast curs se prezint instruciunile DML (Data Manipulation
Language), o parte a limbajului SQL folosit pentru intreinerea datelor stocate n
tabele relaionale ale bazei de date.
Limbajul DML este format din trei comenzi SQL:
INSERT
UPDATE
DELETE

Adaug noi rnduri ntr-un table al bazei de date.

Actualizeaza rndurile existente intr-un table al bazei de date.
Sterge rnduri dintr-un tabel al bazei de date

Instruciunile DML individuale afecteaz datele dintr-un singur tabel. Este

posibil ca ntr-o instruciune DML s referii i o vizualizare care conine date din
mai multe tabele (adic o vizualizare care conine o uniune de tabele), dar, n acest
caz, instruciunea DML poate referi numai coloane dintr-un singur tabel al
vizualizrii. Cu alte cuvinte, atunci cand o instruciune DML folosete o
vizualizare, toate coloanele vizualizrii referite n instruciunea DML trebuie s
corespund unor coloane dintr-un singur tabel fizic al bazei de date.
Sistemul SGBD nu va efectua n baza de date nici o modificare care ncalc
una din restricii.
La formarea instructiunilor DML, trebuie s se in seama de urmatoarele
aspecte referitoare la restriciile tabelului modificat:
Restricii de tip cheie primar
Atunci cnd inserai un nou rnd ntr-un tabel, cheia primar a noului rnd
trebuie sa fie unic n ntregul tabel.Cand modificati valoarea unei chei primare
(ceea ce se intampla rareori), noua valoare trebuie s fie unic n ntregul tabel.
Restricii de unicitate
Ca i n cazul cheilor primare, coloanele pe care a fost definit o restricie de
unicitate trebuie sa aib valori unice n ntregul tabel.
Restricii NOT NULL
O valoare nula (null) este o modalitate special prin care sistemul SGBD
trateaz valoarea unei coloane pentru a indica faptul ca valoarea coloanei
respective nu este cunoscut. O valoare nula nu este acelasi lucru un un spatiu

liber, un sir vid sau valoarea zero este o valoare speciala care nu este egala cu
nimic altceva.
n cazul instruciunilor INSERT, trebuie specificate valori pentru toate
coloanele cu restricii NOT NULL.
n cazul instruciunilor UPDATE nu se pot inlocui valorile unei coloane cu
valori nule dac pe coloana respectiv este definit p restricie NOT NULL.
Dac instruciunea DML refer o vizualizare , nu se poate sa o folosim intro instruciune INSERT dac una dintre coloanele tabelului cu o restricie NOT
NULL(obligatorii) lipsete din definirea vizualizrii.
Restricii refereniale
Nu se poate insera sau actualiza valoarea unei chei externe dect dac exist
deja rndul printe corespondent care conine valoarea cheii n coloana cheii
primare. In sens invers, nu se poate terge un rnd printe dac exist rnduri
subordonate care refer valoarea din rndul printe, dect dac restricia a fost
definit cu opiunea ON DELETE CASCADE. In general inserrile n tabele
trebuie fcute ierarhic (mai intai randurile parinte, apoi randurile copii), iar
tergerile trebuie fcute n ordine invers (copiii inaintea prinilor).
Restrictii de verificare (CHECK) O instructiune INSERT sau UPDATE
nu poate stoca ntr-o coloana o valoare care ncalc o restricie CHECK definit
pentru coloana respectiv.

Instruciunea INSERT
Instruciunea INSERT este folosit pentru inserarea noilor rnduri de date n
tabele sau tabele de baz al unei vizualizri. Instruciunea are dou forme de baz:
una n care valorile coloanelor sunt specificate chiar n instruciune i alta n care
valorile sunt selectate dintr-un tabel sau o vizualizare, folosind o subinterogare.
Inserarea unui singur rand de date folosind clauza Values
Instruciunea INSERT care folosete o clauz VALUES poate crea un
singur rnd la fiecare rulare, deoarece valorile pentru rndul de date respective sunt
specificate chiar n instruciune.

Sintaxa general a instruciunii este urmtoarea:

INSERT INTO nume_tabel_sau_vizualizare
[(lista_de_coloane)]
VALUES (lista_de_valori);
Sau
INSERT INTO nume_tabel / nume_view [(col1[, col2[,]])]
VALUES (expresia1[, expresia2[,]]) / subcerere;
expresia1, expresia2, reprezint expresii a cror evaluare este atribuit
coloanelor precizate (se insereaz o linie);
subcerere, reprezint o interogare (se insereaz una sau mai multe
linii).

Clauza VALUES specific valorile ce vor fi introduse n tabel sau

vizualizare. Pentru a insera mai multe linii prin aceeai instruciune INSERT, n
locul acestei clauze se va preciza o subcerere.
Exemple pentru baza de date FILM
Diagrama ERD a bazei de date FILM(prezentare parial)

FILM
FILM_ID <pk>
MPAA_RATING
MPAA_COD_RATING <pk>
MPAA_DESCRIERE_RATING

FILM_COD_GEN <fk1>
MPAA_COD_RATING <fk2>
FILM_NUME
RETAIL_PRET_VHS
RETAIL_PRET_DVD
AN_PRODUS

FILM_COPII
FILM_ID <pk, fk>>
NUMAR_COPIE <pk>
DATA_CUMPARARE
DATA_VANZARE
FORMAT_MEDIA

FILM_GEN
FILM_COD_GEN <pk>
FILM_DESCRIERE_GEN

Se poate remarc urmtoarele:

Lista de coloane este opional, dar dac este inclus trebuie s fie
ncadrat n paranteze rotunde.
Dac lista de coloane este omis, trebuie specificat o valoare pentru
fiecare coloan din tabel, n ordinea n care sunt definite coloanele n tabel. Este
bine ca ntotdeauna s includei lista de coloane, deoarece omiterea acesteia face ca
instruciunea INSERT s fie dependent de definiia tabelului. Dac o coloan este
modificat sau n tabel este adugat o nou coloan, chiar i opional, probabil
instruciunea INSERT va eua la urmtoarea rulare.
Dac lista de coloane este specificat, lista de valori trebuie s conin
o valoare pentru fiecare coloan din list, n aceeai ordine. Cu alte cuvinte, ntre
lista de coloane i lista de valori trbuie s existe o corespondena unu-la-unu. Orice
coloana care lipsete din list va primi o valoare nul, presupunund c valorile nule
sunt acceptate n coloana respectiv.
n clauza VALUES, valorile de tip caracter i dat calendaristic
trebuie incluse ntre apostrofuri. Nu se recomand includerea ntre apostrofuri a
valorilor numerice, ntruct aceasta ar determina conversii implicite la tipul
NUMBER.
Pentru introducerea de valori speciale n tabel, pot fi utilizate funcii.
Adugarea unei linii care va conine valori null se poate realiza n
mod:
- implicit, prin omiterea numelui coloanei din lista de coloane;
- explicit, prin specificarea n lista de valori a cuvntului cheie null
sau a irului vid n cazul irurilor de caractere sau datelor
calendaristice.
Exemplul urmtor conine dou instruciuni INSERT, una care creeaz un
nou rnd n tabelul FILM, cu o list opional de coloane, din care este omis
coloana RETAIL_PRET_VHS, i alta care creeaz un rnd n tabelul FILM_COPII
pentru acelai tip, dar fr lista opional de coloane.
INSERT INTO FILM
(FILM_ID, FILM_COD_GEN, MPAA_RATING_COD, FILM_NUME,
PRET_INCHIRIAT_DVD, AN_PRODUCERE)
VALUES (21,Drama,PG-13,Ray, 29.95, 2004);
INSERT INTO FILM_COPII
VALUES (21, 1, 2005-04-01, NULL, V);

Exemplu baza galeria de arta

GALERIE
cod_galerie#

inclusa_in

M(1)

SALA
cod_sala#
cod_galerie#

1
cuprinsa_in

M(1)
1

ARTIST
cod_artist#

creata_de

M(1)

OPERA
cod_opera#

SECURITATE
cod_opera#
sistem#
1

protejata_prin

asigurata_de

M(0)

M(0)

POLITA_ASIG
cod_polita#

M(1)
M(1)

M(1)

mentionata_in

studiaza

M(0)
M(0)

SURSA_BIBLIO
cod_sursa#
tip

ARTICOL

CARTE

M(1)
editata_de

M(1)

AUTOR
cod_autor#

SPECIALIST
cod_specialist#

figureaza_in

M(0)

EXPOZITIE
cod_expo#

M(1)

organizata_de

M(1)

ORGANIZATOR
cod_organizator#

S se adauge prin metoda explicit, respectiv prin metoda implicit, dou

nregistrri n tabelul artist, preciznd numai codul, numele i prenumele artistului.
ARTIST(cod_artist#, nume, prenume, an_nastere, an_moarte,
nationalitate, observatii);
INSERT INTO artist
(cod_artist, nume, prenume)
VALUES (50, 'Grigorescu', 'Nicolae');
INSERT INTO artist
VALUES (70, 'Andreescu', 'Ion', NULL, NULL, NULL, NULL);
n galeria creat anterior i care a fost achiziionat la 20 ianuarie 2009.
Exemplu:
Urmtoarea instruciune va genera eroarea ORA-01400: cannot insert
NULL into , ntruct se ncearc inserarea unei linii n tabelul opera fr a
preciza valoarea cheii primare.
INSERT INTO opera
(titlu, data_achizitiei)
VALUES ('Flori de camp', SYSDATE);
Exemplu BD CARTE
S se insereze n tabelul carte toate crile din tabelul carte_info,
presupunnd c tabelul carte_info a fost deja creat. De asemenea, s se introduc o
nou carte creia i se cunoate codul (c34), titlul (algebra) i preul (500).
INSERT INTO carte
(codel, titlu, autor, nrex, pret, coded)
VALUES
(c34,algebra, null, null, 50, null);
Exemplu:
INSERT INTO carte
(codel, nrex)
VALUES ('c25', 25);

inserare prin parametrizare

INSERT INTO domeniu
VALUES ('&cod', '&dendom'); inserare prin parametrizare
Inserri masive folosind instruciunea SELECT intern
Aa cum se observ, este nevoie de foarte mult cod pentru a insera n tabel
un singur rnd de date folosind o instruciune INSERT cu clauza VALUES.
O alt soluie, care poate fi folosit pentru a insera rnduri multiple ntr-un
tabel , este forma care folosete o instruciune SELECT intern. Aceast form este
util i pentru stabilirea urmtoarei valori disponibile pentru o cheie primar cu
valori secveniale. De asemenea , poate fi folosit atunci cnd creai un tabel
temporar pentru testare i vrei s-l populai cu toate datele dintr-un alt tabel.
Sintaxa general a instruciunii este
INSERT INTO nume_tabel_sau_vizualizare
[(lista_de_coloane)]
SELECT instructiune_select;
Se remarc urmtoarele:
Lista de coloane este opional, dar dac este inclus trebuie s fie ncadrat
n paranteze.
Dac lista de coloane este omis, instruciune SELECT intern trebuie s
furnizeze o valoare pentru fiecare coloan din tabel, n ordinea n care sunt definite
coloanele n tabel. Este bine ca ntotdeauna s includei lista de coloane, deoarece
omiterea acesteia face ca instruciunea INSERT s fie dependent de definiia
tabelului. Dac o coloan este modificat sau n tabel este adugat o nou
coloan, chiar i opional, probabil instruciunea INSERT va eua la urmtoarea
rulare.
Dac lista de coloane este specificat, instruciune SELECT intern s
furnizeze o valoare pentru fiecare coloan din lista de valori, n aceeai ordine. Cu
alte cuvinte, ntre lista de coloane i setul de rezultate al instruciunii SELECT
trebuie s existe o corespondena unu-la-unu. Orice coloan care lipsete din list
va primi o valoare nul, presupunund c valorile nule sunt acceptate n coloana
respectiv.
Cuvntul cheie NULL poate fi folosit n instruciunea SELECT pentru
specificarea unei valori nule pentru o coloan.

Ca exemplu, s presupunem c toate filmele sunt acum disponibile i n

limba francez. Tabelul FILM_LIMBA conine rnduri pentru limba francez
pentru o parte din filme, aa c acum vrem s le adugm numai pe cele care
lipsesc. Instruciunea INSERT care va rezolva aceast problem este:
INSERT INTO FILM_LIMBA
(FILM_ID, COD_LIMBA)
SELECT FILM_ID, fr
FROM FILM
WHERE FILM_ID NOT IN
( SELECT FILM_ID FROM FILM_LIMBA
WHERE COD_LIMBA =fr );

INSERT INTO carte

SELECT
*
FROM
carte_info;
Exemplu:
Presupunnd c tabelul salariat a fost completat cu datele tuturor
salariailor editurii, s se completeze tabelele grafician, tehnoredactor i
redactor_sef, n concordan cu datele coninute n tabelul salariat (nu pot exista
graficieni, tehnoredactori sau redactori efi care s nu fie salariai!).
INSERT
INTO grafician (cod_salariat)
SELECT cod_salariat
FROM
salariat
WHERE
job = grafician;
INSERT
SELECT
FROM
WHERE

INTO tehnoredactor (cod_salariat)

cod_salariat
salariat
job = tehnoredactor;

INSERT
SELECT
FROM
WHERE

INTO redactor_sef (cod_salariat)

cod_salariat
salariat
job = redactor_sef;

NU Inserri multitabel
O inserare multitabel presupune introducerea de linii calculate pe baza
rezultatelor unei subcereri, n unul sau mai multe tabele. Acest tip de inserare,
introdus de Oracle9i, este util n mediul data warehouse. Astfel, datele extrase
dintr-un sistem surs, pot fi transformate utiliznd instruciuni INSERT multitabel,
spre a fi ncrcate n obiectele bazei de date.
Pentru o astfel de inserare, n versiunile anterioare lui Oracle9i erau
necesare n operaii independente INSERT INTOSELECT, unde n reprezint
numrul tabelelor destinaie. Aceasta presupunea n procesri ale aceleiai surse de
date i, prin urmare, creterea de n ori a timpului necesar procesului.
Sintaxa clauzei inserare_multi_tabel este urmtoarea:
{ALL INTO[VALUES] [INTO[VALUES] ]
| inserare_condiionat} subcerere
Clauza inserare_condiionat are forma urmtoare:
[ALL | FIRST]
WHEN condiie THEN INTO[VALUES]
[INTO[VALUES] ]
[WHEN condiie THEN INTO[VALUES]
[INTO[VALUES] ] ]
[ELSE INTO[VALUES]
[INTO[VALUES] ] ]
Pentru a efectua o inserare multitabel necondiionat, sistemul va executa
cte o instruciune INSERTINTO pentru fiecare linie returnat de subcerere.
Utiliznd clauza inserare_condiionat, decizia inserrii unei linii depinde
de condiia specificat prin intermediul opiunii WHEN. Expresiile prezente n
aceste condiii trebuie s fac referin la coloane returnate de subcerere. O
instruciune de inserare multitabel poate conine maxim 127 clauze WHEN.
Specificarea opiunii ALL determin evaluarea tuturor condiiilor din
clauzele WHEN. Pentru cele a cror valoare este TRUE, se insereaz nregistrarea
specificat n opiunea INTO corespunztoare.
Opiunea FIRST determin inserarea corespunztoare primei clauze WHEN a
crei condiie este evaluat TRUE. Toate celelalte clauze WHEN sunt ignorate.
Dac nici o condiie din clauzele WHEN nu este TRUE, atunci sistemul
execut clauza INTO corespunztoare opiunii ELSE, iar dac aceasta nu exist, nu
efectueaz nici o aciune.
Inserrile multitabel pot fi efectuate numai asupra tabelelor, nu i asupra
vizualizrilor sau vizualizrilor materializate. De asemenea, acest tip de inserare nu
se poate efectua asupra tabelelor distante. Subcererea dintr-o instruciune

corespunztoare unei inserri multitabel nu poate utiliza o secven.

Exemplu:
Se presupune c licitaiile pentru achiziionarea operelor de art au loc
numai n zilele de miercuri. Fie tabelul opera_intrare (data_inceput, sapt_1,
sapt_2, sapt_3, sapt_4), n care data_inceput reprezint data primei zile de
miercuri din lun, iar sapt_i furnizeaz valoarea operelor achiziionate n
sptmna respectiv. Considernd c n fiecare sptmn se achiziioneaz o
singur lucrare, s se insereze liniile corespunztoare n tabelul opera.
INSERT ALL
INTO opera (cod_opera, valoare, data_achizitiei)
VALUES (secv_cod_opera.NEXT_VALUE, sapt_1, data_inceput)
INTO opera (cod_opera, valoare, data_achizitiei)
VALUES (secv_cod_opera.NEXT_VALUE, sapt_2,
data_inceput + 7)
INTO opera (cod_opera, valoare, data_achizitiei)
VALUES (secv_cod_opera.NEXT_VALUE, sapt_3,
data_inceput + 14)
INTO opera (cod_opera, valoare, data_achizitiei)
VALUES (secv_cod_opera.NEXT_VALUE, sapt_4,
data_inceput + 21)
SELECT data_inceput, sapt_1, sapt_2, sapt_3, sapt_4
FROM opera_intrare;
Exemplu:
Se consider trei tabele care conin informaii referitoare la galerii, n funcie
de numrul operelor gzduite de ctre acestea. Tabelele se numesc galerie_mica,
galerie_medie, galerie_mare dup cum numrul de opere este mai mic dect 30,
cuprins ntre 31 i 100, respectiv mai mare dect 101. Se presupune c structura
fiecruia dintre tabele este alctuit din coloanele cod_galerie, nume,
numr_opere. S se insereze nregistrri n aceste tabele.
INSERT ALL
WHEN nr_opere <= 30 THEN
INTO galerie_mica
WHEN nr_opere > 30 AND nr_opere <= 100 THEN
INTO galerie_medie
WHEN nr_opere > 100 THEN
INTO galerie_mare
SELECT g.cod_galerie, nume_galerie, nr_opere
FROM galerie g, (SELECT cod_galerie, count(*) nr_opere
FROM
opera

GROUP BY cod_galerie) x
WHERE g.cod_galerie = x.cod_galerie;
Acelai rezultat se obine prin utilizarea clauzei ELSE, astfel:
INSERT ALL
WHEN nr_opere <= 30 THEN
INTO galerie_mica
WHEN nr_opere > 30 AND nr_opere <= 100 THEN
INTO galerie_medie
ELSE
INTO galerie_mare
SELECT g.cod_galerie, nume_galerie, nr_opere
FROM galerie g, (SELECT cod_galerie, count(*) nr_opere
FROM
opera
GROUP BY cod_galerie) x
WHERE g.cod_galerie = x.cod_galerie;
Exemplu:
Se consider un tabel, galerie_g, avnd aceeai structur ca i cele din
exemplul precedent. n acesta vor fi reinute galeriile al cror nume ncepe cu litera
G. Se presupune c, dac o galerie se ncadreaz n acest tabel, ea nu mai trebuie
s apar i n cele referitoare la numrul de opere gzduite. S se insereze
nregistrri n tabelele galerie_g, galerie_mica, galerie_medie, galerie_mare.
INSERT FIRST
WHEN UPPER(nume_galerie) LIKE 'G%' THEN
INTO galerie_g
WHEN nr_opere <= 30 THEN
INTO galerie_mica
WHEN nr_opere > 30 AND nr_opere <= 100 THEN
INTO galerie_medie
WHEN nr_opere > 100 THEN
INTO galerie_mare
SELECT g.cod_galerie, nume_galerie, nr_opere
FROM galerie g, (SELECT cod_galerie, count(*) nr_opere
FROM
opera
GROUP BY cod_galerie) x
WHERE g.cod_galerie = x.cod_galerie;

Comanda UPDATE
Instruciunea UPDATE este folosit pentru actualizarea datelor din
coloanele unui tabel (sau ale unei vizualizri).
Valorile cmpurilor care trebuie modificate pot fi furnizate explicit sau pot fi
obinute n urma unei cereri SQL.
Sintaxa general a instruciunii UPDATE:
UPDATE nume_tabel_sau_vizualizare
SET nume_coloana = expresie
[,nume_coloana = expresie...]
[ WHERE conditie];

Sau mai general, expresia poate fi o cerere

UPDATE nume_tabel_sau_vizualizare
SET
(column1[,column2[,]]) = (subquery) / column = expr /
(query)
[WHERE condition]
Observaii:
Pentru a se putea executa instruciunea UPDATE, utilizatorul
care o lanseaz n execuie trebuie s aib acest privilegiu.
Dac nu este specificat clauza WHERE se vor modifica toate
liniile.
Cererea trebuie s furnizeze un numr de valori corespunztor
numrului de coloane din paranteza care precede caracterul de egalitate.
Se remarc urmtoarele:
Clauza SET conine o list cu una sau mai multe coloane,
mpreun cu o expresie care specific noua valoare pentru fiecare coloan.
Aceasta este o list de perechi nume-valoare, separate prin virgule, cu un
operator de egalitate ntre fiecare nume i valoare.

Expresia poate fi o constant, un alt nume de coloan sau orice

alt expresie pe care SQL o poate transforma ntr-o singur valoare, care
poate fi apoi atribuit coloanei respective.
Clauza WHERE conine o expresie care limiteaz rndurile
actualizate. Dac aceast clauz este omis, motorul SQL va ncerca s
actualizeze toate rndurile din tabel sau din vizualizare.
Exemple:
Un film a fost adugat cu un pre incorect. Instruciunea
urmtoare va actualiza dou coloane din acelaI rnd a tabelului MOVIE.
UPDATE FILM
SET RETAIL_PRET_VHS = 29.95 ,
RETAIL_PRET_DVD = 34.95
WHERE FILM_ID = 21
Conducerea firmei de produse video a decis s creasc salariul
tuturor funcionarilor cu 10 procente. Aceast instruciune va actualiza o
singur coloan de pe mai multe rnduri, rotujind rezultatul la 2 zecimale cu
funcia ROUND.
UPDATE ANGAJAT
SET ANGAJAT_PLATA_ORA = ROUND
(ANGAJAT_PLATA_ORA * 1.1, 2)
WHERE ANGAJAT_JOB_CATEGORY =C ;

Exemple BD CARTE
Preul crilor scrise de Lucian Blaga s fie modificat, astfel nct s fie egal
cu preul celei mai scumpe cri de informatic din bibliotec.
UPDATE carte
SET pret = (SELECT MAX(pret)
FROM carte
WHERE coded = I)
WHERE autor = Lucian Blaga;

Exemplu:
S se modifice preul crilor din bibliotec, care se gsesc ntr-un numr de
exemplare mai mic dect media numrului de exemplare pe bibliotec. Noua
valoare a preului s fie egal cu suma preurilor crilor scrise de Zola.
UPDATE carte
SET pret = (SELECT SUM(pret)
FROM carte
WHERE autor = Zola)
WHERE nrex < (SELECT AVG(nrex)
FROM carte);
Exemplu:
S se reduc cu 10% salariile redactorilor efi care nu sunt asociai
nici unei publicaii.
UPDATE salariat
SET salariu = 0,9*salariu
WHERE cod_salariat IN
(SELECT cod_salariat
FROM redactor_sef
WHERE cod_salariat NOT IN
(SELECT cod_salariat
FROM publicatie));
Exemplu:
S se mreasc cu 5% salariile redactorilor efi ce coordoneaza publicaiile
care au cel mai mare numr de frame-uri.
UPDATE salariat
SET salariu = 1,05*salariu
WHERE cod_salariat IN
(SELECT cod_salariat
FROM publicatie
WHERE nr_publicatie IN
(SELECT nr_publicatie
FROM
frame
GROUP BY nr_publicatie
HAVING COUNT(*) > ALL
(SELECT COUNT(*)
FROM
frame
GROUP BY nr_publicatie)));

** Oracle9i permite utilizarea valorii implicite DEFAULT in comenzile

INSERT si UPDATE. Unei coloane i se atribuie valoarea implicit definit la
crearea sau modificarea structurii tabelului dac nu se precizeaz nici o valoare sau
dac se precizeaz cuvntul cheie DEFAULT n comenzile INSERT sau UPDATE.
Dac nu este definit nici o valoare implicit pentru coloana respectiv, sistemul i
atribuie valoarea null.
Exemplu:
UPDATE carte
SET
pret = DEFAULT
WHERE codel = 77;
Exemplu BD GALERIE ARTA
a)
S se transfere n galeria 10 opera avnd codul 110.
UPDATE opera
SET cod_galerie = 10
WHERE cod_opera = 110;
b) S se modifice informaiile referitoare la opera avnd codul 120,
considernd c se afl expus n aceeai galerie i a fost achiziionat la aceeai
dat ca i opera al crei cod este 110.
UPDATE opera
SET (cod_galerie, data_achizitiei) =
(SELECT cod_galerie, data_achizitiei
FROM opera
WHERE cod_opera = 110)
WHERE cod_opera = 120;
c) S se modifice copie_opera pe baza valorilor din tabelul opera. Se
consider c operele care au acelai autor ca i opera avnd codul 100 sunt expuse
n galeria ce conine lucrarea al crei cod este 110.
UPDATE copie_opera
SET cod_galerie = (SELECT cod_galerie
FROM opera
WHERE cod_opera = 110)
WHERE cod_autor = (SELECT cod_autor
FROM opera

WHERE cod_opera = 100);

Cazurile n care instruciunea UPDATE nu poate fi executat sunt similare
celor n care eueaz instruciunea INSERT. Acestea au fost menionate anterior.
Exemplu:
UPDATE opera
SET cod_galerie = 47
WHERE cod_galerie = 40;
Deoarece galeria avnd codul 47 nu exist n tabelul printe (galerie),
instruciunea precedent va genera eroarea ORA-02291: integrity constraint
(STUDENT.SYS_C002773) violated - parent key not found.
Exemplu:
S se transfere n galeria avnd codul 50 toate operele din galeria 60, care
sunt create de Nicolae Grigorescu. S se mreasc cu 10% valoarea acestor opere.
UPDATE opera o
SET cod_galerie = 50,
valoare = valoare * 1.10
WHERE (SELECT INITCAP(nume) ||' '||INITCAP(prenume)
FROM artist
WHERE cod_artist = o.cod_artist)= 'Nicolae Grigorescu'
AND o.cod_galerie = 60;
Exemplu:
S se actualizeze operele al cror autor este tefan Luchian astfel: codul
galeriei devine codul galeriei n care este expus cea mai scump oper a artistului,
valoarea fiecrei opere va fi mrit cu 10% din media valorilor operelor din
galerie, iar data achiziiei va fi considerat data celei mai recente achiziii din
galerie.
UPDATE opera o
SET cod_galerie = (SELECT cod_galerie
FROM artist a, opera b
WHERE a.cod_artist = b.cod_artist
AND INITCAP(nume) = 'Luchian '
AND INITCAP(prenume) = 'Stefan'
AND valoare =
(SELECT MAX(valoare)

FROM opera
WHERE cod_artist =
b.cod_artist)),
(valoare, data_achizitiei) =
(SELECT o.valoare + AVG(o2.valoare)*0.10,
MAX(o2.data_achizitiei)
FROM opera o2
WHERE o.cod_opera = o2.cod_opera)
WHERE cod_artist = (SELECT cod_artist
FROM artist
WHERE INITCAP(nume) = 'Luchian '
AND INITCAP(prenume) = 'Stefan');
Oracle9i introduce o nou funcionalitate, reprezentat de posibilitatea
utilizrii valorilor implicite (DEFAULT) n instruciunile INSERT i UPDATE.
Unei coloane i se atribuie valoarea implicit definit la crearea sau modificarea
structurii tabelului dac:
nu se precizeaz nici o valoare;
se precizeaz cuvntul cheie DEFAULT n comenzile INSERT
sau UPDATE.
Dac nu a fost definit nici o valoare implicit pentru coloana respectiv,
sistemul i atribuie valoarea null. Cuvntul cheie DEFAULT nu poate fi specificat
la actualizarea vizualizrilor.
Exemplu:
S se creeze tabelul test, avnd o coloan creia i se specific o valoare
implicit. Ulterior, s se modifice aceast valoare. S se insereze i s se
actualizeze cte o nregistrare din tabel, utiliznd valoarea implicit.
CREATE TABLE test(
cod NUMBER
PRIMARY KEY,
nume VARCHAR2(30) DEFAULT 'NECUNOSCUT');
ALTER TABLE test MODIFY (nume DEFAULT 'NEDEFINIT');
INSERT INTO test VALUES (1, DEFAULT);
UPDATE test SET nume = DEFAULT WHERE cod = 2;

Comanda (Instruciunea) DELETE

Instruciunea DELETE terge unul sau mai multe rnduri dintr-un tabel.
Instruciunea poate s foloseasc i o vzualizare, dar numai dac aceasta se bazeaz
pe un singur tabel (ceea ce nseamn c instruciunile DELETE nu pot fi folosite
pentru vizualizri care conin uniuni). n instruciunile DELETE nu sunt referite
niciodat coloane, doarece instruciunea terge rnduri ntregi de date, inclusiv
toate valorile datelor (toate coloanele) din rndurile afectate. Dac vrei s tergei
o singur valoare din rndurile existente, folosii instruciunea UPDATE pentru a
nlocui valorile respective cu valori nule (presupunnd c valorile nule sunt
permise n acele coloane).
Sintaxa general a instruciunii DELETE este
DELETE FROM nume_tabel_sau_vizualizare [AS alias]
[ WHERE conditie ];
Se remarc urmtoarele:
Comanda DELETE nu terge structura tabelului.
Clauza WHERE este opional. Totui, este folosit aproape ntotdeauna,
deoarece o instruciune DELETE fr o clauz WHERE ncearc s tearg
toate rndurile din tabel. n clauza WHERE pot fi folosite i subcereri.
Atunci cnd este inclus, clauza WHERE specific rndurile care urmeaz
s fie terse. Orice rnd pentru care condiia WHERE este evaluat ca
adevrat este ters din tabel.
Nu se pot terge rnduri dac se ncalc o restricie referenial. n general,
rndurile subordonate trebuie terse naintea rndurilor printe.
Pentru a terge linii identificate cu ajutorul valorilor din alte tabele, se
utilizeaz subcereri.
Comanda nu poate fi folosit pentru tergerea valorilor unui cmp
individual. Acest lucru se poate realiza cu ajutorul comenzii UPDATE.
Exemple BD MOVIE
S se tearg filmul adugat mai devreme (cu FILM_ID = 21 ).
Se observ c trebuie s se terg mai nti rndurile corespondente din

tabelele FILM_COPY i FILM_LIMBA, deoarece acestea sunt rnduri

copii ale rndului din tabelul FILM
DELETE FROM FILM_COPY
WHERE FILM_ID = 21;
DELETE FROM FILM_LIMBA
WHERE FILM_ID = 21;
DELETE FROM FILM
WHERE FILM_ID = 21;
S se tearg din tabelul FILM_LIMBA toate rndurile pentru
limba spaniol (COD_LIMBA='es' ). n multe implementri SQL se face
diferenierea literelor mari de cele mici, caz n care valoarea codului de limb
trebuie specificat cu litere mici pentru a se potrivi cu datele din tabel.
DELETE FROM FILM_LIMBA
WHERE COD_LIMBA =es;
Exemplu:
S se elimine cititorii care au numele Popai cei care au restituit astzi cel
puin o carte.
DELETE FROM cititor
WHERE
nume=Popa
OR
codec IN (SELECT codec
FROM imprumuta
WHERE data_ef=SYSDATE);
Exemplu:
S se elimine redactorii efi care nu au coordonat nici o publicaie.
DELETE FROM redactor_sef
WHERE
cod_salariat NOT IN
(SELECT DISTINCT cod_salariat
FROM
publicatie);

Exemplu:
S se tearg salariul angajatului avnd codul 1279.
UPDATE salariat
SET salariu=null
WHERE cod_salariat = 1279;
Exemplu:
Urmatoarele doua comenzi sunt echivalente.
DELETE FROM opera
WHERE
cod_opera = 777;
DELETE FROM (SELECT * FROM opera)
WHERE
cod_opera = 777;
Exemplu:
S se tearg cartea cea mai scump
DELETE FROM carte
WHERE pret = (SELECT MAX(pret)
FROM carte);
Exemplu:
Pentru fiecare autor care are mai mult de 10 creaii expuse n muzeu, s se
tearg ultima oper creat de acesta.
DELETE FROM opera o1
WHERE
cod_artist =
(SELECT cod_artist
FROM opera o2
WHERE cod_artist = o1.cod_artist
AND data_crearii =
(SELECT MAX(data_crearii)
FROM opera
WHERE cod_artist = o2.cod_artist)
AND 10 <
(SELECT COUNT(*)
FROM opera
WHERE cod_artist = o2.cod_artist));

Exemple BD GALERIE de ARTA

a)

S se suprime nregistrarea corespunztoare operei avnd codul 120.

DELETE FROM opera

WHERE cod_opera = 120;
Urmtoarea instruciune are acelai efect, dar utilizeaz o subcerere:
DELETE FROM (SELECT * FROM opera)
WHERE cod_opera = 120;
b)

S se tearg ntregul coninut al tabelului copie_opera.

(nu se foloseste caluza where)
DELETE FROM copie_opera;

c) S se tearg toate operele care se afl expuse ntr-o galerie al crei nume
conine irul de caractere muzeu.
DELETE FROM opera
WHERE cod_galerie = (SELECT cod_galerie
FROM galerie
WHERE UPPER(nume_galerie)
LIKE '%MUZEU%');
Dac se ncearc tergerea unei nregistrri care conine o valoare implicat
ntr-o constrngere de integritate, atunci va fi returnat o eroare.
Exemplu:
DELETE FROM galerie
WHERE cod_galerie = 40;
n urma execuiei acestei instruciuni sistemul genereaz eroarea ORA02292: integrity constraint (STUDENT.SYS_C002773) violated - child record
found, datorat calitii de cheie extern a coloanei cod_galerie n tabelul opera.
Exist opere n galeria avnd codul 40 i de aceea aceasta nu poate fi suprimat.
n cazul n care constrngerea de integritate referenial a fost definit
utiliznd opiunea ON DELETE CASCADE, atunci instruciunea DELETE va
terge att liniile indicate, ct i liniile copil din tabelele corespunztoare.

LIMBAJUL PENTRU CONTROLUL DATELOR

Controlul unei baze de date cu ajutorul SQL-ului se refera la:
asigurarea confidentialitatii si securitatii datelor;
organizarea fizica a datelor;
realizarea unor performante;
reluarea unor actiuni in cazul unei defectiuni;
garantarea coerentei datelor in cazul prelucrarii concurente.
Sistemul de gestiune trebuie:
s pun la dispoziia unui numr mare de utilizatori o mulime
coerent de date;
s garanteze coerena datelor n cazul manipulrii simultane de
ctre diferii utilizatori.
Coerena este asigurat cu ajutorul conceptului de tranzacie.
Tranzacia este unitatea logic de lucru constnd din una sau mai multe instruciuni
SQL, care trebuie s fie executate atomic (ori se execut toate, ori nu se execut
nici una!), asigurnd astfel trecerea BD dintr-o stare coerent n alt stare coerent.
Dac toate operaiile ce constituie tranzacia sunt executate i devin
efective, spunem c tranzacia este validat, iar modificrile aduse de tranzacie
devin definitive.
Dac dintr-un motiv sau altul (neverificarea condiiilor, accesul
imposibil) o operaie a tranzaciei nu a fost executat spunem c tranzacia a fost
anulat. Modificrile aduse de toate operaiile tranzaciei anulate sunt i ele
anulate i se revine la starea bazei de date de dinaintea tranzaciei anulate.
Este posibil ca o tranzacie s fie descompus n subtranzacii, astfel
nct dac este necesar s se anuleze doar parial unele operaii.
Fiecare tranzacie se poate termina:
normal (commit);
anormal (rollback).
Controlul tranzaciilor const n:
definirea nceputului i sfritului unei tranzacii,
validarea sau anularea acesteia,
eventual descompunere n subtranzacii.
Limbajul pentru controlul datelor (LCD) permite salvarea informaiei,
realizarea fizic a modificrilor n baza de date, rezolvarea unor probleme de
concuren.

Limbajul conine urmtoarele instruciuni:

COMMIT - folosit pentru permanentizarea modificrilor
executate asupra BD (modificrile sunt nregistrate i sunt vizibile tuturor
utilizatorilor);
ROLLBACK - folosit pentru refacerea strii anterioare a BD
(sunt anulate toate reactualizrile efectuate de la nceputul tranzaciei);
SAVEPOINT - folosit n conjuncie cu instruciunea
ROLLBACK, pentru definirea unor puncte de salvare n fluxul programului.
O tranzacie const:
dintr-o singur instruciune LDD;
dintr-o singur instruciune LCD;
din instruciuni LMD care fac schimbri consistente n date.
Tranzacia ncepe:
dup o comand COMMIT,
dup o comand ROLLBACK,
dup conectarea iniial la Oracle,
cnd este executat prima instruciune SQL.
Tranzacia se termin:
dac sistemul cade;
dac utilizatorul se deconecteaz;
dac se dau comenzile COMMIT sau ROLLBACK ;
dac se execut o comand LDD.
Dup ce se termin o tranzacie, prima instruciune SQL executabil va
genera automat nceputul unei noi tranzacii.
Un commit apare automat:
cnd este executat o comand LDD;
cnd este executat o comand LCD;
dup o ieire normal din SQL*Plus fr specificarea explicit a
comenzilor COMMIT sau ROLLBACK.
Un rollback apare automat dup o ieire anormal din SQL*Plus sau o
cdere sistem.
Din momentul n care s-a executat instruciunea COMMIT, BD s-a
modificat (permanent) n conformitate cu instruciunile SQL executate n cadrul
tranzaciei care tocmai s-a terminat. Din acest punct ncepe o nou tranzacie.

Dac se folosete utilitarul SQL*Plus, exist posibilitatea ca dup fiecare

comand LMD s aib loc o permanentizare automat a datelor (un COMMIT
implicit). Acest lucru se poate realiza folosind comanda:
SET AUTO[COMMIT] {ON | OFF}
Comanda ROLLBACK permite restaurarea unei stri anterioare a BD.
ROLLBACK [TO [SAVEPOINT] savepoint];
Dac nu se specific nici un savepoint, toate modificrile fcute n
tranzacia curent sunt anulate, iar dac se specific un anumit savepoint, atunci
doar modificrile de la acel savepoint pn n momentul respectiv sunt anulate.
Executarea unei instruciuni ROLLBACK presupune terminarea tranzaciei curente
i nceperea unei noi tranzacii.
Punctele de salvare pot fi considerate ca nite etichete care refer o
submulime a schimbrilor dintr-o tranzacie, marcnd efectiv un punct de salvare
pentru tranzacia curent. Punctele de salvare NU sunt obiecte ale schemei. Prin
urmare, nu sunt referite in DD.
Server-ul Oracle implementeaz un punct de salvare implicit pe care l mut
automat dup ultima comand LMD executat. Dac este creat un punct de salvare
avnd acelai nume cu unul creat anterior, cel definit anterior este ters automat.
SAVEPOINT savepoint;
Exemplu:
Comanda ROLLBACK nu va genera terminarea tranzaciei.
COMMIT
INSERT
SAVEPOINT a
UPDATE
INSERT
SAVEPOINT b
DELETE
ROLLBACK TO a
Starea datelor nainte de COMMIT sau ROLLBACK este urmtoarea:
starea anterioar a datelor poate fi recuperat;
utilizatorul curent poate vizualiza rezultatele operaiilor LMD
prin interogri asupra tabelelor;
ali utilizatori nu pot vizualiza rezultatele comenzilor LMD
fcute de utilizatorul curent (read consistency);

nregistrrile (liniile) afectate sunt blocate i, prin urmare, ali

utilizatori nu pot face schimbri n datele acestor nregistrri.
Execuia unei comenzi COMMIT implic anumite modificri.
Toate schimbrile (INSERT, DELETE, UPDATE) din baza de
date fcute dup anterioara comand COMMIT sau ROLLBACK sunt
definitive. Comanda se refer numai la schimbrile fcute de utilizatorul
care d comanda COMMIT.
Toate punctele de salvare vor fi terse.
Starea anterioar a datelor este pierdut definitiv.
Toi utilizatorii pot vizualiza rezultatele.
Blocrile asupra liniilor afectate sunt eliberate; liniile pot fi
folosite de ali utilizatori pentru a face schimbri n date.
Execuia unei comenzi ROLLBACK implic anumite modificri.
Anuleaz tranzacia n curs i toate modificrile de date fcute
dup ultima comand COMMIT.
Sunt eliberate blocrile liniilor implicate.
Nu terge un tabel creat prin CREATE TABLE. Eliminarea
tabelului se poate realiza doar prin comanda DROP TABLE.
Exemplu:
Ce efect are urmtoarea secven de instruciuni?
(a)

SELECT
FROM

*
salariat;

(b)

SAVEPOINT

a;

(c) DELETE FROM salariat;

INSERT INTO salariat
VALUES (18,Breaban,Marin,4,5000, tehnored);
INSERT INTO salariat
VALUES (23,Popescu,Emil,7,40000,grafician);
SAVEPOINT b;
(d) INSERT INTO salariat
VALUES (29,,,5,3000000,tehnoredactor);
SELECT
AVG(salariu)
FROM
salariat;

(e)

ROLLBACK TO b;
SELECT
AVG(salariu)
FROM
salariat;

(f)

ROLLBACK TO a;
INSERT INTO salariat
VALUES (18,Ion,Mihai,5,580,redr_sef);
COMMIT;

Consistena la citire
ntr-un sistem multi-user, sistemul Oracle furnizeaz read consistency la
nivel de instruciune SQL, adic o singur comand SQL nu poate da rezultate care
sunt contradictorii sau inconsistente. Read consistency asigur c fiecare utilizator
vede datele aa cum existau la ultimul commit, nainte s nceap o operaie
LMD. Prin urmare, modificrile efectuate asupra unei baze de date nu sunt vizibile
dect dup ce operaia de actualizare a fost validat. Numai utilizatorul care a
executat tranzacia poate vedea modificrile fcute de el n cursul acestei tranzacii.
Modelul multiversiune, furnizat de Oracle, asigur consistena la citire:
garanteaz c setul de date vzut de orice instruciune SQL este
consistent i nu se schimb n timpul execuiei unei instruciuni (Oracle
asigur o consisten la citire la nivel de instruciune);
operaiile de citire (SELECT) nu trebuie s vad datele care sunt
n proces de schimbare;
operaiile de scriere (INSERT, DELETE, UPDATE) nu trebuie
s afecteze consistena datelor i s ntrerup sau s intre n conflict cu alte
operaii de scriere concurente.
Cum se implementeaz modelul multiversiune? Dac asupra bazei este
executat o comand LMD, server-ul Oracle face o copie a datelor dinainte de
modificare i o depune n segmentul rollback (undo).
Toi utilizatorii (cu excepia celor care modific datele) vor vedea datele
cum sunt nainte de modificare (vd coninutul segmentului undo). Dac comanda
LMD este commit, atunci schimbrile din baza de date devin vizibile oricrui
utilizator care folosete instruciunea SELECT. Cnd se termin tranzacia, spaiul
ocupat n segmentul undo de vechea dat este liber pentru reutilizare. Server-ul
Oracle asigur astfel o vizualizare consistent a datelor n orice moment.

Carte

Controlul datelor (LCD)

Tranzacia este o unitate logic de lucru, constituit dintr-o secven de

comenzi care trebuie s se execute atomic pentru a menine consistena datelor.
Server-ul Oracle asigur consistena datelor prin intermediul tranzaciilor,
inclusiv n eventualitatea unei anomalii a unui proces sau a sistemului. Tranzaciile
ofer mai mult flexibilitate i control n modificarea datelor.
Controlul tranzaciilor se realizeaz prin utilizarea instruciunilor limbajului
de control al datelor: COMMIT, ROLLBACK, SET TRANSACTION, SAVEPOINT.
Tranzaciile pot fi de tip LMD, LDD sau LCD. Tranzaciile LDD i LCD
constau dintr-o singur instruciune LDD, respectiv LCD. Tranzaciile LMD
constau dintr-o succesiune de instruciuni LMD care determin o modificare
consistent a datelor. De exemplu, un transfer de fonduri ntre dou conturi
bancare presupune debitarea unui cont i creditarea celuilalt cu aceeai sum.
Ambele aciuni trebuie fie s eueze, fie s se ncheie cu succes. Creditarea nu
trebuie salvat fr s fie salvat i operaia de debitare.
Procesarea tranzaciilor
Modificrile fcute asupra datelor n timpul unei tranzacii sunt temporare
pn cnd tranzacia este salvat. Operaiile de prelucrare a datelor afecteaz iniial
un buffer al bazei. Prin urmare, starea precedent a datelor poate fi recuperat.
n general, o tranzacie ncepe atunci cnd este ntlnit prima instruciune
LMD i se termin la:
apariia unei instruciuni LDD;
emiterea unei instruciuni LCD;
prsirea mediului SQL*Plus;
defectarea staiei de lucru sau la nregistrarea unei ntreruperi
a sistemului.
Execuia unei instruciuni LDD determin salvarea automat a modificrilor
survenite pe perioada tranzaciei. Server-ul Oracle genereaz o operaie COMMIT
implicit nainte i dup orice instruciune LDD. Aadar, chiar dac instruciunea
LDD nu este executat cu succes, instruciunea anterioar acesteia nu mai poate fi
anulat ntruct server-ul a efectuat deja operaia COMMIT.
Instruciunile COMMIT i ROLLBACK ncheie tranzacia curent prin

definitivarea, respectiv anularea tuturor modificrilor aflate n ateptare. Aceste

instruciuni permit:
asigurarea consistenei datelor;
previzualizarea modificrilor asupra datelor nainte ca acestea
s devin permanente;
gruparea logic a operaiilor.
Ieirea din mediul SQL*Plus fr lansarea unei instruciuni COMMIT sau
ROLLBACK are ca efect salvarea automat a tranzaciei curente.
Atunci cnd intervine o anomalie (cdere) a sistemului sau nchiderea
anormal a sesiunii SQL*Plus, ntreaga tranzacie curent este anulat automat
(ROLLBACK). Acest fapt mpiedic eroarea s cauzeze modificri nedorite ale
datelor i determin revenirea la starea din momentul ultimei operaii COMMIT.
O ieire normal din iSQL*Plus are loc prin apsarea butonului Exit.
Terminarea normal a unei sesiuni SQL*Plus are loc prin execuia comenzii EXIT.
n SQL*Plus, nchiderea ferestrei este interpretat ca ieire anormal.
Interfaa SQL*Plus pune la dispoziie variabila de mediu AUTOCOMMIT,
care poate avea valorile ON sau OFF. Dac aceast variabil are valoarea ON,
atunci efectul fiecrei instruciuni LMD se definitiveaz imediat ce instruciunea a
fost executat. Dac variabila AUTOCOMMIT are valoarea OFF, definitivarea
unei tranzacii va avea loc la execuia comenzii COMMIT sau n cazurile de salvare
automat a tranzaciilor, prezentate anterior.
Dup ncheierea unei tranzacii, urmtoarea instruciune SQL executabil
marcheaz automat nceputul unei noi tranzacii.
Comanda COMMIT
Instruciunea COMMIT determin ncheierea tranzaciei curente i
permanentizarea modificrilor care au intervenit pe parcursul acesteia.
Instruciunea suprim toate punctele intermediare definite n tranzacie i
elibereaz blocrile tranzaciei. De asemenea, instruciunea poate fi utilizat pentru
terminarea unei tranzacii read-only nceput printr-o comand SET
TRANSACTION.
Sistemul lanseaz implicit o comand COMMIT nainte i dup orice
instruciune LDD. Sintaxa corespunztoare comenzii COMMIT este urmtoarea:
COMMIT [WORK] [COMMENT 'text' | FORCE 'text' [, nr_ntreg] ];
Opiunea WORK a fost introdus din motive de conformitate cu standardul
SQL. Instruciunile COMMIT i COMMIT WORK sunt echivalente.
Clauza COMMENT permite specificarea unui comentariu care va fi asociat

tranzaciei curente. Textul care i urmeaz poate ocupa maxim 255 octei i va fi
stocat n vizualizarea DBA_2PC_PENDING din dicionarul datelor.
ntr-un sistem distribuit, clauza FORCE permite salvarea manual a unei
tranzacii distribuite in-doubt (n care operaia COMMIT a fost ntrerupt de o
cdere a sistemului sau a reelei). Textul care i urmeaz conine identificatorul
local sau global al tranzaciei. Pentru a afla aceti identificatori se poate consulta,
de asemenea, vizualizarea DBA_2PC_PENDING din dicionarul datelor.
Pentru a atribui tranzaciei un system change number (SCN) se specific un
numr ntreg n clauza FORCE. Valoarea unui SCN este mrit ori de cte ori este
salvat o tranzacie. Acest numr are un rol important n asigurarea consistenei la
citire. n general, o cerere citete un bloc de date care are ca atribut un SCN
corespunztor ultimei modificri a blocului respectiv. Dac acest SCN este mai
mare dect cel citit la nceputul interogrii, nseamn c blocul a fost modificat
ulterior lansrii cererii. Prin urmare, trebuie gsit o versiune mai veche a blocului
n segmentele de anulare.
O instruciune COMMIT care conine clauza FORCE permanentizeaz
numai tranzacia specificat i nu o afecteaz pe cea curent. Prezena acestei
clauze nu este permis n PL/SQL.
Exemplu:
S se insereze o nregistrare n tabelul artist i s se permanentizeze
modificarea.
INSERT INTO artist(cod_artist, nume, prenume)
VALUES (189, 'Pallady', 'Theodor');
COMMIT;
nainte de operaia COMMIT, utilizatorul curent poate vizualiza rezultatele
comenzilor LMD prin interogarea tabelelor. Efectele acestor operaii nu sunt
vizibile celorlali utilizatori. Server-ul Oracle asigur consistena la citire, astfel
nct fiecare utilizator vizualizeaz datele n starea corespunztoare ultimei operaii
COMMIT efectuate asupra lor. Liniile afectate de tranzacia curent sunt blocate,
nefiind posibil modificarea lor de ctre ceilali utilizatori.
Dac mai muli utilizatori modific simultan acelai tabel, fiecare dintre
acetia poate consulta numai propriile modificri. Pe msur ce operaia COMMIT
este executat de ctre utilizatori, actualizrile efectuate de acetia devin vizibile.
n urma execuiei instruciunii COMMIT, modificrile asupra datelor sunt
scrise n baza de date, iar starea precedent a datelor este pierdut definitiv. n
acest fel, rezultatele tranzaciei pot fi vizualizate de ctre toi utilizatorii. Blocrile
asupra liniilor afectate sunt eliberate, astfel c nregistrrile devin disponibile

celorlali utilizatori pentru a efectua noi actualizri. Dup operaia COMMIT, toate
punctele intermediare (SAVEPOINT) ale tranzaciei respective sunt terse.
Comanda ROLLBACK
Atunci cnd o linie este modificat, valorile anterioare ale coloanelor
actualizate sunt salvate ntr-un segment de reluare. Dac tranzacia este anulat,
server-ul Oracle va rescrie valorile din acest segment n linia tabelului.
Pentru a renuna la modificrile efectuate se utilizeaz instruciunea
ROLLBACK. n urma execuiei acesteia, se ncheie tranzacia, se anuleaz
modificrile asupra datelor, se restaureaz starea lor precedent i se elibereaz
blocrile asupra liniilor.
O parte a tranzaciei poate fi anulat automat printr-o operaie ROLLBACK
implicit dac a fost detectat o eroare n timpul execuiei unei instruciuni. Dac o
singur instruciune LMD eueaz n timpul execuiei unei tranzacii, efectul su
este anulat de un ROLLBACK la nivel de instruciune, dar schimbrile efectuate de
instruciunile LMD precedente nu sunt anulate. Acestea din urm pot fi salvate sau
anulate explicit de ctre utilizator.
Sintaxa instruciunii ROLLBACK este urmtoarea:
ROLLBACK [WORK]
[TO [SAVEPOINT] pct_intermediar | FORCE 'text'];
Semnificaiile opiunilor WORK i FORCE sunt similare celor prezentate n
cadrul instruciunii COMMIT.
n clauza TO SAVEPOINT se poate specifica punctul intermediar pn la
care se dorete anularea tranzaciei. n absena acestei clauze, ntreaga tranzacie
este anulat. O tranzacie in-doubt nu poate fi anulat manual pn la un punct
intermediar.
Dac a fost definit un punct intermediar prin instruciunea SAVEPOINT
nume, instruciunea ROLLBACK TO SAVEPOINT nume determin ntoarcerea
tranzaciei curente la punctul intermediar specificat.
n felul acesta se revine ntr-o stare anterioar a tranzaciei i se anuleaz
modificrile care au survenit dup definirea punctului intermediar. De asemenea,
sunt terse punctele intermediare ulterioare acestuia i sunt eliberate toate blocrile
asupra tabelelor sau liniilor, efectuate dup punctul intermediar respectiv.
Comanda SAVEPOINT
Instruciunea SAVEPOINT marcheaz un punct intermediar n procesarea
tranzaciei. n acest mod este posibil mprirea tranzaciei n subtranzacii.

Aceast instruciune nu face parte din standardul ANSI al limbajului SQL.

Punctele intermediare definite n procesarea unei tranzacii nu sunt obiecte
ale schemei i nu pot fi referite n dicionarul datelor. Nu exist nici o modalitate
de a lista punctele intermediare definite. Dac este creat un al doilea punct
intermediar avnd acelai nume cu un punct intermediar precedent, acesta din urm
este ters.
Instruciunea SAVEPOINT are sintaxa:
SAVEPOINT nume_pct_intermediar;
Exemplu:
S se mreasc prin 20%, respectiv 50% valoarea operelor care au codurile
100, respectiv 150. S se verifice c valoarea total a operelor din galerie nu
depete 7 000 000, iar apoi s se reactualizeze valoarea operei avnd codul 150,
mrind-o cu 40%.
UPDATE opera
SET valoare = valoare * 1.2
WHERE cod_opera = 100;
SAVEPOINT val_100;
UPDATE opera
SET valoare = valoare * 1.5
WHERE cod_opera = 150;
SAVEPOINT val_150;
SELECT SUM(valoare)
FROM opera;
ROLLBACK TO SAVEPOINT val_100;
UPDATE opera
SET valoare = valoare * 1.4
WHERE cod_opera = 150;
COMMIT;

Consistena la citire
Utilizatorii pot accesa baza de date prin operaii de citire (instruciuni
SELECT) sau prin operaii de scriere (instruciuni INSERT, UPDATE, DELETE).
Consistena la citire este necesar pentru a asigura c:
datele vizualizate de ctre utilizatorii care scriu i citesc din
baza de date sunt consistente;
utilizatorii care citesc din baza de date nu pot vizualiza starea
datelor care sunt n curs de modificare;
utilizatorii care scriu n baza de date sunt asigurai c
modificrile asupra acesteia se realizeaz n mod consistent;
modificrile pe care le efectueaz un utilizator nu intr n
conflict cu cele ale altui utilizator.
Scopul consistenei la citire este ca fiecare utilizator s vizualizeze datele n
starea existent la ultima operaie COMMIT.
Consistena la citire se implementeaz automat, prin pstrarea unei copii
pariale a bazei de date n segmentele de reluare. Atunci cnd se efectueaz o
operaie INSERT, UPDATE sau DELETE, server-ul Oracle reine o copie a datelor
n starea dinaintea modificrii i o scrie ntr-un segment de reluare.
Pentru toi utilizatorii care citesc din baza de date, cu excepia celui care a
iniiat modificarea, datele sunt vizibile n starea dinaintea nceperii reactualizrii.
Aceti utilizatori vizualizeaz starea datelor din segmentul de reluare. Astfel, se
garanteaz c utilizatorii citesc date consistente care nu sunt n curs de schimbare.
Dup ce se efectueaz operaia COMMIT asupra tranzaciei, modificrile
fcute n baza de date devin vizibile tuturor. Server-ul Oracle creeaz vizualizri
consistente la citire pentru interogrile care au nceput nainte ca tranzacia s fie
salvat. Apoi, spaiul ocupat de datele vechi n segmentul de reluare va fi eliberat
pentru a fi refolosit.
Dac se efectueaz operaia ROLLBACK asupra tranzaciei, modificrile
sunt anulate. Astfel, versiunea datelor salvate n segmentul de reluare este rescris
n tabel, iar baza de date revine n starea de dinaintea nceperii tranzaciei.