Paul IACOB

1
Introducere

Aplicaţii tradiţionale bazate pe fişiere; limitări
Pentru o mai bună înţelegere a evoluţiei prelucrărilor de date vom rezerva câteva
rânduri la începutul cursului nostru pentru o scurtă trecere în revistă a metodelor tradiţionale
de prelucrare a masivelor de date, aşa-numitele sisteme tradiţionale bazate pe fişiere.
În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfârşit calcule
laborioase în care nu erau implicate cantităţi prea mari de date, aşa-numitele calcule
ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a posibilităţii stocării de mari cantităţi
de informaţie pe suport magnetic adresabil (memorie externa) s-a pus şi problema
eficientizării prelucrării acestora. De data aceasta nu calculele creşteau costul în timp al
prelucrărilor ci manipularea datelor, respectiv regăsirea, actualizarea, etc. S-a constatat că un
factor important al creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor.
De aici şi până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date n-
a mai fost decât un pas.
Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe organizarea
datelor sub forma înregistrărilor în fişiere tradiţionale pe suport adresabil. În această variantă
se elaborau programe de aplicaţie care defineau şi manipulau propriile date şi aveau în general
ca scop elaborarea de rapoarte pentru diverşi beneficiari. Aceste programe au avut menirea de
a înlocui prelucrarea sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele
locuri cum ar fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat
pe fişiere copiau în mare măsură metodele manuale de prelucrare. Evident că puterea de
calcul şi memorare caracteristică sistemelor de calcul au făcut ca gama prelucrărilor să
crească simţitor, la aceasta adăugându-se viteza şi siguranţa prelucrărilor.
Cu toate că la momentul respectiv abordarea tradiţională bazată pe fişiere a fost un
evident progres, putem să amintim aici şi o serie de limitări ale acestui sistem de prelucrare a
datelor:
Separarea şi izolarea datelor
Duplicarea datelor
Dependenţa datelor
Incompatibilitatea fişierelor
Interogări fixe / proliferarea aplicaţiilor
Comentăm pe scurt în continuare semnificaţia acestora.
Separarea şi izolarea datelor
Accesul la date care se află în fişiere diferite este dificil deoarece cade în sarcina
programatorului să sincronizeze înregistrările din fişiere în aşa fel încât datele extrase să fie
corecte.
Duplicarea datelor
În situaţia în care se realizează prelucrări descentralizate de date, pe compartimente,
este posibil să fie necesară duplicarea datelor. Totuşi duplicarea este de evitat din următoarele
motive:
- necesită costuri mari în timp şi spaţiu de memorie.
- duce la pierderea integrităţii datelor. Datele nu mai sunt consistente, deci nu se mai
poate conta pe ele.
2
Dependenţa datelor
Aşa cum am subliniat deja, structura fizică şi modul de memorare al datelor este
definit în fiecare program de aplicaţie în parte. Este evident cât de dificile sunt schimbările în
structura datelor. Toate programele trebuie ajustate la noua structură de date. O simplă
modificare a lungimii unui câmp poate genera probleme. Dependenţa se referă aşadar la
dependenţa program-date.
Incompatibilitatea fişierelor
Această limitare se trage tot din dependenţa de programe a structurii fişierelor.
Structura fiind descrisă în programe ea depinde de limbajul de programare. De exemplu,
structura unui fişier declarată într-un program COBOL diferă de structura unui fişier generat
de un program C. Dacă e necesară prelucrarea de date din ambele fişiere, programatorul este
obligat să scrie programe de conversie, pentru a aduce fişierele la un format comun posibil de
prelucrat.
Interogări fixe / proliferarea aplicaţiilor
Deoarece prelucrarea masivelor de date a devenit mai uşoara şi mai rapida cu ajutorul
calculatorului, beneficiarii au lărgit gama prelucrărilor lansând interogări noi sau modificând
interogări mai vechi, pentru obţinerea de informaţii mai complexe. Orice interogare nouă sau
orice modificare a unei interogări mai vechi se rezolvă în sistemele tradiţionale prin realizarea
de noi programe de către programatorul de aplicaţie. Inutil de subliniat cât de costisitoare sunt
acestea. Un efect secundar era că se înmulţeau programele aplicaţiei şi de multe ori şi fişierele
de prelucrat.



Obiectivele cursului
Cursul de baze de date este un curs de bază pentru meseria de informatician. La
sfârşitul acestui curs, studenţii vor fi capabili să:
 Proiecteze o bază de date
 Programeze cereri în SQL
 Realizeze un sistem cu bază de date



Cerinţe preliminare
Cursul se va susţine studenţilor după cursul de structuri de date.
Cunoştinţele 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 unităţi de învăţare, al doilea modul cuprinde două unităţi de învăţare, al
treilea modul cuprinde două unităţi de învăţare, al patrulea modul cuprinde două
unităţi de învăţare, iar al cincilea modul cuprinde şase unităţi de învăţare. La
rândul său, fiecare unitate de învăţare cuprinde: obiective, aspecte teoretice privind
tematica unităţii de învăţare respective, exemple, teste de autoevaluare precum şi
probleme propuse spre discuţie şi rezolvare.
La sfârşitul fiecărui modul sunt date teste de autoevaluare. Rezolvarea acestor teste
se găseşte la sfârşitul cărţii.


Durata medie de studiu individual
Parcurgerea de către studenţi a unităţilor de învăţare ale cursului de baze de date
(atât aspectele teoretice cât şi rezolvarea testelor de autoevaluare şi rezolvarea
problemelor propuse) se poate face în 1-4 ore pentru fiecare unitate.


Evaluarea
La sfârşitul semestrului, fiecare student va primi o notă, care va cuprinde: un
examen scris cu materia din modulele 1, 3 şi 4 care va deţine 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 învăţare 1. Istoric; comentarii ................................ ................................ ......... 6
Criterii minimale de definire a unui SGBDR ................................ ................................ ... 10
Unitatea de învăţare 1.2 Abstractizarea datelor ................................ ................................ 14
Unitatea de învăţare 1.3 Principalele componente şi funcţiuni ale unui SGBD............... 19
Unitatea de învăţare 1.4 Baze de date distribuite ................................ ............................. 27
Modulul 2. Modele de descriere a datelor ................................ ................................ ................ 37
Unitatea de învăţare 2.1. Generalităţi ................................ ................................ ............... 38
Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship) ................................ ......... 41
Modulul 3. Limbaje de cereri. ................................ ................................ ................................ .. 53
Unitatea de învăţare 3.1 Algebra relaţională. ................................ ................................ ... 54
Unitatea de învăţare 3.2 SQL ................................ ................................ ........................... 65
Modulul 4. Normalizarea................................ ................................ ................................ .......... 85
Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem
normalizarea. ................................ ................................ ................................ .................... 86
Unitatea de învăţare 4.2 Forme normale ................................ ................................ ......... 93
Modulul 5. Metodologia de proiectare a bazelor de date relaţionale ................................ ...... 99
Unitatea de învăţare U5.1 Generalităţi şi proiectarea conceptuală................................ . 101
Unitatea de învăţare U5.2 Proiectarea logică. ................................ ................................ 111
Unitatea de învăţare U5.3 Proiectarea fizică. ................................ ................................ . 122
Unitatea de învăţare U5.4 Tranzacţii şi concurenţă................................ ........................ 126
Unitatea de învăţare U5.5 Metode de control al concurenţei. ................................ ........ 131
Unitatea de învăţare 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 funcţiuni ale unui SGBD
U1.4 Baze de date distribuite



Introducere
Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de
necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce
mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere,
memorare, transmitere şi prelucrare a datelor. Cel mai important domeniu al
aplicaţiilor calculatorului este cel al bazelor de date.







M1. Obiectivele modulului
La sfârşitul acestui modul studenţii vor fi capabili să:
 Distingă gradul de relaţional al unui SGBD
 descrie componenţa unui Sistem de Gestiune al Bazei de Date
 cunoască obiectivele unui SGBD
 cunoască şi să utilizeze funcţiunile unui SGBD
 înţeleagă ce este o bază de date distribbuită
 cum se proiectează o bază de date distribuită








6
Unitatea de învăţare 1. Istoric; comentarii



M1.U1.1. Introducere
Este important să ştim cum a evoluat modelul şi softul pentru bazele de date. Ne
ocupăm, în acest curs, de cel mai important dintre modele şi anume modelul
relaţional.



M1.U1.2. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 Înţeleagă nivelul la care au ajuns bazele de date
 Distingă gradul de relaţional al unui SGBD.



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Istoric şi comentarii
Se pare că sistemul de baze de date îşi are rădăcinile î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).
Conducător de proiect: Charles Bachmann. Proiectul a condus la modelul de date reţea.
În 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea
reprezentanţi ai guvernului USA şi reprezentanţi ai lumii afacerilor şi comerţului, a reuşit să
stabilească un grup de lucru, cunoscut din 1967 sub numele Data Base Task Group (DBTG).
Sarcina acestui grup era să stabilească specificaţii 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 prezentării primului proiect de
raport CODASYL (Raportul final s-a prezentat în 1971). Ideea principală în organizarea
datelor se baza pe existenţa a trei nivele de bază:
- schema de reţea - care reprezenta organizarea logica a întregii baze de date
- subschema - care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de
programele de aplicaţie
- 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 ANŞI (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 generaţie 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ţă covârşitoare în dezvoltarea bazelor de date. Lucrarea trata despre modelul de date
relaţional.
De aici încolo s-au proiectat multe sisteme dintre care menţionăm System R dezvoltat la
IBM's San Jose Research Laboratory din California, la sfârşitul anilor '70. Acest proiect a dus
la:
- dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un
standard pentru sistemele relaţionale;
- producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2 şi
SQL/DS de la IBM şi ORACLE de la ORACLE Corporation.
Alte exemple de sisteme relaţionale: INGRES de la Relaţional Technology Inc., Informix de
la Informix Sofware Inc., Sybase de la Sybase Inc.. Dintre sistemele relaţionale pentru
microcalculatoare enumerăm aici: Paradox şi dBase IV de la Borland, Access de la Microsoft,
FoxPro şi R:base de la Microrim. Toate acestea constituie generaţia a doua de SGBD.
Definirea sistemelor de gestiune ale bazelor de date relaţionale
Într-o primă încercare de definire, se poate considera un sistem de gestiune a bazelor de
date relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de
organizare a datelor modelul relaţional. Astfel spus, un SGDBR reprezintă un sistem care
suportă modelul relaţional.
Definiţia de mai sus este prea generală pentru a putea fi operaţională, deoarece modul de
implementare a modelului relaţional diferă, de regulă atât între diferitele SGBDR, cât şi în
raport cu modelul “ teoretic”, cel definit în cadrul teoriei relaţionale, datorită eforturilor
producătorilor de a realiza sisteme cât mai performanţe care să satisfacă cerinţele şi
exagerările utilizatorilor. Cât de aproape (sau de departe) de modelul relaţional teoretic
trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că SGBD-ul
respectiv utilizează sau nu modelul relaţional, deci este sau nu SGBDR?
Diversitatea modelelor relaţionale operaţionale au determinat, în mod natural existenţa
unei mari diversităţii de SGBDR, pentru a căror prezentare a fost necesară nuanţarea
terminologiei. Au apărut o serie de sintagme precum: sisteme cu interfaţă relaţională, sisteme
pseudorelaţionale, sisteme complet relaţionale.
Conceptele specifice organizării datelor în fişiere, SGBDR şi teoriei relaţionale între care
se pot stabili analogii

Organizarea datelor în fişiere SGBDR Teoria relaţională
Fişier Tabelă Relaţie
Record(înregistrare) Linie Tuplu
Câmp Coloană Atribut

În general, conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale
operaţionale diferă de cele din cadrul teoriei relaţionale. Figura de mai sus prezintă
8
comparativ conceptele organizării datelor în fişiere, concepte SGBDR şi ale teoriei
relaţionale.
Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi
conceptele relaţionale, i-au determinat pe unii producători să prezinte sisteme fără nici o
legătură cu modelul relaţional drept SGBDR, în scopul asigurării 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 relaţional. În acest sens, Codd a formulat 13 reguli care
exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. Deşi reguli au
stârnit 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 relaţie
Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale.
Acest lucru înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin
manipulări în care unitatea de informaţie să fie mulţimea (relaţia), adică să utilizeze limbaje,
precum SQL, care să opereze la un moment dat pe o întreagă relaţie. Dec i SGBD nu trebuie să
accepte operaţii non-relaţionale care să îndeplinească operaţiile de definire şi manipulare a
datelor.
Unele sisteme utilizează mecanisme relaţionale numai pentru o parte din funcţii, în special
pentru interogare. Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR.
R1: Regula privind reprezentarea logică a datelor
Toate datele din baza de date relaţională 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 acelaşi mod. Informaţiile privind numele de
tabele,coloane, domenii, definiţiile tabelelor virtuale, restricţii de integritate trebuie să fie
memorare tot în tabele de date (catal oage). Referinţa la 'nivelul logic' înseamnă că construcţia
fizică nu este reprezentată şi nu necesită explicaţie.
R2: Regula privind garantarea accesului la date.
Orice dată din baza de date relaţională trebuie să poată fi accesată prin specificarea
numelui da tabelă, valorii cheii primare şi numelui de coloană.
Această regulă exprimă cerinţa 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
semnificaţia unor date lipsă sau inaplicabile. Valorile null, care diferă de şirurile de caractere '
spaţiu' sau de şirurile vide da caractere sunt deosebit de importante în implementarea
restricţiilor de integritate (integritatea entităţii şi integritatea referenţială).
R4: Regula privind metadatele
Descrierea bazei de date trebuie să se prezinte la nivel logic în acelaşi mod cu descrierea
datelor propiu-zise, astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi
operaţii ca şi asupra datelor obişnuite.
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
informaţiile de sistem.
Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şi a metadatelor,
utilizând o singură structură, şi anume cea relaţională.
R5: Regula privind facilităţile limbajelor utilizate
Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în mai multe
moduri. Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată
9
exprima oricare din următoarele operaţii: definirea tabelelor de date, definirea tabelelor
virtuale, manipularea datelor (interactiv dau prin program), definirea restricţiilor de
integritate, autorizarea accesului, precizarea limitelor tranzacţiilor. A se nota aici că noul
standard O/I pentru SQL furnizează toate aceste funcţii, 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 inserările, modificările şi ştergerile în baza de date
Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nu
numai în cadrul operaţiilor de regăsire, ci şi în acţiuni de inserare, modificare şi ştergere a
datelor.
Această regulă exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se
lucreze la un moment dat pe o întreagă relaţie.
R8: Regula privind independenţa fizică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de
reprezentare a datelor sau în metodele de acces. O schimbare a structurii fizice a datelor nu
trebuie să blocheze funcţionarea programelor de aplicaţie.
R9: Regula privind independenţa logică a datelor
Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra
relaţiilor bazei de date, schimbări care conservă datele şi care teoretic garantează valabilitatea
programelor de aplicaţie existente.
R10: Regula privind restricţiile de integritate
Restricţiile 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
aplicaţie.
R11: Regula privind distribuirea geografică a datelor
Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca, în situaţia în
care datele sunt distribuite, programele de aplicaţie să fie logic aceleaşi 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 când 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 scăzut) orientat pe prelucrare de
recorduri (tupluri) şi nu pe prelucrarea mulţimilor (relaţiilor), acest limbaj nu trebuie s ă fie
utilizat pentru a se evita restricţiile de integritate sau restricţiile 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ă fără cunoa şterea utilizatorului sau a
administratorului bazei de date.
Pe parcursul anilor regulile lui Codd au generat o seamă de controverse. Câteva
argumente sunt că aceste reguli nu sunt mai mult decât nişte exerciţii academice. Unele
revendicări ale produselor existente sunt că ele pot îndeplini cea mai mare parte din reguli,
dar nu toate. Această discuţie a generat o dispută între utilizatori şi teoreticienii asupra
proprietăţilor esenţiale ale unui SGBDR.
Pentru a accentua implicaţia 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 independenţa datelor.

Să ne reamintim...
Abordarea tradiţională bazată pe fişiere are o serie de limitări cum ar fi
Separarea şi izolarea datelor
Duplicarea datelor
Dependenţa datelor
Incompatibilitatea fişierelor
Interogări fixe / proliferarea aplicaţiilor
Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de
aselenizare Apollo
Ideea principală în organizarea datelor se baza pe existenţa a trei componente
de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de date
 subschema - care reprezenta o parte a bazei de date aşa cum e văzută de
utilizator sau de programele de aplicaţie
 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 organizării datelor în fişiere, SGBDR şi teoriei
relaţionale între care se pot stabili analogii

Organizarea datelor în
fişiere
SGBDR Teoria relaţională
Fişier Tabelă Relaţie
Record(înregistrare) Linie Tuplu
Câmp Coloană Atribut

Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte
un SGBD ca să fie relaţional.

Criterii minimale de definire a unui SGBDR

Nici unul dintre SGBDR disponibile astăzi nu respectă întru totul cerinţele 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 cerinţe minimale pa care trebuie să la
satisfacă un sistem de gestiune a bazelor de date pentru a putea fi considerat relaţional.
Un SGBD este minimal relaţional dacă satisface următoarele condiţii:
1. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,
2. Nu există pointeri observabili de către utilizatori în tabele, în sensul că operaţiile cu relaţii
nu fac apel la pointeri, indecşi, fişiere inverse, etc.
3. Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără limitări
impuse de considerente interne (cum ar fi de exemplu, necesitatea indexării atributelor).
Unitatea de informaţie cu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia.
Un SGBD este complet relaţional dacă este minimal relaţional şi satisface în plus
următoarele condiţii:
4. Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări impuse de
considerente interne.
5. Sistemul suportă două dintre restricţiile de integritate de bază al modelului relaţional şi
anume unicitatea cheii unei relaţii şi restricţia referenţială.

Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. şi 3.
Un SGBD cu interfaţă relaţională este un SGBD are satisface condiţiile 1. şi 3., cu
observaţia că cerinţa 3. Este îndeplinită numai în raport cu funcţia de interogare
În ultimii ani, ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu baze de
date (încurajată şi de progresele apărute în programare o dată cu programarea orientata obiect)
au apărut modelul de date orientat obiect (Object-Oriented Data Model - OODM) şi modelul
de date relaţional extins (Extended Relaţional Data Model - ERDM). Cu toate că modelul de
date ce sta la baza noilor modele nu este atât de clar că în cazul modelului relaţional, se poate
considera că aceste din urma dezvoltări reprezintă generaţia a patra de SGBD.
In esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date
aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre
ele), colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi (sau
organizaţii).
Baza de date trebuie să îndeplinească următoarele condiţii:
- să asigure o independenţă sporită a datelor faţă de programe şi invers;
- structura bazei de date trebuie astfel concepută încât să asigure informaţiile necesare şi
suficiente pentru cerinţele de informare şi decizie;
- să asigure o redundanţă minimă şi controlată a datelor;
- să permită accesul rapid la informaţiile stocate în bază.
Bazele de date sunt extrem de variate în funcţie de criteriile luate în considerare. Prezentăm
câteva criterii de clasificare:
- după orientare: generalizate, specializate;
- după modelul de date: ierarhice, reţele, relaţionale, 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 întreţinerea bazei de date şi pe de alta parte,
permite accesul controlat la informaţiile din baza de date în cauză. SGBD este format din
12
programe de software care interacţionează cu programele de aplicaţie ale utilizatorilor şi cu
baza de date. Sistemul de gestiune al bazei de date asigură realizarea următoarelor activităţi:
- definirea structurii bazei de date;
- încărcarea datelor în baza de date;
- accesul la date (interogare, actualizare);
- întreţinerea 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.
Aşadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe
care asigură interfaţa î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 tendinţa ca marea majoritate a sistemelor de gestiune a bazelor de
date să fie compatibile pe platforme cât 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ă activităţile de creare, actualizare şi interogare a
bazei de date, utilizând limbajele de nivel înalt sau extensii ale acestora, proprii sistemului de
calcul pe care se implementează baza de date. Avantajul acestor sisteme constă în
posibilităţile sporite ce le oferă limbajele de nivel înalt la elaborarea unor proceduri complexe.
Sistemele cu limbaj gazdă prezintă dezavantajul că formularea cerinţelor nu este atât de
simplificată ca în cazul sistemelor cu limbaj autonom.
3. Din punctul de vedere al concepţiei de organizare a datelor pe care le gestionează, SGBD
se clasifică în: sisteme de gestiune a bazelor de date cu structuri ierarhice şi reţea; sisteme de
gestiune a bazelor de date relaţionale; 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 apărute în ultima perioadă dispun şi de o
componentă de gestiune distribuită a datelor.

Să ne reamintim...
Un SGBD este minimal relaţional dacă satisface următoarele condiţii:
Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele,
Nu există pointeri observabili de către utilizatori în tabele, în sensul că
operaţiile cu relaţii nu fac apel la pointeri, indecşi, fişiere inverse, etc.
Sistemul suportă operatori relaţionali de proiecţie, selecţie şi join natural, fără
limitări impuse de considerente interne (cum ar fi de exemplu, necesitatea
indexării atributelor). Unitatea de informaţie cu care se lucrează în cadrul
acestor operaţii trebuie să fie relaţia.
Un SGBD este complet relaţional dacă este minimal relaţional şi satisface
în plus următoarele condiţii:
13
Sistemul suportă toate operaţiile de bază ale algebrei relaţionale, fără limitări
impuse de considerente interne.
Sistemul suportă două dintre restricţiile de integritate de bază al modelului
relaţional şi anume unicitatea cheii unei relaţii şi restricţia referenţială.
În esenţă, conceptul de bază de date poate fi definit ca fiind o colecţie partajată
de date aflate în interdependenţă logică (împreună cu o descriere a acestor date
şi a relaţiilor dintre ele), colecţie 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
concepţiei de organizare a datelor pe care le gestionează

M1.U1.6. Rezumat
Conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date
aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a
relaţiilor dintre ele), colecţie desemnată pentru a rezolva nevoia de
informatizare a unei întreprinderi.
Sistemul de baze de date îşi are rădăcinile în anii '60, în proiectul de
aselenizare Apollo
Ideea principală în organizarea datelor se baza pe existenţa a trei componente
de bază:
 schema de reţea - care reprezenta organizarea logica a întregii baze de date
 subschema - care reprezenta o parte a bazei de date aşa cum e văzută de
utilizator sau de programele de aplicaţie
 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 organizării datelor în fişiere, SGBDR şi teoriei
relaţionale între care se pot stabili analogii


Organizarea datelor în
fişiere
SGBDR Teoria relaţională
Fişier Tabelă Relaţie
Record(înregistrare) Linie Tuplu
Câmp Coloană Atribut


14
Unitatea de învăţare 1.2 Abstractizarea datelor



M1.U1.1. Introducere
Un scop important al unui sistem de gestiune al bazelor de date este să poată
asigura o viziune abstractă asupra realităţii. Este necesar să se reţină din mulţimea
vastă de informaţii doar acelea care sunt necesare unei anumite aplicaţii.





M1.U1.2. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 înţeleagă care este structura pe trei nivele a bazei de date
 înţeleagă ce este independenţa logică şi ce este cea fizică şi de ce este
importantă această independenţă




Durata medie de parcurgere a primei unităţi de învăţare este de 2 or e.
Se poate face referire spre exemplu la încercarea de modelare a unei aplicaţii într-o
întreprindere. Trebuie modelate 'obiectele' şi relaţiile dintre ele. Nu realitatea complexă în
totalitatea ei intră în discuţie 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 aplicaţia în cauza). Astfel în cazul modelării 'obiectului' (sau
entităţii) angajat, trebuie alese doar acele proprietăţi (sau atribute) care interesează. Acestea
ar putea fi, de exemplu: numele, adresa, salariul. O mulţime impresionantă de informaţii, 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 albaştri, dacă este blondă
sau brunetă, dacă ascultă cu plăcere muzică sau dacă este o fire sentimentală.


Ce credeţi că ar interesa să memorăm despre studenţi într-o bază de date a
facultăţii?
Ce nu ar trebui memorat?

Mai mult decât 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 informaţiile stocate, funcţie de aplicaţia pe care o dezvoltă.
15
Pentru a se rezolva aceste cerinţe, se apelează la reprezentarea pe nivele a organizării
informaţiilor î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 funcţie de clasa
utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei, după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de viziunea
programatorului de aplicaţii, care realizează programele de aplicaţii pentru manipularea
datelor la nivel de structură logică (subschema) corespunzătoare descrierii datelor aplicaţiei;
- nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care
realizează structura conceptuală (schema) corespunzătoare descrierii întregii baze de date şi
administrează componentele bazei de date. Acest nivel descrie ce date sunt memorate în baza
de date şi ce relaţii sunt stabilite între date. Nivelul conceptual reprezintă:
- toate entităţile, atributele lor şi relaţiile dintre ele;
- restricţiile impuse datelor
- informaţiile semantice despre date
- informaţiile privitoare la securitatea şi integritatea datelor.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică
corespunzătoare descrierii datelor pe suportul fizic (periferic). Acest nivel descrie cum sunt
memorate datele în baza de date. Nivelul intern se ocupă de:
- alocarea spaţiului de memorie pentru date şi indecşi;
- descrierea înregistrărilor pentru memorare;
- plasarea înregistrărilor 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 funcţie
de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,
după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern. Este dat de
viziunea programatorului de aplicaţii
- nivelul conceptual (global). Este dat de viziunea administratorului bazei
de date, care realizează structura conceptuală (schema) corespunzătoare
descrierii întregii baze de date şi administrează componentele bazei de date.
- nivelul fizic. Este dat de viziunea inginerului de sistem care realizează
structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic).


Scheme, corespondenţe şi instanţe
Descrierea generala a unei baze de date se numeşte 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 relaţiile
între ele, precum şi restricţiile de integritate. Schemei conceptuale îi corespunde o schemă
internă care descrie organizarea fizică a datelor.
SGBD realizează corespondenţa între cele trei nivele de abstractizare, realizând
corespondenţa între cele trei tipuri de scheme. Astfel corespondenţa conceptual / intern
leagă schema conceptuală de schema internă. Datorită acestei corespondenţe se identifică
înregistrarea sau combinaţia de înregistrări la nivel fizic, care constituie înregistrarea logică
în schema conceptuală, împreună cu restricţiile de integritate corespunzătoare. Analog, fiecare
schemă externă este legată de schema conceptuală prin corespondenţa extern / conceptual.
Aceasta corespondenţă permite SGBD să facă legătura între numele din view-urile utilizator
şi partea corespunzătoare relevantă din schema conceptuală. Este de reţinut că trebuie să
facem distincţie între descrierea bazei de date (schema bazei de date) şi baza de date propriu-
zisă. Numim instanţa (în cazul unei baze de date) datele aflate în baza de date la un anumit
moment dat. Altfel spus, mai multe instanţe pot să corespundă aceleiaşi scheme conceptuale
pentru o bază de date.
17

Să ne reamintim...
Descrierea generala a unei baze de date se numeşte 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ă.


Independenţa datelor
Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea
independenţei datelor. O aplicaţie, în general, este dependentă de date în sensul că
modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi
aplicaţia. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele
considerente:
- diferite aplicaţii au nevoie de viziuni diferite asupra aceloraşi date;
- administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare
sau strategia de acces, ca răspuns la cerinţe (schimbări de standarde, priorităţile aplicaţiilor,
unităţile de memorare etc.), fără a modifica aplicaţiile existente, baza de date existentă,
precum şi programele de exploatare a ei, care au fost folosite o perioadă de timp şi care
reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor.
De aceea, se impune ca atunci când apar noi cerinţe în cadrul sistemului informaţional,
sistemele informatice să poată funcţiona cu programele şi procedurile existente, iar datele
existente să poată fi convertite.
Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi
independenţa logică a datelor.
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să
poată fi modificate fără a determina rescrierea programelor de aplicaţie. Aşadar independenţa
fizică a datelor reprezintă gradul de imunitate a schemei conceptuale la schimbările suferite
de schema internă.
Independenţa logică a datelor se refera la posibilitatea adăugării de noi înregistrări sau la
extinderea structurii conceptuale (globale), fără ca acest lucru să impună rescri erea
programelor existente. Cu alte cuvinte independenţa logică a datelor reprezintă gradul de
imunitate a schemelor externe la schimbările suferite de schema conceptuală.

Să ne reamintim...
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de
memorarea să poată fi modificate fără a determina rescrierea programelor de
aplicaţie.
Independenţa logică a datelor se referă la posibilitatea adăugării de noi
înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest lucru
să impună rescrierea programelor existente.
18



M1.U1.6. Rezumat
Componentele bazei de date pot fi structurate pe trei nivele, în funcţie
de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei,
după cum urmează:
- nivelul logic de vizualizare (view) sau nivelul extern.
- nivelul conceptual (global
- nivelul fizic
Descrierea generală a unei baze de date se numeşte 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ă.
Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de
memorarea să poată fi modificate fără a determina rescrierea programelor de
aplicaţie.
Independenţa logică a datelor se referă la posibilitatea adăugării de noi
înregistrări sau la extinderea structurii conceptuale (globale), fără ca acest
lucru să impună rescrierea programelor existente.



M1.U1.2. Test de autoevaluare a cunoştinţelor
1.2.1 Ce ar trebui memorat despre profesori într -o bază de date a facultăţii?
1.2.2 Ce nu ar trebui memorat despre profesori într-o bază de date a
facultăţii?
1.2.3 Ce este arhitectura pe trei nivele?
Răspunsurile se găsesc la sfârşit la pag 147









19
Unitatea de învăţare 1.3 Principalele componente şi funcţiuni al e unui SGBD




M1.U1.3. Introducere
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:



M1.U1.3. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 descrie componenţa unui Sistem de Gestiune al Bazei de Date
 cunoască obiectivele unui SGBD
 cunoască şi să utilizeze funcţiunile unui SGBD



Durata medie de parcurgere a primei unităţi de învăţare es te de 2 ore.
Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune, care se diferenţiază:
- prin limbajele utilizate,
- prin anumite componente ce imprimă diferite facilităţi 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 atât în regim local cât şi în regim de teleprelucrare,
ajungem la concluzia că nu poate fi stabilită o arhitectură unică, valabilă pentru toate
sistemele, ci apar particularităţi de la un sistem la altul.
Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde
internaţionale. O astfel de arhitectură generală cuprinde următoarele componente:
- baza de date propriu-zisă în care se memorează colecţia 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 reglementările administrative,
destinate bunei funcţionări a întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine informaţii despre date,
structura acestora, elemente de descriere a semanticii, statistici, documentaţie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali - (neinformaticieni); de specialitate
(administrator), analişti - programatori, gestionari, operatori).
Arhitectura bazei de date dă o imagine despre modul general de organizare şi funcţionare a ei.
Să detaliem câteva 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 construcţii adecvate oricăror necesităţi de calcul, asemănătoare cu structurile puse la
dispoziţie 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 funcţii. Fişierul preprocesat este
compilat, plasat într-un modul obiect, link-editat cu o bibliotecă în care se află funcţiile
înlocuite, furnizate o dată cu SGBD, şi este executat când 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ă entităţile şi
relaţiile care se pot stabili între acestea.
Schema bazei de date este definita cu ajutorul LDD. Rezultatul compilării declaraţiilor
în acest limbaj este constituit dintr-o serie de tabele memorate într-un Fişier special numit
dicţionar de date (se mai utilizează şi termenii de catalog de date sau director de date).
Datele memorate în acest dicţionar sunt date despre date şi de aceea se mai numesc şi
metadate. Definiţiile din dicţionarul de date se refera la înregistrări, la datele din înregistrări
şi la alte obiecte ce compun baza de date. SGBD consulta dicţionarul de date înaintea oricărui
acces la informaţii.
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 operaţii care suporta
operaţiile de manipulare de baza asupra datelor din baza de date. Operaţii de baza sunt
inserarea, ştergerea, modificarea şi regăsirea 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ă înregistrările individual şi specifica cum trebuie obţinut rezultatul unei interogări. Cu
alte cuvinte trebuie să se specifice un algoritm de prelucrare a înregistrărilor cu ajutorul
operaţiilor puse la dispoziţie de limbaj.
În contrast, un LMD non-procedural specifica doar ce fel de rezultat trebuie obţinut.
SGBD translatează cererea din limbaj non-procedural transformând-o într-o procedura sau
într-o serie de proceduri care manipulează datele conform cererii utilizatorului. Limbajele
non-procedurale sunt mai uşor de utilizat deoarece scutesc utilizatorii de la a cunoaşte
implementarea interna a structurilor de date şi de la a stabili algoritmi de obţinere a
informaţiilor.
Partea componenta a unui LMD care se refera la regăsirea datelor se numeşte limbaj
de interogare. Înţelegem 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 Generaţia a Patra). Nu există
încă un consens asupra semnificaţiei 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 generaţia a treia, poate să constituie câteva zeci de linii de
program într-un limbaj de generaţia 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 aplicaţie pe baza parametrilor respectivi. Un
avantaj important al utilizării 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 aplicaţii, etc.
Exemple de limbaje de interogare 4GL sunt SQL şi QBE, limbaje comerciale asupra
cărora vom reveni ulterior.
Generatoare de ecrane
Un generator de ecrane este un tool cu ajutorul căruia se pot crea uşor şi rapid ecrane
pentru culegerea (introducerea) informaţiilor 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, acelaşi lucru se realizează cu ajutorul unei
facilităţi grafice similare cu generatorul de ecrane.
Generatoare de grafice
Un astfel de generator este o facilitate care regăseşte date din baza de date şi afişează
aceste date sub forma unor grafice.
Generatoare de aplicaţii
Utilizarea unui generator de aplicaţii poate reduce timpul necesar realizării unei
aplicaţii unitare. Generatoarele de aplicaţii constau în module predefinite care cuprind
majoritatea funcţiilor de baza ce sunt prezente în majoritatea programelor. Aceste module
constituie o biblioteca de funcţii la dispoziţia utilizatorilor.

22

Să ne reamintim...
Arhitectura unui SGBD cuprinde următoarele componente:
- baza de date propriu-zisă în care se memorează colecţia 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
reglementările administrative, destinate bunei funcţionări a
întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine
informaţii despre date, structura acestora, elemente de descriere
a semanticii, statistici, documentaţie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analişti -
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 informaţii necesare luării
deciziilor, în condiţii de eficienta economica sporita.
In aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de
cerinţe prin care să se asigure:
- minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la
întrebările solicitate de utilizatori;
- adaptarea facilă a sistemului informatic la evoluţia în timp a sistemului informaţional
din care face parte;
- posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanţii de
sistem;
- posibilitatea folosirii sistemului de informare dispunând de un minim de cunoştinţe
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 independenţei datelor.
Aşa cum am arătat mai devreme, acest obiectiv consta în linii mari din îndeplinirea următoarei
cerinţe: modificările 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 redundanţe 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 încât, pe cât posibil, fiecare informaţie să apară o singură dată.
Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performante sporite (mai ales în
ce priveşte timpul de acces la date şi implicit, timpul de răspuns la solicitările utilizatorilor) să
se accepte o anumita redundanta a datelor. în acest caz se va institui insa un control automat al
redundantei în vederea asigurării coerenţei datelor din baza.
3. Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta presupune:
- folosirea datelor de câtre mai mulţi utilizatori în diferite scopuri (aplicaţii);
- accesul cât mai simplu al utilizatorilor la date, fără ca aceştia să fie nevoiţi să cunoască
structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei
de date;
- existenta unor limbaje performante de regăsire a datelor, care permit exprimarea cu
uşurinţă a criteriilor de selecţie a datelor şi indicarea unor reguli cât mai generale pentru
editarea informaţiilor solicitate;
- spre deosebire de sistemul tradiţional bazat pe Fişiere, unde există un singur criteriu
de adresare (cel care a stat la baza organizării Fişierului) în cazul bazelor de date,
sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial, fără sortări
suplimentare. Modificarea criteriului la fişierele clasice implică, în majoritatea
cazurilor, reorganizarea lor;
- utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării
bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod
facil a bazei de date şi de câtre 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 corespunzătoare, şi poate, totodată, defini verificări de autorizare care să se realizeze
oricând se încearcă accesul la anumite date.
5. Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,
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 partajabilităţii datelor. Partajabilitatea datelor trebuie înţeleasă nu numai sub
aspectul asigurării accesului mai multor utilizatori la aceleaşi date, ci şi sub acela al
posibilităţii dezvoltării unor aplicaţii fără 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 facilităţi sporite de utilizare a datelor. Aceasta
presupune:
Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate
sau neintenţionate.
Asigurarea partajabilităţii datelor.
24

Funcţiile unui SGBD
Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea
numeroaselor operaţii necesare funcţionării optime a sistemului. În funcţie de natura lor şi de
scopul urmărit, operaţiile pot fi grupate pe activităţi. Activităţile acceptă şi ele o grupare pe
funcţii (una sau mai multe activităţi, relativ omogene, re alizează o anumita funcţie).
Ţinând seama de complexitatea sistemului de gestiune, de facilităţile oferite de acesta, de
limbajele utilizate şi de tipul bazei de date ce urmează a fi gestionată de SGBD, gruparea
activităţilor pe funcţii are un oarecare caracter relativ. În situaţia sistemelor de gestiune ce
utilizează limbaje gazdă de nivel înalt, identificarea şi delimitarea funcţiilor nu este atât de
evidentă. Totuşi, în ciuda acestor particularităţi, se pot prezenta câteva funcţii cu caracter de
generalitate pentru toate sistemele de gestiune a bazelor de date şi anume:
1. Funcţia 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 funcţie asigură:
- descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,
- descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiaşi
entităţi,
- definirea eventualelor criterii de validare a datelor,
- definirea metodelor de acces la date,
- definirea aspectelor referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc.
Toate acestea se concretizează în schema bazei de date, memorată în cod intern.
2. Funcţia de manipulare a datelor este cea mai complexa funcţie şi realizează următoarele
activităţi:
- crearea (încărcarea) bazei de date;
- adăugarea de noi înregistrări;
- ştergerea unor înregistrări;
- modificarea valorilor unor câmpuri;
- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc.
Funcţia de manipulare a datelor se realizează prin intermediul limbajului de
manipulare a datelor.
3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor
utilizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Aceştia reprezintă categoria beneficiarilor de
informaţii (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, realizând proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea
ce priveşte funcţionarea optimă a întregului ansamblu.
25
4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de
competenţa administratorului bazei de date.

Să ne reamintim...
Funcţiunile unui SGBD sunt:
Funcţia de descriere a datelor permite definirea structurii bazei de
date cu ajutorul limbajului de definire.
Funcţia de manipulare a datelor.
Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date.
Funcţia de administrare a bazei de date apare ca o funcţie
complexă şi este de competenţa administratorului bazei de date.



M1.U1.6. Rezumat
Arhitectura unui SGBD cuprinde următoarele componente:
- baza de date propriu-zisă în care se memorează colecţia 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
reglementările administrative, destinate bunei funcţionări a
întregului sistem;
- un dicţionar al bazei de date (metabaza de date), ce conţine
informaţii despre date, structura acestora, elemente de descriere a
semanticii, statistici, documentaţie etc.
- mijloacele hard utilizate (comune, specializate etc.);
- personalul implicat: (categorii de utilizatori: finali -
(neinformaticieni); de specialitate (administrator), analişti -
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 informaţii necesare luării deciziilor, în condiţii de
eficienta economica sporita.
Obiectivele sunt:
Asigurarea independentei datelor.
Acest obiectiv consta în îndeplinirea cerinţei ca modificările 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 cât posibil, fiecare informaţie să apară o singură dată. Nu sunt
excluse nici cazurile în care să se accepte o anumită redundanţă a
datelor.
Asigurarea unor facilităţi sporite de utilizare a datelor.
Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau
neintenţionate, 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 partajabilităţii datelor. Partajabilitatea datelor trebuie
înţeleasă şi sub aspectul posibilităţii dezvoltării unor aplicaţii fără a se
modifica structura bazei de date.
Funcţiunile unui SDGBD sunt
Funcţia de descriere a datelor care permite definirea structurii bazei
de date cu ajutorul limbajului de definire.
Funcţia de manipulare a datelor este cea mai complexă funcţie şi
realizează următoarele activităţi:
- crearea (încărcarea) bazei de date;
- adăugarea de noi înregistrări;
- ştergerea unor înregistrări;
- modificarea valorilor unor câmpuri;
- căutarea, sortarea şi editarea parţială sau totală a unei înregistrări
virtuale etc.
Funcţia de manipulare a datelor se realizează prin intermediul
limbajului de manipulare a datelor.
Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru
comunicarea tuturor utilizatorilor cu baza de date. Sunt recunoscute mai
multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Ei apar ca utilizatori
neinformaticieni;
- utilizatori programatori, care utilizează limbajele de manipulare,
realizând proceduri complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are
rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului
ansamblu.
Funcţia de administrare a bazei de date apare ca o funcţie complexă
şi este de competenţa administratorului bazei de date.

M1.U1.3. Test de autoevaluare a cunoştinţelor
1.3.1 Care sunt obiectivele unui SGBD?
1.3.2 Care sunt funcţiunile unui SGBD?
Răspunsurile se găsesc la sfârşit la pag 149
27
Unitatea de învăţare 1.4 Baze de date distribuite





M1.U1.4 Introducere
O baza de date distribuită (BDD) este o colecţie logic corelată de date
partajate, distribuite fizic pe o reţea 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
informaţii". Ele au apărut ca o necesitate, în special in cazul reţelelor de
calculatoare, pentru a sprijini gestionarea datelor în situaţia când acestea se
regăsesc fizic în diferite puncte ale reţelei.




M1.U1.4. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 înţeleagă ce este o bază de date distribbuită
 cum se proiectează o bază de date distribuită



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
Generalităţi
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 (reţeaua) care constituie suportul unei baze de date distribuite poate fi
format din calculatoare personale, minicomputere, staţii de lucru, etc. toate legate în reţea şi
numite generic site-uri.
Putem reformula definiţia de la început spunând ca un sistem de baze de date
distribuite constă dintr-o colecţie de site-uri, fiecare putând participa la executarea
tranzacţiilor care accesează datele de pe un site sau de pe mai multe site -uri.
Printre cerinţele pe care trebuie să le asigure un sistem de baze de date distribuite
menţionăm: autonomia locala în organizarea şi prelucrarea datelor, neutilizarea unei
centralizări a evidenţei şi a datelor, posibilitatea de lucru continuu al site-urilor independent
de schimbările in configuraţiile de lucru (adăugari sau eliminari de site-uri), independenţa
localizării şi fragmentării datelor (transparenţa fizică), posibiliăţti de replicare (copiere) şi
independenţa copiilor, prelucrarea distribuită a cererilor, administrarea distribuită a
tranzacţiilor, independenţa de hardware, de sistemul de operare, de reţea ş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
interogări utilizator în regim local, independent de restul reţelei, sau este capabil să participe
la procesarea unor date situate în alte site-uri din reţea. Pentru a spune că un SGBD este
distribuit trebuie să existe cle puţin o cerere globală.
Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi
tranzacţii 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 organizaţională a multor
organizaţii, 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ă decât în cazul centralizat. Dacă se
semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să
continue să funcţioneze în condiţii satisfăcătoare
- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând
replici aflate pe alte site-uri
- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în
paralel a unor interog[ri
- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile
implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem
centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest
lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la
nevoile organiza’iei (dac[ de exemplu este necesară adăugarea unor site-uri în plus) decât
un calculator central de putere asemănătoare
- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau
rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta
deloc) mersul activităţilor 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 comunicaţii de date (CD)
- un dicţionar de date global (DDG). Acest dicţionar are aceeaşi funcţionalitate ca şi und
dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare
la fragmentare şi la alocarea datelor. Şi DDG poate fi fragmentat şi replicat ca orice altă
informaţie din baza de date distribuită
- componente de SGBD distribuit (SGBDD)

Proiectarea unei baze de date relaţionale distribuite
Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele
cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate
pe diferite site-uri în reţea
- replicarea – se pot realiza copii ale diferitelor relaţii 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 aplicaţia 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 creşte 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 relaţională distribuită:
1. centralizat
Baza de date se află în întregime pe un singur site din reţea ş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 cuvântului. Dezavantajele sunt mai ales
costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în
vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga
activitate în reţea pe această direcţie.
2. fragmentat (partiţionat)
Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale
- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat
- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute
3. replicat complet
Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:
- eficienţa 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 combinaţie intre partiţionare, replicare şi centralizare cu scopul de
a se cumula, pe cat posibil, avantajele fiecărei 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 aplicaţii deoarece nu se poate realiza o
alocare care sa optimizeze toate aplicaţiile simultan.
Printre criteriile care duc la decizia corecta de alocare a bazei de date:
- frecventa cu care se ruleaza o aplicaţie
- site-urile de la care se ruleaza cel mai frecvent aplicaţia
- modul de lucru al tranzactiilor executate de aplicaţie ş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 aplicaţie 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ă relaţia R este descompusă în fragmentele R
1
, R
2
, …,R
n
, trebuie
luate măsuri care să prevină pierderea de informaţii
2. reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit
cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.
3. disjuncţie – 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 excepţie, cazul când o relaţie
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 relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor
relaţiei respective.
Un fragment orizontal se produce prin selecţie:
Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte
reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.
R= R
1
R
2
…R
n

In general fragmentele unei relaţii R sunt disjuncte.
Fragmentarea pe verticală
Un fragment vertical dintr-o relaţie consta dintr-o relaţie care are ca atribute o submulţime a
atributelor relaţiei iniţiale.



Un fragment vertical se produce prin proiecţie:
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 puţin într- una din
submulţimile S
1
şi S
2
.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.
2 1
) ( r X r R r
N
=
Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care
asigură o descompunere fără pierderi la joncţiune.
In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se
admite existenţa unor atribute comune, şi anume a atributelor care formează cheile primare
(respectiv cheile externe). Fragmentele verticale se stabilesc prin determinarea afinităţilor
între atribute, încă din faza de analiză.
Fragmentarea combinată (mixtă, hibridă, compusă)
1. fragmente verticale fragmentate orizontal



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

2. fragmente orizontale fragmentate vertical



Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai
sus) este: )) ( (
,...,
1
R
P A A
n
o H

Transparenţa î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 transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de
transparenţă:
1. transparenţa distribuirii
2. transparenţa tranzacţiilor
3. transparenţa performanţelor

Transparenţa distribuirii
34
Dacă se realizează transparenţa 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 (transparenţa fragmentării) sau utilizatorul
nu ştie de localizarea datelor pe reţea (transparenţa localizării).
Transparenţa fragmentării este cel mai înalt grad de transparenţa. Utilizatorul se
adresează cu interogări bazei de date ca şi când ar fi localizată centralizat, deci nu trebuie să
se preocupe de existenţa fragmentelor.
Transparenţa fragmentării este strâns 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 conţine 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
aplicaţii 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 aplicaţiile 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.
Transparenţa tranzacţiilor
Acest tip de transparenţa asigură faptul că toate tranzacţiile distribuite păstrează
integritatea şi consistenţa BDD.
O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Fiecare
tranzacţie e divizata în sub-tranzacţii, câte una pentru fiecare site accesat. Sub-tranzacţiile se
execută în paralel pe site-uri şi în mod concurent pe fiecare site. SGBDD are sarcini deosebite
în legătură cu gestionarea tranzacţiilor distribuite dar acestea nu vor fi tratate in acest capitol.
În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa
concurenţei şi transparenţa erorilor. SGBDD oferă transparenţă concurenţei dacă rezultatele
tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic
echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând, într-o
ordine serială arbitrară.
Transparenţa erorilor necesită şi un mecanism de recovery care ne să asigure că
tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei
tranzacţii ori nici o operaţie nu este executată. Odată ce o tranzacţie s-a executat,
transformările operate de ea asupra bazei de date sunt durabile (permanente).
Transparenţa performanţelor
Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă
performanţe comparabile cu ale unui sistem centralizat. În această situaţie 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 locaţie se utilizează. DQP produce o strategie de execuţie care este optimizată relativ la o
funcţie 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 colecţie logic corelată de date partajate,
distribuite fizic pe o reţea de calculatoare.
Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi
tranzacţii globale după site-urile pe care le solicită excutarea lor.
Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă
cerinţele cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi
stocate pe diferite site-uri în reţea
- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor
- alocarea fragmentelor şi a replicilor pe diferite site-uri
36
Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională
distribuită:
centralizat
fragmentat (partiţionat)
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 transparenţa poate fi realizată doar într-o anumită măsură. Tipuri de
transparenţă:
- transparenţa distribuirii
- transparenţa tranzacţiilor
- transparenţa performanţelor




M1.U1.4. Test de autoevaluare a cunoştinţelor
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 alocării datelor?
1.4.4 Cum se face o fragmentare corectă?
1.4.5 Ce este fragmentarea?
Răspunsurile se găsesc la sfârşit la pag 149








37
Modulul 2. Modele de descriere a datelor



Cuprins
Introducere
Obiectivele modulului
U2.1 Generalităţi
U2.2 Modelare E-R (Entity-Relaţionship)



Introducere
Numim model de date o colecţie integrată de concepte pentru
descrierea datelor, de relaţii între date şi de restricţii asupra datelor,
toate într-o organizare unitară.
Un model de date este o abstracţie. Un model de date are în
principal rolul de a furniza conceptele de bază şi notaţiile care să
permită proiectanţilor şi utilizatorilor bazei de date să comunice în
mod neambiguu legat de modul de organizare a datelor.





M3. Obiectivele modulului
La sfârşitul acestui modul studenţii vor fi capabili să:
 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 relaţii în mod optim










38
Unitatea de învăţare 2.1. Generalităţi



M2.U2.1. Introducere
Un model de date cuprinde trei părţi:
(1) o parte referitoare la structură, care constă într-un set de reguli ce impun
modul de alcătuire al bazei de date;
(2) o parte referitoare la manipularea datelor, care defineşte tipul de operaţii care
sunt permise asupra datelor. Sunt incluse aici operaţiile care sunt utilizate
pentru a actualiza sau a regăsi datele în baza de date precum şi operaţiile
pentru schimbarea structurii bazei de date;
(3) o parte referitoare la integritatea datelor, parte care cuprinde reguli de
integritate care asigura acurateţea datelor.




M2.U2.1. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 aleagă ce model de date vor folosi pentru baza concretă de date
 distingă modele la diferite nivele



Durata medie de parcurgere a primei unităţi de învăţare 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ă aşa-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 menţionam aici: modelele de
date bazate pe obiecte, modelele de date bazate pe înregistrare, ambele modele fiind utilizate
pentru descrierea organizării datelor la nivel extern şi conceptual. Trebuie să menţionam şi
modelele fizice de date, care descriu dat ele la nivel intern.
Aceste modele utilizează concepte specifice modelului E-R şi anume: entităţi, atribute,
relaţii. Cele mai cunoscute modele de date sunt: modelul entitate-relaţie, modelul semantic,
modelul funcţional, modelul orientat obiect.
Modele de date bazate pe înregistrare
Într-un astfel de model baza de date consta dintr-un număr de înregistrări de format fix
de tipuri eventual diferite. Fiecare tip de înregistrare defineşte un număr fix de câmpuri,
39
fiecare fiind în general de lungime fixa. Exista trei tipuri importante de modele de date bazate
pe înregistrare: modelul de date relaţional, modelul de date reţea şi modelul ierarhic de
date.
Modelele ierarhic şi reţea au fost dezvoltate mai întâi, modelul relaţional apărând cu o
întârziere de un deceniu.
Modele fizice de date
Aceste modele descriu efectiv modul în care datele sunt memorate în calculator, la
nivel fizic. Informaţia furnizata de aceste modele este cea referitoare la înregistrările fizice, la
căi de acces, la organizarea înregistrărilor, etc.
Se considera că schema conceptuala sta la baza structurării unei baze de date. O
schema conceptuala completa şi bine gândită permite o reprezentare interna eficienta şi
permite realizarea de view-uri utilizator fără 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 informaţia de câtre
beneficiar, reprezentare care este independenta de detaliile de implementare cum ar fi
programele de aplicaţie, limbajele de programare, SGBD-ul utilizat sau orice alte consideraţii
fizice. Un astfel de model se numeşte model de date conceptual sau model logic.

Modelare E-R (Entity-Relaţionship)
Modelul E-R (Entity-Relaţionship) 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 restricţiilor de cardinalitate. Având î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-relaţie, modelul
semantic, modelul funcţional, modelul orientat obiect.
Exista trei tipuri importante de modele de date bazate pe înregistrare: modelul de
date relaţional, modelul de date reţea şi modelul ierarhic de date.
Modele fizice de date descriu efectiv modul în care datele sunt memorate în
calculator, la nivel fizic.

40

M2.U2.1. Test de autoevaluare a cunoştinţelor
2.1.1 Care sunt modele de date bazate pe înregistrare?
Răspunsurile se găsesc la sfârşit la pag 152



























41
Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship)



M2.U2.2. Introducere
Modelul E-R constituie un mod de reprezentare a bazelor de date relaţionale
ş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 apărea prin utilizarea unui astfel de model. Vom
discuta de asemenea problemele generate prin utilizarea modelul E-R la
reprezentarea unor aplicaţii.



M2.U2.2. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 descrie structura bazei de date cu ajutorul unui model grafic
 să aleagă cheia unei relaţii în mod optim



Durata medie de parcurgere a primei unităţi de învăţare est e de 3 ore.
Concepte de bază
Conceptele primare ale modelului E-R includ : tip de entitate (mulţime-entitate), tip de
relaţie (mulţime-relaţie), atribute.
Numim entitate un obiect sau un concept ce se poate identifica în mod unic.
Noţiunea 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, numărul: 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 numărul sau şi numele băncii.
Numim tip de entitate sau mulţime-entitate un set de entităţi de acelaşi tip.

Exemple
Mulţimea tuturor persoanelor care sunt studenţi ai Facultăţii de Ştiinţe pot defini
mulţimea-entitate sau tipul de entitate student.


Mulţimea tuturor profesorilor Facultăţii de Ştiinţe formează ce?
42
Tipul de entitate reprezintă o mulţime de 'obiecte' ce aparţin lumii reale şi care sunt descrise
de aceleaşi proprietatea.
Orice obiect care aparţine unui tip de entitate şi care este identificabil în mod unic este numit
simplu entitate. (se mai întâlnesc denumirile: apariţia unei entităţi sau instanţa unei entităţi).
Un tip de entitate conţine mai multe entităţi. O baza de date este o colecţie de tipuri de entitat e
din care fiecare conţine un număr neprecizat de entităţi de acelaşi tip.
Tipurile de entitate nu sunt neapărat disjuncte. Aceasta înseamnă că pot exista entităţi care să
aparţină mai multor tipuri de entitate.

Exemple
Se pot defini următoarele tipuri de entitate: profesor, corespunzător tuturor
cadrelor didactice ale Facultăţii de Ştiinţe şi student, corespunzător tuturor
studenţilor aceleiaşi facultăţi. Se observa uşor că pot exista studenţi care sunt
în acelaşi timp şi cadre didactice (studenţi la master care sunt preparatori sau
asistenţi).


Arătaţi 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
conţine în general mai multe tipuri de entităţi.
Numim atribute proprietăţile ataşate unui tip de entitate.

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


Cum aţi descrie entitatea materii?
Prin domeniul atributului înţelegem mulţimea valorilor care pot fi atribuite unui atribut
simplu.
Atributele unei entităţi conţin valorile care descriu fiecare entitate şi cu ajutorul cărora 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_naşterii se poate descompune în subdomeniile: an, lună, zi.
In general putem considera că fiecare entitate este reprezentabila cu ajutorul unei mulţimi de
perechi de forma (nume_atribut, valoare_atribut), cate o pereche pentru fiecare atribut ataşat
tipului de entitate corespunzător.
43

Exemple
O entitate a tipului de entitate student poate fi reprezentata de mulţimea:
{(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), (număr_matricol, 31455), (grupa, 7211)}


Reprezentaţi 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 corespunzător tipului de entitate student.


Arătaţi 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, număr, oraş,
cod_poştal şi judeţ.

Arătaţi 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 numărul minim şi numărul 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 numărul numerelor de telefon la care poate fi găsit studentul la
44
minim 0 şi la maxim 3. Deci se pot stabili numărul minim şi numărul maxim de
valori pe care le poate lua atributul.

Arătaţi alte atribute cu mai multe valori.
Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai
multe alte atribute. Aceste atribute nu trebuie neapărat să descrie entitatea căreia ii corespunde
atributul derivat.

Exemple
Valoarea pentru atributul vârsta este derivată din valoarea atributului
data_naşterii şi din data curentă.

Arătaţi alte atribute derivate.
Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile
î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 numărul sau şi
numele băncii.
 Numim tip de entitate sau mulţime-entitate un set de entităţi de
acelaşi tip.
 Prin domeniul atributului înţelegem mulţimea 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 cărui 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 conţine elemente grafice cum ar fi:
- dreptunghiuri, care reprezintă tipuri de entitate;
- elipse, care reprezintă atribute;
- linii, care au rolul de a evidenţia legăturile î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 măsură ce vom defini noi
concepte vom reveni cu precizări legate de modul de a le reprezenta.
Un atribut se reprezintă printr-o elipsă, legată de entitatea căreia î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 entităţii locatari
În exemplu entitatea locatari are următoarele atribute: număr_matricol, nume şi
adresa. Dintre aceste atribute, atributul adresa este atribut compus, care se
descompune în număr_bloc, scara, etaj şi apartament. Explicaţia sublinierii
atributului număr_matricol se va da în secţiunea care se ocupa de chei, tot în
această unitate de învăţare.


Desenaţi structura corespunzătoare tipului de entitate student.

Numim tip de relaţie orice asociere între tipuri de entităţi.
Numim relaţie orice asociere între entităţi, când 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 relaţie este o submulţime a următoarei
mulţimi:
{( 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 relaţie.

Exemple
Într-o aplicaţie care ar servi unor evidente în cadrul asociaţiilor de locatari putem
considera tipul de entitate locatari descris de atributele: nume, adresa şi
număr_matricol şi tipul de entitate scări descris de atributele număr_de_bloc şi
scara. Între tipul de entitate scări şi tipul de entitate locatari se poate stabili un
tip de relaţie numit este_locuita_de. Acest tip de relaţie va conţine relaţii de tipul
('Scara A', 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu
Ion".


Descrieţi relaţiile care apar între student şi catalog.

locatari
num
e
numãr
matric
ol
adres
a
adres
a
adres
a
adres
a
adres
a
adres
a
numãr
bloc


scara

etaj
apartam
ent

46
Numim gradul relaţiei numărul entităţilor participante în relaţie. Aşadar relaţia reprezentată
mai sus are gradul n. Entităţile implicate într-o relaţie se numesc participanţi. Dacă într-o
relaţie sunt doi participanţi, atunci relaţia se numeşte binară.
Tipurile de relaţii se reprezintă în diagramele E-R cu ajutorul romburilor care sunt etichetate
cu numele tipului de relaţie.

Exemple










Reprezentarea cu diagrama E-R a relaţiei este_locuita_de

Reprezentaţi relaţia dintre student şi catalog.

Funcţia pe care o joaca o entitate într-o relaţie se numeşte rolul entităţii. în general nu este
necesar să se specifice rolul entităţilor într-o relaţie, deoarece acesta este în general implicit.
Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. în
acest caz este necesar să se precizeze rolurile entităţilor implicate. În cazul relaţiilor recursive,
în diagrama E-R corespunzătoare, cele două arce de la entitate la relaţie şi înapoi, primesc
diferite etichete, care sunt importante în înţelegerea corectă a relaţiei.


Exemple
Dacă am considera entităţile lucrători şi manageri care se refera la personalul
aceleiaşi întreprinderi, am face constatarea că sunt descrise de aceleaşi atribute
deci aparţin aceluiaşi tip de entitate şi anume angajaţi. Relaţia binara
lucrează_pentru, stabilita între lucrători şi manageri este o relaţie recursiva.
Rolurile jucate de fiecare entitate se pot stabili recurgându-se la perechi ordonate
(muncitor, manager).



Exemple



1 M
locatari scări
număr
matric
ol
nume
adre
sa
numă
r de

bloc
scar
a
este
locuită

angajaţi
lucrează
pentru
lucrator
manager
47

Reprezentarea cu diagrama E-R a relaţiei recursive lucrează_pentru
Astfel relaţia ('Popescu Ion', 'Ionescu Gheorghe') se interpretează "Popescu Ion
lucrează pentru (este subordonatul lui) Ionescu Gheorghe".


Daţi un exemplu de relaţie recursivă legată de entitatea profesor.
Unui tip de relaţie i se pot asocia atribute descriptive în acelaşi mod în care se pot asocia
atribute unui tip de entitate.

Exemple
Tipului de relaţie este_locuita_de, care implica tipurile de entitate scări ş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
relaţie şi el nu mai are sens în afara ei.


Să ne reamintim...
 Numim relaţie orice asociere între entităţi, când asocierea include cate o
entitate pentru toate tipurile de entitate participante.
 Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile
implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi
participanţi, atunci relaţia se numeşte binară.
 Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în
roluri diferite. în acest caz este necesar să se precizeze rolurile entităţilor
implicate.

Restricţii structurale
Este posibil să se stabilească diverse restricţii la care conţinutul unei baze de date
trebuie să se conformeze. Vom trata în continuare restricţiile care se pot impune entităţilor
participante într-o relaţie. Aceste restricţii trebuie să reflecte caracteristicile relaţiilor aşa cum
se percep în 'lumea reala'. Doua tipuri importante de restricţii sunt de menţionat aici: restricţii
de cardinalitate şi restricţii de participare.
a) Restricţii de cardinalitate Numim cardinalitate (polaritate) numărul relaţiilor posibile
pentru o entitate participantă. Altfel spus, cardinalitatea exprima numărul entităţilor la care o
alta entitate poate fi asociata prin intermediul unei relaţii.
Observaţie: Am utilizat în definiţia de mai sus referiri la entităţi şi la relaţii pentru a fi mai
expliciţi. Restricţiile structurale se refera insa în mod evident la tipurile de relaţie şi la tipurile
de entitate asociate. Această observaţie rămâne valabila şi în consideraţiile ce urmează.
Majoritatea tipurilor de relaţie 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).
Relaţiile unu-la-unu:
48
În relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel mult
o entitate din celalalt tip de entitate implicat în relaţia respectiva. Implicarea fiecarei entitati
într-o relaţie data este numita "participarea entitatii".
In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu cardinalul
relaţiei; în cazul relaţiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1.
Relaţiile unu-la-mai-multe:
In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de entitate, este legată
de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie.

Exemple
Exemplificăm acest tip de relaţie prin relaţia este_locuita_de dintre tipurile de
entităţi scari, respectiv locatari. în reprezentarea grafică a acestui tip de
relaţie, arcul dinspre tipul de entitate scări se etichetează cu 1 iar arcul dinspre
tipul de entitate locatari se etichetează cu M








Modelul semantic din figură reprezintă relaţia unu-la-mai-multe
este_locuita_de.

Din exemplul de mai sus se observă uşor că dacă relaţia directă este de unu-la-mai-
multe, atunci relaţia inversă este de unu-la-unu.
Relaţiile mai-multe-la-mai-multe:
Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia
inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă şi relaţia directă şi relaţia
inversă sunt de tipul unu-la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-
multe şi se notează cu (N:M).

Daţi un exemplu de n la m între student şi materii.

Exemple







locatari scări
număr
matric
ol
nume
adre
sa
numă
r de

bloc
scar
a
este
locuită

1 M
Sc.
A

Sc.B

Sc.C
scări 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 reţele semantice a relaţiei 1:M este_locuita_de


Reprezentaţi cu reţea semantică relaţia dintre student şi catalog.

Să ne reamintim...
Restricţii de cardinalitate
 Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o
entitate participantă.
 Majoritatea tipurilor de relaţie 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 relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este
legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia
respectiva
 In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de
entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de -al
doilea tip de entitate participant la relaţie.
 Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-
multe prin faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-
mai-multe. Deci, dacă şi relaţia directă şi relaţia inversă sunt de tipul unu -
la-mai-multe, atunci relaţia directa este de tipul mai-multe-la-mai-multe şi
se notează cu (N:M).


b) Restricţii de participare
Numim restricţii de participare acele restricţii prin care se determină dacă existenţa
unui tip de entitate depinde de faptul că este legat sau nu de un alt tip de entitate prin
intermediul relaţiei în discuţie.
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca
existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. În caz
contrar participarea se numeşte parţială. Termenii participare totala şi participare parţială pot
fi înlocuiţi cu participare obligatorie respectiv participare opţionala. În diagrama E-R aceste
tipuri de relaţii se reprezintă prin arc cu linie dublă pentru participarea totală, respectiv cu
linie simplă pentru participarea parţială. Pentru participarea parţială, există un mod de notaţie
prin care se etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul, respectiv
maximul entităţilor participante la relaţie.

Exemple
Daca se considera filialele unei firme oarecare ca entităţi în tipul de entitate
filiala şi daca se considera tipul de entitate personal (unde entităţile reprezintă
personalul firmei respective) se poate defini tipul de relaţie 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 relaţia are_alocat este totala. Daca insa admitem că unii membri ai
personalului (de exemplu vânzătorii) nu lucrează în birourile nici unei filiale,
atunci participarea tipului de entitate personal în relaţia are_alocat este parţiala.
50


Discutaţi participarea în relaţia student cu materii.

Să ne reamintim...
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala daca
existenta entităţii respective necesita existenta unei entităţi asociate în relaţia
dată. În caz contrar participarea se numeşte parţială.
c) Dependenţele de existenţă
Numim tip slab de entitate un tip de entitate, a cărui existenţă este dependentă de
existenta unui alt tip de entitate.
Numim tip tare de entitate un tip de entitate, a cărui existenţă nu depinde de existenta nici
unui alt tip de entitate.
Entităţile slabe se mai numesc existenţial dependente sau subordonate iar entităţile tari se
mai numesc părinte 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 notaţie se extinde şi la relaţii. Astfel: o relaţie care leagă doua tipuri de
entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaţia 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ă entităţile şi relaţiile individuale care participa la modelarea
unei baze de date sunt distincte între ele. Diferenţa între entităţi sau diferenţa între relaţii se
exprima cu ajutorul atributelor care le descriu.
Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de
atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în mod unic a
oricărei entităţi în cadrul tipului de entitate luat în considerare.
Este evident ca, daca o submulţime de atribute formează o supercheie, atunci orice
mulţime de atribute care include supercheia este tot o supercheie.
Numim cheie candidat orice supercheie care conţine un număr minim de atribute.
Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. Putem spune că o
cheie candidat este caracterizata de următoarele proprietatea:
- unicitatea, deoarece valoarea cheii este unica pentru fiecare entitate în parte;

Daţi exemple de chei în entitatea profesor.

Să ne reamintim...
Participarea unei entităţi poate fi totală sau parţială. Participarea este totala
daca existenta entităţii respective necesita existenta unei entităţi asociate în
relaţia dată. În caz contrar participarea se numeşte parţială.
 Numim supercheie asociata unui tip de entitate, orice submulţime a
mulţimii de atribute ce descriu tipul de entitate, submulţime care poate
duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de
51
- ireductibilitatea, deoarece nici o submulţime proprie de atribute ale cheii nu are
proprietatea de unicitate.
Observaţie: Faptul că valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi
determinat decât cu ajutorul informaţiilor semantice referitoare la valorile atributelor ce
formează cheia. Trebuie să se cunoască semnificaţiile din lumea reala a atributelor ce
formează cheia pentru a se stabili daca acestea vor avea valori unice. Doar faptul ca, pentru o
mulţime oarecare de entităţi 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
entităţilor î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 componenţa cheii primare, se
evidenţiază prin sublinierea numelui atributului.
Numim cheie compusă orice cheie candidat care conţine cel puţin două atribute.
Probleme se ivesc atunci când trebuie să identificam în mod unic entităţile unui tip de entitate
slab. Să observam că un tip de entitate tare are întotdeauna o cheie primara, deci are
întotdeauna cel puţin 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 distincţii între entităţile care depind de o anume entitate tare. Aşadar, cheia
primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare
de care este dependenta existenţial, la care se adaugă mulţimea atributelor care compun
discriminatorul tipului de entitate slab.
entitate luat în considerare.
 Numim cheie candidat orice supercheie care conţine un număr minim
de atribute. Pentru o cheie candidat nici o submulţime 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 entităţilor în cadrul tipului de entitate respectiv.
 Numim cheie compusă orice cheie candidat care conţine cel puţin două
atribute.
 Numim discriminatorul unui tip de entitate slab, un set de atribute care
permite realizarea unei distincţii între entităţile care depind de o anume
entitate tare. Aşadar, cheia primara a unui tip de entitate slab este
formata din cheia primara a tipului de entitate tare de care este
dependenta existenţial, la care se adaugă mulţimea atributelor care
compun discriminatorul tipului de entitate slab.
 Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic
relaţiile individuale.
 Cheia primara a tipului de relaţie este formata din reuniunea
mulţimilor de atribute care formează cheile primare ale tipurilor de
entitate participante.

52
Si relaţiile au chei. Cu ajutorul cheilor se pot identifica în mod unic relaţiile
individuale. Cheia primara a tipului de relaţie este formata din reuniunea mulţimilor de
atribute care formează cheile primare ale tipurilor de entitate participante.



M2.U2.2. Rezumat
Numim relaţie orice asociere între entităţi, când asocierea include cate o entitate
pentru toate tipurile de entitate participante.
Numim gradul relaţiei numărul entităţilor participante în relaţie. Entităţile
implicate într-o relaţie se numesc participanţi. Dacă într-o relaţie sunt doi
participanţi, atunci relaţia se numeşte binară.
Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri
diferite. în acest caz este necesar să se precizeze rolurile entităţilor impli cate.
Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate
participantă.
Majoritatea tipurilor de relaţie 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 relaţiile unu-la-unu, o entitate, apartinand unui tip de entitate, este legată de cel
mult o entitate din celalalt tip de entitate implicat în relaţia respectiva
In relaţia de tip unu-la-mai-multe orice entitate, aparţinând primului tip de
entitate, este legată de 0, 1, sau mai multe entităţi apartinand celui de-al doilea tip
de entitate participant la relaţie.
Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-multe prin
faptul că relaţia inversă nu este de unu-la-unu, ci de unu-la-mai-multe. Deci, dacă
şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe, atunci relaţia
directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M).
Numim supercheie asociata unui tip de entitate, orice submulţime a mulţimii de
atribute ce descriu tipul de entitate, submulţime care poate duce la identificarea în
mod unic a oricărei entităţi în cadrul tipului de entitate luat în considerare.
Numim cheie candidat orice supercheie care conţine un număr minim de
atribute. Pentru o cheie candidat nici o submulţime 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 entităţilor în cadrul tipului de entitate respectiv.

M2.U.2.2 Test de autoevaluare a cunoştinţelor
2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi cheia primară.
2.2.2 Daţi exemple de relaţii unu la unu, unu la mai mulţ i şi mulţi la mulţi.
2.2.3 Stabiliţi domeniul fiecărui atribut din tabela profesor.
Răspunsurile se găsesc la sfârşit la pag 152

53



Modulul 3. Limbaje de cereri.





Cuprins
Introducere
Obiectivele modului
U3.1 Algebra relaţională.
U3.2 SQL.



M3. Introducere
Una din funcţiunile importante ale SGBD+urilor este regăsirea datelor. Pentru
aceasta trebuie să facem cereri la baza de date. Modelul matematic al acestor
cereri la baza de date relaţională este algebra relaţională, iar limbajul standardizat
de cereri este SQL.





M3. Obiectivele modulului
La sfârşitul acestui modul studenţii vor fi capabili să:
 Facă operaţii în algebra relaţională
 Exprime cereri în algebra relaţională
 Exprime cereri în SQL
 exprime actualizări ale bazei de date







54



Unitatea de învăţare 3.1 Algebra relaţională.



M3.U3.1. Introducere
In cadrul bazelor de date relaţionale, datele sunt organizate sub forma unor
tablouri bidimensionale (tabele) de date, numite relaţii. Asocierile dintre relaţii se
reprezintă explicit prin atribute de legătură. Aceste atribute figurează într -una din
relaţiile implicate in asociere (de regulă, în cazul legaturilor de tip "unu la mulţi")
sau sunt plasate într-o relaţie distinctă, construită special pentru exprimarea
legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). O bază de date
relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă atât
datele cât şi legăturile dintre date.
Operatorii modelului relaţional definesc operaţiile care se pot efectua asupra
relaţiilor, în scopul realizarii funcţiilor de prelucrare asupra bazei de date,
respectiv consultarea, inserarea, modificarea şi ştergerea datelor.
Restricţiile de integritate ale modelului relaţional permit definirea st ărilor
coerente ale bazei de date.
În continuare, vor fi prezentate pe larg aceste componente.




M3.U3.1. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 Facă operaţii în algebra relaţională
 Exprime cereri în algebra relaţională



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Structura relaţionala a datelor
Prezentarea structurii relaţionale a datelor impune reluarea noţi unilor de: domeniu,
relaţie, atribut şi schemă a unei relaţii.
Domeniul reprezintă un ansamblu de valori, caracterizat printr -un nume. Un domeniu
se poate defini explicit, prin enumerarea tuturor valorilor apartinând acestuia sau implicit, prin
precizarea proprietăţilor pe care le au valorile din cadrul domeniului respectiv.
55

Exemple
Sa considerăm, de exemplu domeniile D1, D2, D3, definite astfel:
D1: ("F","M")
D2 : (x / x aparţine N, x aparţine [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 apartinând
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> aparţin produsului cartezian: D3 x D1 x
D2

Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1, D2, D3,
definite anterior.
Sa considerăm, de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane,
D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde numele unor persoane.
Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o
semnificaţie şi anume cele care conţin numele, sexul şi vârsta aceleiaşi persoane.
Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie, numai unul
poate avea o semnificaţie, dacă presupunem că există o singură persoană cu
acest nume.
Se desprinde de aici necesitatea definirii unei submulţimi de tupluri, din cadrul
produsului cartezian al domeniilor, submulţime care să cuprindă numai tuplurile cu
semnificaţie.
Relaţia reprezintă un subansamblu al produsului cartezian al mai multor domenii,
subansamblu caracterizat printr-un nume şi care conţine tupluri cu semnificatie. Considerând
de exemplu că nu se cunosc decât două persoane definim realţia R prin tuplurile care descriu
aceste persoane şi anume:
R : (<"Maria", "F", 30>, <"Vasile", "M", 35>)
Intr-o relaţie, tuplurile trebuie să fie distincte (nu se admit duplicări ale
tuplurilor) .
O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în care
liniile reprezinta tuplurile, iar coloanele corespund domeniilor (fig.3.1.).

Exemple

Relaţie reprezentată sub forma unei tabele de dat e



56
Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor,
întrucat este uşor de înţeles şi de utilizat.
În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte concepte,
extrem de bine cunoscute în domeniul prelucrării automate a datelor precum cel de fişier.
Relaţia poate avea semnificaţia unui fişier,tuplul poate fi considerat drept o înregistrare, iar
valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înre gistrare.
În cadrul modelului relaţional nu intereseaza decat relaţiile finite, chiar dacă
în construirea relaţiilor se admit domenii infinite. Numărul tuplurilor dintr -o
relaţie reprezinta cardinalul relaţiei, în timp ce numărul valorilor dintr -un tuplu defineste
gradul relaţiei.
In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate apare de mai
multe ori în produsul cartezian pe baza căruia este definită relaţia.

Exemple
Să considerăm, de exemplu că pentru o persoana dispunem de urmatoarele date:
nume,sex, vârsta şi numele soţului/soţiei.
O posibilitate de organizare a acestor date o reprezintă relaţia 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.
Semnificaţia valorilor din cadrul unui tuplu se stabileşte


Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza
domeniului de care aparţin valorile, ci şi in funcţie de poziţia ocupată în cadrul tuplului.
Dependenţa fată de ordine a datelor inseamnă o reducere a flexibiltăţii 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 diferenţia coloanele care conţin valori ale
aceluiaşi domeniu şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază
fiecarei coloane un nume distinct, ceea ce duce la aparitţa noţiunii de atribut.
Atributul reprezintă coloana unei tabele de date, caracterizată printr -un nume. Numele
coloanei (atributului) exprimă de obicei semnificaţia valorilor din cadrul coloanei respective.
Schema unei relaţii
Prin schema unei relaţii se întelege numele relaţiei, urmat de lista atributelor, pentru
fiecare atribut precizându-se domeniul asociat. Astfel, pentru o relaţie R, cu atributele A1, A2,
..., An şi domeniile: D1, D2,..., Dm, cu m <= n, schema relaţiei R poate fi reprezentată într -
una din formele

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

a) b)


Operatorii modelului relaţional.
Modelul relaţional oferă două colecţii de operatori pe relaţii şi anume:
- algebra relaţionala;
- calculul relaţional.
A
1
:D
1
… A
n
:D
m


57
La rândul sau, calculul relaţional este de două tipuri:
- calcul relaţional orientat pe tuplu;
calcul relaţional orientat pe domeniu.
Ne limităm, în cele ce urmează, la elemente de algebră relaţională.
Algebra relaţională şi extensiile sale
E. F. Codd a introdus algebra relaţ ionala (AR) cu operaţii pe relaţii, fiecare operaţie
având drept operanzi una sau mai multe relaţii şi
producând ca rezultat o altă relaţie.
Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. În acest sens,
putem vorbi de:
- operaţii de bază, precum: reuniunea, diferenţa, produsul cartezian etc.
- operaţii derivate, ca: intersecţia, diviziunea etc.
Codd a introdus aşa numita AR standard, constituită din 6 operaţii de bază: reuniunea,
diferenţa, produsul cartezian, proi ecţia, selecţia şi joncţiunea precum şi din două operaţii
derivate: intersecţia şi diviziunea.
Ulterior, la operaţiile AR standard au fost adăugate şi alte operaţii, aşa
numitele operaţii "adiţionale" sau extensii ale AR standard, precum:comple-
mentara unei relaţii, splitarea (spargerea) unei relaţii, închiderea tranzitivă etc.
În continuare vor fi prezentate principalele operaţii ale AR, precum şi modul lor de
utilizare.
1. Reuniunea. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 a mbele cu
o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică
cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată.
Notaţia uzuală pentru reuniune este: R1 U R2
Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.

Exemple

Reuniunea relatiilor ORASE şi MUNICIPII

Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele cu o
aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu schema identică cu a
operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în
relaţia R2.
Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1-R2
58


Exemple

Diferenţa relaţiilor ORAŞE şi MUNICIPII

3. Produs cartezian. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,
operaţie care constă din construirea unei noi rel aţii R3, a cărei schemă se obţine prin
concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile
tuplurilor din R1 cu cele din R2.
Notaţia uzuală pentru desemnarea operaţiei este: R1xR2


Exemple





Produsul cartezian al relaţiilor ORAŞE şi TARIFE

ORAŞ:D
1
JUDEŢ: D
1
TRANSPORT:D
3
TARIF:D
4
Braşov Braşov tramvai 30
Târgovişte Dâmboviţa tramvai 30
Braşov Braşov autobuz 50
Târgovişte Dâmboviţa autobuz 50
Braşov Braşov troleibuz 50
Târgovişte Dâmboviţa troleibuz 50
ORAŞ:D
1
JUDEŢ:D
1
Braşov Braşov
Târgovişte Dâmboviţa
ANSP:D
3
TARIF:D
3
tramvai 30
autobuz 50
troleibuz 50
TRANSPORT
X
TARIFE
ORAŞE:
59

4. Proiecţia. Reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie care constă
din construirea unei noi relaţii P, în care se regăsesc unele atribute din R, înseamnă efectuarea
unor tăieturi verticale asupra lui R, care pot avea ca efect apariţia unor tupluri duplicate ce se
cer a fi eliminate.
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei.
Notaţia uzuală pentru operaţia de proiecţie este:
Π
Ai,Aj,…,Am
(R)


Exemple

Proiectia relaţiei ORAŞE pe atributul "Judeţ"


5. Selecţia. Roprezintă o operaţie din AR definită asupra unei relaţii R,
operaţie care constă din construierea unei relaţii S, a cărei schemă este identică
cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o
condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai adesea, nu toate tuplurile din
R satisfac, această condiţie, selecţia înseamnă efectuarea unor tăieturi orizontal e asupra
relaţiei R, adică eliminarea de tupluri. Condiţia precizată în cadrul operaţiei de selecţie este în
general de forma:



unde: "operator de comparaţie" poate fi: <, <=, >=, > sau <>.
Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este următoarea:
Σ
(conditie)
R




60




Exemple


Selecţie efectuata asupra relaţiei ORAŞE


6. Joncţiunea (Joinul). Reprezintă o operaţie din AR definită pe două relaţii: R1 şi
R2, operaţie care constă din construirea unei noi relaţii R3, prin concatenarea unor
tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 şi R2 care satisfac o
anumita condiţie, specificată explicit în cadrul operaţiei. Extensia relaţiei R3 va contine deci
combinaţiile acelor tupluri care satisfac condiţia de concatenare.
Notaţiiile uzuale pentru desemnarea operaţiei de joncţiune sunt:




Reprezentarea grafica a operaţiei de joncţiune
In general, condiţia de concatenare menţionata in cadrul operaţiei de joncţiune este de
forma:

In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare, joinul
poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei mai frecvente
utilizări este equijoinul.


Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:

Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi
selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei selecţii operate asupra unui produs
cartezian, adică:
61
JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie)
Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea ce face
ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este posibil. Cu toate că
apare drept o operaţie derivată, joinul este prezentat de obicei drept o operaţie de bază din
AR, dată fiind importanţa sa in cadrul sistemelor relaţionale, în special la construirea relaţiilor
virtuale.
In cadrul fig.3.9. este ilustrată operaţia de equijoin.
Au fost definite numeroase variante ale operaţiei de joncţiune, variante care dife ră nu
numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de definire a schemei şi
respectiv, extensiei relaţiei rezultate prin joncţiune.

Exemple


Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI



Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate atributele celor
doi operanzi (fig.3.10.) În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două
valori egale. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală, ca
operaţie definită pe două relaţii: R1 şi R2, prin care este construită o noua relaţie R3, a cărei
schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi
nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea
tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi
nume.

Notaţia uzuală pentru joncţiunea naturală este:
Reprezentarea grafică a acestei operaţii este prezentată în fig. 3.10.

Reprezentarea grafică a operaţiei de joncţiune

62

Exemple




7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2 ambele cu aceeaşi
schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu a
operanzilor şi cu extensia formată din tuplurile comune lui R1 şi R2.
Notaţile uzuale folosite pentru desemnarea operaţiei de intersecţie sunt:

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.12., iar
un exemplu de intersecţie a doua relaţii figurează în fig. 3.13.

Reprezentarea grafica a operatiei de intersectie



63

Exemple



Intersecţia relatiilor ORAŞE şi MUNICIPII


Intersecţia reprezintă o operaţie derivată, care poate fi exprimată prin intermediul unor
operaţii de bază. De exemplu, operaţia de intersecţie se poate exprima prin intermediul
operaţiei de diferenţă, cu ajutorul următoarelor echivalenţe:
R1· R2=R1-(R1-R2)
R1· R2=R2-(R2-R1)

M3.U3.1. Rezumat
Reuniunea reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 ambele
cu o aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu
schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate
impreună o singură dată.
Diferenţa reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2, ambele
cu o aceeaşi schemâ, operaţia constând din construirea unei noi relaţii R3, cu
schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale
relaţiei R1 care nu se regăsesc şi în relaţia R2.
Produs cartezian reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2,
operaţie care constă din construirea unei noi relaţii R3, a cărei schemă se obţine
prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate
combinaţiile tuplurilor din R1 cu cele din R2.
Proiecţia reprezintă o operaţie din AR definită asupra unei relaţii R, operaţie
care constă din construirea unei noi relaţii P, în care se regăsesc unele atribute
din R, înseamnă efectuarea unor tăieturi verticale asupra lui R, care pot avea ca
efect apariţia unor tupluri duplicate ce se cer a fi eliminate.
Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad
p, mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit
operaţiei.
Selecţia reprezintă o operaţie din AR definită asupra unei relaţii R,
operaţie care constă din construierea unei relaţii S, a cărei schemă este identică
64
cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care
satisfac o condiţie menţionată explicit în cadrul operaţiei. Întrucât cel mai
adesea, nu toate tuplurile din R satisfac, această condiţie, selecţia înseamnă
efectuarea unor tăieturi orizontale asupra relaţiei R, adică eliminarea de tupluri.
Joncţiunea (Joinul) reprezintă o operaţie din AR definită pe două relaţii: R1 şi
R2, operaţie care constă din construirea unei noi relaţii R3, prin
concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele
tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în
cadrul operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri
care satisfac condiţia de concatenare.
Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate
atributele celor doi operanzi În toate tuplurile relaţiei rezultat vor exista de aceea
cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus
joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este
construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea
atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată)
şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1
cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi
nume.

M3.U3.1. Test de autoevaluare a cunoştinţelor
3.1.1 Cosideraţi instanţe ale tabelei student, profesor,materii şi catalog.
a) Faceţi selecţie din student după grupa …
b) Faceţi proiecţie la student şi la profesor după nume. La acestea două din
urmă faceţi reuniunea.
c) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi
materii.
d) Faceţi selecţia tabelei de mai nainte după nota < 5.
3.1.2 Să se exprime în algebra relaţională cererile:
a) Studenţii grupei 7271
b) Studenţii care sunt şi profesori
c) Studenţii corigenţi
d) Studenţii integralişti
Răspunsurile se găsesc la sfârşit la pag 152





65
Unitatea de învăţare 3.2 SQL



M3.U3.2. Introducere
SQL (Structured Query Language), a fost conceput iniţial de firma IBM,
pentru produsul dBASE, ca un limbaj standard de descriere a datelor şi de
acces la informţtiile din bazele de date. Limbaj de interogare a bazelor de
date relaţionale, SQL a fost utilizat pe scară largă şi pană în prezent au fost
dezvoltate şapte versiuni ale standardului SQL, trei dintre ele aparţinînd
Institutului National American de Standarde (ANSI), celelalte fiind
concepute de firme de prestigiu ca IBM, Microsoft şi Borland sau de cãtre
consorţii ca SAG (The SQL Access Group) şi X/Open.
Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut
sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua
denumire: ANSI-SQL'92.




M3.U3.2. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 Exprime cereri în SQL
 exprime actualizări ale bazei de date



Durata medie de parcurgere a primei unităţi de învăţare este de 4 ore.

Cereri de interogare simple
Instructiunile de regăsire reprezintă una din categoriile cele mei importante ale
limbajului de interogare SQL. Indiferent dacă sunt simple sau complexe, punctul de plecare al
interogărilor îl constituie fraza SELECT, prin care se r egăsesc şi se afişeaza informaţiile
dorite de utilizator.
Pentru definirea interogărilor de selecţie simple se utilizează următoarea sintaxă a
instrucţiunii SELECT:
SELECT [domeniu] lista_selecţie
FROM nume_tabela1,nume_tabela2…
[WHERE criteriu_de_selecţie}
ORDER BY câmpuri_criteriu [ASC/DESC]];
Domeniu:
- Determină stabilirea modalităţii de manipulare a înregistrărilor din baza de date asupra
căreia se efectuează selecţia şi poate fi:
ALL - permite includerea tuturor inregistrărilor ce indeplinesc condiţiile impuse. Este
folosit foarte rar deoarece este implicit.
DISTINCT - are ce efect eliminarea înregistrărilor care conţin duplicate în câmpurile
selectate; astfel se va afişa doar o apariţie a datei multi ple ( ceea ce este în concordanţă cu
algebra relaţională).
DISTINCTROW - are în vedere înregistrările duplicate în ansamblul lor, nu numai pe cele
care au câmpuri duplicate.
66

Lista_selecţie
Cuprinde toate câmpurile care vor aparea în tabela cu rezulta tele interogării.
Atenţie! }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 relaţională, după cum urmează:
Clauza SELECT menţionează o listă de atribute şi corespunde proiecţiei din algebra
relaţională;
Clauza FROM menţionează o listă de relaţii (tabele) şi corespunde produsului cartezian din
algebra relaţională;
Clauza WRERE descrie un predicat de selecţie şi corespunde selecţiei din algebra relaţi onală.
Înţelesul diferit al termenului “select” utilizat în SQL şi în algebra relaţională este un fapt
istoric nefericit. În SQL, ”select” desemnează proiecţia, iar în algebra relaţională acelaşi
termen desemnează selecţia după un predicat de selecţ ie.
Lista de atribuire care apare în clauza SELECT din SQL poate fi înlocuită cu simbolul *
dacă se doreşte selectarea tuturor atributelor care apar în relaţiile din clauza FROM.

Clauza ORDER BY
Utilizată atunci când se doreşte ca rezultatele int erogării să fie ordonate în mod
crescător (ASC) sau descrescător (DESC). Sortarea este opţională şi se poate realiza dupa
unul sau mai multe câmpuri_criteriu (definite drept chei de sortare). Componenta BY a
clauzei nu poate să lipsească atunci când se doreşte sotrarea rezultatelor interogării SQL.

Rezultatul unei interogări SQL este întotdeauna o relaţie (o tabelă).

Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de închiriere casete
video. Avem următoarele 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 afişeze toate datele despre toţi clienţii.
SELECT *
FROM Clienţi


.Să se afişeze toate datele despre toţi actorii.

Exemple
Să se afişeze oraşele de reşedinţă ale tuturor clienţilor
SELECT Oraş
FROM Clienţi
67


Să se afişeze toate genurile filmelor. Ce puteţi spune despre numărul genurilor
faţă de numărul genurilor.
Ca rezultat al acestei interogări se va obţine o tabelă cu o singură coloană, care conţine
numele oraşelor de reşedinţă ale clienţilor. Se va observa că se repetă numele oraşelor,
deoarece se vor afişa oraşele pentru fiecare client în parte din tabela clienţi.

Exemple
Să se afişeze oraşele de reşedinţă ale clienţilor, dar să apară fiecare ora ş o singură
dată în tabela-rezultat.
SELECT DISTINCT Oraş
FROM Clienti


Să se afişeze toate genurile distincte ale filmelor.

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


Afişaţi, ca mai sus, dar în ordine descendentă.
Să se afişeze 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 menţiunea ASC, ordinea tuplelor ar fi fost
aceeaşi deoarece ordinea ascendentă este implicită.
În scrierea interogărilor de selecţie simple SQL se pot folosi şi funcţii totalizatoare,
cunoscute şi sub numele de funcţii standard sau funcţ ii agregat, care apar în clauza SELECT
şi se aplică atributelor din tabelele implicate în interogare. Funcţii standard sunt:
valoarea medie – AVG
valoarea minima – MIN
valoarea maxima –MAX
total (sumare) – SUM
numaratoare – COUNT
Nu este permisă utilizarea acestor funcţii în clauza WHERE deoarece ele acţionează la nivel
de atribut şi nu la nivel tuplu.


Exemple
Care este suma minimă plătită?
SELECT MIN (suma)
68
FROM plati


.Care este suma maximă plătită?


Exemple
Care este preţul mediu al casetelor?
SELECT AVG(Pret)
FROM Casete


Care este suma medie încasată.

Exemple
Care este suma totală plătită pentru împrumutul cu cod ’30’?
SELECT SUM (suma)
FROM plati
WHWRE Cod_imprumut=’30’


Care este valoarea totală a casetelor.

Exemple
Cate tulpe conţine tabela de casete?
SELECT COUNT (*)
FROM Casete


Câte tupe conţine 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 lângă definirea de interogări de selecţie simple,
crearea unor interogări cu o structura complexă, cum ar fi cele în care regăsim funcţiile
agregate, asocierile (JOIN) sau combinările (UNION).

Funcţiile de grup(agregat)

69
Funcţiile de grup agregat permit construirea unor interogări SQL complexe, prin care
utilizatorul poate să efectueze diverse calcule pentru grupuri de înregistrări care au câmpuri cu
aceeasi valoare. În cazul utilizării lor se foloseşte următoarea formă a frazei SELECT:

SELECT [domeniu] [funcţie agregată (nume_câmp) AS alias [,lista_selecţie]
FROM nume_tabela1, nume_tabela2…
GROUP BY câmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY câmpuri_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 relaţiile din care fac parte
atributele. Aşadar o interogare SQL trebuie să conţină cel puţin următoarele informaţii:

SELECT <lista de atribute>
FROM <lista de relatii>
restul clauzelor sunt opţionale.

Lista selecţie
Se va referi la una sau mai multe funcţii agregate care au ca argumente nume de câmpuri ale
bazei de date. Există restricţia ca aceste câmpuri sa fie întotdeauna de tip numeric.
AS alias
Asociază un pseudonim (nume) rezultatului utilizării funcţiei agregat

Clauza GROUP BY şi HAVING
În unele cazuri, utilizatorul doreşte anumite situatii sintetice, cum ar fi obţinerea de totaluri şi
subtotaluri. Pentru aceste operaţii, limbaj ul SQL permite utilizarea clauzelor GROUP BY şi
HAVING.
Aceste clauze organizează tuplele în grupuri asupra cărora se pot realiza anumite
operaţii, în special prin aplicarea funcţiilor agregat.
Clauza GROUP BY grupeaza tuplele din relaţie după atributele cu aceeaşi valoare
care sunt specificate în clauză, şi generează un tuplu pentru fiecare grup de tuple cu aceeaşi
valoare pe atribut
Atributele care apar în clauza SELECT pot fi de două feluri:
-atribute care alcătuiesc 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 câte ţări avem filme.

Exemple
Câţi clienţi au sediul în fiecare oras?
SELECT Oras,COUNT(*)
70
FROM Client
GROUP BY Oras


Câte filme sunt din fieare ţară.

Exemple
În care case locuiesc cel puţin 3 clienţi?
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 puţin 2 filme.

Exemple
Să se afişeze în ordine alfabetică oraşele în care există clienţi ai centrului.
SELECT Oras
FROM Clienti
GROUP BY Oras
ORDER BY Oras


Să se afişeze în ordine alfabetică ţările din care avem filme.

Exemple
Care sunt clienţii 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 făcute după data 01/01/2009 .

Clauza FROM are forma generală:
FROM <<nume relatie>/<nume view>[alias]…>
şi specifică relaţiile (pot fi şi nume view) din care vor fi regăsite datele. În cazul în care se
operează cu mai multe tabele, este utilă atribuirea unor prescurtări, (numite alias) ale numelor
de tabele ce vor fi utilizate în interogare.


Exemple
Să se afişeze codurile casetelor, numele clienţilor, codul împrumutului şi data
împrumutului pentru clienţii care au cel puţin 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 notaţia cu alias pentru atributele Nume şi
Prenume din tabela Clienti deoarece nu este pericol de confuzie. În schimb s-a
utilizat notaţia pentru a deosebi atributul Cod_client din tabela Clienti de
atributul cu acelaşi nume din tabela Imprumuturi.


Să se afişeze actorii care joacă cel puţin într-un film.
Pentru a restrânge tuplele ce apar în tabela-rezultat, se specifică o condiţie de cautare prin
utilizarea unui predicat de selecţie în clauza WHERE.
Clauza WHERE are forma generala:

WHERE <predicat> / <expresie>;
Numai tuplele care satisfac predicatul de selecţie vor fi incluse în tabela-rezultat. Predicatul
de cautare poate fi specificat printr-o condiţie logica în care se utilizeaza urmatoarele
elemente:
Operatori:
-aritmetici:+ - / * ** ^
-relaţionali: < > <= >= <> != =
-logici:NOT AND OR
-operatori SQL:IN,EXISTS,ALL,ANY
Sub-interogări(exprimate prin interogări 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 binecunoscuţi şi menţionăm aici doar faptul ca şi ^ si ** reprezint[
ridicarea la putere.
Ca operanzi, se pot utiliza atribute,constante,funcţii sau expresii algebrice. Expresiile
algebrice pot aparea în clauzele SELECT sau WHERE.
Operatori relaţionali
< mai mic
> mai mare
! negarea operatorilor <,>,=. Se obţin operatorii: != (diferit),!< (nu mai mic),!> (nu mai
mare).
<= mai mic sau egal
=> mai mare sau egal
<> diferit
Facem observaţia că valorile comparate trebuie să aparţină unor tipuri de date compatbile
(care se pot compara între ele.).

Exemple
Sa se afişeze codurile şi titlurile filmelor de gen acţiune.
SELECT Cod_film<Titlu
FROM Filme
WHERE Gen=”actiune”
72


Să se afişeze filmele din Romania.

Operatori logici

Dacă o clauza WHERE conţine mai multe condiţii formate prin utilizarea aceluiaşi tip de
operator logic, evaluarea se va face de la stânga la dreapta. Tipul de operator logic este dat de
precedenţa operatorilor. Operatorul NOT are cea mai mare prioritate, urmat de OR şi AND
care practic sunt de priorităţi egale. Pentru a schimba ordinea de evaluare a unei expresii se
utilizează parantezele rotunde ().


Exemple
Sa se afişeze codul şi titlul filmelor din SUA care au anul apariţiei mai mare
decât 2000.
SELECT Cod_film,Titlu
FROM Filme
WHERE Tara=”SUA”AND An_aparitie>2000


Să se afişeze plăţile mai mari de 100 lei făcut în anul 2009.

Exemple
Sa se afişeze codul şi titlul filmelor din SUA sau care au anul apariţiei mai mare
decât 2000.
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=”SUA”OR An_aparitie>2000
A se observa că ultima interogare este echivalentă cu interogarea :
SELECT Cod_film ,Titlu
FROM Filme
WHERE Tara=”SUA”OR NOT An_aparitie<=2000


Operatorul IN permite simplificarea predicatului de căutare. Predicatul IN testează dacă
valoarea unui atribut specficat în lista de atribute din clauza WHERE se potriveşte uneia din
valorile listei specificate în predicatul IN (testeaza apartenenţa la o mulţime).

Exemple
Să se afişeze toate datele despre clienţii care au sediul în Râşnov sau în
Braşov.
SELECT *
FROM Clienti
WHERE Oras IN (“Rasnov”,”Brasov”)

73

Să se afişeze, în două moduri, toate datele despre clienţii care au sediul în
Râşnov sau în Braşov sau în B ucuresti.


Asocierile (interogările JOIN)
Una dintre operaţiile cele mai frecvente realizate cu mai multe tabele este joncţiunea
sau produsul cartezian. Joncţiunea aminteşte de operaţiile din algebra relaţională şi chiar e ste
posibil de realizat (urmând anumite structuri ale interogării SQL) oricare dintre tipurile de
joncţiune prezentate teoretic în cadrul algebrei relaţionale. Se pot de asemenea realiza operaţii
ca reuniunea, intersectia şi diferenţa. Sintaxa interogării SQL diferă de la un SGBD la altul
dar sub o formă directă sau printr -o construcţie sintactică specifică se pot realiza oricare dintre
operaţiile amintite.
Putem distinge mai multe categorii de joncţiuni:CROSS (încrucişată) - mai
puţin utilizată, cu rol în ilustrarea elementelor specifce proprietăţilor combinatorii ale tuturor
asocierilor; ECHIVALENTĂ (echijoncţiunea)-cea mai folosită, presupune folosirea clauzei
WHERE (pentru selecţia înregistrărilor) asociată cu o egalitate dorită; NEECHIVALENTA
(non echijoncţiune) - care, spre deosebire de precedenta, face apel în clauza WHERE la
oricare operator de comparare în afară de semnul (“=”). Acest din urmă tip de joncţiune este
în general foarte rar de utilizat.
Sintaxa generală pentru joncţiunile echivalente şi neechivalente este următoarea:

SELECT [domeniu] lista_selecţie
FROM nume_tabela1,nume_tabela 2…
WHERE criteriul_de_asociere]
[ORDER BY câmpuri_criteriu[ASC?DESC];

Deoarece în instrucţiunile SQL care descriu joncţiunea se utilizeaza câmpuri ce fac
parte din tabele diferite, este necesara întotdeauna spacificarea tabelei la care apartin. Forma
generala de descriere a unui câmp va fi urmatoarea:nume_tabela.nume_câmp. Se pot folosi şi
alias-uri.


Exemple
Sa se afişeze 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 afişeze filmele şi casetele pe care se găsesc.

Exemple
Care filme au acelasi gen cu filmul “Titanic”? A se observa că această interogare
necesită realizarea produsului cartezian al tabelei cu ea însăşi.
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 priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe
(OUTER JOIN). Primele determină o asociere a înregistrărilor din tabele, astfel încat sa
rezulte un numar total de înregistrări din fiecare tabela. Joncţiunile externe, la randul lor, sunt
de doua tipuri: de stanga (LEFT OUTER JOIN) şi de dreapta (RIGHT OUTER JOIN) fiind
destul de puţin utilizate.
În acest mod de abordare al joncţiunulor sintaxa va avea forma:

SELECT [domeniu] lista_selecţie
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_selecţie]
[ORDER BY câmpuri_criteriu {ASC/DESC]]:

De remarcat faptul ca SQL acceptă scrierea interogărilor externe fără 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ă relaţia dintre câmpurile pe care se bazează
joncţiunea. Unul se află în tabela asociată, iar celălalt există într -o altă tabelă din lista cu
numele tabelelor. Expresia criteriul_de asociere conţine un operator de comparaţie de tip
egalitate (=) şi va returna valorile logice TRUE sau FALSE



Exemple
Sa se afişeze codul casetelor, preţul ş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 afişeze filmele şi casetele pe care se găsesc. Procedaţi ca mai sus.

Combinările (interogările UNION)
Clauza UNION permite realizarea reuniunii de tabele. În cazul când dorim să reunim
două sau mai multe tabele, este obligatoriu ca acestea să fie daschise de scheme de relatie
identică (acelaşi număr de atribute şi corespunzator – de la stanga la dreapta – atributele din
tabele au aceleasi nume şi aceeaşi descriere). Aceste condiţii sunt impuse tabelelor implicate
în operaţiile intersecţie şi minus (diferenţă). Operaţiile reuniune, intersecţie şi diferenţă de
tabele acţionează analog cu aceleaşi operaţii aplicate în mulţimi.
Forma generală a reuniunii de tabele este:

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


Exemple
Să se afişeze numele clienţilor care sunt fie din Râşnov fie din Braşov ş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 (subinterogări)
Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare
este acela că oferă posibilitatea construirii interogărilor complexe, formate din mai multe
subinterogări simple.
Aceste interogări complexe sunt construite prin incl uderea în clauza WHERE a încă
unei clauze SELECT. Forma generală a unei astfel de construcţii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
Se observă că această construcţie a fost deja utilizată în exemplul de mai sus car e
ilustrează o clauză UNiON.
În construcţia de mai sus clauza SELECT interioară generează valorile pentru condiţia de
căutare a clauzei SELECT exterioare care o conţine. Clauza SELECT exterioară generează o
relaţie pa baza valorilor generate de către clauza interioară. Modul de construire a interogării
exterioare depinde de numărul valorilor returnate de către interogarea interioară. În acest sens,
putem distinge:
 subinterogări care returnează o singură valoare;
 subinterogări care returnează mai multe valori.
Din punctul de vedere al ordinii de evaluare al interogărilor putem distinge:
 Subinterogări simple
Interogarea interioara este evaluata prima, independent de interogarea exterioara.
Rezultatul evaluarii interogării interioare este utilizat de catre nter ogarea
exterioara.
 Subinterogări 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
Subinterogări simple care returneaza o singura valoare
Aceste interogări au urmatoarea sintaxă:
SELECT <lista atribute>
FROM <lista relatii>
WHERE <atribut> 0 (<subinterogare>)
unde 0 este un operator relaţional: =,< > >= <= !=

Exemple
Sa se afişeze numarul împrumuturilor neîncheiate 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 afişeze casetelew care au filme din USA.
Procesul de evaluare a acestei interogări se desfasoară astfel:
Se evalueaza în primul rînd interogarea interioară. Condiţia de evaluare a interogării
interioare este [Nume] & “ ” & [Prenume]=’Ciurar Cristina’.
Valoarea obţinută pentru atributul Cod_client este stocata într-o tebelă temporară.
Rezultatul evaluării interogării interioare devine condiţie de căutare 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 executării interogării exterioare este creată o relaţie finală, ce va contine
tuplele ale căror Cod_client este acelaşi cu valoarea stocată în tabela temporară.
Interogarea interioară poate conţine în clauza WHERE şi condiţii complexe, formate
prin utilizarea operatorilor logici (NOT,AND, OR) şi a funcţiilor agregat (AVG,MAX,…).


Exemple
Sa se afişeze 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 afişeze filmele din casetele, cu preţ minim, împrumutate şi nerestiruite.

Suinterogări simple care returnează mai multe valori.
Principiul de construire a acestui tip de interogare imbricate utilizează în clauza
WHERE condiţii, care evaluate, generează o mulţime de valori. În această categorie intră
operatorii (NOT) IN, (NOT) ANY,(NOT) AND,(NOT) EXISTS.

77

Exemple
Care sunt clienţii 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 clienţi 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ă interogări diferă doar prin operatorul logic NOT. De
asemenea se poate remarca faptul că prima interogare aminteşte de apartenenţa din teoria
mulţimilor iar a doua interogare corespunde operaţiei minus (diferenţa). Dacă versiunea SQL
nu are un cuvânt rezervat pentru operaţia diferenţa inter tabele, se poate construi aceasta
operaţie cu ajutorul predicatului NOT IN ca în exemplul de mai sus.
Subinterogări corelate
În exemplele de până acum, interogarea interioară era evaluată prima, după care
valoarea, sau valorile, rezultate erau utilizate de către clauza WHERE din interogarea
exterioară.
Exista şi o altă forma de subinterogare şi anume Subinterogarea corelată, caz în care
interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară.
De fiecare dată când este transmisă o valoare, este evaluată interogarea interioară.
Dacă ambele interogări acceseaza acelaşi table, trebuie asigurate alias-uri pentru fiecare
referinţa la tabelul respectiv. Ambele interogări accesează tuple diferite din acelaşi table în
acelaşi moment.


Exemple
Sa se afişeze codurile imprumuturilor, data imprumutului, data unei plaţi şi suma
plătită, pentru sumele maxime care s-au plătit, 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;



Restricţionare subinterogărilor
Operatorii ANY şi ALL
Operatorul ANY poate fi utilizat în cobinaţie cu oricare dintre operatorii relaţionali (=
< > <= >= !=) pentru a se varifica dacă valorile unui atribut este egală, mai mică, mai mare,
etc. decât oricare dintre valorile menţionate 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. decât toate valorile generate de interogarea
interioară. Să facem observaţia că acest operator nu poate fi utilizat cu operatorul relaţional =,
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 dăm
mai jos o serie de cazuri concrete.
Să presupunem ca interogarea este de forma:

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

Să observăm că dacă înlocuim operatorul ALL cu expresia verbală toate putem citi
“Valorile lui x trebuie să fie mai mici decât toate valorile din paranteza ce urmeaza după
ALL”.
Atunci vom lua în considerare urmatoarele situaţii:

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ă observăm că dacă înlocuim operatorul ANY cu expresia verbală oricare putem citi
“Valorile lui x trebuie să fie mai mici decât oricare dintre valorile din paranteza ce urmeaza
dupa ALL”.
79
Vom lua în considerare următorul 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 afişeze titlul filmelor, anul apariţ iei şi genul, pentru filmele din SUA,
care au anul apariţiei 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 afişeza codul casetelor, preţul, 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 relaţiei există tuple care
satisfac condiţia interogării 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 relaţie diferită de cea
utilizată în interogarea exterioară. )
Ca şi operatorii ANY şi ALL, operatorul EXISTS apare în clauza WHERE.


Exemple
Să se afişeze titlui filmelor, anul aparitiei şi genul pentru filmele care au un an de
apariţie mai mare sau egal cu anul maxim de apariţie 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ă defineşte o tabelă care conţine tuple pentru care se
verifică condiţia din clauza WHERE internă.

Actualizări ale bazei de date.
SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru actualizarea
bazelor de date. Comenzile pentru actualizări nu sunt atât de complexe ca declaraţia SELECT.
Declaraţiile SQL aferente actualizării unei baze de date se referă la modificările unei tabele
(adăugare sau ştergere de linii, modificarea datelor dintr -o tabelă):
Adăugarea se face cu declaraţia INSERT care are două forme prima accepta
adăugarea unei singure linii, iar a doua adăugarea mai multor linii.
I. Adăugarea 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 ecificăm această
listă atributele pe care dorim să le omitem trebuie să le declarăm ca NULL. Numărul de
elemente din cele două liste trebuie să coincidă, să aibă aceaşi ordine de declarare şi să fie
compatibile ca tip.


Exemple
Exemplu:
Inseraţi o nouă înregistrare în tabela Conducere completând 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’)


Inseraţi o nouă înregistrare în tabela casete.

Exemple


.
81
II. Adăugarea mai multor linii prin copierea lor dintr -o tabelă sau mai multe tabele într-o altă
tabelă
INSERT INTO nume_tabela [(lista_atribute)]
SELECT …
Nume_tabela şi lista de atribute sunt definite la fel ca la cazul anterior, iar clauza SELECT
poate fi orice declaraţie validă.

Exemple
Inseraţi o nouă înregistrare în tabela Conducere completând datele doar pentru
atributele obligatorii cod, Nume, Prenume, Functie
INSERT INTO Conducere
VALUES (‘cd44’, ‘Aduducai’, ‘Maria’, NULL, NULL,’asisent manager’,NULL,
NULL)


Exemplu:

Exemple
Presupunând că în tabela ContConducere conţine numele celor din
conducere şi numărul serviciilor pe care le au în subordine populaţi tabela
ContConducere folosind detalii din tabelele Conducere şi PorpServicii o nouă
înregistrare în tabela Conducere completând 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 declaraţia UPDATE care permite modificarea datelor unor
înregistrări 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ă opţională, prin omiterea ei se consideră că toate că toate
înregistrările for fi modificate pentru atributele alese la clauza SET, iar dacă ea este
specificată atunci doar acele înregistrări care îndeplinesc condiţiile de căutare. Tipul datelor
valoare1,…. trebuie să fie compatibile cu cele ale atributelor corespunzătoare.
82

Exemple
Modificarea tuturor înregistrărilor pentru mărirea salariior tuturor celor din
conducere cu 3%.
UPDATE CONDUCERE
SET salariu = salariu*1.03


Modificarea preţului la casetele cu preţul maxim prin reducere cu 10%.
2. Modificarea doar a unor înregistrări specificate
UPDATE CONDUCERE
SET salariu = salariu*1.05
WHERE functie=’manager’
Modificarea înregistrărilor pentru mai multe atribute
UPDATE CONDUCERE
SET functie=’manager’, salariu = 18.000.000
WHERE id=’cd73’
Ştergerea se face cu declaraţia DELETE , sintaxa acestei comenzi este :
DELETE FROM nume_tabela
WHERE conditie_cautare
Dacă opţiunea WHERE lipseşte atunci se şterg toate înregistrările darn nu şi tabelul,
pentru a şterge un tabel folosim declaraţia DROP TABLE. Se poate şterge un tabel numai
dacă nu mai are înregistrări.

Exemple
1. Ştergerea tuturor înregistrărilor din tabela vedere (view)
DELETE FROM viewing;
2. Ştergerea anumitor înregistrări din tabela vedere (view)
DELETE FROM viewing;
WHERE id = ‘cd72’


Ştergerea tuturor înregistrărilor din tabela casete.
Ştergerea înregistrărilor din tabela casete cu preţ minim.

83

M3.U3.2. Rezumat
Pentru definirea interogǎrilor de selecţie simple se utilizeazǎ urmǎtoarea sintaxǎ
a instrucţiunii SELECT:
SELECT[domeniu]lista_selecţie
FROMnume_tabela1,nume_tabela2…
[WHERE criteriu_de_selecţie}
ORDER BY câmpuri_criteriu [ASC/DESC]];
Funcţiile de grup agregat permit construirea unor interogǎri SQL
complexe, prin care utilizatorul poate sǎ efectueze diverse calcule pentru grupuri
de înregistrǎri care au câmpuri cu aceeasi valoare. În cazul utilizǎrii lor se
foloseşte urmǎtoarea formǎ a frazei SELECT:

SELECT [domeniu] [funcţie agregatǎ (nume_câmp) AS alias [,lista_selecţie]
FROM nume_tabela1, n ume_tabela2…
GROUP BY câmp_de_grupare
[HAVING criteriu_de_grupare]
[ORDER BY câmpuri_criteriu [ASC/DESC]];
Sintaxa generalǎ pentru joncţiuni este urmǎtoarea:
SELECT [domeniu] lista_selecţie
FROM nume_tabela1,nume_tabela 2…
WHERE criteriul_de_asociere]
[ORDER BY câmpuri_criteriu[ASC?DESC];
O altǎ abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe
(OUTER JOIN). Primele determinǎ o asociere a înregistrǎrilor din tabele, astfel
încat sa rezulte un numar total de înregistrǎri din fiecare tabela. Joncţiunile
externe, la randul lor, sunt de doua tipuri: de stanga (LEFT OUTER JOIN) şi de
dreapta (RIGHT OUTER JOIN) fiind destul de puţin utilizate.
În acest mod de abordare al joncţiunulor sintaxa va avea forma:
SELECT [domeniu] lista_selecţie
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_selecţie]
[ORDER BY câmpuri_criteriu {ASC/DESC]]:
Unul din motivele pentru care SQL este considerat un limbaj puternic de
interogare este acela cǎ oferǎ posibilitatea construirii interogǎrilor complexe,
formate din mai multe subinterogǎri simple.
Aceste interogǎri complexe sunt construite prin includerea în clauza
WHERE a încǎ unei clauze SELECT. Forma generalǎ a unei astfel de
construcţii este:
SELECT <lista atributelor>
FROM <lista relatii1>
WHERE <subinterogare>
SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru
actualizarea bazelor de date. Comenzile pentru actualizǎri nu sunt atât de
complexe ca declaraţia SELECT.
Adǎugarea se face cu declaraţia INSERT care are douǎ forme prima accepta
adǎugarea unei singure linii, iar a doua adǎugarea mai multor linii.
84
I. Adǎugarea 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 specificǎm aceastǎ listǎ atributele pe care dorim sǎ le
omitem trebuie sǎ le declarǎm ca NULL. Numǎrul de elemente din cele douǎ
liste trebuie sǎ coincidǎ, sǎ aibǎ aceaşi ordine de declarare şi sǎ fie compatibile
ca tip.
Modificarea se face cu declaraţia UPDATE care permite modificarea datelor
unor înregistrǎri 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 declaraţia DELETE , sintaxa acestei comenzi este:
DELETE FROM nume_tabela
WHERE conditie_cautare









M3.U3.2. Test de autoevaluare a cunoştinţelor
Se dau următoarele relaţii cu schemele lor:
-Scări (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, 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.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2
3.2.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3
3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34
3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp
3.2.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi
pe scara 1 a aceluiaşi bloc
Răspunsurile se găsesc la sfârşit la pag 154
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.





M4. Obiectivele modulului
La sfârşitul acestui modul studenţii vor fi capabili să:
 descopere dependenţele funcţionale între atribute, şi să le pună în
evidenţă proprietăţile
 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 învăţare 4.1 De ce este nevoie de normalizare şi cu ce instrumente facem
normalizarea.



M4.U4.1. Introducere
Procesul de normalizare este o metodă formală care identifica relaţiile
bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF)
şi pe dependenţele funcţionale 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 relaţionala poate fi
normalizata la forma normala dorita, pentru a se preveni aparitia anomaliilor la
actualizare.



M4.U4.1. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 realizeze importanţa normalizării
 descopere dependenţele funcţionale între atribute, şi să le pună în
evidenţă proprietăţile


Durata medie de parcurgere a primei unităţi de învăţare 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 relaţii cu
scopul de a minimiza redundanţa informaţiilor şi (odata cu aceasta) spaţiul ocupat de relatii
(tabele sau fişiere) pe suportul magnetic.

Exemple
Fie relaţia 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
Relaţia Furnizori_Cheltuieli instanţiată
Sa presupunem ca aplicaţia 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.
Informaţia 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 redundanţei informatiilor din baza de date, o reprezinta problemele de
actualizare a informaţiei 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ă către un furnizor, în relaţia
Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre furnizorul în cauză,
chiar dacă ele există deja în baza de date. Această anomalie poate duce la apariţia de
informatii diferite despre acelasi furnizor în înregistrări 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 adăuga detalii despre un furnizor nou în relaţia Furnizori_Cheltuieli, trebuie
neapărat adăugată şi o cheltuială pentru asociaţia de locatari către 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 asociaţiei de locatari către 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 relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui atribut al unui
furnizor, va trebui să schimbăm datele pentru fiecare apariţie a acelui furnizor. De exemplu
dacă dorim să schimbăm codul fiscal al furnizorului cu codul F100, va trebui să schimbăm
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 relaţionale se poate
considera egalitatea;
r
i
=
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.
Dependenţe funcţionale
Unul din cele mai importante concepte asociate cu normalizarea este conceptul de
dependenţă funcţională. Dependenţa funcţională 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 A÷B 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 funcţionale, atributul, sau mulţimea
atributelor din partea stângă a săgeţii.

Exemple O parte dintre dependenţele funcţionale pentru relaţia
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
K÷R, adica pentru orice pereche de tuple t
1
şi t
2
din r, pentru care t
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. Dependenţa funcţională este o proprietate legata de
semantica atributelor în relaţii. Dependentele functionale pot fi stabilite de cine cunoaste exact
legaturile intre valorile atributelor, deci de catre cineva care cunoaste foarte bine aplicaţia ş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 Y÷X, atunci are loc
X÷Y;
2) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca X÷Y atunc
WX÷WY;
3) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi daca X÷Y şi
Y÷Z atunci are loc şi X÷Z.
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 X÷Y şi X÷Z
90
atunci şi X÷YZ;
5) regula descompunerii – daca daca X, Y şi Z sunt subseturi de atribute din R şi daca
X÷YZ atunci au loc şi X÷Y şi X÷Z;
6) regula pseudotranzitivitatii - daca X, Y, W şi Z sunt subseturi de atribute din R şi daca
X÷Y şi WY÷Z atunci şi WX÷Z

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: A÷B, A÷C, CG÷H, CG÷I, B÷H.
Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:
- A÷H, utilizand regula tranzitivitatii aplicata la dependentele A÷B şi B÷H;
- CG÷HI, utilizand regula reuniunii pentru dependentele CG÷H şi CG÷I;
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 joncţiune
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 relaţionala. 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 proiectării incorecte pot apărea anomalii la in serare de noi
ănregistrări, la şterger şi la modificări.
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 relaţionale se poate considera
egalitatea;
r
i
=
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 A÷B
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].
Regulile (Axiomele) lui Armstrong:
7) regula reflexivitatii – daca X este un subset de atribute din R şi Y÷X,
atunci are loc X÷Y;
8) regula creşterii – daca X, Y şi W sunt subseturi de atribute din R şi daca
X÷Y atunc WX÷WY;
9) regula tranzitivitatii – daca X, Y şi Z sunt subseturi de atribute din R şi
daca X÷Y şi Y÷Z atunci are loc şi X÷Z.






M4.U4.1. Test de autoevaluare a cunoştinţelor
4.1.1 Descoperiţi dependenţele funcţionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))
Răspunsurile se găsesc la sfârşit la pag 155







93
Unitatea de învăţare 4.2 Forme normale



M4.U4.2 Introducere
Procesul de normalizare a fost introdus de E. F. Codd (1972). Iniţial s-au propus
trei forme normale, notate 1NF, 2NF, respectiv 3NF. Mai târziu, 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.




M4.U4.2. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 descopere anomaliile din descrierea unei baze de date
 aducă o bază de date la formele normale 1, 2 şi 3.



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
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 până
la un anumit grad, adica se aduce la o anumita forma normala.
Normalizarea se execută trecând prin toate formele normale, până la forma normală cerută. La
proiectarea unei baze de date e recomandabil sa se ajunga cel puţin 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 conţine una sau mai multe grupuri
repetitive pe atribute.
Forma Normală Unu (1NF): Spunem ca o relaţie 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 următor în forma normală unu, identificăm şi
ştergem grupurile repetitive din tabelă. Eliminarea acestor grupuri repetitive se poate realiza
în două moduri:

Exemple 4.2.1
Pentru relaţia Furnizori_Cheltuieli:
Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data
Valoare
F100 Romgaz R1234567 C15 Incalzire 30.06.99
2,150,000
C16 Apa calda 30.06.99 500,000
F110 Renel R7654321 C10 Iluminat 30.06.99
3,000,000
94
C11 Lift 30.06.99 200,000
Tabela nenormalizată Furnizori_Cheltuieli.

Conform primei modalităţi, eliminăm grupurile repetitive, prin crearea altor
înregistrări, î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ă
relaţie împreună cu cheia primară din tabela iniţială. Putem avea mai multe grupuri repetitive.
În acest caz creăm mai multe relaţii noi. Aceste relaţii noi, precum şi tabela normalizată vor fi
în formă normală unu.
Observăm 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
intersecţie linie coloană.
Daca vom normaliza dupa prima metoda, vom scrie repetiţiile pe diferite rânduri iar
coloanele care nu conţin repetiţii, vor fii copiate corespunzator pe fiecare rând

Exemple 4.2.2
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
Tabela Furnizori_Cheltuieli în 1NF


În tabela normalizatã, cheia va fi (Cod_furn, Cod_chelt, Data).
Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu
informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două
tabele vor fi următoarele:


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

Relaţiile Cheltuieli şi Furnizori, create prin metoda a doua de normalizare.

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

Exemple 4.2.4
De exemplu să luăm următoarea dependenţă funcţională:
Cod_chelt, Cod_furn, Data ÷ Valoare
Dependenţa funcţională 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 relaţiile care au cheie compusă pe poziţie
de cheie primară. Relaţia la care cheia primară se compune dintr -un singul atribut, este în 2NF
daca este in 1NF.
Forma Normală Doi (2NF). O relaţie este în forma normală doi, dacă este în forma normală
unu şi fiecare atribut care nu aparţine cheii primare, este total dependent funcţional de cheia
primară.
Vom demonstra aducerea la forma normală doi, folosind relaţia 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 transformări, vom obtine următoarele relaţii:


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
Relaţia 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. Relaţiile rezultate după trecerea la 2NF a relaţiei
Furnizori_Cheltuieli.
Relaţiile rezultate au următoarele 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 conţine atâta redundanţă ca forma normală unu,
totuşi există cazuri în care pot apărea anomalii la actualizare. Aceste anomalii apar din cauza
redundanţei generate de dependenţa tranzitivă.
Dependenţă tranzitivă. Dacă atributele A, B, C sunt în relaţiile A÷B şi B÷C, atunci
spunem că atributul C este dependent tranzitiv de atributul A, via B.
Forma Normală Trei (3NF). Spunem ca o relaţie este în formă normala trei daca este deja in
forma normală doi şi nici un atribut care nu aparţine cheii p rimare nu este tranzitiv dependent
de cheia primara.
În cazul existenţei dependenţei tranzitive, ştergem coloanele care sunt tranzitiv
dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane, împreună cu
determinantul lor, adică cheia primară.
Examinând relaţiile în forma normală de mai sus, observăm că nu există dependenţe
tranzitive. Deci relaţiile sunt în formă normală trei.

Exemple
Să considerăm tabela cu schema:
Carte=(cod_car,titlu,cod_dom,denumire_domeniu)
Cheia este cod_car.
Avem depemdenţele funcţionale:
cod_car ÷cod_dom
cod_car ÷titlu
cod_dom denumire÷domeniu
vedem că dependeţa 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 încât să nu conţină dependenţe parţiale sau
tranzitive, pentru că altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului.
Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. O relaţie cu o
singură cheie candidat în formă normală trei este şi în formă normală Boyce -Codd.
Forma normală Boyce-Codd (BCNF). Spunem ca o relaţie este în forma normală Boyce-
Codd dacă şi numai dacă orice determinant din relaţie este cheie candidat.
Să căutăm determinanţii din exemplul de mai sus:
Cod_furn ÷ Den_furn, Cod_fiscal
Cod_chelt ÷ Den_chelt
Cod_furn, Cod_chelt, Data ÷ Valoare
97
Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. Deci relatiile din
exemplul de mai sus sunt în formă normală Boyce-Codd. Relaţiile în formă normală trei sunt
în general şi în formă normală Boyce-Codd. În cazul în care relaţia nu este în formă normală
Boyce-Codd, trecerea la BCNF se realizează prin ştergerea din relaţia iniţială a atributelor
care sunt asociate unui determinant care nu este cheie candidat şi crearea unei noi relaţii cu
aceste atribute şi determinantul lor.
Există situaţii când este foarte greu de descompus relatiile, ca să ajungem la BCNF. În
aceste situaţii este indicata rămânerea la forma normală trei.



M4.U4.2. Rezumat
Forma Normală Unu (1NF)
Trebuie să căutăm toate intersecţiile de linii şi coloane, unde există repetiţii.
Aceste repetiţii se pot elimina prin două madalităţi:
- Crearea de noi înregistrări pentru fiecare valoare a repetiţiei, după care se caută
o nouă cheie primară.
- Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care vor
conţine atributele şterse, precum şi cheia primara din relaţia iniţială.
Forma Normală Doi (2NF)
Se caută dependenţele totale de cheia primara, adică toate atributele care depind
funcţional de un subset de atribute a cheii primare. Dacă cheia primară este
compusă dintr-un singur atribut, atunci relaţia este în forma normală doi, daca
este deja in forma normala unu. Dacă există dependenţe partiale, ştergem
atributele care depind parţial de cheia primara şi creăm o relaţie 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ă eliminăm dependenţele tranzitive.
Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv de cheia
primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi
determinantul lor.
Forma Normală Boyce-Codd (BCNF)
Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie să
fie cheie candidat. În cazul în care nu este îndeplinită această cerinţă, vom şterge
atributele dependente funcţional de determinantul care nu este cheie candidat şi
creăm o nouă relaţie î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 rămânerea la forma normală trei.




98

M4.U4.2. Test de autoevaluare a cunoştinţelor
4.2.1) Aduceţi la forma normală 1 urmărtoarea tabelă:
Relaţia Furnizori_Cheltuieli:
Cod
Furn.
Denumire Cod
fiscal
Nr.
Crt.
Cod
Chelt.
Denumire
Cheltuială
Valoare
F100 Romgaz R1234567 1 C15 Chelt pt.
Încălzire
1500000
2 C16 Chelt pt.
Bucătării
500000
F110 Renel R7654321 3 C10 Chelt cu
iluminatul
3000000
4 C11 Chelt pt.
Func. liftului
200000
4.2.2 Aduceţi la forma normală 2 schema:
(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod,
Valoare)
4.2.3 Aduceţi la forma normală 3 schema:
carte = (c_carte, titlu, cod_domeniu, den_domeniu)
4.2.4 Aduceţi, pe rând, la formă npr mală 1, 2 şi 3 tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))
Răspunsurile se găsesc la sfârşit la pag 155



















99
Modulul 5. Metodologia de proiectare a bazelor de date
relaţionale




Cuprins
Introducere
Obiectivele modului
U5.1 Generalităţi şi proiectarea conceptuală
U5.2 Proiectarea logica
U5.3 Proiectarea fizica
U5.4 Tranzacţii şi concurenţă
U5.5 Metode de control al concurenţei.




M5. Introducere
Metodologia de proiectare este o aproximare structurată, care utilizează
proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul de
proiectare.
Metodologia de proiectare se compune din etape, care la rândul lor se
compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de
date.
În mod obişnuit, un sistem SGBD deserveşte mai mulţi 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 execuţia concurentă a mai multor procese. Execuţia concurentă a mai multor
procese poate avea loc atât într-un sistem uniprocesor, prin partajarea (împărţirea)
timpului de execuţie al procesorului între mai multe procese, cât ş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 numărul de procesoare ale sistemului,
accesul concurent al mai multor utilizatori la datele memorate în tabelele unei baze de
date necesită tehnici de menţinere a consistenţei (corectitudinii) şi a siguranţei datelor
memorate.




M5. Obiectivele modulului
La sfârşitul acestui modul studenţii vor fi capabili să:
 respecte o metodologie de proiectare
 creeze modelul conceptual al unui sistem informatic
 realizeze proiectul logic local
 realizeze proiectul logic global
 aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.
100
 descrie corect structura fizică a bazei de date
 proiecteze cereri
 proiecteze formulare
 proiecteze rapoarte
 construiască tranzacţii corecte
 aleagă cea mai bună metodă de control al concurenţei
 introducă regulile de integritate
 să impună măsuri de securitate































101
Unitatea de învăţare U5.1 Generalităţi ş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 puţin standardizată şi care
depinde esenţial de experienţa celui care o îdeplineşte, este proiectarea
conceptuală, în care trebuie să aflăm cum funcţionează intreprinderea şi ce parte
din circuitul informaţional va fi automatizată.



M5.U1. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 respecte o metodologie de proiectare
 creeze modelul conceptual al unui sistem informatic



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Î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 paşi asigură
divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat, iar partea de
impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul
nostru, realizarea modelului logic global. Un alt avantaj îl constitue faptul că la terminarea
activităţii de proiectare, avem o mare parte din documentaţia proiectului realizată. De
asemenea urmărirea uinei metodologii face posibil lucru în echipă prin divizarea sarcinilor ţi
posibibilitatea urmăririi stadiului la care s-a ajuns.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi
proiectarea fizică.
Definiţie: Proiectare logică: Procesul de construcţie a unui model de informaţii folosite într -o
întreprindere, bazată pe modelul de date, dar independent de particularizările 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 influenţa mai târziu modelul de date în care se va implementa.
Definiţie: Proiectare fizică: Este procesul de descriere a implementării bazei de date
într-un SGBD.
În această etapă a proiectării 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 activităţii de proiectare trebuie să fie satisfăcute mai multe cerinţe, multe dintre ele fiind
contradictorii şi dificil de îndeplinit: obţinerea unu i timp de răspuns la interogări cât mai mic, şi, în
acelaşi timp, utilizarea unui spaţiu de memorare cât mai redus; asigurarea unui mod de acces la date
cât mai simplu dar intuitiv, etc.
102
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai multe ori,
procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Prin contrast, proiectul
rezultat trebuie să conţină schema bazei de date precis definită, dat fiind că, după implementarea
aplicaţiilor, modificarea bazei de date este mult mai dificilă.
Terminologia folosită în domeniul proiectării bazelor de date este destul de variată, existând şi
unele ambiguităţi 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 lucrări din domeniul proiectării bazelor de date.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă
utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile
pentru aceasta. De asemenea, este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune
a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de salar izare, etc.).
În general, în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. De regulă, persoana cea
mai avizată din cadrul fiecărui grup de util izatori este cooptată ca participant în
activităţile ulterioare de colectare şi analiză a cerinţelor.
• Revederea documentaţiei existente privind aplicaţiile dorite, în afară de documentaţiile
aplicaţiilor dorite se studiază şi alte documentaţii şi interviuri. Se colectează
răspunsuri scrise de la utilizatorii potenţiali la diferite seturi de întrebări şi se
organizează interviuri cu persoanele care reprezintă diferitele grupuri de utilizatori,
în felul acesta, proiectanţii pot înţelege care sunt priorităţile de proiectare a
bazei de date, importanţa diferitelor aplicaţii şi performanţele dorite de la acestea.
Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii,
formularele existente de introducere a datelor, rapoartele utilizate în controlul activităţii
respective, etc.), pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date.
• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.
Această activitate include analiza fluxului de informaţii în cadrul sistemului, precum
şi analiza tipurilor de tranzacţii şi a frecventei de lansare a acestora. Deosebit de
importantă este şi stabilirea volumului de date conţinute în mod tipic de baza de
date, a volumului şi frecvenţei datelor actualizate precum şi a volumului datelor
retumate de interogări şi a frecvenţei acestora.
Chestionare structurate, în general în limbaj natural, pe baza cărora 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 paşii de urmat î n proiectare:
Pasul 1. Proiectarea logică a bazei de date relaţionale: Crearea unui model conceptual
local, pentru vederile utilizatorilor.
Pasul 1.1. Identificarea tipurilor de entităţi.
Pasul 1.2. Identificarea tipurilor de relaţii.
Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de
relaţii.
Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.
Pasul 1.6. Specializare/generalizare (pas opţional).
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 relaţiilor pentru modelul logic local.
Pasul 2.3. Validarea modelului, utilizând normalizarea.
Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.
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 paşi asigură divizarea problemei iniţiale în probleme mai
mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de
succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,
realizarea modelului logic global.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea
logică şi proiectarea fizică.
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai
multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.
Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce
rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce
informaţii primare sunt disponibile pentru aceasta.
în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele
activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.
• Revederea documentaţiei existente privind aplicaţiile dorite
• şi interviuri.
• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a
întreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate în controlul activităţii respective, etc.), pentru a se decide dacă
aceste aspecte influenţează cerinţele bazei de date.
• Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.


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 posibilităţii 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 relaţionale: Translatarea
modelului logic global în SGBD.
Pasul 4.1. Proiectarea relaţiilor de bază în SGBD.
Pasul 4.2. Crearea regulilor de integritate în SGBD.
Pasul 5. Proiectarea şi implementarea reprezentării fizice.
Pasul 5.1. Analizarea tranzacţiilor.
Pasul 5.2. Alegerea organizării fişierelor.
Pasul 5.3. Alegerea indecsilor secundari.
Pasul 5.4. Introducerea unei redundanţe comntrolate.
Pasul 5.5. Estimarea spaţiului 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 operaţional.
Proiectarea logică a bazei de date se divide în trei paşi mari. Primul pas are ca
obiectiv, descompunerea proiectării sistemului informatic în vederi, care se pot discuta cu
utilizatorii sistemului. Modelul de date astfel creat, se validează prin normalizare şi prin
tranzacţii în pasul doi. În final, se generează modelul global al întreprinderii, care este la
rândul lui validat şi verificat cu ajutorul utilizatorului sistemului.
Factori critici pentru succesul proiectării 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 validării conceptuale, prin normalizare şi prin tranzactii, la proiectarea
modelului logic de baze de date.
- Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile.
- Crearea dicţionarului de date, ca supliment al modelului de date.

Crearea modelului logic
Pasul 1. Crearea modelului conceptual local, pentru utilizatori.
Deşi nu este obligatoriu, această fază se poate menţine 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ă proiectanţii pot porni direct cu scheme conceptuale specifice unui anumit SGBD
(care se mai numesc şi scheme logice), este totuşi recomandabil să se realizeze mai întâi schema
conceptuală de nivel înalt independentă de SGBD, datorită următoarelor motive:
• Scopul proiectării schemei conceptuale este înţelegerea cât mai completă a structurii
bazei de date, a asocierilor şi a constrângerilor de către proiectanţi şi programatori. Acest
deziderat se obţine 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 restricţii şi soluţii particulare, care nu trebuie să influenţeze 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, discutând cu viitorii utilizatori ai bazei de date.
Acrastă discuţie presupune o despărţire în vederi, a bazei de date, vederi care pot lucra
separat.
Despărţirea în vederi se poate realiza în mai multe moduri. O modaliate ar fi analiza
datelor globale şi găsirea de părţi relativ independente. O altă modalitate ar fi analiza
rapoartelor, procedurilor cerute şi/sau observarea sistemului existent în lucru.
Modelele conceptuale locale trebuie să conţină:
- tipuri de entităţi,
- tipuri de relaţii,
- atribute,
- domeniile atributelor,
- cheile candidat,
- chei primare
Paşii din prima etapă a proiectării logice sunt:
- Pasul 1.1. Identificarea tipurilor de entităţi.
- Pasul 1.2. Identificarea tipurilor de relaţii.
- Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de
relaţii.
- Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.
- Pasul 1.6. Specializare/generalizare (pas opţional).
- Pasul 1.7. Desenarea diagramei entity-relationship.
- Pasul 1.8. Verificarea modelului conceptual local cu ajutorul utilizatorului.
Pasul 1.1. Identificarea tipurilor de entităţi
Obiectivul: Identificarea tipurilor de entităţi principale în vederile utilizatorilor.
Primul pas în proiectarea bazei de date este identificarea entităţiilor din datele
furnizate de utilizatori. De exemplu, dacă avem informaţiile Nr_Mat, Nr_Bloc, Scara, Etaj,
Apartament şi Nume, putem identifica entitatea Locatari. În general putem identifica
entităţiile în mai multe moduri. De exemplu în locul entităţii Locatari, am putea crea o entitate
Locatari cu atributele Nr_Mat şi Nume, iar celelelte informaţii în entitatea
ProprietateLocatari.
Există cazuri când entităţiile sunt greu de identificat, pentru că modul de prezentare a
viitorilor utilizatori necesită explicaţii. Utilizatorii descriu aceste entităţi, folosind sinonime şi
omonime, ceea ce îngreunează identificarea entităţilor. Sinonimele prin care se descrie aceaşi
entitate, se pot considera sinonime şi la crearea modelului logic, evidenţiind aceste sinonime
ca diverse aliasuri ai entităţiilor.
Documentarea tipurilor de entităţi
După identificarea entităţiilor, le dăm câte un nume, iar aceste nume le vom evidenţia
în dicţionarul de date, împreună cu explicaţiile despre entităţi, precum şi posibilele aliasuri.
Pasul 1.2. Identificarea tipurilor de relaţii
Obiectivul: Identificarea relaţiilor importante dintre entităţi.
După identificarea entităţiilor, va trebui să identificăm şi relaţiile importante dintre
aceste entităţi. Relaţiile se descriu printr-un verb al relaţiei. De exemplu:
106

Exemple
 Scările sunt Locuite de Locatari
 Furnizorii Provoacă Cheltuieli


Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi facultate.
Descrieţi, printr-un verb al relaţiei, relaţia dintre student şi note.

La identificarea relaţiilor vom lua în considerare doar relaţiile care ne interesează.
Degeaba există şi alte relaţii care să se poată identificate, dacă nu prezintă importanţă pentru
problema noastră, atunci nu le luăm în consideraţie.
În cele mai multe din cazuri, relaţiile sunt binare, adică se realizează întrea exact două
entităţi. Există şi relaţii mai complexe, care se realizează între mai multe entităţi, sau relaţii
recursive, care pune în relaţie o singură entitate cu ea însăşi.
Determinarea cardinalităţii şi a participării la tipurile de relaţii
După identificarea tipurilor de relaţii, trebuie să determinăm cardinalitatea lor, alegând
dintre posibilităţiile: unu-la-unu (1:1), unu-la-multe (1:M), sau multe-la-multe (M:N). Dacă se
cunosc valori specifice ale cardinalităţiilor, aceste valori se scriu la documentarea relaţiilor. În
continuare determinăm şi participarea la relaţie, care poate fii totală, sau parţială.

Care este cardinalitatea relaţiei dintre student şi facultate.
Care este cardinalitatea relaţiei dintre student şi note.

Documentarea tipurilor de relaţii
După identificarea tipurilor de relaţii, le denumim şi le introducem în dicţionarul de
date, împreună cu cardinalitatea şi participarea lor.
Utilizarea modelării ER
Pentru vizualizarea sistemelor complicate, utilizăm diagrama ER, pentru că este mult
mai uşor de a cuprinde toate informaţiile. Vă propunem ca să utilizaţi întotdeauna diagrama
ER, pentru o mai bună vizualizare a datelor.
Pasul 1.3. Identificarea şi asocierea de atribute la tipurile de entităţi şi tipurile de
relaţii
Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii.
Următorul pas în metodologie este identificarea atributelor. Aceste atribute se
identifică în aceeaşi mod ca şi entităţiile. Pentru o mai uşoară identificare, trebuie să luăm
entităţiile şi relaţiile ra rând şi să ne punem următoarea întrebare: Ce informaţii deţinem
despre această … ? Răspunsul la această întrebare ne va da atributele căutate.
Atribute simple sau compuse
Este important să notăm dacă un atribut este simplu sau compus. Conform acestei
informaţii va trebui să luăm 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 lăsăm compus în caz contrar.

Exemple
De exemplu, atributul Adresă conţine informaţiile (Nr_Bloc, Scara, Etaj,
Apartament). Noi va trebui să prelucrăm aceste informaţii separat, deci vom
descompune acest atribut în cele patru atribute simple.

Descompuneţi 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, neavând nevoie de
aceste informaţii separat, le vom compune în atributul Nume.


Ce puteţi 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 numărul locatarilor de pe o scară se poate număra în tipul de entitate
Locatari. Deci acest atribut este atribut derivat.


Ce puteţi spune despre atributul vârsta 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 menţiona dacă un atribut este sau nu derivat.
Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau relaţii, ne
întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care să asociem atributul
respectiv.
În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va trebui să
decidem dacă generalizăm sau nu aceste entităţi, proces care este descris la pasul 1.6.
Documentarea atributelor
După identificarea atributelor, le asociem un nume, şi le înregistrăm în dicţionarul de
date, împreună cu următoarele informaţii:
- numele şi descrierea atributului,
- toate aliasurile şi sinonimele prin care este cunoscut atributul,
- tipul de date şi lungimea,
- valorile iniţiale 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 mulţime de valori pe care o poate lua. Pentru a controla în
totalitate domeniul atributelor, se poate evidenţia următoarele:
- setul de valori admisibile pentru un atribut,
- operaţiile admisibile asupra unui atribut,
108
- ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte atribute,
- mărimea şi formatul câmpului atributului.
Documentarea domeniilor atributelor
Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui 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
următoarele:
- cheia candidat, care are un număr minim de atribute,
- cheia candidat, care îşi va schimba cel mai rar valoarea,
- cheia candidat, care este cel mai puţin probabil să sufere modificări în viitor,
- cheia candidat, care este compusă din cele mai puţine caractere (în cazul atributelor de tip
caracter),
- cheia candidat, care este cel mai uşor 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ă reuşim să identificăm o cheie primară, atunci entitatea este
tare, altfel este slabă. O entitate slabă nu poate exista fără o entitate tare, care să-i fie
“părinte”. Cheia primară a entităţii slabe este derivată parţial sau total din cheia primară a
entităţii tari.
Documentarea cheilor primare şi alternante
Înscriem cheile primare şi pe cele alternante în dicţionarul de date.
Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional)
Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă, între entităţiile
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 entităţii respective. Dacă însă alegem procesul de
generalizare, vom căuta superclase pentru acea entitate.
Un exemplu pentru procesul de generalizare ar fii entităţiile Şef_de_scară şi Familii.
Ambele entităţi au atribuite următoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament şi
Nume. Pe lângă 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ă entităţi având atribute în comun, le putem generaliza în entitatea Locatari,
care va conţine atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar
atributele diferite - particularizările faţă de superclasă.
Pasul 1.7. Desenarea diagramei ER.
Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptuală a
vederilor utilizatorilor despre întreprindere.
În momentul acesta suntem în măsură să prezentăm 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 adevărată a vederii utilizatorului despre întreprindere.

Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest
model include diagrama ER şi documentaţia anexată. În cazul în care apare orice fel de
anomalie, repetăm procesul de mai înainte şi remediem problema.


Să ne reamintim...
Paşii din prima etapă a proiectării logice sunt:
- Pasul 1.1. Identificarea tipurilor de entităţi.
- Pasul 1.2. Identificarea tipurilor de relaţii.
- Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
- Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
- Pasul 1.6. Specializare/generalizare (pas opţional).
- Pasul 1.7. Desenarea diagramei entity-relationship.
- 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 paşi asigură divizarea problemei iniţiale în probleme mai
mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de
succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru,
realizarea modelului logic global.
Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică
şi proiectarea fizică.
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai
multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate.
Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită.
Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce
rezultate se aşteaptă utilizatorii potenţiali să obţină de la b aza de date respectivă şi ce
informaţii primare sunt disponibile pentru aceasta.
în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele
activităţi:
• Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor.
• Revederea documentaţiei existente privind aplicaţiile dorite
• şi interviuri.
110




M5.U5.1. Test de autoevaluare a cunoştinţelor
5.1.1. Realizaţi paşii de proiectare conceptuala locală pentru subsistemul
didactic din facultate.
Răspunsurile se găsesc la sfârşit la pag 156














• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a
întreprinderii, formularele existente de introducere a datelor, rapoartele
utilizate în controlul activităţii respective, etc.), pentru a se decide dacă aceste
aspecte influenţează cerinţele bazei de date.
Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.
Paşii din prima etapă a proiectării logice sunt:
- Pasul 1.1. Identificarea tipurilor de entităţi .
- Pasul 1.2. Identificarea tipurilor de relaţii.
- Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi
tipurile de relaţii.
- Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.
- Pasul 1.5. Determinarea atributelor care compun cheile candidate şi
primare.
- Pasul 1.6. Specializare/generalizare (pas opţional).
- Pasul 1.7. Desenarea diagramei entity-relationship.
- Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.

111
Unitatea de învăţare 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 unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 realizeze proiectul logic local
 realizeze proiectul logic global



Durata medie de parcurgere acestei unităţi de învăţare 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 relaţional,
transpunerea se face prin corespondenţa dintre elementele schemei conceptuale de
nivel înalt reprezentată prin diagrama Entitate-Asociere (tipuri de entităţi, atribute,
asocieri) şi elementele modelului relaţional (relaţii, atribute, referinţe). Se obţine un
proiect logic dependent de modelul de date, dar independent de sistem, în această
subfazâ se face şi analiza normalizării relaţiilor, normalizarea fiecărei relaţii până la
nivelul adecvat şi documentarea tuturor dependenţelor de date care nu
sunt determinate de chei ale relaţiilor (necesară pentru proiectarea procedurilor de
verificare şi impunere a dependenţelor respective).
 Rafinarea schemei conceptuale şi a schemelor externe obţinute anterior, astfel
încât să se utilizeze unele (sau cât mai multe) din facilităţile oferite de sistemul
SGBD ales (modul de generare a cheilor primare, definirea constrângerilor, 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
tranzacţiilor cerute.
În acest pas verificăm modelul conceptual creat în pasul anterior şi eliminăm din el
structurile care sunt dificil de realizat într-un SGBD. Dacă la sfârşitul 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
tranzacţiilor.
Activităţile din acest pas sunt:
- Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
- Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
112
- Pasul 2.3. Validarea modelului, utilizând normalizarea.
- Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.
- 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 întâi am pregătit un model conceptual bazat pe informaţiile date de utilizator.
Acest model trebuie prelucrat, pentru a putea fi uşor de prelucrat de sistemul de gestiune a
bazelor de date. Obiectivele acestui pas sunt:
(1) Eliminarea relaţiilor M:N.
(2) Eliminarea relaţiilor complexe.
(3) Eliminarea relaţiilor recursive.
(4) Eliminarea relaţiilor cu atribute.
(5) Reexaminarea relaţiilor 1:1.
(6) Eliminarea relaţiilor redundante.
(1) Eliminarea relaţiilor multe-la-multe
Dacă în modelul de date apar relaţii de tipul multe-la-multe (M:N), trebuie
descompuse în două relaţii unu-la-multe (1:M) prin adăugarea unei noi entităţi suplimentare.

Exemple
De exemplu, pot exista mai multe cheltuieli pentru o scară, dar şi o cheltuială
(factură) poate să se refere la mai multe scări. Deci relaţia dintre entitatea Scări şi
entitatea Cheltuieli este de M:N, ceea de este evidenţiat î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). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două relaţii 1:M.
113

Desfiinţaţi relaţia dintre student şi note.

Această relaţie se poate elimina, prin crearea unui tip de entitate suplimentar,
care să facă legătura dintre scări şi cheltuieli. Diagrama acestor relaţii se vede în figura b).
Notăm, că tipul de entitate nou creat - Pe_scări - este tip de entitate slabă, pentru că
depinde atît de tipul de entitate Scări, cât şi de tipul de entitate Cheltuieli.
(2) Eliminarea relaţiilor complexe
O relaţie complexă este o relaţie între mai mult de couă tipuri de entităţi. Dacă în
modelul conceptual apar relaţii complexe, acestea trebuie eliminate. Se pot elimina prin
crearea unui nou tip de entitate, care să fie în relaţie de tipul 1:M cu fiecare tip de entitate din
relatia iniţială, partea cu M a relaţiei fiind spre tipul de entitate nou creat.
(3) Eliminarea relaţiilor recursive
Relaţiile recursive sunt nişte relaţii particulare, prin care un tip de entitate este în
relaţie cu el însuşi. Dacă apare o astfel de relaţie în modelul conceptual, ea trebuie eliminată.
Eliminarea se poate rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare
entitate care este legată de entitatea din tipul de entitate iniţial. În acest caz vom avea o relaţie
de tipul 1:M între tipul de entitate iniţial şi tipul de entitate nou creat şi o relaţie de tipul 1:1
între tipul de entitate nou creat şi tipul de entitate iniţial.
(4) Eliminarea relaţiilor cu atribute
Dacă în modelul conceptual avem relaţie cu atribute, putem descompune această
relaţie, identificând un nou tip de entitate în care să înregistrăm atributele necesare.
(5) Reexaminarea relaţiilor de tipul 1:1
În modelul conceptual putem avea entităţi între care să avem relaţie de tipul 1:1. Se
poate întâmpla ca aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. Dacă suntem
în acest caz, unim cele două entităţi, cheia primară devenind cheia primară al uneia dintre
entităţi.
(6) Eliminarea relaţiilor redundante
O relaţie 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 relaţiile redundante nu sunt necesare. Decizia că o relaţie este redundantă trebuie să fie
precedată de o analiză amănunţită a relaţiilor care compun cele două drumuri dintre cele două
entităţi, pentru că pot apărea situaţii, când o relaţie 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 relaţii peste modelul logic local
Obiectivul: Crearea de relaţii peste modelul logic.
Relaţia pe care un tip de entitate o are cu alt tip de entitate este reprezentată prin
mecanismul cheie primară/cheie străină. Cheia străină pentru o entitate este reproducerea
cheii primare a altei entităţi. Pentru a decide entităţiile unde vom include copia cheii primare a
altei entităţi, trebuie înainte să identificăm entităţile “părinte” şi “fiu”. Entităţile “părinte” se
referă la acele entităţi ale căror chei primare se vor copia în entităţile “fiu”.
Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database
Definition Language - DDL). În acest limbaj, specificăm prima dată numele entităţii, urmat de
atributele asociate între paranteze. După aceea identificăm cheia primară şi toate cheile
alternante, precum şi/sau cheile străine.
114
Tipuri de entitaţi tari
Pentru tipurile de entităţi tari în modelul logic crearea unei relaţii include toate
atributele entităţii. Pentru atributele compuse al unei entităţi, vom include numai atributele
simple din compunerea atributului compus în descrierea entităţii.


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


Descrieţi relaţia dintre student şi catalog.

Tipurile de entităţi slabe
Descrierea tipurilor de entităţi slabe se face la fel ca şi tipurile de entităţi tari, cu o
completare şi anume, evidenţierea cheii străine.

Exemple
De exemplu descrierea tipului de entitate de mai sus se descrie astfel:
Plăţi (Data, Nr_mat, Valoare, Restanţă)
Cheie primară: Data, Nr_mat
Cheie străină: Nr_mat se referă la Familii(Nr_mat)


Descrieţi tabela catalog.

Menţionăm că în cazul acesta cheia străină este şi în compunerea chei primare. Deci
înainte de introducerea cheii străine, cheia primară nu identifica unic o entitate. La terminarea
acestui pas, putem identifica cheile prinare pentru toate tipurile de entităţi din modelul logic.
Tipurile de relaţii binare de tipul unu-la-unu (1:1)
Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de entitate E1 şi E2
găsim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2, sub
denumirea de cheie străină. Identificarea tipului de entitate “părinte” şi a tipului de entitate
“fiu” depinde de participarea entităţilor la relaţie. Tipul de entitate care participă parţial la
relaţie este desemnat ca fiind “părinte” iar cel cu participare totală “fiu”. Dacă ambele tipuri
de entitate participă parţial sau total la relaţie, atunci tipurile de entităţi se pot evidenţia ca
fiind “părinte” sau “fiu” arbitrar. În cazul în care participarea este totală, putem încerca să
combinăm cele două tipuri de entităţi într-una singură. Această compunere poate să fie
posibilă în cazul în care nici unul dintre cele două tipuri de entităţi nu mai ia parte la altă
relaţie.
Tipurile de relaţii binare de tipul unu-la-multe 1:M
Pentru toate relaţiile 1:M între două entităţi E1 şi E2 în modelul logic de date, vom
avea copia cheii primare a entităţii E1 în compunerea entităţii E2. Totdeauna entitatea de
partea unu a relaţiei este considerată entitate “părinte”, 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, creăm o nouă relaţie care va conţine atributul A împreună cu cheia primară a
entităţii E1 pe post de cheie străină. Cheia primară a noii relaţii va fi atributul A, sau dacă este
necesar, compunerea ei cu cheia primară al lui E1.
Documentarea relaţiilor şi a atributelor din cheile străine
Actualizăm dicţionarul de date, întroducând fiacare atribut nou introdus în
compunerea unei chei la acest pas.

Pasul 2.3. Validarea, utilizând normalizarea

Obiectivul: Validarea modelului logic, utilizând tehnica normalizării.
Examinăm procesul de normalizare după cum am descris în capitolul 5 Prin
normalizare trebuie să demonstrăm că modelul creat este consistent, conţine redundanţă
minimală şi are stabilitate maximă.
Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână
înpreună. Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru
că există o relaţie logică între ele. Câteodată baza de date nu este cea mai eficientă. Acesta se
argumentează prin următoarele:
- Proiectarea normalizată organizează datele în funcţie de dependenţele funcţionale. Deci
acest proces este situat undeva între proiectarea conceptuală şi cea fizică.
- Proiectul logic nu este un proiect final. El ajută priectantul să înţeleagă natura datelor în
întreprindere. Proiectul fizic poate fi diferit. Există posibilitatea ca unele tipuri de entităţi
să se denormalizeze. Totuşi normalizarea nu este un timp pierdut.
- Proiectul normalizat este robust şi independent de anomaliile de actualizare prezentate
înunitatea de învăţare anterioară..
- Calculatoarele moderne au mult mai multă putere de calcul, ca cele de acum câţiva ani.
Din această cauză, câteodată este mai convenabilă implementarea unei baze de date cu
puţină redundanţă, decât suportarea cheltuielilor pentru proceduril e adiţionale.
- Normalizarea produce o bază de date care va fi uşor extensibilă în viitor.
Pasul 2.2. Validarea modelului prin tranzacţii
Obiectivul: Verificarea ca modelul de date suporte toate tranzacţiile cerute de
utilizator.
În acest pas se validează baza de date prin verificarea tranzacţiilor ce se cer de catre
utilizator. Luând în considerare tipurile de entităţi, relaţiile, cheile primare şi străine, încercăm
să rezolvăm manual cerinţele utilizatorilor. Dacă reuşim să rezolvăm fiecare tranzacţie cerută,
atuci înseamnă că modelul creat este valid. Dacă nu putem rezolva o tranzacţie, atunci este
foarte posibil să fi omis un atribut, o relaţie, sau o entitate din modelul de date.
Trebuie să examinăm dacă baza de date suportă tranzacţiile cerute. Mai întâi ar fi prin
rezolvarea de tranzacţii.

Exemple
De exemplu să luăm relaţia 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 tranzacţiile prin fraze SQL.
Inserarea de detalii despre un nou furnizor.
Cheia primară al acestei entităţi este Nr_furnizor. Deci prima dată verific dacă
numărul 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 existenţa 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, actualizându-se
şi cheia străină î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 entităţi care nu
iau parte direct la nici o tranzacţie. Pentru verificarea acestor entităţi, vom verifica nişte
interogări pregătie special.
Pasul 2.5. Desenarea diagramei ER.
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 inconsistenţe. Dacă este necesar, putem produce un proiect fizic de bază de date,
pentru a putea vedea mai uşor ce reguli sunt necesare.
Vom considera cinci tipuri de reguli de integritate:
- necesitatea datelor,
- reguli asupra domeniului atributelor,
- integritatea entităţilor,
- integritatea referinţelor,
- regulile întreprinderii.
Necesitatea datelor
Există atribute care nu pot conţine 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 plătesc prin acea cheltuială.
Aceste reguli deja le-am identificat, când am documentat atributele în pasul 1.3.
Exemplu de relaţie
pentru validarea prin
tranzacţii.

117
Reguli asupra domeniului atributelor.
Unele atribute au un domeniu de definiţie bine definit. Aceste domenii trebuie
respectate. Domeniile de definiţie au fost deja identificate când am documentat domeniile
atributelor în pasul 1.2.
Integritatea entităţilor.
Cheia primară a entităţilor nu poate lua valori nule. De exemplu fiecare furnizor
trebuie să aibă un cod diferit de zero.
Aceste reguli au fost deja identificate, când am documentat cheile primare în pasul
1.5.
Integritatea referinţelor
Cheia străina din tipul de entitate “fiu” face ligătura cu o entitate din tipul de entitate
“părinte”. Deci, dacă cheia străină conţine o valoare, ea trebuie neapărat să se regăsească şi în
tipul de entitate “părinte”. De exemplu tipul de entitate Cheltuieli conţine cheia străină
Cod_furnizor, care se referă la Furnizori(Cod_furnizor). Dacă această cheie nu este nulă,
atunci trebuie să găsim un furnizor care să aibă acel cod.
Prima întrebare pe care trebuie să ne-o ponem este: Poate fii cheia străină nulă? În
cazul exemplului nostru asta ar însemna că există cheltuieli care nu se prătesc nimănui. Aceste
cazuri nu sunt admise de lege, deci nu putem avea valoare nulă în cheia străină din tipul de
entitate Cheltuieli.
În general dacă pariciparea tipului de entitate “fiu” este totală, atunci nu putem avea
valoare nulă în cheia străină. În caz contrar putem avea valoare nulă.
Pentru a demonstra diferitele cazuri la definirea acestor reguli, folosim relaţia de mai
sus dintre Furnizori şi Cheltuieli, care este de tipul 1:M. Considerăm următoarele cazuri:
Cazul 1: Inserarea unei entităţi în tipul de entitate “fiu” (Cheltuieli): Pentru a verifica
integritatea referinţei, verificăm dacă atributele din componenţa cheii străine (Cod_furnizor)
sunt vide, sau să existe entitate în tipul de entitate “părinte” care să aibă valoare cheii primare
egală cu valoare cheii străine.
Cazul 2: Ştergerea unei entităţi din tipul de entitate “fiu” (Cheltuieli): Ştergerea unei
entităţi din tipul de entitate “fiu” nu creează probleme la integritatea referinţelor.
Cazul 3: Actualizarea cheii străine în tipul de entitate “fiu” (Cheltuieli): Acest caz
este similar cazului 1.
Cazul 4: Stergerea unei entităţi din tipul de entitate “părinte” (Furnizori): Dacă se
şterge o entitate din tipul de entitate “părinte”, integritatea referinţelor se strică în cazul în
care există entităţi în tipul de entitate “fiu”, care se referă la entitatea ştearsă. Există strategii
severe de a rezolva integritatea referinţelor:
- FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte, 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 părinte este ştearsă, se şterg automat
toate entităţiile din tipurile de entităţi fiu. Dacă tipurile de entităţi fiu au şi ei la rândul lor
alte tipuri de entităţi fiu, se va efectua ştergerea în cascadă în toate tipurile de entităţi fiu,
până 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 părinte se şterge, atunci se vor seta
la valoare nulă toate cheile străine ai tipurilor de entităţi fiu în cascadă până la ultimul
nivel. În exemplul nortru, dacă se şterge un furnizor, at unci se vor seta la valoare nulă toate
referinţele la acest furnizor în tipul de entitate Cheltuieli. Acesta înseamnă că nu vom ştii
ca anumite cheltuieli la ce furnizor trebuie plătite.
118
- SETARE IMPLICITĂ Este analog cazului de setare la nul, cu diferenţa că aici se
setează cheia străină la o valoare implicită în loc de valoare nulă. În exemplul nostru putem
seta cheia străină din Cheltuieli la o valoare a cheii primare din Furnizori, care să conţină
un furnizor predefinit - de exemplu cu numele de “Furnizor şters”.
- FĂRĂ MODIFICARE În cazul ştergerii unei entităţi din tipul de antitate părinte, nu se
actualizează deloc cheile străine din tipurile de entităţi fiu.
Cazul 6: Modificarea cheii primare în tipul de entitate părinte (Furnizori): Dacă se
modifică cheia primară din tipul de entitate părinte, integritatea referinţelor se strică. Pentru
menţinerea integrităţii, se pot folosii toate cazurile descrise mai sus, dar cel mai indicat este
folosirea cazului CASCADĂ.
Regulile întreprinderii.
În final evidenţiem 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 dicţionarul 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
găsesc diferenţe, ne vom reîntoarce la paşii anteriori şi modificăm cele necasare.

Să ne reamintim...
Activităţile proiectării logice locale sunt:
- Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
- Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
- Pasul 2.3. Validarea modelului, utilizând normalizarea.
- Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.
- 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 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
tranzacţiilor. Acest proces utilizează aceleaşi tehnici pe care le-am descris la paşii 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, funcţie sau
aplicaţie. Activităţile 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 posibilităţii 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 puţine vederi ai utilizatorilor, este relativ uşor de a
compune modelele logice locale. În cazul unui sistem mai mare însă, trebuie să urmăm un
proces sistematic de realizare a modelului global. Paşii acestui proces sunt următoarele:
(1) Verificarea numelor entităţilor şi a cheilor lor primare.
(2) Verificarea numelor relaţiilor.
(3) Compunerea entităţilor de pe view-urile locale.
(4) Includerea (fără compunere) a entităţilor care apar pe doar una dintre view-uri.
(5) Compunerea relaţiilor de pe view-urile locale.
(6) Includerea (fără compunere) a relaţilor care apar pe doar una dintre view-uri.
(7) Căutarea entităţilor şi a relaţilor care lipsesc (dacă există).
(8) Căutarea cheilor străine.
(9) Căutarea regulilor de integritate.
(10) Desenarea modelului logic global.
(11) Actualizarea documentaţiei.
Cel mai uşor de compus mai multe modele locale este compunerea succesivă a două
câte două dintre modele.
(1) Verificarea numelor entităţilor şi a cheilor lor primare.
Această verificare se face folosind şi dicţionarul creat în decursul paşilor de dinainte.
Probleme apar doar atunci când:
- Două entităţi au acelaşi nume, dar sunt de fapt diferiţi.
- Două entităţi sunt aceleaşi, dar nu au aceleaşi nume.
Probabil va fi necesară analizarea atributelor antităţilor, prntru a rezola această
problemă. În particular, putem utiliza cheia primară şi numele entităţii, pentru a identifica
entităţile echivalente.
(2) Verificarea numelor relaţiilor.
Această activitate este asemănătoare celei descrise la entităţi.
(3) Compunerea entităţilor de pe view-urile locale.
Examinăm numele şi atributele entităţilor ca vor fi compuse. Activităţile care se includ
în acest pas sunt:
- Compunerea entităţilor cau au aceleaşi nume şi aceleaşi chei primare.
- Compunerea entităţilor care au aceleaşi nume, dar cu chei primare diferite.
- Compunerea entităţilor care au nume diferite, cu chei primare egale sau diferite.
Compunerea entităţilor care au aceleaşi nume şi aceleaşi chei primare. În general
entităţile cu aceleaşi chei primare reprezintă “lumea reală”, şi deci pot fi compuse. Atributele
care apar în entităţile 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 acelaşi atribut dar descompus în atribute
simple, atunci vom întreba, dacă se poate, utilizatorii pentru a decide asupra formei de
utilizare a atributului.
Compunerea entităţilor care au aceleaşi nume, dar au chei primare diferite. În astfel
de situaţii, căutăm două entităţi care au aceleaşi nume şi nu au aceleaşi chei primare, dar au
aceleaşi chei candidat. Cele două entităţi pot fi compuse, urmând ca după compunere să
alegem o cheie primară, restul rămănând chei alternante.
120
Compunerea entităţilor care nu au nume comune şi nu au aceleaşi chei primare.
Aceste entităţi se pot depista prin analiza atributelor celor două entităţi.
(4) Includerea (fără compunere) a entităţilor care apar doar într-un view.
Pasul anterior identifică toate entităţile comune. Celelalte entităţi, se vor include în
modelul logic global exact aşa cum apar în view-ul respectiv.
(5) Compunerea relaţiilor de pe modelele locale.
În acest pas analizăm similitudinile dintre relaţii de pe diferite modele locale. În
timpul compunerii relaţiilor trebuie rezolvate şi conflictele dintre relaţii, ca şi regulile de
cardinalitate şi participare. Putem compune relaţii care au aceleaşi nume şi acelaşi scop, sau
acelaşi scop, dar nume diferite.
(6) Includerea (fără compunere) a relaţiilor care apar doar pe un view.
Relaţile care au rămas neincluse în modelul global după pasul anterior, se includ în
modelul global fără modificare.
(7) Căutarea entităţilor şi relaţilor care lipsesc.
Este unul din cei mai grei paşi din crearea modelului global. Trebuie căutate acele
entităţi şi relaţii, care s-au omis la paşii anteriori şi n-au ajuns în modelul global.
(8) Căutarea cheilor străine.
În decursul paşilor anterioare, s-au modificat entităţi, chei primare şi chei străine. În
acest pas verificăm dacă cheile străine sunt corecte în fiecare entitate fiu şi efectuăm toate
modificările necesare.
(9) Căutarea regulilor de integritate
Verificăm 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 desenăm diagrama ER pentru modelul global de date.
(11) Actualizarea documentaţiei.
Actualizăm documentaţia, ca să reflecte toate modificările aduse în acest pas
modelului.
Pasul 3.2. Validarea modelului logic global.
Obiectivul: Validarea modelului global logic de date, folosind normalizarea, după care
folosind tranzacţile cerute.
Acest pas este schivalent cu paşii 2.3. şi 2.4., unde am validat modelul local de date.
Pasul 3.3. Verificarea posibilităţilor de extindere a bazei de date în viitor.
Obiectivul: Determinarea ca dacă modelul se acomodează uşor la modificări oricât de
mari ce pot intervenii în viitor.
Este important ca modelul creat să fie expansibil în viitor. Dacă modelul nu are
această calitate, viaţa lui poate fi scurtă şi pentru o mai mare modificare va trebui refăcută 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 paşii în
cauză.
121

Să ne reamintim...
Activităţile proiectării logice globale sunt:
- Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.
- Pasul 3.2. Validarea modelului logic global.
- Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
- Pasul 3.2. Desenarea diagramei ER finale.
- Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.




M5.U5.2. Rezumat
Activităţile proiectării logice locale sunt:
- Pasul 2.1. Proiectarea modelului conceptual local pe un model logic local.
- Pasul 2.2. Crearea relaţiilor pentru modelul logic local.
- Pasul 2.3. Validarea modelului, utilizând normalizarea.
- Pasul 2.2. Validarea modelului din nou, utilizând tranzacţiile.
- 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.
Activităţile proiectării logice globale sunt:
- Pasul 3.1. Compunerea medelelor logice locale într-un model logic global.
- Pasul 3.2. Validarea modelului logic global.
- Pasul 3.3. Verificarea posibilităţii de a completa baza de date în viitor.
- Pasul 3.2. Desenarea diagramei ER finale.
- Pasul 3.5. Verificarea modelului logic global cu ajutorul utilizatorului.



M5.U5.2. Test de autoevaluare a cunoştinţelor
5.2.1 Faceţi proiectul logic local pentru subsistemul didactic al
facultăţii.
Răspunsurile se găsesc la sfârşit la pag 158









122
Unitatea de învăţare 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 fişierelor bazei de date, pentru a obţine performanţe cât mai bune, pentru cât
mai multe din aplicaţiile proiectate. De asemenea, în această fază, se sciu programele care
dau cereri, formulare şi rapoarte.




M5.U5.3. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:

 aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.
 descrie corect structura fizică a bazei de date
 proiecteze cereri
 proiecteze formulare
 proiecteze rapoarte




Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
Fiecare SGBD oferă o varietate de opţiuni de organizare a fişierelor şi a modului de acces
la datele stocate: indexuri, gruparea înregistrărilor corelate în aceleaşi 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 fişierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv, cele mai
potrivite cu cerinţele de proiectare a sistemului de baze de date.
Ca parametri generali de alegere a opţiunilor proiectului fizic al unei baze de date relaţionale se
pot enumera:
Timpul de răspuns. Acesta este intervalul de timp dintre lansarea i execuţie a unei tranzacţii
şi primirea răspunsului la acea tranzacţie. Cea mai mare pondere în timpul de răspuns o are
execuţia operaţiilor î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 către sistemul de operare, timpi:
de comunicaţie, etc.).
Utilizarea spaţiului de memorare. Aceasta este dimensiunea spaţiului pe disc utilizat de
fişierele bazei de date şi de structurile de acces l date.
Capacitatea tranzacţionala (transaction throughput). Acesta este numărul mediu de
tranzacţii care pot fi prelucrate pe minut de către sistemul de baze de date, măsurat în
momentele de vârf ale încărcării. Acesta este un parametru critic în multe aplicaţii, în particular
în acele aplicaţii în care există un număr mare de utilizatori care accesează concurent baza
de date (aplicaţii bancare, rezervări de bilete, etc.).
123
In mod obişnuit, trebuie să fie specificate valorile medii şi limitele în cazurile cele mai
defavorabile ale acestor parametri în cadrul cerinţelor de performanţe ale sistemului. Pentru
compararea valorilor acestor parametri, corespunzătoare diferitelor decizii de proiectare
fizică, se fac diferite evaluări analitice sau măsurători experimentale (prototipuri, simulări).
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
aplicaţiilor care se vor executa şi în principal a interogărilor şi tranzacţiilor pe care acestea le
vor lansa, în continuare se vor prezenta câteva aspecte ale analizei interogărilor şi tranzacţiilor
necesare pentru a stabili opţiunile proiectului fizic al unei baze de date relaţionale.
Analiza atributelor accesate de interogări şi tranzacţii trebuie să evidenţieze:
Atributele de proiecţie, atributele care sunt conţinute în condiţiile de interogare şi atributele
comune a două sau mai multe relaţii pe care se execută joncţiunile. Astfel de atribute sunt
candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare) care
să accelereze operaţiile de interogare.
Atributele pe care sunt specificate condiţii de selecţie pentru operaţii 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 căror valori se modifică în cursul operaţiilor 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 operaţie de
actualizare a relaţiilor.
Analiza frecvenţei estimate de invocare a interogărilor şi a tranzacţiilor, împreună cu listele
de atribute care intervin în interogări şi tranzacţii, permit obţinerea unei situaţii globale
privind frecvenţa estimată de accesare a atributelor relaţiilor, în general, pentru volume mari de
prelucrări, se respectă regula "80-20". Această regulă stipulează că 80% din operaţiile de
prelucrare sunt executate în 20% din interogările şi tranzacţiile tuturor aplicaţiilor
implementate. De aceea, în cazurile practice nu sunt necesare statistici exhaustive ale
frecvenţelor de invocare a tuturor interogărilor şi a tranzacţiilor, ci este suficient să fie
determinate cele mai importante 20% dintre acestea.
Analiza constrângerilor de timp ale interogărilor trebuie să evidenţieze care dintre interogări
şi tranzacţii trebuie să se termine într-un anumit interval de timp. De exemplu, o tranzacţie
trebuie să se termine în mai puţin de 5 secunde în 95% din cazuri şi să nu depăşească niciodată
durata de 20 de secunde. Astfel de constrângeri pot fi folosite pentru a adăuga priorităţi
suplimentare atributelor candidate pentru indexare. Atributele de selecţie utilizate de interogări
şi tranzacţii cu constrângeri de timp devin candidate cu mare prioritate pentru indexare.
Tot în faza de proiectare fizică se poate rafina procesul de normalizare a relaţiilor, folosind
informaţiile de frecvenţă a invocării interogărilor şi tranzacţiilor şi constrângerile de timp
impuse unora dintre acestea, în general, pentru obţinerea unor timpi de răspuns mai mici
pentru unele interogări, se efectuează o denormalizare a unor relaţii, adică se combină două
sau mai multe relaţii existente într-o singură relaţie cu un grad de normalizare mai redus, în care
apar, bineînţeles, date redundante şi sunt posibile anomalii de actualizare. Odată cu
denormalizarea unor relaţii 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 străine Tipuri de date disponibile
Extensibilitatea tipurilor de date Specificarea domeniilor Uşurinţa restructurării Mecanism de
tabele derivate Controlul integrităţii Dicţionar de date Independenţa datelor Tipul de model de
date utilizat
Accesibilitate
124
Suport pentru standardele SQL Interfaţă cu 3GL Mulţi utilizator Securitate:
controlul accesului
mecanism de autorizare
Utilitare
Măsurarea performanţei Acordare (run/ng)/optimizare Facilităţi de încărcare/descărcare Suport
pentru administrarea BD
Dezvoltare
Instrumente 4GL
Instrumente CASE
Facilităţi vizuale
Proceduri de stocare, declanşatoare
Instrumente de dezvoltare Web
Controlul tranzacţiilor
Rutine de salvare şi restaurare Puncte de salvare intermediare Suport pentru jurnalizare
Granularitatea accesului simultan Strategia de rezolvare a interblocajelor Procesare paralelă a
interogărilor
Definirea fizică
Structuri fizice disponibile
întreţinerea structurii de fişiere
Uşurinţa reorganizării
Indexare
Atribute/înregistrări de mărime variabilă
Compresia datelor
Rutine de criptare
Cerinţe de memorie
Alte facilităţi/opţiuni
Evolutivitate
Stabilitatea furnizorului
Baza de utilizatori
Pregătire şi suport pentru utilizatori
Documentare
Sistem de operare cerut
Cost
Help oniine
Standarde utilizate
Managementul versiunilor
Optimizare a interogărilor
Scalabilitate
Suport pentru instrumente OLAP
Interoperabilitate cu alte SGBD
Integrare Web
Utilitare de replicare
Facilităţi de distribuire
Portabilitate
Cerinţe hardware
Suport pentru reţea
Facilităţi de orientare pe obiect
Arhitecturi pe două, trei... straturi
Performanţă
Rata de tranzacţii pe secundă (minut)
125
Număr maxim de utilizatori simultani
Suport pentru XML



M5.U5.3. Rezumat
Pasul 8. Proiectarea fizică şi implementarea bazei de date relaţionale:
Translatarea modelului logic global în SGBD.
Pasul 8.1. Proiectarea relaţiilor de bază în SGBD.
Pasul 8.2. Crearea regulilor de integritate în SGBD.
Pasul 9. Proiectarea şi implementarea reprezentării fizice.
Pasul 9.1. Analizarea tranzacţiilor.
Pasul 9.2. Alegerea organizării fişierelor.
Pasul 9.3. Alegerea indecsilor secundari.
Pasul 9.4. Introducerea unei redundanţe comntrolate.
Pasul 9.5. Estimarea spaţiului 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 operaţional.
Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de
calităţile SGBD-ului legatede Definirea datelor, Accesibilitate, Utilitare,
Dezvoltare, Definirea fizică şi Alte facilităţi/opţiuni



M5.U5.3. Test de autoevaluare a cunoştinţelor
5.3.1 Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.
Răspunsurile se găsesc la sfârşit la pag 160












126
Unitatea de învăţare U5.4 Tranzacţii şi concurenţă



M5 U5.4 Introducere
O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă
(atomică) a datelor unei baze de date prin care se asigură consist enţa acesteia.
În principiu, orice execuţie a unui program care accesează o bază de date poate fi
considerată o tranzacţie, dacă baza de date este într -o stare consistentă atât înainte cât şi
după execuţie. O'tranzacţie trebuie să asigure consistenţa bazei de date indiferent dacă a
fost executată individual sau concurent cu alte tranzacţii precum şi în condiţiile în care au
apărut defecte ale sistemului hardware în cursul execuţiei tranzacţiei.




M5.U5.4. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 construiască tranzacţii corecte



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator sau un
program, care accesează sau schimbă conţinutul bazei de date.
Tranzacţia este o unitate logică de lucru a bazei de date. Nu există reguli de stabilire
automată a acestei unităţi. Pentru a demonstra acest concept o să dăm următoarele exemple.
Fie schemele:
Personal = (nrmat, nume, adresă, salariu)
Proprietate = (nrprop, stradă, oraş, tip, nrmat)
care leagă proprietatea de o persoană prin nrmat printr -o relaţie de cardinalitate n la 1,
Putem avea următoarele tranzacţii:


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

care măreşte salariul cu 10%








127


Exemple 5.4.2
cit (nrmat =x )
şterge (nrmat = x )
pentru toate înregistrările din Proprietate
begin
cit ( nrprop, nrmat)
dacă (nrmat = x ) atunci
şterge (nrprop)
end

care şterge persoana x şi toate proprietăţile ei



O tranzacţie trebuie să transforme întotdeauna baza de date dintr-o stare consistentă
într-o altă stare tot consistentă.
O tranzacţie se poate termina în două moduri. Dacă tranzacţia s-a terminat cu succes,
atunci spunem că tranzacţia a făcut ‘commit’ şi baza de date a trecut în noua stare consistentă.
Dacă tranzacţia 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ă tranzacţia.
Spunem, în acest caz, că tranzacţia face ‘roll back’ este derulată înapoi. O tranzacţie care a
făcut ‘commit’ nu mai poate fi întreruptă, dar o tranzacţie întreruptă poate fi reluată mai târziu
şi atunci s-ar putea să se termine cu succes.
Un SGBD trebuie să aibă posibilitatea de a defini şi mânui tranzacţii.
Găsim astfel cuvintele cheie cu semnificaţie imediată BEGIN TRANSACTION, COMMIT,
ROLLBACK.

Proprietăţile tranzacţiilor.
Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să respecte
proprietăţile ACID.
- Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o unitate indivizibilă
care se execută în întregime sau deloc.
- Consistenţă o tranzacţie trebuie să transforme baza de date dintr-o formă consistentă
într-o altă formă tot consistentă.
- Independenţă o tranzacţie se execută inependent de oricare alta, adică efectele
parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie.
- Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în
baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior.
Dacă fiecare tranzacţie lucrează pe rînd, se pierde timp când calculatorul stă să aştepte
terminarea unei operaţii de intrare/ieşire, sau în timpul altei întreruperi. Pe de altă parte,
dacă lăsăm să lucreze deodată, fiecare în timpul lăsat liber de cel din nainte, zicem că
avem tranzacţii concurente. Concurenţa va mări randamentul timpului de lucru al
calculatorului dar ea trebuie controlată pentru că altfel poate da naştere la inconsistenţă.
Prezentăm în continuare, trei exemple în care arătăm cum se poate pierde cinsistenţa.
În primul exemplu tranzacţia T
1
citeşte contul lui x (bal
x
) şi scade 10 din cont.
Tranzacţia T
2
citeşte contul lui x (bal
x
) şi adună 100 la cont. Pornind cu un cont de 100,
evident că dacă se executa mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost
100-10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să
considerăm următorul plan de tranzacţii.
128
Un plan de tranzacţii este o secvenţă posibilă în timp a modului de execuţie a
tranzacţiilor. Putem observa, în timpii înscrişi în stânga, 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 numeşte problema pierderii actualizării.
Problema dependenţei de o tranzacţie neterminată apare când o tranzacţie este
lăsatăsă ‘vadă’ rezultatele intermediare alei alte tranzacţii înainte ca ea să facă ‘commit’.
Aceleaşi tranzacţii ca în figura precedentă se desfăşoară acum după un alt plan.


Exemple 5.4.4
Time

T
3
T
4
bal
x
A

t
1
begin_transaction 100
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, aţi putea spune că este bun, dar ţineţi cont că tranzacţia 4 a fost întreruptă
şi, când se va relua, va mai mări cu 100 contul ceea ce va deveni incorect.
Chiar şi când unele tranzacţii numai citesc baza de date se pot întâmpla neplăceri.
Această problemă este problema analizei inconsistente sau problema ‘citirii murdare’.
De exemplu tranzacţiile 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 următoare ce se poate întâmpla încazul concurenţei 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, lăsa concurenţa necontrolată, dar nici nu este profitabil să o
desfiinţăm de tot. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una
după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de tranzacţii este
neserial când tranzacţiile sînt concurente , adică între operaţiile unei tranzacţii se intercalează
operaţiile alteia. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat
acelaşi cu unul executat serial; acesta se va numi serializabil. Aveţi deja exemple de planuri
neserializabile.
130

M5.U5.4. Rezumat
 Tranzacţia este o acţiune sau o serie de acţiuni, executate de un singur utilizator
sau un program, care accesează sau schimbă conţinutul bazei de date.
Tranzacţiile trebuie să respecte proprietăţile ACID.
 Atomicitate este proprietatea ‘totul sau nimic’. O tranzacţie este o
unitate indivizibilă care se execută în întregime sau deloc.
 Consistenţă o tranzacţie trebuie să transforme baza de date dintr-
o formă consistentă într-o altă formă tot consistentă.
 Independenţă o tranzacţie se execută inependent de oricare alta,
adică efectele parţiale ale unei tranzacţii incomplete nu trebuie să
influenţeze o altă tranzacţie.
 Durabilitate efectele unei tranzacţii terminată cu succes sunt
definitiv înregistrate în baza de date şi nu se mai pot pierde în
tranzacţiile întrerupte ulterior.
Problemele concurenţei fără control sunt:
 problema pierderii actualizării.
 problema dependenţei de o tranzacţie neterminată
 problema analizei inconsistente sau problema ‘citirii murdare’.
Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una
după alta fără a intercala operaţii din altă tranzacţie. Spunem că un plan de
tranzacţii este neserial când tranzacţiile sînt concurente , adică între operaţiile
unei tranzacţii se intercalează operaţiile alteia. Vom spune că un plan de tranzacţii
este corect atunci când el are ca rezultat acelaşi cu unul executat serial; acesta se
va numi serializabil.



M5.U5.4 Test de autoevaluare a cunoştinţelor
5.4.1 Daţi exemple de pierdere a consistenţei.
Răspunsurile se găsesc la sfârşit la pag 161








131

Unitatea de învăţare U5.5 Metode de control al concurenţei.



M5U5.5 Introducere
Am văzut că problemele apar atunci când o tranzacţie ‘vede’ (citeşte) sau scrie
într-un moment nepotrivit. Ideile de a controla concurenţa sînt legate de a nu lăsa
pe celălalt (de a bloca) sau de a ţine cont de momente (de a marca timpul).




M5.U5.5. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 aleagă cea mai bună metodă de control al concurenţei



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.

Ce înseamnă să blocăm ? Când o tranzacţie blochează partajat (part_bloc) o anumită
unitate de memorie, o altă tranzacţir nu mai poate să rescrie tot acolo, iar când o tranzacţie
blochează exclusiv (ex_bloc) o alta nu mai poate nici să o citească.
Despre ce unitate de memorie este vorba? Aceasta este problema granularităţii la
care se face blocajul. Blocajul se poate face la nivel de:
- întreaga bază de date
- tabela(fişier)
- înregistrare (cel mai des)
- câmp din înregistrare
Mai spunem că avem granularitate dinamică atunci când SGBD-ul poate să schimbe
granularitatea în timpul unei tranzacţii.
Cititorul poate să demonstreze singur pe un exemplu (vezi problema ) că numai
simpla blocare urmată cândva de deblocare (debloc) nu asigură serializabilitatea.
Serializabilitatea este asigurată dacă se respectă protocolul de blocare în două faze.
Acesta constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a
doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se
mai pot face blocări.
Următoarele trei exemple reiau tranzacţiile 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
begin_transaction 100
A

t
2
begin_transaction ex_bloc(bal
x
) 100
A

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

t
4
AŞTEAPTĂ bal
x
= bal
x
+100 100
A

t
5
AŞTEAPTĂ scrie(bal
x
) 200
A

t
6
AŞTEAPTĂ 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
begin_transaction 100
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
AŞTEAPTĂ debloc(bal
x
) 100
A

t
7
AŞTEAPTĂ 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
AŞTEAPTĂ 100 50 25 0
A

t
6
scrie( bal
x
) AŞTEAPTĂ 90 50 25 0
A

t
7

ex_bloc(bal
z
)
AŞTEAPTĂ 90 50 25 0
A

t
8
cit(bal
z
) AŞTEAPTĂ 90 50 25 0
A

t
9
bal
z
= bal
z
+
10
AŞTEAPTĂ 90 50 25 0
A

t
10
scrie(bal
z
) AŞTEAPTĂ 90 50 35 0
A

t
11
debloc(bal
x

, bal
z
)
AŞTEAPTĂ 90 50 35 0
A

t
12
commit AŞTEAPTĂ 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 scuteşte de
probleme. Pezentăm în cele două exemple următoare rollback-ul în cascadă şi blocajul
ciclic.
Observaţi, în figura 9.7 la momentul t14 tranzacţia 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 întâmplă ş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 următor. Cele
două trnzacţii 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
AŞTEAPTĂ ex_bloc(bal
x
)
A

t
8
AŞTEAPTĂ AŞTEAPTĂ
A

t
9
AŞTEAPTĂ AŞTEAPTĂ
A

t
10
… AŞTEAPTĂ
A

t
11
… …

Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de precedenţă care arată
dependenţa între tranzacţii în felul următor:
- se crează un nod pentru fiecare tranzacţie
- se crează o muchie direcţionată Ti ÷ Tj dacă tranzacţia Ti aşteaptă 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
următorul:
135
x
y

Exemple 5.5.6




O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este protocolul cu
marcarea timpului (time stamp). Acest protocol ataşează un timp (timpul real din calculator
sau un număr care se măreşte autmat de câte ori este solicitat) fiecărei tranzacţii (marc(T)) şi
timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Deci
fiecare tranzacţie va avea o valoare de marcj şi fiecare înregiistrare prelucrată va avea două
marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care
spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).
Numai în următoarele trei situaţii se pun probleme deosebite:
1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie
cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început
mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă
trebuie întreruptă.
2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie
care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea
să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o
foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.
3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie
care a început mai târziu, 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 următoare se poate observa cum funcţionează 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 către tranzacţia T
13
violează regula 2 şi de aceea este întreruptă
şi reluată la momentul t
14

** la timpul t
14
scrierea de către tranzacţia T
12
poate fi ignorată conform celei de a treia
reguli
9.4 Tehnici optimiste.
Nu întotdeuna este necesar să pierdem timp în calculator controlând concurenţa.
Atunci când conflictele între tranzacţii sînt rare putem adopta aşa-numitele tehnici optimiste.
Asta înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure
serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’ să efectuăm un control care să
determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă
şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor
fi, şi ele, rare.
Distingem trei faze ale unui control optimist al concurenţei.
 Faza de citire. Această fază durează de la începutul tranzacţiei până înainte de
‘commit’. Tranzacţia citeşte valorile de care are nevoie din baza de date şi le stochează
in variabile locale. Actualizările nu sînt făcute direct în baza de date ci într-o copie
locală.
 Faza de validare. Urmează după faza de citire şi controlează dacă nu s–ar încălca
serializabilitatea în cazul că s-ar aplica actulizarea în baza de date. Dacă avem o
tranzacţie care numai citeşte baza (adică nu scrie), controlul constă în a verifica dacă
datele citite sînt încă datele curente în bază şi, dacă este aşa, atunci se face ‘commit’,
altfel se întrerupe şi se reia mai târziu. Dacă trnzacţia face şi rescrieri în bază, atunci se
verifică dacă se păstrează serializabilitatea şi dacă baza de date rămâne într-o stare
consistentă; dacă acest lucru nu se întâmplă, atunci se întrerupe.
 Faza de scriere. Este o fază care este necesară numai la tranzacţiile care fac rescrieri.
Dacă faza anterioară s-a terminat cu succes, atunci actualizările efectuate în copia
locală, sînt înregistrate definitiv în baza de date.
Iată cum se desfşoară acest tip de control:
Fiecărei tranzacţii îi este ataşat, la începutul primei faze, un marcaj start(T), la
începutul celei de a doua faze, valid(T) şi la sfârşit fin(T), după scriere în copia locală,
dacăeste cazul. Ca să treacă faza de validare trebuie să avem una din următoare le situaţii:
1) Toate tranzacţiile cu un marcaj mai mic, trebuie să se fi terminat înainte ca
tranzacţia T să fi început; adică fin(S) < start(T).
2) Dacă tranzacţia 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 tranzacţia anterioară S nu sînt cele citite de cea curentă
T şi
b. Tranzacţia anterioară S îşi completează faza de scriere înainte ca
tranzacţia curentă T să intre în faza de validare adică start(T) < fin(S) <
valid(T).
Deşi tehnicile optimiste sînt eficiente când conflictele sînt rare totuşi pot apărea multe
reluări (rollback); să reţinem că aceste reluări nu sînt în cascadă pentru că se lucrează pe o
coppie locală.
Ce ne facem dacă apar totiţi inconsistenţe? Trebuie s{ [putem recupera baza de date
într-o stare anterioară consistentă.
Controlul recuperării.
Din diferite motive se poate întâmpla 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 stări corecte a bazei de date şi posibilitatea de ajunge la zi cu
actualizările ulterioare.
O tranzacţie este formată din paşi mici care se execută pe rând şi când a început
acţiunea ‘commit’ ea nu s-a şi terminat. Datele sînt mai întâi 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 cădere, atunci SGBD-ul trebuie să reia scrierea (redo), iar dacă nu
s-au umplut bufferele şi a apărut o cădere atunci SGBD-ul trebuie să facă întreruperea şi
reluarea tranzacţiei (undo sau rollback).
Un SGBD trebuie să aibă un mecanism care să facă copii ale bazei de date şi jurnale
ale tranzacţiilor după care ele să poată fi refăcute. Copiile se fac autmat, fără intervenţii
manuale, şi recuperarea, în multe cazuri, trebuie să se facă tot automat.




M5.U5.5. Rezumat
 Avem două tipuri de tehnici pentru controlul concurenţei.
 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 tranzacţie, după ce s-a făcut 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) ataşează un timp fiecărei tranzacţii
(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a
unei înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare
înregistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut
tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia
care a scris-o (scri_marc).
 O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem
întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă
‘commit’, să efectuăm un control care să determine dacă a avut loc un conflict. Dacă
a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că
138
aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.



M5 U5.5 Test de autoevaluare a cunoştinţelor
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 concurenţei?
Răspunsurile se găsesc la sfârşit la pag 161























139


Unitatea de învăţare U5.6. Securitate şi integritate



M5U5.6 Introducere




M5.U5.6. Obiectivele unităţii de învăţare
La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 introducă regulile de integritate
 să impună măsuri de securitate



Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.
Integritate
Integritatea bazelor de date se refera la corectitudinea informaţiilor ş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
relaţionala 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 relaţional 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
aplicaţia concreta.
Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaţiei 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 aplicaţii.
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 aplicaţiile 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 informaţiilor ş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:
-acces fraudulos la date,
-pierderea confidentialitatii (secretului) datelor,
-pierderea caracterului privat al 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 aplicaţii.
4. Administrarea şi transmiterea drepturilor.




M5.U5.6. Test de autoevaluare a cunoştinţelor
5.6.1 Care sunt restricţiile 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 încălcată securitatea datelor într-o baza de date ?
5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.
5.6.8 Enumeraţi forme de autorizare.
Răspunsurile se găsesc la sfârşit la pag 162

















147




Raspunsuri la testele de autoevaluare.
Unitatea 1.2
1.2.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?
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 facultăţii?
Pasiuni, înălţime, greutate, culoarea părului
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 independenţei datelor.
-Asigurarea unei redundanţe 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 facilităţi sporite de utilizare a datelor
- Sporirea gradului de securitate a datelor împotriva accesului neautorizat la date.
-Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate,
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 inţeleasă nu numai
sub aspectul asigurarii accesului mai multor utilizatori la aceleaşi date, ci şi acela al
posibiliăţtii dezvoltarii unor aplicaţii fără a se modifica structura bazei de date.

1.3.2 Care sunt funcţiunile unui SGBD?
1. Funcţia 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 funcţie asigură:
-descrierea atributelor (câmpurilor) din cadrul structurii bazei de date,
-descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiasi
entităţi,
-definirea eventualelor criterii de validare a datelor,
-definirea metodelor de acces la date,
-definirea aspectelor referitoare la asigurarea integrităţii si confidenţi alităţii datelor, etc.
2. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează
urmatoarele activităţi:
- crearea (incarcarea) bazei de date;
- adaugarea de noi inregistrări;
- ştergerea unor inregistări;
- modificarea valorilor unor câmpuri;
- căutarea, sortarea şi editarea parţială sau totală a unei inregistrări virtuale etc.
3. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor
utlizatorilor cu baza de date. Sunt recunoscute mai multe categorii de utilizatori:
- utilizatori "liberi" sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de
informaţii (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, realizând proceduri
complexe de exploatare a bazei de date;
- administratorul bazei de date apare ca un utilizator special şi are rolul hotarâtor în ceea
ce priveşte funcţionarea optimă a întregului ansamblu.
4. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa
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 interogări utilizator în regim local,
independent de restul reţelei, sau este capabil să participe la procesarea unor date
situate în alte site-uri din reţea. Pentru a spune că un SGBD este distribuit trebuie
să existe cle puţin 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 organizaţională a multor
organizaţii, 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ă decât în cazul centralizat. Dacă se
semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să
continue să funcţioneze în condiţii satisfăcătoare
- fiabilitatea sistemului este îmbunătăţită. Se pot reface rapid fişiere distruse utilizând
replici aflate pe alte site-uri
- performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în
paralel a unor interog[ri
- un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile
implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem
centralizat de putere comparabilă de prelucrare. Costuri scazute se mai obtin daca se
realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest
lucru). De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la
nevoile organiza’iei (dacă de exemplu este necesară adăugarea unor site-uri în plus) decât
un calculator central de putere asemănătoare
- capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau
rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta
deloc) mersul activităţilor pe ansamblul sistemului distribuit.

1.4.3 Cum se poate face proiectarea alocării datelor?
Proiectarea corectă a unei baze de date relaţionale distribuite necesită, pe lângă cerinţele
cunoscute pentru sistemele centralizate, şi realizarea următoarelor:
- fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate
pe diferite site-uri în reţea
- replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor
- alocarea fragmentelor şi a replicilor pe diferite site-uri
Se cunosc patru strategii de alocare a datelor într -o baza de date relaţională distribuită:
150
a!. centralizat
Baza de date se află în întregime pe un singur site din reţea ş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 cuvântului. Dezavantajele sunt mai ales
costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute, având în
vedere că orice eroare care blochează accesul la baza de date, practic paralizează întreaga
activitate în reţea pe această direcţie.
a2. fragmentat (partiţionat)
Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe
diverse site-uri. Comentarii:
- aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale
- dacă nu există replici ale fragmentelor, costurile de stocare sunt reduse
- fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat
- dacă datele sunt distribuite corect, costurile de comunicare pot fi relativ scăzute
a3. replicat complet
Pe fiecare site se găseste o copie completă a bazei de date. Comentarii:
- eficienţa 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 combinaţie intre partiţionare, replicare şi centralizare cu scopul de a
se cumula, pe cat posibil, avantajele fiecărei 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ă relaţia R este descompusă în fragmentele R
1
, R
2
, …,R
n
, trebuie
luate măsuri care să prevină pierderea de informaţii
- reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit
cu fragmentarea. Aceasta regulă conservă dependenţele funcţionale.
- disjuncţie – 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 excepţie, cazul când o relaţie 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 relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor
relaţiei respective.
Un fragment orizontal se produce prin selecţie:
Fiecare tuplu din relatia R apare într-un anume fragment, o singură dată. Dacă se doreşte
reconstrucţia relaţiei, se utilizează reuniunea pentru a obţine relaţia R iniţiala.
R= R
1
R
2
…R
n

In general fragmentele unei relaţii R sunt disjuncte.
Fragmentarea pe verticală
Un fragment vertical dintr-o relaţie constă dintr-o relaţie care are ca atribute o submulţime a
atributelor relaţiei iniţiale.



Un fragment vertical se produce prin proiecţie:
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 puţin într- una din
submulţimile S
1
şi S
2
.
Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.
2 1
) ( r X r R r
N
=
Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care
asigură o descompunere fără pierderi la joncţiune.
In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. Se
admite existenţa 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 relaţională (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 corespunzătoare în algebra relaţională (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
relaţional, modelul de date retea şi modelul ierarhic de date.

Unitatea 2.2
2.2.1 Găsiţi cheile candidat ale tabelei student. Stabiliţi 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 Daţi exemple de relaţii unu la unu, unu la mai mulţi şi mulţi la mulţi.
Relaţia editură carte este de unu la mai mulţi pentru că o editură editează mai mul te cărţi dar o
anumită carte este scoasă de o singură editură (vez ISBN care este unic),
Relaţia student materii este de mulţi la mulţi pentru că un student face mai multe materii şi o
materie ete făcută de mai mulţi studenţi.
2.2.3 Stabiliţi domeniul fiecărui 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 mulţimea(preparator,asistent,lectoe,conferenţiar,profesor)
sex una din două M sau F

Unitatea 3.1
Cosideraţi instanţe 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) Faceţi selecţie din student după grupa 7271
1 Ion ion 7271
5 Dan soc 7271

f) Faceţi proiecţie la student şi la profesor după nume. La acestea două din urmă fac eţi
reuniunea.
Ion ion
Dan soc
Pan tor

Prof1
Prof2


g) Faceti joncţiunea 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) Faceţi selecţia 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 relaţională cererile:
e) Studenţii grupei 7271
o
grupa=7271
(student)
f) Studenţii care sunt şi profesori
154
H
nume
(student) · H
nume
(profesor)

g) Studenţii corigenţi
H
nume
(o
nota<5
(student j
N
catalog j
N
note))
h) Studenţii integralişti
H
nume5
(student) \ H
nume
(o
nota<5
(student j
N
catalog j
N
note))

Unitatea 3.2

Se dau următoarele relaţii cu schemele lor:
-Scări (Nr_bloc, Scara, Lift)
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale, 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
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=3) and (scari.scara= locatar.scara)

3.2.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locat ari.bloc)
and (scari.scara=1) and (scari.scara= locatar.scara)

3.2.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=2) and (scari.scara= locatar.scara)

3.2.4 tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34
select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=3) and (scari.scara= locatar.scara)
union select nume
from scari, locatari
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=1) and (scari.scara= locatar.scara)
union select nume
from scari, locatari
155
where (scari.bloc=34) and(scari.bloc = locatari.bloc)
and (scari.scara=2) and (scari.scara= locatar.scara)

3.2.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp
select Nr_bloc,Scara,Apartament
from apartamente
where suprafaţa > 50

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

Unitatea 4.1
4.1.1 Dependenţele funcţionale 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. Încălzire 1500000
2 C16 Chelt pt. Bucătării 500000
F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000
4 C11 Chelt pt. Func. liftului 200000

În această tabelă observăm 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 intersecţie linie coloană.
În cazul primei modalităţi, scriem repetiţiile pe diferite rânduri iar coloanele care nu
conţin repetiţii, vor fi copiate pe fiecare rând. După despărţirea repetiţiilor pe mai multe
rânduri, identificăm o nouă cheie.
Cod
Furn.
Denumire Cod
fiscal
Nr.
Crt.
Cod
Chelt.
Denumire
Cheltuială
Valoare
F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 1500000
F100 Romgaz R1234567 2 C16 Chelt pt. Bucătării 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.).
Normalizând tabela iniţială după a doua modalitate, vom crea o a doua tabelă cu
informaţiile care nu se repetă, împreună cu cheia primară din tabela iniţială. Deci cele două
tabele vor fi următoarele:
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)
Dependenţele d1 şi d2 sunt dependenţe parţiale de cheie.
Relaţiile rezultate au următoarea formă:
Furnizori = (Cod Furn., Denumire, Cod fiscal)
Tip cheltuială = (Cod Chelt., Denumire cheltuială)
Cheltuieli = (Nr. Crt., Cod Furn., Cod Chelt., Valoare)
Fie relaţia din enunţ:
carte = (c_carte, titlu, cod_domeniu, den_domeniu) cu cheia c_carte. În afara dependenţelor
care definesc cheia mai avem dependenţa:

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 relaţia:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))
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 dependenţele funcţionale:
nrmatricol,codmaterie÷ nota
codmaterie÷ denumirematerie aceasta fiind dependenţă parţială de cheie deci nu este FN2
se obţine forma finaţă:
stud1=( nrmatricol,nume,adresa)
catalog=( nrmatricol,codmaterie,nota)
materii=( codmaterie,denumirematerie)

Unitatea 5.1
5.1.1 Faceţi proiectul conceptual local pentru subsistemul didactic al facultăţii.
Pasul 1.1. Identificarea tipurilor de entităţi.
tipurile de entităţi sunt:
student, materii, profesori, orar, sali
157
Identificarea tipurilor de relaţii.
În continuare identificăm tipurile de relaţii. Tipurile de relaţii se reprezintă prin verbe
ale relaţiilor.
În continuare vom determina cardinalul şi participarea relaţiilor prezentate în tabelele
de mai sus. Cardinalul poate să fie unul dentre următoarele: unu-la-unu (1:1), unu-la-multe
(1:M), sau multe-la-multe (M:N). Participarea poate să fie parţială sau totală.


Tip de entitate Tip de relaţie Tip de entitate
cardinalitate participare
student face Materii
N:M P:T
profesor preda Materii
N:1 T:T
orar Relaţie
complexă cu
Zile, Sali, ore,
materii


Atributele tipurilor de entităţi

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 Faceţi proiectul logic local pentru subsistemul didactic al facultăţii.
Pasul 2.1. Proiectarea modelului local conceptual în modelul local logic.
În acest pas eliminăm 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
următorii paşi:
(1) Eliminarea relaţiilor de tipul N:M.
Este cazul relaţiei dintre student şi materii. Apare entitatea catalog.





(2) Eliminarea relaţiilor complexe.
Avem relaţia cu orarul. Se modifică în felul următor:
profesori
1
orar
sali zile ore
student
N







































materii
M N
student
N

























materii
N
catalog
1 1
159


(3) Eliminarea relaţiilor recursive. Nu avem.
(4) Eliminarea relaţiilor cu atribute. Nu avem.
(5) Reexaminarea relaţiilor 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 relaţii peste modelul logic local.
În acest pas vom crea relaţiile între entităţile din modelul logic local de date, cu
ajutorul mecanismului chei primare/chei străine. de exemplu:

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

Catalog=(nrmatricol,codmaterie,nota)
Cheie primară nrmatricol,codmaterie
Cheie străină nrmatricol referă nrmatricol din student
Cheie străină codmaterie referă codmaterie din materii

materii=(codmaterie,denmaterie)
Cheie primară codmaterie

Pasul 2.3. Validarea modelului prin normalizare.
În acest pas validăm baza de date prin normalizare. Procesul de normalizare este
descris amănunţit în capitolul 4.
- Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.
- Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia primară.
- Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de cheia primară.
- Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rămas.
Trebuie să analizăm fiecare relaţie care este descrisă în anexa 6.3.5. Verificăm dacă
relaţiile sunt în forma normală Boyce-Codd, iar dacă găsim una care nu satisface această
formă normală, ne întoarcem la paşii precedenţi şi rezolvăm problema.
În cazul nostru toate tabelele sunt în FN3
Pasul 2.2. Validarea modelului prin tranzacţiile cerute.
Tranzacţiile vor fi:
T1 Tabel nominal cu studenţii grupei…
T2 Catalogul grupei.. la materia…

Pentru fiecare tranzacţie 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
Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii.
Se vor urmări paşii din Access la purtător [8]


161
Unitatea 5.4
5.4.1 Daţi exemple de pierdere a consistenţei.
1) Tranzacţia T
1
citeşte contul lui x (bal
x
) şi scade 10 din cont. Tranzacţia T
2
citeşte
contul lui x (bal
x
) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se
execută mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-
10+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să
considerăm următorul plan de tranzacţii.

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(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 greşită 90.

Unitatea 5.5
5.5.1 Ce este blocajul?
1) Când o tranzacţie blochează partajat o anumită unitate de memorie, o altă tranzacţie nu
mai poate să rescrie tot acolo, iar când o tranzacţie 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 următor. Cele două trnzacţii 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
AŞTEAPTĂ ex_bloc(bal
x
)
A

t
8
AŞTEAPTĂ AŞTEAPTĂ
A

t
9
AŞTEAPTĂ AŞTEAPTĂ
A

t
10
… AŞTEAPTĂ
A

t
11
… …

5.5.3 Ce este protocolul de blocare în două faze?
1) Protocolul de blocare în două faze constă din împărţirea tranzacţiei în două faze una
de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă
că după ce s-a făcut prima deblocare nu se mai pot face blocări.

5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)?
Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii
(marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei
162
înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare
prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o
(cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc).
Numai în următoarele trei situaţii se pun probleme deosebite:
1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o
tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie
care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă
deci trnzacţia respectivă trebuie întreruptă.
2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o
tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă
că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută
mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă.
3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o
tranzacţie care a început mai târziu, 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 concurenţei?
O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri
care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’, să
efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc
un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste
conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare.

Unitatea 5.6
5.6.1 Care sunt restricţiile de integritate?
integritatea entitatii
- integritatea referentiala
- restrictiile de domeniu
- restricţiile de intreprindere
5.6.2 Ce înseamnă integritatea entitatii?
1) Intr-o relaţie 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 relaţie, ori valoarea cheii externe trebuie să se potriveasca
cu valoarea unei chei candidat a vreunui tuplu în relaţia de origine, ori valoarea cheii externe
trebuie să fie nulă.
5.6.4 Ce înseamnă restrictiile de domeniu?
Aceste restricţii se pot referi la tipul de date pentru un atribut, la o listă de valori
posibile, la un ordin de mărime, la un format sau o formă, la o condiţie 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?
Noţiunea de securitate a bazei de date este de obicei asociată cu accesul răuvoitor, pe cand
integritatea se refera la evitarea pierdelor accidentale de consist enţă
163
5.6.6 Cum poate fi încălcată securitatea datelor într-o baza de date ?
Securitatea este in general asociată cu urmatoarele situaţii:
-acces fraudulos la date,
-pierderea confidenţialitatii (secretului) datelor,
-pierderea caracterului privat al datelor,
-pierderea disponibiliţatii datelor.
5.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor.
Pentru protectia bazei de date se pot lua masuri de asigurare a securităţii 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 autorizaţiile de acces cu multa grijă şi
să se ţină evidenţe stricte ale persoanelor autorizate
-la nivel sistem de operare – slăbiciunile protecţiei la nivel de sistem de operare
trebuie eliminate sau compensate de alte măsuri
-la nivel SGBD – sistemul ofera anumite facilităţi care sprijina protecţia datelor.
5.6.8 Enumeraţi forme de autorizare.
Forme de autorizare:
-autorizare la citire (consultare)
-autorizare la inserare (adăugare)
-autorizare la actualizare (care exclude ştergerile)
-autorizare la ştergeri (la nivel de tuplu)
In situaţiile de mai sus nu se pune problema modificarilor la nivel de schemă a bazei de date.
Dacă considerăm şi acest aspect putem vorbi de:
-autorizare la nivel de index (creare-ştergere de indecşi)
-autorizare la nivel de relaţii (creare)
-autorizare de modificări la nivel de relaţii (ştergeri sau adăugari de atribute în cadrul
relaţiilor)
-autorizări de ştergeri ale relaţiilor.












164




Bibliografie.
[1] L.Ţâmbulea - Structuri de date şi bănci 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.Bâscă – 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 începători. Ed. Universităţii din Piteşti. 2000
[8]iacob P. Access la purtător Ed.Lux libris 2007
[9]iacob P. Oracle la purtător Ed.Lux libris 2008
[10] M. Stanescu şi colectiv - Limbaje de programare şi bănci 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.

Introducere
Aplicaţii tradiţionale bazate pe fişiere; limitări Pentru o mai bună înţelegere a evoluţiei prelucrărilor de date vom rezerva câteva rânduri la începutul cursului nostru pentru o scurtă trecere în revistă a metodelor tradiţionale de prelucrare a masivelor de date, aşa-numitele sisteme tradiţionale bazate pe fişiere. În primii ani, calculatoarele erau utilizate mai ales pentru a duce la bun sfârşit calcule laborioase în care nu erau implicate cantităţi prea mari de date, aşa-numitele calcule ştiinţifice. Odată cu apariţia limbajelor de nivel înalt şi a posibilităţii stocării de mari cantităţi de informaţie pe suport magnetic adresabil (memorie externa) s-a pus şi problema eficientizării prelucrării acestora. De data aceasta nu calculele creşteau costul în timp al prelucrărilor ci manipularea datelor, respectiv regăsirea, actualizarea, etc. S-a constatat că un factor important al creşterii eficienţei prelucrărilor este modul de organizare al informaţiilor. De aici şi până la a gândi sisteme unitare de reprezentare şi manipulare a masivelor de date na mai fost decât un pas. Prima variantă de prelucrare a cantităţilor mari de informaţie s-a bazat pe organizarea datelor sub forma înregistrărilor în fişiere tradiţionale pe suport adresabil. În această variantă se elaborau programe de aplicaţie care defineau şi manipulau propriile date şi aveau în general ca scop elaborarea de rapoarte pentru diverşi beneficiari. Aceste programe au avut menirea de a înlocui prelucrarea sistemelor de fişiere manuale care mai funcţionează şi astăzi în unele locuri cum ar fi cabinetele medicale. Aşadar prelucrările oferite de un sistem tradiţional bazat pe fişiere copiau în mare măsură metodele manuale de prelucrare. Evident că puterea de calcul şi memorare caracteristică sistemelor de calcul au făcut ca gama prelucrărilor să crească simţitor, la aceasta adăugându-se viteza şi siguranţa prelucrărilor. Cu toate că la momentul respectiv abordarea tradiţională bazată pe fişiere a fost un evident progres, putem să amintim aici şi o serie de limitări ale acestui sistem de prelucrare a datelor: Separarea şi izolarea datelor Duplicarea datelor Dependenţa datelor Incompatibilitatea fişierelor Interogări fixe / proliferarea aplicaţiilor Comentăm pe scurt în continuare semnificaţia acestora. Separarea şi izolarea datelor Accesul la date care se află în fişiere diferite este dificil deoarece cade în sarcina programatorului să sincronizeze înregistrările din fişiere în aşa fel încât datele extrase să fie corecte. Duplicarea datelor În situaţia în care se realizează prelucrări descentralizate de date, pe compartimente, este posibil să fie necesară duplicarea datelor. Totuşi duplicarea este de evitat din următoarele motive: - necesită costuri mari în timp şi spaţiu de memorie. - duce la pierderea integrităţii datelor. Datele nu mai sunt consistente, deci nu se mai poate conta pe ele.

1

Dependenţa datelor Aşa cum am subliniat deja, structura fizică şi modul de memorare al datelor este definit în fiecare program de aplicaţie în parte. Este evident cât de dificile sunt schimbările în structura datelor. Toate programele trebuie ajustate la noua structură de date. O simplă modificare a lungimii unui câmp poate genera probleme. Dependenţa se referă aşadar la dependenţa program-date. Incompatibilitatea fişierelor Această limitare se trage tot din dependenţa de programe a structurii fişierelor. Structura fiind descrisă în programe ea depinde de limbajul de programare. De exemplu, structura unui fişier declarată într-un program COBOL diferă de structura unui fişier generat de un program C. Dacă e necesară prelucrarea de date din ambele fişiere, programatorul este obligat să scrie programe de conversie, pentru a aduce fişierele la un format comun posibil de prelucrat. Interogări fixe / proliferarea aplicaţiilor Deoarece prelucrarea masivelor de date a devenit mai uşoara şi mai rapida cu ajutorul calculatorului, beneficiarii au lărgit gama prelucrărilor lansând interogări noi sau modificând interogări mai vechi, pentru obţinerea de informaţii mai complexe. Orice interogare nouă sau orice modificare a unei interogări mai vechi se rezolvă în sistemele tradiţionale prin realizarea de noi programe de către programatorul de aplicaţie. Inutil de subliniat cât de costisitoare sunt acestea. Un efect secundar era că se înmulţeau programele aplicaţiei şi de multe ori şi fişierele de prelucrat.

Obiectivele cursului Cursul de baze de date este un curs de bază pentru meseria de informatician. La sfârşitul acestui curs, studenţii vor fi capabili să:  Proiecteze o bază de date  Programeze cereri în SQL  Realizeze un sistem cu bază de date

Cerinţe preliminare Cursul se va susţine studenţilor după cursul de structuri de date. Cunoştinţele 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.

2

iar al cincilea modul cuprinde şase unităţi de învăţare. al doilea modul cuprinde două unităţi de învăţare.Structura cursului Cursul de baze de date este structurat în trei module. Durata medie de studiu individual Parcurgerea de către studenţi a unităţilor de învăţare ale cursului de baze de date (atât aspectele teoretice cât şi rezolvarea testelor de autoevaluare şi rezolvarea problemelor propuse) se poate face în 1-4 ore pentru fiecare unitate. aspecte teoretice privind tematica unităţii de învăţare respective. 3 . exemple. astfel: primul modul cuprinde patru unităţi de învăţare. al treilea modul cuprinde două unităţi de învăţare. La rândul său. La sfârşitul fiecărui modul sunt date teste de autoevaluare. care va cuprinde: un examen scris cu materia din modulele 1. fiecare unitate de învăţare cuprinde: obiective. 3 şi 4 care va deţine o pondere de 60% în nota finală şi notele aferente celor două capitole de la laborator ACCESS şi ORACLE. Rezolvarea acestor teste se găseşte la sfârşitul cărţii. fiecare student va primi o notă. al patrulea modul cuprinde două unităţi de învăţare. Evaluarea La sfârşitul semestrului. teste de autoevaluare precum şi probleme propuse spre discuţie şi rezolvare.

.......... Metodologia de proiectare a bazelor de date relaţionale .... ......................... ............................. ............................................ ........ 101 Unitatea de învăţare U5.....5 Metode de control al concurenţei................... ..........................4 Baze de date distribuite .......... 10 Unitatea de învăţare 1........... . . ............... ............. 5 Unitatea de învăţare 1.......................... Securitate şi integritate ..........1 De ce este nevoie de normalizare şi cu ce instrumente facem normalizarea........ ....... 54 Unitatea de învăţare 3..............................4 Tranzacţii şi concurenţă..... ......................... ............2 SQL . 99 Unitatea de învăţare U5................ ........ 131 Unitatea de învăţare U5..... 147 Bibliografie............................... 27 Modulul 2.......... ..... .......... ......... .................................................1. ......2 Abstractizarea datelor.. 139 Raspunsuri la testele de autoevaluare............................. 14 Unitatea de învăţare 1...... 86 Unitatea de învăţare 4.......................... ............. Generalităţi ........ 6 Criterii minimale de definire a unui SGBDR ............... ............................................................................. ................... 19 Unitatea de învăţare 1......6.. Modele de descriere a datelor ... ........................ 122 Unitatea de învăţare U5.............. Sisteme de Gestiune a Bazelor de Date (SGBD) ............ ........................ ... ......................................................2 Modelare E-R (Entity-Relaţionship) ...... ................... 53 Unitatea de învăţare 3........ ................... Normalizarea............................................................................................... .......... ........ ......................................... ........................ 41 Modulul 3................ ... ................. ...1 Generalităţi şi proiectarea conceptuală...................................................... Istoric. .............2 Proiectarea logică... comentarii ..................... 164 4 ........... 111 Unitatea de învăţare U5................ 37 Unitatea de învăţare 2..........3 Proiectarea fizică. ...............................3 Principalele componente şi funcţiuni ale unui SGBD ................1 Algebra relaţională........................ Limbaje de cereri............... 85 Unitatea de învăţare 4........................................... ........................................................... ........................... ......2 Forme normale ......... ....... ................................................................ ............ ........... ....... 93 Modulul 5.......................................................................... ...CUPRINS Modulul 1... ............ 38 Unitatea de învăţare 2................ 126 Unitatea de învăţare U5... 65 Modulul 4....

.... ......... M1. 3 U1................................... Sisteme de Gestiune a Bazelor de Date (SGBD) Cuprins Introducere .. Obiectivele modulului La sfârşitul acestui modul studenţii vor fi capabili să:  Distingă gradul de relaţional al unui SGBD  descrie componenţa unui Sistem de Gestiune al Bazei de Date  cunoască obiectivele unui SGBD  cunoască şi să utilizeze funcţiunile unui SGBD  înţeleagă ce este o bază de date distribbuită  cum se proiectează o bază de date distribuită  5 ......2.... .. ..................Modulul 1...... ..................... Cel mai important domeniu al aplicaţiilor calculatorului este cel al bazelor de date........... transmitere şi prelucrare a datelor... ...........................3......................4 Baze de date distribuite Introducere Evoluţia metodelor şi tehnicilor de organizare a datelor a fost determinată de necesitatea de a avea un acces cât mai rapid şi mai uşor la un volum din ce în ce mai mare de informaţii precum şi de perfecţionarea echipamentelor de culegere.. Istoric.................. Abstractizarea datelor U1............... memorare.......1. comentarii U1......... Principalele componente şi funcţiuni ale unui SGBD U1.... 3 Obiectivele modului ..........

s-au propus trei limbaje:  un limbaj de definire a datelor (LDD) la nivel de schemă  un limbaj la nivel de subschemă 6 .1. Istoric. Sarcina acestui grup era să stabilească specificaţii cu rol de standarde pentru un mediu care ar permite crearea de baze de date şi manipularea datelor. Introducere Este important să ştim cum a evoluat modelul şi softul pentru bazele de date. Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.U1. Proiectul a condus la modelul de date reţea. de cel mai important dintre modele şi anume modelul relaţional. În 1965 CODASYL (the Conference On DAta SYstems Languages) care reunea reprezentanţi ai guvernului USA şi reprezentanţi ai lumii afacerilor şi comerţului. Ideea principală în organizarea datelor se baza pe existenţa a trei nivele de bază:  schema de reţea . care se baza pe date organizate în mod ierarhic. Istoric şi comentarii Se pare că sistemul de baze de date îşi are rădăcinile în anii '60. cunoscut din 1967 sub numele Data Base Task Group (DBTG). Conducător de proiect: Charles Bachmann. M1. unul din modelele abstracte ale bazelor de date. comentarii M1. îşi are originea în acest proiect.Unitatea de învăţare 1. Modelul de date ierarhic. In anii ‘60 General Electric a dezvoltat sistemul IDS (Integrated Data Store).care reprezenta organizarea logica a întregii baze de date  subschema . Ne ocupăm.care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de programele de aplicaţie  un limbaj de gestionare a datelor .U1. Deoarece pe atunci nu există un astfel de sistem.2. în acest curs. a reuşit să stabilească un grup de lucru. în proiectul de aselenizare Apollo.care definea caracteristicile datelor. structura lor şi care manipula datele Pentru standardizare. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  Înţeleagă nivelul la care au ajuns bazele de date  Distingă gradul de relaţional al unui SGBD. North American Aviation (actualmente Rockwell International) a dezvoltat un pachet de programe cunoscut sub numele GUAM (Generalized Update Access Method). Conceptul de bază de date s-a definit în 1969 cu ocazia prezentării primului proiect de raport CODASYL (Raportul final s-a prezentat în 1971).

Definiţia de mai sus este prea generală pentru a putea fi operaţională. Proiectul ierarhic şi cel prezentat de CODASYL reprezintă prima generaţie de Sisteme de Gestiune a Bazelor de Date (SGBD). deoarece modul de implementare a modelului relaţional diferă. Sybase de la Sybase Inc.. FoxPro şi R:base de la Microrim. cât şi în raport cu modelul “ teoretic”. În 1978 E.F. Acest proiect a dus la:  dezvoltarea unui limbaj structurat de interogare (numit SQL) care de atunci a devenit un standard pentru sistemele relaţionale. Informix de la Informix Sofware Inc. Astfel spus. la sfârşitul anilor '70. Alte exemple de sisteme relaţionale: INGRES de la Relaţional Technology Inc. Figura de mai sus prezintă 7 .Codd de la IBM Research Laboratory a elaborat o lucrare care a avut o influenţă covârşitoare în dezvoltarea bazelor de date.. Dintre sistemele relaţionale pentru microcalculatoare enumerăm aici: Paradox şi dBase IV de la Borland. cel definit în cadrul teoriei relaţionale. de regulă atât între diferitele SGBDR. se poate considera un sistem de gestiune a bazelor de date relaţionale (SGBDR) ca reprezentând un SGBD care utilizează drept concepţie de organizare a datelor modelul relaţional. pentru a căror prezentare a fost necesară nuanţarea terminologiei.  producerea în anii '80 de sisteme comerciale arhicunoscute dintre care menţionăm: DB2 şi SQL/DS de la IBM şi ORACLE de la ORACLE Corporation. în mod natural existenţa unei mari diversităţii de SGBDR. conceptele utilizate la prezentarea SGBDR şi a modelelor relaţionale operaţionale diferă de cele din cadrul teoriei relaţionale. Conceptele specifice organizării datelor în fişiere. Lucrarea trata despre modelul de date relaţional.. un SGDBR reprezintă un sistem care suportă modelul relaţional. sisteme pseudorelaţionale. Cât de aproape (sau de departe) de modelul relaţional teoretic trebuie să fie modelul datelor efectiv utilizat de SGBD pentru a putea afirma că SGBD-ul respectiv utilizează sau nu modelul relaţional. SGBDR şi teoriei relaţionale între care se pot stabili analogii Organizarea datelor în fişiere Fişier Record(înregistrare) Câmp SGBDR Tabelă Linie Coloană Teoria relaţională Relaţie Tuplu Atribut În general. De aici încolo s-au proiectat multe sisteme dintre care menţionăm System R dezvoltat la IBM's San Jose Research Laboratory din California. datorită eforturilor producătorilor de a realiza sisteme cât mai performanţe care să satisfacă cerinţele şi exagerările utilizatorilor. Au apărut o serie de sintagme precum: sisteme cu interfaţă relaţională. un limbaj de manipulare a datelor (LMD) Cu toate că nu a fost adoptată formal de ANŞI (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. sisteme complet relaţionale. deci este sau nu SGBDR? Diversitatea modelelor relaţionale operaţionale au determinat. Definirea sistemelor de gestiune ale bazelor de date relaţionale Într-o primă încercare de definire. Toate acestea constituie generaţia a doua de SGBD. Access de la Microsoft.

eu le voi prezenta în continuare. Ac este lucru înseamnă că toate datele trebuie să fie memorate şi prelucrate în acelaşi mod. Referinţa la 'nivelul logic' înseamnă că construcţia fizică nu este reprezentată şi nu necesită explicaţie. care diferă de şirurile de caractere ' spaţiu' sau de şirurile vide da caractere sunt deosebit de importante în implementarea restricţiilor de integritate (integritatea entităţii şi integritatea referenţială). Aceste sisteme se numesc sisteme cu interfaţă relaţională ţi nu SGBDR. Regulile lui Codd Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte un SGBD pentru a putea fi considerat relaţional. Sisteme nu trebuie să facă diferenţieri în definirea şi tratarea datelor şi a metadatelor. Informaţiile privind numele de tabele. Orice dată din baza de date relaţională trebuie să poată fi accesată prin specificarea numelui da tabelă. Trebuie să existe însă cel puţin un limbaj de nivel înalt ale cărui instrucţiuni să poată 8 . R3: Regula privind valorile null Sistemele trebuie să permită declararea să manipularea sistematică a valorilor null. R2: Regula privind garantarea accesului la date. R5: Regula privind facilităţile limbajelor utilizate Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje. domenii. există o unică structură logică folosită pentru a depozita informaţiile de sistem. În acest sens. R0: Regula privind gestionarea datelor la nivel de relaţie Sistemul trebuie să gestioneze baza de date numai prin mecanisme relaţionale. adică să utilizeze limbaje. restricţii de integritate trebuie să fie memorare tot în tabele de date (cataloage). Unele sisteme utilizează mecanisme relaţionale numai pentru o parte din funcţii. şi anume cea relaţională.comparativ conceptele organizării datelor în fişiere. i-au determinat pe unii producători să prezinte sisteme fără nici o legătură cu modelul relaţional drept SGBDR. R4: Regula privind metadatele Descrierea bazei de date trebuie să se prezinte la nivel logic în acelaşi mod cu descrierea datelor propiu-zise. care să opereze la un moment dat pe o întreagă relaţie. mai mult. Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. în mai multe moduri. într-un singur mod. cu semnificaţia unor date lipsă sau inaplicabile. astfel încât utilizatorii autorizaţi să poată descrierii bazei de date aceleaşi operaţii ca şi asupra datelor obişnuite. definiţiile tabelelor virtuale. Deşi reguli au stârnit o serie de controverse. Această regulă exprimă cerinţa ca limbajul de cereri al SGBDR să permită accesul la fiecare valoare atomică din baza de date. Valorile null. ele fiind deosebit de utile în evaluarea unui SGBDR. precum SQL. Această regulă specifică că trebuie să existe un unic limbaj de manipulare a metadatelor şi a datelor propui-zise. valorii cheii primare şi numelui de coloană. utilizând o singură structură. Acest lucru înseamnă că sistemul trebuie să-şi îndeplinească toate funcţiile prin manipulări în care unitatea de informaţie să fie mulţimea (relaţia). în special pentru interogare.coloane. şi anume ca valori în tabele de date. Dec i SGBD nu trebuie să accepte operaţii non-relaţionale care să îndeplinească operaţiile de definire şi manipulare a datelor. R1: Regula privind reprezentarea logică a datelor Toate datele din baza de date relaţională trebuie să fie reprezentate explicit la nivel logic. concepte SGBDR şi ale teoriei relaţionale. în scopul asigurării succesului comercial al acestor sisteme. Faptul că se pot stabili analogii între conceptele organizării datelor în fişiere şi conceptele relaţionale.

deci orice limbaj care acceptă acest standard va satisface automat această regulă. R8: Regula privind independenţa fizică a datelor Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate în modul de reprezentare a datelor sau în metodele de acces. manipularea datelor (interactiv dau prin program).exprima oricare din următoarele operaţii: definirea tabelelor de date. Utilizatorul trebuie să perceapă datele ca fiind centralizate. ci şi în acţiuni de inserare. Pentru a accentua implicaţia regulilor lui Codd în analiza unui SGBDR. atunci când acestea sunt distribuite geografic precum şi sarcina recompunerii datelor trebuie să revină sistemului şi nu utilizatorului. R6: Regula privind actualizarea tabelelor virtuale. R7: Regula privind inserările. autorizarea accesului. deci nu toate tabele virtuale sunt teoretic actualizabile. R12: Regula privind prelucrarea datelor la nivelul de bază Dacă sistemul posedă un limbaj de bază (de nivel scăzut) orientat pe prelucrare de recorduri (tupluri) şi nu pe prelucrarea mulţimilor (relaţiilor). Pe parcursul anilor regulile lui Codd au generat o seamă de controverse. modificările şi ştergerile în baza de date Sistemul trebuie să ofere posibilitatea manipulării unei tabele (da bază sau virtuală) nu numai în cadrul operaţiilor de regăsire. Această regulă exprimă cerinţa ca prin operaţiile în care se schimbă bazei da date să se lucreze la un moment dat pe o întreagă relaţie. R9: Regula privind independenţa logică a datelor Programele de aplicaţie nu trebuie să fie afectate de schimbările efectuate asupra relaţiilor bazei de date. Unele revendicări ale produselor existente sunt că ele pot îndeplini cea mai mare parte din reguli. O schimbare a structurii fizice a datelor nu trebuie să blocheze funcţionarea programelor de aplicaţie. Toate tabelele virtuale care teoretic sunt posibil de actualizat trebuie să poată fi efectiv actualizabile. definirea tabelelor virtuale. R10: Regula privind restricţiile de integritate Restricţiile 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 aplicaţie. A se nota aici că noul standard O/I pentru SQL furnizează toate aceste funcţii. şi anume:  Reguli fundamentale. Sarcina de localizare a datelor. precizarea limitelor tranzacţiilor. Câteva argumente sunt că aceste reguli nu sunt mai mult decât nişte exerciţii academice. acest limbaj nu trebuie s ă fie utilizat pentru a se evita restricţiile de integritate sau restricţiile introduse prin utilizarea limbajelor de nivel înalt. programele de aplicaţie să fie logic aceleaşi cu cele utilizate în cazul în care datele sunt fizic centralizate. în situaţia în care datele sunt distribuite. modificare şi ştergere a datelor. aceste reguli au fost reorganizate în cinci categorii. definirea restricţiilor de integritate. altfel integritate bazelor de date nu poate fi compromisă fără cunoa şterea utilizatorului sau a administratorului bazei de date. Această discuţie a generat o dispută între utilizatori şi teoreticienii asupra proprietăţilor esenţiale ale unui SGBDR. dar nu toate. 9 . adică accesul la toate datele va fi controlat de SGBDR. R11: Regula privind distribuirea geografică a datelor Limbajul de manipulare a datelor utilizat de sistem trebuie să permită ca. Nu toate atributele din cadrul unei tabele virtuale. schimbări care conservă datele şi care teoretic garantează valabilitatea programelor de aplicaţie existente.

în cadrul celor 13 reguli.care definea caracteristicile datelor.care reprezenta organizarea logica a întregii baze de date  subschema . în proiectul de aselenizare Apollo Ideea principală în organizarea datelor se baza pe existenţa a trei componente de bază:  schema de reţea . Abordarea tradiţională bazată pe fişiere are o serie de limitări cum ar fi Separarea şi izolarea datelor Duplicarea datelor Dependenţa datelor Incompatibilitatea fişierelor Interogări fixe / proliferarea aplicaţiilor Sistemul de baze de date îşi are rădăcinile în anii '60. De aceea pentru caracterizarea unui SGBD nu sunt utilizate 10 . Reguli privind integritatea datelor.. Criterii minimale de definire a unui SGBDR Nici unul dintre SGBDR disponibile astăzi nu respectă întru totul cerinţele exprimate de Codd.care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de programele de aplicaţie  un limbaj de gestionare a datelor ..    Reguli structurale. Reguli privind independenţa datelor. SGBDR şi teoriei relaţionale între care se pot stabili analogii Organizarea datelor fişiere Fişier Record(înregistrare) Câmp în SGBDR Tabelă Linie Coloană Teoria relaţională Relaţie Tuplu Atribut Codd a formulat 13 reguli care exprimă cerinţele pe care trebuie să le prezinte un SGBD ca să fie relaţional. Să ne reamintim. 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 organizării datelor în fişiere. Reguli privind manipularea datelor.

şi 3.după modelul de date: ierarhice. Bazele de date sunt extrem de variate în funcţie de criteriile luate în considerare. crearea şi întreţinerea bazei de date şi pe de alta parte. Un SGBD cu interfaţă relaţională este un SGBD are satisface condiţiile 1. Un SGBD este pseudorelaţional dacă satisface numai condiţiile 1. necesitatea indexării atributelor). Unitatea de informaţie cu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia. Sistemul suportă operatori relaţionali de proiecţie.să asigure o independenţă sporită a datelor faţă de programe şi invers. Numim SGBD (Sistem de Gestiune al Bazelor de Date) un sistem software care permite. Este îndeplinită numai în raport cu funcţia de interogare În ultimii ani. specializate. SGBD este format din 11 . colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi (sau organizaţii). .după amploarea geografica: locale. . . .OODM) şi modelul de date relaţional extins (Extended Relaţional Data Model . fiind formulate în schimb o serie de cerinţe minimale pa care trebuie să la satisfacă un sistem de gestiune a bazelor de date pentru a putea fi considerat relaţional. orientate obiect. şi 3. Baza de date trebuie să îndeplinească următoarele condiţii: . Un SGBD este minimal relaţional dacă satisface următoarele condiţii: 1. fără limitări impuse de considerente interne. Cu toate că modelul de date ce sta la baza noilor modele nu este atât de clar că în cazul modelului relaţional.structura bazei de date trebuie astfel concepută încât să asigure informaţiile necesare şi suficiente pentru cerinţele de informare şi decizie.să permită accesul rapid la informaţiile stocate în bază. In esenţă. Sistemul suportă toate operaţiile de bază ale algebrei relaţionale. conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre ele). pe de o parte.. permite accesul controlat la informaţiile din baza de date în cauză. definirea.ERDM). se poate considera că aceste din urma dezvoltări reprezintă generaţia a patra de SGBD. Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele. Un SGBD este complet relaţional dacă este minimal relaţional şi satisface în plus următoarele condiţii: 4. Sistemul suportă două dintre restricţiile de integritate de bază al modelului relaţional şi anume unicitatea cheii unei relaţii şi restricţia referenţială. Nu există pointeri observabili de către utilizatori în tabele.după orientare: generalizate. 2.regulile lui Codd. reţele. etc. . selecţie şi join natural. distribuite. relaţionale. Prezentăm câteva criterii de clasificare: . fără limitări impuse de considerente interne (cum ar fi de exemplu. 5. cu observaţia că cerinţa 3. 3. ca răspuns la necesitatea de a creşte complexitatea aplicaţiilor cu baze de date (încurajată şi de progresele apărute în programare o dată cu programarea orientata obiect) au apărut modelul de date orientat obiect (Object-Oriented Data Model . fişiere inverse.să asigure o redundanţă minimă şi controlată a datelor. în sensul că operaţiile cu relaţii nu fac apel la pointeri. indecşi.

. actualizare şi interogare a bazei de date.definirea structurii bazei de date. Sistemul suportă operatori relaţionali de proiecţie. Din punctul de vedere al sistemelor de calcul pe care se implementează. Din punctul de vedere al concepţiei de organizare a datelor pe care le gestionează. Sistemul de gestiune al bazei de date asigură realizarea următoarelor activităţi: . Nu există pointeri observabili de către utilizatori în tabele. Aşadar. Unitatea de informaţie cu care se lucrează în cadrul acestor operaţii trebuie să fie relaţia. etc. 3. fără limitări impuse de considerente interne (cum ar fi de exemplu. .accesul la date (interogare. SGBD se clasifică în: sisteme de gestiune a bazelor de date cu structuri ierarhice şi reţea.programe de software care interacţionează cu programele de aplicaţie ale utilizatorilor şi cu baza de date. 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 orientate obiect. sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigură interfaţa între o bază de date şi utilizatorii acesteia.  sisteme de gestiune pentru microcalculatoare. . sisteme de gestiune a bazelor de date relaţionale. proprii sistemului de calcul pe care se implementează baza de date. actualizare). Sistemele cu limbaj gazdă prezintă dezavantajul că formularea cerinţelor nu este atât de simplificată ca în cazul sistemelor cu limbaj autonom. . Din punctul de vedere al limbajului pe care îl utilizează. SGBD pot fi:  sisteme de gestiune pentru calculatoarele mari. Avantajul acestor sisteme constă în posibilităţile sporite ce le oferă limbajele de nivel înalt la elaborarea unor proceduri complexe. selecţie şi join natural. utilizând limbajele de nivel înalt sau extensii ale acestora.întreţinerea bazei de date (colectarea şi reutilizarea spatiilor goale. în sensul că operaţiile cu relaţii nu fac apel la pointeri. 4.  sisteme de gestiune pentru minicalculatoare. necesitatea indexării atributelor). sunt: sisteme cu limbaj gazdă. 2. In prezent se manifesta tendinţa ca marea majoritate a sistemelor de gestiune a bazelor de date să fie compatibile pe platforme cât mai largi de sisteme de calcul. Clasificarea SGBD se poate realiza din mai multe puncte de vedere. refacerea bazei de date în cazul unui incident). fişiere inverse. Un SGBD este complet relaţional dacă este minimal relaţional şi satisface în plus următoarele condiţii: 12 . sisteme de gestiune a bazelor de date distribuite. . Sistemele cu limbaj gazdă realizează activităţile de creare..integritatea datelor.. sisteme cu limbaj autonom. Un SGBD este minimal relaţional dacă satisface următoarele condiţii: Toate datele din cadrul relaţiei sunt reprezentate prin valori în tabele. indecşi.încărcarea datelor în baza de date.reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces). Marea majoritate a sistemelor de gestiune apărute în ultima perioadă dispun şi de o componentă de gestiune distribuită a datelor.securitatea datelor. . Să ne reamintim.

colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi. conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre ele). În esenţă. fără limitări impuse de considerente interne. SGBDR şi teoriei relaţionale între care se pot stabili analogii Organizarea datelor fişiere Fişier Record(înregistrare) Câmp în SGBDR Tabelă Linie Coloană Teoria relaţională Relaţie Tuplu Atribut 13 . colecţie desemnată pentru a rezolva nevoia de informatizare a unei întreprinderi. SGBD. Sistemul suportă două dintre restricţiile de integritate de bază al modelului relaţional şi anume unicitatea cheii unei relaţii şi restricţia referenţială. 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 organizării datelor în fişiere. Rezumat Conceptul de bază de date poate fi definit ca fiind o colecţie partajată de date aflate în interdependenţă logică (împreună cu o descriere a acestor date şi a relaţiilor dintre ele).care reprezenta organizarea logica a întregii baze de date  subschema .6.care definea caracteristicile datelor.Sistemul suportă toate operaţiile de bază ale algebrei relaţionale. în proiectul de aselenizare Apollo Ideea principală în organizarea datelor se baza pe existenţa a trei componente de bază:  schema de reţea .U1. Clasificarea SGBD se poate realiza din mai multe puncte de vedere: din punctul de vedere al sistemelor de calcul pe care se implementează. din punctul de vedere al limbajului pe care îl utilizează şi din punctul de vedere al concepţiei de organizare a datelor pe care le gestionează M1. Sistemul de baze de date îşi are rădăcinile în anii '60.care reprezenta o parte a bazei de date aşa cum e văzută de utilizator sau de programele de aplicaţie  un limbaj de gestionare a datelor .

deoarece nu prezintă interes pentru întreprindere.2. dacă este blondă sau brunetă. Trebuie modelate 'obiectele' şi relaţiile dintre ele. deoarece baza de date este o resursă partajată. Se poate face referire spre exemplu la încercarea de modelare a unei aplicaţii într-o întreprindere.U1.U1. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  înţeleagă care este structura pe trei nivele a bazei de date  înţeleagă ce este independenţa logică şi ce este cea fizică şi de ce este importantă această independenţă Durata medie de parcurgere a primei unităţi de învăţare este de 2 or e. 14 .2 Abstractizarea datelor M1. este foarte probabil ca fiecare utilizator s ă dorească doar o parte din informaţiile stocate. Exemple De exemplu. Introducere Un scop important al unui sistem de gestiune al bazelor de date este să poată asigura o viziune abstractă asupra realităţii. Nu realitatea complexă în totalitatea ei intră în discuţie 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 aplicaţia în cauza). nu sunt luate în seamă. nu interesează dacă persoana are ochii albaştri. Acestea ar putea fi. funcţie de aplicaţia pe care o dezvoltă. O mulţime impresionantă de informaţii. dacă ascultă cu plăcere muzică sau dacă este o fire sentimentală.1. M1. care contribuie la descrierea unei persoane anume. Astfel în cazul modelării 'obiectului' (sau entităţii) angajat. salariul. adresa. Ce credeţi că ar interesa să memorăm despre studenţi într-o bază de date a facultăţii? Ce nu ar trebui memorat? Mai mult decât faptul că realitatea este reprezentată codificat şi foarte simplificat.Unitatea de învăţare 1. de exemplu: numele. trebuie alese doar acele proprietăţi (sau atribute) care interesează. Este necesar să se reţină din mulţimea vastă de informaţii doar acelea care sunt necesare unei anumite aplicaţii.

care realizează structura conceptuală (schema) corespunzătoare descrierii întregii baze de date şi administrează componentele bazei de date. .nivelul logic de vizualizare (view) sau nivelul extern. Nivelul conceptual reprezintă: . Componentele bazei de date pot fi structurate pe trei nivele.nivelul fizic. după cum urmează: .descrierea înregistrărilor pentru memorare.alocarea spaţiului de memorie pentru date şi indecşi. Utilizator 1 Nivel extern Utilizator 2 View 1 View 2 …. atributele lor şi relaţiile dintre ele.nivelul conceptual (global).restricţiile impuse datelor . în funcţie de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei. Este dat de viziunea inginerului de sistem care realizează structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic). . View n Nivel conceptual Schema conceptuala Nivel intern Schema interna Organizarea la nivel fizic a datelor Baza de date 15 . care realizează programele de aplicaţii pentru manipularea datelor la nivel de structură logică (subschema) corespunzătoare descrierii datelor aplicaţiei. Nivelul intern se ocupă de: . În general este acceptată arhitectura pe trei nivele ANSISPARC.toate entităţile. . . . Este dat de viziunea administratorului bazei de date..Pentru a se rezolva aceste cerinţe.plasarea înregistrărilor pe suport. se apelează la reprezentarea pe nivele a organizării informaţiilor într-o baza de date. Acest nivel descrie cum sunt memorate datele în baza de date. Acest nivel descrie ce date sunt memorate în baza de date şi ce relaţii sunt stabilite între date. Este dat de viziunea programatorului de aplicaţii.tehnicile de compresie şi de criptare a datelor. .informaţiile privitoare la securitatea şi integritatea datelor.informaţiile semantice despre date .

Este dat de viziunea inginerului de sistem care realizează structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic). Analog. fiecare schemă externă este legată de schema conceptuală prin corespondenţa extern / conceptual. Este de reţinut că trebuie să facem distincţie între descrierea bazei de date (schema bazei de date) şi baza de date propriuzisă. Altfel spus. Scheme. Datorită acestei corespondenţe se identifică înregistrarea sau combinaţia de înregistrări la nivel fizic.Arhitectura ANSI-SPARC pe trei nivele Să ne reamintim.. 16 . SGBD realizează corespondenţa între cele trei nivele de abstractizare.nivelul logic de vizualizare (view) sau nivelul extern. Conform nivelelor de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date. Schemei conceptuale îi corespunde o schemă internă care descrie organizarea fizică a datelor.nivelul conceptual (global). după cum urmează: . Componentele bazei de date pot fi structurate pe trei nivele. mai multe instanţe pot să corespundă aceleiaşi scheme conceptuale pentru o bază de date. Aceasta corespondenţă permite SGBD să facă legătura între numele din view-urile utilizator şi partea corespunzătoare relevantă din schema conceptuală. . împreună cu restricţiile de integritate corespunzătoare. care realizează structura conceptuală (schema) corespunzătoare descrierii întregii baze de date şi administrează componentele bazei de date. Este dat de viziunea programatorului de aplicaţii . în funcţie de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei. La nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos de abstractizare există schema internă.nivelul fizic. realizând corespondenţa între cele trei tipuri de scheme. corespondenţe şi instanţe Descrierea generala a unei baze de date se numeşte schema bazei de date. Este dat de viziunea administratorului bazei de date. Pentru fiecare bază de date o singura schemă conceptuală descrie datele şi relaţiile între ele.. La nivelul cel mai înalt există (în general) mai multe scheme externe (numite şi subscheme) care descriu diferitele view-uri ale bazei de date. care constituie înregistrarea logică în schema conceptuală. precum şi restricţiile de integritate. Numim instanţa (în cazul unei baze de date) datele aflate în baza de date la un anumit moment dat. Astfel corespondenţa conceptual / intern leagă schema conceptuală de schema internă.

Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi independenţa logică a datelor. Să ne reamintim.diferite aplicaţii au nevoie de viziuni diferite asupra aceloraşi date. Independenţa logică a datelor se refera la posibilitatea adăugării de noi înregistrări sau la extinderea structurii conceptuale (globale). Conform nivelelor de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date. Cu alte cuvinte independenţa logică a datelor reprezintă gradul de imunitate a schemelor externe la schimbările suferite de schema conceptuală. La nivelul cel mai înalt există (în general) mai multe scheme externe (numite şi subscheme) care descriu diferitele view-uri ale bazei de date. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să poată fi modificate fără a determina rescrierea programelor de aplicaţie. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele considerente: . Independenţa datelor Un obiectiv major al arhitecturii pe trei nivele de abstractizare este realizarea independenţei datelor.. La nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos de abstractizare există schema internă. Descrierea generala a unei baze de date se numeşte schema bazei de date. precum şi programele de exploatare a ei.administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de acces. De aceea. în general. O aplicaţie. baza de date existentă. fără ca acest lucru să impună rescrierea programelor existente...).. Independenţa logică a datelor se referă la posibilitatea adăugării de noi înregistrări sau la extinderea structurii conceptuale (globale). ca răspuns la cerinţe (schimbări de standarde. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să poată fi modificate fără a determina rescrierea programelor de aplicaţie. unităţile de memorare etc. Aşadar independenţa fizică a datelor reprezintă gradul de imunitate a schemei conceptuale la schimbările suferite de schema internă. iar datele existente să poată fi convertite. fără ca acest lucru să impună rescrierea programelor existente. . 17 . care au fost folosite o perioadă de timp şi care reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor. este dependentă de date în sensul că modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi aplicaţia. sistemele informatice să poată funcţiona cu programele şi procedurile existente. priorităţile aplicaţiilor. se impune ca atunci când apar noi cerinţe în cadrul sistemului informaţional. fără a modifica aplicaţiile existente.Să ne reamintim.

în funcţie de clasa utilizatorilor implicaţi şi de viziunea asupra structurării informaţiei.3 Ce este arhitectura pe trei nivele? Răspunsurile se găsesc la sfârşit la pag 147 18 . fără ca acest lucru să impună rescrierea programelor existente.2.nivelul conceptual (global . după cum urmează: . La nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos de abstractizare există schema internă. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să poată fi modificate fără a determina rescrierea programelor de aplicaţie.2.U1. Conform nivelelor de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date.2. Test de autoevaluare a cunoştinţelor 1.nivelul fizic Descrierea generală a unei baze de date se numeşte schema bazei de date. .6.M1. Independenţa logică a datelor se referă la posibilitatea adăugării de noi înregistrări sau la extinderea structurii conceptuale (globale). M1.2 Ce nu ar trebui memorat despre profesori într-o bază de date a facultăţii? 1.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii? 1. Rezumat Componentele bazei de date pot fi structurate pe trei nivele.nivelul logic de vizualizare (view) sau nivelul extern.U1. Există (în general) mai multe scheme externe (numite şi subscheme) care descriu diferitele view-uri ale bazei de date.2.

. specializate etc. Introducere 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: M1. gestionari. Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune. destinate bunei funcţionări a întregului sistem.U1.(neinformaticieni). . ajungem la concluzia că nu poate fi stabilită o arhitectură unică. care se diferenţiază: . structura acestora. altele numai în regim local. . statistici. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:    descrie componenţa unui Sistem de Gestiune al Bazei de Date cunoască obiectivele unui SGBD cunoască şi să utilizeze funcţiunile unui SGBD Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.şi prin faptul că unele oferă posibilitatea lucrului în regim de teleprelucrare. . de specialitate (administrator). . Arhitectura unui SGBD evidenţiază componentele acestuia şi urmează standarde internaţionale. .prin limbajele utilizate.3 Principalele componente şi funcţiuni al e unui SGBD M1. iar altele atât în regim local cât şi în regim de teleprelucrare.3. analişti . precum şi reglementările administrative.).prin anumite componente ce imprimă diferite facilităţi de exploatare a bazei de date.U1. ci apar particularităţi de la un sistem la altul.un dicţionar al bazei de date (metabaza de date).programatori.mijloacele hard utilizate (comune. documentaţie etc.Unitatea de învăţare 1. operatori).baza de date propriu-zisă în care se memorează colecţia de date.personalul implicat: (categorii de utilizatori: finali . . Să detaliem câteva din componentele prezentate mai sus. elemente de descriere a semanticii. Arhitectura bazei de date dă o imagine despre modul general de organizare şi funcţionare a ei. care este un ansamblu de programe (soft) care realizează gestiunea şi prelucrarea complexă a datelor. O astfel de arhitectură generală cuprinde următoarele componente: . 19 . ce conţine informaţii despre date.3.sistemul de gestiune al bazei de date.un set de proceduri manuale şi automate. valabilă pentru toate sistemele.

asemănătoare cu structurile puse la dispoziţie de limbajele de nivel înalt. SGBD translatează cererea din limbaj non-procedural transformând-o într-o procedura sau într-o serie de proceduri care manipulează datele conform cererii utilizatorului. Aceste limbaje mai sunt cunoscute ca sublimbaje de date deoarece ele nu includ construcţii adecvate oricăror necesităţi de calcul.DDL) şi Limbajul de manipulare a datelor (Data Manipulation Language . Nu există încă un consens asupra semnificaţiei acestei denumiri. în realitate există un singur limbaj care tratează toate aspectele definirii datelor. Operaţii de baza sunt inserarea. Fişierul preprocesat este compilat. C. la datele din înregistrări şi la alte obiecte ce compun baza de date. Un LMD procedural tratează înregistrările individual şi specifica cum trebuie obţinut rezultatul unei interogări. link-editat cu o bibliotecă în care se află funcţiile înlocuite. SGBD consulta dicţionarul de date înaintea oricărui acces la informaţii. Ceea ce se programează în sute de linii de program într-un limbaj de generaţia a treia. Cu alte cuvinte trebuie să se specifice un algoritm de prelucrare a înregistrărilor cu ajutorul operaţiilor puse la dispoziţie de limbaj.DML). Rezultatul compilării declaraţiilor în acest limbaj este constituit dintr-o serie de tabele memorate într-un Fişier special numit dicţionar de date (se mai utilizează şi termenii de catalog de date sau director de date). Limbajele 4GL sunt non-procedurale şi se 20 . Pascal. un LMD non-procedural specifica doar ce fel de rezultat trebuie obţinut. Manipularea datelor se aplica la nivel conceptual şi extern. Se cunosc doua tipuri de LMD: procedural şi non-procedural. modificarea şi regăsirea datelor în baza de date. Schema bazei de date este definita cu ajutorul LDD. Limbajele non-procedurale sunt mai uşor de utilizat deoarece scutesc utilizatorii de la a cunoaşte implementarea interna a structurilor de date şi de la a stabili algoritmi de obţinere a informaţiilor. Înţelegem prin interogare orice cerere de acces la datele din baza de date. Fortran. comenzile sublimbajului sunt înlocuite în limbajul gazdă cu apeluri de funcţii.Limbajele utilizate într-un SGBD sunt de două tipuri: Limbajul de definire a datelor (Data Definition Language . Datele memorate în acest dicţionar sunt date despre date şi de aceea se mai numesc şi metadate. plasat într-un modul obiect. Multe SGBD au facilitatea de a incorpora sublimbajul într-un limbaj de nivel înalt (numit limbaj gazdă) cum ar fi COBOL. 4GL 4GL înseamnă Fourth-Generation Language (Limbaj de Generaţia a Patra). Limbajul de manipulare a datelor (LMD) furnizează un set operaţii care suporta operaţiile de manipulare de baza asupra datelor din baza de date. furnizate o dată cu SGBD. poate să constituie câteva zeci de linii de program într-un limbaj de generaţia a patra. se poate identifica cate un LDD pentru fiecare nivel de abstractizare al datelor. În contrast. Limbajul de Definire a Datelor (LDD) este un limbaj descriptiv care permite administratorului bazei de date sau utilizatorilor să descrie şi să denumească entităţile şi relaţiile care se pot stabili între acestea. ştergerea. Pentru compilare. Partea componenta a unui LMD care se refera la regăsirea datelor se numeşte limbaj de interogare. în general 4GL desemnează un limbaj de programare de mare rapiditate pentru programator. şi este executat când este necesar. Teoretic. formulata într-un limbaj de interogare. Ada. Definiţiile din dicţionarul de date se refera la înregistrări.

Se cunosc doua tipuri de generatoare de rapoarte: orientat pe limbaj şi orientat visual. Utilizatorul trebuie să definească parametri pentru aceste tools-uri iar acestea generează programe de aplicaţie pe baza parametrilor respectivi.generatoare de rapoarte. în al doilea caz. Un 4GL cuprinde: . Generatoare de rapoarte Un generator de rapoarte ajuta la crearea de rapoarte (liste) pornind de la datele memorate în baza de date. . limbaje comerciale asupra cărora vom reveni ulterior. . 21 . . Generatoare de ecrane Un generator de ecrane este un tool cu ajutorul căruia se pot crea uşor şi rapid ecrane pentru culegerea (introducerea) informaţiilor necesare programelor sau chiar pentru introducerea şi modificarea datelor din baza de date.generatoare de ecrane. Generatoare de aplicaţii Utilizarea unui generator de aplicaţii poate reduce timpul necesar realizării unei aplicaţii unitare. etc.limbaje de interogare.generatoare de aplicaţii. Generatoare de grafice Un astfel de generator este o facilitate care regăseşte date din baza de date şi afişează aceste date sub forma unor grafice.bazează pe tools-uri performante. Un avantaj important al utilizării limbajelor 4GL este o productivitate deosebita în programare. în primul caz se utilizează comenzile unui sublimbaj pentru a defini datele ce se vor include în raport. Generatoarele de aplicaţii constau în module predefinite care cuprind majoritatea funcţiilor de baza ce sunt prezente în majoritatea programelor. . Aceste module constituie o biblioteca de funcţii la dispoziţia utilizatorilor. Exemple de limbaje de interogare 4GL sunt SQL şi QBE.limbaje specializate cum ar fi spreadsheet-urile şi limbajele specifice bazelor de date. acelaşi lucru se realizează cu ajutorul unei facilităţi grafice similare cu generatorul de ecrane.

In acest context. obiectivul informaticii îl constituie culegerea. . Arhitectura unui SGBD cuprinde următoarele componente: . sistemului de gestiune al bazei de date îi revin o serie de obiective. elemente de descriere a semanticii. . ce conţine informaţii despre date. . .Să ne reamintim. destinate bunei funcţionări a întregului sistem.. documentaţie etc. Obiectivele unui SGBD După cum este cunoscut. care este un ansamblu de programe (soft) care realizează gestiunea şi prelucrarea complexă a datelor. 22 .sistemul de gestiune al bazei de date.. cum sunt: 1. . acest obiectiv consta în linii mari din îndeplinirea următoarei cerinţe: modificările care se fac la un anumit nivel de structura de date nu trebuie să fie 'vizibile' la nivelul de organizare imediat superior.minimizarea costului procesului de prelucrare a datelor.un dicţionar al bazei de date (metabaza de date). necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de cerinţe prin care să se asigure: .personalul implicat: (categorii de utilizatori: finali (neinformaticieni). . precum şi reglementările administrative. statistici. verificarea. . creşterea vitezei de răspuns la întrebările solicitate de utilizatori. de specialitate (administrator).posibilitatea folosirii sistemului de informare dispunând de un minim de cunoştinţe despre modul lui de organizare în general şi despre informatica în special. stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor electronice de calcul. gestionari.). specializate etc.baza de date propriu-zisă în care se memorează colecţia de date.adaptarea facilă a sistemului informatic la evoluţia în timp a sistemului informaţional din care face parte.posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanţii de sistem. Aşa cum am arătat mai devreme. Asigurarea independenţei datelor. In aceste condiţii.mijloacele hard utilizate (comune. operatori). analişti programatori. .integritatea şi securitatea datelor etc. în condiţii de eficienta economica sporita. transmiterea. .un set de proceduri manuale şi automate. în scopul satisfacerii diferitelor nivele de conducere cu informaţii necesare luării deciziilor. structura acestora.

Aceasta presupune: Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate. Aceasta presupune: . reorganizarea lor. timpul de răspuns la solicitările utilizatorilor) să se accepte o anumita redundanta a datelor. defini verificări de autorizare care să se realizeze oricând se încearcă accesul la anumite date. . totodată. Asigurarea unei redundante minime şi controlate a datelor din baza de date. nu sunt excluse nici cazurile în care. a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente. fără sortări suplimentare. Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate. Modificarea criteriului la fişierele clasice implică. acest lucru rămânând în sarcina administratorului bazei de date.2. în majoritatea cazurilor. cu posibilitatea exploatării bazei de date în regim conversaţional. fiecare informaţie să apară o singură dată.spre deosebire de sistemul tradiţional bazat pe Fişiere. pentru a realiza performante sporite (mai ales în ce priveşte timpul de acces la date şi implicit. fără ca aceştia să fie nevoiţi să cunoască structura întregii baze de date. 23 . pe cât posibil.accesul cât mai simplu al utilizatorilor la date. Asigurarea partajabilităţii datelor.existenta unor limbaje performante de regăsire a datelor. stocarea datelor în cazul bazelor de date se face astfel încât. 3. unde există un singur criteriu de adresare (cel care a stat la baza organizării Fişierului) în cazul bazelor de date. ci şi sub acela al posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.. Administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai prin canale corespunzătoare. care permit exprimarea cu uşurinţă a criteriilor de selecţie a datelor şi indicarea unor reguli cât mai generale pentru editarea informaţiilor solicitate. Să ne reamintim. şi poate. Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. în acest caz se va institui insa un control automat al redundantei în vederea asigurării coerenţei datelor din baza. 4. 5. Partajabilitatea datelor trebuie înţeleasă nu numai sub aspectul asigurării accesului mai multor utilizatori la aceleaşi date. Asigurarea unor facilităţi sporite de utilizare a datelor. 6. Asigurarea partajabilităţii datelor. Asigurarea unor facilităţi sporite de utilizare a datelor.utilizarea unui limbaj cât mai apropiat de limbajul natural. . Spre deosebire de sistemele clasice de prelucrare automata a datelor.folosirea datelor de câtre mai mulţi utilizatori în diferite scopuri (aplicaţii). prin intermediul unor proceduri de validare. .. Obiectivele unui SGBD sunt: Asigurarea independentei datelor. Asigurarea unei redundanţe minime şi controlate a datelor din baza de date. . Totuşi. Aceasta ar oferi posibilitatea exploatării în mod facil a bazei de date şi de câtre utilizatorii neinformaticieni. sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial.

24 . Totuşi. În funcţie de natura lor şi de scopul urmărit. Ţinând seama de complexitatea sistemului de gestiune. sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc. Definirea datelor poate fi realizată la nivel logic. 2. relativ omogene. . . identificarea şi delimitarea funcţiilor nu este atât de evidentă. gruparea activităţilor pe funcţii are un oarecare caracter relativ. 3. Funcţia de manipulare a datelor este cea mai complexa funcţie şi realizează următoarele activităţi: .utilizatori programatori. . .ştergerea unor înregistrări.definirea metodelor de acces la date. . conceptual şi fizic.modificarea valorilor unor câmpuri. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire.definirea eventualelor criterii de validare a datelor. Toate acestea se concretizează în schema bazei de date. etc.adăugarea de noi înregistrări. Ei apar ca utilizatori neinformaticieni. Aceasta funcţie asigură: .administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu.definirea aspectelor referitoare la asigurarea integrităţii şi confidenţialităţii datelor. memorată în cod intern. Aceştia reprezintă categoria beneficiarilor de informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date într-o formă simplistă.Funcţiile unui SGBD Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea numeroaselor operaţii necesare funcţionării optime a sistemului. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. Funcţia de manipulare a datelor se realizează prin intermediul limbajului de manipulare a datelor. Sunt recunoscute mai multe categorii de utilizatori: .descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiaşi entităţi. operaţiile pot fi grupate pe activităţi. de limbajele utilizate şi de tipul bazei de date ce urmează a fi gestionată de SGBD. .descrierea atributelor (câmpurilor) din cadrul structurii bazei de date. de facilităţile oferite de acesta. . realizează o anumita funcţie).crearea (încărcarea) bazei de date. . În situaţia sistemelor de gestiune ce utilizează limbaje gazdă de nivel înalt. realizând proceduri complexe de exploatare a bazei de date. în ciuda acestor particularităţi. . se pot prezenta câteva funcţii cu caracter de generalitate pentru toate sistemele de gestiune a bazelor de date şi anume: 1.utilizatori "liberi" sau conversaţionali.căutarea. Activităţile acceptă şi ele o grupare pe funcţii (una sau mai multe activităţi. care utilizează limbajele de manipulare. .

un set de proceduri manuale şi automate..un dicţionar al bazei de date (metabaza de date).U1.6. elemente de descriere a semanticii. gestionari. M1. . operatori). analişti programatori. statistici. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date. . Să ne reamintim. Asigurarea unei redundante minime şi controlate a datelor din 25 .4. precum şi reglementările administrative.personalul implicat: (categorii de utilizatori: finali (neinformaticieni). de specialitate (administrator).). verificarea..baza de date propriu-zisă în care se memorează colecţia de date. Acest obiectiv consta în îndeplinirea cerinţei ca modificările care se fac la un anumit nivel de structura de date să nu fie 'vizibile' la nivelul de organizare imediat superior. în scopul satisfacerii diferitelor nivele de conducere cu informaţii necesare luării deciziilor.sistemul de gestiune al bazei de date. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. care este un ansamblu de programe (soft) care realizează gestiunea şi prelucrarea complexă a datelor. stocarea şi prelucrarea automata a datelor cu ajutorul mijloacelor electronice de calcul. . . structura acestora. . Obiectivele sunt: Asigurarea independentei datelor. destinate bunei funcţionări a întregului sistem. Rezumat Arhitectura unui SGBD cuprinde următoarele componente: . transmiterea. Funcţia de manipulare a datelor.mijloacele hard utilizate (comune. documentaţie etc. specializate etc. Obiectivul informaticii îl constituie culegerea. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date. Funcţiunile unui SGBD sunt: Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. ce conţine informaţii despre date. în condiţii de eficienta economica sporita.

Partajabilitatea datelor trebuie înţeleasă şi sub aspectul posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.adăugarea de noi înregistrări. . fiecare informaţie să apară o singură dată.utilizatori programatori. M1.3.2 Care sunt funcţiunile unui SGBD? Răspunsurile se găsesc la sfârşit la pag 149 26 .3. Asigurarea unor facilităţi sporite de utilizare a datelor. Pe cât posibil. sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc.ştergerea unor înregistrări. . . a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente. Funcţia de manipulare a datelor se realizează prin intermediul limbajului de manipulare a datelor. Funcţiunile unui SDGBD sunt Funcţia de descriere a datelor care permite definirea structurii bazei de date cu ajutorul limbajului de definire.baza de date. Sunt recunoscute mai multe categorii de utilizatori: . Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează următoarele activităţi: . Nu sunt excluse nici cazurile în care să se accepte o anumită redundanţă a datelor.utilizatori "liberi" sau conversaţionali.administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu. . Asigurarea partajabilităţii datelor.crearea (încărcarea) bazei de date. . realizând proceduri complexe de exploatare a bazei de date.1 Care sunt obiectivele unui SGBD? 1. Ei apar ca utilizatori neinformaticieni. care utilizează limbajele de manipulare.căutarea.modificarea valorilor unor câmpuri.U1. Test de autoevaluare a cunoştinţelor 1.3. Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date. . Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate. prin intermediul unor proceduri de validare.

independenţa de hardware. 27 . versiune distribuită a lui INGRES. distribuite fizic pe o reţea de calculatoare. posibiliăţti de replicare (copiere) şi independenţa copiilor. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  înţeleagă ce este o bază de date distribbuită  cum se proiectează o bază de date distribuită Durata medie de parcurgere a primei unităţi de învăţare este de 2 o re. administrarea distribuită a tranzacţiilor. posibilitatea de lucru continuu al site-urilor independent de schimbările in configuraţiile de lucru (adăugari sau eliminari de site-uri). Sistemul fizic (reţeaua) care constituie suportul unei baze de date distribuite poate fi format din calculatoare personale. Printre cerinţele pe care trebuie să le asigure un sistem de baze de date distribuite menţionăm: autonomia locala în organizarea şi prelucrarea datelor. de reţea şi de sistemul de gestiune a bazelor de date. staţii de lucru. Putem reformula definiţia de la început spunând ca un sistem de baze de date distribuite constă dintr-o colecţie de site-uri.4 Baze de date distribuite M1. Generalităţi Primele sisteme de baze de date distribuite au fost INGRES/STAR. minicomputere. Un sistem de gestiune al unei baze de date distribuite (SGBDD) este un sistem software care permite gestionarea BDD şi face distribuirea transparentă pentru utilizator. toate legate în reţea şi numite generic site-uri. prelucrarea distribuită a cererilor. pentru a sprijini gestionarea datelor în situaţia când acestea se regăsesc fizic în diferite puncte ale reţelei.4. independenţa localizării şi fragmentării datelor (transparenţa fizică). SQL*STAR versiune distribuită a lui ORACLE şi R* versiune distribuita a lui DB2. de sistemul de operare. etc.4 Introducere O baza de date distribuită (BDD) este o colecţie logic corelată de date partajate. neutilizarea unei centralizări a evidenţei şi a datelor.Unitatea de învăţare 1.U1. Ele au apărut ca o necesitate. fiecare putând participa la executarea tranzacţiilor care accesează datele de pe un site sau de pe mai multe site-uri.U1. M1. în special in cazul reţelelor de calculatoare. Sistemele de date distribuite sunt menite să rezolve problema "insulelor de informaţii".

- - - Printre dezavantajele distribuirii amintim complexitatea crescuta a unui astfel de sistem.Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente. Deja la nivelul proiectarii şi implementarii sistemului este necesar mai mult timp şi personal specializat. 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. Costuri scazute se mai obtin daca se realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest lucru). De asemenea. Pentru a spune că un SGBD este distribuit trebuie să existe cle puţin o cerere globală. Avantajele distribuirii bazelor de date: sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor organizaţii. 28 - . şi fiecare fragment sau copie se pastrează pe unul sau mai multe site-uri. La aceste costuri se pot adauga acelea care vin din necesitatea asigurarii echipamentelor hardware performante şi a soft-ului necesar. 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ă decât în cazul centralizat. De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la nevoile organiza’iei (dac[ de exemplu este necesară adăugarea unor site-uri în plus) decât un calculator central de putere asemănătoare capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta deloc) mersul activităţilor pe ansamblul sistemului distribuit. Dacă se semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să continue să funcţioneze în condiţii satisfăcătoare fiabilitatea sistemului este îmbunătăţită. Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi tranzacţii globale după site-urile pe care le solicită excutarea lor. potential marit de erori. sau este capabil să participe la procesarea unor date situate în alte site-uri din reţea. in cazul exploatarii sistemului la costurile obisnuite se vor adauga costuri destul de ridicate de comunicatii. 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. sub controlul unui SGBD local. Se pot reface rapid fişiere distruse utilizând replici aflate pe alte site-uri performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în paralel a unor interog[ri un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem centralizat de putere comparabilă de prelucrare. eventual unele fragmente sunt multiplicate. Ambele lucruri necesita costuri mai mari in bani. 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. independent de restul reţelei. Fiecare site este capabil sa proceseze interogări utilizator în regim local.

Nu se poate vorbi de o lipsa totala de standarde dar. La acest nivel se definesc entitatile. Aceasta descriere este independenta de SGBD-ul ales şi datorita acestui fapt se poate vorbi de SGBD heterogene. - - - 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.1. Fig 7. lipsa standardelor. fara a se evidentia aspectul distribuit. Dam mai jos cateva explicatii referitoare la unele elemente prezente in schema: schema conceptuala globala este o descriere logica a intregii baze de date. informatiile generale de securitate a datelor. Datorita costurilor mari de comunicatii (in timp şi bani) uneori se renunta la verificarea unor reguli in detrimentul consistentei bazei de date. 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. conditii) pe care trebuie sa le verifice datele din baza de date. lucrul cu sisteme de date distribuite inca nu are la baza standarde internationale unanim acceptate. Controlul la nivel fizic administrativ are mai putina pondere decat in cazul unui sistem centralizat. etc. Integritatea se exprima de obicei in termeni de restrictii (reguli. relatiile. Nu exista foarte multa experienta privind lucrul distribuit şi proiectarea. eliminarea unor inconsistente datorate redundantelor. Datele sunt mai usor disponibile unor persoane neautorizate deoarece se poate incerca acces la ele prin intermediul accesului intre calculatoare. restrictiile de integritate. - 29 . detectarea şi corectarea unor perturbari. 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.- este necesara o procesare suplimentara care se datoreaza schimburilor de mesaje intre siteuri şi a coordonarii acestora in general securitatea unui sistem distribuit este mai greu de asigurat decat in cazul unui sistem centralizat. gestionarea şi exploatarea unui sistem distribuit sunt mai dificile decat in cazul centralizat. 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. intergitatea datelor este de asemenea mai greu de realizat intr-un sistem distribuit.

Ca o paranteza mentionam aici clasificarea SGBD-urilor distribuite in heterogene şi omogene. pe cat posibil a accesului in regim de referinte locale. 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 creşte costurile foarte mult (si riscul obtinerii inconsistentei) deoarece trebuie sa fie realizate asupra datelor de la toate site-urile. Acest dicţionar are aceeaşi funcţionalitate ca şi und dicţionar de date în cazul SGBD centralizat dar conţine informaţii suplimentare referitoare la fragmentare şi la alocarea datelor. Aici sunt de luat in considerare mai ales costurile interogarilor intre site-uri. Acolo unde este necesar şi unde permite aplicaţia se recomanda utilizarea de copii ale fragmentelor 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. evident. SGBD local identic. lucrul in acest caz este destul de greoi şi este supus multor limitari. SGBD omogene reprezinta situatia cand pe toate site-urile din retea este hardware similar. sistem de operare identic si. În cazul SGBD heterogene exista mai multe situatii dupa cum difera dotarea hardware. optimizarea costurilor de comunicare. şi realizarea următoarelor: fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate pe diferite site-uri în reţea replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor alocarea fragmentelor şi a replicilor pe diferite site-uri realizarea. pe lângă cerinţele cunoscute pentru sistemele centralizate. deoarece au efecte contrare. Şi DDG poate fi fragmentat şi replicat ca orice altă informaţie din baza de date distribuită componente de SGBD distribuit (SGBDD) - Proiectarea unei baze de date relaţionale distribuite Proiectarea corectă a unei baze de date relaţionale distribuite necesită. cel mai important. Diferentele pot fi impinse pana la a avea structuri ale bazei de date diferite (date de modele de date diferite) dar. Trebuie sa se aiba in vedere ca. Definirea fragmentelor şi alocarea acestora pe site-uri au ca obiective: - Alocarea datelor 30 . Capacitatea şi costuril de stocare trebuie puse in balanta cu tendinta de a avea referinte locale. sistemele de operare si/sau SGBD-urile utilizate local pe site-uri. În cadrul unui SGBDD putem identifica urmatoarele componente: o componentă locală SGBD (LSGBD) o componentă de comunicaţii de date (CD) un dicţionar de date global (DDG).

practic paralizează întreaga activitate în reţea pe această direcţie. replicare şi centralizare cu scopul de a se cumula. costurile de stocare sunt reduse fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat dacă datele sunt distribuite corect. la fel sunt şi costurile de actualizare 4. Printre criteriile care duc la decizia corecta de alocare a bazei de date: frecventa cu care se ruleaza o aplicaţie site-urile de la care se ruleaza cel mai frecvent aplicaţia modul de lucru al tranzactiilor executate de aplicaţie şi tipurile de acces la date etc. Dezavantajele sunt mai ales costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute. costurile de comunicare pot fi relativ scăzute 3. pe cat posibil.Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită: 1. centralizat Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur DBMS. având în vedere că orice eroare care blochează accesul la baza de date. replicat selectiv Aceasta strategie este o combinaţie intre partiţionare. fragmentat (partiţionat) Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe diverse site-uri. In faza de analiza. avantajele fiecărei strategii şi să se elimine dezavantajele. replicat complet Pe fiecare site se găseste o copie completă a bazei de date. Comentarii: eficienţa referirilor locale. Fragmentarea La baza fragmentarii bazei de date exista. precum şi alocarea acestora trebuie sa se bazeze pe modul de utilizare a datelor din baza de date. la proiectarea bazei de date trebuie sa se tina cont de cele mai frecvent utilizate aplicaţii deoarece nu se poate realiza o alocare care sa optimizeze toate aplicaţiile simultan. urmatoaele motivari: mod de utilizare – in general intr-o aplicaţie 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 timp 31 . 2. printre altele. ea de fapt nu mai este o bază de date distribuită in adevaratul sens al cuvântului. Comentarii: aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale dacă nu există replici ale fragmentelor. Spunem în acest caz că baza de date este procesată distribuit. fiabilitatea şi disponibilitatea sunt maxime costurile de stocare sunt în schimb şi ele foarte mari. Definirea replicilor şi a fragmentelor.

R n. completitudine – dacă relaţia R este descompusă în fragmentele R 1. disjuncţie – dacă data di apare în fragmentul R i atunci nu este permis să apară în nici un alt fragment. cazul când o relaţie este fragmentată pe verticală. Aceasta regulă conservă dependenţele funcţionale. Fragmentarea pe verticală Un fragment vertical dintr-o relaţie consta dintr-o relaţie care are ca atribute o submulţime a atributelor relaţiei iniţiale. Un fragment vertical se produce prin proiecţie: Dacă S1R şi S2R atunci r1   S1 ( R) şi r2   S 2 ( R) .- securitate – datele care nu sunt necesare sunt stocate in alta parte. R= R1R2…Rn In general fragmentele unei relaţii R sunt disjuncte. 3. R2. deci nu sunt la dispozitia accesului neautoarizat 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 Dezavantajele lucrului cu fragmente ale bazei de date: - Reguli de bază care duc la o fragmentare corectă a bazei de date: 1. se utilizează reuniunea pentru a obţine relaţia R iniţiala. o singură dată. reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit cu fragmentarea. trebuie luate măsuri care să prevină pierderea de informaţii 2. 32 . Un fragment orizontal se produce prin selecţie: Fiecare tuplu din relatia R apare într-un anume fragment. 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 relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor relaţiei respective. De la această regulă se admite doar o excepţie. Dacă se doreşte reconstrucţia relaţiei. ….

.. încă din faza de analiză. este cerinta ca aspectul distribuit trebuie sa fie transparent pentru utilizator. Tipuri de transparenţă: 1.... r ( R )  r1 X N r2 Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care asigură o descompunere fără pierderi la joncţiune. fragmente orizontale fragmentate vertical Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:  A1 . şi anume a atributelor care formează cheile primare (respectiv cheile externe). transparenţa tranzacţiilor 3. Fragmentele verticale se stabilesc prin determinarea afinităţilor între atribute. În realitate transparenţa poate fi realizată doar într-o anumită măsură. Se admite existenţa unor atribute comune. An ( R)) 2..Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într. transparenţa performanţelor Transparenţa distribuirii 33 .. hibridă. deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de baze de date. transparenţa distribuirii 2. Fragmentarea combinată (mixtă. fragmente verticale fragmentate orizontal Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:  P ( A1 . Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date distribuita. An ( P ( R)) Transparenţa în SGBDD Prima regula. Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală.una din submulţimile S1 şi S2. considerată regula de baza in sistemele distribuite. compusă) 1.. In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală.

In aceasta situatie mai exista un mod prin care se poate "indulci" situatia: se utilizeaza alias-uri. Transparenţa fragmentării este strâns legată de acordarea numelor (identificatorilor) în cadrul bazei de date distribuite. Transparenţa fragmentării este cel mai înalt grad de transparenţa. Exemple Prin notatia s1. Două site-uri nu pot conţine obiecte cu nume identice.c2 poate avea ca alias numele client_local pentru utilizatorii site-ului s1. Transparenta localizarii reprezinta un nivel mediu de transparenta.…An from f2 ……… Avantajul major in cazul de mai sus consta in faptul ca se poate oricand reorganiza baza de date (ca locatii) fara ca aplicaţiile ce o utilizeaza sa trebuiasca modificate. In aceasta situatie utilizatorul stie cum este fragmentata baza de date dar nu stie unde sunt plasate diferitele fragmente sau copii ale acestora. Acest tip de transparenţă se poate descompune în două aspecte: utilizatorul nu trebuie să cunoască faptul că există fragmentarea datelor (transparenţa fragmentării) sau utilizatorul nu ştie de localizarea datelor pe reţea (transparenţa localizării).c2 se poate desemna copia a doua a fragmentului 3 a tabelei client care se afla pe site-ul s1. O interogare poate avea un format asemanator cu cel de mai jos: select A1.Dacă se realizează transparenţa distribuirii. se poate ajunge la o suprasolicitarea serverului de nume (se creeaza un asa-numit loc ingust . de copie. Sunt cateva solutii posibile: 1. În interogari vor aparea numele fragmentelor dar nu se vor face referiri la localizare.f3. utilizatorul percepe baza de date ca pe o entitate unitară din punct de veder logic. de fragment."bottleneck") şi disponibilitatea bazei de date este redusa (daca serverul de nume iese din uz temporar. Utilizatorul se adresează cu interogări bazei de date ca şi când ar fi localizată centralizat. Aceasta abordare are dezavantajele ca se pierde autonomia locala a site-urilor. 34 .client. Consecinta cea mai grava a acestui mod de a numi obiectele este pierderea completa a transparentei. deci nu trebuie să se preocupe de existenţa fragmentelor. Şi într-o bază de date distribuită (ca şi în cazul centralizat) numele diferitelor "obiecte" trebuie să fie unic.…An from f1 where conditie1 union select A1.f3. Alternativa la solutia de mai sus este sa se recurga la prefixarea obiectelor cu un identificator de site. se blocheaza accesul la date) 2.client. Se poate crea un server central de nume care are menirea sa sigure ca numele date in aplicaţii distribuite sunt nume unice pe toata baza de date. De exemplu s1.

Rezumat O baza de date distribuită (BDD) este o colecţie logic corelată de date partajate.Transparenta maparii locale reprezinta cel mai jos nivel al transparentei distribuite. M1. Sub-tranzacţiile se execută în paralel pe site-uri şi în mod concurent pe fiecare site. într-o ordine serială arbitrară. Odată ce o tranzacţie s-a executat. care locaţie se utilizează. şi realizarea următoarelor: fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate pe diferite site-uri în reţea replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor alocarea fragmentelor şi a replicilor pe diferite site-uri 35 . În acest scop un DQP (Distributed Query Processor) mapeaza o cerere de date într-o secvenţă ordonată de operatii asupra bazei de date. Transparenţa erorilor necesită şi un mecanism de recovery care ne să asigure că tranzacţiile se comportă atomic în faţa erorilor: ori sunt executate toate operaţiile unei tranzacţii ori nici o operaţie nu este executată. DQP decide ce fragment se accesează. timp CPU la executatrea operatiilor asupra datelor in memoria principala. În cadrul transparenţei tranzacţiilor se tratează în mod deosebit transparenţa concurenţei şi transparenţa erorilor.6. distribuite fizic pe o reţea de calculatoare. SGBDD are sarcini deosebite în legătură cu gestionarea tranzacţiilor distribuite dar acestea nu vor fi tratate in acest capitol. Transparenţa tranzacţiilor Acest tip de transparenţa asigură faptul că toate tranzacţiile distribuite păstrează integritatea şi consistenţa BDD. ce copie se utilizează. Proiectarea corectă a unei baze de date relaţionale distribuite necesită. Tranzacţiile într-o baza de date distribuită sunt clasificate în tranzacţii locale şi tranzacţii globale după site-urile pe care le solicită excutarea lor. câte una pentru fiecare site accesat. transformările operate de ea asupra bazei de date sunt durabile (permanente). Transparenţa performanţelor Transparenţa performanţelor se asigură prin cerinţa ca sistemul considerat să aibă performanţe comparabile cu ale unui sistem centralizat.U1. Costul asociat cu o interogare distribuita include: timp de acces (input/output) la accesarea datelor fizice pe suportul respectiv. În această situaţie trebuie ca SGBDD să determine strategia cea mai eficientă de a executa fiecare interogare în parte. DQP produce o strategie de execuţie care este optimizată relativ la o funcţie de cost. SGBDD oferă transparenţă concurenţei dacă rezultatele tuturor tranzacţiilor concurente (distribuite sau nu) sunt executate independent şi sunt logic echivalente cu rezultatele obtinuţe în cazul în care tranzacţiile sunt executate pe rând. costuri de comunicatii asociate cu transmiterea datelor prin retea. O tranzacţie distribuită accesează date stocate la mai mult de o locaţie în reţea. Utilizatorul trebuie sa specifice şi numele fragmentelor şi localizarea datelor. Fiecare tranzacţie e divizata în sub-tranzacţii. pe lângă cerinţele cunoscute pentru sistemele centralizate.

considerata regula de baza in sistemele distribuite. este cerinta ca aspectul distribuit trebuie sa fie transparent pentru utilizator. Test de autoevaluare a cunoştinţelor 1. deci nu trebuie sa aiba cunostinte in plus ca sa utilizeze resursele unei astfel de baze de date. Tipuri de transparenţă:    transparenţa distribuirii transparenţa tranzacţiilor transparenţa performanţelor M1. Cu alte cuvinte utilizatorul nu trebuie sa-si dea seama ca lucreaza cu o baza de date distribuita.1 Ce este o bază de date distribuită? 1.U1.2 Care sunt avantajele unui sistem distribuit? 1.4.4.4.Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită: centralizat fragmentat (partiţionat) replicat complet replicat selectiv Tipuri de fragmentare: pe orizontală pe verticală combinată Prima regula.3 Cum se poate face proiectarea alocării datelor? 1.4.4 Cum se face o fragmentare corectă? 1.4.5 Ce este fragmentarea? Răspunsurile se găsesc la sfârşit la pag 149 36 . În realitate transparenţa poate fi realizată doar într-o anumită măsură.4.

Obiectivele modulului La sfârşitul acestui modul studenţii vor fi capabili să:  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 relaţii în mod optim 37 . toate într-o organizare unitară. Modele de descriere a datelor Cuprins Introducere Obiectivele modulului U2. Un model de date este o abstracţie.1 Generalităţi U2. de relaţii între date şi de restricţii asupra datelor.Modulul 2. M3.2 Modelare E-R (Entity-Relaţionship) Introducere Numim model de date o colecţie integrată de concepte pentru descrierea datelor. Un model de date are în principal rolul de a furniza conceptele de bază şi notaţiile care să permită proiectanţilor şi utilizatorilor bazei de date să comunice în mod neambiguu legat de modul de organizare a datelor.

modelul funcţional.Unitatea de învăţare 2. Sunt incluse aici operaţiile care sunt utilizate pentru a actualiza sau a regăsi datele în baza de date precum şi operaţiile pentru schimbarea structurii bazei de date. relaţii. M2. care constă într-un set de reguli ce impun modul de alcătuire al bazei de date. Trebuie să menţionam şi modelele fizice de date. adică punctul de vedere al utilizatorului). Modele de date se pot realiza pentru fiecare nivel de abstractizare. Dintre diversele modele propuse în literatura de specialitate menţionam aici: modelele de date bazate pe obiecte.1. modelul semantic.1. ambele modele fiind utilizate pentru descrierea organizării datelor la nivel extern şi conceptual. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  aleagă ce model de date vor folosi pentru baza concretă de date  distingă modele la diferite nivele Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră. Astfel putem vorbi de:  model extern de date (care reprezintă aşa-numitul univers al discursului.U2. Generalităţi M2. modelele de date bazate pe înregistrare. Fiecare tip de înregistrare defineşte un număr fix de câmpuri.  model de date conceptual (care reprezintă structura logica a bazei de date. care descriu datele la nivel intern. atribute. Modele de date bazate pe înregistrare Într-un astfel de model baza de date consta dintr-un număr de înregistrări de format fix de tipuri eventual diferite. Aceste modele utilizează concepte specifice modelului E-R şi anume: entităţi. 38 . (3) o parte referitoare la integritatea datelor. independenta de sistemul de gestiune ales).1. Cele mai cunoscute modele de date sunt: modelul entitate-relaţie.  model de date intern (care reprezintă schema conceptuala într-un mod în care poate fi perceputa de SGBD). (2) o parte referitoare la manipularea datelor.U2. parte care cuprinde reguli de integritate care asigura acurateţea datelor. Introducere Un model de date cuprinde trei părţi: (1) o parte referitoare la structură. modelul orientat obiect. care defineşte tipul de operaţii care sunt permise asupra datelor.

Informaţia furnizata de aceste modele este cea referitoare la înregistrările fizice.  model de date intern (care reprezintă schema conceptuala într-un mod în care poate fi perceputa de SGBD). modelul EE-R şi conceptul principal asociat acestuia. Se considera că schema conceptuala sta la baza structurării unei baze de date.fiecare fiind în general de lungime fixa. M2.U2. Exista trei tipuri importante de modele de date bazate pe înregistrare: modelul de date relaţional. Rezumat Putem vorbi de:  model extern de date (adică punctul de vedere al utilizatorului). modelul de date reţea şi modelul ierarhic de date. SGBD-ul utilizat sau orice alte consideraţii fizice. Modele fizice de date Aceste modele descriu efectiv modul în care datele sunt memorate în calculator. vom discuta un model mai complex.  model de date conceptual (care reprezintă structura logica a bazei de date. Un astfel de model se numeşte model de date conceptual sau model logic. reprezentare care este independenta de detaliile de implementare cum ar fi programele de aplicaţie. 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 restricţiilor de cardinalitate. la căi de acces. la nivel fizic. O schema conceptuala completa şi bine gândită permite o reprezentare interna eficienta şi permite realizarea de view-uri utilizator fără dificultate. Modele fizice de date descriu efectiv modul în care datele sunt memorate în calculator. la organizarea înregistrărilor. modelul relaţional apărând cu o întârziere de un deceniu. Modelele de date bazate pe obiecte sunt: modelul entitate-relaţie. Având în vedere limitele modelului E-R. 39 . la nivel fizic. modelul semantic. etc. Modelele ierarhic şi reţea au fost dezvoltate mai întâi. conceptul de specializare/generalizare. 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).1. modelul orientat obiect. Modelare E-R (Entity-Relaţionship) Modelul E-R (Entity-Relaţionship) este un model conceptual de nivel înalt. limbajele de programare. independenta de sistemul de gestiune ales). modelul de date reţea şi modelul ierarhic de date. Modelarea conceptuala sau proiectarea conceptuala a bazei de date este procesul de construire a unui model care să reprezinte modul în care este utilizata informaţia de câtre beneficiar. Exista trei tipuri importante de modele de date bazate pe înregistrare: modelul de date relaţional. modelul funcţional. dezvoltat de Chen în 1976.

Test de autoevaluare a cunoştinţelor 2.U2.M2.1 Care sunt modele de date bazate pe înregistrare? Răspunsurile se găsesc la sfârşit la pag 152 40 .1.1.

Introducere Modelul E-R constituie un mod de reprezentare a bazelor de date relaţionale şi de aceea este un instrument util în proiectarea acestora. Mulţimea tuturor profesorilor Facultăţii de Ştiinţe formează ce? 41 . Exemple  Popescu Ion. un cont la banca identificabil în mod unic prin numărul sau şi numele băncii. M2.U2.U2. după care vom identifica problemele care pot apărea prin utilizarea unui astfel de model.Unitatea de învăţare 2. Numim tip de entitate sau mulţime-entitate un set de entităţi de acelaşi tip. Numim entitate un obiect sau un concept ce se poate identifica în mod unic. tip de relaţie (mulţime-relaţie). atribute.2. Exemple Mulţimea tuturor persoanelor care sunt studenţi ai Facultăţii de Ştiinţe pot defini mulţimea-entitate sau tipul de entitate student. de exemplu. Concepte de bază Conceptele primare ale modelului E-R includ : tip de entitate (mulţime-entitate). Vom discuta de asemenea problemele generate prin utilizarea modelul E-R la reprezentarea unor aplicaţii. posesor al buletinului de identitate seria ABC. În acest capitol. Ce este studentul Ion Ion? Ce este grupa 7172? O entitate care reprezintă un obiect ceva mai abstract poate fi. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  descrie structura bazei de date cu ajutorul unui model grafic  să aleagă cheia unei relaţii în mod optim Durata medie de parcurgere a primei unităţi de învăţare este de 3 ore. vom descrie conceptele primare care stau la baza modelului E-R.2 Modelare E-R (Entity-Relaţionship) M2. numărul: 444555 este o entitate deoarece identifica în mod unic o persoana în acest univers. Ea reprezintă 'obiecte' concrete (cu existenta fizica) sau abstracte (cu existenta conceptuala).2. Noţiunea de entitate este un concept de baza în cadrul modelului E-R.

Cum aţi descrie entitatea materii? Prin domeniul atributului înţelegem mulţimea valorilor care pot fi atribuite unui atribut simplu. O baza de date este o colecţie de tipuri de entitate din care fiecare conţine un număr neprecizat de entităţi de acelaşi tip. Un tip de entitate se identifică printr-un nume şi o listă de proprietatea. De exemplu data_naşterii se poate descompune în subdomeniile: an. cate o pereche pentru fiecare atribut ataşat tipului de entitate corespunzător. 42 . corespunzător tuturor cadrelor didactice ale Facultăţii de Ştiinţe şi student. zi. Numim atribute proprietăţile ataşate unui tip de entitate. valoare_atribut). Un tip de entitate conţine mai multe entităţi. telefon. număr_matricol. grupa. Unele domenii se pot descompune în mai multe subdomenii. Exemple Entitatea student poate fi descrisă de atributele: nume_student. Exemple Se pot defini următoarele tipuri de entitate: profesor. Domeniul unui atribut nu se poate defini întotdeauna foarte exact. atributul nume_student trebuie să fie un şir de caractere dar poate lua ca valori doar un nume de familie existent. (se mai întâlnesc denumirile: apariţia unei entităţi sau instanţa unei entităţi). data_nasterii. lună.Tipul de entitate reprezintă o mulţime de 'obiecte' ce aparţin lumii reale şi care sunt descrise de aceleaşi proprietatea. De exemplu. adresa. corespunzător tuturor studenţilor aceleiaşi facultăţi. Atributele unei entităţi conţin valorile care descriu fiecare entitate şi cu ajutorul cărora fiecare entitate se poate identifica în mod unic. prenume_student. Aceasta înseamnă că pot exista entităţi care să aparţină mai multor tipuri de entitate. Aceste valori reprezintă cea mai mare parte a datelor memorate într-o baza de date. O bază de date conţine în general mai multe tipuri de entităţi. Tipurile de entitate nu sunt neapărat disjuncte. sex. Orice obiect care aparţine unui tip de entitate şi care este identificabil în mod unic este numit simplu entitate. Se observa uşor că pot exista studenţi care sunt în acelaşi timp şi cadre didactice (studenţi la master care sunt preparatori sau asistenţi). Arătaţi că nici tipurile de entitate personal auxiliar şi profesor nu sunt disjuncte. In general putem considera că fiecare entitate este reprezentabila cu ajutorul unei mulţimi de perechi de forma (nume_atribut.

11.Exemple O entitate a tipului de entitate student poate fi reprezentata de mulţimea: {(nume_student. Atributele se pot clasifica în simple sau compuse. (telefon. În acest caz se poate limita de exemplu numărul numerelor de telefon la care poate fi găsit studentul la 43 . (număr_matricol. masculin). număr. (prenume_student. Brasov. Arătaţi alte atribute compuse. cod_poştal şi judeţ. 31455). fiecare cu o existenţă independentă. judetul Brasov).1981). Ele se mai numesc şi atribute atomice. (grupa. (adresa. 12. Pentru atributele cu mai multe valori trebuie precizate numărul minim şi numărul maxim de valori pe care le poate lua atributul respectiv. Numim atribut compus orice atribut care are mai multe componente. (data_nasterii. 15. Ion). Aceste atribute nu se pot diviza în mai multe atribute distincte. oraş. Exemple Atributul telefon poate fi un atribut cu mai multe valori. Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru fiecare entitate. (sex. 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. Arătaţi alte atribute simple ale tipului de entitate materii. Numim atribut simplu orice atribut care are doar o singură componentă şi o existenţă independentă. Numim atribut cu o singură valoare orice atribut care poate lua cate o singură valoare pentru fiecare entitate. Aceste atribute se pot diviza în general în mai multe atribute simple. Exemple Atributul adresă se poate descompune în atributele: strada. sau ca un întreg. B-dul Garii. respectiv derivate. Exemple Atributul sex corespunzător tipului de entitate student. 7211)} Reprezentaţi o entitate a tipului de entitate materii. cod 2200. Popescu). cu o singură valoare sau cu mai multe valori. 068/444555). Majoritatea atributelor sunt atribute cu o singură valoare.

fiecare cu o existenţă independentă.minim 0 şi la maxim 3. Reprezentare grafică . Arătaţi alte atribute derivate.. linii. 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. Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai multe alte atribute. Deci se pot stabili numărul minim şi numărul maxim de valori pe care le poate lua atributul. Să ne reamintim. care reprezintă atribute. Exemple Valoarea pentru atributul vârsta este derivată din valoarea atributului data_naşterii şi din data curentă. care reprezintă tipuri de entitate.        entitate care reprezintă un obiect ceva mai abstract poate fi. Numim tip de entitate sau mulţime-entitate un set de entităţi de acelaşi tip. Numim atribut cu mai multe valori orice atribut care poate lua mai multe valori pentru fiecare entitate. Numim atribut derivat orice atribut a cărui valoare se poate calcula din unul sau mai multe alte atribute. 44 . care au rolul de a evidenţia legăturile între elementele diagramei. dacă atributul este un atribut derivat şi respectiv cu linie dublă. Valoarea atributului numărul_total_de_entităţi se poate calcula numărând entităţile înregistrate. Prin domeniul atributului înţelegem mulţimea valorilor care pot fi atribuite unui atribut simplu. Arătaţi alte atribute cu mai multe valori. Acestea nu sunt singurele elemente grafice utilizate într-o diagrama E-R.    Un atribut se reprezintă printr-o elipsă. Elipsa este trasata cu linie punctată. Aceste atribute nu trebuie neapărat să descrie entitatea căreia ii corespunde atributul derivat. legată de entitatea căreia îi este asociat cu o linie şi etichetată cu numele atributului. O astfel de diagrama conţine elemente grafice cum ar fi: dreptunghiuri. un cont la banca identificabil în mod unic prin numărul sau şi numele băncii. Dreptunghiurile şi elipsele sunt etichetate cu numele 'obiectului' reprezentat.diagrame E-R Întreaga structura logica a unei baze de date poate fi reprezentata grafic cu ajutorul diagramelor E-R. daca atributul poate lua mai multe valori. elipse. de exemplu. Pe măsură ce vom defini noi concepte vom reveni cu precizări legate de modul de a le reprezenta..

45 ... Între tipul de entitate scări şi tipul de entitate locatari se poate stabili un tip de relaţie numit este_locuita_de. Formal. e n) reprezintă formal o relaţie. Dintre aceste atribute.. etaj adres şi apartament. care se descompune în număr_bloc.. atributul adresa este atribut compus. e nEn } ceea ce înseamnă că ( e 1. Fie E1. . Descrieţi relaţiile care apar între student şi catalog.... nume şi a adresa.. Exemple num e numãr bloc locatari adres a numãr adres scara apartam matric a ent ol etaj adres a adres a Reprezentarea cu diagrama E-R a entităţii locatari adres În exemplu entitatea locatari are următoarele atribute: număr_matricol. E n tipuri de entitate. . e2E2.. Explicaţia sublinierii a atributului număr_matricol se va da în secţiunea care se ocupa de chei. Numim relaţie orice asociere între entităţi. tot în această unitate de învăţare. scara. E2. 'Popescu Ion') care va fi interpretata: "Scara A este locuita de Popescu Ion". e n) | unde e1E1. Desenaţi structura corespunzătoare tipului de entitate student. .Dacă un atribut este compus. e2. e2.. Exemple Într-o aplicaţie care ar servi unor evidente în cadrul asociaţiilor de locatari putem considera tipul de entitate locatari descris de atributele: nume.. Acest tip de relaţie va conţine relaţii de tipul ('Scara A'. .. un tip de relaţie este o submulţime a următoarei mulţimi: {( e1. adresa şi număr_matricol şi tipul de entitate scări descris de atributele număr_de_bloc şi scara. atunci componentele atributului se reprezintă prin elipse legate cu cate o linie de atributul compus. când asocierea include cate o entitate pentru toate tipurile de entitate participante. Numim tip de relaţie orice asociere între tipuri de entităţi.

Exemple Dacă am considera entităţile lucrători şi manageri care se refera la personalul aceleiaşi întreprinderi. în diagrama E-R corespunzătoare. Exemple lucrator angajaţi manager lucrează pentru 46 . am face constatarea că sunt descrise de aceleaşi atribute deci aparţin aceluiaşi tip de entitate şi anume angajaţi. Aşadar relaţia reprezentată mai sus are gradul n. Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. deoarece acesta este în general implicit. Rolurile jucate de fiecare entitate se pot stabili recurgându-se la perechi ordonate (muncitor. Tipurile de relaţii se reprezintă în diagramele E-R cu ajutorul romburilor care sunt etichetate cu numele tipului de relaţie. atunci relaţia se numeşte binară. Entităţile implicate într-o relaţie se numesc participanţi. Exemple nume numă r de bloc scări 1 scar a este locuită număr matric ol locatari M adre sa Reprezentarea cu diagrama E-R a relaţiei este_locuita_de Reprezentaţi relaţia dintre student şi catalog. cele două arce de la entitate la relaţie şi înapoi. care sunt importante în înţelegerea corectă a relaţiei. Funcţia pe care o joaca o entitate într-o relaţie se numeşte rolul entităţii. primesc diferite etichete. manager).Numim gradul relaţiei numărul entităţilor participante în relaţie. În cazul relaţiilor recursive. în general nu este necesar să se specifice rolul entităţilor într-o relaţie. Relaţia binara lucrează_pentru. stabilita între lucrători şi manageri este o relaţie recursiva. în acest caz este necesar să se precizeze rolurile entităţilor implicate. Dacă într-o relaţie sunt doi participanţi.

Numim gradul relaţiei numărul entităţilor participante în relaţie. Unui tip de relaţie i se pot asocia atribute descriptive în acelaşi mod în care se pot asocia atribute unui tip de entitate. Exemple Tipului de relaţie este_locuita_de. atunci relaţia se numeşte binară. După cum se observa. acest atribut descrie exclusiv tipul de relaţie şi el nu mai are sens în afara ei. Majoritatea tipurilor de relaţie au gradul doi.. i se poate asocia atributul data care să retina data la care locatarul L s-a mutat pe scara S.    Numim relaţie orice asociere între entităţi. când asocierea include cate o entitate pentru toate tipurile de entitate participante. sau mai-multe-la-mai-multe (M:N). Să ne reamintim. a) Restricţii de cardinalitate Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate participantă. Dacă într-o relaţie sunt doi participanţi. în acest caz este necesar să se precizeze rolurile entităţilor implicate. Restricţii structurale Este posibil să se stabilească diverse restricţii la care conţinutul unei baze de date trebuie să se conformeze.Reprezentarea cu diagrama E-R a relaţiei recursive lucrează_pentru Astfel relaţia ('Popescu Ion'. cardinalitatea exprima numărul entităţilor la care o alta entitate poate fi asociata prin intermediul unei relaţii. Vom trata în continuare restricţiile care se pot impune entităţilor participante într-o relaţie. unu-la-mai-multe (1:M). Entităţile implicate într-o relaţie se numesc participanţi.. Daţi un exemplu de relaţie recursivă legată de entitatea profesor. Restricţiile structurale se refera insa în mod evident la tipurile de relaţie şi la tipurile de entitate asociate. Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite. care implica tipurile de entitate scări şi locatari. Doua tipuri importante de restricţii sunt de menţionat aici: restricţii de cardinalitate şi restricţii de participare. Relaţiile unu-la-unu: 47 . Aceste restricţii trebuie să reflecte caracteristicile relaţiilor aşa cum se percep în 'lumea reala'. Cardinalitatea în acest caz poate fi de tipurile: unu-la-unu (1:1). Observaţie: Am utilizat în definiţia de mai sus referiri la entităţi şi la relaţii pentru a fi mai expliciţi. Altfel spus. Această observaţie rămâne valabila şi în consideraţiile ce urmează. 'Ionescu Gheorghe') se interpretează "Popescu Ion lucrează pentru (este subordonatul lui) Ionescu Gheorghe".

Implicarea fiecarei entitati într-o relaţie data este numita "participarea entitatii". arcul dinspre tipul de entitate scări se etichetează cu 1 iar arcul dinspre tipul de entitate locatari se etichetează cu M nume numă r de bloc scări 1 Modelul semantic este_locuita_de.C 48  Fam . apartinand unui tip de entitate. 1. Deci. o entitate. din figură reprezintă scar a este locuită număr matric ol locatari adre sa M relaţia unu-la-mai-multe Din exemplul de mai sus se observă uşor că dacă relaţia directă este de unu-la-maimulte.B Sc. A Sc. Exemple Exemplificăm acest tip de relaţie prin relaţia este_locuita_de dintre tipurile de entităţi scari. respectiv locatari. este legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia respectiva. dacă şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe. sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie. Exemple atribu te nr_blo c scara nr_blo c scara nr_blo c scara scări Sc.2 atribu nr_ma te t numel e nr_ma t numel e nr_ma t . în reprezentarea grafică a acestui tip de relaţie. In diagrama E-R se eticheteaza arcul dintre relaţie şi fiecare tip de entitate cu cardinalul relaţiei.1  Fam . atunci relaţia inversă este de unu-la-unu. în cazul relaţiilor unu-la-unu fiecare din cele doua arce se eticheteaza cu 1. atunci relaţia directa este de tipul mai-multe-la-maimulte şi se notează cu (N:M).În relaţiile unu-la-unu. Relaţiile unu-la-mai-multe: In relaţia de tip unu-la-mai-multe orice entitate. Daţi un exemplu de n la m între student şi materii. Relaţiile mai-multe-la-mai-multe: Acest tip de relaţie se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia inversă nu este de unu-la-unu. aparţinând primului tip de entitate. este legată de 0. ci de unu-la-mai-multe.3 este locuita de R1 R2 R3 locatari  Fam .

 Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-maimulte prin faptul că relaţia inversă nu este de unu-la-unu. atunci participarea tipului de entitate personal în relaţia are_alocat este parţiala. 1. În acest caz. 49 . unu-la-mai-multe (1:M). În caz contrar participarea se numeşte parţială. apartinand unui tip de entitate. În diagrama E-R aceste tipuri de relaţii se reprezintă prin arc cu linie dublă pentru participarea totală.  În relaţiile unu-la-unu. Daca insa admitem că unii membri ai personalului (de exemplu vânzătorii) nu lucrează în birourile nici unei filiale. Să ne reamintim. ci de unu-lamai-multe. atunci relaţia directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M). respectiv cu linie simplă pentru participarea parţială. Cardinalitatea în acest caz poate fi de tipurile: unu-la-unu (1:1). b) Restricţii de participare Numim restricţii de participare acele restricţii prin care se determină dacă existenţa unui tip de entitate depinde de faptul că este legat sau nu de un alt tip de entitate prin intermediul relaţiei în discuţie. Restricţii de cardinalitate  Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate participantă. o entitate. sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie. Participarea este totala daca existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. este legată de 0. Termenii participare totala şi participare parţială pot fi înlocuiţi cu participare obligatorie respectiv participare opţionala. Participarea unei entităţi poate fi totală sau parţială. Deci.. aparţinând primului tip de entitate. sau maimulte-la-mai-multe (M:N). există un mod de notaţie prin care se etichetează arcele relaţiei cu perechea de numere ce reprezintă minimul.Reprezentarea cu reţele semantice a relaţiei 1:M este_locuita_de Reprezentaţi cu reţea semantică relaţia dintre student şi catalog. Pentru participarea parţială.. dacă şi relaţia directă şi relaţia inversă sunt de tipul unu la-mai-multe. respectiv maximul entităţilor participante la relaţie. Exemple Daca se considera filialele unei firme oarecare ca entităţi în tipul de entitate filiala şi daca se considera tipul de entitate personal (unde entităţile reprezintă personalul firmei respective) se poate defini tipul de relaţie are_alocat stabilit între o filiala concreta şi personalul firmei. daca se considera că fiecare filiala are alocat personal al firmei atunci participarea tipului de entitate filiala în relaţia are_alocat este totala.  Majoritatea tipurilor de relaţie au gradul doi. este legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia respectiva  In relaţia de tip unu-la-mai-multe orice entitate.

Discutaţi participarea în relaţia student cu materii. daca o submulţime de atribute formează o supercheie. Astfel: o relaţie care leagă doua tipuri de entitate tari este reprezentata cu un romb trasat cu linie simpla iar relaţia care leagă un tip de entitate tare de un tip de entitate slab este reprezentata cu un romb trasat cu linie dubla. Să ne reamintim. Entităţile slabe se mai numesc existenţial dependente sau subordonate iar entităţile tari se mai numesc părinte sau dominante. c) Dependenţele de existenţă Numim tip slab de entitate un tip de entitate. submulţime care poate duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de entitate luat în considerare. deoarece valoarea cheii este unica pentru fiecare entitate în parte. În caz contrar participarea se numeşte parţială. În caz contrar participarea se numeşte parţială. În diagrama E-R tipurile de entitate tari se reprezintă cu un dreptunghi trasat cu linie simpla.. Numim cheie candidat orice supercheie care conţine un număr minim de atribute.. Participarea unei entităţi poate fi totală sau parţială. Chei Conceptual este evident că entităţile şi relaţiile individuale care participa la modelarea unei baze de date sunt distincte între ele. Participarea unei entităţi poate fi totală sau parţială. Pentru tipurile de entitate slabe conturul dreptunghiului este trasat cu linie dubla. Numim supercheie asociata unui tip de entitate. a cărui existenţă nu depinde de existenta nici unui alt tip de entitate. Participarea este totala daca existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. submulţime care poate duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de 50 .  Numim supercheie asociata unui tip de entitate. Participarea este totala daca existenta entităţii respective necesita existenta unei entităţi asociate în relaţia dată. Diferenţa între entităţi sau diferenţa între relaţii se exprima cu ajutorul atributelor care le descriu. orice submulţime a mulţimii de atribute ce descriu tipul de entitate. Daţi exemple de chei în entitatea profesor. Să ne reamintim. De asemenea aceasta notaţie se extinde şi la relaţii. a cărui existenţă este dependentă de existenta unui alt tip de entitate. Putem spune că o cheie candidat este caracterizata de următoarele proprietatea: .unicitatea.. atunci orice mulţime de atribute care include supercheia este tot o supercheie.. Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. orice submulţime a mulţimii de atribute ce descriu tipul de entitate. Numim tip tare de entitate un tip de entitate. Este evident ca.

Dintre acestea. Cheia primara a tipului de relaţie este formata din reuniunea mulţimilor de atribute care formează cheile primare ale tipurilor de entitate participante. deci are întotdeauna cel puţin o cheie candidat. un set de atribute care permite realizarea unei distincţii între entităţile care depind de o anume entitate tare. deoarece nici o submulţime proprie de atribute ale cheii nu are proprietatea de unicitate. cheia primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare de care este dependenta existenţial. pentru o mulţime oarecare de entităţi concrete. cheia primară este cheia aleasa ca mijloc principal de identificare a entităţilor în cadrul tipului de entitate respectiv. Numim cheie candidat orice supercheie care conţine un număr minim de atribute.       entitate luat în considerare. Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei candidat. la care se adaugă mulţimea atributelor care compun discriminatorul tipului de entitate slab. Un tip de entitate slab nu are cheie primara. Doar faptul ca. un set de atribute care permite realizarea unei distincţii între entităţile care depind de o anume entitate tare. Dintre acestea. valorile diferă între ele nu este de ajuns. Cu ajutorul cheilor se pot identifica în mod unic relaţiile individuale. 51 . Cheia primară este în general cea mai scurtă dintre cheile candidat. In diagrama E-R atributele care intră în componenţa cheii primare. Numim discriminatorul unui tip de entitate slab. Aşadar. Aşadar. Să observam că un tip de entitate tare are întotdeauna o cheie primara.ireductibilitatea. Numim cheie compusă orice cheie candidat care conţine cel puţin două atribute. Si relaţiile au chei. Observaţie: Faptul că valorile unei chei candidat sunt unice pentru fiecare entitate nu poate fi determinat decât cu ajutorul informaţiilor semantice referitoare la valorile atributelor ce formează cheia. Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. se evidenţiază prin sublinierea numelui atributului. Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei candidat. Trebuie să se cunoască semnificaţiile din lumea reala a atributelor ce formează cheia pentru a se stabili daca acestea vor avea valori unice. Numim cheie compusă orice cheie candidat care conţine cel puţin două atribute. cheia primară este cheia aleasa ca mijloc principal de identificare a entităţilor în cadrul tipului de entitate respectiv. Probleme se ivesc atunci când trebuie să identificam în mod unic entităţile unui tip de entitate slab. cheia primara a unui tip de entitate slab este formata din cheia primara a tipului de entitate tare de care este dependenta existenţial. Numim discriminatorul unui tip de entitate slab. la care se adaugă mulţimea atributelor care compun discriminatorul tipului de entitate slab. .

1 Găsiţi cheile candidat ale tabelei student. Deci. Dacă într-o relaţie sunt doi participanţi. Rezumat Numim relaţie orice asociere între entităţi. cheia primară este cheia aleasa ca mijloc principal de identificare a entităţilor în cadrul tipului de entitate respectiv.3 Stabiliţi domeniul fiecărui atribut din tabela profesor. unu la mai mulţi şi mulţi la mulţi. unu-la-mai-multe (1:M).2 Test de autoevaluare a cunoştinţelor 2. Cardinalitatea în acest caz poate fi de tipurile: unu-la-unu (1:1). Dintre acestea. În relaţiile unu-la-unu. Entităţile implicate într-o relaţie se numesc participanţi. este legată de 0.2. Numim gradul relaţiei numărul entităţilor participante în relaţie. este legată de cel mult o entitate din celalalt tip de entitate implicat în relaţia respectiva In relaţia de tip unu-la-mai-multe orice entitate. Si relaţiile au chei. orice submulţime a mulţimii de atribute ce descriu tipul de entitate.U. apartinand unui tip de entitate. Cheia primara a tipului de relaţie este formata din reuniunea mulţimilor de atribute care formează cheile primare ale tipurilor de entitate participante.U2. Pentru un tip de entitate este posibil să se poată determina una sau mai multe chei candidat. aparţinând primului tip de entitate. M2. Pentru o cheie candidat nici o submulţime proprie nu mai este supercheie. Stabiliţi cheia primară. sau mai-multe-la-maimulte (M:N). în acest caz este necesar să se precizeze rolurile entităţilor impli cate. Numim cardinalitate (polaritate) numărul relaţiilor posibile pentru o entitate participantă. atunci relaţia se numeşte binară. Numim relaţie recursivă orice relaţie în care aceleaşi entităţi participă în roluri diferite.2. ci de unu-la-mai-multe. 1. Cu ajutorul cheilor se pot identifica în mod unic relaţiile individuale.2 Daţi exemple de relaţii unu la unu. dacă şi relaţia directă şi relaţia inversă sunt de tipul unu-la-mai-multe. Răspunsurile se găsesc la sfârşit la pag 152 52 .2.2. când asocierea include cate o entitate pentru toate tipurile de entitate participante. Relaţiile mai-multe-la-mai-multe se deosebeşte de relaţia unu-la-mai-multe prin faptul că relaţia inversă nu este de unu-la-unu. Majoritatea tipurilor de relaţie au gradul doi. sau mai multe entităţi apartinand celui de-al doilea tip de entitate participant la relaţie.2. atunci relaţia directa este de tipul mai-multe-la-mai-multe şi se notează cu (N:M). o entitate. Numim cheie candidat orice supercheie care conţine un număr minim de atribute. submulţime care poate duce la identificarea în mod unic a oricărei entităţi în cadrul tipului de entitate luat în considerare.M2. 2. Numim supercheie asociata unui tip de entitate. 2.

Cuprins Introducere Obiectivele modului U3. Modelul matematic al acestor cereri la baza de date relaţională este algebra relaţională. Introducere Una din funcţiunile importante ale SGBD+urilor este regăsirea datelor. Limbaje de cereri. U3.Modulul 3. M3.1 Algebra relaţională. Pentru aceasta trebuie să facem cereri la baza de date.2 SQL. Obiectivele modulului La sfârşitul acestui modul studenţii vor fi capabili să:  Facă operaţii în algebra relaţională  Exprime cereri în algebra relaţională  Exprime cereri în SQL  exprime actualizări ale bazei de date 53 . M3. iar limbajul standardizat de cereri este SQL.

54 . prin care se reprezintă atât datele cât şi legăturile dintre date. Introducere In cadrul bazelor de date relaţionale.1 Algebra relaţională. Structura relaţionala a datelor Prezentarea structurii relaţionale a datelor impune reluarea noţiunilor de: domeniu. M3.1. Un domeniu se poate defini explicit. În continuare. vor fi prezentate pe larg aceste componente. modificarea şi ştergerea datelor. prin precizarea proprietăţilor pe care le au valorile din cadrul domeniului respectiv. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  Facă operaţii în algebra relaţională  Exprime cereri în algebra relaţională Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore. datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date. numite relaţii. M3.U3. construită special pentru exprimarea legaturilor între relaţii (în cazul legaturilor de tip "mulţi la mulţi"). în scopul realizarii funcţiilor de prelucrare asupra bazei de date. inserarea. O bază de date relaţională (BDR) reprezintă un ansamblu de relaţii. Domeniul reprezintă un ansamblu de valori. Operatorii modelului relaţional definesc operaţiile care se pot efectua asupra relaţiilor.1. Aceste atribute figurează într -una din relaţiile implicate in asociere (de regulă. atribut şi schemă a unei relaţii. Asocierile dintre relaţii se reprezintă explicit prin atribute de legătură. caracterizat printr-un nume. relaţie. prin enumerarea tuturor valorilor apartinând acestuia sau implicit.U3. Restricţiile de integritate ale modelului relaţional permit definirea stărilor coerente ale bazei de date. respectiv consultarea. în cazul legaturilor de tip "unu la mulţi") sau sunt plasate într-o relaţie distinctă.Unitatea de învăţare 3.

Relaţia reprezintă un subansamblu al produsului cartezian al mai multor domenii. unde: v1 este o valoare apartinând domeniului D1. "F".a... "M". 30>. vn>. tuplurile trebuie să fie distincte (nu se admit duplicări ale tuplurilor) . <"Vasile". <"Vasile". de exemplu ca D1 cuprinde valorile referitoare la sexul unei persoane. submulţime care să cuprindă numai tuplurile cu semnificaţie. . Exemple De exemplu. D2 conţine valori care exprimă vârsta unei persoane şi D3 cuprinde numele unor persoane. Se desprinde de aici necesitatea definirii unei submulţimi de tupluri. <"Vasile"."M". D3.d. "F"... . subansamblu caracterizat printr-un nume şi care conţine tupluri cu semnificatie. x aparţine [0. Exemple Relaţie reprezentată sub forma unei tabele de date 55 . D2.100]) D3 :(s/s=şir de caractere) În cazul lui D1 s-a recurs la o definire explicită.1. <"Vasile".15>."M") D2 : (x / x aparţine N. "M". v2.100> aparţin produsului cartezian: D3 x D1 x D2 Să presupunem că se acordă o anumită semnificaţie valorilor domeniilor D1. 35>) Intr-o relaţie.. sexul şi vârsta aceleiaşi persoane. de exemplu domeniile D1. iar coloanele corespund domeniilor (fig.).. D2.20>. definite anterior. O reprezentare comodă a relaţiei este tabelul bidimensional (tabela de date în care liniile reprezinta tuplurile.Exemple Sa considerăm. în timp ce pentru D2 şi D3 s-a utilizat definirea implicită. dacă presupunem că există o singură persoană cu acest nume. Considerând de exemplu că nu se cunosc decât două persoane definim realţia R prin tuplurile care descriu aceste persoane şi anume: R : (<"Maria". definite astfel: D1: ("F". Dintre cele 202 tupluri care au valoarea "Vasile" pe prima pozitie. v2 este o valoare din D2 s. Dn produsul catezian al acestora reprezinta ansamblul tuplurilor <v1. Pentru un ansamblu de domenii D1. din cadrul produsului cartezian al domeniilor.m. tuplurile: <"Maria". numai unul poate avea o semnificaţie. "F". Numai unele dintre tuplurile produsului cartezian: D3 x D1 x D2 pot avea o semnificaţie şi anume cele care conţin numele.3. 50>. D2. Sa considerăm. D3.

Numele coloanei (atributului) exprimă de obicei semnificaţia valorilor din cadrul coloanei respective. în timp ce numărul valorilor dintr -un tuplu defineste gradul relaţiei. ordinea liniilor şi a coloanelor din cadrul tabele i de date nu trebuie să prezinte nici o importanţă. A n:Dm) a) b) A1:D1 … An:Dm Operatorii modelului relaţional. caracterizată printr-un nume. Pentru a diferenţia coloanele care conţin valori ale aceluiaşi domeniu şi a elimina astfel dependenţa de poziţie în cadrul tabelei se asociază fiecarei coloane un nume distinct.calculul relaţional. O posibilitate de organizare a acestor date o reprezintă relaţia din figură R: D3 D1 D2 “Maria” “F” 30 “Vasile” “M” 35 Relatia PERS reprezintă un subansamblu al produsului cartezian: D3 x D1 x D2 x D3. chiar dacă în construirea relaţiilor se admit domenii infinite. In timp ce tuplurile dintr-o relaţie trebuie să fie unice un domeniu poate apare de mai multe ori în produsul cartezian pe baza căruia este definită relaţia. 56 .sex. .. Exemple Să considerăm. Atributul reprezintă coloana unei tabele de date. …. cu atributele A1... pentru o relaţie R. În prezentarea conceptului de reţatie se recurge uneori la analogii cu alte concepte. flexibilă. . întrucat este uşor de înţeles şi de utilizat. A2. ceea ce duce la aparitţa noţiunii de atribut. de exemplu că pentru o persoana dispunem de urmatoarele date: nume. Într-o organizare eficientă. cu m <= n.. Semnificaţia valorilor din cadrul unui tuplu se stabileşte Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza domeniului de care aparţin valorile. ci şi in funcţie de poziţia ocupată în cadrul tuplului. Numărul tuplurilor dintr -o relaţie reprezinta cardinalul relaţiei. Modelul relaţional oferă două colecţii de operatori pe relaţii şi anume: .. Schema unei relaţii Prin schema unei relaţii se întelege numele relaţiei.tuplul poate fi considerat drept o înregistrare. pentru fiecare atribut precizându-se domeniul asociat. schema relaţiei R poate fi reprezentată într una din formele R(A1:D1. D2. Relaţia poate avea semnificaţia unui fişier. Dependenţa fată de ordine a datelor inseamnă o reducere a flexibiltăţii organizarii datelor.algebra relaţionala. urmat de lista atributelor. Dm. An şi domeniile: D1. iar valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înre gistrare..Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor. vârsta şi numele soţului/soţiei. extrem de bine cunoscute în domeniul prelucrării automate a datelor precum cel de fişier. În cadrul modelului relaţional nu intereseaza decat relaţiile finite. Astfel..

1. cu schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în relaţia R2. fiecare operaţie având drept operanzi una sau mai multe relaţii şi producând ca rezultat o altă relaţie. proiecţia. Codd a introdus aşa numita AR standard. Ulterior. Reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 a mbele cu o aceeaşi schemă. în cele ce urmează. Notaţia uzuală pentru operaţia de diferenţă a doua relaţii este: R1-R2 57 . În acest sens. cu schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată. precum: reuniunea.La rândul sau. splitarea (spargerea) unei relaţii. Reuniunea. aşa numitele operaţii "adiţionale" sau extensii ale AR standard.operaţii de bază. diviziunea etc. Ne limităm. produsul cartezian etc. . produsul cartezian. Exemple Reuniunea relatiilor ORASE şi MUNICIPII Diferenţa. Reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2.3. selecţia şi joncţiunea precum şi din două operaţii derivate: intersecţia şi diviziunea. Codd a introdus algebra relaţionala (AR) cu operaţii pe relaţii.calcul relaţional orientat pe tuplu. Unele operaţii ale AR pot fi definite prin intermediul altor operaţii. calcul relaţional orientat pe domeniu. 3. la operaţiile AR standard au fost adăugate şi alte operaţii. calculul relaţional este de două tipuri: .operaţii derivate. Notaţia uzuală pentru reuniune este: R1 U R2 Reprezentarea grafică a reuniunii este prezentata in fig. F. la elemente de algebră relaţională. ca: intersecţia. constituită din 6 operaţii de bază: reuniunea. Algebra relaţională şi extensiile sale E. ambele cu o aceeaşi schemâ. putem vorbi de: . În continuare vor fi prezentate principalele operaţii ale AR. operaţie care constă din construirea unei noi relaţii R3. operaţia constând din construirea unei noi relaţii R3. precum:complementara unei relaţii. diferenţa. diferenţa. precum şi modul lor de utilizare. închiderea tranzitivă etc.

Exemple Diferenţa relaţiilor ORAŞE şi MUNICIPII 3. Produs cartezian. Notaţia uzuală pentru desemnarea operaţiei este: R1xR2 Exemple TRANSPORT ORAŞ:D1 Braşov Târgovişte Braşov Târgovişte Braşov Târgovişte ORAŞ:D1 Braşov Târgovişte JUDEŢ: D1 Braşov Dâmboviţa Braşov Dâmboviţa Braşov Dâmboviţa TRANSPORT:D3 tramvai tramvai autobuz autobuz troleibuz troleibuz ANSP:D3 tramvai X autobuz troleibuz TARIF:D4 30 30 50 50 50 50 TARIF:D3 30 50 50 JUDEŢ:D1 Braşov Dâmboviţa ORAŞE: TARIFE Produsul cartezian al relaţiilor ORAŞE şi TARIFE 58 . operaţie care constă din construirea unei noi relaţii R3. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2. a cărei schemă se obţine prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile tuplurilor din R1 cu cele din R2.

Notaţia folosită in mod uzual pentru desemnarea operaţiei de selecţie este următoarea: Σ(conditie)R 59 . Proiecţia. selecţia înseamnă efectuarea unor tăieturi orizontale asupra relaţiei R. <=. care pot avea ca efect apariţia unor tupluri duplicate ce se cer a fi eliminate. operaţie care constă din construirea unei noi relaţii P. Întrucât cel mai adesea.…. adică eliminarea de tupluri. Roprezintă o operaţie din AR definită asupra unei relaţii R. a cărei schemă este identică cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o condiţie menţionată explicit în cadrul operaţiei.Aj. Condiţia precizată în cadrul operaţiei de selecţie este în general de forma: unde: "operator de comparaţie" poate fi: <. Notaţia uzuală pentru operaţia de proiecţie este: ΠAi.4. Reprezintă o operaţie din AR definită asupra unei relaţii R.Am (R) Exemple Proiectia relaţiei ORAŞE pe atributul "Judeţ" 5. > sau <>. nu toate tuplurile din R satisfac. mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei. această condiţie. în care se regăsesc unele atribute din R. Selecţia. >=. înseamnă efectuarea unor tăieturi verticale asupra lui R. operaţie care constă din construierea unei relaţii S. Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad p.

Exemple

Selecţie efectuata asupra relaţiei ORAŞE

6. Joncţiunea (Joinul). Reprezintă o operaţie din AR defin ită pe două relaţii: R1 şi R2, operaţie care constă din construirea unei noi relaţii R3, prin concatenarea unor tupluri din R1 cu tupluri din R2. Se concateneaza acele tupluri din R1 şi R2 care satisfac o anumita condiţie, specificată explicit în cadrul operaţiei. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri care satisfac condiţia de concatenare. Notaţiiile uzuale pentru desemnarea operaţiei de joncţiune sunt:

Reprezentarea grafica a operaţiei de joncţiune In general, condiţia de concatenare menţionata in cadrul operaţiei de joncţiune este de forma:

In funcţie de operatorul do comparaţie din cadrul condiţiei de concatenare, joinul poate fi de mai multe tipuri. Cel mai important tip de join, în sensul celei mai frecvente utilizări este equijoinul.

Equijoinul reprezinta joncţiunea dirijată de o condiţie de forma:

Operatia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi selecţie, rezultatul unui join fiind acelaşi cu rezultatul unei selecţii operate asupra unui produs cartezian, adică:

60

JOIN (R1,R2, condiţie) = RESTRICT(PRODUCT(R1,R2), condiţie) Produsul cartezian reprezintă o operaţie laborioasă şi foarte costisitoare, ceea ce face ca in locul produsului să fie utilizat joinul ori de câte ori acest lucru este posibil. Cu toate că apare drept o operaţie derivată, joinul este prezentat de obicei drept o operaţie de bază din AR, dată fiind importanţa sa in cadrul sistemelor relaţionale, în special la construirea relaţiilor virtuale. In cadrul fig.3.9. este ilustrată operaţia de equijoin. Au fost definite numeroase variante ale operaţiei de joncţiune, variante care dife ră nu numai în funcţie de tipul condiţiilor de concatenare, ci şi după modul de definire a schemei şi respectiv, extensiei relaţiei rezultate prin joncţiune. Exemple

Operaţia de equijoin a relaţiilor ORAŞE şi ESTIMARI

Joncţiunea naturală. In cazul equijoinului, schema relaţiei conţine toate atributele celor doi operanzi (fig.3.10.) În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două valori egale. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală, ca operaţie definită pe două relaţii: R1 şi R2, prin care este construită o noua relaţie R3, a cărei schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi nume. Notaţia uzuală pentru joncţiunea naturală este: Reprezentarea grafică a acestei operaţii este prezentată în fig. 3.10.

Reprezentarea grafică a operaţiei de joncţiune

61

Exemple

7. Intersecţia. Reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2 ambele cu aceeaşi schemă, operaţie care constă din construirea unei noi relaţii R3, cu schema identică cu a operanzilor şi cu extensia formată din tuplurile comune lui R1 şi R2. Notaţile uzuale folosite pentru desemnarea operaţiei de intersecţie sunt:

Reprezentarea grafică a operaţiei de intersecţie este prezantată în fig. 3.12., iar un exemplu de intersecţie a doua relaţii figurează în fig. 3.13.

Reprezentarea grafica a operatiei de intersectie

62

operaţie care constă din construirea unei noi relaţii R3. operaţie care constă din construierea unei relaţii S. Proiecţia reprezintă o operaţie din AR definită asupra unei relaţii R. Selecţia reprezintă o operaţie din AR definită asupra unei relaţii R. Diferenţa reprezintă operaţie din AR definită pe doua relaţii: R1 şi R2. operaţie care constă din construirea unei noi relaţii R3.Exemple Intersecţia relatiilor ORAŞE şi MUNICIPII Intersecţia reprezintă o operaţie derivată. care poate fi exprimată prin intermediul unor operaţii de bază. De exemplu. Produs cartezian reprezintă o operaţie a AR definită pe două relaţii: R1 şi R2.U3. mai mic decât cel iniţial (p < n) ceea ce explică şi numele de proiecţie atribuit operaţiei. a cărei schemă este identică 63 . operaţia de intersecţie se poate exprima prin intermediul operaţiei de diferenţă. Prin operaţia de proiecţie se trece de la o relaţie de grad n la o relaţie de grad p. care pot avea ca efect apariţia unor tupluri duplicate ce se cer a fi eliminate. operaţie care constă din construirea unei noi relaţii P. operaţia constând din construirea unei noi relaţii R3. Rezumat Reuniunea reprezintă o operaţie a AR definita pe doua relaţii: R1 şi R2 ambele cu o aceeaşi schemă. ambele cu o aceeaşi schemâ. cu ajutorul următoarelor echivalenţe: R1 R2=R1-(R1-R2) R1 R2=R2-(R2-R1) M3.1. în care se regăsesc unele atribute din R. cu schema identică cu R1 şi R2 şi având drept extensie tuplurile din R1 şi R2 luate impreună o singură dată. a cărei schemă se obţine prin concatenarea schemelor relaţiilor R1 şi R2 şi a cărei extensie cuprinde toate combinaţiile tuplurilor din R1 cu cele din R2. cu schema identică cu a operanzilor şi cu extensia formată din acele tupluri ale relaţiei R1 care nu se regăsesc şi în relaţia R2. înseamnă efectuarea unor tăieturi verticale asupra lui R.

1. M3. In sensul eliminării acestei redundanţe s-a introdus joncţiunea naturală. a cărei schemă este obţinută prin reuniunea atributelor din relaţiile R1 şi R2 (atributele cu acelaşi nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R1 cu tuplurile din R2 care prezintă aceleaşi valori pentru atributele cu acelaşi nume. prin concatenarea unor tupluri din R1 cu tupluri din R2. Test de autoevaluare a cunoştinţelor 3. d) Faceţi selecţia tabelei de mai nainte după nota < 5. Joncţiunea naturală. nu toate tuplurile din R satisfac. operaţie care constă din construirea unei noi relaţii R3. ca operaţie definită pe două relaţii: R1 şi R2.2 Să se exprime în algebra relaţională cererile: a) Studenţii grupei 7271 b) Studenţii care sunt şi profesori c) Studenţii corigenţi d) Studenţii integralişti Răspunsurile se găsesc la sfârşit la pag 152 64 .1. La acestea două din urmă faceţi reuniunea. 3. schema relaţiei conţine toate atributele celor doi operanzi În toate tuplurile relaţiei rezultat vor exista de aceea cel puţin două valori egale. profesor. Joncţiunea (Joinul) reprezintă o operaţie din AR definită pe două relaţii: R1 şi R2. selecţia înseamnă efectuarea unor tăieturi orizontale asupra relaţiei R. Se concateneaza acele tupluri din R1 şi R2 care satisfac o anumita condiţie. Întrucât cel mai adesea. c) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi materii. prin care este construită o noua relaţie R3. a) Faceţi selecţie din student după grupa … b) Faceţi proiecţie la student şi la profesor după nume.1 Cosideraţi instanţe ale tabelei student.U3.1. această condiţie.materii şi catalog. Extensia relaţiei R3 va contine deci combinaţiile acelor tupluri care satisfac condiţia de concatenare. adică eliminarea de tupluri.cu cea a relaţiei R şi a cărei extensie este constituită din acele tupluri din R care satisfac o condiţie menţionată explicit în cadrul operaţiei. specificată explicit în cadrul operaţiei. In cazul equijoinului.

a fost conceput iniţial de firma IBM. Pentru definirea interogărilor de selecţie simple se utilizează următoarea sintaxă a instrucţiunii SELECT: SELECT [domeniu] lista_selecţie FROM nume_tabela1. SQL a fost utilizat pe scară largă şi pană în prezent au fost dezvoltate şapte versiuni ale standardului SQL. 65 .are ce efect eliminarea înregistrărilor care conţin duplicate în câmpurile selectate.2 SQL M3. Domeniu: . celelalte fiind concepute de firme de prestigiu ca IBM.2. M3. Introducere SQL (Structured Query Language). prin care se r egăsesc şi se afişeaza informaţiile dorite de utilizator.2.Determină stabilirea modalităţii de manipulare a înregistrărilor din baza de date asupra căreia se efectuează selecţia şi poate fi: ALL . Cereri de interogare simple Instructiunile de regăsire reprezintă una din categoriile cele mei importante ale limbajului de interogare SQL. Primul standard SQL a fost creat in anul 1989 de cãtre ANSI fiind cunoscut sub numele de ANSI-SQL'89 şi a fost revizuit in octombrie 1992 sub noua denumire: ANSI-SQL'92. nu numai pe cele care au câmpuri duplicate. Microsoft şi Borland sau de cãtre consorţii ca SAG (The SQL Access Group) şi X/Open. punctul de plecare al interogărilor îl constituie fraza SELECT. Este folosit foarte rar deoarece este implicit. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  Exprime cereri în SQL  exprime actualizări ale bazei de date Durata medie de parcurgere a primei unităţi de învăţare este de 4 ore. ca un limbaj standard de descriere a datelor şi de acces la informţtiile din bazele de date.Unitatea de învăţare 3. DISTINCTROW . Indiferent dacă sunt simple sau complexe.U3. DISTINCT . pentru produsul dBASE. Limbaj de interogare a bazelor de date relaţionale.nume_tabela2… [WHERE criteriu_de_selecţie} ORDER BY câmpuri_criteriu [ASC/DESC]].permite includerea tuturor inregistrărilor ce indeplinesc condiţiile impuse.are în vedere înregistrările duplicate în ansamblul lor. astfel se va afişa doar o apariţie a datei multiple ( ceea ce este în concordanţă cu algebra relaţională). trei dintre ele aparţinînd Institutului National American de Standarde (ANSI).U3.

Componenta BY a clauzei nu poate să lipsească atunci când se doreşte sotrarea rezultatelor interogării SQL. Cod_caseta. Scara. Pentru a putea da exemple concrete ne vom referi la baza de date: centrul de închiriere casete video. Cod_actor) Imprumuturi (Cod_imprumut.Lista_selecţie Cuprinde toate câmpurile care vor aparea în tabela cu rezultatele interogării. Disponibila) Filme ( Cod_film. Clauza ORDER BY Utilizată atunci când se doreşte ca rezultatele interogării să fie ordonate în mod crescător (ASC) sau descrescător (DESC).Pret. Exemple Să se afişeze oraşele de reşedinţă ale tuturor clienţilor SELECT Oraş FROM Clienţi 66 . SELECT * FROM Clienţi . Prenume. Clauzele SQL SELECT. Titlu. Nr_BI. iar în algebra relaţională acelaşi termen desemnează selecţia după un predicat de selecţie. Telefon) Casete (Cod_caseta. Cod_client. Cod_film. Bloc. Clauza FROM menţionează o listă de relaţii (tabele) şi corespunde produsului cartezian din algebra relaţională. Cod_imprumut. An_aparitie. Gen) Casete-Filme (Cod_casetafilm. În SQL. Rezultatul unei interogări SQL este întotdeauna o relaţie (o tabelă). Atenţie! }n list[ vor ap[rea numai aatribute ale tabelelor din clauya FROM. după cum urmează: Clauza SELECT menţionează o listă de atribute şi corespunde proiecţiei din algebra relaţională. Nr. Restituita) Exemple Să se afişeze toate datele despre toţi clienţii. Seria_BI. Clauza WRERE descrie un predicat de selecţie şi corespunde selecţiei din algebra relaţională. Înţelesul diferit al termenului “select” utilizat în SQL şi în algebra relaţională este un fapt istoric nefericit. Cod_caseta. Stare) Plati (Cod_plata. Data . Avem următoarele tabele: Clienti (Cod_client . Cod_film) Actori (Cod_actor. Sex) Filme_Actori (Cod_filmactor. Lista de atribuire care apare în clauza SELECT din SQL poate fi înlocuită cu simbolul * dacă se doreşte selectarea tuturor atributelor care apar în relaţiile din clauza FROM. Oras. Data_imprumut. Nume. Tara. Apartament. Suma) Casete imprumutate (Cod_imprcaseta. Cod_imprumut.Nume. FROM şi WRERE pot fi puse în corespondenţă cu operatorii din algebra relaţională. Data_ nasterii. Sortarea este opţională şi se poate realiza dupa unul sau mai multe câmpuri_criteriu (definite drept chei de sortare). Strada.Să se afişeze toate datele despre toţi actorii. ”select” desemnează proiecţia.

dar în ordine descendentă. dar să apară fiecare ora ş o singură dată în tabela-rezultat. Exemple Să se afişeze oraşele de reşedinţă ale clienţilor. ordinea tuplelor ar fi fost aceeaşi deoarece ordinea ascendentă este implicită. SELECT DISTINCT Oraş FROM Clienti Să se afişeze toate genurile distincte ale filmelor.ASC A se observa că dacă ar fi lipsit menţiunea ASC. Funcţii standard sunt: valoarea medie – AVG valoarea minima – MIN valoarea maxima –MAX total (sumare) – SUM numaratoare – COUNT Nu este permisă utilizarea acestor funcţii în clauza WHERE deoarece ele acţionează la nivel de atribut şi nu la nivel tuplu. care apar în clauza SELECT şi se aplică atributelor din tabelele implicate în interogare. Se va observa că se repetă numele oraşelor. deoarece se vor afişa oraşele pentru fiecare client în parte din tabela clienţi. Ca rezultat al acestei interogări se va obţine o tabelă cu o singură coloană. Ce puteţi spune despre numărul genurilor faţă de numărul genurilor. care conţine numele oraşelor de reşedinţă ale clienţilor.Să se afişeze toate genurile filmelor. Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a titlurilor filmelor SELECT * FROM Filme ORDER BY Titlu.ASC Afişaţi. Exemple Să se afişeze datele despre filmele din baza de date în ordinea alfabetică a titlurilor filmelor SELECT * FROM Filme ORDER BY Titlu. Exemple Care este suma minimă plătită? SELECT MIN (suma) 67 . cunoscute şi sub numele de funcţii standard sau funcţii agregat. În scrierea interogărilor de selecţie simple SQL se pot folosi şi funcţii totalizatoare. ca mai sus.

asocierile (JOIN) sau combinările (UNION).Care este suma maximă plătită? Exemple Care este preţul mediu al casetelor? SELECT AVG(Pret) FROM Casete Care este suma medie încasată. Funcţiile de grup(agregat) 68 . cum ar fi cele în care regăsim funcţiile agregate. crearea unor interogări cu o structura complexă. 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.FROM plati . Exemple Cate tulpe conţine tabela de casete? SELECT COUNT (*) FROM Casete Câte tupe conţine tabela clienti. pe lângă definirea de interogări de selecţie simple. Exemple Care este suma totală plătită pentru împrumutul cu cod ’30’? SELECT SUM (suma) FROM plati WHWRE Cod_imprumut=’30’ Care este valoarea totală a casetelor.

prin care utilizatorul poate să efectueze diverse calcule pentru grupuri de înregistrări care au câmpuri cu aceeasi valoare. cum ar fi obţinerea de totaluri şi subtotaluri.COUNT(*) 69 . AS alias Asociază un pseudonim (nume) rezultatului utilizării funcţiei agregat Clauza GROUP BY şi HAVING În unele cazuri. nume_tabela2… GROUP BY câmp_de_grupare [HAVING criteriu_de_grupare] [ORDER BY câmpuri_criteriu [ASC/DESC]]. singurele elemente obligatorii într-o interogare SQL sunt clauzele SELECT cu lista de atribute ce vor fi extrase şi clauza FROM cu relaţiile din care fac parte atributele. Pentru aceste operaţii. şi generează un tuplu pentru fiecare grup de tuple cu aceeaşi valoare pe atribut Atributele care apar în clauza SELECT pot fi de două feluri: -atribute care alcătuiesc baza pentru grupare (cele care apar în clauza GROUP BY).lista_selecţie] F ROM nume_tabela1. În cazul utilizării lor se foloseşte următoarea formă a frazei SELECT: SELECT [domeniu] [funcţie agregată (nume_câmp) AS alias [. Aşadar o interogare SQL trebuie să conţină cel puţin următoarele informaţii: SELECT <lista de atribute> FROM <lista de relatii> restul clauzelor sunt opţionale. Lista selecţie Se va referi la una sau mai multe funcţii agregate care au ca argumente nume de câmpuri ale bazei de date. Din câte ţări avem filme. limbajul SQL permite utilizarea clauzelor GROUP BY şi HAVING. -atribute care nu participa la gruparea rezultatelor. în special prin aplicarea funcţiilor agregat.Funcţiile de grup agregat permit construirea unor interogări SQL complexe. Exemple Câţi clienţi au sediul în fiecare oras? SELECT Oras. 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ă. utilizatorul doreşte anumite situatii sintetice. Aceste clauze organizează tuplele în grupuri asupra cărora se pot realiza anumite operaţii. Dupa cum se observă. Există restricţia ca aceste câmpuri sa fie întotdeauna de tip num eric. Clauza GROUP BY grupeaza tuplele din relaţie după atributele cu aceeaşi valoare care sunt specificate în clauză.

COUNT(*) FROM Clienti GROUP BY Oras HAVING COUNT(*)>=3 Clauza GROUP BY se poate folosi şi cu ORDER BY şi WHERE. este utilă atribuirea unor prescurtări. 70 . Clauza FROM are forma generală: FROM <<nume relatie>/<nume view>[alias]…> şi specifică relaţiile (pot fi şi nume view) din care vor fi regăsite datele. Din ce ţări avem cel puţin 2 filme. SELECT Oras FROM Clienti GROUP BY Oras ORDER BY Oras Să se afişeze în ordine alfabetică ţările din care avem filme. numele clienţilor.FROM Client GROUP BY Oras Câte filme sunt din fieare ţară. În cazul în care se operează cu mai multe tabele. (numite alias) ale numelor de tabele ce vor fi utilizate în interogare. Exemple Să se afişeze în ordine alfabetică oraşele în care există clienţi ai centrului. Exemple Care sunt clienţii 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 făcute după data 01/01/2009 . Exemple În care case locuiesc cel puţin 3 clienţi? SELECT Oras. codul împrumutului şi data împrumutului pentru clienţii care au cel puţin un împrumut. Exemple Să se afişeze codurile casetelor.

constante. Operatori relaţionali < mai mic > mai mare ! negarea operatorilor <. se specifică o condiţie de cautare prin utilizarea unui predicat de selecţie în clauza WHERE. În schimb s-a utilizat notaţia pentru a deosebi atributul Cod_client din tabela Clienti de atributul cu acelaşi nume din tabela Imprumuturi. se pot utiliza atribute.>.Cod_client=B. Clauza WHERE are forma generala: WHERE <predicat> / <expresie>. Se obţin operatorii: != (diferit).ALL. Pentru a restrânge tuplele ce apar în tabela-rezultat.funcţii sau expresii algebrice.Cod_imprumut=C.=. Ca operanzi.EXISTS. SELECT Cod_film<Titlu FROM Filme WHERE Gen=”actiune” 71 . Operatori aritmetici Ace.ANY Sub-interogări(exprimate prin interogări SQL)cu observatia ca acestea vor fi primele evaluate şi tabela-rezultat trebuie sa corespunda operatorilor ce i se aplica în continuare. [Nume] &””& [Prenume] AS Numele.SELECTC Cod_caseta. Cod_imprumut A se observa că nu s-a mai utilizat notaţia cu alias pentru atributele Nume şi Prenume din tabela Clienti deoarece nu este pericol de confuzie.ti operatori sunt binecunoscuţi şi menţionăm aici doar faptul ca şi ^ si ** reprezint[ ridicarea la putere. Numai tuplele care satisfac predicatul de selecţie vor fi incluse în tabela-rezultat.Cod_client AND B.!> (nu mai mare). Predicatul de cautare poate fi specificat printr-o condiţie logica în care se utilizeaza urmatoarele elemente: Operatori: -aritmetici:+ .). B.Data_imprumut FROM Clienti A. Exemple Sa se afişeze codurile şi titlurile filmelor de gen acţiune./ * ** ^ -relaţionali: < > <= >= <> != = -logici:NOT AND OR -operatori SQL:IN. <= mai mic sau egal => mai mare sau egal <> diferit Facem observaţia că valorile comparate trebuie să aparţină unor tipuri de date compatbile (care se pot compara între ele. Expresiile algebrice pot aparea în clauzele SELECT sau WHERE. [casete imprumutate] C WHERE A. Cod_imprumut.!< (nu mai mic). Imprumuturi B. Să se afişeze actorii care joacă cel puţin într-un film.

SELECT * FROM Clienti WHERE Oras IN (“Rasnov”.Titlu FROM Filme WHERE Tara=”SUA”AND An_aparitie>2000 Să se afişeze plăţile mai mari de 100 lei făcut în anul 2009. Predicatul IN testează dacă valoarea unui atribut specficat în lista de atribute din clauza WHERE se potriveşte uneia din valorile listei specificate în predicatul IN (testeaza apartenenţa la o mulţime). SELECT Cod_film .Să se afişeze filmele din Romania.Titlu FROM Filme WHERE Tara=”SUA”OR NOT An_aparitie<=2000 Operatorul IN permite simplificarea predicatului de căutare. Tipul de operator logic este dat de precedenţa operatorilor. evaluarea se va face de la stânga la dreapta. Operatorul NOT are cea mai mare prioritate.Titlu FROM Filme WHERE Tara=”SUA”OR An_aparitie>2000 A se observa că ultima interogare este echivalentă cu interogarea : SELECT Cod_film . Exemple Sa se afişeze codul şi titlul filmelor din SUA sau care au anul apariţiei mai mare decât 2000. Pentru a schimba ordinea de evaluare a unei expresii se utilizează parantezele rotunde (). urmat de OR şi AND care practic sunt de priorităţi egale. Exemple Să se afişeze toate datele despre clienţii care au sediul în Râşnov sau în Braşov. SELECT Cod_film.”Brasov”) 72 . Operatori logici Dacă o clauza WHERE conţine mai multe condiţii formate prin utilizarea aceluiaşi tip de operator logic. Exemple Sa se afişeze codul şi titlul filmelor din SUA care au anul apariţiei mai mare decât 2000.

Cod_client=b. Acest din urmă tip de joncţiune este în general foarte rar de utilizat. face apel în clauza WHERE la oricare operator de comparare în afară de semnul (“=”).nume_tabela 2… WHERE criteriul_de_asociere] [ORDER BY câmpuri_criteriu[ASC?DESC]. presupune folosirea clauzei WHERE (pentru selecţia înregistrărilor) asociată cu o egalitate dorită. Exemple Sa se afişeze numele clientilor şi codurile imprumuturilor pentru imprumuturile neterminate. SELECT p1.Titlu. Deoarece în instrucţiunile SQL care descriu joncţiunea se utilizeaza câmpuri ce fac parte din tabele diferite. Asocierile (interogările JOIN) Una dintre operaţiile cele mai frecvente realizate cu mai multe tabele este joncţiunea sau produsul cartezian. SELECT[Nume]&””&[Prenume] AS Numele.Cod_imprumut FROM Clienti 1.p2. intersectia şi diferenţa. Sintaxa interogării SQL diferă de la un SGBD la altul dar sub o formă directă sau printr-o construcţie sintactică specifică se pot realiza oricare dintre operaţiile amintite. în două moduri.Gen. cu rol în ilustrarea elementelor specifce proprietăţilor combinatorii ale tuturor asocierilor. spre deosebire de precedenta.Gen FROM Filme p1.b.Titlu=”Titanic” 73 . NEECHIVALENTA (non echijoncţiune) . toate datele despre clienţii care au sediul în Râşnov sau în Braşov sau în B ucuresti.Titlu.mai puţin utilizată. Forma generala de descriere a unui câmp va fi urmatoarea:nume_tabela. Putem distinge mai multe categorii de joncţiuni:CROSS (încrucişată) . Joncţiunea aminteşte de operaţiile din algebra relaţională şi chiar e ste posibil de realizat (urmând anumite structuri ale interogării SQL) oricare dintre tipurile de joncţiune prezentate teoretic în cadrul algebrei relaţionale.care.Filme p2 WHERE p1. Se pot de asemenea realiza operaţii ca reuniunea.Gen AND p2.Gen=p2.Cod_client AND Stare=Yes Sa se afişeze filmele şi casetele pe care se găsesc.p2. Sintaxa generală pentru joncţiunile echivalente şi neechivalente este următoarea: SELECT [domeniu] lista_selecţie FROM nume_tabela1. Exemple Care filme au acelasi gen cu filmul “Titanic”? A se observa că această interogare necesită realizarea produsului cartezian al tabelei cu ea însăşi. este necesara întotdeauna spacificarea tabelei la care apartin.Imprumuturi b WHERE 1.nume_câmp.Să se afişeze. Se pot folosi şi alias-uri. ECHIVALENTĂ (echijoncţiunea)-cea mai folosită.p1.

este obligatoriu ca acestea să fie daschise de scheme de relatie identică (acelaşi număr de atribute şi corespunzator – de la stanga la dreapta – atributele din tabele au aceleasi nume şi aceeaşi descriere). astfel încat sa rezulte un numar total de înregistrări din fiecare tabela.Cod_film WHERE (((Casete.Casete. Procedaţi ca mai sus. Expresia criteriul_de asociere conţine un operator de comparaţie de tip egalitate (=) şi va returna valorile logice TRUE sau FALSE Exemple Sa se afişeze codul casetelor.Titlu.nume_tabela3…) tabelei preciată în clauza FROM ON criteriu_de_asociere – arată relaţia dintre câmpurile pe care se bazează joncţiunea. Operaţiile reuniune. Sa se afişeze filmele şi casetele pe care se găsesc. iar celălalt există într-o altă tabelă din lista cu numele tabelelor. intersecţie şi diferenţă de tabele acţionează analog cu aceleaşi operaţii aplicate în mulţimi. pentru casetele care sunt disponibile. SELECT Casete. sunt de doua tipuri: de stanga (LEFT OUTER JOIN) şi de dreapta (RIGHT OUTER JOIN) fiind destul de puţin utilizate. Primele determină o asociere a înregistrărilor din tabele. În cazul când dorim să reunim două sau mai multe tabele.Filme. JOIN – specifică tabela care va fi asociată (nume_tabela2.O altă abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe (OUTER JOIN).Cod_caseta)ON Filme. Aceste condiţii sunt impuse tabelelor implicate în operaţiile intersecţie şi minus (diferenţă).Cod_caseta.Cod_film=[CaseteFiml]. Joncţiunile externe. preţul şi filmele de pe casete. la randul lor.Pret FROM Filme INNER JOIN (Casete INNER JOIN [Casete-Filme] ON Casete. Forma generală a reuniunii de tabele este: 74 . În acest mod de abordare al joncţiunulor sintaxa va avea forma: SELECT [domeniu] lista_selecţie 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_selecţie] [ORDER BY câmpuri_criteriu {ASC/DESC]]: De remarcat faptul ca SQL acceptă scrierea interogărilor externe fără specificarea explicită a lui OUTER.Cod_caseta=[Casete-Filme]. Combinările (interogările UNION) Clauza UNION permite realizarea reuniunii de tabele. Unul se află în tabela asociată.disponibile)=Yes)).

Strada. În acest sens.Scara. Forma generală a unei astfel de construcţii este: SELECT <lista atributelor> FROM <lista relatii1> WHERE <subinterogare> Se observă că această construcţie a fost deja utilizată în exemplul de mai sus care ilustrează o clauză UNiON. Strada.Am FROM… [WHERE…] Exemple Să se afişeze numele clienţilor care sunt fie din Râşnov fie din Braşov şi adresa lor.Am FROM [WHERE…] UNION SELECT A1. Clauza SELECT exterioară generează o relaţie pa baza valorilor generate de către clauza interioară.Clienti.Clienti.Clienti. SELECT [Nume]&””&[Prenume]AS Nume.…. Modul de construire a interogării exterioare depinde de numărul valorilor returnate de către interogarea interioară.Apartament. Interogarea interioară este evaluată reletat pentru fiecare tuplu cercetat de interogarea exterioara.Telefon FROM Clienti WHERE Oras=”Brasov”).Bloc.Oras. Clienti. formate din mai multe subinterogări simple.Nr.Clienti.Apartament. Aceste interogări complexe sunt construite prin includerea în clauza WHERE a încă unei clauze SELECT.  Subinterogări corelate Valorile returnate de catre interogarea interioară depind de valorile returnate de catre interogarea exterioară. Cereri de interogare imbricate (subinterogări) Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare este acela că oferă posibilitatea construirii interogărilor complexe.Clienti. 75 . putem distinge:  subinterogări care returnează o singură valoare. Din punctul de vedere al ordinii de evaluare al interogărilor putem distinge:  Subinterogări simple Interogarea interioara este evaluata prima.Clienti. Clienti.  subinterogări care returnează mai multe valori.Oras.SELECT A1. Clienti.Clienti.…. În construcţia de mai sus clauza SELECT interioară generează valorile pentru condiţia de căutare a clauzei SELECT exterioare care o conţine.Telefon FROM Clienti WHERE Oras=”Rasnov” UNION (SELECT [Nume] &””&[Prenume] AS Numele.Clienti. Rezultatul evaluarii interogării interioare este utilizat de catre nterogarea exterioara. independent de interogarea exterioara.

Pret.Cod_caseta. Rezultatul evaluării interogării interioare devine condiţie de căutare pentru interogarea exterioară.Subinterogări simple care returneaza o singura valoare Aceste interogări au urmatoarea sintaxă: SELECT <lista atribute> FROM <lista relatii> WHERE <atribut> 0 (<subinterogare>) unde 0 este un operator relaţional: =. pretul şi titlurile filmelor. Exemple Sa se afişeze codul casetelor.(NOT) EXISTS. Valoarea obţinută pentru atributul Cod_client este stocata într-o tebelă temporară. Să se afişeze filmele din casetele. Condiţia de evaluare a interogării interioare este [Nume] & “ ” & [Prenume]=’Ciurar Cristina’.Cod_client)=6 În urma executării interogării exterioare este creată o relaţie finală.Cod_film WHERE Pret=(SELECT MAX(Pret) FROM Casete).Cod_caseta=[Casete-Filme].Cod_film=[Casete-ilme].Cod_client)=SELECT Clienti. Suinterogări simple care returnează mai multe valori.Filme.(NOT) AND. (NOT) ANY.AND. Principiul de construire a acestui tip de interogare imbricate utilizează în clauza WHERE condiţii.< > >= <= != Exemple Sa se afişeze numarul împrumuturilor neîncheiate pentru clienta Ciurar Cristina.Casete. care evaluate. Interogarea interioară poate conţine în clauza WHERE şi condiţii complexe. 76 . ce va contine tuplele ale căror Cod_client este acelaşi cu valoarea stocată în tabela temporară.…). Procesul de evaluare a acestei interogări se desfasoară astfel: Se evalueaza în primul rînd interogarea interioară. SELECT Count(Cod_imprumut) AS [Nr de imprumuturi] FROM Imprumuturi WHERE (((Imprumuturi. OR) şi a funcţiilor agregat (AVG.Cod_client FROM Clienti WHERE [Nume] & “ “ & [Prenume]=’Ciurar Cristina’))). cu preţ minim.Cod_caseta) ON Filme.MAX. generează o mulţime de valori. împrumutate şi nerestiruite. Sa se afişeze casetelew care au filme din USA. care ar putea fi exprimată în această fază ca: SELECT Count(Cod_imprumut) AS [Nr de imprumuturi] FROM Imprumuturi WHERE (Imprumuturi. SELECT Casete. În această categorie intră operatorii (NOT) IN.Titlu FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON Casete. pentru casetele care au un pret maxim. formate prin utilizarea operatorilor logici (NOT.

trebuie asigurate alias-uri pentru fiecare referinţa la tabelul respectiv. după care valoarea. De fiecare dată când este transmisă o valoare.data.Cod_imprumut =[ casete imprumutate] cod_imprumut WHERE restituit=NO). A se observa ce cele două interogări diferă doar prin operatorul logic NOT. sau valorile.Exemple Care sunt clienţii care mai au de restituit casete. data imprumutului. caz în care interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară. Imprumuturi. se poate construi aceasta operaţie cu ajutorul predicatului NOT IN ca în exemplul de mai sus. SELECT Imprumuturi. Exista şi o altă forma de subinterogare şi anume Subinterogarea corelată. este evaluată interogarea interioară.Data_ imprumut. rezultate erau utilizate de către clauza WHERE din interogarea exterioară. interogarea interioară era evaluată prima. data unei plaţi şi suma plătită.plati. Dacă ambele interogări acceseaza acelaşi table. ordonate după data împrumutului. pentru sumele maxime care s-au plătit. SELECT [Nume]&””&[Prenume]AS Numele FROM Clienti WHERE Cod_client IN (SELECT Cod_client FROM Imprumuturi INNER JOIN [casete imprumutate] ON Imprumuturi. Ambele interogări accesează tuple diferite din acelaşi table în acelaşi moment.Cod_imprumut =[ casete imprumutate] cod_imprumut WHERE restituit=NO). Dacă versiunea SQL nu are un cuvânt rezervat pentru operaţia diferenţa inter tabele.Cod_imprumut. Subinterogări corelate În exemplele de până acum. plati. SELECT [Nume]&””&[Prenume]AS Numele FROM Clienti WHERE Cod_client NOT IN (SELECT Cod_client FROM Imprumuturi INNER JOIN [casete imprumutate] ON Imprumuturi. De asemenea se poate remarca faptul că prima interogare aminteşte de apartenenţa din teoria mulţimilor iar a doua interogare corespunde operaţiei minus (diferenţa). Exemple Sa se afişeze codurile imprumuturilor.Cod 77 .suma FROM Imprumuturi INNER JOIN plati ON Imprumuturi. Exemple Care clienţi nu mai au nimic de restituit. Care sunt actorii care joacă în casetele împrumutate.

6.Cod_ Imprumut=plati.2. mai mare. etc. decât oricare dintre valorile menţionate o dată cu operatorul.4) Să observăm că dacă înlocuim operatorul ANY cu expresia verbală oricare putem citi “Valorile lui x trebuie să fie mai mici decât oricare dintre valorile din paranteza ce urmeaza dupa ALL”.… 4.-1. mai mici sau egale.Data_ Imprumut.2. ect._imprumut=plati. ceea ce ar corespunde cazului banal în care toate valorile din listă sunt identice.3. Pentru a stabili mai exact modul în care se selectează valorile cu operatorii ANY şi ALL dăm mai jos o serie de cazuri concrete. mai mică.-1.0.6.5. Să facem observaţia că acest operator nu poate fi utilizat cu operatorul relaţional =. Restricţionare subinterogărilor Operatorii ANY şi ALL Operatorul ANY poate fi utilizat în cobinaţie cu oricare dintre operatorii relaţionali (= < > <= >= !=) pentru a se varifica dacă valorile unui atribut este egală.… 78 .. 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. decât toate valorile generate de interogarea interioară. mai mari.7.cod_ Imprumut) ORDER BY Imprumuturi.… 5. Să presupunem ca interogarea este de forma: SELECT… FROM … WHERE x <ALL (1.3.4) Să observăm că dacă înlocuim operatorul ALL cu expresia verbală toate putem citi “Valorile lui x trebuie să fie mai mici decât toate valorile din paranteza ce urmeaza după ALL”.-2. Atunci vom lua în considerare urmatoarele situaţii: Expresia din clauza WHERE X<ALL X<=ALL X>ALL X>=ALL Daca vom studia o interogare de forma: SELECT… FROM … WHERE x <ANY (1.-2.… 1.cod_imprumut WHERE suma= (SELECT MAX(suma) FROM plati WHERE Imprumuturi. Valori ale lui x care corespund 0.

Cod_caseta) ON Filme. anul aparitiei şi genul pentru filmele care au un an de apariţie mai mare sau egal cu anul maxim de apariţie al filmelor de gen fabula.Filme.titlu FROM Filme INNER JOIN (Casete INNER JOIN[Casete-Filme] ON Casete.3.-2. operatorul EXISTS apare în clauza WHERE.Filme. care au anul apariţiei maxim.) Ca şi operatorii ANY şi ALL.-1.6.… 4.… 1. anul apariţiei şi genul.0.6.3. operatorul EXISTS permite specificarea mai multor attribute în interogarea interioară. Exemple Să se afişeze titlui filmelor.disponibil.Cod_film= [CaseteFilme].Cod_caseta=[ Casete-Filme].Titlu.-2. EXISTS ia valoarea de adevar TRUE.… 2.2. ci se generează o valoare de adevar ( TRUE sau FALSE).2. după cum există sau nu există o anumită valoare într-o relaţie diferită de cea utilizată în interogarea exterioară. preţul.Casete.Filme. pentru filmele din SUA.4.An_aparitie. din care le excludem pe cele de preţ maxim.… Exemple Exemple: Să se afişeze titlul filmelor. În cazul în care există asemenea tuple.1.Gen FROM Filme WHERE An_aparitie<ALL (SELECT An_aparitie FROM Filme WHERE Tara=’SUA’).Pret.2. SELECT Casete.5. titlurile filmelor pentru Casetele disponibile. 79 . Operatorul EXISTS Operatorul EXISTS verifică dacă pentru fiecare tuplu al relaţiei există tuple care satisfac condiţia interogării interioare.Casete.7.0.-1.Cod_caseta.1. Acest lucru este posibil deoarece nu se verifică valoarea unui atribut.4. ca în cazurile anterioare. Exemple Să se afişeza codul casetelor.5.Cod_film WHERE disponibil=Yes AND Pret<ANY (SELECT Pret FROM Casete WHERE disponibil=YES). Astfel.3. SELECT Filme.Vom lua în considerare următorul table: Expresia din clauza WHERE X<ANY X<=ANY X>ANY X>=ANY Valori ale lui x care corespund 3.

Gen FROM Filme f WHERE NOT EXISTS (SELECT * FROM Filme WHERE Gen=’fabula’ AND An_aparitie>f. Bucuresti’.1945’) Inseraţi o nouă înregistrare în tabela casete. SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru actualizarea bazelor de date. ‘Alex’. Actualizări ale bazei de date. ‘George Enescu 37.’director economic’. Exemple  .SELECT Titlu.An_aparitie. să aibă aceaşi ordine de declarare şi să fie compatibile ca tip. ‘Ionescu’. iar a doua adăugarea mai multor linii. Declaraţiile SQL aferente actualizării unei baze de date se referă la modificările unei tabele (adăugare sau ştergere de linii.’m’. Adăugarea 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.07. lista_atribute reprezintă o listă de una sau mai multe nume ale coloanelor tabelei separate prin virgulă. Numărul de elemente din cele două liste trebuie să coincidă. 80 .4. În cazul în care sp ecificăm această listă atributele pe care dorim să le omitem trebuie să le declarăm ca NULL. modificarea datelor dintr-o tabelă): Adăugarea se face cu declaraţia INSERT care are două forme prima accepta adăugarea unei singure linii. Comenzile pentru actualizări nu sunt atât de complexe ca declaraţia SELECT. ‘021 456-12456’. Exemple Exemplu: Inseraţi o nouă înregistrare în tabela Conducere completând datele pentru toate atributele: INSERT INTO Conducere VALUES (‘cd16’. date ’01. Interogarea SELECT interioară defineşte o tabelă care conţine tuple pentru care se verifică condiţia din clauza WHERE internă. I. Dacă această listă nu este specificată SQL consideră toate atributele tabelei în ordinea în care au fost create în tabela originală. ap.An_aparitie).

id. 0 FORM Conducere WHERE id NOT IN (SELECT DISTINCT id FROM PropServicii)) Modificarea se face cu declaraţia UPDATE care permite modificarea datelor unor înregistrări existente într-o tabelă dată.’asisent manager’. NULL.nume_atribut2=valoare2 …. trebuie să fie compatibile cu cele ale atributelor corespunzătoare.NULL. WHERE este o clauză opţională. prin omiterea ei se consideră că toate că toate înregistrările for fi modificate pentru atributele alese la clauza SET. Adăugarea mai multor linii prin copierea lor dintr-o tabelă sau mai multe tabele într-o altă tabelă INSERT INTO nume_tabela [(lista_atribute)] SELECT … Nume_tabela şi lista de atribute sunt definite la fel ca la cazul anterior. 81 . Prenume.id. prenume) UNION (SELECT id. Functie INSERT INTO Conducere VALUES (‘cd44’. Sintaxa acestei comenzi este: UPDATE nume_tabela SET nume_atribut1=valoare1[. ‘Maria’. ‘Aduducai’. nume. prenume. nume.] [WHERE conditie_cautare] Clauza SET specifică numele unui atribut sau a mai multor atribute care urmează a fi modificate.…. Exemple Inseraţi o nouă înregistrare în tabela Conducere completând datele doar pentru atributele obligatorii cod.id=p. Tipul datelor valoare1. Nume. iar dacă ea este specificată atunci doar acele înregistrări care îndeplinesc condiţiile de căutare. PropServicii p WHERE s. prenume.id GROUP BY s. COUNT(*) FORM Conducere s. NULL.II. NULL) Exemplu: Exemple Presupunând că în tabela ContConducere conţine numele celor din conducere şi numărul serviciilor pe care le au în subordine populaţi tabela ContConducere folosind detalii din tabelele Conducere şi PorpServicii o nouă înregistrare în tabela Conducere completând datele pentru toate atributele: INSERT INTO ContConducere (SELECT s. nume. iar clauza SELECT poate fi orice declaraţie validă.

2.000 WHERE id=’cd73’ Ştergerea se face cu declaraţia DELETE . Exemple 1. Ştergerea înregistrărilor din tabela casete cu preţ minim. Ştergerea tuturor înregistrărilor din tabela vedere (view) DELETE FROM viewing. salariu = 18.Exemple Modificarea tuturor înregistrărilor pentru mărirea salariior tuturor celor din conducere cu 3%. 2. WHERE id = ‘cd72’ Ştergerea tuturor înregistrărilor din tabela casete.03 Modificarea preţului la casetele cu preţul maxim prin reducere cu 10%.05 WHERE functie=’manager’ Modificarea înregistrărilor pentru mai multe atribute UPDATE CONDUCERE SET functie=’manager’.000. pentru a şterge un tabel folosim declaraţia DROP TABLE. 82 . UPDATE CONDUCERE SET salariu = salariu*1. sintaxa acestei comenzi este: DELETE FROM nume_tabela WHERE conditie_cautare Dacă opţiunea WHERE lipseşte atunci se şterg toate înregistrările darn nu şi tabelul. Modificarea doar a unor înregistrări specificate UPDATE CONDUCERE SET salariu = salariu*1. Ştergerea anumitor înregistrări din tabela vedere (view) DELETE FROM viewing. Se poate şterge un tabel numai dacă nu mai are înregistrări.

prin care utilizatorul poate sǎ efectueze diverse calcule pentru grupuri de înregistrǎri care au câmpuri cu aceeasi valoare. astfel încat sa rezulte un numar total de înregistrǎri din fiecare tabela. Joncţiunile externe. formate din mai multe subinterogǎri simple. Primele determinǎ o asociere a înregistrǎrilor din tabele. O altǎ abordare priveşte joncţiunile ca fiind: interne (INNER JOIN) şi externe (OUTER JOIN). Funcţiile de grup agregat permit construirea unor interogǎri SQL complexe. n ume_tabela2… GROUP BY câmp_de_grupare [HAVING criteriu_de_grupare] [ORDER BY câmpuri_criteriu [ASC/DESC]].2. Rezumat Pentru definirea interogǎrilor de selecţie simple se utilizeazǎ urmǎtoarea sintaxǎ a instrucţiunii SELECT: SELECT[domeniu]lista_selecţie FROMnume_tabela1. la randul lor. 83 . Adǎugarea se face cu declaraţia INSERT care are douǎ forme prima accepta adǎugarea unei singure linii. iar a doua adǎugarea mai multor linii.nume_tabela2… [WHERE criteriu_de_selecţie} ORDER BY câmpuri_criteriu [ASC/DESC]]. În acest mod de abordare al joncţiunulor sintaxa va avea forma: SELECT [domeniu] lista_selecţie 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_selecţie] [ORDER BY câmpuri_criteriu {ASC/DESC]]: Unul din motivele pentru care SQL este considerat un limbaj puternic de interogare este acela cǎ oferǎ posibilitatea construirii interogǎrilor complexe.nume_tabela 2… WHERE criteriul_de_asociere] [ORDER BY câmpuri_criteriu[ASC?DESC]. În cazul utilizǎrii lor se foloseşte urmǎtoarea formǎ a frazei SELECT: SELECT [domeniu] [funcţie agregatǎ (nume_câmp) AS alias [. sunt de doua tipuri: de stanga (LEFT OUTER JOIN) şi de dreapta (RIGHT OUTER JOIN) fiind destul de puţin utilizate. Sintaxa generalǎ pentru joncţiuni este urmǎtoarea: SELECT [domeniu] lista_selecţie FROM nume_tabela1.lista_selecţie] FROM nume_tabela1.U3. Aceste interogǎri complexe sunt construite prin includerea în clauza WHERE a încǎ unei clauze SELECT.M3. Forma generalǎ a unei astfel de construcţii este: SELECT <lista atributelor> FROM <lista relatii1> WHERE <subinterogare> SQL poate fi folosit atât pentru interogarea bazei de date cât şi pentru actualizarea bazelor de date. Comenzile pentru actualizǎri nu sunt atât de complexe ca declaraţia SELECT.

În cazul în care specificǎm aceastǎ listǎ atributele pe care dorim sǎ le omitem trebuie sǎ le declarǎm ca NULL.Scara. Lift) -Apartamente(Nr_bloc. Numǎrul de elemente din cele douǎ liste trebuie sǎ coincidǎ. Sintaxa acestei comenzi este: UPDATE nume_tabela SET nume_atribut1=valoare1[. Nr_bloc.2. Adǎugarea 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.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1 3. Apartament.2.Familii (Nr_mat.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3 3.4 tabel nominal cu locatarii de pe scările 1.3 ale blocului 34 3. Nr_prize_tv) . Modificarea se face cu declaraţia UPDATE care permite modificarea datelor unor înregistrǎri existente într-o tabelǎ datǎ.nume_atribut2=valoare2 ….Suprafaţa.2.2. Scara. Nr_pers. 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ǎ.I.2.Nume Să se exprime în SQL cererile: 3.] [WHERE conditie_cautare] Ştergerea se face cu declaraţia DELETE .2.2. sintaxa acestei comenzi este: DELETE FROM nume_tabela WHERE conditie_cautare M3.Cutii_poştale.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi pe scara 1 a aceluiaşi bloc Răspunsurile se găsesc la sfârşit la pag 154 84 . Scara.2.U3. Test de autoevaluare a cunoştinţelor Se dau următoarele relaţii cu schemele lor: -Scări (Nr_bloc. Nr_pers_prez.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp 3.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2 3. Nr_chei) -Locatari Nr_Mat. sǎ aibǎ aceaşi ordine de declarare şi sǎ fie compatibile ca tip.Apartament. Etaj.

este realizarea unei reprezentari corecte a datelor. Obiectivele modulului La sfârşitul acestui modul studenţii vor fi capabili să:  descopere dependenţele funcţionale între atribute. descopere anomaliile din descrierea unei baze de date aducă o bază de date la formele normale 1.2 Forme normale M4 Introducere La proiectarea unei baze de date. şi să le pună în evidenţă proprietăţile  descopere anomaliile din descrierea unei baze de date  aducă o bază de date la formele normale 1. 2 şi 3. Normalizarea Cuprins Introducere Obiectivele modului U4. 2 şi 3. care are ca scop principal identificarea setului celui mai adecvat de relatii care sa modeleze realitatea dorita.Modulul 4. un obiectiv foarte important. Pentru realizarea acestui obiectiv se utilizeaza tehnica normalizarii. U4.1 De ce este nevoie de normalizare şi cu ce instrumente facem normalizarea. a relatiilor dintre date şi a restrictiilor impuse asupra datelor. 85 . care trebuie urmarit cand se gandeste un model de date. M4.

Normalizarea sprijina proiectantul bazei de date.99 Iluminat Lift 30.06.U4.06. vom utiliza exemple din sistemul informatic Asociatie de locatari. şi să le pună în evidenţă proprietăţile Durata medie de parcurgere a primei unităţi de învăţare este de 1 oră.99 Apa calda 30.000 F100 500. pentru a se preveni aparitia anomaliilor la actualizare.U4.000 Romgaz R1234567 R1234567 R7654321 R7654321 C15 C16 C10 C11 Incalzire 30. M4.000 Renel Relaţia Furnizori_Cheltuieli instanţiată Sa presupunem ca aplicaţia pe care o vom studia ca exemplu contine datele organizate intr-o singura relatie descrisa de urmatoarele schema de relatie: 86 . In exemple se vor simplifica numele atributelor. dandu-i posibilitatea sa aplice o serie de teste asupra relatiilor individuale.1.000 F110 200.150.06.99 F110 Renel 3. Pentru a ilustra procesul de normalizare. Exemple Fie relaţia Furnizori_Cheltuieli exemplificată mai jos. M4. asa incat schema relaţionala poate fi normalizata la forma normala dorita. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  realizeze importanţa normalizării  descopere dependenţele funcţionale între atribute. Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare F100 Romgaz 2. Introducere Procesul de normalizare este o metodă formală care identifica relaţiile bazandu-se pe cheile primare ale acestora (sau pe cheile candidat în cazul BCNF) şi pe dependenţele funcţionale care exista intre atributele acestor relatii.Unitatea de învăţare 4. Partea cea mai importantă la proiectarea bazei de date este gruparea atributelor în relaţii cu scopul de a minimiza redundanţa informaţiilor şi (odata cu aceasta) spaţiul ocupat de relatii (tabele sau fişiere) pe suportul magnetic.99 30.06.1.000.1 De ce este nevoie de normalizare şi cu ce instrumente facem normalizarea.

Furnizori_Cheltuieli = (Cod_furn. (Nu dorim sa insistam asupra cauzelor care pot duce la aceste situatii. Anomalii de modificare Dacă în relaţia Furnizori_Cheltuieli dorim să schimbăm valoarea unui atribut al unui furnizor. se va şterge şi furnizorul. trebuie neapărat adăugată şi o cheltuială pentru asociaţia de locatari către acel furnizor. Anomaliile enumerate mai sus se pot evita prin folosirea (in acest caz) a două relatii distincte: Cheltuieli şi Furnizori. Relatia Furnizori_Cheltuieli are cheia compusa din atributele Cod_furn. Descompuneri cu pierderi de informatii 87 . va trebui să schimbăm datele pentru fiecare apariţie a acelui furnizor. De exemplu dacă dorim să schimbăm codul fiscal al furnizorului cu codul F100. Este nerecomandabil sa se lucreze cu valori nule deoarece se genereaza probleme la regasirea şi actualizarea informatiilor. Pentru a adăuga detalii despre un furnizor nou în relaţia Furnizori_Cheltuieli. Deci toate detaliile introduse despre acel furnizor vor fi pierdute. nu se poate înregistra nici o cheltuială şi deci trebuie introduse valori nule. Această anomalie poate duce la apariţia de informatii diferite despre acelasi furnizor în înregistrări diferite. Enumeram mai jos o parte dintre acestea. Detaliile despre furnizor se repetă la fiecare introducere a unei cheltuieli noi. nu ne mai putem baza pe corectitudinea datelor despre furnizor in baza de date. în relaţia Furnizori_Cheltuieli trebuie obligatoriu adăugate şi detaliile despre furnizorul în cauză. Datele sunt prost organizate in relatia prezentata.). Cod_fiscal. 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. daca e necesara o stergere in relatia Cheltuieli. În cazul în care încă nu a sosit factura de la furnizor. Informatia despre furnizor isi pierde in acest mod consistenta.  Anomalii de ştergere În cazul ştergerii unei cheltuieli a asociaţiei de locatari către un furnizor nou (tot in cadrul relatiei Furnizori_Cheltuieli ). Din nou . Cod_Chelt şi Data. modificarea se va xecuta intr-un singur loc în relatia Furnizori. Nu este insa singura problema pe care o organizare nepotrivita a datelor o poate genera. aceasta nu va mai afecta furnizorii din relatia Furnizori. Valoare) Dintre atribute. Asemanator. chiar dacă ele există deja în baza de date. Informaţia despre furnizori din relatia Furnizori_Cheltuieli este redundantă. Cod_chelt. Den_furn. O altă consecinta a redundanţei informatiilor din baza de date. Den_chelt. Data. va trebui să schimbăm acest atribut în toate tuplele in care apare furnizorul F100. Anomalii de adaugare Anomaliile de inserare se pot clasifica în două tipuri:  Pentru a adauga detaliile despre o cheltuială către un furnizor. cele evidentiate constituie cheia primara pentru relatia respectiva. ceea ce duce la obligativitatea reintroducerii datelor la o nouă folosire al acelui furnizor. o reprezinta problemele de actualizare a informaţiei stocate. De asemenea orice cheltuiala adaugata şi orice furnizor nou adaugat nu se vor mai conditiona reciproc in nici un fel. În acest caz dacă trebuie modificat un atribut al unui furnizor.

pentru care t 1[A]=t2[A]. se verifica urmatoarea situatie: pentru orice pereche de tuple t1 şi t2 din r. Exemple O parte dintre Furnizori_Cheltuieli sunt: Cod_furn  Den_furn dependenţele funcţionale pentru relaţia 88 . R n} daca n Ri = R i 1 Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel putin o schema de relatie din descompunere. In acest caz. construita pe schema de relatie R. obligatoriu cele doua tuple vor avea aceeasi valoare şi pe submultimea de atribute B. …. Criteriul este mai mult de ordin intuitiv şi el nu ne este de mare ajutor in cazul reprezentarii multimilor-relatie. atributul. Orice relatie se construieste pe baza unei scheme de relatie. …. rn construite pe schemele de relatie ce formeaza descompunerea. Dependenţe funcţionale Unul din cele mai importante concepte asociate cu normalizarea este conceptul de dependenţă funcţională. Spunem ca B depinde functional de A şi scriem AB daca pentru orice relatie legala r. Valorile din B sunt in mod unic determinate de valorile din A. Fie R o schema oarecare de relatie. Aceasta inseamna ca atunci cand un tuplu t1 are (pe submultimea de atribute A) aceeasi valoare cu alt tuplu t2. Numim determinant al unei dependente funcţionale. În general se poate urmari ca in fiecare relatie sa se reprezinte informatii despre o singura multime-entitate. sau mulţimea atributelor din partea stângă a săgeţii. are loc intotdeauna şi t 1[B]=t2[B]. Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. Se verifica A R şi BR. Daca ne raportam la relatiile care se bazeaza pe schemele de mai sus. Un set de scheme de relatie reprezinta o descompunere a lui R şi se noteaza {R1. Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de relatie R i. 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 neam ocupat. Pentru a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta functionala.Î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. In termenii algebrei relaţionale se poate considera egalitatea. intr-o relatie se intalnesc date despre mai multe multimi-entitate. Dependenţa funcţională descrie un anumit tip de legatura care se stabileste intre atributele aceleiasi relatii. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se realizeaza descompunerea. Este necesar sa se stabileasca o modalitate riguroasa de a decide care sunt informatiile care trebuie sa alcatuiasca o astfel de relatie. fie r relatia construita pe schema R sie fie relatiile r1. r2. R2. ri =  Ri (r) pentru toti 1in.

are loc intotdeauna şi t1[R]=t2[R]. pentru care t1[K]=t2[K]. La coduri egale.a. Dependentele functionale pot fi stabilite de cine cunoaste exact legaturile intre valorile atributelor. Astfel: 4) regula reuniunii – daca X. Y şi Z sunt subseturi de atribute din R şi daca XY şi YZ atunci are loc şi XZ. O metoda de a determina multimea tuturor dependentelor functionale dintr-o relatie se bazeaza pe asa-numitele Axiome ale lui Armstrong. cod furnizor şi data. Daca nu se iau cele trei informatii impreuna se pot crea confuzii in legatura cu valoarea. …) Notiunea de dependenta functionala generalizeaza notiune de cheie. pentru un anumit serviciu (care duce la un anume cod cheltuiala) cere o suma bine determinata de bani. (Acelasi cod de cheltuiala poate corespunde la valori diferite in date diferite. Valoarea insa nu poate fi determinata in mod unic decat de combinatia cod cheltuiala. Dependenţa funcţională este o proprietate legata de semantica atributelor în relaţii. Y şi W sunt subseturi de atribute din R şi daca XY atunc WXWY. Y şi Z sunt subseturi de atribute din R şi daca XY şi XZ 89 . Dependentele functionale ne permit sa exprimam restrictii asupra relatiilor pe care nu le putem exprima cu ajutorul cheilor.m. Intr-o anume data.d. 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.Cod_furn  Cod_fiscal Cod_chelt Den_chelt Cod_chelt. Nu se pot da retete pentru stabilirea dependentelor functionale. Regulile (Axiomele) lui Armstrong: 1) regula reflexivitatii – daca X este un subset de atribute din R şi YX. un anumit furnizor. adica pentru orice pereche de tuple t1 şi t2 din r. 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. 3) regula tranzitivitatii – daca X. numele sunt identice. Acelasi furnizor poate avea chiar şi coduri de cheltuiala diferite darmite valoarea care le reprezinta. atunci are loc XY. s. Se poate da urmatoarea definitie a supercheii: Spunem ca submultimea deatribute K din schema de relatie R este o supercheie daca KR. deci de catre cineva care cunoaste foarte bine aplicaţia şi semnificatia informatiilor din relatii. Nici una dintre valori nu poate determina valoarea şi nici in combinatii de cate doua. Data  Valoare Numele furnizorului este determinat in mod unic de codul furnizorului. 2) regula creşterii – daca X. Totusi se mai utilizeaza in mod obisnuit şi reguli suplimentare (care pot fi deduse din primele trei) deoarece usureaza calculele. Cod_furn.

Y şi Z sunt subseturi de atribute din R şi daca XYZ atunci au loc şi XY şi XZ. cu F+ se va nota inchiderea lui F (deci toate dependentele functionale care se pot defini pentru relatia in cauza. operatie din algebra relaţionala. H. R 2. se obtin in general mai multe tuple decat au fost in relatia initiala r. C. la cate un tuplu ti in fiecare relatie ri. Pornind de la acest set initial se mai pot calcula şi urmatoarele dependente:   AH. R2. Rn} a unei scheme de relatie R este o descompunere fara pierderi la jonctiune pentru R. I} şi fie setul de dependente initial notat cu F şi format din dependentele: AB. CGHI.atunci şi XYZ. prin descompunere. Altfel spus. Y.daca X. 6) regula pseudotranzitivitatii . Fie C un set de restrictii asupra bazei de date. utilizand regula tranzitivitatii aplicata la dependentele AB şi BH. W şi Z sunt subseturi de atribute din R şi daca XY şi WYZ atunci şi WXZ Exemple EXEMPLU: Fie schema de relatie R={A. Am subliniat mai inainte ca este necesar sa fim atenti la descompuneri pentru a evita pierderea de informatii. daca pentru toate relatiile r definite pe schema R (care sunt legale sub restrictiile C) se verifica: n r= X  Ri (r) i 1 Vom prezenta in continuare un criteriu cu ajutorul caruia se poate verifica daca este o descompunere fara pierderi la jonctiune sau nu. …. BH. si asa mai departe… … Daca se noteaza cu F setul initial de dependente functionale. CGH.) Putem reveni in acest moment pentru a trata descompunerile de relatii. …. Pentru o descompunere oarecare se verifica intotdeuna relatia: n r X ri i 1 unde prin X s-a notat produsul cartezian. 5) regula descompunerii – daca daca X. 90 . CGI. B. O descompunere {R1. utilizand regula reuniunii pentru dependentele CGH şi CGI. În general spunem ca o relatie este legala daca satisface toate regulile sau restrictiile care sunt impuse la proiectarea bazei de date. care sa asigure corectitudinea informatiilor din respectiva baza de date. orice tuplu din relatia r duce. Cand se realizeaza produsul cartezian cu toate relatiile ri. G. AC. Rn} a relatiei R. deoarece produsul cartezian are ca rezultat toate combinatiile posibile intre elementele participante. Descompuneri fara pierderi la joncţiune Fie o descompunere oarecare {R1. Asupra relatiilor dintr-o baza de date se impun intotdeauna anumite restrictii sau conditii. asa cum am definit-o formal la inceputul acestui capitol.

In general F'F. R n} daca n Ri = R i 1 Aceasta inseamna ca orice atribut din schema de relatie initiala R se regaseste in cel putin o schema de relatie din descompunere. n Vom obtine un set de multimi de dependente functionale F1. Fie F'= i 1 Fi.Definitie. 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. Orice relatie se construieste pe baza unei scheme de relatie. ri =  Ri (r) pentru toti 1in. (Se cere ca dependentele functionale din Fi sa includa doar atribute care se regasesc in relatia R i). Un set de scheme de relatie reprezinta o descompunere a lui R şi se noteaza {R 1. Se pot impune restrictii care permit sistemului sa verifice la orice actualizare a informatiilor ca nu se va crea o relatie ilegala.U4. şi fie {R1. F2. Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de relatie R i. Fn. reuniunea seturilor de dependente funtionale. rn construite pe schemele de relatie ce formeaza descompunerea. la şterger şi la modificări. …. Aceasta descompunere este fara pierderi la jonctiune daca cel putin una dintre urmatoarele dependente functionale se gasesc in F+: R1R2R1 R1R2R2 Descompuneri cu pastrarea dependentelor Pastrarea dependentelor duce la pastrarea consistentei informatiilor din baza de date. Este posibil sa pierdem informatii daca nu suntem atenti la modul in care se realizeaza descompunerea. In termenii algebrei relaţionale se poate considera egalitatea. Daca se intampla asa atunci spunem ca descompunerea este o descompunere cu pastrarea dependentei. Dar s-ar putea ca sa se verifice relatia F'+=F+. definit pe o schema de relatie R. Daca ne raportam la relatiile care se bazeaza pe schemele de mai sus. R2}. Notam cu Fi restrictia la Ri a multimii de dependente functionale F. Fie R o schema oarecare de relatie. …. fie r relatia construita pe schema R sie fie relatiile r1. Rn} o descompunere a lui R. …. Fie R o schema de relatie şi fie descompunerea lui R reprezentata de {R1. R 2. Pentru 91 . r2. Fie F setul initial de dependente functionale. …. Rezumat Din cauza proiectării incorecte pot apărea anomalii la in serare de noi ănregistrări. M4. Descompunerile cu pierderi de informatii se pot clasifica in Descompuneri cu pierderi la jonctiune şi Descompuneri cu pierderea dependentelor. R2.1.

nume. Y şi W sunt subseturi de atribute din R şi daca XY atunc WXWY. Se verifica AR şi BR.U4. Y şi Z sunt subseturi de atribute din R şi daca XY şi YZ atunci are loc şi XZ.10(codmaterie. Spunem ca B depinde functional de A şi scriem AB daca pentru orice relatie legala r. construita pe schema de relatie R. Regulile (Axiomele) lui Armstrong: 7) regula reflexivitatii – daca X este un subset de atribute din R şi YX. Test de autoevaluare a cunoştinţelor 4.1. are loc intotdeauna şi t1[B]=t2[B]. Fie o schema de relatie R şi fie submultimile de atribute A şi B din R. atunci are loc XY.a clarifica lucrurile in aceasta directie este necesara mai intai definirea notiunii de dependenta functionala. 8) regula creşterii – daca X. 9) regula tranzitivitatii – daca X. se verifica urmatoarea situatie: pentru orice pereche de tuple t1 şi t2 din r.1 Descoperiţi dependenţele funcţionale din tabela: Student=(nrmatricol.denumirematerie. M4.1.adresa.nota)) Răspunsurile se găsesc la sfârşit la pag 155 92 . pentru care t1[A]=t2[A].

Normalizarea se execută trecând prin toate formele normale. Toate aceste forme normale se bazeaza pe dependentele functionale stabilite intre atributele unei relatii. 2NF.U4. M4. Iniţial s-au propus trei forme normale.forma normală 4 (4NF) şi forma normală 5 (5NF) .99 3. La proiectarea unei baze de date e recomandabil sa se ajunga cel puţin pana la forma normală trei.dar acestea se folosesc foarte rar. 2 şi 3.99 500.06. Boyce şi E. Codd (1974).2.06. adica nu exista nici atribute compuse nici repetitive. Forma Normală Unu (1NF): Spunem ca o relaţie se gaseste in Forma normala unu daca orice atribut este atomic.000.150. s-a obtinut forma Boyce-Codd.U4. Codd (1972). Acest proces presupune respectarea unor reguli prin care baza de date se poate normaliza până la un anumit grad. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  descopere anomaliile din descrierea unei baze de date  aducă o bază de date la formele normale 1. Există şi forme normale mai tari . Aceasta asigura evitarea anomaliilor descrise la inceputul acestui capitol. adica se aduce la o anumita forma normala. F.000 F110 Renel R7654321 C10 Iluminat 30. până la forma normală cerută. Pentru a transforma tabela din exemplul următor în forma normală unu. Normalizarea este un proces de organizare a datelor in relatiile unei baze de d ate. F.99 2. după numele celor care au introdus aceasta forma normala: R.2. Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.06.2 Forme normale M4.Unitatea de învăţare 4. respectiv 3NF. Formele normale cele mai folosite sunt: forma normală 3 şi forma normală Boyce-Codd. notate 1NF. Forma Normală Unu (1NF) Numim Formă Nenormalizată (UNF) orice tabelă care conţine una sau mai multe grupuri repetitive pe atribute.000 C16 Apa calda 30. identificăm şi ştergem grupurile repetitive din tabelă. Mai târziu. prin enuntarea unei definitii mai tari a formei normale trei.000 93 . Eliminarea acestor grupuri repetitive se poate realiza în două moduri: Exemple 4.2 Introducere Procesul de normalizare a fost introdus de E.1 Pentru relaţia Furnizori_Cheltuieli: Cod_furn Den_furn Cod_fiscal Cod_chelt Den_chelt Data Valoare F100 Romgaz R1234567 C15 Incalzire 30.

prin crearea altor înregistrări.99 Iluminat Lift 30.3 Furnizori (Cod_furn.000 F110 Renel R7654321 C10 3.150. Daca vom normaliza dupa prima metoda. trebuie să avem o singură valoare la fiecare intersecţie linie coloană.06.99 În tabela normalizatã. Cod_chelt Data Den_chelt Valoare F100 C15 30. Cod_chelt. Cod_chelt. în care să fie introduse valorile din aceste grupuri. Normalizând tabela iniţială după a doua modalitate. cheia va fi (Cod_furn. vom crea o a doua tabelă cu informaţiile care nu se repetă.06.99 30.000 F110 Renel R7654321 C11 200.06.C11 Lift 30. împreună cu celelalte valori ale atributelor din înregistrarea la care se lucrează.99 Iluminat 3000000 F110 4 C11 30.06.06.000 Tabela nenormalizată Furnizori_Cheltuieli.06.000 Tabela Furnizori_Cheltuieli în 1NF Den_chelt Data Incalzire 30. La fel şi pentru furnizorul "Renel". Cod_fiscal) Cheltuieli (Cod_furn. împreună cu cheia primară din tabela iniţială.99 Incalzire 1500000 F100 2 C16 30. Den_furn. Aceste relaţii noi. Valoare) Cele două tabele astfel create sunt în 1NF: Cheltuieli Cod_furn. Observăm că pentru furnizorul "Romgaz" avem două tipuri de cheltuieli. Tabele astefel rezultată va fi în formă normală unu.06.06.99 Apa calda 500000 F110 3 C10 30.06.99 Apa calda 30. Data. Deci cele două tabele vor fi următoarele: Exemple 4.000 F100 Romgaz R1234567 C16 500. eliminăm grupurile repetitive.2 Cod_furn Den_furn Cod_fiscal Cod_chelt Valoare F100 Romgaz R1234567 C15 2. Pentru a transforma această tabelă în 1NF. precum şi tabela normalizată vor fi în formă normală unu. Den_chelt. vom scrie repetiţiile pe diferite rânduri iar coloanele care nu conţin repetiţii. Putem avea mai multe grupuri repetitive. vor fii copiate corespunzator pe fiecare rând Exemple 4. Conform primei modalităţi.99 200.2. În a doua modalitate. În acest caz creăm mai multe relaţii noi. Data).2.000. fiecere valoare a grupurilor repetitive le copiem într-o nouă relaţie împreună cu cheia primară din tabela iniţială.99 Lift 200000 Furnizori Cod_furn Den_furn Cod_fiscal F100 Romgaz R1234567 94 .

2.2..5.99 500000 F110 C10 30.06. Pentru a demonstra trecerea la forma normală doi şi mai departe. Relaţiile rezultate după trecerea la 2NF a relaţiei Furnizori_Cheltuieli. dar nu este dependent funcţional de nici un subset de atribute din A. Data  Valoare Dependenţa funcţională este totala pentru ca Valoare nu depinde functional de nici un subset de atribute al grupului Cod_chelt. spunem ca B este total dependent funcţional de grupul de atribute A.99 3000000 F110 C11 30. dacă este în forma normală unu şi fiecare atribut care nu aparţine cheii primare. Relaţiile rezultate au următoarele scheme de relatie: Furnizori = (Cod_furn. Cod_fiscal) 95 . este în 2NF daca este in 1NF. Relaţia la care cheia primară se compune dintr-un singul atribut.06.2.99 200000 Relaţia 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. Exemple 4. După efectuarea acestor transformări. folosind relaţia Furnizori_Cheltuieli.4 De exemplu să luăm următoarea dependenţă funcţională: Cod_chelt. Den_furn. vom obtine următoarele relaţii: Exemple Relatia Cheltuieli: Cod_furn. Data. create prin metoda a doua de normalizare. Forma Normală Doi (2NF) Forma normală doi se obtine utilizand conceptul de dependenţă funcţională totală. Dependenţa funcţională totală. 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. prezentata în exemplul 4.99 1500000 F100 C16 30. O relaţie este în forma normală doi. dacă B este dependent funcţional de A.06.F110 Renel R7654321 Relaţiile Cheltuieli şi Furnizori. este total dependent funcţional de cheia primară. Vom demonstra aducerea la forma normală doi. Cod_furn. vom folosi relaţia Furnizori_Cheltuieli. Cod_chelt Data Valoare F100 C15 30.06. Cod_furn. Dacă A este un subset de doua sau mai multe atribute şi B este atribut (sau subset de atribute) al aceleiasi relaţii. Forma normală doi trebuie verificată doar la relaţiile care au cheie compusă pe poziţie de cheie primară. Forma Normală Doi (2NF).

Spunem ca o relaţie este în forma normală BoyceCodd dacă şi numai dacă orice determinant din relaţie este cheie candidat. Forma Normală Boyce-Codd (BCNF) Baza de date trebuie proiectată astfel încât să nu conţină dependenţe parţiale sau tranzitive. Cod_chelt. Dacă atributele A. Aceste anomalii apar din cauza redundanţei generate de dependenţa tranzitivă. Cod_fiscal Cod_chelt  Den_chelt Cod_furn. Exemple Să considerăm tabela cu schema: Carte=(cod_car.titlu.titlu. Den_chelt) Cheltuieli = (Cod_furn. Forma normală Boyce-Codd (BCNF).Tip cheltuială = (Cod_Chelt. Valoare) Forma Normală Trei (3NF) Forma normală doi chiar dacă nu conţine atâta redundanţă ca forma normală unu. Spunem ca o relaţie este în formă normala trei daca este deja in forma normală doi şi nici un atribut care nu aparţine cheii p rimare nu este tranzitiv dependent de cheia primara. observăm că nu există dependenţe tranzitive.. totuşi există cazuri în care pot apărea anomalii la actualizare. Data. Forma normală Boyce-Codd se obtine utilizand cheile candidat din relaţie. pentru că altfel ne putem confrunta cu anomaliile descrise la inceputul capitolului. O relaţie cu o singură cheie candidat în formă normală trei este şi în formă normală Boyce -Codd. Examinând relaţiile în forma normală de mai sus. Data  Valoare 96 . Cod_chelt. Forma Normală Trei (3NF). atunci spunem că atributul C este dependent tranzitiv de atributul A. Dependenţă tranzitivă.denumire_domeniu) Cu cheia cod_dom. adică cheia primară. C sunt în relaţiile AB şi BC. B. împreună cu determinantul lor. Domenii=( cod_dom.cod_dom) Cu cheia cod_car. În cazul existenţei dependenţei tranzitive. ştergem coloanele care sunt tranzitiv dependente de cheia primară şi creăm o relaţie nouă cu aceste coloane. Deci relaţiile sunt în formă normală trei.cod_dom. Să căutăm determinanţii din exemplul de mai sus: Cod_furn  Den_furn.denumire_domeniu) Cheia este cod_car. Avem depemdenţele funcţionale: cod_car cod_dom cod_car titlu cod_dom denumiredomeniu vedem că dependeţa 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. via B.

U4. Există situaţii când este foarte greu de descompus relatiile. În aceste situaţii este indicata rămânerea la forma normală trei.Toţi cei trei determinanţi sunt şi chei candidat in relatiile lor. trecerea la BCNF se realizează prin ştergerea din relaţia iniţială a atributelor care sunt asociate unui determinant care nu este cheie candidat şi crearea unei noi relaţii cu aceste atribute şi determinantul lor. Rezumat Forma Normală Unu (1NF) Trebuie să căutăm toate intersecţiile de linii şi coloane. Eliminarea se realizează prin ştergerea câmpurilor dependente tranzitiv de cheia primară din relaţia iniţială şi crearea unei noi relaţii cu aceste atribute şi determinantul lor.2. 97 . trebuie să eliminăm dependenţele tranzitive. precum şi cheia primara din relaţia iniţială. adică toate atributele care depind funcţional de un subset de atribute a cheii primare. caz în care este de preferat rămânerea la forma normală trei. ştergem atributele care depind parţial de cheia primara şi creăm o relaţie nouă care să se compună din atributele şterse împreună cu determinantul lor. Relaţiile în formă normală trei sunt în general şi în formă normală Boyce-Codd. În cazul în care relaţia nu este în formă normală Boyce-Codd. atunci relaţia este în forma normală doi. vom şterge atributele dependente funcţional de determinantul care nu este cheie candidat şi creăm o nouă relaţie în care să avem atributele şterse şi determinantul lor. Forma Normală Boyce-Codd (BCNF) Cerinţa la forma normală Boyce-Codd este ca fiecare determinant din relaţie să fie cheie candidat. ca să ajungem la BCNF. M4. Dacă există dependenţe partiale. după care se caută o nouă cheie primară. În cazul în care nu este îndeplinită această cerinţă. Aceste repetiţii se pot elimina prin două madalităţi:   Crearea de noi înregistrări pentru fiecare valoare a repetiţiei. Dacă cheia primară este compusă dintr-un singur atribut. daca este deja in forma normala unu. Ştergerea atributelor care conţin repetiţii şi crearea de noi relaţii care vor conţine atributele şterse. Forma Normală Trei (3NF) Pentru a trece la forma normală trei. unde există repetiţii. Forma Normală Doi (2NF) Se caută dependenţele totale de cheia primara. În unele cazuri trecerea la forma normală Boyce-Codd complică foarte mult baza de date. Deci relatiile din exemplul de mai sus sunt în formă normală Boyce-Codd.

M4.U4.2. Test de autoevaluare a cunoştinţelor 4.2.1) Aduceţi la forma normală 1 urmărtoarea tabelă: Relaţia Furnizori_Cheltuieli: Cod Denumire Cod Nr. Cod Denumire Furn. fiscal Crt. Chelt. Cheltuială F100 Romgaz R1234567 1 C15 Chelt pt. Încălzire 2 C16 Chelt pt. Bucătării F110 Renel R7654321 3 C10 Chelt cu iluminatul 4 C11 Chelt pt. Func. liftului

Valoare 1500000 500000 3000000 200000

4.2.2 Aduceţi la forma normală 2 schema: (Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr. Crt., Cod, Valoare) 4.2.3 Aduceţi la forma normală 3 schema: carte = (c_carte, titlu, cod_domeniu, den_domeniu) 4.2.4 Aduceţi, pe rând, la formă nprmală 1, 2 şi 3 tabela: Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota)) Răspunsurile se găsesc la sfârşit la pag 155

98

Modulul 5. Metodologia de proiectare a bazelor de date relaţionale

Cuprins Introducere Obiectivele modului U5.1 Generalităţi şi proiectarea conceptuală U5.2 Proiectarea logica U5.3 Proiectarea fizica U5.4 Tranzacţii şi concurenţă U5.5 Metode de control al concurenţei.

M5. Introducere Metodologia de proiectare este o aproximare structurată, care utilizează proceduri, tehnici, instrumente şi documentaţii pentru a facilita procesul de proiectare. Metodologia de proiectare se compune din etape, care la rândul lor se compun din paşi, care orientează proiectantul la fiecare nivel al creării bazei de date.
În mod obişnuit, un sistem SGBD deserveşte mai mulţi 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 execuţia concurentă a mai multor procese. Execuţia concurentă a mai multor procese poate avea loc atât într-un sistem uniprocesor, prin partajarea (împărţirea) timpului de execuţie al procesorului între mai multe procese, cât ş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 numărul de procesoare ale sistemului, accesul concurent al mai multor utilizatori la datele memorate în tabelele unei baze de date necesită tehnici de menţinere a consistenţei (corectitudinii) şi a siguranţei datelor memorate.

M5. Obiectivele modulului La sfârşitul acestui modul studenţii vor fi capabili să:  respecte o metodologie de proiectare  creeze modelul conceptual al unui sistem informatic  realizeze proiectul logic local  realizeze proiectul logic global  aleagă, în cunoştinţă de cauză, SGBD-ul cel mai potrivit.

99

       

descrie corect structura fizică a bazei de date proiecteze cereri proiecteze formulare proiecteze rapoarte construiască tranzacţii corecte aleagă cea mai bună metodă de control al concurenţei introducă regulile de integritate să impună măsuri de securitate

100

Proiectarea logică începe cu crearea modelului conceptual al bazei de date. O metodologie este o cale de a apllica în proiectare metoda divide et impera. iar partea de impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi. şi. mai puţin standardizată şi care depinde esenţial de experienţa celui care o îdeplineşte. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  respecte o metodologie de proiectare  creeze modelul conceptual al unui sistem informatic Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore. Definiţie: Proiectare logică: Procesul de construcţie a unui model de informaţii folosite într-o întreprindere. în acelaşi timp. împreună cu procedurile de actualizare. este proiectarea conceptuală.Unitatea de învăţare U5. multe dintre ele fiind contradictorii şi dificil de îndeplinit: obţinerea unu i timp de răspuns la interogări cât mai mic. realizarea modelului logic global. pentru că deciziile luate la implementarea fizică pot afecta baza de date logice. în cazul nostru. Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi proiectarea fizică. Definiţie: Proiectare fizică: Este procesul de descriere a implementării bazei de date într-un SGBD. care va influenţa mai târziu modelul de date în care se va implementa. bazată pe modelul de date. În această etapă a proiectării este creată baza de date într-un SGBD. În această etapă există un feedback între proiectarea fizică şi cea logică. asigurarea unui mod de acces la date cât mai simplu dar intuitiv. care este independent de implementarea într-un SGBD. M5. Un alt avantaj îl constitue faptul că la terminarea activităţii de proiectare.1 Generalităţi şi pro iectarea conceptuală M5U1 Introducere Metodologia de proiectare are o mare importanţă în ordonarea muncii grele de proiectare a unui sistem informatic. În orice domeniu folosirea unei metodologii are o mare importanţă. avem o mare parte din documentaţia proiectului realizată. în care trebuie să aflăm cum funcţionează intreprinderea şi ce parte din circuitul informaţional va fi automatizată. 101 . Modelul conceptual este apoi proiectat pe un model logic.U1. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat. Prima etapă. De asemenea urmărirea uinei metodologii face posibil lucru în echipă prin divizarea sarcinilor ţi posibibilitatea urmăririi stadiului la care s-a ajuns. dar independent de particularizările sistemului de gestiune a bazei de date şi a altor considerente fizice. etc. utilizarea unui spaţiu de memorare cât mai redus. Pe parcursul activităţii de proiectare trebuie să fie satisfăcute mai multe cerinţe.

102 .). etc.. Prin contrast. Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii. a volumului şi frecvenţei datelor actualizate precum şi a volumului datelor retumate de interogări şi a frecvenţei acestora. rapoartele utilizate în controlul activităţii respective. modificarea bazei de date este mult mai dificilă. De asemenea. aplicaţii contabile. după implementarea aplicaţiilor. Se colectează răspunsuri scrise de la utilizatorii potenţiali la diferite seturi de întrebări şi se organizează interviuri cu persoanele care reprezintă diferitele grupuri de utilizatori. proiectanţii pot înţelege care sunt priorităţile de proiectare a bazei de date. etc. proiectul rezultat trebuie să conţină schema bazei de date precis definită. importanţa diferitelor aplicaţii şi performanţele dorite de la acestea. De regulă. pe baza cărora se pot construi diagrame. aplicaţii de salar izare. pentru proiectul conceptual al unei baze de date se folosesc denumirile de schemă conceptuală de nivel înalt sau schemă conceptuală independentă de SGBD sau. • Analiza mediului de operare şi a cerinţelor de prelucrare a datelor. în afară de documentaţiile aplicaţiilor dorite se studiază şi alte documentaţii şi interviuri. este necesar să se cunoască ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile pentru aceasta. tabele. de cele mai multe ori. procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Deosebit de importantă este şi stabilirea volumului de date conţinute în mod tipic de baza de date. Proiectul logic al unei baze de date este denumit schemă logică sau schemă conceptuală dependentă de SGBD în cele mai multe lucrări din domeniul proiectării bazelor de date.). dar este crucială pentru succesul sistemului informatic. persoana cea mai avizată din cadrul fiecărui grup de utilizatori este cooptată ca participant în activităţile ulterioare de colectare şi analiză a cerinţelor. în felul acesta. formularele existente de introducere a datelor. dat fiind că. Înainte de a se proiecta efectiv o bază de date. în această fază de colectare şi analiză a cerinţelor. Revederea documentaţiei existente privind aplicaţiile dorite. în general în limbaj natural. În general. Această fază este puternic consumatoare de timp. existând şi unele ambiguităţi privind denumirile etapelor sau ale tipurilor de scheme ale bazelor de date. este necesar să se cunoască ce aplicaţii se vor efectua (aplicaţii de gestiune a stocurilor. Terminologia folosită în domeniul proiectării bazelor de date este destul de variată. manual sau folosind diferi te instrumente software de proiectare. Cel mai frecvent. Această activitate include analiza fluxului de informaţii în cadrul sistemului. schemă conceptuală. se desfăşoară următoarele activităţi: • Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. chiar mai simplu.Problema proiectării bazelor de date este complicată şi de faptul că. pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date. • Chestionare structurate. etc. precum şi analiza tipurilor de tranzacţii şi a frecventei de lansare a acestora. aplicaţii de urmărire a consumurilor. grafice.

Pasul 2. Pasul 2. Pasul 1.1. Identificarea tipurilor de relaţii.4. Pasul 1. Determinarea domeniilor de definiţie a atributelor.4.2. iar partea de impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi. O metodologie este o cale de a apllica în proiectare metoda divide et impera. Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii.7. Pasul 1. Pasul 1.1. Pasul 1. Desenarea diagramei entity-relationship. este necesar să se cunoască ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la baza de date respectivă şi ce informaţii primare sunt disponibile pentru aceasta. Pasul 2. Validarea modelului din nou. Determinarea atributelor care compun cheile candidate şi primare. proiectul rezultat trebuie să conţină schema bazei de date precis definită. se desfăşoară următoarele activităţi: • • Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. realizarea modelului logic global. rapoartele utilizate în controlul activităţii respective. Problema proiectării bazelor de date este complicată şi de faptul că.Să ne reamintim. etc. 103 .5. de cele mai multe ori.3. Analiza mediului de operare şi a cerinţelor de prelucrare a datelor. utilizând normalizarea. Separarea în paşi asigură divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat. Revederea documentaţiei existente privind aplicaţiile dorite şi interviuri. Pasul 2.. Crearea şi validarea modelului logic local. Validarea modelului. Pasul 2. Specializare/generalizare (pas opţional).. Pasul 1. Pasul 1. în cazul nostru.). utilizând tranzacţiile.6. în această fază de colectare şi analiză a cerinţelor. Pasul 2. Prin contrast. Verificarea modelului conceptual local cu ajutorul utilizatorului. Desenarea diagramei ER. Identificarea tipurilor de entităţi.3.8. formularele existente de introducere a datelor.2. Proiectarea logică a bazei de date relaţionale: Crearea unui model conceptual local. pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date. Crearea relaţiilor pentru modelul logic local.5. Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi proiectarea fizică. Proiectarea modelului conceptual local pe un model logic local. pentru vederile utilizatorilor. Pasul 1. procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de relaţii. Înainte de a se proiecta efectiv o bază de date. • • • Prezentarea metodologiei Prima dată să vedem care sunt paşii de urmat în proiectare: Pasul 1.

7.1. Pasul 3. Pasul 3. Deşi nu este obligatoriu.  Utilizarea diagramelor pentru a reprezenta cât mai multe modele logice posibile. este totuşi recomandabil să se realizeze mai întâi schema conceptuală de nivel înalt independentă de SGBD. Pasul 6. Proiectarea regulilor de acces la baza de date. această fază se poate menţine independentă de SGBD şi produce un model de date de nivel înalt.5. Verificarea modelului logic local cu ajutorul utilizatorului. Pasul 5. Alegerea organizării fişierelor. Pasul 5. prin normalizare şi prin tranzactii. care va fi implementat după transpunerea lui într-un model de date specific.5. În final. Verificarea posibilităţii de a completa baza de date în viitor. Primul pas are ca obiectiv. la proiectarea modelului logic de baze de date. Crearea modelului conceptual local. Crearea regulilor de integritate în SGBD. Crearea modelului logic Pasul 1. Pasul 3. Crearea şi validarea modelului logic global de date. Pasul 3. pentru utilizatori. Introducerea unei redundanţe comntrolate. Pasul 4. Compunerea medelelor logice locale într-un model logic global. care este la rândul lui validat şi verificat cu ajutorul utilizatorului sistemului.4. Verificarea modelului logic global cu ajutorul utilizatorului.6.Pasul 2. Pasul 4. Verificarea sistemului operaţional. Factori critici pentru succesul proiectării logice:  Lucrul interactiv cu utilizatorul sistemului.2.1. Definirea regulilor de integritate a bazei de date.  Crearea dicţionarului de date. Pasul 5. Pasul 3. Proiectarea şi implementarea unui mechanism de securitate. Proiectarea logică a bazei de date se divide în trei paşi mari. descompunerea proiectării sistemului informatic în vederi.2. deoarece un model de date de nivel înalt este mult mai general şi mai expresiv. Acest deziderat se obţine mult mai bine independent de un anumit SGBD.  Încorporarea regulilor de integritate în modelul logic de date. care se pot discuta cu utilizatorii sistemului. Proiectarea şi implementarea reprezentării fizice. Crearea view-urilor pentru utilizatori.  Combinarea validării conceptuale.3. Proiectarea fizică şi implementarea bazei de date relaţionale: Translatarea modelului logic global în SGBD. Proiectarea relaţiilor de bază în SGBD. Modelul de date astfel creat. Analizarea tranzacţiilor.2. Pasul 5. ca supliment al modelului de date. Pasul 6.1.4. Validarea modelului logic global. Pasul 3. se validează prin normalizare şi prin tranzacţii în pasul doi.  Folosirea unei metodologii structurate pentru procesul de proiectare a bazei de date. Alegerea indecsilor secundari. Desenarea diagramei ER finale. Pasul 5. Pasul 6. Pasul 7. în timp ce fiecare SGBD 104 . a asocierilor şi a constrângerilor de către proiectanţi şi programatori. Pasul 2. Chiar dacă proiectanţii pot porni direct cu scheme conceptuale specifice unui anumit SGBD (care se mai numesc şi scheme logice). Pasul 4. Estimarea spaţiului pe disc.3.2. datorită u rmătoarelor motive: • Scopul proiectării schemei conceptuale este înţelegerea cât mai completă a structurii bazei de date. Pasul 5.1. se generează modelul global al întreprinderii.

O modaliate ar fi analiza datelor globale şi găsirea de părţi relativ independente.  domeniile atributelor. le dăm câte un nume. Determinarea domeniilor de definiţie a atributelor. care nu trebuie să influenţeze proiectul schemei conceptuale. împreună cu explicaţiile despre entităţi. iar celelelte informaţii în entitatea ProprietateLocatari. se pot considera sinonime şi la crearea modelului logic. folosind sinonime şi omonime. procedurilor cerute şi/sau observarea sistemului existent în lucru. O altă modalitate ar fi analiza rapoartelor.  cheile candidat. Nr_Bloc.5.  Pasul 1.2.  chei primare Paşii din prima etapă a proiectării logice sunt:  Pasul 1.  Pasul 1.1. Există cazuri când entităţiile sunt greu de identificat. Documentarea tipurilor de entităţi După identificarea entităţiilor. va trebui să identificăm şi relaţiile importante dintre aceste entităţi. am putea crea o entitate Locatari cu atributele Nr_Mat şi Nume. iar aceste nume le vom evidenţia în dicţionarul de date. ceea ce îngreunează identificarea entităţilor. Sinonimele prin care se descrie aceaşi entitate. precum şi posibilele aliasuri. a bazei de date. Pasul 1. Primul pas în proiectarea bazei de date este de a colecta datele necesare pentru realizarea sistemului. De exemplu. evidenţiind aceste sinonime ca diverse aliasuri ai entităţiilor.  Pasul 1.3. Identificarea tipurilor de entităţi. Utilizatorii descriu aceste entităţi. Etaj. Desenarea diagramei entity-relationship. vederi care pot lucra separat. De exemplu: 105 . Identificarea tipurilor de relaţii Obiectivul: Identificarea relaţiilor importante dintre entităţi.  Pasul 1. De exemplu în locul entităţii Locatari.4.are propriile restricţii şi soluţii particulare. pentru view-urile utilizatorilior. ceea ce putem culege. Scara.1. Relaţiile se descriu printr-un verb al relaţiei. Modelele conceptuale locale trebuie să conţină:  tipuri de entităţi. Determinarea atributelor care compun cheile candidate şi primare. pentru că modul de prezentare a viitorilor utilizatori necesită explicaţii.7.  Pasul 1. Specializare/generalizare (pas opţional). putem identifica entitatea Locatari.  atribute. Pasul 1. Acrastă discuţie presupune o despărţire în vederi. În general putem identifica entităţiile în mai multe moduri. Identificarea tipurilor de entităţi Obiectivul: Identificarea tipurilor de entităţi principale în vederile utilizatorilor. Primul pas în proiectarea bazei de date este identificarea entităţiilor din datele furnizate de utilizatori. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de relaţii. discutând cu viitorii utilizatori ai bazei de date. Verificarea modelului conceptual local cu ajutorul utilizatorului.8.  Pasul 1. dacă avem informaţiile Nr_Mat.6. Identificarea tipurilor de relaţii. Apartament şi Nume. Despărţirea în vederi se poate realiza în mai multe moduri.  tipuri de relaţii.2. După identificarea entităţiilor.  Pasul 1. Obiectivul: Crearea unui model conceptual local.

Apartament). Etaj. care poate fii totală. relaţiile sunt binare. Există şi relaţii mai complexe. Atribute simple sau compuse Este important să notăm dacă un atribut este simplu sau compus. împreună cu cardinalitatea şi participarea lor. Care este cardinalitatea relaţiei dintre student şi facultate. În continuare determinăm şi participarea la relaţie. Aceste atribute se identifică în aceeaşi mod ca şi entităţiile. La identificarea relaţiilor vom lua în considerare doar relaţiile care ne interesează. relaţia dintre student şi facultate. Documentarea tipurilor de relaţii După identificarea tipurilor de relaţii. Descompuneţi atributul adresă din tabela student. Următorul pas în metodologie este identificarea atributelor. dacă nu prezintă importanţă pentru problema noastră.3. printr-un verb al relaţiei. printr-un verb al relaţiei. Descrieţi. sau multe-la-multe (M:N). sau relaţii recursive. Exemple De exemplu. aceste valori se scriu la documentarea relaţiilor. Dacă se cunosc valori specifice ale cardinalităţiilor.Exemple  Scările sunt Locuite de Locatari  Furnizorii Provoacă Cheltuieli Descrieţi. care se realizează între mai multe entităţi. atunci putem opta pentru descompunerea sa. Noi va trebui să prelucrăm aceste informaţii separat. pentru o mai bună vizualizare a datelor. Utilizarea modelării ER Pentru vizualizarea sistemelor complicate. trebuie să luăm entităţiile şi relaţiile ra rând şi să ne punem următoarea întrebare: Ce informaţii deţinem despre această … ? Răspunsul la această întrebare ne va da atributele căutate. unu-la-multe (1:M). Pasul 1. dacă este necesară prelucrarea separată a detelor compuse. Care este cardinalitatea relaţiei dintre student şi note. trebuie să determinăm cardinalitatea lor. Identificarea şi asocierea de atribute la tipurile de entităţi şi tipurile de relaţii Obiectivul: Asocierea de atribute la tipurile de entităţi şi la tipurile de relaţii. Conform acestei informaţii va trebui să luăm decizii referitoare la acel atribut. 106 . Determinarea cardinalităţii şi a participării la tipurile de relaţii După identificarea tipurilor de relaţii. le denumim şi le introducem în dicţionarul de date. pentru că este mult mai uşor de a cuprinde toate informaţiile. relaţia dintre student şi note. atunci nu le luăm în consideraţie. În cele mai multe din cazuri. adică se realizează întrea exact două entităţi. Vă propunem ca să utilizaţi întotdeauna diagrama ER. care pune în relaţie o singură entitate cu ea însăşi. utilizăm diagrama ER. deci vom descompune acest atribut în cele patru atribute simple. Scara. Dacă un atribut este compus. atributul Adresă conţine informaţiile (Nr_Bloc. Pentru o mai uşoară identificare. sau putem să-l lăsăm compus în caz contrar. sau parţială. alegând dintre posibilităţiile: unu-la-unu (1:1). Degeaba există şi alte relaţii care să se poată identificate.

Putem avea cazuri în care atributele simple să le compunem. Exemple De exemplu în cazul atributelor Nume_Familie şi Prenume, neavând nevoie de aceste informaţii separat, le vom compune în atributul Nume. Ce puteţi 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 numărul locatarilor de pe o scară se poate număra în tipul de entitate Locatari. Deci acest atribut este atribut derivat. Ce puteţi spune despre atributul vârsta 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 menţiona dacă un atribut este sau nu derivat. Dacă identificăm un atribut care să nu-l putem asocia nici unei entităţi sau relaţii, ne întoarcem la paşii anteriori, identificând noua relaţie sau entitate la care să asociem atributul respectiv. În cazul în care putem asocia acelaşi atribut la mai multe entităţi, atunci va trebui să decidem dacă generalizăm sau nu aceste entităţi, proces care este descris la pasul 1.6. Documentarea atributelor După identificarea atributelor, le asociem un nume, şi le înregistrăm în dicţionarul de date, împreună cu următoarele informaţii:  numele şi descrierea atributului,  toate aliasurile şi sinonimele prin care este cunoscut atributul,  tipul de date şi lungimea,  valorile iniţiale 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 mulţime de valori pe care o poate lua. Pentru a controla în totalitate domeniul atributelor, se poate evidenţia următoarele:  setul de valori admisibile pentru un atribut,  operaţiile admisibile asupra unui atribut,

107

 ce atribute se pot compara cu atributul respectiv, în combinaţiile cu alte atribute,  mărimea şi formatul câmpului atributului.
Documentarea domeniilor atributelor Actualizăm dicţionarul de date cu domeniul de definiţie al fiecărui 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 următoarele:  cheia candidat, care are un număr minim de atribute,  cheia candidat, care îşi va schimba cel mai rar valoarea,  cheia candidat, care este cel mai puţin probabil să sufere modificări în viitor,  cheia candidat, care este compusă din cele mai puţine caractere (în cazul atributelor de tip caracter),  cheia candidat, care este cel mai uşor 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ă reuşim să identificăm o cheie primară, atunci entitatea este tare, altfel este slabă. O entitate slabă nu poate exista fără o entitate tare, care să-i fie “părinte”. Cheia primară a entităţii slabe este derivată parţial sau total din cheia primară a entităţii tari. Documentarea cheilor primare şi alternante Înscriem cheile primare şi pe cele alternante în dicţionarul de date. Pasul 1.6. Specializarea/generalizarea tipurilor de entităţi (pas opţional) Obiectivul: Identificarea entităţiilor subclasă respectiv superclasă, între entităţiile 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 entităţii respective. Dacă însă alegem procesul de generalizare, vom căuta superclase pentru acea entitate. Un exemplu pentru procesul de generalizare ar fii entităţiile Şef_de_scară şi Familii. Ambele entităţi au atribuite următoarele atribute: Nr_mat, Nr_bloc, Scara, Etaj, Apartament şi Nume. Pe lângă 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ă entităţi având atribute în comun, le putem generaliza în entitatea Locatari, care va conţine atributele comune, şi entităţile Şef_de_scară şi Familii, conţinând doar atributele diferite - particularizările faţă de superclasă. Pasul 1.7. Desenarea diagramei ER. Obiectivul: Desenarea unei diagrame ER. care va fi reprezentarea conceptuală a vederilor utilizatorilor despre întreprindere. În momentul acesta suntem în măsură să prezentăm o giagramă completă a modelului bazat pe vederile utilizatorilor despre întreprindere. 108

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 adevărată a vederii utilizatorului despre întreprindere. Înainte de a termina pasul 1, trebuie verificat modelul conceptual elaborat. Acest model include diagrama ER şi documentaţia anexată. În cazul în care apare orice fel de anomalie, repetăm procesul de mai înainte şi remediem problema. Să ne reamintim... Paşii din prima etapă a proiectării logice sunt:  Pasul 1.1. Identificarea tipurilor de entităţi.  Pasul 1.2. Identificarea tipurilor de relaţii.  Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de relaţii.  Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.  Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.  Pasul 1.6. Specializare/generalizare (pas opţional).  Pasul 1.7. Desenarea diagramei entity-relationship.  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 paşi asigură divizarea problemei iniţiale în probleme mai mici şi deci mai uşor de rezolvat, iar partea de impera este rezolvată de succesiunea strictă a paşilor şi de faze speciale cum ar fi, în cazul nostru, realizarea modelului logic global. Paşii mari ai metodologiei pe care o prezentăm aici sunt proiectarea logică şi proiectarea fizică.
Problema proiectării bazelor de date este complicată şi de faptul că, de cele mai multe ori, procesul de proiectare începe cu cerinţe foarte generale şi imprecis formulate. Prin contrast, proiectul rezultat trebuie să conţină schema bazei de date precis definită. Înainte de a se proiecta efectiv o bază de date, este necesar să se cunoască ce rezultate se aşteaptă utilizatorii potenţiali să obţină de la b aza de date respectivă şi ce informaţii primare sunt disponibile pentru aceasta. în această fază de colectare şi analiză a cerinţelor, se desfăşoară următoarele activităţi: • • Identificarea grupurilor de utilizatori potenţiali si a aplicaţiilor. Revederea documentaţiei existente privind aplicaţiile dorite şi interviuri.

109

Identificarea tipurilor de entităţi. Realizaţi paşii de proiectare conceptuala locală pentru subsistemul didactic din facultate. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de relaţii.1. Paşii din prima etapă a proiectării logice sunt:  Pasul 1.  Pasul 1.3. Test de autoevaluare a cunoştinţelor 5.  Pasul 1. etc. Determinarea domeniilor de definiţie a atributelor. M5.  Pasul 1.  Pasul 1.  Pasul 1.4.• Toate aceste activităţi oferă informaţii slab(diagramele de organizare a întreprinderii. Analiza mediului de operare şi a cerinţelor de prelucrare a datelor.  Pasul 1.2.1. rapoartele utilizate în controlul activităţii respective. Identificarea tipurilor de relaţii.).5. formularele existente de introducere a datelor.6.1. Verificarea modelului conceptual local cu ajutorul utilizatorului. Determinarea atributelor care compun cheile candidate şi primare. Răspunsurile se găsesc la sfârşit la pag 156 110 . Desenarea diagramei entity-relationship.7. pentru a se decide dacă aceste aspecte influenţează cerinţele bazei de date. Specializare/generalizare (pas opţional).U5.  Pasul 1.1.8.

vom corecta aceste probleme şi ne vom referi în continuare la modelul rezultat. 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 tranzacţiilor cerute. dar independent de sistem.2 Proiectarea logică. în cazul modelului relaţional. Proiectarea modelului conceptual local pe un model logic local. definirea constrângerilor. Crearea relaţiilor pentru modelul logic local. atribute. M5. în această subfazâ se face şi analiza normalizării relaţiilor. Pasul 2. atribute. proiectate în faza precedentă. pornind de la schema conceptuală şi schemele externe de nivel înalt independen te de SGBD. Se obţine un proiect logic dependent de modelul de date. În acest pas verificăm modelul conceptual creat în pasul anterior şi eliminăm din el structurile care sunt dificil de realizat într-un SGBD.  Pasul 2. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  realizeze proiectul logic local  realizeze proiectul logic global Durata medie de parcurgere acestei unităţi de învăţare este de 3 ore.).Unitatea de învăţare U5. Rafinarea schemei conceptuale şi a schemelor externe obţinute anterior. ca fiind modelul logic local. transpunerea se face prin corespondenţa dintre elementele schemei conceptuale de nivel înalt reprezentată prin diagrama Entitate-Asociere (tipuri de entităţi. Această fază de proiectare logică poate fi realizată în două subfaze:   Transpunerea schemei conceptuale în modelul de date al sistemului SGBD ales. Activităţile din acest pas sunt:  Pasul 2. 111 . dependente de sistemul SGBD ales şi de modelul de date al acestuia. 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. etc. Vom valida modelul logic prin procesul de normalizare şi a tranzacţiilor. normalizarea fiecărei relaţii până la nivelul adecvat şi documentarea tuturor dependenţelor de date care nu sunt determinate de chei ale relaţiilor (necesară pentru proiectarea procedurilor de verificare şi impunere a dependenţelor respective).2.U2. Dacă la sfârşitul acestui proces modelul ete alterat. referinţe). astfel încât să se utilizeze unele (sau cât mai multe) din facilităţile oferite de sistemul SGBD ales (modul de generare a cheilor primare. dar independent de sistemul de gestiune propriu-zis.1. asocieri) şi elementele modelului relaţional (relaţii. Rezultatul acestei faze de proiectare îl constituie schema conceptuală şi schemele externe ale bazei de date.

Pasul 2. Scari Nr_Bloc Scara Lift Cheltuieli Nr_Crt Cod_Cheltuiala (FK) Cod_Furnizor (FK) Nr_factura Data_factura Valoare_factura Sunt platite de Scari Nr_Bloc Scara Lift Pe scari Scara (FK) Nr_Crt (FK) Nr_Bloc (FK) Cheltuieli Nr_Crt Cod_Furnizor (FK) Cod_cheltuiala Nr_factura Data_factura Valoare_factura Au cheltuieli Se calculeaza a). Acest model trebuie prelucrat. ceea de este evidenţiat în figură.2. Obiectivele acestui pas sunt: (1) Eliminarea relaţiilor M:N. (1) Eliminarea relaţiilor multe-la-multe Dacă în modelul de date apar relaţii de tipul multe-la-multe (M:N). pentru a putea fi uşor de prelucrat de sistemul de gestiune a bazelor de date. Definirea regulilor de integritate ale bazei de date. utilizând tranzacţiile.3. (4) Eliminarea relaţiilor cu atribute. În pasul întâi am pregătit un model conceptual bazat pe informaţiile date de utilizator.1.7. (5) Reexaminarea relaţiilor 1:1. Verificarea modelului logic local cu ajutorul utilizatorului. Relaţie de tipul N:M. Validarea modelului din nou. (2) Eliminarea relaţiilor complexe. Pasul 2. Desenarea diagramei ER. dar şi o cheltuială (factură) poate să se refere la mai multe scări. 112 . Relaţie transfornamtă în două relaţii 1:M.6. (3) Eliminarea relaţiilor recursive. Pasul 2. 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. Pasul 2. Validarea modelului.5. (b). pot exista mai multe cheltuieli pentru o scară.     Pasul 2. Pasul 2. Exemple De exemplu. trebuie descompuse în două relaţii unu-la-multe (1:M) prin adăugarea unei noi entităţi suplimentare. (6) Eliminarea relaţiilor redundante. utilizând normalizarea. Deci relaţia dintre entitatea Scări şi entitatea Cheltuieli este de M:N.

Pasul 2. pentru că depinde atît de tipul de entitate Scări. prin crearea unui tip de entitate suplimentar. După aceea identificăm cheia primară şi toate cheile alternante. Această relaţie se poate elimina.DDL). Pentru descrierea relaţiilor vom folosi un limbaj de definire a bazei de date (Database Definition Language . pentru că pot apărea situaţii. În acest caz vom avea o relaţie de tipul 1:M între tipul de entitate iniţial şi tipul de entitate nou creat şi o relaţie de tipul 1:1 între tipul de entitate nou creat şi tipul de entitate iniţial. Entităţile “părinte” se referă la acele entităţi ale căror chei primare se vor copia în entităţile “fiu”. Eliminarea se poate rezolva prin crearea unei noi entităţi unde să se evidenţieze fiecare entitate care este legată de entitatea din tipul de entitate iniţial. Relaţia pe care un tip de entitate o are cu alt tip de entitate este reprezentată prin mecanismul cheie primară/cheie străină.este tip de entitate slabă. unim cele două entităţi.Pe_scări . (2) Eliminarea relaţiilor complexe O relaţie complexă este o relaţie între mai mult de couă tipuri de entităţi. 113 .2. care să facă legătura dintre scări şi cheltuieli. când o relaţie este aparent redundantă. cât şi de tipul de entitate Cheltuieli. Cheia străină pentru o entitate este reproducerea cheii primare a altei entităţi. (6) Eliminarea relaţiilor redundante O relaţie este redundantă dacă se poate ajunge de la un tip de entitate la alt tip de entitate pe mai multe drumuri. Decizia că o relaţie este redundantă trebuie să fie precedată de o analiză amănunţită a relaţiilor care compun cele două drumuri dintre cele două entităţi. Vă amintim că noi vrem să ajungem la un model minimal şi deci relaţiile redundante nu sunt necesare. că tipul de entitate nou creat . putem descompune această relaţie. În acest limbaj. prin care un tip de entitate este în relaţie cu el însuşi. Crearea de relaţii peste modelul logic local Obiectivul: Crearea de relaţii peste modelul logic. Notăm. cheia primară devenind cheia primară al uneia dintre entităţi. (4) Eliminarea relaţiilor cu atribute Dacă în modelul conceptual avem relaţie cu atribute. (5) Reexaminarea relaţiilor de tipul 1:1 În modelul conceptual putem avea entităţi între care să avem relaţie de tipul 1:1. Dacă în modelul conceptual apar relaţii complexe. dar în realitate este nevoie de ea. (3) Eliminarea relaţiilor recursive Relaţiile recursive sunt nişte relaţii particulare. Se pot elimina prin crearea unui nou tip de entitate. precum şi/sau cheile străine. identificând un nou tip de entitate în care să înregistrăm atributele necesare. Diagrama acestor relaţii se vede în figura b). Î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. partea cu M a relaţiei fiind spre tipul de entitate nou creat. specificăm prima dată numele entităţii. acestea trebuie eliminate. trebuie înainte să identificăm entităţile “părinte” şi “fiu”. ea trebuie eliminată. urmat de atributele asociate între paranteze. Dacă apare o astfel de relaţie în modelul conceptual. Dacă suntem în acest caz. Se poate întâmpla ca aceste entităţi să fie de fapt aceeaşi entitate cu nume diferite. care să fie în relaţie de tipul 1:M cu fiecare tip de entitate din relatia iniţială.Desfiinţaţi relaţia dintre student şi note. Pentru a decide entităţiile unde vom include copia cheii primare a altei entităţi.

Tipurile de relaţii binare de tipul unu-la-multe 1:M Pentru toate relaţiile 1:M între două entităţi E1 şi E2 în modelul logic de date. cheia primară nu identifica unic o entitate. Dacă ambele tipuri de entitate participă parţial sau total la relaţie. În cazul în care participarea este totală. evidenţierea cheii străine. Apartament. putem identifica cheile prinare pentru toate tipurile de entităţi din modelul logic. Nr_pers_prezente. Valoare. Pentru atributele compuse al unei entităţi. Familii (Nr_mat. putem încerca să combinăm cele două tipuri de entităţi într-una singură. Exemple De exemplu descrierea tipului de entitate de mai sus se descrie astfel: Plăţi (Data. Tipul de entitate care participă parţial la relaţie este desemnat ca fiind “părinte” iar cel cu participare totală “fiu”. Scara. Nr_mat Cheie străină: Nr_mat se referă la Familii(Nr_mat) Descrieţi tabela catalog. Nr_chei) Cheie primară: Nr_mat Descrieţi relaţia dintre student şi catalog. Tipurile de relaţii binare de tipul unu-la-unu (1:1) Pentru fiecare tip de relaţie binară de tipul 1:1 între două tipuri de entitate E1 şi E2 găsim o copie a cheii primare a tipului de entitate E1 în compunerea tipului de entitate E2. Nr_bloc.Tipuri de entitaţi tari Pentru tipurile de entităţi tari în modelul logic crearea unei relaţii include toate atributele entităţii. Această compunere poate să fie posibilă în cazul în care nici unul dintre cele două tipuri de entităţi nu mai ia parte la altă relaţie. Nume. iar cealaltă entitate “fiu”. Tipurile de entităţi slabe Descrierea tipurilor de entităţi slabe se face la fel ca şi tipurile de entităţi tari. La terminarea acestui pas. Totdeauna entitatea de partea unu a relaţiei este considerată entitate “părinte”. vom include numai atributele simple din compunerea atributului compus în descrierea entităţii. Deci înainte de introducerea cheii străine. Atributele cu mai multe valori 114 . Nr_pers. Exemple De exemplu tipul de entitate Familii. cu o completare şi anume. Etaj. prezentată în figură se descrie în următorul mod. Menţionăm că în cazul acesta cheia străină este şi în compunerea chei primare. atunci tipurile de entităţi se pot evidenţia ca fiind “părinte” sau “fiu” arbitrar. Restanţă) Cheie primară: Data. Identificarea tipului de entitate “părinte” şi a tipului de entitate “fiu” depinde de participarea entităţilor la relaţie. sub denumirea de cheie străină. Nr_mat. vom avea copia cheii primare a entităţii E1 în compunerea entităţii E2.

Cheia primară a noii relaţii va fi atributul A. utilizând tehnica normalizării. Pasul 2. o relaţie. Trebuie să examinăm dacă baza de date suportă tranzacţiile cerute. utilizând normalizarea Obiectivul: Validarea modelului logic. Normalizarea este procesul prin care se decide dacă atributele pot sau nu să rămână înpreună.  Calculatoarele moderne au mult mai multă putere de calcul. relaţiile. cheile primare şi străine. încercăm să rezolvăm manual cerinţele utilizatorilor. compunerea ei cu cheia primară al lui E1. Validarea modelului prin tranzacţii Obiectivul: Verificarea ca modelul de date suporte toate tranzacţiile cerute de utilizator. Există posibilitatea ca unele tipuri de entităţi să se denormalizeze. sau o entitate din modelul de date. Deci acest proces este situat undeva între proiectarea conceptuală şi cea fizică. Dacă nu putem rezolva o tranzacţie. Validarea.2. Totuşi normalizarea nu este un timp pierdut. sau dacă este necesar. Pasul 2. Examinăm procesul de normalizare după cum am descris în capitolul 5 Prin normalizare trebuie să demonstrăm că modelul creat este consistent. Proiectul fizic poate fi diferit. atuci înseamnă că modelul creat este valid. Exemple De exemplu să luăm relaţia dintre Furnizori şi Cheltuieli exemplificată în figură 115 . El ajută priectantul să înţeleagă natura datelor în întreprindere. Luând în considerare tipurile de entităţi.  Normalizarea produce o bază de date care va fi uşor extensibilă în viitor. câteodată este mai convenabilă implementarea unei baze de date cu puţină redundanţă.  Proiectul logic nu este un proiect final. Conceptul de bază a teoriei relaţiilor este că atributele sunt grupate împreună pentru că există o relaţie logică între ele. întroducând fiacare atribut nou introdus în compunerea unei chei la acest pas.. creăm o nouă relaţie care va conţine atributul A împreună cu cheia primară a entităţii E1 pe post de cheie străină.  Proiectul normalizat este robust şi independent de anomaliile de actualizare prezentate înunitatea de învăţare anterioară. ca cele de acum câţiva ani. decât suportarea cheltuielilor pentru procedurile adiţionale.Pentru ficarea atribut A care permite mai multe valori din entitatea E1 în modelul logic de date.3. Din această cauză. În acest pas se validează baza de date prin verificarea tranzacţiilor ce se cer de catre utilizator. Câteodată baza de date nu este cea mai eficientă. Dacă reuşim să rezolvăm fiecare tranzacţie cerută. conţine redundanţă minimală şi are stabilitate maximă. Documentarea relaţiilor şi a atributelor din cheile străine Actualizăm dicţionarul de date. atunci este foarte posibil să fi omis un atribut. Mai întâi ar fi prin rezolvarea de tranzacţii. Acesta se argumentează prin următoarele:  Proiectarea normalizată organizează datele în funcţie de dependenţele funcţionale.

 integritatea entităţilor. Obiectivul: Identificarea regulilor de integritate pentru vederile utilizatorilor asupra întreprinderii. Pasul 2. A doua modalitate de verificare trebuie folosită în cazul în care avem entităţi care nu iau parte direct la nici o tranzacţie. Ştergerea detaliilor despre un furnizor Se caută codul furnizorului de şters. pentru a putea vedea mai uşor ce reguli sunt necesare. Dacă există deja codul. Inserarea de detalii despre un nou furnizor. după care.  regulile întreprinderii. 116 . Dacă este necesar. nu admit inserarea.6. când am documentat atributele în pasul 1. care este reprezentarea logică a vederilor utilizatorilor aspra întreprinderii. De exemplu fiecare cheltuială înregistrată trebuie să aibă asociat un furnizor al serviciilor sau al obiectelor ce se plătesc prin acea cheltuială. actualizându-se şi cheia străină în entitatea Cheltuieli. inserez detaliile despre furnizor.  reguli asupra domeniului atributelor.  integritatea referinţelor. Cheia primară al acestei entităţi este Nr_furnizor. Aceste reguli deja le-am identificat. Pot verifica şi existenţa codului fiscal. Pasul 2. putem produce un proiect fizic de bază de date. Regulile de integritate sunt importante pentru a proteja baza de date împotriva posibilelor inconsistenţe. Identificarea regulilor de integritate. care pentru această entitate este cheie alternantă. în caz că nu există acest cod. Desenarea diagramei ER. Obiectivul: Desenarea diagramei Entity-Relationship. Necesitatea datelor Există atribute care nu pot conţine valoarea nulă. vom verifica nişte interogări pregătie special. Provoaca Dar mai bine se descriu tranzacţiile prin fraze SQL.5. Dacă nu există codul cerut. atunci apare un mesaj de eroare şi nu este şters nici un furnizor.Cheltuieli Nr_Crt Cod_Furnizor (FK) Cod_cheltuiala Nr_factura Data_factura Valoare_factura Furnizori Cod_Furnizor Denumire Cod_fiscal (AK1) Cont Banca Strada Nr Bl Sc Ap Localitate Judet Exemplu de relaţie pentru validarea prin tranzacţii.3. ci trebuie să aibă totdeauna o valoare. Vom considera cinci tipuri de reguli de integritate:  necesitatea datelor. Dacă există se şterge furnizorul. Deci prima dată verific dacă numărul introdus nu există deja. Pentru verificarea acestor entităţi.

integritatea referinţelor se strică în cazul în care există entităţi în tipul de entitate “fiu”. dacă acesta este referit de o entitate din tipul de entitate fiu. dacă el are o factură de încasat. Domeniile de definiţie au fost deja identificate când am documentat domeniile atributelor în pasul 1. atunci trebuie să găsim un furnizor care să aibă acel cod. ea trebuie neapărat să se regăsească şi în tipul de entitate “părinte”. dacă cheia străină conţine o valoare. Integritatea referinţelor Cheia străina din tipul de entitate “fiu” face ligătura cu o entitate din tipul de entitate “părinte”. Cazul 2: Ştergerea unei entităţi din tipul de entitate “fiu” (Cheltuieli): Ştergerea unei entităţi din tipul de entitate “fiu” nu creează probleme la integritatea referinţelor.5.Reguli asupra domeniului atributelor. care este de tipul 1:M. Aceste reguli au fost deja identificate. În exemplul nortru.2. verificăm dacă atributele din componenţa cheii străine (Cod_furnizor) sunt vide. când am documentat cheile primare în pasul 1. sau să existe entitate în tipul de entitate “părinte” care să aibă valoare cheii primare egală cu valoare cheii străine. În cazul nostru. Cheia primară a entităţilor nu poate lua valori nule. nu se acceptă ştergerea furnizorului. Există strategii severe de a rezolva integritatea referinţelor:  FĂRĂ ACŢIUNE Neacceptarea ştergerii unei entităţi din tipul de entitate părinte. În general dacă pariciparea tipului de entitate “fiu” este totală. Integritatea entităţilor. Prima întrebare pe care trebuie să ne-o ponem este: Poate fii cheia străină nulă? În cazul exemplului nostru asta ar însemna că există cheltuieli care nu se prătesc nimănui. se şterg automat toate entităţiile din tipurile de entităţi fiu. dacă se şterge un furnizor. 117 . Cu alte cuvinte. Unele atribute au un domeniu de definiţie bine definit. atunci se vor seta la valoare nulă toate referinţele la acest furnizor în tipul de entitate Cheltuieli. Considerăm următoarele cazuri: Cazul 1: Inserarea unei entităţi în tipul de entitate “fiu” (Cheltuieli): Pentru a verifica integritatea referinţei. deci nu putem avea valoare nulă în cheia străină din tipul de entitate Cheltuieli. atunci automat se şterge fiacare factură pe carea are de încasat acest furnizor. atunci se vor seta la valoare nulă toate cheile străine ai tipurilor de entităţi fiu în cascadă până la ultimul nivel. folosim relaţia de mai sus dintre Furnizori şi Cheltuieli. Dacă tipurile de entităţi fiu au şi ei la rândul lor alte tipuri de entităţi fiu. care se referă la entitatea ştearsă.  CASCADĂ Dacă o entitate din tipul de entitate părinte este ştearsă. se va efectua ştergerea în cascadă în toate tipurile de entităţi fiu.  SETARE LA NUL Dacă o entitate din tipul de entitate părinte se şterge. până la ultimul nivel. Cazul 4: Stergerea unei entităţi din tipul de entitate “părinte” (Furnizori): Dacă se şterge o entitate din tipul de entitate “părinte”. atunci nu putem avea valoare nulă în cheia străină. Dacă această cheie nu este nulă. Aceste domenii trebuie respectate. Aceste cazuri nu sunt admise de lege. Acesta înseamnă că nu vom ştii ca anumite cheltuieli la ce furnizor trebuie plătite. De exemplu tipul de entitate Cheltuieli conţine cheia străină Cod_furnizor. De exemplu fiecare furnizor trebuie să aibă un cod diferit de zero. În caz contrar putem avea valoare nulă. care se referă la Furnizori(Cod_furnizor). Deci. Cazul 3: Actualizarea cheii străine în tipul de entitate “fiu” (Cheltuieli): Acest caz este similar cazului 1. Pentru a demonstra diferitele cazuri la definirea acestor reguli. dacă se şterge un furnizor.

 Pasul 2.2.2.  Pasul 2.6. Regulile întreprinderii.1. După combinarea modelelor locale.5. ne vom reîntoarce la paşii anteriori şi modificăm cele necasare.3.de exemplu cu numele de “Furnizor şters”. Documentarea tuturor regulilor de integritate. La acest pas modelul local logic este clomplet şi este bine documentat.  Pasul 2. Activităţile din acest pas sunt:  Pasul 3. Acest proces este foarte important în proiectarea bazei de date. Verificarea posibilităţii de a completa baza de date în viitor. Crearea şi validarea modelului global logic de date. să fie conform cu realitatea. 118 . Pasul 2. care să conţină un furnizor predefinit . şi 2. Obiectivul: Convingerea că modelul creat reprezintă în totalitate realitatea care trebuie modelată în baza de date. Validarea modelului.7. Înainte de a trece la pasul 3.7. se pot folosii toate cazurile descrise mai sus.3. Acest proces utilizează aceleaşi tehnici pe care le-am descris la paşii 2.. prin tehnica tranzacţiilor. trebuie verificat modelul. Definirea regulilor de integritate ale bazei de date. Validarea modelului logic global.3. În cazul în care se găsesc diferenţe. integritatea referinţelor se strică. Crearea relaţiilor pentru modelul logic local. A treia activitate majoră în proiectarea bazei de date logice este crearea modelului logic global. Cazul 6: Modificarea cheii primare în tipul de entitate părinte (Furnizori): Dacă se modifică cheia primară din tipul de entitate părinte.2.1. Verificarea modelului logic local cu ajutorul utilizatorului.. Validarea modelului din nou.  Pasul 3. Obiectivul: Combinarea modelelor locale logice într-un model logic global care să reprezinte întreprinderea care este modelată.2. Compunerea medelelor logice locale într-un model logic global. Desenarea diagramei ER. cu diferenţa că aici se setează cheia străină la o valoare implicită în loc de valoare nulă.  Pasul 2. SETARE IMPLICITĂ Este analog cazului de setare la nul. pentru că el demonstrează că reprezentarea întreprinderii este independentă de orice utilizator. nu se actualizează deloc cheile străine din tipurile de entităţi fiu.  FĂRĂ MODIFICARE În cazul ştergerii unei entităţi din tipul de antitate părinte. Să ne reamintim.  Pasul 3. utilizând normalizarea. dar cel mai indicat este folosirea cazului CASCADĂ. În final evidenţiem acele reguli care sunt date de realitatea ce se va modela în baza de date. prin compunerea tuturor modelelor locale.  Pasul 2. În exemplul nostru putem seta cheia străină din Cheltuieli la o valoare a cheii primare din Furnizori. Verificarea modelului logic local cu ajutorul utilizatorului. utilizând tranzacţiile. funcţie sau aplicaţie. Activităţile proiectării logice locale sunt:  Pasul 2. Pentru menţinerea integrităţii. Trecem toate regulile de integritate în dicţionarul de date. trebuie validat modelul global prin tehnica de normalizare şi după aceea. Pasul 3.  Pasul 2. Proiectarea modelului conceptual local pe un model logic local.

dar nu au aceleaşi nume. cu puţine vederi ai utilizatorilor. (2) Verificarea numelor relaţiilor. În astfel de situaţii. dar cu chei primare diferite. Dacă într-un view apare un atribut compus. În cazul unui sistem mic. iar într-un alt view acelaşi atribut dar descompus în atribute simple. (5) Compunerea relaţiilor de pe view-urile locale. Obiectivul: Compunerea tuturor modelelor logice locale într-un model logic global al întreprinderii. Această activitate este asemănătoare celei descrise la entităţi. Atributele care apar în entităţile de pe ambele view-uri. (10) Desenarea modelului logic global. Pasul 3. şi deci pot fi compuse. (1) Verificarea numelor entităţilor şi a cheilor lor primare. (3) Compunerea entităţilor de pe view-urile locale. utilizatorii pentru a decide asupra formei de utilizare a atributului. Compunerea entităţilor care au aceleaşi nume şi aceleaşi chei primare. În cazul unui sistem mai mare însă. vor fi trecute doar o singură dată. Pasul 3. pentru a identifica entităţile echivalente. Cel mai uşor de compus mai multe modele locale este compunerea succesivă a două câte două dintre modele. În general entităţile cu aceleaşi chei primare reprezintă “lumea reală”.  Două entităţi sunt aceleaşi. atunci vom întreba. (7) Căutarea entităţilor şi a relaţilor care lipsesc (dacă există).1. Probleme apar doar atunci când:  Două entităţi au acelaşi nume. (4) Includerea (fără compunere) a entităţilor care apar pe doar una dintre view -uri. (8) Căutarea cheilor străine.  Pasul 3. Compunerea modelelor logice locale într-un model logic global. căutăm două entităţi care au aceleaşi nume şi nu au aceleaşi chei primare. (3) Compunerea entităţilor de pe view-urile locale. Desenarea diagramei ER finale. Această verificare se face folosind şi dicţionarul creat în decursul paşilor de dinainte.  Compunerea entităţilor care au nume diferite. restul rămănând chei alternante. prntru a rezola această problemă. (9) Căutarea regulilor de integritate. În particular. 119 . Paşii acestui proces sunt următoarele: (1) Verificarea numelor entităţilor şi a cheilor lor primare.2.  Compunerea entităţilor care au aceleaşi nume. (6) Includerea (fără compunere) a relaţilor care apar pe doar una dintre view -uri. Compunerea entităţilor care au aceleaşi nume. Cele două entităţi pot fi compuse. Probabil va fi necesară analizarea atributelor antităţilor. trebuie să urmăm un proces sistematic de realizare a modelului global. Examinăm numele şi atributele entităţilor ca vor fi compuse. putem utiliza cheia primară şi numele entităţii. (11) Actualizarea documentaţiei. dar au aceleaşi chei candidat. dar au chei primare diferite.5. (2) Verificarea numelor relaţiilor. dar sunt de fapt diferiţi. cu chei primare egale sau diferite. este relativ uşor de a compune modelele logice locale. dacă se poate. Verificarea modelului logic global cu ajutorul utilizatorului. urmând ca după compunere să alegem o cheie primară. Activităţile care se includ în acest pas sunt:  Compunerea entităţilor cau au aceleaşi nume şi aceleaşi chei primare.

În acest moment modelul global este complet şi documentat. care s-au omis la paşii anteriori şi n-au ajuns în modelul global. Obiectivul: Validarea modelului global logic de date. (4) Includerea (fără compunere) a entităţilor care apar doar într-un view. Putem compune relaţii care au aceleaşi nume şi acelaşi scop. (5) Compunerea relaţiilor de pe modelele locale. după care folosind tranzacţile cerute. dar nume diferite. chei primare şi chei străine. (6) Includerea (fără compunere) a relaţiilor care apar doar pe un view. Pasul 3. folosind normalizarea. s-au modificat entităţi. Obiectivul: Determinarea ca dacă modelul se acomodează uşor la modificări oricât de mari ce pot intervenii în viitor. Pasul 3.Compunerea entităţilor care nu au nume comune şi nu au aceleaşi chei primare. Desenarea diagramei Entity-Relationship finale. În acest pas analizăm similitudinile dintre relaţii de pe diferite modele locale. Acum desenăm diagrama ER pentru modelul global de date. se vor include în modelul logic global exact aşa cum apar în view-ul respectiv. viaţa lui poate fi scurtă şi pentru o mai mare modificare va trebui refăcută de la început. Obiectivul: Verificarea că modelul global reprezintă în totalitate realitatea.2. Este unul din cei mai grei paşi din crearea modelului global. Verificarea modelului global cu ajutorul utilizatorului. (11) Actualizarea documentaţiei. Verificarea posibilităţilor de extindere a bazei de date în viitor. ca şi regulile de cardinalitate şi participare. Fiecare problemă de acest gen se rezolvă cu ajutorul utilizatorului sistemului. Celelalte entităţi.5. Relaţile care au rămas neincluse în modelul global după pasul anterior. În timpul compunerii relaţiilor trebuie rezolvate şi conflictele dintre relaţii. Pasul anterior identifică toate entităţile comune. Obiectivul: Desenarea unei diagrame ER. Validarea modelului logic global. sau acelaşi scop. Acest pas este schivalent cu paşii 2. În decursul paşilor anterioare.. Pasul 3.4. (9) Căutarea regulilor de integritate Verificăm dacă regulile de integritate a modelului global nu sunt în conflict cu regulile definite la modelele locale. (7) Căutarea entităţilor şi relaţilor care lipsesc.3. Este important ca modelul creat să fie expansibil în viitor. Trebuie căutate acele entităţi şi relaţii. Dacă modelul nu are această calitate. Actualizăm documentaţia. 120 . (10) Desenarea diagramei ER. (8) Căutarea cheilor străine. Împreună cu utilizatorul sistemului se verifică acest model şi se aduc eventualele corecturi prin întoarcerea la paşii în cauză. În acest pas verificăm dacă cheile străine sunt corecte în fiecare entitate fiu şi efectuăm toate modificările necesare. Pasul 3.3. ca să reflecte toate modificările aduse în acest pas modelului. se includ în modelul global fără modificare. care să reprezinte modelul global de date al întreprinderii. Aceste entităţi se pot depista prin analiza atributelor celor două entităţi. unde am validat modelul local de date.4. şi 2.

Desenarea diagramei ER finale. utilizând normalizarea.U5. Răspunsurile se găsesc la sfârşit la pag 158 121 . Test de autoevaluare a cunoştinţelor 5. Verificarea modelului logic global cu ajutorul utilizatorului.5.  Pasul 3. Compunerea medelelor logice locale într-un model logic global.  Pasul 3.  Pasul 3.2.1.2.Să ne reamintim.  Pasul 2.5.1.  Pasul 3. M5. Proiectarea modelului conceptual local pe un model logic local.7.2.1. Validarea modelului logic global.3.  Pasul 3.  Pasul 2. Activităţile proiectării logice globale sunt:  Pasul 3.  Pasul 2. Validarea modelului din nou. Definirea regulilor de integritate ale bazei de date.  Pasul 3. Rezumat Activităţile proiectării logice locale sunt:  Pasul 2. Verificarea posibilităţii de a completa baza de date în viitor.2.  Pasul 2..2.3. utilizând tranzacţiile. Desenarea diagramei ER finale. Validarea modelului.2.2.U5.5.6.3. Compunerea medelelor logice locale într-un model logic global. M5.  Pasul 3.1 Faceţi proiectul logic local pentru subsistemul didactic al facultăţii. Desenarea diagramei ER. Verificarea posibilităţii de a completa baza de date în viitor. Validarea modelului logic global.2.  Pasul 3. Crearea relaţiilor pentru modelul logic local.2..  Pasul 2. Verificarea modelului logic global cu ajutorul utilizatorului. Verificarea modelului logic local cu ajutorul utilizatorului.  Pasul 2. Activităţile proiectării logice globale sunt:  Pasul 3.

). planificarea sarcinilor de către sistemul de operare. măsurat în momentele de vârf ale încărcării. M5. cele mai potrivite cu cerinţele de proiectare a sistemului de baze de date. gruparea înregistrărilor corelate în aceleaşi blocuri pe disc (clustering). După alegerea sistemului SGBD.3 Introducere Proiectarea fizică a bazei de date este procesul de alegere a structurilor de memorare şi de acces a fişierelor bazei de date.). se sciu programele care dau cereri.3. Fiecare SGBD oferă o varietate de opţiuni de organizare a fişierelor şi a modului de acces la datele stocate: indexuri.U5. dar există şi factori care nu se află sub controlul acestuia (viteza de operare a procesorului. Acesta este numărul mediu de tranzacţii care pot fi prelucrate pe minut de către sistemul de baze de date. Ca parametri generali de alegere a opţiunilor proiectului fizic al unei baze de date relaţionale se pot enumera: Timpul de răspuns. M5U5. formulare şi rapoarte. principale. etc. Capacitatea tranzacţionala (transaction throughput). De asemenea. Acesta este intervalul de timp dintre lansarea i execuţie a unei tranzacţii şi primirea răspunsului la acea tranzacţie. Utilizarea spaţiului de memorare. Aceasta este dimensiunea spaţiului pe disc utilizat de fişierele bazei de date şi de structurile de acces l date. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:      aleagă. timpi: de comunicaţie. SGBD-ul cel mai potrivit. rezervări de bilete. în particular în acele aplicaţii în care există un număr mare de utilizatori care accesează concurent baza de date (aplicaţii bancare.3 Proiectarea fizică. etc. pentru cât mai multe din aplicaţiile proiectate.Unitatea de învăţare U5. 122 . etc. dimensiunea memorie. tabele de dispersie (hashing). în cunoştinţă de cauză. descrie corect structura fizică a bazei de date proiecteze cereri proiecteze formulare proiecteze rapoarte Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore. Cea mai mare pondere în timpul de răspuns o are execuţia operaţiilor în sistemul SGBD. în această fază. în faza de proiectare fizică a bazei de date se aleg structurile fişierelor bazei de date dintre cele oferite de sistemul de gestiune respectiv. pentru a obţine performanţe cât mai bune. Acesta este un parametru critic în multe aplicaţii.

Tot în faza de proiectare fizică se poate rafina procesul de normalizare a relaţiilor. • Atributele ale căror valori se modifică în cursul operaţiilor de actualizare. Analiza constrângerilor de timp ale interogărilor trebuie să evidenţieze care dintre interogări şi tranzacţii trebuie să se termine într-un anumit interval de timp. De exemplu. pentru volume mari de prelucrări. se efectuează o denormalizare a unor relaţii. împreună cu listele de atribute care intervin în interogări şi tranzacţii. permit obţinerea unei situaţii globale privind frecvenţa estimată de accesare a atributelor relaţiilor. Deciziile de proiectare fizică se pot lua numai după o analiză a aplicaţiilor care se vor executa şi în principal a interogărilor şi tranzacţiilor pe care acestea le vor lansa. Astfel de atribute sunt candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare) care să accelereze operaţiile de interogare. se fac diferite evaluări analitice sau măsurători experimentale (prototipuri. Pentru compararea valorilor acestor parametri. simulări). corespunzătoare diferitelor decizii de proiectare fizică. Atributele pe care sunt specificate condiţii de selecţie pentru operaţii de ştergere sau actualizare. Astfel de constrângeri pot fi folosite pentru a adăuga priorităţi suplimentare atributelor candidate pentru indexare. în continuare se vor prezenta câteva aspecte ale analizei interogărilor şi tranzacţiilor necesare pentru a stabili opţiunile proiectului fizic al unei baze de date relaţionale. trebuie să fie specificate valorile medii şi limitele în cazurile cele mai defavorabile ale acestor parametri în cadrul cerinţelor de performanţe ale sistemului. Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de: Definirea datelor Gestiunea cheilor primare Specificarea cheilor străine Tipuri de date disponibile Extensibilitatea tipurilor de date Specificarea domeniilor Uşurinţa restructurării Mecanism de tabele derivate Controlul integrităţii Dicţionar de date Independenţa datelor Tipul de model de date utilizat Accesibilitate 123 . Atributele de selecţie utilizate de interogări şi tranzacţii cu constrângeri de timp devin candidate cu mare prioritate pentru indexare. Analiza frecvenţei estimate de invocare a interogărilor şi a tranzacţiilor. De aceea. atributele care sunt conţinute în condiţiile de interogare şi atributele comune a două sau mai multe relaţii pe care se execută joncţiunile. Analiza atributelor accesate de interogări şi tranzacţii trebuie să evidenţieze: Atributele de proiecţie. La fel ca mai sus. Această regulă stipulează că 80% din operaţiile de prelucrare sunt executate în 20% din interogările şi tranzacţiile tuturor aplicaţiilor implementate. Pentru o schemă conceptuală dată există o multitudine de alternative ale proiectului fizic pentru un SGBD dat.In mod obişnuit. adică se combină două sau mai multe relaţii existente într-o singură relaţie cu un grad de normalizare mai redus. în general. folosind informaţiile de frecvenţă a invocării interogărilor şi tranzacţiilor şi constrângerile de timp impuse unora dintre acestea. bineînţeles. Odată cu denormalizarea unor relaţii trebuie să se prevadă şi procedurile necesare (care depind de SGBD) pentru verificarea datelor şi evitarea anomaliilor. în care apar. în general. o tranzacţie trebuie să se termine în mai puţin de 5 secunde în 95% din cazuri şi să nu depăşească niciodată durata de 20 de secunde. 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 operaţie de actualizare a relaţiilor. în cazurile practice nu sunt necesare statistici exhaustive ale frecvenţelor de invocare a tuturor interogărilor şi a tranzacţiilor. date redundante şi sunt posibile anomalii de actualizare. se respectă regula "80-20". astfel de atribute sunt candidate pentru definirea unor structuri suplimentare de acces (indexuri secundare). pentru obţinerea unor timpi de răspuns mai mici pentru unele interogări. ci este suficient să fie determinate cele mai importante 20% dintre acestea.

declanşatoare Instrumente de dezvoltare Web Controlul tranzacţiilor Rutine de salvare şi restaurare Puncte de salvare intermediare Suport pentru jurnalizare Granularitatea accesului simultan Strategia de rezolvare a interblocajelor Procesare paralelă a interogărilor Definirea fizică Structuri fizice disponibile întreţinerea structurii de fişiere Uşurinţa reorganizării Indexare Atribute/înregistrări de mărime variabilă Compresia datelor Rutine de criptare Cerinţe de memorie Alte facilităţi/opţiuni Evolutivitate Stabilitatea furnizorului Baza de utilizatori Pregătire şi suport pentru utilizatori Documentare Sistem de operare cerut Cost Help oniine Standarde utilizate Managementul versiunilor Optimizare a interogărilor Scalabilitate Suport pentru instrumente OLAP Interoperabilitate cu alte SGBD Integrare Web Utilitare de replicare Facilităţi de distribuire Portabilitate Cerinţe hardware Suport pentru reţea Facilităţi de orientare pe obiect Arhitecturi pe două. straturi Performanţă Rata de tranzacţii pe secundă (minut) 124 ...Suport pentru standardele SQL Interfaţă cu 3GL Mulţi utilizator Securitate: controlul accesului mecanism de autorizare Utilitare Măsurarea performanţei Acordare (run/ng)/optimizare Facilităţi de încărcare/descărcare Suport pentru administrarea BD Dezvoltare Instrumente 4GL Instrumente CASE Facilităţi vizuale Proceduri de stocare. trei.

Proiectarea regulilor de acces la baza de date. în ACCESS.3.U5. Introducerea unei redundanţe comntrolate. Pasul 9.2.1.Număr maxim de utilizatori simultani Suport pentru XML M5.1. Pasul 10. Pasul 9. proiectul fizic al subsistemului didactic al facultăţii.5. Alegerea indecsilor secundari. Proiectarea fizică şi implementarea bazei de date relaţionale: Translatarea modelului logic global în SGBD. Pasul 11. Utilitare. Crearea view-urilor pentru utilizatori. Rezumat Pasul 8. Alegerea sistemului de gestiune al bazei de date rebuie să ţină cont de calităţile SGBD-ului legatede Definirea datelor. Pasul 8.4. Crearea regulilor de integritate în SGBD. Proiectarea şi implementarea unui mecanism de securitate. Pasul 9.U5. Estimarea spaţiului pe disc. Pasul 9. Pasul 9. Pasul 10.2. Proiectarea relaţiilor de bază în SGBD. Pasul 9. Accesibilitate.1 Realizaţi. Răspunsurile se găsesc la sfârşit la pag 160 125 . Pasul 8. Test de autoevaluare a cunoştinţelor 5.3. Proiectarea şi implementarea reprezentării fizice.3.2. Dezvoltare.3. Alegerea organizării fişierelor. Pasul 10. Definirea fizică şi Alte facilităţi/opţiuni M5. Verificarea sistemului operaţional. Analizarea tranzacţiilor.1.

Putem avea următoarele tranzacţii: Exemple 5. salariu) Proprietate = (nrprop. Fie schemele: Personal = (nrmat.1 scrie (nrmat = x.4 Tranzacţii şi concurenţă M5 U5.1 cit (nrmat = x. Tranzacţia este o acţiune sau o serie de acţiuni. Nu există reguli de stabilire automată a acestei unităţi. stradă. orice execuţie a unui program care accesează o bază de date poate fi considerată o tranzacţie.4 Introducere O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă (atomică) a datelor unei baze de date prin care se asigură consist enţa acesteia.4.Unitatea de învăţare U5.U5. nrmat) care leagă proprietatea de o persoană prin nrmat printr -o relaţie de cardinalitate n la 1. M5. tip. salariu) care măreşte salariul cu 10%  126 . În principiu.4. Tranzacţia este o unitate logică de lucru a bazei de date. salariu) salariu = salariu * 1. oraş. Pentru a demonstra acest concept o să dăm următoarele exemple. O'tranzacţie trebuie să asigure consistenţa bazei de date indiferent dacă a fost executată individual sau concurent cu alte tranzacţii precum şi în condiţiile în care au apărut defecte ale sistemului hardware în cursul execuţiei tranzacţiei. care accesează sau schimbă conţinutul bazei de date. nume. executate de un singur utilizator sau un program. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  construiască tranzacţii corecte Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore. adresă. dacă baza de date este într-o stare consistentă atât înainte cât şi după execuţie.

Deşi nu avem reguli automate pentru construcţia tranzacţiilor ele trebuie să respecte proprietăţile ACID. Dacă tranzacţia nu s-a terminat cu succes atunci. trei exemple în care arătăm cum se poate pierde cinsistenţa. Prezentăm în continuare. Găsim astfel cuvintele cheie cu semnificaţie imediată BEGIN TRANSACTION. se pierde timp când calculatorul stă să aştepte terminarea unei operaţii de intrare/ieşire. că tranzacţia face ‘roll back’ este derulată înapoi.2 cit (nrmat =x ) şterge (nrmat = x ) pentru toate înregistrările din Proprietate begin cit ( nrprop. nrmat) dacă (nrmat = x ) atunci şterge (nrprop) end care şterge persoana x şi toate proprietăţile ei O tranzacţie trebuie să transforme întotdeauna baza de date dintr-o stare consistentă într-o altă stare tot consistentă. ea este întreruptă şi. dar o tranzacţie întreruptă poate fi reluată mai târziu şi atunci s-ar putea să se termine cu succes.4. O tranzacţie este o unitate indivizibilă care se execută în întregime sau deloc. COMMIT. Tranzacţia T2 citeşte contul lui x (balx) şi adună 100 la cont. dacă lăsăm să lucreze deodată. atunci spunem că tranzacţia a făcut ‘commit’ şi baza de date a trecut în noua stare consistentă.  Independenţă o tranzacţie se execută inependent de oricare alta. în acest caz . ROLLBACK. Să considerăm următorul plan de tranzacţii.Exemple 5.  Consistenţă o tranzacţie trebuie să transforme baza de date dintr-o formă consistentă într-o altă formă tot consistentă. fiecare în timpul lăsat liber de cel din nainte. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Concurenţa va mări randamentul timpului de lucru al calculatorului dar ea trebuie controlată pentru că altfel poate da naştere la inconsistenţă. Un SGBD trebuie să aibă posibilitatea de a defini şi mânui tranzacţii. În primul exemplu tranzacţia T 1 citeşte contul lui x (bal x) şi scade 10 din cont. Pornind cu un cont de 100. Spunem. baza de date trebuie să fie readusă în starea consistentă în care era înainte să înceapă tranzacţia. evident că dacă se executa mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 100-10+100=190. zicem că avem tranzacţii concurente. adică efectele parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie. Proprietăţile tranzacţiilor.  Atomicitate este proprietatea ‘totul sau nimic’. Dacă fiecare tranzacţie lucrează pe rînd. 127 .  Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior. O tranzacţie se poate termina în două moduri. O tranzacţie care a făcut ‘commit’ nu mai poate fi întreruptă. sau în timpul altei întreruperi. Pe de altă parte. în acest caz. Dacă tranzacţia s-a terminat cu succes.

De exemplu tranzacţiile T5 şi T6 executate serial.Un plan de tranzacţii este o secvenţă posibilă în timp a modului de execuţie a tranzacţiilor. Putem observa. ar trebui să dea rezultatele: T5T6 balx=100-10=90.4. Problema dependenţei de o tranzacţie neterminată apare când o tranzacţie este lăsatăsă ‘vadă’ rezultatele intermediare alei alte tranzacţii înainte ca ea să facă ‘commit’. Aceleaşi tranzacţii ca în figura precedentă se desfăşoară acum după un alt plan. aţi putea spune că este bun. balx=100-10=90. cum evoluează contul din ultima coloană. Chiar şi când unele tranzacţii numai citesc baza de date se pot întâmpla neplăceri.3 Time T1 A t1 A t2 A t3 A t4 A t5 A t6  Problema se numeşte problema pierderii actualizării. Exemple 5.4. dar ţineţi cont că tranzacţia 4 a fost întreruptă şi.10 scrie(bal x) commit T4 begin_transaction cit(bal x) bal x = balx + 10 scrie(bal x) rollback balx 100 100 100 200 200 100 190 190 begin_transaction cit(bal x) bal x = balx . balz=25+10=35. în timpii înscrişi în stânga. va mai mări cu 100 contul ceea ce va deveni incorect. balz=25+10=35 şi putem vedea în figura următoare ce se poate întâmpla încazul concurenţei libere. adică una după alta. sum=90+50+35+175 sau T6T5 sum=100+50+25=175. Exemple 5.4 Time T3 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 T2 begin_transaction cit(bal x) bal x = balx + 10 scrie(bal x) commit balx 100 100 100 200 90 90 begin_transaction cit(bal x) bal x = balx . necontrolate: 128 . Această problemă este problema analizei inconsistente sau problema ‘citirii murdare’. când se va relua.10 scrie(bal x) commit Rezultatul este 190.

Exemple 4. lăsa concurenţa necontrolată. adică între operaţiile unei tranzacţii se intercalează operaţiile alteia. 129 . acesta se va numi serializabil. dar nici nu este profitabil să o desfiinţăm de tot.5 Time T5 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 T6 balx baly 50 50 50 50 50 50 50 50 50 50 50 balz 25 25 25 25 25 25 25 35 35 35 35 sum begin_transaction 100 begin_transaction sum = 0 100 cit(bal x) cit(bal x) 100 bal x = balx sum = sum + 100 10 balx scrie(bal x) cit(bal y) 90 cit(bal z) sum = sum + 90 baly bal z = balz + 90 10 scrie(bal z) 90 commit cit(bal z) 90 sum = sum + 90 balz commit 90 0 0 100 100 150 150 150 150 185 185 Nu putem. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una după alta fără a intercala operaţii din altă tranzacţie. Aveţi deja exemple de planuri neserializabile. Spunem că un plan de tranzacţii este neserial când tranzacţiile sînt concurente . deci. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat acelaşi cu unul executat serial.4.

Tranzacţiile trebuie să respecte proprietăţile ACID.1 Daţi exemple de pierdere a consistenţei. Rezumat  Tranzacţia este o acţiune sau o serie de acţiuni. adică între operaţiile unei tranzacţii se intercalează operaţiile alteia. adică efectele parţiale ale unei tranzacţii incomplete nu trebuie să influenţeze o altă tranzacţie. Spunem că un plan de tranzacţii este neserial când tranzacţiile sînt concurente .  Consistenţă o tranzacţie trebuie să transforme baza de date dintro formă consistentă într-o altă formă tot consistentă.M5.  Problemele concurenţei fără control sunt: problema pierderii actualizării. care accesează sau schimbă conţinutul bazei de date.  Atomicitate este proprietatea ‘totul sau nimic’.  problema dependenţei de o tranzacţie neterminată  problema analizei inconsistente sau problema ‘citirii murdare’.U5.U5.4. Vom spune că un plan de tranzacţii este corect atunci când el are ca rezultat acelaşi cu unul executat serial. Răspunsurile se găsesc la sfârşit la pag 161 130 . O tranzacţie este o unitate indivizibilă care se execută în întregime sau deloc.4 Test de autoevaluare a cunoştinţelor 5.  Durabilitate efectele unei tranzacţii terminată cu succes sunt definitiv înregistrate în baza de date şi nu se mai pot pierde în tranzacţiile întrerupte ulterior.  Independenţă o tranzacţie se execută inependent de oricare alta. M5. Spunem că un plan de tranzacţii este serial cînd tranzacţiile se execută una după alta fără a intercala operaţii din altă tranzacţie.4. acesta se va numi serializabil. executate de un singur utilizator sau un program.

131 .2 şi T5 şi T6 din exemplul 5.U5. Ideile de a controla concurenţa sînt legate de a nu lăsa pe celălalt (de a bloca) sau de a ţine cont de momente (de a marca timpul). M5U5. Cititorul poate să demonstreze singur pe un exemplu (vezi problema ) că numai simpla blocare urmată cândva de deblocare (debloc) nu asigură serializabilitatea.5 Metode de control al concurenţei. Următoarele trei exemple reiau tranzacţiile T1 şiT2 din exemplul 5.4.4. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  aleagă cea mai bună metodă de control al concurenţei Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore.4.5. Ce înseamnă să blocăm ? Când o tranzacţie blochează partajat (part_bloc) o anumită unitate de memorie. iar când o tranzacţie blochează exclusiv (ex_bloc) o alta nu mai poate nici să o citească. Serializabilitatea este asigurată dacă se respectă protocolul de blocare în două faze. Blocajul se poate face la nivel de: întreaga bază de date tabela(fişier) înregistrare (cel mai des) câmp din înregistrare Mai spunem că avem granularitate dinamică atunci când SGBD-ul poate să schimbe granularitatea în timpul unei tranzacţii. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se mai pot face blocări. o altă tranzacţir nu mai poate să rescrie tot acolo.5 Introducere Am văzut că problemele apar atunci când o tranzacţie ‘vede’ (citeşte) sau scrie într-un moment nepotrivit. Despre ce unitate de memorie este vorba? Aceasta este problema granularităţii la care se face blocajul.Unitatea de învăţare U5.1respectiv T3 şi T4 din exemplul 5. Acesta constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. M5.3 cu protocolul în două faze şi realizează planuri serializabile.

Exemple 5.1 Time T1 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 T2 begin_transaction ex_bloc(bal x) cit(bal x) bal x = balx +100 scrie(bal x) debloc(bal x) commit balx 100 100 100 100 200 200 200 200 190 190 190 begin_transaction ex_bloc(bal x) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ cit(bal x) bal x = balx -10 scrie(bal x) deblo c(balx) commit Exemple 5.5.5.2 Time T3 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 T4 begin_transaction ex_bloc(bal x) cit(bal x) balx = balx +100 scrie(bal x) debloc(bal x) rollback balx 100 100 100 100 200 100 100 100 100 90 90 90 begin_transaction ex_bloc(bal x) AŞTEAPTĂ AŞTEAPTĂ cit(bal x) bal x = balx -10 scrie(bal x) debloc(bal x) commit 132 .

balz) commit 0 0 0 0 0 0 0 0 0 0 0 0 90 90 90 140 140 140 175 175 175 part_bloc(bal x) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ cit(bal x) sum = sum + bal x part_bloc(bal y) cit(bal y) sum = sum + bal y part_bloc(bal z) cit(bal z) sum = sum + bal z debloc(balx. în figura 9.balz) commit Protocolul de blocare în două faze asigură serializanilitatea dar nu ne scuteşte de probleme. pentru că T8 este dependentă de T7 care a citit o înregistrare care a fost actualizată de T7.5. Observaţi. Pezentăm în cele două exemple următoare rollback-ul în cascadă şi blocajul ciclic.baly. trebuie să facă şi T 8 rollback. ceea ce pe urmă se întâmplă şi cu T 9.3 Time T5 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 A t15 A t16 A t17 A t18 A t19 A t20 A t21 A t22 T6 begin_transaction sum = 0 balx baly balz 100 50 100 50 100 50 100 50 100 50 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 25 25 25 25 25 25 25 25 25 35 35 35 35 35 35 35 35 35 35 35 35 35 sum begin_transaction ex_bloc(balx) cit(bal x) bal x = balx 10 scrie( balx) ex_bloc(balz) cit(bal z) bal z = balz + 10 scrie(bal z) debloc(bal x . 133 .7 la momentul t14 tranzacţia T7 face rollback (dintr-un motiv extern) şi.Exemple 5.

prin constuirea unui graf de precedenţă care arată dependenţa între tranzacţii în felul următor: se crează un nod pentru fiecare tranzacţie se crează o muchie direcţionată Ti  Tj dacă tranzacţia Ti aşteaptă să blocheze o înregistrare care este deja blocată de Tj. de obicei.5. Pe acest graf se detectează un blocaj ciclic dacă există un circuit.Exemple 5. Cele două trnzacţii T 10 şi T 11 se blochează reciproc. Pentru figura 9.5.8 graful ar fi următorul: 134 .4 Time T7 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 A t15 A t16 A t17 A t18 T8 T9 begin_transaction ex_bloc(bal x) cit(bal x) part_bloc(bal y) bal x = baly + balx scrie(bal x) debloc(bal x) begin_transaction … ex_bloc(bal x) … cit(bal x) … bal x = balx +100 … scrie(bal x) … debloc(balx) … … … rollback rollback begin_transaction part_bloc(balx) … rollback O altă problemă este blocarea ciclică prezentată în exemplul următor. Exemple 5.5 Time T10 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 begin_transaction ex_bloc(bal x) cit(bal x) bal x = balx -10 scrie(bal x) ex_bloc(bal y) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ … … T11 begin_transaction ex_bloc(bal y) cit(bal y) bal y = bal y +100 scrie(bal y) ex_bloc(bal x) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ … Blocajul ciclic este detectat .

Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie cu scri_marc(x) > marc(T). adică marc(T) < scri_marc(x). Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc). Deci fiecare tranzacţie va avea o valoare de marcj şi fiecare înregiistrare prelucrată va avea două marcaje. pe care o altă tranzacţie începută mai târziu. Aceasta înseamnă că tranzacţia vrea să rescrie o înregistrare. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie care a început mai târziu.Exemple 5.5. Acest protocol ataşează un timp (timpul real din calculator sau un număr care se măreşte autmat de câte ori este solicitat) fiecărei tranzacţii (marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. Şi în acest caz tranzacţia trebuie întreruptă. În figura următoare se poate observa cum funcţionează acest protocol. 3.6 y T10 x T11 O altă metodă de a evita blocajul ciclic păstrând serializabilitatea este protocolul cu marcarea timpului (time stamp). a citit-o şi o foloseşte. Este o încercare de a scrie o valoare perimată şi în acest caz se ignoră această scriere.5. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă trebuie întreruptă.7 Time Op A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 A t12 A t13 A t14 T7 T8 T9 begin_transaction cit(balx) cit(bal x) balx = balx bal x = balx +10 +100 scrie(bal x) scrie(bal x) begin_transaction cit(baly) cit(bal y) baly = baly bal y = baly +20 +20 cit(baly) scrie(bal y) scrie(bal y)** baly = baly +30 scrie(bal y) balz=100 scrie(bal z) balz=50 bal z=50 scrie(bal z) scrie(bal z)* begin135 begin_transaction cit(baly) bal y = baly +30 scrie(bal y) bal z=100 scrie(bal z) commit . Exemple 5. Numai în următoarele trei situaţii se pun probleme deosebite: 1. adică o înregistrare scrisă de o tranzacţie care a început mai târziu. 2.

Faza de scriere.  Faza de validare. tranzacţia trebuie întreruptă şi restartată. aceste înteruperi şi restartări vor fi. Asta înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure serializabilitatea. Ca să treacă faza de validare trebuie să avem una din următoare le situaţii: 1) Toate tranzacţiile cu un marcaj mai mic. trebuie să se fi terminat înainte ca tranzacţia T să fi început. Iată cum se desfşoară acest tip de control: Fiecărei tranzacţii îi este ataşat. atunci actualizările efectuate în copia locală. Distingem trei faze ale unui control optimist al concurenţei.  Faza de citire.4 Tehnici optimiste. la începutul celei de a doua faze. Este o fază care este necesară numai la tranzacţiile care fac rescrieri. după scriere în copia locală. Actualizările nu sînt făcute direct în baza de date ci într-o copie locală. valid(T) şi la sfârşit fin(T). Dacă faza anterioară s-a terminat cu succes. Tranzacţia citeşte valorile de care are nevoie din baza de date şi le stochează in variabile locale. atunci se face ‘commit’. rare. sînt înregistrate definitiv în baza de date. iar când o tranzacţie vrea să facă ‘commit’ să efectuăm un control care să determine dacă a avut loc un conflict. altfel se întrerupe şi se reia mai târziu. Nu întotdeuna este necesar să pierdem timp în calculator controlând concurenţa. dacăeste cazul. controlul constă în a verifica dacă datele citite sînt încă datele curente în bază şi. atunci se verifică dacă se păstrează serializabilitatea şi dacă baza de date rămâne într-o stare consistentă. Această fază durează de la începutul tranzacţiei până înainte de ‘commit’. la începutul primei faze. atunci se întrerupe. Dacă avem o tranzacţie care numai citeşte baza (adică nu scrie). dacă acest lucru nu se întâmplă.A t15 A t16 A t17 A t18 cit(baly) commit baly = baly +20 scrie(bal y) _transaction cit(bal y) bal y = baly +20 scrie(baly) commit * la timpul t8 scrierea de către tranzacţia T13 violează regula 2 şi de aceea este întreruptă şi reluată la momentul t 14 ** la timpul t14 scrierea de către tranzacţia T12 poate fi ignorată conform celei de a treia reguli 9. adică fin(S) < start(T). Atunci când conflictele între tranzacţii sînt rare putem adopta aşa-numitele tehnici optimiste. şi ele. Pentru că am spus că aceeste conflicte sînt rare. un marcaj start(T). dacă este aşa. Dacă trnzacţia face şi rescrieri în bază. Dacă a avut loc un conflict. 2) Dacă tranzacţia start(S) < start(T) (S a început înaintea lui T) şi nu s-a terminat adică fin(S) < fin(T) atunci:  136 . Urmează după faza de citire şi controlează dacă nu s–ar încălca serializabilitatea în cazul că s-ar aplica actulizarea în baza de date.

Dacă între scrierea în buffer şi scrierea pe disc apare vreo cădere. Deşi tehnicile optimiste sînt eficiente când conflictele sînt rare totuşi pot apărea multe reluări (rollback). M5. fără intervenţii manuale.  Controlul pesimist se poate face cu blocaje prin protocolul în două faze sau cu marcarea timpului. tranzacţia trebuie întreruptă şi restartată. Din diferite motive se poate întâmpla ca baza de date să ajungă într-o stare incorectă sau să se piardă de tot. şi recuperarea. Datele scrise de tranzacţia anterioară S nu sînt cele citite de cea curentă T şi b. unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc). în multe cazuri. O tranzacţie este formată din paşi mici care se execută pe rând şi când a început acţiunea ‘commit’ ea nu s-a şi terminat. Un SGBD trebuie să aibă un mecanism care să facă copii ale bazei de date şi jurnale ale tranzacţiilor după care ele să poată fi refăcute. Ce ne facem dacă apar totiţi inconsistenţe? Trebuie s{ [putem recupera baza de date într-o stare anterioară consistentă. Rezumat  Avem două tipuri de tehnici pentru controlul concurenţei.  O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure serializabilitatea. Copiile se fac autmat. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare prelucrată va avea două marcaje.a. Datele sînt mai întâi duse într-un buffer (o memorie internă intermediară) şi pe urmă scrise în bază (pe disc). atunci SGBD-ul trebuie să reia scrierea (redo).5. iar când o tranzacţie vrea să facă ‘commit’. să efectuăm un control care să determine dacă a avut loc un conflict. să reţinem că aceste reluări nu sînt în cascadă pentru că se lucrează pe o coppie locală. Un SGBD trebuie să prevadă mecanisme de recuperare automată sau manuală de recuperare a unei stări corecte a bazei de date şi posibilitatea de ajunge la zi cu actualizările ulterioare. putem. trebuie să se facă tot automat. Dacă a avut loc un conflict. Tranzacţia anterioară S îşi completează faza de scriere înainte ca tranzacţia curentă T să intre în faza de validare adică start(T) < fin(S) < valid(T).  Protocolul de blocare în două faze impune ca. Controlul recuperării. iar dacă nu s-au umplut bufferele şi a apărut o cădere atunci SGBD-ul trebuie să facă întreruperea şi reluarea tranzacţiei (undo sau rollback). după ce s-a făcut o deblocare sa nu se mai facă nici o deblocare.U5.  Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii (marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei înregistrări. într-o tranzacţie. Pentru că am spus că 137 . în acest caz să avem blocare ciclică sau ROLLBACK în cascadă.

aceste înteruperi şi restartări vor fi.2 Ce este blocaju ciclic? Exemplu.5.aceeste conflicte sînt rare.5 Ce este o tehnică optimistă de control al concurenţei? Răspunsurile se găsesc la sfârşit la pag 161 138 .4 Care este protocolul de control cu marcarea timpului (time stamp)? 5. rare.5.5. 5.5. M5 U5.3 Ce este protocolul de blocare în două faze? 5. şi ele.1 Ce este blocajul? 5.5.5 Test de autoevaluare a cunoştinţelor 5.

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). 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. Securitate şi integritate M5U5. corectarea şi prevenirea diferitelor erori care pot afecta datele introduse în bazel e de date. 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. întelegem că datele sunt consistente relativ la toate restrictiile formulate anterior (care se aplica datelor respective) şi ca urmare a acestui fapt.Unitatea de învăţare U5. O alta serie de conditii se clasifica dupa unitatea la care se aplica restrictia si.U5. datele sunt considerate valide.6. Aceasta regula se mai poate enunta şi sub forma: "intr-o baza de date relaţionala nu se inregistreaza nici o informatie despre ceva ce nu poate fi identificat.6. in campurile corespunzatoare cheii primare." Un exemplu de restrictie de integritate de relatie de tip multituplu este restrictia referentiala care se exprima prin conditia ca. Obiectivele unităţii de învăţare La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:  introducă regulile de integritate  să impună măsuri de securitate Durata medie de parcurgere a primei unităţi de învăţare este de 2 ore. În general sunt acceptate mai multe criterii de clasificare a regulilor de integritate.6 Introducere M5. exista restrictii pe domenii (ce privesc anumite valori pentru atribute) sau restrictii pe tabele (relatii). daca nu sunt nule. sa se admita valori corespunzatoare uneia din cheile primare existente in relatia referita. sa apara valori diferite de valorile nule corespunzatoare. O serie de conditii sunt de tip structural. Integritate Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune detectarea. in acest caz. pentru cheile externe. Verificarea 139 . Cand facem referiri la integritatea datelor.

ori valoarea cheii externe trebuie sa se potriveasca cu valoarea unei chei candidat a vreunui tuplu in relatia de origine. In majoritatea SGBD unicitatea cheii primare şi integritatea entitatii sunt conditii obligatorii. ori ea trebuie sa se potriveasca cu valoarea unei chei primare dintr-o alta relatie ori sa fie nula. care se pot aplica numai la anumite relatii. Deja cunoastem ca se cere (in multe situatii) ca valorile cheilor primare sa fie unice. semnalandu-se eventualele neconcordante şi anuland modificarile. Restrictiile pot fi clasificate şi din punct de vedere al momentului in care se aplica ele.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. Verificarea unicitatii cheii primare şi restrictiile rezultate din dependentele functionale şi multivaloare sunt alte exemple de acelasi tip. Regulile de integritate se aplica relatiilor de baza in care sunt reprezentate efectiv datele bazei de date. Cu late cuvinte. restrictiile pot fi impartite in restrictii generale. Probleme serioase apar in momentul cand sunt de efectuat modificari sau stergeri de valori ale cheilor primare. Dintre regulile generale cel mai des folosite in modelul relaţional sunt regulile ce privesc cheile primare (vezi unicitatea valorilor cheilor primare in cadrul relatiei) şi cheile externe. 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). aplicabile tuturor relatiilor din baza de date şi restrictii particulare. daca o valoare exista intr-o relatie pe post de cheie externa. În functie de aria de aplicare. 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 140 . Restrictii pentru integritatea referentiala Enunt: Daca exista o cheie externa intr-o relatie. Analizam in continuare cateva tipuri de restrictii de integritate. ori valoarea cheii externe trebuie sa fie nula. I. Restrictii pentru integritatea entitatii Enunt: Intr-o relatie de baza nici un atribut al unei chei primare nu poate avea valori nule. 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. II.

check if num(LL) = 2 and mod(num(AA). pot suferi mici transformari.7.100) <> 0 then num(ZZ) < 29. validitatea şi consistenta datelor se bazeaza exclusiv pe utilizarea corecta şi de buna credinta a sistemului de catre utilizatorii autorizati.6. adica se sterg tuplele care au valori ale cheii externe care se potrivesc cu cheia primara (ii) d) se intra in dialog cu utilizatorul Toate acestea sunt reguli generale care. Daca se definesc controalele de securitate in absenta celor de integritate.5. create domain LUNA char(2) check is_integer(LUNA) and num(LUNA) >= 1 and num(LUNA) <= 12. la o lista de valori posibile. la un format sau o forma. LL domain(LUNA).3. datele au sansa sa fie consistente dar sunt susceptibile la pericolele care provin din lipsa securitatii.4) <> 0 then num(ZZ) < 28. create domain AN char(2) check is_integer(AN) and num(AN) >= 0 and num(AN) <= 99. Standardul SQL furnizeaza controale pentru integritatea referentiala in declaratiile de creare a tabelelor. check if num(LL) = 2 and mod(num(AA).(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. Integritatea datelor este strans corelata cu securitatea datelor unei baze de date.9. 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. cum ar fi actualizari şi stergeri ale unor atribute. check if num(LL) in (4. Aceste restrictii se pot referi la tipul de date pentru un atribut. 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. 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. 141 . Restrictiile de domeniu Aceste restrictii sunt intotdeauna restrictii de stare imediate.8.12) then num(ZZ) < 31. create domain DATA(ZZ domain(ZI). la un ordin de marime. se propaga schimbarile acolo unde aceasta din urma cheie primara este cheie externa intr-o alta relatie in cazul stergerilor – se propaga stergerea .4) = 0 and mod(num(AA). III. in functie de aplicaţia concreta. Situatiile descrise mai sus pot fi rezolvate in cadrul aplicaţiei sau se pot include in SGBD utilizand mecanismul trigger-elor. 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. dupa caz. Daca insa se definesc numai controale de integritate. AA domain(AN)) check if num(LL) in (1.11) then num(ZZ) < 30.10.

La terminarea unei tranzactii. Pentru reconstituirea bazelor de date in cazul cand pot sa apara inconsistente in general. cum ar fi: introducerea. 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. sfarsit. Modificarile tranzactiilor abandonate sau necomise nu sunt luate in considerare la parcurgerea jurnalului pentru restaurarea bazei de date. si altele.Este important de mentionat aici ca restrictiile de integritate nu garanteaza corectitudinea datelor. fosta valoare şi noua valoare introdusa pentru un element. De asemenea se tine o evidenta a tuturor transformarilor efectuate in baza de date de cand s-a efectuat ultima copie. -anomalii datorate accesului concurent la baza de date. 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. Acestea sunt operatii susceptibile de introducerea de date inconsistente in baza de date. indiferent daca ea s-a incheiat normal sau prin eroare. Pierderea accidentala de consistenta a datelor poate rezulta din: -incidente ce apar pe parcursul executarii tranzactiilor. baza de date trebuie sa aiba acelasi grad de integritate ca la momentul inceperii executiei tranzactiei respective. dar gradul in care acest lucru este posibil depinde de SGBD. -anomalii datorate lucrului cu date distribuite pe mai multe calculatoare intr-o retea.01.01. et c. Restrictiile de integritate pot fi memorate in multe cazuri chiar in SGBD. 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. majoritatea bazelor de date se copiaza periodic pe medii magnetice ce se pastreaza in locuri sigure. 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.). Fiecare inregistrare din jurnal contine un identificator al programului care a facut modificarea. Toate mecanismele mentionate in acest paragraf sunt caracteristice lucrului cu tranzactii. -erori logice care apar din programele utilizator. Exemplu: Nu se poate verifica automat daca numele unei persoane este "Pop" sau "Popa". Fisierul care contine aceste modificari se numeste jurnal. 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 142 . Tot in jurnal se mai pastreaza diferitele momente importante din desfasurarea programelor (inceput. actualizarea şi stergerea. cum nu se poate verifica automat daca data nasterii este "10.2001".2001" sau "01. terminarea unor operatii. Aceasta deoarece este aproape imposibil (in multe situatii) ca verificarea corectitudinii sa fie realizata automat. etc. 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.

Adevarul este insa undeva la mijloc. 2. 143 . Pentru protectia bazei de date se pot lua masuri de asigurare a securitatii la mai multe nivele: -la nivel fizic . -distrugeri de date. Securitatea este in general asociata cu urmatoarele situatii: -acces fraudulos la date.nepermise de date. etc. Decodificarea datelor se poate face numai dupa identificarea utilizatorului prin garzi asociate lui. 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. -pierderea disponibilitatii datelor Este mai dificila protejarea datelor impotriva accesului rauvoitor. Notiunea de securitate a bazei de date este de obicei asociata cu accesul rauvoitor. -pierderea integritatii datelor. intentionat. -modificari neutorizate de date. -pierderea confidentialitatii (secretului) datelor. Pentru realizarea securitatii datelor din baza de date se utilizeaza controale tehnice şi administrative. 3. inserarii. stergerii sau modificarii datelor respective.locurile in care se afla calculatoarele trebuie protejate de accesul persoanelor neautorizate. Identificarea utilizatorilor. Utilizarea view-urilor in aplicaţii. Forme de acces intentionat şi rauvoitor la datele unei baze de date: -citire neautorizata a unor date. Se recunoaste ca de fapt nu exista protectie absolut sigura ci doar protectii şi masuri de securitate mai eficiente sau mai putin eficiente. -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. pagina. atributul. -pierderea caracterului privat al datelor. Identificarea se face de obicei prin parole stabilite fie de administratorul bazei de date fie de utilizator. Protejarea datelor prin codificare (criptare). pe cand integritatea se refera la evitarea pierdelor accidentale de consistenta. 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. inregistrarea. Drepturile se refera la posibilitatea citirii.

ele devin accesibile unui grup mai mare de persoane decat cel prevazut. Astfel se poate vorbi de acces la nivel de relatie (tabela) sau acces la nivel de view. 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. 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. sociale şi etice. 4. Astfel de view-uri se numesc read-only (numai pentru citire) şi sunt utilizate mai ales in aplicaţiile 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. Nu intotdeauna "scurgerile" de informatii lasa urme. Conducerea organizatiei. care este proprietara bazei de date. deci nu se materializeaza intotdeauna in schimbari detectabile la nivelul bazei de date. securitatea sistemului de operare (protejarea informatiilor şi anularea rezultatelor intermediare pentru pastrarea secretului 144 . trebuie sa ia masuri de securitate care reduc riscul de a se pierde informatii sau de a se distruge informatii.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. aspecte privind controlul hard (modul de acces hard la diferite componente). Administrarea şi transmiterea drepturilor. 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. Problema securitatii cuprinde aspecte legale. aspecte de politie (fixarea conditiilor 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. 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. aspecte privind controlul fizic (paza şi posibilitati de blocarea accesului la terminale). aspecte operationale (modul de stabilire a parolelor). 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. Prin pierdere de informatii se poate intelege ca se pierde caracterul privat al informatiilor. In unele sisteme nu sunt acceptate modificari prin intermediul view-urilor.

M5. Securitatea este in general asociata cu urmatoarele situatii: -acces fraudulos la date.locurile in care se afla calculatoarele trebuie protejate de accesul persoanelor neautorizate. daca acest fapt ar dauna proprietarului informatiilor respective.U5. Rezumat Integritatea bazelor de date se refera la corectitudinea informaţiilor şi presupune detectarea. Putem enumera aici o paleta larga de domenii care lucreaza cu informatii al caror caracter privat trebuie neaparat pastrat: domeniul bancar. -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 145 .datelor) aspecte privind notiunea de proprietate asupra datelor din baza de date şi altele asemanatoare. datele sunt considerate valide. 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. gravitatea acestor fapte depinzand şi de profilul organizatiei in cauza. corectarea şi prevenirea diferitelor erori care pot afecta datele introduse în bazele de date. -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 . 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. Trebuie sa mentionam aici ca furturile şi fraudele nu sunt neaparat legate de baza de date. Cand facem referiri la integritatea datelor. -pierderea caracterului privat al datelor. etc. domeniul productiei in majoritatea firmelor de marca. domeniul medical. deci sa nu fie accesibile publicului larg sau nici macar unui grup relativ restrans. ele sunt un factor de risc pentru intreaga organizatie. întelegem că datele sunt consistente relativ la toate restrictiile formulate anterior (care se aplica datelor respective) şi ca urmare a acestui fapt.6. În Comunitatea Europeana exista o preocupare serioasa legata de actualizarea legislatiei la noile nevoi generate de utilizarea intensiva a calculatoarelor. evidente administrativ-financiare. -pierderea confidentialitatii (secretului) datelor. Tipuri de restrictii de integritate.

6.6. Răspunsurile se găsesc la sfârşit la pag 162 146 .6.6.6.U5. 5.8 Enumeraţi forme de autorizare.3 Ce înseamnă integritatea referentiala? 5.-la nivel SGBD – sistemul ofera anumite facilitati care sprijina protectia datelor Tehnici de asigurare a securitatii datelor: 1.6 Cum poate fi încălcată securitatea datelor într-o baza de date ? 5. 3.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor. 4.6.5 Care este deosebirea între integritate şi securitate? 5.6. M5.6. Utilizarea view-urilor in aplicaţii.4 Ce înseamnă restrictiile de domeniu? 5.6. Identificarea utilizatorilor.2 Ce înseamnă integritatea entitatii? 5. Administrarea şi transmiterea drepturilor. Test de autoevaluare a cunoştinţelor 5. 2.1 Care sunt restricţiile de integritate? 5. Protejarea datelor prin codificare (criptare).

culoarea părului 1.2.Raspunsuri la testele de autoevaluare. adresa.sex 1. Unitatea 1.1 Ce ar trebui memorat despre profesori într-o bază de date a facultăţii? Nume. greutate. -Asigurarea unei redundanţe minime şi controlate a datelor din baza de date.adresa de e-mail.2 Ce nu ar trebui memorat despre profesori într-o bază de date a facultăţii? Pasiuni.2 1.3..grad didactic. înălţime.1 Care sunt obiectivele unui SGBD? Bazei de date îi revin o serie de obiective.3 1.2.2.3 Ce este arhitectura pe trei nivele? Nivel extern View 1 View 2 …. 147 . cum sunt: -Asigurarea independenţei datelor. View n Nivel conceptual Schema conceptuala Nivel intern Schema interna Organizarea la nivel fizic a datelor Baza de date Arhitectura ANSI-SPARC pe trei nivele Unitatea 1.

-Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate.administratorul bazei de date apare ca un utilizator special şi are rolul hotarâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu. care utilizează limbajele de manipulare.2 Care sunt funcţiunile unui SGBD? 1. ci şi acela al posibiliăţtii dezvoltarii unor aplicaţii fără a se modifica structura bazei de date. .utilizatori "liberi" sau conversaţionali. Aceasta funcţie asigură: -descrierea atributelor (câmpurilor) din cadrul structurii bazei de date.Asigurarea unor facilităţi sporite de utilizare a datelor . .Sporirea gradului de securitate a datelor împotriva accesului neautorizat la date.utilizatori programatori.3. 2. -descrierea legăturilor dintre entităţile bazei de date sau dintre atributele aceleiasi entităţi. realizând proceduri complexe de exploatare a bazei de date. -Asigurarea partajabilitatii datelor. Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează urmatoarele activităţi: . Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date. Partajabilitatea datelor trebuie inţeleasă nu numai sub aspectul asigurarii accesului mai multor utilizatori la aceleaşi date.. Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utlizatorilor cu baza de date. conceptual şi fizic. . -definirea eventualelor criterii de validare a datelor. Aceaştia reprezintă categoria beneficiarilor de informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date intr-o formă simplistă. etc.crearea (incarcarea) bazei de date. Definirea datelor poate fi realizată la nivel logic. Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. sortarea şi editarea parţială sau totală a unei inregistrări virtuale etc. Ei apar ca utilizatori neinformaticieni.ştergerea unor inregistări. -definirea aspectelor referitoare la asigurarea integrităţii si confidenţialităţii datelor. 148 . prin intermediul unor proceduri de validare.căutarea. 4.modificarea valorilor unor câmpuri.adaugarea de noi inregistrări. a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente. Sunt recunoscute mai multe categorii de utilizatori: . . -definirea metodelor de acces la date. . 3. . 1.

pe lângă cerinţele cunoscute pentru sistemele centralizate. Fiecare site este capabil sa proceseze interogări utilizator în regim local.4 1.3 Cum se poate face proiectarea alocării datelor? Proiectarea corectă a unei baze de date relaţionale distribuite necesită. 1. eventual unele fragmente sunt multiplicate.Unitatea 1. sau este capabil să participe la procesarea unor date situate în alte site-uri din reţea. şi fiecare fragment sau copie se pastrează pe unul sau mai multe site-uri.4.4. independent de restul reţelei. Costuri scazute se mai obtin daca se realizeaza prelucrări locale cât mai multe (în cază sistemul şi aplicaţiile permit acest lucru).2 Care sunt avantajele unui sistem distribuit? 2) Avantajele distribuirii bazelor de date sunt: sistemul distribuit se modelează cel mai bine pe structura organizaţională a multor organizaţii. Pentru a spune că un SGBD este distribuit trebuie să existe cle puţin o cerere globală. sub controlul unui SGBD local.1 Ce este o bază de date distribuită? 1) Un SGBDD constă dintr-o singură bază de date care este descompusă în fragmente.4. 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ă decât în cazul centralizat. Se pot reface rapid fişiere distruse utilizând replici aflate pe alte site-uri performanţele în prelucrarea datelor se îmbunătăţesc prin posibilitatea prelucr[rii în paralel a unor interog[ri un sistem distribuit oferă avanatje economice dacă luăm în considerare costurile implementării şi întreţinerii unei reţele faţă de costurile corespunzătoare ale unui sistem centralizat de putere comparabilă de prelucrare. Dacă se semnalează unele erori sau "ăderi" de sistem la nivel local sistemul ]n întregime poate să continue să funcţioneze în condiţii satisfăcătoare fiabilitatea sistemului este îmbunătăţită. şi realizarea următoarelor: fragmentarea datelor – informaţiile pot fi partitionate în fragmente care sunt apoi stocate pe diferite site-uri în reţea replicarea – se pot realiza copii ale diferitelor relaţii sau ale fragmentelor alocarea fragmentelor şi a replicilor pe diferite site-uri Se cunosc patru strategii de alocare a datelor într-o baza de date relaţională distribuită: 149 . - - - 1. De asemenea este mult mai convenabil să se "ajusteze" o reţea de calculatoare la nevoile organiza’iei (dacă de exemplu este necesară adăugarea unor site-uri în plus) decât un calculator central de putere asemănătoare capacitatea de gestionare modulară a sistemului permite extensii ale acestuia sau rezolvarea unor "căderi" parţiale fără să se afecteze prea tare (uneori fără a se afecta deloc) mersul activităţilor pe ansamblul sistemului distribuit.

Aceasta regulă conservă dependenţele funcţionale. trebuie luate măsuri care să prevină pierderea de informaţii .reconstrucţie – să fie posibil în orice moment să se refacă relaţia R de la care s -a pornit cu fragmentarea. fragmentat (partiţionat) Baza de date este partiţionată în mai multe fragmente disjuncte care sunt stocate pe diverse site-uri. fiabilitatea şi disponibilitatea sunt maxime costurile de stocare sunt în schimb şi ele foarte mari. ea de fapt nu mai este o bază de date distribuită in adevaratul sens al cuvântului. replicare şi centralizare cu scopul de a se cumula. Dezavantajele sunt mai ales costurile mari de comunicaţii şi o fiabilitate şi o disponibilitate foarte scăzute. având în vedere că orice eroare care blochează accesul la baza de date.R n. a2.4. …. Spunem în acest caz că baza de date este procesată distribuit. replicat complet Pe fiecare site se găseste o copie completă a bazei de date.5 Ce este fragmentarea? Tipurile de fragmentare sunt: pe orizontală pe verticală combinată Fragmentarea pe orizontală: 150 . practic paralizează întreaga activitate în reţea pe această direcţie.4 Cum se face o fragmentare corectă? Reguli de bază care duc la o fragmentare corectă a bazei de date: . Comentarii: eficienţa referirilor locale. disjuncţie – dacă data d i apare în fragmentul R i atunci nu este permis să apară în nici un alt fragment. R2.a!. 1. centralizat Baza de date se află în întregime pe un singur site din reţea şi este gestionată de un singur DBMS. pe cat posibil. avantajele fiecărei strategii şi să se elimine dezavantajele. replicat selectiv Aceasta strategie este o combinaţie intre partiţionare.completitudine – dacă relaţia R este descompusă în fragmentele R1.4. costurile de comunicare pot fi relativ scăzute a3. Comentarii: aceasta parţitionare a datelor poate îmbunătăti frecvenţa referinţelor locale dacă nu există replici ale fragmentelor. De la această regulă se admite doar o excepţie. la fel sunt şi costurile de actualizare a4. cazul când o relaţie este fragmentată pe verticală. costurile de stocare sunt reduse fiabilitatea şi disponibilitatea sunt scăzute dar nu aşa de mici ca în cazul centralizat dacă datele sunt distribuite corect. 1.

una din submulţimile S1 şi S2. Un fragment orizontal se produce prin selecţie: Fiecare tuplu din relatia R apare într-un anume fragment. In cazul descompunerii pe verticală nu este posibil să se realizeze o disjuncţie totală. şi anume a atributelor care formează cheile primare (respectiv cheile externe).. Completitudinea este asigurată prin faptul că fiecare atribut apare cel puţin într. compusă) Se poate face din fragmente verticale fragmentate orizontal: Expresia corespunzatoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:  P ( A1 . An ( R)) Sau se poate face din fragmente orizontale fragmentate vertical 151 .. Se admite existenţa unor atribute comune. Fragmentarea combinată (mixtă. hibridă. Reconstrucţia relaţiei iniţilale se realizează prin joncţiune naturală. Fragmentarea pe verticală Un fragment vertical dintr-o relaţie constă dintr-o relaţie care are ca atribute o submulţime a atributelor relaţiei iniţiale. r ( R )  r1 X N r2 Aşadar la descompunerea relaţiei iniţiale în fragmente trebuie să se ţină seama de regulile care asigură o descompunere fără pierderi la joncţiune. R= R1R2…Rn In general fragmentele unei relaţii R sunt disjuncte. o singură dată. Un fragment vertical se produce prin proiecţie: Dacă S1R şi S2R atunci r1   S1 ( R) şi r2   S 2 ( R) .. se utilizează reuniunea pentru a obţine relaţia R iniţiala. Dacă se doreşte reconstrucţia relaţiei..Ne putem imagina că o tabelă se fragmentează orizontal ca mai jos: Un fragment al unei relaţii partitionate pe orizontală constă dintr-o submulţime a tuplelor relaţiei respective.

1 2. Relaţia editură carte este de unu la mai mulţi pentru că o editură editează mai multe cărţi dar o anumită carte este scoasă de o singură editură (vez ISBN care este unic).grupa.asistent.grad didactic. An ( P ( R)) .lectoe.3 Stabiliţi domeniul fiecărui atribut din tabela profesor. 1 Ion ion 7271 5 Dan soc 7271 7 Pan tor 7273 15 23 1 2 Prof1 Prof2 Bv lunga 22 Fag oltet 34 Baze de date Algoritmica 152 . Relaţia student materii este de mulţi la mulţi pentru că un student face mai multe materii şi o materie ete făcută de mai mulţi studenţi..2. Unitatea 2.Expresia corespunzătoare în algebra relaţională (pentru fiecare dreptunghi din figura de mai sus) este:  A1 .1 Care sunt modele de date bazate pe înregistrare? Exista trei tipuri importante de modele de date bazate pe inregistrare: modelul de date relaţional. Student=(nrmatricol. 2.nrtelefon.conferenţiar.profesor) sex una din două M sau F Unitatea 3.adresa de e-mail.materii şi catalog. Unitatea 2.cnp.adresa nrtelefon cheia principală va fi nrmatricol pentru că: cnp este mai lung nume.. unu la mai mulţi şi mulţi la mulţi. modelul de date retea şi modelul ierarhic de date.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 mulţimea(preparator. 2. profesor=(Nume.2 Daţi exemple de relaţii unu la unu..2 2.nume.2.1.2.1 Găsiţi cheile candidat ale tabelei student.datanasterii) chei candidat: nrmatricol cnp nume.. adresa. Stabiliţi cheia primară.sex.adresa. profesor.adresa are două componente şi adresa se poate schimba nrtelefon se poate schimba.1 Cosideraţi instanţe ale tabelei student.

2 Să se exprime în algebra relaţională cererile: e) Studenţii grupei 7271  f) grupa=7271 (student) Studenţii care sunt şi profesori 153 .1. La acestea două din urmă fac eţi reuniunea.3 Structuri de date codmaterie 1 2 3 1 3 nota 5 8 4 3 9 nrmatricol 1 1 5 7 7 e) Faceţi selecţie din student după grupa 7271 1 Ion ion 7271 5 Dan soc 7271 f) Faceţi proiecţie la student şi la profesor după nume. Ion ion Dan soc Pan tor Prof1 Prof2 g) Faceti joncţiunea naturală intre student şi catalog apoi între rezultat şi materii. nrmatricol numestd grupa codmaterie 5 Dan soc 7271 3 7 Pan tor 7273 1 denmaterie Structuri de date Baze de date nota 4 3 3. numestd Ion ion Ion ion Dan soc Pan tor Pan tor grupa 7271 7271 7271 7273 7273 codmaterie 1 2 3 1 3 denmaterie Baze de date Algoritmica Structuri de date Baze de date Structuri de date nota 5 8 4 3 9 nrmatricol 1 1 5 7 7 h) Faceţi selecţia tabelei de mai nainte după nota < 5.

locatari where (scari.bloc = locatari.bloc = locatari.bloc=34) and(scari.Nume Să se exprime în SQL cererile: 3. Nr_chei) -Locatari Nr_Mat. locatari 154 .bloc = locatari.bloc = locatari.bloc) and (scari.scara=1) and (scari.scara=3) and (scari.2. Scara.bloc) and (scari.4 tabel nominal cu locatarii de pe scările 1.bloc = locatari. locatari where (scari.scara= locatar.Scara.2 Se dau următoarele relaţii cu schemele lor: -Scări (Nr_bloc. Nr_pers. locatari where (scari.bloc) and (scari.2 (tabel nominal cu locatarii de pe scara = 1 din bloc = 34) = R2 select nume from scari.Suprafaţa. locatari where (scari. locatari where (scari. Etaj. g) nume (student)   nume (profesor) Studenţii corigenţi nume  ( h) (student N catalog Studenţii integralişti nota<5 j j note)) N  nume5 (student) \  ( nume nota<5 (student j catalog j note)) N N Unitatea 3. Nr_prize_tv) .scara) union select nume from scari.2.scara= locatar.Familii (Nr_mat.1 (tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = R1 select nume from scari.scara) 3. Lift) -Apartamente(Nr_bloc. Apartament.bloc=34) and(scari.scara) union select nume from scari.bloc) and (scari.scara= locatar.bloc=34) and(scari.3 (tabel nominal cu locatarii de pe scara = 2 din bloc = 34) = R3 select nume from scari.scara= locatar.Cutii_poştale.2.2.scara) 3.scara=2) and (scari. Nr_pers_prez. Nr_bloc.bloc=34) and(scari. Scara.3 ale blocului 34 select nume from scari.bloc=34) and(scari.scara=1) and (scari.scara=3) and (scari.scara) 3.bloc) and (scari.2.Apartament.scara= locatar.

bloc locatari. liftului 200000 Tabela Furnizori_Cheltuieli în 1NF creată prin prima modaliate de transformare.codmaterie nota codmaterie denumirematerie 4. locatari where (scari. Încălzire Chelt pt.scara) and not in ( select nume from scari.nota)) sunt: nrmatricol nume nrmatricol adresa nrmatricol. După despărţirea repetiţiilor pe mai multe rânduri.bloc=34) and(scari.1 Dependenţele funcţionale din tabela: Student=(nrmatricol.5 lista apartamentelor cu suprafaţa mai mare decât 50 mp select Nr_bloc. Cod Denumire Valoare Furn.1.scara=2) and (scari. Grupul de atribute (nr.bloc) and (scari. Bucătării Chelt cu iluminatul Chelt pt. identificăm o nouă cheie. Încălzire 1500000 F100 Romgaz R1234567 2 C16 Chelt pt. vor fi copiate pe fiecare rând. Pentru a transforma această tabelă în 1NF..bloc=34) and(scari. Cheltuială F100 Romgaz R1234567 1 C15 Chelt pt.bloc = locatari. 1 2 3 4 Cod Chelt.bloc=34) and(scari. Cod Denumire Cod Nr. 155 .1 Fie tabela din enunţ: Cod Denumire Cod Furn.scara= locatar.bloc = locatari.scara) 3. denumire cheltuială.6 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34 şi nu locuiesc şi pe scara 1 a aceluiaşi bloc select nume from scari. Bucătării 500000 F110 Renel R7654321 3 C10 Chelt cu iluminatul 3000000 F110 Renel R7654321 4 C11 Chelt pt.2. locatari where (scari. cod chelt. liftului Valoare 1500000 500000 3000000 200000 În această tabelă observăm că pentru furnizorul “Romgaz” avem două tipuri de cheltuieli.2. Crt. Func. Chelt.. Func.scara= locatar. C15 C16 C10 C11 Denumire Cheltuială Chelt pt.nume.1 4.scara=1) and (scari.crt. trebuie să avem o singură valoare la fiecare intersecţie linie coloană.scara)) Unitatea 4.10(codmaterie. În cazul primei modalităţi.2. scriem repetiţiile pe diferite rânduri iar coloanele care nu conţin repetiţii.bloc) and (scari.scara=3) and (scari.scara= locatar.bloc) and (scari. fiscal F100 Romgaz R1234567 F110 Renel R7654321 Nr.denumirematerie.where (scari. fiscal Crt.Scara.Apartament from apartamente where suprafaţa > 50 3. valoare) apare de mai multe ori.adresa.

1...codmaterie nota codmaterie denumirematerie aceasta fiind dependenţă parţială de cheie deci nu este FN2 se obţine forma finaţă: stud1=( nrmatricol..)  R deci K este cheie. orar. Denumire. Relaţiile rezultate au următoarea formă: Furnizori = (Cod Furn.În tabela normalizată.denumirematerie. Crt. Normalizând tabela iniţială după a doua modalitate.nume. Denumire cheltuială) Cheltuieli = (Nr. Identificarea tipurilor de entităţi.nota) materii=( codmaterie..nota) unde avem dependenţele funcţionale: nrmatricol.1 Faceţi proiectul conceptual local pentru subsistemul didactic al facultăţii.2. Cod fiscal) Dependenţele d1 şi d2 sunt dependenţe parţiale de cheie.. Nr.denumirematerie) Unitatea 5.denumirematerie.codmaterie. Cod.nota)) Are grup repetitiv deci nu este FN1. Cod fiscal) Cheltuieli (Cod Furn.adresa) catalog=( nrmatricol. Denumire. den_domeniu)..nume. Cod fiscal.. Cod Chelt. Fie relaţia: Student=(nrmatricol. tipurile de entităţi sunt: student.2 Fie R = (Cod Furn.codmaterie.. Crt. Denumire cheltuială. Cod Chelt. Cod Furn. cod_domeniu) şi domeniu = (cod_domeniu. Denumire cheltuială.. Cod Chelt.. profesori. Nr. Denumire. Valoare) Vom avea dependentele functionale: K = (Cod Furn. materii. Pasul 1.1 5.1. vom crea o a doua tabelă cu informaţiile care nu se repetă.. Nr. Cod Chelt. Crt. împreună cu cheia primară din tabela iniţială. den_domeniu) cu cheia c_carte.). Cod fiscal) Tip cheltuială = (Cod Chelt.adresa) care este FN3 şi stud2=( nrmatricol. Deci cele două tabele vor fi următoarele: Furnizori (Cod Furn. Crt . titlu..10(codmaterie. titlu. se descompune în: stud1=( nrmatricol. sali 156 . În afara dependenţelor care definesc cheia mai avem dependenţa: cod_domeniu  den_domeniu şi pentru că c_carte este cheie avem şi c_carte  cod_domeniu deci den_domeniu depinde tranzitiv de cheie. noua cheie va fi (Cod Furn. Cod Chelt.. cod_domeniu. Prin descompunere rezultă două scheme 3NF: carte1 = (c_carte.adresa.nume. Crt.. d1 Cod Chelt  Denumire cheltuială d2 Cod Furn  (Denumire.. Valoare) Fie relaţia din enunţ: carte = (c_carte.. Valoare) Cele două tabele astfel create sunt în 1NF: 4. Nr.

Tipurile de relaţii se reprezintă prin verbe ale relaţiilor. În continuare vom determina cardinalul şi participarea relaţiilor prezentate în tabelele de mai sus. Participarea poate să fie parţială sau totală.Identificarea tipurilor de relaţii. materii cardinalitate N:M N:1 participare P:T T:T Atributele tipurilor de entităţi Tip de entitate student Atribute nrmatricol nume adresa sex grupa … materii … Codmaterie Denmaterie …. sau multe-la-multe (M:N). unu-la-multe (1:M). Tip de entitate student profesor orar Tip de relaţie face preda Relaţie complexă cu Tip de entitate Materii Materii Zile. Desenarea modelului ER. Sali.7. ore. Cardinalul poate să fie unul dentre următoarele: unu-la-unu (1:1). Pasul 1. Numeric de 3 Text domeniu Numeric de 5 text text M sau F Numeric de 4 157 . În continuare identificăm tipurile de relaţii.

student N materii M N profesori 1 orar sali zile ore Unitatea 5. Pentru a rezolva această problemă. care sunt dificil de implementat în sistemul de gestiune al bazelor de date. Proiectarea modelului local conceptual în modelul local logic. Pasul 2. Avem relaţia cu orarul. student N catalog 1 materii N 1 (2) Eliminarea relaţiilor complexe. Este cazul relaţiei dintre student şi materii.1 Faceţi proiectul logic local pentru subsistemul didactic al facultăţii.2 5.2. În acest pas eliminăm acele structuri din baza de date.1. se vor urma următorii paşi: (1) Eliminarea relaţiilor de tipul N:M. Se modifică în felul următor: 158 . Apare entitatea catalog.

student N zile 1 ore 1 Sali 1 materii M N profesori 1 N zileore N 1 N zioresali N 1 N orar N 159 . Nu avem. Am eliminat din acest model. (4) Eliminarea relaţiilor cu atribute. (5) Reexaminarea relaţiilor de tipul 1:1. Nu avem Desenarea diagramei ER. Diagrama modificată se va numi în continuare modelul local logic al bazei de date. Nu avem.zile 1 ore 1 Sali 1 materii 1 N zileore N 1 N zioresali N 1 N orar N (3) Eliminarea relaţiilor recursive. Modelul conceptual care este reprezentat anterior s-a modificat în acest pas. toate structurile greu de implementat într-un sistem de gestiune a bazelor de date.

Pasul 2.2. Crearea de relaţii peste modelul logic local. În acest pas vom crea relaţiile între entităţile din modelul logic local de date, cu ajutorul mecanismului chei primare/chei străine. de exemplu: Student=(nrmatricol,nume,adresa,sex,grupa) Cheie primară nrmatricol Catalog=(nrmatricol,codmaterie,nota) Cheie primară nrmatricol,codmaterie Cheie străină nrmatricol referă nrmatricol din student Cheie străină codmaterie referă codmaterie din materii materii=(codmaterie,denmaterie) Cheie primară codmaterie … Pasul 2.3. Validarea modelului prin normalizare. În acest pas validăm baza de date prin normalizare. Procesul de normalizare este descris amănunţit în capitolul 4.  Forma Normală Unu (1NF), eliminarea repetiţiilor din atribute.  Forma Normală Doi (2NF), eliminarea dependenţelor parţiale de cheia primară.  Forma Normală Trei (3NF), eliminarea dependenţelor tranzitive de cheia primară.  Forma Normală Boyce-Codd (BCNF), eliminarea anomaliilor care au mai rămas. Trebuie să analizăm fiecare relaţie care este descrisă în anexa 6.3.5. Verificăm dacă relaţiile sunt în forma normală Boyce-Codd, iar dacă găsim una care nu satisface această formă normală, ne întoarcem la paşii precedenţi şi rezolvăm problema. În cazul nostru toate tabelele sunt în FN3 Pasul 2.2. Validarea modelului prin tranzacţiile cerute. Tranzacţiile vor fi: T1 Tabel nominal cu studenţii grupei… T2 Catalogul grupei.. la materia… … Pentru fiecare tranzacţie 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 Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic al facultăţii. Se vor urmări paşii din Access la purtător [8]

160

Unitatea 5.4 5.4.1 Daţi exemple de pierdere a consistenţei. 1) Tranzacţia T1 citeşte contul lui x (balx) şi scade 10 din cont. Tranzacţia T2 citeşte contul lui x (balx) şi adună 100 la cont. Pornind cu un cont de 100, evident că dacă se execută mai întâi prima tranzacţie şi apoi a doua contul lui x ar fi fost 10010+100=190. În cealaltă ordine am fi avut 100+100-10=190 aceeaşi valoare. Să considerăm următorul plan de tranzacţii. Time T1 T2 begin_transaction cit(bal x) bal x = balx + 10 scrie(bal x) commit balx 100 100 100 200 90 90

A t1 A t2 begin_transaction A t3 cit(b alx) A t4 bal x = balx - 10 A t5 scrie(bal x) A t6 commit Se ved că balx are valoarea greşită 90.

Unitatea 5.5 5.5.1 Ce este blocajul? 1) Când o tranzacţie blochează partajat o anumită unitate de memorie, o altă tranzacţie nu mai poate să rescrie tot acolo, iar când o tranzacţie 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 următor. Cele două trnzacţii T10 şi T11 se blochează reciproc. Time T10 T11 A t1 A t2 A t3 A t4 A t5 A t6 A t7 A t8 A t9 A t10 A t11 begin_transaction ex_bloc(bal x) cit(bal x) bal x = balx -10 scrie(bal x) ex_bloc(bal y) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ … …

begin_transaction ex_bloc(bal y) cit(bal y) bal y = bal y +100 scrie(bal y) ex_bloc(bal x) AŞTEAPTĂ AŞTEAPTĂ AŞTEAPTĂ …

5.5.3 Ce este protocolul de blocare în două faze? 1) Protocolul de blocare în două faze constă din împărţirea tranzacţiei în două faze una de blocări şi creşteri de blocaje şi a doua de descreşteri şi deblocaje. Aceasta înseamnă că după ce s-a făcut prima deblocare nu se mai pot face blocări. 5.5.4 Care este protocolul de control cu marcarea timpului (time stamp)? Protocolul cu marcarea timpului (time stamp) ataşează un timp fiecărei tranzacţii (marc(T)) şi timpul tranzacţiei care realizează operaţia fiecărei citiri sau scrieri a unei

161

înregistrări. Deci fiecare tranzacţie va avea o valoare de marcaj şi fiecare înregistrare prelucrată va avea două marcaje; unul care spune ce marcaj a avut tranzacţia care a citit-o (cit_marc) şi celălalt care spune ce marcaj a avut tranzacţia care a scris-o (scri_marc). Numai în următoarele trei situaţii se pun probleme deosebite: 1. Tranzacţia T cere să citească o înregistrare x care a fost deja actualizată de o tranzacţie cu scri_marc(x) > marc(T), adică o înregistrare scrisă de o tranzacţie care a început mai târziu. Ce ar rescrie ea ar putea da naştere la inconsistenţă deci trnzacţia respectivă trebuie întreruptă. 2. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o tranzacţie care a început mai tîrziu marc(T) < cit_marc(x). Aceasta înseamnă că tranzacţia vrea să rescrie o înregistrare, pe care o altă tranzacţie începută mai târziu, a citit-o şi o foloseşte. Şi în acest caz tranzacţia trebuie întreruptă. 3. Tranzacţia cere să scrie o înregistrare x a cărei valoare a fost deja scrisă de o tranzacţie care a început mai târziu, 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 concurenţei? O tehnică optimistă înseamnă să lăsăm tranzacţiile să ruleze fără să impunem întârzieri care să asigure serializabilitatea, iar când o tranzacţie vrea să facă ‘commit’, să efectuăm un control care să determine dacă a avut loc un conflict. Dacă a avut loc un conflict, tranzacţia trebuie întreruptă şi restartată. Pentru că am spus că aceeste conflicte sînt rare, aceste înteruperi şi restartări vor fi, şi ele, rare. Unitatea 5.6 5.6.1 Care sunt restricţiile de integritate? integritatea entitatii integritatea referentiala restrictiile de domeniu restricţiile de intreprindere

5.6.2 Ce înseamnă integritatea entitatii? 1) Intr-o relaţie 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 relaţie, ori valoarea cheii externe trebuie să se potriveasca cu valoarea unei chei candidat a vreunui tuplu în relaţia de origine, ori valoarea cheii externe trebuie să fie nulă. 5.6.4 Ce înseamnă restrictiile de domeniu? Aceste restricţii se pot referi la tipul de date pentru un atribut, la o listă de valori posibile, la un ordin de mărime, la un format sau o formă, la o condiţie 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? Noţiunea de securitate a bazei de date este de obicei asociată cu accesul răuvoitor, pe cand integritatea se refera la evitarea pierdelor accidentale de consistenţă

162

6 Cum poate fi încălcată securitatea datelor într-o baza de date ? Securitatea este in general asociată cu urmatoarele situaţii: -acces fraudulos la date.8 Enumeraţi forme de autorizare. -pierderea caracterului privat al datelor. -pierderea disponibiliţatii datelor. -la nivel uman – este recomandabil sa se acorde autorizaţiile de acces cu multa grijă şi să se ţină evidenţe stricte ale persoanelor autorizate -la nivel sistem de operare – slăbiciunile protecţiei la nivel de sistem de operare trebuie eliminate sau compensate de alte măsuri -la nivel SGBD – sistemul ofera anumite facilităţi care sprijina protecţia datelor.6.7 Enumeraţi măsuri de protecţie pentru asigurerea securităţii datelor. Forme de autorizare: -autorizare la citire (consultare) -autorizare la inserare (adăugare) -autorizare la actualizare (care exclude ştergerile) -autorizare la ştergeri (la nivel de tuplu) In situaţiile de mai sus nu se pune problema modificarilor la nivel de schemă a bazei de date. Pentru protectia bazei de date se pot lua masuri de asigurare a securităţii la mai multe nivele: -la nivel fizic . 5.5. Dacă considerăm şi acest aspect putem vorbi de: -autorizare la nivel de index (creare-ştergere de indecşi) -autorizare la nivel de relaţii (creare) -autorizare de modificări la nivel de relaţii (ştergeri sau adăugari de atribute în cadrul relaţiilor) -autorizări de ştergeri ale relaţiilor. 163 .locurile în care se afla calculatoarele trebuie protejate de accesul persoanelor neautorizate.6. 5. -pierderea confidenţialitatii (secretului) datelor.6.

Ed. McGraw Hill. Baze de date Ed. Cluj.C.Harrington. 164 .Theorie und Praxis relationaler Datenbanken.Silberschatz . Bucuresti. Bodea C.A. Assison-Wesley.Bâscă – Baze de date. A.Baze de date pentru începători.L. New York. 1992 [11] R Steiner .Ţâmbulea . Ionita C.Korth. 1987 [3] T.1998.Structuri de date şi bănci de date.All.Bibliografie. Access la purtător Ed.ALL 1995 [6] Iacob P. Stanescu şi colectiv .Lux libris 2008 [10] M.Strachan – Database Systems. 2000 [8]iacob P. Vieweg Verlag. Universităţii din Piteşti. Universitatea Babeş-Bolyai. 1997 [4] O.1997 [5] Lungu I.Relational database design. Badescu G. 1994 [12] J. [1] L.Database System Concepts.Connoly. 1992 [2] H.Limbaje de programare şi bănci de date. Oracle la purtător Ed.Begg.F.Lux libris 2007 [9]iacob P. ASE.AP PROFESSIONAL.

Sign up to vote on this title
UsefulNot useful