Curs Baze de Date

Paul IACOB
1
Introducere

Aplicaii tradiionale bazate pe fiiere; limitri
Pentru o mai bun nelegere a evoluiei prelucrrilor de date vom rezerva cteva
rnduri la nceputul cursului nostru pentru o scurt trecere n revist a metodelor tradiionale
de prelucrare a masivelor de date, aa-numitele sisteme tradiionale bazate pe fiiere.
n primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfrit calcule
laborioase n care nu erau implicate cantiti prea mari de date, aa-numitele calcule
tiinifice. Odat cu apariia limbajelor de nivel nalt i a posibilitii stocrii de mari cantiti
de informaie pe suport magnetic adresabil (memorie externa) s-a pus i problema
eficientizrii prelucrrii acestora. De data aceasta nu calculele creteau costul n timp al
prelucrrilor ci manipularea datelor, respectiv regsirea, actualizarea, etc. S-a constatat c un
factor important al creterii eficienei prelucrrilor este modul de organizare al informaiilor.
De aici i pn la a gndi sisteme unitare de reprezentare i manipulare a masivelor de date n-
a mai fost dect un pas.
Prima variant de prelucrare a cantitilor mari de informaie s-a bazat pe organizarea
datelor sub forma nregistrrilor n fiiere tradiionale pe suport adresabil. n aceast variant
se elaborau programe de aplicaie care defineau i manipulau propriile date i aveau n general
ca scop elaborarea de rapoarte pentru diveri beneficiari. Aceste programe au avut menirea de
a nlocui prelucrarea sistemelor de fiiere manuale care mai funcioneaz i astzi n unele
locuri cum ar fi cabinetele medicale. Aadar prelucrrile oferite de un sistem tradiional bazat
pe fiiere copiau n mare msur metodele manuale de prelucrare. Evident c puterea de
calcul i memorare caracteristic sistemelor de calcul au fcut ca gama prelucrrilor s
creasc simitor, la aceasta adugndu-se viteza i sigurana prelucrrilor.
Cu toate c la momentul respectiv abordarea tradiional bazat pe fiiere a fost un
evident progres, putem s amintim aici i o serie de limitri ale acestui sistem de prelucrare a
datelor:
Separarea i izolarea datelor
Duplicarea datelor
Dependena datelor
Incompatibilitatea fiierelor
Interogri fixe / proliferarea aplicaiilor
Comentm pe scurt n continuare semnificaia acestora.
Accesul la date care se afl n fiiere diferite este dificil deoarece cade n sarcina
programatorului s sincronizeze nregistrrile din fiiere n aa fel nct datele extrase s fie
corecte.
Duplicarea datelor
n situaia n care se realizeaz prelucrri descentralizate de date, pe compartimente,
este posibil s fie necesar duplicarea datelor. Totui duplicarea este de evitat din urmtoarele
motive:
- necesit costuri mari n timp i spaiu de memorie.
- duce la pierderea integritii datelor. Datele nu mai sunt consistente, deci nu se mai
poate conta pe ele.
2
Dependena datelor
Aa cum am subliniat deja, structura fizic i modul de memorare al datelor este
definit n fiecare program de aplicaie n parte. Este evident ct de dificile sunt schimbrile n
structura datelor. Toate programele trebuie ajustate la noua structur de date. O simpl
modificare a lungimii unui cmp poate genera probleme. Dependena se refer aadar la
dependena program-date.
Aceast limitare se trage tot din dependena de programe a structurii fiierelor.
Structura fiind descris n programe ea depinde de limbajul de programare. De exemplu,
structura unui fiier declarat ntr-un program COBOL difer de structura unui fiier generat
de un program C. Dac e necesar prelucrarea de date din ambele fiiere, programatorul este
obligat s scrie programe de conversie, pentru a aduce fiierele la un format comun posibil de
prelucrat.
Deoarece prelucrarea masivelor de date a devenit mai uoara i mai rapida cu ajutorul
calculatorului, beneficiarii au lrgit gama prelucrrilor lansnd interogri noi sau modificnd
interogri mai vechi, pentru obinerea de informaii mai complexe. Orice interogare nou sau
orice modificare a unei interogri mai vechi se rezolv n sistemele tradiionale prin realizarea
de noi programe de ctre programatorul de aplicaie. Inutil de subliniat ct de costisitoare sunt
acestea. Un efect secundar era c se nmuleau programele aplicaiei i de multe ori i fiierele
de prelucrat.

Obiectivele cursului
Cursul de baze de date este un curs de baz pentru meseria de informatician. La
sfritul acestui curs, studenii vor fi capabili s:
Proiecteze o baz de date
Programeze cereri n SQL
Realizeze un sistem cu baz de date

Cerine preliminare
Cursul se va susine studenilor dup cursul de structuri de date.
Cunotinele acumulate la acest curs pot fi utile la un curs de informatic de
gestiune.

Resurse
Pentru a proiecta un sistem cu baz de date vom folosi sistemul ACCESS de la
Microsoft i ORACLE 10G Express edition.
3

Structura cursului
Cursul de baze de date este structurat n trei module, astfel: primul modul cuprinde
patru uniti de nvare, al doilea modul cuprinde dou uniti de nvare, al
treilea modul cuprinde dou uniti de nvare, al patrulea modul cuprinde dou
uniti de nvare, iar al cincilea modul cuprinde ase uniti de nvare. La
rndul su, fiecare unitate de nvare cuprinde: obiective, aspecte teoretice privind
tematica unitii de nvare respective, exemple, teste de autoevaluare precum i
probleme propuse spre discuie i rezolvare.
La sfritul fiecrui modul sunt date teste de autoevaluare. Rezolvarea acestor teste
se gsete la sfritul crii.

Durata medie de studiu individual
Parcurgerea de ctre studeni a unitilor de nvare ale cursului de baze de date
(att aspectele teoretice ct i rezolvarea testelor de autoevaluare i rezolvarea
problemelor propuse) se poate face n 1-4 ore pentru fiecare unitate.

Evaluarea
La sfritul semestrului, fiecare student va primi o not, care va cuprinde: un
examen scris cu materia din modulele 1, 3 i 4 care va deine o pondere de 60% n
nota final i notele aferente celor dou capitole de la laborator ACCESS i
ORACLE.

4

CUPRINS
Modulul 1. Sisteme de Gestiune a Bazelor de Date (SGBD) ................................ ..................... 5
Unitatea de nvare 1. Istoric; comentarii ................................ ................................ ......... 6
Criterii minimale de definire a unui SGBDR ................................ ................................ ... 10
Unitatea de nvare 1.2 Abstractizarea datelor ................................ ................................ 14
Unitatea de nvare 1.3 Principalele componente i funciuni ale unui SGBD............... 19
Unitatea de nvare 1.4 Baze de date distribuite ................................ ............................. 27
Modulul 2. Modele de descriere a datelor ................................ ................................ ................ 37
Unitatea de nvare 2.1. Generaliti ................................ ................................ ............... 38
Unitatea de nvare 2.2 Modelare E-R (Entity-Relaionship) ................................ ......... 41
Modulul 3. Limbaje de cereri. ................................ ................................ ................................ .. 53
Unitatea de nvare 3.1 Algebra relaional. ................................ ................................ ... 54
Unitatea de nvare 3.2 SQL ................................ ................................ ........................... 65
Modulul 4. Normalizarea................................ ................................ ................................ .......... 85
Unitatea de nvare 4.1 De ce este nevoie de normalizare i cu ce instrumente facem
normalizarea. ................................ ................................ ................................ .................... 86
Unitatea de nvare 4.2 Forme normale ................................ ................................ ......... 93
Modulul 5. Metodologia de proiectare a bazelor de date relaionale ................................ ...... 99
Unitatea de nvare U5.1 Generaliti i proiectarea conceptual................................ . 101
Unitatea de nvare U5.2 Proiectarea logic. ................................ ................................ 111
Unitatea de nvare U5.3 Proiectarea fizic. ................................ ................................ . 122
Unitatea de nvare U5.4 Tranzacii i concuren................................ ........................ 126
Unitatea de nvare U5.5 Metode de control al concurenei. ................................ ........ 131
Unitatea de nvare U5.6. Securitate i integritate ................................ ........................ 139
Raspunsuri la testele de autoevaluare. ................................ ................................ .................... 147
Bibliografie. ................................ ................................ ................................ ............................ 164

5
Modulul 1. Sisteme de Gestiune a Bazelor de Date
(SGBD)

Cuprins
Introducere ................................ ................................ ................................ ...................... 3
Obiectivele modului ................................ ................................ ................................ ........ 3
U1.1. Istoric; comentarii
U1.2. Abstractizarea datelor
U1.3. Principalele componente i funciuni ale unui SGBD
U1.4 Baze de date distribuite

Introducere
Evoluia metodelor i tehnicilor de organizare a datelor a fost determinat de
necesitatea de a avea un acces ct mai rapid i mai uor la un volum din ce n ce
mai mare de informaii precum i de perfecionarea echipamentelor de culegere,
memorare, transmitere i prelucrare a datelor. Cel mai important domeniu al
aplicaiilor calculatorului este cel al bazelor de date.

M1. Obiectivele modulului
La sfritul acestui modul studenii vor fi capabili s:
Disting gradul de relaional al unui SGBD
descrie componena unui Sistem de Gestiune al Bazei de Date
cunoasc obiectivele unui SGBD
cunoasc i s utilizeze funciunile unui SGBD
neleag ce este o baz de date distribbuit
cum se proiecteaz o baz de date distribuit

6
Unitatea de nvare 1. Istoric; comentarii

M1.U1.1. Introducere
Este important s tim cum a evoluat modelul i softul pentru bazele de date. Ne
ocupm, n acest curs, de cel mai important dintre modele i anume modelul
relaional.

M1.U1.2. Obiectivele unitii de nvare
La sfritul acestei uniti de nvare studenii vor fi capabili s:
neleag nivelul la care au ajuns bazele de date
Disting gradul de relaional al unui SGBD.

Durata medie de parcurgere a primei uniti de nvare este de 2 ore.

Istoric i comentarii
Se pare c sistemul de baze de date i are rdcinile n anii '60, n proiectul de
aselenizare Apollo. Deoarece pe atunci nu exist un astfel de sistem, North American
Aviation (actualmente Rockwell International) a dezvoltat un pachet de programe cunoscut
sub numele GUAM (Generalized Update Access Method), care se baza pe date organizate n
mod ierarhic. Modelul de date ierarhic, unul din modelele abstracte ale bazelor de date, i are
originea n acest proiect.
In anii 60 General Electric a dezvoltat sistemul IDS (Integrated Data Store).
Conductor de proiect: Charles Bachmann. Proiectul a condus la modelul de date reea.
n 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea
reprezentani ai guvernului USA i reprezentani ai lumii afacerilor i comerului, a reuit s
stabileasc un grup de lucru, cunoscut din 1967 sub numele Data Base Task Group (DBTG).
Sarcina acestui grup era s stabileasc specificaii cu rol de standarde pentru un mediu care ar
permite crearea de baze de date i manipularea datelor.
Conceptul de baz de date s-a definit n 1969 cu ocazia prezentrii primului proiect de
raport CODASYL (Raportul final s-a prezentat n 1971). Ideea principal n organizarea
datelor se baza pe existena a trei nivele de baz:
- schema de reea - care reprezenta organizarea logica a ntregii baze de date
- subschema - care reprezenta o parte a bazei de date aa cum e vzut de utilizator sau de
programele de aplicaie
- un limbaj de gestionare a datelor - care definea caracteristicile datelor, structura lor i care
manipula datele
Pentru standardizare, s-au propus trei limbaje:
- un limbaj de definire a datelor (LDD) la nivel de schem
- un limbaj la nivel de subschem
7
- un limbaj de manipulare a datelor (LMD)
Cu toate c nu a fost adoptat formal de ANI (American National Standard Institute)
propunerea DBTG a fost aplicat ntr-o serie de sisteme dezvoltate ulterior i ea st la baza
conceptului modern de baz de date.
Proiectul ierarhic i cel prezentat de CODASYL reprezint prima generaie de Sisteme de
Gestiune a Bazelor de Date (SGBD).
n 1978 E.F.Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o
influen covritoare n dezvoltarea bazelor de date. Lucrarea trata despre modelul de date
relaional.
De aici ncolo s-au proiectat multe sisteme dintre care menionm System R dezvoltat la
IBM's San Jose Research Laboratory din California, la sfritul anilor '70. Acest proiect a dus
la:
- dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un
standard pentru sistemele relaionale;
- producerea n anii '80 de sisteme comerciale arhicunoscute dintre care menionm: DB2 i
SQL/DS de la IBM i ORACLE de la ORACLE Corporation.
Alte exemple de sisteme relaionale: INGRES de la Relaional Technology Inc., Informix de
la Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sistemele relaionale pentru
microcalculatoare enumerm aici: Paradox i dBase IV de la Borland, Access de la Microsoft,
FoxPro i R:base de la Microrim. Toate acestea constituie generaia a doua de SGBD.
Definirea sistemelor de gestiune ale bazelor de date relaionale
ntr-o prim ncercare de definire, se poate considera un sistem de gestiune a bazelor de
date relaionale (SGBDR) ca reprezentnd un SGBD care utilizeaz drept concepie de
organizare a datelor modelul relaional. Astfel spus, un SGDBR reprezint un sistem care
suport modelul relaional.
Definiia de mai sus este prea general pentru a putea fi operaional, deoarece modul de
implementare a modelului relaional difer, de regul att ntre diferitele SGBDR, ct i n
raport cu modelul teoretic, cel definit n cadrul teoriei relaionale, datorit eforturilor
productorilor de a realiza sisteme ct mai performane care s satisfac cerinele i
exagerrile utilizatorilor. Ct de aproape (sau de departe) de modelul relaional teoretic
trebuie s fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma c SGBD-ul
respectiv utilizeaz sau nu modelul relaional, deci este sau nu SGBDR?
Diversitatea modelelor relaionale operaionale au determinat, n mod natural existena
unei mari diversitii de SGBDR, pentru a cror prezentare a fost necesar nuanarea
terminologiei. Au aprut o serie de sintagme precum: sisteme cu interfa relaional, sisteme
pseudorelaionale, sisteme complet relaionale.
Conceptele specifice organizrii datelor n fiiere, SGBDR i teoriei relaionale ntre care
se pot stabili analogii

Organizarea datelor n fiiere SGBDR Teoria relaional
Fiier Tabel Relaie
Record(nregistrare) Linie Tuplu
Cmp Coloan Atribut

n general, conceptele utilizate la prezentarea SGBDR i a modelelor relaionale
operaionale difer de cele din cadrul teoriei relaionale. Figura de mai sus prezint
8
comparativ conceptele organizrii datelor n fiiere, concepte SGBDR i ale teoriei
relaionale.
Faptul c se pot stabili analogii ntre conceptele organizrii datelor n fiiere i
conceptele relaionale, i-au determinat pe unii productori s prezinte sisteme fr nici o
legtur cu modelul relaional drept SGBDR, n scopul asigurrii succesului comercial al
acestor sisteme.
Regulile lui Codd
Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie s le prezinte
un SGBD pentru a putea fi considerat relaional. n acest sens, Codd a formulat 13 reguli care
exprim cerinele pe care trebuie s le prezinte un SGBD ca s fie relaional. Dei reguli au
strnit o serie de controverse, eu le voi prezenta n continuare, ele fiind deosebit de utile n
evaluarea unui SGBDR.
R0: Regula privind gestionarea datelor la nivel de relaie
Sistemul trebuie s gestioneze baza de date numai prin mecanisme relaionale.
Acest lucru nseamn c sistemul trebuie s-i ndeplineasc toate funciile prin
manipulri n care unitatea de informaie s fie mulimea (relaia), adic s utilizeze limbaje,
precum SQL, care s opereze la un moment dat pe o ntreag relaie. Dec i SGBD nu trebuie s
accepte operaii non-relaionale care s ndeplineasc operaiile de definire i manipulare a
datelor.
Unele sisteme utilizeaz mecanisme relaionale numai pentru o parte din funcii, n special
pentru interogare. Aceste sisteme se numesc sisteme cu interfa relaional i nu SGBDR.
R1: Regula privind reprezentarea logic a datelor
Toate datele din baza de date relaional trebuie s fie reprezentate explicit la nivel
logic, ntr-un singur mod, i anume ca valori n tabele de date. Ac este lucru nseamn c toate
datele trebuie s fie memorate i prelucrate n acelai mod. Informaiile privind numele de
tabele,coloane, domenii, definiiile tabelelor virtuale, restricii de integritate trebuie s fie
memorare tot n tabele de date (catal oage). Referina la 'nivelul logic' nseamn c construcia
fizic nu este reprezentat i nu necesit explicaie.
R2: Regula privind garantarea accesului la date.
Orice dat din baza de date relaional trebuie s poat fi accesat prin specificarea
numelui da tabel, valorii cheii primare i numelui de coloan.
Aceast regul exprim cerina ca limbajul de cereri al SGBDR s permit accesul la
fiecare valoare atomic din baza de date.
R3: Regula privind valorile null
Sistemele trebuie s permit declararea s manipularea sistematic a valorilor null, cu
semnificaia unor date lips sau inaplicabile. Valorile null, care difer de irurile de caractere '
spaiu' sau de irurile vide da caractere sunt deosebit de importante n implementarea
restriciilor de integritate (integritatea entitii i integritatea referenial).
R4: Regula privind metadatele
Descrierea bazei de date trebuie s se prezinte la nivel logic n acelai mod cu descrierea
datelor propiu-zise, astfel nct utilizatorii autorizai s poat descrierii bazei de date aceleai
operaii ca i asupra datelor obinuite.
Aceast regul specific c trebuie s existe un unic limbaj de manipulare a metadatelor i
a datelor propui-zise, mai mult, exist o unic structur logic folosit pentru a depozita
informaiile de sistem.
Sisteme nu trebuie s fac diferenieri n definirea i tratarea datelor i a metadatelor,
utiliznd o singur structur, i anume cea relaional.
R5: Regula privind facilitile limbajelor utilizate
Un sistem relaional trebuie s fac posibil utilizarea mai multor limbaje, n mai multe
moduri. Trebuie s existe ns cel puin un limbaj de nivel nalt ale crui instruciuni s poat
9
exprima oricare din urmtoarele operaii: definirea tabelelor de date, definirea tabelelor
virtuale, manipularea datelor (interactiv dau prin program), definirea restriciilor de
integritate, autorizarea accesului, precizarea limitelor tranzaciilor. A se nota aici c noul
standard O/I pentru SQL furnizeaz toate aceste funcii, deci orice limbaj care accept acest
standard va satisface automat aceast regul.
R6: Regula privind actualizarea tabelelor virtuale.
Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie s poat fi efectiv
actualizabile. Nu toate atributele din cadrul unei tabele virtuale, deci nu toate tabele virtuale
sunt teoretic actualizabile.
R7: Regula privind inserrile, modificrile i tergerile n baza de date
Sistemul trebuie s ofere posibilitatea manipulrii unei tabele (da baz sau virtual) nu
numai n cadrul operaiilor de regsire, ci i n aciuni de inserare, modificare i tergere a
datelor.
Aceast regul exprim cerina ca prin operaiile n care se schimb bazei da date s se
lucreze la un moment dat pe o ntreag relaie.
R8: Regula privind independena fizic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate n modul de
reprezentare a datelor sau n metodele de acces. O schimbare a structurii fizice a datelor nu
trebuie s blocheze funcionarea programelor de aplicaie.
R9: Regula privind independena logic a datelor
Programele de aplicaie nu trebuie s fie afectate de schimbrile efectuate asupra
relaiilor bazei de date, schimbri care conserv datele i care teoretic garanteaz valabilitatea
programelor de aplicaie existente.
R10: Regula privind restriciile de integritate
Restriciile de integritate trebuie s fie definite n limbajul utilizat de sistem pentru
definirea datelor i s fie memorate n cadrul bazei de date i nu n cadrul programului de
aplicaie.
R11: Regula privind distribuirea geografic a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie s permit ca, n situaia n
care datele sunt distribuite, programele de aplicaie s fie logic aceleai cu cele utilizate n
cazul n care datele sunt fizic centralizate.
Utilizatorul trebuie s perceap datele ca fiind centralizate. Sarcina de localizare a
datelor, atunci cnd acestea sunt distribuite geografic precum i sarcina recompunerii datelor
trebuie s revin sistemului i nu utilizatorului.
R12: Regula privind prelucrarea datelor la nivelul de baz
Dac sistemul posed un limbaj de baz (de nivel sczut) orientat pe prelucrare de
recorduri (tupluri) i nu pe prelucrarea mulimilor (relaiilor), acest limbaj nu trebuie s fie
utilizat pentru a se evita restriciile de integritate sau restriciile introduse prin utilizarea
limbajelor de nivel nalt, adic accesul la toate datele va fi controlat de SGBDR, altfel
integritate bazelor de date nu poate fi compromis fr cunoa terea utilizatorului sau a
administratorului bazei de date.
Pe parcursul anilor regulile lui Codd au generat o seam de controverse. Cteva
argumente sunt c aceste reguli nu sunt mai mult dect nite exerciii academice. Unele
revendicri ale produselor existente sunt c ele pot ndeplini cea mai mare parte din reguli,
dar nu toate. Aceast discuie a generat o disput ntre utilizatori i teoreticienii asupra
proprietilor eseniale ale unui SGBDR.
Pentru a accentua implicaia regulilor lui Codd n analiza unui SGBDR, aceste reguli
au fost reorganizate n cinci categorii, i anume:
Reguli fundamentale,
10
Reguli structurale,
Reguli privind integritatea datelor,
Reguli privind manipularea datelor,
Reguli privind independena datelor.

S ne reamintim...
Abordarea tradiional bazat pe fiiere are o serie de limitri cum ar fi
Duplicarea datelor
Dependena datelor
Sistemul de baze de date i are rdcinile n anii '60, n proiectul de
aselenizare Apollo
Ideea principal n organizarea datelor se baza pe existena a trei componente
de baz:
schema de reea - care reprezenta organizarea logica a ntregii baze de date
subschema - care reprezenta o parte a bazei de date aa cum e vzut de
utilizator sau de programele de aplicaie
un limbaj de gestionare a datelor - care definea caracteristicile datelor,
structura lor i care manipula datele
Pentru standardizare avem trei limbaje:
un limbaj de definire a datelor (LDD) la nivel de schem
un limbaj la nivel de subschem
un limbaj de manipulare a datelor (LMD)
Conceptele specifice organizrii datelor n fiiere, SGBDR i teoriei
relaionale ntre care se pot stabili analogii

Organizarea datelor n
fiiere
SGBDR Teoria relaional
Fiier Tabel Relaie
Cmp Coloan Atribut

Codd a formulat 13 reguli care exprim cerinele pe care trebuie s le prezinte
un SGBD ca s fie relaional.

Criterii minimale de definire a unui SGBDR

Nici unul dintre SGBDR disponibile astzi nu respect ntru totul cerinele exprimate de
Codd, n cadrul celor 13 reguli. De aceea pentru caracterizarea unui SGBD nu sunt utilizate
11
regulile lui Codd, fiind formulate n schimb o serie de cerine minimale pa care trebuie s la
satisfac un sistem de gestiune a bazelor de date pentru a putea fi considerat relaional.
Un SGBD este minimal relaional dac satisface urmtoarele condiii:
1. Toate datele din cadrul relaiei sunt reprezentate prin valori n tabele,
2. Nu exist pointeri observabili de ctre utilizatori n tabele, n sensul c operaiile cu relaii
nu fac apel la pointeri, indeci, fiiere inverse, etc.
3. Sistemul suport operatori relaionali de proiecie, selecie i join natural, fr limitri
impuse de considerente interne (cum ar fi de exemplu, necesitatea indexrii atributelor).
Unitatea de informaie cu care se lucreaz n cadrul acestor operaii trebuie s fie relaia.
Un SGBD este complet relaional dac este minimal relaional i satisface n plus
urmtoarele condiii:
4. Sistemul suport toate operaiile de baz ale algebrei relaionale, fr limitri impuse de
considerente interne.
5. Sistemul suport dou dintre restriciile de integritate de baz al modelului relaional i
anume unicitatea cheii unei relaii i restricia referenial.

Un SGBD este pseudorelaional dac satisface numai condiiile 1. i 3.
Un SGBD cu interfa relaional este un SGBD are satisface condiiile 1. i 3., cu
observaia c cerina 3. Este ndeplinit numai n raport cu funcia de interogare
n ultimii ani, ca rspuns la necesitatea de a crete complexitatea aplicaiilor cu baze de
date (ncurajat i de progresele aprute n programare o dat cu programarea orientata obiect)
au aprut modelul de date orientat obiect (Object-Oriented Data Model - OODM) i modelul
de date relaional extins (Extended Relaional Data Model - ERDM). Cu toate c modelul de
date ce sta la baza noilor modele nu este att de clar c n cazul modelului relaional, se poate
considera c aceste din urma dezvoltri reprezint generaia a patra de SGBD.
In esen, conceptul de baz de date poate fi definit ca fiind o colecie partajat de date
aflate n interdependen logic (mpreun cu o descriere a acestor date i a relaiilor dintre
ele), colecie desemnat pentru a rezolva nevoia de informatizare a unei ntreprinderi (sau
organizaii).
Baza de date trebuie s ndeplineasc urmtoarele condiii:
- s asigure o independen sporit a datelor fa de programe i invers;
- structura bazei de date trebuie astfel conceput nct s asigure informaiile necesare i
suficiente pentru cerinele de informare i decizie;
- s asigure o redundan minim i controlat a datelor;
- s permit accesul rapid la informaiile stocate n baz.
Bazele de date sunt extrem de variate n funcie de criteriile luate n considerare. Prezentm
cteva criterii de clasificare:
- dup orientare: generalizate, specializate;
- dup modelul de date: ierarhice, reele, relaionale, orientate obiect;
- dup amploarea geografica: locale, distribuite;
Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care
permite, pe de o parte, definirea, crearea i ntreinerea bazei de date i pe de alta parte,
permite accesul controlat la informaiile din baza de date n cauz. SGBD este format din
12
programe de software care interacioneaz cu programele de aplicaie ale utilizatorilor i cu
baza de date. Sistemul de gestiune al bazei de date asigur realizarea urmtoarelor activiti:
- definirea structurii bazei de date;
- ncrcarea datelor n baza de date;
- accesul la date (interogare, actualizare);
- ntreinerea bazei de date (colectarea i reutilizarea spatiilor goale, refacerea bazei de
date n cazul unui incident);
- reorganizarea bazei de date (restructurarea i modificarea strategiei de acces);
- integritatea datelor;
- securitatea datelor.
Aadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe
care asigur interfaa ntre o baz de date i utilizatorii acesteia.
Clasificarea SGBD se poate realiza din mai multe puncte de vedere.
Din punctul de vedere al sistemelor de calcul pe care se implementeaz. SGBD pot fi:
sisteme de gestiune pentru calculatoarele mari;
sisteme de gestiune pentru minicalculatoare;
sisteme de gestiune pentru microcalculatoare.
In prezent se manifesta tendina ca marea majoritate a sistemelor de gestiune a bazelor de
date s fie compatibile pe platforme ct mai largi de sisteme de calcul.
2. Din punctul de vedere al limbajului pe care l utilizeaz, sunt: sisteme cu limbaj gazd;
sisteme cu limbaj autonom.
Sistemele cu limbaj gazd realizeaz activitile de creare, actualizare i interogare a
bazei de date, utiliznd limbajele de nivel nalt sau extensii ale acestora, proprii sistemului de
calcul pe care se implementeaz baza de date. Avantajul acestor sisteme const n
posibilitile sporite ce le ofer limbajele de nivel nalt la elaborarea unor proceduri complexe.
Sistemele cu limbaj gazd prezint dezavantajul c formularea cerinelor nu este att de
simplificat ca n cazul sistemelor cu limbaj autonom.
3. Din punctul de vedere al concepiei de organizare a datelor pe care le gestioneaz, SGBD
se clasific n: sisteme de gestiune a bazelor de date cu structuri ierarhice i reea; sisteme de
gestiune a bazelor de date relaionale; sisteme de gestiune a bazelor de date orientate obiect.
4. Din punctul de vedere al modului de localizare a bazelor de date avem: sisteme de gestiune
a bazelor de date centralizate; sisteme de gestiune a bazelor de date distribuit e.
Marea majoritate a sistemelor de gestiune aprute n ultima perioad dispun i de o
component de gestiune distribuit a datelor.

S ne reamintim...
Un SGBD este minimal relaional dac satisface urmtoarele condiii:
Toate datele din cadrul relaiei sunt reprezentate prin valori n tabele,
Nu exist pointeri observabili de ctre utilizatori n tabele, n sensul c
operaiile cu relaii nu fac apel la pointeri, indeci, fiiere inverse, etc.
Sistemul suport operatori relaionali de proiecie, selecie i join natural, fr
limitri impuse de considerente interne (cum ar fi de exemplu, necesitatea
indexrii atributelor). Unitatea de informaie cu care se lucreaz n cadrul
acestor operaii trebuie s fie relaia.
Un SGBD este complet relaional dac este minimal relaional i satisface
n plus urmtoarele condiii:
13
Sistemul suport toate operaiile de baz ale algebrei relaionale, fr limitri
impuse de considerente interne.
Sistemul suport dou dintre restriciile de integritate de baz al modelului
relaional i anume unicitatea cheii unei relaii i restricia referenial.
n esen, conceptul de baz de date poate fi definit ca fiind o colecie partajat
de date aflate n interdependen logic (mpreun cu o descriere a acestor date
i a relaiilor dintre ele), colecie desemnat pentru a rezolva nevoia de
informatizare a unei ntreprinderi.
Clasificarea SGBD se poate realiza din mai multe puncte de vedere: din punctul
de vedere al sistemelor de calcul pe care se implementeaz. SGBD, din punctul
de vedere al limbajului pe care l utilizeaz i din punctul de vedere al
concepiei de organizare a datelor pe care le gestioneaz

M1.U1.6. Rezumat
Conceptul de baz de date poate fi definit ca fiind o colecie partajat de date
aflate n interdependen logic (mpreun cu o descriere a acestor date i a
relaiilor dintre ele), colecie desemnat pentru a rezolva nevoia de
informatizare a unei ntreprinderi.
Sistemul de baze de date i are rdcinile n anii '60, n proiectul de
aselenizare Apollo
Ideea principal n organizarea datelor se baza pe existena a trei componente
de baz:
schema de reea - care reprezenta organizarea logica a ntregii baze de date
subschema - care reprezenta o parte a bazei de date aa cum e vzut de
utilizator sau de programele de aplicaie
un limbaj de gestionare a datelor - care definea caracteristicile datelor,
structura lor i care manipula datele
Pentru standardizare avem trei limbaje:
un limbaj de definire a datelor (LDD) la nivel de schem
un limbaj la nivel de subschem
un limbaj de manipulare a datelor (LMD)
Conceptele specifice organizrii datelor n fiiere, SGBDR i teoriei
relaionale ntre care se pot stabili analogii

Organizarea datelor n
fiiere
SGBDR Teoria relaional
Fiier Tabel Relaie
Cmp Coloan Atribut

14
Unitatea de nvare 1.2 Abstractizarea datelor

Un scop important al unui sistem de gestiune al bazelor de date este s poat
asigura o viziune abstract asupra realitii. Este necesar s se rein din mulimea
vast de informaii doar acelea care sunt necesare unei anumite aplicaii.

neleag care este structura pe trei nivele a bazei de date
neleag ce este independena logic i ce este cea fizic i de ce este
important aceast independen

Durata medie de parcurgere a primei uniti de nvare este de 2 or e.
Se poate face referire spre exemplu la ncercarea de modelare a unei aplicaii ntr-o
ntreprindere. Trebuie modelate 'obiectele' i relaiile dintre ele. Nu realitatea complex n
totalitatea ei intr n discuie ci doar o mic parte a ei, constituit din anumite 'obiecte' i
pentru acele obiecte se iau n considerare doar o parte din caracteristici (acele caracteristici
care sunt importante pentru aplicaia n cauza). Astfel n cazul modelrii 'obiectului' (sau
entitii) angajat, trebuie alese doar acele proprieti (sau atribute) care intereseaz. Acestea
ar putea fi, de exemplu: numele, adresa, salariul. O mulime impresionant de informaii, care
contribuie la descrierea unei persoane anume, nu sunt luate n seam, deoarece nu prezint
interes pentru ntreprindere.

Exemple
De exemplu, nu intereseaz dac persoana are ochii albatri, dac este blond
sau brunet, dac ascult cu plcere muzic sau dac este o fire sentimental.

Ce credei c ar interesa s memorm despre studeni ntr-o baz de date a
facultii?
Ce nu ar trebui memorat?

Mai mult dect faptul c realitatea este reprezentat codificat i foarte simplificat,
deoarece baza de date este o resurs partajat, este foarte probabil ca fiecare utilizator s
doreasc doar o parte din informaiile stocate, funcie de aplicaia pe care o dezvolt.
15
Pentru a se rezolva aceste cerine, se apeleaz la reprezentarea pe nivele a organizrii
informaiilor ntr-o baza de date. n general este acceptat arhitectura pe trei nivele ANSI-
SPARC.
Componentele bazei de date pot fi structurate pe trei nivele, n funcie de clasa
utilizatorilor implicai i de viziunea asupra structurrii informaiei, dup cum urmeaz:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea
programatorului de aplicaii, care realizeaz programele de aplicaii pentru manipularea
datelor la nivel de structur logic (subschema) corespunztoare descrierii datelor aplicaiei;
- nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care
realizeaz structura conceptual (schema) corespunztoare descrierii ntregii baze de date i
administreaz componentele bazei de date. Acest nivel descrie ce date sunt memorate n baza
de date i ce relaii sunt stabilite ntre date. Nivelul conceptual reprezint:
- toate entitile, atributele lor i relaiile dintre ele;
- restriciile impuse datelor
- informaiile semantice despre date
- informaiile privitoare la securitatea i integritatea datelor.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizeaz structura fizic
corespunztoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt
memorate datele n baza de date. Nivelul intern se ocup de:
- alocarea spaiului de memorie pentru date i indeci;
- descrierea nregistrrilor pentru memorare;
- plasarea nregistrrilor pe suport;
- tehnicile de compresie i de criptare a datelor.

View 1

View 2

View n
Schema
conceptuala
Schema
interna
Baza de
date
Utilizator 1 Utilizator 2
Nivel
extern
Nivel
conceptual
Nivel
intern
Organizarea la
nivel fizic a datelor
..
16
Arhitectura ANSI-SPARC pe trei nivele

S ne reamintim...
Componentele bazei de date pot fi structurate pe trei nivele, n funcie
de clasa utilizatorilor implicai i de viziunea asupra structurrii informaiei,
dup cum urmeaz:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de
viziunea programatorului de aplicaii
- nivelul conceptual (global). Este dat de viziunea administratorului bazei
de date, care realizeaz structura conceptual (schema) corespunztoare
descrierii ntregii baze de date i administreaz componentele bazei de date.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizeaz
structura fizic corespunztoare descrierii datelor pe suportul fizic (periferic).

Scheme, corespondene i instane
Descrierea generala a unei baze de date se numete schema bazei de date. Conform
nivelelor de abstractizare a datelor exist trei tipuri de scheme pentru fiecare baz de date. La
nivelul cel mai nalt exist (n general) mai multe scheme externe (numite i subscheme)
care descriu diferitele view-uri ale bazei de date. La nivelul conceptual exist schema
conceptual iar la nivelul cel mai de jos de abstractizare exist schema intern.
Pentru fiecare baz de date o singura schem conceptual descrie datele i relaiile
ntre ele, precum i restriciile de integritate. Schemei conceptuale i corespunde o schem
intern care descrie organizarea fizic a datelor.
SGBD realizeaz corespondena ntre cele trei nivele de abstractizare, realiznd
corespondena ntre cele trei tipuri de scheme. Astfel corespondena conceptual / intern
leag schema conceptual de schema intern. Datorit acestei corespondene se identific
nregistrarea sau combinaia de nregistrri la nivel fizic, care constituie nregistrarea logic
n schema conceptual, mpreun cu restriciile de integritate corespunztoare. Analog, fiecare
schem extern este legat de schema conceptual prin corespondena extern / conceptual.
Aceasta coresponden permite SGBD s fac legtura ntre numele din view-urile utilizator
i partea corespunztoare relevant din schema conceptual. Este de reinut c trebuie s
facem distincie ntre descrierea bazei de date (schema bazei de date) i baza de date propriu-
zis. Numim instana (n cazul unei baze de date) datele aflate n baza de date la un anumit
moment dat. Altfel spus, mai multe instane pot s corespund aceleiai scheme conceptuale
pentru o baz de date.
17

S ne reamintim...
Descrierea generala a unei baze de date se numete schema bazei de date.
Conform nivelelor de abstractizare a datelor exist trei tipuri de scheme
pentru fiecare baz de date. La nivelul cel mai nalt exist (n general) mai
multe scheme externe (numite i subscheme) care descriu diferitele view-uri
ale bazei de date. La nivelul conceptual exist schema conceptual iar la
nivelul cel mai de jos de abstractizare exist schema intern.

Independena datelor
Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea
independenei datelor. O aplicaie, n general, este dependent de date n sensul c
modificarea structurii de memorare a datelor sau a strategiei de acces la date afecteaz i
aplicaia. Independena datelor fa de aplicaie este totui necesar cel puin din urmtoarele
considerente:
- diferite aplicaii au nevoie de viziuni diferite asupra acelorai date;
- administratorul bazei de date trebuie s aib libertatea de a schimba structura de memorare
sau strategia de acces, ca rspuns la cerine (schimbri de standarde, prioritile aplicaiilor,
unitile de memorare etc.), fr a modifica aplicaiile existente, baza de date existent,
precum i programele de exploatare a ei, care au fost folosite o perioad de timp i care
reprezint o investiie major la care nu trebuie s se renune prea uor.
De aceea, se impune ca atunci cnd apar noi cerine n cadrul sistemului informaional,
sistemele informatice s poat funciona cu programele i procedurile existente, iar datele
existente s poat fi convertite.
Independena datelor trebuie privit din dou puncte de vedere: independena fizic i
independena logic a datelor.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de memorarea s
poat fi modificate fr a determina rescrierea programelor de aplicaie. Aadar independena
fizic a datelor reprezint gradul de imunitate a schemei conceptuale la schimbrile suferite
de schema intern.
Independena logic a datelor se refera la posibilitatea adugrii de noi nregistrri sau la
extinderea structurii conceptuale (globale), fr ca acest lucru s impun rescri erea
programelor existente. Cu alte cuvinte independena logic a datelor reprezint gradul de
imunitate a schemelor externe la schimbrile suferite de schema conceptual.

S ne reamintim...
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de
memorarea s poat fi modificate fr a determina rescrierea programelor de
aplicaie.
Independena logic a datelor se refer la posibilitatea adugrii de noi
nregistrri sau la extinderea structurii conceptuale (globale), fr ca acest lucru
s impun rescrierea programelor existente.
18

M1.U1.6. Rezumat
Componentele bazei de date pot fi structurate pe trei nivele, n funcie
de clasa utilizatorilor implicai i de viziunea asupra structurrii informaiei,
dup cum urmeaz:
- nivelul logic de vizualizare (view) sau nivelul extern.
- nivelul conceptual (global
- nivelul fizic
Descrierea general a unei baze de date se numete schema bazei de
date. Conform nivelelor de abstractizare a datelor exist trei tipuri de scheme
pentru fiecare baz de date. Exist (n general) mai multe scheme externe
(numite i subscheme) care descriu diferitele view-uri ale bazei de date. La
nivelul conceptual exist schema conceptual iar la nivelul cel mai de jos de
abstractizare exist schema intern.
Independena fizic a datelor face ca memorarea datelor i tehnicile fizice de
memorarea s poat fi modificate fr a determina rescrierea programelor de
aplicaie.
Independena logic a datelor se refer la posibilitatea adugrii de noi
nregistrri sau la extinderea structurii conceptuale (globale), fr ca acest
lucru s impun rescrierea programelor existente.

M1.U1.2. Test de autoevaluare a cunotinelor
1.2.1 Ce ar trebui memorat despre profesori ntr -o baz de date a facultii?
1.2.2 Ce nu ar trebui memorat despre profesori ntr-o baz de date a
facultii?
1.2.3 Ce este arhitectura pe trei nivele?
Rspunsurile se gsesc la sfrit la pag 147

19
Unitatea de nvare 1.3 Principalele componente i funciuni al e unui SGBD

Pentru a concepe i a utiliza o baz de date trebuie s tim ce putem cere de la o
baz de date i de la un SGBD:

descrie componena unui Sistem de Gestiune al Bazei de Date
cunoasc obiectivele unui SGBD
cunoasc i s utilizeze funciunile unui SGBD

Durata medie de parcurgere a primei uniti de nvare es te de 2 ore.
innd seama de faptul c exist diferite tipuri de sisteme de gestiune, care se difereniaz:
- prin limbajele utilizate,
- prin anumite componente ce imprim diferite faciliti de exploatare a bazei de date,
- i prin faptul c unele ofer posibilitatea lucrului n regim de teleprelucrare, altele
numai n regim local, iar altele att n regim local ct i n regim de teleprelucrare,
ajungem la concluzia c nu poate fi stabilit o arhitectur unic, valabil pentru toate
sistemele, ci apar particulariti de la un sistem la altul.
Arhitectura unui SGBD evideniaz componentele acestuia i urmeaz standarde
internaionale. O astfel de arhitectur general cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia de date;
- sistemul de gestiune al bazei de date, care este un ansamblu de programe (soft) care
realizeaz gestiunea i prelucrarea complex a datelor;
- un set de proceduri manuale i automate, precum i reglementrile administrative,
destinate bunei funcionri a ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine informaii despre date,
structura acestora, elemente de descriere a semanticii, statistici, documentaie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate
(administrator), analiti - programatori, gestionari, operatori).
Arhitectura bazei de date d o imagine despre modul general de organizare i funcionare a ei.
S detaliem cteva din componentele prezentate mai sus.
20
Limbajele utilizate ntr-un SGBD sunt de dou tipuri: Limbajul de definire a datelor
(Data Definition Language - DDL) i Limbajul de manipulare a datelor (Data Manipulation
Language - DML). Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu
includ construcii adecvate oricror necesiti de calcul, asemntoare cu structurile puse la
dispoziie de limbajele de nivel nalt.
Multe SGBD au facilitatea de a incorpora sublimbajul ntr-un limbaj de nivel nalt
(numit limbaj gazd) cum ar fi COBOL, Fortran, Pascal, Ada, C. Pentru compilare, comenzile
sublimbajului sunt nlocuite n limbajul gazd cu apeluri de funcii. Fiierul preprocesat este
compilat, plasat ntr-un modul obiect, link-editat cu o bibliotec n care se afl funciile
nlocuite, furnizate o dat cu SGBD, i este executat cnd este necesar.
Limbajul de Definire a Datelor (LDD) este un limbaj descriptiv care permite
administratorului bazei de date sau utilizatorilor s descrie i s denumeasc entitile i
relaiile care se pot stabili ntre acestea.
Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilrii declaraiilor
n acest limbaj este constituit dintr-o serie de tabele memorate ntr-un Fiier special numit
dicionar de date (se mai utilizeaz i termenii de catalog de date sau director de date).
Datele memorate n acest dicionar sunt date despre date i de aceea se mai numesc i
metadate. Definiiile din dicionarul de date se refera la nregistrri, la datele din nregistrri
i la alte obiecte ce compun baza de date. SGBD consulta dicionarul de date naintea oricrui
acces la informaii.
Teoretic, se poate identifica cate un LDD pentru fiecare nivel de abstractizare al
datelor, n realitate exist un singur limbaj care trateaz toate aspectele definirii datelor.
Limbajul de manipulare a datelor (LMD) furnizeaz un set operaii care suporta
operaiile de manipulare de baza asupra datelor din baza de date. Operaii de baza sunt
inserarea, tergerea, modificarea i regsirea datelor n baza de date. Manipularea datelor se
aplica la nivel conceptual i extern.
Se cunosc doua tipuri de LMD: procedural i non-procedural. Un LMD procedural
trateaz nregistrrile individual i specifica cum trebuie obinut rezultatul unei interogri. Cu
alte cuvinte trebuie s se specifice un algoritm de prelucrare a nregistrrilor cu ajutorul
operaiilor puse la dispoziie de limbaj.
n contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obinut.
SGBD translateaz cererea din limbaj non-procedural transformnd-o ntr-o procedura sau
ntr-o serie de proceduri care manipuleaz datele conform cererii utilizatorului. Limbajele
non-procedurale sunt mai uor de utilizat deoarece scutesc utilizatorii de la a cunoate
implementarea interna a structurilor de date i de la a stabili algoritmi de obinere a
informaiilor.
Partea componenta a unui LMD care se refera la regsirea datelor se numete limbaj
de interogare. nelegem prin interogare orice cerere de acces la datele din baza de date,
formulata ntr-un limbaj de interogare.
4GL
4GL nseamn Fourth-Generation Language (Limbaj de Generaia a Patra). Nu exist
nc un consens asupra semnificaiei acestei denumiri. n general 4GL desemneaz un limbaj
de programare de mare rapiditate pentru programator. Ceea ce se programeaz n sute de linii
de program ntr-un limbaj de generaia a treia, poate s constituie cteva zeci de linii de
program ntr-un limbaj de generaia a patra. Limbajele 4GL sunt non-procedurale i se
21
bazeaz pe tools-uri performante. Utilizatorul trebuie s defineasc parametri pentru aceste
tools-uri iar acestea genereaz programe de aplicaie pe baza parametrilor respectivi. Un
avantaj important al utilizrii limbajelor 4GL este o productivitate deosebita n programare.
Un 4GL cuprinde:
- limbaje de interogare;
- generatoare de ecrane;
- generatoare de rapoarte;
- limbaje specializate cum ar fi spreadsheet -urile i limbajele specifice bazelor de date;
- generatoare de aplicaii, etc.
Exemple de limbaje de interogare 4GL sunt SQL i QBE, limbaje comerciale asupra
crora vom reveni ulterior.
Generatoare de ecrane
Un generator de ecrane este un tool cu ajutorul cruia se pot crea uor i rapid ecrane
pentru culegerea (introducerea) informaiilor necesare programelor sau chiar pentru
introducerea i modificarea datelor din baza de date.
Generatoare de rapoarte
Un generator de rapoarte ajuta la crearea de rapoarte (liste) pornind de la datele
memorate n baza de date. Se cunosc doua tipuri de generatoare de rapoarte: orientat pe limbaj
i orientat visual. n primul caz se utilizeaz comenzile unui sublimbaj pentru a defini datele
ce se vor include n raport, n al doilea caz, acelai lucru se realizeaz cu ajutorul unei
faciliti grafice similare cu generatorul de ecrane.
Generatoare de grafice
Un astfel de generator este o facilitate care regsete date din baza de date i afieaz
aceste date sub forma unor grafice.
Generatoare de aplicaii
Utilizarea unui generator de aplicaii poate reduce timpul necesar realizrii unei
aplicaii unitare. Generatoarele de aplicaii constau n module predefinite care cuprind
majoritatea funciilor de baza ce sunt prezente n majoritatea programelor. Aceste module
constituie o biblioteca de funcii la dispoziia utilizatorilor.

22

S ne reamintim...
Arhitectura unui SGBD cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia de
date;
- sistemul de gestiune al bazei de date, care este un ansamblu de
programe (soft) care realizeaz gestiunea i prelucrarea
complex a datelor;
- un set de proceduri manuale i automate, precum i
reglementrile administrative, destinate bunei funcionri a
ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine
informaii despre date, structura acestora, elemente de descriere
a semanticii, statistici, documentaie etc.
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analiti -
programatori, gestionari, operatori).

Obiectivele unui SGBD
Dup cum este cunoscut, obiectivul informaticii l constituie culegerea, verificarea,
transmiterea, stocarea i prelucrarea automata a datelor cu ajutorul mijloacelor electronice de
calcul, n scopul satisfacerii diferitelor nivele de conducere cu informaii necesare lurii
deciziilor, n condiii de eficienta economica sporita.
In aceste condiii, necesitatea acut de informare trebuie satisfcut innd seama de o serie de
cerine prin care s se asigure:
- minimizarea costului procesului de prelucrare a datelor; creterea vitezei de rspuns la
ntrebrile solicitate de utilizatori;
- adaptarea facil a sistemului informatic la evoluia n timp a sistemului informaional
din care face parte;
- posibilitatea rspunsului la anumite ntrebri neanticipate de ctre proiectanii de
sistem;
- posibilitatea folosirii sistemului de informare dispunnd de un minim de cunotine
despre modul lui de organizare n general i despre informatica n special;
- integritatea i securitatea datelor etc.
In acest context, sistemului de gestiune al bazei de date i revin o serie de obiective, cum sunt:
1. Asigurarea independenei datelor.
Aa cum am artat mai devreme, acest obiectiv consta n linii mari din ndeplinirea urmtoarei
cerine: modificrile care se fac la un anumit nivel de structura de date nu trebuie s fie
'vizibile' la nivelul de organizare imediat superior.
23
2. Asigurarea unei redundane minime i controlate a datelor din baza de date.
Spre deosebire de sistemele clasice de prelucrare automata a datelor, stocarea datelor n cazul
bazelor de date se face astfel nct, pe ct posibil, fiecare informaie s apar o singur dat.
Totui, nu sunt excluse nici cazurile n care, pentru a realiza performante sporite (mai ales n
ce privete timpul de acces la date i implicit, timpul de rspuns la solicitrile utilizatorilor) s
se accepte o anumita redundanta a datelor. n acest caz se va institui insa un control automat al
redundantei n vederea asigurrii coerenei datelor din baza.
3. Asigurarea unor faciliti sporite de utilizare a datelor. Aceasta presupune:
- folosirea datelor de ctre mai muli utilizatori n diferite scopuri (aplicaii);
- accesul ct mai simplu al utilizatorilor la date, fr ca acetia s fie nevoii s cunoasc
structura ntregii baze de date, acest lucru rmnnd n sarcina administratorului bazei
de date;
- existenta unor limbaje performante de regsire a datelor, care permit exprimarea cu
uurin a criteriilor de selecie a datelor i indicarea unor reguli ct mai generale pentru
editarea informaiilor solicitate;
- spre deosebire de sistemul tradiional bazat pe Fiiere, unde exist un singur criteriu
de adresare (cel care a stat la baza organizrii Fiierului) n cazul bazelor de date,
sistemul de gestiune trebuie s ofere posibilitatea unui acces multicriterial, fr sortri
suplimentare. Modificarea criteriului la fiierele clasice implic, n majoritatea
cazurilor, reorganizarea lor;
- utilizarea unui limbaj ct mai apropiat de limbajul natural, cu posibilitatea exploatrii
bazei de date n regim conversaional. Aceasta ar oferi posibilitatea exploatrii n mod
facil a bazei de date i de ctre utilizatorii neinformaticieni.
4. Sporirea gradului de securitate a datelor mpotriva accesului neautorizat la ele.
Administratorul bazei de date poate prevedea ca accesul la baza de date s se fac numai prin
canale corespunztoare, i poate, totodat, defini verificri de autorizare care s se realizeze
oricnd se ncearc accesul la anumite date.
5. Asigurarea integritii datelor mpotriva unor tergeri intenionate sau neintenionate,
prin intermediul unor proceduri de validare, a unor protocoale de control concurent i a unor
proceduri de refacere a bazei de date dup incidente.
6. Asigurarea partajabilitii datelor. Partajabilitatea datelor trebuie neleas nu numai sub
aspectul asigurrii accesului mai multor utilizatori la aceleai date, ci i sub acela al
posibilitii dezvoltrii unor aplicaii fr a se modifica structura bazei de date.

S ne reamintim...
Obiectivele unui SGBD sunt:
Asigurarea independentei datelor.
Asigurarea unei redundante minime i controlate a datelor din
baza de date.
Asigurarea unor faciliti sporite de utilizare a datelor. Aceasta
presupune:
Asigurarea integritii datelor mpotriva unor tergeri intenionate
sau neintenionate.
Asigurarea partajabilitii datelor.
24

Funciile unui SGBD
Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea
numeroaselor operaii necesare funcionrii optime a sistemului. n funcie de natura lor i de
scopul urmrit, operaiile pot fi grupate pe activiti. Activitile accept i ele o grupare pe
funcii (una sau mai multe activiti, relativ omogene, re alizeaz o anumita funcie).
innd seama de complexitatea sistemului de gestiune, de facilitile oferite de acesta, de
limbajele utilizate i de tipul bazei de date ce urmeaz a fi gestionat de SGBD, gruparea
activitilor pe funcii are un oarecare caracter relativ. n situaia sistemelor de gestiune ce
utilizeaz limbaje gazd de nivel nalt, identificarea i delimitarea funciilor nu este att de
evident. Totui, n ciuda acestor particulariti, se pot prezenta cteva funcii cu caracter de
generalitate pentru toate sistemele de gestiune a bazelor de date i anume:
1. Funcia de descriere a datelor permite definirea structurii bazei de date cu ajutorul
limbajului de definire. Definirea datelor poate fi realizat la nivel logic, conceptual i fizic.
Aceasta funcie asigur:
- descrierea atributelor (cmpurilor) din cadrul structurii bazei de date,
- descrierea legturilor dintre entitile bazei de date sau dintre atributele aceleiai
entiti,
- definirea eventualelor criterii de validare a datelor,
- definirea metodelor de acces la date,
- definirea aspectelor referitoare la asigurarea integritii i confidenialitii datelor, etc.
Toate acestea se concretizeaz n schema bazei de date, memorat n cod intern.
2. Funcia de manipulare a datelor este cea mai complexa funcie i realizeaz urmtoarele
activiti:
- crearea (ncrcarea) bazei de date;
- adugarea de noi nregistrri;
- tergerea unor nregistrri;
- modificarea valorilor unor cmpuri;
- cutarea, sortarea i editarea parial sau total a unei nregistrri virtuale etc.
Funcia de manipulare a datelor se realizeaz prin intermediul limbajului de
manipulare a datelor.
3. Funcia de utilizare asigur mulimea interfeelor necesare pentru comunicarea tuturor
utilizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaionali. Acetia reprezint categoria beneficiarilor de
informaii (utilizatori finali) care utilizeaz limbajele de interogare a bazei de date ntr-o
form simplist. Ei apar ca utilizatori neinformaticieni;
- utilizatori programatori, care utilizeaz limbajele de manipulare, realiznd proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special i are rolul hotrtor n ceea
ce privete funcionarea optim a ntregului ansamblu.
25
4. Funcia de administrare a bazei de date apare ca o funcie complex i este de
competena administratorului bazei de date.

S ne reamintim...
Funciunile unui SGBD sunt:
Funcia de descriere a datelor permite definirea structurii bazei de
date cu ajutorul limbajului de definire.
Funcia de manipulare a datelor.
Funcia de utilizare asigur mulimea interfeelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date.
Funcia de administrare a bazei de date apare ca o funcie
complex i este de competena administratorului bazei de date.

M1.U1.6. Rezumat
Arhitectura unui SGBD cuprinde urmtoarele componente:
- baza de date propriu-zis n care se memoreaz colecia de date;
- sistemul de gestiune al bazei de date, care este un ansamblu de
programe (soft) care realizeaz gestiunea i prelucrarea complex
a datelor;
- un set de proceduri manuale i automate, precum i
reglementrile administrative, destinate bunei funcionri a
ntregului sistem;
- un dicionar al bazei de date (metabaza de date), ce conine
informaii despre date, structura acestora, elemente de descriere a
semanticii, statistici, documentaie etc.
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analiti -
programatori, gestionari, operatori).
Obiectivul informaticii l constituie culegerea, verificarea, transmiterea,
stocarea i prelucrarea automata a datelor cu ajutorul mijloacelor
electronice de calcul, n scopul satisfacerii diferitelor nivele de
conducere cu informaii necesare lurii deciziilor, n condiii de
eficienta economica sporita.
Obiectivele sunt:
Asigurarea independentei datelor.
Acest obiectiv consta n ndeplinirea cerinei ca modificrile care se fac
la un anumit nivel de structura de date s nu fie 'vizibile' la nivelul de
organizare imediat superior.
Asigurarea unei redundante minime i controlate a datelor din
26
baza de date.
Pe ct posibil, fiecare informaie s apar o singur dat. Nu sunt
excluse nici cazurile n care s se accepte o anumit redundan a
datelor.
Asigurarea unor faciliti sporite de utilizare a datelor.
Asigurarea integritii datelor mpotriva unor tergeri intenionate sau
neintenionate, prin intermediul unor proceduri de validare, a unor
protocoale de control concurent i a unor proceduri de refacere a bazei
de date dup incidente.
Asigurarea partajabilitii datelor. Partajabilitatea datelor trebuie
neleas i sub aspectul posibilitii dezvoltrii unor aplicaii fr a se
modifica structura bazei de date.
Funciunile unui SDGBD sunt
Funcia de descriere a datelor care permite definirea structurii bazei
de date cu ajutorul limbajului de definire.
Funcia de manipulare a datelor este cea mai complex funcie i
realizeaz urmtoarele activiti:
- crearea (ncrcarea) bazei de date;
- adugarea de noi nregistrri;
- tergerea unor nregistrri;
- cutarea, sortarea i editarea parial sau total a unei nregistrri
virtuale etc.
Funcia de manipulare a datelor se realizeaz prin intermediul
limbajului de manipulare a datelor.
Funcia de utilizare asigur mulimea interfeelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date. Sunt recunoscute mai
multe categorii de utilizatori:
- utilizatori "liberi" sau conversaionali. Ei apar ca utilizatori
neinformaticieni;
- utilizatori programatori, care utilizeaz limbajele de manipulare,
realiznd proceduri complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special i are
rolul hotrtor n ceea ce privete funcionarea optim a ntregului
ansamblu.
Funcia de administrare a bazei de date apare ca o funcie complex
i este de competena administratorului bazei de date.

1.3.1 Care sunt obiectivele unui SGBD?
1.3.2 Care sunt funciunile unui SGBD?
27
Unitatea de nvare 1.4 Baze de date distribuite

M1.U1.4 Introducere
O baza de date distribuit (BDD) este o colecie logic corelat de date
partajate, distribuite fizic pe o reea de calculatoare.
Un sistem de gest iune al unei baze de date distribuite (SGBDD) este un
sistem software care permite gestionarea BDD i face distribuirea transparent
pentru utilizator.
Sistemele de date distribuite sunt menite s rezolve problema "insulelor de
informaii". Ele au aprut ca o necesitate, n special in cazul reelelor de
calculatoare, pentru a sprijini gestionarea datelor n situaia cnd acestea se
regsesc fizic n diferite puncte ale reelei.

neleag ce este o baz de date distribbuit
cum se proiecteaz o baz de date distribuit

Generaliti
Primele sisteme de baze de date distribuite au fost INGRES/STAR, versiune
distribuit a lui INGRES, SQL*STAR versiune distribuit a lui ORACLE i R* versiune
distribuita a lui DB2.
Sistemul fizic (reeaua) care constituie suportul unei baze de date distribuite poate fi
format din calculatoare personale, minicomputere, staii de lucru, etc. toate legate n reea i
numite generic site-uri.
Putem reformula definiia de la nceput spunnd ca un sistem de baze de date
distribuite const dintr-o colecie de site-uri, fiecare putnd participa la executarea
tranzaciilor care acceseaz datele de pe un site sau de pe mai multe site -uri.
Printre cerinele pe care trebuie s le asigure un sistem de baze de date distribuite
menionm: autonomia locala n organizarea i prelucrarea datelor, neutilizarea unei
centralizri a evidenei i a datelor, posibilitatea de lucru continuu al site-urilor independent
de schimbrile in configuraiile de lucru (adugari sau eliminari de site-uri), independena
localizrii i fragmentrii datelor (transparena fizic), posibiliti de replicare (copiere) i
independena copiilor, prelucrarea distribuit a cererilor, administrarea distribuit a
tranzaciilor, independena de hardware, de sistemul de operare, de reea i de sistemul de
gestiune a bazelor de date.
28
Un SGBDD const dintr-o singur baz de date care este descompus n fragmente,
eventual unele fragmente sunt multiplicate, i fiecare fragment sau copie se pastreaz pe unul
sau mai multe site-uri, sub controlul unui SGBD local. Fiecare site este capabil sa proceseze
interogri utilizator n regim local, independent de restul reelei, sau este capabil s participe
la procesarea unor date situate n alte site-uri din reea. Pentru a spune c un SGBD este
distribuit trebuie s existe cle puin o cerere global.
Tranzaciile ntr-o baza de date distribuit sunt clasificate n tranzacii locale i
tranzacii globale dup site-urile pe care le solicit excutarea lor.
O configuratie pe retea reprezinta o baza de date distribuita daca diversele site-uri sunt
"constiente" de existenta celorlalte site-uri i daca fiecare site ofera un mediu in care se pot
executa tranzactii locale i globale.
Avantajele distribuirii bazelor de date:
- sistemul distribuit se modeleaz cel mai bine pe structura organizaional a multor
organizaii, avand n vedere ca multe companii sunt localizate "distribuit" din punct de
vedere geografic
- datele sunt partajabile dar administrarea lor se bucur de un grad nalt de autonomie local
- disponibilitatea bazei de date este evident mai bun dect n cazul centralizat. Dac se
semnaleaz unele erori sau "deri" de sistem la nivel local sistemul ]n ntregime poate s
continue s funcioneze n condiii satisfctoare
- fiabilitatea sistemului este mbuntit. Se pot reface rapid fiiere distruse utiliznd
replici aflate pe alte site-uri
- performanele n prelucrarea datelor se mbuntesc prin posibilitatea prelucr[rii n
paralel a unor interog[ri
- un sistem distribuit ofer avanatje economice dac lum n considerare costurile
implementrii i ntreinerii unei reele fa de costurile corespunztoare ale unui sistem
centralizat de putere comparabil de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrri locale ct mai multe (n caz sistemul i aplicaiile permit acest
lucru). De asemenea este mult mai convenabil s se "ajusteze" o reea de calculatoare la
nevoile organizaiei (dac[ de exemplu este necesar adugarea unor site-uri n plus) dect
un calculator central de putere asemntoare
- capacitatea de gestionare modular a sistemului permite extensii ale acestuia sau
rezolvarea unor "cderi" pariale fr s se afecteze prea tare (uneori fr a se afecta
deloc) mersul activitilor pe ansamblul sistemului distribuit.
Printre dezavantajele distribuirii amintim complexitatea crescuta a unui astfel de sistem.
Acesta este un dezavantaj major din care decurg unele dezavantaje "consecinta" dintre care:
- este mai greu de gestionat i de implementat un sistem distribuit
- costurile legate de un astfel de sistem sunt mult mai mari decat in cazul centralizat. Deja la
nivelul proiectarii i implementarii sistemului este necesar mai mult timp i personal
specializat. Ambele lucruri necesita costuri mai mari in bani. La aceste costuri se pot
adauga acelea care vin din necesitatea asigurarii echipamentelor hardware performante i
a soft-ului necesar. De asemenea, in cazul exploatarii sistemului la costurile obisnuite se
vor adauga costuri destul de ridicate de comunicatii.
- potential marit de erori. La erorile obisnuite in lucrul cu baze de date se pot adauga o serie
de erori cum ar fi de exemplu cele generate de algoritmi distribuiti.
29
- este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre site-
uri i a coordonarii acestora in general
- securitatea unui sistem distribuit este mai greu de asigurat decat in cazul unui sistem
centralizat. Datele sunt mai usor disponibile unor persoane neautorizate deoarece se poate
incerca acces la ele prin intermediul accesului intre calculatoare. Controlul la nivel fizic
administrativ are mai putina pondere decat in cazul unui sistem centralizat.
- intergitatea datelor este de asemenea mai greu de realizat intr-un sistem distribuit.
Integritatea se exprima de obicei in termeni de restrictii (reguli, conditii) pe care trebuie sa
le verifice datele din baza de date. Datorita costurilor mari de comunicatii (in timp i bani)
uneori se renunta la verificarea unor reguli in detrimentul consistentei bazei de date.
- lipsa standardelor. Nu se poate vorbi de o lipsa totala de standarde dar, lucrul cu sisteme
de date distribuite inca nu are la baza standarde internationale unanim acceptate. De aici
decurg dezavantaje cum ar fi: probleme de comunicare care se pun deoarece standardele
de comunicatii i protocoalele de acces la date inca nu au standarde fixate i acceptate pe
scara larga. Nu exista foarte multa experienta privind lucrul distribuit i proiectarea,
gestionarea i exploatarea unui sistem distribuit sunt mai dificile decat in cazul centralizat.
- un alt dezavantaj pe care il mentionam aici il constituie posibilitatea aparitiei unui flux
mare de informatii intre site-uri i de aici necesitatea rezolvarii unor probleme cum ar fi
sincronizarea mesajelor, detectarea i corectarea unor perturbari, eliminarea unor
inconsistente datorate redundantelor, etc.
Functiile i arhitectura unui SGBDD
Enumeram mai jos functiile principale ale unui SGBDD:
- toate functiile pe care le atribuim unui SGBD centralizat
- sa extinda comunicatiile pentru a furniza acces la site-urile din retea i sa permita
transferul de date i realizarea interogarilor
- sa gestioneze un dictionar de date extins pentru detalii legate de modul de distribuire a
datelor
- sa permita i sa sustina procesarea distribuita a interogarilor
- sa faciliteze un control extins al concurentei in scopl mentinerii unui grad satisfacator al
consistentei datelor
- sa ofere servicii de recovery extinse care sa rezolve caderi ale site-urilor i ale
comunicatiilor
Arhitectura ANSI-SPARC pe trei nivele a unei baze de date distribuite este redata grafic in
pagina urmatoare, Fig 7.1. Dam mai jos cateva explicatii referitoare la unele elemente
prezente in schema:
- schema conceptuala globala este o descriere logica a intregii baze de date, fara a se
evidentia aspectul distribuit. La acest nivel se definesc entitatile, relatiile, restrictiile de
integritate, informatiile generale de securitate a datelor.
- schemele de fragmentare descriu modelul logic al partitionarii bazei de date iar alocarea
descrie repartizarea fragmentelor i a eventualelor copii ale acestora pe site -urile retelei
- schemele locale de mapare redau fragmentele din schema de alocare in "obiecte" externe
bazei de date locale. Aceasta descriere este independenta de SGBD-ul ales i datorita
acestui fapt se poate vorbi de SGBD heterogene.
30
Ca o paranteza mentionam aici clasificarea SGBD-urilor distribuite in heterogene i
omogene.
SGBD omogene reprezinta situatia cand pe toate site-urile din retea este hardware similar,
sistem de operare identic si, cel mai important, SGBD local identic.
n cazul SGBD heterogene exista mai multe situatii dupa cum difera dotarea hardware,
sistemele de operare si/sau SGBD-urile utilizate local pe site-uri. Diferentele pot fi impinse
pana la a avea structuri ale bazei de date diferite (date de modele de date diferite) dar, evident,
lucrul in acest caz este destul de greoi i este supus multor limitari.
n cadrul unui SGBDD putem identifica urmatoarele componente:
- o component local SGBD (LSGBD)
- o component de comunicaii de date (CD)
- un dicionar de date global (DDG). Acest dicionar are aceeai funcionalitate ca i und
dicionar de date n cazul SGBD centralizat dar conine informaii suplimentare referitoare
la fragmentare i la alocarea datelor. i DDG poate fi fragmentat i replicat ca orice alt
informaie din baza de date distribuit
- componente de SGBD distribuit (SGBDD)

Proiectarea unei baze de date relaionale distribuite
Proiectarea corect a unei baze de date relaionale distribuite necesit, pe lng cerinele
cunoscute pentru sistemele centralizate, i realizarea urmtoarelor:
- fragmentarea datelor informaiile pot fi partitionate n fragmente care sunt apoi stocate
pe diferite site-uri n reea
- replicarea se pot realiza copii ale diferitelor relaii sau ale fragmentelor
- alocarea fragmentelor i a replicilor pe diferite site-uri
Definirea fragmentelor i alocarea acestora pe site-uri au ca obiective:
- realizarea, pe cat posibil a accesului in regim de referinte locale. Acolo unde este necesar
i unde permite aplicaia se recomanda utilizarea de copii ale fragment elor
- obtinerea unei fiabilitati i a unei disponibilitati deosebite ale bazei de date prin utilizarea
optima a replicarii fragmentelor
- realizarea unor parametri deosebiti de performanta. Daca se aloca prost datele pe site-uri
se ajunge fie la suprasolicitarea unui site (loc ingust) fie la utilizarea resurselor la un nivel
inferior
- optimizarea capacitatii i a costurilor de stocare. Capacitatea i costuril de stocare trebuie
puse in balanta cu tendinta de a avea referinte locale, deoarece au efecte contrare.
- optimizarea costurilor de comunicare. Aici sunt de luat in considerare mai ales costurile
interogarilor intre site-uri. Trebuie sa se aiba in vedere ca, daca se pot micsora costurile de
regasire atunci cand referintele sunt mai ales locale (sau cand fiecare site are propriile
copii ale datelor) in schimb actualizarile in aceeasi situatie pot crete costurile foarte mult
(si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate
site-urile.
Alocarea datelor
31
Se cunosc patru strategii de alocare a datelor ntr-o baza de date relaional distribuit:
1. centralizat
Baza de date se afl n ntregime pe un singur site din reea i este gestionat de un singur
DBMS. Spunem n acest caz c baza de date este procesat distribuit, ea de fapt nu mai
este o baz de date distribuit in adevaratul sens al cuvntului. Dezavantajele sunt mai ales
costurile mari de comunicaii i o fiabilitate i o disponibilitate foarte sczute, avnd n
vedere c orice eroare care blocheaz accesul la baza de date, practic paralizeaz ntreaga
activitate n reea pe aceast direcie.
2. fragmentat (partiionat)
Baza de date este partiionat n mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta paritionare a datelor poate mbuntti frecvena referinelor locale
- dac nu exist replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea i disponibilitatea sunt sczute dar nu aa de mici ca n cazul centralizat
- dac datele sunt distribuite corect, costurile de comunicare pot fi relativ sczute
3. replicat complet
Pe fiecare site se gseste o copie complet a bazei de date. Comentarii:
- eficiena referirilor locale, fiabilitatea i disponibilitatea sunt maxime
- costurile de stocare sunt n schimb i ele foarte mari, la fel sunt i costurile de
actualizare
4. replicat selectiv
Aceasta strategie este o combinaie intre partiionare, replicare i centralizare cu scopul de
a se cumula, pe cat posibil, avantajele fiecrei strategii i s se elimine dezavantajele.
Definirea replicilor i a fragmentelor, precum i alocarea acestora trebuie sa se bazeze pe
modul de utilizare a datelor din baza de date. In faza de analiza, la proiectarea bazei de date
trebuie sa se tina cont de cele mai frecvent utilizate aplicaii deoarece nu se poate realiza o
alocare care sa optimizeze toate aplicaiile simultan.
Printre criteriile care duc la decizia corecta de alocare a bazei de date:
- frecventa cu care se ruleaza o aplicaie
- site-urile de la care se ruleaza cel mai frecvent aplicaia
- modul de lucru al tranzactiilor executate de aplicaie i tipurile de acces la date
- etc.
Fragmentarea
La baza fragmentarii bazei de date exista, printre altele, urmatoaele motivari:
- mod de utilizare in general intr-o aplicaie utilizatorii au acces mai mult la view-uri
decat la intreaga baza de date
- eficienta se doreste ca datele sa fie stocate acolo unde sunt utilizate mai frecvent
- paralelism o tranzactie poate fi divizata in mai multe subinterogari care opereaza pe
fragmente in paralel i astfel se castiga t imp
32
- securitate datele care nu sunt necesare sunt stocate in alta parte, deci nu sunt la
dispozitia accesului neautoarizat
Dezavantajele lucrului cu fragmente ale bazei de date:
- performantele pot fi destul de scazute daca sunt necesare date ce apar in diverse
fragmente
- controlul integritatii datelor este mai dificil daca datele i dependentele functionale
sunt fragmentate i localizate pe diferite site-uri
Reguli de baz care duc la o fragmentare corect a bazei de date:
1. completitudine dac relaia R este descompus n fragmentele R
1
, R
2
, ,R
n
, trebuie
luate msuri care s previn pierderea de informaii
2. reconstrucie s fie posibil n orice moment s se refac relaia R de la care s -a pornit
cu fragmentarea. Aceasta regul conserv dependenele funcionale.
3. disjuncie dac data d
i
apare n fragmentul R
i
atunci nu este permis s apar n nici
un alt fragment. De la aceast regul se admite doar o excepie, cazul cnd o relaie
este fragmentat pe vertical.
Tipuri de fragmentare:
- pe orizontal
- pe vertical
- combinat
Fragmentarea pe orizontal:
Ne putem imagina c o tabel se fragmenteaz orizontal ca mai jos:

Un fragment al unei relaii partitionate pe orizontal const dintr-o submulime a tuplelor
relaiei respective.
Un fragment orizontal se produce prin selecie:
Fiecare tuplu din relatia R apare ntr-un anume fragment, o singur dat. Dac se dorete
reconstrucia relaiei, se utilizeaz reuniunea pentru a obine relaia R iniiala.
R= R
1
R
2
R
n

In general fragmentele unei relaii R sunt disjuncte.
Fragmentarea pe vertical
Un fragment vertical dintr-o relaie consta dintr-o relaie care are ca atribute o submulime a
atributelor relaiei iniiale.

Un fragment vertical se produce prin proiecie:
Dac S
1
_R i S
2
_R atunci ) (
1
1
R r
S
H = i ) (
2 2
R r
S
H = .
33
Completitudinea este asigurat prin faptul c fiecare atribut apare cel puin ntr- una din
submulimile S
1
i S
2
.
Reconstrucia relaiei iniilale se realizeaz prin jonciune natural.
2 1
) ( r X r R r
N
=
Aadar la descompunerea relaiei iniiale n fragmente trebuie s se in seama de regulile care
asigur o descompunere fr pierderi la jonciune.
In cazul descompunerii pe vertical nu este posibil s se realizeze o disjuncie total. Se
admite existena unor atribute comune, i anume a atributelor care formeaz cheile primare
(respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinitilor
ntre atribute, nc din faza de analiz.
Fragmentarea combinat (mixt, hibrid, compus)
1. fragmente verticale fragmentate orizontal

Expresia corespunzatoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: )) ( (
,...,
1
R
n
A A P
H o

2. fragmente orizontale fragmentate vertical

Expresia corespunztoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: )) ( (
,...,
1
R
P A A
n
o H

Transparena n SGBDD
Prima regula, considerat regula de baza in sistemele distribuite, este cerinta ca
aspectul distribuit trebuie sa fie transparent pentru util izator.
Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date
distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de
baze de date.
n realitate transparena poate fi realizat doar ntr-o anumit msur. Tipuri de
transparen:
1. transparena distribuirii
2. transparena tranzaciilor
3. transparena performanelor

Transparena distribuirii
34
Dac se realizeaz transparena distribuirii, utilizatorul percepe baza de date ca pe o
entitate unitar din punct de veder logic.
Acest tip de transparen se poate descompune n dou aspecte: utilizatorul nu trebuie
s cunoasc faptul c exist fragmentarea datelor (transparena fragmentrii) sau utilizatorul
nu tie de localizarea datelor pe reea (transparena localizrii).
Transparena fragmentrii este cel mai nalt grad de transparena. Utilizatorul se
adreseaz cu interogri bazei de date ca i cnd ar fi localizat centralizat, deci nu trebuie s
se preocupe de existena fragmentelor.
Transparena fragmentrii este strns legat de acordarea numelor (identificatorilor) n
cadrul bazei de date distribuite. i ntr-o baz de date distribuit (ca i n cazul centralizat)
numele diferitelor "obiecte" trebuie s fie unic. Dou site-uri nu pot conine obiecte cu nume
identice.
Sunt cateva solutii posibile:
1. Se poate crea un server central de nume care are menirea sa sigure ca numele date in
aplicaii distribuite sunt nume unice pe toata baza de date. Aceasta abordare are
dezavantajele ca se pierde autonomia locala a site-urilor, se poate ajunge la o
suprasolicitarea serverului de nume (se creeaza un asa-numit loc ingust - "bottleneck") i
disponibilitatea bazei de date este redusa (daca serverul de nume iese din uz temporar, se
blocheaza accesul la date)
2. Alternativa la solutia de mai sus este sa se recurga la prefixarea obiectelor cu un
identificator de site, de fragment, de copie.

Exemple
Prin notatia s1.client.f3.c2 se poate desemna copia a doua a
fragmentului 3 a tabelei client care se afla pe site-ul s1.

Consecinta cea mai grava a acestui mod de a numi obiectele este pierderea completa a
transparentei. In aceasta situatie mai exista un mod prin care se poate "indulci" situatia: se
utilizeaza alias-uri. De exemplu s1.client.f3.c2 poate avea ca alias numele client_local pentru
utilizatorii site-ului s1.
Transparenta localizarii reprezinta un nivel mediu de transparenta. In aceasta situatie
utilizatorul stie cum este fragmentata baza de date dar nu stie unde sunt plasate diferitele
fragmente sau copii ale acestora.
n interogari vor aparea numele fragmentelor dar nu se vor face referiri la localizare. O
interogare poate avea un format asemanator cu cel de mai jos:
select A
1
,A
n

from f1
where conditie1
union
select A
1
,A
n

from f2

Avantajul major in cazul de mai sus consta in faptul ca se poate oricand reorganiza
baza de date (ca locatii) fara ca aplicaiile ce o utilizeaza sa trebuiasca modificate.
35
Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite.
Utilizatorul trebuie sa specifice i numele fragmentelor i localizarea datelor.
Transparena tranzaciilor
Acest tip de transparena asigur faptul c toate tranzaciile distribuite pstreaz
integritatea i consistena BDD.
O tranzacie distribuit acceseaz date stocate la mai mult de o locaie n reea. Fiecare
tranzacie e divizata n sub-tranzacii, cte una pentru fiecare site accesat. Sub-tranzaciile se
execut n paralel pe site-uri i n mod concurent pe fiecare site. SGBDD are sarcini deosebite
n legtur cu gestionarea tranzaciilor distribuite dar acestea nu vor fi tratate in acest capitol.
n cadrul transparenei tranzaciilor se trateaz n mod deosebit transparena
concurenei i transparena erorilor. SGBDD ofer transparen concurenei dac rezultatele
tuturor tranzaciilor concurente (distribuite sau nu) sunt executate independent i sunt logic
echivalente cu rezultatele obtinue n cazul n care tranzaciile sunt executate pe rnd, ntr-o
ordine serial arbitrar.
Transparena erorilor necesit i un mecanism de recovery care ne s asigure c
tranzaciile se comport atomic n faa erorilor: ori sunt executate toate operaiile unei
tranzacii ori nici o operaie nu este executat. Odat ce o tranzacie s-a executat,
transformrile operate de ea asupra bazei de date sunt durabile (permanente).
Transparena performanelor
Transparena performanelor se asigur prin cerina ca sistemul considerat s aib
performane comparabile cu ale unui sistem centralizat. n aceast situaie trebuie ca SGBDD
s determine strategia cea mai eficient de a executa fiecare interogare n parte. n acest scop
un DQP (Distributed Query Processor) mapeaza o cerere de date ntr-o secven ordonat de
operatii asupra bazei de date. DQP decide ce fragment se acceseaz, ce copie se utilizeaz,
care locaie se utilizeaz. DQP produce o strategie de execuie care este optimizat relativ la o
funcie de cost. Costul asociat cu o interogare distribuita include:
- timp de acces (input/output) la accesarea datelor fizice pe suportul respectiv,
- timp CPU la executatrea operatiilor asupra datelor in memoria principala,
- costuri de comunicatii asociate cu transmiterea datelor prin retea.

M1.U1.6. Rezumat
O baza de date distribuit (BDD) este o colecie logic corelat de date partajate,
distribuite fizic pe o reea de calculatoare.
Tranzaciile ntr-o baza de date distribuit sunt clasificate n tranzacii locale i
tranzacii globale dup site-urile pe care le solicit excutarea lor.
Proiectarea corect a unei baze de date relaionale distribuite necesit, pe lng
cerinele cunoscute pentru sistemele centralizate, i realizarea urmtoarelor:
- fragmentarea datelor informaiile pot fi partitionate n fragmente care sunt apoi
stocate pe diferite site-uri n reea
36
Se cunosc patru strategii de alocare a datelor ntr-o baza de date relaional
distribuit:
centralizat
fragmentat (partiionat)
replicat complet
replicat selectiv
Tipuri de fragmentare:
- pe orizontal
- pe vertical
- combinat
Prima regula, considerata regula de baza in sistemele distribuite, este cerinta ca
aspectul distribuit trebuie sa fie transparent pentru utilizator.
Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date
distribuita, deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei
astfel de baze de date.
n realitate transparena poate fi realizat doar ntr-o anumit msur. Tipuri de
transparen:
- transparena distribuirii
- transparena tranzaciilor
- transparena performanelor

1.4.1 Ce este o baz de date distribuit?
1.4.2 Care sunt avantajele unui sistem distribuit?
1.4.3 Cum se poate face proiectarea alocrii datelor?
1.4.4 Cum se face o fragmentare corect?
1.4.5 Ce este fragmentarea?

37
Modulul 2. Modele de descriere a datelor

Cuprins
Introducere
Obiectivele modulului
U2.1 Generaliti
U2.2 Modelare E-R (Entity-Relaionship)

Introducere
Numim model de date o colecie integrat de concepte pentru
descrierea datelor, de relaii ntre date i de restricii asupra datelor,
toate ntr-o organizare unitar.
Un model de date este o abstracie. Un model de date are n
principal rolul de a furniza conceptele de baz i notaiile care s
permit proiectanilor i utilizatorilor bazei de date s comunice n
mod neambiguu legat de modul de organizare a datelor.

aleag ce model de date vor folosi pentru baza concret de date
disting modele la diferite nivele
descrie structura bazei de date cu ajutorul unui model grafic
s aleag cheia unei relaii n mod optim

38
Unitatea de nvare 2.1. Generaliti

Un model de date cuprinde trei pri:
(1) o parte referitoare la structur, care const ntr-un set de reguli ce impun
modul de alctuire al bazei de date;
(2) o parte referitoare la manipularea datelor, care definete tipul de operaii care
sunt permise asupra datelor. Sunt incluse aici operaiile care sunt utilizate
pentru a actualiza sau a regsi datele n baza de date precum i operaiile
pentru schimbarea structurii bazei de date;
(3) o parte referitoare la integritatea datelor, parte care cuprinde reguli de
integritate care asigura acurateea datelor.

aleag ce model de date vor folosi pentru baza concret de date
disting modele la diferite nivele

Durata medie de parcurgere a primei uniti de nvare este de 1 or.

Modele de date se pot realiza pentru fiecare nivel de abstractizare. Astfel putem vorbi de:
- model extern de date (care reprezint aa-numitul univers al discursului, adic punctul de
vedere al utilizatorului);
- model de date conceptual (care reprezint structura logica a bazei de date, independenta de
sistemul de gestiune ales);
- model de date intern (care reprezint schema conceptuala ntr-un mod n care poate fi
perceputa de SGBD).
Dintre diversele modele propuse n literatura de specialitate menionam aici: modelele de
date bazate pe obiecte, modelele de date bazate pe nregistrare, ambele modele fiind utilizate
pentru descrierea organizrii datelor la nivel extern i conceptual. Trebuie s menionam i
modelele fizice de date, care descriu dat ele la nivel intern.
Aceste modele utilizeaz concepte specifice modelului E-R i anume: entiti, atribute,
relaii. Cele mai cunoscute modele de date sunt: modelul entitate-relaie, modelul semantic,
modelul funcional, modelul orientat obiect.
Modele de date bazate pe nregistrare
ntr-un astfel de model baza de date consta dintr-un numr de nregistrri de format fix
de tipuri eventual diferite. Fiecare tip de nregistrare definete un numr fix de cmpuri,
39
fiecare fiind n general de lungime fixa. Exista trei tipuri importante de modele de date bazate
pe nregistrare: modelul de date relaional, modelul de date reea i modelul ierarhic de
date.
Modelele ierarhic i reea au fost dezvoltate mai nti, modelul relaional aprnd cu o
ntrziere de un deceniu.
Modele fizice de date
Aceste modele descriu efectiv modul n care datele sunt memorate n calculator, la
nivel fizic. Informaia furnizata de aceste modele este cea referitoare la nregistrrile fizice, la
ci de acces, la organizarea nregistrrilor, etc.
Se considera c schema conceptuala sta la baza structurrii unei baze de date. O
schema conceptuala completa i bine gndit permite o reprezentare interna eficienta i
permite realizarea de view-uri utilizator fr dificultate.
Modelarea conceptuala sau proiectarea conceptuala a bazei de date este procesul de
construire a unui model care s reprezinte modul n care este utilizata informaia de ctre
beneficiar, reprezentare care este independenta de detaliile de implementare cum ar fi
programele de aplicaie, limbajele de programare, SGBD-ul utilizat sau orice alte consideraii
fizice. Un astfel de model se numete model de date conceptual sau model logic.

Modelare E-R (Entity-Relaionship)
Modelul E-R (Entity-Relaionship) este un model conceptual de nivel nalt, dezvoltat
de Chen n 1976. Primele idei legate de utilizarea modelului E-R la proiectarea unei baze de
date au fost expuse de Chen (1977) i au fost continuate de Sakai (1980). Conceptele de
specializare i generalizare au fost introduse de Smith i Smith (1977) i au fost utilizate
ulterior de Lenzerini i Santucci (1983) la definirea restriciilor de cardinalitate. Avnd n
vedere limitele modelului E-R, vom discuta un model mai complex, modelul EE-R i
conceptul principal asociat acestuia, conceptul de specializare/generalizare.

M2.U2.1. Rezumat
Putem vorbi de:
model extern de date (adic punctul de vedere al utilizatorului);
model de date conceptual (care reprezint structura logica a bazei de date,
independenta de sistemul de gestiune ales);
model de date intern (care reprezint schema conceptuala ntr-un mod n care
poate fi perceputa de SGBD).
Modelele de date bazate pe obiecte sunt: modelul entitate-relaie, modelul
semantic, modelul funcional, modelul orientat obiect.
Exista trei tipuri importante de modele de date bazate pe nregistrare: modelul de
date relaional, modelul de date reea i modelul ierarhic de date.
Modele fizice de date descriu efectiv modul n care datele sunt memorate n
calculator, la nivel fizic.

40

2.1.1 Care sunt modele de date bazate pe nregistrare?

41
Unitatea de nvare 2.2 Modelare E-R (Entity-Relaionship)

Modelul E-R constituie un mod de reprezentare a bazelor de date relaionale
i de aceea este un instrument util n proiectarea acestora. n acest capitol, vom
descrie conceptele primare care stau la baza modelului E-R, dup care vom
identifica problemele care pot aprea prin utilizarea unui astfel de model. Vom
discuta de asemenea problemele generate prin utilizarea modelul E-R la
reprezentarea unor aplicaii.

descrie structura bazei de date cu ajutorul unui model grafic
s aleag cheia unei relaii n mod optim

Durata medie de parcurgere a primei uniti de nvare est e de 3 ore.
Concepte de baz
Conceptele primare ale modelului E-R includ : tip de entitate (mulime-entitate), tip de
relaie (mulime-relaie), atribute.
Numim entitate un obiect sau un concept ce se poate identifica n mod unic.
Noiunea de entitate este un concept de baza n cadrul modelului E-R. Ea reprezint 'obiecte'
concrete (cu existenta fizica) sau abstracte (cu existenta conceptuala).

Exemple
Popescu Ion, posesor al buletinului de identitate seria ABC, numrul: 444555
este o entitate deoarece identifica n mod unic o persoana n acest univers.

Ce este studentul Ion Ion?
Ce este grupa 7172?
O entitate care reprezint un obiect ceva mai abstract poate fi, de exemplu, un cont la
banca identificabil n mod unic prin numrul sau i numele bncii.
Numim tip de entitate sau mulime-entitate un set de entiti de acelai tip.

Exemple
Mulimea tuturor persoanelor care sunt studeni ai Facultii de tiine pot defini
mulimea-entitate sau tipul de entitate student.

Mulimea tuturor profesorilor Facultii de tiine formeaz ce?
42
Tipul de entitate reprezint o mulime de 'obiecte' ce aparin lumii reale i care sunt descrise
de aceleai proprietatea.
Orice obiect care aparine unui tip de entitate i care este identificabil n mod unic este numit
simplu entitate. (se mai ntlnesc denumirile: apariia unei entiti sau instana unei entiti).
Un tip de entitate conine mai multe entiti. O baza de date este o colecie de tipuri de entitat e
din care fiecare conine un numr neprecizat de entiti de acelai tip.
Tipurile de entitate nu sunt neaprat disjuncte. Aceasta nseamn c pot exista entiti care s
aparin mai multor tipuri de entitate.

Exemple
Se pot defini urmtoarele tipuri de entitate: profesor, corespunztor tuturor
cadrelor didactice ale Facultii de tiine i student, corespunztor tuturor
studenilor aceleiai faculti. Se observa uor c pot exista studeni care sunt
n acelai timp i cadre didactice (studeni la master care sunt preparatori sau
asisteni).

Artai c nici tipurile de entitate personal auxiliar i profesor nu sunt
disjuncte.
Un tip de entitate se identific printr-un nume i o list de proprietatea. O baz de date
conine n general mai multe tipuri de entiti.
Numim atribute proprietile ataate unui tip de entitate.

Exemple
Entitatea student poate fi descris de atributele: nume_student,
prenume_student, data_nasterii, sex, adresa, telef on, numr_matricol, grupa.

Cum ai descrie entitatea materii?
Prin domeniul atributului nelegem mulimea valorilor care pot fi atribuite unui atribut
simplu.
Atributele unei entiti conin valorile care descriu fiecare entitate i cu ajutorul crora fiecare
entitate se poate identifica n mod unic. Aceste valori reprezint cea mai mare parte a datelor
memorate ntr-o baza de date.
Domeniul unui atribut nu se poate defini ntotdeauna foarte exact. De exemplu, atributul
nume_student trebuie s fie un ir de caractere dar poate lua ca valori doar un nume de familie
existent. Unele domenii se pot descompune n mai multe subdomenii. De exemplu
data_naterii se poate descompune n subdomeniile: an, lun, zi.
In general putem considera c fiecare entitate este reprezentabila cu ajutorul unei mulimi de
perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut ataat
tipului de entitate corespunztor.
43

Exemple
O entitate a tipului de entitate student poate fi reprezentata de mulimea:
{(nume_student, Popescu), (prenume_student, Ion), (data_nasterii, 15.11.1981),
(sex, masculin), (adresa, B-dul Garii, 12, Brasov, cod 2200, judetul Brasov),
(telefon, 068/444555), (numr_matricol, 31455), (grupa, 7211)}

Reprezentai o entitate a tipului de entitate materii.
Atributele se pot clasifica n simple sau compuse; cu o singur valoare sau cu mai multe
valori; respectiv derivate.
Numim atribut simplu orice atribut care are doar o singur component i o existen
independent.
Aceste atribute nu se pot diviza n mai multe atribute distincte. Ele se mai numesc i atribute
atomice.

Exemple
Atributul sex corespunztor tipului de entitate student.

Artai alte atribute simple ale tipului de entitate materii.
Numim atribut compus orice atribut care are mai multe componente, fiecare cu o existen
independent.
Aceste atribute se pot diviza n general n mai multe atribute simple.

Exemple
Atributul adres se poate descompune n atributele: strada, numr, ora,
cod_potal i jude.

Artai alte atribute compuse.
Decizia ca un atribut compus s se descompun n mai multe atribute simple este dependent
de modul n care se va utiliza acel atribut: pe componente, sau ca un ntreg.
Numim atribut cu o singur valoare orice atribut care poate lua cate o singur valoare
pentru fiecare entitate.
Majoritatea atributelor sunt atribute cu o singur valoare.
Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru
fiecare entitate.
Pentru atributele cu mai multe valori trebuie precizate numrul minim i numrul maxim de
valori pe care le poate lua atributul respectiv.

Exemple
Atributul telefon poate fi un atribut cu mai multe valori. n acest caz se poate
limita de exemplu numrul numerelor de telefon la care poate fi gsit studentul la
44
minim 0 i la maxim 3. Deci se pot stabili numrul minim i numrul maxim de
valori pe care le poate lua atributul.

Artai alte atribute cu mai multe valori.
Numim atribut derivat orice atribut a crui valoare se poate calcula din unul sau mai
multe alte atribute. Aceste atribute nu trebuie neaprat s descrie entitatea creia ii corespunde
atributul derivat.

Exemple
Valoarea pentru atributul vrsta este derivat din valoarea atributului
data_naterii i din data curent.

Artai alte atribute derivate.
Valoarea atributului numrul_total_de_entiti se poate calcula numrnd entitile
nregistrate.

S ne reamintim...
entitate care reprezint un obiect ceva mai abstract poate fi, de
exemplu, un cont la banca identificabil n mod unic prin numrul sau i
numele bncii.
Numim tip de entitate sau mulime-entitate un set de entiti de
acelai tip.
Prin domeniul atributului nelegem mulimea valorilor care pot fi
atribuite unui atribut simplu.
Numim atribut simplu orice atribut care are doar o singur component
i o existen independent
Numim atribut compus orice atribut care are mai multe componente,
fiecare cu o existen independent.
Numim atribut cu mai multe valori orice atribut care poate lua mai
multe valori pentru fiecare entitate.
Numim atribut derivat orice atribut a crui valoare se poate calcula din
unul sau mai multe alte atribute.
Reprezentare grafic - diagrame E-R
ntreaga structura logica a unei baze de date poate fi reprezentata grafic cu ajutorul
diagramelor E-R. O astfel de diagrama conine elemente grafice cum ar fi:
- dreptunghiuri, care reprezint tipuri de entitate;
- elipse, care reprezint atribute;
- linii, care au rolul de a evidenia legturile ntre elementele diagramei.
Dreptunghiurile i elipsele sunt etichetate cu numele 'obiectului' reprezentat. Acestea nu sunt
singurele elemente grafice utilizate ntr-o diagrama E-R. Pe msur ce vom defini noi
concepte vom reveni cu precizri legate de modul de a le reprezenta.
Un atribut se reprezint printr-o elips, legat de entitatea creia i este asociat cu o linie i
etichetat cu numele atributului. Elipsa este trasata cu linie punctat, dac atributul este un
atribut derivat i respectiv cu linie dubl, daca atributul poate lua mai multe valori.
45
Dac un atribut este compus, atunci componentele atributului se reprezint prin elipse legate
cu cate o linie de atributul compus.

Exemple

Reprezentarea cu diagrama E-R a entitii locatari
n exemplu entitatea locatari are urmtoarele atribute: numr_matricol, nume i
adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se
descompune n numr_bloc, scara, etaj i apartament. Explicaia sublinierii
atributului numr_matricol se va da n seciunea care se ocupa de chei, tot n
aceast unitate de nvare.

Desenai structura corespunztoare tipului de entitate student.

Numim tip de relaie orice asociere ntre tipuri de entiti.
Numim relaie orice asociere ntre entiti, cnd asocierea include cate o entitate pentru toate
tipurile de entitate participante.
Fie E
1
, E
2
, ..., E
n
tipuri de entitate. Formal, un tip de relaie este o submulime a urmtoarei
mulimi:
{( e
1
, e
2
, ..., e
n
) | unde e1eE1, e
2
eE
2
, ..., e
n
eE
n
}
ceea ce nseamn c ( e
1
, e
2
, ..., e
n
) reprezint formal o relaie.

Exemple
ntr-o aplicaie care ar servi unor evidente n cadrul asociaiilor de locatari putem
considera tipul de entitate locatari descris de atributele: nume, adresa i
numr_matricol i tipul de entitate scri descris de atributele numr_de_bloc i
scara. ntre tipul de entitate scri i tipul de entitate locatari se poate stabili un
tip de relaie numit este_locuita_de. Acest tip de relaie va conine relaii de tipul
('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu
Ion".

Descriei relaiile care apar ntre student i catalog.

locatari
num
e
numr
matric
ol
adres
a
adres
a
adres
a
adres
a
adres
a
adres
a
numr
bloc

scara

etaj
apartam
ent

46
Numim gradul relaiei numrul entitilor participante n relaie. Aadar relaia reprezentat
mai sus are gradul n. Entitile implicate ntr-o relaie se numesc participani. Dac ntr-o
relaie sunt doi participani, atunci relaia se numete binar.
Tipurile de relaii se reprezint n diagramele E-R cu ajutorul romburilor care sunt etichetate
cu numele tipului de relaie.

Exemple

Reprezentarea cu diagrama E-R a relaiei este_locuita_de

Reprezentai relaia dintre student i catalog.

Funcia pe care o joaca o entitate ntr-o relaie se numete rolul entitii. n general nu este
necesar s se specifice rolul entitilor ntr-o relaie, deoarece acesta este n general implicit.
Numim relaie recursiv orice relaie n care aceleai entiti particip n roluri diferite. n
acest caz este necesar s se precizeze rolurile entitilor implicate. n cazul relaiilor recursive,
n diagrama E-R corespunztoare, cele dou arce de la entitate la relaie i napoi, primesc
diferite etichete, care sunt importante n nelegerea corect a relaiei.

Exemple
Dac am considera entitile lucrtori i manageri care se refera la personalul
aceleiai ntreprinderi, am face constatarea c sunt descrise de aceleai atribute
deci aparin aceluiai tip de entitate i anume angajai. Relaia binara
lucreaz_pentru, stabilita ntre lucrtori i manageri este o relaie recursiva.
Rolurile jucate de fiecare entitate se pot stabili recurgndu-se la perechi ordonate
(muncitor, manager).

Exemple

1 M
locatari scri
numr
matric
ol
nume
adre
sa
num
r de

bloc
scar
a
este
locuit

angajai
lucreaz
pentru
lucrator
manager
47

Reprezentarea cu diagrama E-R a relaiei recursive lucreaz_pentru
Astfel relaia ('Popescu Ion', 'Ionescu Gheorghe') se interpreteaz "Popescu Ion
lucreaz pentru (este subordonatul lui) Ionescu Gheorghe".

Dai un exemplu de relaie recursiv legat de entitatea profesor.
Unui tip de relaie i se pot asocia atribute descriptive n acelai mod n care se pot asocia
atribute unui tip de entitate.

Exemple
Tipului de relaie este_locuita_de, care implica tipurile de entitate scri i
locatari, i se poate asocia atributul data care s retina data la care locatarul L s-a
mutat pe scara S. Dup cum se observa, acest atribut descrie exclusiv tipul de
relaie i el nu mai are sens n afara ei.

S ne reamintim...
Numim relaie orice asociere ntre entiti, cnd asocierea include cate o
entitate pentru toate tipurile de entitate participante.
Numim gradul relaiei numrul entitilor participante n relaie. Entitile
implicate ntr-o relaie se numesc participani. Dac ntr-o relaie sunt doi
participani, atunci relaia se numete binar.
Numim relaie recursiv orice relaie n care aceleai entiti particip n
roluri diferite. n acest caz este necesar s se precizeze rolurile entitilor
implicate.

Restricii structurale
Este posibil s se stabileasc diverse restricii la care coninutul unei baze de date
trebuie s se conformeze. Vom trata n continuare restriciile care se pot impune entitilor
participante ntr-o relaie. Aceste restricii trebuie s reflecte caracteristicile relaiilor aa cum
se percep n 'lumea reala'. Doua tipuri importante de restricii sunt de menionat aici: restricii
de cardinalitate i restricii de participare.
a) Restricii de cardinalitate Numim cardinalitate (polaritate) numrul relaiilor posibile
pentru o entitate participant. Altfel spus, cardinalitatea exprima numrul entitilor la care o
alta entitate poate fi asociata prin intermediul unei relaii.
Observaie: Am utilizat n definiia de mai sus referiri la entiti i la relaii pentru a fi mai
explicii. Restriciile structurale se refera insa n mod evident la tipurile de relaie i la tipurile
de entitate asociate. Aceast observaie rmne valabila i n consideraiile ce urmeaz.
Majoritatea tipurilor de relaie au gradul doi. Cardinalitatea n acest caz poate fi de tipurile:
unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-multe (M:N).
Relaiile unu-la-unu:
48
n relaiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legat de cel mult
o entitate din celalalt tip de entitate implicat n relaia respectiva. Implicarea fiecarei entitati
ntr-o relaie data este numita "participarea entitatii".
In diagrama E-R se eticheteaza arcul dintre relaie i fiecare tip de entitate cu cardinalul
relaiei; n cazul relaiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.
Relaiile unu-la-mai-multe:
In relaia de tip unu-la-mai-multe orice entitate, aparinnd primului tip de entitate, este legat
de 0, 1, sau mai multe entiti apartinand celui de-al doilea tip de entitate participant la relaie.

Exemple
Exemplificm acest tip de relaie prin relaia este_locuita_de dintre tipurile de
entiti scari, respectiv locatari. n reprezentarea grafic a acestui tip de
relaie, arcul dinspre tipul de entitate scri se eticheteaz cu 1 iar arcul dinspre
tipul de entitate locatari se eticheteaz cu M

Modelul semantic din figur reprezint relaia unu-la-mai-multe
este_locuita_de.

Din exemplul de mai sus se observ uor c dac relaia direct este de unu-la-mai-
multe, atunci relaia invers este de unu-la-unu.
Relaiile mai-multe-la-mai-multe:
Acest tip de relaie se deosebete de relaia unu-la-mai-multe prin faptul c relaia
invers nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dac i relaia direct i relaia
invers sunt de tipul unu-la-mai-multe, atunci relaia directa este de tipul mai-multe-la-mai-
multe i se noteaz cu (N:M).

Dai un exemplu de n la m ntre student i materii.

Exemple

locatari scri
numr
matric
ol
nume
adre
sa
num
r de

bloc
scar
a
este
locuit

1 M
Sc.
A

Sc.B

Sc.C
scri este locuita
de
R1

R2

R3
- Fam
.1

- Fam
.2

- Fam
.3
locatari
nr_blo
c
scara

nr_blo
c
scara

nr_blo
c
scara
atribu
te
nr_ma
t
numel
e

nr_ma
t
numel
e

nr_ma
t
numel
atribu
te
49
Reprezentarea cu reele semantice a relaiei 1:M este_locuita_de

Reprezentai cu reea semantic relaia dintre student i catalog.

S ne reamintim...
Restricii de cardinalitate
Numim cardinalitate (polaritate) numrul relaiilor posibile pentru o
entitate participant.
Majoritatea tipurilor de relaie au gradul doi. Cardinalitatea n acest caz
poate fi de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-
multe-la-mai-multe (M:N).
n relaiile unu-la-unu, o entitate, apartinand unui tip de entitate, este
legat de cel mult o entitate din celalalt tip de entitate implicat n relaia
respectiva
In relaia de tip unu-la-mai-multe orice entitate, aparinnd primului tip de
entitate, este legat de 0, 1, sau mai multe entiti apartinand celui de -al
doilea tip de entitate participant la relaie.
Relaiile mai-multe-la-mai-multe se deosebete de relaia unu-la-mai-
multe prin faptul c relaia invers nu este de unu-la-unu, ci de unu-la-
mai-multe. Deci, dac i relaia direct i relaia invers sunt de tipul unu -
la-mai-multe, atunci relaia directa este de tipul mai-multe-la-mai-multe i
se noteaz cu (N:M).

b) Restricii de participare
Numim restricii de participare acele restricii prin care se determin dac existena
unui tip de entitate depinde de faptul c este legat sau nu de un alt tip de entitate prin
intermediul relaiei n discuie.
Participarea unei entiti poate fi total sau parial. Participarea este totala daca
existenta entitii respective necesita existenta unei entiti asociate n relaia dat. n caz
contrar participarea se numete parial. Termenii participare totala i participare parial pot
fi nlocuii cu participare obligatorie respectiv participare opionala. n diagrama E-R aceste
tipuri de relaii se reprezint prin arc cu linie dubl pentru participarea total, respectiv cu
linie simpl pentru participarea parial. Pentru participarea parial, exist un mod de notaie
prin care se eticheteaz arcele relaiei cu perechea de numere ce reprezint minimul, respectiv
maximul entitilor participante la relaie.

Exemple
Daca se considera filialele unei firme oarecare ca entiti n tipul de entitate
filiala i daca se considera tipul de entitate personal (unde entitile reprezint
personalul firmei respective) se poate defini tipul de relaie are_alocat stabilit
ntre o filiala concreta i personalul firmei. n acest caz, daca se considera c
fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate
filiala n relaia are_alocat este totala. Daca insa admitem c unii membri ai
personalului (de exemplu vnztorii) nu lucreaz n birourile nici unei filiale,
atunci participarea tipului de entitate personal n relaia are_alocat este pariala.
50

Discutai participarea n relaia student cu materii.

S ne reamintim...
Participarea unei entiti poate fi total sau parial. Participarea este totala daca
existenta entitii respective necesita existenta unei entiti asociate n relaia
dat. n caz contrar participarea se numete parial.
c) Dependenele de existen
Numim tip slab de entitate un tip de entitate, a crui existen este dependent de
existenta unui alt tip de entitate.
Numim tip tare de entitate un tip de entitate, a crui existen nu depinde de existenta nici
unui alt tip de entitate.
Entitile slabe se mai numesc existenial dependente sau subordonate iar entitile tari se
mai numesc printe sau dominante.
n diagrama E-R tipurile de entitate tari se reprezint cu un dreptunghi trasat cu linie simpla.
Pentru tipurile de entitate slabe conturul dreptunghiului este trasat cu linie dubla. De
asemenea aceasta notaie se extinde i la relaii. Astfel: o relaie care leag doua tipuri de
entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaia care leag un tip de
entitate tare de un tip de entitate slab este reprezentata cu un romb trasat cu linie dubla.
Chei
Conceptual este evident c entitile i relaiile individuale care participa la modelarea
unei baze de date sunt distincte ntre ele. Diferena ntre entiti sau diferena ntre relaii se
exprima cu ajutorul atributelor care le descriu.
Numim supercheie asociata unui tip de entitate, orice submulime a mulimii de
atribute ce descriu tipul de entitate, submulime care poate duce la identificarea n mod unic a
oricrei entiti n cadrul tipului de entitate luat n considerare.
Este evident ca, daca o submulime de atribute formeaz o supercheie, atunci orice
mulime de atribute care include supercheia este tot o supercheie.
Numim cheie candidat orice supercheie care conine un numr minim de atribute.
Pentru o cheie candidat nici o submulime proprie nu mai este supercheie. Putem spune c o
cheie candidat este caracterizata de urmtoarele proprietatea:
- unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate n parte;

Dai exemple de chei n entitatea profesor.

S ne reamintim...
Participarea unei entiti poate fi total sau parial. Participarea este totala
daca existenta entitii respective necesita existenta unei entiti asociate n
relaia dat. n caz contrar participarea se numete parial.
Numim supercheie asociata unui tip de entitate, orice submulime a
mulimii de atribute ce descriu tipul de entitate, submulime care poate
duce la identificarea n mod unic a oricrei entiti n cadrul tipului de
51
- ireductibilitatea, deoarece nici o submulime proprie de atribute ale cheii nu are
proprietatea de unicitate.
Observaie: Faptul c valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi
determinat dect cu ajutorul informaiilor semantice referitoare la valorile atributelor ce
formeaz cheia. Trebuie s se cunoasc semnificaiile din lumea reala a atributelor ce
formeaz cheia pentru a se stabili daca acestea vor avea valori unice. Doar faptul ca, pentru o
mulime oarecare de entiti concrete, valorile difer ntre ele nu este de ajuns.
Pentru un tip de entitate este posibil s se poat determina una sau mai multe chei
candidat. Dintre acestea, cheia primar este cheia aleasa ca mijloc principal de identificare a
entitilor n cadrul tipului de entitate respectiv. Cheia primar este n general cea mai scurt
dintre cheile candidat. In diagrama E-R atributele care intr n componena cheii primare, se
evideniaz prin sublinierea numelui atributului.
Numim cheie compus orice cheie candidat care conine cel puin dou atribute.
Probleme se ivesc atunci cnd trebuie s identificam n mod unic entitile unui tip de entitate
slab. S observam c un tip de entitate tare are ntotdeauna o cheie primara, deci are
ntotdeauna cel puin o cheie candidat. Un tip de entitate slab nu are cheie primara.
Numim discriminatorul unui tip de entitate slab, un set de atribute care permite
realizarea unei distincii ntre entitile care depind de o anume entitate tare. Aadar, cheia
primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare
de care este dependenta existenial, la care se adaug mulimea atributelor care compun
discriminatorul tipului de entitate slab.
entitate luat n considerare.
Numim cheie candidat orice supercheie care conine un numr minim
de atribute. Pentru o cheie candidat nici o submulime proprie nu mai
este supercheie.
Pentru un tip de entitate este posibil s se poat determina una sau mai
multe chei candidat.
Dintre acestea, cheia primar este cheia aleasa ca mijloc principal de
identificare a entitilor n cadrul tipului de entitate respectiv.
Numim cheie compus orice cheie candidat care conine cel puin dou
atribute.
Numim discriminatorul unui tip de entitate slab, un set de atribute care
permite realizarea unei distincii ntre entitile care depind de o anume
entitate tare. Aadar, cheia primara a unui tip de entitate slab este
formata din cheia primara a tipului de entitate tare de care este
dependenta existenial, la care se adaug mulimea atributelor care
compun discriminatorul tipului de entitate slab.
Si relaiile au chei. Cu ajutorul cheilor se pot identifica n mod unic
relaiile individuale.
Cheia primara a tipului de relaie este formata din reuniunea
mulimilor de atribute care formeaz cheile primare ale tipurilor de
entitate participante.

52
Si relaiile au chei. Cu ajutorul cheilor se pot identifica n mod unic relaiile
individuale. Cheia primara a tipului de relaie este formata din reuniunea mulimilor de
atribute care formeaz cheile primare ale tipurilor de entitate participante.

M2.U2.2. Rezumat
Numim relaie orice asociere ntre entiti, cnd asocierea include cate o entitate
pentru toate tipurile de entitate participante.
Numim gradul relaiei numrul entitilor participante n relaie. Entitile
implicate ntr-o relaie se numesc participani. Dac ntr-o relaie sunt doi
participani, atunci relaia se numete binar.
Numim relaie recursiv orice relaie n care aceleai entiti particip n roluri
diferite. n acest caz este necesar s se precizeze rolurile entitilor impli cate.
Numim cardinalitate (polaritate) numrul relaiilor posibile pentru o entitate
participant.
Majoritatea tipurilor de relaie au gradul doi. Cardinalitatea n acest caz poate fi
de tipurile: unu-la-unu (1:1), unu-la-mai-multe (1:M), sau mai-multe-la-mai-
multe (M:N).
n relaiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legat de cel
mult o entitate din celalalt tip de entitate implicat n relaia respectiva
In relaia de tip unu-la-mai-multe orice entitate, aparinnd primului tip de
entitate, este legat de 0, 1, sau mai multe entiti apartinand celui de-al doilea tip
de entitate participant la relaie.
Relaiile mai-multe-la-mai-multe se deosebete de relaia unu-la-mai-multe prin
faptul c relaia invers nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dac
i relaia direct i relaia invers sunt de tipul unu-la-mai-multe, atunci relaia
directa este de tipul mai-multe-la-mai-multe i se noteaz cu (N:M).
Numim supercheie asociata unui tip de entitate, orice submulime a mulimii de
atribute ce descriu tipul de entitate, submulime care poate duce la identificarea n
mod unic a oricrei entiti n cadrul tipului de entitate luat n considerare.
Numim cheie candidat orice supercheie care conine un numr minim de
atribute. Pentru o cheie candidat nici o submulime proprie nu mai este
supercheie.
Pentru un tip de entitate este posibil s se poat determina una sau mai multe chei
candidat.
Dintre acestea, cheia primar este cheia aleasa ca mijloc principal de identificare
a entitilor n cadrul tipului de entitate respectiv.

M2.U.2.2 Test de autoevaluare a cunotinelor
2.2.1 Gsii cheile candidat ale tabelei student. Stabilii cheia primar.
2.2.2 Dai exemple de relaii unu la unu, unu la mai mul i i muli la muli.
2.2.3 Stabilii domeniul fiecrui atribut din tabela profesor.

53

Modulul 3. Limbaje de cereri.

Cuprins
Introducere
Obiectivele modului
U3.1 Algebra relaional.
U3.2 SQL.

M3. Introducere
Una din funciunile importante ale SGBD+urilor este regsirea datelor. Pentru
aceasta trebuie s facem cereri la baza de date. Modelul matematic al acestor
cereri la baza de date relaional este algebra relaional, iar limbajul standardizat
de cereri este SQL.

Fac operaii n algebra relaional
Exprime cereri n algebra relaional
Exprime cereri n SQL
exprime actualizri ale bazei de date

54

Unitatea de nvare 3.1 Algebra relaional.

In cadrul bazelor de date relaionale, datele sunt organizate sub forma unor
tablouri bidimensionale (tabele) de date, numite relaii. Asocierile dintre relaii se
reprezint explicit prin atribute de legtur. Aceste atribute figureaz ntr -una din
relaiile implicate in asociere (de regul, n cazul legaturilor de tip "unu la muli")
sau sunt plasate ntr-o relaie distinct, construit special pentru exprimarea
legaturilor ntre relaii (n cazul legaturilor de tip "muli la muli"). O baz de date
relaional (BDR) reprezint un ansamblu de relaii, prin care se reprezint att
datele ct i legturile dintre date.
Operatorii modelului relaional definesc operaiile care se pot efectua asupra
relaiilor, n scopul realizarii funciilor de prelucrare asupra bazei de date,
respectiv consultarea, inserarea, modificarea i tergerea datelor.
Restriciile de integritate ale modelului relaional permit definirea st rilor
coerente ale bazei de date.
n continuare, vor fi prezentate pe larg aceste componente.

Fac operaii n algebra relaional
Exprime cereri n algebra relaional


Structura relaionala a datelor
Prezentarea structurii relaionale a datelor impune reluarea noi unilor de: domeniu,
relaie, atribut i schem a unei relaii.
Domeniul reprezint un ansamblu de valori, caracterizat printr -un nume. Un domeniu
se poate defini explicit, prin enumerarea tuturor valorilor apartinnd acestuia sau implicit, prin
precizarea proprietilor pe care le au valorile din cadrul domeniului respectiv.
55

Exemple
Sa considerm, de exemplu domeniile D1, D2, D3, definite astfel:
D1: ("F","M")
D2 : (x / x aparine N, x aparine [0,100])
D3 :(s/s=ir de caractere)
n cazul lui D1 s-a recurs la o definire explicit, n timp ce pentru D2 i D3 s-a
utilizat definirea implicit.

Pentru un ansamblu de domenii D1, D2, ..., Dn produsul catezian al acestora
reprezinta ansamblul tuplurilor <v1, v2, . .., vn>, unde: v1 este o valoare apartinnd
domeniului D1, v2 este o valoare din D2 s.a.m.d.

Exemple
De exemplu, tuplurile: <"Maria", "F", 50>, <"Vasile", "M",15>,
<"Vasile","M",20>, <"Vasile", "F",100> aparin produsului cartezian: D3 x D1 x
D2

S presupunem c se acord o anumit semnificaie valorilor domeniilor D1, D2, D3,
definite anterior.
Sa considerm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane,
D2 conine valori care exprim vrsta unei persoane i D3 cuprinde numele unor persoane.
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o
semnificaie i anume cele care conin numele, sexul i vrsta aceleiai persoane.
Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul
poate avea o semnificaie, dac presupunem c exist o singur persoan cu
acest nume.
Se desprinde de aici necesitatea definirii unei submulimi de tupluri, din cadrul
produsului cartezian al domeniilor, submulime care s cuprind numai tuplurile cu
semnificaie.
Relaia reprezint un subansamblu al produsului cartezian al mai multor domenii,
subansamblu caracterizat printr-un nume i care conine tupluri cu semnificatie. Considernd
de exemplu c nu se cunosc dect dou persoane definim realia R prin tuplurile care descriu
aceste persoane i anume:
R : (<"Maria", "F", 30>, <"Vasile", "M", 35>)
Intr-o relaie, tuplurile trebuie s fie distincte (nu se admit duplicri ale
tuplurilor) .
O reprezentare comod a relaiei este tabelul bidimensional (tabela de date n care
liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).

Exemple

Relaie reprezentat sub forma unei tabele de dat e

56
Reprezentarea tabelar este preferat adesea altor forme de reprezentare a relaiilor,
ntrucat este uor de neles i de utilizat.
n prezentarea conceptului de reatie se recurge uneori la analogii cu alte concepte,
extrem de bine cunoscute n domeniul prelucrrii automate a datelor precum cel de fiier.
Relaia poate avea semnificaia unui fiier,tuplul poate fi considerat drept o nregistrare, iar
valorile din cadrul tuplului pot fi interpretate drept valori ale cmpurilor de nre gistrare.
n cadrul modelului relaional nu intereseaza decat relaiile finite, chiar dac
n construirea relaiilor se admit domenii infinite. Numrul tuplurilor dintr -o
relaie reprezinta cardinalul relaiei, n timp ce numrul valorilor dintr -un tuplu defineste
gradul relaiei.
In timp ce tuplurile dintr-o relaie trebuie s fie unice un domeniu poate apare de mai
multe ori n produsul cartezian pe baza cruia este definit relaia.

Exemple
S considerm, de exemplu c pentru o persoana dispunem de urmatoarele date:
nume,sex, vrsta i numele soului/soiei.
O posibilitate de organizare a acestor date o reprezint relaia din figur
R: D
3
D
1
D
2
Maria F 30
Vasile M 35

Relatia PERS reprezint un subansamblu al produsului cartezian:
D3 x D1 x D2 x D3.
Semnificaia valorilor din cadrul unui tuplu se stabilete

Semnificaia valorilor din cadrul unui tuplu se stabilete n acest caz nu numai pe baza
domeniului de care aparin valorile, ci i in funcie de poziia ocupat n cadrul tuplului.
Dependena fat de ordine a datelor inseamn o reducere a flexibiltii organizarii datelor.
ntr-o organizare eficient, flexibil, ordinea liniilor i a coloanelor din cadrul tabele i de date
nu trebuie s prezinte nici o importan. Pentru a diferenia coloanele care conin valori ale
aceluiai domeniu i a elimina astfel dependena de poziie n cadrul tabelei se asociaz
fiecarei coloane un nume distinct, ceea ce duce la aparita noiunii de atribut.
Atributul reprezint coloana unei tabele de date, caracterizat printr -un nume. Numele
coloanei (atributului) exprim de obicei semnificaia valorilor din cadrul coloanei respective.
Schema unei relaii
Prin schema unei relaii se ntelege numele relaiei, urmat de lista atributelor, pentru
fiecare atribut precizndu-se domeniul asociat. Astfel, pentru o relaie R, cu atributele A1, A2,
..., An i domeniile: D1, D2,..., Dm, cu m <= n, schema relaiei R poate fi reprezentat ntr -
una din formele

R(A
1
:D
1
, , A
n
:D
m
)

a) b)

Operatorii modelului relaional.
Modelul relaional ofer dou colecii de operatori pe relaii i anume:
- algebra relaionala;
- calculul relaional.
A
1
:D
1
A
n
:D
m

57
La rndul sau, calculul relaional este de dou tipuri:
- calcul relaional orientat pe tuplu;
calcul relaional orientat pe domeniu.
Ne limitm, n cele ce urmeaz, la elemente de algebr relaional.
Algebra relaional i extensiile sale
E. F. Codd a introdus algebra rela ionala (AR) cu operaii pe relaii, fiecare operaie
avnd drept operanzi una sau mai multe relaii i
producnd ca rezultat o alt relaie.
Unele operaii ale AR pot fi definite prin intermediul altor operaii. n acest sens,
putem vorbi de:
- operaii de baz, precum: reuniunea, diferena, produsul cartezian etc.
- operaii derivate, ca: intersecia, diviziunea etc.
Codd a introdus aa numita AR standard, constituit din 6 operaii de baz: reuniunea,
diferena, produsul cartezian, proi ecia, selecia i jonciunea precum i din dou operaii
derivate: intersecia i diviziunea.
Ulterior, la operaiile AR standard au fost adugate i alte operaii, aa
numitele operaii "adiionale" sau extensii ale AR standard, precum:comple-
mentara unei relaii, splitarea (spargerea) unei relaii, nchiderea tranzitiv etc.
n continuare vor fi prezentate principalele operaii ale AR, precum i modul lor de
utilizare.
1. Reuniunea. Reprezint o operaie a AR definita pe doua relaii: R1 i R2 a mbele cu
o aceeai schem, operaie care const din construirea unei noi relaii R3, cu schema identic
cu R1 i R2 i avnd drept extensie tuplurile din R1 i R2 luate impreun o singur dat.
Notaia uzual pentru reuniune este: R1 U R2
Reprezentarea grafic a reuniunii este prezentata in fig. 3.3.

Exemple

Reuniunea relatiilor ORASE i MUNICIPII

Diferena. Reprezint operaie din AR definit pe doua relaii: R1 i R2, ambele cu o
aceeai schem, operaia constnd din construirea unei noi relaii R3, cu schema identic cu a
operanzilor i cu extensia format din acele tupluri ale relaiei R1 care nu se regsesc i n
relaia R2.
Notaia uzual pentru operaia de diferen a doua relaii este: R1-R2
58

Exemple

Diferena relaiilor ORAE i MUNICIPII

3. Produs cartezian. Reprezint o operaie a AR definit pe dou relaii: R1 i R2,
operaie care const din construirea unei noi rel aii R3, a crei schem se obine prin
concatenarea schemelor relaiilor R1 i R2 i a crei extensie cuprinde toate combinaiile
tuplurilor din R1 cu cele din R2.
Notaia uzual pentru desemnarea operaiei este: R1xR2

Exemple

Produsul cartezian al relaiilor ORAE i TARIFE

ORA:D
1
JUDE: D
1
TRANSPORT:D
3
TARIF:D
4
Braov Braov tramvai 30
Trgovite Dmbovia tramvai 30
Braov Braov autobuz 50
Trgovite Dmbovia autobuz 50
Braov Braov troleibuz 50
Trgovite Dmbovia troleibuz 50
ORA:D
1
JUDE:D
1
Braov Braov
Trgovite Dmbovia
ANSP:D
3
TARIF:D
3
tramvai 30
autobuz 50
troleibuz 50
TRANSPORT
X
TARIFE
ORAE:
59

4. Proiecia. Reprezint o operaie din AR definit asupra unei relaii R, operaie care const
din construirea unei noi relaii P, n care se regsesc unele atribute din R, nseamn efectuarea
unor tieturi verticale asupra lui R, care pot avea ca efect apariia unor tupluri duplicate ce se
cer a fi eliminate.
Prin operaia de proiecie se trece de la o relaie de grad n la o relaie de grad
p, mai mic dect cel iniial (p < n) ceea ce explic i numele de proiecie atribuit operaiei.
Notaia uzual pentru operaia de proiecie este:
Ai,Aj,,Am
(R)

Exemple

Proiectia relaiei ORAE pe atributul "Jude"

5. Selecia. Roprezint o operaie din AR definit asupra unei relaii R,
operaie care const din construierea unei relaii S, a crei schem este identic
cu cea a relaiei R i a crei extensie este constituit din acele tupluri din R care satisfac o
condiie menionat explicit n cadrul operaiei. ntruct cel mai adesea, nu toate tuplurile din
R satisfac, aceast condiie, selecia nseamn efectuarea unor tieturi orizontal e asupra
relaiei R, adic eliminarea de tupluri. Condiia precizat n cadrul operaiei de selecie este n
general de forma:

unde: "operator de comparaie" poate fi: <, <=, >=, > sau <>.
Notaia folosit in mod uzual pentru desemnarea operaiei de selecie este urmtoarea:
(conditie)
R

60

Exemple

Selecie efectuata asupra relaiei ORAE

6. Jonciunea (Joinul). Reprezint o operaie din AR definit pe dou relaii: R1 i
R2, operaie care const din construirea unei noi relaii R3, prin concatenarea unor
tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 i R2 care satisfac o
anumita condiie, specificat explicit n cadrul operaiei. Extensia relaiei R3 va contine deci
combinaiile acelor tupluri care satisfac condiia de concatenare.
Notaiiile uzuale pentru desemnarea operaiei de jonciune sunt:

Reprezentarea grafica a operaiei de jonciune
In general, condiia de concatenare menionata in cadrul operaiei de jonciune este de
forma:

In funcie de operatorul do comparaie din cadrul condiiei de concatenare, joinul
poate fi de mai multe tipuri. Cel mai important tip de join, n sensul celei mai frecvente
utilizri este equijoinul.

Equijoinul reprezinta jonciunea dirijat de o condiie de forma:

Operatia de jonciune se poate exprima cu ajutorul operaiilor de produs cartezian i
selecie, rezultatul unui join fiind acelai cu rezultatul unei selecii operate asupra unui produs
cartezian, adic:
61
JOIN (R1,R2, condiie) = RESTRICT(PRODUCT(R1,R2), condiie)
Produsul cartezian reprezint o operaie laborioas i foarte costisitoare, ceea ce face
ca in locul produsului s fie utilizat joinul ori de cte ori acest lucru este posibil. Cu toate c
apare drept o operaie derivat, joinul este prezentat de obicei drept o operaie de baz din
AR, dat fiind importana sa in cadrul sistemelor relaionale, n special la construirea relaiilor
virtuale.
In cadrul fig.3.9. este ilustrat operaia de equijoin.
Au fost definite numeroase variante ale operaiei de jonciune, variante care dife r nu
numai n funcie de tipul condiiilor de concatenare, ci i dup modul de definire a schemei i
respectiv, extensiei relaiei rezultate prin jonciune.

Exemple

Operaia de equijoin a relaiilor ORAE i ESTIMARI

Jonciunea natural. In cazul equijoinului, schema relaiei conine toate atributele celor
doi operanzi (fig.3.10.) n toate tuplurile relaiei rezultat vor exista de aceea cel puin dou
valori egale. In sensul eliminrii acestei redundane s-a introdus jonciunea natural, ca
operaie definit pe dou relaii: R1 i R2, prin care este construit o noua relaie R3, a crei
schem este obinut prin reuniunea atributelor din relaiile R1 i R2 (atributele cu acelai
nume se iau o singur dat) i a crei extensie conine tuplurile obinute prin concatenarea
tuplurilor din R1 cu tuplurile din R2 care prezint aceleai valori pentru atributele cu acelai
nume.

Notaia uzual pentru jonciunea natural este:
Reprezentarea grafic a acestei operaii este prezentat n fig. 3.10.

Reprezentarea grafic a operaiei de jonciune

62

Exemple

7. Intersecia. Reprezint o operaie a AR definit pe dou relaii: R1 i R2 ambele cu aceeai
schem, operaie care const din construirea unei noi relaii R3, cu schema identic cu a
operanzilor i cu extensia format din tuplurile comune lui R1 i R2.
Notaile uzuale folosite pentru desemnarea operaiei de intersecie sunt:

Reprezentarea grafic a operaiei de intersecie este prezantat n fig. 3.12., iar
un exemplu de intersecie a doua relaii figureaz n fig. 3.13.

Reprezentarea grafica a operatiei de intersectie

63

Exemple

Intersecia relatiilor ORAE i MUNICIPII

Intersecia reprezint o operaie derivat, care poate fi exprimat prin intermediul unor
operaii de baz. De exemplu, operaia de intersecie se poate exprima prin intermediul
operaiei de diferen, cu ajutorul urmtoarelor echivalene:
R1 R2=R1-(R1-R2)
R1 R2=R2-(R2-R1)

M3.U3.1. Rezumat
Reuniunea reprezint o operaie a AR definita pe doua relaii: R1 i R2 ambele
cu o aceeai schem, operaie care const din construirea unei noi relaii R3, cu
schema identic cu R1 i R2 i avnd drept extensie tuplurile din R1 i R2 luate
impreun o singur dat.
Diferena reprezint operaie din AR definit pe doua relaii: R1 i R2, ambele
cu o aceeai schem, operaia constnd din construirea unei noi relaii R3, cu
schema identic cu a operanzilor i cu extensia format din acele tupluri ale
relaiei R1 care nu se regsesc i n relaia R2.
Produs cartezian reprezint o operaie a AR definit pe dou relaii: R1 i R2,
operaie care const din construirea unei noi relaii R3, a crei schem se obine
prin concatenarea schemelor relaiilor R1 i R2 i a crei extensie cuprinde toate
combinaiile tuplurilor din R1 cu cele din R2.
Proiecia reprezint o operaie din AR definit asupra unei relaii R, operaie
care const din construirea unei noi relaii P, n care se regsesc unele atribute
din R, nseamn efectuarea unor tieturi verticale asupra lui R, care pot avea ca
efect apariia unor tupluri duplicate ce se cer a fi eliminate.
Prin operaia de proiecie se trece de la o relaie de grad n la o relaie de grad
p, mai mic dect cel iniial (p < n) ceea ce explic i numele de proiecie atribuit
operaiei.
Selecia reprezint o operaie din AR definit asupra unei relaii R,
operaie care const din construierea unei relaii S, a crei schem este identic
64
cu cea a relaiei R i a crei extensie este constituit din acele tupluri din R care
satisfac o condiie menionat explicit n cadrul operaiei. ntruct cel mai
adesea, nu toate tuplurile din R satisfac, aceast condiie, selecia nseamn
efectuarea unor tieturi orizontale asupra relaiei R, adic eliminarea de tupluri.
Jonciunea (Joinul) reprezint o operaie din AR definit pe dou relaii: R1 i
R2, operaie care const din construirea unei noi relaii R3, prin
concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele
tupluri din R1 i R2 care satisfac o anumita condiie, specificat explicit n
cadrul operaiei. Extensia relaiei R3 va contine deci combinaiile acelor tupluri
care satisfac condiia de concatenare.
Jonciunea natural. In cazul equijoinului, schema relaiei conine toate
atributele celor doi operanzi n toate tuplurile relaiei rezultat vor exista de aceea
cel puin dou valori egale. In sensul eliminrii acestei redundane s-a introdus
jonciunea natural, ca operaie definit pe dou relaii: R1 i R2, prin care este
construit o noua relaie R3, a crei schem este obinut prin reuniunea
atributelor din relaiile R1 i R2 (atributele cu acelai nume se iau o singur dat)
i a crei extensie conine tuplurile obinute prin concatenarea tuplurilor din R1
cu tuplurile din R2 care prezint aceleai valori pentru atributele cu acelai
nume.

3.1.1 Cosiderai instane ale tabelei student, profesor,materii i catalog.
a) Facei selecie din student dup grupa
b) Facei proiecie la student i la profesor dup nume. La acestea dou din
urm facei reuniunea.
c) Faceti jonciunea natural intre student i catalog apoi ntre rezultat i
materii.
d) Facei selecia tabelei de mai nainte dup nota < 5.
3.1.2 S se exprime n algebra relaional cererile:
a) Studenii grupei 7271
b) Studenii care sunt i profesori
c) Studenii corigeni
d) Studenii integraliti

65
Unitatea de nvare 3.2 SQL

SQL (Structured Query Language), a fost conceput iniial de firma IBM,
pentru produsul dBASE, ca un limbaj standard de descriere a datelor i de
acces la informtiile din bazele de date. Limbaj de interogare a bazelor de
date relaionale, SQL a fost utilizat pe scar larg i pan n prezent au fost
dezvoltate apte versiuni ale standardului SQL, trei dintre ele aparinnd
Institutului National American de Standarde (ANSI), celelalte fiind
concepute de firme de prestigiu ca IBM, Microsoft i Borland sau de ctre
consorii ca SAG (The SQL Access Group) i X/Open.
Primul standard SQL a fost creat in anul 1989 de ctre ANSI fiind cunoscut
sub numele de ANSI-SQL'89 i a fost revizuit in octombrie 1992 sub noua
denumire: ANSI-SQL'92.

Exprime cereri n SQL
exprime actualizri ale bazei de date


Cereri de interogare simple
Instructiunile de regsire reprezint una din categoriile cele mei importante ale
limbajului de interogare SQL. Indiferent dac sunt simple sau complexe, punctul de plecare al
interogrilor l constituie fraza SELECT, prin care se r egsesc i se afieaza informaiile
dorite de utilizator.
Pentru definirea interogrilor de selecie simple se utilizeaz urmtoarea sintax a
instruciunii SELECT:
SELECT [domeniu] lista_selecie
FROM nume_tabela1,nume_tabela2
[WHERE criteriu_de_selecie}
ORDER BY cmpuri_criteriu [ASC/DESC]];
Domeniu:
- Determin stabilirea modalitii de manipulare a nregistrrilor din baza de date asupra
creia se efectueaz selecia i poate fi:
ALL - permite includerea tuturor inregistrrilor ce indeplinesc condiiile impuse. Este
folosit foarte rar deoarece este implicit.
DISTINCT - are ce efect eliminarea nregistrrilor care conin duplicate n cmpurile
selectate; astfel se va afia doar o apariie a datei multi ple ( ceea ce este n concordan cu
algebra relaional).
DISTINCTROW - are n vedere nregistrrile duplicate n ansamblul lor, nu numai pe cele
care au cmpuri duplicate.
66

Lista_selecie
Cuprinde toate cmpurile care vor aparea n tabela cu rezulta tele interogrii.
Atenie! }n list[ vor ap[rea numai aatribute ale tabelelor din clauya FROM.
Clauzele SQL SELECT, FROM i WRERE pot fi puse n coresponden cu operatorii din
algebra relaional, dup cum urmeaz:
Clauza SELECT menioneaz o list de atribute i corespunde proieciei din algebra
relaional;
Clauza FROM menioneaz o list de relaii (tabele) i corespunde produsului cartezian din
algebra relaional;
Clauza WRERE descrie un predicat de selecie i corespunde seleciei din algebra relai onal.
nelesul diferit al termenului select utilizat n SQL i n algebra relaional este un fapt
istoric nefericit. n SQL, select desemneaz proiecia, iar n algebra relaional acelai
termen desemneaz selecia dup un predicat de selec ie.
Lista de atribuire care apare n clauza SELECT din SQL poate fi nlocuit cu simbolul *
dac se dorete selectarea tuturor atributelor care apar n relaiile din clauza FROM.

Clauza ORDER BY
Utilizat atunci cnd se dorete ca rezultatele int erogrii s fie ordonate n mod
cresctor (ASC) sau descresctor (DESC). Sortarea este opional i se poate realiza dupa
unul sau mai multe cmpuri_criteriu (definite drept chei de sortare). Componenta BY a
clauzei nu poate s lipseasc atunci cnd se dorete sotrarea rezultatelor interogrii SQL.

Rezultatul unei interogri SQL este ntotdeauna o relaie (o tabel).

Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de nchiriere casete
video. Avem urmtoarele tabele:
Clienti (Cod_client , Nume, Prenume, Strada, Nr, Bloc, Scara, Apartament, Oras, Seria_BI,
Nr_BI, Data_ nasterii, Telefon)
Casete (Cod_caseta,Pret, Disponibila)
Filme ( Cod_film, Titlu, An_aparitie, Tara. Gen)
Casete-Filme (Cod_casetafilm, Cod_caseta, Cod_film)
Actori (Cod_actor,Nume, Sex)
Filme_Actori (Cod_filmactor, Cod_film, Cod_actor)
Imprumuturi (Cod_imprumut, Cod_client, Data_imprumut, Stare)
Plati (Cod_plata, Cod_imprumut, Data , Suma)
Casete imprumutate (Cod_imprcaseta, Cod_imprumut, Cod_caseta, Restituita)

Exemple
S se afieze toate datele despre toi clienii.
SELECT *
FROM Clieni

.S se afieze toate datele despre toi actorii.

Exemple
S se afieze oraele de reedin ale tuturor clienilor
SELECT Ora
FROM Clieni
67

S se afieze toate genurile filmelor. Ce putei spune despre numrul genurilor
fa de numrul genurilor.
Ca rezultat al acestei interogri se va obine o tabel cu o singur coloan, care conine
numele oraelor de reedin ale clienilor. Se va observa c se repet numele oraelor,
deoarece se vor afia oraele pentru fiecare client n parte din tabela clieni.

Exemple
S se afieze oraele de reedin ale clienilor, dar s apar fiecare ora o singur
dat n tabela-rezultat.
SELECT DISTINCT Ora
FROM Clienti

S se afieze toate genurile distincte ale filmelor.

Exemple
S se afieze datele despre filmele din baza de date n ordinea alfabetic a
titlurilor filmelor
SELECT *
FROM Filme
ORDER BY Titlu,ASC

Afiai, ca mai sus, dar n ordine descendent.
S se afieze datele despre filmele din baza de date n ordinea alfabetic a titlurilor filmelor

SELECT *
FROM Filme
ORDER BY Titlu,ASC
A se observa c dac ar fi lipsit meniunea ASC, ordinea tuplelor ar fi fost
aceeai deoarece ordinea ascendent este implicit.
n scrierea interogrilor de selecie simple SQL se pot folosi i funcii totalizatoare,
cunoscute i sub numele de funcii standard sau func ii agregat, care apar n clauza SELECT
i se aplic atributelor din tabelele implicate n interogare. Funcii standard sunt:
valoarea medie AVG
valoarea minima MIN
valoarea maxima MAX
total (sumare) SUM
numaratoare COUNT
Nu este permis utilizarea acestor funcii n clauza WHERE deoarece ele acioneaz la nivel
de atribut i nu la nivel tuplu.

Exemple
Care este suma minim pltit?
SELECT MIN (suma)
68
FROM plati

.Care este suma maxim pltit?

Exemple
Care este preul mediu al casetelor?
SELECT AVG(Pret)
FROM Casete

Care este suma medie ncasat.

Exemple
Care este suma total pltit pentru mprumutul cu cod 30?
SELECT SUM (suma)
FROM plati
WHWRE Cod_imprumut=30

Care este valoarea total a casetelor.

Exemple
Cate tulpe conine tabela de casete?
SELECT COUNT (*)
FROM Casete

Cte tupe conine tabela clienti.

Exemple
Cate genuri de filme sunt nregistrate pentru filmele din baza de date?
SELECT COUNT (DISTINCT Gen)
FROM Filme

Cereri de interogare complexe

Limbajul de interogare SQL permite, pe lng definirea de interogri de selecie simple,
crearea unor interogri cu o structura complex, cum ar fi cele n care regsim funciile
agregate, asocierile (JOIN) sau combinrile (UNION).

Funciile de grup(agregat)

69
Funciile de grup agregat permit construirea unor interogri SQL complexe, prin care
utilizatorul poate s efectueze diverse calcule pentru grupuri de nregistrri care au cmpuri cu
aceeasi valoare. n cazul utilizrii lor se folosete urmtoarea form a frazei SELECT:

SELECT [domeniu] [funcie agregat (nume_cmp) AS alias [,lista_selecie]
FROM nume_tabela1, nume_tabela2
GROUP BY cmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY cmpuri_criteriu [ASC/DESC]];

Dupa cum se observ, singurele elemente obligatorii ntr-o interogare SQL sunt clauzele
SELECT cu lista de atribute ce vor fi extrase i clauza FROM cu relaiile din care fac parte
atributele. Aadar o interogare SQL trebuie s conin cel puin urmtoarele informaii:

SELECT <lista de atribute>
FROM <lista de relatii>
restul clauzelor sunt opionale.

Lista selecie
Se va referi la una sau mai multe funcii agregate care au ca argumente nume de cmpuri ale
bazei de date. Exist restricia ca aceste cmpuri sa fie ntotdeauna de tip numeric.
AS alias
Asociaz un pseudonim (nume) rezultatului utilizrii funciei agregat

Clauza GROUP BY i HAVING
n unele cazuri, utilizatorul dorete anumite situatii sintetice, cum ar fi obinerea de totaluri i
subtotaluri. Pentru aceste operaii, limbaj ul SQL permite utilizarea clauzelor GROUP BY i
HAVING.
Aceste clauze organizeaz tuplele n grupuri asupra crora se pot realiza anumite
operaii, n special prin aplicarea funciilor agregat.
Clauza GROUP BY grupeaza tuplele din relaie dup atributele cu aceeai valoare
care sunt specificate n clauz, i genereaz un tuplu pentru fiecare grup de tuple cu aceeai
valoare pe atribut
Atributele care apar n clauza SELECT pot fi de dou feluri:
-atribute care alctuiesc baza pentru grupare (cele care apar n clauza GROUP BY);
-atribute care nu participa la gruparea rezultatelor.

Exemple
n ce orase exista clienti ai centrului de nchiriere casete video?
SELECT Oras
FROM Clienti
GROUP BY Oras
n urma executarii vor aparea orasele din tabela clientilor listate o singur dat.

Din cte ri avem filme.

Exemple
Ci clieni au sediul n fiecare oras?
SELECT Oras,COUNT(*)
70
FROM Client
GROUP BY Oras

Cte filme sunt din fieare ar.

Exemple
n care case locuiesc cel puin 3 clieni?
SELECT Oras,COUNT(*)
FROM Clienti
GROUP BY Oras
HAVING COUNT(*)>=3
Clauza GROUP BY se poate folosi i cu ORDER BY i WHERE.

Din ce ri avem cel puin 2 filme.

Exemple
S se afieze n ordine alfabetic oraele n care exist clieni ai centrului.
SELECT Oras
FROM Clienti
GROUP BY Oras
ORDER BY Oras

S se afieze n ordine alfabetic rile din care avem filme.

Exemple
Care sunt clienii care au mprumutat casete nainte de data de 6/5/2004?
SELECT Cod_client
FROM Imprumuturi
WHERE Data_imprumut<#6/5/2002#
GROUP BY Cod_client

Care sunt mprumuturile fcute dup data 01/01/2009 .

Clauza FROM are forma general:
FROM <<nume relatie>/<nume view>[alias]>
i specific relaiile (pot fi i nume view) din care vor fi regsite datele. n cazul n care se
opereaz cu mai multe tabele, este util atribuirea unor prescurtri, (numite alias) ale numelor
de tabele ce vor fi utilizate n interogare.

Exemple
S se afieze codurile casetelor, numele clienilor, codul mprumutului i data
mprumutului pentru clienii care au cel puin un mprumut.
71
SELECTC Cod_caseta, [Nume] && [Prenume] AS Numele,
Cod_imprumut, B.Data_imprumut
FROM Clienti A, Imprumuturi B, [casete imprumutate] C
WHERE A.Cod_client=B.Cod_client AND B.Cod_imprumut=C. Cod_imprumut
A se observa c nu s-a mai utilizat notaia cu alias pentru atributele Nume i
Prenume din tabela Clienti deoarece nu este pericol de confuzie. n schimb s-a
utilizat notaia pentru a deosebi atributul Cod_client din tabela Clienti de
atributul cu acelai nume din tabela Imprumuturi.

S se afieze actorii care joac cel puin ntr-un film.
Pentru a restrnge tuplele ce apar n tabela-rezultat, se specific o condiie de cautare prin
utilizarea unui predicat de selecie n clauza WHERE.
Clauza WHERE are forma generala:

WHERE <predicat> / <expresie>;
Numai tuplele care satisfac predicatul de selecie vor fi incluse n tabela-rezultat. Predicatul
de cautare poate fi specificat printr-o condiie logica n care se utilizeaza urmatoarele
elemente:
Operatori:
-aritmetici:+ - / * ** ^
-relaionali: < > <= >= <> != =
-logici:NOT AND OR
-operatori SQL:IN,EXISTS,ALL,ANY
Sub-interogri(exprimate prin interogri SQL)cu observatia ca acestea vor
fi primele evaluate i tabela-rezultat trebuie sa corespunda operatorilor ce i se aplica n
continuare.

Operatori aritmetici

Ace;ti operatori sunt binecunoscui i menionm aici doar faptul ca i ^ si ** reprezint[
ridicarea la putere.
Ca operanzi, se pot utiliza atribute,constante,funcii sau expresii algebrice. Expresiile
algebrice pot aparea n clauzele SELECT sau WHERE.
Operatori relaionali
< mai mic
> mai mare
! negarea operatorilor <,>,=. Se obin operatorii: != (diferit),!< (nu mai mic),!> (nu mai
mare).
<= mai mic sau egal
=> mai mare sau egal
<> diferit
Facem observaia c valorile comparate trebuie s aparin unor tipuri de date compatbile
(care se pot compara ntre ele.).

Exemple
Sa se afieze codurile i titlurile filmelor de gen aciune.
SELECT Cod_film<Titlu
FROM Filme
WHERE Gen=actiune
72

S se afieze filmele din Romania.

Operatori logici

Dac o clauza WHERE conine mai multe condiii formate prin utilizarea aceluiai tip de
operator logic, evaluarea se va face de la stnga la dreapta. Tipul de operator logic este dat de
precedena operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de OR i AND
care practic sunt de prioriti egale. Pentru a schimba ordinea de evaluare a unei expresii se
utilizeaz parantezele rotunde ().

Exemple
Sa se afieze codul i titlul filmelor din SUA care au anul apariiei mai mare
dect 2000.
SELECT Cod_film,Titlu
FROM Filme
WHERE Tara=SUAAND An_aparitie>2000

S se afieze plile mai mari de 100 lei fcut n anul 2009.

Exemple
Sa se afieze codul i titlul filmelor din SUA sau care au anul apariiei mai mare
dect 2000.
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=SUAOR An_aparitie>2000
A se observa c ultima interogare este echivalent cu interogarea :
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=SUAOR NOT An_aparitie<=2000

Operatorul IN permite simplificarea predicatului de cutare. Predicatul IN testeaz dac
valoarea unui atribut specficat n lista de atribute din clauza WHERE se potrivete uneia din
valorile listei specificate n predicatul IN (testeaza apartenena la o mulime).

Exemple
S se afieze toate datele despre clienii care au sediul n Rnov sau n
Braov.
SELECT *
FROM Clienti
WHERE Oras IN (Rasnov,Brasov)

73

S se afieze, n dou moduri, toate datele despre clienii care au sediul n
Rnov sau n Braov sau n B ucuresti.

Asocierile (interogrile JOIN)
Una dintre operaiile cele mai frecvente realizate cu mai multe tabele este jonciunea
sau produsul cartezian. Jonciunea amintete de operaiile din algebra relaional i chiar e ste
posibil de realizat (urmnd anumite structuri ale interogrii SQL) oricare dintre tipurile de
jonciune prezentate teoretic n cadrul algebrei relaionale. Se pot de asemenea realiza operaii
ca reuniunea, intersectia i diferena. Sintaxa interogrii SQL difer de la un SGBD la altul
dar sub o form direct sau printr -o construcie sintactic specific se pot realiza oricare dintre
operaiile amintite.
Putem distinge mai multe categorii de jonciuni:CROSS (ncruciat) - mai
puin utilizat, cu rol n ilustrarea elementelor specifce proprietilor combinatorii ale tuturor
asocierilor; ECHIVALENT (echijonciunea)-cea mai folosit, presupune folosirea clauzei
WHERE (pentru selecia nregistrrilor) asociat cu o egalitate dorit; NEECHIVALENTA
(non echijonciune) - care, spre deosebire de precedenta, face apel n clauza WHERE la
oricare operator de comparare n afar de semnul (=). Acest din urm tip de jonciune este
n general foarte rar de utilizat.
Sintaxa general pentru jonciunile echivalente i neechivalente este urmtoarea:

FROM nume_tabela1,nume_tabela 2
WHERE criteriul_de_asociere]
[ORDER BY cmpuri_criteriu[ASC?DESC];

Deoarece n instruciunile SQL care descriu jonciunea se utilizeaza cmpuri ce fac
parte din tabele diferite, este necesara ntotdeauna spacificarea tabelei la care apartin. Forma
generala de descriere a unui cmp va fi urmatoarea:nume_tabela.nume_cmp. Se pot folosi i
alias-uri.

Exemple
Sa se afieze numele clientilor i codurile imprumuturilor pentru
imprumuturile neterminate.
SELECT[Nume]&&[Prenume] AS Numele,b.Cod_imprumut
FROM Clienti 1,Imprumuturi b
WHERE 1.Cod_client=b.Cod_client AND Stare=Yes

Sa se afieze filmele i casetele pe care se gsesc.

Exemple
Care filme au acelasi gen cu filmul Titanic? A se observa c aceast interogare
necesit realizarea produsului cartezian al tabelei cu ea nsi.
SELECT p1.Titlu,p2.Titlu,p1.Gen.p2.Gen
FROM Filme p1,Filme p2
WHERE p1.Gen=p2.Gen AND p2.Titlu=Titanic

74

O alt abordare privete jonciunile ca fiind: interne (INNER JOIN) i externe
(OUTER JOIN). Primele determin o asociere a nregistrrilor din tabele, astfel ncat sa
rezulte un numar total de nregistrri din fiecare tabela. Jonciunile externe, la randul lor, sunt
de doua tipuri: de stanga (LEFT OUTER JOIN) i de dreapta (RIGHT OUTER JOIN) fiind
destul de puin utilizate.
n acest mod de abordare al jonciunulor sintaxa va avea forma:

FROM num_tabela1
JOIN nume_tabela2
ON criteriu_de_asociere
[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3
ON criteriu_de_asociere]
[WHERE criteriu_de_selecie]
[ORDER BY cmpuri_criteriu {ASC/DESC]]:

De remarcat faptul ca SQL accept scrierea interogrilor externe fr specificarea
explicit a lui OUTER.

JOIN specific tabela care va fi asociat (nume_tabela2,nume_tabela3) tabelei preciat n
clauza FROM ON criteriu_de_asociere arat relaia dintre cmpurile pe care se bazeaz
jonciunea. Unul se afl n tabela asociat, iar cellalt exist ntr -o alt tabel din lista cu
numele tabelelor. Expresia criteriul_de asociere conine un operator de comparaie de tip
egalitate (=) i va returna valorile logice TRUE sau FALSE

Exemple
Sa se afieze codul casetelor, preul i filmele de pe casete, pentru casetele care
sunt disponibile.
SELECT Casete.Cod_caseta,Filme.Titlu,Casete.Pret
FROM Filme INNER JOIN (Casete INNER JOIN [Casete-Filme] ON
Casete.Cod_caseta=[Casete-Filme].Cod_caseta)ON Filme.Cod_film=[Casete-
Fiml].Cod_film
WHERE (((Casete.disponibile)=Yes));

Sa se afieze filmele i casetele pe care se gsesc. Procedai ca mai sus.

Combinrile (interogrile UNION)
Clauza UNION permite realizarea reuniunii de tabele. n cazul cnd dorim s reunim
dou sau mai multe tabele, este obligatoriu ca acestea s fie daschise de scheme de relatie
identic (acelai numr de atribute i corespunzator de la stanga la dreapta atributele din
tabele au aceleasi nume i aceeai descriere). Aceste condiii sunt impuse tabelelor implicate
n operaiile intersecie i minus (diferen). Operaiile reuniune, intersecie i diferen de
tabele acioneaz analog cu aceleai operaii aplicate n mulimi.
Forma general a reuniunii de tabele este:

75
SELECT A1,,Am
FROM
[WHERE]
UNION
SELECT A1,,Am
FROM
[WHERE]

Exemple
S se afieze numele clienilor care sunt fie din Rnov fie din Braov i adresa
lor.
SELECT [Nume]&&[Prenume]AS Nume,Clienti.Strada,Clienti.Nr,
Clienti.Bloc,Clienti.Scara,Clienti.Apartament,Clienti.Oras,Clienti.Telefon
FROM Clienti
WHERE Oras=Rasnov
UNION (SELECT [Nume] &&[Prenume] AS Numele, Clienti.
Strada,Clienti.Apartament, Clienti.Oras,Clienti.Telefon
FROM Clienti
WHERE Oras=Brasov);

Cereri de interogare imbricate (subinterogri)
Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare
este acela c ofer posibilitatea construirii interogrilor complexe, formate din mai multe
subinterogri simple.
Aceste interogri complexe sunt construite prin incl uderea n clauza WHERE a nc
unei clauze SELECT. Forma general a unei astfel de construcii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
Se observ c aceast construcie a fost deja utilizat n exemplul de mai sus car e
ilustreaz o clauz UNiON.
n construcia de mai sus clauza SELECT interioar genereaz valorile pentru condiia de
cutare a clauzei SELECT exterioare care o conine. Clauza SELECT exterioar genereaz o
relaie pa baza valorilor generate de ctre clauza interioar. Modul de construire a interogrii
exterioare depinde de numrul valorilor returnate de ctre interogarea interioar. n acest sens,
putem distinge:
subinterogri care returneaz o singur valoare;
subinterogri care returneaz mai multe valori.
Din punctul de vedere al ordinii de evaluare al interogrilor putem distinge:
Subinterogri simple
Interogarea interioara este evaluata prima, independent de interogarea exterioara.
Rezultatul evaluarii interogrii interioare este utilizat de catre nter ogarea
exterioara.
Subinterogri corelate
Valorile returnate de catre interogarea interioar depind de valorile returnate de catre
interogarea exterioar. Interogarea interioar este evaluat reletat pentru fiecare tuplu cercetat
de interogarea exterioara.
76
Subinterogri simple care returneaza o singura valoare
Aceste interogri au urmatoarea sintax:
SELECT <lista atribute>
FROM <lista relatii>
WHERE <atribut> 0 (<subinterogare>)
unde 0 este un operator relaional: =,< > >= <= !=

Exemple
Sa se afieze numarul mprumuturilor nencheiate pentru clienta Ciurar Cristina.
SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]
FROM Imprumuturi
WHERE (((Imprumuturi.Cod_client)=SELECT Clienti.Cod_client
FROM Clienti
WHERE [Nume] & &
[Prenume]=Ciurar Cristina)));

Sa se afieze casetelew care au filme din USA.
Procesul de evaluare a acestei interogri se desfasoar astfel:
Se evalueaza n primul rnd interogarea interioar. Condiia de evaluare a interogrii
interioare este [Nume] & & [Prenume]=Ciurar Cristina.
Valoarea obinut pentru atributul Cod_client este stocata ntr-o tebel temporar.
Rezultatul evalurii interogrii interioare devine condiie de cutare pentru interogarea
exterioar, care ar putea fi exprimat n aceast faz ca:
SELECT Count(Cod_imprumut) AS [Nr de imprumuturi]
FROM Imprumuturi
WHERE (Imprumuturi.Cod_client)=6
n urma executrii interogrii exterioare este creat o relaie final, ce va contine
tuplele ale cror Cod_client este acelai cu valoarea stocat n tabela temporar.
Interogarea interioar poate conine n clauza WHERE i condiii complexe, formate
prin utilizarea operatorilor logici (NOT,AND, OR) i a funciilor agregat (AVG,MAX,).

Exemple
Sa se afieze codul casetelor, pretul i titlurile filmelor, pentru casetele care au un
pret maxim.
SELECT Casete.Cod_caseta,Casete.Pret,Filme.Titlu
FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON
Casete.Cod_caseta=[Casete-Filme].Cod_caseta) ON
Filme.Cod_film=[Casete-ilme].Cod_film
WHERE Pret=(SELECT MAX(Pret) FROM Casete);

S se afieze filmele din casetele, cu pre minim, mprumutate i nerestiruite.

Suinterogri simple care returneaz mai multe valori.
Principiul de construire a acestui tip de interogare imbricate utilizeaz n clauza
WHERE condiii, care evaluate, genereaz o mulime de valori. n aceast categorie intr
operatorii (NOT) IN, (NOT) ANY,(NOT) AND,(NOT) EXISTS.

77

Exemple
Care sunt clienii care mai au de restituit casete.
SELECT [Nume]&&[Prenume]AS Numele
FROM Clienti
WHERE Cod_client IN
(SELECT Cod_client
FROM Imprumuturi INNER JOIN [casete imprumutate]
ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut
WHERE restituit=NO);

Care sunt actorii care joac n casetele mprumutate.

Exemple
Care clieni nu mai au nimic de restituit.
SELECT [Nume]&&[Prenume]AS Numele
FROM Clienti
WHERE Cod_client NOT IN
(SELECT Cod_client
FROM Imprumuturi INNER JOIN [casete imprumutate]
ON Imprumuturi.Cod_imprumut =[ casete imprumutate] cod_imprumut
WHERE restituit=NO);

A se observa ce cele dou interogri difer doar prin operatorul logic NOT. De
asemenea se poate remarca faptul c prima interogare amintete de apartenena din teoria
mulimilor iar a doua interogare corespunde operaiei minus (diferena). Dac versiunea SQL
nu are un cuvnt rezervat pentru operaia diferena inter tabele, se poate construi aceasta
operaie cu ajutorul predicatului NOT IN ca n exemplul de mai sus.
Subinterogri corelate
n exemplele de pn acum, interogarea interioar era evaluat prima, dup care
valoarea, sau valorile, rezultate erau utilizate de ctre clauza WHERE din interogarea
exterioar.
Exista i o alt forma de subinterogare i anume Subinterogarea corelat, caz n care
interogarea exterioar transmite repetat cte o valoare pentru interogarea interioar.
De fiecare dat cnd este transmis o valoare, este evaluat interogarea interioar.
Dac ambele interogri acceseaza acelai table, trebuie asigurate alias-uri pentru fiecare
referina la tabelul respectiv. Ambele interogri acceseaz tuple diferite din acelai table n
acelai moment.

Exemple
Sa se afieze codurile imprumuturilor, data imprumutului, data unei plai i suma
pltit, pentru sumele maxime care s-au pltit, ordonate dup data mprumutului.

SELECT Imprumuturi.Cod_imprumut, Imprumuturi.Data_ imprumut,
plati.data,plati.suma
FROM Imprumuturi INNER JOIN plati ON Imprumuturi.Cod
78
_imprumut=plati.cod_imprumut
WHERE suma=
(SELECT MAX(suma)
FROM plati
WHERE Imprumuturi.Cod_ Imprumut=plati.cod_ Imprumut) ORDER BY
Imprumuturi..Data_ Imprumut;

Restricionare subinterogrilor
Operatorii ANY i ALL
Operatorul ANY poate fi utilizat n cobinaie cu oricare dintre operatorii relaionali (=
< > <= >= !=) pentru a se varifica dac valorile unui atribut este egal, mai mic, mai mare,
etc. dect oricare dintre valorile menionate o dat cu operatorul. Urmatoarele predicate sunt
echivalente:
=ANY si IN
!=ANY si NOT IN
Operatorul ALL returneaz tuplele pentru care valorile atributului din clauza WHERE
sunt mai mici, mai mari, mai mici sau egale, ect. dect toate valorile generate de interogarea
interioar. S facem observaia c acest operator nu poate fi utilizat cu operatorul relaional =,
ceea ce ar corespunde cazului banal n care toate valorile din list sunt identice.
Pentru a stabili mai exact modul n care se selecteaz valorile cu operatorii ANY i ALL dm
mai jos o serie de cazuri concrete.
S presupunem ca interogarea este de forma:

SELECT
FROM
WHERE x <ALL (1,2,3,4)

S observm c dac nlocuim operatorul ALL cu expresia verbal toate putem citi
Valorile lui x trebuie s fie mai mici dect toate valorile din paranteza ce urmeaza dup
ALL.
Atunci vom lua n considerare urmatoarele situaii:

Expresia din clauza WHERE Valori ale lui x care corespund
X<ALL 0,-1,-2,
X<=ALL 1,0,-1,-2,
X>ALL 5,6,7,
X>=ALL 4,5,6,

Daca vom studia o interogare de forma:

SELECT
FROM
WHERE x <ANY (1,2,3,4)

S observm c dac nlocuim operatorul ANY cu expresia verbal oricare putem citi
Valorile lui x trebuie s fie mai mici dect oricare dintre valorile din paranteza ce urmeaza
dupa ALL.
79
Vom lua n considerare urmtorul table:

Expresia din clauza WHERE Valori ale lui x care corespund
X<ANY 3,2,1,0,-1,-2,
X<=ANY 4,3,2,1,0,-1,-2,
X>ANY 2,3,4,5,6,7,
X>=ANY 1,2,3,4,5,6,

Exemple
Exemple:
S se afieze titlul filmelor, anul apari iei i genul, pentru filmele din SUA,
care au anul apariiei maxim.
SELECT Filme.Titlu,Filme.An_aparitie,Filme.Gen
FROM Filme
WHERE An_aparitie<ALL
(SELECT An_aparitie
FROM Filme
WHERE Tara=SUA);

Exemple
S se afieza codul casetelor, preul, titlurile filmelor pentru
Casetele disponibile, din care le excludem pe cele de pre maxim.

SELECT Casete.Cod_caseta,Casete.Pret,Casete.disponibil,Filme.titlu
FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON
Casete.Cod_caseta=[ Casete-Filme].Cod_caseta) ON Filme.Cod_film= [Casete-
Filme].Cod_film
WHERE disponibil=Yes AND Pret<ANY
(SELECT Pret
FROM Casete
WHERE disponibil=YES);

Operatorul EXISTS
Operatorul EXISTS verific dac pentru fiecare tupl u al relaiei exist tuple care
satisfac condiia interogrii interioare. n cazul n care exist asemenea tuple, EXISTS ia
valoarea de adevar TRUE. Astfel, operatorul EXISTS permite specificarea mai multor
attribute n interogarea interioar. Acest lucru este posibil deoarece nu se verific valoarea
unui atribut, ca n cazurile anterioare, ci se genereaz o valoare de adevar ( TRUE sau
FALSE), dup cum exist sau nu exist o anumit valoare ntr -o relaie diferit de cea
utilizat n interogarea exterioar. )
Ca i operatorii ANY i ALL, operatorul EXISTS apare n clauza WHERE.

Exemple
S se afieze titlui filmelor, anul aparitiei i genul pentru filmele care au un an de
apariie mai mare sau egal cu anul maxim de apariie al fi lmelor de gen fabula.
80

SELECT Titlu,An_aparitie,Gen
FROM Filme f
WHERE NOT EXISTS
(SELECT *
FROM Filme
WHERE Gen=fabula AND An_aparitie>f.An_aparitie);

Interogarea SELECT interioar definete o tabel care conine tuple pentru care se
verific condiia din clauza WHERE intern.

Actualizri ale bazei de date.
SQL poate fi folosit att pentru interogarea bazei de date ct i pentru actualizarea
bazelor de date. Comenzile pentru actualizri nu sunt att de complexe ca declaraia SELECT.
Declaraiile SQL aferente actualizrii unei baze de date se refer la modificrile unei tabele
(adugare sau tergere de linii, modificarea datelor dintr -o tabel):
Adugarea se face cu declaraia INSERT care are dou forme prima accepta
adugarea unei singure linii, iar a doua adugarea mai multor linii.
I. Adugarea unei singure linii
INSERT INTO nume_tabela [(lista_atribute)]
VALUES (lista_valorilor_datelor)
Nume_tabela reprezint numele unei tabele din baza de date sau o vedere actualizat a
acesteia, lista_atribute reprezint o list de una sau mai multe nume ale coloanelor tabelei
separate prin virgul. Dac aceast list nu este specificat SQL consider toate atributele
tabelei n ordinea n care au fost create n tabela original. n cazul n care sp ecificm aceast
list atributele pe care dorim s le omitem trebuie s le declarm ca NULL. Numrul de
elemente din cele dou liste trebuie s coincid, s aib aceai ordine de declarare i s fie
compatibile ca tip.

Exemple
Exemplu:
Inserai o nou nregistrare n tabela Conducere completnd datele pentru toate
atributele:
INSERT INTO Conducere
VALUES (cd16, Ionescu, Alex, George Enescu 37, ap.4, Bucuresti, 021 -
456-12456,director economic,m, date 01.07.1945)

Inserai o nou nregistrare n tabela casete.

Exemple

.
81
II. Adugarea mai multor linii prin copierea lor dintr -o tabel sau mai multe tabele ntr-o alt
tabel
SELECT
Nume_tabela i lista de atribute sunt definite la fel ca la cazul anterior, iar clauza SELECT
poate fi orice declaraie valid.

Exemple
Inserai o nou nregistrare n tabela Conducere completnd datele doar pentru
atributele obligatorii cod, Nume, Prenume, Functie
INSERT INTO Conducere
VALUES (cd44, Aduducai, Maria, NULL, NULL,asisent manager,NULL,
NULL)

Exemplu:

Exemple
Presupunnd c n tabela ContConducere conine numele celor din
conducere i numrul serviciilor pe care le au n subordine populai tabela
ContConducere folosind detalii din tabelele Conducere i PorpServicii o nou
nregistrare n tabela Conducere completnd datele pentru toate atributele:
INSERT INTO ContConducere
(SELECT s.id, nume, prenume, COUNT(*)
FORM Conducere s, PropServicii p
WHERE s.id=p.id
GROUP BY s.id, nume, prenume)
UNION
(SELECT id, nume, prenume, 0
FORM Conducere
WHERE id NOT IN
(SELECT DISTINCT id
FROM PropServicii))

Modificarea se face cu declaraia UPDATE care permite modificarea datelor unor
nregistrri existente ntr-o tabel dat. Sintaxa acestei comenzi este:
UPDATE nume_tabela
SET nume_atribut1=valoare1[,nume_atribut2=valoare2 .]
[WHERE conditie_cautare]
Clauza SET specific numele unui atribut sau a mai multor atribute care urmeaz a fi
modificate, WHERE este o clauz opional, prin omiterea ei se consider c toate c toate
nregistrrile for fi modificate pentru atributele alese la clauza SET, iar dac ea este
specificat atunci doar acele nregistrri care ndeplinesc condiiile de cutare. Tipul datelor
valoare1,. trebuie s fie compatibile cu cele ale atributelor corespunztoare.
82

Exemple
Modificarea tuturor nregistrrilor pentru mrirea salariior tuturor celor din
conducere cu 3%.
UPDATE CONDUCERE
SET salariu = salariu*1.03

Modificarea preului la casetele cu preul maxim prin reducere cu 10%.
2. Modificarea doar a unor nregistrri specificate
UPDATE CONDUCERE
SET salariu = salariu*1.05
WHERE functie=manager
Modificarea nregistrrilor pentru mai multe atribute
UPDATE CONDUCERE
SET functie=manager, salariu = 18.000.000
WHERE id=cd73
tergerea se face cu declaraia DELETE , sintaxa acestei comenzi este :
DELETE FROM nume_tabela
WHERE conditie_cautare
Dac opiunea WHERE lipsete atunci se terg toate nregistrrile darn nu i tabelul,
pentru a terge un tabel folosim declaraia DROP TABLE. Se poate terge un tabel numai
dac nu mai are nregistrri.

Exemple
1. tergerea tuturor nregistrrilor din tabela vedere (view)
DELETE FROM viewing;
2. tergerea anumitor nregistrri din tabela vedere (view)
DELETE FROM viewing;
WHERE id = cd72

tergerea tuturor nregistrrilor din tabela casete.
tergerea nregistrrilor din tabela casete cu pre minim.

83

M3.U3.2. Rezumat
Pentru definirea interogrilor de selecie simple se utilizeaz urmtoarea sintax
a instruciunii SELECT:
SELECT[domeniu]lista_selecie
FROMnume_tabela1,nume_tabela2
[WHERE criteriu_de_selecie}
ORDER BY cmpuri_criteriu [ASC/DESC]];
Funciile de grup agregat permit construirea unor interogri SQL
complexe, prin care utilizatorul poate s efectueze diverse calcule pentru grupuri
de nregistrri care au cmpuri cu aceeasi valoare. n cazul utilizrii lor se
folosete urmtoarea form a frazei SELECT:

SELECT [domeniu] [funcie agregat (nume_cmp) AS alias [,lista_selecie]
FROM nume_tabela1, n ume_tabela2
GROUP BY cmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY cmpuri_criteriu [ASC/DESC]];
Sintaxa general pentru jonciuni este urmtoarea:
FROM nume_tabela1,nume_tabela 2
WHERE criteriul_de_asociere]
[ORDER BY cmpuri_criteriu[ASC?DESC];
O alt abordare privete jonciunile ca fiind: interne (INNER JOIN) i externe
(OUTER JOIN). Primele determin o asociere a nregistrrilor din tabele, astfel
ncat sa rezulte un numar total de nregistrri din fiecare tabela. Jonciunile
externe, la randul lor, sunt de doua tipuri: de stanga (LEFT OUTER JOIN) i de
dreapta (RIGHT OUTER JOIN) fiind destul de puin utilizate.
n acest mod de abordare al jonciunulor sintaxa va avea forma:
FROM num_tabela1
JOIN nume_tabela2
ON criteriu_de_asociere
[{INNER/LEFT OUTER/ RIGHT OUTER} JOIN nume_tabela3
ON criteriu_de_asociere]
[WHERE criteriu_de_selecie]
[ORDER BY cmpuri_criteriu {ASC/DESC]]:
Unul din motivele pentru care SQL este considerat un limbaj puternic de
interogare este acela c ofer posibilitatea construirii interogrilor complexe,
formate din mai multe subinterogri simple.
Aceste interogri complexe sunt construite prin includerea n clauza
WHERE a nc unei clauze SELECT. Forma general a unei astfel de
construcii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
SQL poate fi folosit att pentru interogarea bazei de date ct i pentru
actualizarea bazelor de date. Comenzile pentru actualizri nu sunt att de
complexe ca declaraia SELECT.
Adugarea se face cu declaraia INSERT care are dou forme prima accepta
adugarea unei singure linii, iar a doua adugarea mai multor linii.
84
I. Adugarea unei singure linii
VALUES (lista_valorilor_datelor)
Nume_tabela reprezint numele unei tabele din baza de date sau o vedere
actualizat a acesteia, lista_atribute reprezint o list de una sau mai multe nume
ale coloanelor tabelei separate prin virgul . Dac aceast list nu este specificat
SQL consider toate atributele tabelei n ordinea n care au fost create n tabela
original. n cazul n care specificm aceast list atributele pe care dorim s le
omitem trebuie s le declarm ca NULL. Numrul de elemente din cele dou
liste trebuie s coincid, s aib aceai ordine de declarare i s fie compatibile
ca tip.
Modificarea se face cu declaraia UPDATE care permite modificarea datelor
unor nregistrri existente ntr-o tabel dat. Sintaxa acestei comenzi este:
UPDATE nume_tabela
SET nume_atribut1=valoare1[,nume_atribut2=valoare2 .]
[WHERE conditie_cautare]
tergerea se face cu declaraia DELETE , sintaxa acestei comenzi este:
DELETE FROM nume_tabela
WHERE conditie_cautare

Se dau urmtoarele relaii cu schemele lor:
-Scri (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaa,Cutii_potale, Nr_prize_tv)
- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume
S se exprime n SQL cererile:
3.2.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1
3.2.4 tabel nominal cu locatarii de pe scrile 1,2,3 ale blocului 34
3.2.5 lista apartamentelor cu suprafaa mai mare dect 50 mp
3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 i nu locuiesc i
pe scara 1 a aceluiai bloc
85

Modulul 4. Normalizarea

Cuprins
Introducere
Obiectivele modului
U4.1 De ce este nevoie de normalizare i cu ce instrumente facem normalizarea.
U4.2 Forme normale

M4 Introducere
La proiectarea unei baze de date, un obiectiv foarte important, care trebuie
urmarit cand se gandeste un model de date, este realizarea unei reprezentari
corecte a datelor, a relatiilor dintre date i a restrictiilor impuse asupra datelor.
Pentru realizarea acestui obiectiv se utilizeaza tehnica normalizarii, care are ca
scop principal identificarea setului celui mai adecvat de relatii care sa modeleze
realitatea dorita.

descopere dependenele funcionale ntre atribute, i s le pun n
eviden proprietile
descopere anomaliile din descrierea unei baze de date
aduc o baz de date la formele normale 1, 2 i 3. descopere
anomaliile din descrierea unei baze de date
aduc o baz de date la formele normale 1, 2 i 3.

86

Unitatea de nvare 4.1 De ce este nevoie de normalizare i cu ce instrumente facem
normalizarea.

Procesul de normalizare este o metod formal care identifica relaiile
bazandu-se pe cheile primare ale acestora (sau pe cheile candidat n cazul BCNF)
i pe dependenele funcionale care exista intre atributele acestor relatii.
Normalizarea sprijina proiectantul bazei de date, dandu-i posibilitatea sa aplice o
serie de teste asupra relatiilor individuale, asa incat schema relaionala poate fi
normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la
actualizare.

realizeze importana normalizrii
descopere dependenele funcionale ntre atribute, i s le pun n
eviden proprietile

Durata medie de parcurgere a primei uniti de nvare este de 1 or.
Pentru a ilustra procesul de normalizare, vom utiliza exemple din sistemul informatic
Asociatie de locatari.
Partea cea mai important la proiectarea bazei de date este gruparea atributelor n relaii cu
scopul de a minimiza redundana informaiilor i (odata cu aceasta) spaiul ocupat de relatii
(tabele sau fiiere) pe suportul magnetic.

Exemple
Fie relaia Furnizori_Cheltuieli exemplificat mai jos. In exemple se vor
simplifica numele atributelor.
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare
F100 Romgaz R1234567 C15 Incalzire 30.06.99
2,150,000
F100 Romgaz R1234567 C16 Apa calda 30.06.99
500,000
F110 Renel R7654321 C10 Iluminat 30.06.99
3,000,000
F110 Renel R7654321 C11 Lift 30.06.99
200,000
Relaia Furnizori_Cheltuieli instaniat
Sa presupunem ca aplicaia pe care o vom studia ca exemplu contine datele organizate intr-o
singura relatie descrisa de urmatoarele schema de relatie:
87
Furnizori_Cheltuieli = (Cod_furn, Den_furn, Cod_fiscal, Cod_chelt, Den_chelt, Data,
Valoare)
Dintre atribute, cele evidentiate constituie cheia primara pentru relatia respectiva.
Relatia Furnizori_Cheltuieli are cheia compusa din atributele Cod_furn, Cod_Chelt i Data.
Datele sunt prost organizate in relatia prezentata.
Informaia despre furnizori din relatia Furnizori_Cheltuieli este redundant. Detaliile
despre furnizor se repet la fiecare introducere a unei cheltuieli noi.
Nu este insa singura problema pe care o organizare nepotrivita a datelor o poate
genera.
O alt consecinta a redundanei informatiilor din baza de date, o reprezinta problemele de
actualizare a informaiei stocate. Enumeram mai jos o parte dintre acestea.
Anomalii de adaugare
Anomaliile de inserare se pot clasifica n dou tipuri:
- Pentru a adauga detaliile despre o cheltuial ctre un furnizor, n relaia
Furnizori_Cheltuieli trebuie obligatoriu adugate i detaliile despre furnizorul n cauz,
chiar dac ele exist deja n baza de date. Aceast anomalie poate duce la apariia de
informatii diferite despre acelasi furnizor n nregistrri diferite. Informatia despre furnizor
isi pierde in acest mod consistenta, nu ne mai putem baza pe corectitudinea datelor despre
furnizor in baza de date.
- Pentru a aduga detalii despre un furnizor nou n relaia Furnizori_Cheltuieli, trebuie
neaprat adugat i o cheltuial pentru asociaia de locatari ctre acel furnizor. n cazul n
care nc nu a sosit factura de la furnizor, nu se poate nregistra nici o cheltuial i deci
trebuie introduse valori nule. Este nerecomandabil sa se lucreze cu valori nule deoarece se
genereaza probleme la regasirea i actualizarea informatiilor.
Anomalii de tergere
n cazul tergerii unei cheltuieli a asociaiei de locatari ctre un furnizor nou (tot in cadrul
relatiei Furnizori_Cheltuieli ), se va terge i furnizorul. Deci toate detaliile introduse despre
acel furnizor vor fi pierdute, ceea ce duce la obligativitatea reintroducerii datelor la o nou
folosire al acelui furnizor.
Anomalii de modificare
Dac n relaia Furnizori_Cheltuieli dorim s schimbm valoarea unui atribut al unui
furnizor, va trebui s schimbm datele pentru fiecare apariie a acelui furnizor. De exemplu
dac dorim s schimbm codul fiscal al furnizorului cu codul F100, va trebui s schimbm
acest atribut n toate tuplele in care apare furnizorul F100. Din nou , este posibil ca datele sa
nu fie modificate corect. Este posibil sa ramana tuple cu datele nemodificate sau este posibil
sa se modifice datele respective cu valori diferite in locuri diferite. (Nu dorim sa insistam
asupra cauzelor care pot duce la aceste situatii.).
Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a dou relatii
distincte: Cheltuieli i Furnizori. n acest caz dac trebuie modificat un atribut al unui
furnizor, modificarea se va xecuta intr-un singur loc n relatia Furnizori. Asemanator, daca e
necesara o stergere in relatia Cheltuieli, aceasta nu va mai afecta furnizorii din relatia
Furnizori. De asemenea orice cheltuiala adaugata i orice furnizor nou adaugat nu se vor mai
conditiona reciproc in nici un fel.
Descompuneri cu pierderi de informatii
88
n urma analizarii anomaliilor de actualizare prezentate mai sus am tras concluzia ca o
descompunere a relatiilor care ne fac probleme este binevenita i duce la rezolvarea
problemelor. Este bine insa sa tratam descompunerile de relatii cu prudenta deoarece o
descompunere neglijenta ne poate crea probleme la fel de mari cu acelea de care tocmai ne-
am ocupat. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se
realizeaza descompunerea.
n general se poate urmari ca in fiecare relatie sa se reprezinte informatii despre o
singura multime-entitate. Criteriul este mai mult de ordin intuitiv i el nu ne este de mare
ajutor in cazul reprezentarii multimilor-relatie. In acest caz, intr-o relatie se intalnesc date
despre mai multe multimi-entitate. Este necesar sa se stabileasca o modalitate riguroasa de a
decide care sunt informatiile care trebuie sa alcatuiasca o astfel de relatie.
Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema oarecare
de relatie. Un set de scheme de relatie reprezinta o descompunere a lui R i se noteaza {R
1
,
R
2
, , R
n
} daca
n
i
i
R
1 =
= R
Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel
putin o schema de relatie din descompunere. Daca ne raportam la relatiile care se bazeaza pe
schemele de mai sus, fie r relatia construita pe schema R sie fie relatiile r
1
, r
2
, , r
n
construite
pe schemele de relatie ce formeaza descompunerea. In termenii algebrei relaionale se poate
considera egalitatea;
r
i
=
[
i
R
(r) pentru toti 1sisn.
Deci fiecare r
i
este proiectia relatiei r pe atributele care apar in schema de relatie R
i
.
Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu
pierderi la jonctiune i Descompuneri cu pierderea dependentelor. Pentru a clarifica
lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta
functionala.
Dependene funcionale
Unul din cele mai importante concepte asociate cu normalizarea este conceptul de
dependen funcional. Dependena funcional descrie un anumit tip de legatura care se
stabileste intre atributele aceleiasi relatii.
Fie o schema de relatie R i fie submultimile de atribute A i B din R. Se verifica A_R
i B_R. Spunem ca B depinde functional de A i scriem AB daca pentru orice relatie legala
r, construita pe schema de relatie R, se verifica urmatoarea situatie: pentru orice pereche de
tuple t
1
i t
2
din r, pentru care t
1
[A]=t
2
[A], are loc intotdeauna i t
1
[B]=t
2
[B].
Aceasta inseamna ca atunci cand un tuplu t
1
are (pe submultimea de atribute A)
aceeasi valoare cu alt tuplu t
2
, obligatoriu cele doua tuple vor avea aceeasi valoare i pe
submultimea de atribute B. Valorile din B sunt in mod unic determinate de valorile din A.
Numim determinant al unei dependente funcionale, atributul, sau mulimea
atributelor din partea stng a sgeii.

Exemple O parte dintre dependenele funcionale pentru relaia
Furnizori_Cheltuieli sunt:
Cod_furn Den_furn
89
Cod_furn Cod_fiscal
Cod_chelt Den_chelt
Cod_chelt, Cod_furn, Data Valoare
Numele furnizorului este determinat in mod unic de codul furnizorului. La coduri
egale, numele sunt identice.
Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod
cheltuiala, cod furnizor i data. Intr-o anume data, un anumit furnizor, pentru un
anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine
determinata de bani. Nici una dintre valori nu poate determina valoarea i nici in
combinatii de cate doua. Daca nu se iau cele trei informatii impreuna se pot crea
confuzii in legatura cu valoarea. (Acelasi cod de cheltuiala poate corespunde la
valori diferite in date diferite. Acelasi furnizor poate avea chiar i coduri de
cheltuiala diferite darmite valoarea care le reprezinta, s.a.m.d. )

Notiunea de dependenta functionala generalizeaza notiune de cheie. Se poate da
urmatoarea definitie a supercheii:
Spunem ca submultimea deatribute K din schema de relatie R este o supercheie daca
KR, adica pentru orice pereche de tuple t
1
i t
2
1
[K]=t
2
[K], are loc
intotdeauna i t
1
[R]=t
2
[R].
Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor pe care nu
le putem exprima cu ajutorul cheilor. Dependena funcional este o proprietate legata de
semantica atributelor n relaii. Dependentele functionale pot fi stabilite de cine cunoaste exact
legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaia i
semnificatia informatiilor din relatii.
Nu se pot da retete pentru stabilirea dependentelor functionale, dar se pot da metode
de a determina toate dependentele functionale dintr-o relatie daca se cunosc cateva
dependente de la care poate porni algoritmul.
O metoda de a determina multimea tuturor dependentelor functionale dintr-o relatie se
bazeaza pe asa-numitele Axiome ale lui Armstrong.
Regulile (Axiomele) lui Armstrong:
1) regula reflexivitatii daca X este un subset de atribute din R i YX, atunci are loc
XY;
2) regula creterii daca X, Y i W sunt subseturi de atribute din R i daca XY atunc
WXWY;
3) regula tranzitivitatii daca X, Y i Z sunt subseturi de atribute din R i daca XY i
YZ atunci are loc i XZ.
Cele trei reguli sunt suficiente i formeaza un set complet pentru a se putea determina
toate dependentele functionale daca se porneste de la un set de baza initial. Totusi se mai
utilizeaza in mod obisnuit i reguli suplimentare (care pot fi deduse din primele trei) deoarece
usureaza calculele.
Astfel:
4) regula reuniunii daca X, Y i Z sunt subseturi de atribute din R i daca XY i XZ
90
atunci i XYZ;
5) regula descompunerii daca daca X, Y i Z sunt subseturi de atribute din R i daca
XYZ atunci au loc i XY i XZ;
6) regula pseudotranzitivitatii - daca X, Y, W i Z sunt subseturi de atribute din R i daca
XY i WYZ atunci i WXZ

Exemple
EXEMPLU:
Fie schema de relatie R={A, B, C, G, H, I} i fie setul de dependente initial notat
cu F i format din dependentele: AB, AC, CGH, CGI, BH.
Pornind de la acest set initial se mai pot calcula i urmatoarele dependente:
- AH, utilizand regula tranzitivitatii aplicata la dependentele AB i BH;
- CGHI, utilizand regula reuniunii pentru dependentele CGH i CGI;
si asa mai departe

Daca se noteaza cu F setul initial de dependente functionale, cu F
+
se va nota
inchiderea lui F (deci toate dependentele functionale care se pot defini pentru relatia in cauza.)
Putem reveni in acest moment pentru a trata descompunerile de relatii. Am subliniat
mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita pierderea de
informatii.
Descompuneri fara pierderi la jonciune
Fie o descompunere oarecare {R
1
, R
2
, , R
n
} a relatiei R, asa cum am definit-o
formal la inceputul acestui capitol. Pentru o descompunere oarecare se verifica intotdeuna
relatia:
r_
n
1 i
X
=
r
i

unde prin X s-a notat produsul cartezian, operatie din algebra relaionala. Altfel spus, orice
tuplu din relatia r duce, prin descompunere, la cate un tuplu t
i
in fiecare relatie r
i
. Cand se
realizeaza produsul cartezian cu toate relatiile r
i
, se obtin in general mai multe tuple decat au
fost in relatia initiala r, deoarece produsul cartezian are ca rezultat toate combinatiile posibile
intre elementele participante.
Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii sau
conditii, care sa asigure corectitudinea informatiilor din respectiva baza de date.
n general spunem ca o relatie este legala daca satisface toate regulile sau restrictiile
care sunt impuse la proiectarea bazei de date.
Fie C un set de restrictii asupra bazei de date. O descompunere {R
1
, R
2
, , R
n
} a unei
scheme de relatie R este o descompunere fara pierderi la jonctiune pentru R, daca pentru toate
relatiile r definite pe schema R (care sunt legale sub restrictiile C) se verifica:
r=
n
1 i
X
=
r) (
i
R
H
Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o
descompunere fara pierderi la jonctiune sau nu.
91
Definitie. Fie R o schema de relatie i fie descompunerea lui R reprezentata de {R1, R2}.
Aceasta descompunere este fara pierderi la jonctiune daca cel putin una dintre urmatoarele
dependente functionale se gasesc in F
+
:
R
1
R
2
R
1

R
1
R
2
R
2

Descompuneri cu pastrarea dependentelor
Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza de date.
Se pot impune restrictii care permit sistemului sa verifice la orice actualizare a informatiilor
ca nu se va crea o relatie ilegala.
Fie F setul initial de dependente functionale, definit pe o schema de relatie R. i fie
{R
1
, R
2
, , R
n
} o descompunere a lui R. Notam cu F
i
restrictia la R
i
a multimii de dependente
functionale F. (Se cere ca dependentele functionale din F
i
sa includa doar atribute care se
regasesc in relatia R
i
).
Vom obtine un set de multimi de dependente functionale F
1
, F
2
, , F
n
. Fie F'=
n
i 1 =
F
i
,
reuniunea seturilor de dependente funtionale. In general F'=F. Dar s-ar putea ca sa se verifice
relatia F'
+
=F
+
. Daca se intampla asa atunci spunem ca descompunerea este o descompunere cu
pastrarea dependentei.

M4.U4.1. Rezumat
Din cauza proiectrii incorecte pot aprea anomalii la in serare de noi
nregistrri, la terger i la modificri.
In urma analizarii anomaliilor de actualizare prezentate mai sus am tras
concluzia ca o descompunere a relatiilor care ne fac probleme este binevenita
i duce la rezolvarea problemelor. Este posibil sa pierdem informatii daca nu
suntem atenti la modul in care se realizeaza descompunerea.
Orice relatie se construieste pe baza unei scheme de relatie. Fie R o schema
oarecare de relatie. Un set de scheme de relatie reprezinta o descompunere a
lui R i se noteaza {R
1
, R
2
, , R
n
} daca
n
i
i
R
1 =
= R
Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste
in cel putin o schema de relatie din descompunere. Daca ne raportam la
relatiile care se bazeaza pe schemele de mai sus, fie r relatia construita pe
schema R sie fie relatiile r
1
, r
2
, , r
n
construite pe schemele de relatie ce
formeaza descompunerea. In termenii algebrei relaionale se poate considera
egalitatea;
r
i
=
[
i
R
(r) pentru toti 1sisn.
Deci fiecare r
i
este proiectia relatiei r pe atributele care apar in schema de
relatie R
i
.
Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu
pierderi la jonctiune i Descompuneri cu pierderea dependentelor. Pentru
92
a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii
de dependenta functionala.
Fie o schema de relatie R i fie submultimile de atribute A i B din R. Se
verifica A_R i B_R. Spunem ca B depinde functional de A i scriem AB
daca pentru orice relatie legala r, construita pe schema de relatie R, se verifica
urmatoarea situatie:
pentru orice pereche de tuple t
1
i t
2
1
[A]=t
2
[A], are loc
intotdeauna i t
1
[B]=t
2
[B].
Regulile (Axiomele) lui Armstrong:
7) regula reflexivitatii daca X este un subset de atribute din R i YX,
atunci are loc XY;
8) regula creterii daca X, Y i W sunt subseturi de atribute din R i daca
XY atunc WXWY;
9) regula tranzitivitatii daca X, Y i Z sunt subseturi de atribute din R i
daca XY i YZ atunci are loc i XZ.

4.1.1 Descoperii dependenele funcionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

93
Unitatea de nvare 4.2 Forme normale

M4.U4.2 Introducere
Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniial s-au propus
trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai trziu, prin enuntarea
unei definitii mai tari a formei normale trei, s-a obtinut forma Boyce-Codd, dup
numele celor care au introdus aceasta forma normala: R. Boyce i E. F. Codd
(1974). Toate aceste forme normale se bazeaza pe dependentele functionale
stabilite intre atributele unei relatii.
Formele normale cele mai folosite sunt: forma normal 3 i forma normal
Boyce-Codd. Exist i forme normale mai tari - forma normal 4 (4NF) i forma
normal 5 (5NF) - dar acestea se folosesc foarte rar.

descopere anomaliile din descrierea unei baze de date
aduc o baz de date la formele normale 1, 2 i 3.

Normalizarea este un proces de organizare a datelor in relatiile unei baze de d ate.
Acest proces presupune respectarea unor reguli prin care baza de date se poate normaliza pn
la un anumit grad, adica se aduce la o anumita forma normala.
Normalizarea se execut trecnd prin toate formele normale, pn la forma normal cerut. La
proiectarea unei baze de date e recomandabil sa se ajunga cel puin pana la forma normal
trei. Aceasta asigura evitarea anomaliilor descrise la inceputul acestui capitol.
Forma Normal Unu (1NF)
Numim Form Nenormalizat (UNF) orice tabel care conine una sau mai multe grupuri
repetitive pe atribute.
Forma Normal Unu (1NF): Spunem ca o relaie se gaseste in Forma normala unu daca
orice atribut este atomic, adica nu exista nici atribute compuse nici repetitive.
Pentru a transforma tabela din exemplul urmtor n forma normal unu, identificm i
tergem grupurile repetitive din tabel. Eliminarea acestor grupuri repetitive se poate realiza
n dou moduri:

Exemple 4.2.1
Pentru relaia Furnizori_Cheltuieli:
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data
Valoare
2,150,000
C16 Apa calda 30.06.99 500,000
3,000,000
94
C11 Lift 30.06.99 200,000
Tabela nenormalizat Furnizori_Cheltuieli.

Conform primei modaliti, eliminm grupurile repetitive, prin crearea altor
nregistrri, n care s fie introduse valorile din aceste grupuri, mpreun cu celelalte valori ale
atributelor din nregistrarea la care se lucreaz. Tabele astefel rezultat va fi n form normal
unu.
n a doua modalitate, fiecere valoare a grupurilor repetitive le copiem ntr -o nou
relaie mpreun cu cheia primar din tabela iniial. Putem avea mai multe grupuri repetitive.
n acest caz crem mai multe relaii noi. Aceste relaii noi, precum i tabela normalizat vor fi
n form normal unu.
Observm c pentru furnizorul "Romgaz" avem dou tipuri de cheltuieli. La fel i
pentru furnizorul "Renel".
Pentru a transforma aceast tabel n 1NF, trebuie s avem o singur valoare la fiecare
intersecie linie coloan.
Daca vom normaliza dupa prima metoda, vom scrie repetiiile pe diferite rnduri iar
coloanele care nu conin repetiii, vor fii copiate corespunzator pe fiecare rnd

Exemple 4.2.2
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data
Valoare
2,150,000
F100 Romgaz R1234567 C16 Apa calda 30.06.99
500,000
3,000,000
F110 Renel R7654321 C11 Lift 30.06.99
200,000
Tabela Furnizori_Cheltuieli n 1NF

n tabela normalizat, cheia va fi (Cod_furn, Cod_chelt, Data).
Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabel cu
informaiile care nu se repet, mpreun cu cheia primar din tabela iniial. Deci cele dou
tabele vor fi urmtoarele:

Exemple 4.2.3
Furnizori (Cod_furn, Den_furn, Cod_fiscal)
Cheltuieli (Cod_furn, Cod_chelt, Data, Den_chelt, Valoare)
Cele dou tabele astfel create sunt n 1NF:
Cheltuieli
Cod_furn. Cod_chelt Data Den_chelt Valoare
F100 C15 30.06.99 Incalzire 1500000
F100 2 C16 30.06.99 Apa calda 500000
F110 3 C10 30.06.99 Iluminat 3000000
F110 4 C11 30.06.99 Lift 200000
Furnizori
Cod_furn Den_furn Cod_fiscal
F100 Romgaz R1234567
95
F110 Renel R7654321

Relaiile Cheltuieli i Furnizori, create prin metoda a doua de normalizare.

Pentru a demonstra trecerea la forma normal doi i mai departe, vom folosi relaia
Furnizori_Cheltuieli, prezentata n exemplul 4.2.2.
Forma Normal Doi (2NF)
Forma normal doi se obtine utilizand conceptul de dependen funcional tot al.
Dependena funcional total. Dac A este un subset de doua sau mai multe atribute i B
este atribut (sau subset de atribute) al aceleiasi relaii, spunem ca B este total dependent
funcional de grupul de atribute A, dac B este dependent funcional de A, dar nu este
dependent funcional de nici un subset de atribute din A.

Exemple 4.2.4
De exemplu s lum urmtoarea dependen funcional:
Cod_chelt, Cod_furn, Data Valoare
Dependena funcional este totala pentru ca Valoare nu depinde functional de
nici un subset de atribute al grupului Cod_chelt, Cod_furn, Data.

Forma normal doi trebuie verificat doar la relaiile care au cheie compus pe poziie
de cheie primar. Relaia la care cheia primar se compune dintr -un singul atribut, este n 2NF
daca este in 1NF.
Forma Normal Doi (2NF). O relaie este n forma normal doi, dac este n forma normal
unu i fiecare atribut care nu aparine cheii primare, este total dependent funcional de cheia
primar.
Vom demonstra aducerea la forma normal doi, folosind relaia Furnizori_Cheltuieli.
Putem trece la forma normal doi prin tergerea atributelor care nu depind total de cheia
primar i trecerea lor ntr-o alt tabel mpreun cu determinantul lor. Dup efectuarea
acestor transformri, vom obtine urmtoarele relaii:

Exemple Relatia Cheltuieli:
Cod_furn. Cod_chelt Data Valoare
F100 C15 30.06.99 1500000
F100 C16 30.06.99 500000
F110 C10 30.06.99 3000000
F110 C11 30.06.99 200000
Relaia Furnizori:
Cod_furn Den_furn Cod_fiscal
F100 Romgaz R1234567
F110 Renel R7654321
Relatia Tip_cheltuiala:
Cod_Chelt Den_chelt
C15 Incalzire
C16 Apa calda
C10 Iluminat
C11 Lift
Figura 5.5. Relaiile rezultate dup trecerea la 2NF a relaiei
Furnizori_Cheltuieli.
Relaiile rezultate au urmtoarele scheme de relatie:
Furnizori = (Cod_furn., Den_furn, Cod_fiscal)
96
Tip cheltuial = (Cod_Chelt., Den_chelt)
Cheltuieli = (Cod_furn, Cod_chelt, Data, Valoare)

Forma Normal Trei (3NF)
Forma normal doi chiar dac nu conine atta redundan ca forma normal unu,
totui exist cazuri n care pot aprea anomalii la actualizare. Aceste anomalii apar din cauza
redundanei generate de dependena tranzitiv.
Dependen tranzitiv. Dac atributele A, B, C sunt n relaiile AB i BC, atunci
spunem c atributul C este dependent tranzitiv de atributul A, via B.
Forma Normal Trei (3NF). Spunem ca o relaie este n form normala trei daca este deja in
forma normal doi i nici un atribut care nu aparine cheii p rimare nu este tranzitiv dependent
de cheia primara.
n cazul existenei dependenei tranzitive, tergem coloanele care sunt tranzitiv
dependente de cheia primar i crem o relaie nou cu aceste coloane, mpreun cu
determinantul lor, adic cheia primar.
Examinnd relaiile n forma normal de mai sus, observm c nu exist dependene
tranzitive. Deci relaiile sunt n form normal trei.

Exemple
S considerm tabela cu schema:
Carte=(cod_car,titlu,cod_dom,denumire_domeniu)
Cheia este cod_car.
Avem depemdenele funcionale:
cod_car cod_dom
cod_car titlu
cod_dom denumiredomeniu
vedem c dependea lui denumire_domeniu de cod_car este tranzitiv (via
cod_dom)
Descompunerea acestei scheme pentru a ajunge la form normal trei este:
Carte=(cod_car,titlu,cod_dom)
Cu cheia cod_car.
Domenii=( cod_dom,denumire_domeniu)
Cu cheia cod_dom.

Forma Normal Boyce-Codd (BCNF)
Baza de date trebuie proiectat astfel nct s nu conin dependene pariale sau
tranzitive, pentru c altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului.
Forma normal Boyce-Codd se obtine utilizand cheile candidat din relaie. O relaie cu o
singur cheie candidat n form normal trei este i n form normal Boyce -Codd.
Forma normal Boyce-Codd (BCNF). Spunem ca o relaie este n forma normal Boyce-
Codd dac i numai dac orice determinant din relaie este cheie candidat.
S cutm determinanii din exemplul de mai sus:
Cod_furn Den_furn, Cod_fiscal
Cod_chelt Den_chelt
Cod_furn, Cod_chelt, Data Valoare
97
Toi cei trei determinani sunt i chei candidat in relatiile lor. Deci relatiile din
exemplul de mai sus sunt n form normal Boyce-Codd. Relaiile n form normal trei sunt
n general i n form normal Boyce-Codd. n cazul n care relaia nu este n form normal
Boyce-Codd, trecerea la BCNF se realizeaz prin tergerea din relaia iniial a atributelor
care sunt asociate unui determinant care nu este cheie candidat i crearea unei noi relaii cu
aceste atribute i determinantul lor.
Exist situaii cnd este foarte greu de descompus relatiile, ca s ajungem la BCNF. n
aceste situaii este indicata rmnerea la forma normal trei.

M4.U4.2. Rezumat
Forma Normal Unu (1NF)
Trebuie s cutm toate interseciile de linii i coloane, unde exist repetiii.
Aceste repetiii se pot elimina prin dou madaliti:
- Crearea de noi nregistrri pentru fiecare valoare a repetiiei, dup care se caut
o nou cheie primar.
- tergerea atributelor care conin repetiii i crearea de noi relaii care vor
conine atributele terse, precum i cheia primara din relaia iniial.
Forma Normal Doi (2NF)
Se caut dependenele totale de cheia primara, adic toate atributele care depind
funcional de un subset de atribute a cheii primare. Dac cheia primar este
compus dintr-un singur atribut, atunci relaia este n forma normal doi, daca
este deja in forma normala unu. Dac exist dependene partiale, tergem
atributele care depind parial de cheia primara i crem o relaie nou care s se
compun din atributele terse mpreun cu determinantul lor.
Forma Normal Trei (3NF)
Pentru a trece la forma normal trei, trebuie s eliminm dependenele tranzitive.
Eliminarea se realizeaz prin tergerea cmpurilor dependente tranzitiv de cheia
primar din relaia iniial i crearea unei noi relaii cu aceste atribute i
determinantul lor.
Forma Normal Boyce-Codd (BCNF)
Cerina la forma normal Boyce-Codd este ca fiecare determinant din relaie s
fie cheie candidat. n cazul n care nu este ndeplinit aceast cerin, vom terge
atributele dependente funcional de determinantul care nu este cheie candidat i
crem o nou relaie n care s avem atributele terse i determinantul lor. n
unele cazuri trecerea la forma normal Boyce-Codd complic foarte mult baza de
date, caz n care este de preferat rmnerea la forma normal trei.

98

4.2.1) Aducei la forma normal 1 urmrtoarea tabel:
Relaia Furnizori_Cheltuieli:
Cod
Furn.
Denumire Cod
fiscal
Nr.
Crt.
Cod
Chelt.
Denumire
Cheltuial
Valoare
F100 Romgaz R1234567 1 C15 Chelt pt.
nclzire
1500000
2 C16 Chelt pt.
Buctrii
500000
F110 Renel R7654321 3 C10 Chelt cu
iluminatul
3000000
4 C11 Chelt pt.
Func. liftului
200000
4.2.2 Aducei la forma normal 2 schema:
(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuial, Nr. Crt., Cod,
Valoare)
4.2.3 Aducei la forma normal 3 schema:
carte = (c_carte, titlu, cod_domeniu, den_domeniu)
4.2.4 Aducei, pe rnd, la form npr mal 1, 2 i 3 tabela:

99
Modulul 5. Metodologia de proiectare a bazelor de date
relaionale

Cuprins
Introducere
Obiectivele modului
U5.1 Generaliti i proiectarea conceptual
U5.2 Proiectarea logica
U5.3 Proiectarea fizica
U5.4 Tranzacii i concuren
U5.5 Metode de control al concurenei.

M5. Introducere
Metodologia de proiectare este o aproximare structurat, care utilizeaz
proceduri, tehnici, instrumente i documentaii pentru a facilita procesul de
proiectare.
Metodologia de proiectare se compune din etape, care la rndul lor se
compun din pai, care orienteaz proiectantul la fiecare nivel al crerii bazei de
date.
n mod obinuit, un sistem SGBD deservete mai muli utilizatori, care acceseaz
concurent datele din tabele. Accesul concurent al utilizatorilor este asigurat prin
capacitatea de multiprogramare a sistemului de operare al calculatorului gazd, care
permite execuia concurent a mai multor procese. Execuia concurent a mai multor
procese poate avea loc att ntr-un sistem uniprocesor, prin partajarea (mprirea)
timpului de execuie al procesorului ntre mai multe procese, ct i ntr-un sistem
multiprocesor n care mai multe procese pot fi executate n mod real simultan, pe mai
multe procesoare ale sistemului. Indiferent de numrul de procesoare ale sistemului,
accesul concurent al mai multor utilizatori la datele memorate n tabelele unei baze de
date necesit tehnici de meninere a consistenei (corectitudinii) i a siguranei datelor
memorate.

respecte o metodologie de proiectare
creeze modelul conceptual al unui sistem informatic
realizeze proiectul logic local
realizeze proiectul logic global
aleag, n cunotin de cauz, SGBD-ul cel mai potrivit.
100
descrie corect structura fizic a bazei de date
proiecteze cereri
proiecteze formulare
proiecteze rapoarte
construiasc tranzacii corecte
aleag cea mai bun metod de control al concurenei
introduc regulile de integritate
s impun msuri de securitate

101
Unitatea de nvare U5.1 Generaliti i pro iectarea conceptual

M5U1 Introducere
Metodologia de proiectare are o mare importan n ordonarea muncii grele de
proiectare a unui sistem informatic. Prima etap, mai puin standardizat i care
depinde esenial de experiena celui care o deplinete, este proiectarea
conceptual, n care trebuie s aflm cum funcioneaz intreprinderea i ce parte
din circuitul informaional va fi automatizat.

M5.U1. Obiectivele unitii de nvare
respecte o metodologie de proiectare
creeze modelul conceptual al unui sistem informatic


n orice domeniu folosirea unei metodologii are o mare importan. O metodologie
este o cale de a apllica n proiectare metoda divide et impera. Separarea n pai asigur
divizarea problemei iniiale n probleme mai mici i deci mai uor de rezolvat, iar partea de
impera este rezolvat de succesiunea strict a pailor i de faze speciale cum ar fi, n cazul
nostru, realizarea modelului logic global. Un alt avantaj l constitue faptul c la terminarea
activitii de proiectare, avem o mare parte din documentaia proiectului realizat. De
asemenea urmrirea uinei metodologii face posibil lucru n echip prin divizarea sarcinilor i
posibibilitatea urmririi stadiului la care s-a ajuns.
Paii mari ai metodologiei pe care o prezentm aici sunt proiectarea logic i
proiectarea fizic.
Definiie: Proiectare logic: Procesul de construcie a unui model de informaii folosite ntr -o
ntreprindere, bazat pe modelul de date, dar independent de particularizrile sistemului de
gestiune a bazei de date i a altor considerente fizice.
Proiectarea logic ncepe cu crearea modelului conceptual al bazei de date, care este
independent de implementarea ntr-un SGBD. Modelul conceptual este apoi proiectat pe un
model logic, care va influena mai trziu modelul de date n care se va implementa.
Definiie: Proiectare fizic: Este procesul de descriere a implementrii bazei de date
ntr-un SGBD.
n aceast etap a proiectrii este creat baza de date ntr-un SGBD, mpreun cu
procedurile de actualizare. n aceast etap exist un feedback ntre proiectarea fizic i cea
logic, pentru c deciziile luate la implementarea fizic pot afecta baza de date logice.
Pe parcursul activitii de proiectare trebuie s fie satisfcute mai multe cerine, multe dintre ele fiind
contradictorii i dificil de ndeplinit: obinerea unu i timp de rspuns la interogri ct mai mic, i, n
acelai timp, utilizarea unui spaiu de memorare ct mai redus; asigurarea unui mod de acces la date
ct mai simplu dar intuitiv, etc.
102
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai multe ori,
procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate. Prin contrast, proiectul
rezultat trebuie s conin schema bazei de date precis definit, dat fiind c, dup implementarea
aplicaiilor, modificarea bazei de date este mult mai dificil.
Terminologia folosit n domeniul proiectrii bazelor de date este destul de variat, existnd i
unele ambiguiti privind denumirile etapelor sau ale tipurilor de scheme ale bazelor de date. Cel mai
frecvent, pentru proiectul conceptual al unei baze de date se folosesc denumirile de schem
conceptual de nivel nalt sau schem conceptual independent de SGBD sau, chiar mai simplu,
schem conceptual. Proiectul logic al unei baze de date este denumit schem logic sau schem
conceptual dependent de SGBD n cele mai multe lucrri din domeniul proiectrii bazelor de date.
nainte de a se 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, aplicaii de urmrire a consumurilor, aplicaii de salar izare, etc.).
n general, n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele activiti:
Identificarea grupurilor de utilizatori poteniali si a aplicaiilor. De regul, persoana cea
mai avizat din cadrul fiecrui grup de util izatori este cooptat ca participant n
activitile ulterioare de colectare i analiz a cerinelor.
Revederea documentaiei existente privind aplicaiile dorite, n afar de documentaiile
aplicaiilor dorite se studiaz i alte documentaii i interviuri. Se colecteaz
rspunsuri scrise de la utilizatorii poteniali la diferite seturi de ntrebri i se
organizeaz interviuri cu persoanele care reprezint diferitele grupuri de utilizatori,
n felul acesta, proiectanii pot nelege care sunt prioritile de proiectare a
bazei de date, importana diferitelor aplicaii i performanele dorite de la acestea.
Toate aceste activiti ofer informaii slab(diagramele de organizare a ntreprinderii,
formularele existente de introducere a datelor, rapoartele utilizate n controlul activitii
respective, etc.), pentru a se decide dac aceste aspecte influeneaz cerinele bazei de date.
Analiza mediului de operare i a cerinelor de prelucrare a datelor.
Aceast activitate include analiza fluxului de informaii n cadrul sistemului, precum
i analiza tipurilor de tranzacii i a frecventei de lansare a acestora. Deosebit de
important este i stabilirea volumului de date coninute n mod tipic de baza de
date, a volumului i frecvenei datelor actualizate precum i a volumului datelor
retumate de interogri i a frecvenei acestora.
Chestionare structurate, n general n limbaj natural, pe baza crora se pot construi diagrame, tabele,
grafice, etc., manual sau folosind diferi te instrumente software de proiectare. Aceast faz este puternic
consumatoare de timp, dar este crucial pentru succesul sistemului informatic.
103

Prezentarea metodologiei
Prima dat s vedem care sunt paii de urmat n proiectare:
Pasul 1. Proiectarea logic a bazei de date relaionale: Crearea unui model conceptual
local, pentru vederile utilizatorilor.
Pasul 1.1. Identificarea tipurilor de entiti.
Pasul 1.2. Identificarea tipurilor de relaii.
Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de
relaii.
Pasul 1.4. Determinarea domeniilor de definiie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare.
Pasul 1.6. Specializare/generalizare (pas opional).
Pasul 1.7. Desenarea diagramei entity-relationship.
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 2. Crearea i validarea modelului logic local.
Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
Pasul 2.2. Crearea relaiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utiliznd normalizarea.
Pasul 2.4. Validarea modelului din nou, utiliznd tranzaciile.
Pasul 2.5. Desenarea diagramei ER.

S ne reamintim...
O metodologie este o cale de a apllica n proiectare metoda divide et
impera. Separarea n pai asigur divizarea problemei iniiale n probleme mai
mici i deci mai uor de rezolvat, iar partea de impera este rezolvat de
succesiunea strict a pailor i de faze speciale cum ar fi, n cazul nostru,
realizarea modelului logic global.
Paii mari ai metodologiei pe care o prezentm aici sunt proiectarea
logic i proiectarea fizic.
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai
multe ori, procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate.
Prin contrast, proiectul rezultat trebuie s conin schema bazei de date precis definit.
nainte de a se 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.
n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele
activiti:
Identificarea grupurilor de utilizatori poteniali si a aplicaiilor.
Revederea documentaiei existente privind aplicaiile dorite
i interviuri.
Toate aceste activiti ofer informaii slab(diagramele de organizare a
ntreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate n controlul activitii respective, etc.), pentru a se decide dac
aceste aspecte influeneaz cerinele bazei de date.

104
Pasul 2.6. Definirea regulilor de integritate a bazei de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 3. Crearea i validarea modelului logic global de date.
Pasul 3.1. Compunerea medelelor logice locale ntr-un model logic global.
Pasul 3.2. Validarea modelului logic global.
Pasul 3.3. Verificarea posibilitii de a completa baza de date n viitor.
Pasul 3.4. Desenarea diagramei ER finale.
Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
Pasul 4. Proiectarea fizic i implementarea bazei de date relaionale: Translatarea
modelului logic global n SGBD.
Pasul 4.1. Proiectarea relaiilor de baz n SGBD.
Pasul 4.2. Crearea regulilor de integritate n SGBD.
Pasul 5. Proiectarea i implementarea reprezentrii fizice.
Pasul 5.1. Analizarea tranzaciilor.
Pasul 5.2. Alegerea organizrii fiierelor.
Pasul 5.3. Alegerea indecsilor secundari.
Pasul 5.4. Introducerea unei redundane comntrolate.
Pasul 5.5. Estimarea spaiului pe disc.
Pasul 6. Proiectarea i implementarea unui mechanism de securitate.
Pasul 6.1. Crearea view-urilor pentru utilizatori.
Pasul 6.2. Proiectarea regulilor de acces la baza de date.
Pasul 7. Verificarea sistemului operaional.
Proiectarea logic a bazei de date se divide n trei pai mari. Primul pas are ca
obiectiv, descompunerea proiectrii sistemului informatic n vederi, care se pot discuta cu
utilizatorii sistemului. Modelul de date astfel creat, se valideaz prin normalizare i prin
tranzacii n pasul doi. n final, se genereaz modelul global al ntreprinderii, care este la
rndul lui validat i verificat cu ajutorul utilizatorului sistemului.
Factori critici pentru succesul proiectrii logice:
- Lucrul interactiv cu utilizatorul sistemului.
- Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date.
- ncorporarea regulilor de integritate n modelul logic de date.
- Combinarea validrii conceptuale, prin normalizare i prin tranzactii, la proiectarea
modelului logic de baze de date.
- Utilizarea diagramelor pentru a reprezenta ct mai multe modele logice posibile.
- Crearea dicionarului de date, ca supliment al modelului de date.

Crearea modelului logic
Pasul 1. Crearea modelului conceptual local, pentru utilizatori.
Dei nu este obligatoriu, aceast faz se poate menine independent 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, datorit urmtoarelor motive:
Scopul proiectrii schemei conceptuale este nelegerea ct mai complet a structurii
bazei de date, a asocierilor i a constrngerilor de ctre proiectani i programatori. Acest
deziderat se obine mult mai bine independent de un anumit SGBD, deoarece un model
de date de nivel nalt este mult mai general i mai expresiv, n timp ce fiecare SGBD
105
are propriile restricii i soluii particulare, care nu trebuie s influeneze proiectul
schemei conceptuale.
Obiectivul: Crearea unui model conceptual local, pentru view-urile utilizatorilior.
Primul pas n proiectarea bazei de date este de a colecta datele necesare pentru
realizarea sistemului, ceea ce putem culege, discutnd cu viitorii utilizatori ai bazei de date.
Acrast discuie presupune o desprire n vederi, a bazei de date, vederi care pot lucra
separat.
Desprirea n vederi se poate realiza n mai multe moduri. O modaliate ar fi analiza
datelor globale i gsirea de pri relativ independente. O alt modalitate ar fi analiza
rapoartelor, procedurilor cerute i/sau observarea sistemului existent n lucru.
Modelele conceptuale locale trebuie s conin:
- tipuri de entiti,
- tipuri de relaii,
- atribute,
- domeniile atributelor,
- cheile candidat,
- chei primare
Paii din prima etap a proiectrii logice sunt:
- Pasul 1.1. Identificarea tipurilor de entiti.
- Pasul 1.2. Identificarea tipurilor de relaii.
- Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i tipurile de
relaii.
- Pasul 1.4. Determinarea domeniilor de definiie a atributelor.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate i primare.
- Pasul 1.6. Specializare/generalizare (pas opional).
- Pasul 1.7. Desenarea diagramei entity-relationship.
- Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 1.1. Identificarea tipurilor de entiti
Obiectivul: Identificarea tipurilor de entiti principale n vederile utilizatorilor.
Primul pas n proiectarea bazei de date este identificarea entitiilor din datele
furnizate de utilizatori. De exemplu, dac avem informaiile Nr_Mat, Nr_Bloc, Scara, Etaj,
Apartament i Nume, putem identifica entitatea Locatari. n general putem identifica
entitiile n mai multe moduri. De exemplu n locul entitii Locatari, am putea crea o entitate
Locatari cu atributele Nr_Mat i Nume, iar celelelte informaii n entitatea
ProprietateLocatari.
Exist cazuri cnd entitiile sunt greu de identificat, pentru c modul de prezentare a
viitorilor utilizatori necesit explicaii. Utilizatorii descriu aceste entiti, folosind sinonime i
omonime, ceea ce ngreuneaz identificarea entitilor. Sinonimele prin care se descrie aceai
entitate, se pot considera sinonime i la crearea modelului logic, evideniind aceste sinonime
ca diverse aliasuri ai entitiilor.
Documentarea tipurilor de entiti
Dup identificarea entitiilor, le dm cte un nume, iar aceste nume le vom evidenia
n dicionarul de date, mpreun cu explicaiile despre entiti, precum i posibilele aliasuri.
Pasul 1.2. Identificarea tipurilor de relaii
Obiectivul: Identificarea relaiilor importante dintre entiti.
Dup identificarea entitiilor, va trebui s identificm i relaiile importante dintre
aceste entiti. Relaiile se descriu printr-un verb al relaiei. De exemplu:
106

Exemple
Scrile sunt Locuite de Locatari
Furnizorii Provoac Cheltuieli

Descriei, printr-un verb al relaiei, relaia dintre student i facultate.
Descriei, printr-un verb al relaiei, relaia dintre student i note.

La identificarea relaiilor vom lua n considerare doar relaiile care ne intereseaz.
Degeaba exist i alte relaii care s se poat identificate, dac nu prezint importan pentru
problema noastr, atunci nu le lum n consideraie.
n cele mai multe din cazuri, relaiile sunt binare, adic se realizeaz ntrea exact dou
entiti. Exist i relaii mai complexe, care se realizeaz ntre mai multe entiti, sau relaii
recursive, care pune n relaie o singur entitate cu ea nsi.
Determinarea cardinalitii i a participrii la tipurile de relaii
Dup identificarea tipurilor de relaii, trebuie s determinm cardinalitatea lor, alegnd
dintre posibilitiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dac se
cunosc valori specifice ale cardinalitiilor, aceste valori se scriu la documentarea relaiilor. n
continuare determinm i participarea la relaie, care poate fii total, sau parial.

Care este cardinalitatea relaiei dintre student i facultate.
Care este cardinalitatea relaiei dintre student i note.

Documentarea tipurilor de relaii
Dup identificarea tipurilor de relaii, le denumim i le introducem n dicionarul de
date, mpreun cu cardinalitatea i participarea lor.
Utilizarea modelrii ER
Pentru vizualizarea sistemelor complicate, utilizm diagrama ER, pentru c este mult
mai uor de a cuprinde toate informaiile. V propunem ca s utilizai ntotdeauna diagrama
ER, pentru o mai bun vizualizare a datelor.
Pasul 1.3. Identificarea i asocierea de atribute la tipurile de entiti i tipurile de
relaii
Obiectivul: Asocierea de atribute la tipurile de entiti i la tipurile de relaii.
Urmtorul pas n metodologie este identificarea atributelor. Aceste atribute se
identific n aceeai mod ca i entitiile. Pentru o mai uoar identificare, trebuie s lum
entitiile i relaiile ra rnd i s ne punem urmtoarea ntrebare: Ce informaii deinem
despre aceast ? Rspunsul la aceast ntrebare ne va da atributele cutate.
Atribute simple sau compuse
Este important s notm dac un atribut este simplu sau compus. Conform acestei
informaii va trebui s lum decizii referitoare la acel atribut. Dac un atribut este compus,
atunci putem opta pentru descompunerea sa, dac este necesar prelucrarea separat a detelor
compuse, sau putem s-l lsm compus n caz contrar.

Exemple
De exemplu, atributul Adres conine informaiile (Nr_Bloc, Scara, Etaj,
Apartament). Noi va trebui s prelucrm aceste informaii separat, deci vom
descompune acest atribut n cele patru atribute simple.

Descompunei atributul adres din tabela student.
107

Putem avea cazuri n care atributele simple s le compunem.

Exemple
De exemplu n cazul atributelor Nume_Familie i Prenume, neavnd nevoie de
aceste informaii separat, le vom compune n atributul Nume.

Ce putei spune despre atributul nume din tabela student.

Atribute derivate (calculate)
Sunt acele atribute, care se pot calcula din alte atribute existente n baza de date.

Exemple
De exemplu numrul locatarilor de pe o scar se poate numra n tipul de entitate
Locatari. Deci acest atribut este atribut derivat.

Ce putei spune despre atributul vrsta din tabela student.

n general aceste atribute nu trebuie incluse n modelul de date, pentru c n cazul n
care se modific atributul din care se calculeaz atributul derivat, trebuie s se modifice i
acesta. n cazul n care nu se modific, baza de date devine inconsistent. De aceea este
important de a meniona dac un atribut este sau nu derivat.
Dac identificm un atribut care s nu-l putem asocia nici unei entiti sau relaii, ne
ntoarcem la paii anteriori, identificnd noua relaie sau entitate la care s asociem atributul
respectiv.
n cazul n care putem asocia acelai atribut la mai multe entiti, atunci va trebui s
decidem dac generalizm sau nu aceste entiti, proces care este descris la pasul 1.6.
Documentarea atributelor
Dup identificarea atributelor, le asociem un nume, i le nregistrm n dicionarul de
date, mpreun cu urmtoarele informaii:
- numele i descrierea atributului,
- toate aliasurile i sinonimele prin care este cunoscut atributul,
- tipul de date i lungimea,
- valorile iniiale ale atributelor (dac exist),
- dac atributul accept sau nu valoarea nul,
- dac atributul este sau nu compus, i dac este atunci atributele simple care l compun,
- dac atributul este sau nu derivat i atributul din care deriv,
- dac atributul accept sau nu mai multe valori.
Pasul 1.2. Determinarea domeniului atributelor
Obiectivul: Determinarea domeniului atributelor n modelul conceptual local.
Domeniul atributului este o mulime de valori pe care o poate lua. Pentru a controla n
totalitate domeniul atributelor, se poate evidenia urmtoarele:
- setul de valori admisibile pentru un atribut,
- operaiile admisibile asupra unui atribut,
108
- ce atribute se pot compara cu atributul respectiv, n combinaiile cu alte atribute,
- mrimea i formatul cmpului atributului.
Documentarea domeniilor atributelor
Actualizm dicionarul de date cu domeniul de definiie al fiecrui atribut.
Pasul 1.5. Determinarea atributelor care compun cheile candidat i primare
Obiectivul: Identificarea cheilor candidat pentru fiecare entitate i alegerea cheilor
primare n cazul n care sunt mai multe chei candidat.
Identificarea cheilor i selectarea cheilor primare
O cheie candidat este un atribut, sau un grup de atribute care identific unic fiecare
nregistrare din tipul de entitate. Putem identifica una, sau mai multe chei candidat. n acest
caz trebuie s alegem dintre ele o cheie primar. Cheile candidat care nu sunt primare, se vor
numi chei alternante. Pentru alegerea unei chei ca fiind cheie primar, vom ine cont de
urmtoarele:
- cheia candidat, care are un numr minim de atribute,
- cheia candidat, care i va schimba cel mai rar valoarea,
- cheia candidat, care este cel mai puin probabil s sufere modificri n viitor,
- cheia candidat, care este compus din cele mai puine caractere (n cazul atributelor de tip
caracter),
- cheia candidat, care este cel mai uor de folosit din punctul de vedere al utilizatorului.

Care ar fi cheile candidat ale tabelei student. Care va fi cheia principal.

Prin procesul de identificare a cheilor primare, deducem i dac o entitate este entitate
tare, sau entitate slab. Dac reuim s identificm o cheie primar, atunci entitatea este
tare, altfel este slab. O entitate slab nu poate exista fr o entitate tare, care s-i fie
printe. Cheia primar a entitii slabe este derivat parial sau total din cheia primar a
entitii tari.
Documentarea cheilor primare i alternante
nscriem cheile primare i pe cele alternante n dicionarul de date.
Pasul 1.6. Specializarea/generalizarea tipurilor de entiti (pas opional)
Obiectivul: Identificarea entitiilor subclas respectiv superclas, ntre entitiile
apropiate.
n acest pas putem opta pentru a continua modelarea ER, folosind procesul de
generalizare sau specializare. Dac alegem procesul de specializare, vom ncerca s definim
una, sau mai multe subclase ale entitii respective. Dac ns alegem procesul de
generalizare, vom cuta superclase pentru acea entitate.
Un exemplu pentru procesul de generalizare ar fii entitiile ef_de_scar i Familii.
Ambele entiti au atribuite urmtoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament i
Nume. Pe lng aceste atribute, entitatea ef_de_scar mai are asociate atributul
Data_intrare_func; iar entitatea Familii, atributele Nr_pers, Nr_pers_prezente i Nr_chei.
Deci, cele dou entiti avnd atribute n comun, le putem generaliza n entitatea Locatari,
care va conine atributele comune, i entitile ef_de_scar i Familii, coninnd doar
atributele diferite - particularizrile fa de superclas.
Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptual a
vederilor utilizatorilor despre ntreprindere.
n momentul acesta suntem n msur s prezentm o giagram complet a modelului
bazat pe vederile utilizatorilor despre ntreprindere.
109
Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului
Obiectivul: Verificarea modelului conceptual local cu ajutorul utilizatorului, pentru a
vedea dac modelul este o reprezentare adevrat a vederii utilizatorului despre ntreprindere.

nainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest
model include diagrama ER i documentaia anexat. n cazul n care apare orice fel de
anomalie, repetm procesul de mai nainte i remediem problema.

S ne reamintim...
- Pasul 1.1. Identificarea tipurilor de entiti.
- Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i
tipurile de relaii.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate i
primare.
- Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.

M5.U5.1. Rezumat
O metodologie este o cale de a apllica n proiectare metoda divide et
impera. Separarea n pai asigur divizarea problemei iniiale n probleme mai
mici i deci mai uor de rezolvat, iar partea de impera este rezolvat de
succesiunea strict a pailor i de faze speciale cum ar fi, n cazul nostru,
realizarea modelului logic global.
Paii mari ai metodologiei pe care o prezentm aici sunt proiectarea logic
i proiectarea fizic.
Problema proiectrii bazelor de date este complicat i de faptul c, de cele mai
multe ori, procesul de proiectare ncepe cu cerine foarte generale i imprecis formulate.
Prin contrast, proiectul rezultat trebuie s conin schema bazei de date precis definit.
nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce
rezultate se ateapt utilizatorii poteniali s obin de la b aza de date respectiv i ce
informaii primare sunt disponibile pentru aceasta.
n aceast faz de colectare i analiz a cerinelor, se desfoar urmtoarele
activiti:
Identificarea grupurilor de utilizatori poteniali si a aplicaiilor.
Revederea documentaiei existente privind aplicaiile dorite
i interviuri.
110

5.1.1. Realizai paii de proiectare conceptuala local pentru subsistemul
didactic din facultate.

Toate aceste activiti ofer informaii slab(diagramele de organizare a
ntreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate n controlul activitii respective, etc.), pentru a se decide dac aceste
aspecte influeneaz cerinele bazei de date.
- Pasul 1.1. Identificarea tipurilor de entiti .
- Pasul 1.3. Identificarea i atribuirea de atribute la tipurile de entiti i
tipurile de relaii.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate i
primare.
- Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.

111
Unitatea de nvare U5.2 Proiectarea logic.

M5U2 Introducere
n faza de proiectare logic a unei baze de date se realizeaz schema conceptual
global i schemele conceptuale (vederile) externe pentru sistemul SGBD ales, pornind de
la schema conceptual i schemele externe de nivel nalt independen te de SGBD, proiectate
n faza precedent.

M5.U2. Obiectivele unitii de nvare
realizeze proiectul logic local
realizeze proiectul logic global

Durata medie de parcurgere acestei uniti de nvare este de 3 ore.

Aceast faz de proiectare logic poate fi realizat n dou subfaze:
Transpunerea schemei conceptuale n modelul de date al sistemului SGBD ales, dar
independent de sistemul de gestiune propriu-zis. n cazul modelului relaional,
transpunerea se face prin corespondena dintre elementele schemei conceptuale de
nivel nalt reprezentat prin diagrama Entitate-Asociere (tipuri de entiti, atribute,
asocieri) i elementele modelului relaional (relaii, atribute, referine). Se obine un
proiect logic dependent de modelul de date, dar independent de sistem, n aceast
subfaz se face i analiza normalizrii relaiilor, normalizarea fiecrei relaii pn la
nivelul adecvat i documentarea tuturor dependenelor de date care nu
sunt determinate de chei ale relaiilor (necesar pentru proiectarea procedurilor de
verificare i impunere a dependenelor respective).
Rafinarea schemei conceptuale i a schemelor externe obinute anterior, astfel
nct s se utilizeze unele (sau ct mai multe) din facilitile oferite de sistemul
SGBD ales (modul de generare a cheilor primare, definirea constrngerilor, etc.).
Rezultatul acestei faze de proiectare l constituie schema conceptual i schemele externe
ale bazei de date, dependente de sistemul SGBD ales i de modelul de date al acestuia.
Pasul 2. Crearea i validarea modelului logic local
Obiectivul: Crearea unui model logic local bazat pe modelul conceptual al
utilizatorilor asupra ntreprinderii i validarea ei prin procesul de normalizare i prin tehnica
tranzaciilor cerute.
n acest pas verificm modelul conceptual creat n pasul anterior i eliminm din el
structurile care sunt dificil de realizat ntr-un SGBD. Dac la sfritul acestui proces modelul
ete alterat, vom corecta aceste probleme i ne vom referi n continuare la modelul rezultat, ca
fiind modelul logic local. Vom valida modelul logic prin procesul de normalizare i a
tranzaciilor.
Activitile din acest pas sunt:
- Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
- Pasul 2.2. Crearea relaiilor pentru modelul logic local.
112
- Pasul 2.3. Validarea modelului, utiliznd normalizarea.
- Pasul 2.2. Validarea modelului din nou, utiliznd tranzaciile.
- Pasul 2.5. Desenarea diagramei ER.
- Pasul 2.6. Definirea regulilor de integritate ale bazei de date.
- Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Pasul 2.1. Proiectarea modelului conceptual local pe modelul logic local
Obiectivul: Verificarea modelului conceptual local pentru eliminarea structurilor care
se pot implementa greu ntr-un SGBD i proiectarea modelului rezultat la modelul logic local.
n pasul nti am pregtit un model conceptual bazat pe informaiile date de utilizator.
Acest model trebuie prelucrat, pentru a putea fi uor de prelucrat de sistemul de gestiune a
bazelor de date. Obiectivele acestui pas sunt:
(1) Eliminarea relaiilor M:N.
(2) Eliminarea relaiilor complexe.
(3) Eliminarea relaiilor recursive.
(4) Eliminarea relaiilor cu atribute.
(5) Reexaminarea relaiilor 1:1.
(6) Eliminarea relaiilor redundante.
(1) Eliminarea relaiilor multe-la-multe
Dac n modelul de date apar relaii de tipul multe-la-multe (M:N), trebuie
descompuse n dou relaii unu-la-multe (1:M) prin adugarea unei noi entiti suplimentare.

Exemple
De exemplu, pot exista mai multe cheltuieli pentru o scar, dar i o cheltuial
(factur) poate s se refere la mai multe scri. Deci relaia dintre entitatea Scri i
entitatea Cheltuieli este de M:N, ceea de este evideniat n figur.

Sunt platite de
Scari
Nr_Bloc
Scara
Lift
Cheltuieli
Nr_Crt
Cod_Cheltuiala (FK)
Cod_Furnizor (FK)
Nr_factura
Data_factura
Valoare_factura

Se calculeaza
Au cheltuieli
Pe scari
Scara (FK)
Nr_Crt (FK)
Nr_Bloc (FK)
Cheltuieli
Nr_Crt
Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura
Scari
Nr_Bloc
Scara
Lift

a). Relaie de tipul N:M. (b). Relaie transfornamt n dou relaii 1:M.
113

Desfiinai relaia dintre student i note.

Aceast relaie se poate elimina, prin crearea unui tip de entitate suplimentar,
care s fac legtura dintre scri i cheltuieli. Diagrama acestor relaii se vede n figura b).
Notm, c tipul de entitate nou creat - Pe_scri - este tip de entitate slab, pentru c
depinde att de tipul de entitate Scri, ct i de tipul de entitate Cheltuieli.
(2) Eliminarea relaiilor complexe
O relaie complex este o relaie ntre mai mult de cou tipuri de entiti. Dac n
modelul conceptual apar relaii complexe, acestea trebuie eliminate. Se pot elimina prin
crearea unui nou tip de entitate, care s fie n relaie de tipul 1:M cu fiecare tip de entitate din
relatia iniial, partea cu M a relaiei fiind spre tipul de entitate nou creat.
(3) Eliminarea relaiilor recursive
Relaiile recursive sunt nite relaii particulare, prin care un tip de entitate este n
relaie cu el nsui. Dac apare o astfel de relaie n modelul conceptual, ea trebuie eliminat.
Eliminarea se poate rezolva prin crearea unei noi entiti unde s se evidenieze fiecare
entitate care este legat de entitatea din tipul de entitate iniial. n acest caz vom avea o relaie
de tipul 1:M ntre tipul de entitate iniial i tipul de entitate nou creat i o relaie de tipul 1:1
ntre tipul de entitate nou creat i tipul de entitate iniial.
(4) Eliminarea relaiilor cu atribute
Dac n modelul conceptual avem relaie cu atribute, putem descompune aceast
relaie, identificnd un nou tip de entitate n care s nregistrm atributele necesare.
(5) Reexaminarea relaiilor de tipul 1:1
n modelul conceptual putem avea entiti ntre care s avem relaie de tipul 1:1. Se
poate ntmpla ca aceste entiti s fie de fapt aceeai entitate cu nume diferite. Dac suntem
n acest caz, unim cele dou entiti, cheia primar devenind cheia primar al uneia dintre
entiti.
(6) Eliminarea relaiilor redundante
O relaie este redundant dac se poate ajunge de la un tip de entitate la alt tip de
entitate pe mai multe drumuri. V amintim c noi vrem s ajungem la un model minimal i
deci relaiile redundante nu sunt necesare. Decizia c o relaie este redundant trebuie s fie
precedat de o analiz amnunit a relaiilor care compun cele dou drumuri dintre cele dou
entiti, pentru c pot aprea situaii, cnd o relaie este aparent redundant, dar n realitate
este nevoie de ea.
n finalul acestui pas putem spune c am eliminat din modelul conceptual acele
structuri care sunt dificil de implementat i deci este mai corect ca n continuare s ne referim
la acest model ca fiind un model logic local de date.
Pasul 2.2. Crearea de relaii peste modelul logic local
Obiectivul: Crearea de relaii peste modelul logic.
Relaia pe care un tip de entitate o are cu alt tip de entitate este reprezentat prin
mecanismul cheie primar/cheie strin. Cheia strin pentru o entitate este reproducerea
cheii primare a altei entiti. Pentru a decide entitiile unde vom include copia cheii primare a
altei entiti, trebuie nainte s identificm entitile printe i fiu. Entitile printe se
refer la acele entiti ale cror chei primare se vor copia n entitile fiu.
Pentru descrierea relaiilor vom folosi un limbaj de definire a bazei de date (Database
Definition Language - DDL). n acest limbaj, specificm prima dat numele entitii, urmat de
atributele asociate ntre paranteze. Dup aceea identificm cheia primar i toate cheile
alternante, precum i/sau cheile strine.
114
Tipuri de entitai tari
Pentru tipurile de entiti tari n modelul logic crearea unei relaii include toate
atributele entitii. Pentru atributele compuse al unei entiti, vom include numai atributele
simple din compunerea atributului compus n descrierea entitii.

Exemple
De exemplu tipul de entitate Familii, prezentat n figur se descrie n urmtorul
mod.
Familii (Nr_mat, Nr_bloc, Scara, Etaj, Apartament, Nume, Nr_pers,
Nr_pers_prezente, Nr_chei)
Cheie primar: Nr_mat

Descriei relaia dintre student i catalog.

Tipurile de entiti slabe
Descrierea tipurilor de entiti slabe se face la fel ca i tipurile de entiti tari, cu o
completare i anume, evidenierea cheii strine.

Exemple
De exemplu descrierea tipului de entitate de mai sus se descrie astfel:
Pli (Data, Nr_mat, Valoare, Restan)
Cheie primar: Data, Nr_mat
Cheie strin: Nr_mat se refer la Familii(Nr_mat)

Descriei tabela catalog.

Menionm c n cazul acesta cheia strin este i n compunerea chei primare. Deci
nainte de introducerea cheii strine, cheia primar nu identifica unic o entitate. La terminarea
acestui pas, putem identifica cheile prinare pentru toate tipurile de entiti din modelul logic.
Tipurile de relaii binare de tipul unu-la-unu (1:1)
Pentru fiecare tip de relaie binar de tipul 1:1 ntre dou tipuri de entitate E1 i E2
gsim o copie a cheii primare a tipului de entitate E1 n compunerea tipului de entitate E2, sub
denumirea de cheie strin. Identificarea tipului de entitate printe i a tipului de entitate
fiu depinde de participarea entitilor la relaie. Tipul de entitate care particip parial la
relaie este desemnat ca fiind printe iar cel cu participare total fiu. Dac ambele tipuri
de entitate particip parial sau total la relaie, atunci tipurile de entiti se pot evidenia ca
fiind printe sau fiu arbitrar. n cazul n care participarea este total, putem ncerca s
combinm cele dou tipuri de entiti ntr-una singur. Aceast compunere poate s fie
posibil n cazul n care nici unul dintre cele dou tipuri de entiti nu mai ia parte la alt
relaie.
Tipurile de relaii binare de tipul unu-la-multe 1:M
Pentru toate relaiile 1:M ntre dou entiti E1 i E2 n modelul logic de date, vom
avea copia cheii primare a entitii E1 n compunerea entitii E2. Totdeauna entitatea de
partea unu a relaiei este considerat entitate printe, iar cealalt entitate fiu.
Atributele cu mai multe valori
115
Pentru ficarea atribut A care permite mai multe valori din entitatea E1 n modelul
logic de date, crem o nou relaie care va conine atributul A mpreun cu cheia primar a
entitii E1 pe post de cheie strin. Cheia primar a noii relaii va fi atributul A, sau dac este
necesar, compunerea ei cu cheia primar al lui E1.
Documentarea relaiilor i a atributelor din cheile strine
Actualizm dicionarul de date, ntroducnd fiacare atribut nou introdus n
compunerea unei chei la acest pas.

Pasul 2.3. Validarea, utiliznd normalizarea

Obiectivul: Validarea modelului logic, utiliznd tehnica normalizrii.
Examinm procesul de normalizare dup cum am descris n capitolul 5 Prin
normalizare trebuie s demonstrm c modelul creat este consistent, conine redundan
minimal i are stabilitate maxim.
Normalizarea este procesul prin care se decide dac atributele pot sau nu s rmn
npreun. Conceptul de baz a teoriei relaiilor este c atributele sunt grupate mpreun pentru
c exist o relaie logic ntre ele. Cteodat baza de date nu este cea mai eficient. Acesta se
argumenteaz prin urmtoarele:
- Proiectarea normalizat organizeaz datele n funcie de dependenele funcionale. Deci
acest proces este situat undeva ntre proiectarea conceptual i cea fizic.
- Proiectul logic nu este un proiect final. El ajut priectantul s neleag natura datelor n
ntreprindere. Proiectul fizic poate fi diferit. Exist posibilitatea ca unele tipuri de entiti
s se denormalizeze. Totui normalizarea nu este un timp pierdut.
- Proiectul normalizat este robust i independent de anomaliile de actualizare prezentate
nunitatea de nvare anterioar..
- Calculatoarele moderne au mult mai mult putere de calcul, ca cele de acum civa ani.
Din aceast cauz, cteodat este mai convenabil implementarea unei baze de date cu
puin redundan, dect suportarea cheltuielilor pentru proceduril e adiionale.
- Normalizarea produce o baz de date care va fi uor extensibil n viitor.
Pasul 2.2. Validarea modelului prin tranzacii
Obiectivul: Verificarea ca modelul de date suporte toate tranzaciile cerute de
utilizator.
n acest pas se valideaz baza de date prin verificarea tranzaciilor ce se cer de catre
utilizator. Lund n considerare tipurile de entiti, relaiile, cheile primare i strine, ncercm
s rezolvm manual cerinele utilizatorilor. Dac reuim s rezolvm fiecare tranzacie cerut,
atuci nseamn c modelul creat este valid. Dac nu putem rezolva o tranzacie, atunci este
foarte posibil s fi omis un atribut, o relaie, sau o entitate din modelul de date.
Trebuie s examinm dac baza de date suport tranzaciile cerute. Mai nti ar fi prin
rezolvarea de tranzacii.

Exemple
De exemplu s lum relaia dintre Furnizori i Cheltuieli exemplificat n figur

116

Provoaca
Furnizori
Cod_Furnizor
Denumire
Cod_fiscal (AK1)
Cont
Banca
Strada
Nr
Bl
Sc
Ap
Localitate
Judet
Cheltuieli
Nr_Crt
Cod_Furnizor (FK)
Cod_cheltuiala
Nr_factura
Data_factura
Valoare_factura

Dar mai bine se descriu tranzaciile prin fraze SQL.
Inserarea de detalii despre un nou furnizor.
Cheia primar al acestei entiti este Nr_furnizor. Deci prima dat verific dac
numrul introdus nu exist deja; dup care, n caz c nu exist acest cod, inserez detaliile
despre furnizor. Dac exist deja codul, nu admit inserarea. Pot verifica i existena codului
fiscal, care pentru aceast entitate este cheie alternant.
tergerea detaliilor despre un furnizor
Se caut codul furnizorului de ters. Dac exist se terge furnizorul, actualizndu-se
i cheia strin n entitatea Cheltuieli. Dac nu exist codul cerut, atunci apare un mesaj de
eroare i nu este ters nici un furnizor.
A doua modalitate de verificare trebuie folosit n cazul n care avem entiti care nu
iau parte direct la nici o tranzacie. Pentru verificarea acestor entiti, vom verifica nite
interogri pregtie special.
Obiectivul: Desenarea diagramei Entity-Relationship, care este reprezentarea logic a
vederilor utilizatorilor aspra ntreprinderii.
Pasul 2.6. Identificarea regulilor de integritate.
Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra
ntreprinderii.
Regulile de integritate sunt importante pentru a proteja baza de date mpotriva
posibilelor inconsistene. Dac este necesar, putem produce un proiect fizic de baz de date,
pentru a putea vedea mai uor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
- necesitatea datelor,
- reguli asupra domeniului atributelor,
- integritatea entitilor,
- integritatea referinelor,
- regulile ntreprinderii.
Necesitatea datelor
Exist atribute care nu pot conine valoarea nul, ci trebuie s aib totdeauna o
valoare. De exemplu fiecare cheltuial nregistrat trebuie s aib asociat un furnizor al
serviciilor sau al obiectelor ce se pltesc prin acea cheltuial.
Aceste reguli deja le-am identificat, cnd am documentat atributele n pasul 1.3.
Exemplu de relaie
pentru validarea prin
tranzacii.

117
Reguli asupra domeniului atributelor.
Unele atribute au un domeniu de definiie bine definit. Aceste domenii trebuie
respectate. Domeniile de definiie au fost deja identificate cnd am documentat domeniile
atributelor n pasul 1.2.
Integritatea entitilor.
Cheia primar a entitilor nu poate lua valori nule. De exemplu fiecare furnizor
trebuie s aib un cod diferit de zero.
Aceste reguli au fost deja identificate, cnd am documentat cheile primare n pasul
1.5.
Integritatea referinelor
Cheia strina din tipul de entitate fiu face ligtura cu o entitate din tipul de entitate
printe. Deci, dac cheia strin conine o valoare, ea trebuie neaprat s se regseasc i n
tipul de entitate printe. De exemplu tipul de entitate Cheltuieli conine cheia strin
Cod_furnizor, care se refer la Furnizori(Cod_furnizor). Dac aceast cheie nu este nul,
atunci trebuie s gsim un furnizor care s aib acel cod.
Prima ntrebare pe care trebuie s ne-o ponem este: Poate fii cheia strin nul? n
cazul exemplului nostru asta ar nsemna c exist cheltuieli care nu se prtesc nimnui. Aceste
cazuri nu sunt admise de lege, deci nu putem avea valoare nul n cheia strin din tipul de
entitate Cheltuieli.
n general dac pariciparea tipului de entitate fiu este total, atunci nu putem avea
valoare nul n cheia strin. n caz contrar putem avea valoare nul.
Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaia de mai
sus dintre Furnizori i Cheltuieli, care este de tipul 1:M. Considerm urmtoarele cazuri:
Cazul 1: Inserarea unei entiti n tipul de entitate fiu (Cheltuieli): Pentru a verifica
integritatea referinei, verificm dac atributele din componena cheii strine (Cod_furnizor)
sunt vide, sau s existe entitate n tipul de entitate printe care s aib valoare cheii primare
egal cu valoare cheii strine.
Cazul 2: tergerea unei entiti din tipul de entitate fiu (Cheltuieli): tergerea unei
entiti din tipul de entitate fiu nu creeaz probleme la integritatea referinelor.
Cazul 3: Actualizarea cheii strine n tipul de entitate fiu (Cheltuieli): Acest caz
este similar cazului 1.
Cazul 4: Stergerea unei entiti din tipul de entitate printe (Furnizori): Dac se
terge o entitate din tipul de entitate printe, integritatea referinelor se stric n cazul n
care exist entiti n tipul de entitate fiu, care se refer la entitatea tears. Exist strategii
severe de a rezolva integritatea referinelor:
- FR ACIUNE Neacceptarea tergerii unei entiti din tipul de entitate printe, dac
acesta este referit de o entitate din tipul de entitate fiu. n cazul nostru, nu se accept
tergerea furnizorului, dac el are o factur de ncasat.
- CASCAD Dac o entitate din tipul de entitate printe este tears, se terg automat
toate entitiile din tipurile de entiti fiu. Dac tipurile de entiti fiu au i ei la rndul lor
alte tipuri de entiti fiu, se va efectua tergerea n cascad n toate tipurile de entiti fiu,
pn la ultimul nivel. Cu alte cuvinte, dac se terge un furnizor, atunci automat se terge
fiacare factur pe carea are de ncasat acest furnizor.
- SETARE LA NUL Dac o entitate din tipul de entitate printe se terge, atunci se vor seta
la valoare nul toate cheile strine ai tipurilor de entiti fiu n cascad pn la ultimul
nivel. n exemplul nortru, dac se terge un furnizor, at unci se vor seta la valoare nul toate
referinele la acest furnizor n tipul de entitate Cheltuieli. Acesta nseamn c nu vom tii
ca anumite cheltuieli la ce furnizor trebuie pltite.
118
- SETARE IMPLICIT Este analog cazului de setare la nul, cu diferena c aici se
seteaz cheia strin la o valoare implicit n loc de valoare nul. n exemplul nostru putem
seta cheia strin din Cheltuieli la o valoare a cheii primare din Furnizori, care s conin
un furnizor predefinit - de exemplu cu numele de Furnizor ters.
- FR MODIFICARE n cazul tergerii unei entiti din tipul de antitate printe, nu se
actualizeaz deloc cheile strine din tipurile de entiti fiu.
Cazul 6: Modificarea cheii primare n tipul de entitate printe (Furnizori): Dac se
modific cheia primar din tipul de entitate printe, integritatea referinelor se stric. Pentru
meninerea integritii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este
folosirea cazului CASCAD.
Regulile ntreprinderii.
n final evideniem acele reguli care sunt date de realitatea ce se va modela n baza de
date.
Documentarea tuturor regulilor de integritate.
Trecem toate regulile de integritate n dicionarul de date.
Pasul 2.7. Verificarea modelului logic local cu ajutorul utilizatorului.
Obiectivul: Convingerea c modelul creat reprezint n totalitate realitatea care trebuie
modelat n baza de date.
La acest pas modelul local logic este clomplet i este bine documentat. nainte de a
trece la pasul 3, trebuie verificat modelul, s fie conform cu realitatea. n cazul n care se
gsesc diferene, ne vom rentoarce la paii anteriori i modificm cele necasare.

S ne reamintim...
Activitile proiectrii logice locale sunt:

Pasul 3. Crearea i validarea modelului global logic de date.
Obiectivul: Combinarea modelelor locale logice ntr-un model logic global care s
reprezinte ntreprinderea care este modelat.
A treia activitate major n proiectarea bazei de date logice este crearea modelului
logic global, prin compunerea tuturor modelelor locale. Dup combinarea modelelor locale,
trebuie validat modelul global prin tehnica de normalizare i dup aceea, prin tehnica
tranzaciilor. Acest proces utilizeaz aceleai tehnici pe care le-am descris la paii 2.3. i 2.2.
Acest proces este foarte important n proiectarea bazei de date, pentru c el
demonstreaz c reprezentarea ntreprinderii este independent de orice utilizator, funcie sau
aplicaie. Activitile din acest pas sunt:
- Pasul 3.1. Compunerea medelelor logice locale ntr-un model logic global.
- Pasul 3.2. Validarea modelului logic global.
- Pasul 3.3. Verificarea posibilitii de a completa baza de date n viitor.
119
- Pasul 3.2. Desenarea diagramei ER finale.
- Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.
Pasul 3.1. Compunerea modelelor logice locale ntr-un model logic global.
Obiectivul: Compunerea tuturor modelelor logice locale ntr-un model logic global al
ntreprinderii.
n cazul unui sistem mic, cu puine vederi ai utilizatorilor, este relativ uor de a
compune modelele logice locale. n cazul unui sistem mai mare ns, trebuie s urmm un
proces sistematic de realizare a modelului global. Paii acestui proces sunt urmtoarele:
(1) Verificarea numelor entitilor i a cheilor lor primare.
(2) Verificarea numelor relaiilor.
(3) Compunerea entitilor de pe view-urile locale.
(4) Includerea (fr compunere) a entitilor care apar pe doar una dintre view-uri.
(5) Compunerea relaiilor de pe view-urile locale.
(6) Includerea (fr compunere) a relailor care apar pe doar una dintre view-uri.
(7) Cutarea entitilor i a relailor care lipsesc (dac exist).
(8) Cutarea cheilor strine.
(9) Cutarea regulilor de integritate.
(10) Desenarea modelului logic global.
(11) Actualizarea documentaiei.
Cel mai uor de compus mai multe modele locale este compunerea succesiv a dou
cte dou dintre modele.
(1) Verificarea numelor entitilor i a cheilor lor primare.
Aceast verificare se face folosind i dicionarul creat n decursul pailor de dinainte.
Probleme apar doar atunci cnd:
- Dou entiti au acelai nume, dar sunt de fapt diferii.
- Dou entiti sunt aceleai, dar nu au aceleai nume.
Probabil va fi necesar analizarea atributelor antitilor, prntru a rezola aceast
problem. n particular, putem utiliza cheia primar i numele entitii, pentru a identifica
entitile echivalente.
(2) Verificarea numelor relaiilor.
Aceast activitate este asemntoare celei descrise la entiti.
(3) Compunerea entitilor de pe view-urile locale.
Examinm numele i atributele entitilor ca vor fi compuse. Activitile care se includ
n acest pas sunt:
- Compunerea entitilor cau au aceleai nume i aceleai chei primare.
- Compunerea entitilor care au aceleai nume, dar cu chei primare diferite.
- Compunerea entitilor care au nume diferite, cu chei primare egale sau diferite.
Compunerea entitilor care au aceleai nume i aceleai chei primare. n general
entitile cu aceleai chei primare reprezint lumea real, i deci pot fi compuse. Atributele
care apar n entitile de pe ambele view-uri, vor fi trecute doar o singur dat. Dac ntr-un
view apare un atribut compus, iar ntr-un alt view acelai atribut dar descompus n atribute
simple, atunci vom ntreba, dac se poate, utilizatorii pentru a decide asupra formei de
utilizare a atributului.
Compunerea entitilor care au aceleai nume, dar au chei primare diferite. n astfel
de situaii, cutm dou entiti care au aceleai nume i nu au aceleai chei primare, dar au
aceleai chei candidat. Cele dou entiti pot fi compuse, urmnd ca dup compunere s
alegem o cheie primar, restul rmnnd chei alternante.
120
Compunerea entitilor care nu au nume comune i nu au aceleai chei primare.
Aceste entiti se pot depista prin analiza atributelor celor dou entiti.
(4) Includerea (fr compunere) a entitilor care apar doar ntr-un view.
Pasul anterior identific toate entitile comune. Celelalte entiti, se vor include n
modelul logic global exact aa cum apar n view-ul respectiv.
(5) Compunerea relaiilor de pe modelele locale.
n acest pas analizm similitudinile dintre relaii de pe diferite modele locale. n
timpul compunerii relaiilor trebuie rezolvate i conflictele dintre relaii, ca i regulile de
cardinalitate i participare. Putem compune relaii care au aceleai nume i acelai scop, sau
acelai scop, dar nume diferite.
(6) Includerea (fr compunere) a relaiilor care apar doar pe un view.
Relaile care au rmas neincluse n modelul global dup pasul anterior, se includ n
modelul global fr modificare.
(7) Cutarea entitilor i relailor care lipsesc.
Este unul din cei mai grei pai din crearea modelului global. Trebuie cutate acele
entiti i relaii, care s-au omis la paii anteriori i n-au ajuns n modelul global.
(8) Cutarea cheilor strine.
n decursul pailor anterioare, s-au modificat entiti, chei primare i chei strine. n
acest pas verificm dac cheile strine sunt corecte n fiecare entitate fiu i efectum toate
modificrile necesare.
(9) Cutarea regulilor de integritate
Verificm dac regulile de integritate a modelului global nu sunt n conflict cu regulile
definite la modelele locale. Fiecare problem de acest gen se rezolv cu ajutorul utilizatorului
sistemului.
(10) Desenarea diagramei ER.
Acum desenm diagrama ER pentru modelul global de date.
(11) Actualizarea documentaiei.
Actualizm documentaia, ca s reflecte toate modificrile aduse n acest pas
modelului.
Pasul 3.2. Validarea modelului logic global.
Obiectivul: Validarea modelului global logic de date, folosind normalizarea, dup care
folosind tranzacile cerute.
Acest pas este schivalent cu paii 2.3. i 2.4., unde am validat modelul local de date.
Pasul 3.3. Verificarea posibilitilor de extindere a bazei de date n viitor.
Obiectivul: Determinarea ca dac modelul se acomodeaz uor la modificri orict de
mari ce pot intervenii n viitor.
Este important ca modelul creat s fie expansibil n viitor. Dac modelul nu are
aceast calitate, viaa lui poate fi scurt i pentru o mai mare modificare va trebui refcut de
la nceput.
Pasul 3.4. Desenarea diagramei Entity-Relationship finale.
Obiectivul: Desenarea unei diagrame ER, care s reprezinte modelul global de date al
ntreprinderii.
Pasul 3.5. Verificarea modelului global cu ajutorul utilizatorului.
Obiectivul: Verificarea c modelul global reprezint n totalitate realitatea.
n acest moment modelul global este complet i documentat. mpreun cu utilizatorul
sistemului se verific acest model i se aduc eventualele corecturi prin ntoarcerea la paii n
cauz.
121

S ne reamintim...
Activitile proiectrii logice globale sunt:

M5.U5.2. Rezumat
Activitile proiectrii logice locale sunt:
Activitile proiectrii logice globale sunt:

5.2.1 Facei proiectul logic local pentru subsistemul didactic al
facultii.

122
Unitatea de nvare U5.3 Proiectarea fizic.

M5U5.3 Introducere
Proiectarea fizic a bazei de date este procesul de alegere a structurilor de memorare
i de acces a fiierelor bazei de date, pentru a obine performane ct mai bune, pentru ct
mai multe din aplicaiile proiectate. De asemenea, n aceast faz, se sciu programele care
dau cereri, formulare i rapoarte.


aleag, n cunotin de cauz, SGBD-ul cel mai potrivit.
descrie corect structura fizic a bazei de date
proiecteze cereri
proiecteze formulare
proiecteze rapoarte

Fiecare SGBD ofer o varietate de opiuni de organizare a fiierelor i a modului de acces
la datele stocate: indexuri, gruparea nregistrrilor corelate n aceleai blocuri pe disc (clustering),
tabele de dispersie (hashing), etc.
Dup alegerea sistemului SGBD, n faza de proiectare fizic a bazei de date se aleg
structurile fiierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv, cele mai
potrivite cu cerinele de proiectare a sistemului de baze de date.
Ca parametri generali de alegere a opiunilor proiectului fizic al unei baze de date relaionale se
pot enumera:
Timpul de rspuns. Acesta este intervalul de timp dintre lansarea i execuie a unei tranzacii
i primirea rspunsului la acea tranzacie. Cea mai mare pondere n timpul de rspuns o are
execuia operaiilor n sistemul SGBD, dar exist i factori care nu se afl sub controlul
acestuia (viteza de operare a procesorului, dimensiunea memorie; principale, planificarea
sarcinilor de ctre sistemul de operare, timpi:
de comunicaie, etc.).
Utilizarea spaiului de memorare. Aceasta este dimensiunea spaiului pe disc utilizat de
fiierele bazei de date i de structurile de acces l date.
Capacitatea tranzacionala (transaction throughput). Acesta este numrul mediu de
tranzacii care pot fi prelucrate pe minut de ctre sistemul de baze de date, msurat n
momentele de vrf ale ncrcrii. Acesta este un parametru critic n multe aplicaii, n particular
n acele aplicaii n care exist un numr mare de utilizatori care acceseaz concurent baza
de date (aplicaii bancare, rezervri de bilete, etc.).
123
In mod obinuit, trebuie s fie specificate valorile medii i limitele n cazurile cele mai
defavorabile ale acestor parametri n cadrul cerinelor de performane ale sistemului. Pentru
compararea valorilor acestor parametri, corespunztoare diferitelor decizii de proiectare
fizic, se fac diferite evaluri analitice sau msurtori experimentale (prototipuri, simulri).
Pentru o schem conceptual dat exist o multitudine de alternative ale proiectului fizic
pentru un SGBD dat. 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 continuare se vor prezenta cteva aspecte ale analizei interogrilor i tranzaciilor
necesare pentru a stabili opiunile proiectului fizic al unei baze de date relaionale.
Analiza atributelor accesate de interogri i tranzacii trebuie s evidenieze:
Atributele de proiecie, atributele care sunt coninute n condiiile de interogare i atributele
comune a dou sau mai multe relaii pe care se execut jonciunile. Astfel de atribute sunt
candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare) care
s accelereze operaiile de interogare.
Atributele pe care sunt specificate condiii de selecie pentru operaii de tergere sau
actualizare. La fel ca mai sus, astfel de atribute sunt candidate pentru definirea unor
structuri suplimentare de acces (indexuri secundare).
Atributele ale cror valori se modific n cursul operaiilor de actualizare. Este
recomandabil ca pe astfel de atribute s nu se defineasc structuri suplimentare de acces
(indexuri secundare) deoarece ar trebui ca i acestea s fie actualizate la fiecare operaie de
actualizare a relaiilor.
Analiza frecvenei estimate de invocare a interogrilor i a tranzaciilor, mpreun cu listele
de atribute care intervin n interogri i tranzacii, permit obinerea unei situaii globale
privind frecvena estimat de accesare a atributelor relaiilor, n general, pentru volume mari de
prelucrri, se respect regula "80-20". Aceast regul stipuleaz c 80% din operaiile de
prelucrare sunt executate n 20% din interogrile i tranzaciile tuturor aplicaiilor
implementate. De aceea, n cazurile practice nu sunt necesare statistici exhaustive ale
frecvenelor de invocare a tuturor interogrilor i a tranzaciilor, ci este suficient s fie
determinate cele mai importante 20% dintre acestea.
Analiza constrngerilor de timp ale interogrilor trebuie s evidenieze care dintre interogri
i tranzacii trebuie s se termine ntr-un anumit interval de timp. De exemplu, o tranzacie
trebuie s se termine n mai puin de 5 secunde n 95% din cazuri i s nu depeasc niciodat
durata de 20 de secunde. Astfel de constrngeri pot fi folosite pentru a aduga prioriti
suplimentare atributelor candidate pentru indexare. Atributele de selecie utilizate de interogri
i tranzacii cu constrngeri de timp devin candidate cu mare prioritate pentru indexare.
Tot n faza de proiectare fizic se poate rafina procesul de normalizare a relaiilor, folosind
informaiile de frecven a invocrii interogrilor i tranzaciilor i constrngerile de timp
impuse unora dintre acestea, n general, pentru obinerea unor timpi de rspuns mai mici
pentru unele interogri, se efectueaz o denormalizare a unor relaii, adic se combin dou
sau mai multe relaii existente ntr-o singur relaie cu un grad de normalizare mai redus, n care
apar, bineneles, date redundante i sunt posibile anomalii de actualizare. Odat cu
denormalizarea unor relaii trebuie s se prevad i procedurile necesare (care depind de
SGBD) pentru verificarea datelor i evitarea anomaliilor.
Alegerea sistemului de gestiune al bazei de date rebuie s in cont de:
Definirea datelor
Gestiunea cheilor primare Specificarea cheilor strine Tipuri de date disponibile
Extensibilitatea tipurilor de date Specificarea domeniilor Uurina restructurrii Mecanism de
tabele derivate Controlul integritii Dicionar de date Independena datelor Tipul de model de
date utilizat
Accesibilitate
124
Suport pentru standardele SQL Interfa cu 3GL Muli utilizator Securitate:
controlul accesului
mecanism de autorizare
Utilitare
Msurarea performanei Acordare (run/ng)/optimizare Faciliti de ncrcare/descrcare Suport
pentru administrarea BD
Dezvoltare
Instrumente 4GL
Instrumente CASE
Faciliti vizuale
Proceduri de stocare, declanatoare
Instrumente de dezvoltare Web
Controlul tranzaciilor
Rutine de salvare i restaurare Puncte de salvare intermediare Suport pentru jurnalizare
Granularitatea accesului simultan Strategia de rezolvare a interblocajelor Procesare paralel a
interogrilor
Definirea fizic
Structuri fizice disponibile
ntreinerea structurii de fiiere
Uurina reorganizrii
Indexare
Atribute/nregistrri de mrime variabil
Compresia datelor
Rutine de criptare
Cerine de memorie
Alte faciliti/opiuni
Evolutivitate
Stabilitatea furnizorului
Baza de utilizatori
Pregtire i suport pentru utilizatori
Documentare
Sistem de operare cerut
Cost
Help oniine
Standarde utilizate
Managementul versiunilor
Optimizare a interogrilor
Scalabilitate
Suport pentru instrumente OLAP
Interoperabilitate cu alte SGBD
Integrare Web
Utilitare de replicare
Faciliti de distribuire
Portabilitate
Cerine hardware
Suport pentru reea
Faciliti de orientare pe obiect
Arhitecturi pe dou, trei... straturi
Performan
Rata de tranzacii pe secund (minut)
125
Numr maxim de utilizatori simultani
Suport pentru XML

M5.U5.3. Rezumat
Pasul 8. Proiectarea fizic i implementarea bazei de date relaionale:
Translatarea modelului logic global n SGBD.
Pasul 8.1. Proiectarea relaiilor de baz n SGBD.
Pasul 8.2. Crearea regulilor de integritate n SGBD.
Pasul 9. Proiectarea i implementarea reprezentrii fizice.
Pasul 9.1. Analizarea tranzaciilor.
Pasul 9.2. Alegerea organizrii fiierelor.
Pasul 9.3. Alegerea indecsilor secundari.
Pasul 9.4. Introducerea unei redundane comntrolate.
Pasul 9.5. Estimarea spaiului pe disc.
Pasul 10. Proiectarea i implementarea unui mecanism de securit ate.
Pasul 10.1. Crearea view-urilor pentru utilizatori.
Pasul 10.2. Proiectarea regulilor de acces la baza de date.
Pasul 11. Verificarea sistemului operaional.
Alegerea sistemului de gestiune al bazei de date rebuie s in cont de
calitile SGBD-ului legatede Definirea datelor, Accesibilitate, Utilitare,
Dezvoltare, Definirea fizic i Alte faciliti/opiuni

5.3.1 Realizai, n ACCESS, proiectul fizic al subsistemului didactic al facultii.

126
Unitatea de nvare U5.4 Tranzacii i concuren

M5 U5.4 Introducere
O tranzacie (transaction) este o unitate logic de prelucrare indivizibil
(atomic) a datelor unei baze de date prin care se asigur consist ena acesteia.
n principiu, orice execuie a unui program care acceseaz o baz de date poate fi
considerat o tranzacie, dac baza de date este ntr -o stare consistent att nainte ct i
dup execuie. O'tranzacie trebuie s asigure consistena bazei de date indiferent dac a
fost executat individual sau concurent cu alte tranzacii precum i n condiiile n care au
aprut defecte ale sistemului hardware n cursul execuiei tranzaciei.

construiasc tranzacii corecte

Tranzacia este o aciune sau o serie de aciuni, executate de un singur utilizator sau un
program, care acceseaz sau schimb coninutul bazei de date.
Tranzacia este o unitate logic de lucru a bazei de date. Nu exist reguli de stabilire
automat a acestei uniti. Pentru a demonstra acest concept o s dm urmtoarele exemple.
Fie schemele:
Personal = (nrmat, nume, adres, salariu)
Proprietate = (nrprop, strad, ora, tip, nrmat)
care leag proprietatea de o persoan prin nrmat printr -o relaie de cardinalitate n la 1,
Putem avea urmtoarele tranzacii:

Exemple 5.4.1
cit (nrmat = x, salariu)
salariu = salariu * 1,1
scrie (nrmat = x, salariu)

care mrete salariul cu 10%

127

Exemple 5.4.2
cit (nrmat =x )
terge (nrmat = x )
pentru toate nregistrrile din Proprietate
begin
cit ( nrprop, nrmat)
dac (nrmat = x ) atunci
terge (nrprop)
end

care terge persoana x i toate proprietile ei

O tranzacie trebuie s transforme ntotdeauna baza de date dintr-o stare consistent
ntr-o alt stare tot consistent.
O tranzacie se poate termina n dou moduri. Dac tranzacia s-a terminat cu succes,
atunci spunem c tranzacia a fcut commit i baza de date a trecut n noua stare consistent.
Dac tranzacia nu s-a terminat cu succes atunci, ea este ntrerupt i, n acest caz , baza de
date trebuie s fie readus n starea consistent n care era nainte s nceap tranzacia.
Spunem, n acest caz, c tranzacia face roll back este derulat napoi. O tranzacie care a
fcut commit nu mai poate fi ntrerupt, dar o tranzacie ntrerupt poate fi reluat mai trziu
i atunci s-ar putea s se termine cu succes.
Un SGBD trebuie s aib posibilitatea de a defini i mnui tranzacii.
Gsim astfel cuvintele cheie cu semnificaie imediat BEGIN TRANSACTION, COMMIT,
ROLLBACK.

Proprietile tranzaciilor.
Dei nu avem reguli automate pentru construcia tranzaciilor ele trebuie s respecte
proprietile ACID.
- Atomicitate este proprietatea totul sau nimic. O tranzacie este o unitate indivizibil
care se execut n ntregime sau deloc.
- Consisten o tranzacie trebuie s transforme baza de date dintr-o form consistent
ntr-o alt form tot consistent.
- Independen o tranzacie se execut inependent de oricare alta, adic efectele
pariale ale unei tranzacii incomplete nu trebuie s influeneze o alt tranzacie.
- Durabilitate efectele unei tranzacii terminat cu succes sunt definitiv nregistrate n
baza de date i nu se mai pot pierde n tranzaciile ntrerupte ulterior.
Dac fiecare tranzacie lucreaz pe rnd, se pierde timp cnd calculatorul st s atepte
terminarea unei operaii de intrare/ieire, sau n timpul altei ntreruperi. Pe de alt parte,
dac lsm s lucreze deodat, fiecare n timpul lsat liber de cel din nainte, zicem c
avem tranzacii concurente. Concurena va mri randamentul timpului de lucru al
calculatorului dar ea trebuie controlat pentru c altfel poate da natere la inconsisten.
Prezentm n continuare, trei exemple n care artm cum se poate pierde cinsistena.
n primul exemplu tranzacia T
1
citete contul lui x (bal
x
) i scade 10 din cont.
Tranzacia T
2
x
) i adun 100 la cont. Pornind cu un cont de 100,
evident c dac se executa mai nti prima tranzacie i apoi a doua contul lui x ar fi fost
100-10+100=190. n cealalt ordine am fi avut 100+100-10=190 aceeai valoare. S
considerm urmtorul plan de tranzacii.
128
Un plan de tranzacii este o secven posibil n timp a modului de execuie a
tranzaciilor. Putem observa, n timpii nscrii n stnga, cum evolueaz contul din ultima
coloan.

Exemple 5.4.3
Time

T
1
T
2
bal
x
A

t
1
begin_transaction 100
A

t
2
begin_transaction cit(bal
x
) 100
A

t
3
cit(bal
x
) bal
x
= bal
x
+ 10 100
A

t
4
bal
x
= bal
x
- 10 scrie(bal
x
) 200
A

t
5
scrie(bal
x
) commit 90
A

t
6
commit 90

Problema se numete problema pierderii actualizrii.
Problema dependenei de o tranzacie neterminat apare cnd o tranzacie este
lsats vad rezultatele intermediare alei alte tranzacii nainte ca ea s fac commit.
Aceleai tranzacii ca n figura precedent se desfoar acum dup un alt plan.

Exemple 5.4.4
Time

T
3
T
4
bal
x
A

t
1
A

t
2
cit(bal
x
) 100
A

t
3
bal
x
= bal
x
+ 10 100
A

t
4
begin_transaction scrie(bal
x
) 200
A

t
5
cit(bal
x
) 200
A

t
6
bal
x
= bal
x
- 10 rollback 100
A

t
7
scrie(bal
x
) 190
A

t
8
commit 190

Rezultatul este 190, ai putea spune c este bun, dar inei cont c tranzacia 4 a fost ntrerupt
i, cnd se va relua, va mai mri cu 100 contul ceea ce va deveni incorect.
Chiar i cnd unele tranzacii numai citesc baza de date se pot ntmpla neplceri.
Aceast problem este problema analizei inconsistente sau problema citirii murdare.
De exemplu tranzaciile T
5
i T
6
executate serial, adic una dup alta, ar trebui s dea
rezultatele:
T
5
T
6
bal
x
=100-10=90, bal
z
=25+10=35, sum=90+50+35+175
sau T
6
T
5
sum=100+50+25=175, bal
x
=100-10=90, bal
z
=25+10=35
i putem vedea n figura urmtoare ce se poate ntmpla ncazul concurenei libere,
necontrolate:

129

Exemple 4.4.5
Time

T
5
T
6
bal
x
bal
y
bal
z
sum
A

t
1
begin_transaction 100 50 25
A

t
2
begin_transaction sum = 0 100 50 25 0
A

t
3
cit(bal
x
) cit(bal
x
) 100 50 25 0
A

t
4
bal
x
= bal
x
-
10
sum = sum +
bal
x

100 50 25 100
A

t
5
scrie(bal
x
) cit(bal
y
) 90 50 25 100
A

t
6
cit(bal
z
) sum = sum +
bal
y

90 50 25 150
A

t
7
bal
z
= bal
z
+
10
90 50 25 150
A

t
8
scrie(bal
z
) 90 50 35 150
A

t
9
commit cit(bal
z
) 90 50 35 150
A

t
10
sum = sum +
bal
z

90 50 35 185
A

t
11
commit 90 50 35 185

Nu putem, deci, lsa concurena necontrolat, dar nici nu este profitabil s o
desfiinm de tot. Spunem c un plan de tranzacii este serial cnd tranzaciile se execut una
dup alta fr a intercala operaii din alt tranzacie. Spunem c un plan de tranzacii este
neserial cnd tranzaciile snt concurente , adic ntre operaiile unei tranzacii se intercaleaz
operaiile alteia. Vom spune c un plan de tranzacii este corect atunci cnd el are ca rezultat
acelai cu unul executat serial; acesta se va numi serializabil. Avei deja exemple de planuri
neserializabile.
130

M5.U5.4. Rezumat
Tranzacia este o aciune sau o serie de aciuni, executate de un singur utilizator
sau un program, care acceseaz sau schimb coninutul bazei de date.
Tranzaciile trebuie s respecte proprietile ACID.
Atomicitate este proprietatea totul sau nimic. O tranzacie este o
unitate indivizibil care se execut n ntregime sau deloc.
Consisten o tranzacie trebuie s transforme baza de date dintr-
o form consistent ntr-o alt form tot consistent.
Independen o tranzacie se execut inependent de oricare alta,
adic efectele pariale ale unei tranzacii incomplete nu trebuie s
influeneze o alt tranzacie.
Durabilitate efectele unei tranzacii terminat cu succes sunt
definitiv nregistrate n baza de date i nu se mai pot pierde n
tranzaciile ntrerupte ulterior.
Problemele concurenei fr control sunt:
problema pierderii actualizrii.
problema dependenei de o tranzacie neterminat
problema analizei inconsistente sau problema citirii murdare.
Spunem c un plan de tranzacii este serial cnd tranzaciile se execut una
dup alta fr a intercala operaii din alt tranzacie. Spunem c un plan de
tranzacii este neserial cnd tranzaciile snt concurente , adic ntre operaiile
unei tranzacii se intercaleaz operaiile alteia. Vom spune c un plan de tranzacii
este corect atunci cnd el are ca rezultat acelai cu unul executat serial; acesta se
va numi serializabil.

M5.U5.4 Test de autoevaluare a cunotinelor
5.4.1 Dai exemple de pierdere a consistenei.

131

Unitatea de nvare U5.5 Metode de control al concurenei.

M5U5.5 Introducere
Am vzut c problemele apar atunci cnd o tranzacie vede (citete) sau scrie
ntr-un moment nepotrivit. Ideile de a controla concurena snt legate de a nu lsa
pe cellalt (de a bloca) sau de a ine cont de momente (de a marca timpul).

aleag cea mai bun metod de control al concurenei


Ce nseamn s blocm ? Cnd o tranzacie blocheaz partajat (part_bloc) o anumit
unitate de memorie, o alt tranzacir nu mai poate s rescrie tot acolo, iar cnd o tranzacie
blocheaz exclusiv (ex_bloc) o alta nu mai poate nici s o citeasc.
Despre ce unitate de memorie este vorba? Aceasta este problema granularitii la
care se face blocajul. Blocajul se poate face la nivel de:
- ntreaga baz de date
- tabela(fiier)
- nregistrare (cel mai des)
- cmp din nregistrare
Mai spunem c avem granularitate dinamic atunci cnd SGBD-ul poate s schimbe
granularitatea n timpul unei tranzacii.
Cititorul poate s demonstreze singur pe un exemplu (vezi problema ) c numai
simpla blocare urmat cndva de deblocare (debloc) nu asigur serializabilitatea.
Serializabilitatea este asigurat dac se respect protocolul de blocare n dou faze.
Acesta const din mprirea tranzaciei n dou faze una de blocri i creteri de blocaje i a
doua de descreteri i deblocaje. Aceasta nseamn c dup ce s-a fcut prima deblocare nu se
mai pot face blocri.
Urmtoarele trei exemple reiau tranzaciile T
1
iT
2
din exemplul 5.4.1respectiv T
3
i
T
4
din exemplul 5.4.2 i T
5
i T
6
din exemplul 5.4.3 cu protocolul n dou faze i realizeaz
planuri serializabile.

132

Exemple 5.5.1
Time

T
1
T
2
bal
x
A

t
1
A

t
2
begin_transaction ex_bloc(bal
x
) 100
A

t
3
ex_bloc(bal
x
) cit(bal
x
) 100
A

t
4
ATEAPT bal
x
= bal
x
+100 100
A

t
5
ATEAPT scrie(bal
x
) 200
A

t
6
ATEAPT debloc(bal
x
) 200
A

t
7
cit(bal
x
) commit 200
A

t
8
bal
x
= bal
x
-10 200
A

t
9
scrie(bal
x
) 190
A

t
10
deblo c(bal
x
) 190
A

t
11
commit 190

Exemple 5.5.2
Time

T
3
T
4
bal
x
A

t
1
A

t
2
ex_bloc(bal
x
) 100
A

t
3
cit(bal
x
) 100
A

t
4
begin_transaction bal
x
= bal
x
+100 100
A

t
5
ex_bloc(bal
x
) scrie(bal
x
) 200
A

t
6
ATEAPT debloc(bal
x
) 100
A

t
7
ATEAPT rollback 100
A

t
8
cit(bal
x
) 100
A

t
9
bal
x
= bal
x
-10 100
A

t
10
scrie(bal
x
) 90
A

t
11
debloc(bal
x
) 90
A

t
12
commit 90

133

Exemple 5.5.3
Time

T
5
T
6
bal
x
bal
y
bal
z
sum
A

t
1
begin_transaction 100 50 25
A

t
2
begin_transaction sum = 0 100 50 25 0
A

t
3

ex_bloc(bal
x
)
100 50 25 0
A

t
4
cit(bal
x
) part_bloc(bal
x
) 100 50 25 0
A

t
5
bal
x
= bal
x
-
10
ATEAPT 100 50 25 0
A

t
6
scrie( bal
x
) ATEAPT 90 50 25 0
A

t
7

ex_bloc(bal
z
)
ATEAPT 90 50 25 0
A

t
8
cit(bal
z
) ATEAPT 90 50 25 0
A

t
9
bal
z
= bal
z
+
10
ATEAPT 90 50 25 0
A

t
10
scrie(bal
z
) ATEAPT 90 50 35 0
A

t
11
debloc(bal
x

, bal
z
)
ATEAPT 90 50 35 0
A

t
12
commit ATEAPT 90 50 35 0
A

t
13
cit(bal
x
) 90 50 35 0
A

t
14
sum = sum + bal
x
90 50 35 90
A

t
15
part_bloc(bal
y
) 90 50 35 90
A

t
16
cit(bal
y
) 90 50 35 90
A

t
17
sum = sum + bal
y
90 50 35 140
A

t
18
part_bloc(bal
z
) 90 50 35 140
A

t
19
cit(bal
z
) 90 50 35 140
A

t
20
sum = sum + bal
z
90 50 35 175
A

t
21

debloc(bal
x
,bal
y
,bal
z
)
90 50 35 175
A

t
22
commit 90 50 35 175

Protocolul de blocare n dou faze asigur serializanilitatea dar nu ne scutete de
probleme. Pezentm n cele dou exemple urmtoare rollback-ul n cascad i blocajul
ciclic.
Observai, n figura 9.7 la momentul t14 tranzacia T
7
face rollback (dintr-un motiv
extern) i, pentru c T
8
este dependent de T
7
care a citit o nregistrare care a fost
actualizat de T
7
, trebuie s fac i T
8
rollback, ceea ce pe urm se ntmpl i cu T
9
.

134

Exemple 5.5.4
Time

T
7
T
8
T
9
A

t
1
begin_transaction
A

t
2
ex_bloc(bal
x
)
A

t
3
cit(bal
x
)
A

t
4
part_bloc(bal
y
)
A

t
5
bal
x
= bal
y
+
bal
x

A

t
6
scrie(bal
x
)
A

t
7
debloc(bal
x
) begin_transaction
A

t
8
ex_bloc(bal
x
)
A

t
9
cit(bal
x
)
A

t
10
bal
x
= bal
x
+100
A

t
11
scrie(bal
x
)
A

t
12
debl oc(bal
x
)
A

t
13

A

t
14
rollback
A

t
15
rollback begin_transaction
A

t
16

part_bloc(bal
x
)
A

t
17

A

t
18
rollback

O alt problem este blocarea ciclic prezentat n exemplul urmtor. Cele
dou trnzacii T
10
i T
11
se blocheaz reciproc.

Exemple 5.5.5
Time

T
10
T
11

A

t
1
begin_transaction
A

t
2
ex_bloc(bal
x
) begin_transaction
A

t
3
cit(bal
x
) ex_bloc(bal
y
)
A

t
4
bal
x
= bal
x
-10 cit(bal
y
)
A

t
5
scrie(bal
x
) bal
y
= bal
y
+100
A

t
6
ex_bloc(bal
y
) scrie(bal
y
)
A

t
7
ATEAPT ex_bloc(bal
x
)
A

t
8
ATEAPT ATEAPT
A

t
9
ATEAPT ATEAPT
A

t
10
ATEAPT
A

t
11

Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de preceden care arat
dependena ntre tranzacii n felul urmtor:
- se creaz un nod pentru fiecare tranzacie
- se creaz o muchie direcionat Ti Tj dac tranzacia Ti ateapt s blocheze
o nregistrare care este deja blocat de Tj.
Pe acest graf se detecteaz un blocaj ciclic dac exist un circuit. Pentru figura 9.8 graful ar fi
urmtorul:
135
x
y

Exemple 5.5.6

O alt metod de a evita blocajul ciclic pstrnd serializabilitatea este protocolul cu
marcarea timpului (time stamp). Acest protocol ataeaz un timp (timpul real din calculator
sau un numr care se mrete autmat de cte ori este solicitat) fiecrei tranzacii (marc(T)) i
timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a unei nregistrri. Deci
fiecare tranzacie va avea o valoare de marcj i fiecare nregiistrare prelucrat va avea dou
marcaje; unul care spune ce marcaj a avut tranzacia care a citit-o (cit_marc) i cellalt care
spune ce marcaj a avut tranzacia care a scris-o (scri_marc).
Numai n urmtoarele trei situaii se pun probleme deosebite:
1. Tranzacia T cere s citeasc o nregistrare x care a fost deja actualizat de o tranzacie
cu scri_marc(x) > marc(T), adic o nregistrare scris de o tranzacie care a nceput
mai trziu. Ce ar rescrie ea ar putea da natere la inconsisten deci trnzacia respectiv
trebuie ntrerupt.
2. Tranzacia cere s scrie nregistrarea x a crei valoare a fost deja citit de o tranzacie
care a nceput mai trziu marc(T) < cit_marc(x). Aceasta nseamn c tranzacia vrea
s rescrie o nregistrare, pe care o alt tranzacie nceput mai trziu, a citit-o i o
folosete. i n acest caz tranzacia trebuie ntrerupt.
3. Tranzacia cere s scrie o nregistrare x a crei valoare a fost deja scris de o tranzacie
care a nceput mai trziu, adic marc(T) < scri_marc(x). Este o ncercare de a scrie o
valoare perimat i n acest caz se ignor aceast scriere.
n figura urmtoare se poate observa cum funcioneaz acest protocol.

Exemple 5.5.7
Time

Op T
7
T
8
T
9
A

t
1
begin_transaction
A

t
2
cit(bal
x
) cit(bal
x
)
A

t
3
bal
x
= bal
x

+10
bal
x
= bal
x

+100

A

t
4
scrie(bal
x
) scrie(bal
x
) begin-
_transaction

A

t
5
cit(bal
y
) cit(bal
y
)
A

t
6
bal
y
= bal
y

+20
bal
y
= bal
y

+20
begin-
_transaction
A

t
7
cit(bal
y
) cit(bal
y
)
A

t
8
scrie(bal
y
) scrie(bal
y
)
**

A

t
9
bal
y
= bal
y

+30
bal
y
= bal
y

+30
A

t
10
scrie(bal
y
) scrie(bal
y
)
A

t
11
bal
z
=100 bal
z
=100
A

t
12
scrie(bal
z
) scrie(bal
z
)
A

t
13
bal
z
=50 bal
z
=50 commit
A

t
14
scrie(bal
z
) scrie(bal
z
)
*
begin-
T
10
T
11
136
_transaction
A

t
15
cit(bal
y
) commit cit(bal
y
)
A

t
16
bal
y
= bal
y

+20
bal
y
= bal
y

+20

A

t
17
scrie(bal
y
) scrie(bal
y
)
A

t
18
commit

* la timpul t
8
scrierea de ctre tranzacia T
13
violeaz regula 2 i de aceea este ntrerupt
i reluat la momentul t
14

** la timpul t
14
scrierea de ctre tranzacia T
12
poate fi ignorat conform celei de a treia
reguli
9.4 Tehnici optimiste.
Nu ntotdeuna este necesar s pierdem timp n calculator controlnd concurena.
Atunci cnd conflictele ntre tranzacii snt rare putem adopta aa-numitele tehnici optimiste.
Asta nseamn s lsm tranzaciile s ruleze fr s impunem ntrzieri care s asigure
serializabilitatea, iar cnd o tranzacie vrea s fac commit s efectum un control care s
determine dac a avut loc un conflict. Dac a avut loc un conflict, tranzacia trebuie ntrerupt
i restartat. Pentru c am spus c aceeste conflicte snt rare, aceste nteruperi i restartri vor
fi, i ele, rare.
Distingem trei faze ale unui control optimist al concurenei.
Faza de citire. Aceast faz dureaz de la nceputul tranzaciei pn nainte de
commit. Tranzacia citete valorile de care are nevoie din baza de date i le stocheaz
in variabile locale. Actualizrile nu snt fcute direct n baza de date ci ntr-o copie
local.
Faza de validare. Urmeaz dup faza de citire i controleaz dac nu sar nclca
serializabilitatea n cazul c s-ar aplica actulizarea n baza de date. Dac avem o
tranzacie care numai citete baza (adic nu scrie), controlul const n a verifica dac
datele citite snt nc datele curente n baz i, dac este aa, atunci se face commit,
altfel se ntrerupe i se reia mai trziu. Dac trnzacia face i rescrieri n baz, atunci se
verific dac se pstreaz serializabilitatea i dac baza de date rmne ntr-o stare
consistent; dac acest lucru nu se ntmpl, atunci se ntrerupe.
Faza de scriere. Este o faz care este necesar numai la tranzaciile care fac rescrieri.
Dac faza anterioar s-a terminat cu succes, atunci actualizrile efectuate n copia
local, snt nregistrate definitiv n baza de date.
Iat cum se desfoar acest tip de control:
Fiecrei tranzacii i este ataat, la nceputul primei faze, un marcaj start(T), la
nceputul celei de a doua faze, valid(T) i la sfrit fin(T), dup scriere n copia local,
daceste cazul. Ca s treac faza de validare trebuie s avem una din urmtoare le situaii:
1) Toate tranzaciile cu un marcaj mai mic, trebuie s se fi terminat nainte ca
tranzacia T s fi nceput; adic fin(S) < start(T).
2) Dac tranzacia start(S) < start(T) (S a nceput naintea lui T) i nu s-a terminat
adic fin(S) < fin(T) atunci:
137
a. Datele scrise de tranzacia anterioar S nu snt cele citite de cea curent
T i
b. Tranzacia anterioar S i completeaz faza de scriere nainte ca
tranzacia curent T s intre n faza de validare adic start(T) < fin(S) <
valid(T).
Dei tehnicile optimiste snt eficiente cnd conflictele snt rare totui pot aprea multe
reluri (rollback); s reinem c aceste reluri nu snt n cascad pentru c se lucreaz pe o
coppie local.
Ce ne facem dac apar totii inconsistene? Trebuie s{ [putem recupera baza de date
ntr-o stare anterioar consistent.
Controlul recuperrii.
Din diferite motive se poate ntmpla ca baza de date s ajung ntr-o stare incorect
sau s se piard de tot. Un SGBD trebuie s prevad mecanisme de recuperare automat sau
manual de recuperare a unei stri corecte a bazei de date i posibilitatea de ajunge la zi cu
actualizrile ulterioare.
O tranzacie este format din pai mici care se execut pe rnd i cnd a nceput
aciunea commit ea nu s-a i terminat. Datele snt mai nti duse ntr-un buffer (o memorie
intern intermediar) i pe urm scrise n baz (pe disc). Dac ntre scrierea n buffer i
scrierea pe disc apare vreo cdere, atunci SGBD-ul trebuie s reia scrierea (redo), iar dac nu
s-au umplut bufferele i a aprut o cdere atunci SGBD-ul trebuie s fac ntreruperea i
reluarea tranzaciei (undo sau rollback).
Un SGBD trebuie s aib un mecanism care s fac copii ale bazei de date i jurnale
ale tranzaciilor dup care ele s poat fi refcute. Copiile se fac autmat, fr intervenii
manuale, i recuperarea, n multe cazuri, trebuie s se fac tot automat.

M5.U5.5. Rezumat
Avem dou tipuri de tehnici pentru controlul concurenei.
Controlul pesimist se poate face cu blocaje prin protocolul n dou faze sau cu
marcarea timpului.
Protocolul de blocare n dou faze impune ca, ntr-o tranzacie, dup ce s-a fcut o
deblocare sa nu se mai fac nici o deblocare. putem, n acest caz s avem blocare
ciclic sau ROLLBACK n cascad.
Protocolul cu marcarea timpului (time stamp) ataeaz un timp fiecrei tranzacii
(marc(T)) i timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a
unei nregistrri. Deci fiecare tranzacie va avea o valoare de marcaj i fiecare
nregistrare prelucrat va avea dou marcaje; unul care spune ce marcaj a avut
tranzacia care a citit-o (cit_marc) i cellalt care spune ce marcaj a avut tranzacia
care a scris-o (scri_marc).
O tehnic optimist nseamn s lsm tranzaciile s ruleze fr s impunem
ntrzieri care s asigure serializabilitatea, iar cnd o tranzacie vrea s fac
commit, s efectum un control care s determine dac a avut loc un conflict. Dac
a avut loc un conflict, tranzacia trebuie ntrerupt i restartat. Pentru c am spus c
138
aceeste conflicte snt rare, aceste nteruperi i restartri vor fi, i ele, rare.

M5 U5.5 Test de autoevaluare a cunotinelor
5.5.1 Ce este blocajul?
5.5.2 Ce este blocaju ciclic? Exemplu.
5.5.3 Ce este protocolul de blocare n dou faze?
5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?
5.5.5 Ce este o tehnic optimist de control al concurenei?

139

Unitatea de nvare U5.6. Securitate i integritate

M5U5.6 Introducere

introduc regulile de integritate
s impun msuri de securitate

Integritate
Integritatea bazelor de date se refera la corectitudinea informaiilor i presupune
detectarea, corectarea i prevenirea diferitelor erori care pot afecta datele introduse n bazel e
de date. Cand facem referiri la integritatea datelor, ntelegem c datele sunt consistente relativ
la toate restrictiile formulate anterior (care se aplica datelor respective) i ca urmare a acestui
fapt, datele sunt considerate valide.
Conditiile de integritate numite i reguli sau restrictii de integritate nu permit
introducerea in baza de date a unor date aberante i sunt exprimate prin conditii puse asupra
datelor.
n general sunt acceptate mai multe criterii de clasificare a regulilor de integritate.
O serie de conditii sunt de tip structural, legate de anumite egalitati intre valori, i exprimate
prin dependente functionale sau prin declararea unor campuri cu valori unice (de cele mai
multe ori aceste campuri sunt chei).
O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si, in acest
caz, exista restrictii pe domenii (ce privesc anumite valori pentru atribute) sau restrictii pe
tabele (relatii). Restrictiile pe tabele pot fi unituplu (se refera la fiecare tuplu in parte) sau
multituplu (se refera la combinatii de mai multe tupluri).
O restrictie de integritate de relatie unituplu impune ca in fiecare tuplu al unei relatii
de baza, in campurile corespunzatoare cheii primare, sa apara valori diferite de valorile nule
corespunzatoare. Aceasta regula se mai poate enunta i sub forma: "intr-o baza de date
relaionala nu se inregistreaza nici o informatie despre ceva ce nu poate fi identificat."
Un exemplu de restrictie de integritate de relatie de tip multituplu este restrictia
referentiala care se exprima prin conditia ca, pentru cheile externe, daca nu sunt nule, sa se
admita valori corespunzatoare uneia din cheile primare existente in relatia referita. Verificarea
140
acestei conditii are loc de cate ori se insereaza un nou tuplu ce contine o cheie externa sau se
modifica valoarea unei chei externe a unui tuplu, semnalandu-se eventualele neconcordante i
anuland modificarile. Verificarea unicitatii cheii primare i restrictiile rezultate din
dependentele functionale i multivaloare sunt alte exemple de acelasi tip.
Un alt criteriu de clasificare este acela prin care se deosebesc regulile de integritate ce
se refera la diferitele stari ale bazei de date de regulile ce se refera la tranzitia dintr-o stare in
alta.
Restrictiile pot fi clasificate i din punct de vedere al momentului in care se aplica ele,
astfel avem reguli imediate (ce se verifica in momentul in care se efectueaza operatia indicata)
sau reguli amanate (ce se verifica numai dupa ce au fost executate i alte operatii asociate dar
inainte de a se modifica baza de date).
n functie de aria de aplicare, restrictiile pot fi impartite in restrictii generale,
aplicabile tuturor relatiilor din baza de date i restrictii particulare, care se pot aplica numai la
anumite relatii.
Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate efectiv datele bazei
de date. Dintre regulile generale cel mai des folosite in modelul relaional sunt regulile ce
privesc cheile primare (vezi unicitatea valorilor cheilor primare in cadrul relatiei) i cheile
externe.
Analizam in continuare cateva tipuri de restrictii de integritate.
I. Restrictii pentru integritatea entitatii
Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate avea valori nule.
Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa fie unice. In
majoritatea SGBD unicitatea cheii primare i integritatea entitatii sunt conditii obligatorii.
II. Restrictii pentru integritatea referentiala
Enunt: Daca exista o cheie externa intr-o relatie, ori valoarea cheii externe trebuie sa se
potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de origine, ori valoarea
cheii externe trebuie sa fie nula.
Cu late cuvinte, daca o valoare exista intr-o relatie pe post de cheie externa, ori ea trebuie sa
se potriveasca cu valoarea unei chei primare dintr -o alta relatie ori sa fie nula.
Probleme serioase apar in momentul cand sunt de efectuat modificari sau stergeri de valori ale
cheilor primare.
Daca se actualizeaza o cheie primara sau se sterge intregul tuplu i daca
1) valoarea cheii primare nu apare nicaieri ca i cheie externa
atunci se permite efectuarea operatiei
2) valoarea cheii primare apare in alta parte ca i cheie externa
atunci
a) nu se permite efectuarea operatiei
b) se permite efectuarea operatiei dar de asemenea se seteaza aparitiile cheii externe
la valorile nule sau o valoare implicita (daca s-a specificat vreuna)
c) se permite efectuarea operatiei dar de asemenea
141
(i) in cazul actualizarii se propaga valoarea schimbata la aparitiile cheii
externe unde cheia externa este o parte a cheii primare a relatiei si, de
asemenea, se propaga schimbarile acolo unde aceasta din urma cheie
primara este cheie externa intr-o alta relatie
(ii) in cazul stergerilor se propaga stergerea , adica se sterg tuplele care au
valori ale cheii externe care se potrivesc cu cheia primara
d) se intra in dialog cu utilizatorul
Toate acestea sunt reguli generale care, dupa caz, pot suferi mici transformari, in functie de
aplicaia concreta.
Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaiei sau se pot include in SGBD
utilizand mecanismul trigger-elor. Mai multe SGBD permit sa se creeze i sa se memoreze
proceduri referitoare la baza de date i aceste proceduri pot fi invocate cand au loc anumite
evenimente, cum ar fi actualizari i stergeri ale unor atribute.
Standardul SQL furnizeaza controale pentru integritatea referentiala in declaratiile de creare a
tabelelor.
III. Restrictiile de domeniu
Aceste restrictii sunt intotdeauna restrictii de stare imediate. Aceste restrictii se pot referi la
tipul de date pentru un atribut, la o lista de valori posibile, la un ordin de marime, la un format
sau o forma, la o conditie exprimata cu o formula logica sau la o procedura care este apelata
de cate ori are loc o modificare pentru domeniul specificat.
Exemplu: Restrictiile de domeniu referitoare la o data calendaristica pot fi exprimate
(eventual) in felul urmator:

create domain ZI char(2)
check is_integer(ZI) and num(ZI) >= 1 and num(ZI) <= 31;
create domain LUNA char(2)
check is_integer(LUNA) and num(LUNA) >= 1 and num(LUNA) <= 12;
create domain AN char(2)
check is_integer(AN) and num(AN) >= 0 and num(AN) <= 99;
create domain DATA(ZZ domain(ZI), LL domain(LUNA), AA domain(AN))
check if num(LL) in (1,3,5,7,8,10,12) then num(ZZ) < 31;
check if num(LL) in (4,6,9,11) then num(ZZ) < 30;
check if num(LL) = 2 and mod(num(AA),4) = 0 and
mod(num(AA),100) <> 0 then num(ZZ) < 29;
check if num(LL) = 2 and mod(num(AA),4) <> 0
then num(ZZ) < 28;
Restrictiile de integritate pot fi exprimate prin intermediul limbajului de prelucrare a datelor
sub forma unei egalitati sau ca o relatie intre rezultatele a doua cereri.
Integritatea datelor este strans corelata cu securitatea datelor unei baze de date.
Daca se definesc controalele de securitate in absenta celor de integritate, validitatea i
consistenta datelor se bazeaza exclusiv pe utilizarea corecta i de buna credinta a sistemului
de catre utilizatorii autorizati. Daca insa se definesc numai controale de integritate, datele au
sansa sa fie consistente dar sunt susceptibile la pericolele care provin din lipsa securitatii.
142
Este important de mentionat aici ca restrictiile de integritate nu garanteaza corectitudinea
datelor. Aceasta deoarece este aproape imposibil (in multe situatii) ca verificarea
corectitudinii sa fie realizata automat.
Exemplu: Nu se poate verifica automat daca numele unei persoane este "Pop" sau "Popa",
cum nu se poate verifica automat daca data nasterii este "10.01.2001" sau "01.01.2001", et c.
Pentru a asigura un grad multumitor de integritate a datelor trebuie prevazute restrictii de
integritate in asociere cu principalele momente in care datele respective sunt manipulate, cum
ar fi: introducerea, actualizarea i stergerea. Acestea sunt operatii susceptibile de introducerea
de date inconsistente in baza de date.
Restrictiile de integritate pot fi memorate in multe cazuri chiar in SGBD, dar gradul in care
acest lucru este posibil depinde de SGBD.
Asociata cu integritatea datelor este i protectia datelor impotriva unor evenimente de avarie
cum ar fi caderea sistemului cauzata de defectarea unor componente hardware sau software.
Pierderea accidentala de consistenta a datelor poate rezulta din:
-incidente ce apar pe parcursul executarii tranzacti ilor,
-anomalii datorate accesului concurent la baza de date,
-anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr -o retea,
-erori logice care apar din programele utilizator,
si altele.
Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente in
general, majoritatea bazelor de date se copiaza periodic pe medii magnetice ce se pastreaza in
locuri sigure. De asemenea se tine o evidenta a tuturor transformarilor efectuate in baza de
date de cand s-a efectuat ultima copie. Fisierul care contine aceste modificari se numeste
jurnal. Fiecare inregistrare din jurnal contine un identificator al programului care a facut
modificarea, fosta valoare i noua valoare introdusa pentru un element. Tot in jurnal se mai
pastreaza diferitele momente importante din desfasurarea programelor (inceput, sfarsit,
terminarea unor operatii, etc.). Toate mecanismele mentionate in acest paragraf sunt
caracteristice lucrului cu tranzactii. La terminarea unei tranzactii, indiferent daca ea s-a
incheiat normal sau prin eroare, baza de date trebuie sa aiba acelasi grad de integritate ca la
momentul inceperii executiei tranzactiei respective.
Se spune despre o tranzactie ca este comisa daca au fost terminate toate calculele
produse de ea in aria de lucru i s-a facut o copie a rezultatelor ei in jurnal. Aparitia unor
caderi dupa ce o tranzactie a fost comisa nu afecteaza continutul bazei de date deoarece se
poate reconstitui baza de date cu ajutorul ultimei copii i a jurnalului in care se gasesc toate
rezultatele tranzactiilor comise. Modificarile tranzactiilor abandonate sau necomise nu sunt
luate in considerare la parcurgerea jurnalului pentru restaurarea bazei de date.
Se defineste strategia de comitere in doua faze astfel: o tranzactie poate sa scrie intr-o
baza de date numai dupa ce a fost comisa i o tranzactie poate fi comisa numai dupa ce a
inregistrat in jurnal toate schimbarile de elemente produse de ea.

Securitate
Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva folosirii
neautorizate a lor i in special a modificarilor i distrugerilor nedorite de date i a citirilor
143
nepermise de date. Pentru realizarea securitatii datelor din baza de date se utilizeaza controale
tehnice i administrative.
Securitatea este in general asociata cu urmatoarele situatii:
-acces fraudulos la date,
-pierderea confidentialitatii (secretului) datelor,
-pierderea caracterului privat al datelor,
-pierderea integritatii datelor,
-pierderea disponibilitatii datelor
Este mai dificila protejarea datelor impotriva accesului rauvoitor, intentionat. Se
recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii i masuri de securitate
mai eficiente sau mai putin eficiente.
Forme de acces intentionat i rauvoitor la datele unei baze de date:
-citire neautorizata a unor date,
-modificari neutorizate de date,
-distrugeri de date.
Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor, pe
cand integritatea se refera la evitarea pierdelor accidentale de consistenta. Adevarul este insa
undeva la mijloc.
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe
nivele:
-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de accesul
persoanelor neautorizate;
-la nivel uman este recomandabil sa se acorde autorizatiile de acces cu multa grija i
sa se tina evidente stricte ale persoanelor autorizate
-la nivel sistem de operare slabiciunile protectiei la nivel de sistem de operare
trebuie eliminate sau compensate de alte masuri
-la nivel SGBD sistemul ofera anumite facilitati care sprijina protectia datelor
Tehnici de asigurare a securitatii datelor:
1. Identificarea utilizatorilor.
Fiecarui utilizator in parte i se acorda anumite drepturi de operare pe diferite portiuni din baza
de date la diferite nivele cum ar fi relatia, inregistrarea, pagina, atributul, etc. Drepturile se
refera la posibilitatea citirii, inserarii, stergerii sau modificarii datelor respective. Identificarea
se face de obicei prin parole stabilite fie de administratorul bazei de date fie de utilizator.
2. Protejarea datelor prin codificare (criptare).
Deoarece s-ar putea ajunge la date i prin alte mijloace decat prin intermediul SGBD-ului (de
exemplu prin citirea directa a mediului magnetic) se poate face o protectie prin pastrarea
codificata a datelor pe mediul magnetic. Decodificarea datelor se poate face numai dupa
identificarea utilizatorului prin garzi asociate lui.
3. Utilizarea view-urilor in aplicaii.
144
Abilitatea view-urilor de a "ascunde" o parte din informatiile din baza de date poate fi
utilizata i pentru stabilirea unui anumit grad de securitate a datelor. Astfel se poate vorbi de
acces la nivel de relatie (tabela) sau acces la nivel de view.
In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor. Astfel de view-uri
se numesc read-only (numai pentru citire) i sunt utilizate mai ales in aplicaiile in care datele
pot fi citite de toti utilizatorii (baze de date publice) dar modificarile se fac numai cu
aprobarea administratorului/proprietarului bazei de date.
Modificarile din view-uri nu sunt in general admise deoarece pot duce la efecte laterale ce
privesc parti din baza de date ce nu apar in view-uri. De exemplu stergerea unui element din
view poate sa duca la eliminarea unui alt element care are singura legatura cu elemntul sters i
care nu se afla in view.
4. Administrarea i transmiterea drepturilor.
Se tine evidenta stricta a drepturilor de acces ale fiecarui utilizator la portiuni din baza de
date i se fixeaza reguli de transmitere de la un utilizator la altul a dreptului de acces.
Forme de autorizare:
-autorizare la citire (consultare)
-autorizare la inserare (adaugare)
-autorizare la actualizare (care exclude stergerile)
-autorizare la stergeri (la nivel de tuplu)
n situatiile de mai sus nu se pune problema modificarilor la nivel de schema a bazei
de date.
Daca consideram i acest aspect putem vorbi de:
-autorizare la nivel de index (creare-stergere de indexi)
-autorizare la nivel de relatii (creare)
-autorizare de modificari la nivel de relatii (stergeri sau adaugari de atribute in cadrul
relatiilor)
-autorizari de stergeri ale relatiilor
Diferitele protectii pot fi indicate prin intermediul limbajului de prelucrare a datelor.
Portiunile din baza de date ce pot fi folosite de utilizator pot fi definite prin operatii de selectie
i proiectie care fac invizibile alte portiuni ale bazei de date.
Conducerea organizatiei, care este proprietara bazei de date, trebuie sa ia masuri de
securitate care reduc riscul de a se pierde informatii sau de a se distruge informatii. Prin
pierdere de informatii se poate intelege ca se pierde caracterul privat al informatiilor, ele
devin accesibile unui grup mai mare de persoane decat cel prevazut. Nu intotdeauna
"scurgerile" de informatii lasa urme, deci nu se materializeaza intotdeauna in schimbari
detectabile la nivelul bazei de date.
Problema securitatii cuprinde aspecte legale, sociale i etice, aspecte privind controlul
fizic (paza i posibilitati de blocarea accesului la terminale), aspecte de politie (fixarea
conditiilor de acces), aspecte operationale (modul de stabilire a parolelor), aspecte privind
controlul hard (modul de acces hard la diferite componente), securitatea sistemului de operare
(protejarea informatiilor i anularea rezultatelor intermediare pentru pastrarea secretului
145
datelor) aspecte privind notiunea de proprietate asupra datelor din baza de date i altele
asemanatoare.
Trebuie sa mentionam aici ca furturile i fraudele nu sunt neaparat legate de baza de
date, ele sunt un factor de risc pentru intreaga organizatie, gravitatea acestor fapte depinzand
i de profilul organizatiei in cauza.
n Comunitatea Europeana exista o preocupare serioasa legata de actualizarea
legislatiei la noile nevoi generate de utilizarea intensiva a calculatoarelor. Se incearca in
principal sa se adopte legi care sa protejeze persoana sau organizatia i sa tina seama de
nevoia ca anumite informatii sa aiba caracter privat, deci sa nu fie accesibile publicului larg
sau nici macar unui grup relativ restrans, daca acest fapt ar dauna proprietarului informatiilor
respective. Putem enumera aici o paleta larga de domenii care lucreaza cu informatii al caror
caracter privat trebuie neaparat pastrat: domeniul bancar, domeniul medical, evidente
administrativ-financiare, domeniul productiei in majoritatea firmelor de marca, etc.

M5.U5.6. Rezumat
Integritatea bazelor de date se refera la corectitudinea informaiilor i presupune
detectarea, corectarea i prevenirea diferitelor erori care pot afecta datele introduse
n bazele de date. Cand facem referiri la integritatea datelor, ntelegem c datele sunt
consistente relativ la toate restrictiile formulate anterior (care se aplica datelor
respective) i ca urmare a acestui fapt, datele sunt consider ate valide.
Tipuri de restrictii de integritate.
Restrictii pentru integritatea entitatii.
Restrictii pentru integritatea referentiala
Restrictiile de domeniu
Prin securitatea bazelor de date se intelege protejarea bazelor de date impotriva
folosirii neautorizate a lor i in special a modificarilor i distrugerilor nedorite de
date i a citirilor nepermise de date.
Securitatea este in general asociata cu urmatoarele situatii:
-pierderea confidentialitatii (secretului) datelor,
-pierderea integritatii datelor,
-pierderea disponibilitatii datelor
Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai
multe nivele:
-la nivel fizic - locurile in care se afla calculatoarele trebuie protejate de
accesul persoanelor neautorizate;
-la nivel uman este recomandabil sa se acorde autorizatiile de acces cu
multa grija i sa se tina evidente stricte ale persoanelor autorizate
-la nivel sistem de operare slabiciunile protectiei la nivel de sistem de
operare trebuie eliminate sau compensate de alte masuri
146
-la nivel SGBD sistemul ofera anumite facilitati care sprijina protectia
datelor
Tehnici de asigurare a securitatii datelor:
1. Identificarea utilizatorilor.
2. Protejarea datelor prin codificare (criptare).
3. Utilizarea view-urilor in aplicaii.
4. Administrarea i transmiterea drepturilor.

5.6.1 Care sunt restriciile de integritate?
5.6.2 Ce nseamn integritatea entitatii?
5.6.3 Ce nseamn integritatea referentiala?
5.6.4 Ce nseamn restrictiile de domeniu?
5.6.5 Care este deosebirea ntre integritate i securitate?
5.6.6 Cum poate fi nclcat securitatea datelor ntr-o baza de date ?
5.6.7 Enumerai msuri de protecie pentru asigurerea securitii datelor.
5.6.8 Enumerai forme de autorizare.

147

Raspunsuri la testele de autoevaluare.
Unitatea 1.2
1.2.1 Ce ar trebui memorat despre profesori ntr-o baz de date a facultii?
Nume, adresa,adresa de e-mail,grad didactic,sex
1.2.2 Ce nu ar trebui memorat despre profesori ntr -o baz de date a facultii?
Pasiuni, nlime, greutate, culoarea prului
1.2.3 Ce este arhitectura pe trei nivele?

Arhitectura ANSI-SPARC pe trei nivele

Unitatea 1.3
1.3.1 Care sunt obiectivele unui SGBD?
Bazei de date i revin o serie de obiective, cum sunt:
-Asigurarea independenei datelor.
-Asigurarea unei redundane minime i controlate a datelor din baza de date.

View 1

View 2

View n
Schema
conceptuala
Schema
interna
Baza de
date

Nivel
extern
Nivel
conceptual
Nivel
intern
Organizarea la
nivel fizic a datelor
..
148
- Asigurarea unor faciliti sporite de utilizare a datelor
- Sporirea gradului de securitate a datelor mpotriva accesului neautorizat la date.
-Asigurarea integritii datelor mpotriva unor tergeri intenionate sau neintenionate,
prin intermediul unor proceduri de validare, a unor protocoale de control concurent i a unor
proceduri de refacere a bazei de date dup incidente.
-Asigurarea partajabilitatii datelor. Partajabilitatea datelor trebuie ineleas nu numai
sub aspectul asigurarii accesului mai multor utilizatori la aceleai date, ci i acela al
posibilitii dezvoltarii unor aplicaii fr a se modifica structura bazei de date.

1.3.2 Care sunt funciunile unui SGBD?
1. Funcia de descriere a datelor permite definirea structurii bazei de date cu ajutorul
limbajului de definire. Definirea datelor poate fi realizat la nivel logic, conceptual i fizic.
Aceasta funcie asigur:
-descrierea atributelor (cmpurilor) din cadrul structurii bazei de date,
-descrierea legturilor dintre entitile bazei de date sau dintre atributele aceleiasi
entiti,
-definirea eventualelor criterii de validare a datelor,
-definirea metodelor de acces la date,
-definirea aspectelor referitoare la asigurarea integritii si confideni alitii datelor, etc.
2. Funcia de manipulare a datelor este cea mai complex funcie i realizeaz
urmatoarele activiti:
- crearea (incarcarea) bazei de date;
- adaugarea de noi inregistrri;
- tergerea unor inregistri;
- cutarea, sortarea i editarea parial sau total a unei inregistrri virtuale etc.
3. Funcia de utilizare asigur mulimea interfeelor necesare pentru comunicarea tuturor
utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaionali. Aceatia reprezint categoria beneficiarilor de
informaii (utilizatori finali) care utilizeaz limbajele de interogare a bazei de date intr-o
form simplist. Ei apar ca utilizatori neinformaticieni;
- utilizatori programatori, care utilizeaz limbajele de manipulare, realiznd proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special i are rolul hotartor n ceea
ce privete funcionarea optim a ntregului ansamblu.
4. Funcia de administrare a bazei de date apare ca o funcie complex i este de competena
administratorului bazei de date.

149
Unitatea 1.4
1.4.1 Ce este o baz de date distribuit?
1) Un SGBDD const dintr-o singur baz de date care este descompus n
fragmente, eventual unele fragmente sunt multiplicate, i fiecare fragment sau
copie se pastreaz pe unul sau mai multe site-uri, sub controlul unui SGBD local.
Fiecare site este capabil sa proceseze interogri utilizator n regim local,
independent de restul reelei, sau este capabil s participe la procesarea unor date
situate n alte site-uri din reea. Pentru a spune c un SGBD este distribuit trebuie
s existe cle puin o cerere global.

1.4.2 Care sunt avantajele unui sistem distribuit?
2) Avantajele distribuirii bazelor de date sunt:
- sistemul distribuit se modeleaz cel mai bine pe structura organizaional a multor
organizaii, avand n vedere ca multe companii sunt localizate "distribuit" din punct de
vedere geografic
- datele sunt partajabile dar administrarea lor se bucur de un grad nalt de autonomie local
- disponibilitatea bazei de date este evident mai bun dect n cazul centralizat. Dac se
semnaleaz unele erori sau "deri" de sistem la nivel local sistemul ]n ntregime poate s
continue s funcioneze n condiii satisfctoare
- fiabilitatea sistemului este mbuntit. Se pot reface rapid fiiere distruse utiliznd
replici aflate pe alte site-uri
- performanele n prelucrarea datelor se mbuntesc prin posibilitatea prelucr[rii n
paralel a unor interog[ri
- un sistem distribuit ofer avanatje economice dac lum n considerare costurile
implementrii i ntreinerii unei reele fa de costurile corespunztoare ale unui sistem
centralizat de putere comparabil de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrri locale ct mai multe (n caz sistemul i aplicaiile permit acest
lucru). De asemenea este mult mai convenabil s se "ajusteze" o reea de calculatoare la
nevoile organizaiei (dac de exemplu este necesar adugarea unor site-uri n plus) dect
un calculator central de putere asemntoare
- capacitatea de gestionare modular a sistemului permite extensii ale acestuia sau
rezolvarea unor "cderi" pariale fr s se afecteze prea tare (uneori fr a se afecta
deloc) mersul activitilor pe ansamblul sistemului distribuit.

1.4.3 Cum se poate face proiectarea alocrii datelor?
Proiectarea corect a unei baze de date relaionale distribuite necesit, pe lng cerinele
cunoscute pentru sistemele centralizate, i realizarea urmtoarelor:
- fragmentarea datelor informaiile pot fi partitionate n fragmente care sunt apoi stocate
pe diferite site-uri n reea
Se cunosc patru strategii de alocare a datelor ntr -o baza de date relaional distribuit:
150
a!. centralizat
Baza de date se afl n ntregime pe un singur site din reea i este gestionat de un singur
DBMS. Spunem n acest caz c baza de date este procesat distribuit, ea de fapt nu mai
este o baz de date distribuit in adevaratul sens al cuvntului. Dezavantajele sunt mai ales
costurile mari de comunicaii i o fiabilitate i o disponibilitate foarte sczute, avnd n
vedere c orice eroare care blocheaz accesul la baza de date, practic paralizeaz ntreaga
activitate n reea pe aceast direcie.
a2. fragmentat (partiionat)
Baza de date este partiionat n mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta paritionare a datelor poate mbuntti frecvena referinelor locale
- dac nu exist replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea i disponibilitatea sunt sczute dar nu aa de mici ca n cazul centralizat
- dac datele sunt distribuite corect, costurile de comunicare pot fi relativ sczute
a3. replicat complet
Pe fiecare site se gseste o copie complet a bazei de date. Comentarii:
- eficiena referirilor locale, fiabilitatea i disponibilitatea sunt maxime
- costurile de stocare sunt n schimb i ele foarte mari, la fel sunt i costurile de
actualizare
a4. replicat selectiv
Aceasta strategie este o combinaie intre partiionare, replicare i centralizare cu scopul de a
se cumula, pe cat posibil, avantajele fiecrei strategii i s se elimine dezavantajele.

1.4.4 Cum se face o fragmentare corect?
Reguli de baz care duc la o fragmentare corect a bazei de date:
- completitudine dac relaia R este descompus n fragmentele R
1
, R
2
, ,R
n
, trebuie
luate msuri care s previn pierderea de informaii
- reconstrucie s fie posibil n orice moment s se refac relaia R de la care s -a pornit
cu fragmentarea. Aceasta regul conserv dependenele funcionale.
- disjuncie dac data d
i
apare n fragmentul R
i
atunci nu este permis s apar n nici un alt
fragment. De la aceast regul se admite doar o excepie, cazul cnd o relaie este
fragmentat pe vertical.

1.4.5 Ce este fragmentarea?
Tipurile de fragmentare sunt:
- pe orizontal
- pe vertical
- combinat
Fragmentarea pe orizontal:
151
Ne putem imagina c o tabel se fragmenteaz orizontal ca mai jos:

Un fragment al unei relaii partitionate pe orizontal const dintr-o submulime a tuplelor
relaiei respective.
Un fragment orizontal se produce prin selecie:
Fiecare tuplu din relatia R apare ntr-un anume fragment, o singur dat. Dac se dorete
reconstrucia relaiei, se utilizeaz reuniunea pentru a obine relaia R iniiala.
R= R
1
R
2
R
n

In general fragmentele unei relaii R sunt disjuncte.
Fragmentarea pe vertical
Un fragment vertical dintr-o relaie const dintr-o relaie care are ca atribute o submulime a
atributelor relaiei iniiale.

Un fragment vertical se produce prin proiecie:
Dac S
1
_R i S
2
_R atunci ) (
1
1
R r
S
H = i ) (
2 2
R r
S
H = .
Completitudinea este asigurat prin faptul c fiecare atribut apare cel puin ntr- una din
submulimile S
1
i S
2
.
Reconstrucia relaiei iniilale se realizeaz prin jonciune natural.
2 1
) ( r X r R r
N
=
Aadar la descompunerea relaiei iniiale n fragmente trebuie s se in seama de regulile care
asigur o descompunere fr pierderi la jonciune.
In cazul descompunerii pe vertical nu este posibil s se realizeze o disjuncie total. Se
admite existena unor atribute comune, i anume a atributelor care formeaz cheile primare
(respectiv cheile externe).
Fragmentarea combinat (mixt, hibrid, compus)
Se poate face din fragmente verticale fragmentate orizontal:

Expresia corespunzatoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: )) ( (
,...,
1
R
n
A A P
H o
Sau se poate face din fragmente orizontale fragmentate vertical

152

Expresia corespunztoare n algebra relaional (pentru fiecare dreptunghi din figura de mai
sus) este: )) ( (
,...,
1
R
P A A
n
o H .

Unitatea 2.1
2.1.1 Care sunt modele de date bazate pe nregistrare?
Exista trei tipuri importante de modele de date bazate pe inregistrare: modelul de date
relaional, modelul de date retea i modelul ierarhic de date.

Unitatea 2.2
2.2.1 Gsii cheile candidat ale tabelei student. Stabilii cheia primar.
Student=(nrmatricol,cnp,nume,adresa,nrtelefon,sex,grupa,datanasterii)
chei candidat:
nrmatricol
cnp
nume,adresa
nrtelefon
cheia principal va fi nrmatricol pentru c:
cnp este mai lung
nume,adresa are dou componente i adresa se poate schimba
nrtelefon se poate schimba.
2.2.2 Dai exemple de relaii unu la unu, unu la mai muli i muli la muli.
Relaia editur carte este de unu la mai muli pentru c o editur editeaz mai mul te cri dar o
anumit carte este scoas de o singur editur (vez ISBN care este unic),
Relaia student materii este de muli la muli pentru c un student face mai multe materii i o
materie ete fcut de mai muli studeni.
2.2.3 Stabilii domeniul fiecrui atribut din tabela profesor.
profesor=(Nume, adresa,adresa de e-mail,grad didactic,sex)
nume Alfabetic
adresa compus
adresa de e-mail ir de caractere urmat de @ i de alt ir de caractere
grad didactic La alegere din mulimea(preparator,asistent,lectoe,confereniar,profesor)
sex una din dou M sau F

Unitatea 3.1
Cosiderai instane ale tabelei student, profesor,materii i catalog.
1 Ion ion 7271
5 Dan soc 7271
7 Pan tor 7273

15 Prof1 Bv lunga 22
23 Prof2 Fag oltet 34

1 Baze de date
2 Algoritmica
153
3 Structuri de date

nrmatricol codmaterie nota
1 1 5
1 2 8
5 3 4
7 1 3
7 3 9

e) Facei selecie din student dup grupa 7271
1 Ion ion 7271
5 Dan soc 7271

f) Facei proiecie la student i la profesor dup nume. La acestea dou din urm fac ei
reuniunea.
Ion ion
Dan soc
Pan tor

Prof1
Prof2

g) Faceti jonciunea natural intre student i catalog apoi ntre rezultat i materii.

nrmatricol numestd grupa codmaterie denmaterie nota
1 Ion ion 7271 1 Baze de date 5
1 Ion ion 7271 2 Algoritmica 8
5 Dan soc 7271 3 Structuri de
date
4
7 Pan tor 7273 1 Baze de date 3
7 Pan tor 7273 3 Structuri de
date
9

h) Facei selecia tabelei de mai nainte dup nota < 5.
nrmatricol numestd grupa codmaterie denmaterie nota
5 Dan soc 7271 3 Structuri de
date
4
7 Pan tor 7273 1 Baze de date 3

3.1.2 S se exprime n algebra relaional cererile:
e) Studenii grupei 7271
o
grupa=7271
(student)
f) Studenii care sunt i profesori
154
H
nume
(student) H
nume
(profesor)

g) Studenii corigeni
H
nume
(o
nota<5
(student j
N
catalog j
N
note))
h) Studenii integraliti
H
nume5
(student) \ H
nume
(o
nota<5
(student j
N
catalog j
N
note))

Unitatea 3.2

Se dau urmtoarele relaii cu schemele lor:
-Scri (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaa,Cutii_potale, Nr_prize_tv)
- Familii (Nr_mat, Nr_pers, Nr_pers_prez, Nr_chei)
-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume
S se exprime n SQL cererile:
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=3) and (scari.scara= locatar.scara)

select nume
where (scari.bloc=34) and(scari.bloc = locat ari.bloc)

select nume

3.2.4 tabel nominal cu locatarii de pe scrile 1,2,3 ale blocului 34
select nume
union select nume
union select nume
155

3.2.5 lista apartamentelor cu suprafaa mai mare dect 50 mp
select Nr_bloc,Scara,Apartament
from apartamente
where suprafaa > 50

3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 i nu locuiesc i pe scara 1 a
aceluiai bloc
select nume
and not in ( select nume
where (scari.bloc=34) and(scari.bloc locatari.bloc)
and (scari.scara=1) and (scari.scara= locatar.scara))

Unitatea 4.1
4.1.1 Dependenele funcionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota)) sunt:
nrmatricol nume
nrmatricol adresa
nrmatricol,codmaterie nota
codmaterie denumirematerie

4.2.1 Fie tabela din enun:
Cod
Furn.
Denumire Cod
fiscal
Nr.
Crt.
Cod
Chelt.
Denumire
Cheltuial
Valoare
F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 1500000
2 C16 Chelt pt. Buctrii 500000
F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000
4 C11 Chelt pt. Func. liftului 200000

n aceast tabel observm c pentru furnizorul Romgaz avem dou tipuri de
cheltuieli. Grupul de atribute (nr.crt., cod chelt., denumire cheltuial, valoare) apare de mai
multe ori. Pentru a transforma aceast tabel n 1NF, trebuie s avem o singur valoare la
fiecare intersecie linie coloan.
n cazul primei modaliti, scriem repetiiile pe diferite rnduri iar coloanele care nu
conin repetiii, vor fi copiate pe fiecare rnd. Dup desprirea repetiiilor pe mai multe
rnduri, identificm o nou cheie.
Cod
Furn.
Denumire Cod
fiscal
Nr.
Crt.
Cod
Chelt.
Denumire
Cheltuial
Valoare
F100 Romgaz R1234567 1 C15 Chelt pt. nclzire 1500000
F100 Romgaz R1234567 2 C16 Chelt pt. Buctrii 500000
F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000
F110 Renel R7654321 4 C11 Chelt pt. Func. liftului 200000
Tabela Furnizori_Cheltuieli n 1NF creat prin prima modaliate de transformare.
156
n tabela normalizat, noua cheie va fi (Cod Furn., Nr. Crt ., Cod Chelt.).
Normaliznd tabela iniial dup a doua modalitate, vom crea o a doua tabel cu
informaiile care nu se repet, mpreun cu cheia primar din tabela iniial. Deci cele dou
tabele vor fi urmtoarele:
Furnizori (Cod Furn., Denumire, Cod fiscal)
Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuial, Valoare)
Cele dou tabele astfel create sunt n 1NF:
4.2.2 Fie R = (Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuial, Nr. Crt.,
Cod, Valoare)
Vom avea dependentele functionale:
K = (Cod Furn., Cod Chelt., Nr. Crt.) R deci K este cheie.
d1 Cod Chelt Denumire cheltuial
d2 Cod Furn (Denumire, Cod fiscal)
Dependenele d1 i d2 sunt dependene pariale de cheie.
Relaiile rezultate au urmtoarea form:
Furnizori = (Cod Furn., Denumire, Cod fiscal)
Tip cheltuial = (Cod Chelt., Denumire cheltuial)
Cheltuieli = (Nr. Crt., Cod Furn., Cod Chelt., Valoare)
Fie relaia din enun:
carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. n afara dependenelor
care definesc cheia mai avem dependena:

cod_domeniu den_domeniu i pentru c c_carte este cheie avem i
c_carte cod_domeniu deci den_domeniu depinde tranzitiv de cheie.
Prin descompunere rezult dou scheme 3NF:
carte1 = (c_carte, titlu, cod_domeniu) i
domeniu = (cod_domeniu, den_domeniu).
Fie relaia:
Are grup repetitiv deci nu este FN1.
se descompune n:
stud1=( nrmatricol,nume,adresa) care este FN3 i
stud2=( nrmatricol,codmaterie,denumirematerie,nota) unde avem dependenele funcionale:
nrmatricol,codmaterie nota
codmaterie denumirematerie aceasta fiind dependen parial de cheie deci nu este FN2
se obine forma fina:
stud1=( nrmatricol,nume,adresa)
catalog=( nrmatricol,codmaterie,nota)
materii=( codmaterie,denumirematerie)

Unitatea 5.1
5.1.1 Facei proiectul conceptual local pentru subsistemul didactic al facultii.
Pasul 1.1. Identificarea tipurilor de entiti.
tipurile de entiti sunt:
student, materii, profesori, orar, sali
157
Identificarea tipurilor de relaii.
n continuare identificm tipurile de relaii. Tipurile de relaii se reprezint prin verbe
ale relaiilor.
n continuare vom determina cardinalul i participarea relaiilor prezentate n tabelele
de mai sus. Cardinalul poate s fie unul dentre urmtoarele: unu-la-unu (1:1), unu-la-multe
(1:M), sau multe-la-multe (M:N). Participarea poate s fie parial sau total.

Tip de entitate Tip de relaie Tip de entitate
cardinalitate participare
student face Materii
N:M P:T
profesor preda Materii
N:1 T:T
orar Relaie
complex cu
Zile, Sali, ore,
materii

Atributele tipurilor de entiti

Tip de entitate Atribute
domeniu
student nrmatricol Numeric de 5
nume text
adresa text
sex M sau F
grupa Numeric de 4

materii Codmaterie Numeric de 3

Denmaterie
.
Text

Pasul 1.7. Desenarea modelului ER.
158

Unitatea 5.2
5.2.1 Facei proiectul logic local pentru subsistemul didactic al facultii.
Pasul 2.1. Proiectarea modelului local conceptual n modelul local logic.
n acest pas eliminm acele structuri din baza de date, care sunt dificil de implementat
n sistemul de gestiune al bazelor de date. Pentru a rezolva aceast problem, se vor urma
urmtorii pai:
(1) Eliminarea relaiilor de tipul N:M.
Este cazul relaiei dintre student i materii. Apare entitatea catalog.

(2) Eliminarea relaiilor complexe.
Avem relaia cu orarul. Se modific n felul urmtor:
profesori
1
orar
sali zile ore
student
N

materii
M N
student
N

materii
N
catalog
1 1
159

(3) Eliminarea relaiilor recursive. Nu avem.
(4) Eliminarea relaiilor cu atribute. Nu avem.
(5) Reexaminarea relaiilor de tipul 1:1. Nu avem
Desenarea diagramei ER.
Modelul conceptual care este reprezentat anterior s-a modificat n acest pas. Am
eliminat din acest model, toate structurile greu de implementat ntr-un sistem de gestiune a
bazelor de date. Diagrama modificat se va numi n continuare modelul local logic al bazei de
date.

N orar N
zile
1
ore
1
N zileore N
1
Sali
1
N zioresali N
1

materii
1

student
N

materii
M N
profesori
1
N orar N
zile
1
ore
1
N zileore N
1
Sali
1
N zioresali N
1

160

Pasul 2.2. Crearea de relaii peste modelul logic local.
n acest pas vom crea relaiile ntre entitile din modelul logic local de date, cu
ajutorul mecanismului chei primare/chei strine. de exemplu:

Student=(nrmatricol,nume,adresa,sex,grupa)
Cheie primar nrmatricol

Catalog=(nrmatricol,codmaterie,nota)
Cheie primar nrmatricol,codmaterie
Cheie strin nrmatricol refer nrmatricol din student
Cheie strin codmaterie refer codmaterie din materii

materii=(codmaterie,denmaterie)
Cheie primar codmaterie

Pasul 2.3. Validarea modelului prin normalizare.
n acest pas validm baza de date prin normalizare. Procesul de normalizare este
descris amnunit n capitolul 4.
- Forma Normal Unu (1NF), eliminarea repetiiilor din atribute.
- Forma Normal Doi (2NF), eliminarea dependenelor pariale de cheia primar.
- Forma Normal Trei (3NF), eliminarea dependenelor tranzitive de cheia primar.
- Forma Normal Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rmas.
Trebuie s analizm fiecare relaie care este descris n anexa 6.3.5. Verificm dac
relaiile sunt n forma normal Boyce-Codd, iar dac gsim una care nu satisface aceast
form normal, ne ntoarcem la paii precedeni i rezolvm problema.
n cazul nostru toate tabelele sunt n FN3
Pasul 2.2. Validarea modelului prin tranzaciile cerute.
Tranzaciile vor fi:
T1 Tabel nominal cu studenii grupei
T2 Catalogul grupei.. la materia

Pentru fiecare tranzacie vom da fraza SQL:
T1 SELECT nume
FROM student
WHERE grupa=
T2 SELECT student.nume,denmaterie,nota
FROM student,catalog,materii
WHERE grupa= AND denmaaterie=
AND student.nrmatricol=catalog.nrmatricol
AND catalog.codmaterie)materii.codmaterie

Unitatea 5.3
Realizai, n ACCESS, proiectul fizic al subsistemului didactic al facultii.
Se vor urmri paii din Access la purttor [8]

161
Unitatea 5.4
5.4.1 Dai exemple de pierdere a consistenei.
1) Tranzacia T
1
x
) i scade 10 din cont. Tranzacia T
2
citete
contul lui x (bal
x
) i adun 100 la cont. Pornind cu un cont de 100, evident c dac se
execut mai nti prima tranzacie i apoi a doua contul lui x ar fi fost 100-
10+100=190. n cealalt ordine am fi avut 100+100-10=190 aceeai valoare. S
considerm urmtorul plan de tranzacii.

Time

T
1
T
2
bal
x
A

t
1
A

t
2
begin_transaction cit(bal
x
) 100
A

t
3
cit(b al
x
) bal
x
= bal
x
+ 10 100
A

t
4
bal
x
= bal
x
- 10 scrie(bal
x
) 200
A

t
5
scrie(bal
x
) commit 90
A

t
6
commit 90
Se ved c bal
x
are valoarea greit 90.

Unitatea 5.5
5.5.1 Ce este blocajul?
1) Cnd o tranzacie blocheaz partajat o anumit unitate de memorie, o alt tranzacie nu
mai poate s rescrie tot acolo, iar cnd o tranzacie blocheaz exclusiv o alta nu mai
poate nici s o citeasc.
5.5.2 Ce este blocaju ciclic? Exemplu.
1) Blocarea ciclic este prezentat n exemplul urmtor. Cele dou trnzacii T
10
i T
11
se
blocheaz reciproc.
Time

T
10
T
11

A

t
1
begin_transaction
A

t
2
ex_bloc(bal
x
) begin_transaction
A

t
3
cit(bal
x
) ex_bloc(bal
y
)
A

t
4
bal
x
= bal
x
-10 cit(bal
y
)
A

t
5
scrie(bal
x
) bal
y
= bal
y
+100
A

t
6
ex_bloc(bal
y
) scrie(bal
y
)
A

t
7
ATEAPT ex_bloc(bal
x
)
A

t
8
ATEAPT ATEAPT
A

t
9
ATEAPT ATEAPT
A

t
10
ATEAPT
A

t
11

5.5.3 Ce este protocolul de blocare n dou faze?
1) Protocolul de blocare n dou faze const din mprirea tranzaciei n dou faze una
de blocri i creteri de blocaje i a doua de descreteri i deblocaje. Aceasta nseamn
c dup ce s-a fcut prima deblocare nu se mai pot face blocri.

5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?
Protocolul cu marcarea timpului (time stamp) ataeaz un timp fiecrei tranzacii
(marc(T)) i timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a unei
162
nregistrri. Deci fiecare tranzacie va avea o valoare de marcaj i fiecare nregistrare
prelucrat va avea dou marcaje; unul care spune ce marcaj a avut tranzacia care a citit-o
(cit_marc) i cellalt care spune ce marcaj a avut tranzacia care a scris-o (scri_marc).
Numai n urmtoarele trei situaii se pun probleme deosebite:
1. Tranzacia T cere s citeasc o nregistrare x care a fost deja actualizat de o
tranzacie cu scri_marc(x) > marc(T), adic o nregistrare scris de o tranzacie
care a nceput mai trziu. Ce ar rescrie ea ar putea da natere la inconsisten
deci trnzacia respectiv trebuie ntrerupt.
2. Tranzacia cere s scrie nregistrarea x a crei valoare a fost deja citit de o
tranzacie care a nceput mai trziu marc(T) < cit_marc(x). Aceasta nseamn
c tranzacia vrea s rescrie o nregistrare, pe care o alt tranzacie nceput
mai trziu, a citit-o i o folosete. i n acest caz tranzacia trebuie ntrerupt.
3. Tranzacia cere s scrie o nregistrare x a crei valoare a fost deja scris de o
tranzacie care a nceput mai trziu, adic marc(T) < scri_marc(x). Este o
ncercare de a scrie o valoare perimat i n acest caz se ignor aceast scriere.

5.5.5 Ce este o tehnic optimist de control al concurenei?
O tehnic optimist nseamn s lsm tranzaciile s ruleze fr s impunem ntrzieri
care s asigure serializabilitatea, iar cnd o tranzacie vrea s fac commit, s
efectum un control care s determine dac a avut loc un conflict. Dac a avut loc
un conflict, tranzacia trebuie ntrerupt i restartat. Pentru c am spus c aceeste
conflicte snt rare, aceste nteruperi i restartri vor fi, i ele, rare.

Unitatea 5.6
5.6.1 Care sunt restriciile de integritate?
integritatea entitatii
- integritatea referentiala
- restrictiile de domeniu
- restriciile de intreprindere
5.6.2 Ce nseamn integritatea entitatii?
1) Intr-o relaie de baza nici un atribut al unei chei primare nu poate avea valori nule.
5.6.3 Ce nseamn integritatea referentiala?
Daca exista o cheie externa intr-o relaie, ori valoarea cheii externe trebuie s se potriveasca
cu valoarea unei chei candidat a vreunui tuplu n relaia de origine, ori valoarea cheii externe
trebuie s fie nul.
5.6.4 Ce nseamn restrictiile de domeniu?
Aceste restricii se pot referi la tipul de date pentru un atribut, la o list de valori
posibile, la un ordin de mrime, la un format sau o form, la o condiie exprimat cu o
formul logic sau la o procedur care este apelat de cate ori are loc o modificare
pentru domeniul specificat.
5.6.5 Care este deosebirea ntre integritate i securitate?
Noiunea de securitate a bazei de date este de obicei asociat cu accesul ruvoitor, pe cand
integritatea se refera la evitarea pierdelor accidentale de consist en
163
5.6.6 Cum poate fi nclcat securitatea datelor ntr-o baza de date ?
Securitatea este in general asociat cu urmatoarele situaii:
-pierderea confidenialitatii (secretului) datelor,
-pierderea disponibiliatii datelor.
5.6.7 Enumerai msuri de protecie pentru asigurerea securitii datelor.
Pentru protectia bazei de date se pot lua masuri de asigurare a securitii la mai multe nivele:
-la nivel fizic - locurile n care se afla calculatoarele trebuie protejate de accesul
persoanelor neautorizate;
-la nivel uman este recomandabil sa se acorde autorizaiile de acces cu multa grij i
s se in evidene stricte ale persoanelor autorizate
-la nivel sistem de operare slbiciunile proteciei la nivel de sistem de operare
trebuie eliminate sau compensate de alte msuri
-la nivel SGBD sistemul ofera anumite faciliti care sprijina protecia datelor.
5.6.8 Enumerai forme de autorizare.
Forme de autorizare:
-autorizare la citire (consultare)
-autorizare la inserare (adugare)
-autorizare la actualizare (care exclude tergerile)
-autorizare la tergeri (la nivel de tuplu)
In situaiile de mai sus nu se pune problema modificarilor la nivel de schem a bazei de date.
Dac considerm i acest aspect putem vorbi de:
-autorizare la nivel de index (creare-tergere de indeci)
-autorizare la nivel de relaii (creare)
-autorizare de modificri la nivel de relaii (tergeri sau adugari de atribute n cadrul
relaiilor)
-autorizri de tergeri ale relaiilor.

164

Bibliografie.
[1] L.mbulea - Structuri de date i bnci de date, Universitatea Babe -Bolyai, Cluj, 1992
[2] H.F.Korth, A.Silberschatz - Database System Concepts, McGraw Hill, New York, 1987
[3] T.Connoly,C.Begg,A.Strachan Database Systems, Assison-Wesley, 1997
[4] O.Bsc Baze de date,All,1997
[5] Lungu I. Bodea C. Badescu G. Ionita C. Baze de date Ed.ALL 1995
[6] Iacob P.Baze de date pentru nceptori. Ed. Universitii din Piteti. 2000
[8]iacob P. Access la purttor Ed.Lux libris 2007
[9]iacob P. Oracle la purttor Ed.Lux libris 2008
[10] M. Stanescu i colectiv - Limbaje de programare i bnci de date, ASE, Bucuresti, 1992
[11] R Steiner - Theorie und Praxis relationaler Datenbanken, Vieweg Verlag, 1994
[12] J.L.Harrington,Relational database design,AP PROFESSIONAL,1998.

Curs Baze de Date

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curs Baze de Date

Uploaded by

Copyright:

Available Formats

Paul IACOB

You might also like