Access	Adobe photoshop	Algoritmi	Autocad	Baze de date	C
C sharp	Calculatoare	Corel draw	Dot net	Excel	Fox pro
Frontpage	Hardware	Html	Internet	Java	Linux
Matlab	Ms dos	Pascal	Php	Power point	Retele calculatoare
Sql	Tutorials	Webdesign	Windows	Word	Xml

STRUCTURI DE BAZE DE DATE

calculatoare

+ Font mai mare | - Font mai mic

 

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:

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 :

Relatia identificarea locului de munca :

Relatia perioada angajarii salariatului pe fiecare loc de munca :

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 :

NEW SELECT from SALARIAT where Marca = "34A70"

Relatia NEW

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

NEW SELECT from SALARIAT where Marca = "34A70"

Relatia NEW

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

PLACE 1 JOIN ANGAJARE SALARIAT AND LOC DE MUNCA unde

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

Relatia PLACE 1

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.

DISTRIBUIE DOCUMENTUL

Vizualizari: 1359
Importanta:

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 2024 . All rights reserved

Distribuie URL
https://www.scrigroup.com/calculatoare/STRUCTURI-DE-BAZE-DE-DATE71822.php

Adauga cod HTML in site
<a href="https://www.scrigroup.com/calculatoare/STRUCTURI-DE-BAZE-DE-DATE71822.php" target="_blank" title=" - https://www.scrigroup.com/calculatoare/STRUCTURI-DE-BAZE-DE-DATE71822.php">STRUCTURI DE BAZE DE DATE</a>