Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


AccessAdobe photoshopAlgoritmiAutocadBaze de dateC
C sharpCalculatoareCorel drawDot netExcelFox pro
FrontpageHardwareHtmlInternetJavaLinux
MatlabMs dosPascalPhpPower pointRetele calculatoare
SqlTutorialsWebdesignWindowsWordXml

STRUCTURI DE BAZE DE DATE

calculatoare

+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Trimite pe Messenger
Procesare de text
ScanAIR 2000-Air Quality Software Manager - Dinamica
IMPRIMANTA
RECONSTRUCTIA IMAGINILOR IN TOMOGRAFIA COMPUTERIZATA
AUTOMATIZARE - Sisteme de automatizare pentru instalatiile de termoficare
Securitatea datelor
Principalele tipuri de diagrama de frecvente - Biostatistica
Incarcarea sistemului si procesul init
Notiuni de baza in teoria grafurilor
Clase de grafuri


STRUCTURI DE BAZE DE DATE

1. Consideratii generale




In general, intelegem prin baza de date orice ansamblu de date, dar termenul semnifica de obicei un ansamblu de date stocate pe un dispozitiv magnetic de stocare de masa, avand diferite forme de prezentare (organizare), in functie de necesitati si disponibil ca sursa de date pentru o gama larga de aplicatii.

Din alt punct de vedere, o baza de date este rezultatul combinarii mai multor serii de date (proiectate si culese initial pentru aplicatii diferite) intr-un singur ansamblu unificat.

Aceasta abordare integrata a conceptului de baza de date isi are originea in evolutia istorica a sistemelor automate de stocare si intretinere a datelor.

De exemplu, nevoia calcularii salariilor a condus la aparitia unor fisiere secventiale, iar necesitatea regasirii interactive a datelor a avut ca rezultat realizarea unor fisiere cu acces direct.

Desi fiecare din aceste sisteme de fisiere a reprezentat o imbunatatire fata de procedurile manuale, datorita lipsei de comunicare intre ele, totusi permiteau numai o utilizare limitata si neeficienta a resurselor.

In aceste conditii, bazele de date au reprezentat solutia adecvata a organizarii informatiilor stocate si gestionate de institutii si organizatii.

Daca se implementeaza o baza centrala de date referitoare la datele solicitate de mai multe compartimente, administrarea acesteia se poate executa dintr-o unica pozitie cunoscuta sub numele de administrator al bazei de date (DBA – database administrator).

Administratorul stie atat ce date sunt disponibile in cadrul organizatiei, cat si care sunt datele necesare diferitelor compartimente, putand lua hotarari referitoare la organizarea si accesul la date.

Exista si dezavantaje care apar la organizarea datelor sub forma unor baze de date.

Una din problemele delicate este controlul accesului la datele importante. Controlul asupra accesului la informatiile din baza de date este la fel de important ca si capacitatea lor de partajare.

Acordarea de drepturi distincte de acces la sistemele de baze de date se face tinand seama de schema de descriere a intregii structuri a bazei de date. In ultima vreme, dimensiunile si aria de cuprindere a bazelor de date a cunoscut o crestere rapida, ceea ce a condus la aparitia unor grupari foarte mari de date. Aceste grupari de date pot fi fara efort organizate, asamblate si interogate de la distanta. Acest mod de manipulare genereaza propagarea cu usurinta a informatiilor gresite si aparitia incidentelor legate de utilizarea neautorizata sau vicierea intentionata a informatiilor cum ar fi falsificarea creditelor, cazierelor judiciare sau accesul neautorizat la informatii personale.

2. Implementarea stratificata a bazelor de date

Cel care utilizeaza o baza de date este numit utilizator (user), iar uneori utilizator final (end-user). Acest utilizator final poate fi in egala masura un functionar al unei companii aviatice care efectueaza rezervari de locuri sau un director executiv al unei mari societati constructoare de automobile.

In ambele cazuri, probabil ca utilizatorul nu este specialist in calculatoare si nici nu trebuie sa cunoasca in detaliu tehnologia si tehnicile utilizate in domeniu. Utilizatorul trebuie sa se poata concentra asupra problemei pe care o are de rezolvat, iar sistemul de gestionare a bazei de date trebuie sa ii prezinte informatiile necesare intr-o forma specifica aplicatiei respective, si nu intr-un limbaj tehnic greu de inteles.

Pentru a raspunde la aceste cerinte bazele de date sunt construite pe mai multe niveluri de abstractizare (fig. 3.2.1).

Imaginea datelor oferita utilizatorului final este produsa de un software de aplicatie, a carui comunicare cu utilizatorul se desfasoara in mod interactiv si in termeni specifici programului.

Proiectarea acestui software de aplicatie imprima personalitate sistemului de uz general. De exemplu, comunicarea cu utilizatorul se poate face printr-un sistem de intrebari si raspunsuri sau prin formulare care trebuie completate.

Utilizator

final

 

Software

de

aplicatie

 

Sistem de

gestiunea

bazei de date

 

Structura

bazei  de

date

 

Date prezentate in Date prezentate in Date prezentate in

forma efectiva de termeni specifici termeni specifici

de organizare modelului conceptual al aplicatiei

bazei de date

Fig. 3.2.1.- Stratificarea conceptuala a bazelor de date

Indiferent de interfata adoptata, aplicatia trebuie sa comunice cu utilizatorul pentru a obtine de la acesta informatiile necesare (inclusiv cerintele/solicitarile), pe care ulterior sa le prezinte intr-un format cat mai „prietenos” (friendly user interface).

De manipularea datelor, in cadrul bazei de date, se ocupa un pachet de programe numit sistem de gestiunea bazei de date – SGBD (data base management system – DBMS).

Primul avantaj al utilizarii acestor sisteme de gestiunea bazei de date – SGBD este simplificarea activitatii programatorului aplicatiei in ceea ce priveste manipularea efectiva a datelor solicitate de aplicatie. Aceasta manipulare s-ar complica si mai mult din punct de vedere al rezolvarii problemei in contextul unei baze de date distribuite (o baza de date impartita pe mai multe calculatoare legate in retea).

Alt avantaj al separarii aplicatiei de sistemul de gestiune a bazei de date este ca o astfel de organizare permite controlul accesului la baza de date.

Un alt avantaj important al utilizarii a doua pachete de programe, unul pentru interfata cu utilizatorul, celalalt pentru manipularea efectiva a datelor este obtinerea independentei datelor. Altfel spus, este posibila schimbarea organizarii bazei de date fara a fi necesara modificarea aplicatiilor.

Si un ultim avantaj al separarii intre aplicatii si SGBD este acela ca permite ca aplicatia sa fie scrisa utilizandu-se un model simplificat conceptual, al bazei de date, fara a lua in considerare structura efectiva a acesteia.

Aplicatiile sunt scrise in limbaje de uz general, dispunand de instrumente necesare exprimarii algoritmilor, dar nu si pentru operatii care sa permita manipularea facila a bazei de date. Rutinele furnizate de SGBD extind facilitatile limbajului utilizat, permitand folosirea imaginii conceptuale a modelului bazei de date.

Un astfel de limbaj de uz general care se adauga capacitatilor SGBD-ului se numeste limbaj de gazda.

Cautarea unor model mai performante de baze de date este in plina desfasurare, scopul fiind acela de a se gasi un model care sa permita conceptualizarea unor sisteme complexe, sa conduca la moduri cat mai concise de solicitare a informatiilor si sa poata fi implementat eficient prin furnizarea de catre SGBD a unor instrumente abstracte utilizabile in aplicatii.

Modelul relational

Popularitatea de care se bucura modelul relational este motivata de simplitatea sa structurala, modelul prezinta datele ca fiind stocate in niste tabele numite relatii.

Modelul relational permite reprezentarea informatiilor referitoare la salariatii unei firme printr-o relatie ca cea din tabelul urmator:

Marca

Salariatului

N u m e l e

A d r e s a

Cod  numeric

12 X 95

Ion C. Ion

Sos. Stefan cel Mare, 56

34 A 70

Gh. Vasilescu

Bd. Carol I, 50

30 Y 24

Marcela Patache

Str. Dionisie Lupu, 22

Fig. 3.2.2.- Relatia care contine informatii despre angajatii unei firme

O linie din cadrul relatiei (tabelului) poarta numele de tuplu. Coloanele relatiei se numesc atribute.

Proiectarea relationala

Proiectarea unei baze de date utilizand modelul relational se concentreaza pe proiectarea relatiilor din componenta sa. Sa presupunem ca pe langa informatiile continute in relatia din fig. 3.2.2, dorim sa includem si alte informatii legate de un istoric al pozitiilor detinute de un salariat in cadrul firmei cu urmatoarele atribute: denumirea postului (secretar, sef birou, sef compartiment), codul de identificare a postului (unic pentru fiecare post), codul referitor la pregatirea profesionala necesara fiecarui post, compartimentul in cadrul caruia a fost detinut postul si perioada de ocupare a postului (data/inceput si data/sfarsit activitate; in cazul unui post detinut in prezent se va nota acest atribut cu un asterisc).

Un mod de rezolvare a noi probleme este extinderea relatiei din fig. 3.2.2, prin adaugarea de noi coloane care sa cuprinda noile atribute conform fig. 3.2.3.

La o examinare mai atenta aceasta relatie ridica o serie de probleme. Una dintre ele este ineficienta relatiei: nu mai contine cate un tuplu pentru fiecare salariat, fiind posibil ca un salariat sa fi fost avansat in decursul timpului.

Descriind legaturile dintre atribute, ca mai sus, informatiile initiale se vor repeta, fie: marca, numele, adresa, codul numeric, fie: departamentul, codul pregatire profesionala. O alta problema apare la stergerea unor informatii inregistrate o singura data in baza de date, cum ar fi codul functiei pentru pozitia a treia din tabel (S8 – director compartiment).

Aceasta situatie a aparut deoarece am combinat in aceeasi relatie informatii care se refera la lucruri diferite.

Modul de rezolvare a problemei este reproiectarea bazei de date folosind atatea relatii cate subiecte am ales. In cazul nostru este vorba de trei subiecte – identificare salariat, locul sau de munca si perioada angajarii salariatului pentru fiecare loc de munca.

Relatia identificarea salariatului :

Marca

Salariatului

N u m e l e

A d r e s a

Cod  numeric

12 X 95

Ion C. Ion

Sos. Stefan cel Mare, 56

34 A 70

Gh. Vasilescu

Bd. Carol I, 50

30 Y 24

Marcela Patache

Str. Dionisie Lupu, 22

Relatia identificarea locului de munca :

Cod functie

Denumire functie

Cod pregatire

profesionala

pentru functie

Denumire

compartiment

J 25 X

Secretara

S C 5



Personal

J 25 Y

Secretara

S C 5

Contabilitate

J 25 Z

Secretara

S C 6

Financiar

S 8

Director departament

D 3

Aprovizionare

.

.

.

.

.

.

.

.

.

.

.

.

Relatia perioada angajarii salariatului pe fiecare loc de munca :

Marca

salariatului

Codul functiei

Data  debut

Data  sfarsit

12 X 15

A 6

34 A 70

S 8

12 X 15

B 7

30 Y 24

J 25 X

30 Y 24

J 25 Y

.

.

.

.

.

.

.

.

.

.

.

Fig. 3.2.4.- Baza de date care contine trei relatii

Utilizand aceasta baza de date informatiile suplimentare sunt disponibile implicit prin combinarea informatiilor continute in aceste relatii. Cate odata impartirea atributelor in relatii foarte simple duce la pierderea de informatii. Pornind de la proprietatile relatiilor s-au putut construi ierarhii de clase de relatii numite prima forma normala, a doua forma normala, a treia forma normala, , fiecare din aceste forme normale (clase de relatii) fiind mai putin predispuse aparitiei unor anomalii de functionare decat cele din clasa precedenta.

Operatii relationale

Analizam in continuare operatiile efectuate asupra relatiilor.

Selectarea unui tuplu cu anumite caracteristici dintr-o relatie

Pentru a regasi informatiile referitoare la un angajat se va selecta din relatia identificarea salariatului tuplul cu atributul de identificare dorit, iar pentru a obtine lista posturilor dintr-un compartiment se vor selecta tuplurile din relatia identificarea locului de munca care pentru atributul compartiment au valoarea codului departamentului precizat.

Realizarea selectiei tuplului si plasarea sa intr-o noua relatie se poate exprima sintactic astfel:

NEW SELECT from SALARIAT where Marca = „34A70”

(din) (unde)

Astfel se creeaza o noua relatie numita NEW care contine tuplurile din relatia salariat, al caror atribut Marca este egal cu 34A70 (vezi fig. 3.2.4.).

Relatia identificare salariat :

Marca

Salariatului

N u m e l e

A d r e s a

Cod  numeric

12 X 95

Ion C. Ion

Sos. Stefan cel Mare, 56

34 A 70

Gh. Vasilescu

Bd. Carol I, 50

30 Y 24

Marcela Patache

Str. Dionisie Lupu, 22

NEW SELECT from SALARIAT where Marca = „34A70”

Relatia NEW

Marca

Salariatului

N u m e l e

A d r e s a

Cod  numeric

34 A 70

Gh. Vasilescu

Bd. Carol I, 50

Fig. 3.2.4.- Operatia SELECT

Operatia PROJECT extrage anumite coloane. Daca dorim sa aflam titulaturile posturilor dintr-un compartiment, dupa ce am efectuat o operatie SELECT pentru a extrage din relatia LOCURI de MUNCA tuplurile care contin departamentul-tinta plasandu-le intr-o relatie NEW, lista pe care o cautam este cea a valorilor din coloana Denumire compartiment a acestei noi relatii.

Pentru a extrage aceasta noua coloana si a plasa rezultatul intr-o noua relatie, utilizam operatia PROJECT, care se va exprima sintactic astfel:

MAIL PROJECT Nume, Adresa from SALARIAT

si va realiza obtinerea unei liste cu numele si adresele tuturor salariatilor firmei. Lista se va gasi in noua relatie MAIL care are doua coloane (vezi fig. 3.2.5).

Relatia identificare salariat

Marca

Salariatului

N u m e l e

A d r e s a

Cod  numar

12 X 95

Ion C. Ion

Sos. Stefan cel Mare, 56

34 A 70

Gh. Vasilescu



Bd. Carol I, 50

30 Y 24

Marcela Patache

Str. Dionisie Lupu, 22

NEW SELECT from SALARIAT where Marca = „34A70”

Relatia NEW

N u m e l e

A d r e s a

Ion C. Ion

Sos. Stefan cel Mare, 56

Gh. Vasilescu

Bd. Carol I, 50

Marcela Patache

Str. Dionisie Lupu, 22

Fig. 3.2.5. - Operatia PROJECT

Relatia JOIN aplicata asupra a doua relatii are ca rezultat obtinerea unei noi relatii ale carei atribute sunt atributele relatiilor initiale (vezi. fig. 3.2.6).

Modul in care sunt concatenate tuplurile este determinat de conditia specificata pentru operatia JOIN.

C JOIN A and B where A . W = B . X

In acest exemplu un tuplu din relatia A va fi concatenat cu unul din relatia B daca si numai daca atributele W si X ale celor doua tupluri sunt egale.

X

 

Y

g

d

m

t

 

Z

p

e

q

f

 

V

r

t

p

 

W

 
Relatia A Relatia B


C JOIN A and B where A . W = B . X

Relatia C


Fig. 3.2.6.- Operatia JOIN

Se va exemplifica mai jos operatia JOIN asupra bazei de date din fig. 3.2.3 pentru a obtine o lista a codurilor de identificare ale tuturor angajatilor, impreuna cu departamentul in care lucreaza fiecare.

Instructiunea necesara este :

PLACE 1   JOIN ANGAJARE SALARIAT AND LOC DE MUNCA unde

ANGAJARE SALARIAT . Cod functie = LOC DE MUNCA . Cod functie,

rezultatul este prezentat in fig. 3.2.7.

Pentru a rezolva problema se selecteaza mai intai acele tupluri din relatia ANGAJARE SALARIAT Data sfarsit, unde Data sfarsit = „* ”, iar dupa aceea se proiecteaza atributele:

ANGAJARE SALARIAT Marca salariatului

si

LOC DE MUNCA Denumire departament.

In concluzie, obtinerea informatiilor se realizeaza prin executarea instructiunilor :

PLACE 1 JOIN ANGAJARE SALARIAT AND LOC DE MUNCA unde

ANGAJARE SALARIAT . Cod functie = LOC DE MUNCA .Cod functie

PLACE 2 SELECT from PLACE 1 unde

ANGAJARE SALARIAT Data sfarsit = „* ”

LIST PROJECT ANGAJARE SALARIAT, Marca salariat LOC DE MUNCA

Denumire departament from PLACE 2.

Relatia ANGAJARE SALARIAT Relatia LOC DE MUNCA

Marca

salariat

Codul

functiei

Data

debut

Data

sfarsit

Codul

functiei

Denumire

functie

Cod pregatire

profesionala

functie

Denumire

compartiment

12 X 15

A6

J 25 X

Secretara

S C 5

Personal

34 A 70

S 8

*

J 25 Y

Secretara

S C 5

Contabilitate

12 X 15

B 7

*

J 25 Z

Secretara

S C 6

Financiar

30 Y 24

J 25 X

S 8

Director

departament

D 3



Aprovizionare

PLACE 1 JOIN ANGAJARE SALARIAT AND LOC DE MUNCA unde

ANGAJARE SALARIAT . Cod functie = LOC DE MUNCA . Cod functie


Relatia PLACE 1

Marca

salaria-

tului

Codul

functiei

Data

debut

Data

sfarsit

Codul

functiei

Denumire

functie

Cod pre-

gatire pro-

fesionala

pt.functie

Denumire

comparti-ment

12 X 15

A6

A 6

Sef birou

S B 5

Aprovizionare

34 A 70

S 8

*

S 8

Director

departament

D 3

Aprovizionare

12 X 15

B 7

*

B 7

Sef serviciu

S S 4

Aprovizionare

Fig. 3.2.7.- Exemplu de aplicare a operatiei JOIN

Sistemul de gestiune a bazei de date are rolul de a accepta comenzi exprimate in termenii modelului relational si de a le transforma in actiuni ce tin cont de structura efectiva de stocare. Un sistem de gestiune a bazei de date care utilizeaza un model relational va include rutine pentru efectuarea operatiilor SELECT, PROJECT si JOIN, rutine care vor fi apelate din aplicatie printr-o structura sintactica compatibila cu limbajul-gazda.

In realitate sistemele de gestiune a bazelor de date contin operatii care pot fi combinatii ale unor pasi elementari intr-o forma prietenoasa pentru utilizatori. Un astfel de limbaj este limbajul S Q L (Structured Query Language).

S Q L

Limbajul SQL este destinat interogarii bazelor de date. Acest limbaj permite ca printr-o singura instructiune SQL se poate exprima o interogare care presupune o secventa de operatii SELECT, PROJECT si JOIN.

De exemplu interogarea din ultimul exemplu (fig. 3.2.7) poate fi exprimata in SQL printr-o instructiune:

select Marca salariat, Denumire departament

from ANGAJARE SALARIAT, LOC DE MUNCA

unde ANGAJARE SALARIAT . Cod functie = COD LOC DE MUNCA . Cod functie si ANGAJARE SALARIAT . Data sfarsit = „* ”.

Iata cateva exemple in SQL.

Instructiunea:

select Nume, Adresa

from IDENTIFICAREA SALARIATULUI

genereaza o lista care contine numele si adresele tuturor angajatilor din relatia IDENTIFICAREA SALARIATULUI. (Aceasta operatie este identica cu operatia PROJECT).

Instructiunea :

select IDENTIFICAREA SALARIATULUI Nume, ANGAJAREA

SALARIATULUI . Data debut

from IDENTIFICAREA SALARIATULUI, ANGAJAREA SALARIATULUI

where IDENTIFICAREA SALARIATULUI . Cod functie = ANGAJAREA

SALARIATULUI . Cod functie

furnizeaza o lista a tuturor angajatilor cu informatii privind data angajarii.

Pe langa interogari, limbajul SQL permite si definirea structurii unei relatii, crearea de noi relatii, ca si modificarea continutului unor relatii existente.

4. Baze date orientate spre [pe] obiecte

Una dintre cele mai noi directii de cercetare in domeniul bazelor de date o constituie aplicarea paradigmei orientate spre obiecte. Directia este incurajata de urmatoarele motive:

a)      independenta datelor se poate obtine prin incapsulare;

b)      clasele si mostenirea par concepute dedicat pentru descrierea schemei generale a bazei de date si a schemelor partiale;

c)      baze de date constituite din „obiecte inteligente” care pot raspunde direct la intrebarile ce li se pun, fara sa utilizeze un program supervizor de interogare;

d)      abordarea orientata pe obiecte elimina anumite restrictii inerente altor metode de organizare a bazelor de date.

5. Mentinerea integritatii bazelor de date

Sistemele de gestiune a bazelor de date (SGBD) de „uz personal” sunt in general ieftine si relativ simplu de manipulat. Instalarea lor nu-l implica de utilizator in detalii tehnice legate de implementare. Volumul acestor baze de date este de marime mica sau medie, iar pierderea sau alterarea informatiilor continute constituie o neplacere si nu un dezastru. In general problemele aparute nu afecteaza de obicei decat cativa oameni, iar pierderile de ordin financiar sunt desul de mici.

Desigur altfel stau lucrurile cu SGBD-urile de mari dimensiuni (ca volum de informatii inmagazinat si manipulat) utilizate in scop comercial.

In astfel de sisteme unul din principalele roluri ale sistemului de gestiune este de a veghea la mentinerea integritatii bazei de date, evitand operatiile efectuate partial sau acre, actionand intr-un mod neprevazut, care conduc la aparitia de informatii eronate.

Protocolul Commit/Rollback

Transferarea unei sume de bani dintr-un cont in altul presupune retragerea sumei din contul-sursa si adaugarea ei la contul-destinatie. In faza intermediara intre doua etape de actualizare a bazei de date, informatiile din baza de date pot fi contradictorii. Astfel in scurta perioada dintre retragerea (scoaterea) banilor dintr-un cont si depunerea lor in celalalt cont, suma respectiva dispare din evidente.

In cazul bazelor de date de mari dimensiuni in care sunt in curs de executie foarte multe tranzactii, probabilitatea ca la un moment ales aleator sa fie in curs o tranzactie este foarte mare.

In cazul unei defectiuni, SGBD nu lasa baza de date in stare de contradictie interna. Acest deziderat este dus la indeplinire prin mentinerea unui jurnal in care se inregistreaza toate activitatile efectuate asupra unei tranzactii.

Punctul in care s-au inregistrat toate etapele tranzactiei se numeste punct de angajare (commit point).

In acest fel SGBD-ul dispune de toate informatiile necesare pentru reconstruirea pe cont propriu a tranzactiei daca acest lucru este necesar. In cazul defectarii unui dispozitiv, SGBD-ul utilizeaza informatiile din jurnal pentru a reconstitui tranzactiile incheiate de la efectuarea ultimei salvari.

Daca apare o problema inainte ca o tranzactie sa atinga punctul de angajare, SGBD-ul se va gasi in situatia de a fi executat partial o tranzactie pe care nu o poate finaliza.

In aceasta situatie jurnalul poate fi utilizat pentru anularea (derulare inapoi – roll back) activitatilor deja efectuate de tranzactia respectiva.

Uneori derularea inapoi a unei tranzactii poate afecta elementele bazei de date care au fost utilizate intre timp la alte tranzactii.

Este posibil ca tranzactia anulata sa fi actualizat un cont bancar, iar alta tranzactie efectuata intre timp sa fi utilizat noua valoare. Aceasta situatie necesita anularea si a altor tranzactii, ceea ce va avea influenta si asupra altora s.a.m.d. Fenomenul se numeste anulare in cascada (cascading rollback).

B l o c a r e a

Daca studiem problema unei tranzactii care se executa in timp ce baze de date se modifica ca urmare a altei tranzactii uneori observam aparitia unor interactiuni dorite intre tranzactii care pot conduce la rezultate eronate. Atunci cand o tranzactie efectueaza un transfer de fonduri dintr-un cont in altul, in timp ce alte tranzactii calculeaza valoarea totala a depozitelor, poate apare problema cunoscuta sub numele de insumare incorecta (incorrect summary problem).

Pentru inlaturarea unei astfel de situatii, SGBD-ul poate obliga tranzactiile sa se execute integral, una dupa alta (serial), noile tranzactii plasandu-se intr-o coada de asteptare pana la finalizarea celor precedente.

Majoritatea sistemelor mari de gestiune a bazelor de date utilizeaza un modul de coordonare a partajarii timpului de calcul intre tranzactii.

Pentru evitarea unor anomalii din categoria precizata, modulele de coordonare recurg la un protocol de blocare (locking protocol), in care elementele bazei de date care sunt utilizate in mod curent intr-o tranzactie sunt marcate ca fiind blocate.

Se utilizeaza doua tipuri de blocare – blocarea partajabila si blocarea exclusiva, corespunzand celor doua tipuri de acces – partajabil si exclusiv. Daca o tranzactie nu modifica datele, atunci are nevoie de acces partajabil (permite altor tranzactii sa citeasca datele respective).

Daca tranzactia are ca obiectiv modificarea datelor, atunci are nevoie de acces exclusiv (nu permite accesul altor tranzactii la articolul respectiv.

Pentru tratarea cazurilor in care accesul solicitat de o tranzactie la un articol de date este refuzat, se pot utiliza mai multi algoritmi. Unul dintre acestia forteaza tranzactia respectiva sa astepte pana cand cererea poate fi aprobata, dar acest lucru poate conduce la aparitia interblocarii.

Pentru evitarea interblocarii SGBD-urile acorda prioritate primei tranzactii.

Acest protocol este cunoscut sub numele de protocol de asteptare (wound wait protocol) si asigura efectuarea tuturor tranzactiilor.






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 897
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2021 . All rights reserved

Distribuie URL

Adauga cod HTML in site