Sunteți pe pagina 1din 169

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 face,
la începutul cursului nostru, o scurtă trecere în revistă a metodelor tradiţionale
de prelucrare a datelor, 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

1
Î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.
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

2
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 sat dr baze de date pentru e-comerţ.

Resurse
Pentru a proiecta un sistem cu bază de date vom folosi sistemul APEX Oracle.

Structura cursului
Cursul de baze de date este structurat în şase module, astfel: primul modul
cuprinde trei 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, al cincilea modul cuprinde trei unităţi de învăţare, iar al şaselea
modul cuprinde două 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 cursului.

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 2-3 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 3 şi 4 care va deţine o pondere de 60% în
nota finală şi notele aferente celor două capitole de la laborator: proiectul logic al
unui sistem cu baza de date şi proiectul în Apex realizat după îndrumarul de
laborator.

Spor la treaba !

3
CUPRINS

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


Unitatea de învăţare 1.1 Istoric; comentarii...............................................6
Criterii minimale de definire a unui SGBDR...........................................11
Unitatea de învăţare 1.2 Abstractizarea datelor........................................15
Unitatea de învăţare 1.3 Principalele componente şi funcţiuni ale unui
SGBD.......................................................................................................22
Modulul 2. Modele de descriere a datelor........................................................32
Unitatea de învăţare 2.1. Generalităţi.......................................................33
Unitatea de învăţare 2.2 Modelare E-R (Entity-Relaţionship).................36
Modulul 3. Limbaje de cereri...........................................................................51
Unitatea de învăţare 3.1 Algebra relaţională............................................52
Unitatea de învăţare 3.1 SQL...................................................................66
Modulul 4. Normalizarea..................................................................................89
Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce
instrumente facem normalizarea...............................................................90
Unitatea de învăţare 4.2 Forme normale.................................................98
Modulul 5. Metodologia de proiectare a bazelor de date relaţionale............105
Unitatea de învăţare U5.1 Generalităţi şi proiectarea conceptuală.........106
Unitatea de învăţare U5.2 Proiectarea logică.........................................118
Unitatea de învăţare U5.3 Proiectarea fizică..........................................132
Modulul 6 Tranzacţii şi concurenţă................................................................137
Unitatea de învăţare U6.1 Tranzacţii şi concurenţă................................138
Unitatea de învăţare U6.2 Metode de control al concurenţei.................143

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

Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3
U1. Istoric; comentarii
U2. Abstractizarea datelor
U3. Principalele componente şi funcţiuni ale unui SGBD

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.

5
Unitatea de învăţare 1.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 acestei unităţi de învăţare este de 2 ore.

Istoric; comentarii
Bazele de date au 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

6
 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ă
 un limbaj de manipulare a datelor (LMD)
Cu toate că nu a fost adoptată formal de ANSI (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
introducea modelul de date relaţional.
De atunci 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 performante 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?

7
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ă 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.
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. Deci 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.
Aceste 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 (cataloage). Referinţa la 'nivelul logic' înseamnă că
construcţia fizică nu este reprezentată şi nu necesită explicaţie.

8
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ă 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

9
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,
 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

10
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 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:

11
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 ca î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 altă parte, permite accesul controlat la informaţiile din baza de
date în cauză. SGBD este format din 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;

12
- î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.

1) Din punctul de vedere al sistemelor de calcul pe care se implementează.


SGBD pot fi:

a) sisteme de gestiune pentru calculatoarele mari;

b) sisteme de gestiune pentru minicalculatoare;

c) 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 distribuite.

13
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:
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:

14
 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

Unitatea de învăţare 1.2 Abstractizarea datelor

M1.U2.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.

15
M1.U2.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 acestei unităţi de învăţare este de 2 ore.

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ă.
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ă:

16
- 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.

Utilizator 1 Utilizator 2 Utilizator n

Nivel
View 1 View 2 ….. View n
extern

Nivel Schema
conceptual conceptuala

17
Nivel Schema
intern interna

Organizarea la
nivel fizic a datelor Baza de
date

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ă,

18
î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.
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ă.

19
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ă rescrierea 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.

M1.U2.3. 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.U2.4. Test de autoevaluare a cunoştinţelor


1) Ce ar trebui memorat despre profesori într-o bază de date a
facultăţii?

20
2) Ce nu ar trebui memorat despre profesori într-o bază de date
a facultăţii?
3) Ce este arhitectura pe trei nivele?
Răspunsurile se găsesc la sfârşit la pag154

Unitatea de învăţare 1.3 Principalele componente şi funcţiuni ale unui


SGBD

M1.U3.1. 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.U3.2. Obiectivele unităţii de învăţare


La sfârşitul acestei unităţi de învăţare studenţii vor fi capabili să:
 descriem componenţa unui Sistem de Gestiune al Bazei de Date

21
 cunoaştem obiectivele unui SGBD
 sa cunoaştem şi să utilizăm funcţiunile unui SGBD

Durata medie de parcurgere a acestei unităţi de învăţare este 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.
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

22
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.
In 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

23
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 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.

24
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;

25
- 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.
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

26
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.

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, realizează 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,

27
- 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.
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

28
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.U3.3. 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
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.

29
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.U3.4. Test de autoevaluare a cunoştinţelor
1) Care sunt obiectivele unui SGBD?
2) Care sunt funcţiunile unui SGBD?

30
Răspunsurile se găsesc la sfârşit la pag154

Modulul 2. Modele de descriere a datelor

Cuprins
Introducere.......................................................................................................................3

31
Obiectivele modulului.....................................................................................................3
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.

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

M2.U1.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

32
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.U1.2. 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 acestei 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 datele 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, fiecare fiind în general de lungime fixa. Exista trei

33
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. Unii autori fac
diferenţa între cele doua denumiri în sensul că se considera că modelul de date
conceptual este într-adevăr independent de orice detalii fizice, pe când modelul
logic presupune cunoaşterea modelului de date ce sta la baza SGBD-ului ce
urmează a fi utilizat. În modulul … se va expune metodologia obţinerii unui
model logic bazat pe modelul de date relaţional.

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.U1.3. 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).

34
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.

M2.U1.4. Test de autoevaluare a cunoştinţelor


1) Care sunt modele de date bazate pe înregistrare?
Răspunsurile se găsesc la sfârşit la pag 155

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

M2.U2.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. Î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

35
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 acestei unităţi de învăţare este 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?

Tipul de entitate reprezintă o mulţime de 'obiecte' ce aparţin lumii reale şi care


sunt descrise de aceleaşi proprietatea.

36
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 entitate 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, telefon,
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.

37
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.
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.

38
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 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.

Exemplu: 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 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.
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

39
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.
Dacă un atribut este compus, atunci componentele atributului se reprezintă
prin elipse legate cu cate o linie de atributul compus.

Exemple
numãr
nu bloc
me locatari adre
sa
numã adre
aparta scar
r sa
ment a
matri adre eta
col sa j
adre
Reprezentarea cu diagrama E-Rsaa entităţii locatari
În exemplu entitatea locatari adre are următoarele atribute:
număr_matricol, nume şi adresa. sa Dintre aceste atribute, atributul
adresa este atribut compus, care se descompune în număr_bloc,
adre
scara, etaj şi apartament. sa 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.

40
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 E1, E2, ..., En tipuri de entitate. Formal, un tip de relaţie este o submulţime a
următoarei mulţimi:
{( e1, e2, ..., en) | unde e1E1, e2E2, ..., enEn }
ceea ce înseamnă că ( e1, e2, ..., en) 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.

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

nume
numă
r de scar numă
a r adr
matri esa
bloc
scări este col locatari
locuită

41
1 M

Reprezentarea cu diagrama E-R a relaţiei este_locuita_de


.

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

lucrator
angajaţi lucrează
manager pentru

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".

42
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ă.

43
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:
Î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

num
num e
ăr de sca numă
ra r adr
matri esa
bloc
scări este col locatari
locuită

1 M

44
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

atribu scări este locuita atribu


locatari nr_ma
te
nr_blo de
R1 te
c Sc. Fam.1 t
scara A numel
R2 e
Fam.2
nr_blo Sc.B R3
c Fam.3 nr_ma
scara Sc.C t
Reprezentarea cu reţele semantice a relaţiei 1:Mnumel
este_locuita_de
e
nr_blo
c Reprezentaţi cu reţea semantică relaţia dintre student şi catalog.
scara nr_ma
t
Să ne reamintim... numel
e
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

45
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.

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

46
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.
In 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.

47
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 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.

- 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.

48
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.
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.3. 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 implicate.
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.

49
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.U2.4. Test de autoevaluare a cunoştinţelor


1) Găsiţi cheile candidat ale tabelei student.
2) Stabiliţi cheia primară.
3) Daţi exemple de relaţii unu la unu, unu la mai mulţi şi
mulţi la mulţi.
4) Stabiliţi domeniul fiecărui atribut din tabela profesor.
Răspunsurile se găsesc la sfârşit la pag 155

Modulul 3. Limbaje de cereri.

Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3

U3.1 Algebra relaţională.


U3.2 SQL.

50
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.

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

M3.U1.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.

51
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.U1.2. 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 acestei unităţi de învăţare este de


2 ore.

Algebra relaţională
Structura relaţionala a datelor
Prezentarea structurii relaţionale a datelor impune reluarea noţiunilor
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.
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

52
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 date

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 înregistrare.

53
Î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: D3 D1 D2
“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 tabelei 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(A1:D1, …, An:Dm) A1:D1 … An:Dm

a) b)

54
Operatorii modelului relaţional.
Modelul relaţional oferă două colecţii de operatori pe relaţii şi anume:
- algebra relaţionala;
- calculul relaţional.
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, proiecţ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 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ă.
Notaţia uzuală pentru reuniune este: R1 U R2
Reprezentarea grafică a reuniunii este prezentata in fig. 3.3.
Exemple

55
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

Exemple

56
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 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.
Notaţia uzuală pentru desemnarea operaţiei este: R1xR2
Exemple
TRANSPORT
RAŞ:D1 JUDEŢ:D1
Braşov Braşov
Târgovişte Dâmboviţa

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

X
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

57
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ă

58
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. 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

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:

59
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ă:
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 diferă 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

60
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

Exemple

61
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.

Fig.3.12. Reprezentarea grafica a operatiei de intersectie

Exemple

62
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)

63
M3.U1.3. 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ă

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.

64
M3.U1.4. Test de autoevaluare a cunoştinţelor
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.
2. Să se exprime în algebra relaţională cererile:
a) Studenţii grupei 7202
b) Studenţii care sunt şi profesori
c) Studenţii corigenţi
d) Studenţii integralişti

65
Unitatea de învăţare 3.2 SQL

M3.U2.1. 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.U2.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 actualizpri ale bazei de date

Durata medie de parcurgere a acestei 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 regă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.

66
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 multiple ( 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.

Lista_selecţie
Cuprinde toate câmpurile care vor aparea în tabela cu rezultatele 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ţională.
Î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 interogă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)

67
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

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

68
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)
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.

69
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

4.2.2. 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)

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>

70
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, limbajul 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(*)
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(*)

71
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.
SELECTC Cod_caseta, [Nume] &””& [Prenume] AS Numele,
Cod_imprumut, B.Data_imprumut

72
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.).

73
Exemple
Sa se afişeze codurile şi titlurile filmelor de gen acţiune.
SELECT Cod_film<Titlu

FROM Filme
WHERE Gen=”actiune”

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

74
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”)

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 este 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.

75
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”

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

76
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:

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

77
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 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>
Se observă că această construcţie a fost deja utilizată în exemplul de
mai sus care 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 nterogarea
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.

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: =,< > >= <= !=

78
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 casetele 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);

79
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.

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.

80
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
_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.

81
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”.
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

82
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 tuplu 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 filmelor de gen fabula.

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

83
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 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.

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

II. Adăugarea mai multor linii prin copierea lor dintr-o tabelă sau mai multe
tabele într-o altă tabelă

84
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:
1. 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.
Exemple
Modificarea tuturor înregistrărilor pentru mărirea salariior tuturor
celor din conducere cu 3%.
UPDATE CONDUCERE

85
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.

M3.U2.3. 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, nume_tabela2…
GROUP BY câmp_de_grupare

86
[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.
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

87
î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.U2.4. 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:
1) (tabel nominal cu locatarii de pe scara = 3 din bloc = 34)
= R1
2) (tabel nominal cu locatarii de pe scara = 1 din bloc = 34)
= R2
3) (tabel nominal cu locatarii de pe scara = 2 din bloc = 34)
= R3
4) tabel nominal cu locatarii de pe scările 1,2,3 ale blocului
34
5) lista apartamentelor cu suprafaţa mai mare decât 50 mp
6) tabel nominal cu persoanele carelocuiesc pe scara 3 bloc
34 şi nu locuiesc şi pe scara 1 a aceluiaşi bloc

88
Modulul 4. Normalizarea

Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3

U4.1 De ce este nevoie de normalizare şi cu ce instrumente facem


normalizarea.
U4.2 Forme normale

89
Unitatea de învăţare 4.1 De ce este nevoie de normalizare şi cu ce
instrumente facem normalizarea.

M4.U1.1. 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.U1.2. 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 acestei unităţi de învăţare este de


1 oră.

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.
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

90
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:
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.

91
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
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 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.
In 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 {R1, R2, …, Rn} daca
n

R = R
i 1
i

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

92
schema R sie fie relatiile r1, r2, …, rn construite pe schemele de relatie ce
formeaza descompunerea. In termenii algebrei relaţionale se poate considera
egalitatea;
ri =  Ri
(r) pentru toti 1in.

Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de


relatie Ri.
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.
5.2. 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 t1 şi t2 din r, pentru care t1[A]=t2[A], are loc
intotdeauna şi t1[B]=t2[B].
Aceasta inseamna ca atunci cand un tuplu t 1 are (pe submultimea de atribute
A) aceeasi valoare cu alt tuplu t2, 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
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

93
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 t2 din r, pentru
care t1[K]=t2[K], are loc intotdeauna şi t1[R]=t2[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 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

94
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 jonctiune
Fie o descompunere oarecare {R1, R2, …, Rn} a relatiei R, asa cum am definit-
o formal la inceputul acestui capitol. Pentru o descompunere oarecare se
verifica intotdeuna relatia:
n
r X ri
i 1

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 ti
in fiecare relatie ri. 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.
In 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, R2, …,
Rn} a unei scheme de relatie R este o descompunere fara pierderi la jonctiune

95
pentru R, 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.
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+:
R1R2R1
R1R2R2
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 {R1, R2, …, Rn} o descompunere a lui R. Notam cu Fi restrictia la Ri a
multimii de dependente functionale F. (Se cere ca dependentele functionale din
Fi sa includa doar atribute care se regasesc in relatia Ri).
Vom obtine un set de multimi de dependente functionale F1, F2, …, Fn. Fie F'=
n

 Fi, reuniunea seturilor de dependente funtionale. In general F'F. Dar s-ar


i 1

putea ca sa se verifice relatia F'+=F+. Daca se intampla asa atunci spunem ca


descompunerea este o descompunere cu pastrarea dependentei.

M4.U1.3. 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 {R1, R2, …, Rn} daca
n

R = R
i 1
i

Aceasta inseamna ca orice atribut din schema de relatie initiala R se


regaseste in cel putin o schema de relatie din descompunere. Daca ne

96
raportam la relatiile care se bazeaza pe schemele de mai sus, fie r relatia
construita pe schema R sie fie relatiile r1, r2, …, rn construite pe schemele de
relatie ce formeaza descompunerea. In termenii algebrei relaţionale se poate
considera egalitatea;
ri =  Ri
(r) pentru toti 1in.

Deci fiecare ri este proiectia relatiei r pe atributele care apar in schema de


relatie Ri.
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.
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 t2 din r, pentru care t1[A]=t2[A], are loc
intotdeauna şi t1[B]=t2[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.U1.4. Test de autoevaluare a cunoştinţelor


Descoperiţi dependenţele funcţionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

97
Unitatea de învăţare 4.2 Forme normale

M4.U2.1.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.U2.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 acestei unităţi de învăţare este de 2 ore.

Normalizarea este un proces de organizare a datelor in relatiile unei baze de


date. 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:

98
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
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

99
Î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
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ă
totală.
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.

100
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)
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
primare nu este tranzitiv dependent de cheia primara.

101
Î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
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

102
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.U2.3. 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.

103
M4.U2.4. Test de autoevaluare a cunoştinţelor
1) Aduceţi la forma normală 1 urmărtoarea tabelă:
Relaţia Furnizori_Cheltuieli:

Cod Denumire Cod Nr. Cod Denumire Valoare


Furn. fiscal Crt. Chelt. Cheltuială
F100 Romgaz R1234567 1 C15 Chelt pt. 1500000
Încălzire
2 C16 Chelt pt. 500000
Bucătării
F110 Renel R7654321 3 C10 Chelt cu 3000000
iluminatul
4 C11 Chelt pt. 200000
Func.
liftului
2) Aduceţi la forma normală 2 schema:
(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Nr.
Crt., Cod, Valoare)
3) Aduceţi la forma normală 3 schema:
carte = (c_carte, titlu, cod_domeniu, den_domeniu)
4 ) Aduceţi, pe rând, la formă nprmală 1, 2 şi 3 tabela:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

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

Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3

U5.1 Generalităţi şi proiectarea conceptuală


U5.2 Proiectarea logica
U5.3 Proiectarea fizica

Introducere
Metodologie 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.

105
Unitatea de învăţare U5.1 Generalităţi şi proiectarea conceptuală

M5U1.1 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.2 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 acestei 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

106
î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 unui 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.
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 salarizare, 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 utilizatori
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

107
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 diferite instrumente
software de proiectare. Această fază este puternic consumatoare de timp, dar este
crucială pentru succesul sistemului informatic.
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.

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.

108
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.
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ă

109
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 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

110
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:
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.

111
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

112
informaţii separat, deci vom descompune acest atribut în cele
patru atribute simple.
Descompuneţi atributul adresă din tabela student.

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,

113
 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,
 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ă.

114
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.
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.

115
 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.U1.3. 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 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.
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).

116
 Pasul 1.7. Desenarea diagramei entity-relationship.
 Pasul 1.8. Verificarea modelului conceptual local cu ajutorul
utilizatorului.

M5.U1.4. Test de autoevaluare a cunoştinţelor


Realizaţi paşii de proiectare conceptuala locală pentru
subsistemul didactic din facultate.

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

117
la schema conceptuală şi schemele externe de nivel înalt independente 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.

118
 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ă.

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

Sunt platite de

119
Scari Cheltuieli
Nr_Bloc Nr_Crt
Pe scari
Scara Cod_Furnizor (FK)
Scara (FK)
Lift Nr_Crt (FK) Cod_cheltuiala
Nr_Bloc (FK) Nr_factura
Data_factura
Valoare_factura

Au cheltuieli Se calculeaza

a). Relaţie de tipul N:M. (b). Relaţie transfornamtă în două relaţii


1:M.
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

120
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.
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
Exemplu de model logic.
Descrieţi relaţia dintre student şi catalog.

Tipurile de entităţi slabe

121
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
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

122
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 procedurile 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ă

Exemplu de relaţie pentru


validarea prin tranzacţii.

123
Cheltuieli Furnizori
Nr_Crt Cod_Furnizor

Cod_Furnizor (FK) Denumire


Cod_cheltuiala Cod_fiscal (AK1)
Nr_factura Cont
Data_factura Banca
Valoare_factura Strada
Nr
Bl
Sc
Provoaca Ap
Localitate
Judet

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,

124
 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.
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.

125
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, atunci 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.
 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.

126
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.
 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.

127
(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.

128
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.

129
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ă.
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.

M1.U1.6. 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.

130
M5.U2.7. Test de autoevaluare a cunoştinţelor
Faceţi proiectul logic local pentru subsistemul didactic al
facultăţii.

131
Unitatea de învăţare U5.3 Proiectarea fizică.
M5U3 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.U3. 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 acestei unităţi de învăţare este de 1 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

132
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.).
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

133
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
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

134
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)
Număr maxim de utilizatori simultani
Suport pentru XML

M1.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 mechanism de securitate.
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.

135
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

M1.U5.3. Test de autoevaluare a cunoştinţelor


Realizaţi, în ACCESS, proiectul fizic al subsistemului didactic
al facultăţii.

Modulul 6 Tranzacţii şi concurenţă.

136
Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3
M6U1 Introducere
Î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.

M6.U1. Obiectivele modulului


La sfârşitul acestui modul studenţii vor fi capabili să:
 construiască tranzacţii
 să aleagă cea mai bună metodă de control al concurenţei

U6.1 Tranzacţii şi concurenţă


U6.2 Metode de control al concurenţei.

Unitatea de învăţare U6.1 Tranzacţii şi concurenţă

M6.U1.1 Introducere

O tranzacţie (transaction) este o unitate logică de prelucrare indivizibilă


(atomică) a datelor unei baze de date prin care se asigură consistenţa acesteia.

137
Î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.

M6.U1.2 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 acestei unităţi de învăţare este de 1 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:

cit (nrmat = x, salariu)


salariu = salariu * 1,1
scrie (nrmat = x, salariu)

care măreşte salariul cu 10%

cit (nrmat =x )
şterge (nrmat = x )

138
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 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 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.
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ă.

139
Time T1 T2 balx

A t1 begin_transaction 100
A t2 begin_transaction cit(balx) 100
A t3 cit(balx) balx = balx + 10 100
A t4 balx = balx - 10 scrie(balx) 200
A t5 scrie(balx) commit 90
A t6 commit 90

Figura 6.1.1

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.

Time T3 T4 balx

A t1 begin_transaction 100
A t2 cit(balx) 100
A t3 balx = balx + 10 100
A t4 begin_transaction scrie(balx) 200
A t5 cit(balx) 200
A t6 balx = balx - 10 rollback 100
A t7 scrie(balx) 190
A t8 commit 190

Figura 6.1.2.

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 T5 şi T6 executate serial, adică una după alta, ar trebui să dea
rezultatele:
T5T6 balx=100-10=90, balz=25+10=35, sum=90+50+35+175
sau T6T5 sum=100+50+25=175, balx=100-10=90, balz=25+10=35
şi putem vedea în figura următoare ce se poate întâmpla încazul concurenţei libere,
necontrolate:

Time T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25
A t2 begin_transaction sum = 0 100 50 25 0
A t3 cit(balx) cit(balx) 100 50 25 0
A t4 balx = balx sum = sum + 100 50 25 100
-10 balx

140
A t5 scrie(balx) cit(baly) 90 50 25 100
A t6 cit(balz) sum = sum + 90 50 25 150
baly
A t7 balz = balz + 90 50 25 150
10
A t8 scrie(balz) 90 50 35 150
A t9 commit cit(balz) 90 50 35 150
A t10 sum = sum + 90 50 35 185
balz
A t11 commit 90 50 35 185

Figura 6.1.3.
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.

M6.U1.3. 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.

141
M6.U1.4. Test de autoevaluare a cunoştinţelor
Daţi exemple de pierdere a consistrenţei.

142
Unitatea de învăţare U6.2 Metode de control al concurenţei.

M6.U2.1 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).

M6.U2..2 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 acestei 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ţie 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 T1 şiT2 din figura 6.1.1 respectiv T 3 şi T4
din figura 6.1.2 şi T5 şi T6 din figura 6.1.3 cu protocolul în două faze şi realizează planuri
serializabile.

Time T1 T2 balx

A t1 begin_transaction 100
A t2 begin_transaction ex_bloc(balx) 100
A t3 ex_bloc(balx) cit(balx) 100
A t4 AŞTEAPTĂ balx = balx +100 100
A t5 AŞTEAPTĂ scrie(balx) 200
A t6 AŞTEAPTĂ debloc(balx) 200

143
A t7 cit(balx) commit 200
A t8 balx = balx -10 200
A t9 scrie(balx) 190
A t10 debloc(balx) 190
A t11 commit 190

Figura 6.2.1

Time T3 T4 balx

A t1 begin_transaction 100
A t2 ex_bloc(balx) 100
A t3 cit(balx) 100
A t4 begin_transaction balx = balx +100 100
A t5 ex_bloc(balx) scrie(balx) 200
A t6 AŞTEAPTĂ debloc(balx) 100
A t7 AŞTEAPTĂ rollback 100
A t8 cit(balx) 100
A t9 balx = balx -10 100
A t10 scrie(balx) 90
A t11 debloc(balx) 90
A t12 commit 90

Figura 6.2.2
Time T5 T6 balx baly balz sum

A t1 begin_transaction 100 50 25
A t2 begin_transaction sum = 0 100 50 25 0
A t3 ex_bloc(bal x 100 50 25 0
)
A t4 cit(balx) part_bloc(balx) 100 50 25 0
A t5 balx = balx AŞTEAPTĂ 100 50 25 0
-10
A t6 scrie(balx) AŞTEAPTĂ 90 50 25 0
A t7 ex_bloc(balz AŞTEAPTĂ 90 50 25 0
)
A t8 cit(balz) AŞTEAPTĂ 90 50 25 0
A t9 balz = balz + AŞTEAPTĂ 90 50 25 0
10
A t10 scrie(balz) AŞTEAPTĂ 90 50 35 0
A t11 debloc(bal x , AŞTEAPTĂ 90 50 35 0
balz)
A t12 commit AŞTEAPTĂ 90 50 35 0
A t13 cit(balx) 90 50 35 0

144
A t14 sum = sum + balx 90 50 35 90
A t15 part_bloc(baly) 90 50 35 90
A t16 cit(baly) 90 50 35 90
A t17 sum = sum + baly 90 50 35 140
A t18 part_bloc(balz) 90 50 35 140
A t19 cit(balz) 90 50 35 140
A t20 sum = sum + balz 90 50 35 175
A t21 debloc(balx,baly,balz 90 50 35 175
)
A t22 commit 90 50 35 175

Figura 6.2.3

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 T7 face rollback (dintr-un motiv
extern) şi, pentru că T8 este dependentă de T7 care a citit o înregistrare care a fost
actualizată de T7, trebuie să facă şi T8 rollback, ceea ce pe urmă se întâmplă şi cu T9.

Time T7 T8 T9

A t1 begin_transaction
A t2 ex_bloc(balx)
A t3 cit(balx)
A t4 part_bloc(baly)
A t5 balx = baly +
balx
A t6 scrie(balx)
A t7 debloc(balx) begin_transaction
A t8 … ex_bloc(balx)
A t9 … cit(balx)
A t10 … balx = balx +100
A t11 … scrie(balx)
A t12 … debloc(balx)
A t13 … …
A t14 rollback …
A t15 rollback begin_transaction
A t16 part_bloc(bal
x )
A t17 …
A t18 rollback
Figura 6.2.4
O altă problemă este blocarea ciclică prezentată în exemplul următor. Cele
două trnzacţii T10 şi T11 se blochează reciproc.
Time T10 T11

A t1 begin_transaction

145
A t2 ex_bloc(balx) begin_transaction
A t3 cit(balx) ex_bloc(baly)
A t4 balx = balx -10 cit(baly)
A t5 scrie(balx) baly = baly +100
A t6 ex_bloc(baly) scrie(baly)
A t7 AŞTEAPTĂ ex_bloc(balx)
A t8 AŞTEAPTĂ AŞTEAPTĂ
A t9 AŞTEAPTĂ AŞTEAPTĂ
A t10 … AŞTEAPTĂ
A t11 … …
Figura 6.2.5
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 6.2.5 graful ar
fi următorul:
y
T10 T11
x

Figura 6.2.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 marcaj ş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.

146
Time Op T7 T8 T9

A t1 begin_transaction
A t2 cit(balx) cit(balx)
A t3 balx = balx +10 balx = balx +100
A t4 scrie(balx) scrie(balx) begin_transaction
A t5 cit(baly) cit(baly)
A t6 baly = baly +20 baly = baly +20 begin_transaction
A t7 cit(baly) cit(baly)
A t8 scrie(baly) scrie(baly)**
A t9 baly = baly +30 baly = baly +30
A t10 scrie(baly) scrie(baly)
A t11 balz=100 balz=100
A t12 scrie(balz) scrie(balz)
A t13 balz=50 balz=50 commit
A t14 scrie(balz) scrie(balz)* begin_transaction
A t15 cit(baly) commit cit(baly)
A t16 baly = baly +20 baly = baly +20
A t17 scrie(baly) scrie(baly)
A t18 commit

Figura 6.2.7
* la timpul t8 scrierea de către tranzacţia T13 violează regula 2 şi de aceea este întreruptă
şi reluată la momentul t14
** la timpul t14 scrierea de către tranzacţia T12 poate fi ignorată conform celei de a treia
reguli
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

147
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ătoarele 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:
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.

148
M6.U2.3. Rezumat
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ă.

Se pune 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.
Simpla blocare urmată cândva de deblocare (debloc) nu asigură
serializabilitatea.
Serializabilitatea este asigurată dacă se respectă protocolul de blocare în
două faze care 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.
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 marcaj ş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).
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.
Control optimist al concurenţei are trei faze.
 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.
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.

149
M6.U2.4 Test de autoevaluare a cunoştinţelor
1. Ce este blocajul?
2. Ce este blocaju ciclic? Exemplu.
3. Ce este protocolul de blocare în două faze?
4. Care este protocolul de control cu marcarea timpului (time stamp)?
5. Ce este o tehnică optimistă de control al concurenţei?

Modulul 7. Capitole speciale de baze de date

150
Cuprins
Introducere.......................................................................................................................3
Obiectivele modului.........................................................................................................3

U7.1 Securitate şi integritate


U7.2 Baze de date distribuite
Unitatea de învăţare U7.1 Securitate şi integritate

M7U1 Introducere

M7.U1. Obiectivele unităţii de învăţare


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

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

M1.U1.7. Test de autoevaluare a cunoştinţelor

Unitatea de învăţare U7.2 Baze de date distribuite

M7U2 Introducere

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

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

M1.U1.6. Rezumat

M1.U1.7. Test de autoevaluare a cunoştinţelor

Raspunsuri la intrebări.
1) Fie tabela din enunţ:
Cod Denumire Cod Nr. Cod Denumire Valoare
Furn. fiscal Crt. Chelt. Cheltuială
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 Denumire Cod Nr. Cod Denumire Valoare
Furn. fiscal Crt. Chelt. Cheltuială
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.
Î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:

152
Furnizori (Cod Furn., Denumire, Cod fiscal)
Cheltuieli (Cod Furn., Cod Chelt., Nr. Crt., Denumire cheltuială, Valoare)
Cele două tabele astfel create sunt în 1NF:
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)
4) 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).

M1.U1.4. Test de autoevaluare a cunoştinţelor


1) Ce ar trebui memorat despre profesori într-o bază de date a facultăţii?
2) Ce nu ar trebui memorat despre profesori într-o bază de date a facultăţii?
3) Ce este arhitectura pe trei nivele?
Răspunsuri:
1) profesor=(cnp,nume,prenume,adresa,grad_didactic,titlu_stiintific,anul_titlului,data_nasterii,
catedra)
2) materii predate,facultatea,salariulinaltimea,greutatea etc
3) Descrierea generală a unei baze de date se numeşte schema bazei de date. Conform nivele
de abstractizare a datelor există trei tipuri de scheme pentru fiecare bază de date. Există
general) mai multe scheme externe (numite şi subscheme) care descriu diferitele view-uri
bazei de date. La nivelul conceptual există schema conceptuală iar la nivelul cel mai de jos
abstractizare există schema internă.

M1.U3.4. Test de autoevaluare a cunoştinţelor


1) Care sunt obiectivele unui SGBD?
2) Care sunt funcţiunile unui SGBD?

153
Răspunsuri:
1) Asigurarea independentei datelor.
Asigurarea unei redundante minime şi controlate a datelor din
baza de date.
Asigurarea unor facilităţi sporite de utilizare a datelor.
Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate
sau neintenţionate.
Asigurarea partajabilităţii datelor
2) Funcţiunile unui SDGBD sunt:
Funcţia de descriere a datelor.
Funcţia de manipulare a datelor
- 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 utilizare asigură mulţimea interfeţelor necesare
pentru comunicarea tuturor utilizatorilor cu baza de date
Funcţia de administrare a bazei de.

M2.U1.4. Test de autoevaluare a cunoştinţelor


1) Care sunt modele de date bazate pe înregistrare?
Răspuns:
1) 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.

M1.U2.4. Test de autoevaluare a cunoştinţelor


1) Găsiţi cheile candidat ale tabelei student.
2) Stabiliţi cheia primară.
3) Daţi exemple de relaţii unu la unu, unu la mai mulţi şi mulţi la mulţi.
4) Stabiliţi domeniul fiecărui atribut din tabela profesor.

Răspunsuri
1)student=(numar_matricol,cnp,nume,prenume,adresa,grupa,data_nasterii,)
Chei candidatsunt:
a) numar_matricol
b) cnp

154
c) nume,prenume,adresa,data_nasterii
2) numar matricol pentruca contine cele mai putine atribute, si este mai scurta decat cnp.
3) a) Unu la unu: barbat femeie in relatia de casatorie.
b) Unu la mai multi: editura are mai multe carti dar o carte este editata de o anumita editura.
c) la multi: Student cu materiile facute.
4)
profesor=(cnp,nume,prenume,adresa,grad_didactic,titlu_stiintific,anul_titlului,data_nasterii,
catedra)
cnp – numeric de 10 cifre
nume - alfabetic
prenume - alfanumeric
adresa - alfanumeric
grad_didactic - alfabetic
titlu_stiintific - alfabetic
anul_titlului – numeric 4 cifre
data_nasterii - data calendaristica
catedra - alfabetic

M5.U1.4. Test de autoevaluare a cunoştinţelor


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.
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ăspunsuri:
1) STUDENT
NR_MATRICOL CNP NUME GRUPA
12345 1950604080022 ANCU ION 7202
13456 2950607300045 BANU ANCA 7201
15671 1941004080066 COSTEA DAN 7202
34561 1950609080078 NANU 7202
CORNEL
45321 2930621080044 MARA DANA 7201

155
PROFESOR
NR_MATRICOL NUME GRAD
3452 BANC TEO PROF
4325 CONU DECAN CONF
5647 DUMITRU ION CONF
7654 ENACHE ANCA LECTOR

MATERII
COD_MATERIE DEN_MATERIE
12 BAZE DE DATE
15 ALGORITMICA
22 STRUCTURI DE DATE

CATALOG
COD_MATERIE NR_MATRICOL NOTA
12 12345 5
15 12345 6
22 12345 7
12 13456 7
15 13456 8
22 13456 8
12 15671 10
12 45321 4
22 45321 4

a) GRUPA=7201STUDENT da urmatorul
tabel:
NR_MATRICOL CNP NUME GRUPA
13456 2950607300045 BANU ANCA 7201
45321 2930621080044 MARA DANA 7201

b) T1= 
NUMESTUDENT da urmatorul tabel:

156
NUME
ANCU ION
BANU ANCA
COSTEA DAN
NANU CORNEL
MARA DANA

c) T2=  NUME PROFESOR da urmatorul tabel:


NUME
BANC TEO
CONU DECAN
DUMITRU ION
ENACHE ANCA

d) T1 U T2 da urmatorul tabel:
NUME
ANCU ION
BANU ANCA
COSTEA DAN
NANU CORNEL
MARA DANA
BANC TEO
CONU DECAN
DUMITRU ION
ENACHE ANCA

e) T3=STUDENT JN CATALOG JN MATERII da urmatorul tabel:


NR_ CNP NUME GRUPA COD_M DEN_ NOTA
MATRICOL ATERIE MATERIE
12345 1950604080022 ANCU 7202 12 BAZE DE DATE 5
ION
13456 2950607300045 BANU 7201 12 BAZE DE DATE 7
ANCA

157
15671 1941004080066 COSTEA 7202 12 BAZE DE DATE 10
DAN
45321 2930621080044 MARA 7201 12 BAZE DE DATE 4
M3.U2.4. Test de autoevaluare a cunoştinţelor
DANA
Se dau următoarele relaţii cu schemele lor:
12345 (Nr_bloc, 1950604080022
-Scări Scara, Lift) ANCU 7202 15 ALGORITMICA 6
ION
-Apartamente(Nr_bloc,Scara,Apartament,Suprafaţa,Cutii_poştale,
Nr_prize_tv)
13456 2950607300045 BANU 7201 15 ALGORITMICA 8
- Familii (Nr_mat, Nr_pers, Nr_pers_prez,ANCA Nr_chei)
-Locatari Nr_Mat, Nr_bloc, Scara, Etaj, Apartament,Nume
12345
Să se exprime în 1950604080022
SQL cererile: ANCU 7202 22 STRUCTURI 7
i. ION
(tabel nominal cu locatarii de pe scara = 3 din bloc = 34) = DE DATE
13456 R1 2950607300045 BANU 7201 22 STRUCTURI 8
ii. (tabel nominal cu locatarii ANCA
de pe scara = 1 din bloc = 34) = DE DATE
R2
45321
b) 2930621080044
(tabel nominal cu locatarii MARA
de pe scara 7201 22= 34) =
= 2 din bloc STRUCTURI 4
R3 DANA DE DATE
c) tabel nominal cu locatarii de pe scările 1,2,3 ale blocului 34
d) lista apartamentelor cu suprafaţa mai mare decât 50 mp
e)
e)
 tabel nominal cu persoanele carelocuiesc pe scara 3 bloc 34
NOTA<5T3 da urmatorul tabel:
şi nu locuiesc şi pe scara 1 a aceluiaşi bloc
NR_
Raspunsuri:CNP NUME GRUPA COD_M DEN_ NOTA
i. MATRICOL
Select nume ATERIE MATERIE
45321 2930621080044 MARA
From locatari 7201 12 BAZE DE 4
DANA DATE
Where scara=3 and nr_bloc=34
45321 2930621080044 MARA 7201 22 STRUCTURI 4
ii. Select nume
DANA DE DATE
2. From locatari

iii.
a) Studenţii grupei 7202.
3) Select nume

Where scara=1 and nr_bloc=34
NUME ( 
GRUPA=7202STUDENT)

b) From
Studenţii care sunt şi profesori. 
locatari SUDENT  
NUME NUME PROFESOR

corigenţi. T4= (
Where scara=2 and nr_bloc=34
iv. c) Studenţii
Select nume NUME SUDENT)
NOTA<5

Studenţii integralişti.  SUDENT \ T4


From locatari
d) NUME
Where scara Beetween 1 and 3 and nr_bloc=34
v. select Nr_bloc,Scara,Apartament
from apartamente
where suprafata > 50
vi. select nume
from locatari
where scara =3 and nume not in
( select nume
from locatari
where scara =1) 158
M4.U1.4. Test de autoevaluare a cunoştinţelor
Descoperiţi dependenţele funcţionale din tabela:
Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))

Raspunsuri:
nrmatricol nume
 adresa
codmateriedenumirematerie
nrmatricol,codmaterienota

M4.U2.4. Test de autoevaluare a cunoştinţelor


1) Aduceţi la forma normală 1 urmărtoarea tabelă:
Relaţia Furnizori_Cheltuieli:
Cod Denumire Cod Cod Denumire Valoare
Furn. fiscal Chelt. Cheltuială
F100 Romgaz R1234567 C15 Chelt pt. 1500000
Încălzire
C16 Chelt pt. 500000

159
Bucătării
F110 Renel R7654321 C10 Chelt cu 3000000
iluminatul
C11 Chelt pt. Func. 200000
liftului
2) Aduceţi la forma normală 2 schema:
(Cod Furn., Denumire, Cod fiscal, Cod Chelt., Denumire cheltuială, Valoare)
3) Aduceţi la forma normală 3 schema:
carte = (c_carte, titlu, cod_domeniu, den_domeniu)
4) Aduceţi, pe rând, la formă nprmală 1, 2 şi 3 tabela:

Student=(nrmatricol,nume,adresa,10(codmaterie,denumirematerie,nota))
Raspunsuri:
1) 1)
1)
Cod Denumire Cod Cod Denumire Valoare
Furn. fiscal Chelt. Cheltuială
F100 Romgaz R1234567 C15 Chelt pt. 1500000
Încălzire
F100 Romgaz R1234567 C16 Chelt pt. 500000
Bucătării
F110 Renel R7654321 C10 Chelt cu 3000000
iluminatul
F110 Renel R7654321 C11 Chelt pt. Func. 200000
liftului

2) Dependente functionale:
Cod Furn. Denumire
Cod Furn. Cod fiscal
Cod Chelt.Denumire cheltuială
Cod Furn., Cod Chelt  Valoare
Primele trei dependente sunt partiale deci nu este FN 3.
Se descompune in:
Furnizori=(Cod Furn., Denumire, Cod fiscal)
Cheltuieli=(Cod Chelt., Denumire cheltuială) si
Chel_la_furn=( Cod Furn., Cod Chelt., Valoare)
3) Dependente functionale:
c_carte titlu
c_carte cod_domeniu
c_carte den_domeniu
cod_domeniu den_domeniu
ultima dependenta este tranzitiva de cheie deci nu avem FN3.
Se descompune in:
Carte1=( c_carte, titlu, cod_domeniu) si
Domenii=( cod_domeniu, den_domeniu)
4)
Forma normala 1:
Student=(nrmatricol,nume,adresa,codmaterie,denumirematerie,nota)
Dependente functionale:
Nrmatricol nume

160
Nrmatricol adresa
Nrmatricol, codmaterie  nota
codmaterie  denumirematerie
Primele doua si ultima sunt dependente partiale deci se obtine FN2 :
Student1=( nrmatricol,nume,adresa)
Materii=( codmaterie,denumirematerie)
Catalog=( Nrmatricol, codmaterie,nota)
Nu avem dependente tranzitive deci este si FN3.
M5.U1.4. Test de autoevaluare a cunoştinţelor
Realizaţi paşii de proiectare conceptuala locală pentru subsistemul didactic din facultate.
Răspuns:
 Pasul 1.1. Identificarea tipurilor de entităţi.
Studenti.
Materii.
Profesori.
Sala.
Orar.
Nume tip de entitate Descriere
Studenti Cei care studiaza.
Materii Obiectul studiului.
Profesori Cei care conduc procesul de

studiu.
Sala Locul unde se desfasoara

procesul
Orar Programul saptamanal de

studiu

 Pasul 1.2. Identificarea tipurilor de relaţii.


Tip de Tip de relaţie Tip de Cardinalitate

entitate entitate
Studenti Studiaza si au Materii M la n

note la
Studiaza dupa Orar Complexa

programul din

Profesori Predau dupa Orar Complexa

161
programul din
Predau Materii 1 la n
Orar Se desfasoara in Sala N la 1

 Pasul 1.3. Identificarea şi atribuirea de atribute la tipurile de entităţi şi tipurile de relaţii.


Tip de date

şi
Tip de Atribute Descriere Reguli

lungime
entitate
Studenti Numar_matricol Int 5 Cheie prim

CNP Int 13

Nume Alfa 10

Prenume Alfa 20

Data_nastere Data cal 8

Adresa Alfa 30

Cod_bugetat Alfa 3

Grupa Int 4

An_sectie Alfa 10

An_studiu Int1

Profesori Numar_matricol Int 5 Cheie prim

CNP Int 13

Nume Alfa 10

Prenume Alfa 20

Data_nastere Data cal 8

162
Adresa Alfa 30

Grd_didactic Alfa 10

Facultatea Alfa 20

Departament Alfa 20
Materii Cod_materie Int 3 Cheie prim

Den_materie Alfa 20

An_sectie Alfa 20
Sala Cod_sala Int 3 Cheie prim

Corp_cladire Alfa 20

Numar_loc Int3

Destinatie Alfa 20
Orar Cod_pozitie Int 4 Cheie prim

Zi Alfa 8

Ora Alfa 5

Grupa Int 4 Se scrie cand


este laorator
sau seminar
An_sectia Alfa 10
Se scrie cand e
curs care se
tine pe

An studiu Int1 Se scrie cand e


pe tot anul

Profesor.cod_matricol Int5

Cod_materie Int 3

 Pasul 1.4. Determinarea domeniilor de definiţie a atributelor.


S-a facut in pasul anterior.
 Pasul 1.5. Determinarea atributelor care compun cheile candidate şi primare.
S-a facut in pasul 1.4.

163
Pasul 2.1. Desenarea diagramei entity-relationship

Pasul 2.2. Proiectarea modelului conceptual local pe un model logic local

Eliminarea relaţiilor M:N.


Avem relatia dintre studenti şi materii. Introducem între ele catalogul.
catalog numar_mattricol Int 5 Cheie prim

Cod_materie Int3 Cheie prim

nota Int2

Eliminarea relaţiilor complexe.

Avem relaţia dintre student şi orar. Introducem Tabela grupa.

grupa Nr_grupa Int 4 Cheie prim

164
An_sectie alfa

an Int1

Eliminarea relaţiilor recursive. Nu avem


Eliminarea relaţiilor cu atribute. Nu avem
Reexaminarea relaţiilor 1:1. Nu avem
Eliminarea relaţiilor redundante. Nu avem

Pasul 2.2. Crearea relaţiilor pentru modelul logic local


Studenti=(Numar_matricol,CNP,Nume,Prenume,Data_nastere,Adresa,Cod_bugetat,Grupa,
An_sectie,An_studiu)
cheie primara: Numar_matricol
cheie straina: Grupa refera Grupa din grupa

Profesori=( Numar_matricol,CNP,Nume,Prenume,Data_nastere,Adresa,Grd_didactic,
Facultatea,Departament)
cheie primara: Numar_matricol

Materii=( Cod_materie,Den_materie)
cheie primara: Cod_materie

Sala=( Cod_sala,Corp_cladire,Numar_loc,Destinatie)
cheie primara: Cod_sala

grupa=( Nr_grupa,An_sectie,an)
cheie primara: Nr_grupa

catalog=(numar_matricol,Cod_materie,nota)
cheie primara: numar_matricol, Cod_materie
cheie straina: Cod_materie refera Cod_materie din materii
cheie straina: numar_matricol refera numar_matricol din studenti

orar=( Cod_pozitie,Zi,Ora,Grupa,An_sectia,An studiu,cod_matricol,cod_materie,cod_sala)


cheie primara: Cod_pozitie
cheie straina: Grupa refera nr_Grupa din Grupa
cheie straina: cod_matricol refera nr_matricol din profesori
cheie straina: cod_materie refera cod_materie din materii
cheie straina: cod_sala refera cod_sala din sala

Pasul 2.3. Validarea modelului, utilizând normalizarea.


Toate tabelele sunt în FN 3.

165
Pasul 2.4. Validarea modelului din nou, utilizând tranzacţiile.
Vom lista , mai întâi, tranzactiile.
T1. Tabel nominal cu studentii grupei…
T2. Catalogul disciplinei… pentru grupa…
T3. Orarul grupei …
T4. Orarul anului…
T5. Orarul profesorului…
T6. Tabel nominal cu studrntii corijenti pentru grupa…
T7. Tabel nominal cu studrntii corijenti pentru anul.. sectia…
T8. Tabel cu materiile pe care le face sectia.

V om scrie,în continuare, frazele SELECT pentru fiecare tranzacţie.


T1. Tabel nominal cu studentii grupei…
SELECT nume, prenume
FROM studenti
WHERE grupa=…

T2. Catalogul disciplinei … pentru grupa…


SELECT nume, prenume,den_materie, nota
FROM studenti, catalog,materii
WHERE grupa=… and studenti.nr_matricol=catalog.nr_matricol and
catalog.cod_materie=materii.cod_materie

T3. Orarul grupei …


SELECT den_materie, zi, ora, profesor.nume,den_sala
FROM orar, materii, profesori,sala
WHERE grupa=… AND orar.cod_materie=materii.cod_materie AND
orar.cod.matricol=profesor.nr_matricol AND sala.cod_sala= orar.cod_sala

T4. Orarul anului…


SELECT den_materie, zi, ora, profesor.nume,den_sala,grupa,an
FROM orar, materii, profesori,sala
WHERE an=… AND orar.cod_materie=materii.cod_materie AND
orar.cod.matricol=profesor.nr_matricol AND sala.cod_sala= orar.cod_sala

T5. Orarul profesorului…


SELECT den_materie, zi, ora, profesor.nume,den_sala,grupa
FROM orar, materii, profesori,sala
WHERE profesor.nume=… AND orar.cod_materie=materii.cod_materie AND
orar.cod.matricol=profesor.nr_matricol AND sala.cod_sala= orar.cod_sala

T6. Tabel noominal cu studrntii corijenti pentru grupa…


SELECT UNIC nume, prenume, grupa
FROM studenti, catalog, materii
WHERE grupa=... AND studenti.nr_matricol=catalog.nr_matricol AND
catalog.cod_materii=materie.cod_materie andnota <5

T7. Tabel noominal cu studrntii corijenti pentru anul.. sectia…


SELECT UNIC nume, prenume, grupa
FROM studenti, catalog, materii

166
WHERE an_sectie=... AND studenti.nr_matricol=catalog.nr_matricol AND
catalog.cod_materii=materie.cod_materie andnota <5

T8. Tabel cu materiile pe care le face sectia.


SELECT den_materie, an_sectia
FROM materii
WHERE an_sectie=...

M1.U1.7. Test de autoevaluare a cunoştinţelor


Daţi exemple de pierdere a consistrenţei.
Raspunsuri:
Prima tranzacţie introduce în stoc 30 de bucăţi, iar cea de adoua scoate 10 bucăţi.
Stocul iniţial este de 100 bucăţi.

Time T1 T2 stocx

A t1 begin_transaction 100
A t2 begin_transaction cit(prodx) 100
A t3 cit(prodx) stocx = stocx-10 100
A t4 stocx=stocx +30 scrie(stocx) 90
A t5 scrie(stocx) commit 130
A t6 commit 130
Stocul corect ar fi de 120.

Aceleaşi trazacţii, din care una este întreruptă din motive accidentale:
Time T3 T4 balx

A t1 begin_transaction 100
A t2 cit(prodx) 100
A t3 stocx = stocx-10 100
A t4 begin_transaction scrie(stocx) 90
A t5 cit(prodx) 90
A t6 stoc x=stocx rollback 90
+30
A t7 scrie(stocx) 120
A t8 commit 120

Pare OK, dar T4 se va relua şi stoc vafi 110 îm loc de 120.

167
M6.U2.4 Test de autoevaluare a cunoştinţelor
1. Ce este blocajul?
2. Ce este blocajul ciclic? Exemplu.
3. Ce este protocolul de blocare în două faze?
4. Care este protocolul de control cu marcarea timpului (time stamp)?
5. Ce este o tehnică optimistă de control al concurenţei?
Raspunsuri:
1. Când o tranzacţie blochează partajat (part_bloc) o
anumită unitate de memorie, o altă tranzacţie 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ă.
2. Blocarea ciclică prezentată în exemplul următor. Cele două trnzacţii T 5 şi
T6 se blochează reciproc.
Time T5 T6

A t1 begin_transaction
A t2 ex_bloc(prodx) begin_transaction
A t3 cit(balx) ex_bloc(prody)
A t4 stocx = stocx -10 cit(baly)
A t5 scrie(prodx) stocy = stocy +100
A t6 ex_bloc(prody) scrie(prody)
A t7 AŞTEAPTĂ ex_bloc(prodx)
A t8 AŞTEAPTĂ AŞTEAPTĂ
A t9 AŞTEAPTĂ AŞTEAPTĂ
A t10 … AŞTEAPTĂ
A t11 … …

3. 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.
4. Protocolul cu marcarea timpului (time stamp) 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. Fiecare tranzacţie va avea o valoare de
marcaj ş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).
În următoarele trei situaţii se pun probleme deosebite:
a. 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ă.
b. Tranzacţia cere să scrie înregistrarea x a cărei valoare a fost deja citită de o

168
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ă.
c. 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. 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.

169