Cap.

2 Limbajul SQL - Proiectarea bazelor de date relaionale

CAPITOLUL 2
LIMBAJUL SQL PROIECTAREA BAZELOR DE
DATE RELAIONALE

Majoritatea sistemelor relaionale suport diferite variante

(dialecte) ale limbajului SQL (Structured Query Language).
Limbajul SQL a fost dezvoltat ntr-un prototip de sistem
relaional - System R - la compania IBM la mijlocul anilor
1970. n anul 1979 corporaia Oracle a introdus prima
implementare a limbajului SQL n varianta comercial. n anul
1986 Institutul Naional American de Standarde (ANSI) a
definit standardul limbajului SQL pentru bazele de date
relaionale. Organizaia Internaional de Standarde (ISO) a
adoptat de asemenea SQL ca limbaj standard pentru sistemele
relaionale, sub denumirea de SQL-92 (sau mai simplu, SQL2).
2.1. Limbajul SQL

Limbajul SQL nglobeaz mai multe componente, dintre

care cele mai importante sunt: componenta de descriere a
datelor (LDD - Limbaj de Descriere a Datelor), (Data
Description Language - DDL) i componenta de manipulare a
datelor (LMD - Limbaj de Manipulare a Datelor) (Data
Manipulation Language - DML).
2.1.1. Tipuri de date SQL2

n limbajul SQL (standardul SQL2), sunt predefinite mai

multe tipuri de date: numeric, ir de caractere, dat
(calendaristic), timp etc. Denumirile tipurilor de date i
limitele acestora (valoare minim, valoare maxim) prezint
diferite variaii n funcie de implementare (versiunea
sistemului SGBD), dar n general sunt destul de asemntoare.
37

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

n toate specificaiile de sintax, parantezele drepte [..] sunt

folosite pentru parametrii opionali ai unei instruciuni.
Tipul numeric include numere ntregi de diferite dimensiuni
(integer sau int reprezentat pe 4 octei, smallint,
reprezentat pe 2 octei), numere reale reprezentate n virgul
flotant, cu diferite precizii (float, reprezentat pe 4 octei,
real i double [precision] reprezentat pe 8 octei) i
numere zecimale reprezentate cu precizia dorit (tipul numeric
sau decimal).
Formatul de reprezentare a numerelor zecimale cu precizia
dorit este: numeric [(p,s)] (sau decimal [(p,s)]), unde
p (precizia) este numrul total de cifre afiate, iar s (scara)
este numrul de cifre dup punctul zecimal. Pentru a pstra
precizia dorit, numerele de tip decimal sau numeric sunt
memorate ca ir de caractere, fiecare caracter reprezentnd o
cifr, punctul zecimal sau semnul.
Tipul ir de caractere permite definirea irurilor de
caractere de lungime fix (char(n) sau character(n)),
precum i a irurilor de caractere de lungime variabil
(varchar(n)). Ambele tipuri pot reprezenta iruri de
maximum n caractere, cu diferena c, pentru iruri de lungime
mai mic dect n, la tipul char(n) se completeaz irul cu
spaii albe pn la n caractere, n timp ce la tipul varchar(n)
se memoreaz numai attea caractere cte are irul dat.
Tipurile pentru data calendaristic i timp sunt: date, time,
timestamp, interval.

2.1.2. Funcii definite n limbajul SQL2

Funciile definite n SQL2 sunt de dou categorii: funcii

scalare i funcii agregat.
Funciile scalare se folosesc n expresii, care pot s apar n
diferite clauze ale instruciunilor SQL. Acestea primesc unul
sau mai multe argumente i returneaz valoarea calculat, sau
NULL, n caz de eroare. Argumentele funciilor pot fi constante
38

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

(literale) sau valori ale atributelor specificate prin numele

coloanelor corespunztoare. Exist mai multe tipuri de funcii
scalare SQL: funcii numerice (sin, cos, ln, log etc.), funcii
pentru manipularea irurilor de caractere, funcii pentru data
calendaristic i timp, funcii de conversie.
Funciile agregat calculeaz un rezultat din mai multe linii
ale unui tabel. Acestea sunt:
COUNT: returneaz numrul de linii ale rezultatului (care
ndeplinesc condiia WHERE);
SUM: returneaz suma tuturor valorilor dintr-o coloan;
MAX: returneaz valoarea cea mai mare dintr-o coloan;
MIN: returneaz valoarea cea mai mica dintr-o coloan;
AVG: returneaz media valorilor dintr-o coloan.
Aceste funcii se pot folosi cu clauza GROUP BY, dac se
calculeaz valoarea dorit (medie, suma etc.) prin gruparea
liniilor n funcie de valoarea uneia sau mai multor coloane sau
fr clauza GROUP BY dac se calculeaz valoarea dorit
considernd toate tuplurile relaiei. De exemplu, comanda
urmtoare va afia salariul mediu al tuturor angajailor:
SELECT AVG(Salariu) FROM ANGAJATI;
2.1.3. Instruciuni SQL de definire a datelor

Instruciunea

de creare a unui tabel (CREATE TABLE)

definete atributele (coloanele) tabelului, domeniile atributelor
i diferite constrngeri pe care datele nregistrate (valori ale
atributelor) trebuie s le respecte pentru asigurarea integritii
(corectitudinii) bazei de date. Sintaxa general a acestei
instruciuni este:

39

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Constrngerile impuse fiecrui atribut (coloan) i

constrngerile de tabel, sunt opionale.
Se pot introduce una sau mai multe constrngeri de atribut
(coloan): PRIMARY KEY, NOT, NULL, DEFAULT.
Constrngerea de coloan PRIMARY KEY definete
atributul pe care l nsotete ca fiind cheie primar, adic un
identificator unic al tuplului respectiv. ntr-o relaie nu pot
exista dou sau mai multe tupluri cu aceeai valoare a cheii
primare. Dac cheia primar este compus (format din mai
multe atribute), atunci constrngerea de cheie primar se
specific dup definirea atributelor, ca o constrngere de tabel
sub forma:
[CONSTRAINT
nume_constr]
(lista_atribute)

PRIMARY

KEY

Aceasta form de definire se poate folosi i pentru o cheie

primar simpl. Cheia strin se introduce cu construcia:
[CONSTRAINT
nume_constr]
FOREIGN
KEY
(cheie_straina)
REFERENCES relatie_referita (cheie_candidata)

Constrngerea NOT NULL specific fapul c atributul

respectiv nu poate lua valori nedefinite (NULL). Constrngerea
DEFAULT introduce o valoare implicit a atributului
respectiv, care va fi folosit la iniializarea valorilor unui tuplu
nou introdus, atunci cnd nu se specific o valoare pentru acest
atribut. n lipsa parametrului DEFAULT, valorile implicite ale
atributelor depind doar de tipul atributului (numerele reale
primesc valoarea implicit 0, irurile de caractere sunt iruri
vide etc).
Instruciunea de modificare a unui tabel (ALTER
TABLE) permite adaugrea sau tergerea unor atribute,
modificarea domeniilor unor atribute, precum i adugarea,
modificarea sau tergerea unor constrngeri ale tabelului. De
exemplu,
instruciunea de adugare a
atributului

40

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

DataAngajarii n tabelul ANGAJATI se scrie n felul

urmtor:
ALTER TABLE ANGAJATI ADD DataAngajarii date;

Pentru tergerea unui atribut (coloan) dintr-un tabel, n

instruciunea ALTER TABLE se folosete cuvntul-cheie
DROP. De exemplu, tergerea atributului Functie din tabelul
ANGAJAT se poate face cu comanda:
ALTER TABLE ANGAJATI DROP Functie;

Instruciunea de tergere a unui tabel este:

DROP TABLE nume_tabel.

2.1.4. Instruciunea SQL de manipulare a datelor

Instruciunea SELECT reprezint blocul de interogare de

baz i ea selecteaz informaiile dorite din tabelele bazei de
date. Instruciunea SELECT este foarte puternic i are
urmtoarea sintax general:
SELECT
[DISTINCT]
lista_coloane
lista_tabele [WHERE conditie]
[clauze_secundare];

FROM

Se remarc 3 seciuni (clauze) importante ale construciei

de interogare: clauza SELECT, clauza FROM i clauza WHERE.
Clauza SELECT introduce lista atributelor (coloanelor)
unor tabele sau al expresiilor care vor fi selectate i afiate.
Coloanele din list trebuie s aparin uneia din tabelele
specificate n clauza FROM.
Ca rezultat al instruciunii de mai sus se pot obine dou sau
mai multe linii identice, dac exist angajai cu acelai nume i
prenume. n general, dac lista de atribute nu conine o cheie a
relaiei, rezultatul operaiei SELECT poate conine linii
duplicat. Pentru eliminarea liniilor duplicat se introduce
parametrul DISTINCT i atunci rezultatul este o relaie n
sensul definiiei din modelul relaional.
Dac lista de atribute este un asterisc (*), atunci se
selecteaz toate atributele produsului cartezian al tabelelor
41

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

indicate prin clauza FROM, care ndeplinesc condiia din clauza

WHERE. n clauza SELECT se pot redenumi atributele (coloane
ale tabelelor) sau se pot specifica nume pentru expresii,
folosind urmtoarea sintax:
SELECT nume1 [AS] noul_nume1,..., expresie
[AS] nume_expresie
FROM lista_tabele [alte_clauze];

Se observ c noul nume atribuit unei coloane sau expresii

urmeaz vechiul nume al coloanei sau expresiei, precedat
(opional, depinznd de implementare) de cuvntul-cheie AS.
Clauza FROM este obligatorie dac ntr-una din clauzele
SELECT, WHERE, HAVING apar nume de atribute (coloane ale
unor tabele). n acest caz, lista de tabele care nsoete clauza
FROM trebuie s conin numele tuturor tabelelor (separate prin
virgul) ale cror coloane se folosesc. Dac lista conine mai
mult de un tabel, atunci numele coloanelor din clauza SELECT
trebuie s fie diferite, dac nu sunt diferite, atunci se calific
numele coloanei cu numele tabelului cruia i aparine
(precednd numele atributului cu numele tabelului urmat de
operatorul punct (.). De exemplu:
SELECT
ANGAJATI.Nume,Prenume,SECTII.Nume
FROM ANGAJATI,SECTII;
Clauza WHERE restricioneaz tuplurile returnate ca rezultat

la acele tupluri care ndeplinesc condiia introdus de aceast

clauz. n forma cea mai obinuit, clauza WHERE este urmat
de o condiie, dat ca o expresie boolean.
Clauza ORDER BY introduce numele atributului dup care
se face ordonarea liniilor rezultate.
Ordonarea este implicit n ordine cresctoare; dac numele
atributului este urmat de cuvntul DESC, ordonarea liniilor se
face n ordine descresctoare a valorilor acelui atribut.
Clauza GROUP BY se foloeste pentru a grupa rezultatele
funciilor agregat (totalizatoare) dup valoarea uneia sau mai
multor coloane. Dac se dorete calculul unei valori
42

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

totalizatoare separat, pe grupe de linii, atunci se introduce

clauza GROUP BY, urmat de numele uneia sau mai multor
coloane.
n acest caz, funcia totalizatoare se aplic separat acelor
linii care au aceeai valoare a atributelor listate de clauza
GROUP BY. De exemplu, salariul mediu calculat separat pe
grupe de angajai, fiecare grup fiind compus din linii care au
aceeai valoare a atributului Functie, se obine cu urmtoarea
comand SQL:
SELECT AVG(Salariu) FROM ANGAJATI GROUP
BY(Functie);
Clauza HAVING este asemntoare clauzei WHERE, adic

introduce o condiie pe care trebuie s o ndeplineasc tuplurile

rezultat, dar, n plus, permite utilizarea funciilor agregat n
expresia condiional. De exemplu:
SELECT Nume,Prenume FROM ANGAJATI HAVING
Salariu >= AVG(Salariu);
Instruciunea INSERT se folosete pentru introducerea

liniilor i are urmtoarea sintax:

INSERT INTOnume_tabel(coloana_1,coloana_2,...)
VALUES (valoare_1,valoare_2,...);

ntre valori i numele de coloane trebuie s existe o

coresponden unu la unu. Lista de coloane poate s lipseasc,
dac se introduc valori n toate coloanele tabelului, dar n
aceast situaie ordinea valorilor introduse trebuie s respecte
ordinea atributelor.
Instruciunea UPDATE permite actualizarea valorilor
coloanelor (atributelor) din una sau mai multe linii ale unui
tabel. Aceasta are sintaxa:
UPDATE nume_tabel
SET col_1 = expr_1, col_2 = expr_2,...
[WHERE conditie];
Clauza WHERE impune ca actualizarea valorilor coloanelor

s se efectueze numai asupra acelor linii (tupluri) care

ndeplinesc condiia dat. Dac este omis clauza WHERE,
43

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

atunci vor fi modificate valorile coloanelor din toate liniile

tabelului.
Instruciunea DELETE permite tergerea uneia sau mai
multor linii dintr-un tabel i are urmtoarea sintax:
DELETE FROM nume_tabel[WHERE conditie];

Din tabel se terg acele linii care ndeplinesc condiia dat

n clauza WHERE. Dac este omis clauza WHERE, atunci vor fi
terse toate liniile din tabel.
Integritatea referenial este proprietatea bazei de date
care garanteaz c oricare valoare a unei chei strine se
regsete printre valorile cheii candidate corespunztoare din
relaia referit, sau cheia strin are valoarea NULL. Operaiile
de modificare a strii unei relaii (introducerea, tergerea i
actualizarea tuplurilor relaiei) trebuie s fie efectuate astfel
nct s asigure meninerea integritii refereniale a bazei de
date.
Stabilirea modului de tergere sau de actualizare a
tuplurilor se face n comenzile SQL de creare sau modificare a
tabelelor, prin adugarea uneia din opiunile ON DELETE,
respectiv ON UPDATE, constrngerii de cheie strin. Valorile
posibile ale acestor opiuni sunt RESTRICT (pentru tergerea
restricionat) sau CASCADE (pentru tergerea n cascad);
valoarea RESTRICT este implicit. De exemplu, instruciunea
SQL de creare a tabelului ANGAJATI cu opiunea de tergere
n cascad pentru cheia strin IdSectie este:

2.2. Proiectarea bazelor de date relaionale

Proiectarea unei baze de date const din proiectarea

schemei conceptuale (logice) i fizice a acesteia, astfel nct s
rspund cerinelor utilizatorilor pentru un anumit set de
44

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

aplicaii. n general, se consider c proiectarea unei baze de

date se poate diviza n urmtoarele faze:
Colectarea i analiza cerinelor.
Proiectarea conceptual a bazei de date.
Alegerea unui SGBD.
Proiectarea logic a bazei de date.
Proiectarea fizic a bazei de date.
Cele cinci faze de proiectare enumerate mai sus nu se
desfaoar strict ntr-o singur secven.
n multe cazuri este necesar modificarea proiectului dintro faz iniial ntr-una din fazele ulterioare, pentru a se obine
rezultatele dorite. Aceste bucle de reacie ntre faze (sau n
interiorul unei faze) sunt, n general, frecvente n cursul
proiectrii unei baze de date.
nainte de a proiecta efectiv o baz de date, este necesar s
se cunoasc ce rezultate se ateapt utilizatorii poteniali s
obin de la baza de date respectiv i ce informaii primare
sunt disponibile pentru aceasta. De asemenea, este necesar s
se cunoasc ce aplicaii se vor efectua (aplicaii de gestiune a
stocurilor, aplicaii contabile, salarizare etc.).
2.2.1. Proiectarea conceptual a bazelor de date

faza de proiectare conceptual a bazelor de date se

proiecteaz schema conceptual i schemele externe ale bazei
de date.
Dei nu este obligatoriu, aceast faz se poate menine
independena de SGBD i produce un model de date de nivel
nalt, care va fi implementat dup transpunerea lui ntr-un
model de date specific. Chiar dac proiectanii pot porni direct
cu scheme conceptuale specifice unui anumit SGBD (care se
mai numesc i scheme logice), este totui recomandabil s se
realizeze mai nti schema conceptual de nivel nalt
independent de SGBD, deoarece aceasta este o descriere
stabil i inavuabil a bazei de date. Alegerea unui SGBD i
45

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

deciziile ulterioare de proiectare se pot schimba fr ca aceasta

s se schimbe.
Proiectul conceptual de nivel nalt se realizeaz pe baza
cerinelor definite n prima etapa de proiectare i se reprezint,
n general printr-o diagram Entitate-Asociere (extins).
Modelul Entitate-Asociere (Entity-Relationship Model)
este un model conceptual de nivel nalt al unei baze de date,
care definete mulimile de entiti i asocierile dintre ele, dar
nu impune nici un mod specific de structurare i prelucrare a
datelor. Elementele eseniale ale modelului Entitate-Asociere
sunt entitile (entities) i asocierile dintre acestea
(relationships).
O entitate (entity) este "orice poate fi identificat n mod
distinctiv"; o entitate se refer la un aspect al realitii obiective
care poate fi deosebit de restul universului i poate reprezenta
un obiect fizic, o activitate, un concept etc. Orice entitate este
descris prin atributele sale. Un atribut (attribute ) este o
proprietate care descrie un anumit aspect al unei entiti.
Toate entitile similare, care pot fi descrise prin aceleai
atribute, aparin unui acelai tip de entitate (entity type), iar
colecia tuturor entitilor de acelai tip dintr-o baz de date
constitue o mulime de entiti (entities set). n general, n
modelul E-A se folosete aceeai denumire att pentru un tip de
entitate ct i pentru mulimea entitilor de acel tip.
De exemplu, tipul de entitate angajat (al unei instituii)
reprezint orice persoan angajat a instituiei, care are o
anumit funcie i primete un anumit salariu. Acest tip de
entitate poate fi descris prin mai multe atribute, dintre care o
parte sunt
atribute
de identificare
a persoanei
(Nume,Prenume,DataNasterii,Adresa), iar altele sunt
atribute legate de activitatea acesteia n instituia respectiv
(Functie,Salariu).

46

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

n proiectarea bazelor de date se consider dou categorii

de entiti: entiti normale (puternice, obinuite - regular
entities) i entiti slabe (dependente - weak entities).
Entitile normale au o existen proprie n cadrul
modelului, n timp ce entitile slabe nu pot exista dect dac
exist o entitate normal (puternic) cu care sunt asociate. De
exemplu, o entitate dependent poate s reprezinte o persoan
care depinde de un angajat al unei instituii (adic se afl n
ntreinerea acestuia). O entitate angajat este o entitate
puternic, deoarece ea exist n mod normal n modelul
activitii instituiei, n timp ce o entitate dependent este o
entitate slab: nu se va nregistra o astfel de persoan dect
dac printele (susintorul) acesteia este angajat n acea
instituie.
O asociere (relationship ), este o coresponden ntre
entiti din dou sau mai multe mulimi de entiti. Gradul unei
asocieri este dat de numrul de mulimi de entiti asociate.
Asocierile pot fi binare (de gradul 2, ntre 2 mulimi de entiti)
sau multiple (ntre k mulimi de entiti, k > 2).
Asocierile binare sunt, la rndul lor, de trei categorii, dup
numrul elementelor din fiecare dintre cele dou mulimi puse
n coresponden de asocierea respectiv. Fiind date dou
mulimi de entiti, E1 i E2, se definesc urmtoarele categorii
de asocieri binare:
Asocierea unul-la-unul (one-to-one), este asocierea
prin care unui element (entitate) din mulimea E1 i corespunde
un singur element din mulimea E2 i reciproc; se noteaz cu
1:1.
Asocierea unul-la-multe (one-to-many), este asocierea
prin care unui element din mulimea E1 i corespund unul sau
mai multe elemente din mulimea E2, dar unui element din E2
i corespunde un singur element n mulimea E1; se noteaz cu
1:N.

47

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Asocierea multe-la-multe (many-to-many), este

asocierea prin care unui element din mulimea E1 i corespund
unul sau mai multe elemente din mulimea E2 i reciproc; se
noteaz cu M:N.
O asociere ntre dou sau mai multe mulimi de entiti este,
n acelai timp, o asociere ntre tipurile de entiti
corespunztoare.
Diagrama
Entitate-Asociere
(Entity-Relationship
Diagram) reprezint modelul Entitate-Asociere prin mulimile
de entiti i asocierile dintre acestea.
Exist numeroase variante de notaii pentru redarea
diagramei E-A. Una dintre cele mai folosite notaii reprezint
un tip de entitate (precum i mulimea de entiti de acel tip)
printr-un dreptunghi, iar atributele tipului de entitate prin elipse
conectate printr-o linie continu la acesta (Fig. 2.1). Pentru
entitile puternice se utilizeaz un dreptunghi ncadrat cu o
linie simpl, iar pentru entitile slabe se utilizeaz un
dreptunghi ncadrat cu linie dubl.
O asociere (tip de asociere) dintre dou sau mai multe
tipuri de entiti se reprezint printr-un romb conectat prin linkuri (linii continue, formate din unul sau mai multe segmente) la
tipurile de entiti asociate. O asociere poate s aib sau nu, un
nume; dac are un nume, acesta poate fi nscris n rombul
respectiv sau n vecintatea acestuia. Categoria asocierii se
noteaz prin nscrierea multiplicitii pe fiecare link care
conduce la un tip de entitate. Este posibil ca o asociere s
prezinte ea nsi atribute i aceste atribute se reprezint prin
elipse conectate la asocierea respectiv.
Modelul Entitate -Asociere Extins (Enhanced EntityRelationship Model), permite definirea de subtipuri ale unui tip
de entiti, care motenesc atribute de la tipul de entitate pe
care l extind (n acest context, se numete supertip) i au n
plus atribute specifice semnificaiei lor. Prin definirea tipurilor
i a subtipurilor de entiti se pot crea ierarhii de tipuri de
48

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

entiti pe mai multe niveluri. Modelul Entitate-Asociere Extins

se reprezint printr-o diagram E-A extins, n care legtura
ntre un supertip de entiti i subtipurile acestuia se reprezint
printr-o linie pe care se plaseaz un semicerc ndreptat ctre
supertip (Fig. 2.1).
Exemplu de model Entitate-Asociere. Se consider o baz
de date a unei intreprinderi. Tipurile de entiti puternice
(normale) care se pot defini pentru modelarea activitii unei
intreprinderi pot fi:
SECTII, ANGAJATI, FURNIZORI, CLIENTI, PRODUSE,
COMPONENTE (Fig. 2.1) :
SECTII(Nume,Buget)
ANGAJATI(Nume,Prenume,DataNasterii,Adresa,Func
tie,Salariu)
FURNIZORI(Nume,Prenume,Adresa)
CLIENTI(Nume,Prenume,Adresa)
PRODUSE(Denumire,Descriere)
COMPONENTE(Denumire,Descriere)

La aceste mulimi de entiti se adaug mulimea de entiti

slabe:
DEPENDENTI(Nume,Prenume,DataNasterii,GradRuden
ie)

Fig. 2.1 Diagrama E-A a bazei de date a unei intreprinderi.

49

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Pentru tipul ANGAJATI se definete o specializare

disjunct parial, cu subtipurile INGINERI i SECRETARE.
Aceste subtipuri se afl n asociere 1:1 cu tipul de baz
ANGAJATI, motenesc atributele acestuia i fiecare mai conine
atribute specifice:
INGINERI(Specialitatea)
SECRETARE(VitezaRedactare)

Asocierile dintre mulimile de entiti se stabilesc n funcie

de modul n care se desfoar activitatea modelat. De
exemplu, dac n ntreprinderea respectiv fiecare angajat
lucreaz ntr-o singur secie, atunci ntre mulimile de entiti
SECTII-ANGAJATI exist o asociere 1:N.
O mulime de entiti slabe se afl, de regul, n asociere
N:1 cu mulimea de entiti puternice de care depinde. n
exemplul dat, ntre mulimea DEPENDENTI i mulimea de
entiti ANGAJATI exist o asociere N:1. O mulime de entiti
de un subtip dat este, de regul, n asociere 1:1 cu mulimea de
entiti de supertipul acesteia. Pentru exemplul de mai sus, un
angajat poate fi un (singur) inginer; iar un inginer este chiar un
angajat, deci asocierea ntre mulimile de entiti ANGAJATI i
INGINERI exist o asociere cu raportul de cardinalitate 1:1.
2.2.2. Proiectarea logic a bazelor de date

faza de proiectare logic a unei baze de date se

realizeaz schema conceptual global i schemele conceptuale
(vederile) externe pentru SGBD ales, pornind de la schema
conceptual i schemele externe de nivel nalt independente de
SGBD, proiectate n faza precedent.
Aceast faz de proiectare logic poate fi realizat n dou
sub-faze: transpunerea schemei conceptuale n modelul de date
al SGBD ales, dar independent de sistemul de gestiune propriuzis i rafinarea schemei conceptuale i a schemelor externe
obinute anterior, astfel nct s se utilizeze unele (sau ct mai
50

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

multe) din facilitile oferite de SGBD ales (modul de generare

a cheilor primare, definirea constrngerilor etc.).
Aceste dou sub-faze se pot realiza mpreun, folosind unul
din instrumentele de proiectare oferite de SGBD ales.
Rezultatul acestei faze de proiectare l constituie, aadar,
schema conceptual i schemele externe ale bazei de date,
dependente de SGBD ales i de modelul de date al acestuia.
Pentru transpunerea modelului Entitate-Asociere (reprezentat
prin diagrama E-A) n model relaional se parcurg n principal
dou etape: proiectarea relaiilor i proiectarea asocierilor.
Proiectarea relaiilor. n Fig. 2.2 este dat schema
conceptual a bazei de date relaionale corespunztoare
diagramei E-A din Fig. 2.1, dezvoltat n MS Access. n MS
Access relaiile i asocierile ntre ele sunt reprezentate vizual n
diagrama de asocieri (Relationships), care este corespondentul
relaional al diagramei E-A.
Mulimile de entiti puternice (normale) din diagrama E-A
devin relaii, cu atributele date de atributele entitilor. n astfel
de relaii cheia primar se definete fie ca o cheie natural
(combinaie de atribute care definesc n mod unic un tuplu al
relaiei), fie ca o cheie primar artificial. n exemplul
prezentat, n fiecare din relaiile care corespund mulimilor de
entiti puternice s-a adaugat cte o cheie primar artificial
(IdAngajat,IdSectie,IdProiect etc.).
Mulimile de entiti slabe din diagrama E-A devin, de
regul, relaii aflate n asociere N:1 cu relaia coresunztoare
mulimii de entiti de care acestea depind. Pentru realizarea
acestei asocieri, n relaia dependen se adaug o cheie strin
care refer cheia primar a relaiei referite (puternice).
Cheia primar a unei relaii dependente poate fi o
combinaie format din atributul cheie strin i alte atribute
care asigur posibilitatea de identificare unic a unui tuplu, sau
poate fi o cheie artificial. Cheia primar a relaiei
DEPENDENTI este compus din atributul cheie strin
51

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

(IdAngajat, care refer cheia primar a relaiei ANGAJATI) i

atributele Nume i Prenume (ale persoanei dependente).
Mulimile de entiti care sunt subtipuri ale unui tip de
entitate dat devin relaii aflate n asociere 1:1 cu relaia
corespunztoare mulimii de entiti de tipul respectiv
(supertip). Pentru realizarea acestei asocieri, n relaia
corespunztoare subtipului de entiti se definete o cheie
strin care refer cheia primar din relaia corespunztoare
supertipului de entiti; aceast cheie strin este n acelai
timp i cheie primar n relaia corespunztoare subtipului de
entiti.

Fig. 2.2 Diagrama bazei de date INTREPRINDERE n MS Access.

n exemplul prezentat, asocierile ANGAJATI-INGINERI si

ANGAJATI-SECRETARE
sunt asocieri 1:1. n relaia
INGINERI atributul IdAngajat este cheie strin care refer
cheia primar cu acelai nume din relaia ANGAJATI i este n
52

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

acelai timp i cheie primar; la fel, n relaia SECRETARE

atributul IdAngajat este cheie strin care refer cheia
primar cu acelai nume din relaia ANGAJATI i este n
acelai timp i cheie primar.
Proiectarea asocierilor. Asocierea binar N:1 dintre dou
mulimi de entiti puternice din diagrama E-A se realizeaz n
modelul relaional prin intermediul unei chei strine n prima
relaie (cea cu multiplicitatea N a asocierii) care refer cheia
primar (sau o cheie candidat) din relaia referit (cea cu
multiplicitatea 1 a asocierii). De exemplu, asocierea N:1 ntre
relaiile ANGAJATISECTII se realizeaz prin cheia strin
IdSectie adaugat relaiei ANGAJATI, care refer cheia
primar cu acelai nume a relaiei SECTII.
Asocierea binar M:N dintre dou mulimi de entiti din
diagrama E-A se realizeaz n modelul relaional prin
intermediul unei noi relaii, numit relaie de asociere. Aceast
nou relaie se afl n asociere M:1, respectiv N:1 cu fiecare
din cele dou relaii date prin intermediul a dou chei strine
care refer cheile primare (sau cheile candidate) din relaiile
date.
De exemplu, pentru a reprezenta asocierea M:N dintre
relaiile COMPONENTE-PRODUSE se adaug o nou relaie
numit COMPOZITII, care conine cheile strine
IdComponenta i IdProdus, care refer cheile primare cu
acelai nume din relaiile COMPONENTE, respectiv PRODUSE.
Cheia primar a unei relaii de asociere poate fi o cheie
artificial sau poate fi compus din cheile strine care refer
cele dou relaii asociate, eventual l mpreun cu alte atribute
ale relaiei, care caracterizeaz asocierea respectiv. Aa cum
se poate vedea n Fig. 2.2, cheia primar a relaiei
COMPOZITII este format din cele dou chei strine pe care le
conine.
Asocierea binar 1:1 ntre dou mulimi de entiti
puternice se poate transpune n modelul relaional n dou
53

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

moduri: fie prin intermediul unei chei strine (ca un caz

particular al unei asocieri N:1), fie printr-o relaie de asociere
(ca un caz particular al unei asocieri M:N).
Asocierea binar 1:1 dintre o mulime de entiti de un
subtip i mulimea de entiti supertip din diagrama EntitateAsociere este tot o asociere binar cu raportul de
cardinalitate1:1 ntre relaiile corespunztoare n modelul
relaional. Acest tip de asociere se realizeaz prin definirea n
relaia corespunztoare subtipului de entiti a unei chei strine
care refer cheia primar din relaia corespunztoare
supertipului de entiti; aceast cheie strin este n acelai
timp i cheie primar n relaia corespunztoare subtipului de
entiti. Acest mod de definire a fost folosit pentru asocierea
dintre tabelele INGINERI, SECRETARE i tabelul ANGAJATI.
Asocierea multipl M:N:P:. dintre mai mult de dou
mulimi de entiti din diagrama E-A se realizeaz n mod
asemntor cu asocierea binar, prin intermediul unei noi
relaii care se afl n asociere M:1, N:1, P:1 etc, cu fiecare din
relaiile date. Aceast asociere este realizat prin intermediul
mai multor chei strine, fiecare cheie strin referind cheia
primar (sau o cheie candidat) dintr-una din relaiile date. De
exemplu, relaia ACHIZITII realizeaz asocierea ntre
relaiile COMPONENTE, FURNIZORI, ANGAJATI. Ea conine trei
chei strine (IdComponenta, IdFurnizor, IdAchizitor)
care refer relaiile COMPONENTE, FURNIZORI, respectiv
ANGAJATI, iar cheia primar este cheia artificial
IdAchizitie.
2.2.3. Proiectarea fizic a bazelor de date

Proiectarea fizic a bazei de date este procesul de alegere a

structurilor de memorare i de acces la fiierele bazei de date,
pentru a obine performane ct mai bune, pentru ct mai multe
din aplicaiile proiectate. Ca parametri generali de alegere a
opiunilor proiectului fizic al unei baze de date relaionale se
54

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

pot enumera: timpul de rspuns, utilizarea spaiului de

memorare, capacitatea tranzacional. Deciziile de proiectare
fizic se pot lua numai dup o analiz a aplicaiilor care se vor
executa i n principal a interogrilor i tranzaciilor pe care
acestea le vor lansa. n urma analizei se pot sintetiza informaii
care s dea imaginea de ansamblu a utilizrii atributelor
relaiilor bazei de date: care atribute sunt actualizate cel mai
frecvent, care atribute sunt folosite cel mai frecvent n selecii
ale interogrilor etc. Aceste informaii se folosesc pentru
stabilirea indexurilor secundare ale relaiilor.
2.3. Particularitile limbajului SQL i de proiectare a
bazelor de date n diferite SGBD

Majoritatea SGBD relaionale actuale suport standardul

SQL2, dar fiecare implementeaz, de fapt, un dialect specific al
limbajului SQL. n diferitele implementri ale limbajului SQL
pot s lipseasc unele comenzi prevzute n standardul SQL2,
dar pot exista extensii specifice, neprevzute n standard, care
micoreaz gradul de portabilitate a aplicaiilor. n continuare
sunt prezentate particularitile limbajului SQL i de proiectare
a bazelor de date n diferite SGBD.
2.3.1. Sistemul SQL Server

Sistemul SQL Server poate executa programe n limbajul

SQL sau n limbajul Transact-SQL, care este extensia
procedural a limbajului SQL. Limbajul Transact-SQL conine
instruciuni SQL (asemntoare celor specificate n standardul
SQL2) precum i instruciuni de control al execuiei (care vor fi
prezentate n Capitolul 4). Instruciunile Transact-SQL se
transmit sistemului grupate n loturi de execuie (batches), prin
intermediul programelor de aplicaii sau al programelor
utilitare osql sau Query Analizer.

55

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Proiectarea tabelelor se poate face att vizual, folosind

generatoarele de cod (Wizards) ale programului utilitar SQL
Server Enterprise Manager, ct i prin comenzi (grupate n
scripturi) care conin loturi de execuie Transact-SQL,
executate de la consol (folosind utilitarul osql) sau din
programul Query Analyzer. Proiectarea vizual a tabelelor se
poate face n programul SQL Server Enterprise Manager. La
comanda New Table, care se acioneaz din meniul contextual
care se deschide la apsarea butonului dreapta al mouse-ului
atunci cnd este selectat directorul Tables al bazei de date
proprii, se deschide o fereastr de proiectare foarte
asemntoare cu cea din MS Access, cu unele diferene (Fig.
2.3). La definirea cheii primare se poate specifica proprietatea
de autoincrementare cu opiunea IDENTITY, care este
echivalent cu opiunea AutoNumber din MS Access, dar, n
plus, aceast opiune permite specificarea valorii de nceput a
secvenei de numere cresctoare (Identity Seed), i valoarea de
incrementare (Identity Increment) care este implicit 1.

Fig. 2.3 Fereastra de proiectare a unui tabel folosind SQL Server Enterprise
Manager.
56

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Asocierea ntre relaii se stabilete prin comanda New

Database Diagram din meniul contextual care se deschide la
apsarea butonului dreapta al mouse-ului atunci cnd este
selectat subdirectorul Diagrams al bazei de date. La aceast
comand se deschide o fereastr de proiectare a asocierilor
asemntoare cu cea din MS Access (Relationships), prin care
se stabilesc cheile strine i modul de referire ntre relaii.
Scripturile de comenzi n SQL Server conin loturi de
execuie Transact-SQL i pot fi executate prin intermediul unor
programe utilitare, cum sunt osq sau Query Analyzer. Pentru
detalii privind folosirea acestor programe este necesar, s fie
studiat documentaia oferit de furnizor (Books Online).
Pentru exemplificare se prezint scriptul de creare a tabelelor
SECTII, ANGAJATI n baza de date proprie din sistemul SQL
Server (fiier creare_tabele_sqlserver.sql).

57

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

La inserarea liniilor n tabele (cu instruciuni INSERT), nu

se admite precizarea valorii pentru un atribut cheie primar de
tip
IDENTITY.
Dac
se
execut
fiierul
introducere_sqlserver.sql pentru introducerea unor
linii n tabelele SECTII i ANGAJATI, se va observa c liniile
n care se specific valoarea cheii primare nu sunt admise
(produc eroare de execuie).

Sistemul efectueaz verificarea cheilor strine i nu admite

tupluri care conin o cheie strin a crui valoare nu se
regsete n nicio valoare a cheii primare referite (Fig. 2.4).
Cheile primare au fost definite de tipul IDENTITY, care
este un atribut cu autoincrementare, iar cheia strin din tabelul
58

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

ANGAJATI s-a definit printr-o instruciune ALTER TABLE.

Aceast modalitate este frecvent folosit, deoarece permite

crearea tabelelor n orice ordine i adugarea dup aceea a
cheilor strine. Dac s-ar fi dorit definirea cheii strine chiar n
instruciunea CREATE TABLE ANGAJATI, atunci relaia
referit (n acest caz relaia SECTII) ar fi trebuit s fie definit
naintea relaiei care refer (n acest caz relaia ANGAJATI). La
proiectarea unei baze de date mari, cu multe relaii i referiri
ntre ele, este destul de dificil de stabilit ordinea complet de
referiri ntre tabele i de aceea se prefer definirea separat a
cheilor strine, prin instruciuni ALTER TABLE.
n pagina de afiare Messages se gsesc mesajele de eroare
returnate de sistemul de gestiune.
La execuia instruciunilor din fereastra de interogri din
Fig. 2.4 se obin urmtoarele mesaje:
Cannot insert explicit value for
column in table 'ANGAJATI'
when IDENTITY_INSERT is set to OFF.

identity

INSERT
statement
conflicted
with
COLUMN
FOREIGN KEY constraint
'FK_ANGAJATI'.
The
conflict
occurred
in
database 'Intreprindere',
table 'SECTII', column 'IdSectie'.

Primul mesaj se refer la faptul c nu se admit valori

explicite pentru o cheie cu proprietatea IDENTITY dect dac
se seteaz la ON
proprietatea IDENTITY_INSERT.
Instruciunea Transact-SQL care seteaz aceast proprietate
este:
SET
IDENTITY_INSERT
{table}{ON|OFF}

[database.[owner.]]

Cel de-al doilea mesaj se refer la faptul c nu se admit

tupluri care nu respect integritatea referenial (egalitatea
valorii cheii strine cu o valoare a cheii primare din relaia
referit).
59

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Fig. 2.4. Afiarea liniilor inserate n tabelul ANGAJATI n SQL Server Query
Analyzer.

2.3.2. Sistemul MS Access

Sistemul MS Access ofer o interfa grafic de proiectare

a bazelor de date, cu mai multe instrumente software de
generare a tabelelor, asocierilor, formularelor etc.
Pentru crearea sau modificarea tabelelor, n fereastra
Database, se selecteaz comanda Tables care afieaz panoul
cu toate tabelele existente. La comanda de creare a unui tabel
nou (comanda New), se deschide o fereastr de dialog (New
Table) n care sunt prezentate mai multe opiuni de afiare i
creare:
Datasheet View prezint o foaie de calcul alb n care se
introduc valorile datelor. Dac nu se definesc tipurile de date n
modul de afiare Design, programul MS Access le asigneaz
singur.
Design View este o gril n care se pot selecta definiiile
datelor din diferite liste; n acest mod de afiare nu se introduce
n mod explicit nici o dat.
Table Wizard este un program expert care, dup alegerea
unei baze de date predefinite, conduce procesul de selectare a
cmpurilor i de stabilire a cheilor i a sistemului de asocieri.
60

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Import Table este o metod folosit pentru a importa un

tabel de date dintr-un alt fiier, creat n programul MS Access
sau ntr-o alt aplicaie de baza de date care este recunoscut de
ctre Access.
Link Table opereaz la fel ca metoda anterioar, dar
datele externe ramn n fiierul extern.
Atunci cnd se creaz un tabel nou n modul de afiare
Design View, pe ecran apare o fereastr care are n partea
superioar "grila de cmpuri" (Field Grid) - locul n care se
introduc numele i se specific tipul cmpurilor (coloanelor)
care vor alctui tabelul. Panoul din partea de jos, denumit
"proprietile cmpurilor" (Field Properties), permite
modificarea proprietilor fiecrui cmp (coloan) din tabel. Un
nou cmp ntr-un tabel se creaz astfel:
Se introduce un nume n coloana Field Name.
Se selecteaz un tip de date n coloana Data Type din
caseta combinat corespunztoare.
Opional se poate introduce n coloana Description un
comentariu care descrie modul de utilizare a cmpului.
La nchiderea ferestrei modului de afiare Design View,
sistemul MS Access salveaz modificrile efectuate n tabelul
original, n cazul editrii unui tabel existent sau solicit
introducerea unui nume pentru tabelul nou creat.
Tipul de date selectat pentru fiecare cmp n parte
determin modul de stocare folosit de MS Access. De aceea,
selectarea tipului corect de date pentru fiecare cmp este un
element important n vederea obinerii unor informaii corecte
din baza de date. n aplicaie se pot folosi tipurile de date Text
(un ir de max. 50 caractere), Number (un numr ntreg sau n
virgul mobil), Date/Time, AutoNumber (un numr ntreg
care este incrementat automat pe msur ce sunt introduse noi
nregistrri ntr-un tabel, folosit ca i cheie primar).
Pentru fiecare tabel trebuie s fie specificat cheia primar
(Primary Key) care este o submulime a cmpurilor
61

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

(coloanelor) tabelei cu proprietatea c are valoare unic pentru

fiecare din rndurile (tuplurile) tabelului. Cheia primar se
poate stabili pe unul sau mai multe cmpuri, prin selectarea
acestora i acionarea comenzii Primary Key din bara de
instrumente (care are ca pictogram o cheie de lact).
Celelalte proprieti ale unui cmp din tabel se stabilesc n
panoul Field Properties i depind de tipul de date al acestuia i
de calitatea de a aparine cheii primare sau nu. Toate tipurile de
date prezint mai multe proprieti (opiuni), dintre care unele
pot fi configurate. n general, opiunile prestabilite de sistemul
MS Access sunt satisfctoare pentru cele mai multe cmpuri
de date i numele lor sunt suficient de explicative. O atenie
mai deosebit trebuie s fie acordat proprietilor: "cmp
cerut" (Required), "admite lungime zero" (Allow Zero Length)
i "cmp indexat" (Indexed).
Un cmp pentru care se selecteaz opiunea Yes pentru
proprietatea Required este un cmp n care nu se admit valori
NULL; dac se selectez opiunea No, atunci valoarea acestui
cmp poate s fie specificat sau nu, nespecificarea valorii
nsemnnd o valoare de NULL pentru acel cmp.
Proprietatea Allow Zero Length este prezent numai pentru
tipul de date Text. Optiunea Yes pentru aceast proprietate
valideaz acceptarea unui text de lungime zero, iar opiunea No
invalideaz un text de lungime zero.
O alt proprietate a cmpurilor care poate fi configurat
este proprietatea Indexed. Dac se selecteaz opiunea No,
atunci cmpul nu este indexat. Dac se selecteaz una din
optiunile Yes(No Duplicates) sau Yes (Duplicates OK) sistemul
MS Access creaz un index (o structur de date diferit de
tabelul nsui), care este folosit pentru cutarea rapid a
nregistrrilor dup valoarea acelui cmp.
Atunci cnd nu se admit duplicate, trebuie ca valorile din
cmpul indexat s fie unice n nregistrrile tabelului. Acest
lucru se asigur automat dac acel cmp este cheie primar;
62

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

dac acel cmp nu este cheie primar, atunci valorile introduse

sunt verificate i se rejecteaz acele nregistrri care au valori
duplicat n cmpul astfel indexat. Pentru un cmp care
constituie singur cheia primar, se atribuie n mod automat un
index far duplicate.
Cheile strine permit stabilirea asocierilor ntre tabele i n
MS Access se definesc n dou etape. n prima etap, la crearea
tabelelor, cmpurile (sau cmpul) care vor constitui cheia
strin trebuie s fie definite de acelai tip de date (cu acelai
domeniu) ca i cmpurile corespunztoare din cheia primar
din tabela pe care o refer. Dup definirea tabelelor (tabelele
referite i tabelele care refer), se folosete comanda de meniu
Tools/Relationships (sau comanda Relationships din bara de
instrumente, care are o pictogram reprezentnd un arbore)
pentru a defini asocierile i deci cheile strine ntre tabele.
La acionarea comenzii Relationships, programul Access
afieaz o fereastr numit Relationships i mai multe comenzi
de meniu asociate acestei ferestre. n fereastra Relationships
sunt reprezentate tabelele asociate, fiecare tabel avnd toate
cmpurile definite, iar o asociere este reprezentat printr-un
link (conexiune) ntre dou tabele, n dreptul atributelor
(cmpurilor) corespundente. Tabelele afiate pot fi rearanjate n
cadrul ferestrei trgndu-le cu mouse-ul (Fig. 2.5).
Pentru a crea o nou asociere ntre dou tabele, se parcurg
urmtorii pasi:
1. Se adaug n fereastra Relationships tabelele ntre care se
dorete crearea de asocieri.
Pentru aceasta se acioneaz comanda Show Table din
meniul Relationships sau din meniul contextual, obinut prin
click pe butonul dreapta al mousului n fereastra Relationships.
La aceast comand, se deschide nc o fereastr, cu titlul Show
Table , care listeaz toate tabelele definite. Se selecteaz una
sau mai multe tabele i se d comanda Add, care introduce

63

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

tabelele selectate n fereastra Relationship . Dup aceasta,

fereastra Show Table poate fi nchis (cu comanda Close).
2. Cheile primare din fiecare tabel sunt afiate cu caractere
ngroate. Cu mouse-ul, se trage numele cheii primare din
tabela refereniat peste numele cmpului corespunztor cheii
strine sau cheii primare din tabela care refereniaz. Va fi
afiat o nou fereastr Relationships, care permite stabilirea
unor opiuni de asociere ntre tabele. Prin acest mecanism, se
definesc att asocieri 1:1 ct i asocieri 1:N. Link-ul de
conectare ntre dou tabele asociate are eticheta 1 pe captul
dinspre tabela refereniat (care conine cheia primar) i
eticheta pe captul dinspre tabela care refereniaz (care
conine cheia strin).
3. n fereastra Relationships (Fig. 2.5) apar numele
cmpurilor care au fost asociate. n majoritatea situaiilor, se
recomand selectarea casetei de validare Enforce Referential
Integrity (foreaz integritatea referenial), ceea ce impune
verificarea condiiei de integritate referenial, adic pentru
cheia strin din tabela care refereniaz nu se admit dect
valori care exist n cheia primar dintr-un tuplu (linie) din
tabela refereniat.
4. n fereastra de editare a unei asocieri Relationships se
mai poate valida opiunea de "actualizare n cascad" a
cmpurilor corelate prin referire (Cascade Update Related
Fields) i opiunea de "tergere n cascad" a cmpurilor
corelate prin refereniere (Cascade Delete Related Fields).
Comanda Join Type (Tipul de cuplare) permite stabilirea
tipului de cuplare (join) ntre tabele. La acionarea acestei,
comenzi se deschide o fereastr de dialog modal (Join
Propeerties) prin care se poate selecta unul din trei tipuri de
operaii de cuplare. Prima opiune este cea implicit (cuplare
intern - internal join ), este cea mai frecvent utilizat; celelalte
dou tipuri (cuplri externe la dreapta sau la stnga) pot fi
studiate din documentaia MS Access (Help).
64

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Fig. 2.5 Crearea unei asocieri ntre dou tabele n MS Access.

2.3.3. Sistemul Oracle

sistemul Oracle proiectarea bazelor de date se poate

realiza prin comenzi SQL transmise serverului din programele
de aplicaii sau prin intermediul unor programe utilitare (SQL*
Plus, SQL* Plus Worksheet i altele).
n Oracle, pentru generarea valorilor unei chei primare
artificiale se creeaz o secven (cu comanda CREATE
SEQUENCE) i la fiecare apel al metodei NEXTVAL al secvenei
se obine urmtoarea valoare din succesiunea de numere ntregi
generate. Pentru crearea tabelelor ANGAJATI i SECTII se
lanseaz execuia n SQL* Plus Worksheet a fiierului
creare_tabele_oracle.sql de mai jos:

65

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

La introducerea datelor ntr-un tabel se apeleaz metoda

NEXTVAL a secvenei cheii primare a tabelului respectiv. De
exemplu, introducerea unor linii n tabelele SECTII i
ANGAJATI se realizeaz cu scriptul de mai jos:

66

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Dup introducerea acestor linii, se poate observa coninutul

tabelului ANGAJATI cu comanda SELECT *FROM ANGAJATI;
executat n Oracle SQL* Plus Worksheet (Fig. 2.6).

Fig. 2.6 Afiarea coninutului tabelului ANGAJATI n Oracle SQL* Plus

Worksheet.

67

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

n Oracle se impune introducerea valorilor pentru atributele

cheii primare i aceste valori se extrag, de regul, din secvene.
Nu este recomandabil s se amestece valori generate de
secvene cu alte valori, deoarece nu exist garania c nu vor
avea loc suprapuneri, ceea ce conduce la refuzarea inserrii
tuplurilor care au valoare duplicat a cheii primare.
2.3.4. Sistemul MySQL

Limbajul SQL implementat n sistemul MySQL respect

majoritatea caracteristicilor standardului SQL2, iar aceast
coresponden se mbuntete de la o versiune la alta.
Instruciunile SQL de definire i manipulare a datelor se pot
introduce de la monitorul mysql direct (de la tastatur), sau
folosind fiiere de script lansate n execuie cu comanda
source nume_fisier. La definirea unei tabel (cu
instruciunea CREATE TABLE) se poate stabili cheia primar
printr-un atribut dat ca numr ntreg (int) cu proprietatea de
autoincrementare (AUTO_INCREMENT), ceea ce asigur
unicitatea cheii n cadrul relaiei. Considernd c a fost deja
creat un utilizator (cu numele user1) i o baz de date a
acestuia (cu acelai nume, user1) se lanseaz monitorul
mysql cu comanda: C:\ mysql -u user1 p user1

68

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

La promptul monitorului mysql se pot introduce comenzile

de creare a tabelelor manual sau executnd fiierul de script
creare_tabele_mysql.sql:
mysql> source creare_tabele_mysql.sql;

n fiierul script se nscriu cu un editor de text oarecare

instruciunile de creare a tabelelor. De exemplu, pentru fiierul
creare_tabele_mysql.sql poate avea urmtorul coninut:

Aceste comenzi terg mai nti tabelele ANGAJATI i

SECTII (dac exist), dup care le creeaz conform definiiei,
iar n tabelul ANGAJATI se adaug un atribut nou (IdSectie,
care este cheie strin) folosind comanda ALTARE TABLE. Se
observ modul de introducere a proprietii AUTO_INCREMENT
pentru cheile primare n cele dou tabele i a cheii strine n
tabelul ANGAJATI.
n MySQL, tabelele unei baze de date se pot afia cu
comanda SHOW TABLES, iar structura fiecrui tabel existent se
poate afla cu comanda DESCRIBE nume_tabel. De exemplu,
dup execuia comenzii: source creare_tabele_mysql.
sql, se pot obine urmtoarele informaii despre baza de date
curent:
69

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Constrngerea de cheie strin (FOREIGN KEY) este

acceptat din punct de vedere sintactic n orice instruciune
CREATE TABLE sau ALTER TABLE, dar nu are efect de a
impune integritatea referenial dect dac tabelul se creaz de
tipul InnoDB. Pentru a nelege aceast caracteristic a
sistemului MySQL se recomand studierea manualului de
documentaie al produsului.
Pentru crearea tuturor tabelelor bazei de date se poate
completa fiierul script creare_tabele_mysql.sql.
La introducerea liniilor n tabelele n care cheia primar are
proprietatea AUTO_INCREMENT se poate s nu se specifice
valoarea atributului cheii primare i aceasta este setat automat
de ctre sistemul de gestiune, cu valoarea urmtoare
(incrementat cu 1) fa de cea mai mare valoare a cheii
primare existente n tabel. Pentru exemplificare, se nscriu mai
multe linii n tabelele SECTII i ANGAJATI (executnd
fiierul introducere_mysql.sql:

70

Cap.2 Limbajul SQL - Proiectarea bazelor de date relaionale

Dup execuia acestor comenzi, tabelul SECTII conine un

singur tuplu (1, Productie, 4000000) iar tabelul
ANGAJATI va arta astfel:

Se poate observa c sistemul MySQL nu efectueaz nici o

verificare a cheilor strine: a fost introdus n tabelul ANGAJATI
un tuplu care conine o valoare a cheii strine (valoarea 2) care
nu exista n tabelul referit (SECTII). Este evident c sistemul
de gestiune MySQL nu asigur verificarea i impunerea
integritii refereniale i acest aspect trebuie s fie avut n
vedere la proiectarea aplicaiilor. Pentru meninerea integritii
refereniale tabelele trebuie s fie definite de tip InnoDB.

71