Tema

de casa
SO
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

Proiectarea
unei baze de
date folosind
sistemul
2
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

MySql
WorkBench

Masterand:
Matei Theodor

Cuprins:

INTRODUCERE:......................................................................................................................................4

I. Proiectarea Bazei de date...................................................................................................................4

II. Colectarea si analiza cerintelor..........................................................................................................6

2 .1 Proiectarea conceptual a bazelor de date...................................................................................7

2.2 Proiectarea schemei conceptuale de nivel înalt..........................................................................7

III. Proiectarea asocierilor....................................................................................................................11

3.1 Asocierea binară N:1..................................................................................................................11

3.2 Asocierea binară M:N................................................................................................................11

IV. Proiectarea tranzacţiilor.................................................................................................................12

V. Prezentare Mysql Workbench

1.Introducere
2.Instalare

3
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

3.Configurare
4.Realizarea tabelelor si a relatiilor dintre ele

VI.Concluzii

INTRODUCERE:
Sistemele de baze de date sunt o componentă esenţială a vieţii de zi cu zi în societatea modernă.In
cursul unei zile, majoritatea persoanelor desfasoara activitati care implica interacţiunea cu o baza de
date: depunerea sau extragerea unor sume de bani din banca, rezervarea biletelor de tren sau avion,
cautarea unei referinte într-o biblioteca computerizata, cumpararea unor produse etc.

Bazele de date pot avea dimensiuni (numar de inregistrari) extrem de variate, de la cateva zeci de
înregistrari (de exemplu, baza de date pentru o agenda cu numere de telefon) sau pot ajunge la zeci
de milioane de inregistrari (de exemplu, baza de date de plata pentru plata taxelor si a impozitelor).

In sensul cel mai larg, o baza de date (database) este o colectie de date corelate din punct de vedere
logic, care reflectă un anumit aspect al lumii reale şi este destinată unui anumit grup de utilizatori. În
acest sens, bazele de date pot fi create şi menţinute manual (de exemplu, fişele de evidenţă a
cărţilor dintr-o bibliotecă, aşa cum erau folosite cu ani în urmă) sau computerizat, aşa cum este
majoritatea bazelor de date folosite în momentul de faţă. O definiţie într-un sens mai restrâns a unei
baze de date este următoarea:

O bază de date (database) este o colecţie de date creată şi menţinută computerizat, care permite
operaţii de introducere, ştergere, actualizare şi interogare a datelor.

4
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

I. Proiectarea Bazei de date

Dezvoltarea sistemelor de baze de date comportă mai multe etape, care pot fi prezentate
succint astfel:

1.1. Analiza şi definirea sistemului: definirea scopului sistemului de baze de date, a

utilizatorilor şi a aplicaţiilor acestuia.

1.2. Proiectarea sistemului: în această etapă se realizează proiectul logic şi proiectul fizic al
sistemului, pentru un anumit SGBD ales.

1.3. Implementarea: este etapa în care se scriu definiţiile obiectelor bazei de date (tabele,
vederi, etc.) şi se implementează aplicaţiile software.

1.4.Incarcarea(sau conversia) datelor : popularea bazei de date,fie prin incarcarea directa a

datelor,fie prin conversia unor date existente sub diferite alte forme.

1.5.Conversia aplicatiilor:toate aplicatiile software existente in sistemele informatice

precedente ale organizatiei se convertesc in noul sistem.

1.6. Testarea şi validarea: noul sistem de baze de date este testat şi validat cât mai riguros
posibil.

1.7.Operarea:sistemul de baze de date este pus la dispozitia utilizatorilor sai cu toate

aplicatiile realizate in cadrul sistemului informatic al organizatiei.
Faza
Faza 1:
1: Cerinţele de date Cerinţele de prelucrare
1.8.Monitorizarea si intretinerea: pe tot parcursul etapei de operare sistemul de baze de
dateColectarea
trebuie saşişifie
Colectarea analiza
analiza
in mod permanent monitorizat si intretinut pentru a sigura consistenta si
cerinţelor
cerinţelor
securitatea datelor si pentru a permite atat cresterea continutului de date cat si dezvoltarea de noi
aplicatii software.Pot fi necesare la anumite intervale de timp,revizii si reorganizari ale sistemului de
baze de date.
Faza 2: Proiectarea schemei Proiectarea tranzacţiilor
Faza 2: Proiectarea schemei Proiectarea tranzacţiilor
conceptuale şi a schemelor (independente de
de SGBD)
ÎnProiectare se consideră că etapa de conceptuale
general, conceptuală
Proiectare conceptuală
proiectare aşiunei
a schemelor (independente
baze de date se pot diviza, la rândul ei, SGBD)
externe
externe (independente
(independente de
de
în mai multe faze : SGBD)
SGBD)

a. Proiectarea conceptuală a bazei de date.

Faza 3:
b. Alegerea unui SGBD.
Alegerea unui SGBD
c.Proiectarea logică a bazei de date.

d. Proiectarea fizică a bazeiProiectarea

de date.
Faza 4: Proiectarea schemei
schemei conceptual
conceptual si
si
aa schemelor
schemelor externe(dependente
externe(dependente
În mod tipic, dezvoltarea unei baze de date constă din desfăşurarea a două categorii de activităţi
Proiectare logica de
de SGBD)
SGBD)
paralele, aşa cum se poate vedea în figura de mai jos:

Faza 5: Proiectarea schemei interne

Proiectare fizica (dependent de SGBD)

Instructiuni
Instructiuni de
de descriere
5
descriere aa datelor
datelor Implemantarea tranzactiilor
Faza 6:
(LDD)
(LDD)
Implementare (dependente de SGBD)
(dependete
(dependete de
de SGBD)
SGBD)
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

Prima categorie de activităţi se referă la proiectarea structurii şi a conţinutului bazei de date,

iar cea de-a doua categorie se referă la proiectarea modului de prelucrare a datelor. Aceste două
categorii de activităţi sunt strâns corelate: toate prelucrările care se efectuează în tranzacţii depind
de structura datelor memorate, iar proiectarea fizică a bazei de date depinde de prelucrările
necesare în tranzacţii.
Cele şase faze de proiectare şi implementare enumerate mai sus nu se desfăşoară strict într-o
singură secvenţă.În multe cazuri este necesară modificarea proiectului dintr-o fază iniţială într-una
din fazele ulterioare, pentru a se obţine rezultatele dorite. Aceste bucle de reacţie între faze (sau în
interiorul unei faze) sunt, în general frecvente în cursul proiectării unei baze de date, dar nu au mai
fost reprezentate în figura de mai sus, pentru a nu complica diagrama respectivă.
Fazele cele mai importanate de proiectare a unei baze de date sunt fazele 2,4 si 5.Faza 1 in
care se colecteaza informatiile despre cerintele de utilizare a bazei de date si faza 6,de implementare
a datelor si a tranzactiilor pot sa nu fie considerate ca parte a procesului de proiectere a bazei de
date ,ci ca parte de a ciclui de viata a sistemului din care face parte baza de date.Faza 3 de alegere a
sistemului de gestiune a bazei de date este mai putin o faza de proiectare ci mai curand o faza de
decizie,in care factorii economici au pondere la fel de importanta ca si factorii tehnici.

II. Colectarea si analiza cerintelor

Inainte 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

6
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

(aplicaţii de gestiune a stocurilor, aplicaţii contabile, aplicaţii de urmărire a consumurilor, aplicaţii de

salarizare, etc.).
In general,in acesta faza de colectare si analiza a cerintelor se desfasoara urmatoarele
activitati:
 Identificarea grupurilor de utilizatori potentiali si a aplicatiilor.De regula,persoana cea mai
avizata din cadrul fiecarui grup de utilizatori este cooptata ca participant in activitatile
ulterioare de colectare si analiza a cerintelor.
 Revederea documentatiei existente privind aplicatiile dorite.In afara de documentatiile
aplicatiilor dorite se studiaza si alte documentatii(diagramele de organizare a
intreprinderii,formularele existente de introducere a datelor,rapoartele utilizate in controlul
activitatii respective,etc.)pentru a se decide daca aceste aspect influenteaza cerintele bazei
de date.
 Analiza mediului de operare si cerintelor de prelucrare a datelor.
Aceasta activitate include analiza fluxului de informatii in cadrul sistemului ,precum si analiza
tipurilor de tranzactii si a frecventei de lansare a acestora.Deosebit de importanta este si
stabilirea volumului si frecventei datelor actualizate precum si a volumului datelor returnate
de interogari si a frecventei acestora.
 Chestionare si interviuri.Se colecteaza raspunsuri scrise de la utilizatorii potentiali la diferite
seturi de intrebari si se organizeaza interviuri cu persoanele care reprezinte diferitele grupuri
de utilizatori.In felul acesta,proiectantii pot intelege care sunt prioritatile de proiectare a
bazei de date,importanta diferitelor aplicatii si performantele dorite de la acestea.
Toate aceste activităţi oferă informaţii slab 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.

2 .1 Proiectarea conceptual a bazelor de date

Faza de proiectare conceptuală a bazelor de date implică două activităţi paralele:
proiectarea schemei conceptuale şi a schemelor externe ale bazei de date şi proiectarea
tranzacţiilor.

2.2 Proiectarea schemei conceptuale de nivel înalt

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, deoarece o astfel de schema conceptuală este o
descriere stabilă şi inavuabilă a bazei de date, iar alegerea unui SGBD şi deciziile ulterioare de
proiectare se pot schimba fără ca aceasta să se schimbe.

Pentru proiectarea schemei conceptuale se identifică elementele esenţiale ale acesteia:

tipurile de entităţi şi atributele lor precum şi asocierile dintre aceste tipuri. Se pot defini, dacă este
necesar, subtipuri, prin specializări ale tipurilor de bază, sau supertipuri, prin generalizări ale tipurilor

7
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

deja definite. Acest proiect conceptual de nivel înalt este realizat pe baza cerinţelor definite în prima
etapă de proiectare şi se reprezintă, în general printr-o diagramă Entitate-Asociere (extinsă).
Există mai multe aspecte privind modul de abordare a proiectării conceptuale. Un prim
aspect se referă la modul de proiectare a schemei conceptuale a bazei de date: proiectare prin
integrarea cerinţelor şi proiectare prin integrarea schemelor externe.
În proiectarea prin integrarea cerinţelor (care se mai numeşte şi proiectare centralizată) se
realizează mai întâi integrarea (combinarea) tuturor cerinţelor de proiectare într-un singur set de
cerinţe, pe baza căruia se proiectează schema conceptuală a bazei de date. Din această schema
conceptuală (unică) proiectată se deduc schemele externe (vederile) corespunzătoare diferitelor
grupuri de utilizatori şi aplicaţii.

În proiectarea prin integrarea vederilor (schemelor) externe se proiectează câte o schemă

corespunzătoare fiecărui grup de utilizatori şi aplicaţii, pe baza cerinţelor acestora, după care se
combină aceste scheme într-o singură schemă conceptuală globală, pentru întreaga bază de date.

Fiind dat un set de cerinţe, pentru un singur utilizator sau pentru mai mulţi utilizatori ai bazei de
date, proiectarea schemei conceptuale care să satisfacă aceste cerinţe se poate aborda într-o
varietate de strategii, dintre care cele mai relevante sunt proiectarea ascendentă (bottom-up) şi
proiectarea descendentă (top-down).

În proiectare ascendentă a bazelor de date se porneşte de la o schemă conceptuală universală care

conţine toate atributele, care sunt apoi grupate pentru a forma tipuri de entităţi şi asocierile dintre
acestea. Proiectul poate fi rafinat prin grupări ulterioare şi creare de supertipuri şi subtipuri ale
tipurilor existente.

În proiectarea descendentă a bazelor de date se porneşte de la o schemă conceptuală dezvoltată în

modelul Entitate-Asociere (extins) în care sunt cuprinse aspectele de bază (tipuri de entităţi şi
asocieri ale acestora). Dezvoltarea şi rafinarea acestui model se face prin adăugarea de noi atribute
şi constrângeri, crearea unor subtipuri (prin specializare) şi asocierea acestora cu tipurile de bază.

Aşadar, în această fază de proiectare se obţine schema conceptuală de nivel înalt a bazei de date,
care este independentă de orice model de date specific (ierarhic, reţea, relaţional, etc.), şi de orice
sistem de gestiune care poate fi folosit pentru realizarea bazei de date.

8
3.SCHEMA CONCEPTUALA DE NIVEL ÎNALT A BAZEI DE DATE
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

Entităţi.

Tipurile de entităţi puternice (normale) care se pot defini pentru modelarea activitătii unei agentii sunt
urmatoarele:

ANGAJAT(Nume,Prenume,Parola,Ghiseu)

PERSOANE(Nume,Prenume,Serie_buletin,Numar_Buletin,CNP)

RUTA(Nr_Km,Nr_bilete_rezervate,Clasa)

TRONSON_Aerian(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Ve
hicul)

TRONSON_Tren(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,Vehi
cul)

TRONSON_Autocar(Data_plecare,Ora_Plecare,Data_sosire,Ora_sosire,Locuri_ramase,Sursa,Destinatie,V
ehicul)

Aeroporturi(Oras,Aeroporturi)

Gari(Oras,Gari)

Autogari(Oras,Autogari)

Vehicul(Vehicul,Nr_locuri)

Tara(Tari)

Asocieri.

Asocierile dintre mulţimile de entităţi se stabilesc în funcţie de modul în care se desfăşoară

activitatea modelată. De exemplu, dacă agentia respectivă activitatea este organizată pe mai multe
birouri(ghisee) şi fiecare angajat lucrează într-unul (şi numai unul) din birouri,si se ocupa de cate o
rezervare la un anumit moment(nu realizeaza mai multe rezervari concomitent) atunci între mulţimile
de entităţi ANGAJAT-REZERVARI există o asociere 1:N.

Asocierea PERSOANE-REZERVARI este o asociere M:N dacă se consideră că opersoana poate sa faca mai
multe rezervari si o rezervare poate sa contina mai multe persoane .

O ruta este compusa din mai multe tronsoane şi fiecare tronson poate fi inclus în mai multe, rute; deci
asocierea RUTA-TRONSON este este M:N.

10
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

O mulţime de entităţi slabe se află, de regulă, în asociere N:1 cu mulţimea de entităţi puternice de care
depinde. In exemplul dat, între mulţimea AEROPORTURI şi mulţimea de entităţi ORAS există o asociere
N:1.

III. Proiectarea asocierilor

3.1 Asocierea binară N:1
Asocierea binară N:1 dintre două mulţimi de entităţi puternice din diagrama E-A se realizează în
modelul relaţional prin intermediul unei chei străine în prima relaţie (cea cu multiplicitatea N a asocierii)
care referă cheia primară (sau o cheie candidată) din relaţia referită (cea cu multiplicitatea 1 a asocierii).
De exemplu,asocierea N:1 între relaţiile AEROPORTURI - ORAS se realizează prin cheia străină IdOras
adăugată relaţiei AEROPORTURI, care referă cheia primară cu acelaşi nume a relaţiei ORAS.

Astfel de atribute (pentru definirea cheilor străine) nu există în modelul E-A şi ele trebuie să fie adăugate
în modelul relaţional pentru definirea asocierii N:1, aşa cum în modelul ierarhic pentru o astfel de
asociere se adaugă link-uri (pointeri) între noduri. Asocierea binară N:1 poate apare şi ca asociere între o
relaţie corespunzătoare unei mulţimi de entităţi slabe şi relaţia corespunzătoare mulţimii de entităţi
puternice de care aceasta depinde, aşa cum a fost prezentată mai sus.

3.2 Asocierea binară M:N

Asocierea binară M:N dintre două mulţimi de entităţi din diagrama E-A se realizează în modelul
relaţional prin intermediul unei noi relaţii, numită relaţie de asociere. Această nouă relaţie se află în
asociere M:1, respectiv N:1 cu fiecare din cele două relaţii date prin intermediul a două chei străine care
referă cheile primare (sau cheile candidate) din relaţiile date.

De exemplu, pentru a reprezenta asocierea M:N dintre relaţiile RUTA-TRONSON_AERIAN se adaugă o

nouă relaţie numită RUTA2, care conţine cheile străine IdTronson şi IdRuta, ce referă cheile primare din
relaţiile TRONSON_AERIAN, respectiv RUTA.

O relaţie de asociere poate să conţină şi alte atribute în afara cheilor străine, atribute care caracterizează
asocierea dintre relaţiile date. Cheia primară a unei relaţii de asociere binară poate fi o cheie artificială
sau poate fi compusă din cheile străine, eventual împreună cu alte atribute ale relaţiei.

Asocierea M:N dintre relaţiile PERSOANE-REZERVARI se realizează prin introducerea relaţiei de asociere
PERS, care conţine două chei străine, IdPersoane1 şi IdPersoane2, care referă cheile primare IdPersoane
si IdRezervari.

Schema conceptuală a unei baze de date relaţionale poate fi dezvoltată independent de un anumit
SGBD, urmând ca ulterior să se adauge diferite trăsături specifice SGBD-ului folosit. De obicei însă,
fiecare SGBD pune la dispoziţie un număr de instrumente mai mult sau mai puţin „prietenoase” de
proiectare a relaţiilor şi a asocierilor, astfel încât în mod frecvent, proiectul conceptual se dezvoltă de la
început în cadrul sistemului SGBD în care se va realiza baza de date. De exemplu, Microsoft Access oferă

11
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

o interfaţă vizuală de proiectare a relaţiilor şi a asocierilor deosebit de uşor de utilizat. La fel, sistemele
SQL Server sau Oracle 10g oferă instrumente grafice pentru proiectarea vizuală a relaţiilor.

IV. Proiectarea tranzacţiilor

Atunci când se proiectează o bază de date, se cunosc în mare parte şi ce tipuri de aplicaţii se vor
executa. Un aspect important în proiectarea bazelor de date este specificarea caracteristicilor
funcţionale ale acestor aplicaţii cât mai devreme în cursul procesului de proiectare, astfel încât schema
bazei de date să includă toate informaţiile necesare cu privire la aceste aplicaţii. În plus, cunoaşterea
importanţei relative a diferitelor tranzacţii executate de aplicaţiile bazei de date, precum şi a frecvenţei
de invocare a acestora, permite luarea unor decizii în etapa de proiectare fizică a bazei de date.
Una din tehnicile cele mai obisnuite de specificare a tranzactiilor la nivel conceptual si
independent de sistemul de de gestiune este de identifica intrarile si iesirile lor su comportarea
functional.Tranzactiile sunt grupate in trei categorii:tranzactii de interogare,trnzactii de actualizare si
tranzactii mixte,care executa atat interogari cat si actualizari.
Pentru dezvoltarea ulterioara ulterioara in bune conditii a proiectului unui sitem de baze de
date,atat proiectarea schemei conceptual
După implementarea sistemului de baze de date vor mai fi identificate şi implementate noi
tranzacţii. Totuşi, cele mai importante tranzacţii sunt cel mai adesea cunoscute înainte de
implementarea sistemului. Dacă operaţiile de acces la baza de date ale unei tranzacţii sunt numai
operaţii de citire, acea tranzacţie se numeşte tranzacţie de citire (read-only transaction) şi controlul
concurenţei unor astfel de tranzacţii este mult mai simplu.
In cele ce urmează se va studia cazul general, al tranzacţiilor de citire şi scriere (read-write transactions)
care efectuează atât regăsiri de date (prin operaţii de citire) cât şi actualizări (prin operaţii de scriere), şi
care necesită tehnici de control al concurenţei mult mai complexe.Operaţiile efectuate de o tranzacţie şi
înregistrate de administratorul de refacere (recovery manager), pentru a asigura cele patru proprietăţi
importante ale tranzacţiilor (ACID), sunt următoarele:

1. begin: această operaţie marchează începutul execuţiei unei tranzacţii.

2. read sau write: sunt operaţii de citire sau scriere a articolelor în baza de date, executate în cadrul unei
tranzacţii.

3. end: această operaţie marchează terminarea operaţiilor de scriere sau citire din baza de date, ceea ce
înseamnă că tranzacţia se poate termina; totuşi, este posibil să fie necesare unele operaţii de verificare
înainte de validarea (commit) tranzacţiei.

4. commit: această operaţie semnalează terminarea cu succes a tranzacţiei, validarea tuturor

modificărilor efectuate în baza de date şi vizibilitatea modificărilor efectuate pentru alte tranzacţii; din
acest moment, modificările efectuate nu mai pot fi anulate, nici pierdute printr-o defectare ulterioară a
sistemului (bineînţeles, dacă mecanismul de refacere al SGBD-ului funcţionează corect).

12
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

5. rollback (sau abort): această operaţie semnalează faptul că tranzacţia a fost abandonată şi că orice
efect pe care tranzacţia l-a avut asupra bazei de date trebuie să fie anulat (printr-o “rulare înapoi” a
operaţiilor).

6. undo: această operaţie este similară operaţiei rollback, dar se aplică unei singure operaţii, nu unei
întregi tranzacţii.

7. redo: această operaţie specifică faptul că unele operaţii ale unei tranzacţii trebuie să fie executate din
nou pentru a se putea valida întreaga tranzacţie.

Ultimele două operaţii sunt necesare numai în anumite tehnici de refacere.

În figura de mai jos este reprezentată diagrama de stare a unei tranzacţii folosind limbajul UML, unde
fiecare stare are o denumire şi fiecare operaţie provoacă o anumită tranziţie între stări.

În starea ACTIVA se ajunge ca urmare a lansării unei tranzacţii prin operaţia begin, iar execuţia corectă a
operaţiilor read sau write nu modifică această stare. Atunci când o tranzacţie se termină, ea trece în
starea PARTIAL VALIDATA în care se efectuează operaţii de verificare impuse de tehnicile (protocoalele)
de control al concurenţei şi de refacere. Dacă ambele verificări sunt îndeplinite cu succes, atunci
tranzacţia este validată (prin execuţia unei operaţii commit) şi trecută în starea VALIDATA; dacă una sau
ambele condiţii nu sunt îndeplinite, tranzacţia este trecută în starea ABANDONATĂ prin execuţia
operaţiei abort. Starea TERMINATĂ este consecinţa imediată a atingerii uneia din stările VALIDATĂ sau
ABANDONATĂ şi nu necesită nici o altă operaţie pentru efectuarea acestei tranziţii.În cursul stării
ACTIVĂ, orice tranzacţie poate fi abandonată (şi trecută în starea ABANDONATĂ prin execuţia unei
operaţii abort), dacă diferite verificări efectuate nu sunt îndeplinite.

Pentru refacerea bazei de date în condiţiile în care unele tranzacţii sunt abandonate sau în care pot
apărea defecte de funcţionare, sistemul SGBD menţine un fişier jurnal, în care memorează operaţiile
efectuate de tranzacţii. Fişierul jurnal este memorat pe disc şi nu este afectat de diferite erori de

13
 Universitatea Politehnica Bucuresti
Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

execuţie, cu excepţia unei defectări catastrofice a discului. În plus, fişierul jurnal este salvat periodic pe
un suport auxiliar (bandă magnetică), ca o măsură de prevedere pentru astfel de defecte catastrofice.

În fişierul jurnal (log file) se înregistrează operaţiile efectuate de fiecare tranzacţie, identificată printr-un
identificator unic (T) generat de sistem.Prima înregistrare referitoare la o tranzacţie cu identificatorul T
este înregistrarea de start a tranzacţiei: [begin,T]. La fiecare operaţie write(X) executată de o tranzacţie
T, în fişierul jurnal se memorează o înregistrare de tipul [write,T,X,vechea_valoare,noua_valoare], dacă
pentru refacerea datelor se folosesc operaţii undo, sau o înregistrare de tipul [write,T,X,noua_ valoare],
dacă se folosesc operaţii redo. Sistemele care nu evită abandonarea în cascadă a tranzacţiilor
înregistrează în fişierul jurnal şi operaţiile de citire read(X), printr-o înregistrare de tipul
[read,T,X,valoare].

Pentru fiecare tranzacţie T, în fişierul jurnal se mai memorează starea de terminare: validată (printr-o
înregistrare [commit,T] ) sau anulată (printr-o înregistrare[rollback,T]). După executarea validării şi
înregistrarea ei în fişierul jurnal, efectul tranzacţiei este permanent memorat în baza de date.

Dacă sistemul se defectează, la reluarea execuţiei după îndepărtarea defectului, sistemul SGBD va aduce
baza de date într-o stare consistentă prin examinarea fişierului jurnal. Dat fiind că fişierul jurnal conţine
o înregistrare pentru fiecare operaţie de scriere care a modificat valoarea unui articol al bazei de date,
este posibil de a anula efectul tuturor operaţiilor de scriere efectuate de o tranzacţie care a fost lansată
dar nu a fost validată, parcurgând înapoi fişierul jurnal şi înlocuind valoarea existentă a articolului
modificat cu vechea valoare, memorată în fişierul jurnal. În cazul abandonării în cascadă, trebuie să fie
abandonate şi tranzacţiile care au citit valori modificate de tranzacţiile abandonate.

14