767
Algoritmi si structuri de date Autori: Cristian Bologa, G.C. Silaghi 1. NOŢIUNI INTRODUCTIVE; ALGORITMI DE SORTARE 1.1. Definiţii Un algoritm este o procedură de calcul bine definită care primeşte o valoare sau o mulţime de valori ca date de intrare şi produce o valoare sau mulţime de valori ca date de ieşire. Este deci un şir de paşi care transformă datele de intrare în date de ieşire. Putem lua ca exemplu definirea problemei de sortare a unui şir de numere. Datele de intrare (inputul) îl reprezintă o secvenţă de n numere (a 1 , a 2 , … a n ). Datele de ieşire (outputul) îl reprezintă o permutare (sau o reordonare) (a 1 , a 2 , …a n ) a secvenţei de numere furnizată la intrare astfel încât a 1 < a 2 < …<a n . Un algoritm de sortare, pentru o anumită secvenţă de numere (reprezentând inputul) 31, 41, 59, 26 va produce la ieşire drept output secvenţa 26, 31, 41, 59. O instanţă a problemei reprezintă mulţimea tuturor datelor de intrare (care satisface restricţiile impuse în definirea problemei) date necesare pentru a determina o soluţie a problemei. Un algoritm se spune că este corect dacă pentru orice secvență de intrare care satisface condițiile problemei va produce la ieșire un rezultat (output) corect. Spunem că algoritmul respectiv rezolvă problema computațională furnizată. O structură de date reprezintă un mod de a organiza și stoca datele astfel încât să facilităm accesul la ele și modificarea acestora. Pseudocodul este o modalitate de a descrie algoritmi; este similar cu schemele logice. Un algoritm descris în pseudocod poate apoi să fie implementat în orice limbaj de programare (C, Pascal etc). 1.2. Necesitatea studierii algoritmilor Analiza unui algoritm înseamnă identificarea resurselor necesare execuției algoritmului (memorie, lăţime de bandă pentru comunicații, hardware necesar etc). În analiză, considerăm că utilizăm un model generic de calculator cu următoarele caracteristici: Un singur procesor

licenta hatz

  • Upload
    claudiu

  • View
    88

  • Download
    2

Embed Size (px)

DESCRIPTION

licenta

Citation preview

Page 1: licenta hatz

Algoritmi si structuri de date

Autori: Cristian Bologa, G.C. Silaghi1. NOŢIUNI INTRODUCTIVE; ALGORITMI DE SORTARE1.1. Definiţii

Un algoritm este o procedură de calcul bine definită care primeşte o valoare sau o mulţime de valori ca date de intrare şi produce o valoare sau mulţime de valori ca date de ieşire. Este deci un şir de paşi care transformă datele de intrare în date de ieşire.

Putem lua ca exemplu definirea problemei de sortare a unui şir de numere. Datele de intrare (inputul) îl reprezintă o secvenţă de n numere (a1, a2, … an). Datele de ieşire (outputul) îl reprezintă o permutare (sau o reordonare) (a1

’, a2’,

…an’) a secvenţei de numere furnizată la intrare astfel încât a1

’< a2’< …<an

’.Un algoritm de sortare, pentru o anumită secvenţă de numere (reprezentând

inputul) 31, 41, 59, 26 va produce la ieşire drept output secvenţa 26, 31, 41, 59.O instanţă a problemei reprezintă mulţimea tuturor datelor de intrare (care

satisface restricţiile impuse în definirea problemei) date necesare pentru a determina o soluţie a problemei.

Un algoritm se spune că este corect dacă pentru orice secvență de intrare care satisface condițiile problemei va produce la ieșire un rezultat (output) corect. Spunem că algoritmul respectiv rezolvă problema computațională furnizată.

O structură de date reprezintă un mod de a organiza și stoca datele astfel încât să facilităm accesul la ele și modificarea acestora.

Pseudocodul este o modalitate de a descrie algoritmi; este similar cu schemele logice. Un algoritm descris în pseudocod poate apoi să fie implementat în orice limbaj de programare (C, Pascal etc).

1.2. Necesitatea studierii algoritmilorAnaliza unui algoritm înseamnă identificarea resurselor necesare execuției

algoritmului (memorie, lăţime de bandă pentru comunicații, hardware necesar etc). În analiză, considerăm că utilizăm un model generic de calculator cu următoarele caracteristici:

Un singur procesor

Model random-access machine pentru procesor: instrucţiunile se execută secvențial (una după alta) și nu există posibilitate de concurență

Se presupune că instrucțiunile permise pe procesor se execută toate într-un timp constant

Presupunem că procesorul poate lucra cu date de tip întreg sau flotant, fără ca precizia să fie de larg interes (în demersul nostru de analiză a algoritmului)

Dacă calculatoarele ar avea o viteză de execuție infinită, atunci orice metodă corectă de rezolvare a unei probleme ar fi potrivită. Dar calculatoarele au viteze de execuție limitate. În acelaşi timp, spațiile de memorare ale calculatoarelor sunt ieftine dar nu gratuite. Problema este că nu orice algoritm corect funcționează în mod utilizabil pe orice resurse de calcul.

Page 2: licenta hatz

3

Page 3: licenta hatz

Eficiența unui algoritm se referă la resursele de calcul și memorie necesare pentru execuția algoritmului. Practic este un studiu teoretic al performanţei (în primul rând) şi al resurselor utilizate. Progresele tehnologice din ultima perioadă fac ca importanţa mărimii memoriei solicitate de un algoritm să scadă ca importanţă. Ceea ce trebuie să intereseze programatorul este reducerea timpului de execuţie al programului. Există aplicaţii “real time” la care constrângerile de timp sunt cruciale.

Un algoritm la care timpul de execuţie nu depinde de dimensiunea problemei este un algoritm de timp constant a cărui complexitate se notează cu O(1). Timpul de execuţie al unui algoritm de complexitate O(n) creşte liniar (direct proporţional) cu valoarea lui n. Un algoritm liniar are complexitatea O(n), unul pătratic O(n2) iar unul cubic O(n 3). Un algoritm se numeşte polinomial dacă are o complexitate egală cu O(p(n)) unde p(n) este o funcţie polinomială. Altă clasă de algoritmi sunt cei exponenţiali.

Un algoritm este mai eficient decât altul dacă are o rată de creştere mai mică, pentru cazul cel mai defavorabil. Vorbim de eficienţa asimptotică a algoritmilor atunci când rata de creştere a timpului de execuţie devine esenţială considerând mărimi mari ale setului de date de intrare.

1.3. SortareaSortarea este o operaţie des întâlnită în rezolvarea problemelor de natură

algoritmică. Problema sortării unei mulţimi de obiecte se poate reduce la problema sortării cheilor asociate acestora. După ce cheile sunt sortate, folosind informaţia de asociere (care leagă cheia de obiectul căreia îi aparţine), se pot rearanja obiectele în ordinea în care au fost aranjate cheile lor.

Dându-se o secvenţă de elemente caracterizate de valorile e1, e2, ... en E, operaţia de sortare este operaţia de găsire a unei permutări a secvenţei ei1, ei2, ... ein astfel încât eij eik, oricare ar fi ij ik, unde “ ” este o relaţie de ordine definită peste mulţimea E.

O metodă de sortare se spune că este stabilă dacă după sortare, ordinea relativă a elementelor cu chei egale coincide cu cea iniţială, element esenţial în special în cazul în care se execută sortarea după mai multe chei.

O cerinţă fundamentală care se formulează faţă de metodele de sortare a tablourilor se referă la utilizarea cât mai economică a zonei de memorie disponibile. Astfel, algoritmii care utilizează doar zona de memorie alocată tabloului, fără a fi necesar un tablou suplimentar se numesc sortări "în situ".

1.3.1 Sortarea prin inserţieIdeea sortării prin inserţie este următoarea:

Pornim cu un şir gol de numere

Luăm câte un număr din șirul inițial și îl plasăm în şirul sortat la poziția corespunzătoare

Plasarea numărului în șir la poziția corespunzătoare se face prin comparare succesivă de la stânga la dreapta sau invers

Pseudocodul aferent sortării prin inserţie este prezentat în figura 1.1:

Page 4: licenta hatz

4

Page 5: licenta hatz

Figura 1.1 Algoritmul de sortare prin inserţie

1.3.2. Metoda Divide-and-conquerNumită şi divide et impera (divide şi stăpâneşte), aceasta este o tehnică sau o

metodă de programare în care: problema iniţială se sparge în subprobleme cu structură similară cu

problema originală, dar de dimensiune mai mică.

aceste subprobleme sunt rezolvate recursiv

soluţiile recursive sunt combinate pentru a produce soluţia problemei iniţiale

Metoda se poate aplica în rezolvarea unei probleme care îndeplineşte următoarele condiţii:

se poate descompune în două sau mai multe subprobleme

aceste suprobleme sunt independente una faţă de alta (o subproblemă nu se rezolvă pe baza alteia şi nu foloseşte rezultatele celeilalte)

aceste subprobleme sunt similare cu problema iniţială

la rândul lor subproblemele se pot descompune (dacă este necesar) în alte subprobleme mai simple

aceste subprobleme simple se pot soluţiona imediat prin algoritmul simplificat

1.3.3. Sortarea prin interclasare (Merge Sort) Sortarea prin interclasare se bazează pe următorul principiu: pentru a sorta un

vector cu n elemente, îl împărţim în 2 vectori, care, odată sortaţi, se interclasează. Conform strategiei Divide and Conquer, descompunerea unui vector în alţi doi vectori care urmează a fi sortaţi are loc până când avem de sortat vectori de un element.

Sortarea prin interclasare are deci 3 paşi:

5

Page 6: licenta hatz

Divide –şirul A de n elemente se împarte în două subşiruri de n/2 elemente (în cazul în care n este impar dimensiunea primului şir este cu 1 mai mare decât dimensiunea celui de al doilea şir)

Conquer –se sortează recursiv cele două subşiruri

Combine –se combină prin interclasare cele două şiruri sortate obţinute la pasul Conquer, rezultând un singur şir sortat

Recursivitatea se încheie la şiruri de lungime 1, care sunt implicit deja sortate.În continuare vom descrie procedura MERGE(A,p,q,r) care primeşte ca şi parametru

şirul A, poziţia p de la care începe sortarea, poziţia r la care se încheie sortarea şi q o valoare între p şir, valoare care va împărţi şirul A[p]..A[q] în două subşiruri A[p..q] şi A[q+1]..A[r].Complexitatea procedurii Merge este ϴ(n) unde n=r-p+1 este numărul elementelor interclasate. Merge sort nu este o sortare “in situ”, ea necesită spaţiu suplimentar pentru a păstra subşirurile care apoi se vor interclasa.

Figura 1.2 prezintă algoritmul procedurii MERGE(A,p,q,r):

Figura 1.2 Algoritmul de interclasare a două şiruri ordonate crescătorÎn figura 1.3 este prezentat algoritmul procedurii Merge-Sort:

Figura 1.3. Algoritmul sortării prin interclasare

1.3.4. Heap SortHeap Sort sau Sortarea prin metoda ansamblelor este cunoscută şi sub denumirea

de “sortare pe bază de arbore”, deoarece vectorul de sortat, organizat ca o movilă, corespunde unui arbore. Heapsort utilizează o structură de date numită heap.

Page 7: licenta hatz

6

Page 8: licenta hatz

Un heap (o movilă) este un vector care poate fi vizualizat sub forma unui arbore binar aproape complet cu proprietatea că cheia fiecărui nod din arbore este mai mare decât cheile descendenţilor (deci fiecare nod are o cheie mai mică sau egală cu cea a tatălui său). Ultimul rând al arborelui se completează de la stânga la dreapta.

Un heap poate fi reprezentat sub forma unui arbore binar sau sub forma unui vector. Astfel, dacă v este un vector care conţine reprezentarea unui heap avem următoarea proprietate:

Elementele v[left]..v[n] îndeplinesc condiţia de structură a heapului:i>left avem: v[i]>v[2*i], dacă 2*i n, respectiv

v[i]>v[2*i+1] dacă 2*i+1 n.Evident, pentru valori ale lui i mai mari decât n/2 nu se pune problema îndeplinirii

condiţiilor de mai sus.Figura 1.4 prezintă un heap descris atât sub forma unui arbore cât şi sub formă de şir de elemente.

Figura 1.4 Un exemplu de heap descris printr-un arbore respectiv printr-un şir Ca să putem folosi Heap Sort va trebui să transformăm şirul de intrare într-un heap.

Vom crea iniţial procedura MAX-HEAPIFY(A,i) care primeşte ca şi parametri un vector A şi un indice i din vector. Atunci când apelăm MAX-HEAPIFY se presupune că subarborii având ca rădăcini nodurile Left(i) şi Right(i) sunt heapuri. Dacă elementul A(i) este mai mic decât cel puţin unul din descendenţii Left(i) şi Right(i), înseamnă că acest element nu respectă proprietatea de heap (deci nu avem un heap şi va trebui transformat ca să devină heap). Sarcina procedurii MAX-HEAPIFY este să “scufunde” în heap valoarea A(i) astfel încât subarborele care are în rădăcină valoarea elementului de indice i sa devină un heap.

Figura 1.5 prezintă algoritmul MAX-HEAPIFY:

Figura 1.5 Algoritmul MAX-HEAPIFY de refacere a proprietăţii de heapVom construi heapul de jos în sus (de la frunze) (care sunt heap-uri de heapsize=1)

(figura 1.6).

Page 9: licenta hatz

7

Page 10: licenta hatz

Figura 1.6. Algoritmul de creare a unui heapPrezentăm în figura 1.7 algoritmul de sortare utilizând un heap bazat pe algoritmii

BUILD-MAX-HEAP şi MAX-HEAPIFY.

Figura 1.7 Algoritmul de sortare utilizând un heap

1.3.5. Sortarea rapidă (Quick Sort)Quick Sort este un algoritm de sortare (inventat de Tony Hoare in 1962) care

pentru un şir de n elemente are un timp de execuţie ϴ(n2) în cazul cel mai defavorabil. În ciuda acestei comportări proaste pentru cazul cel mai defavorabil, acest algoritm este deseori cea mai bună soluţie practică deoarece are o comportare medie remarcabilă: timpul mediu de execuţie este ϴ(nlgn) şi constanta ascunsă în formula lui ϴ(nlgn) este destul de mică. Este o sortare in situ (adică e o sortare în spaţiul alocat şirului de intrare).

Algoritmul Quick Sort se bazează pe tehnica de programare “Divide and Conquer”, bazându-se pe următorii 3 paşi:

Divide: Şirul A[p..r] este împărţit (rearanjat) în două subşiruri nevide A[p..q-1] şi A[q+1..r] astfel încât fiecare element al subşirului A[p..q-1] să fie mai mic sau egal cu A[q] (element denumit element pivot) şi orice element al subsirului A[q+1..r] este mai mare sau egal cu A[q]. Indicele q este calculat de procedura de partiţionare. Deci elementele mai mici decât pivotul vor fi mutate în stânga pivotului iar elementele mai mari decât pivotul vor fi mutate în dreapta pivotului.

Conquer: Cele două subşiruri A[p..q-1] şi A[q+1..r] sunt sortate prin apeluri recursive ale algoritmului de sortare rapidă

Combine: Cele două subşiruri sunt sortate pe loc, nu este nevoie de nici o combinare, şirul A[p..r] este ordonat.

Prezentăm în figura 1.8 algoritmul procedurii QUICKSORT:

Figura 1.8 Algoritmul QUICK-SORTPentru ordonarea întregului şir A, iniţial se apelează QUICKSORT(A,1,lungime[A]).

8

Page 11: licenta hatz

Prezentăm în figura 1.9 algoritmul procedurii PARTITION care realizează partiţionarea şirului:

Figura 1.9 Partiţionarea unui şir în cazul QUICK-SORTUn algoritm se numeşte aleator dacă comportarea lui depinde nu numai de

valorile de intrare ci şi de valorile produse de un generator de numere aleatoare. Vom presupune că dispunem de un generator de numere aleatoare numit RANDOM. Un apel al procedurii RANDOM(p,r) va produce un număr întreg aleator între p şi r (inclusiv). Fiecare număr întreg din acest interval va avea aceeaşi probabilitate de apariţie.

În Quick Sort vom selecta aleator un element din subşirul A[p..r] care va juca rolul pivotului. La fiecare pas al sortării rapide, înainte de partiţionarea vectorului vom interschimba elementul A[p] cu acest element aleator ales. Practic, această modificare a algoritmului asigură că elementul pivot x=A[p] să fie cu aceeaşi probabilitate orice element dintre cele r-p+1 elemente ale vectorului A[p..r]. Rezultatul este că partiţionarea vectorului de intrare va fi în medie, rezonabil de echilibrată. Modificările în algoritmul deja prezentat sunt minore. Vom avea implementată schimbarea elementului ce va deveni pivot înainte de apelul propriu zis al procedurii PARTITION. Prezentăm în figura 1.10 algoritmul de alegere aleatoare a elementului pivot:

Figura 1.10 Algoritmul de alegere aleatoare a elementului pivot pentru QUICK-SORTDe asemenea, noua procedură QUICKSORT va apela procedura RANDOMIZED-

PARTTION în loc de vechea procedură PARTITION. Prezentăm în figura 1.11 algoritmul noii proceduri denumită RANDOMIZED-QUICKSORT:

Figura 1.11 Algoritmul de sortare rapidă în cazul alegerii aleatoare a elementului pivot

Page 12: licenta hatz

9

Page 13: licenta hatz

2. TEHNICI DE PROGRAMARE: PROGRAMARE DINAMICᾸ; GREEDY; BACKTRACKING

2.1. Programarea dinamică

Tehnicile de programare sunt modalităţi generale de elaborare a algoritmilor. Ele reprezintă doar nişte tipare de organizare a acţiunilor ("scheme" de algoritmi), nu garantează şi succesul acestora. Pentru a avea succes trebuie îndeplinite nişte condiţii suplimentare, care sunt specifice şi se demonstrează separat pentru fiecare problemă în parte.

Programarea dinamică este o tehnică de proiectare a unui algoritm care permite rezolvarea unei clase de probleme. Programarea dinamică, la fel ca şi metoda Divide and Conquer, rezolvă problemele combinând soluţiile unor subprobleme. Spre deosebire de abordarea din Divide and Conquer, programarea dinamică este aplicabilă atunci când subproblemele nu sunt independente, adică subproblemele au în comun sub-subprobleme. Astfel, un algoritm de tipul Divide and Conquer ar presupune mai multe calcule decât ar fi necesar dacă s-ar rezolva repetat aceste sub-subprobleme comune.

Programarea dinamică rezolvă fiecare sub-subproblemă o singură dată şi salvează rezultatul într-o tabelă cu rezultate. Se evită astfel ca o sub-subproblemă să fie rezolvată de mai multe ori.

Programarea dinamică se aplică la probleme de optimizare, probleme cu următoarele caracteristici:

Au mai multe soluţii posibile, fiecare caracterizate printr-o valoare

Dorim să identificăm o soluţie cu valoarea cea mai mică/cea mai mare. O asemenea soluţie se numeşte “o soluţie optimă” a problemei, prin contrast cu “soluţia optimă” deoarece pot fi mai multe soluţii care realizează soluţia optimă.

Dezvoltarea unui algoritm bazat pe programarea dinamică poate fi împărţită într-o secvenţă de 4 paşi:

1. Se caracterizează structura unui soluții optime

2. În mod recursiv, se definește valoarea unui soluții optime

3. Se calculează valoarea unei soluții optime pornindu-se de jos în sus

4. Se calculează soluția optimă pe baza informației obţinute până în acest pas

Paşii 1->3 sunt baza unei abordări de tip programare dinamică. Pasul 4 poate fi omis dacă se doreşte doar calculul unei singure soluţii optime.

10

Page 14: licenta hatz

2.1.1. Problema tăierii barei de oţel

Compania Sterling Enterprises cumpără bare de oţel lungi şi le taie în bucăţi mai scurte pe care apoi le revinde. Se cunoaşte preţul pi cu care compania vinde o bară de lungime i (i este o valoare întreagă). Se cere determinarea locurilor unde se vor face tăieturile la o bară de lungime n, astfel încât să se obţină câştigul maxim rn.

Input: n ca fiind lungimea iniţială a barei precum şi preţurile pi pentru i=1..n. Deci pi este preţul unei bare de lungime i.

Output: Soluţia optimă va însemna tăierea barei în k bucăţi, deci obţinerea partiţiei i1, i2, … ik cu i1+i2+…ik=n astfel încât suma rn=pi1+pi2+…+pik să fie maximă

Observaţii: Tăierile nu costă nimic (sunt gratis) iar lungimile sunt întotdeauna numereîntregi.

Având în vedere că din 1 în 1 avem posibilitatea de a tăia sau nu bara, înseamnă că pentru n-1 poziţii avem posibilitatea de a tăia sau nu. Numărul maxim de partiţii posibil pentru o bară de lungime n este deci 2n-1.

În figura 2.1 prezentăm un exemplu de cum vom tăia bare de lungime 1, 2, ...10 pornind de la preţul unei bare de lungime 1, 2, … 10.

Figura 2.1 Un exemplu de tăiere optimă a unei bare de oţel de diverse lungimi (1->10) Problema tăierii barei de oţel este o problemă cu structură optimă: soluţia optimă a

acestei probleme incorporează soluţii optime ale subproblemelor.Rezolvarea problemei se va baza pe o soluţie recursivă. Descompunerea recursivă

a problemei tăierii barei de oţel se va face astfel: Se taie o piesă de lungime i

Bara rămasă de lungime n-i se taie în mod recursiv

rn= max1<=i<=n(pi+rn-i)

Algoritmul recursiv de tăiere a barei de oţel este descris în figura 2.2:

Figura 2.2 Algoritmul recursiv de tăiere a unei bare de oţel

11

Page 15: licenta hatz

Va trebui să maximizăm profitul la tăierea bucăţii de lungime i respectiv bucăţii de lungime n-i care a rămas. Recursivitatea continuă doar pentru a doua bucată care a rămas.Abordarea în algoritmul descris în figura 2.2 este de tip top-

down. Linia 5 este echivalent cu a scrie:rn =max(pn, r1+rn-1, r2+rn-2, …, r n-1+ r1)

unde pn este echivalentul de a nu tăia deloc bara.

Problema este că algoritmul CUT-ROD este foarte lent. Pentru n=40 rezolvarea vaţine cel puţin câteva minute, poate chiar o oră. La fiecare creştere a lui n cu 1, timpul de execuţie se va dubla. De ce este ineficient acest CUT-ROD? Pentru că el se autoapelează de mai multe ori cu aceeaşi parametri, rezolvând astfel aceleaşi subprobleme în mod repetat (adică acelaşi apel CUT-ROD(p,j) se face de mai multe ori ceea ce este ineficient).

Încercăm să elaborăm un algoritm astfel încât fiecare subproblemă să fie rezolvată o singură dată. Vom utiliza o zonă de memorie suplimentară unde să se salveze rezultatele fiecărei subprobleme. Timpul de execuţie exponențial se poate reduce astfel la un timp de execuţie polinomial dacă numărul de subprobleme este polinomial și rezolvarea unei subprobleme este polinomială.

Vom putea folosi 2 abordări: Abordare top-down cu memo-izare: se scrie procedura recursivă în mod

obişnuit, dar o modificăm astfel încât să salvăm rezultatul fiecărei subprobleme într-un şir. Înainte să se apeleze recursivitatea, se verifică dacă rezultatul dorit este deja salvat în şir

Abordare bottom-up: sortăm subproblemele în funcţie de ordinul lor de mărime și le rezolvăm cele mai mici la început

În figura 2.3 prezentăm algoritmul de tăiere a barei de oţel utilizând programarea dinamică cu o abordare top-down:

Figura 2.3 Algoritmul top-down de tăiere a barei de oţel utilizând programare dinamică Acelaşi algoritm dar utilizând o abordare BOTTOM-UP este prezentat în figura 2.4:

Page 16: licenta hatz

12

Page 17: licenta hatz

Figura 2.4 Algoritmul bottom-up de tăiere a barei de oţel utilizând programare dinamică Algoritmul prezentat în anterior oferă valoarea optimă în cazul tăierii barei de oţel

dar nu oferă şi soluţia adică lista mărimilor bucăţilor tăiate. Pentru a reconstrui soluţia, vom extinde abordarea anterioară prin memorarea în fiecare pas nu doar a valorii soluţiei optime ci şi a alegerii făcute pentru a se ajunge la soluţia optimă.

Prezentăm în figura 2.5 algoritmul de tăiere a barei de oţel cu memorarea în şirul s a mărimilor bucăţilor ce vor fi tăiate.

Figura 2.5 Algoritmul de tăiere a barei de oţel cu memorarea mărimilor bucăţilor ce vor fi tăiate

2.1.2. Problema înmulţirii unui şir de matrici

Următorul exemplu de programare dinamică este algoritmul care rezolvă problema înmulţirii unui şir de matrici. Se dă un şir (o secvenţă A1, A2,… An) de n matrici care trebuieînmulţite, dorindu-se calcularea produsului A1A2 …An

Spunem că un produs de matrice este complet parantezat fie dacă este format dintr-o unică matrice, fie dacă este produsul a două produse de matrice care sunt la rândul lor complet parantezate. Datorită faptului că înmulţirea matricilor este asociativă, toate parantezările conduc la acelaşi rezultat (matrice produs).

Pseudocodul aferent înmulţirii a 2 matrici este prezentat în figura 2.6.

13

Page 18: licenta hatz

INMULTIRE-MATRICE(A,B)1: If coloane[A]!=linii[B]2: scrie “dimensiuni incompatibile”3: else4: for i=1 to linii[A]5: for j=1 to coloane[B]6: C[i,j]=07: for k=1 to coloane[A]8: C[i,j]=C[i,j]+A[i,k]*B[k,j]9: returneaza C

Figura 2.6 Algoritmul de înmulţire a 2 matrici

Dacă avem o matrice A(p,q) pe care dorim să o înmulţim cu o matrice B(q,r) pentru a rezulta matricea produs C(p,r) vor fi necesare p*q*r înmulţiri scalare.Exemplu: Considerăm A1(10,100), A2(100,5) şi A3(5,50). Se pune problema când vom avea un număr minim de înmulţiri scalare pentru a obţine produsul celor 3 matrici: când vom calcula (A1A2)A3 sau când vom calcula A1(A2A3)A1A2 –vom avea 10*100*5=5000 de înmulţiri scalare pt a calcula A1A2 de dimensiune 10x5. Apoi vom avea 10*5*50=2500 înmulţiri scalare pentru a calcula (A1A2)A3 deci în total 7500 de înmulţiri scalare.A2A3 -vom avea 100*5*50=25000 de înmulţiri scalare pentru a calcula A2A3 de dimensiune 100x50. Apoi vom avea 10*100*50=50000 înmulţiri scalare pentru a calcula A1(A2A3) deci în total 75000 de înmulţiri scalareÎn concluzie prima variantă de parantezare ne oferă un algoritm de 10 ori mai rapid.

Problema pe care urmează să o rezolvăm are următorul enunţ: Se dă un şir dematrici (A1A2…An) care trebuie înmulţite. Matricea Ai are dimensiunile pi-1 x pi. Să se pună parantezele pentru a rezolva produsul celor n matrici astfel încât numărul de înmulţiri scalare să fie minim.

P(n) va fi numărul de parantezări distincte ale unui şir de matrici (altfel spus va fi numărul de posibile soluţii pentru un şir de n matrici). Vom demonstra că verificarea exhaustivă a tuturor parantezărilor nu conduce la un algoritm eficient.

Formula recursivă de calcul a lui P(n) este prezentată în figura 2.7:

Figura 2.7 Formula recursivă de calcul a numărului de parantezări posibile pentru un produs de n matrici

Soluţia recurenţei pentru calculul lui P(n) va fi Ω(2n). Numărul de soluţii este exponenţial în n şi în concluzie metoda forţei brute a căutării exhaustive este o strategie proastă de determinare a modalităţii de parantezare a şirului de matrici.

Pentru a calcula AiAi+1..Aj (vom nota acest produs cu Ai..j) va trebui să găsim un k optim astfel încât să punem o paranteză între Ak şi Ak+1. În consecinţă:

Costul lui Ai..j este egal cu costul lui Ai..k plus costul lui Ak+1..j plus costulînmulţirii acestor două matrici

Dacă costurile lui Ai..k şi Ak+1..j sunt optime, atunci şi costul lui Ai..j este optim

O soluţie optimă a unei instanţe a problemei înmulţirii şirului de matrice conţine soluţii optime pentru instanţe ale subproblemelor. Existenţa substructurilor optime în cadrul unei soluţii optime este una din caracteristicile cadrului de aplicare a metodei programării dinamice.

Page 19: licenta hatz

14

Page 20: licenta hatz

Pentru a determina subproblemele necesare abordării prin prisma programării dinamice, observăm că avem câte o subproblemă pentru fiecare alegere a lui i şi j, cu1<=i<=j<=n. În total vom avea Cn

2+n=ϴ(n) subprobleme.Un algoritm recursiv poate întâlni fiecare subproblemă de mai multe ori pe ramuri

diferite ale arborelui său de recurenţă. Această proprietate de suprapunere a subproblemelor este una din caracteristicile programării dinamice. Astfel, rezolvarea fiecărei subprobleme A i..j o păstrăm într-un tabel de dimensiuni nxn cu liniile i şi coloanele j.

Figura 2.8 prezintă algoritmul bottom-up de determinare a costurilor înmulţirii şirului de matrici precum şi a indicilor pentru care s-a obţinut costul optim.

Figura 2.8 Algoritmul bottom-up de determinare a costurilor înmulţirii unui şir de matrici

Algoritmul recursiv prezentat în figura 2.9 ne oferă afişarea parantezării optime a produsului (AiAi+1…Aj) pe baza tabelului s calculate de procedura MATRIX-CHAIN-ORDER şi a indicilor i şi j. Apelul iniţial PRINT-OPTIMAL-PARENS(s,1,n) ne oferă parantezarea optimă pentru produsul (A1A2..An).

Figura 2.9 Algoritmul recursiv de afişare a parantezării optime pentru un produs de n matrici

Descoperirea sub-structurii optimale:1. Arătăm că solutia problemei se obtine printr-o alegere, care implică rezolvarea a

unei sau mai multe subprobleme

Page 21: licenta hatz

15

Page 22: licenta hatz

2. La o problemă, presupunem că ni se furnizează alegerea care să conducă la soluţia optimală

3. Având această alegere, determinăm care sunt subproblemele, şi cum caracterizăm cel mai bine spaţiul rezultat al subproblemelor

4. Arătăm că solutiile la subproblemele utilizate in cadrul solutiei optimale sunt ele la rândul lor optimale, prin repetarea raţionamentului de mai sus

Identificăm următoarele:Primul pas al rezolvării unei probleme de optimizare utilizând programarea

dinamică constă în caracterizarea structurii unei soluţii optime. Spunem că problema prezintă o substructură optimă dacă o soluţie optimă a problemei include soluţii optime ale subproblemelor. În consecinţă,

Avem două elemente cheie pe care o problemă de optimizare trebuie să le aibă pentru ca să putem aplica programarea dinamică:

Când o problemă prezintă o sub-structură optimală, este un candidat pentru programarea dinamică

Se construieşte soluţia optimă a problemei prin combinarea unor soluţii optimale la subprobleme

Substructura optimă variază în funcţie de domeniile problemei în două moduri:1. Câte subprobleme utilizează soluţia optimală a problemei

2. Câte posibilități de alegere avem pentru a determina subproblemele utilizate de soluţia optimală

În cazul tăierii barei de oţel de dimensiune n, avem o subproblemă de dimensiune n-i, dar trebuie să considerăm n variante pentru i pentru a determina care din ele conduce spre o soluţie optimă. În cazul problemei parantezării şirului de matrici în vederea înmulţirii lor, avem două subprobleme prin împărţirea şirului AiAi+1...Aj în două subşiruri AiAi+1…Ak respectiv Ak+1Ak+2…Aj care necesită apoi rezolvarea amândurora în mod optim. Practic există j-i candidaţi pentru alegerea indexului k.

2.2. Metoda Greedy

Metoda Greedy (greedy = lacom) este o metodă generală de proiectare a algoritmilor care constă în construirea soluţiei globale optimale printr-un şir de soluţii cu caracter de optim local atunci când este posibilă exprimarea “optimului global” ca o combinaţie de o “optime locale”. Algoritmii greedy sunt în general simpli şi sunt folositi la probleme de optimizare, cum ar fi: să se găsească cea mai bună ordine de executare a unor lucrări, să se găsească cel mai scurt drum într-un graf etc.

2.2.1 Problema selecţiei activităţilor

Se pune problema planificării unor activităţi care necesită utilizarea unei resurse comune.

Datele de intrare (inputul) este reprezentat de o mulţime S=a1, a2, …an de activităţi care necesită o resursă ce poate fi utilizată doar de o singură activitate la un moment dat.

Page 23: licenta hatz

16

Page 24: licenta hatz

Fiecare activitate ai are un moment de start si şi un moment de terminare fi cu 0<=si<fi<∞.O activitate ai are loc în intervalul [si,fi). Două activităţi ai şi aj sunt compatibile dacă si>=fj sau sj>=fi (intervalele lor nu se suprapun).

Datele de ieşire (outputul) reprezintă subsetul maximal de activităţi compatibile. Prezentăm în figura 2.10 un exemplu format din 11 activităţi (i=1,2, ..11) fiecare cu

momentul său de start si şi momentul de terminare fi.

Figura 2.10 Un exemplu de 11 activităţi având şirul momentelor de terminare sortat ascendent

În exemplul prezentat în figura 2.10, a3, a9, a11 reprezintă un subset de activităţi compatibile; acesta nu este un subset maximal deoarece a1, a4, a8, a11 este mai mare.Acesta din urmă este cel mai mare subset de activităţi compatibile; în acelaşi timp un alt subset maximal este şi a2, a4, a9, a11.

Substructura optimală a problemei selecţiei activităţilor –putem uşor constata că problema selecţiei activităţilor expune substructura optimă. Vom considera Sij mulţimea activităţilor care încep după finalizarea activităţii ai şi se termină înainte de începutul activităţii aj (slide –corectaţi “se termină” în loc de încep).

Presupunem că subsetul maximal de activităţi compatibile din Sij este Aij şi acesta include o activitate ak.

Incluzând ak în soluţia optimă pentru Sij, am împărţit problema Sij în două subprobleme Sik şi Skj cărora trebuie să le găsim subsetul maximal de activităţi. Sik sunt activităţi care încep după ce activitatea ai s-a terminat şi se termină înainte ca activitatea ak să înceapă iar Skj sunt activităţi care încep după ce activitatea ak s-a terminat şi se terminăînainte ca activitatea aj să înceapă.

Dacă Aik = Aij∩Sik şi Akj=Aij∩Skj atunci Aij=Aik ᴜak ᴜAkj unde Aik conţine activităţile din Aij care se termină înainte ca ak să înceapă iar Akj conţine activităţile din A ij care pornesc după ce ak se termină.

Deci soluţia optimală pentru Sij include soluţiile optimale pentru Sik şi Skj. Acest mod de a caracteriza substructura optimă ne sugerează că am putea rezolva problema selecţiei activităţilor utilizând programarea dinamică.

Dacă c[i,j] este mărimea unei soluţii optimale pentru Sij atunci c[i,j]=c[i,k]+c[k,j]+1. Pentru sij trebuie să determinăm acea activitate ak pentru care are loc recurenţa din

figura 2.11.

Figura 2.11 Formula recurentă pentru calculul mărimii soluţiei optimale la problema selecţiei activităţilor

Putem elabora un algoritm recursiv top-down pe care să îl memoizăm sau putem să folosim o abordare bottom-up şi să completăm succesiv intrările în această matrice.

Întrebarea este dacă am putea să adăugăm o activitate la soluţia optimă fără să rezolvăm mai întâi toate subproblemele? Aceasta ne-ar ajuta să scăpăm de luarea în considerare a tuturor variantelor care apar în formula recurentă 2.11. Astfel, în problema alegerii activităţilor vom considera o singură alegere şi anume alegerea greedy.

Page 25: licenta hatz

17

Page 26: licenta hatz

Intuitiv, alegerea greedy este acea activitate care lasă resursele disponibile pentru cât de multe activităţi disponibile, deci vom alege activitatea cu cel mai devreme moment de terminare (dacă mai mult de o activitate din S are cel mai devreme moment de terminare atunci vom putea alege oricare din aceste activităţi). Altfel spus, dacă activităţile sunt sortate în ordinea crescătoare a timpului de terminare, atunci alegerea greedy este activitatea a1.

Făcând o alegere greedy, ne rămâne o singură subproblemă de rezolvat: găsirea activităţilor care pornesc după ce a1 s-a terminat. De ce nu putem considera activităţile care se termină înainte ca a1 să înceapă? Deoarece avem s1<f1 şi f1 este cel mai devreme moment de terminare al oricărei activităţi şi deci nici o activitate nu poate avea timp de terminare mai mic sau egal decât s1. Deci toate activităţile compatibile cu a1 trebuie să înceapă după ce a1 se termină.

Condiţia structurii optimale ne spune că dacă alegerea greedy este optimală atunci şi rezultatul optim al problemei se compune din alegerea greedy şi rezultatul optimal al subproblemei rămase.

O soluţie greedy recursivă care rezolvă problema selecţiei activităţilor este prezentată în figura 2.12. Procedura RECURSIVE-ACTIVITY-SELECTOR primeşte ca parametri timpii de început şi de sfârşit al activităţilor (reprezentaţi de vectorii s şi f), indicele i care defineşte subproblema care trebuie rezolvată şi mărimea j a problemei originale. Această procedură va returna mulţimea maximă de activităţilor compatibile din Si. Presupunem că cele j activităţi primite ca date de intrare sunt deja ordonate crescător după timpul de terminare a lor. Dacă nu sunt sortate, am putea face sortarea lor într-un timp de complexitate O(nlgn).

Figura 2.12 Algoritmul recursiv greedy de selecţie a activităţilor

Procedura GREEDY-ACTIVITY-SELECTOR este o versiune iterativă a procedurii RECURSIVE-ACTIVITY-SELECTOR. Şi ea presupune că pornim de la un şir de activităţi sortat ascendent după timpul de finalizare a activităţilor. Procedura prezentată în figura 2.13 colectează activităţile selectate într-o mulţime A şi o returnează când această activitate este finalizată.

Figura 2.13 Varianta greedy iterativă a algoritmului de selecţie a activităţilor

Page 27: licenta hatz

18

Page 28: licenta hatz

În concluzie, proprietatea alegerii greedy poate fi enunţată astfel: alegem alternativa care apare ca şi cea mai promiţătoare la problema curentă, fără a rezolva subproblemele. De fapt, aceasta diferenţiază tehnica greedy de programarea dinamică prin faptul că aceasta din urmă rezolvă subproblemele (câte o singură dată) pentru a putea decide care este cea mai bună alegere. Utilizând greedy, facem alegerea care ni se pare cea mai bună la un anumit moment, după care rezolvăm subproblema rămasă. Programarea dinamică rezolvă subproblemele înainte să facă alegerea, în timp ce greedy face alegerea înainte să rezolve orice subproblemă. Programarea dinamică lucrează în general cu o strategie bottom-up (sau top-down cu memo-izare) în timp ce greedy foloseşte în general o strategie top-down, făcând alegeri greedy una după alta, reducând astfel instanţa problemei la o instanţă mai mică.

2.3. Metoda Backtracking

În practică se întâlnesc un număr mare de probleme care au un număr mare de variante ce se pot încerca, dar doar o parte din ele îndeplinesc condiţiile specifice problemei. O abordare simplistă a acestui gen de probleme poate fi următoarea: Se generează toate variantele posibile după care se elimină cele care nu îndeplinesc condiţiile specific (“brute force attack”). În cele mai multe cazuri o astfel de abordare este păguboasă, dacă nu chiar imposibilă.

O astfel de problemă poate fi caracterizată astfel: soluţia lor poate fi pusă sub forma unui vector S=v1,v2,v3…vn cu v1 S1,v2 S2,.....,vn Sn;

mulţimile S1,S2,S3…Sn sunt multimi finite, iar elementele lor se consideră că se află într-o relaţie de ordine bine stabilită

există anumite relaţii între componentele v1, v2,… vn, numite condiţii internePractic, dacă nu cunoaştem tehnica backtracking, suntem tentaţi să generăm toate

elementele produsului cartezian S1 S2 S3… Sn şi fiecare element să fie testat dacă este soluţie. Metoda de generare a tuturor soluţiilor posibile şi apoi de determinare a soluţiilor rezultat prin verificarea îndeplinirii condiţiilor interne necesită foarte mult timp (timpul cerut de această investigare exhaustivă este exponenţial). În cadrul tehnicii backtracking nu se generează toate soluţiile posibile, ci numai acelea care îndeplinesc anumite condiţii specifice problemei, numite condiţii interne (în unele lucrări de specialitate acestea mai sunt numite şi condiţii de validare). În cadrul acestei tehnici, elementele vectorului x primesc pe rând valori, în sensul că lui vk i se atribuie o valoare numai dacă au fost atribuite deja valori lui v1, v2, vk-1. Odată o valoare pentru vk stabilită, nu se trece direct la atribuirea de valori lui vk+1, ci se verifică condiţiile de continuare referitoare la v1, v2, vk care stabilesc situaţiile în care are sens să trecem la determinarea unei valori pentru vk+1.

Conceptual, tehnica backtracking caută sistematic soluţia într-un spaţiu al soluţiilor organizat sub forma unui arbore. Fiecare nod din arbore defineşte o stare a problemei. Toate drumurile de la rădăcină la frunze formează spaţiul stărilor. O soluţie a problemei reprezintă acele stări pentru care există drum de la rădăcină la un nod etichetat cu un n-uplu. Pot exista arbori statici (în cazul în care arborele astfel construit nu depinde de instanţa problemei) şi arbori dinamici (în cazul în care alegerea valorii vi depinde de una sau mai multe valori din mulţimea v1, v2, …vi-1)

Algoritmul acestei tehnici poate fi descris astfel:

1)se alege primul element v1 ce aparţine lui S1

Page 29: licenta hatz

19

Page 30: licenta hatz

2)se presupun generate elementele v1,v2,v3…vk-1 aparţinând mulţimilor S1 S2 S3…Sk-1 pentru generarea lui vk se alege primul element din Sk disponibil şi pentru valoarea aleasă se testează îndeplinirea condiţiilor de continuare.

Pot apărea următoarele situaţii :

a)nu s-a găsit un astfel de element, caz în care se reia căutarea considerând generate elementele v1,v2,v3…vk-1 iar vk se reia de la urmatorul element al mulţimii Sk rămas netestat

b)a fost găsit, caz în care se testează dacă acesta îndeplineşte condiţiile de continuare, aparând astfel alte două posibilităţi:

b1) vk îndeplineşte condiţiile de continuare. Dacă s-a ajuns la soluţia finală (k=n) atunci se afişează soluţia obtinută. Dacă nu s-a ajuns la soluţia finală se trece la generarea elementului următor vk+1;

b2) vk nu îndeplineste condiţiile de continuare. Se încearcă următoarea valoare disponibilă din Sk. Dacă nu se găseşte nici o valoare în S k care să îndeplinească condiţiile de continuare, se revine la elementul vk-1 şi se reia algoritmul pentru o nouă valoare a acestuia.Algoritmul se încheie când au fost luate în considerare toate elementele lui v1.

Algoritmul general al metodei backtracking este prezentat în figura 2.14.

Figura 2.14 Algoritmul general de rezolvare a unei probleme utilizând metoda backtracking

Backtracking este o metodă care poate furniza toate soluţiile unei probleme.

2.3.1 Problema reginelorProblema reginelor (sau a damelor) are următorul enunţ: Să se afişeze toate

posibilităţile de a aşeza pe o tablă de şah de dimensiune nxn, n dame astfel încât oricare 2 din acestea să nu se atace reciproc. Două dame se atacă una pe cealaltă dacă sunt aşezate pe aceeaşi linie sau pe aceeaşi coloană sau pe aceeaşi diagonală (principală sau secundară).

Vom considera xi linia pe care vom aşeza dama de pe coloana i. Printr-o astfel de reprezentare ne asigurăm că nu vom aşeza două dame pe aceeaşi coloană. Atunci, pentru o soluţie parţială Sk=x1, x2, … x k condiţiile de continuare includ:

xi≠xj oricare ar fi j=1,..k –i (sau altfel spus 1<=i≠j<=k) (prin acesta verificăm că nu am aşezat dama k pe o linie pe care să se găsească deja o altă damă)

Page 31: licenta hatz

20

Page 32: licenta hatz

|xi-xj|≠|i-j| pentru orice j=1,..k-i (prin aceasta ne asigurăm că dama k pe care am aşezat-o nu se atacă pe una din diagonale cu damele deja aşezate).

Un algoritm nerecursiv de rezolvare a problemei damelor se prezintă în figura 2.15:

Figura 2.15 Algoritmul nerecursiv de rezolvare a problemei damelor

Page 33: licenta hatz

21

Page 34: licenta hatz

3. NOŢIUNI DESPRE STRUCTURI DE DATE

3.1. Tipuri abstracte de date

Un tip abstract de date (Abstract Data Type ADT) este un tip de date necesar unui analist, dar care este posibil să nu existe în limbajul de programare ceea ce impune necesitatea implementării lui.

De exemplu tipul abstract Boolean reprezentat prin cele două valori de adevăr true şi false. În limbajul Basic acesta este implementat prin şiruri de caractere (“true” şi “false”) dar în limbajul C nu există acest tip de date, programatorii putându-se folosi de faptul că valoarea 0 înseamnă întotodeauna “false” iar orice valoare diferită de 0 (exemplu valoarea 1) înseamnă “true”. Dacă doreşte, programatorul poate să-şi implementeze un tip abstract de date Boolean. Specificarea unui ADT presupune specificarea:

Mulţimii valorilor admisibile

Mulţimii operaţiilor pe acele valori

Utilizărilor posibile ale acelei ADT

De exemplu, avem cazul unei structuri abstracte de date de tip coadă (queue) (structură de date de tip FIFO First In First Out –primul intrat primul ieşit). Cunoştinţele necesare unui analist privesc doar comportamentul unui ADT. În cazul unei ADT queue, analistul trebuie să cunoască cum se face:

Inserarea in coadă: la sfârşit

Extragerea de elemente din coadă: la început

Analistul nu trebuie să ştie implementarea cozii, programatorul ADT-ului se va ocupa de acest aspect. Există 2 implementări posibile pentru o coadă:

Un masiv + o variabilă auxiliară care memorează sfârşitul cozii

Un masiv + 2 variabile auxiliare: sfârşitul cozii şi începutul acesteia

Implementare cu pointeri: 2 variabile auxiliare: sfârşitul listei şi începutul acesteia

Acesta are implicaţii pentru programatorul ADT-ului care poate alege structuri de date corespunzătoare pentru implementare în timp ce pentru utilizatorul ADT-ului, comportamentul ADT-ului este observat prin efectul şi rezultatul realizării operaţiilor specificate.

3.2. ADT ListaO listă este o secvenţă de 0 sau mai multe elemente de acelaşi tip denumite noduri

noduri între care există o relaţie de ordine determinată de poziţia lor relativă. Ea este deci o mulţime eşalonată de elemente de acelaşi tip având un număr arbitrar de elemente. Numărul n al nodurilor se numeşte lungimea listei. Dacă n=0, lista este vidă. Dacă n>=1, a1 este primul nod iar an este ultimul nod. Pentru 1<i<n, ai precede pe ai+1 şi succede pe ai-1.

O listă se poate implementa în 2 moduri: folosind un şir sau folosind pointeri.Figura 3.1 prezintă structura unei liste implementate cu ajutorul unui şir.

Page 35: licenta hatz

22

Page 36: licenta hatz

Figura 3.1 O implementare statică a unei liste cu ajutorul unui şir

Implementarea unei liste utilizând un şir prezintă avantaje şi dezavantaje. Avantajul este accesul rapid la oricare din elementele listei, acces care se face cu

ajutorul indicelui elementului din şir. Dacă dorim o regăsire pe baza numărului de ordine al elementelor, vom utiliza indici (sau indecşi), în acest caz timpul de acces la oricare din elementele listei (elemente de tablou) este constant, indiferent de poziţie. De aceea, accesul la elementele listei prezintă o complexitate O(1).

Dezavantajul unei astfel de structuri statice de memorie este că dimensiunea ei trebuie specificată la compilare, nemaiputându-se apoi modifica această dimensiune. Deci este necesară estimarea dimensiunii tabloului (cu ajutorul căreia se va implementa lista) înainte de compilare. Tot ca dezavantaj, operaţiile de insert şi delete sunt de complexitate sporită.

În cazul implementării unei liste ca şi structura dinamică (utilizând pointeri), accesul la elementele unei liste liniare se face secvenţial, pornind de la capul listei (adresa primului nod al listei) până la ultimul element al ei, ceea ce măreşte uneori considerabil timpul de acces la un anumit element.

Figura 3.2 prezintă o listă de n elemente implementată cu ajutorul pointerilor. Regăsirea unui element se face destul de încet, vorbind de o complexitate O(n). În schimb operaţiile de insert şi delete se fac uşor. Un alt avantaj al implementării unei liste folosind pointeri este că nu trebuie specificată dimensiunea maximă, gestiunea spaţiului de stocare este optimă, utilizând alocarea dinamică de memorie.

Figura 3.2 O implementare dinamică a unei liste utilizând pointeri

Există două variante de implementare a unei liste utilizând pointeri: Acces la listă printr-un pointer

Santinele la început şi/sau sfârşit

Santinela reprezintă un element de listă gol care marchează începutul sau sfârşitul listei. Avantajul santinelei este că permite inserarea uşoară de elemente la început / sfârşitul listei.

23

Page 37: licenta hatz

Lista înlănţuită este o structură de date în care obiectele sunt aranjate într-o ordine liniară. La implementarea prin şiruri, ordinea este determinată de indici în timp ce la implementarea prin pointeri, ordinea este determinată de un pointer care arată către obiectul următor.

Pentru o listă liniară este obligatoriu să existe o variabilă, declarată în timpul compilării, denumită cap de listă (head) care să păstreze adresa primului element al listei. Pierderea acestei valori va duce la imposibilitatea accesării elementelor listei liniare.

În cazul unei liste dublu înlănţuite, la un element x, x.next arată către elementul succesor iar x.prev arată către elementul predecesor. Dacă x.prev == NULL, atunci x este primul element, denumit head. Dacă x.next == NULL, atunci x este ultimul element, denumit tail.

În cazul listelor simplu înlănţuite, fiecare element al listei conţine adresa următorului element al listei. Ultimul element poate conţine ca adresă de legătură fie constanta NULL sau NIL (sau constanta 0 care nu indică nici un alt element), fie adresa primului element al listei, în cazul listelor liniare circulare. În cazul unei liste circulare dubluînlănţuite, ultimul element din listă pointează către head iar primul element din listă pointează către tail.

Dacă lista este sortată, cheile apar în ordine sortată.

3.2.1. Operaţia de căutare într-o listăFigura 3.3 prezintă algoritmul de căutare a elementului k în lista L folosind o

căutare liniară simplă şi returnând un pointer către primul element cu cheia k din lista L. Dacă nu se găseşte nici un obiect cu cheia k în listă, atunci se returnează NIL.

Figura 3.3 Algoritmul de căutare unui element într-o listă înlănţuităPentru a căuta într-o listă cu n elemente, timpul de execuţie al procedurii LIST-

SEARCH este ϴ(n), în cazul cel mai defavorabil, caz în care trebuie traversată întreaga listă pentru a găsi elementul cu cheia k.

3.2.2. Inserarea unui element la începutul listeiFigura 3.4 prezintă algoritmul de inserare a unui element x într-o listă L.

Figura 3.4 Algoritmul de inserare a unui element într-o listă înlănţuită

3.2.3. Ştergerea unui element dintr-o listăPentru a şterge un element dintr-o listă avem nevoie de un pointer către acesta.

Dacă nu avem acest pointer, atunci va trebui găsit prin LIST-SEARCH.Figura 3.5 prezintă algoritmul de ştergere a elementului indicat de pointerul x.

Page 38: licenta hatz

24

Page 39: licenta hatz

Figura 3.5 Algoritmul de ştergere a unui element într-o listă înlănţuită

LIST-DELETE şterge un element într-un timp ϴ(1), dar dacă dorim să ştergem un element cu o cheie dată atunci în cel mai defavorabil caz vom avea nevoie de un timp ϴ(n) datorită necesităţii apelului procedurii LIST-SEARCH care să ne întoarcă un pointer către elementul care conţine cheia k.

Dacă ignorăm condiţiile de head şi tail ale listei, operaţia de delete se transformăîntr-un algoritm mult mai scurt, prezentat în figura 3.6.

Figura 3.6 Algoritmul simplificat de ştergere a unui element într-o listă înlănţuită

3.2.4. Căutarea şi inserarea unui element într-o listă cu santinelăO santinelă este un obiect dummy care marchează începutul sau sfârşitul listei. De

exemplu, noi vom introduce în lista L un obiect L.NIL care reprezintă un NIL dar care are toate atributele celorlalte elemente din listă. De câte ori vom avea în pseudocod o referinţă către NIL noi o vom înlocui cu o referinţă către L.NIL.

Atributul L.nil.next indică capul listei (head) iar L.nil.prev indică coada (sfârşitul) listei (tail). Atributul next al lui tail respectiv atributul prev al lui tail indică spre L.nil. Figura 3.7 indică modificările care apar în procedura de căutare respectiv inserare într-o listă dublu înlănţuită circulară cu santinelă.

Figura 3.7 Algoritmul de căutare respectiv inserare într-o listă dublu înlănţuită circulară cu santinelă

3.3. StivaStiva este o structură de tip LIFO (Last In First Out) –elementul ce ar urma să fie şters

este ultimul element adăugat într-o astfel de structură. Există două modalităţi de a implementa o stivă: folosind un şir (un array) sau folosind o structură înlănţuită cu pointeri.

25

Page 40: licenta hatz

Operaţia de inserare într-o stivă este cel mai adesea denumită PUSH iar operaţia de extragere este denumită POP. Figura 3.8 prezintă un exemplu de stivă cu cel mult n elemente implementată folosind un array S[1..n].

Figura 3.8 Un exemplu de stivă implementată cu un şir

Şirul are un atribut S.top care indexează ultimul element adăugat în stivă. Stiva conţine elementele S[1..S.top], unde S[1] este elementul de la baza stivei iar S[S.top] este elementul din vârf. Când S.top=0 stiva nu conţine nici un element şi este deci goală. Putem testa dacă stiva este goală cu ajutorul operaţiei STACK-EMPTY din figura 3.9. Într-o stivă goală (vidă) nu se poate face operaţia POP de extragere a unui element. Dacă S.top este mai mare decât n atunci stiva este plină. În pseudocodul prezentat în figura 3.9 nu ne facem griji cu privire la această posibilitate.

Figura 3.9 Procedurile de depunere şi extragere dintr-o stivă

Fiecare din cele 3 operaţii pe stivă din figura 3.9 au un timp de execuţie O(1).

3.4. CoadaCoada este o structură de tip FIFO (First In First Out). Într-o elementul care va fi

şters este întotdeauna cel mai vechi element adăugat în coadă. Operaţia de adăugare a unui element într-o coadă se numeşte ENQUEUE iar operaţia de extragere a unui element dintr-o coadă se numeşte DEQUEUE. La fel ca operaţia POP de extragere a unui element dintr-o stivă, şi operaţia DEQUEUE de extragere a unui element dintr-o coadă nu primeşte nici un argument.

Figura 3.10 prezintă operaţiile de inserare respective extragere din coadă, fără a se verifica dacă nu cumva încercăm să extragem un element dintr-o coadă goală sau dacă încercăm să inserăm un element într-o coadă plină.

Page 41: licenta hatz

26

Page 42: licenta hatz

Figura 3.10 Operaţiile de inserare respectiv extragere dintr-o coadă

Fiecare din cele 2 operaţii pe coadă din figura 3.10 au un timp de execuţie O(1).

3.5. Tabele direct adresabile; Tabele de dispersie

Multe aplicaţii necesită o structură de date care să suporte doar operaţii esenţiale pentru un dicţionar: INSERT, SEARCH şi DELETE. O tabelă de dispersie (hash table) este o structură de date care implementează dicţionare. Deşi căutarea unui element într-o tabelă de dispersie poate ţine (în anumite condiţii) la fel de mult ca şi căutarea unui element într-o listă înlănţuită (ϴ(n)), în practică această structură se comportă foarte bine. În anumite circumstanţe, timpul mediu de căutare a unui element într-o astfel de structură este de complexitate O(1).

Un hash table generalizează noţiunea unui şir (array) care foloseşte un indice pentru adresarea directă a elementelor lui. Astfel, orice poziţie poate fi examinată într-un timp O(1). Când numărul de chei stocate într-o astfel de structură este relative scăzut faţă de numărul total de posibile chei, tabelele de dispersie sunt o alternativă foarte bună la adresarea directă pe care o are un array. În loc de a utiliza cheia direct ca şi index pentru a adresa un element al şirului, într-o tabelă de dispersie indexul este calculat pe baza cheii(conceptul de hashing).

3.5.1 Tabele direct adresabile

Adresarea directă este o tehnică care funcţionează bine dacă universul U al cheilor este rezonabil de mic. Presupunem că o aplicaţie necesită elemente dintr-un dicţionar în care fiecare element are o cheie asociată din mulţimea U=0,1,…m-1. Vom presupune că nu există două elemente cu aceeaşi cheie. Pentru reprezentarea mulţimii dinamice se foloseşte un şir (o tabelă direct adresabilă) T[0..m-1] în care fiecare poziţie (sau slot) corespunde unei chei din U. Figura 3.11 ilustrează acest concept: Fiecare element din universul U=0,1,…9 corespunde unui index în tabela direct adresabilă T. Mulţimea K=2,3,5,8 a elementelor mulţimii determină sloturi în tabelă care conţin pointeri către elemente. Slotul k pointează spre un element din mulţime având cheia k. Dacă mulţimea K nu conţine un element cu cheia k, atunci valoarea din tabela T este T[k]=NIL.

27

Page 43: licenta hatz

Figura 3.11 Exemplificarea conceptului de tabelă direct adresabilăUneori, pentru a salva spaţiu, în loc să păstrăm cheia şi datele adiţionale într-un

obiect extern tabelei direct adresabile, cu un pointer într-un slot al tabelei către obiect, am putea stoca stoca obiectul chiar în slot. În acest ultim caz, un element cu cheia k este stocat în slotul k.

Figura 3.12 prezintă operaţiile pe astfel de tabele direct adresabile.

Figura 3.12 Operaţiile pe tabele direct adresabile

Fiecare din aceste operaţii au un timp de execuţie O(1).

3.5.2. Tabele de dispersie

Dacă universul de chei U este mare (adică m are o valoare mare), alocarea unui şir de dimensiune m nu este fezabilă iar uneori este imposibilă. În general în aceste cazuri, numărul de chei K care se stochează este mic în comparaţie cu mărimea lui U.

Când numărul de chei K stocat în dictionar este mult mai mic decât universul U al tuturor posibilelor chei, o tabelă de dispersie va necesita mult mai puţin spaţiu decât o tabelă direct adresabilă. Scopul de fapt este reducerea spaţiului de stocare cu menţinerea în acelaşi timp a facilităţii de căutare a unui element într-un timp de complexitate O(1). In cazul tabelelor de dispersie, timpul O(1) de căutare este valabil pentru cazul mediu de utilizare, în timp ce la tabelele direct adresabile timpul O(1) are loc şi pentru cazul cel mai defavorabil.

În cazul tabelelor de dispersie, pentru a determina locul în care va fi stocat elementul cu cheia k, vom utiliza o funcţie de dispersie (hash function):h:U->0,1,…m-1

Funcţia h mapează universul U al cheilor în sloturile tabelei hash T[0..m-1].Mărimea m a tabelei T este în mod obişnuit mult mai mică decât universul U. Fiecare element cu cheia k este salvat în locaţia T[h[k]]. Se spune că h[k] este valoarea hash a cheii k. Figura 3.13 ilustrează aceste concepte.

28

Page 44: licenta hatz

Figura 3.13 Ilustrarea conceptului de tabelă de dispersie

În figura 3.13, cheile k2 şi k5 ocupă acelaşi slot –în acest caz spunem că cele 2 valori intră în coliziune. Există tehnici de rezolvare a conflictelor create de coliziuni. Bineînţeles, ideal ar fi să se evite coliziunile –aceasta se poate face printr-o alegere potrivită a funcţiei h. Totuşi, datorită faptului că mărimea universului U este mai mare decât m, obligatoriu vor exista cel puţin două valori care să aibe acelaşi cod hash. Alegerea funcţiei hash trebuie să minimizeze numărul de coliziuni.

Cea mai folosită tehnică de rezolvare a coliziunilor este cea prin înlănţuire. Toate elementele care au acelaşi cod hash vor fi plasate în aceeaşi listă înlănţuită. Slotul j conține un pointer către lista care salvează elementele care au j ca şi valoare hash. Dacă nici un element nu are valoare de hash pe j, atunci T[j] = NIL.

Figura 3.14 prezintă modalitatea de rezolvare a coliziunilor prin înlănţuire.

Figura 3.14 Rezolvarea coliziunilor prin liste înlănţuite

Figura 3.15 prezintă operaţiile care se fac pe o tabelă de dispersie atunci când rezolvarea coliziunilor se face prin înlănţuire.

29

Page 45: licenta hatz

Figura 3.15 Operaţiile pe o tabelă de dispersie ce utilizează liste înlănţuite pentru valorile în coliziune

În adresarea directă, elementele vor fi salvate direct în tabela de dispersie. Deci fiecare slot din tabela de dispersie conţine fie un element fie NIL. La căutare, se examinează fiecare slot unde fie vom identifica elementul fie vom avea NIL. Într-o astfel de abordare nu vom avea liste înlănţuite sau elemente stocate în afara tabelei precum în tabelele cu înlăntuire. La inserare, se testează locaţiile din tabelă până să se găsească una liberă pentru inserare. Tabela de dispersie se poate umple, deci în mod maxim vom avea α=1.

În loc să urmărim pointerii, vom calcula secvenţa de sloturi care va fi examinată. Pentru a realiza inserarea utilizând adresarea directă, vom examina tabela hash până vom găsi un slot în care să punem cheia. În loc să lucrăm într-o ordine 0,1,...m-1 (care necesită un timp de căutare ϴ(n)), secvenţa poziţiilor depinde de cheia care va fi inserată. Pentru a determina care sloturi să fie examinate, vom extinde funcţia de dispersie astfel:h:U x 0,1…m-1->0,1,…m-1.

Cu adresarea directă, vom solicita pentru fiecare k o secvenţă de analizat:h(k,0), h(k,1), … h(k,m-1) care reprezintă o permutare a lui 0,1,…m-1, fiecare poziţie a tabelei de dispersie fiind eventual considerată ca un slot pentru o nouă cheie pe măsura umplerii tabelei.

În pseudocodul prezentat în figura 3.16, presupunem că elementele tabelei de dispersie T sunt chei fără informaţii adiţionale, cheile k sunt identice cu elementele conţinând conţinând cheia k. Fiecare slot conţine o cheie sau NIL dacă slotul este gol.

Figura 3.16 Inserarea şi căutarea într-o tabelă de dispersie

Trei tehnici sunt folosite pentru a calcula secvenţa de chei necesară adresării directe:1. Probarea liniară:

Dacă h’:U->0,1,…m-1 este o funcţie de dispersie obişnuită auxiliară, atunci probarea liniară va utiliza următoarea funcţie de dispersie: h(k,i)=(h’(k)+i) mod m cu i=0,1,…m-1.

30

Page 46: licenta hatz

Dându-se cheia k, vom încerca slotul T[h’(k)] dacă este liber; apoi vom încerca slotul T[h’(k)+1] şi tot aşa până la slotul T[m-1]. Vom continua apoi cu sloturile T[0], T[1] până la T[h’(k)-1].2. Probarea pătratică

Dacă h’:U->0,1,…m-1 este o funcţie de dispersie obişnuită auxiliară, atunci h(k,i)=(h’(k)+c1i+c2i2) mod m, cu c1 şi c2 două constante pozitive iar i=0,1,…m-1. Prima poziţie încercată va fi T[h’(k)] apoi următoarele poziţii depind într-o manieră pătratică de valorile lui i.

3. Dispersia dublă

Dacă se consideră două funcţii de dispersie auxiliare h1 şi h2, atunci h(k,i)=(h1(k)+ih2(k)) mod m.De exemplu se poate considera h1(k)=k mod m şi h2(k)=1+(k mod (m-1)) cu m număr prim. Pentru k=123456 şi m=701 vom aveam h1(k)=80 şi h2(k)=257 deci vom proba întâi poziţia 80 apoi vom încerca to al 257-lea slot (modulo 701) până vom găsi slotul liber.

Page 47: licenta hatz

31

Page 48: licenta hatz

STRUCTURI DE DATE AVANSATE

4.1. Arbore binar de căutareUn arbore binar de căutare se poate reprezenta ca o structură înlănţuită în care

fiecare nod este un obiect. Fiecare nod al arborelui conţine cheia, date auxiliare şi 3 referinţe: left care pointează spre nodul copil stânga, right care pointează spre nodul copil dreapta şi p care pointează spre nodul rădăcină. Dacă un copil lipseşte atunci referinţa spre acel copil va fi NIL.

Un arbore binar de căutare este un arbore binar (adică fiecare nod are cel mult 2 copii) care are următoarele proprietăţi:

Dacă x este un nod oarecare în arbore şi y este un nod în subarborele stâng atunci y.key<=x.key şi

Dacă x este un nod oarecare în arbore şi y este un nod în subarborele drept atunci x.key<=y.key

4.1.1. Traversarea unui arbore binar de căutare

Pentru arborii binari, se pot considera următoarele traversări:o Traversare în preordine: se vizitează nodul rădăcină, apoi subarborele stâng şi în

final subarborele drept (R St Dr).o Traversare în inordine: se vizitează subarborele stâng, apoi nodul rădăcină şi în

final subarborele drept (St R Dr)o Traversare în postordine: se vizitează subarborele stâng, apoi subarborele drept şi

în final nodul rădăcină (St Dr R)Pentru fiecare din cele 3 traversări, la vizitarea fiecărui subarbore se aplică din nou

aceeaşi regulă de vizitareConsiderăm arborele binar de căutare din figura 4.1:

Figura 4.1. Un exemplu de arbore binar de căutare

Traversarea în preordine a arborelui din figura de mai sus dă naştere următorului şir: 15 6 3 2 4 7 13 9 18 17 20.

Pentru traversarea în inordine vom avea: 2 3 4 6 7 9 13 15 17 18 20. Pentru traversarea în postordine vom avea: 2 4 3 9 13 7 6 17 20 18 15.Consecinţa acestei proprietăţi a arborelui binar de căutare este că traversând în

inordine nodurile unui astfel de arbore obţinem un şir crescător (după valoarea cheii) de articole.

Page 49: licenta hatz

32

Page 50: licenta hatz

Figura 4.2 prezintă algoritmul de afişare a elementelor unui arbore binar traversatîn inordine:

Figura 4.2 Parcurgerea în inordine a unui arbore binar de căutare

4.1.2. Căutarea într-un arbore binar de căutare

Figura 4.3 prezintă algoritmul de căutare într-un arbore binar de căutare. Procedura primeşte un pointer către rădăcina arborelui şi o cheie dată k care urmează să fie căutată în arbore. Procedura va returna un pointer către nodul cu cheia k (dacă acest nod există) sauNIL în caz contrar.

Figura 4.3 Algoritmul recursiv de căutare într-un arbore binar de căutare

Figura 4.4 prezintă acelaşi algoritm dar iterativ (deci fără a utiliza recursivitatea):

Figura 4.4. Algoritmul iterativ de căutare într-un arbore binar de căutare

4.1.3. Minimul, maximul şi succesorul unui nod într-un arbore binar de căutare

Într-un arbore binar de căutare, întotdeauna vom putea găsi elementul minim folosind un pointer care porneşte de la rădăcină şi urmează întotdeauna copilul din stânga.Figura 4.5 ilustrează acest algoritm.

Figura 4.5 Algoritmul de căutare a minimului într-un arbore binar de căutare

Analog, poate avea loc căutarea elementului maxim într-un arbore binar de căutare urmărind de data aceasta întotdeauna copilul din dreapta. Figura 4.6 prezintă acest algoritm.

Page 51: licenta hatz

33

Page 52: licenta hatz

Figura 4.6 Algoritmul de căutare a maximului într-un arbore binar de căutare

Dându-se un nod într-un arbore binar de căutare, uneori dorim să cunoaştem “succesorul” acestui element în ordinea sortată determinată de parcurgerea în inordine a acestui arbore. Dacă toate cheile sunt distincte, atunci succesorul unui nod cu cheia x este nodul cu cea mai mică cheie mai mare decât x.key. Proprietatea unui arbore binar de căutare ne permite să determinăm succesorul unui nod fără să comparăm cheile. Procedura prezentată în figura 4.7 returnează un pointer către succesorul nodului x (dacă acesta există) şi NIL în cazul în care x deja conţine cea mai mare cheie în arborele binar de căutare.

Figura 4.7 Algoritmul de găsire a succesorului unui element într-un arbore binar de căutare

4.1.4. Inserarea într-un arbore binar de căutare

Inserarea unui element va trebui să menţină proprietatea de bază a unui arbore binar de căutare.

Procedura TREE-INSERT din figura 4.8 primeşte ca şi parametru un nod z pentru care z.key=v (unde v este valoarea care urmează să fie inserată), z.left=NIL şi z.right=NIL.

Figura 4.8 Inserarea unui element într-un arbore binar de căutare

34

Page 53: licenta hatz

4.1.5. Ştergerea unui nod într-un arbore binar de căutare

În cadrul operaţiei de ştergere a unui nod într-un arbore binar de căutare vom avea nevoie de un algoritm care înlocuieşte un subarbore cu un alt subarbore.

Procedura TRANSPLANT din figura 4.9 înlocuieşte un subarbore ca şi copil al părintelui său cu un alt subarbore. Procedura înlocuieşte subarborele având ca rădăcină nodul pointat de u cu subarborele pointat de v. Astfel, părintele nodului u va deveni părintele nodului v.

Figura 4.9 Înlocuirea unui subarbore cu un alt subarbore

Figura 4.10 prezintă algoritmul de ştergere a unui nod dintr-un arbore binar de căutare.

Figura 4.10 Algoritmul de ştergere a unui nod într-un arbore binar de căutare

4.2 Arbore roşu şi negru

Operaţiile pe un arbore binar de căutare se fac într-un timp O(h) unde h este înălţimea arborelui. Aceste operaţii sunt rapide în cazul în care înălţimea arborelui este

35

Page 54: licenta hatz

mică. Dacă înălţimea este mare (arbori creaţi dezechilibraţi sau dezechilibraţi în urma unor inserări sau ştergeri succesive) atunci timpul acestor operaţii nu este mai bun decât în cazul unei liste înlănţuite.

Arborii roşu şi negru garantează un timp O(lgn) în cazul cel mai defavorabil pentru operaţiile de bază în acest arbore.

Un arbore roșu-şi-negru este un arbore binar de căutare la care fiecare nod are bit suplimentar, reprezentând culoarea: roșu sau negru. Fiecare nod de arbore conține următoarele campuri: cheia, culoarea, nodul stâng, nodul drept și părintele.

Un arbore roșu şi negru este un arbore binar de căutare cu următoarele proprietăţi:1. Fiecare nod este sau roșu sau negru2. Rădăcina este negru3. Fiecare frunză (NIL) este neagră4. Dacă un nod este roșu, atunci amândoi copii sunt negrii5. Pentru fiecare nod, toate căile simple de la nodul respectiv la frunzele descendente conțin același număr de noduri negre

Punând constrângeri asupra culorilor nodurilor oricărei căi simple de la rădăcină la frunze, arborii roşu şi negru asigură că nici una din aceste chei nu este de două ori mai lungă decât oricare alta; în consecinţă arborele este aproximativ balansat.

Într-un arbore roşu şi negru vom utiliza o singură santinelă pentru a reprezenta NIL. Santinela T.nil este un obiect cu aceleaşi atribute ca un nod oarecare din arbore. Culoarea santinelei este negru iar celelalte atribute p, left, right şi key pot avea valori arbitrare. Aşa cum se vede în figura 4.11 punctul b, toţi pointerii spre NIL au fost înlocuiţi cu pointeri către santinela T.nil. Vom utiliza santinela astfel încât vom putea trata orice copil NIL al unui nod x ca un nod ordinar a cărui părinte este x.

Page 55: licenta hatz

36

Page 56: licenta hatz

Figura 4.11 Un exemplu de arbore roşu şi negruOperaţiile TREE-INSERT şi TREE-DELETE într-un arbore cu n noduri se execută într-

un timp O(log(n)). Aceste operaţii schimbă arboreal, deci este posibil ca arborele rezultat să nu mai îndeplinească condiţiile de arbore roşu şi negru. Vor fi necesare corecţii în arbore pentru a păstra proprietăţile arborelui. Pentru a restaura aceste proprietăţi, vor trebui schimbate culori ale unor noduri ale arborelui şi de asemenea schimbată structura de pointeri.

Vom schimba structura de pointeri prin intermediul operaţiei de rotaţie care este o operaţie locală într-un arbore de căutare care menţine proprietăţile arborelui binar de căutare. Figura 4.12 prezintă cele două tipuri de rotaţii: rotaţii la stânga şi rotaţii la dreapta.

37

Page 57: licenta hatz

Figura 4.12 Operaţiile de rotaţie pe un arbore binar de căutareCând facem o rotaţie la stânga a unui nod x, presupunem că copilul dreapta y nu

este T.nil; x poate fi orice nod în arbore a cărui copil dreapta nu este T.nil. Operaţia de rotaţie la stânga (transformarea configuraţiei din dreapta figurii 4.14 în configuraţia din stânga) îl face pe y noua rădăcină a subarborelui, cu x ca şi copilul stânga a lui y iar copilul stânga a lui y (adică β) devine copilul dreapta a lui x.

Algoritmul LEFT-ROTATE din figura 4.13 presupune că x.right≠T.nil şi că părintele rădăcinii este T.nil.

Figura 4.13 Algoritmul de rotaţie la stânga într-un arbore binar de căutare Procedura RB-INSERT din figura 4.14 va insera în arborele roşu şi negru T nodul z

(cu cheia deja încărcată în acest nou nod).

38

Page 58: licenta hatz

Figura 4.14 Algoritmul de inserare a unui nod într-un arbore roşu şi negru Datorită faptului că colorarea în roşu a nodului proaspăt inserat ar putea încălca

proprietatea de colorare a arborilor roşu şi negru, vom apela procedura RB-INSERT-FIXUP(T,z) (prezentată în figura 4.15) la linia 17 pentru a restaura această proprietate.

Figura 4.15 Algoritmul de restaurare a proprietăţilor unui arbore roşu şi negru după inserarea unui nod

Ca şi alte operaţii de bază într-un arbore roşu şi negru, operaţia de ştergere a unui nod se va face într-un timp O(lg n). În primul rând este necesară modificarea procedurii TRANSPLANT (figura 4.9) făcută la arborii binar de căutare. Noua procedură RB-TRANSPLANT este prezentată în figura 4.16.

39

Page 59: licenta hatz

Figura 4.16 Procedura de înlocuire a unui arbore cu un alt subarbore pentru un arbore roşu şi negru

4.3. Elemente legate de grafuri

Vom considera un graf G=(V,E) unde V reprezintă mulţimea nodurilor iar E reprezintă mulţimea arcelor (sau mulţimea muchiilor).

Există două moduri standard de a reprezenta un graf G: ca o mulţime de liste de adiacenţă sau ca o matrice de adiacenţă. Fiecare din cele două variante se aplică atât grafurilor neorientate cât şi grafurilor orientate. Reprezentarea prin liste de adiacenţă este de preferat pentru reprezentarea grafurilor rare –adică a grafurilor pentru care mulţimea arcelor este mult mai mică decât multimea nodurilor (grafuri cu densitate mică). Pentru grafurile dense este de preferat reprezentarea cu ajutorul matricilor de adiacenţă.

O listă de adiacenţă ca modalitate de reprezentare a unui graf reprezintă un şir Adj de V liste, câte una pentru fiecare nod din graf. Pentru fiecare nod uϵV, Adj[u] conţine toate nodurile v din graf pentru care există o muchie (un arc) (u,v)ϵE. Deci Adj[u] este format din totalitatea vârfurilor adiacente lui u în G. Notaţia G.Adj[u] se foloseşte pentru a ne referi la lista de adiacenţă a nodului u.

Dacă G este un graf orientat, suma lungimilor tuturor listelor de adiacenţă este |E| deoarece un arc (u,v) este reprezentat doar prin vϵ Adj[u]. Dacă G este un graf neorientat, suma lungimilor tuturor listelor de adiacenţă este 2|E| deoarece un arc (u,v) apare atât in lista de adiacenţă a lui u (v apare în Adj[u]) cât şi în lista de adiacenţă a lui v (u apare înAdj[v]).

Atât pentru grafuri orientate cât şi pentru grafuri neorientate, spaţiul de memorie necesar este ϴ(V+E).

Dacă graful este ponderat (graf cu costuri) cu ponderile dată de o funcţie de cost w:E->R, atunci ponderea w(u,v) al muchiei (u,v)ϵE va fi memorată împreună cu vârful v în lista de adiacenţă a lui u.

Un dezavantaj al listelor de adiacenţă este că nu oferă un mod mai rapid de a determina dacă există un arc (u,v) între cele două noduri altfel decât a căuta pe v în lista de adiacenţă a lui u adică în Adj[u]. Matricea de adiacenţă rezolvă această problemă dar folosind asimptotic mai multă memorie.

Într-o matrice de adiacenţă presupunem că nodurile sunt numerotate arbitrar cu1,2,…|V|. Vom folosi o matrice A de dimensiuni |V|x|V| astfel încât elementele aijîndeplinesc condiţia din figura 4.17:

Figura 4.17 Matricea de adiacenţă a unui graf

Matricea de adiacenţă ocupă un spaţiu ϴ(V2), indiferent de numărul de arce(muchii) ale grafului.

40

Page 60: licenta hatz

La un graf neorientat, (u,v) şi (v,u) reprezintă aceeaşi muchie, în consecinţă matricea este simetrică faţă de diagonala principală (deci matricea de adiacenţă este propria sa transpusă AT=A).

Pentru un graf ponderat, putem stoca costurile arcelor ca elemente ale matricii de adiacenţă, iar acolo unde arcul nu există putem stoca NIL, ∞ sau 0.

Vom putea accesa un atribut d al unui unui nod v folosind notaţia v.d. De asemenea, vom putea accesa un atribut f al unui arc (u,v) folosind notaţia (u,v).f.

4.3.1 Parcurgerea în lăţime a unui grafExistă două modalităţi de parcurgere a grafurilor: parcurgerea în lăţime (breadth

first) respectiv parcurgerea în adâncime (depth first).În cazul parcurgerii în lăţime, pornind de la un graf G(V,E) şi un nod s de start, vom

explora în mod sistematic arcele din G pentru a descoperi fiecare nod care este accesibil pornind de la nodul s. Algoritmul calculează distanţa (cel mai mic număr de muchii) de la nodul s la fiecare nod care este conectat la s. Algoritmul explorează frontiera dintre nodurile descoperite şi cele nedescoperite în lăţime, adică descoperă toate nodurile la distanţă k, apoi cele la distanţă k+1 etc. Algoritmul este funcţional atât pentru un graf neorientat cât şi pentru un graf orientat.

Parcurgerea în lăţime colorează fiecare nod cu alb, gri sau negru pentru a ţine evidenţa avansării. Se presupune că iniţial toate nodurile din graf sunt colorate în alb (adică sunt nedescoperite), devin mai târziu gri şi apoi negre. Nodurile gri şi negru sunt noduri care au fost descoperite. Dacă avem arcul (u,v)ϵE şi u este nod negru, atunci v va fi negru sau gri (toate nodurile adiacente unui nod negru au fost descoperite).

Algoritmul produce un “arbore de lăţime” având ca rădăcină nodul s, care conţine toate aceste vârfuri conectate la s. Pentru fiecare vârf v accesibil din s, calea din “arborele de lăţime” de la s la v corespunde celui mai scurt drum de la s la v în G, adică un drum care conţine un număr minim de muchii. De fiecare dată când căutarea descoperă un nod alb v în cursul scanării listei de adiacenţă al unui nod deja descoperit u, nodul v şi arcul (u,v) este adăugat în acest arbore. Vom spune că u este predecesorul sau părintele lui v în arborele de lăţime. Deoarece un vârf este descoperit cel mult o dată, el poate avea cel mult un părinte.

Procedura de căutare în lăţime din figura 4.18 presupune că graful de intrare G(V,E) este reprezentat utilizând liste de adiacenţă.

Page 61: licenta hatz

41

Page 62: licenta hatz

Figura 4.18 Algoritmul de parcurgere în lăţime pentru un graf reprezentat cu liste de adiacenţă

4.3.2. Noţiunea drumului de lungime minimăVom defini calea cea mai scurtă (sau drumul de lungime minimă) δ(s,v) din s în v ca

fiind numărul minim de muchii ale oricărui drum de la s la v sau ∞ dacă nu există un drum de la s la v.

Dacă avem un graf G=(V,E) şi s un nod arbitrar din V, atunci pentru orice arc (u,v)ϵE avem δ(s,v)<=δ(s,u)+1. (dacă u este accesibil din s atunci şi v este accesibil din s. În acest caz, cel mai scurt drum de la s la v nu poate fi mai lung decât cel mai scurt drum de la s la u la care se adaugă 1 corespunzător muchiei (u,v)).

Dacă se execută BFS pornind de la un nod s, la terminare, pentru fiecare nod v pentru care există o cale de la s, valoarea v.d calculată de algoritmul BFS satisface v.d=δ(s,v).

Procedura PRINT-PATH din figura 4.19 prezintă algoritmul de afişare a drumurilor de lungime minimă pornind de la nodul sursă s până la nodul destinaţie v.

Figura 4.19 Procedura de afişare a drumurilor de lungime minimă pornind de la s la v

4.3.3. Parcurgerea în adâncime a unui grafParcurgerea în adâncime presupune o căutare în graf cât mai adâncă oricând

acest lucru este posibil. În căutarea in adâncime, muchiile sunt explorate pornind de la vârful v cel mai recent descoperit care mai are încă muchii neexplorate care pleacă din el. Dacă toate muchiile unui nod v au fost explorate, atunci algoritmul face back-tracking la

42

Page 63: licenta hatz

următorul nod care trebuie explorat după v. Această operaţie continuă până când au fost descoperite toate nodurile accesibile din vârful sursă iniţial.

Vom folosi aceeaşi convenție de colorare şi anume alb, gri şi negru. Pentru fiecare nod folosim 2 ştampile de timp:

v.d momentul în care nodul a fost descoperit pentru prima dată (când este marcat gri)

v.f momentul în care parcurgerea termină lista de adiacență a lui v (când nodul va fi marcat negru)

Acest marcaj de timp este o valoare întreagă cuprinsă între 1 şi 2|V| deoarece există un moment de descoperire şi un moment de terminare pentru fiecare din cele |V| noduri ale grafului.

Figura 4.20 Algoritmul de căutare în adâncimeFigura 4.20 prezintă algoritmul de căutare în adâncime pentru un graf neorientat

sau orientat.

4.3.4. Sortare topologicăCăutarea în adâncime poate fi folosită pentru o sortare topologică a unui graf orientat

aciclic. O sortare topologică a unui graf orientat aciclic G=(V,E) este o ordonare liniară a tuturor vârfurilor sale astfel încât, dacă G conţine o muchie (u,v) atunci u apare înaintea lui v în ordonare. Dacă graful nu este aciclic, atunci nu este posibilă sortarea topologică. O sortare topologică a unui graf poate fi văzută ca o ordonare a vârfurilor sale de-a lungul unei linii orizontale astfel încât toate muchiile sale merg de la stânga la dreapta.

Figura 4.21 prezintă un exemplu de sortare topologică a unor obiecte de îmbrăcăminte care trebuie îmbrăcate într-o anumită ordine. De exemplu, ciorapii trebuie îmbrăcaţi înaintea pantofilor. O muchie orientată (u,v) din graful aciclic din figura 4.21 punctul (a) indică faptul că articolul de îmbrăcăminte u trebuie îmbrăcat înaintea articolului v. Punctul (b) prezintă graful orientat aciclic sortat topologic ca o ordonare a vârfurilor de-a

Page 64: licenta hatz

43

Page 65: licenta hatz

lungul unei linii orizontale. Muchiile orientate merg de la stânga la dreapta. Vârfurile sunt aranjate de la stânga la dreapta în ordinea descrescătoare a timpului de terminare.

Figura 4.21 Un exemplu de sortare topologică

Algoritmul din figura 4.22 sortează topologic un graf orientat aciclic:

Figura 4.22 Algoritmul simplu de sortare topologică a unui graf orientat aciclic

Page 66: licenta hatz

44

Page 67: licenta hatz

4.3.5. Componentă tare conexă a unui grafO componentă tare conexă a unui graf orientat G=(V,E) este o mulţime maximală de

vârfuri U V, astfel încât, pentru fiecare pereche de vârfuri u şi v din U există un drum de la u la v precum şi de la v la u. Altfel spus, între oricare două noduri din componentă există cel puţin un drum şi nu mai există nici un nod în afara componentei legat printr-un drum de un

nod al componentei.

Algoritmul din figura 4.23 determină componentele tare conexe ale unui

graf orientat G=(V,E) folosind două căutări în adâncime, una în G şi una în GT.

Figura 4.23 Algoritmul de determinare a componentelor tare conexe dintr-un graf orientat

4.4. Arbori de acoperire minimi

La proiectarea circuitelor electronice, de multe ori este necesară legarea pinilor mai multe componente, conectându-i cu fire, fiecare fir conectând doi pini. Pentru interconectarea unei mulţimi de n pini vor fi necesare n-1 fire. Având în vedere că pot fi mai multe aranjamente de interconectare, se cere să se determine cablarea care foloseşte cea mai mică cantitate de cabluri.

Vom folosi un graf neorientat conex, G=(V,E) unde V este mulţimea pinilor şi E este mulţimea interconectărilor posibile dintre perechile de pini; pentru fiecare pereche de pini (u,v)ϵE, avem un cost w(u,v) ce reprezintă costul cablului de la pinul u la pinul v. Dorim să determinăm submulţimea aciclică T E care conectează toate nodurile din V şi al cărei cost total w(T)=∑(u,v)ϵT w(u,v) este minim.

Deoarece mulţimea T este aciclică şi conectează toate nodurile, ea trebuie să formeze un arbore care va fi denumit arbore de acoperire deoarece “acoperă” graful G. Problema determinării arborelui T va fi numită problema arborelui de acoperire minim.Vom prezenta doi algoritmi de determinare a arborelui de acoperire minim: algoritmul luiKruskal şi algoritmul lui Prim.

Algoritmii pe care îi vom prezenta pentru determinarea arborelui de acoperire minim sunt algoritmi greedy. Această strategie greedy este implementată în algoritmul generic din figura 4.24, care dezvoltă arborele de acoperire minim adăugând o muchie o dată. Algoritmul foloseşte o mulţime A care este întotdeauna o submulţime a unui arbore de acoperire minim. La fiecare pas este determinată o muchie (u,v) care poate fi adăugată la A, respectând proprietatea de mai sus, adică AU(u,v) este, de asemenea, o submulţime a unui arbore de acoperire minim. Numim o astfel de muchie o muchie sigură (safe) pentruA, deoarece poate fi adăugată, în siguranţă, mulţimii A, respectând proprietatea de mai sus.

45

Page 68: licenta hatz

Figura 4.24 Algoritmul generic de determinare a unui arbore de acoperire minim Partea dificilă este găsirea unei muchii sigure în linia 3 a algoritmului. Vom defini o

tăietură (S, V-S) a unui graf neorientat G=(V,E) ca o partiţie a lui V. Spunem că o muchie (u,v)ϵE traversează tăietura (S,V-S) dacă unul din punctele sale terminale este în S şi celălalt este în S-V. Spunem că o tăietură respectă mulţimea de muchii A dacă nici o muchie din A nu traversează tăietura. O muchie este o muchie uşoară care traversează o tăietură dacă are costul minim dintre toate muchiile care traversează tăietura. Pot exista mai multe muchii uşoare care traversează o tăietură dacă ele au costuri egale. Generalizând, spunem că o muchie este o muchie uşoară care satisface o proprietate dată dacă are costul minim dintre toate muchiile care satisfac acea proprietate.

4.4.1. Algoritmul lui Kruskal de determinare a unui arbore de acoperire minim

Algoritmul lui Kruskal de determinare a unui arbore de acoperire minim se bazează pe algoritmul generic prezentat în figura 4.24. Algoritmul găseşte o muchie sigură (u,v) dintre toate muchiile care conectează 2 arbori în pădurea de arbori pentru a o adăuga la pădurea dezvoltată. Muchia sigură (u,v) este muchia cu costul minim care uneşte doi arbori din pădurea respectivă.

Algoritmul lui Kruskal, prezentat în figura 4.25, foloseşte o structură de date pentru mulţimi disjuncte pentru a reprezenta mai multe mulţimi de elemente disjuncte. Fiecare mulţime conţine vârfurile unui arbore din pădurea curentă. Funcţia FIND-SET(u) returnează un element reprezentativ din mulţimea care îl conţine pe u. Astfel, putem determina dacă două vârfuri u şi v aparţin aceluiaşi arbore testând dacă FIND-SET(u) este egal cu FIND-SET(v). Combinarea arborilor este realizată de procedura UNION.

Figura 4.25 Algoritmul lui Kruskal de determinare a unui arbore de acoperire minim

4.4.2. Algoritmul lui Prim de determinare a unui arbore de acoperire minim

Precum algoritmul lui Kruskal, algoritmul lui Prim este un caz particular al algoritmului generic pentru determinarea unui arbore de acoperire minim pentru un graf conex. Algoritmul lui Prim are proprietatea că muchiile din mulţimea A formează întotdeauna un singur arbore. Arborele se formează pornind de la un vârf arbitrar r şi creşte

46

Page 69: licenta hatz

până acoperă toate vârfurile din V. La fiecare pas, se adaugă arborelui o muchie uşoară care uneşte mulţimea A cu un vârf izolat din GA=(V,A). La fel ca algoritmul lui Kruskal, algoritmul lui Prim foloseşte o tehnică gredy deoarece arborelui ii este adăugată la fiecare pas o muchie care adaugă cel mai mic cost la costul total al arborelui.

În procedura MST-PRIM din figura 4.26, graful G, rădăcina r a arborelui minim de acoperire care urmează să fie dezvoltat şi costurile w sunt parametri de intrare. În timpul execuţiei, toate vârfurile care nu sunt în arbore sunt într-o coadă de prioritate Q bazată pe un câmp cheie. Pentru fiecare vârf v, atributul v.key este costul minim al oricărei muchii care uneşte pe v cu un vârf din arbore.

Figura 4.26 Algoritmul lui Prim de determinare a unui arbore de acoperire minim

4.5. Drumuri minime într-un graf

Problema drumului minim apare deseori în practică. Un exemplu ar fi găsirea drumului cel mai scurt dintre 2 oraşe.

Fiind dat un graf orientat cu costuri G=(V,E) şi având funcţia de cost w:E->R care asociază fiecărei muchii câte un cost exprimat printr-un număr real. Costul w(p) al unei căi p=v0, v1, … vk este suma costurilor de pe calea p (figura 4.27).

Figura 4.27 Costul unei căi exprimat ca suma costurilor muchiilor de pe acea cale

Costul unui drum minim (costul optim) de la u la v se defineşte în figura 4.28.

Figura 4.28 Costul drumului minim

Un drum minim de la u la v este orice drum p cu proprietatea w(p)=δ(u,v).În continuare ne vom axa pe problema drumului minim de sursă unică. Însă, există

mai multe variante ale problemei drumului minim, şi anume:Problema drumurilor minime de destinaţie unică: Să se găsească de la fiecare nod vϵV drumul minim până la un vârf destinaţie t prestabilit. Această problemă poate fi pusă şi invers: calea cea mai scurtă de la o sursă s la fiecare nod v dintr-un graf.Problema drumurilor minime de sursă şi destinaţie unică: Să se determine un drum minim de la u la v pentru u şi v date. Dacă rezolvăm problema drumurilor minime de sursă unică pentru vârful u atunci rezolvăm şi această problemă. De fapt, nu se cunosc algoritmi pentru

Page 70: licenta hatz

47

Page 71: licenta hatz

rezolvarea acestei probleme care să fie asimptotic mai rapizi decât cel mai bun algoritm pentru determinarea drumurilor minime de sursă unică, în cazul cel mai defavorabil. Problema drumurilor minime pentru surse şi destinaţii multiple: Să se determine drumul minim de la u la v pentru fiecare pereche de vârfuri u şi v. Această problemă poate fi rezolvată, de exemplu, prin aplicarea algoritmului pentru sursă unică pentru fiecare vârf al grafului.

De regulă, algoritmii pentru determinarea drumurilor minime exploatează proprietatea că un drum minim între două vârfuri conţine alte drumuri optimale. Această proprietate de optimalitate substructurală este specifică atât programării dinamice cât şi metodei greedy. Algoritmul Dijkstra aplică metoda greedy iar algoritmul Floyd-Warshall pentru determinarea drumurilor minime pentru toate perechile de vârfuri este un algoritm de programare dinamică.

Proprietatea de optimalitate substructurală a drumurilor minime poate fi enunţatăastfel:

Dacă se dă un graf orientat G=(V,E) şi o funcţie de cost w:E->R pe graful G, şi fie p=v0, v1, …vk calea de cost minim între 2 noduri v0 şi vk; atunci pentru orice 0<=i<=j<=k, p-ij=vi,v i+1, …vj este calea de cost minim între vi şi vj.

Considerând un graf G=(V,E), pentru fiecare nod vϵV vom memora predecesorul acestuia v.π, care poate fi un alt nod sau NIL. Algoritmii de determinare a drumului minim setează predecesorii astfel încât dacă se merge de la un nod v înapoi, vom găsi calea minimă (printr-o traversare în ordine inversă) de la sursa s până la nodul v.

4.5.1. Reprezentarea drumurilor minime

Deseori dorim nu doar să determinăm lungimea drumului minim ci şi vârfurile care compun acest drum minim. Pentru reprezentarea acestor drumuri minime vom utiliza o reprezentare similară celei considerate la parcurgerea în lăţime a arborilor. Dându-se un graf G=(V,E) vom păstra pentru fiecare nod vϵV un predecesor v.π care este fie un alt nod fie NIL. Algoritmii pentru determinarea drumurilor minime ce urmează să fie prezentaţi determină π astfel încât pentru fiecare vârf v, lanţul de predecesori care începe cu vârful v să corespundă unei traversări în ordine inversă a unui drum minim de la s la v. Astfel, pentru orice vârf v pentru care v.π≠NIL vom putea utiliza procedura PRINT-PATH(G,s,v) pentru tipărirea unui drum minim de la s la v.

Vom considera subgraful predecesor Gπ=(Vπ,Eπ) indus de valorile lui π, unde Vπ este mulţimea nodurilor din V care au proprietatea că au predecesor diferit de NIL reunită cu mulţimea constând din nodul sursă:Vπ=vϵV:v.π≠NILᴜs

Mulţimea de muchii orientate Eπ este mulţimea de muchii indusă de valorile lui π pentru vârfurile din Vπ:Eπ=(v.π,v)ϵE:vϵVπ-s

Atunci Gπ este un “arbore al drumurilor minime” adică este un arbore cu rădăcina s conţinând câte un drum minim de la sursa s la fiecare vârf al grafului G care este accesibil din s.

4.5.2. Relaxarea

Algoritmii care urmează să fie prezentaţi în continuare utilizează tehnica de relaxare. Pentru fiecare vârf vϵV vom păstra un atribut v.d reprezentând o margine superioară a costului unui drum minim de la sursa s la vârful v. Numim d.v o estimare a

Page 72: licenta hatz

48

Page 73: licenta hatz

valorii drumului minim. Estimările drumurilor minime şi predecesorii sunt iniţializaţi prin procedura din figura 4.29.

Figura 4.29 Iniţializarea estimărilor drumurilor minime şi a predecesorilor într-un graf G cu sursa s

Termenul de relaxare semnifică de fapt o operaţie care determină decrementarea unei margini superioare. În procesul de relaxare a unei muchii (u,v) se verifică dacă drumul minim până la vârful v (determinat până în acel moment) poate fi îmbunătăţit pe baza unui drum care să treacă prin u, şi dacă da, atunci se reactualizează v.d şi v.π. Practic, un pas de relaxare poate determina descreşterea valorii v.d reprezentând valoarea drumului minim de la s la v şi reactualizarea câmpului v.π care conţine predecesorul vârfului v. Procedura RELAX este prezentată în figura 4.30.

Figura 4.30 Procedura de relaxare a unei muchii (u,v) într-un graf cu costuri

4.5.3. Algoritmul Bellman-Ford

Algoritmul Bellman-Ford rezolvă problema drumurilor minime cu sursă unică în cazul general al unui graf care poate avea şi costuri negative. Dându-se un graf orientat G=(V,E), un vârf sursă s şi funcţia de cost w:E->R, algoritmul Bellman Ford returnează o valoare booleană indicând dacă există sau nu un ciclu de cost negativ accesibil din vârful sursă s considerat. În cazul în care un astfel de ciclu există, algoritmul semnalează că nu există soluţie iar dacă nu există un astfel de ciclu, algoritmul produce drumurile minime şi costurile corespunzătoare lor. Procedura BELLMAN-FORD este prezentată în figura 4.31 şi utilizează tehnica relaxării prin descreşterea estimării valorii v.d adică valoarea drumului minim de la vârful sursă s până la fiecare vârf vϵV până la obţinerea adevăratului cost minim δ(s,v). Algoritmul returnează TRUE dacă şi numai dacă nu conţine cicluri de cost negativ accesibile din sursă.

Figura 4.31 Algoritmul Belmann-Ford

Page 74: licenta hatz

49

Page 75: licenta hatz

4.5.4. Drumuri minime de sursă unică în grafuri orientate aciclice

Prin relaxarea arcelor într-un graf orientat aciclic (DAG directed acyclic graph) cu costuri conform unei ordonări topologice a vârfurilor sale putem calcula drumurile minine de sursă unică într-un timp ϴ(V+E). Drumurile minime sunt întotdeauna bine definite într-un DAG datorită faptului că acesta nu poate avea cicluri de cost negativ, chiar dacă graful conţine arce de cost negativ.

Algoritmul începe prin sortarea topologică a grafului pentu impunerea unei ordini liniare a vârfurilor. Dacă există un drum de la u la v atunci u precede v în ordinea topologică. Algoritmul efectuează o singură trecere peste vârfurile sortate topologic şi pe măsură ce fiecare vârf este procesat, sunt relaxate toate muchiile care pornesc din acel vârf.

Algoritmul de căutare a drumurilor minime într-un graf orientat aciclic este prezentat în figura 4.32.

Figura 4.32 Algoritmul de căutare a drumurilor minime într-un graf orientat aciclic

4.5.5. Algoritmul lui Dijkstra

Algoritmul lui Dijkstra rezolvă problema drumurilor de lungime minimă cu sursă unicăîntr-un graf orientat G=(V,E) cu costuri nenegative. Deci în acdrul acestui algoritm vom avea w(u,v)>=0 pentru orice arc (u,v)ϵE.Algoritmul lui Dijkstra gestionează o mulţime S de noduri pentru a cărui elemente algoritmul a calculat deja costurile finale ale drumurilor minime de la sursa s. Algoritmul selectează câte un vârf u din mulţimea V-S pentru care estimarea drumului minim este minimă, introduce acest vârf u în mulţimea S şi relaxează arcele divergente din din vârful u. Figura 4.33 prezintă algoritmul lui Dijkstra.

Figura 4.33 Algoritmul lui Dijkstra de determinare a drumurilor de lungime minimăîntr-un graf orientat cu costuri nenegative

50

Page 76: licenta hatz
Page 77: licenta hatz

1. SISTEME DE OPERARE

Autor: George Sebastian Chiş

1.1 Sisteme de Operare - Definiție şi funcționalitate

Un sistem de calcul modern este alcătuit dintr-unul sau mai multe procesoare, memorie principală, discuri, display, tastatură, display, interfețe de rețea și alte interfețe de intrare/ieșire. Toate aceste elemente împreună formează un sistem complex[TANENBAUM06]

Peste arhitectura hard a unui calculator este un program de bază numit și sistem de operare care are sarcină să administreze dispozitivele din sistem și să ofere programelor utilizatorilor modalități de interfațare mai simple cu structura hard. Structură hard împreună cu instrucțiunile în limbaj de asamblare alcătuiesc nivelul ISA (Instruction Set Arhitecture - Arhitectura setului de instrucțiuni) numit și limbaj mașină.

Programe de aplicaţii Dezvoltat de Pachete de programeutilizatori Biblioteci, Browsere Editoare …

Soft de bază SO Translatoare Editoare de legături …Hard Limbaj maşină

Microprograme (Firmware)Componente fizice

Figura 2. 1 – Sistem de calcul alcătuit din structura hard, SO şi aplicaţii

Software de bază (sistem) – fac sistemul să funcţioneze:Translatoare Interpretoare de comenziEditoare de legăturiPrograme de comunicație etc.Software de aplicaţii ale unor utilitare pentru utilizatori: Pachete de programeEditoare de texte SGBD-uri Navigatoare WebInstrumente de dezvoltare de aplicaţii Editoare de imaginiSisteme financiar contabile, ERP (Entreprise Resource Planning), HRM, CRM, SCM, FMS Bibliotecare etc.

Sistemele de operare realizează două funcții de bază între care nu există nici o legătură: extinderea funcționalității mașinii şi gestionarea resurselor,ceea ce nu putem spune este care din aceste funcții este mai importantă. Prin funcția de extindere ascunde detalii neplăcute precum: întreruperile, timer-ele, gestiunea memoriei şi alte elemente de nivel scăzut. Tot funcția de extindere ascunde programatorului „adevărul” despre structură hard și prezintă numai partea frumoasă a fișierelor cu nume nu și cu octeți şi reprezintă o vedere de sus în jos a SO.

În abordarea de jos în sus este prezența funcția de gestionare a resurselor care are că sarcină să realizeze o alocare ordonată și controlată a proceselor, memoriilor și dispozitivelor de I/O în diversele programe scrise pentru ele. Administrarea resurselor include partajarea resurselor în timp şi spațiu (multiplexarea). Când este în timp programele sau utilizatorii le folosesc pe rând resursele (exemplu: tipărirea) formându-se o coadă SO este acela care spune cine urmează şi cât timp are alocat. Când este în spațiu fiecare client folosește o parte din resursa (exemplu: memoria principală este împărțită între mai multe programe, sau HDD este o altă resursa multiplexată în spațiu.

Page 78: licenta hatz

1.2 Evoluţia şi clasificarea sistemelor de calcul

Abacul - sistem de bile – Asia - introdus cu 2000-3000 de ani [Price77]. 1614 - John Napier – logaritmi şi tabel de calcul;1620 - Wiliam Oughtred - bazat pe logaritm.1642 - Blaise Pascal (19 ani) - maşinilor mecanice. Maşina Pascal făcea adunări şi scăderi; conceptul de

complement - preluat în informatica modernă. O limitare - înmulţirea - adunări repetate. Nicolaus Wirth – limbajulPASCAL.

1671 - Gottfried von Leibnitz - înmulţiri şi împărţiri.1822 - Charles Babbage, profesor de matematică la Universitatea din Cambridge (Anglia) - a construit un

sextant - motor diferenţial prezentat Societății Regale de Ştiinţe.1834 - dispozitiv complex - maşină analitică, care a avut o arhitectură asemănătoare cu cea a calculatoarelor

moderne. Motivele nerealizării: suport tehnologic adecvat şi epoca industrială era în faza incipientă.Ada Augusta Byron, contesă de Lovelace prima programatoare din lume; limbajul Ada (Bull).1802-1804 - Calculatoarelor electromecanice - cartele perforate - Joseph Jacquard introduce automatizarea

războaielor de ţesut. Hermann Hollerith - compania Hermann Hollerith Tabulating Recording Company sisteme Hollerith sau tabulatoare.

1911, fuzionarea a 3 firme The Computing Tabulating Recording Company, - din 1924 IBM (International Business Machine Corporation).

1937-1944, Howard Aitken de la Harvard University - Mark I, cu ajutorul IBM. John von Neumann - unul dintre fondatorii informaticii moderne principiile.

Principiile von Newmann de construire a unui calculator

John von Neumann făcea analogii cu comportamentul creierului uman. Această arhitectură descrie un calculator cu patru module importante: unitatea aritmetică-logică (UAL, arithmetic logic unit sau ALU), unitatea de control, memoria centrală (care bine-înţeles se deosebeşte aproape total de memoria omului), şi dispozitivele de intrare/ieşire I/E (sau I/O , de la input/output). Acestea sunt interconectate cu un mănunchi de fire numit magistrală(bus) şi sunt conduse în tactul unui ceas (clock).

maşina va executa frecvent operaţiile aritmetice: adunarea, scăderea, înmulţirea şi împărţirea rezultând existenţa unei componente specializate destinată calculului (aritmetico-logică, unitate de calcul etc.).operaţiile se vor executa secvenţial. Distincţie între instrucţiunile necesare rezolvării unei probleme particulare şi controlul general asupra acestor instrucţiuni. (componenta de control) - unitatea de calcul + CPU (Control and Processing Unit) / procesor.memorie în care se „ţin minte" instrucţiunile & datele necesare rezolvării problemei (internă sau memorie operativă).senzor – recepţioneze / transmit semnalele vin / la din exterior (astăzi le numim dispozitive de intrare/ieşire, I/E, sau periferice).

volatilitatea;memorie permanentă (memoria externă de astăzi). transfer între memoria internă la cea permanentă.

1.3 Istoria sistemelor de operare

Sistemele de operare se împart în 5 generaţii după cum urmează:

Prima generaţie 1945 – 1955 - Primele calculatoare digitale construite: relee electro-mecanice, tuburi; programare se făcea manual, în limbaj mașină; nu existau compilatoare sau asambloare; nu existau sisteme de operare; primul bug descoperit în 1947 (Harvard Mark II).

În 1941 inginerul german Konrad Zuse dezvolta computerul Z3 pentru a proiecta avioane şi rachete. 1943: Forţele Aliate produc un computer spărgător de coduri, denumit Colossus. 1944: SUA produce Mark I, primul computer complet electronic, cu dimensiunile unei jumătăţi de teren de fotbal. Al doilea computer produs de SUA a

Page 79: licenta hatz

fost ENIAC. Era de 1.000 de ori mai rapid ca Mark I şi consuma 160 de kilowati. 1951: apare UNIVAC I, primul computer disponibil comercial. 1952: UNIVAC I prezice matematic alegerea ca presedinte a lui Eisenhower.

A doua generaţie 1955 – 1965 - tranzistoare, batch systems; tranzistoare; mainframe-uri; apare conceptul de batch; sisteme de operare: FMS, IBSYS.Inventarea tranzistorului aduce schimbari radicale. Introdus în computere în 1956 şi cuplat cu memoria cu

miez magnetic, el da naștere unei generații de ordinatoare mai mici şi mai eficiente. Primele „supercomputere“ au fost Stretch, produse de IBM şi LARC pentru laboratoarele de energie atomica. La începutul anilor ’60 apare IBM 1401, considerat piatra de temelie a conceptului actual. Apar de asemenea limbajele de programare COBOL (Common Business-Oriented Language) şi FORTRAN (Formula Translator), care înlocuiesc codul binar criptic cu cuvinte şi formule matematice.

A treia generaţie 1965 – 1980 - ICs şi multiprogramarea; circuite integrate; apare conceptul de familie de calculatoare (IBM System/360): aceeași arhitectura şi set de instrucțiuni.

Deși tranzistorii reprezentau o evoluție semnificativa, ei generau intens căldură, care deteriora restul componentelor interne. Așa începe folosirea cristalelor de cuarț. În 1958, Texas Instruments produsese circuitul integrat, care combina trei componente electronice pe un disc de siliciu. Un alt pas l-a constituit apariția sistemelor de operare, care au permis computerelor sa ruleze mai multe aplicaţii simultan, cu un program central de monitorizare şi coordonare a memoriei. Sistemul de operare pentru System/360: OS/360 aduce: Multiprogramare - Partiţionarea memoriei în mai multe segmente, cât timp un job aşteaptă la I/O alt job se execută Spooling - Citirea joburilor de pe cartele perforate şi păstrarea lor pe disc pâna la execuţie Multitasking (time-sharing): CTSS (Compatible Time Sharing System) MULTICS (Multiplexed Information and Computing Service) MIT, Bell Labs, General Electric Lansat în 1960 are un succes comercial scăzut, însă are o influenţă masivă

asupra dezvoltării ulterioare a SO UNIX versiune mult redusă a MULTICS, implementată de Ken Thompson System V, BSDA patra generaţie 1980 – prezent- calculatoarele personale CP/M - Dezvoltat de Kidall pentru Intel 8080. După circuitele integrate, direcția principală a rămas reducerea dimensiunilor. Deja, în anii ’80, integrarea la scara foarte larga putea concentra sute de componente pe un singur cip. În 1971, cipul Intel 4001 integra toatecomponentele unui computer pe o pastila minuscula. Acum se naste microprocesorul. Computerele vândute sunt însoţite de pachete de software. Pionieri ai domeniului sunt Commodore, Radio Shack şi Apple Computers. La începutul anilor ’80 apar primele jocuri arcade, precum Pac Man, şi primele sisteme casnice de jocuri, precum Atari 2600. 1981: IBM lansează PC (Personal Computer), care va deveni standard în domeniu. După 1984 este folosită pe scară largă invenţia MacIntosh, pe care azi o cunoaştem ca mouse. 1992: Începe folosirea intensivă a rețelelor şi Internetului în accepțiunea actuală a conceptului.

A cincea generaţie Definirea acestei generații este dificilă, deoarece se află în faza de început. Cel mai bun exemplu ar putea fi celebrul, dar fictivul, HAL 9000 (care era dotat cu inteligenţă artificială), din romanul Odiseea spaţială 2001 al lui Arthur C. Clarke. Considerat utopic la data apariţiei cărţii (1968), acest calculator se va naşte în laboratoarele viitorului, confirmând, încă o dată, aserțiunea conform căreia cuvintele creează realitatea.

Perioada Tehnologie Tehnologie Limbaje Performanţe,Generaţia CPU memorie Utilizate memorie şi CPU

1946-1956 Tuburi electronice Tambur Asamblare Memorie 2 Ko., Viteza:magnetic 104 I/S

1957-1963 Tranzistori Inele de ferită nivel înalt: Memorie: 32 Ko, Viteză:I FORTRAN, 2*105 I/S

COBOL etc.1964-1981 Circuite integrate Memorii Pascal, Lisp, limbaje grafice Memorie: 2Mo, Viteză:

II semiconductori 5*106 I/Sdiscurimagnetice

După-1982 Circuite integrate Memorii cu ADA, limbaje obiectuale, Memorie de peste 256V pe scară foarte largă bule, discuri limbaje vizuale etc. Mo, Viteză 5*107 I/S,

optice SupercalculatoareDupă 1990 Circuite integrate Arhitecturi Limbaje concurent, limbaj Viteză: 1012 I/S;

pe scară extrem de paralele natural,limbaje funcţionale memorare şi prelucrarelargă; maşini LISP şi logice cunoştinţe, vedereşi Prolog artificială, tehnologia

vorbirii

Page 80: licenta hatz

Clasificarea sistemelor de operare:SO pentru mainframe: OS/360, VM/370SO pentru servere: UNIX, Windows NT/2000/2003/2008, LinuxSO pentru sisteme multiprocesorSO pentru calculatoare personaleReal Time OS: QNX, RTLinuxSO pentru sisteme embeddedSO pentru PDA-uri şi telefoane mobile (Windows Mobile, Symbian, Android, iPhone OS (bazat pe Mac OS))

Componentele sistemului de operare: Gestiunea proceselor Gestiunea memoriei Gestiunea fişierelor Gestiunea operaţiilor de I/E Gestiunea reţelei

3: Concepte ale SO

Procesul - este în fapt un program în execuţie. Fiecărui proces i se asociază un spaţiu de adrese, adică o listă de locaţii în memorie din care programul poate câţi sau în care poate scrie. Locaţiile cuprinse între două limite, una minimă (de obicei 0) şi una maximă. Spaţiul de adrese conţine programul executabil, datele programului şi stiva. Procesului i se asociază, de asemenea, un set de registre care cuprinde contorul program, indicatorul de stiva şi alte registre hard, precum şi diverse alte informaţii necesare rulării programului.[TANENBAUM06]

La multe SO toate informaţiile despre fiecare proces, altele decât cele aflate în propriul spaţiu de adrese, sunt memorate într-un tabel al sistemului de operare numit tabel de procese, care este un tablou de structuri pentru fiecare proces existent.

Figura 3. 1 Arbore de proces. Procesul A a creat două procese- copii: B şi C Procesul B a creat 3 procese copii D, E, F

Pentru a implementa un proces a „SO foloseşte o tabelă (un vector de structuri) numit tabelă de procese cu o intrare pentru fiecare proces. Această intrare conţine informaţii despre: starea procesului, contorul program, indicatorul de stiva, alocarea memoriei, starea fișierelor deschise, detalii de contabilizare, şi planificare şi orice alte informaţii despre un proces, care trebuie salvate atunci când procesul comută între stările în execuţie, gata de execuţie şi blocat, astfel încât să poată fi repornit mai târziu ca şi cum nu ar fi fost oprit niciodată.

În tabelul de mai jos se poate vedea câteva din câmpurile importante dintr-un sistem obişnuit:Gestiunea procesului Gestiunea memoriei Gestiunea fişierelor

Registrare Indicator spre segmentul de text Directorul rădăcinăContorul program Indicator spre segmentul de date Directorul de lucru

Indicator spre segmentul deCuvântul de stare al programului stivă Descriptorii de fişiere

Page 81: licenta hatz

IdentificatorulIndicatorul de stivă utilizatoruluiStarea procesului Identificatorul grupuluiPrioritateParametri de planificareIdentificatorul procesuluiProces primarGrupul procesuluiSemneMomentele începerii procesuluiDurata de utilizare UCPDurata de utilizare UCP de cătrecopiiMomentul următoarei alarme

Figura 3. 2 Câteva din câmpurile unei intrări obişnuite din tabela de proceseFirele de execuţie în sistemele de operare tradiţionale, fiecare proces are un spaţiu de adrese şi un singur fir

de control. Dar de cele mai multe ori este de dorit existenţa mai multor fire de control în acelaşi spaţiu de adrese rulând pseudo-paralel, că şi cum ar fi procese separate(cu excepţia partajării spaţiului de adrese).

Un proces este că o grupare de resurse înrudite şi are spaţiu de adrese ce conţine textul programului şi date, precum şi alte resurse. Aceste resurse pot include fişiere deschise, procese copil, semnale de alarmă în aşteptare, rutine de tratare a semnalelor, informaţii de contabilizare şi altele. Acestea pot fi gestionate uşor prin gruparea lor sub formă de proces.

Firul de execuţie (thread) are un contor de program care ţine evidenţa următoarei instrucţiuni de executat, totodată deţine şi registre care ţin variabilele curente de lucru. Are de asemenea o stiva care conţine istoricul execuţiei, cu un cadru pentru fiecare procedura apelată din care nu s-a revenit încă. Deşi un fir de execuţie trebuie să ruleze într-un proces,firul şi procesul sunt concepte diferite şi pot fi tratate separat. Procesele sunt utilizate pentru a grupă resurse, în timp ce firele de execuţie sunt entităţi planificate pentru execuţie în cadrul UCP (unitate centrală de procesare).

Modul de lucru al firelor de execuţie este: partajează spaţiul de adrese, fişiere deschise şi ale resurse sau partajează memoria fizică , discurile, imprimantele şi alte resurse.

Prin comutarea între mai multe procese, sistemul oferă iluzia unor procese secvenţiale separate care se execută în paralel. Programarea cu fire de execuţie multiple funcţionează în acelaşi mod: UCP comută rapid între firele de execuţie oferind iluzia că acestea rulează în paralel, deşi pe o UCP mai lentă decât pe cea reală. În cazul unui proces cu trei fire de execuţie, toate efectuând calcule, acestea păr să se execute în paralel, fiecare pe o UCP cu o viteză de trei ori mai mică decât a UCP reale.

Situaţiile în care două sau mai multe procese citesc şi scriu date partajate şi rezultatul final depinde de cine ce execută exact când, se numesc condiţii de cursă (race conditions). Rezolvarea acestora o reprezintă excluderea mutuală (mutual exclusion), adică o cale prin care să fim asiguraţi că dacă un proces foloseşte o variabila partajată sau un fişier, celelalte procese nu vor putea face acelaşi lucru. Pentru a avea o soluţie bună trebuie îndeplinite patru condiţii:oricare două procese nu se pot afla simultan în regiunile lor critice1;nici un fel de presupunere nu se poate face asupra vitezelor sau numărului de UCP-uri;

nici un proces care rulează în afara regiunii lui critice nu poate bloca alte procese; nici un proces nu trebuie sa aștepte la infinit pentru a intra în regiunea lui critică.

Page 82: licenta hatz

1 Partea de program în care memoria partajată este accesată

Page 83: licenta hatz

Figura 3.2A Excluderea mutuală folosind regiuni criticeInterblocările – sunt situaţiile când două sau mai multe procese interacționează, şi se ajunge la situaţii

conflictuale din care nu mai pot ieşi(exemplu: ca şi în traficul rutier dintr-o intersecţie).Dispozitivele de I/O – sunt acele dispozitive care preiau intrări şi generează ieșiri. La ce ar fi bun un

calculator dacă utilizatorii n-ar putea să-i „spună” ce să facă şi n-ar putea prelua rezultatele activităţii solicitate.Fişier - un sistem de administrare al fişierelor constă într-o asociaţie de date abstracte necesare pentru

memorarea, organizarea ierarhică, manipularea, accesul şi recuperarea informaţiilor stocate într-un sistem de calcul.Cele mai familiare sisteme de operare folosesc pentru memorarea informaţiilor un şir de blocuri de

dimensiune fixă, numite de obicei sectoare, de regulă, de 512 octeţi fiecare. Sistemul de operare este responsabil cu organizarea acestor blocuri de date în fişiere şi directoare şi controlul sectoarelor care aparţin unor fişiere sau sunt libere.

Sistemul de fişierele conţine directoare sau foldere şi fişiere acestea fiind administrate, de regulă, prin asocierea numelui lor la un tabel de indexare, în stilul FAT pentru DOS sau INODE pentru UNIX. Structura folderelor poate fi liniară sau ierarhizată, situaţie în care folderele conţin şi subfoldere. Unele sisteme folosesc nume structurate de fişiere cu o sintaxă specială pentru extensie şi număr de versiune; alte sisteme folosesc drept nume de fişiere şiruri simple de caractere, metadatele (diverse proprietăţi ale fişierelor) fiind memorate în altă parte. [Silberschatz04]

Sistemele de fişiere se pot clasifica în: sisteme de fişiere pe disc, sisteme de fişiere de reţea şi sisteme de fişiere cu destinaţie specială.

Un sistem al fişiere pe disc este destinat memorării fişierelor pe un disc care este direct sau indirect legat la un calculator.

Cele mai cunoscute astfel de sisteme, în ordine alfabetică, sunt:EXT2 (second extended file system) este folosit de majoritatea sistemelor de operare din familia LINUX.EXT3 (third extended file system) este o perfecţionare a lui EXT2 în sensul monitorizării în diverse jurnale

a tuturor activităţilor efectuate; are tendinţa de a înlocui EXT2 dar încă are erori.FAT (File Allocation Table) este sistemul de fişiere de bază dezvoltat pentru DOS şi Windows; este

considerat cel mai simplu şi, datorită popularităţii sale, este cel mai folosit pentru discurile flexibile.FAT este principalul sistem de administrare al fişierelor dezvoltat pentru DOS şi Windows. Sistemul FAT

este considerat relativ simplu, acesta fiind unul din motivele pentru care este cel mai popular format pentru discurile flexibile. Este suportat, virtual, de multe sisteme de operare şi adesea este folosit pentru distribuirea informaţiilor între mai multe sisteme de operare instalate pe acelaşi calculator într-un mediu multibooting.

FAT a fost dezvoltat de mult timp, acesta fiind unul din motivele pentru care astăzi este destul de criticat: FAT induce în timp o fragmentare importantă a fişierelor pe disc, aceasta având drept consecinţă scăderea

vitezei de accesare a fişierelor;FAT nu păstrează informaţii redundante necesare pentru recuperarea datelor în cazul unei defecţiuni a

sistemului; într-adevăr, există o copie a tabelului de alocare însă aceasta, de cele mai multe ori nu poate rezolva problemele apărute;

FAT nu dispune de nici un mecanism pentru prevenirea accesului neautorizat la fişiere, atributele asociate fişierelor fiind minimale;

primele versiuni de FAT aveau limitate numărul de caractere pentru numele şi extensia fişierului (8+3); prin VFAT, o variantă modernizată, s-a extins totuşi la 255 numărul de caractere al numelui şi extensiei;

organizarea, prin clustere2 de mari dimensiuni, iroseşte spaţiul pe discurile de mare capacitate, spaţiu inaccesibil sistemului dar accesibil unor aplicaţii perfide; spaţiul respectiv este denumit slack file.

FAT a debutat o dată cu DOS 1.0 în 1983. Varianta iniţială era destinată numai discurilor flexibile şi nu admitea existenţa directoarelor. Datorită dimensiunii reduse a discurilor, primele sisteme FAT erau realizate pe 12

2Termen traductibil prin grămadă, ciorchine; constă într-un spaţiu continuu pe disc obţinut prin alipirea a mai multor sectoare consecutive.

Page 84: licenta hatz

biţi, dimensiune acceptabilă pentru discurile flexibile cu care lucra sistemul de operare DOS1.0 (12 biţi semnifică 4096 de sectoare adresabile adică o capacitate de 2MB, mai mare decât cei 1.44 MB ai discului). Acest sistem de administrare a căpătat denumirea de FAT12.

Ulterior, DOS 2.0 a inclus şi suportul pentru subdirectoare, precum şi FAT pe 16 biţi necesar pentru utilizarea primelor hard discuri de 5 MB. Cele 65536 de locaţii permiteau adresarea unui disc de 32 MB, suficienţi la data respectivă. Sistemul a căpătat denumirea de FAT16.

Odată ce hard discurile au începu să crească în dimensiuni, FAT16 a început să aibă probleme în administrarea întregului spaţiu util de pe un hard disc. Soluţiile au constat în partiţionarea discului (împărţirea în mai multe volume logice de sine stătătoare) şi în introducerea clusterelor care au mărit, virtual, capacitatea de stocare a unei unităţi de alocare. În principal, aceste facilităţi au apărut odată cu Windows 95 care a mai eliminat o limitare a sistemului clasic: prin VFAT (virtual FAT) era eliminată regula numelor de fişiere 8+3.

Din 1997, creşterea în dimensiuni a clusterelor a fost epuizată: clusterul maxim era de 32768 octeţi, ceea ce însemna că Windows 95 nu putea vedea discuri mai mari de 2 GB. În consecinţă, pentru următorul sistem de operare, Windows 95 OSR2, s-a introdus FAT32, sistem care permitea adresarea a 268 435 456 clustere (deocamdată nu sunt folosiţi decât 28 de biţi din cei 32; valoarea reprezintă 228). În aceste condiţii, dimensiunea clusterelor a putut fi redusă înapoi la 4 KB (8 sectoare), fiind totuşi posibilă adresarea unui disc de 1TB. O consecinţă pozitivă rezultată din scăderea dimensiunii clusterului a fost şi utilizarea mai eficientă a spaţiului pe disc.

Sistemele de operare alternative pentru PC, de exemplu OS/2, BeOS, FreeBSD, LINUX etc. dispun şi ele de variante care suportă VFAT şi FAT32.

FAT32 - utilizează spaţiul mai eficient. FAT32 utilizează clustere mai mici (adică clustere de 4 KO pentru unităţi de până la 8 GO), având ca rezultat o utilizare a spaţiului de disc cu 10-15 la sută mai eficientă faţă de unităţile mari FAT sau FAT16, este mai robust, poate relocaliza folderul rădăcină şi poate utiliza copia de rezervă a tabelului de alocare a fişierelor în locul copiei implicite. În plus, înregistrarea de încărcare a unităţilor FAT32 este extinsă pentru a include o copie de rezervă a structurilor de date critice, sunt mai puţin predispuse la un singur punct de eroare decât unităţile FAT16, este mai flexibil. Folderul rădăcină de pe o unitate FAT32 este un lanţ obişnuit de clustere, astfel încât poate fi plasat oriunde pe unitate. Limitările anterioare în ceea ce priveşte numărul de intrări în folderul rădăcină nu mai există. În plus, se poate dezactiva oglindirea tabelului de alocare de fişiere, permiţând să fie activă o altă copie a tabelului de alocare a fişierelor în loc de prima copie. Aceste caracteristici permit redimensionarea dinamică a partiţiilor FAT32.

UMSDOS este un sistem de fişiere pentru LINUX care simulează cele mai avansate facilităţi UNIX folosind un sistem de fişiere de tip FAT.

HFS (Hierarchical File System) este folosit de sistemul de operare Apple Mac OS. HPFS (High Performance File System) a fost creat pentru sistemul de operare OS/2.

ISO 9660 (împreună cu extensiile Rock Ridge şi Joliet) este un standard care defineşte sistemul de fişiere pentruCD-ROM; este implementat în Windows, Mac OS, LINUX, UNIX etc.

JFS (Journalizing File System) sistem de fişiere cu monitorizarea activităţilor dezvoltat de IBM; este disponibil pe AIX, OS/2 şi LINUX.

MINIX (Mini Unix) este unul din numeroasele clone de UNIX apărute în perioada în care AT&T (proprietarul UNIX) refuza vânzarea acestuia; a stat la baza dezvoltării LINUX.

NTFS (New Technology File System) este sistemul de fişiere standard pentru Windows NT şi predecesoarele sale Windows 2000 şi Windows XP; capacitatea de a recupera automat după anumite erori legate de disc, ceea ce FAT32 nu poate realiza. Suport îmbunătățit pentru hard disk-uri mai mari. Are securitate mai bună, deoarece aveți posibilitatea să utilizați permisiuni şi criptare pentru a restricționa accesul la anumite fișiere numai la utilizatorii autorizați. Acest sistem de fișiere foloseşte adrese de disc de 64 de biţi şi poate suporta partiţii de până la 264 bytes, totodată oferă posibilitatea folosirii caracterelor Unicode în numele de fişiere, permite folosirea numelor de fişiere de până la 255 de caractere, inclusiv spaţii şi puncte; permite indexare generală a fişierelor; oferă posibilitatea managementului dinamic al sectoarelor; datorită compatibilităţii POSIX, permite crearea hard-link-uri, face distincţie între litere mari şi mici în cadrul numelor de fişiere şi păstrează informaţii de timp referitoare la fişier; permite utilizarea fişierelor cu seturi multiple de date.

1.5 Gestiunea memoriei şi dispozitivelor I/O

Memoria ocupă locul doi ca importanţă în structura unui sistem de calcul după procesor şi este de tip ierarhic şi este caracterizata astfel:

Page 85: licenta hatz

puţină memorie cache foarte rapidă, scumpă şi volatilă mult RAM3 de viteză medie, nu foarte scumpă şi volatilă foarte mult spaţiu de stocare pe disc lent, ieftin şi nevolatil.BIOS4-ul este un program de mărime mică (< 2MB) fără de care computerul nu poate funcționa, acesta

reprezintă interfața intre componentele din sistem şi sistemul de operare.În zilele noastre un calculator personal - PC are în prezent mai mult memorie decât calculatorul IBM 7094,

cel mai mare calculator din lume la începutul anilor 1960.În zilelor noastre programele cresc în dimensiune mai repede decât memoria. Legea lui Parkison spune ca programele se extind pentru a ocupa toată memoria care le este pusă la dispoziție.

Ideea – este că orice programator ar vrea ca memoria sa fie infinit de mare, infinit de rapidă, nevolatilă, adică sâ îşi păstreze conținutul când nu este alimentată de curent.

Partea sistemului de operare care gestionează această memorie ierarhică se numeşte manager de memorie. Este sarcina sa să urmărească ce părți de memorie sunt libere, să aloce memorie proceselor când acestea au nevoie, să dealoce memoria când procesele au terminat şi să facă transferul dintre memoria principala şi disc atunci când memoria principală este insuficientă pentru a conţine toate procesele.

Sistemele de gestiune a memoriei pot fi împărţite în două categorii: cele care mută procesele între memorie şi disc în timpul execuției acestora (interschimbare – swapping şi paginare) şi cele care nu fac aceste operaţii.

Trebuie să înțelegem că interschimbarea şi paginarea sunt în mare parte metode ce compensează lipsa unei memorii principale suficient de mare încât să poată conţine toate programele ce rulează la un moment dat. De exemplu, Microsoft recomandă următoarele specificaţii pentru sistemul de operare Windows 7: Procesor: 1 GHz; RAM - 1 GB -2 GB şi spațiu pe Hard Disk - 16 GB, asta în timp ce pentru Windows XP recomanda: Procesor: 200 MHz; RAM– 128 MB şi spaţiu pe Hard Disk – 1,5 GB.

Sistemul de operare când este în RAM ca şi în cazul (a) a fost folosit în trecut pe mainframe-uri5 şi minicalculatoare, dra în prezent nu mai este întâlnit aproape nicăieri. Când este ținut ca şi în cazul (b) în ROM îl întâlnim pe PDA-uri6 şi sisteme încorporate, iar al treilea model a fost folosit pe primele calculatoare personale (exemplu: cele pe care rulau MS-DOS, unde porţiunea sistemului care se afla în ROM se numește BIOS.

SistemulDriverele

de echipament înde operare în

Programul ROMROM7

utilizatoruluiProgramul

utilizatoruluiProgramul

Sistemulutilizatorului

Sistemulde operare în de operare în

RAM RAM

(a) (b) (c)Figura 3. 3 Trei moduri simple de organizare a memoriei pentru un sistem de operare şi un

singur proces al utilizatoruluiCu excepţia sistemelor încorporate simple, monoprogramarea nu mai este folosită aproape nicăieri. Cele mai

multe sisteme moderne permit rularea mai multor procese în același timp. A avea mai multe programe care rulează

1 Random Access Memory – Memorie cu Acces Aleator2Basic Input Output Sistem – Sistem elementar de Intrare/Ieşire3Sisteme mari de calcul

4Personal Digital Assistant - Asistente personale digitale sunt calculatoarele de tinut in mana care au fost initial proiectate sa fie agende personale electronice, dar, in timp, au devenit mai polivalente. PDA-urile sunt de asemenea calculatoarele de buzunar avand reputatia de calculatoarele sau de palmtop. Intrebuintari : calculator aritmetic, ceas de buzunar si agenda calendaristica, pentru a juca jocuri electronice, accesarea internetul, receptionarea si transmiterea de e-mail-uri, inregistrarea video, editarea de documente de tip text, agende electronice de contacte, editarea foilor de calcul tabelar, receptor radio sau redarea fisierelor multimedia, si chiar Global Positioning System (GPS).5 Read Only Memory – Memorie cu access doar pentru citire

Page 86: licenta hatz

simultan înseamnă că atunci când unul din procese este blocat așteptând ca o operație de I/E sa se termine, alt proces poate utiliza procesorul. Deci multiprogramarea creste gradul de utilizare al procesorului. Dacă în trecut numai serverele de reţea aveau întotdeauna capacitatea de a rula mai multe procese în același timp pentru mai mulți clienți, în zilele noastre PC-urile personale au această capacitate.

Cea mai simplă modalitate de a face multiprogramarea este de a diviza memoria în N partiții posibil inegale ca dimensiune, iar aceste partiţii pot fi făcute manual la pornirea sistemului de operare. Când un proces trebuie executat, va fi pus în coada de intrare a celei mai mici partiţii care este suficient de mare pentru a-l cuprinde. Deoarece partiţiile sunt fixe, orice spaţiu care nu este folosit de un proces, va fi pierdut.

Dezavantajul sortării proceselor apare când o coada pentru o partiţie mare este goală şi o coadă pentru o partiţie mică este plină (exemplu partiţiile 1 şi 3 din figura de mai jos).

Figura 3. 4 Partiţii fixe ale memoriei cu cozi separate pentru fiecare partiţie / Partiţii fixe ale memoriei cu o singură coadă de intrare

Aici procese mici trebuie să aştepte pentru a fi încărcate în memorie, deși este suficientă memorie liberă, alternativa ar fi să fie organizate într-o singură coadă de aşteptare. Deoarece când o partiţie devine liberă, procesul cel mai apropiat de începutul cozii care încape în partiţia respectivă va fi încărcat şi rulat în spațiul liber creat. Deoarece este de preferat sa nu se piardă o partiţie mare pentru un proces mic, deci o strategie ar fi atunci când se eliberează o partiţie să se caute prin toată coada de intrare cel mai mare proces care se potriveşte. Însă acest algoritm dezavantajează procesele mici care se consideră că nu merită o partiţie pentru ele, în condițiile în care este de preferat să se ofere proceselor mici cea mai buna servire, nu cea mai proastă. Soluţia ar reprezenta-o alocarea unei partiţii mici pentru rularea acestor procese, sau o altă soluţie ar fi o regulă care să nu permită ca un proces să fie sărit mai mult de k ori.

Acest sistem cu partiţii fixe alese de operator dimineața şi care nu se mai schimbă, a fost mulţi ani de OS/260. Pe marile sisteme de calcul IBM, şi se numeau MFT8, însă în prezent acest model nu mai este implementat decat de foarte puţine sisteme de operare (Exemplu: mainframe-uri).

În funcție de echipamentul folosit există două strategii de gestiune a memoriei: interschimbare (swapping) – aducerea unui proces în memorie, execuția sa pentru un timp, apoi trecerea lui înapoi pe disc şi memorie virtuală – permite programelor să ruleze chiar dacă nu sunt încărcate complet în memorie.

Figura 3. 5 Alocarea memoriei se schimba pe măsură ce procesele vin şi pleacă din memorieObservaţie: Regiunile haşurate reprezintă memoria nefolosită.

Page 87: licenta hatz

8 Multiprogramming with a fixed number of Tasks- Multiprogramare cu un număr fix de sarcini

Page 88: licenta hatz

Figura 3. 6 Gestiunea memoriei cu hărţi de biţi

Figura 3. 7 Gestiunea memoriei cu liste înlănţuite

Atunci când procesele şi spaţiile libere sunt păstrate într-o listă sortate după adresa, există algoritmi care pot fi folosiţi pentru alocarea de memorie pentru un nou proces (sau un proces care este adus de pe disc în memorie)

Algoritmul prima potrivire – gestionarul de memorie caută în lista de segmente un spaţiu suficient de mare liber, îl sparge în două: o parte pentru proces şi cealaltă parte rămâne liberă, este rapid deoarece caută cât mai puţin posibil.

Algoritmul următoarea potrivire – funcționează ca şi algoritmul prima potrivire, dar în plus memorează poziția unde a găsit spaţiul, la următoarea căutare nu mai parcurge lista încă o data, este mai lent decât prima potrivire conform simulărilor lui Bays din 1977.

Algoritmul cea mai bună potrivire - caută în toată lista şi alege spațiul liber cel mai mic care este potrivit, este mai lent decât prima potrivire deoarece trebuie să caută în toată lista.

Algoritmul cea mai proastă potrivire - alege spaţiul cel mai mare astfel încât spațiul rămas să fie suficient de mare să fie util, simulările au arătat că nu este cea mai bună soluţie.

Toţi 4 algoritmii pot fi îmbunătăţiţi prin păstrarea a doua liste separate una pentru spaţii şi una pentru procese. Insă preţul plătit pentru viteza este complexitatea suplimentară şi încetinirea dealocării memoriei.

Algoritmul potrivirea rapidă - ţine liste separate pentru cele mai uzuale dimensiuni cerute. Memoria virtuală - cele mai multe sisteme de memorie virtuală folosesc o tehnică numită paginare.

Figura 3. 8 Poziția şi funcția MMU9 , după cum se vede este parte a cipului procesorului.Algoritmi de înlocuire a paginilor apar atunci când eroarea din pagina ne indică:

Ce pagină trebuie să înlocuim

9 Memory Management Unit – Unitatea de gestiune a memoriei

Page 89: licenta hatz

Să facem loc paginii ce urmeazăModificarea paginii trebuie prima dată salvată Nemodificările sunt rescriseEste bine să alegem să utilizăm o pagină care nu este deja deschisă Va fi nevoie să o aducem înapoi curând.

Dispozitive de Intrare / Ieşire:

Device-urile de Intrare: sunt cele utilizate pentru a converti datele de intrare „nonsens„ ale utilizatorilor în cod intern pe care calculatorul le înțelege, utilizează şi stochează ca şi cod ASCII

Device-urile Ieşire: sunt utilizate pentru a decoda rezultatele după ce sunt procesate de calculator în ieșiri. Vitezele de transfer a componentelor de I/O:

Device Date rateKeyboard 10 bytes/secMouse 100 bytes/sec56K modem 7 KB/secTelephone Channel 8 KB/secDual ISDN lines 16 KB/secLaser printer 100 KB/secScanner 400 KB/secClassic Ethernet 1.25 MB/secUSB ( Universal Serial Bus) 1.5 MB/secUSB 2.0 480MB/secUSB 3.0 4800MB/secDigital camcorder 4 MB/secIDE disk 5 MB/sec40x CD-ROM 6 MB/secFast Ethernet 12.5 Mb/secISA Bus 16.7 MB/secEIDE (ATA-2) disk 16.7 MB/secFireWire (IEEE 1394) 50 MB/sec - 800MB/secXGA Monitor 60 MB/secSONET OC-12 network 78 MB/secSCSI Ultra 2 disk 80 MB/secGigabit Ethernet 125 MB/secUltrium tape 320 Mb/secPCI bus 528 Mb/secSun Gigaplane XB

Backplane 20 GB/sec

Page 90: licenta hatz

Tabel 3. 1 Rate de transfer pe componente de I/O

Page 91: licenta hatz

1.6 RAID - Redundant Array of Inexpensive Disks

RAID combină hard discuri fizice într-o singură unitate logică folosind o componentă hardware sau o aplicaţie software. Soluţiile hardware sunt proiectate cu scopul de a se prezenta sistemului ataşat ca un singur hard disc, fără ca sistemul de operare să cunoască arhitectura fizică.

Soluţiile software sunt implementate în sistemul de operare, dar aplicaţiile vor utiliza arhitectura RAID ca o singură unitate.

Sunt trei tipuri principale în RAID: mirroring (oglindirea), copierea datelor pe mai multe discuri; striping(întreţesute), împărţirea datelor pe mai multe discuri; şi error correction (cu corectarea erorilor) unde discuri de verificare redundante stochează datele pentru a fi detectate şi corectate eventualele erori. Diferitele niveluri RAID folosesc unul sau mai multe dintre tipurile enumerate mai sus, în funcţie de cerinţele sistemului. Scopul principal în folosirea arhitecturii RAID este mărirea siguranţei datelor, important pentru protejarea informaţiilor critice pentru afaceri, de exemplu o bază de date a comenzilor date de clienţi; sau a măririi vitezei, de exemplu un sistem care transmite programe TV „la cerere” mai multor telespectatori.

Diferitele configuraţii afectează stabilitatea şi performanţa în mod diferit. Problema folosirii mai multor discuri este creşterea probabilităţi ca unul dintre ele să se strice, dar folosind funcţii de verificare a erorilor întreg sistemul poate fi mai stabil şi capabil de a supravieţui şi repara eventualele erori. Oglindirea simplă poate creşte viteza la citire deoarece sistemul poate accesa date diferite de pe cele două discuri, dar va fi mai încet la scriere dacă sistemul insistă ca ambele discuri să confirme corectitudinea datelor scrise. Formatul întreţesut este îndeosebi folosit pentru mărirea performanţei, deoarece permite citirea secvenţelor de date de pe mai multe discuri simultan. Verificarea erorilor în mod obişnuit va încetini sistemul deoarece datele vor fi citite din mai multe locaţii şi apoi comparate. De aceea în arhitectura RAID un compromis şi o înţelegere a necesităţilor sistemului este importantă. Ariile de disc moderne furnizează în general facilităţi de selecţie al configuraţiilor RAID apropiate.

Sistemele RAID pot fi concepute să ruleze chiar şi în caz de cădere – discurile pot fi schimbate „la cald” şi datele recuperate automat în timp ce sistemul rulează în continuare. Alte sisteme trebuie oprite până când datele sunt recuperate. RAID este adeseori folosit la sistemele cu accesibilitate ridicată, unde este important ca sistemul să ruleze cât mai mult cu putinţă.

RAID este în general folosit la servere dar poate fi folosit şi în cazul staţiilor de lucru. Cel din urmă folosit în general la computerele cu stocare intensivă ca cele folosite la editări video şi audio.

RAID 0

cea mai performantă metodă de stocare RAID;

se însumează capacităţile discurilor.Avantajul este dat de distribuţia operaţiilor de scriere/citire pe mai multe discuri, simultan;

performanta crecută a matricii;lipsa redundanţei, defectarea oricărui disc ducând la compromiterea întregii matrice.

Figura 3. 9 RAID 0RAID 1

este oglindirea dispozitivelor (mirroring);dacă se folosesc două discuri în RAID1 informația va fi stocată pe ambele, în oglindă;

Figura 3. 10 RAID 1

Page 92: licenta hatz

RAID 3oricare din ele poate ceda, fără să afecteze integritatea matricei;Performanţa este afectată, deoarece scrierea/citirea se face simultan;spaţiul de stocare este de jumătate; număr par de discuri.

Figura 3. 11 RAID 3RAID 5redundanţă de nivel N+1;viabil de la mai mult de 3 discuri/partiţii

într-o matrice;scrierea informaţiilor de paritate se face

pe toate discurile,pentru un număr mare de discuri este cea

mai eficientă metodă;

Figura 3. 12 RAID 5capacitate de stocare este data de(capacitatea unui disc)*(numărul de

discuri -1).

RAID RAIDRAID RAID 0 RAID 1 RAID 5 RAID 6 10 50 RAID 60

Nr minim de2 2 3 4 4 6 8HDD

de la un de la undisk disc de la douacăzut în căzut în discuri căzute

Protecția un hdd fiecare fiecare în fiecare sub-Datelor NU căzut un hdd căzut două hdd căzute sub-şir sub-şir şir

PerformantaRidicată Ridicată Ridicată Ridicată Ridicată Ridicată RidicatăCitire

PerformantaRidicată Medie Scăzută Scăzută Mediu Mediu MediuScriere

PerformantaCitire

N/A Medie Scăzută Scăzută Ridicată Mediu Mediu(degradata)

Page 93: licenta hatz

RAID RAIDRAID RAID 0 RAID 1 RAID 5 RAID 6 10 50 RAID 60

PerformantaScriere

N/A Ridicată Scăzută scăzută Ridicată Mediu Scăzută(degradata)

Capacitatea 67%-de utilizare 100% 50% 67% - 94% 50% - 88% 50% 94% 50% - 88%

Staţii delucru, arhive DB, BD arhive DB,loguri de backup pe disc, mari, backup pedate, soluţii de Servere disc, soluţii deredarea în Sisteme disponibilitate BD de disponibilitatetimp real, de foarte mare, rapide, fişiere, foarte mare,date operare, Depozite BD, servere cu servere servere servere cufoarte tranzacții servicii web, cerințe mari de de de cerinţe mari

Aplicaţii tranzitorii în DB arhivari capacitate aplicaţii aplicaţii de capacitate

1.7 Securitatea sistemelor de operare

Tehnologiile de securitate ale calculatorului sunt bazate pe logică. Deoarece cele mai multe cereri ale calculatorului nu sunt legate de securitate, proiectarea unui program cu siguranţă inclusa adesea impune restricţii asupra comportamentului acest program. Există mai multe abordări pentru a lua în calcul securitatea, uneori, o combinaţie de abordări este valabilă:

Încredere ca software-ul să respecte o politică de securitate, dar software-ul nu este de încredere.Încredere în toate software-ul să respecte o politică de securitate şi software-ul este validat ca de încredere.

(prin filiala tedious şi analiză calea de exemplu).Încrederea software-ul, dar nu pune în aplicare o politică de securitate, cu mecanisme care nu sunt de

încredere (din nou acest lucru este nesiguranţă calculator).Încrederea software-ul, dar nu pune în aplicare o politică de securitate, cu mecanisme de încredere.Multe sisteme au avut ca rezultat în mod neintenţionat în prima posibilitate. Din moment ce abordare doi

este costisitoare şi non-determinist, utilizarea sa este foarte limitată. Abordările unu şi trei duc la eşec. Deoarece numărul de abordare patru este adesea bazat pe mecanisme de hardware şi evită o multitudine de grade de libertate, este mai practic. Combinaţiile de abordări două şi patru sunt adesea folosite într-o arhitectură stratificată cu straturi subţiri de două şi straturi groase de patru.

Există diverse strategii şi tehnici utilizate pentru proiectarea sistemelor de securitate. Strategiile de toate acestea, există puţine, dacă este cazul, eficiente pentru a spori securitatea, după proiectare. O tehnică impune principiul de cel privilegiul de a mare măsură, în cazul în care o entitate are doar privilegiile de care sunt necesare pentru funcţia sa. În acest fel, chiar dacă câştigurile de un atacator acces la o parte a sistemului, amenda-bob de securitate asigură că acesta este la fel de dificil pentru ei pentru a accesa restul.

În plus, prin ruperea de sistemul de până în componente mai mici, complexitatea componentele individuale este redus, deschide posibilitatea de a folosi tehnici, cum ar fi teorema automate dovedesc a dovedi corectitudinea subsistemelor software de o importanţă crucială. Acest lucru permite o soluţie închis formular pentru securitate care funcţionează bine atunci când doar un singur bine caracterizat de proprietate poate fi izolat ca fiind esenţiale, şi că proprietatea este, de asemenea assessible la matematica. Deloc surprinzător, nu este practic pentru corectitudinea generalizate, care, probabil, nu poate fi nici măcar definite, mult mai puţin dovedite. În cazul în care dovezile corectitudinea formală nu sunt posibile, utilizarea riguroasă a revizuirii cod şi de testare unitate reprezintă cel mai bine o abordare efort pentru a face module în deplină siguranță.

Design-ar trebui să utilizeze tehnica „de apărare în profunzime”, în cazul în care mai mult de un subsistem trebuie să fie încălcate de a compromite integritatea sistemului şi informaţiile pe care le deţine. Apărării în profunzime funcţionează atunci când încălcarea de o măsură de securitate nu oferă o platformă pentru a facilita păcălirea altul. De asemenea, principiul cascadă recunoaşte că mai multe obstacole de scăzut, care nu face un obstacol mare. Deci, în cascada de mai multe mecanisme de slab, nu oferă siguranţa unui singur mecanism mai puternic.

Subsistemele trebuie să funcţioneze implicit pentru a asigura setările, şi ori de câte ori este posibil ar trebui să fie concepute pentru că „nu reuşesc sigure”, mai degrabă decât „nu reuşesc nesigure” (a se vedea nu reuşesc în

Page 94: licenta hatz

condiţii de siguranţă pentru echivalentul în inginerie de siguranţă). În mod ideal, un sistem sigur ar trebui să solicite o deliberată, decizie conştientă, cunoştinţe şi gratuit din partea autorităţilor legitime în scopul de a face nesigure.

În plus, securitatea nu ar trebui să fie o problemă de totul sau nimic. Designerii şi operatorii de sisteme ar trebui să presupună că încălcările de securitate sunt inevitabile. Pistele de audit completa ar trebui să fie păstrate de activitate de sistem, astfel încât atunci când se produce o încălcare a securităţii, mecanismul şi gradul de încălcare poate fi determinată. Stocarea pistele de audit de la distanţă, în cazul în care acestea pot fi doar anexate, se poate păstra intruşi de la care să acopere urmele lor. În cele din urmă, dezvăluirea completă ajută să se asigure că, atunci când sunt găsite bug-uri la fereastra „de vulnerabilitate” este menţinută cât mai scurt posibil.

1.7.1 Tipuri de atac

4.3.2. Atacuri DOS

Atacurile de tip Denial of Service10 sunt o cauză majoră de operare defectuoasă a sistemelor în Internet şi reprezintă cea mai serioasă ameninţare de astăzi. Primul atac major a îngenunchiat reţeaua Universităţii Minnesota în august 1999, iar 6 luni mai târziu un tânăr canadian a atacat unele dintre cele mai importante site-uri Internet: Yahoo, CNN, Amazon, Buy şi eBay. De atunci atacurile par să fie în creştere.

Din nefericire, utilizatorii sunt mai interesaţi de software-ul cu mai multe facilităţi decât de cel robust, fără erori. În plus, securitatea are preţul său. Software-ul modern cheltuieşte un număr imens de cicluri maşină pentru a desena ferestre tri-dimensionale cu alpha-blending sau alte asemenea îmbunătăţiri vizuale, dar aceste lucruri nu aduc nimic din punct de vedere al funcţionalităţii. Deşi securitatea este o problemă majoră, mulţi utilizatori nu se arată dispuşi să cheltuiască o putere de calcul similară pentru securitate. De asemenea, multor utilizatori nu le pasă dacă sistemul lor este sigur sau poate fi utilizat ca ţintă sau rampă de lansare a unor atacuri de diferite feluri.

Falsul sentiment de securitate este probabil mai rău decât lipsa totală a securităţii. Încă există suficient de mulţi administratori care lasă sistemele lor neprotejate, neaplicând ultimele patch-uri şi neconformându-se procedurilor de bună practică adoptate de fiecare organizaţie. Dacă avem în vedere faptul că numărul de locuinţe, şcoli, biblioteci şi alte locuri publice conectate la Internet a crescut exponenţial în ultima vreme, dimensiunea problemei apare în toată măreţia sa.

Ameninţările de securitate se pot categorisi, după cum urmează:Scurgeri de informaţii (confidenţialitate) Autentificări nereuşite

Denial of Service (DOS)În timp ce primele două atacuri au fost analizate extensiv în literatura de specialitate, atacurile DOS nu au

primit atenţia cuvenită până de curând.Un atac Denial of Service poate lua una din cele două forme posibile. Un atacator poate cauza

netransmiterea de către reţea a mesajelor pe care ar trebui să le transmită în mod normal clienţilor săi. De cealaltă parte se află reţelele care trimit mesaje pe care nu ar trebui să le trimită. De departe cel mai cunoscut atac DOS este cauzarea de trafic fals (inundarea reţelei) în direcţia un server particular, lucru care în final va duce la împiedicarea clienţilor legitimi să obţină serviciul pe care îl cer de la acel server.

Comunitatea Internet cunoaşte o serie întreagă de atacuri DOS, care se pot împărţi în două categorii: atacuri prin inundare (flooding) şi atacuri prin pachete modificate.

O cauză evidentă a atacurilor TCP SYN este că dialogul iniţial între părţi are loc înaintea unei minime autentificări. Serverul este incapabil de a distinge traficul legitim de cel fals, fapt ce are toate şansele să rămână aşa. Impunerea necesităţii de a autentifica toate cererile ar însemna un atac DOS în sine, din moment ce serverul ar fi ocupat cu verificarea semnăturilor digital, indiferent dacă acestea sunt sau nu valide. Această nouă cale de atac ar fi la fel de periculoasă ca şi simpla umplere a tabelei TCP.

O cauză mai puţin cunoscută a atacurilor DOS este contabilizarea resurselor, mai precis lipsa acestora. Spatscheck şi Peterson [SPAT99] consideră că sunt trei ingrediente cheie pentru protejarea de atacuri DOS:

contabilizarea tuturor resurselor consumate de un client;detecţia momentului când resursele alocate unui client depăşesc un prag stabilit apriori;constrângerea – capacitatea de a revendica resursele blocate după detectarea unui atac prin alocarea de

resurse minime unui atacator, lucru ce înseamnă automat evitarea unui atac DOS ulterior;

10Termenul se traduce aproximativ prin „interzicerea serviciului”, dar am ales să folosim aici terminologia originală din limba engleză deoarece este un termen de referinţă în articolele de specialitate

Page 95: licenta hatz

În perioada când Internetul însuşi era proiectat, contabilizarea resurselor era scopul cu prioritatea cea mai mică, lucru ce ne afectează astăzi cel mai mult. În contrast cu reţelele de telefonie omniprezente unde folosirea resurselor era atent controlată, cei care au proiectat reţeaua Internet nu au părut să acorde importanţă acestui aspect. Astfel, serverele alocă aceeaşi putere de calcul tuturor cererilor care sosesc la un moment dat ceea ce împiedică o degradare elegantă a performanţei în cazul unui atac sau în cazul unei încărcări excesive.

Scenariul anterior este oarecum similar cu mecanismul rudimentar de procesare a pachetelor de intrare datorită arhitecturii bazate pe întreruperi a subsistemului de reţea. Toate sistemele de operare implementează acest tip de arhitectură care s-a dovedit neadecvat în condiţii de încărcare mare. Pachetele de la intrare sunt procesate cu prioritatea maximă pentru ca apoi să fie distruse pentru că nu există nici o aplicaţie care să le deservească. Această situaţie se numeşte receiver livelock. Mai mult, chiar dacă există o aplicaţie care să deservească aceste pachete, prioritatea procesului nu este luată în calcul. Astfel, aplicaţiile cu prioritate mică primesc aceeaşi cantitate de trafic ca cele cu prioritate mai mare. În lucrarea lor, Druschel şi Banga propun o arhitectură cu de procesare întârziată care se bazează pe demultiplexarea timpurie a pachetelor şi procesarea cu prioritatea destinatarului. Ei susţin că noua arhitectură ar îmbunătăţi stabilitatea, justeţea şi capacitatea sistemelor în condiţii de încărcare mare în timp ce performanţa nu ar avea de suferit în condiţii normale. O noua clasă de atacuri de bandă îngustă exploatează deficienţele structurilor de date în diferite aplicaţii. Structurile de date folosite în mod uzual au un timp de rulare în cazul mediu mult mai bun decât în cazul cel mai defavorabil.

Spre exemplu, atât tabelele de dispersie cât şi arborii binari degenerează în liste înlănţuite atunci când la intrare se prezintă date alese corespunzător. Folosind banda tipică a unui modem, autorii citaţi au adus un server Bro în pragul colapsului; în şase minute de la începutul atacului, serverul ignora 71% din trafic şi consuma întreaga putere de calcul disponibilă.

Având în vedere tendinţa globală a pieţelor de a se muta on-line, atacurile DOS se dovedesc mult mai periculoase decât s-a prevăzut la început întrucât acestea pot bloca victimele pe durate lungi de timp. De la momentul la care a început atacul şi până când acesta este detectat şi eliminat, victima este paralizată şi nu poate răspunde la cererile legitime. Pentru site-urile comerciale mari aceasta se traduce prin pierderi de ordinul miliardelor de dolari.

Deşi atacurile DOS nu ameninţă datele în mod direct, nu avem nici un motiv să credem că un altfel de atac nu ar putea uram cu exact acest scop. Aceste atacuri de urmare pot distruge date critice, cauzând astfel mai multe daune decât atacul DOS în sine, ceea ce nu este de dorit.

Acest fel de atacuri în lanţ pot avea loc dacă protocoalele continuă dialogul cu atacatorul chiar şi după detectarea unor anomalii în dialogul purtat între părţi. Ideea de bază în spatele protocoalelor rezistente (numite protocoale fail-stop sau fail-safe) este că schimbul de mesaje să înceteze cu orice client care nu urmează cursul firesc al protocolului.

Atacuri asupra protocoalelor de autentificare

Atacuri prin inundare (flooding)Atacurile prin inundare sunt comune şi sunt lansate cu intenţia de a satura legăturile de reţea pentru a prăbuşi

router-ele şi switch-urile sau inundarea cu trafic peste posibilităţile de prelucrare. Din nefericire, uneltele necesare pentru un asemenea atac sunt disponibile pe Internet şi chiar utilizatorii fără experienţă le pot folosi cu succes.

Smurf FloodSmurf Flood este un atac DOS cunoscut şi sub numele de reflector. Un atacator trimite un număr mic de

pachete echo ICMP la o adresă de broadcast care defineşte mai multe gazde. Răspunsurile tuturor acelor gazde sunt trimise simultan către victimă, epuizând toată banda de comunicaţie şi posibil puterea de calcul.

TCP SYNAtacul de tip TCP SYN este posibil datorită schimbului de mesaje de la începutul protocolului TCP. Un

client trimite o cerere (SYN) către un server, anunţându-şi intenţia de a porni o conversaţie. La rândul său, serverul desemnează o intrare în tabela cu conexiuni pe jumătate deschise şi trimite înapoi un mesaj de încuviinţare (SYNACK), semnalizând astfel disponibilitatea sa. În acest moment clientul trebuie să răspundă cu un pachet SYN ACK ACK pentru a putea începe comunicaţia de fapt. Un atacator ar putea să nu trimită niciodată această confirmare, cauzând umplerea tabelei de conexiuni, cererile legitime ulterioare fiind astfel blocate. Daca un atacator trimite o rafală de astfel de cereri, acesta poate paraliza activitatea unui server de 100 MIPS care poate deservi 2000 de conexiuni pe secundă [SPAT99], dimensiunea tipică a tabelei TCP fiind de 2048 de intrări [DEC96].

UDP Flood (Fraggle)

Page 96: licenta hatz

Acest atac este posibil datorită naturii protocolului UDP care nu este orientat pe conexiune. Din moment ce nu este necesar nici un dialog în prealabil, un atacator poate trimite pachete către porturi aleatoare ale sistemului vizat. Victima va aloca resurse pentru determinarea aplicaţiilor care ascultă porturile pe care sosesc date, iar când îşi dă seama că nici o aplicaţie nu face acest lucru, va trimite ca răspuns un pachet ICMP. Dacă numărul de pachete aleatoare este suficient de mare, există posibilitatea ca sistemul să aibă probleme.

ICMP FloodAcest atac constă din trimiterea unui număr mare de pachete ICMP către victimă. Aceasta nu poate ţine

pasul cu volumul de informaţie primit şi poate observa o degradare a performanţei.

E-mail bombing„E-mail bombing” înseamnă trimiterea unui număr mare de mesaje electronice către un server cu scopul de

a epuiza spaţiul de pe disc şi lăţimea de bandă.Cu excepţia atacului UDP, restul se pot evita prin măsuri luate la nivelul sistemului de operare. Atacul UDP

este dificil de contracarat întrucât există o multitudinede aplicaţii care ascultă la o multitudine de porturi. Filtrarea cu ajutorul firewall-urilor ar avea un impact

puternic asupra funcţionalităţii iar acest preţ nu îl vor plăti foarte mulţi utilizatori.

Atacuri prin pachete modificate

Atacul prin pachete modificate este un alt fel de atac DOS răspândit. Scopul acestui tip de atac este exploatare greşelilor de proiectare a codului care prelucrează pachete din diferite sisteme de operare. Efectele merg de la degradarea performanţei până la căderea sistemului.

Aproximativ jumătate din totalul problemelor pe Internet au ca şi cauză depăşirile de buffer. Acestea se cunosc de mai bine de 40 de ani şi cam din aceeaşi perioadă datează şi soluţia. Limbajul Algol a introdus limitele obligatorii la tablouri dar programatorii încă refuză să folosească instrumente mai bune. Acest lucru este comparabil cu un fabricant de maşini care înzestrează maşinile cu rezervor din hârtie cerată [DEWA01].

Principalele atacuri cu pachete modificate sunt:Ping of DeathAcest atac constă în trimiterea unui pachet ICMP mult mai mare decât pachetul maxim IP, şi anume 64

KBytes. La destinaţie, unele implementări nu pot decodifica pachetul, cauzând prăbuşirea sau reboot-ul sistemului. Două implementări binecunoscute care au acest comportament sunt Windows 95 şi unele versiuni timpurii deWindows NT.

ChargenAcest atac este o variantă a atacului de tip UDP Flood şi foloseşte portul 19 (chargen) al unui sistem

intermediar folosit ca amplificator. Atacatorul trimite un pachet UDP fals către un sistem intermediar care la rândul său răspunde cu un şir de caractere victimei, pe portul său echo. Victima trimite înapoi un ecou al şirului primit şi bucla creată consumă rapid banda dintre victimă şi sistemul intermediar.

TeardropDatorită implementării defectuoase, unele sisteme nu pot asambla fragmente de pachete care au deplasamente

eronate. În loc să ignore elegant aceste pachete, aceste implementări blochează sau reboot-ează sistemul.LandDeşi este greu de crezut, unele sisteme se blochează când primesc pachete având aceeaşi adresa ca sursă şi

destinaţie.WinNukeAcest tip de atac este specific sistemelor de operare Windows. Atacatorul trimite date aleatoare la un port

anume, ceea ce cauzează blocarea sau reboot-ul sistemului.O altă clasificare a atacurilor DOS este după numărul de participanţi: Atacuri uni-sursă: un singur atacator are ca ţintă o singură victimă.Atacuri multi-sursă: mai multe gazde (numite „zombie”) participă fără să ştie în rolul atacatorilor, fiind

compromise de capul operaţiunii. Deşi mai greu de pus în practică, acest tip de atac este şi cel mai periculos şi cel mai greu de luptat împotriva lui. Mai este cunoscut şi sub numele de atac Distributed Denial of Service (DDOS).

[RAZM00] dă un echivalent al atacului DOS în lumea reală: Alice nu îl place pe Bob şi în consecinţă telefonează mai multor companii de pizza, comandând câte o pizza de la fiecare şi cerând ca acestea să fie trimise la domiciliul lui Bob la o oră anume. Când timpul soseşte, Bob este copleşit de mulţimea de distribuitori de pizza care ajung la domiciliul său, fiecare pretinzând banii cuveniţi. Simplu şi eficient, acest atac poate să rămână cu autor necunoscut dacă Alice a sunat de la un telefon public (în esenţă ascunzându-şi identitatea).

Page 97: licenta hatz
Page 98: licenta hatz

2 Ştefan Ioan Niţchi

1. BAZE DE DATE - CONCEPTEFUNDAMENTALE

1.1. DEFINIŢIA ŞI CLASIFICAREA BAZELOR DEDATE. BAZE DE DATE RELAŢIONALE

1.1.1. Conceptul de bază de date

La baza prelucrării datelor stau fişierele. Odată cu dezvoltarea informaticii, numărul acestora a crescut, ajungându-se ca într-o firmă să existe mai multe zeci sau sute de fişiere permanente şi temporare legate de gestiunea personalului, materialelor, producţiei, vânzărilor etc. Această creştere a avut o serie de dezavantaje, dintre care amintim:

redundanţa – este proprietatea unei informaţii de a se repeta nejustificat; de exemplu codul materialelor, care poate ajunge la 20-30 de cifre, se repetă în majoritatea acestor fişiere, mărind nejustificat spaţiul fizic ocupat;inconsistenţa – este legată de apariţia distorsionată a unor informaţii în diferite contexte; una dintre cauzele inconsistenţei este redundanţa, deoarece este suficient ca la o apariţie (copie) a informaţiei redundante, aceasta să fie introdusă greşit şi informaţia poate deveni inconsistentă;validarea datelor – este clar că diferite aplicaţii care gestionează fişiere disparate pot valida datele diferit; nevalidarea uniformă a datelor poate duce la compromiterea întregului sistem de fişiere;disponibilitatea şi securitatea datelor – reprezintă o problemă de asemenea foarte spinoasă. Datele aflându-se în fişiere disparate, acestea pot fi reţinute de proprietari, nefiind disponibile şi comunităţii utilizatorilor. De asemenea, neexistând un control centralizat asupra lor, nu se poate asigura securitatea acestora.

Pornind de la toate acestea şi multe altele, cum ar fi dezvoltarea tehnicii de calcul, s-a ajuns la ideea bazelor de date.

O primă definiţie a bazelor de date este [Niţchi&Racoviţan04]: baza de date este un sistem integrat, coerent şi partajat de fişiere. Integrat - înseamnă că baza de date poate fi gândită ca o unificare a mai multor fişiere distincte de date, unde fiecare utilizator are viziunea sa proprie asupra datelor. Partajat - înseamnă că părţi distincte din baza de date pot fi folosite de către mai mulţi utilizatori. Coerent – înseamnă că se asigură caracterul neredundant şi coerent al datelor.

Page 99: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 3

Page 100: licenta hatz

O definiţie mai plastică, întâlnită în literatura franceză de largă circulaţie, este: baza de date reprezintă revenirea la un nivel superior de la registrul unic al micului burghez.

Una dintre caracteristicile de bază ale organizării datelor în baze de date constă în posibilitatea folosirii în comun a datelor din baza de date de către mai mulţi utilizatori.

Pentru a asigura folosirea în comun a aceloraşi date de către mai mulţi utilizatori era necesară asigurarea independenţei aplicaţiilor faţă de structura logică a datelor. Astfel, în cazul fişierelor clasice, orice modificare în structura datelor efectuată pentru a asigura de exemplu cerinţele unui nou utilizator, putea atrage după sine modificări ale tuturor aplicaţiilor care exploatau structura de date respectivă.

Din acest motiv, era necesară desprinderea din cadrul programelor de aplicaţie a descrierii structurii datelor. Acest lucru a fost posibil prin definirea unui fişier de descriere globală a bazei de date, denumit dicţionar de date. Extragerea şi modificarea datelor, adică lucrul cu fişierele de date, se derulează exclusiv prin intermediul dicţionarului de date, considerat şi ca un fişier de metadate (date despre date), care conţine informaţii privind structura datelor, restricţiile aferente acestora şi chiar relaţii între date.

Bazele de date au apărut în anii ’60, odată cu lansarea programului Apollo, în 1964, pornind de la ceea ce formau sistemele de fişiere înlănţuite, introduse de IBM pentru gestionarea lansării şi urmăririi producţiei. Astfel au apărut aşa zisele baze de date arborescente sau de generaţia 1-a.

Conceptul de bază de date, sub această denumire, a apărut pentru prima dată în anul 1969, an în care CODASYL a publicat, în cadrul unei conferinţe dedicate limbajelor de gestiune a datelor, un raport tehnic despre acest concept. Faţă de modelul bazat pe fişiere clasice (file-based), noul model de organizare a datelor în baze de date include un fişier de descriere globală a bazei de date (dicţionar de date) care să poată asigura independenţa programelor faţă de structura datelor.

Pornind de la aceste considerente, se pot da şi alte definiţii bazelor de date, cum ar fi [Fotache01]: O bază de date reprezintă o colecţie de date, organizate într-o structură descrisă printr-un model conceptual sau colecţie de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre ele.

Principala caracteristică a aplicaţiilor cu baze de date constă în faptul că accentul este pus pe operaţiile de memorare şi regăsire efectuate asupra unui volum mare

Page 101: licenta hatz

4 Ştefan Ioan Niţchi

de date şi mai puţin pe operaţiile de prelucrare a acestora. Mai mult, în sistemele client-server sau multi-etajate, operaţiile de prelucrare sunt complet rupte de cele de gestiune a datelor. După cum este normal, operaţia cel mai frecvent întâlnită în exploatarea bazelor de date este aceea de regăsire a datelor sau de interogare, în scopul obţinerii unor informaţii utile.

Totalitatea informaţiilor stocate în baza de date la un moment dat reprezintă conţinutul (denumit şi extensia) bazei de date. Conţinutul are un caracter volatil, în sensul că se modifică permanent în funcţie de volumul şi complexitatea proceselor şi fenomenelor economice la care se referă. Structura datelor împreună cu legăturile dintre entităţi şi restricţiile de integritate formează schema (denumită şi intensia) bazei de date, care, de obicei, rămâne constantă pe durata utilizării bazei de date.

Gestionarea datelor dintr-o bază de date este asigurată de un sistem de gestiune a bazelor de date sau SGBD (în limba engleză DBMS - Data Base Management System).

Un SGBD reprezintă un ansamblu de programe pentru gestiunea datelor sau un mediu de programare destinat gestiunii datelor din baza de date. Prin urmare, el este cel care asigură încărcarea bazei de date, actualizarea şi interogarea acesteia, cât şi interfaţa cu sistemul de operare în vederea simplificării accesului la date.

In general, SGBD-urile au implementate limbaje gazdă, care conţin atât instrucţiuni specifice exploatării datelor din bazele de date, cât şi unele instrucţiuni din limbajele de programare clasice.

Un SGBD include, în general, o serie de componente [Date05] grupate în jurul dicţionarului de date, dintre care amintim:

sistemul de gestiune a fişierelor şi suporturilor la nivel fizic, care se ocupă cu afectarea spaţiilor de memorie pe disc, structurile fizice de date şi gestionarea acestora la nivelul fizic;sistemul de gestiune a fişierelor la nivel logic, care face legătura dintre datele fizice şi structurile bazei de date;limbajul de manipulare a datelor (LMD) şi translatorul aferent; limbajul de descriere a datelor (LDD) şi translatorul aferent;limbajul de consultare sau interogare (Query Language) şi procesorul aferent, care traduce instrucţiunile limbajului de consultare în instrucţiuni inteligibile pentru sistemul de gestiune la nivel logic;

componente de interfaţă cu programele de aplicaţii;

Page 102: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 5

Page 103: licenta hatz

componente de serviciu, legate de jurnalizări, securitate etc.Trebuie să specificăm, însă, că în majoritatea SGBD-urilor, cum este şi cazul xBase sau Visual FoxPro, mai multe componente, cum ar fi de exemplu cele trei limbaje şi translatoarele lor, sunt integrate, formând o singură componentă.

Principalele funcţii ale unui SGBD sunt următoarele:

Funcţia de descriere date, care permite descrierea structurii datelor şi a legăturilor dintre entităţi. Pentru a realiza această funcţie, SGBD-urile dispun de un limbaj de descriere date LDD (Data Description Language - DLL), care este specific fiecărui SGBD.Funcţia de manipulare date, care permite crearea, consultarea (interogarea) şi actualizarea bazei de date. Această funcţie se realizează prin intermediul limbajului de manipulare date LMD (Data Manipulation Language - DML), numit adesea şi limbaj de interogare. Acesta conţine un set de comenzi necesare exploatării în condiţii optime a bazei de date.Funcţia de utilizare, care permite comunicarea dintre utilizator şi baza de date prin intermediul unei interfeţe cât mai simple şi mai apropiate de utilizator(ferestre, meniuri etc.).

În încheiere, trebuie să menţionăm faptul că în limbajul curent se face de regulă confuzie între baze de date şi bănci de date. Dintre principalele diferenţe între cele două, amintim:

Bazele de date conţin informaţii directe (factuale), în timp ce băncile de date conţin informaţii referenţiale [Deitel90]. Astfel, interogând o bază de date referitor la numărul , aceasta va returna valoarea 3,14159… sau faptul că informaţia n-a fost introdusă. Adresând aceeaşi cerere unei bănci de date, aceasta va indica bibliografia care ar trebui consultată.Datele din băncile de date se memorează pe baza unor cuvinte cheie ataşate documentelor prin procesul de indexare. Relaţiile existente între cuvintele cheie se memorează într-un fişier denumit tezaur. Regăsirea informaţiilor realizându-se pe baza unor combinaţii booleene dintre cuvintele cheie, precum şi a relaţiilor existente în tezaur, apar o serie de fenomene de bruiaj, adică documente care răspund fără să trebuiască (datorită nefiltrării suficiente) sau fenomene de linişte, adică documente care nu sunt regăsite (datorită superfiltrării). Astfel de fenomene nu sunt acceptabile în domeniul bazelor de date.

Page 104: licenta hatz

Putem deci concluziona că cele două domenii sunt distincte.

Page 105: licenta hatz

6 Ştefan Ioan Niţchi1.1.2. Arhitectura unei baze de date

Intre sistemul de calcul care realizează prelucrarea datelor şi utilizatorul bazei de date, care operează cu diferite concepte mai mult sau mai puţin abstracte, se interpun mai multe nivele de abstractizare a datelor.

Asigurarea independenţei logice şi fizice a datelor impune adoptarea unei arhitecturi a bazei de date pe trei nivele astfel:

3: nivelul intern

4: nivelul conceptual

5: nivelul extern

Nivelul intern (baza de date fizică) defineşte baza de date ca fiind o colecţie de fişiere, conţinând datele din cadrul bazei de date, la care se adaugă şi alte structuri auxiliare de date şi un set de programe, care interacţionează cu sistemul de operare pentru îmbunătăţirea managementului bazei de date. La acest nivel structura bazei de date se concretizează în schema internă. Aici apare independenţa faţă de căile de acces, adică utilizatorul nu trebuie să fie preocupat de organizarea şi modul de acces la date la nivel fizic.

Nivelul conceptual este nivelul imediat superior celui fizic, datele fiind privite prin prisma semanticii lor, respectiv a conţinutului şi relaţiilor cu alte date. Acesta este şi primul nivel de abstractizare a lumii reale, având ca obiectiv principal modelarea realităţii existente prin definirea şi descrierea unităţilor logice cu care se lucrează şi a legăturilor dintre acestea. Această schemă este descrisă în general de administratorul bazei de date, el fiind singurul care cunoaşte şi manipulează schema conceptuală a bazei de date, degrevând utilizatorii de cunoaşterea întregii structuri a bazei de date.

Nivelul conceptual se defineşte cu ajutorul schemei entitate-relaţie (E-R) [Gardarin86] sau obiect-entitate-relaţie (OLE) [Miranda&Busta86].

Prin entităţi se înţeleg concepte cu care operează utilizatorii şi prin care aceştia îşi modelează aplicaţiile, cum ar fi: PRODUSE, BENEFICIARI, FACTURI (în cazul unei firme productive) sau PROFESORI, STUDENTI, SALI, MATERII (în cadrul unei facultăţi).

Fiecare entitate poate avea una sau mai multe atribute. De exemplu, un STUDENT are MATRICOLA, NUME, DATA-NAŞTERII etc.

Page 106: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 7

Page 107: licenta hatz

Prin urmare, la acest nivel baza de date se defineşte ca fiind o mulţime de entităţi (unităţi logice) rezultată din reuniunea entităţilor aferente unor categorii de utilizatori, în vederea realizării unei viziuni globale asupra bazei de date. În acest scop, entităţile sunt legate prin relaţii, care exprimă semantica organizării datelor.

La acest nivel se specifică:

ce anume poate face parte din baza de date, respectiv entităţile sau unităţile logice şi legăturile (relaţiile) dintre acestea;ce nu poate face parte din baza de date, fapt care rezultă pe baza unor constrângeri explicite asupra datelor.

Constrângerile reprezintă proprietăţi ale datelor şi se referă la restricţii privind valorile pe care le pot lua aceste date sau la restricţii privind legăturile dintre diferite entităţi. În cadrul oricărei operaţii de actualizare a datelor din baza de date sau de încărcare a acesteia cu date, se verifică aceste constrângeri, pentru a asigura integritatea bazei de date.

Trebuie precizat faptul că nivelul conceptual permite o descriere a conţinutului bazei de date şi prin urmare nu include informaţii privind modul de memorare a datelor pe suportul extern şi strategiile de acces la aceste date.

Prin nivelul conceptual se asigură independenţa fizică a datelor din baza de date. In acest sens, nivelului conceptual i se ataşează o transformare prin care se defineşte modul în care structura conceptuală se transpune în structura fizică de memorare a datelor şi care reprezintă interfaţa dintre cele două nivele.

Ca urmare, orice modificare în structura de memorare a datelor sau schimbarea suportului magnetic va afecta doar interfaţa dintre nivelul conceptual şi cel fizic, fără a modifica nivelul conceptual. Rezultatul imediat al independenţei fizice a datelor îl reprezintă imunitatea aplicaţiilor faţă de structura fizică de memorare a datelor. La acest nivel structura bazei de date se concretizează în schema conceptuală.

Nivelul extern este ultimul nivel de abstractizare la care se poate descrie o bază de date. Dacă la nivelul conceptual baza de date este abordată în ansamblul ei, în practică, un utilizator sau un grup de utilizatori lucrează numai cu o porţiune specifică din baza de date, în funcţie de locul său în departamentul în care îşi desfăşoară activitatea. Astfel, de exemplu, un profesor nu are nevoie de datele complete ale unui student, cum ar fi cele legate de domiciliul permanent, data şi locul naşterii etc., ci doar de datele de identificare şi unele date legate de activitatea profesională, deci are nevoie doar de o parte din datele memorate în baza de date.

Page 108: licenta hatz

8 Ştefan Ioan Niţchi

Nivelul extern conţine, deci, o parte din unităţile logice descrise la nivel conceptual, dar poate include şi unităţi logice care nu apar la nivel conceptual şi care nu au corespondent direct în baza de date fizică, obţinute de exemplu prin calcule. Ca urmare, nivelul extern este derivat din nivelul conceptual şi reprezintă ceea ce vede utilizatorul din baza de date. Fiecărui utilizator îi va corespunde un model externpropriu, în funcţie de cerinţele informaţionale ale acestuia.

Unităţile logice folosite la nivel extern se numesc unităţi logice virtuale, imagini sau vederi şi formează o bază de date virtuală.

Aceste vederi se pot obţine în unul din următoarele moduri:

4.1. prin modificarea unor unităţi logice reale;

4.2. prin combinarea a două sau a mai multor unităţi logice reale.

Vederile asigură, printre altele, următoarele funcţii în cadrul unei baze de date:

4.1.4. securitatea bazei de date, prin limitarea accesului la datele din baza de date a anumitor categorii de utilizatori. Ca urmare, prin definirea unor vederi utilizatorii au acces la părţi bine definite din baza de date, fiindu-le ascunse acele părţi care nu trebuie să le vadă sau nu-i interesează;

4.1.5. definirea modului de acces la date; astfel, pentru unele vederi utilizatorii pot avea doar drept de consultare, iar în cazul altor vederi pot avea drept de modificare sau ştergere;

4.1.6. oferă utilizatorului o viziune simplificată şi personalizată asupra bazei de date.

Unităţile logice virtuale, sau vederile, pot fi referite în cadrul programelor de aplicaţie şi pot participa la prelucrări ca orice unitate logică din baza de date. Ca urmare, orice operaţie asupra unei vederi care modifică datele din cadrul acesteia, se va reflecta la nivelul unităţilor logice din care aceasta este derivată şi, în final, în baza de date fizică.

Prin nivelul extern se realizează independenţa logică a datelor din baza de date. Astfel, fiecărei vederi îi corespunde o descriere a datelor de la nivelul conceptual. Mecanismul independenţei logice asigură faptul că o modificare în structura conceptuală va determina modificări la nivelul interfeţei prin care se obţine vederea din schema conceptuală, dar nu va afecta vederea în sine, aşa cum este percepută de utilizator.

Page 109: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 9

Page 110: licenta hatz

Independenţa logică se referă aşadar la imunitatea modelului propriu extern şi deci a programelor de aplicaţie faţă de modificările din structura globală a bazei de date. La acest nivel structura bazei de date se reprezintă prin intermediul schemei externe sau al unor subscheme, în funcţie de cerinţele informaţionale ale unui utilizator sau grup de utilizatori.

Interfaţa dintre utilizator şi SGBD se poate realiza în mai multe moduri, dintre care amintim:

printr-un mecanism de apel (cuvânt cheie urmat eventual de parametri) inserat în programele scrise într-un limbaj tradiţional (C, COBOL etc), numit limbaj gazdă;prin comenzi speciale utilizate autonom (specifice SGBD-urilor, în afara limbajelor tradiţionale), în cazul SGBD-urilor autonome.

Observaţii:

4.3.3. în literatura de specialitate din ţara noastră, cei trei termeni au fost traduşi în mod diferit: fizic, virtual şi logic sau fizic, conceptual (global) şi logic.

4.3.4. în literatura de specialitate străină, unii autori definesc un al patrulea nivel de abstractizare, numit intermediar, situat între cel fizic şi conceptual [ Date05]. Acesta este de fapt nivelul utilizat de administratorul bazei de date pentru descrierea structurii acesteia cu ajutorul SGBD-urilor, de exemplu în VisualFoxPro sau SQL. În acest caz apar două noi independenţe, una între nivelul conceptual şi cel intermediar şi alta între cel intermediar şi cel fizic.

1.1.3. Modele de organizare a datelor

Utilitatea oricărei colecţii de date constă în obţinerea de informaţii şi depinde în mare măsură de modul de organizare şi manipulare a acestora.

Analiza, proiectarea şi implementarea structurii bazei de date se realizează utilizând un anumit model de date.

Un asemenea model reprezintă un ansamblu de instrumente conceptuale, care permit descrierea datelor,a relaţiilor dintre ele, a semanticii lor, cât şi a restricţiilor la care sunt supuse aceste date [Fotache02, Popescu02]. Un model de date reprezintă, deci, un instrument teoretic care ne ajută să identificăm semnificaţia sau conţinutul unei colecţii de date (structura de organizare a acestora) cât şi

Page 111: licenta hatz

10 Ştefan Ioan Niţchi

modul de utilizare a acestora, prin intermediul operaţiilor permise asupra datelor respective.

Modelul de organizare a datelor este deci o reprezentare a obiectelor lumii reale şi a evenimentelor asociate lor, având rolul de a pune la dispoziţia utilizatorilor conceptele de bază şi notaţiile, care să le permită acestora să comunice clar şi rapid informaţiile despre datele firmei [Dollinger98].

Ca urmare, un model de date include următoarele componente [Dollinger98]:

un set de reguli de structurare a datelor, numite şi reguli generatoare. Ele exprimă proprietăţile statice ale modelului şi sunt materializate prin limbajul de descriere a datelor (LDD). Aceste reguli includ de obicei două părţi:

partea de specificare a structurii, prin care se definesc entităţile, caracteristicile acestora şi legăturile dintre entităţi;partea de specificare a constrângerilor, care include regulile de integritate referenţială şi restricţiile utilizator.

un set de reguli de manipulare a datelor. Ele exprimă proprietăţile dinamice ale modelului şi sunt materializate în cadrul unui SGBD prin limbajul de manipulare a datelor (LMD). Limbajul de manipulare include operaţiile prin care se produc schimbări în starea bazei de date, stare reprezentată de valoarea datelor la un moment dat. Aceste schimbări pot afecta datele din baza de date, dar nu afectează structura bazei de date, deci ele conservă modelul conceptual al bazei de date.

Modelele utilizate de bazele de date se pot grupa în trei categorii [Fotache98]: modele bazate pe obiect, modele bazate pe înregistrare şi modele fizice.

Modelele bazate pe obiect permit descrierea datelor la nivel conceptual şi extern. Din această categorie fac parte:

modelele entitate-asociaţii (E-A), entitate-relaţie (E-R) sau obiect-entitate-relaţie (OLE)

modelul semantic modelul funcţional modelul orientat pe obiecte.Din categoria modelelor orientate pe înregistrări fac parte:

modelul ierarhic modelul reţea modelul relaţional.

Page 112: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 11

Page 113: licenta hatz

Această din urmă orientare a dat naştere şi clasificării bazelor de date pe generaţii [Miranda&Busta86, Gardarin86].

Astfel, prima generaţie de baze de date a fost cea bazată pe structuri arborescente, adică relaţii de tip 1:n. Dintre SGBD-urile cele mai cunoscute din domeniu amintim:IMS al IBM (utilizat şi azi), Total, System2000, Nomad etc.

A doua generaţie de baze de date a fost cea bazată pe reţele sau relaţii de tip n:m. Aceste baze de date au fost denumite şi baze de date de tip CODASYL, deoarece această organizaţie a încercat să dezvolte un standard pentru ele şi să le introducăîn standardul COBOL 81. Dintre SGBD-urile cele mai utilizate în România, din această categorie, amintim SGBD-urile de tip Socrate, dezvoltate de firma franceză CII după proiectul profesorului M.Abrial de la Universitatea din Grenoble şi DBMS-11, al firmei DEC.

În prezent, cel mai răspândit dintre modelele de baze de date este cel relaţional, adică de tip n:1, dezvoltat de E.F.Codd de la IBM, al cărui obiectiv este acela de simplificare a accesului la date de către utilizatorii finali. Aceasta reprezintă a treia etapă sau generaţie în evoluţia SGBD-urilor.

Ca şi în cazul limbajelor, şi în cazul SGBD-urilor relaţionale s-a extins modelul relaţional prin includerea tehnologiei obiectuale. Astfel au apărut SGBD-urile obiectuale. La ora actuală există discuţii aprinse legate de faptul dacă acestea reprezintă sau nu o a patra generaţie de SGBD-uri. Problematica bazelor de date obiectuale depăşeşte domeniul nostru de interes, fiind larg dezbătută în [Date04].

1.1.4. Entităţi şi tipuri de entităţi

Entitatea reprezintă unul dintre conceptele de bază cu care se operează în cadrul modelelor de organizare a datelor în baze de date.

O entitate este o realitate obiectivă care există prin ea însăşi. Orice entitate, aşa după cum s-a mai arătat, se caracterizează prin anumite proprietăţi, care în cadrul modelului de date sunt reprezentate prin atribute.

Entităţile la rândul lor sunt reprezentate prin tipuri de entităţi. Un tip de entitate este o reprezentare a unei categorii de obiecte din lumea reală sau a unei mulţimi de entităţi de acelaşi fel şi atributele sale reprezintă caracteristicile generale (intensionale) ale acelei categorii. Pentru fixarea ideilor, să considerăm următorul exemplu: mulţimea de entităţi reprezentând studenţii unei facultăţi este definită prin tipul sau clasa de entităţi STUDENT cu următoarele proprietăţi sau atribute: Nume, An, Secţie, Situaţie şcolară, care reprezintă proprietăţi generale sau intensionale ale tipului de entitate respectiv.

Page 114: licenta hatz

12 Ştefan Ioan Niţchi

Mulţimea entităţilor descrise prin tipul de entitate dat reprezintă extensiunea tipului de entitate respectiv, atributele unei instanţe ale entităţii fiind proprietăţile particulare sau extensionale ale acesteia. Astfel, un student oarecare este o extensiune a clasei STUDENT, iar atributele sale, care iau de exemplu valorile:Popescu, an II, CIG, bursier, reprezintă proprietăţi extensionale ale unei instanţe a tipului de entitate STUDENT.

Pentru reprezentarea unei mulţimi de entităţi din lumea reală printr-un tip de entitate, se iau în considerare acele proprietăţi care sunt relevante pentru acel tip de entitate.

Ideea fundamentală a lui E.F.Codd, de la IBM, a fost că mulţimile de entităţi se modelează convenabil prin tabele a căror descriere, adică antetul, defineşte tipul de entitate prin atribute sau proprietăţi, iar liniile reprezintă entităţi din mulţime, sau instanţe ale tipului de entitate respectiv.

Exemplu: tipul de entitate STUDENT se poate modela prin următorul tabel:

Antet reprezentat prin

Nume An Secţie Situaţie şcolară atribute care defineşte tipulde entitate STUDENTIonescu II CIG BURSIER

Popescu III FA NEBURSIER Entităţi sau instanţe ale… … … … tipului de entitate… … … …. STUDENT

Tabelul 3.1 Tipul de entitate STUDENT1.1.5. Modelul de date relaţional

Caracteristici generalePrimul model de date relaţional, aşa după cum s-a amintit, a fost propus de către cercetătorul american E.F. Codd de la laboratorul din Palo Alto al IBM. Principiile matematice care stau la baza acestui model pornesc de la teoria matematică a relaţiilor, extinsă la cerinţele de gestiune a datelor. Mai exact, teoria lui Codd se bazează pe faptul că între relaţiile finite şi tabele se poate realiza o corespondenţă biunivocă. În baza acestei observaţii, operaţiile din bazele de date efectuate asupra tabelelor pot fi realizate prin operaţii matematice (algebrice) asupra relaţiilor.

Modelul relaţional stă la baza majorităţii SGBD-urilor comerciale care există sau apar în prezent. Răspândirea acestui model se datorează faptului că SGBD-urile relaţionale dispun de un limbaj de manipulare a datelor foarte puternic şi simplu şi

Page 115: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 13

Page 116: licenta hatz

de o interfaţă prietenoasă, care permite folosirea bazelor de date relaţionale de către o categorie foarte largă de utilizatori.

O bază de date relaţională este definită ca fiind un ansamblu de tabele sau relaţii între care există anumite legături, fiecare tabelă fiind alcătuită din coloane, denumite atribute, şi linii, denumite şi tuple.

Definirea entităţilor şi structurii acestoraReamintim că în cadrul modelului relaţional entităţile se reprezintă prin intermediul tabelelor, sau a relaţiilor statice, precum şi a legăturilor dintre ele, sau a relaţiilor dinamice.

Conceptele cu care se operează în cadrul modelului relaţional în vederea definirii entităţilor şi structurii acestora sunt următoarele:

1.3.4. linia sau tuplul

1.3.5. atributul sau caracteristica

1.3.6. domeniul

1.3.7. înregistrarea logică

1.3.8. cardinalitatea relaţiei

1.3.9. rangul relaţiei

1.3.10. cheia relaţiei

Pentru exemplificarea conceptelor anterior prezentate se consideră relaţia sau tabelul FACULTẶŢI având următoarea structură:

Atribut

Înregistrare logicăCod facultate Denumire facultate Adresa (antet relaţie)STE ŞT. ECONOMICE Mihali 58+60FIL FILOLOGIE Horea 5 Linie (tuplu)BIO BIOLOGIE Hajdeu 10MED MEDICINĂ E. Isac 20

Domeniu

Page 117: licenta hatz

Tabelul 3.2 Tabelul FACULTATI

Page 118: licenta hatz

14 Ştefan Ioan Niţchi

Semnificaţia acestor concepte este următoarea:

Linia sau tuplul reprezintă o succesiune de valori de diferite tipuri şi conţine informaţii referitoare la un obiect sau la o entitate, cum ar fi: o carte dintr-o bibliotecă, un angajat din tabelul ANGAJATI sau o facultate din cadrul tabelului FACULTATI şi corespunde noţiunii de înregistrare folosită la organizarea datelor în fişiere. Teoretic, orice tuplu reprezintă o relaţie între clase de valori. Astfel, linia sau tuplul:

FIL FILOLOGIE HOREA 5

conţine trei valori asociate, care definesc codul, denumirea şi adresa unei facultăţi. Numărul de linii sau tuple din cadrul unei relaţii, sau a unui tabel, determină cardinalitatea relaţiei. Astfel, tabelul FACULTATI are cardinalitatea egală cu 4.

Atributul reprezintă, aşa după cum s-a mai amintit, o caracteristică sau o proprietate a unui tip de entitate sau clase de entităţi şi defineşte ansamblul valorilor de acelaşi tip din cadrul unei coloane a tabelului.

Domeniul reprezintă totalitatea valorilor acceptate sau autorizate pentru un atribut al relaţiei. Astfel, pentru atributul STARE_CIVILA din tabelul PERSONAL, domeniul este alcătuit din valorile .T. (adevărat) sau .F. (false). Pentru atributul UM (unitate de măsură) dintr-un tabel CATALOG, domeniul poate include valorile: "Buc" (bucată), "Kg", "MP" etc., în schimb, pentru atributul preţ din acelaşi tabel, domeniul poate fi mult mai larg, conţinând valori întregi cuprinse între 1 şi 10.000.000.

Putem considera că un atribut reprezintă o utilizare sub un anumit nume a unui domeniu. Din acelaşi domeniu pot deriva mai multe atribute, fiecare cu nume diferite la nivelul unui tabel. Astfel, dacă considerăm domeniul numerelor întregi sau reale, din acest domeniu pot deriva atribute cum ar fi: SALAR, IMPOZIT, VALOARE, PRET, CANTITATE etc.

Fundamentul matematic al conceptului de relaţie şi atribut

Din punct de vedere matematic, prin relaţie se înţelege o submulţime a produsului cartezian al unor domenii.

Având domeniile D1D2…Dn, produsul lor cartezian se defineşte astfel:

V=D1 x D2 x …. x Dn = (d1, d2,….,dn)

Page 119: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 15

Page 120: licenta hatz

şi reprezintă o asociere între elementele fiecărui domeniu, sau mai exact, este mulţimea tuturor combinaţiilor sau tuplelor de forma d1, d2,….,dn, unde di Di.

De exemplu, considerând mulţimile A=(1,2) şi B=(1,2,3) avem produsul cartezianAxB=(1,1), (1,2),(1,3), (2,1), (2,2),(2,3).

O submulţime a mulţimii V reprezintă o relaţie în măsura în care această submulţime conţine acele tuple ale căror elemente se pot asocia logic între ele.

De exemplu, să considerăm din produsul cartezian definit anterior, relaţia obţinută punând condiţia a1 2. Astfel se va obţine: R= (2,1), (2,2),(2,3)

Deci, relaţia se defineşte astfel:

R D1 x D2 x ……x Dn

unde D1, D2,…,Dn reprezintă domeniile relaţiei R comparabile între ele, iar "n" reprezintă rangul relaţiei. După rang, relaţia poate fi: primară, binară, ternară sau,în general, n-ară.

Desigur că definiţia anterioară dată relaţiei nu este unica posibilă. Astfel, Date [Date04] defineşte o relaţie ca fiind compusă din două părţi:

3. Antetul relaţiei, ca fiind o mulţime de atribute definite pe câte un domeniu (nu neapărat distinct), astfel:

A1 : D1, A2 : D2,….An:Dm

2.2. Corpul relaţiei, ca fiind o mulţime de tuple, fiecare tuplu conţinând o mulţime de valori aferente atributelor definite în antetul relaţiei, astfel:

t1, t2,…tk…….tm mulţime de tuple

ti = di1,di2………din mulţime de valori aferente unei tuple

pentru i=1,2,...,m

Ilustrarea acestui mod de abordare rezultă din figura următoare:

Page 121: licenta hatz

16 Ştefan Ioan Niţchi

A1 A2 … An Antetul relaţieit1

d1,1

d1,2

d1,n

t2d

2,1d

2,2d

2,n

… … … … Corpul relaţieitk

dk,1

dk,2

dk,n

… … … … …tm

dm,1

dm,2

dm,n

Figura 3.1 Antetul şi corpul unei relaţii

Deci, o relaţie poate fi simbolizată prin mulţimea atributelor sale astfel:

R(A1,A2…..,An) sau (A1:D1,A2:D2,….,An:Dn)

Din definiţiile noţiunii de relaţie, rezultă următoarele proprietăţi ale acesteia:

Ordinea atributelor în cadrul unei relaţii este nesemnificativă (atributele nu sunt ordonate).

Atributele unei relaţii trebuie să fie distincte, chiar dacă pe acelaşi domeniu sunt definite mai multe atribute.

Orice atribut are valori atomice, adică la intersecţia dintre o linie şi o coloană se află o singură valoare şi nu o colecţie de valori sau grupuri repetitive. In acest caz, se consideră că relaţia se află în forma întâia normală.

In cadrul corpului relaţiei, tuplele nu sunt ordonate în mod obligatoriu. Intr-o relaţie nu există tuple duplicate.

Trebuie menţionat că unele implementări particulare ale noţiunii de relaţie nu respectă toate aceste restricţii. Astfel, de exemplu, în cazul SQL Server unicitatea tuplelor nu este obligatorie.

Legături între relaţiiDefinirea cheilor unei relaţii

Pornind de la ideea că tuplele unei relaţii sunt unice, înseamnă că fiecare tuplu poate fi identificat prin valoarea unui atribut sau grup de atribute.

Dacă într-o relaţie există mai multe atribute sau combinaţii de atribute care permit identificarea unică a tuplelor, acestea sunt denumite chei candidat. O astfel de cheie reprezintă un atribut sau o mulţime de atribute (K) cu următoarele proprietăţi[Gardarin86] :

Page 122: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 17

Page 123: licenta hatz

5. identificare unică, ceea ce înseamnă că mulţimea de atribute K identifică în mod unic fiecare tuplu din relaţie;

6. ireductibilitate, ceea ce înseamnă că nu există nici o submulţime proprie a mulţimii K, care să identifice în mod unic un tuplu al mulţimii R;

7. valorile atributului sau ale ansamblului de atribute care definesc cheile candidat sunt întotdeauna specificate, adică nu pot fi nule.

O entitate poate conţine mai multe chei candidat, dar numai una dintre ele se alege pentru a fi folosită la identificarea tuplelor. Această cheie se numeşte cheie primară. O cheie candidat care nu este desemnată ca şi cheie primară se numeşte cheie alternativă.

Pe lângă noţiunile de cheie candidat şi cheie primară, în cadrul modelului relaţional se mai foloseşte şi noţiunea de cheie străină. Ea se utilizează la stabilirea legăturilor dintre două tabele, numite tabela principală sau părinte şi tabela secundară sau copil. Prin definiţie, valoarea cheii străine trebuie să se regăsească în mulţimea cheilor primare ale tabelei principale. Ea reprezintă deci o referinţă către un tuplu din tabela părinte care are aceeaşi valoare a cheii primare.

Pentru clarificarea noţiunilor, să considerăm următorul exemplu. Fie o bază de date care conţine tabela PERSONAL şi tabela COPII. Tabela are atributele: MARCA,NUME-PRENUME, DATA-NASTERII, VECHIME, SALAR-BRUT. Această tabelă poate avea mai multe chei candidat: MARCA, NUME-PRENUME, sau dacă aceasta nu are valori unice, perechea (NUME-PRENUME, DATA-NASTERII). Se observă fără dificultate că soluţia cea mai avantajoasă este să se aleagă ca şi cheie primară MARCA. Fiecare angajat poate avea unul sau mai mulţi copii ale căror date sunt păstrate în tabela COPII, care are printre altele atributele: NUME-PRENUME, DATA-NASTERII, SITUATIA-SCOLARA. Pentru a lega între ele cele două tabele, în tabela COPII se va introduce cheia stăină MARCA, care reprezintă marca angajatului ai cărui copii sunt. Astfel, de exemplu, pentru angajatul Ionescu Ion care are marca 142, toţi copiii vor avea valoarea cheii străine MARCA, 142.

Tipuri de legături între relaţiiUna din componentele modelului relaţional se referă la legăturile dintre relaţii sau tabele. O legătură (relaţie dinamică) se defineşte ca fiind o asociere între mai multe tipuri sau clase de entităţi. Cea mai frecventă legătură întâlnită în practică este cea dintre două tipuri de entităţi, numită şi legătură binară.

Legăturile binare, aşa cum s-a amintit, după cardinalitatea lor (numărul entităţilor din fiecare clasă de entităţi care intră în cadrul legăturii) se pot clasifica astfel:

Page 124: licenta hatz

18 Ştefan Ioan Niţchi

legături de tip 1-1, prin care unei entităţi din mulţimea sau clasa M1 îi corespunde o singură entitate în mulţimea sau clasa M2. Exemplu: legătura între tabelele SALARII şi ANGAJATI legate prin cheia COD_ANGAJAT; unui angajat din tabela ANGAJATI îi corespunde o singură entitate (înregistrare) în tabela SALARII şi invers; în relaţiile sociale aceste relaţii se numesc monogamie sau relaţii de tip iudeo-creştine;legături de tip 1-n, prin care unei entităţi din mulţimea M1 sau din tabelul M1 îi corespund mai multe entităţi în mulţimea sau tabelul M2, iar unei entităţi din M2 îi corespunde o singură entitate în M1. Exemplu: în cazul tabelelor DEPARTAMENTE şi ANGAJATI, un departament poate avea mai mulţi angajaţi, dar un angajat nu poate face parte decât dintr-un departament; în cadrul relaţiilor sociale, acestea se numesc relaţii de tip poligamie sau poliandrie, după caz;legături de tip m-n, prin care unei entităţi din M1 îi corespund mai multe entităţi în M2 şi reciproc; relaţiile sociale de acest tip se numesc relaţii de grup sau hyppie.

Observaţii.

În unele materiale apar şi legăturile de tip n:1, care însă pot fi considerate ca legături de tip 1:n inversate.

Legăturile de tip 1-1 se implementează introducând în una din tabele (secundară) o cheie străină care va face legătura cu cheia primară din tabela principală, folosind procedeul propagării cheii dintr-o relaţie în alta.

Legăturile de tip m-n se implementează prin intermediul unei tabele suplimentare, care are ca şi atribute cheile celor două relaţii.

Definirea restricţiilor pentru datele dintr-o bază de date

Pentru datele dintr-o bază de date pot fi definite mai multe tipuri de restricţii, cum ar fi: restricţia de domeniu, de atomicitate, referenţială şi restricţii utilizator. Dintre acestea, ne vom referi în continuare la restricţia referenţială sau integritatea referenţială, pe care se bazează stabilirea legăturilor dintre două tabele.

Integritatea referenţială, denumită în unele sisteme (ca de exemplu în SQL Server), integritate referenţială statică deoarece se păstrează în dicţionarul de date, se defineşte ca fiind un ansamblu de reguli impuse tabelelor între care s-au stabilit anumite legături. Astfel, pentru a asigura integritatea referenţială trebuie ca atunci când se fac modificări ale valorii unui câmp de tip cheie primară sau străină dintr-un tabel, să nu fie afectată relaţia dintre cele două tabele, adică să se modifice automat valorile cheii în toate tuplele corespunzătoare. Integritatea referenţială

Page 125: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 19

Page 126: licenta hatz

cere ca valorile cheii străine să se regăsească printre valorile cheii primare. Această condiţie introduce în baza de date constrângeri numite constrângeri referenţiale.

Operaţiile de adăugare, modificare şi ştergere pot afecta integritatea referenţială astfel:

In tabela principală (tabela referită sau părinte):

← operaţia de adăugare se va face fără nici un fel de restricţii din punct de vedere al condiţiilor de integritate referenţială;

← operaţia de ştergere - deoarece prin ştergerea unui tuplu din relaţia sau tabela principală, în relaţia secundară pot rămâne tuple care fac referire la tuplul şters, pentru a menţine integritatea referenţială se poate introduce ştergerea restricţionată sau în cascadă;

← în primul caz, nu se poate şterge un tuplu din tabela principală dacă acesta are corespondent tuple în tabela secundară, deoarece tuplele din tabela secundară rămân orfane, adică vor avea referinţe nesatisfăcute;

← în al doilea caz, ştergerea unui tuplu din tabela principală va fi urmată de ştergerea tuturor tuplelor din relaţia secundară care fac referire la tuplul şters;

← operaţia de modificare poate fi privită ca şi în cazul operaţiei de ştergere, iar restricţiile referenţiale sunt cele folosite la operaţia de ştergere.

În tabela secundară (de referinţă sau tabela copil):

← operaţia de adăugare se poate face numai dacă valorile cheii străine pentru articolele adăugate se regăsesc printre valorile cheii primare din tabela principală, altfel operaţia de adăugare este interzisă;

← operaţia de ştergere se poate realiza fără nici o restricţie din punct de vedere al condiţiilor de integritate referenţială;

← operaţia de modificare se poate realiza cu condiţia să nu apară înregistrări fără corespondent în tabela principală.

Page 127: licenta hatz

20 Ştefan Ioan Niţchi

Constrângerile referenţiale pot fi reprezentate printr-o diagramă referenţială.Aceasta apare sub forma unui graf, având ca noduri tabelele, iar arcele reprezentând constrângerile, după cum se va vedea în cazul Visual FoxPro.

Schema şi conţinutul unei baze de date relaţionale

Există două modalităţi de abordare a bazelor de date relaţionale şi anume[Fotache01]:

schema relaţională (intensia sau structura bazei de

date); conţinutul unei relaţii (extensia bazei de date).

Schema relaţională sau intensia unei baze de date poate fi definită ca un ansamblu de relaţii asociate semantic prin domeniul de definiţie şi prin restricţii de integritate. Ea conţine:

5: una sau mai multe scheme de relaţie, unde fiecare schemă de relaţie include numele relaţiei şi atributele aferente;

6: restricţii de integritate, care pot fi:

← restricţia cheilor primare, adică fiecare cheie primară trebuie să fie unică, nenulă şi cu compoziţie minimală;

← restricţii referenţiale, care decurg din existenţa cheilor străine;

← alte restricţii, cum ar fi cele definite de utilizator (dependenţe între atribute, valori limită, unicitate, caracter nenul etc.).

Schema relaţională descrie întotdeauna modelul conceptual din cadrul unei baze de date. O posibilă schemă relaţională pentru o bază de date care conţine informaţii referitoare la studenţi este următoarea:

JUDETE (CodJud, DenumireJudeţ, Regiune)

LOCALITATI (CodPoştal, Localitatea, CodJud)

STUDENŢI (NrMatricol, CNP, Nume, Prenume, AdresaDomiciliuStabil,AdresaFlotant, AdresaE-mail, DataNasterii, LoculNasterii, Sectia, An, Grupa)

NOTE (NrMatricol, CodMaterie, An, Semestru, TipExaminare, Nota,NrCredite)

MATERIE(CodMaterie, DenumireMaterie)

Page 128: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 21

Page 129: licenta hatz

PROFESOR(CodProfesor, Nume, Prenume, GradDidactic, CodMaterie)

Schema relaţională poate fi reprezentată grafic prin mai multe metode. Una dintre ele [Ullman90] se bazează pe următoarele reguli:

10: o tabelă se reprezintă pe două linii, unde prima linie conţine numele tabelei, iar a doua linie, numele atributelor;

11: cheia primară este plasată în stânga tabelei, reprezentată de primul atribut;

12: numele atributului sau atributelor care formează cheia primară se subliniază;

13: o restricţie se indică printr-o săgeată care pleacă de la numele coloanei de referinţă (care reprezintă cheia străină) spre coloana referenţiată (care reprezintă cheia primară).

Trebuie să menţionăm însă că în cazul unor SGBD-uri concrete, cum este cazul Visual FoxPro, această reprezentare a schemei relaţionale este mai clară şi mai riguroasă.

Conţinutul sau extensia unei baze de date se reprezintă sub formă de tabele, unde fiecare tabel corespunde unei scheme de relaţie.

Pe parcursul exploatării bazei de date, extensia se poate modifica (creşte sau scade). Prin urmare, ea reprezintă componenta dinamică a bazei de date, în timp ce schema relaţională reprezintă componenta permanentă sau statică şi nu este dependentă de timp sau de volumul de activităţi.

Pentru fixarea ideilor referitoare la noţiunile mai sus menţionate, să considerăm următorul exemplu. Fie tabela FACULTATI din figura de mai jos:

Cod_fac Den_fac Adresa

FSE STIINTE EC. Mihaly 58-62

FIL FILOLOGIE Horea 5

BIO BIOLOGIE Hajdeu 10

MED MEDICINA 1 Mai 15

Tabelul 3.3 Relaţia FACULTĂŢI

Elementele definite mai sus sunt reprezentate în exemplul nostru astfel:

Page 130: licenta hatz

22 Ştefan Ioan Niţchi

1. Relaţie / tabelă FACULTATI

2. Înregistrare logică / antet tabelă Cod_fac Den_fac Adresa

3. Atribute Cod_fac, Den_fac, Adresa

4. Tuple / Linii FSE, ŞT. ECONOMICE, Mihali 58-62

7. Domeniu FSE, FIL, BIO, MED

6. Colecţie de date / fişier FSE STIINTE EC. Mihaly 58-62

FIL FILOLOGIE Horea 5

BIO BIOLOGIE Hajdeu 10

MED MEDICINA 1 Mai 15

Corespondenţa dintre termenii formali şi informali nu trebuie luată ca şi o echivalenţă perfectă, deoarece în practică există anumite particularităţi de care trebuie să ţinem seama. Astfel:

în timp ce relaţia este o mulţime teoretică, tabela este un obiect concret cu o anumită reprezentare (tablou bidimensional);

în timp ce într-o relaţie ordinea atributelor sau tuplelor nu este semnificativă, într-o tabelă există o ordonare atât a coloanelor, dată de ordinea acestora la creare, cât şi a înregistrărilor, dată de ordinea în care au fost introduse în tabelă sau ca urmare a indexării tabelei;

în timp ce o relaţie teoretică este formată întotdeauna din tuple distincte, în practică o tabelă poate conţine şi linii duplicat, aşa după cum s-a mai menţionatîn cazul SQL Server.

În acest context, noţiunea de relaţie se identifică cu cea de tabelă sau fişier, atributele, cu denumirea coloanelor unei tabele sau cu câmpurile unui fişier, iar tuplele, cu liniile tabelei sau cu articolele (respectiv înregistrările) unui fişier.

Cele de mai sus justifică faptul subliniat la definiţia bazelor de date, şi anume că baza de date este o colecţie de fişiere. În unele SGBD-uri, cum este cazul VisualFoxPro, fiecare fişier are articole de lungime fixă, în timp ce la altele, cum este cazul SQL Server, articolele pot fi de lungime variabilă. Spre deosebire însă de fişierele obişnuite, fişierele bazei de date prezintă o serie de particularităţi, dintre care amintim:

Page 131: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 23

Page 132: licenta hatz

2. fiecare fişier are asociată o înregistrare de structură sau un antet, care include informaţii despre conţinutul fişierului şi se memorează în dicţionarul de date;

3. dacă fişierul are articole de lungime fixă, articolele sau înregistrările de date conţin un număr de ordine, folosit la identificarea unei înregistrări în baza de date, numit şi indicatorul sau pointer-ul articolului respectiv; în Visual FoxPro acest pointer poate fi obţinut prin funcţia RECNO();

4. de regulă, unul dintre articolele bazei de date este cel tratat curent; pointer-ul acestui articol se numeşte pointer-ul sau indicatorul bazei de date;

5. fişierele din baza de date sunt interconectate între ele prin legături de tip 1-1, 1-n sau m-n.

Aplicaţia 1

Aplicaţia 2

Se memorează în Dicţionarul de ...ANTET Aplicaţia n

date

Înregistrări Se memorează în Fişier 1Extensia bazei

de date de date Fişier 1

...

Fişier m

Baza de date fizică

Figura 3.2 O bază de date şi relaţia ei cu aplicaţiile

Cu cele de mai sus, o bază de date şi relaţia ei cu aplicaţiile se poate reprezenta conform Figurii 3.2.

1.2. FORME NORMALE ŞI MECANISMUL NORMALIZĂRII

1.2.1. Introducere

Prin întreprindere se înţelege o structură organizată în vederea realizării unor produse sau servicii. Astfel, o fabrică, o universitate, un spital etc. reprezintăîntreprinderi. Întreprinderea este deci un univers real.

Model este un ansamblu de reguli pentru formalizarea întreprinderii. În practică există: modele matematice, economice, contabile, de date etc. Modelele de date reprezintă un ansamblu de reguli prin care întreprinderii i se ataşează structuri de

Page 133: licenta hatz

24 Ştefan Ioan Niţchi

date. Aşa după cum se ştie, modelele de date se clasifică după nivel şi semanticăîn: modele conceptuale, logice, fizice, respectiv externe.

Modelul conceptual, fiind primul nivel şi cel mai general de abstractizare a întreprinderii, se realizează fără utilizarea calculatorului şi poate lua diferite forme cum ar fi: modelele de tip E-R sau OLE. Imaginea întreprinderii prin modelul conceptual este schema conceptuală, care este formată din obiecte şi relaţii sau legături între acestea.

La nivelul logicii globale modelul conceptual se traduce în: modele arborescente, în reţea sau relaţionale.

Schema de date este imaginea la nivel relaţional a schemei conceptuale şi deci, a întreprinderii. Baza de datepoate fi considerată, în această accepţiune, ca fiind schema de date împreună cu datele care populează schema respectivă. Problema centrală a proiectării logice a unei baze de date este: stabilirea ansamblului relaţiilor care descriu corect schema conceptuală, şi deci, întreprinderea.

Prima problemă pe care o are administratorul bazei de date relaţionale, după stabilirea schemei conceptuale, este să stabilească schema de date a acesteia, cu alte cuvinte, structura bazei de date. Pentru stabilirea structurii, el porneşte de la diferite tabele. După cum se ştie, nu toate tabelele reprezintă relaţii, în sens clasic, sau altfel spus, acestea sunt relaţii nenormalizate. În timpul proiectării trebuie să se urmărească transformarea tabelelor în relaţii normalizate.

Pentru a înţelege problemele cu care se confruntă administratorul bazei de date, să considerăm următorul exemplu. Fie orarul sălilor de curs din FSEGA (tabelul 3.4)

Acest tabel nu este o relaţie normalizată, deoarece nu toate atributele sunt atomice; de exemplu, atributul Orar este format din Zi şi Ora.

Trebuie să remarcăm şi faptul că în tabel există şi dependenţe de tip N:1 (funcţionale), adică există dependenţa:

Sala → Capacitate

Astfel, mai multe săli (022, 033,...) au aceeaşi capacitate.

Aceste tipuri de dependenţe pot genera mai multe tipuri de anomalii:

redundanţă logică – perechile de forma (026, 100) sau (022,150) apar de mai multe ori în tabel;

anomalii de stocare

Page 134: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 25

Page 135: licenta hatz

anomalii de inserare - să presupunem că se construieşte o nouă sală de curs; aceasta nu poate fi introdusă în tabelul orarului până nu se primeşte o valoare pentru cheia primară Sala#, deoarece cheia primară nu poate fi vidă;

2.2.2 anomalii de ştergere – să presupunem că sala 022 trebuie scoasă din orar datorită unor reparaţii; prin ştergerea liniilor respective se va putea pierde legătura (Sala, Capacitate) care n-are o legătură semantică cu reparaţia din acest caz şi ar trebui să rămână în baza de date.

← anomalii de modificare – să presupunem că s-a extins capacitatea sălii 022 la 120 de locuri. Rezultă că trebuie să se urmărească toate tuplele din tabelă care conţin relaţia (022,100), deoarece altfel apare o anomalie generată de faptul că aceeaşi sală poate apare cu două capacităţi diferite.

probleme de reconexiune; să presupunem că descompunem tabelul 3.4 în două tabele (vezi tabelul 3.5). Dacă se recompun prin echijoin (asociere pe baza de egalitate) cele două tabele, se obţine tabelul 3.6. Deoarece fiecare tuplu din tabelul din stânga se combină cu fiecare tuplu din tabelul din dreapta şi pe baza egalităţii valorilor cheii comune, nu se ajunge la tabelul iniţial.

Page 136: licenta hatz

26 Ştefan Ioan Niţchi

Sala# Capacitatea Orar An Materia Cadrul didactic

Zi Ora

026 100 Luni 8 IE IV Baze de date Ionescu

026 100 Luni 10 MF III MRU Popescu

...

022 150 Luni 8 CIG III Contabilitate Georgescu

022 150 Luni 10 IE IV CSBD Ionescu

... .. ...

033 150 Luni 8 IEIII CSBD Apolodor

033 150 Luni 10 MKIII Cercetări de Alexamarketing

... .. ...

Tabelul 3.4 Orarul sălilor de curs

Mecanismul la dispoziţia proiectantului sau administratorului bazei de date pentru rezolvarea acestor probleme se numeşte normalizare.

Page 137: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 27

Page 138: licenta hatz

Sala1 Sala2:

Sala Capaci Capaci Orar An Materia Cadru didactic

tatea Tatea Zi Ora

026 100 100 Luni 8 IE IV Baze de date Ionescu

026 100 100 Luni 10 MF III MRU Popescu

...

022 150 150 Luni 8 CIG III Contabilitate Georgescu

022 150 150 Luni 10 IE IV CSBD Ionescu

... .. ...

033 150 150 Luni 10 IE IV CSBD Apolodor

033 150 150 Luni 10 IE IV CSBD Alexa

... .. ...

Tabelul 3.5 Descompunerea relaţiei orarul sălilor

Page 139: licenta hatz

28 Ştefan Ioan Niţchi

Sala# Capacitate Orar An Materia Cadru didactic

Zi Ora

026 100 Luni 8 IE IV Baze de date Ionescu

026 100 Luni 10 MF III MRU Popescu

...

026 100 Luni 8 IE IV Baze de date Ionescu

026 100 Luni 10 MF III MRU Popescu

...

022 150 Luni 8 CIG III Contabilitate Georgescu

022 150 Luni 10 IE IV CSBD Ionescu

... .. ...

022 150 Luni 8 CIG III Contabilitate Georgescu

022 150 Luni 10 IE IV CSBD Ionescu

... .. ...

Tabelul 3.6 Relaţia “orarul sălilor” recompusă

Normalizarea este o operaţie prin care se urmăreşte:

transformarea tabelelor în relaţii;

înlăturarea redundanţelor;

înlăturarea dependenţelor interne între atributele unei relaţii, transformându-le în dependenţe între tabele obţinute prin descompunere;

înlăturarea diferitelor anomalii (de inserare, modificare sau ştergere) existente iniţial sau apărute în urma descompunerii tabelelor;

asigurarea descompunerilor fără pierderi, adică, recompunând tabelele obţinute în urma descompunerilor unui tabel trebuie să se ajungă la tabelul iniţial.

Page 140: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 29

Page 141: licenta hatz

Normalizarea este deci procesul iterativ prin care baza de date se aduce la o formă standard în care dispare fenomenul de redundanţă, nu există anomalii şi fiecare tabel conţine o singură entitate semantică (nu există dependenţe între atribute).

Există, aşa după cum se va vedea, mai multe forme normale, care sunt parcurse piramidal de la Forma 1-a normală (1NF) până la Forma a 5-a normală (5NF). Aducerea unei relaţii la 1NF este obligatorie deoarece altfel tabelul nu poate fi reprezentat în cadrul unui SGBD. Pentru a aduce un tabel la forma unei relaţii, de regulă, în proiectare se merge până la 3NF.

Teoria normalizării este deosebit de vastă, fiind tratată în toate materialele referitoare la teoria sau proiectarea bazelor de date relaţionale, mai teoretic[Ullmann80, Abidaboul01], sau mai pragmatic [Date04, Connolly01, R.Avram-Niţchi04].

1.2.2. Definiţii preliminare

Algoritmul prin care, pornind de la o relaţie dată într-o formă normală, se ajunge la o relaţie în forma imediat superioară se numeşte algoritm de descompunere.

Dependenţa funcţională, fiind o dependenţă univocă, seamănă cu funcţia din matematică, deoarece uneia sau mai multor valori ale primului atribut îi corespund 0 sau 1 valoare din al doilea atribut. Deosebirea dintre cele două noţiuni este că în timp ce funcţia matematică este atemporală, dependenţa funcţională depinde de timp. Dependenţele funcţionale se notează de regulă cu DF. Se poate observa că, dacă se notează cu A şi B două grupuri de atribute, între acestea are loc o DF dacă şi numai dacă din t1(A) = t2(A) rezultă t1(B) = t2(B), unde cu ti(A), respectiv ti(B) pentru i=1,2 s-au notat subtupluri corespunzătoare lui A, respectiv B. A se numeşte domeniul de definiţie sau determinantul, iar B cel al valorilor sau cel determinat.

Fie R o relaţie, A şi B fiind două mulţimi de atribute ale ei. Se spune că între A şi B există o dependenţă funcţională totală şi se notează cu DFT: A→B, dacă şi numai dacă au loc următoarele două condiţii:

(i) Există DF: A→B.

(ii) Nu există nici o submulţime proprie A’ a lui A as el ca să existe DF: A’→B.

O dependenţă funcţională care nu este totală este o dependenţă funcţională parţială.

Page 142: licenta hatz

30 Ştefan Ioan Niţchi

Dependenţele funcţionale au o serie de proprietăţi, dintre care cele mai cunoscute sunt axiomele lui Armstrong, stabilite de acesta în 1974. Fie R o relaţie şi A,B,C trei mulţimi de atribute ale ei. Pentru dependenţe funcţionale au loc următoarele axiome:

A1. Reflexivitatea A→A, sau mai general, dacă A’ este o parte a lui A, rezultă A→A’.

A2. Creşterea determinantului:

dacă există DF: A→BA este o submulţime a lui C

Rezultă că are loc şi DF: C→B.

Se poate observa că DF: C→B este o dependenţă funcţională parţială, deoarece B depinde de o parte a lui C.

A3. Tranzitivitatea

din A→Bşi B→C

rezultă A→C.

DF:A→C se mai numeşte închiderea tranzitivăa primelor două dependenţe, respectiv se spune că C depinde tranzitiv de A.

Observaţie. Analog cu dependenţele univoce se definesc şi dependenţele multivoce, în care unui element din primul atribut îi corespund un ansamblu de elemente din al doilea atribut. Acestea sunt de tip 1:n, deci dependenţe arborescente. De exemplu, corespondenţa (Sală, An) sau (Sală, Cadru Didactic). Dependenţa tranzitivă din cadrul dependenţelor univoce se poate extinde analog şi pentru cele multivoce.

Fie E o mulţime de dependenţe (univoce sau multivoce). Mulţimea E+ a tuturor dependenţelor tranzitive obţinute din E se numeşte închiderea lui E. Fie acum două mulţimi de relaţii E şi E’, unde E’ conţine dependenţele din E precum şi unele dependenţe obţinute din E aplicând proprietăţile acestor dependenţe. E’ se numeşte acoperire a lui E dacă şi numai dacă, E şi E’ au aceeaşi închidere.

Referitor la mulţimile de axiome, se introduc două noţiuni care permit caracterizarea lor:

Page 143: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 31

Page 144: licenta hatz

mulţime de axiome este completă dacă şi numai dacă pornind de la o mulţime de dependenţe E se pot obţine pe baza axiomelor toate dependenţeleînchiderii lui E.O mulţime de axiome este închisă, dacă şi numai dacă, pornind de la mulţimea E a dependenţelor nu se pot deduce, cu ajutorul axiomelor, dependenţe care nu fac parte din E.

Enunţăm fără demonstraţie teorema lui Ullman dată în 1980: Mulţimea axiomelorlui Armstrong este completă şi închisă.

E’ se numeşte o acoperire minimală a lui E dacă şi numai dacă este o acoperire a lui E şi nici o parte a lui E’ nu are această proprietate. Referitor la acoperirea minimală trebuie remarcate următoarele:

acoperirea minimală joacă un rol important în descompunerea relaţiilor; o mulţime de aplicaţii poate avea mai multe acoperiri minimale.

O descompunere se spune că este reversibilă dacă, recompunând relaţiile obţinute prin descompunere, se obţine relaţia iniţială. O relaţie se numeşte ireductibilă dacă nu mai poate fi descompusă în mod reversibil. Se poate observa că o relaţie ireductibilă defineşte o singură entitate semantică şi, deci, relaţiile ireductibile pot fi considerate module logice pe baza cărora se modelează întreprinderea.

Se numeşte o descompunere atomicăa unei relaţii R, o descompunere reversibilă a lui R în relaţii ireductibile.

1.2.3. Prima formă normală

Fie tabelul PERSONAL al angajaţilor unei organizaţii, care are forma:

MARCA# Nume şi Domiciliu ... Copil Copil CopilPrenume

Judeţ Localitate Stradă Număr

... ... ... ... ... ... ... ... ... ...

Tabelul 3.7 Relaţia PERSONAL

Acest tabel nu este o relaţie normalizată deoarece, pe de o parte, câmpul Domiciliu este un câmp compus, fiind la rândul său format din câmpuri (Judeţ, Localitate, Stradă, Număr), deci nu este atomic, iar pe de altă parte, câmpul Copil este repetitiv. Principala problemă legată de câmpurile repetitive este faptul că nu se ştie câte astfel de câmpuri să se rezerve. Astfel, dacă se rezervă 5 câmpuri Copil şi un angajat nu are decât 1 copil, 4 zone se pierd inutil, în schimb, dacă are 7 copii, spaţiul alocat copiilor nu ajunge.

Page 145: licenta hatz

32 Ştefan Ioan Niţchi

O relaţie este în prima formă normală (1NF) dacă fiecare atribut (câmp) este atomic şi nu conţine grupuri repetitive.

Trecerea unui tabel la prima formă normală se realizează astfel:

atributele care nu sunt atomice se transformă în câmpuri atomice prin proiectare (descompunere) şi eventual redenumire;pentru câmpurile repetitive se introduc atâtea tuple câte apariţii are câmpul respectiv, fiecare tuplu conţinând o apariţie a câmpului.

Transformarea de mai sus poate fi rezumată grafic astfel:

Tabel nenormalizat Relaţie 1NF

Figura 3.3 Transformarea în prima normă formală

Având în vedere cele de mai sus, tabelul PERSONAL devine:

MARCA# Nume şi D-Judeţ D-Localitate D-Stradă D-Număr ... CopilPrenume

... ... … … … … ... ...

Tabelul 3.8 Relaţia PERSONAL transformată

unde am izolat Judeţ, Localitate, Stradă şi Număr din Domiciliu şi le-am redenumit. În plus, pentru câmpul Copil s-a reţinut o singură apariţie, fiecărui copil corespunzându-i un tuplu. În baza celor de mai sus, dacă angajatul Ionescu are 3 copii, el va avea 3 tuple de forma:

123Ionescu IonCJCluj-NapocaTh.Mihali2 ... Petrică

123Ionescu IonCJCluj-NapocaTh.Mihali2 ... Mărioara

123Ionescu IonCJCluj-NapocaTh.Mihali2 ... Costică ...

Page 146: licenta hatz

Tabelul 3.9

Page 147: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 33

Page 148: licenta hatz

Se poate observa fără dificultate că acest tabel va avea o cantitate însemnată de informaţie redundantă datorită grupului repetitiv. Pentru a înlătura acest neajuns, se va descompune (prin proiecţie) tabelul în două şi anume, vom avea tabelul PERS1 cu structura:

MARCA# Nume şi D-Judeţ D-Localitate D-Stradă D-Număr ...Prenume

... ... … … … … ...

Tabelul 3.10

şi tabelul COPII cu structura:

MARCA# Nume şi Data- Locul- Şituaţia AlocaţiePrenume Naşterii Naşterii şcolară

... ... … … … …

Tabelul 3.11

unde MARCA# este o cheie străină, prin care se asigură legătura cu tabelul PERS1, restul datelor fiind proprii copilului în cauză. MARCA# nu mai poate fi cheie primară, deoarece un părinte poate avea mai mulţi copii şi deci nu se mai asigură unicitatea valorilor cheii. Rezultă deci că s-ar putea lua ca şi cheie primară atributul „Nume şi Prenume” împreună cu „Data-Naşterii”, având în vedere faptul că un părinte poate, prin absurd, boteza doi sau mai mulţi copii cu acelaşi prenume.

Se observă că astfel s-au obţinut două tabele în prima formă normală, iar prin recompunerea tabelelor (prin echijoin) se ajunge la relaţia iniţială, deci descompunerea este fără pierderi, adică:

PERSONAL = PERS1 [MARCA# = MARCA#] COPII

Teorema de descompunereDescompunerea se utilizează pentru a evita anomaliile de stocare mai sus amintite.

Teorema de descompunere reversibilă se mai numeşte teorema lui Delobel şi se enunţă astfel: Fie R o relaţie definită pe mulţimea atributelor Ω, R(Ω) şi fie A,B,C o partiţionare a lui Ω, as el încât să existe DF:A→B. Atunci R(Ω) poate fi descompus fără pierderi în două relaţii R(Ω1 ) şi R(Ω2 ), unde

Ω1=A U B – este reuniunea atributelor din DF

Ω2=A U C- este reuniunea lui A cu atributele care nu fac parte din DF.

Page 149: licenta hatz

34 Ştefan Ioan Niţchi

Descompunerea permite izolarea a două concepte care iniţial se găseau în acelaşi tabel, adică transformă o dependenţă intra-relaţie într-o dependenţă inter-relaţie.

Dezavantajul este reprezentat de faptul că apare o migrare de atribute, în sensul că, atributele din grupul notat cu A (în cazul exemplului Marca#) se dublează.

1.2.4. A doua formă normală

O relaţie se consideră în a doua formă normală (2NF), dacă este în prima formă normală şi orice atribut care nu face parte din cheia primară, depinde funcţional total de cheia primară; cu alte cuvinte, nici un atribut care nu face parte din cheia primară nu depinde funcţional de o parte a cheii primare.

Se poate observa că relaţia PERS1 este în a doua formă normală, deoarece cheia primară MARCA# este formată dintr-un singur atribut, deci toate celelalte atribute depind funcţional total de cheia primară, aceasta neavând părţi. In schimb, relaţia COPII nu este în a doua formă normală, deoarece câmpul Alocaţia depinde funcţional de Data-Naşterii care reprezintă o parte a cheii primare, deci cheia primară formată din Nume şi Prenume şi respectiv Data-Naşterii nu determină funcţional total atributul Alocaţia.

Se poate observa că şi în acest caz avem o serie de anomalii:

anomalia de inserare – nu se poate introduce alocaţia unui copil, care depinde de Data-Naşterii, până când nu se introduce şi numele copilului, deşi alocaţia nu depinde de acest parametru;anomalia de ştergere – prin ştergerea numelui unui copil (care face parte din cheia primară) există riscul pierderii legăturii dintre data naşterii şi alocaţie;anomalii de punere la zi – pentru a pune la zi perechea (Data-Naşterii, Alocaţie) trebuie analizat fiecare articol, deoarece altfel se riscă apariţia unor inconsistenţe, dar operaţia este foarte costisitoare.

Pentru înlăturarea acestor anomalii, această relaţie se aduce la a doua formă normală, prin aplicarea teoremei descompunerii lui Delobel, deci relaţia COPII se va descompune în două relaţii şi anume, COPIL1 şi COPIL2 sub forma:

Page 150: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 35

COPIL1MARCA# Nume şi Data- Locul-

prenume naşterii naşterii… … … …

COPII COPIL2Data- Situaţia Alocaţienaşterii şcolară… … …

Figura 3.4 Aplicarea teoremei de descompunere relaţiei COPII

În felul acesta se înlătură redundanţele şi anomaliile, deoarece dependenţa

DF: Data-Naţerii→Alocaţie

nu mai este în relaţia COPIL1. Această descompunere este fără pierderi, adică prin recompunerea celor două tabele se regăseşte tabela iniţială. Avem deci:

COPII = COPIL1 [Data-Naşterii = Data Naşterii] COPIL2

În concluzie, cele prezentate mai sus se pot reprezenta grafic astfel:

Teorema de descompunere

Relaţie 1NF Relaţie 2NFSe izolează dependenţaparţială de cheia primară

Figura 3.5 Transformarea în forma 2-a normală

1.2.5. Forma a 3-a normală (3NF) şi variantele (3 ½ NF)A treia formă normală are mai multe definiţii, dintre care 3 sunt mai importante:

O relaţie este în 3NF (Codd 1970) dacă este în 2NF şi între două atribute care nu sunt cheie nu există o dependenţă tranzitivă.

Se spune că un atribut C depinde tranzitiv de atributul B dacă au loc dependenţele funcţionale între B şi C, A şi B, respectiv între A şi C. Cu alte cuvinte, schema dependenţelor funcţionale are forma:

A B

C

Figura 3.6 Dependenţă tranzitivă

Page 151: licenta hatz

36 Ştefan Ioan Niţchi

O formulare mai clară a definiţiei anterioare este: o relaţie este în 3NF dacă este în 2NF şi nu există dependenţe funcţionale între atributele care nu fac parte din cheie.

O a doua definiţie pentru forma a 3-a normală a fost dată de Boyce şi Codd în 1971; ea se numeşte forma BCNF sau Boyce-Codd Normal Form şi se defineşte astfel: o relaţie R este în BCNF dacă pentru orice mulţime de atribute A pentru care există un atribut din C(A), unde C(A) este mulţimea atributelor din R care nu fac parte din A şi care depind funcţional de A, are loc proprietatea că orice atribut din R depinde funcţional de A.

O a treia definiţie a formei a 3-a normale este cea dată de Sharman în 1975 şi se enunţă astfel: O relaţie este în 3NF dacă orice determinant este o cheie (primară sau candidat).

Ideea de bază este deci aceea că: fiecare relaţie în 3NF conţine un singur conceptsemantic.

Fie relaţia PERS1, care se mai poate reprezenta punând în evidenţă şi alte câmpuri, astfel:

MARCA Nume şi … Data- Ore-Lucrate Salar- ...Prenume Angajării Brut

... ... … … … … ...

Tabelul 3.12

Aceasta, deşi este în 2NF, nu este în 3NF, deoarece între atributele care nu fac parte din cheie, Data-Angajării şi Ore-Lucrate, pe de o parte, şi Salar-Brut, pe de altă parte, există o relaţie funcţională. Izolând această relaţie, din tabelul PERS1 se obţin tabelele:

PERS11MARCA# Nume şi Data Ore

prenume angajării lucrare… … … … … …

PERS1 PERS12Data- Ore Salarangajării lucrate brut… … …

Page 152: licenta hatz

Figura 3.7 Decompunerea relaţiei PERS1

Page 153: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 37

În felul acesta se elimină anomalii legate de prezenţa dependenţei funcţionale DF: (Data Angajării, Ore Lucrate → Salar Brut) şi se poate demonstra, pe baza aceleiaşi teoreme, că descompunerea este fără pierderi, adică:

PERS1 = PERS11 [Data-Angajării, Ore-Lucrate = Data-Angajării, Ore-Locrate]PERS12

Putem deci spune că trecerea de la 2NF la 3NF se realizează prin izolarea DF tranzitive şi aplicând teorema de descompunere. Schematic fenomenul se reprezintă astfel:

Teorema de

Relaţie 2NFdescompunere

Relaţie 3NFSe izolează dependenţeletranzitive între atributecare nu sunt chei

Figura 3.8 Transformarea în forma 3-a normală

Observaţie. Se poate remarca faptul că a doua şi a treia definiţie sunt echivalente şi sunt mai restrictive decât 3NF.

Pentru a arăta că într-adevăr forma BCNF este mai generală ca forma 3NF, să considerăm relaţia PERS12. Aceasta este în 3NF. Să considerăm că realizarea salarului brut implică faptul că angajatul lucrează un număr de ore. Rezultă că apare o dependenţă funcţională

DF: Salar-Brut → Ore-Lucrate

deci relaţia nu este în BCNF. Reprezentând schematic relaţiile, se poate observa că au loc dependenţele conform figurii:

Data-angajării

Salar-brutOre-lucrate (1)

Figura 3.9

Page 154: licenta hatz

Aplicând teorema descompunerii şi izolând (1), vor rezulta două tabele:

Page 155: licenta hatz

38 Ştefan Ioan Niţchi

Page 156: licenta hatz

PERS121

Data-angajării Ore-lucrate

… …

Tabelul 3.13

PERS122

Ore-lucrateSalar-brut

2. …

Page 157: licenta hatz

Este de remarcat faptul că relaţia PERS121 este format numai din cheie (ALL KEY), deci nu are nici un atribut care să nu fie cheie, şi că descompunerea este fără pierderi, deci:

PERS12 = PERS121 [Ore_Lucrate = Ore_Lucrate] PERS122

Schematic operaţia se poate reprezenta astfel:

Teorema de

Relaţie 3NFdescompunere

Relaţie BCNFSe izolează dependenţeledintre atributul non-cheieşi o parte a cheii primare

Figura 3.14 Transformarea în BCNF

Observaţii.

4.1.2. BCNF fiind mai restrictivă decât 3NF, se consideră că este forma 3 ½, deoarece se bazează totuşi pe dependenţe funcţionale, deci nu se justifică să fie considerată 4NF.

4.1.3. Aşa după cum s-a mai amintit, orice bază de date pentru a fi corect proiectată se aduce cel puţin până la 3NF.

Observaţie. În literatura de specialitate se discută despre formele normale 4, 5, 6 şi alte teorii de normalizare.

1.2.6. Tipuri de conservare

Teorema lui Ullman. Fie o descompunere al lui R în două relaţii R1şi R2. Dacă se notează cu D mulţimea tuturor dependenţelor funcţionale din R, descompunerea este fără pierderi de date, deci reversibilă, dacă şi numai dacă dependenţele funcţionale de la R1∩ R2 la R1- R2 , respectiv R2- R1, fac parte din închiderea lui D.

Page 158: licenta hatz

Definiţia şi clasificarea bazelor de date. Baze de date relaţionale 39

Page 159: licenta hatz

Observaţie. Teorema lui Delobel satisface condiţiile teoremei lui Ullman. Într-adevăr, DF aplică A= R1∩ R2 în B= R1- R2. Din cele de mai sus rezultă că descompunerea pe baza teoremei lui Ullman conservă datele.

Fie R o relaţie, F, o mulţime de dependenţe de tip DF în R şi A un grup de atribute. Se numeşte proiecţia mulţimii F pe A şi se notează cu F(A), mulţimea tuturor dependenţelor din închiderea lui F, de forma, DF:B→C, cu B,C submulţimi din A.

Fie R1, R2,..., Rn o partiţionare a lui R. Această partiţionare conservă dependenţele dacă şi numai dacă închiderea lui F , notată cu F+ este egală cu reuniunea dependenţelor F(Ri) pentru i=1,2,...,n.

Observaţie. Cele două tipuri de conservări sunt independente. Pentru argumentarea acestor afirmaţii vom considera două exemple.

p Fie R(A,B,C), o relaţie definită pe atributele A,B,C cu F = A→B, B→C. Fie descompunerea lui R în R1(A,B), R2(B,C). Se poate observa că descompunerea conservă datele, deci este reversibilă, deoarece R1∩ R2 =B→C= R2- R1. F nu conservă însă dependenţele deoarece A→C care face parte din F+, dar nu face parte din reuniunea lui F(R1) cu F(R2).

q Dacă considerăm însă analog R(A,B,C,D) şi F = A→B, C→D, descompunerea lui R în R1(A,B), R2(C,D) conservă dependenţele, deoarece F+=F(R1)U F(R2), dar nu conservă datele, deoarece R1∩ R2 =Φ şi deci nu există DF la R1- R2 sau R2-R1.

Cele de mai sus se pot concluziona sub forma teoremei lui Rissanen (1978): Fie R1, R2 o descompunere a lui R şi F mulţimea dependenţelor din R. Descompunerea este reversibilă şi conservă dependenţele din F dacă şi numai dacă:

p F poate fi dedus din F(R1) şi F(R2) (conservă dependenţele).q Atributele comune ale lui R1 şi R2 formează o cheie cel puţin în una din

relaţiile R1 sau R2, adică există o dependenţă de la R1∩ R2 la R1- R2 sauR2- R1.

Observaţii. Aceste probleme au fost tratate de foarte mult timp în literatura de specialitate. Astfel, enumerăm câteva rezultate din domeniu, pe care le considerăm interesante:

6. Teorema lui Delobel asigură reversibilitatea descompunerii dar nu şi conservarea dependenţelor.

7. S-a demonstrat (Ullman 1980), că orice relaţie are cel puţin o descompunere reversibilă în 3NF, cu conservarea dependenţelor. El a dat şi un algoritm pentru o astfel de descompunere.

Page 160: licenta hatz
Page 161: licenta hatz

1. SISTEME DE BAZE DE DATE DISTRIBUITE1

Autor: Dan Andrei Sitar Tăut

1.1 Introducere în sisteme de baze de date distribuite

Bazele şi sistemele distribuite au apărut într-un moment în care tehnologia bazelor de date şi cea a reţelelor erau destul de avansate individual, însă la nivelul integrării lor, lucrurile nu stăteau atât de bine.

Un exponent al hibridizării celor două tehnologii amintite este sistemul cu prelucrare distribuită, adică un sistem centralizat de baze de date. Este un precursor al sistemelor distribuite şi implică accesarea unei singure baze de date (baza de date centrală) prin intermediul unei reţele de calculatoare. Punctele forte ale acestor sisteme ar fi integrarea aplicaţiilor şi a datelor din cadrul unei organizaţii şi simplitatea proiectării. Neajunsurile se referă la rezolvarea problemei accesului concurent, vulnerabilitatea şi disponibilitatea nodului central, număr relativ scăzut de utilizatori şi accese concomitente, precum şi viteza scăzută şi „distanţa” acceselor.

Deşi considerate de mulţi ca fiind destul de primitive, sistemele centralizate deţin încă o cotă destul de ridicată în implementările existente şi de multe ori constituie o variantă mult mai bună – de regulă pentru „comunităţile informatice” de dimensiuni mici – decât sistemele distribuite. Totuşi, atât comunitatea academică, cât şi cea economică au consimţit că e nevoie să se facă un nou pas în evoluţia integrării bazelor de date cu reţelele de calculatoare.

De-a lungul timpului în literatura de specialitate au fost formulate o serie de definiţii ale bazelor de date distribuite.

Definiţie: O bază de date distribuită reprezintă o colecţie de date integrate logic, însă repartizate2 fizic pe siturile3 unei reţele de calculatoare [Gardarin & Valduriez 1989], [Lungu et al. 1995], [Connolly et al. 2001], [Messaoui 2001] etc.

Aşadar, o bază de date distribuită e un ansamblu de baze de date administrate de diferite situri, dar care apar pentru utilizator ca o bază unică. Ele sunt proiectate sub forma unor colecţii de date integrate, omogene sau nu, împrăştiate cu discernământ într-o reţea de calculatoare sub forma unei baze de date globale. [Schmitt & Saake 2005]

În majoritatea cazurilor definiţiile surprind două elemente importante:Integrarea logică. Se referă la aspectul că datele înmagazinate nu sunt simple

colecţii de fişiere. Ele reprezintă o structură bine organizată pe care utilizatorul – potrivit unor principii ce vor fi enunţate ulterior – trebuie s-o perceapă ca făcând parte dintr-o singură bază de date globală, la fel ca şi în cazul bazelor de date locale sau centralizate;

Repartizarea fizică. Relevă faptul că baza de date nu este stocată într-o singură locaţie, precum în cazul bazelor de date locale şi sistemelor centralizate, ci este împărţităîntre mai multe staţii de lucru.

10 Acest material este preluat/adaptat după [Sitar 2005]11 în general în literatura de specialitate se foloseşte termenul „distribuit”. Am evitat utilizarea unor definiţii recursive, pentru a nu spune că bazele de date distribuite sunt ceva ... distribuit.12 vom utiliza în general noţiunea de sit, ca sinonim pentru ”site”, „nod”, „staţie” etc.

Page 162: licenta hatz

Sisteme de baze de date distribuite

Page 163: licenta hatz

Prin natura lor, datele din cadrul unei organizaţii sunt dispersate atât logic, cât şi fizic. Angajaţii colaborează la realizarea unui proiectul prin intermediul a mai multe calculatoare amplasate fizic în birouri, clădiri, ateliere specifice etc. Accesarea se poate face de pe aceeaşi maşină de calcul sau de pe maşini diferite, indiferent de apartenenţa utilizatorului la un anumit departament sau birou. La fel, baza de date poate fi şi ea plasată într-o singură locaţie sau în locaţii diferite. Dispersarea poate să se facă depăşind bariera unui birou sau a unei clădiri, ajungându-se în secţiile sau atelierele unităţii de producţie sau în diferite sucursale, agenţii sau puncte de lucru ale organizaţiei respective răspândite în diverse colţuri ale unui oraş, ţară, continent, sau chiar ale lumii. În exemplele furnizate în acest capitol vom considera o bază de date care reflectă evidenţa studenţilor facultăţii noastre în condiţiile unei activităţi repartizate pe secretariate din doar două locaţii posibile: Cluj-Napoca şi Sighetu Marmaţiei.

Apariţia reţelelor de calculatoare a fost un prim pas în integrarea informaţiei existente într-o companie. Integrarea tehnologiei bazelor de date cu cea a reţelelor a dat naştere unei tehnologii mult mai puternice decât era fiecare dintre cele două domenii anterior momentului hibridizării. Deşi explozivă, dezvoltarea s-a făcut în trepte de evoluţie. Cu toate acestea, nici acum şi niciodată nu vom putea spune că s-a epuizat cu totul acest domeniu.

Sistemele de Gestiune a Bazelor de Date Distribuite (SGBDD4) au ca obiectiv crearea unei „punţi” între „insulele de informaţii”. Ideea unui astfel de sistem este de a face accesibile toate datele necesare funcţionării unei organizaţii, oriunde s-ar afla ele, şi de a le răspândi fizic, dacă este cazul, în acele locaţii unde vor fi utilizate cel mai des. [Date 2005] SGBDD-ul este o extensie software şi funcţională a sistemelor SGBD locale.

Definiţie: Un sistem de gestiune al bazelor de date distribuite reprezintă sistemul software care permite gestiunea bazelor de date distribuite, făcând distribuirea fizică transparentă pentru utilizatori [Gardarin & Valduriez 1989], [Connolly et al. 2001].

Atunci când se vorbeşte despre sisteme distribuite, cei mai utilizaţi termeni sunt: fragmentare, alocare şi replicare.

1.2 Fragmentarea

În literatura de specialitate, pentru conceptul de fragmentare se foloseşte alternativ şi denumirea de partiţionare.

Definiţie: Fragmentarea reprezintă procedeul de spargere a relaţiilor utilizate într-un sistem distribuit prin operaţiuni relaţionale de proiecţie şi selecţie controlate, în vederea plasării aşa-numitelor partiţii (fragmente) rezultate în locul în care sunt cel mai frecvent solicitate datele pe care le conţin.

Fragmentarea reprezintă o abordare a dimensiunii bazei de date, care se realizează prin divizarea tabelelor de date în unul sau mai multe fragmente disjuncte, în scopul stocării fizice.

[Connolly et al. 2001] consideră următoarele motive ca fiind premisele de bază în favoarea recurgerii la fragmentare:

Uzanţa. În aplicaţiile proiectate pentru baze de date – în general, multiutilizator – se practică frecvent utilizarea tabelelor virtuale în detrimentul relaţiilor întregi. De cele mai multe ori un operator nu are nevoie de toate informaţiile, atât ca şi structură, cât şi ca şi

4 în literatura de specialitate se utilizează abrevierea DDBMS, acronim pentru DistributedDataBase Management Systems

Page 164: licenta hatz

Sisteme de baze de date distribuite

Page 165: licenta hatz

conţinut, pe care o relaţie întreagă este capabilă să le furnizeze. Astfel, acesta poate să se concentreze strict asupra problemelor cu care interacţionează şi nu asupra unor aspecte colaterale. Datorită acestui aspect, unitatea atomică de proiectare şi utilizare în cadrul unor astfel de sisteme, nu va fi relaţia (de cele mai multe ori), ci o subdiviziune a acesteia;

Eficienţa. Distribuirea unor relaţii întregi pe diferite staţii de lucru ar anula aspectul „semantic” al siturilor în funcţionalitatea sistemului distribuit. Cu ce ar ajuta dacă în situl X localizat în Cluj-Napoca am avea stocată relaţia ce conţine materiile de studiu, iar pe nodul Y aflat în Sighetu Marmaţiei am avea relaţia care conţine datele de identificare a tuturor studenţilor? În mod uzual secretariatul din Cluj-Napoca (X) ar dori să utilizeze informaţiile privind studenţii care frecventează cursurile în Cluj-Napoca, iar cel din Sighet (Y), informaţiile referitoare la cei din Sighet;

Paralelismul. Mai multe fragmente ale unei baze de date permit sporirea accesului concurent. Mai mult, sistemul va fi capabil să răspundă aproximativ în acelaşi timp la mai multe cereri tocmai datorită acestui aspect. De exemplu, mult mai rapid se va răspunde unor cereri lansate simultan, una de pe situl X şi una de pe Y, în cazul în care X solicită mediile studenţilor ce frecventează cursurile în Cluj-Napoca, iar Y ale celor din Sighet. Dacă relaţia ce conţine toţi studenţii ar fi stocată într-un singur loc – să zicem în Sighet – rezolvarea cererilor ar fi încetinită de secvenţialitatea procesării (mai întâi una din cereri, apoi cealaltă) sau întârzieri datorate metodelor de gestionare a accesului concurent, dimensiunea mai mare a relaţiei (prelucrare mai greoaie), şi nu în ultimul rând, distanţa;

Securitatea. În ceea ce priveşte securitatea, un atac din partea unor persoane rău-voitoare n-ar afecta funcţionarea întregului sistem (şi în general chiar deloc, datorită replicării datelor) în cazul unui atac asupra unui sit, care conţine doar câteva fragmente ale bazei de date şi nicidecum întreaga bază sau relaţii întregi. Pentru succesul atacului acesta ar trebui să fie direcţionat asupra mai multor noduri, iar probabilitatea unui asemenea eveniment este mult mai mică decât cea a reuşitei asupra unui singur nod.

Cu toate punctele tari, aceasta prezintă şi unele dezavantaje:Complexitatea proiectării. Un sistem distribuit este mai greu de proiectat decât

unul nedistribuit. Existenţa fragmentelor implică o serie de factori suplimentari, cum ar fi de exemplu stabilirea locaţiei unui fragment, optimizarea interogărilor etc.;

Performanţa. Chiar dacă în general, datorită unei alocări eficiente a fragmentelor, performanţele unui sistem distribuit sunt mai mari decât ale unui sistem nedistribuit, lucrurile se pot complica în cazul unor interogări mai complexe ce solicită informaţii prea disparate(de pe mai multe situri);

Controlul integrităţii. Păstrarea integrităţii bazei de date este dezideratul primordial al oricărui sistem tranzacţional. Faţă de abordarea în cazul unui sistem centralizat, existenţa fragmentelor răspândite pe siturile sistemului, complică lucrurile.

Fragmentarea nu poate fi făcută la voia întâmplării. Fragmentele rezultate trebuie să îndeplinească anumite condiţii de la care nu se poate face rabat:

Completitudinea fragmentării. Divizarea unei relaţii în fragmente trebuie făcută de aşa manieră încât, fragmentele rezultate, să asigure acoperirea întregii relaţii iniţiale. Potrivit acestei cerinţe, fragmentarea are ca obiectiv eliminarea apariţiei pierderilor informaţionale şi nu cea a redundanţelor.Refacerea relaţiei iniţiale. Fragmentarea se face astfel încât, în orice moment să poată fi reprodusă relaţia iniţială din care fragmentele provin. Operatorii de recompunere trebuie să fie strict relaţionali.Caracterul disjunct [Connolly et al. 2001]. Fragmentele provenite din aceeaşi relaţie trebuie să fie disjuncte, adică să nu se suprapună, atât ca tuple cât şi ca atribute. La această condiţie avem şi o excepţie de la regulă, firească de altfel. Pentru a nu pierde

Page 166: licenta hatz

Sisteme de baze de date distribuite

Page 167: licenta hatz

legătura între datele unui tuplu şi pentru a putea face recompunerea cu uşurinţă, cheile primare trebuie replicate pentru fiecare fragment creat de-a lungul atributelor.

În funcţie de operatorii relaţionali care se aplică asupra relaţiilor, fragmentarea (partiţionarea) poate fi de mai multe tipuri: orizontală, verticală şi mixtă. Pe lângă aceste tipuri clasice, uneori situaţia impune necesitatea unor fragmentări derivate sau chiar a unor relaţii nefragmentate. Toate acestea vor fi discutate mai pe larg în paragrafele următoare.

Limitele în care se încadrează fragmentarea sunt de la un tuplu, atribut, o valoare a unui tuplu, până la întreaga relaţie sau bază de date (în cazul fragmentării derivate). Între aceste graniţe se află granulaţia fragmentării. Ce, cum şi cât fragmentăm sunt întrebările pe care şi le pun toţi proiectanţii de baze de date.

1.2.1 Fragmentarea orizontală

Fragmentarea orizontală, după cum sugerează numele, se face de-a lungul tuplelor unei relaţii. Aşadar, un fragment orizontal, este format dintr-o submulţime a tuplurilor unei relaţii, submulţime obţinută în urma unei operaţii de restricţie. Restricţia trebuie să asigure o descompunere ortogonală în fragmente orizontale.

Reprezentarea simbolică a unui fragment orizontal F, realizat pe baza unei relaţii R, prin specificarea modalităţii de obţinere, este următoarea:

Fi: σp(R), unde Fi reprezintă numele fragmentului, p fiind „un predicat bazat pe unul sau mai multe atribute ale relaţiei” [Connolly et al. 2001], iar R reprezintă denumirea relaţiei. σ este simbolul operaţiei de restricţie (selecţie).

Să presupunem că în relaţia STUDENT avem atributul Locatia, a cărui valori indică locul unde urmează cursurile studenţii de la FSEGA Cluj-Napoca. Considerând că aceştia pot să fie într-una din cele două locaţii posibile, avem fragmentele:

CJ_STUD: σLocatia = ”Cluj-Napoca”(STUDENT)SM_STUD: σLocatia = ”Sighetu Marmatiei”(STUDENT)Deci, vom avea două fragmente. Fragmentul CJ_STUD pentru studenţii înscrişi la

FSEGA Cluj-Napoca şi urmează cursurile în Cluj-Napoca şi fragmentul SM_STUD pentru studenţii înscrişi la FSEGA Cluj-Napoca, dar care frecventează cursurile în Sighetu Marmaţiei. Cele două fragmente îndeplinesc cele trei reguli de bază.

După cum s-a văzut, fragmentarea orizontală se realizează prin operaţiuni de selecţie aplicate relaţiei globale. În proiectarea fragmentelor se ţine cont de aspectul logic şi cel statistic. Componenta logică a unui fragment este dată de predicatul pe baza căruia se face fragmentarea. Acesta poartă numele şi de calificare. Proprietăţile statistice se referă la afinitatea (număr şi frecvenţă) unor aplicaţii sau cereri pentru fragmentul în cauză. [Lunguet al. 1995]

Predicatele pe baza cărora se abordează problematica fragmentării orizontale sunt predicatele minterm. Ele sunt conjuncţii de predicate simple sau negaţii ale acestora.Predicatele simple sunt de forma pi: Aj <valoare>, i=1, 2, ... ,n, iar A1, ...,Am reprezintăatributele relaţiei, iar ia una din valorile =, <, >, <=, >=.

Fie următoarul set de predicate simple: p1: CodSectie = 1, p2: CodSectie = 2, p3:CodSectie > 2, p4: Media < 8, p5: Media >= 8. Predicatele minterm aferente sunt:

m1: CodSectie = 1 Media < 8 m5: CodSectie = 2 Media < 8m2: CodSectie = 1 ~(Media < 8) m6: CodSectie = 2 ~(Media < 8)m3: CodSectie = 1 Media >= 8 m7: CodSectie = 2 Media >= 8m4: CodSectie = 1 ~(Media >= 8) m8: CodSectie = 2 ~(Media >= 8)...

Page 168: licenta hatz

Sisteme de baze de date distribuite

Page 169: licenta hatz

În ceea ce priveşte aspectul semantic al acestui tip de predicate, putem spune că unele sunt fără înţeles. Nu este cazul nostru, decât dacă am fi construit predicate minterm şi între p1 şi p2, respectiv între p3, p4 şi p5. Un alt aspect se referă la faptul că unele predicate minterm se suprapun (de exemplu m1 cu m4). Mai mult, pot să apară contradicţii în cazul unui astfel de predicat, ceea ce ar avea drept urmare constituirea unui fragment vid. Spre exemplu, un predicat simplu ar referi studenţii cu numărul matricol între 8.000 şi 10.000, iar un altul studenţii din anul 3. Întâmplător, chiar aceşti studenţi din anul 3 au numerele matricole chiar între intervalele stabilite. Acest lucru va conduce la eliminarea a două predicate minterm. Mai mult, în acest caz particular, cele două predicate sunt echivalente.

Un predicat este considerat relevant în raport cu un set de predicate date dacă prezenţa sa influenţează setul de tuple al selecţiei referite de o aplicaţie.

În termeni formali, fie două predicate minterm mi şi mj care diferă prin faptul că

unul conţine pi, iar celălalt ~

pi. Cele două predicate minterm determină fragmentele fi şi fj. pi este relevant în raport su setul de atribute dacă şi numai dacă:

acc(mi)/card(fi) acc(mj)/card(fj). [Sacca & Wiederhold 1985]Un set de predicate se consideră complet dacă şi numai dacă probabilitatea de

referire a două tupluri din cadrul aceluiaşi fragment este egală.Un set de predicate este minimal dacă şi numai dacă toate predicatele sunt relevante. La

capitolul informaţii cantitative putem defini selectivitatea predicatului minterm (cardinalitatea selecţiei); frecvenţa accesului: (frecvenţa accesării datelor de către

aplicaţii).În cazul în care avem n predicate simple, atunci numărul predicatelor minterm ce

pot fi definite pe baza acestora este de 2n. Acesta este numărul maxim teoretic de fragmente orizontale care pot fi constituite. Totuşi, acest număr poate fi redus prin simplul fapt că o serie de predicate se pot suprapune sau devin contradictorii intern.

1.2.2 Fragmentarea verticală

Fragmentarea verticală reprezintă o descompunere de-a lungul atributelor unei relaţii. Realizarea acesteia presupune operaţii de proiecţie asupra atributelor, prin includerea în cazul fiecărui fragment a unei chei alternative a relaţiei. Scopul includerii acesteia este obţinerea unei descompuneri fără pierderi, deci una care să verifice fără probleme cele trei condiţii impuse fragmentării, de orice fel ar fi ea.

Simbolistica reprezentării unui fragment vertical Fi obţinut prin proiecţia atributelor a1, a2, ..., an ale unei relaţii R este următoarea:

Fi: Πa1, a2, ... ,an(R), unde simbolul Π reprezintă însemnul proiecţiei din algebrarelaţională.

Pentru exemplificarea acestui nou tip de fragmentare vom lua cazul relaţiei LOCALITATI(CodLoc, Loc, CodJud), prezentată în subcapitolele anterioare. Numărul redus de atribute şi dimensiunea unui tuplu, precum şi a relaţiei în sine, nu ar justifica o astfel de fragmentare. Totuşi putem avea următoarele fragmente:

L_LOC: ΠCodLoc, Loc(LOCALITATI)J_LOC: ΠCodLoc, CodJud(LOCALITATI)În ambele fragmente a trebuit să includem cheia primară a relaţiei LOCALITATI

şi respectă cele 3 reguli, recompunerea relaţiei iniţiale presupunând operaţia de JOIN.Partiţionarea verticală e mult mai complexă decât cea orizontală. Am văzut că în

cazul fragmentării orizontale numărul de variante posibile la un număr dat (n) de predicate

Page 170: licenta hatz

Sisteme de baze de date distribuite

Page 171: licenta hatz

simple este 2n. Există păreri cum că la un număr dat de m atribute non-cheie ale unei relaţii, numărul de variante este determinat de o funcţia B(m), care reprezintă al m-lea număr Bell. [Niamir 1978] Pentru valori mai mari ale lui m, numărul de variante posibile tinde spre 10m. Pentru m=15, B(m) 109, iar pentru m=30, B(m) 1023.

Există două modalităţi de abordare a proiectării fragmentării verticale:Gruparea atributelor. A fost propusă pentru prima dată spre a fi utilizată în

bazele de date centralizate în 1978 [Niamir 1978], iar mai apoi, în 1985 [Sacca & Wiederhold 1985], în bazele de date distribuite. Presupune iniţial stabilirea câte unui fragment pentru fiecare atribut. Apoi, până la satisfacerea unor criterii stabilite se agregă noi atribute. Această tehnică încalcă proprietatea de disjunctivitate a fragmentelor. De aceea, se recomandă ca atributele replicate să nu fie deloc, sau eventual doar foarte rar actualizate [Lungu et al. 1995];

Partiţionarea atributelor. Tehnica a fost discutată şi propusă pentru bazele de date centralizate [Hoffer & Severance 1975], pentru a fi extinsă [Navathe et al. 1984] şi în cazul bazelor de date distribuite. Se porneşte de la schema iniţială a relaţiei şi pe baza unor criterii statistice (număr de accese din partea aplicaţiilor).

În general se aplică cea de-a doua metodă. Pentru stabilirea atributelor care vor face parte dintr-un anumit fragment se vor identifica mai întâi aplicaţiile (cererile) care acţionează asupra acestor atribute. Se va determina matricea afinităţilor dintre atribute, iar apoi se va utiliza algoritmului energiei de angajament (BEA5), propus de Mc Cormick [Mohan et al. 1986], care este special proiectat pentru a grupa atributele cu afinităţi apropiate. Efortul computaţional al acestuia este rezonabil (O(n2)), iar în plus permite şi determinarea legăturilor secundare dintre diferitele grupuri de atribute. [Hoffer & Severance 1975] Algoritmul se bazează pe permutarea coloanelor şi liniilor matricei de afinitate şi obţinerii matricei de afinitate partiţionată. Permutările trebuie făcute de aşa manieră încât să se maximizeze cuantumul afinităţii globale.

Deoarece şi matricea care va rezulta este o matrice simetrică, formula de maximizare a afinităţii globale poate fi redusă la:

n n

aff (Ai , Aj )[aff (Ai , Aj 1 ) aff (Ai , Aj 1 )]6

i 1 j 1Crearea matricei este un proces iterativ care presupune mai întâi mutarea unei

singure coloane în noua matrice, apoi plasarea celorlalte în aşa manieră încât să fie în acord cu condiţiile expuse anterior. După plasarea tuturor coloanelor, şi liniile trebuie interschimbate astfel încât să potrivească poziţia relativă a coloanelor.

După găsirea matricei de afinitate partiţionată, pe diagonala matricei trebuie să fixăm un punct, numit punct de divizare, care împarte mulţimea atributelor relaţiei în două submulţimi formate din atributele A1, A2, Ai, respectiv Ai+1, An, alcătuind matricele (pătratele) TA7 şi BA8.

După identificarea posibilelor fragmente în funcţie de afinităţile atributelor şi frecvenţelor aplicaţiilor care le solicită este necesară efectuarea procedurii de verificare a celor trei condiţii definitorii ale fragmentării. Singura de la care putem face rabat într-o anumită măsură ar fi cea de disjunctivitate a fragmentelor. Aşa cum am mai menţionat, în

1 Bond Energy Algorithm2formulă preluată din [Őzsu & Valduriez 1991], pagina 1263Top Attributes4Bottom Attributes

Page 172: licenta hatz

Sisteme de baze de date distribuite

Page 173: licenta hatz

cazul fragmentelor verticale disjunctivitatea nu poate fi realizată în proporţie de 100%, decât atunci când se folosesc identificatoare de tuplu, invizibile pentru utilizator. În celelalte cazuri, pentru fiecare fragment în parte trebuie să se replice cheia primară.

1.2.3 Fragmentarea mixtă

Fragmentarea mixtă – numită şi hibridă de către unii autori – nu reprezintă un tip special de fragmentare, ci o combinaţie a celorlalte două enunţate anterior. Combinaţia se datorează aplicării celor doi operatori din algebra relaţională utilizaţi pentru fragmentarea pe orizontală şi pentru cea pe verticală. În funcţie de ordinea în care sunt aplicaţi, putem să avem două tipuri de fragmentări mixte. Dacă mai întâi avem o operaţie de selecţie, urmată apoi pentru fiecare fragment, de operaţii de proiecţie obţinem fragmente orizontale partiţionate vertical. Dacă ordinea operaţiilor este inversată, atunci vom avea fragmente verticale partiţionate orizontal.

În reprezentarea simbolică se vor folosi notaţiile deja amintite. Un astfel de fragment poate fi descris ca fiind rezultatul aplicării fie a unei operaţii de proiecţie asupra uneia de restricţie, fie rezultatul unei restricţii aplicat asupra rezultatului unei proiecţii:

Fi: Πa1, a2, ... ,an(σp(R)) sau Fj: σp(Πa1, a2, ... ,an(R))În Figura 6. 1 – Tipuri de fragmente mixte sunt prezentate cele două tipuri de

fragmentări mixte:F1 F2 F1 F3 F4

F3 F4 F5F2

F5

F6 F6Figura 6. 1 – Tipuri de fragmente mixte

Din imagine se poate observa caracterul complet al fragmentării mixte, indiferentde cazul analizat. Cele 6 fragmente acoperă pe de-a-ntregul relaţia studiată.

Reconstrucţia se face prin operaţii de uniune şi reuniune.R = (F1 F2) U (F3 F4 F5) U F6, sauR = (F1 U F2) F3 (F4 U F5 U F6).Caracterul disjunct poate fi sesizat cu uşurinţă din figură prin faptul că niciun

fragment nu încalcă „teritoriul” unui alt fragment.

1.2.4 Fragmentarea derivată

Fragmentarea derivată reprezintă un tip mai aparte de fragmentare, chiar dacă în practică este posibil a fi cel mai des întâlnită. Până acum s-a vorbit de fragmentări a căror sursă erau relaţii întregi stocate în cadrul a diferitelor situri. Fragmentarea de care vorbim este impusă de anumite nevoi practice menite să optimizeze accesul la date prin reducerea timpului de transmisie. Fragmentarea derivată este o fragmentare orizontală care se face între două relaţii: una părinte şi cealaltă fiu. Se va porni de la relaţia copil, care va fi fragmentată conform predicatului prestabilit. Predicatul implică în mod obligatoriu cheia externă.

Page 174: licenta hatz

Sisteme de baze de date distribuite

Page 175: licenta hatz

1.2.5 Relaţii nefragmentate

În anumite cazuri fragmentarea ar fi mai degrabă un disconfort decât un lucru care să aducă într-adevăr performanţe sistemului. Aşadar, nu întotdeauna fragmentarea va fi eficientă şi de aceea nici nu va fi aplicată. Relaţiile care se pretează la o astfel de abordare sunt acelea care au un număr relativ mic de înregistrări. În astfel de situaţii se recomandă fie replicarea acestora pe fiecare sit în parte, fie menţinerea lor în acele noduri unde se utilizează cel mai des, iar în cazul unei cereri la distanţă care le solicită, strategia optimă ar fi cea de mutare a acestei relaţii, şi nu a celorlalte, fie în situl din care s-a solicitat cererea, fie într-un alt sit în care există deja una sau mai multe din relaţiile implicate.

1.3 Replicarea

Unul din aspectele importante ce caracterizează sistemele distribuite este fiabilitatea şi disponibilitatea. Aceasta înseamnă că o pană în unul dintre siturile sistemului nu va paraliza funcţionarea sistemului şi nici nu va afecta disponibilitatea datelor care au fost înmagazinate în situl respectiv. Atingerea acestei performanţe nu se poate realiza decât cu ajutorul replicării fragmentelor.

Replicarea – cunoscută în literatura de specialitate şi ca reproducere – presupune copierea unor fragmente în mai multe locaţii. Într-o bază de date distribuită există mai multe nivele de replicare. Astfel, avem:

Baze de date centralizate. Sunt sistemele cu prelucrare distribuită (centralizate), în care avem o singură bază de date stocată pe nodul central. La fel avem un singur SGBD. Caracterul local al referinţei este cel mai scăzut, deoarece doar nodul central poate face accesări sau prelucrări locale. Securitatea, fiabilitatea şi disponibilitatea sunt scăzute şi depind în cea mai mare măsură de nodul central. Costul comunicaţiei este ridicat;

Baze de date partiţionate, fragmentate sau nereplicate. Sunt acele baze de date distribuite în care toate fragmentele apar o singură dată. Implementarea se face cu cel mai scăzut cost al stocării. O astfel de bază de date nu oferă fiabilitate şi nici disponibilitate prea ridicate, însă este mai mare decât în cazul sistemelor centralizate. Caracterul local al referinţei este la un nivel acceptabil. Costurile de comunicaţie sunt mai moderate. Actualizările şi consultările se fac eficient;

Baze de date replicate integral. Orice sit conţine câte o copie a întregii baze de date. Caracterul local al referinţei, disponibilitatea, securitatea şi fiabilitatea sunt maxime. Probleme întâmpinăm la costul ridicat al echipamentelor de stocare, comunicaţia aglomerată în cazul actualizărilor. O rezolvare parţială a acestor inconveniente ar fi utilizarea instantaneelor, adică imagini ale bazei de date care se actualizează periodic. Dezavantajul lor este că nu întotdeauna oferă o situaţie actualizată, iar în momentul actualizării se generează trafic mare pe reţea;

Baze de date replicate parţial sau selectiv. Anumite fragmente sunt replicate, altele nu. Sunt replicate fie acele fragmente cu utilizare frecventă, fie relaţii întregi de dimensiuni mici care nu merită să fie fragmentate, ci mai degrabă memorate pe fiecare sit. În această ultimă situaţie intră şi acele relaţii sau fragmente cu actualizări sporadice. Această strategie este o îmbinare a celor 3 enunţate anterior. Încearcă să le preia avantajele şi să le minimizeze dezavantajele. De aceea aceasta se implementează cel mai adesea. Costurile de comunicaţie şi de stocare sunt relativ reduse. Caracterul local al referinţei, securitatea, fiabilitatea şi disponibilitatea sunt apropiate de maxim. [Connolly et al. 2001]

Page 176: licenta hatz

Sisteme de baze de date distribuite

Page 177: licenta hatz

Replicarea favorizează performanţele sistemului la consultare. Atunci când e însă vorba de actualizări, replicarea poate constitui un impediment: se generează trafic suplimentar, pot apărea inconsistenţe datorită indisponibilităţii temporare a unei replici.

1.4 Proiectarea alocării

Alocarea reprezintă procesul de repartizare a fragmentelor pe situri. Să presupunem că avem un set de fragmente F = F1, F2, ..., Fi, ..., Fn într-o reţea formată din siturile S = S1, S2, ..., Sj, ..., Sm şi asupra cărora se execută anumite aplicaţii (interogări) Q = q1, q2,..., qk, ..., qq. Problema proiectării alocării se referă la distribuirea optimă – cost minim, performanţă maximă – a fragmentelor F pe siturile S.

Alocarea poate să fie neredundantă sau redundantă. Alocarea neredundantă este cea mai ieftină în ceea ce priveşte efortul de proiectare şi cea mai uşor de realizat. Un alt avantaj îl conferă posibilitatea de actualizare a fragmentelor. Realizarea unei astfel de proiectări se bazează pe metoda celei mai bune alegeri, care stipulează că unei staţii pe care deja a fost plasat un fragment, nu poate să-i mai fie alocat un fragment „înrudit”. Alocarea redundantă este o problemă de proiectare mult mai complexă. Mai mult, atât consultările de date cât şi actualizările sunt problematice. Există două variante de abordare a proiectării în acest caz:

2.2.1. Metoda selectării. Identificarea acelor situri pentru care beneficiul alocării unei copii depăşeşte costul alocării;

2.2.2. Metoda alocării progresive. Se implementează mai întâi o alocare neredundantă. Apoi, în funcţie de gradul de profitabilitate al staţiilor se vor răspândi replici ale fragmentelor deja alocate, până când nu mai există candidaţi.

Suntem de părere că o abordare mai eficientă, dar şi mai selectivă, ar fi aplicarea metodei celei mai bune alegeri şi în etapa de proliferare a copiilor. Atâta doar că se va începe cu fragmentele considerate ca fiind cele mai importante, ţinându-se cont la fiecare alocare de relaţia de „rudenie” a tuturor fragmentelor ce există sau urmează a fi stocate într-un sit.

6 O arhitectură de referinţă a unui sistem distribuit

După o propunere iniţială din partea grupului DataBase Task Group (DBTG) din 1971 de a standardiza sistemele de baze de date pe două nivele – schemă şi subschemă – în1975 a fost abordată o arhitectură pe trei nivele: extern, conceptual şi intern, care şi-a propus separarea viziunii utilizatorului de modul fizic de reprezentare a datelor. Astfel a rezultat arhitectura ANSI-SPARC pentru sisteme centralizate, prin iniţiativa comună a două organisme: Institutului Naţional American pentru Standarde (ANSI) şi Comitetul de Planificare şi Cerinţe privind Standardele (SPARC). Deşi intenţia era una de standardizare a proiectării acestor sisteme, arhitectura amintită s-a impus doar ca una de referinţă, larg uzitată în mediile academice şi chiar pragmatice ale bazelor de date. [Connolly et al. 2001] Datorită complexităţii domeniului bazelor de date distribuite faţă de cele centralizate, impunerea unei arhitecturi standardizate ar fi cu mult mai greu de realizat. Totuşi, ne permitem să prezentăm o astfel de variantă (vezi Figura 6. 2).

Arhitectura este formată din: schemele externe globale, care reprezintă viziunea fiecărui utilizator asupra sistemului;

Page 178: licenta hatz

Sisteme de baze de date distribuite

Page 179: licenta hatz

o schemă conceptuală globală, adică o imagine completă a întregii baze de date, fără a lăsă măcar pentru vreun moment impresia că aceasta ar putea fi una distribuită;schema de fragmentare, ce reprezintă ideea proiectantului de partiţionare a întregii baze de date;schema de alocare se referă la modul de amplasare fizică a fragmentelor şi replicilor acestora în vederea deservirii optime a interogărilor şi tranzacţiilor sistemului distribuit;

Pentru fiecare sit avem o arhitectură ANSI-SPARC pe trei nivele:schema de transformare reflectă o armonizare de interese între fragmentele amplasate conform schemei de alocare şi vederile utilizatorilor bazei de date locale;schema conceptuală locală este descrierea logică a bazei de date amplasate pe un anumit sit;schema internă locală indică modalitatea de stocare a datelor locale (reprezentarea fizică a bazei de date locale).

Figura 6. 2 – O arhitectură de referinţă pentru un SGBDD9

Avem o singură bază de date cu o singură schemă conceptuală globală. Ţinând cont de schema de fragmentare şi de cea de alocare schema conceptuală globală este implementată pe siturile sistemului distribuit. Fiecare sit prezintă propria schemă internă şi conceptuală, precum şi o schemă de transformare locală. Schemele externe sunt independente de SGBD şi asigură interfaţa cu sistemul distribuit. Ele conferă suport pentru sistemele federative, despre care se va vorbi în subcapitolul Baze de date federative.

Page 180: licenta hatz

9 exemplu preluat din [Connolly et al. 2001], pagina 628

Page 181: licenta hatz

Sisteme de baze de date distribuite

Page 182: licenta hatz

După cum aminteam, arhitectura prezentată este una orientativă, de care se poate sau nu, ţine seama. În funcţie de specificul sistemului distribuit, o serie de componente ale acesteia pot fi ignorate.

1.6 Principiile lui C.J. Date referitoare la sistemele distribuite

Chris J. Date este autorul unor „reguli”10 care privesc îndeaproape sistemele distribuite. El a formulat un set – de fapt, ad-literam, sunt două seturi, o duzină – de astfel de principii pe care sistemele distribuite trebuie sau ar trebui să le respecte. Acestea sunt completate de un principiu fundamental, intitulat „Principiul 0”, „Regula 0”, sau „Regula de aur”. În cele ce urmează le vom trece succint în revistă.

Principiul fundamental al bazelor de date distribuite stipulează că „pentru utilizator, sistemul distribuit trebuie să arate” – am completa noi: şi să se comporte – „la fel cu unul nedistribuit”. [Date 2005]

Aşadar, indiferent dacă utilizatorul doreşte să acceseze sau să prelucreze date care sunt stocate în situl X, Y sau Z, acesta să nu perceapă faptul că de oriunde şi-ar lansa cererile– să spunem situl A, B sau C – sistemul se comportă în acelaşi mod ca şi cum datele ar fi fost locale (de pe A, B sau C), deci să nu trădeze faptul că ele au fost chemate din situl X, Y sau Z. Conceptul fundamental este succint, însă prea sumar pentru un domeniu atât de complex precum sistemele distribuite. De aceea, autorul se simte obligat să facă o detaliere a tuturor aspectelor de ordin mai tehnic, pe care „regula de aur” le presupune. Acestea sunt:autonomia locală, absenţa unei dependenţe de un sit central, operarea continuă, independenţa de fragmentare11, independenţa de localizare, independenţa de replicare, prelucrarea distribuită a interogărilor, gestionarea distribuită a tranzacţiilor, independenţa de hardware, independenţa de sistemul de operare, independenţa de reţea şi independenţa de sistemul SGBD.

1.7 Procesarea şi optimizarea cererilor

La începuturi, s-a lucrat destul de mult la capitolul „prelucrare interogări” pentru bazele de date relaţionale, deoarece acestea ofereau o gamă generoasă de oportunităţi de optimizare. Limbajul de interogare putea să fie bazat atât pe algebră relaţională, cât şi pe calcul relaţional. În cazul limbajelor pe calcul relaţional era necesară o fază suplimentară de translatare a interogărilor în algebra relaţională. Acum însă, în contextul sistemelor distribuite, această etapă este înglobată direct în sistem. [Gardarin & Valduriez 1989]

Potrivit aceleiaşi lucrări, procesarea interogărilor presupune 4 etape importante: Descompunerea interogărilor, Localizarea datelor, Optimizarea cererilor globale şiOptimizarea cererilor locale.

Primele trei etape sunt executate la nivel centralizat, pe când ultima la nivelul siturilor locale. Descompunere a interogărilor, împreună cu localizare datelor sunt considerate ca fiind modalităţi de abordare a optimizării cererilor globale. Mai mult, se introduce şi o extensie a algebrei relaţionale intitulată algebra relaţiilor calificate, utilizatăîn optimizare.

3.3. aşa au fost intitulate de către Date în prima lucrare pe această temă3.4. în lucrarea originală aceasta este prezentată după independenţa de localizare

Page 183: licenta hatz

Sisteme de baze de date distribuite

Page 184: licenta hatz

1.8 Gestiunea accesului concurent în medii distribuite

Gestiunea tranzacţiilor acoperă problema accesului concurent şi refacerea sistemului în caz de defecţiuni. Materialul de faţă nu-şi propune trecerea în revistă a protocoalelor care se referă la cel de-al doilea aspect al gestiunii tranzacţiilor.

Faţă de mediul cu prelucrare distribuită, într-un sistem de baze de date distribuite protocoalele de acces sunt mai complexe, lucru care va putea fi observat şi în cele ce urmează.

Într-un sistem centralizat subsistemul tranzacţional al unui SGBD este format din: administratorul de tranzacţii, planificator, administratorul de refacere şi administratorul de buffere (memorie-tampon). Administratorul de tranzacţii dirijează execuţia tranzacţiilor. În funcţie de caracteristicile tranzacţiei, planificatorul va hotărî ce strategie de control a concurenţei se va impune în această situaţie. Această strategie trebuie să maximizeze gradul de concurenţă, fără însă să cauzeze interferenţă cu alte tranzacţii. Administratorul de refacere intervine atunci când execuţia a fost întreruptă sau perturbată de anumite incidente. Rolul său este de a repune în funcţiune sistemul şi de a aduce baza de date în cea mai apropiată stare de consistenţă posibilă. Administratorul de buffere gestionează memoria tampon aferentă execuţiei tranzacţiilor şi asigură transferul bidirecţional între memoria de lucru şi dispozitivul fizic de stocare.

Toate aceste componente există în cadrul fiecărui sit al unui sistem distribuit. Pe lângă acestea mai avem şi câte un administrator de tranzacţii global sau coordonator de tranzacţii responsabil cu execuţia tranzacţiilor globale sau locale iniţiate de situl respectiv. Comunicarea dintre situri se realizează prin intermediul componentei de comunicaţii de date, care nu este specifică procesului tranzacţional.

În sistemele distribuite un mecanism de control al concurenţei trebuie să fie flexibil la căderile parţiale ale sistemului, să permită un grad înalt de paralelism al tranzacţiilor în condiţiile menţinerii integrităţii bazei de date, să genereze un trafic rezonabil al reţelei şi să nu suprasolicite resursele sistemului. [Kohler 1981]

Controlul concurenţei tranzacţiilor în cazul unui sistem centralizat se referă la evitarea următoarelor posibile anomalii ce caracterizează execuţia simultană a unor tranzacţii ce reclamă aceleaşi resurse: actualizarea pierdută, dependenţa nefinalizată şi analiza inconsistentă. O metodă de evitare a acestora este transformarea accesului concurent în acces secvenţial. O soluţie cu aplicabilitate doar teoretică, însă totuşi de referinţă. Rezultatul execuţiilor seriale este reperul în controlul corectitudinii execuţiilor paralele. Aşadar, atunci când există posibilitatea interferării a două sau mai multe tranzacţii, o planificare este considerată o soluţie bună din acest punct de vedere dacă şi numai dacă rezultatul ei este identic cu al unei planificări seriale. O astfel de planificare se numeşte serializabilă. Identificarea tuturor sau doar uneia din aceste planificări în momentul execuţiei nu constituie o soluţie pragmatică rezonabilă. De aceea se recomandă utilizarea unor metode dovedite că garantează planificări serializabile. În funcţie de gradul de concurenţă al tranzacţiilor dintr-un sistem, de probabilitatea de apariţie a interferenţelor şi de complexitatea şi costul implementării anumitor strategii se pot aplica metode pesimiste, optimiste şi mixte. [Sitar 2004-2], [Sitar 2004-3] şi [Sitar 2005]

Pe lângă anomaliile ce pot să intervină în cazul în care nu se aplică vreo metodă suplimentară de protecţie, în mediul distribuit mai poate să apară problema incoerenţei copiilor multiple. Aceasta apare în special la bazele de date cu fragmente replicate total sau parţial, dar şi atunci când e vorba de actualizarea dicţionarelor sau cataloagelor.

Problematica tranzacţiilor din cadrul unui sistem distribuit este însă mai complexă. Şi în sistemele distribuite, tranzacţiile – atât cea globală cât şi cele locale – trebuie să respecte

Page 185: licenta hatz

Sisteme de baze de date distribuite

Page 186: licenta hatz

proprietăţile ACID. Respectarea acestora se face cu sacrificii mai mari decât în cazul sistemelor centralizate, aici existând mult mai multe tentaţii de eludare a lor. Cu cât într-un sistem coexistă în acelaşi moment mai multe tranzacţii care îşi pot disputa aceleaşi date, cu atât gestiunea tranzacţiilor devine mai complexă. Tranzacţiile globale, subtranzacţiile acestora şi toate celelalte care rulează la un moment dat, trebuie să asigure transparenţa la nivelul concurenţei şi a toleranţei la defecte.

În sistemele distribuite controlul accesului concurent se poate face prin: blocare(Protocolul 2PL centralizat, Protocolul 2PL de copie primară, Protocolul 2PL distribuit şi Protocolul de zăvorâre a majorităţii) sau prin utilizarea mărcilor de timp.

1.9 Avantajele şi dezavantajele sistemelor distribuite

Orice lucru are atât avantaje cât şi dezavantaje. O gândire raţională se va orienta evident spre acele lucruri ale căror avantaje sunt mai mari – dacă se poate chiar să surclaseze– decât dezavantajele. În general nu putem cuantifica raportul avantaje/dezavantaje la nivel absolut. Întotdeauna în evaluarea calităţilor sau defectelor se are în vedere un etalon. Putem spune că un obiect este mai bun decât altul în funcţie de un criteriu valabil în anumite circumstanţe: loc, timp, cost, variante disponibile etc. În această categorie intră şi sistemele de baze de date distribuite, despre care ne permitem să afirmăm că în general au mai multe avantaje decât dezavantaje, rămânând însă la latitudinea factorilor decizionali să stabilească dacă un sistem distribuit şi ce sistem distribuit ar fi soluţia ideală pentru succesul afacerii sale.

Autorii lucrărilor [Connolly et al. 2001] şi [Gardarin & Valduriez 1989] sintetizează avantajele şi dezavantajele sistemelor distribuite. Deşi cele două materiale au fost elaborate la un deceniu distanţă, problemele semnalate sunt în linii mari aceleaşi. Nu vor lipsi nici opiniile autorului în legătură cu problematica abordată.

Avantajele se referă la următoarele aspecte:Structura organizaţională

Caracterul partajabil şi autonomia locală Disponibilitate şi fiabilitate crescutePerformanţe îmbunătăţite Dezvoltare modulară

Economie.Dezavantajele sistemelor distribuite sunt:

ComplexitateaLipsa de standarde SecuritateaDificultatea controlului integrităţii şi a concurenţei Lipsa de experienţă

Dificultatea de înlocuire sau schimbare.

Acestea sunt principalele beneficii şi neajunsuri ale sistemelor de baze de date distribuite.

Page 187: licenta hatz

Sisteme de baze de date distribuite

Page 188: licenta hatz

1.10 Baze de date federative

1.10.1 Introducere

În ultimele decenii s-a manifestat o modă – necesară am putea spune – în ceea ce priveşte sistemele de baze de date multiple, cunoscute în literatura de specialitate ca şiMultiDataBase Systems (MDBS).

Definiţie: Sistemele de baze de date multiple reprezintă un sistem de baze de date distribuite în care fiecare sit păstrează o autonomie totală. [Connolly et al. 2001]

În general, rolul acestora este de a se interconecta logic mai multe sisteme de baze de date în vederea atingerii unui ţel comun. Sistemele locale îşi păstrează controlul complet asupra bazei de date prin intermediul aplicaţiilor existente. De aceea, sistemul global nu poate aduce atingeri asupra structurii sau aplicaţiilor care rulează local. Dialogul dintre cele două nivele se face prin intermediul unei interfeţe software şi la nivelul datelor pe care situl local consimte să le partajeze. Putem să avem sisteme de baze de date multiple în care nu avem utilizatori locali. Acestea se numesc sisteme de baze multiple nefederative.

Principiul federalizării, care s-a dovedit a fi un tipar comportamental atât în cazul organismelor biologice, dar şi în comunităţile de succes, poate fi de asemenea un curs firesc de urmat şi în cazul corporaţiilor. Acesta presupune existenţa unor entităţi mici care îşi pot îndeplini autonom – pe cât se poate cu putinţă – sarcinile, fără a se abate atât de la obiectivul individual, cât şi global de sporire a profitului şi de micşorare a costurilor. Dacă principiul federalizării este acceptat ca un comportament strategic în viaţa reală, atunci de ce nu, şi structurile informatice ar putea fi supuse proiectării conform aceluiaşi principiu. [Schmitt & Saake 2005] Fiecare membru al federaţiei este şi va rămâne independent atât timp cât activitatea lui urmăreşte şi binele întregii federaţii. Ca principiu antreprenorial, federalismul promovează expansiunea clară şi diferenţiată a reţelelor şi proceselor corporatiste. Din punctul de vedere structural şi organizaţional, sistemul federativ protejează mai micile entităţi împotriva coloşilor, fără a fi private de sprijinul de care au nevoie pentru desfăşurarea activităţii şi – paradoxal – conferindu-le un nivel ridicat de libertate.

Necesitatea în continuă creştere de cooperare între diferite entităţi impune un acces integrat la baze de date distribuite heterogene, dar autonome. Acesta trebuie să confere imaginea unei singure baze de date şi necesită interconectarea sistemelor de baze de date prin intermediul unei reţele de comunicaţii şi suprapunând un nivel software deasupra sistemelor de gestiune a bazelor de date în vederea susţinerii comunicării, să partajeze anumite date, însă să păstreze autonomia de la nivelul local. [W3C FDMS Group] La începutul anilor `90 integrarea diferitelor surse heterogene de informaţii a devenit un important şi interesant domeniu de investigaţie. Până să se sedimenteze denumirea de „sisteme federative”, în publicaţiile acelor vremuri ele figurau fie ca ”next-generation gateways”, ”data access middleware”, sau ”multi-database servers”. Activităţile din acest domeniu şi-au propus combinarea sistemelor informatice existente. Realizarea unei integrări iscusite va permite accesul transparent la aceste sisteme heterogene.

Definiţie: Un sistem de baze de date federative (FMDBS12) este o colecţie de sisteme de baze de date colaborative care sunt autonome şi posibil heterogene. [Sheth &Larson 1990]

[Buch 2002] şi [Nukpe 2001] susţin ideea că bazele de date federative reprezintă unificarea logică a unor baze de date distincte ce rulează pe servere independente, (în general

12 Federated MultiDataBase System

Page 189: licenta hatz

Sisteme de baze de date distribuite

Page 190: licenta hatz

descentralizate geografic) fără partajare de resurse şi conectate prin intermediul unui LAN. Reprezentând un sistem transparent şi integrat de metabaze de date, ele modelează universuri similare sau complementare [Bouguettaya 1998]. Cât timp bazele de date rămân autonome, federalizarea constituie o alternativă viabilă în raport cu principiul centralizării. [WikipediaBDF]

Cea mai sugestivă exemplificare a conceptului o reprezintă însuşi Internetul, care, la rândul său, reprezintă un sistem federativ de dimensiuni mari.

Un sistem de baze de date federative al unei agenţii de turism interconectează sistemele unor tipuri de instituţii cu domenii de activitate diferite (hoteluri, agenţii de turism, sisteme de rezervare etc). Din necesitatea de întâmpinare a nevoilor clientului, sunt necesareşi comunicarea cu băncile – ofertă de instrumente comode de plată, acordarea la faţa locului a unor eventuale credite pentru excursii, şi chiar pentru verificarea bonităţii clientului sau a situaţiei încasărilor, tranzacţii bancare cu partenerii – şi cu societăţile de asigurări (asigurări medicale pentru străinătate sau ţară, a mijloacelor de transport proprii şi pentru punerea la adăpost faţă de situaţii neprevăzute ce pot rezulta din activitatea pe care o prestează). Este de la sine înţeles că activitatea partenerilor va fi autonomă, adică agenţia nu va putea efectua orice şi pentru oricine tranzacţii bancare sau să modifice salariul angajaţilor din hoteluri. Ţelul comun al federaţiei este de maximizare a profiturilor individuale şi deci şi a celui global, câştigarea de noi clienţi, reducerea timpilor de desfăşurare a unor tranzacţii obişnuite etc.

Un sistem federativ reprezintă o îmbinare între un sistem distribuit şi unul centralizat, adică un sistem distribuit pentru utilizatorii globali şi unul centralizat pentru cei locali. Nu aderăm întru totul la această accepţiune pe motivul că utilizatorii sistemului local ar putea fi tot atât de bine utilizatori ai unui sistem distribuit, iar în al doilea rând un sit nu„şi-ar putea permite” libertatea să-i condiţioneze virtualului nod central ce date îi va pune la dispoziţie, ce tranzacţii sau ce interogări îi dă voie să lanseze. Un al treilea punct de vedere ar fi că dacă am avea de-a face cu o cădere a nodului central, activitatea sitului nu are de ce să fie întreruptă.

1.10.2 Caracteristicile sistemelor federative

Potrivit lui Fèlix Saltor, există trei elemente esenţiale care caracterizează sistemele federative:

Autonomia. Fiecare bază de date a fost proiectată autonom şi îşi păstrează libertatea de a-şi modifica sau nu design-ul; este liberă să decidă ce date şi cui le va partaja, precum şi modul de gestionare al interogărilor şi tranzacţiilor provenite din exterior; disponibilitatea datelor rămâne din nou la latitudinea siturilor. Aceste nivele de autonomie sunt descrise sub denumirile de: autonomie de proiectare, autonomie de comunicare, autonomie de execuţie. Atunci când se atinge autonomia deplină vom referi sistemele de baze distribuite doar ca sisteme de baze de date multiple [Kosch 2000];

Heterogenitatea. Se concretizează în diferenţe de hardware, sisteme de operare, SGBD (heterogenitate de sistem); modele de date şi limbaje şi dialecte (heterogenitate sintactică); diferenţe în ceea ce priveşte modul de percepere a realităţii, diferenţe conceptuale şi de reprezentare în cadrul bazelor de date (heterogenitate semantică). Un sistem federativ din cadrul unei organizaţii poate avea nodurile formate din maşini cu tehnologii diferite – avem laptop, maşini Mac, server, mainframe, desktop, staţii de lucru, calculatoare generice– sunt conectate la o reţea locală de calculatoare. Heterogenitatea este completată şi la nivelul

Page 191: licenta hatz

Sisteme de baze de date distribuite

Page 192: licenta hatz

bazelor de date care interoperează, având fişiere clasice, baze de date ierarhice, reţea, funcţionale, relaţionale, obiectuale şi obiect-relaţionale.

Distribuirea. Aici nu este vorba doar de o singură bază de date distribuită, ci şi de un număr de baze de date separate ce pot fi localizate în diferite noduri ale unui sistem distribuit [Saltor 1995], [Nukpe 2001].

Caracterul heterogen al datelor provenite din varii surse reprezintă o mare şi continuă provocare adresată tehnicii, de mai bine de un deceniu. Să luăm drept exemplu terminologia bancară. Fiecare bancă îşi are propriile denumiri şi caracteristici pentru instrumentele de creditare. Privite la nivel internaţional, însemnele monetare şi ratele de schimb sunt de asemenea diferite. Să nu uităm şi faptul când în lumea financiară se constituie acele consorţii bancare, sau sunt tot mai dese preluările sau absorbţiile unor bănci de către altele. Toate acestea sunt premisele necesităţii unei comunicări – mai de suprafaţă sau mai în profunzime – între acestea, fără ca heterogenitatea să devină o barieră informaţională.

Faţetele heterogenităţii din cadrul bazelor de date multiple sunt uneori categorisite doar în heterogenitate fizică şi heterogenitate semantică. [Litwin 1988] Prima dintre ele se referă la diferenţele în reprezentarea datelor: unele sunt reprezentate ca întregi, numere reale, şiruri de caractere, date calendaristice, reprezentări în virgulă fixă mobilă cu simplă sau dublă precizie ş.a.m.d.; sisteme de gestiune a bazelor de date (Oracle, Access, Visual Fox, Sysbase, Informix, SQL Server, Paradox etc.); limbajul de interogare; modelul de date etc. Cel mai des utilizată soluţie pentru dobândirea interoperabilităţii este utilizarea conexiunilor active la bazele de date (ODBC13). Acest standard se foloseşte pentru omogenizarea bazelor de date relaţionale, pentru toate SGBDR-urile importante existând câte un astfel de driver. Acum, o tabelă sau interogare definită în Access poate fi vizualizată/rulată fără probleme şi în Oracle, Paradox, SQL Server etc. În aceste condiţii utilizatorii pot să uite că a existat heterogenitate fizică, atâta vreme cât nu există conflicte între versiunile de drivere. În cazul unei diversităţi mari de sisteme – toate cele din familia IBM DB2, Oracle, SQL Server, Sysbase, Informix, foi de lucru Excel, fişiere plate – se poate folosi produsul IBM DB2 Integrator, care le acoperă pe toate acestea, în plus asigurând acces şi asupra ODBC-urilor deja definite, servicii web şi suport XML. Pentru browsere există un standard aflat deasupra ODBC-urilor clasice, şi anume JDBC14. Acesta permite rularea interogărilor direct din appletele Java. JDBC asigură suport atât pentru paginile, tabelele, rapoartele sau formularele în format HTML, cât şi pentru cele în format XML.

Cel mai popular concept, atunci când se vorbeşte despre interconectarea bazelor de date heterogene, este wrapper-ul, uneori fiind cunoscut şi cu denumirea de mediator. Wrapper-ele sunt nişte adaptoare, nişte straturi software intermediare ce transparentizează diferitele nivele ale heterogenităţii. Heterogenitatea fizică poate fi împărţită în următoarele subcategorii: heterogenitate de hardware, heterogenitatea sistemelor de operare, heterogenitatea modelelor de date, heterogenitate de limbaje de interogare, heterogenitatea limbajelor de programare.

Heterogenitatea semantică se referă la numele obiectelor, valorile pe care pot să le ia datele şi structura conceptuală. Un exemplu, ce-i drept puţin utopic, care ar putea să dezvăluie o parte din problemele heterogenităţii semantice, ar fi interconectarea sistemelor educaţionale naţionale într-o federaţie internaţională. Dacă vrem să analizăm doar sistemul de evaluare al elevilor, studenţilor, masteranzilor, doctoranzilor etc. am constata că şi în cadrul aceleiaşi regiuni geografice modalităţile de evaluare sunt heterogene: note, calificative, admis/respins, premii, titluri dobândite. Asta ca să nu mai vorbim de steluţe,

4.3.1 Open DataBase Connectivity4.3.2 Java DataBase Connectivity

Page 193: licenta hatz

Sisteme de baze de date distribuite

Page 194: licenta hatz

buline roşii sau negre, porcuşori etc. utilizate în primele etape ale stadiului didactic. Fără a trece la detalii de subtilitate semantică, privitoare la calitatea învăţământului, cantitatea şi nivelul de dificultate a materiei predate, pentru a putea face o comparaţie între un sistem sau altul, ne lovim de bariera sistemului de notare. Putem să avem note de la 1 la 10 (România), în SUA avem A, B ..., în Ungaria şi în fosta URSS aveam note de la 1 la 5. La fel şi în Germania, cu deosebire că 1 este nota cea mai bună. La fel, există punctaje sau baremuri de admitere. Pentru a se realiza o comparaţie echitabilă trebuie ca wrapper-ul să ţină cont de aceste aspecte, precum şi de multe altele, cum ar fi perioada de şcolarizare, vârsta minimă de şcolarizare etc. Aspectul semantic este foarte delicat, mai ales că în acest domeniu nu se pot impune standarde.

1.10.3 Integrarea bazelor de date

Integrarea bazelor de date presupune un proces în urma căruia informaţiile din bazele de date participante pot fi înglobate într-o singură definiţie coerentă acceptată de un sistem de baze de date federative. Este, de fapt procesul de constituire a schemei conceptuale globale. Integrarea trebuie să se poată face între diferitele modele de date pe baza cărora bazele de date locale sunt constituite, fie că e vorba de cel relaţional, ierarhic, reţea, orientat pe obiecte, sau obiectual-relaţional.

Detalierea procesului de integrare a bazelor de date din cadrul unui sistem federativ urmează în linii mari abordarea propusă în materialul [Kosch 2000]. Integrarea bazelor de date necesită parcurgerea a doi paşi:

Translatarea schemei (sau pur şi simplu translatarea), care înseamnă translatarea schemelor locale participante într-o reprezentare canonică intermediară comună. Aceasta se referă la faptul că dacă o bază de date locală este reprezentată în modelul ierarhic, iar alta în cel relaţional, trebuie să se aleagă o reprezentare comună. În cazul în care alegerea a fost făcută în favoarea modelului relaţional, atunci primului nod trebuie să-i fie aplicată translatarea înspre modelul relaţional;

Integrarea schemei se referă la aducerea tuturor modelelor canonice intermediare către un model ţintă, cel al schemei globale conceptuale.

Este recomandat ca întreg procesul de integrare să fie asistat de către vreun instrument software de integrare. Integrarea schemei conceptuale globale este o sarcină primordială în proiectarea bazei de date federative, unde sistemele heterogene preexistente necesită o integrare virtuală prin furnizarea unei interfeţe omogenizate a bazei de date în ansamblu. Cele mai frecvente metode de integrare suferă din cauza complexităţii schemei rezultate şi din cauza gestionării tardive a redundanţelor din bazele de date. Nedetectarea din timp a acestora poate conduce la pierderea controlului asupra sistemului.

1.10.4 Concluzii privind sistemele federative

Aşadar, federalismul este un principiu structural şi organizaţional a cărui componente de bază, independente şi autonome îşi unesc forţele pentru a forma o structură bine închegată de nivel mai înalt care să combine într-o anumită proporţie uniformitatea cu diversitatea indispensabile asigurării succesului organizaţiei. [Schmitt & Saake 2005]

De multă vreme informaţia este considerată un factor-cheie în industrie (şi nu numai), ea devenind necesară şi pentru stabilirea relaţiilor între sursele şi serviciile deja existente (de exemplu, pentru cuplarea sectorului administrativ cu cel de producţie, ambele

Page 195: licenta hatz

Sisteme de baze de date distribuite

Page 196: licenta hatz

având deja baze de date). [W3C IDC #22542] Multe organizaţii sunt nevoite să interacţioneze cu baze de date distribuite, preexistente, heterogene şi autonome. Ele trebuie să găsească soluţii care să facă posibilă expansiunea bazelor de date şi să promoveze partajarea datelor între utilizatori şi aplicaţii, fără eforturi prea mari de implementare. Acest lucru presupune o tehnologie ce furnizează o integrare selectivă, dar totuşi controlată a unor astfel de baze de date. Bazele de date federative sunt capabile să ofere diferite nivele de integrare, cu implicaţii diverse asupra gradului de control în condiţiile conservării autonomiei bazelor de date individuale. [Sheth 1991]

Ideea federalizării a prins bine publicului, indiferent că este vorba de comunitatea academică, de firme dezvoltatoare de tehnologii IT, sau de grupuri economice. Sistemele de baze de date distribuite sunt de dorit, însă aria lor de aplicabilitate este relativ redusă în comparaţie cu sistemele federative. Atunci când pornim o afacere mare care presupune o serie de departamente, birouri, filiale, puncte de lucru dispersate geografic, ne vom construi cu siguranţă un sistem distribuit. Pe parcurs însă, atunci când afacerea ta se îngemănează cu o serie de terţi şi îşi diversifică domeniul de activitate, nu ne vom mai permite să reproiectăm din temelii sistemul informatic sau să-l actualizăm în consecinţă, în baza concepţiei iniţiale.Reproiectarea unui sistem de baze de date distribuite necesită în afară de resurse financiare importante şi o perioadă destul de îndelungată de implementare. Cum lumea afacerilor se mişcă şi se schimbă extrem de rapid, trebuie să găsim o soluţie nu doar mai ieftină, cât mai ales puţin consumatoare de timp de implementare. Cu atât mai mult cu cât relaţiile cu unii terţi sunt sporadice şi întotdeauna se va ivi unul nou faţă de care nu vom avea niciun interes de a realiza o colaborare atât de „profundă” încât să necesite dezvoltarea unui sistem de baze de date împreună. În astfel de situaţii soluţia ideală este cea de construire a unui sistem federativ peste sistemul nostru şi cel al partenerilor de afaceri. Acest lucru nu va afecta autonomia niciunuia dintre noi, fiecare având propria afacere, de cele mai multe cazuri chiar total în domenii diferite. Aceeaşi abordare se impune şi atunci când fuzionăm cu alte companii sau le preluăm.

Bazele de date federative reprezintă de multe ori suportul şi pentru alte tehnologii, precum depozitele, data mart-urile sau pieţele de date, sisteme OLAP şi OLTP, data mining, baze de date multimedia, baze de date documentare, baze de date statistice etc. Ele pot fi aplicate în orice domeniu de activitate, chiar şi în cazul bibliotecilor on-line, sisteme GIS (Geo-Information System) [Tuladhar 2005], afacerilor pe Internet15, fie că vorba de simple achiziţii de bunuri sau de instrumente bancare, asigurări, marketing şi multe altele.

1.11 Depozite de date

Derularea fenomenului economic asistat de calculator în cadrul organizaţiilor a condus la acumularea unor cantităţi din ce în ce mai mari de date. Unele companii au considerat că menţinerea datelor arhaice constituie nici mai mult nici mai puţin decât un balast pentru derularea în bune condiţii a activităţii economice, pe motivul că o bază de date supradimensionată cauzează deficienţe în exploatare. Această afirmaţie este adevărată în condiţiile în care rata de înnoire a sistemelor de calcul şi a celor informaţionale este una lentă. O altă categorie de firme a înţeles că înnoirea instrumentelor de susţinere a activităţii este necesară. Odată cu acestea, dimensiunea bazei de date nu mai reprezenta o povară. Aşa că, mai mult sau mai puţin intenţionat s-au creat premisele constituirii unui depozit de date. Cei

Page 197: licenta hatz

15 pentru detalii se poate consulta referinţa [Sitar & Sitar 2001]

Page 198: licenta hatz

Sisteme de baze de date distribuite

Page 199: licenta hatz

care au înţeles că o analiză a datelor mai vechi este o cale spre succesul afacerii au câştigat o luptă mută, dar importantă, cu concurenţa ignorantă. Învăţarea din greşelile trecutului prin nerepetarea lor, precum şi descoperirea unor şabloane comportamentale care garantează succesul constituie un avantaj.

Definiţie: Depozitele de date (DW16) sunt colecţii de date nevolatile, orientate spre subiect, integrate, variabile în timp care sprijină managementul firmei în procedeul de luare a deciziilor. [Inmon 1996]

Spunem că datele sunt nevolatile deoarece ale sunt reactualizate sporadic şi menţinute în baza de date. Rareori avem de-a face cu actualizări de conţinut, depozitele bazându-se pe inserări. Orientarea spre subiect se referă la faptul că depozitul gravitează în jurul „subiectelor” unei organizaţii – clienţi, produse, vânzări – şi nu înspre domenii de aplicaţie (facturare, aprovizionare, desfacere etc.). Integrarea presupune înmagazinarea în acelaşi loc, într-o formă unitară şi coerentă a datelor provenite de la diverse subiecte sau activităţi. Variabilitatea în timp se referă la caracterul permanent dinamic al conţinutului bazei de date, lucru ce conferă o instabilitate în timp a conţinutului, neputând afirma că între două momente de timp mai îndepărtate nu s-a întâmplat nimic semnificativ. [Connolly et al.2001]

[Singh 1997] sintetizează diferenţele şi asemănările dintre sistemele de înmagazinare a datelor şi cele de prelucrare on-line a tranzacţiilor (OLTP17):

Sisteme de înmagazinare a datelor Sisteme OLTPPăstrează date istorice Păstrează date curenteStochează date detaliate, rezumate pe diferite Stochează date detaliateniveleDatele sunt în general statice Datele sunt dinamicePrelucrare ad-hoc, nestructurată, euristică Prelucrare cu grad ridicat de

repetitivitateNivel mediu sau scăzut de transfer al Nivel înalt de transfer al tranzacţiilortranzacţiilorTipar de utilizare imprevizibil Tipar de utilizare previzibilConduse prin analiză Conduse prin tranzacţiiOrientare spre subiect Orientare spre aplicaţiiSuport pentru decizii strategice Suport pentru decizii de zi cu ziDeservesc un număr relativ mic de utilizatori din Deservesc un număr mare deadministraţie utilizatori obişnuiţi

Figura 6.3 Comparaţie între sistemele de înmagazinare şi cele OLTP

Un aspect deosebit de important este acordat memorării şi gestionării metadatelor, adică a datelor despre date. Rolul metadatelor este unul foarte însemnat. Cu ajutorul datelor putem să studiem provenienţa şi chiar întreaga istorie a unui articol. Astfel putem afla compartimentul de la care provine, data intrării în depozit, modificările suferite până în prezent, atât valorice, cât şi structurale etc.

Un depozit de date este reprezentat din structuri de date ce sunt optimizate în vederea distribuirii lor în cadrul unei reţele de calculatoare. Acesta colectează şi înmagazinează seturi de date istorice din multiple sisteme operaţionale, alimentând între timp şi una sau mai multe

4.3.5. Data Warehouse4.3.6. On-Line Transaction Processing

Page 200: licenta hatz

Sisteme de baze de date distribuite

Page 201: licenta hatz

pieţe de date [W3C ODC]. Nu subscriem întru totul la această ipoteză deoarece modalităţile de elaborare a unui depozit pot să difere de modalitatea expusă anterior.

Definiţie: Pieţele de date (DM18) sunt submulţimi ale depozitelor de date, particularizate în vederea îndeplinirii nevoilor unui departament sau care acoperă un subiect.[Inmon 1996]

Pieţele de date sunt depozite de date cu caracter mai specific, care conţin date sumarizate într-o anumită măsură, putând astfel să răspundă unor probleme formulate de utilizatorii unui domeniu.

Atât pentru realizarea unui depozit de date, cât şi pentru exploatare acestuia, un sistem relaţional trebuie să îndeplinească o serie de cerinţe referitoare la: performanţele de încărcare, prelucrarea încărcării, administrarea calităţii datelor, performanţele interogărilor, scalabilitatea la nivel de teraocteţi sau chiar superioare, scalabilitatea la nivelul masei de utilizatori, distribuirea depozitului în reţea, administrarea depozitului de date, analiza dimensională integrată, funcţionalitatea interogărilor avansate. [Connolly et al. 2001] Şi sistemele SGBDOO ar putea furniza rezultate bune.

Beneficiile înmagazinării datelor sunt: o potenţială rată ridicată de întoarcere a investiţiilor, avantajul competitiv pe care-l pot oferi şi sporirea productivităţii organelor decizionale. Dezavantajele sunt: subestimarea resurselor necesare pentru încărcarea datelor, probleme ascunse ale sistemului sursă, eşuarea capturării unor date, cerinţe sporite din partea utilizatorului final, uniformizarea datelor, cerinţe mai mult decât modeste privind resursele, proprietatea asupra datelor, gradul înalt de întreţinere, iniţierea unor proiecte de lungă durată şi complexitatea integrării.

Înmagazinarea datelor, prin intermediul căreia volume imense de date sunt extrase, în general prin intermediul unui proces batch, este un domeniu care datează de trei decenii.

Ea este susţinută de tehnologii precum bazele de date distribuite, baze de date federative, tehnologii Web etc. şi constituie un suport solid pentru instrumentele de raportareşi interogare, dezvoltare de aplicaţii, sisteme EIS19, OLAP, data mining şi altele.

Elemente privind prelucrarea analitică şi de extragere a datelor legate de baze de date distribuite şi federative

1.12.1 Introducere

Procesul de înmagazinare al datelor nu trebuie privit ca o obligaţie sau modă. În aceste condiţii informaţia strânsă cu atâta râvnă reprezintă o povară – mai mult chiar, una scumpă – pentru organizaţie. Informaţia reprezintă cel mai de preţ lucru pentru procesul decizional. În anii ’80, în SUA s-a estimat că aproximativ 70% din timpul de lucru al angajaţilor este destinat procurării, utilizării sau difuzării de informaţie. Constituirea depozitelor de date trebuie să se facă pentru progresul companiei într-o manieră care să permită câştigarea unui avantaj competitiv.

Acumularea unui volum din ce în ce mai mare de date şi stocarea pe un singur sistem de calcul este o ipoteză de neconceput. În primul rând, chiar şi cu explozia tehnologică din ultima vreme, este greu de înţeles că ar putea exista o unitate de stocare care să înmagazineze experienţa de zeci de ani a unei companii de dimensiuni mai mari, cu activitate frecventă şi

Data Mart Executive Information System

Page 202: licenta hatz

Sisteme de baze de date distribuite

Page 203: licenta hatz

complexă. Un alt motiv ar fi că riscul memorării datelor într-un singur loc ar fi prea mare, o defecţiune minoră putând să pună capăt unei activităţi care datează de decenii. Mai mult, fără existenţa unor copii de siguranţă orice atac informatic, act de sabotaj sau calamitate naturală ar fi fatal. Aşadar, chiar dacă volumul de date este imens, valoarea datelor necesită replicare. Abordarea cu o bază de date locală sau centrală ar genera regăsiri mari consumatoare de timp datorate dimensiunii mari a bazei de date şi a operaţilor de arhivare/dezarhivare, şi totodată ar limita numărul utilizatorilor care să efectueze operaţii concurente.

1.12.2 Instrumentele OLAP

După cum am văzut în subcapitolul anterior, bazele de date ale organizaţiilor sunt într-o continuă creştere. Pentru a face faţă nu numai operaţiunilor de constituire a acestor volume de date, ci şi de exploatare viitoare trebuie să fim preocupaţi atât de instrumentele hardware, cât şi de cele software. La volume imense de date de complexitate din ce în ce mai mare anumite produse – evident şi sistemele relaţionale – dau bătăi de cap atunci când se doresc răspunsuri prompte.

Aplicaţiile din domeniul afacerilor, precum analiza pieţei sau prognoza financiară, se bazează pe scheme de baze de date orientate spre interogări. Acestea trebuie să confere o imagine multidimensională, uşor de interpretat şi cât mai natural reprezentată. Aplicaţiile de acest gen au ca scop regăsirea unui număr mare de înregistrări dintr-un imens bagaj de date şi posibilitatea de sumarizare din mers a acestora. Suportul pentru acest gen de operaţii este furnizat de către instrumentele OLAP. Termenul „OLAP” a fost inventat de E.F. Codd în1993.

Definiţie: Prelucrarea analitică on-line reprezintă sinteza, analiza şi consolidarea dinamică a unor volume vaste de date multidimensionale. [Connolly et al. 2001]

OLAP este o tehnologie ce suportă facilităţi analitice asupra uneia sau mai multor surse de date. În general, sistemele OLAP implică analiza datelor ce-şi au originea în baze de date tradiţionale, dar au fost ulterior transformate în structuri multidimensionale pentru o vizualizare şi o analiză mai facilă. De aceea, majoritatea instrumentelor OLAP au ca platformă sistemele de gestiune a bazelor de date multidimensionale (MDDBMS20), interfaţa cu utilizatorul fiind personalizată

Instrumente OLAP multidimensionale sunt cele mai intuitive, mai fiabile, dar şi cele mai costisitoare material instrumente de prelucrare analitică. Sunt cunoscute în literatura de specialitate sub acronimul MOLAP21. Ele sunt destinate în rezolvarea unor interogări care furnizează răspunsuri multiple, facilitând utilizatorului capacitatea de analiză, sinteză şi comparaţie. Atunci când vrem să aflăm care sunt mediile generale ale studenţilor facultăţii pe ani de studiu, semestriale şi anuale, pe specialităţi în vederea comparării rezultatelor cu situaţiile din anii precedenţi, cel mai bine e să apelăm la baze de date multidimensionale. Ulterior putem să facem comparaţii cu rezultatele obţinute de facultăţile de profil din ţară, de stat sau particulare, în cadrul cărora întâlnim secţii similare. Sau, putem să agregăm rezultatele în vederea creării premiselor de comparabilitate pe o anumită perioadă a rezultatelor cu celelalte facultăţi ale universităţii. Dacă interogarea trebuie să returneze doar rezultate simple: „Care este media generală a studenţilor de la secţia de Informatică economică, anul 3 de studiu pe semestrul întâi al anului curent?”, atunci nu se impune utilizarea bazelor de date multidimensionale. Pentru aceste tipuri de interogări se pot folosi

Multi-Dimensional DataBase Management System Multidimensional OLAP

Page 204: licenta hatz

Sisteme de baze de date distribuite

Page 205: licenta hatz

baze de date relaţionale. Totuşi, bazele de date relaţionale nu fac faţă cu succes unor volume de date mari. După [Connolly et al. 2001], un sistem relaţional obişnuit poate efectua prelucrarea a câtorva sute de înregistrări pe secundă, în timp ce unul multidimensional tipic efectuează mai mult de 10.000 de grupări pe secundă. Astfel, la dimensiuni mari ale bazei de date, pentru sistemele relaţionale componenta „On-Line” a instrumentelor OLAP îşi va pierde semnificaţia.

În cadrul sistemelor multidimensionale, reprezentarea intuitivă a datelor se face prin intermediul cuburilor de date. Atunci când numărul de dimensiuni devine mai mare de 3, avem de-a face cu cuburi n-dimensionale, sau simplu: hipercuburi. Reprezentarea intuitivă a acestora va fi însă prea dificil de realizat. Cuburile de date sunt uşor de extins pentru noi dimensiuni. Navigarea prin intermediul cuburilor este facilă.

Instrumente ROLAP22 au cunoscut cea mai puternică creştere dintre toate instrumentele OLAP. Pentru a se conforma regulilor instrumentelor OLAP, tehnologiaROLAP solicită definirea unui strat de metadate care îi conferă o imagine multidimensională dinamică.

1.12.3 Data mining

Am construit depozite de date. Se pune întrebarea firească: „Acum ce facem cu ele?”. Neutilizarea potenţialului oferit de către bazele de date de dimensiuni mari reprezintă o cale sigură spre eşecul afacerii. Însă, utilizarea acelor informaţii pentru ceva mai mult decât urmărirea istoricului afacerii, începe să aibă sens într-un mediu de afaceri concurenţial raţional. Am văzut că instrumentele OLAP ne oferă informaţii pe care interogările simple ale bazelor de date nu le relevă. Totuşi noi ţintim mult mai sus decât a crea analize şi comparaţii multicriteriale.

Posibilitatea de a oferi consumatorilor acele tehnologii care le vor permite să interogheze eficient bazele de date şi să extragă efectiv surse de informaţii va deveni un factor determinant în alegerea tehnologiei noastre în raport cu cea a concurenţei. Mineritul datelor reprezintă un imens potenţial pentru tehnologia bazelor de date, precum şi un instrument profitabil în lumea modernă a afacerilor.

Definiţie: Extragerea datelor reprezintă descoperirea automată a unor tipare netriviale, anterior necunoscute şi potenţial folositoare, bine înrădăcinate în bazele de date[W3C Koundourakis].

Data mining, extragerea de cunoştinţe sau „mineritul” datelor, constă într-o analiză automată a datelor electronice structurate, precum în cadrul unui depozit de date, cu intenţia de a descoperi tipare anterior necunoscute şi relaţii dintre date [W3C ODC] pentru a putea fi folosite în adoptarea unor decizii importante necesare eficientizării activităţii economice.

Extragerea datelor diferă faţă de instrumentele OLAP şi alte forme de analiză a datelor conduse prin interogări, prin aceea că şabloanele sau tiparele comportamentale sunt determinate de către sistem prin utilizarea unor algoritmi statistici, astfel încât să se dezvăluie relaţii pentru care utilizatorul nu este capabil să dezvolte interogări.

Clasificarea şi descoperirea regulilor de asociere sunt două componente ale extragerii cunoştinţelor ce pot sprijini marketingul de exemplu, procesul de luare a deciziilor şi conducerea afacerilor [W3C Meadowcroft].

Extragerea datelor poate furniza avantaje importante organizaţiilor care au deja propriile lor depozite de date. Chiar dacă mineritul este un domeniu relativ nou al tehnologiei

Page 206: licenta hatz

22 Relational OLAP

Page 207: licenta hatz

Sisteme de baze de date distribuite

Page 208: licenta hatz

bazelor de date, procesul de data mining este deja aplicat cu succes în diferite domenii, printre care şi cele exemplificate mai jos.

Comerţul cu amănuntul/marketingIdentificarea tiparelor de cumpărare ale clienţilorGăsirea de asociaţii între caracteristicele demografice ale clienţilorPreviziunea răspunsurilor la campaniile prin poştă sau publicitate prin mediaAnaliza coşurilor de piaţăDomeniul bancarDetectarea tiparelor de utilizare frauduloasă a cărţilor de creditIdentificarea clienţilor loialiPreviziunea privind clienţii care este probabil să-şi schimbe afilierea cărţilor de creditIdentificarea şablonului solicitantului de credite şi particularizarea oferteiDeterminarea cheltuielilor din cărţile de credit pentru grupuri de utilizatoriAsigurăriAnaliza solicitărilorPreviziunea clienţilor care vor cumpăra poliţe noiDeterminarea comportamentului fraudulosMedicinăCaracterizarea comportamentului pacienţilor pentru prognoza consultaţiilor chirurgicaleIdentificarea terapiilor de succes pentru diverse boliStabilirea listelor de medicamente compensate

Connolly prezintă principalele operaţii de extragere a datelor. Acestea sunt:Modelarea predictivă, Segmentarea bazei de date, Analiza legăturilor şi

Detectarea deviaţiilor.Toate cele 4 operaţii expuse contribuie la procesul de data mining. În general se

poate folosi oricare dintre ele, sau asocieri de mai multe operaţii. Totuşi, prin studiul comportamentelor s-a constatat că anumite operaţii dau rezultate mai bune în anumite domenii. Spre exemplu, stabilirea profilului clientului este abordată prin segmentarea bazei de date, apoi se aplică modelarea predictivă.

1.12.4 Concluzii privind prelucrarea analitică şi extragerea datelor

Modelele de baze de date relaţionale şi multidimensionale deservesc multor scopuri. Astfel, în timp ce primele se pretează la operaţii de citire-scriere, tranzacţii, activităţi cu volum ridicat, celelalte se potrivesc pentru activităţi de volum scăzut, interogări complexe şi care se întind peste cantităţi enorme de date ce pot fi procesate simultan. În timp ce bazele de date relaţionale se bazează ca limbaj de interogare pe SQL, sistemele MOLAP nu au încă un limbaj stabilit de comun acord. [W3C ODC]

Mineritul datelor reprezintă descoperire automată a inteligenţei din date brute stocate pe diferite sisteme de calcul. Acest instrument este folosit pentru detectarea comportamentului fraudulos în utilizarea cărţilor de credit sau a cartelelor telefonice, solicitărilor de despăgubire suspecte, determinarea tiparelor de clienţi, segmentarea categoriilor de clienţi etc. Ţinând cont de realitatea existenţei datelor murdare în cadrul bazei de date, instrumentele de data mining trebuie să fie foarte precaute. Toleranţa la erori poate

Page 209: licenta hatz

Sisteme de baze de date distribuite

Page 210: licenta hatz

constitui un criteriu important în selectarea algoritmilor utilizaţi la extragerea datelor. Până nu demult, algoritmii de data mining se mulţumeau să descopere tipare şi tendinţe anterior necunoscute, dar de masă. Noua generaţie de algoritmi este preocupată şi de descoperirea unor comportamente şi tendinţe excepţionale, mai ales în condiţiile actuale când se urmăresc riscurile de securitate, suspectarea posibililor terorişti, transferuri suspecte de fonduri etc. Aşadar, noii algoritmi trebuie să fie înzestraţi cu capacităţi de reţele neuronale, astfel încât să poată fi antrenaţi şi în condiţiile anterior amintite: date murdare, respectiv comportamente excepţionale. Fără a se ţine cont şi de astfel de considerente, în ziua de azi, astfel de instrumente nu pot fi considerate a fi cu un grad înalt de fidelitate. [Kim 2002]

Ambele tehnologii se aplică asupra unor depozite sau pieţe de date. Cu cât dimensiunea bazei de date relevă mai multe tipuri de evenimente, „experienţa” (volumul de date şi perioada de înmagazinare) este mai bogată, iar datele sunt cât mai curate, cu atât gradul de încredere al rezultatelor obţinute este mai mare. Acurateţea acestuia permite extrapolări de calitate. Oricât de evaluate ar fi mijloacele moderne de stocare sau arhivare a datelor, nu putem să concepem existenţa domeniilor de prelucrare analitică on-line şi de descoperire a cunoştinţelor, în absenţa unui mediu distribuit cu grad de heterogenitate variabil şi cu sferă de întindere cât mai mare.

1.13 Bazele de date şi Internetul

După cum ziceam ceva mai devreme, Internetul este cel mai vast sistem de baze de date federative. De fapt, Internetul reprezintă o reţea mondială de calculatoare interconectate, în timp ce prin termenul Web desemnăm conţinutul, adică însăşi baza de date federativă. Interesantă asocierea, atâta timp cât reţeaua Internet a apărut şi s-a dezvoltat exploziv fără să aibă legături prea mari cu ceea ce reprezintă bazele de date sau cu sistemele lor de gestiune.

Informaţiile sunt făcute publice prin intermediul paginilor web, care reprezintă o colecţie organizată de informaţii textuale, imagini, sunete, video, în general integrată cu ajutorul limbajului HTML. Paginile Web pot „comunica” cu alte pagini web datorită hiperlegăturilor pe care le conţin. În Internet siturile comunică unele cu celelalte prin interacţiunea clienţilor cu serverele.

Integrarea tehnologiei bazelor de date cu tehnologiile web este unul din paşii importanţi pe care i-a făcut tehnologia modernă. Paginile sunt acum mai atractive, mai dinamice şi mai uşor de administrat. Se reduce foarte mult redundanţa, chiar dacă din punctul de vedere al stocării unui număr enorm de fişiere HTML, accesarea unei astfel de pagini se face mai rapid decât prin interogarea unei baze de date.

Există diverse modalităţi de integrare a celor două tehnologii, însă niciuna dintre ele nu este unanim acceptată pentru rezolvarea problemelor de integrare. Mai mult, datorită caracteristicilor protocolului HTTP încă nu se poate garanta o calitate şi o securitate deplină a mediului Internet. Serviciile oferite prin platforma web sunt destul de lente. Viitorul va asigura însă soluţii mai fiabile.

Apariţia limbajului XML este un pas revoluţionar în integrarea Web-SGBD. Considerăm că între domeniul bazelor de date distribuite şi cel al tehnologiei Web va exista o colaborare de lungă durată. Anumite detalii ale acestei simbioze vor fi prezentate în capitolele următoare.

Page 211: licenta hatz

Sisteme de baze de date distribuite

Page 212: licenta hatz

1.14 Conceptul de Big Data

1.14.1 Introducere

În ultimii ani, tot mai multă lume interacţionează cu datele prin intermediul dispozitivelor mobile inteligente, reţelelor de socializare, în general al internetului. Zilnic, 2,5 EB (Exabytes, catralioane, 1018 octeţi) sunt create la nivel mondial. În raport cu tendinţele ultimilor ani, se poate afirma că 90% din totalul datelor existente apar în ultimii 2 ani, iar procesul este în dinamică [IBM BigData]. Volume din ce în ce mai mari se acumulează mai ales automat datorită serviciilor GPRS,23 sau mai nou 4G, a unei largi varietăţi de senzori, sisteme de monitorizare, climaterice, date geospaţiale, reţele de socializare, servicii email sau partajare diverse tipuri de media etc. Astfel, datele din jurul nostru au cunoscut creşteri exponenţiale, ajungându-se la nivelul anului 2012 ca Exabytes de date, să poată fi totuşi procesate în parametri rezonabili de timp [Francis 2012]. Aceste colecţii de date, stocate şi prelucrabile în vederea desfăşurării în bune condiţii a activităţii, oferire de servicii în limita termenilor agreaţi faţă de terţii implicaţi şi a extragerii de informaţii utile pentru organizaţie, poartă termenul generic de “Big Data”.Tot mai des, atunci când vorbim de Big Data, se remarcă următoarele 4 caracteristici – cunoscute generic ca 4V – 3 considerate de [Zikopoulos & Eaton 2011], în timp ce unii autori constată că numărul declarat de 4 este exagerat, când de fapt poate fi surprins şi cu doar două caracteristici [W3-Villa], dar mai cuprinzătoare.

Volum: Datele încearcă să surprindă cât mai fidel realitatea, de aceea trebuie să fie mai detaliate, complexe, presupunând un volum ridicat de atribute. De asemenea, fenomenele repetitive necesită un volum cât mai mare de instanţe. Chiar dacă ambele caracteristici fac apel la „volum”, nu înseamnă neapărat că orice date care satisfac una sau chiar ambele valenţe privitoare la volum, pot fi asociate cu conceptul de Big Data. Să urmărim şi celelalte caracteristici;

Viteză: datele cresc ca volum cu o viteză foarte mare. Viteza se referă nu atât la rata de creştere a volumului de date, ci la viteza cu care instrumentele sunt capabile să proceseze aceste date, pentru a le putea face disponibile beneficiarilor, într-un timp încadrabil în limita parametrilor de calitate;

Varietate: Datele pot proveni din diverse surse şi pot avea formate şi tipuri multiple: text, numere, date calendaristice, imagini, secvenţe de voce sau video etc., semi- dar de cele mai multe ori nestructurate.

Veracitate (sau Valoare): O mică parte din volumul de date este utilizabilă în procesul decizional, însă aceste date luate individual nu au nicio relevanţă fără aportul celorlalte. Această caracteristică se referă la veridicitatea datelor, consistenţă, integritate şi încredere în ele.

Pentru a putea fi catalogate Big Data, colecţiile de date trebuie să satisfacă toate caracteristicile menţionate anterior.

Page 213: licenta hatz

23 General Packet Radio Service, un serviciu mobil de date orientat pe pachete în cadrul sistemelor de comunicaţii mobile

Page 214: licenta hatz

Sisteme de baze de date distribuite

Page 215: licenta hatz

1.14.2 Bazele de date NoSQL

IstoricTermenul NoSQL este folosit pentru prima dată în 1998 şi se referă la acele baze de date relaţionale ce nu folosesc SQL [Str10]. În 2009, Jon Oskarsson consfinţeşte termenul în cadrul unei conferinţe din San Francisco, iniţiată de către susţinătorii teoriei bazelor de date nerelaţionale, fiind mai apoi mediatizat de blogger-ul Eric Evans [Evans 2009].De acum, folosim denumiri precum NoSQL sau NOSQL (Not Only SQL).

Bazele de date NoSQL nu au schemă şi nu stochează date relaţionale. Ele ridică problematici importante, legate de consistenţă, durabilitate/persistenţă şi gestiunea versiunilor.La ora actuală există următoarele categorii de baze de date NoSQL:

Key-/Value-stores – cel mai simplu model pentru date nestructurate. Foarte eficientşi flexibil. Dezavantaj: datele nu conţin descrierea lor

Document databases – pentru depozite XML şi obiecte care se autodescriu. Stocarea în acest caz este foarte ineficientă. În această categorie întâlnim subtipurile următoare:

– Baze de date relaţionale cu facilităţi XML: CLOB, XML împărţit în mai multe tabele în funcţie de schema; SGBDR-uri care acceptă tipul ISO XML (Ex. IBM DB2, Microsoft SQL Server, Access, Oracle Database, PostgreSQL)

– Baze de date XML native. Column-Oriented Databases (Baze de date pe coloane) – model foarte bun folosit în cadrul

depozitelor de date pentru date rarefiate. Putem avea coloane grupate şi agregate. Graf [Oracle 2012] – un model relativ nou, bun pentru parcurgerea relaţiilor, dar nu pentru căutări

generale.

Materialul de faţă nu îşi propune detalierea altor aspecte privitoare la bazele de date NoSQL.

Page 216: licenta hatz

Programarea front-end a site-urilor web

Autor: Daniel Mican

Front-end se refera la orice aspect al procesului de proiectare, al paginilor web, care apare sau are legatura directa cu browser-ul. Dezvoltarea front-end presupune design-ul interfetelor paginilor web. Urmatoarele activitati sunt, de obicei, considerate a fi sarcini de front-end: design-ul grafic al interfetelor, aranjarea si prezentarea informatiilor in vederea vizionarii in conditii optime; crearea documentelor HTML si a foilor de stil CSS; integrarea functionalitatilor oferite cu ajutorul scripturilor JavaScript.

HTML (Hypertext Markup Language) este folosit pentru structurarea paginilor web. Exista cateva versiuni de HTML in uz astazi: HTML 4.01 este cel mai popular, HTML5 este mai robust si castiga teren, iar incet incet se bucura si de sprijinul browserelor. Ambele versiuni au o implementare mai stricta numita XHTML (eXtensible HTML ), care este, in esenta, aceeasi limbaj dar cu o sintaxa mult mai stricta. HTML nu este un limbaj de programare, este un limbaj de marcare, ceea ce inseamna ca permite identificarea si descrierea diferitelor componente ale unui document, cum ar fi titluri, paragrafe sau liste. Marcajul indica structura de baza a documentului.

CSS (Cascading Style Sheets) este folosit pentru prezentare. In timp ce HTML este folosit pentru a descrie continutul unei pagini web, rolul Cascading Style Sheets (CSS) este de a descrie modul in care ar trebui sa arate continutul. In designul web, modul in care arata pagina este cunoscut sub termenul de prezentare. Asta inseamna fonturi, culori, imagini de fundal, linii de spatiere, aspectul paginii, etc. Toate aceste elemente sunt controlate cu CSS. Cu cea mai noua versiune (CSS3), putem adauga chiar efecte speciale si animatie paginilor web.

JavaScript este folosit pentru a oferi interactivitate. JavaScript este un limbaj de scripting care este utilizat pentru a adauga interactivitate paginilor web. Interactivitatea consta in: validarea campurilor unui formular; schimbarea stilurilor pentru un element sau chiar pentru intreg-ul site; determinarea browserului sa isi aminteasca informatii despre utilizator pentru vititele viitoare; construirea unor widget-uri de interfata, cum ar fi meniurile derulante. JavaScript este utilizat pentru a manipula elementele din cadrul paginiilor web, a stilurilor aplicate, sau chiar a browser-ului.

1. Marcarea si structurarea paginilor Web cu ajutorul HTML

HTML (Hyper Text Markup Language) este un limbaj folosit pentru a descrie paginile web. HTML este un limbaj de marcare alcatuit dintr-un set de tag-uri de marcare. Tag-urile descriu continutul si structura documentului HTML. Documentele HTML sunt alcatuite atat din tag-uri HTML cat si din text simplu. Documentele HTML mai sunt numite si pagini web.

Tag-urile de marcare HTML sunt de obicei numite simplu, tag-uri HTML. Acestea sunt cuvinte cheie inconjurate de paranteze unghiulare. Tag-urile HTML sunt in mod normal prezente in perechi. Primul tag dintr-o pereche este tag-ul de inceput, iar al doilea este tag-ul de final. Tag-ul de final este scris ca si tag-ul de inceput, cu diferenta ca mai contine un slash inainte de numele tag-ului.

<numetag> Continut </numetag>

Un element HTML este tot ceea ce este intre tag-ul de start si tag-ul final, inclusiv tag-urile. Tag-urile HTML si elementele HTML sunt adesea folosite pentru a descrie acelasi lucru. Fiecare element spune browserului ceva despre informatiile care se afla intre tag-ul de inceput si cel de sfarsit.

element HTML

Page 217: licenta hatz

<p> Acesta este un paragraf.</p>

Page 218: licenta hatz

Tag-urile HTML pot contine atribute. Atributele furnizeaza informatii suplimentare cu privire la elemente HTML. Atribute sunt intotdeauna specificate in eticheta de start si vin in perechi. Adica fiecarui nume de atribut ii este atribuita si o valoare.

<tag numeatribut = "valoare"> ... </tag>

Valorile atributelor trebuie sa fie intotdeauna cuprinse intre ghilimele. Ghilimele duble sunt cele mai comune, dar sunt de asemenea permise si cele simple. Tag-urile HTML pot contine mai multe atribute si valori ale acestora. La marcatorii simetrici, atributele sunt descrise in eticheta de deschidere:

<tag atribut1="valoare1" atribut2="valoare2" .... atributN="valoareN">... </tag>

1.1. Documentele HTML

Structura unei pagini HTML poate fi vizualizata in figura de mai jos:

Orice document HTML se redacteaza intr-un editor de texte, si se salveaza ca text ASCII standard, cu extensiile .html sau .htm. Textul ASCII trebuie cuprins in marcatorul (chiar daca multe browsere tolereaza lipsa sa): <html>...</html>. Numele tagurilor, atributelor si numele valorilor atributelor sunt case-insensitive. Totusi World Wide Web Consortium (W3C) recomanda valori lowercase pentru taguri, atribute si valori in recomandarile HTML 4. Noua versiune (X)HTML solicita si valori lowercase pentru taguri.

Fiecare document are doua sectiuni principale, o sectiune de antet si una de corp, generate de marcatorii pereche <head>... </head> pentru antet si <body>... </body> pentru corp. Un exemplu de document HTML poate fi observat in cele ce urmeaza:

<!DOCTYPE html><html>

<head><title>Acesta este un titlu</title>

</head><body>

<h1>Acesta este un heading</h1> <p>Acesta este un paragraf.</p> <b>Acesta este un text boldat.</b>

</body></html>

Page 219: licenta hatz

In exemplul de mai sus declaratia DOCTYPE defineste tipul de document. Textul intre <html> si </html> descrie pagina web, cel intre <head> si </head> este continutul invizibil al paginii, iar cel intre <body> si </body> este continutul vizibil al paginii. Textul continut intre <title> si </title> este afisat ca un titlu in browserul web. Textul intre <h1> si </h1> este afisat ca un titlu in pagina HTML, iar textul continut intre <p> si </p> este afisat ca un paragraf.Dupa redactare si salvare, documentul HTML trebuie deschis cu ajutorul unui browser. Scopul unui browser web (cum ar fi Google Chrome, Internet Explorer, Firefox, Safari), este de a citi documentele HTML si a le afisa ca pagini web. Browser-ul nu afiseaza tag-uri HTML, dar foloseste tag-urile pentru a determina modul in care continutul paginii HTML trebuie prezentat / afisat utilizatorilor.

In sectiunea de antet <head>1 se introduc informatii despre autorul documentului si titlul sau (tagul: <title>...</title>). Majoritatea browserelor Web afiseaza continutul din title in bara de titlu si stocheaza acest titlu atunci cand utilizatorul salveaza adresa paginii, ca semn de carte sau intr-o lista de interes. Din aceste motive se recomanda folosirea unor titluri cat mai semnificative, unice care trebuie sa contina numai text simplu.

Elementul <head> este un container pentru o serie de elementele componente. Elementele ce il compun pot include scripturi, instructiuni browser, style sheets, meta informatii. Astfel aici vom intalni urmatoarele taguri: <title>, <link>, <style>, <script>, <noscript>, <meta>, si <base>. Antetul contine, de obicei, si corpul functiilor-handler si ale altor scripturi. Comentariile se includ in marcatorul <!--....--> si pot contine scripturi Java Scrit, Jscript, PHP, ASP, care bor fi ingorate de browserece care nu poseda configuratii adecvate.

Corpul unui document trebuie sa fie cuprins integral intre tag-urile <body>...</body> si este format din informatia nestructurata, textuala, care se scrie ca in orice document ASCII, dupa care este structurata prin includerea anumitor portiuni in marcatori simetrici si formatata prin stabilirea de atribute pentru anumiti marcatori. Textul neformatat este considerat de catre browsere plain text, afisat intr-un singur sir, trecandu-se la o noua linie doar cand se ajunge la marginea ferestrei, fontul folosit la afisare este fontul implicit setat in browser.

Listele sunt enumerari de item-uri. Listele pot fi ordonate (<ol>), neordonate (<ul>) sau liste de definitii (<dl>). In cadrul primelor doua categorii, item-urile sunt delimitate cu marcatorul vid <li>. Listele de definitie folosesc doi marcatori, unul pentru termen (<dt>) si unul pentru definitie (<dd>).

<ol><li>Alexandra</li> <li>Mihai</li>

</ol><ul>

<li>Alexandra</li> <li>Mihai</li>

</ul><dl>

<dt>Alexandra</dt><dd>- are ochii albastri</dd> <dt>Mihai</dt><dd>- are ochii verzi</dd>

</dl>

Structurarea suprafetei de afisare impune impartirea documentului in zone de continut. Aceste zone pot fi delimitate fie prin tabele, fie prin cadre. Tabelele sunt definite cu tag-ul <table>.

Page 220: licenta hatz

1 Lucia Rusu, Robert Buchmann, Dezvoltarea aplicaţiilor WEB, Editura Risoprint, 2004

Page 221: licenta hatz

Un tabel este impartit in randuri cu tag-ul <tr>. Un rand este impartit in celule de date cu tag-ul <td>. Un rand poate fi, de asemenea, divizat in titluri cu tag-ul <th>. Elementele <td> sunt containerele de date din tabel. Elementele <td> poate contine tot felul de elemente HTML, cum ar fi text, imagini, liste, alte tabele, etc. Formatarea unui tabel poate fi realizata folosind CSS.

In cele ce urmeaza prezentam cele mai importante tag-uri HTML pentru lucrul cu tabele:

<table> defineste un tabel<th> defineste o celula antet intr-un tabel<tr> defineste un rand intr-un tabel<td> defineste o celula intr-un tabel<thead> grupeaza continutul din antetul unui tabel<tbody> grupeaza continutul din corpul unui tabel<tfoot> grupeaza continutul din subsolul unui tabel

Mai jos prezentam un exemplu de folosire a tagurilor pentru afisarea unui tabel cu doua linii. Prima linie este impartita in doua celule, iar cea de-a doua linie contine o singura celula.

<table bordercolor="blue" border="5"> <tr>

<td background="imagine.gif">celula 1 rand 1</td> <td>celula 2 rand 1</td>

</tr><tr>

<td colspan="2">celula 1 rand 2</td></tr>

</table>

Un iframe este folosit pentru a afisa o pagina web in cadrul unei alte pagini web. Mai jos URL-ul indica locatia paginii care va fi apelata si deschisa in cadrul iframe-ului. Sintaxa pentru a adauga un iframe este:

<iframe src="URL"> </iframe>

Pentru formatarea unui iframe se folosesc stilurile CSS. Cele mai importante atribute pe care le poate contine un iframe sunt prezentate in continuare:

src specifica adresa URL a documentului care va fi incorporat in <iframe>srcdoc specifica continutul HTML al documentului care va fi incorporat in <iframe>height specifica inaltimea unui <iframe>width specifica latimea unui <iframe>

Link-urile permit utilizatorilor sa navigheze de la o pagina la alta. Un link se creaza cu ajutorul tag-ului HTML <a>, care defineste un hyperlink. Un hyperlink (sau link-ul) poate fi reprezentat de catre un cuvant, grup de cuvinte, sau o imagine pe care se poate da clic pentru a trece la un alt document. Cand se deplaseaza cursorul pe o legatura intr-o pagina Web, sageata se va transforma intr-o mana mica. Cel mai important atribut al elementului <a> este atributul href, care specifica destinatia link-ului. Pe langa acesta atributul target specifica unde sa se deschida documentul HTML spre care este adaugata legatura. Valorile pe care le poate lua sunt urmatoarele: _blank, _parent, _self, _top. Codul HTML pentru un link se poate vedea mai jos:

Page 222: licenta hatz

<a href="URL" target="_blank">Textul link-ului / Imagine</ a>

Page 223: licenta hatz

In cadrul tag-ului <a>, atributul id poate fi folosit pentru a crea un marcaj in interiorul unui document HTML. Marcajele nu sunt afisate in nici un fel special si sunt invizibile pentru cititor. Un marcaj are urmatorul cod:

<a id="semncarte">Ati ajuns la semnul de carte</a>

Un link catre semnul de carte, existent in cadrul aceluiasi document HTML, se adauga folosind urmatorul cod:

<a href="#semncarte">Click aici pentru a merge la semnul de carte</a>

In cazul in care se doreste adaugarea unui link catre semnul de carte de pe un alt document HTML codul este:

<a href="pagina.html#semncarte">Click aici pentru a merge la semnul de carte </a>

In HTML, imaginile sunt definite cu tag-ul <img>. Tag-ul <img> este gol, ceea ce inseamna ca aceasta contine doar atribute si nu are nici o eticheta de inchidere. Pentru a afisa o imagine pe o pagina, trebuie sa utilizam atributul src. Src vine de la "sursa". Valoarea atributului src este URL-ul imaginii pe care dorim sa il afisam. Sintaxa pentru definirea unei imagini se poate vedea mai jos:

<img src="url" alt="titlul sau descrierea imaginii">

URL-ul contine locatia la care este stocata imaginea. Daca dorim sa afisam intr-un document HTML o imagine cu sigla FSEGA, logo.png, situat in directorul /img/ de la "www.econ.ubbcluj.ro" are URL-ul: http://www.econ.ubbcluj.ro/img/logo.png.

Pentru formatarea imaginilor se recomanda folosirea stilurilor CSS. Cele mai importante atribute ale tag-ului <img> pe care le poate contine o imagine sunt prezentate in continuare:

src specifica adresa URL a unei imaginialt specifica un text alternativ pentru imagine si va fi afisat in cazul in care imaginea

nu poate fi afisataheight specifica inaltimea unei imaginiwidth specifica latimea unei imagini

1.2. Interactivitatea cu clientul prin intermediul formularelor

Formularele au fost introduse in HTML pentru a sigura schimbul de informatii intre client si server. Formulare preiau datele de la utilizator si sunt trimise spre a fi procesate de catre scripturi pe partea de server.

Modul de functionare al formularelor este urmatorul:

1: utilizatorul completeaza formularul si apasa butonul de trimitere (se trimit informatiile din formular catre server);

2: numele fiecarui control impreuna cu valorile introduse/selectate sunt trimise catre server;3: serverul proceseaza informatiile prin intermediul unui script care se afla si ruleaza pe partea

de server;4: serverul creaza o noua pagina raspuns pe care o trite utilizatorului.

Page 224: licenta hatz

Un formular HTML se va afla tot timpul intre tag-urile <form> ... <form> si se introduce astfel:

<form action="url-al-unui-script-aflat-pe-server" method="get||post"> elemente de input</form>

Atributul action indica URL-ul fisierului care va prelua, pe partea de server, datele formularului. Acele fisiere pot fi constituite din scripturi CGI, ASP, PHP, etc.

Atributul method indica metoda de transfer, POST sau GET. Cu metoda POST valorile sunt trimise prin intermediul antetelor HTTP, sau transfera un flux de octeti la bufferul de intrare al serverului. Cu metoda (GET) datele sunt codificate intr-un sir de caractere care se alipeste URL-ului specificat in action. URL-ul scriptului de prelucrare contine un sir de caractere ce incepe cu ?, continua cu perechi de forma numeElementFormular = valoareElementFormular, despartite prin &. Acest sir de caractere va fi preluat pe server, de catre scripturile aflate pe server, in vederea prelucrarii informatiilor.

In figura urmatoare se poate vedea cum se trimit datele din formularul de mai sus prim metoda GET.

http://www.econ.ubbcluj.ro/~daniel.mican/script.php?nume=daniel+mican&email=daniel.mican%4 0econ.ubbcluj.ro

Metoda GET este bine sa se foloseasca pentru:

13 formulare scurte (cum ar fi casetele de cautare);14 atunci cand se primesc date de la serverul web (nu se recomanda trimiterea de informatii

care ar trebui sa fie adaugate sau sterse dintr-o baza de date).

Metoda POST este bine sa se foloseasca in cazul in care formularul:

Page 225: licenta hatz

4: permite utilizatorilor sa incarce fisiere;5: contine foarte multe elemente de input;6: contine date sensibile (de exemplu parole);7: adauga / sterge informatii dintr-o baza de date.

Intre etichetele <form> se include textul formularului si elementele sale. Un eveniment important tratat in scripturi se ferera la actiunea de trimitere (Submit), asociat cu actiunea specificata in action.

In cele ce urmeaza prezentam cele mai importante atribute pentru tag-ul <form>:

accept-charset specifica codificarile de caractere care urmeaza sa fie utilizate pentru trimitereaformularului

action specifica unde sa se trimita datele din formular atunci cand se apasa pe butonulde trimitere

autocomplete specifica daca un formular ar trebui sa aiba autocomplete activat sau nuenctype specifica modul in care datele din formular ar trebui sa fie codificate atunci cand

sunt trimise spre server (numai pentru metoda = "post")method specifica metoda HTTP ce va fi utilizata pentru trimiterea datelor din formularname specifica numele unui formularnovalidate specifica daca formularul nu ar trebui sa fie validat atunci cand se apasa pe

butonul de trimiteretarget specifica unde sa afiseze raspunsul care este primit dupa trimiterea formularului

Un formular HTML poate contine mai multe tipuri de elemente de intrare, cum ar fi: campurile de tip text, liste derulante, legende, elemente de etichetare, casete de selectare, butoane radio, butoane de trimitere / resetare.

Fiecare control din cadrul unui formular are rolul de a aduna si transmite informatie pe server. Pentru a sti carui element ii apartine o data care a fost trimisa pe server, fiecare element de input trimite un nume si o valoare. Aceasta valoare poate fi introdusa (campuri de tip text) sau aleasa (liste derulante, butoane radio) de catre utilizator, dintr-un set de raspunsuri predefinit.

nume valoare

nume = daniel mican

email = [email protected]

Cel mai important element din cadrul unui formular este elementul <input>. Elementul <input> este folosit pentru a capta informatii provenite de la utilizator. Un element <input> poate varia in mai multe moduri, in functie de atributul type. Un element <input> poate fi un camp de tip, caseta, parola, buton radio, buton de trimitere, etc.

Cele mai frecvente tipuri de elemente de tip <input> sunt descrise mai jos:

<input type="text"> defineste un camp de introducere ce se intinde pe o linie, in careutilizatorul poate introduce text;

<input type="password"> defineste un camp de tip parola;<input type="radio"> defineste un buton radio. Butoane radio permit unui utilizator sa

selecteze doar o singura optiune dintr-un numar limitat de optiuni;<input type="checkbox"> defineste o caseta de selectare. Casete de selectare permit unui

utilizator sa selecteze zero sau mai multe optiuni dintr-un numarlimitat de optiuni;

Page 226: licenta hatz

<input type="submit"> defineste un buton de trimitere;<input type="button"> defineste un buton pe care se poate da click (de obicei se utilizeaza

impreuna cu JavaScript pentru a rula un script);<input type="color"> defineste un selector de culoare;<input type="date"> defineste un control de tip data (an, luna si zi);<input type="datetime"> defineste un control de tip data impreuna cu unul de tip timp (an,

luna, zi, ora, minut, secunda, si fractiune de secunda, in functie defusul orar UTC );

<input type="email"> defineste un camp pentru o adresa de e-mail;<input type="file"> defineste un camp pentru selectarea fisierelor si un buton "Browse..."

(pentru incarcarea fisierelor);<input type="hidden"> defineste un camp de introducere ascuns;<input type="image"> defineste o imagine ce va fi setata ca buton de trimitere a

formularului;<input type="reset"> defineste un buton de resetare (reseteaza toate valorile unui formular

la valorile implicite);<input type="tel"> defineste un camp pentru introducerea unui numar de telefon;<input type="url"> defineste un camp pentru introducerea unui URL.

Elementul <input type="text"> defineste un camp de introducere care se intinde pe o singura linie, in care utilizatorul poate introduce text. Atributul name este folosit pentru a prelua, pe server, valorile trimise prin intermediul formularului. Atributul size este folosit pentru a specifica latimea formularului (se recomanda evitarea lui si folosirea CSS). Artibutul maxlength este folosit pentru a limita numarul maxim de caractere pe care utilizatorul le poate introduce.

Nume <input type="text" name="nume" size="25" maxlength="50" />

Elementul <input type="password"> defineste un camp de tip parola. Este similar cu tipul text, cu diferenta ca mascheaza caracterele.

Parola <input type="password" name="parola" size="25" maxlength="50" />

Elementul <input type="hidden"> defineste un camp de introducere ascuns. Aceste controale nu sunt afisate in cadrul formularului. Acestea pot fi vazute doar in cazul in care se vizualizeaza sursa paginii HTML.

<input type="hidden" name="cod" value="acesta valoare este trimisa pe server">

Elementul <input type="file"> defineste un camp pentru selectarea fisierelor si un buton "Browse..." (pentru incarcarea fisierelor). Permite alegerea si incarcarea fisierelor grafice, video, mp3, pdf, etc.

<input type="file" name="fisier" />

Elementul <input type="submit"> defineste un buton de trimitere. Un buton de trimitere este folosit pentru a trimite datele din formular catre un server. Datele sunt trimise la pagina specificata in atributul action al formularului. Fisierul definit in atributul action preia datele de intrare trimise si de obicei le introduce intr-o tabela din cadrul bazei de date.

Page 227: licenta hatz

<input type="submit" name="trimite" value="Trimite formular" />

Elementul <input type="reset"> defineste un buton de resetare (reseteaza toate valorile unui formular la valorile implicite).

<input type="reset" value="Resetati">

Tag-ul <textarea> defineste un control de introducere a textului pe mai multe linii. O zona de text poate contine un numar nelimitat de caractere, chiar daca se specifica un numar de coloane si linii. Dimensiunea unei zone de text pot fi specificata cu ajutorul atributelor cols si rows. Sau chiar se recomanda folosirea proprietatilor CSS, height si width. In cazul in care se doreste introducerea unei valoari implicite, aceasta va fi pozitionata intre cele doua tag-uri <textarea>...</textarea>.

<textarea name="observatii" rows="5" cols="30"> valoare implicita </textarea>

Elementul <select> este folosit pentru a crea o lista derulanta. Tag-urile <option> din interiorul elementului definesc optiunile disponibile in cadrul listei. Tag-ul <optgroup> este folosit pentru a grupa optiunile in cadrul listei. In cazul in care o lista contine un numar mare de optiuni, gruparea optiunilor este recomandata pentru ca acestea devin mai usor de manevrat pentru utilizatori. Cand tributul selected este prezent in cadrul tag-ului <option>, optiunea devine implicita. Atributul value ataseaza o valoare elementului listei care va fi trimisa, in cazul in care se selecteaza optiunea.

<select><option value="Garsoniera">Garsoniera</option>

<optgroup label="Apartament"><option value="1 camera" selected>1 camera</option>

<option value="2 camere">2 camere</option> </optgroup>

</select>

Tag-ul <fieldset> este folosit pentru gruparea elementelor in cadrul unui formular. Tag-ul <fieldset> deseneaza o caseta in jurul elementelor pe care le grupeaza. Tag-ul <legend> defineste o legenda pentru elementul <fieldset>.

<form><fieldset><legend> Detalii personale: </legend>

Nume: <input type="text" name="nume"> </fieldset>

</form>

Page 228: licenta hatz

HTML5 a introdus noi controale care pot fi folosite in cadrul formularelor pentru a standardiza modul in care unele informatii sunt colectate. Browserele mai vechi, care nu recunosc aceste elemente, le vor trata la fel ca pe un simplu element de tip text. Totusi, browserele unor smartphone-uri isi modifica tastatura in functie de tipul elementului de input astfel incat sa se optimizeze introducerea datelor.

Elementul <input type="date"> defineste un control de tip data (an, luna si zi). Daca s-a folosit un element de tipul date browserul se va verifica daca utilizatorul a furnizat informatii in formatul corect pentru data.

<input type="date" name="data_eveniment" />

Elementul <input type="datetime"> defineste un control de tip data impreuna cu unul de tip timp (an, luna, zi, ora, minut, secunda, si fractiune de secunda, in functie de fusul orar UTC ).

<input type="datetime" name="data_ora_eveniment" />

Elementul <input type="email"> defineste un camp pentru o adresa de e-mail. Daca s-a folosit un element de tipul email browserul se va verifica daca utilizatorul a furnizat informatii in formatul corect al unei adrese de e-mail.

<input type="email" name="adresa_email" />

Elementul <input type="url"> defineste un camp pentru a introduce un URL. Daca s-a folosit un element de tipul url browserul se va verifica daca utilizatorul a furnizat informatii in formatul corect al unei adrese web/URL.

<input type="url" name="adresa_site" />

Page 229: licenta hatz

2. CSS (Cascading Style Sheets)

CSS este un standard W3C pentru definirea prezentarii documentelor scrise in HTML. Prezentarea se refera la modul in care documentul este afisat in browser pentru utilizator. Datorita faptului ca CSS se ocupa de stilizarea si prezentarea documentelor, HTML se poate ocupa de definirea structurii documentului, asa cum este prevazut.

CSS este un limbaj separat cu propria sintaxa. Stilurile CSS au rezolvat o mare problema si salveaza o multime de timp in cadrul activitatilor de dezvoltare a site-urilor web. Acest lucru pentru faptul ca HTML nu a fost destinat sa contina tag-uri pentru formatarea documentelor. HTML a fost destinat sa defineasca continutul si structura unui document.

In HTML 4.0, toate formatarile pot fi eliminate din document HTML si stocate intr -un fisier CSS extern. Acest lucru este chiar recomandat pentru ca toate browserele din zilele noastre suporta CSS. CSS defineste cum vor fi afisate elemente HTML. Stilurile sunt in mod normal, salvate in fisiere CSS externe. Foile de stil externe permit schimbarea aranjarii si aspectului tuturor paginilor dintr-un site, prin editarea unui singur fisier CSS.

CSS functioneaza prin asocierea unor reguli elementelor HTML. Aceste reguli reglementeaza modul in care ar trebui sa fie afisat continutul elementelor specificate. O regula CSS contine doua parti: un selector si o declaratie.

declaratie

selector proprietate: valoare;

Selectorii indica carui element i se aplica regula. Aceeasi regula se poate aplica la mai mult de un element, daca numele elementelor sunt separate prin virgule.

Declaratiile indica cum ar trebui sa fie stilizate elementele mentionate prin intermediul selectorului. Declaratiile sunt impartite in doua parti (o proprietate si o valoare), fiind separate prin punct si virgula.

Proprietatile indica aspectele elementului pe care dorim sa le modificam. De exemplu, culoarea, fontul, latimea, inaltimea sau bordura.

Valorile specifica setarile pe care dorim sa le utilizam pentru proprietatile alese. De exemplu, daca dorim sa modificam proprietatea culoare, atunci valoarea este culoarea pe care dorim sa o aiba textul din elementele selectate.

Pentru un selector se pot adauga mai multe declaratii. Acestea vor fi adaugate intre cele doua acolade si vor constitui un bloc de declaratii. Pentru a face mai usor de citit codul CSS, se recomanda adaugarea unei singure declaratii pe fiecare linie.

selector proprietate1: valoare1;proprietate2: valoare2; bloc de declaratii proprietate3: valoare3;

Declaratiile CSS se pot introduce in cadrul paginilor HTML in trei moduri:

5 Foaie de stil externa (declarata intr-un fisier CSS extern)

Page 230: licenta hatz

2 Foaie de stil interna (declarata in sectiunea de head a documentului HTML)3 Stilul declarat inline (declarat in interiorul unui element HTML)

Adaugarea declaratiilor CSS in foile de stil externe. In acest caz foaia de stil externa este un document separat de tip text, cu extensia *.css, care contine o serie de declaratii de stil. Dupa ce a fost creat, documentul *.css poate fi legat, sau importat in unul sau mai multe documente HTML. In acest fel, toate documentele HTML dintr-un site web pot folosi aceeasi foaie de stil. Aceasta este metoda cea mai puternica si preferata pentru atasarea foilor de stil. O foaie de stil externa este ideala atunci cand stilul este aplicat la mai multe pagini. Cu o foaie de stil externa, putem modifica aspectul unui intreg site prin simpla modificare realizata intr-un singur fisier. Fiecare pagina trebuie leagata la foaia de stil cu ajutorul tag-ul <link>. Tag-ul <link> va fi pozitionat tot timpul in partea de head.

<head><link rel="stylesheet" type="text/css" href="stiluri.css"> </head>

O foaie de stil externa poate fi scrisa in orice editor de text. Fisierul nu trebuie sa contina nici un tag HTML. Fisierul stiluri.css contine urmatorul cod CSS:

h1 color: red; p color: blue;

Adaugarea declaratiilor CSS in foaia de stil interna. Acesta este plasata intr-un document HTML folosind elementul stil. Este important de stiut ca declaratiile sale se aplica numai in documentul HTML in care a fost declarata. O foaie de stil interna trebuie sa fie utilizata doar atunci cand o singura pagina HTML are un stil unic. Elementul de stil trebuie sa fie plasat in sectiunea <head> a unei pagini HTML, cu ajutorul tag-ului <style>.

<head><style>h1 color: red; p color: blue; </style>

</head>

Adaugarea declaratiilor CSS inline. Acestea pot fi declarate chiar in interiorul unui element HTML folosind atributul style. Proprietatile si valorile se aplica doar elementului in care au fost definite. Folosirea stilurilor inline ar trebui sa fie evitata. Acestea trebuie folosite doar atunci cand este absolut necesar pentru a suprascrie declaratiile provenite de la o foaie de stil incorporata sau externa. Un stil declarat inline pierde multe din avantajele foilor de stil. Prin urmare rezulta amestecarea declaratiilor de prezentare si stilizare cu tag-urile HTML care realizeaza structurarea si continutul. De asemenea, activitatea de modificare a prezentarii paginilor HTML si a site-ului per ansamblu este mult mai dificila. Astfel, pentru modificarea fiecarei declaratii de stil trebuie mers direct in codul sursa al paginii HTML.

<h1 style = "color: red"> Titlu </h1> <p style = "color: blue"> Paragraf </p>

2.1. Selectorii CSS

Page 231: licenta hatz

In plus, fata de stabilirea unui stil pentru un element HTML, CSS permite specificarea propriilor selectori. Exista mai multe tipuri diferite de selectori CSS care permit declararea unor reguli pentru anunite elemente specifice din cadrul unui document HTML. Selectorii CSS sunt case sensitive, astfel

Page 232: licenta hatz

incat acestia trebuie sa se potriveasca exact cu numele elementelor si valorilor de atribute. Exista unii selectori mai avansati care permit selectarea unor elemente bazate pe atributele si valorile lor. In continuare vom prezenta cei mai frecvent utilizati selectorii CSS.

Selectorul universal - se aplica la toate elementele din document

* Se aplica tuturor elementelor din pagina

Selectorul de tip - se aplica numelor de elemente

h1, h2, h3 Se aplica elementelor <h1>, <h2> si <h3>

Selectorul de clasa - se aplica unui element al carui atribut clasa are o valoare care se potriveste cu cel specificat dupa simbolul . (punct)

.azorel Se aplica tuturor elementelor care au atributul class egal cu azorel

p.azorel Se aplica doar elementelor <p> a caror atribut class este egal cu azorel

Selectorul ID - se aplica unui element al carui atribut id are o valoare care se potriveste cu cel specificat dupa simbolul # (diez)

#cnp Se aplica elementului al carui atribut id este egal cu cnp

Selectorul copil - se aplica unui element care este un copil direct al unui alt element

li>a Se aplica elementelor <a> care sunt continute in cadrul unui element <li>

Selectorul descendent - se aplica unui element care este un descendent din cadrul unui alt element specificat (nu doar unui copil direct al acestui element)

p a Se aplica elementelor <a> care sunt continute in cadrul unui element <p>, chiar daca exista si alte elemente imbricate intre ele

Selectorii grupati- se aplica numelor de elemente specificate

h1, p, em, img Se aplica elementelor <h1>, <p>, <em> si <img>

2.2. Agregarea in cascada a stilurilor

De cele mai multe ori in cadrul aplicatiilor web exista mai multe foi de stil care se agrega in cascada. In cazul in care exista doua sau mai multe reguli care se aplica aceluiasi element, este important sa se inteleaga care va avea prioritate. Agregarea in cascada se refera la ceea ce se intampla atunci cand mai multe declaratii de stil lupta pentru controlul elementelor de pe o pagina. Declaratiile de stil se propaga in cascada, in jos, pana cand vor fi suprascrise de o declaratie de stil cu o greutate mai mare.

Page 233: licenta hatz

In general putem spune ca, toate stilurile vor fi agregate in "cascada", intr-o noua foaie de stil virtuala. Agregarea se face respectand urmatoarea ordine, tinand cont ca declaratiile inline au cea mai mare prioritate:

7 Foaia de stil implicita a browser-ului8 Foaie de stil externa (declarata intr-un fisier CSS extern)9 Foaie de stil interna (declarata in sectiunea de head a documentului HTML)10 Stilul declarat inline (declarat in interiorul unui element HTML)

Prin urmare, un stil inline (declarat in interiorul unui element HTML) are cea mai mare prioritate. Acest lucru inseamna ca va inlocui un stil definit in interiorul tag-ul <head>, sau intr-o foaie de stil externa, respectiv in cadrul browser-ului. Daca legatura la foaia de stil externa este plasata dupa foaia de stil interna in HTML <head>, foaia de stil externa va inlocui foaia de stil interna.

De exemplu, in cazul codului HTML de mai jos:

<html><head>

<title>Exemplu de agregare in cascada a stilurilor</title> <link rel="stylesheet" type="text/css" href="stilulmeu.css"> <style>

h1color: red; pcolor: blue;

</style></head><body>

<h1 style="color: indigo">Titlu</h1> <p style="color: violet">Paragraf</p>

</body></html>Si a codului CSS de mai jos continut in cadrul fisierului stilulmeu.css:

h1color: green; pcolor: orange;

Va rezulta:

Dupa ce foile de stil au fost agregate in "cascada", intr-o noua foaie de stil virtuala, conflictele pot sa apara in continuare. Prin urmare, regula agregarii in cascada continua si la nivel de regula. Cand doua reguli dintr-o foaie CSS intra in conflict, tipul de selector este folosit pentru a determina castigatorul. Cu cat este mai specific selectorul, cu atat mai multa greutate ii este acordata pentru a suprascrie declaratiile contradictorii.

In cazul in care doi selectorii sunt identici, sau de aceeasi importanta, oricare dintre acestia este declarat ultimul va suprascrie pe precedentii. Prin urmare cel care apare ultimul va avea prioritate.

De exemplu, in cazul codului HTML de mai jos:

<html><head>

Page 234: licenta hatz

<title>Exemplu de specificitate si prioritate</title> <style>

* color: blue; h1 color: purple; p b color: violet; b color: orange; b color: red; p color: chocolate; p#abstract color: green;

</style></head><body>

<h1>Titlu</h1><p id="abstract">Acesta este un <b>abstract</b></p> <p>Acesta este un text dintr-un paragraf</p>Acesta e un text <b>oarecare</b>

</body></html>

Va rezulta:

Este foarte usor sa suprascriem, in mod accidental, declaratiile anterioare in momentul in care vom ajunge sa folosim proprietati combinate. Prin urmare, modul de agregare a foilor de stil si importanta selectorilor este un comportament deosebit de important de care trebuie sa tinem cont.

2.3. Mostenirea in CSS

Mostenirea se poate folosi pentru a crea un avantaj atunci cand scriem foile de stil. De exemplu, daca dorim ca toate elementele de tip text sa fie formatate cu fontul Verdana avem doua optiuni. Am putea scrie declaratii pentru fiecare element din cadrul documentului HTML si sa setam proprietatea font-face astfel incat textul sa fie formatat cu Verdana. O cale mult mai buna ar fi sa scriem o singura regula de stil prin care sa se aplice proprietatea font-face la elementul <body>, iar toate elementele de tip text incluse in elementul <body> sa mosteneasca acel stil.

Daca specificam pe elementul <body> proprietati precum fontul sau culoarea, se vor aplica pe mai multe elemente continute in cadrul documentului HTML. Acest lucru se datoreaza faptului ca valoarea proprietatii font-family este mostenita de elementele continute. Aceast lucru ne salveaza de la a fi nevoie sa aplicam aceste proprietati pentru mai multe elemente. Prin urmare vor rezulta foi de stil mai simple si de dimensiuni mai mici.

De exemplu, in cazul codului HTML de mai jos:

<html><head>

<title>Exemplu de specificitate si prioritate</title> <style>

Page 235: licenta hatz

body font-family: Arial, Verdana, sans-serif; font-weight: bold;color: blue; background-color: yellow;

.cutie color: white; background-color: green; border: 1px solid red;

.cutiutza color: gold;

</style></head><body><div>

<p>Mostenesc de la body fontul, proprietatea bold si culoarea albastra</p></div><div class="cutie">

<p>Mostenesc de la body fontul si proprietatea bold. Dar am culoarea alba, culoarea de fundal verde si bordura rosie.</p>

<div class="cutiutza"><p>Mostenesc de la body fontul si proprietatea bold. Am culoarea aurita, dar mostenesc culoarea de fundal verde de la cutie. Bordura nu se mosteneste.</p> </div>

</div></body></html>

Va rezulta:

E bine de stiut ca nu toate proprietatile sunt mostenite. Este important sa retinem ca unele proprietati CSS sunt mostenite, iar altele nu. In general, proprietatile legate de stilul, dimensiunea textului, fontul, culoarea, etc, sunt transmise si la elementele continute. Proprietati precum bordura unui element, marginile, fundalurile, etc, care afecteaza zona din jurul elementului tind sa nu fie transmise. Acest lucru este destul de logic. De exemplu, daca am pus un chenar in jurul unui div, nu am vrea ca acesta sa apara si in jurul fiecarui element inline continut (de ex. paragraf). Trebuie sa tinem minte ca orice proprietate aplicata unui element specific va suprascrie valorile mostenite pentru acea proprietate.

Page 236: licenta hatz

2.4. Specificarea culorilor

Exista trei modalitati mai des folosite in practica, prin care se pot specifica culorile. Culorile pot fi specificate prin intermediul:

6: numelor de culori7: valorilor RGB8: codurilor hexa zecimale

CSS1 si CSS2 au adoptat cele 16 nume de culori standard, introduse initial in HTML 4.01. CSS3 adauga suport pentru un set extins ce contine 140 de nume de culori.

Cele 16 culori standard sunt: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow.

Codurile hexa zecimale sunt codurile de sase cifre care reprezinta cantitatea de rosu, verde si albastru dintr-o culoare, precedata de semnul #. Sistemul de numerotare hexazecimal foloseste 16 elemente: perechi de numere de la 0 la 9 si litere de la A la F.

#RRGGBBAlb = #FFFFFF sau #FFF (echivalentul lui 255,255,255)Negru = #000000 sau #000 (echivalentul lui 0,0,0)

2.5. Unitati de masura in CSS

CSS ofera o varietate de unitati de masura pe care le enumeram si descriem in continuare:

3.5. px - pixeli (un px reprezinta un punct de pe ecranul computerului)3.6. % - procent3.7. in - inch3.8. cm - centimetru3.9. mm - milimetru3.10. em - 1em este egal cu dimensiunea fontului curent. 2em inseamna de 2 ori

dimensiunea fontului curent.

De exemplu, in cazul in care un element este afisat cu un font de 12 pt, atunci '2em" este de 24 pt. "em" este o unitate foarte utila in CSS, deoarece se poate adapta automat la fontul pe care cititorul il foloseste.

2.6. Box Model

Un aspect important in structurarea si stilizarea elementelor cu CSS este asa-numitul „Box Model”. Acest model stabileste ca fiecare element de structura din cadrul unei pagini Web poate fi vazut ca o cutie/caseta (dreptunghi) definita prin urmatoarele proprietati:

4.3. Margin – permite stabilirea unei zone libere transparente in exteriorul bordurii4.4. Border – permite adaugarea unei borduri in jurul elementului luat in considerare4.5. Padding – permite stabilirea unei zone libere transparente in interiorul bordurii4.6. Content – permite introducerea unui continut in cadrul elementului

Page 237: licenta hatz

Modelul de mai sus permite stabilirea de borduri si spatieri intre elementele din cadrul unei pagini Web.

Page 238: licenta hatz

Controlarea felului in care aceste casete pentru elemente apar, este esentiala. Prin pozitionarea si gestionarea lor vom construi layout-ul paginilor web.

Proprietatea border-width este folosita pentru a controla latimea unei borduri. Valoarea acestei proprietati poate fi specificata fie in pixeli sau folosind una dintre urmatoarele valori:

4.1.7. thin - specifica o bordura subtire4.1.8. medium - specifica o bordura de grosime medie4.1.9. thick - specifica o bordura grosa

Putem controla dimensiunea individuala a bordurilor utilizand patru proprietati distincte:

4.3.3 border-top-width - specifica latimea bordurii de sus4.3.4 border-right-width - specifica latimea bordurii din dreapta4.3.5 border-bottom-width - specifica latimea bordurii de jos4.3.6 border-left-width - specifica latimea bordurii din stanga

Putem specifica, de asemenea, latimi diferite pentru cele patru valori ale bordurii intr-o singura proprietate. Valorile vor aparea in sensul acelor de ceasornic: sus, dreapta, jos si stanga.

<html><head><style>

div border: solid gray; border-width: 5px 6px 10px 3px;

</style></head><body>

<div>Sus 5px, dreapta 6px, jos 10px, stanga 3px.</div> </body></html>

Acelasi mod de folosinta, ca si pentru proprietatea border-width, se aplica si proprietatilor padding si margin.

Proprietatea margin permite stabilirea unei zone libere transparente in exteriorul bordurii. Aceasta zona nu este afectata de culoarea de fundal al elementului si preia culoarea de fundal al elementului

Page 239: licenta hatz

in care este continuta. Putem controla spatierea individuala din interiorul casetei utilizand patru proprietati distincte:

4.3.7. margin-top - specifica spatierea din exterior in partea de sus4.3.8. margin-right - specifica spatierea din exterior in partea dreapta4.3.9. margin-bottom - specifica spatierea din exterior in partea de jos4.3.10. margin-left - specifica spatierea din exterior in partea stanga

Proprietatea padding permite stabilirea unei zone libere transparente in interiorul bordurii. Aceasta zona este afectata de culoarea de fundal al elementului. Putem controla spatierea individuala din exteriorul casetei utilizand patru proprietati distincte:

padding-top - specifica spatierea din interior in partea de sus padding-right - specifica spatierea din interior in partea dreapta padding-bottom - specifica spatierea din interior in partea de jos padding-left - specifica spatierea din interior in partea stanga

La fel, putem specifica, margini si spatieri diferite pentru cele patru valori intr-o singura proprietate. Valorile vor aparea in sensul acelor de ceasornic: sus, dreapta, jos si stanga.

Dimensionarea casetelor

In mod normal o caseta se adapteaza la dimensiunea continutului care se afla in ea. Pentru a stabili dimensiuni absolute se pot folosi proprietatile height si width.

Cele mai populare moduri prin care se poate specifica dimensiunea unei casete, este de a utiliza pixeli, procente, sau ems. In mod traditional, pixeli au fost cea mai populara metoda, deoarece permit proiectantilor sa controleze cu exactitate dimensiunea casetei.

Cand utilizam procente, dimensiunea casetei este relativa la dimensiunea fereastrei browser-ului sau, in cazul in care caseta este continuta de catre o alta caseta, acesta reprezinta un procent din dimensiunea casetei in care este continuta.

<html><head><style>

divwidth: 210px; padding: 15px;border: 15px solid gray; margin: 15px;

</style></head><body>

<img src="poza.png"><div>Poza de deasupra e lata de 300px.Latimea acestui element:<br> 210 (latime) +<br>30 (2*15 padding) +<br>30 (2*15 bordura) +<br>30 (2*15 margine) =<br>300px.</div>

</body></html>

Page 240: licenta hatz

Putem limita dimensiunea casetelor cu ajutorul proprietatilor: min-width, max-width, min-height,max-height.

min-width - stabileste latimea minima a unui element si previne ca valoarea proprietatii width sa fie mai mica decat min-width.

max-width - seteaza latimea maxima a unui element si previne ca valoarea proprietatii width sa fie mai mare decat max-width.

min-height - seteaza inaltimea minima a unui element si previne ca valoarea proprietatii height sa fie mai mica decat min-height.

max-height - seteaza inaltimea maxima a unui element si previne ca valoarea proprietatii height sa fie mai mare decat max-height.

<html><head><style>

.adaptabil background-color: gold; min-width: 400px; max-width: 600px; padding: 10px;

</style></head><body>

<div class="adaptabil">Acest div se redimensioneaza in functie de rezolutia ecranului.<p> Dimensiunea minima este de 400px, iar cea maxima de 600px. Textul de pe prima linie nu va fi afectat de redimensionare.</div>

</body></html>

Page 241: licenta hatz

3. JavaScript

JavaScript:

este utilizat pentru programarea comportamentului paginilor web si pentru adaugarea de interactivitate;

este un limbaj usor, dar foarte complex si puternic; este case sensitive; este un limbaj de scripting client-side, care ruleaza pe calculatorul utilizatorului si nu pe

server; ruleaza in browser-ul utilizatorului, care citeste codul si il interpreteaza in momentul in care il

primeste (nu are nevoie de un compilator); a fost standardizat in 1996 de catre European Computer Manufacturer's Association (ECMA),

iar din acest motiv se mai gaseste sub denumirea de ECMAScript; codul JavaScript poate fi editat in orice editor de texte; codul JavaScript (si modul in care il folosim) este dependent de capacitatile si setarile

browser-ului; JavaScript si Java sunt doua limbi complet diferite, atat in concept cat si in design.

JavaScript:

1.3.15. nu a fost creat ca un limbaj de programare general, ci a fost creat cu scopul de a manipula pagini web;

1.3.16. nu poate accesa fisierele locale;1.3.17. nu poate accesa in mod direct o baza de date;1.3.18. nu poate accesa componentele hardware (USB, etc);1.3.19. nu este activat si suportat pe toate browserele, asa ca trebuie tinut cont de acest

lucru in momentul dezvoltarii unei aplicatii web.

JavaScript poate fi utilizat pentru:

scrierea script-urilor care reactioneaza la comportamentul sau datele introduse de catre utilizator;

validarea datelor de intrare pe care le introduc utilizatorii in cadrul unui formular; schimbarea continutului si informatiilor dintre documentul curent si server. Acest lucru se

face, prin intermediul Ajax, fara a reincarca intreaga pagina; crearea meniurilor dinamice si a plierii continutului in functie de click-urile utilizatorilor; manipularea arborelui DOM (pentru a schimba structura si continutul unei pagini HTML).

Astfel, JavaScript permite:

Page 242: licenta hatz

o schimbarea elementelor HTML o stergerea elemente HTMLo crearea de noi elemente HTMLo copierea si clonarea elementelor HTML o schimbarea atributelor CSS

Amplasarea codului se realizeaza intre tagurile <script>…</script>.

<script>// aici va fi amplasat codul JavaScrpitcomanda JavaScrpit; cod JavaScript comanda JavaScrpit;

</script>

Inserarea codului JavaScript in cadrul paginilor HTML se realizeaza in doua moduri:

Fisier extern (declarat intr-un fisier *.js extern) Script incorporat (incorporat in sectiunea de head sau body a documentului HTML)

Adaugarea codului JavaScript intr-un fisier .js extern:

<head><script type="text/ javascript" href="scriptulmeu.js">

</head>

Fisierul scriptulmeu.js contine urmatorul cod JavaScript:

alert("Salutare");

Elementul script poate fi amplasat oriunde in document, dar cele mai comune si recomandate locuri pentru script-uri sunt in partea de <head> sau <body>. In cazul in care se adauga in sectiunea body, codul trebuie sa fie pozitionat chiar inainte de inchiderea tag-ului </body>.

In sectiunea <head> In sectiunea <body>

<html> <html><head> <head>

<script> </head>alert("Salutare"); <body>

</script > Text oarecare</head> <script><body> alert("Salutare");

Text oarecare </script ></body> </body></html> </html>

Page 243: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 244: licenta hatz

3.1. Variabilele in JavaScript

O variabila este ca un container de informatii. In primul rand trebuie sa o definim si sa ii dam un nume. Pe urma putem sa ii atribuim o valoare care poate fi un numar, un text, un element din DOM sau chiar si o functie. In acest fel putem oricand sa accesam valoarea atribuita pe baza numelui variabilei. Valoarea stocata in cadrul variabilei poate fi oricand modificata sau mutata in functie de nevoi.

Orice variabila se declara folosind cuvantul cheie var, urmat de numele variabilei. Semnul egal "=" indica faptul ca se atribuie o valoare. Orice declaratie se termina prin adaugarea la sfarsitul liniei a semnului punct si virgula ";".

Declararea variabilelor

In momentul in care declaram variabile este bine sa tinem cont de cateva reguli:

4. numele unei variabile poate contine litere, numere si liniute de subliniere "_".5. numele trebuie sa inceapa cu o litera, cu semnul $ sau _. Se recomanda ca numele variabilei

sa inceapa tot timpul cu o litera:6. numele variabilelor nu pot contine spatii:7. numele variabilelor nu pot contine caractere speciale precum (! @ # % . , / \ + * = etc).8. pentru a declara mai multe variabile intr-o declaratie vom incepe declaratia cu var si vom

separa variabilele prin virgula: var varsta = 20, prenume = "Cristina";

Tipuri de date in JavaScript

Valorile pe care le atribuim variabilelor pot fi de cateva tipuri de date distincte: Undefined, String, Number, Boolean, Array, Object.

3.2. Operatori

Operatorii sunt folositi pentru a realiza anumite operatii elementare intre variabile. In JavaScript sunt mai multe tipuri de operatori:

2.3. matematici - realizeaza diferite operatii matematice pe valorile numerice;2.4. de comparare - evalueaza si compara valorile si variabilele;2.5. logici - compara doua expresii si returneaza true daca amandoua sunt adevarate, in caz

contrar returneaza false.Operatori aritmetici+ x = 3 + 2 Adunare- x = 3 - 2 Scadere

Page 245: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 246: licenta hatz

* x = 3 * 2 Inmultire/ x = 3 / 2 Impartire% x = 3 % 2 Modul (restul impartirii)++ x = y++ Incrementeaza valoarea unui numar (sau a unei variabile care contine o valoare

x = ++y numerica) cu 1-- x = y-- Scade valoarea unui numar (sau a unei variabile care contine o valoare

x = y-- numerica) cu 1

Operatori de asignare= x = 2 Asigneaza valoarea unei variabile+= x += y (x = x + y) Insumeaza valoarea la valoarea variabilei-= x -= y (x = x - y) Scade valoarea din valoarea variabilei*= x *= y (x = x * y) Inmulteste valoarea la valoarea variabilei/= x /= y (x = x / y) Imparte valoarea variabilei

Operatori de comparare== 2 == 3 este false Este egal cu!= 2 != 3 este true Nu este egal cu=== 2 === 3 este false Este identic cu (este egal cu si de acelasi tip de date)!== 2 !== 3 este true Nu este identic cu (nu este egal cu si de acelasi tip de date)> 2 > 3 este false Este mai mare decat>= 2 >= 3 este false Este mai mare sau egal decat< 2 < 3 este true Este mai mic decat<= 2 <= 3 este true Este mai mic sau egal decat

Operatori logici&& 1 < 5 && 3 < 1 este false AND / SI logic|| 1 < 5 || 3 > 1 este true OR / SAU logic! ! (1 < 3 ) este false Negatie logica

Structuri decizionale if/else

Declaratiile conditionale sunt utilizate pentru a efectua diferite actiuni in functie de diferite conditii.

if( conditie ) // executa acest cod in cazul in care conditia este adevarata

else

// executa acest cod in cazul in care conditia nu este adevarata

Exemplu:

var a = 2, b = 4; if( a < b )

alert (" a este < decat b ");else

alert (" a este > decat b ");

Page 247: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB

Structura for

Lect.univ.dr. Daniel Mican [email protected]

Page 248: licenta hatz

Structura for este folosita pentru a executa un bloc de cod de un anumit numar de ori si are urmatoarea sintaxa:

for (initializeaza variabila, testeaza conditie, modifica valoarea)

// executa acest cod in cazul in care conditia este adevarata

Exemplu:

for ( var i = 1; i < 3; i++) alert ("Numarul este " + i);

Structura while

Structura while executa un bloc de cod, atata timp cat o conditie specificata este adevarata. while (conditie)

// executa acest cod in cazul in care conditia este adevarata

Exemplu:

var i = 1; while (i < 3)

alert ("Numarul este " + i); i++;

Structura do/while

Structura do/while este o varianta a structurii while. Aceasta va executa blocul de cod cel putin o data, inainte de a verifica daca conditia este adevarata. Pe urma se va repeta executia codului atata timp cat conditia este adevarata.do

← executa acest cod in cazul in care conditia este adevarata while (conditie);Exemplu:

var i = 1; do

alert ("Numarul este " + i); i++;

while (i < 3)

3.3. Functii in JavaScript

Page 249: licenta hatz

O functie JavaScript este:8. un bloc de cod programat pentru a indeplini o anumita sarcina;

Page 250: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 251: licenta hatz

executata in momentul in care este invocata de catre un anumit eveniment; definita prin intermediul cuvantului cheie al functiei function, urmat de un numele functiei,

de paranteze (), iar codul se gaseste intre acolade :← intre paranteze se pot gasi zero sau mai multi parametri (parametrul1, parametrul2,

..., parametruln)← codul care va fi executat de catre functie este plasat in interiorul acoladelor

Functiile definite de catre utilizator au forma:

function numeFunctie ( parametri ) codul care va fi executat;

Exemplu de functie care nu primeste parametrii:

function afiseazaMesaj( ) alert("Functia a fost apelata");/* acest cod nu va rula pana in momentul in care codul functiei functia afiseazaMesaj() va fi apelata */

function afiseazaMesaj(); //apelarea functiei afiseazaMesaj()

Exemplu de functie care primeste parametrii:

function adunaNumere( a, b ) return a + b;alert("Acest text nu va fi afisat");/* acest cod nu va rula pana in momentul in care codul functiei functia adunaNumere () va fi apelata */

alert( function adunaNumere( 2, 3 ) ); //afiseaza numarul "5"

Pe langa functiile definite de catre utilizator, in JavaScript exista si o serie de functii native. Functiile JavaScript native sunt cele care vin "out-of-the-box".

In JavaScript exista sute de functii predefinite precum:

alert(), confirm(), si prompt() - aceste functii declanseaza casete de dialog la nivel de browser.

Date() - returneaza data si ora curenta. sqrt() - returneaza radacina patrata a unui numar. max() - returneaza cea mai mare valoare dintre mai multe numere. min() - returneaza cea mai mica valoare dintre mai multe numere.

Variabile locale

variabila declarata in interiorul unei functii JavaScript, folosind var, va fi LOCALA. variabila LOCALA este vizibila si poate fi accesata numai in interiorul functiei.

Page 252: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 253: licenta hatz

7: variabilele locale pot avea acelasi nume in diferite functii, deoarece sunt recunoscute numai de functia in care au fost declarate.

8: argumentele (parametri) se comporta ca variabile locale in interiorul functiilor.9: variabilele locale sunt create atunci cand functia incepe si sterse in momentul in care functia

este finalizata.

Exemplu de definire si folosire a unei variabile locale:

<!DOCTYPE html> <html><body><div id="c1"></div> <div id="c2"></div> <script>function myFunction()

var a = 4; // variabila locala document.getElementById("c1").innerHTML = a;

myFunction(); document.getElementById("c2").innerHTML = a; </script></body></html>

Variabile globale

14: variabila declarata in exteriorul unei functii, devine GLOBALA.15: variabila GLOBALA este vizibila si poate fi accesata de catre toate script-urile si functiile din

cadrul paginii web.16: variabilele globale sunt sterse in momentul in care se inchide pagina web.

Exemplu de definire si folosire a unei variabile globale:

<!DOCTYPE html> <html><body><div id="c1"></div> <div id="c2"></div> <script>var a; // variabila globala function myFunction()

a = 4; document.getElementById("c1").innerHTML = a;

myFunction(); document.getElementById("c2").innerHTML = a; </script></body></html>Exemplu de definire, stocare si folosire a unei functii anonime in cadrul unei variabile:

Page 254: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB

<!DOCTYPE html> <html><body><div id="c1"></div> <div id="c2"></div> <div id="c3"></div> <script>

function adunare(a, b) return a + b;var x = function(a, b) return a + b; var y = adunare(2, 4);document.getElementById("c1").innerHTML = x ; document.getElementById("c2").innerHTML = y ; document.getElementById("c3").innerHTML = x(2, 3);

</script></body></html>

Lect.univ.dr. Daniel Mican [email protected]

Page 255: licenta hatz

Evenimente

← un eveniment este o actiune care poate fi detectata de catre JavaScript.← JavaScript permite executarea unui cod in momentul in care sunt detectate anumite

evenimente.← un eveniment HTML poate fi creat de catre browser, sau de catre actiunile utilizatorului.← in JavaScript un eveniment este identificat de catre un handler de evenimente.← un eveniment are loc in momentul in care se incarca o pagina web, cand utilizatorul da clic pe

un element sau misca cursorul mouse-ului peste el.

<elementHTML eveniment="cod JavaScript">

Exista trei metode prin intermediul carora se poate reactiona la evenimentele din JavaScript:6. Ca un atribut HTML7. Ca metoda atasata la element8. Utilizarea addEventListener

Ca un atribut HTML

Se specifica functia care va fi rulata prin intermediul unui atribut in cadrul elementului.

<button onclick="functiaMea();">Click pe mine</button>

<button onclick="alert('Ai dat click pe mine')">Click pe mine</button>

Este bine ca cest mod de a atasa evenimente pentru elementele din cadrul paginii web sa fie evitat.

Ca metoda atasata la element

Putem atasa functii folosind diferite obiecte si metode incorporate in JavaScript.

Page 256: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 257: licenta hatz

window.onclick = functiaMea; /* functiaMea va rula atunci cand utilizatorul da clic in fereastra browser-ului */

In acest caz putem folosi functii anonime in locul celor predefinite.

window.onclick = function () / * Codul plasat aici va rula in momentul in care utilizatorul da clic in fereastra browser-ului * / ;

Aceasta abordare are avantajul de a simplifica si usura intretinerea codului, dar are un dezavantaj destul de mare. Doar o singura functie se poate lega de un eveniment la un moment dat.

window.onclick = functiaMea; window.onclick = altaFunctie;

In cazul de fata, a doua atribuire o suprascrie pe prima. In momentul in care utilizatorul da clic in interiorul ferestrei browser-ului, va rula doar altaFunctie. Referirea la functiaMea este suprascrisa/pierduta.

Utilizarea addEventListener

Aceasta abordare, desi un pic mai complexa la prima vedere, ne permite sa pastram logica in scripturi si permite legarea mai multor functii la un eveniment.

Legarea se face prin apelarea metodei addEventListener a obiectului tinta, si apoi se specifica evenimentul si functia care va fi executata.

window.addEventListener ("click", functiaMea); window.addEventListener ("click", altaFunctie);

Trebuie observat ca se omite prefixul "on" al evenimentului in cadrul acestei sintaxe.

Mai jos metodei addEventListener ii este atasata o functie anonima:

window.addEventListener ("click", functia () /* codul functiei */ );

Lista evenimente

Evenimentele HTML sunt actiuni care au loc asupra elementelor HTML. De obicei, in momentul in care au loc evenimentele se doreste executarea unui anumit cod. Prin urmare, JavaScript permite executarea codului in momentul in care sunt detectate anumite evenimente.

Eveniment Descriereonblur Un element pierde focusul (este parasit)onchange Continutul unui camp dintr-un formular se modificaonclick Mouse-ul face clic pe un obiectonerror Apare o eroare in momentul in care documentul sau o imagine se incarcaonfocus Un element primeste focusul (devine activ)onkeydown Este apasata o tasta

Page 258: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 259: licenta hatz

onkeypress Este apasata o tasta si tinuta apasataonkeyup O tasta care a fost apasata este eliberataonload Momentul in care o pagina sau o imagine s-a terminat de incarcatonmousedown Un buton al mouse-ului este apasatonmousemove Cursorul mouse-ului este mutatonmouseout Cursorul mouse-ului este mutat de pe un elementonmouseover Cursorul mouse-ului este mutat peste un elementonmouseup Un buton al mouse-ului este eliberatonsubmit Se apasa butonul de trimitere intr-un formular

3.5. JavaScript + DOM

Document Object Model (DOM) este atat un model cat si o interfata, neutra din punct de vedere al limbajului de programare folosit, care permite programelor si scripturilor sa acceseze si actualizeze continutul, structura si stilul unui document in mod dinamic. DOM:

5. este un standard W3C (World Wide Web Consortium);6. defineste un standard de acces la documente si este o interfata de programare (API) pentru

pagini HTML si XML;7. ofera o harta structurata a documentului, precum si un set de metode pentru a interactiona cu

elementele continute;8. este o traducere a paginii HTML, creata cu ajutorul marcatorilor, intr-un format pe care atat

JavaScript cat si alte limbaje de programare il pot intelege;9. serveste ca o harta pentru toate elementele de pe o pagina;10. permite gasirea si modificarea elementelor, respectiv adaugarea, modificarea sau stergerea

elementelor impreuna cu continutul lor.

HTML DOM este un model de obiecte si o interfata de programare standard pentru HTML. DOM defineste:

Elementele HTML ca obiecte Proprietatile tuturor elementelor HTML Metodele de a acces la toate elementele HTML Evenimentele pentru toate elementele HTML

In concluzie, HTML DOM este un standard pentru modul in care se obtin, schimba, adauga si sterg elementele HTML.

Metodele HTML DOM sunt actiuni care se pot efectua (pe elementele HTML). O metoda este o actiune precum adaugarea sau stergerea unui element HTML.

Proprietatile HTML DOM sunt valori, ale elementelor HTML, care se pot seta sau schimba. O proprietate este o valoare precum continutul unui element HTML.

Cu modelul de obiecte, JavaScript poate crea HTML in mod dinamic. Astfel, JavaScript poate:

2.2.3 schimba toate elementele HTML din pagina2.2.4 schimba toate atributele HTML din pagina2.2.5 schimba toate stilurile CSS din pagina2.2.6 elimina elemente si atribute HTML existente

Page 260: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB

adauga noi elemente si atribute HTML reactiona la toate evenimentele HTML existente in pagina crea noi evenimente HTML in pagina

Lect.univ.dr. Daniel Mican [email protected]

Page 261: licenta hatz

Pagina web reprezentata in browser Pagina web reprezentata arborescent in DOM

Pagina web reprezentata in cod HTML

DOM este o colectie de noduri:

Noduri Element Noduri Atribut Noduri de text

Mai jos este prezentata in cod HTML structura nodului, de tip element, p. Nodul p contine un nod de tip text si un nod de tip element, a. Nodul a contine nodul de tip atribut, href si un nod de tip text.

<p>Textul paragrafului contine un link <a href="pagina.html">link</a></p>

In figura de mai jos este prezentat arborescent in DOM structura nodului, de tip element, p.

Pentru a putea manipula elementele HTML, JavaScript trebuie sa poata, in primul rand, sa gaseasca elementele. Acest lucru se poate realiza in mai multe feluri prin intermediul id-ului, tag-ului, sau numelui clasei. In continuare vom trece in revista unele dintre metodele specifice pe care le putem utiliza pentru a accesa obiectele definite de DOM. De asemenea vom prezenta si unele dintre cele mai populare metode de manipulare a acestor elemente.

getElementById("Id") Metoda acceseaza primul element cu Id-ul specificat.Este ablolut necesar sa se furnizeze Id-ul elementului pecare dorim sa il accesam/manipulam.

Page 262: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 263: licenta hatz

getElementsByTagName("TagName") Metoda acceseaza toate elementele cu tagul specificat. Este ablolut necesar sa se furnizeze numele tag-ului pe care dorim sa il accesam/manipulam.

getElementsByClassName("ClassName") Metoda acceseaza toate elementele cu numele clasei specificat. Este ablolut necesar sa se furnizeze numele clasei pe care dorim sa o accesam/manipulam.

Dupa ce am accesat un nod folosind una din metodele discutate anterior, DOM ne ofera mai multe metode standard pentru manipularea elementelor, atributelor si continutului acestora. Aceste metode sunt:

element.innerHTML= Permite modificarea continutului din cadrul unui elementHTML

element.attribute= Permite modificarea atributului unui element HTMLelement.setAttribute(attribute,value) Permite modificarea atributului unui element HTMLelement.style.property= Permite modificarea stilului unui element HTML

Pana acum, am vazut metodele folosite pentru obtinerea si setarea nodurilor in documentul HTML. Pe langa acestea, DOM mai contine metode prin care permite dezvoltatorilor schimbarea structurii documentului HTML prin adaugarea si eliminarea nodurilor "on the fly". Pentru a adauga un nou element (nod) in cadrul HTML DOM trebuie urmati doi pasi: in primul rand trebuie creat elementul (nodul); in al doilea rand trebuie adaugat la un element (nod) deja existent in cadrul documentului.

Cel mai simplu mod de a modifica continutul unui element HTML este de proprietatea innerHTML. Totusi, adaugarea si stergerea elementelor se poate face si prin intermediul urmatoarelor metode:

document.createElement() Permite crearea unui element HTMLdocument.createTextNode() Permite crearea unui nod de tip text cu textul specificat

pentru elementul HTMLdocument.appendChild() Permite adaugarea unui element HTMLdocument.replaceChild() Permite inlocuirea unui element HTMLdocument.removeChild() Permite eliminarea unui element HTMLdocument.write(text) Permite scrierea in fluxul de iesire HTML

Aceasta metoda este mult mai precisa decat adaugarea de continut prin intermediul metodei innerHTML.

Observatie importanta:Codul JavaScript este Case-sensitive. Acest lucru inseamna ca getElementById este diferit de getElementByID. Folosind varianta a doua codul JavaScript nu va functiona.

Accesarea elementelor in cadrul DOM

Obiectul document identifica, in cadrul DOM, pagina in sine. Obiectul document vine cu o serie de proprietati si metode standard care permit accesarea colectiilor de elemente.

Accesarea elementelor pe baza atributului ID

document.getElementById ("idElement")

Metoda getElementById() returneaza elementul care are atributul de identitate egal cu valoarea specificata.

Page 264: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 265: licenta hatz

Aceasta metoda este una dintre cele mai comune metode din HTML DOM. Ea este folosita aproape de fiecare data cand se doreste manipularea, sau obtinerea de informatii de la un element din cadrul documentului.

Metoda returneaza null in cazul in care nu exista elemente cu ID-ul specificat.

In cazul in care exista mai mult de un element cu ID-ul specificat, metoda getElementById() returneaza primul element.

Accesarea elementelor pe baza numelui elementului

document.getElementsByTagName("numeTag")

Metoda getElementsByTagName() acceseaza toate elementele cu numele tagului specificat.

Metoda returneaza o colectie cu toate elementele din document, cu tagul specificat, sub forma unui obiect NodeList.

NodeList se comporta la fel ca un array si contine toate elementele in ordinea in care apar in document, de sus in jos.

Pentru a avea acces la anumite elemente din NodeList, vom face referinta la indicele lor, la fel ca intr-un array.

paragrafe = getElementsByTagName("p")

Pentru a accesa primul paragraf din document vom folosi paragrafe[0], pentru a accesa al doilea vom folosi paragrafe[1], si asa mai departe.

Accesarea elementelor pe baza numelui clasei

getElementsByClassName("numeClasa")

Metoda getElementsByClassName() acceseaza toate elementele cu numele clasei specificate.

Metoda returneaza o colectie cu toate elementele din document, cu clasa specificata, sub forma unui obiect NodeList.

Pentru a avea acces la anumite elemente din NodeList, vom face referinta la indicele lor, la fel ca intr-un array.

elementeLista = getElementsByClassName("elementeLista")

Pentru a accesa primul element din lista cu clasa elementeLista vom folosi elementeLista[0], pentru a accesa al doilea vom folosi elementeLista[1], si asa mai departe.

Manipularea nodurilor

In continuare vom detalia mai multe metode, impreuna cu proprietatile pe care DOM le ofera pentru manipularea elementelor, continutului si al atributelor acestora.

Setarea valorii unui element

elementHTML.innerHTML="text"

Proprietatea innerHTML seteaza sau returneaza continutul interioar al unui element HTML.

Page 266: licenta hatz

Grafica si programare pe Internet - FSEGA, UBB Lect.univ.dr. Daniel Mican [email protected]

Page 267: licenta hatz

innerHTML ne ofera o metoda simpla pentru accesarea si modificarea textului si elementelor din interiorul unui element.

<p id="paragraf">Acest text va fi schimbat prin intermediul innerHTML</p> <script>document.getElementById("paragraf").innerHTML="Eu sunt noul text";</script>

Setarea valorii unui atribut

element.setAttribute(numeAtribut, valoareAtribut)

Metoda setAttribute() adauga atributul specificat, in cazul in care nu exista, si il seteaza la valoarea specificata.

In cazul in care atributul specificat deja exista, doar valoarea ii este setata / schimbata.

Aceasta metoda necesita doua argumente: atributul a carei valoare trebuie sa fie schimbata si noua valoare pentru atribut.

<img src="poza1.jpg" id="poza" onclick="schimba()"> <script>function schimba() document.getElementById("poza").setAttribute("src","poza2.jpg");</script>

Manipularea stilurilor CSS

document.getElementById("idElement").style.proprietateCss = "valoare";DOM permite adaugarea, modificarea, sau eliminarea unui stil CSS de la un element folosind proprietatea style. Acesta functioneaza in mod similar cu aplicarea unui stil cu atributul de stil inline. Proprietatile individuale CSS sunt disponibile ca proprietati ale proprietatii style.

<p id="paragraf" onclick="schimbaStil()">Daca dai click pe mine ma inrosesc</h1> <script>function schimbaStil() document.getElementById("paragraf").style.color = "red";</script>

In JavaScript si DOM, numele de proprietati, care sunt despartite in CSS (cum ar fi background-color si border-top-width) devin (backgroundColor si borderTopWidth), astfel incat caracterul - sa nu fie confundat cu un operator.

Page 268: licenta hatz

PROIECTAREA SITE-URILOR WEBAutor: Liana Stanca

1.1. Abordarea serverelor Web în programarea pe parte de serverUn server web este o tehnologie de informații care procesează cererile prin intermediul HTTP.

HTTP(HyperText Transfer Protocol) este un protocolul de rețea folosit pentru a distribui informații pe World Wide Web. Ca şi alte protocoale utilizate în Internet, protocolul HTTP (HyperText Transfer Protocol) este un protocol de tip cerere-răspuns, bazat pe TCP/IP, destinat transferurilor informaţiilor hipermedia. Apache foloseşte HTTP pentru a comunica cu Internet Explorer, pentru a analiza URL-ul şi a stabili protocolul de conectare în cazul de faţă:-http://localhost. Termenul de server se poate referi fie la întregul sistem de calcul, fie la un aparat, fie în mod specific pentru software-ul care acceptă și supraveghează cererile HTTP. Serverele Web au ca funcţionalitate de bază recepţionarea de cereri anonime de la clienţi şi furnizarea de informaţii într-o manieră dorită a fi eficientă şi rapidă [Ricart1998]. Deci, un server Web este un daemon care acceptă conexiuni conform protocolului HTTP, răspunzând cererilor recepţionate de la clienţi.

Conform statistici realizate de Netcraft1, în luna martie 2015, serverul Apache a înregistrat o scădere a numărului de hostname-uri de 2.9 milioane din 2012. Referitor la situatia hostname-uri,Microsoft afirmă că,în ultima perioada a crescut cota de piață a lui la 28,7%, dar Apache continuă să conducă cu o cotă de 38,8%, în ciuda unei pierderi de 5,9 milioane de site-uri. În studiu realizat de Netcraft, cota de piață Nginx prezintă o creștere ușoară față de trecuta de până la 11,3%, în timp ceApache menține în continuare un avantaj confortabil, dat de o cotă de 47,2%, în timp ce Microsoft a a ajuns la o cotă de 29,9%. În prezent Apache deservește 58,3% din totalul site-urile ale căror server web se cunosc, conform lui studiului realizat de w3techs 2.

Proiectul Apache reprezintă dezvoltarea unui soft colaborativ care urmăreşte cererea şi utilizarea unui Web Server puternic şi robust. Proiectul era condus de către voluntari din întreaga lume.Acest grup de voluntari foloseşte Internet-ul pentru comunicare, planificări şi dezvoltarea serverului şi a documentaţiei de rigoare.Ei sunt cunoscuţi sub denumirea de Grupul Apache (Apache Group).În plus, sute de utilizatori au contribuit cu idei, coduri şi documentaţie la acest proiect.

Apache furnizează o implementare robustă a protocolului HTTP. Apache suportă o mare varietate de module care îi extind funcţionalitatea, acestea variază de la server side programming şi până la scheme de autentificare şi anume: mod_ssl oferă suport pt SSL şi TLS modulul proxyun, modul de rescriere URL (cunoscut ca un motor de rescriere mod_rewrite), custom log files (mod_log_config)şi suport de filtrare (mod_include şi mod_ext_filter).Apache este virtual hosting (găzduirea virtuală), care constă în posibilitatea de a găzdui mai multe site-uri simultan pe acelaşi server.

[Converse_Park_Morgan_2005]Apache2 rămâne o platformă pe baza căreia indivizii şi instituţiile pot să construiască sisteme în scopuri experimentale şi nu numai. Apache este o entitate organică, cei care beneficează de ea prin utilizare contribuie de cele mai multe ori la dezvoltarea ulterioară a platformei. Dacă cineva plăteşte pentru un produs software, nu va dori după aceea să-i repare defectele.[Converse_Park_Morgan_2005]Limbajele suportate de serverul Apache sunt:PHP,PERL, PYTHON.

1http://www.netcraft.com/survey2 http://w3techs.com/technologies/overview/web_ server/all

Page 269: licenta hatz

Dorinţa creatorilor Apache, după cum se specifică în site-ul Grupului Apache3 este ca platforma sa să fie folosită de cât mai multă lume (companii mari sau mici, instituţii de cercetare, şcoli, Intranet-uri ) şi să se acopere cât mai multe domenii de activitate.În prezent, motorul de căutare folosit de Google4utilizeaza o versiune modificată de Apache numită Google Web Server (GWS) şi proiectele Wikimedia5 inclusiv Wikipedia rulează tot pe un server Apache.

5: Modelul CLIENT-SERVER pentru aplicaţii web pe parte de server

Modelul Client-Server[site17] [LalaniChandak1997] stă la baza tuturor aplicaţiilor electronice şi serviciilor Internet. Clientul, în general, rulează pe calculatorul utilizatorului şi este folosit pentru a accesa informaţii sau alte aplicaţii din cadrul reţelei Internet. Exemplul de client este browser-ul care poate îndeplini cu succes următoarele sarcini:[site17]

emite cererile şi recepţionează datele care se vor afişa; formatează documentele pe baza tag-urilor HTML;

afişează documentele.Serverul [site17] rulează, în general, pe un calculator centralizator sau aflat la distanţă,

furnizând sau oferind informaţii/servicii clienţilor. Exemple de servere folosite în prezent sunt: Apache, IIS şi etc.

Clientul şi serverul se pot găsi pe acelaşi calculator, în cazul în care se utilizează mecanisme de comunicaţie locală sau pe calculatore diferite, atunci când se folosesc mecanisme de comunicaţie în reţea. (Figura1.2)

Figura 1.2. Arhitectura client server - adaptare [LalaniChandak1997]

Un server web este un program care rulează pe un calculator, aşteaptă pe un port o conexiune TCP venită de la un client şi serveşte acestuia pagini web folosind protocolul HTTP. [site31]

Serverul web este un software, un program de sine stătător, un executabil cu o funcţie bine stabilită: accea de a servi la cerere pagini de Internet într-un mod bine determinat. Acest software

3http://www.apache.org ,

4http://code.google.com/webtoolkit/terms.html

5http://apache-http-server .software.informer .com/wiki/

Page 270: licenta hatz

poate fi: Apache HTTP Server, Microsoft Internet Information Services (IIS), iPlanet WebServer, Roxen WebServer, Zeus WebServer, ş.a. Serverul web rulează pe un calculator. [site31]

Clientul folosit pentru accesarea serverului web poate fi atât un browser cât şi un alt program capabil să se conecteze la un port TCP (de exemplu: telnet, ftp, etc.).

Browserul [site31] este un program folosit la afişarea de conţinut web. Acesta se impune să poată să interpreteze pagini HTML, să afişeze imagini şi alte forme de conţinut multimedia, să folosească referinţe (link-uri) etc. Cea mai importantă caracteristică a sa este capacitatea lui de a se conecta prin protocolul TCP la un server web. Metoda de conectare s-a prezentat anterior. În acest context se impune să se precizieze că introducerea unei adrese web (de exemplu: http://www.ubbcluj.ro/exemplu.html) în browser, determină executarea următorilor paşi:[site31][site8][Boian1997] .[stanca2007]

8: Browser-ul determină protocolul pe care îl va folosi în dialogul cu serverul web (http:// = HTTP - HyperText Transfer Protocol).

9: Browser-ul determină adresa web a serverului (www.ubbcluj.ro).10: Browser-ul determină ce anume trebuie să ceară de la serverul web, adică pagina html

numită exemplu.html.11: Browser-ul determină adresa IP a maşinii pe care rulează serverul web prin interogări

DNS (Domain Name Service) pe baza adresei web introdusă în address bar.12: pe baza adresei IP determinată anterior, browserul va crea o conexiune TCP pe portul

specificat în URL sau implicit pe portul 80.13: Browser-ul lansează o cerere GET sau POST către server specificând fişierul dorit: GET

/exemplu.html.14: Serverul web răspunde trimiţând fişierul dorit sau o eroare corespunzătoare în cazul în

care trimiterea nu este posibilă (lipsa fişierului, drepturi de acces insuficiente etc.). Aici conexiunea dintre client şi server se încheie.

15: Browser-ul analizează fişierul primit şi îl afişează corespunzător.Browser-ele cele mai cunoscute şi deci cele mai folosite sunt: Microsoft Internet Explorer,

Mozilla, Netscape, Opera, Lynx, etc.[stanca2007]

1.3. MySQL –concepte de bază, caracteristici

MySQL este cel mai popular sistem de management pentru baze de date relaţionale deoarece este open-source. MySQL Server a fost creat pentru a lucra cu baze de date mai rapid decât soluţiile deja existente la ora actuală pe piaţă [Graeme-site].

Facilităţile oferite de MySQL sunt variate, dintre care se vor preciza următoarele[BuBois2001]:

posibilitatea accesului concurent la date de către un număr nelimitat de utilizatori; capacitatea de a gestiona până la 50000000 de înregistrări şi chiar mai multe;execuţia foarte rapidă a comenzilor, poate chiar cea mai rapidă din cele existente pe piaţă; sistem uşor şi eficient de gestiune a drepturilor utilizatorilor;este gratuit, fapt ce a atras extinderea fără precedent a folosirii acestui server de baze de date.

MySQL este un sistem de gestiune a bazelor de date. Pentru a adăuga, insera şi procesa datele memorate pe un calculator este nevoie de un astfel de sistem de gestiune a datelor. Având în vedere că toate calculatoarele sunt destinate pentru memorarea informaţiilor, managementul

Page 271: licenta hatz

bazelor de date joacă un rol decisiv, atât în gestiunea datelor ca activitate de sine stătătoare, cât şi în cadrul aplicaţiilor ample [BuBois2001].

MySQL este un sistem multiuser (permite să fie folosit concomitent de mai mulţi utilizatori) şi multithread (prezintă mai multe fire de execuţie). Utilizează SQL, limbajul standard de interogare a bazelor de date.[WellingThomson2005]

MySQL este un sistem de gestiune a bazelor de date relaţionale. Tabelele sunt conectate prin relaţii predefinite, fapt ce face posibilă combinarea datelor din mai multe tabele, la cerere.MySQL este un produs open source.

MySQL este un sistem client-server care este alcătuit dintr-un server SQL multithread care are facilităţi pentru mai mulţi utilizatori, mai multe programe şi biblioteci client, instrumente de administrare şi un număr mare de interfeţe de programare. Având în vedere că MySQL suportă o gamă variată de produse software, există posibilitatea ca multe din limbajele de programare deja folosite de anumiţi utilizatori să suporte deja interfaţa cu acest produs [BuBois2001].

Orice maşină care doreşte să proceseze interogări asupra unei baze de date MySQL trebuie să ruleze MySQL server-MySQLd-, care este responsabil de tot traficul de tip incoming sau outgoing cu baza de date. Ca orice server, MySQLd primeşte pe un port particular (3306) eventualele cereri de conexiune ale unui client care trimite cereri către o bază de date via MySQLd. Acest client poate fi un script în PHP care, graţie modelului DBI, poate trimite o cerere către baza de date prin intermediul serverului MySQL, sau chiar clientului command-line MySQL. Clientul MySQL este o interfaţă interactivă pentru trimiterea de comenzi către server[BuBois2001].

1.3.1. Modul de funcţionare a unui server de baze de date pentru Web

Funcţionarea unui server de baze de date pentru Web, în cazul nostru MySQL, implică existenţa a două elemente: un browser Web şi un server. Între aceste două elemente se impune să existe un canal de comunicare. Serverul de Web funcţionează în moduri diferite în următoarele situaţii: [WellingThomson2005]

în cazul în care server-ul lucrează cu pagini de web statice, un browser Web (clientul) formulează cererea către server, iar serverul trimite înapoi un răspuns.în cazul în care server-ul lucrează cu pagini web dinamice care preiau datele dintr-o bază de date şi le afişează se realizează următorii paşi: [WellingThomson2005]

browser-ul web al unui utilizator emite o cerere HTTP pentru o anumită pagină Web;server-ul web recepţionează cererea şi transferă fişierul către motorul PHP, în cazul nostru, pentru prelucrare;motorul php începe analiza paginii. În interiorul unei pagini web dinamice există o comandă care realizează legătura la baza de date şi execută interogările pe care le trimite serverului MySql;serverul MySQL recepţionează interogarea bazei de date şi o prelucrează, iar apoi trimite rezultatele motorului PHP;motorul PHP afişează rezultatele furnizate de server-ul MySQL formatate într-un cod HTML pe care îl returnează server-ului Web, în cazul nostru Apache.

Server-ul Web transmite codul HTML browser-ului, unde utilizatorului i se afişează rezultatul dorit de acesta.

Page 272: licenta hatz

1.3.2. Tipuri de date SQL

Crearea unei baze de date relaţionale presupune crearea unuia sau mai multor tabele legate între ele. În procesul de creare a unui tabel are loc stabilirea numelor câmpurilor acestuia cât şi a tipurilor de date prin care unui utilizator i se indică ce date are voie să introducă în acestea. În funcţie de tipurile de date alese pentru fiecare coloană a tabelei se alocă pe disc un spaţiu de memorie. În această situaţie este indicată o cunoaştere aprofundată a acestora, deoarece acest fapt va permite creatorului tabelei să aleagă tipul de date potrivit pentru fiecare coloană a tabelei astfel încât aceasta să ocupe un spaţiu de memorie optim pe disc şi în acelaşi timp să răspundă nevoilor utilizatorilor acesteia. De exemplu, dacă se doreşte să se definească un câmp “Vârsta” în cadrul unei tabele “Personal” este bine ca acesta să fie de tipul TINYINT deoarece acesta se defineşte pe un interval numeric ce cuprinde valoarea numerică care poate fi introdusă într-un astfel de câmp. Un individ poate trăi în intervalul (0,100) aşa cum s-a observat până în momentul de faţă. Pentru fiecare înregistrare introdusă în tabela Elevi pentru câmpul Vârsta se va aloca 1 byte de memorie.

Tipurile de date folosite în procesul de creare a tabelelor din cadrul bazelor de date MySql, sunt [site9] [site10] [site11] [Chip2/2003]:

2.3.1Tipuri numerice sunt: TINYINT, SMALLINT, MEDIUMINT, INT sau INTEGER, BIGINT, FLOAT, REAL sau DOUBLE, NUMERIC

2.3.2Tipurile de dată calendaristică sunt : DATETIME, DATE, TIMESTAMP, TIME, YEAR ;

2.3.3Şirurile de caractere se împart în trei grupuri şi anume: şiruri normale definite prin tipul CHAR (fixed length character), respectiv VARCHAR (variable length character), şiruri text definite prin tipul TEXT respectiv BLOB (pentru şiruri lungi sau date binare) şi şirurile care folosesc SET respectiv ENUM pentru valori predefinte.[site11]

9:3.3. Operaţii asupra bazelor de date în MySQL

O regulă de bază în MySql este că majoritatea comenzilor tastate în monitorul MySQL declienţi pentru a fi transmise serverului se termină cu “;”. Caracterul “;’ indică server-ului de baze de date MySql că s-a terminat introducerea unei comenzi şi deci o poate procesa şi afişa rezultatul.

Crearea unei aplicaţii Web dinamice, în marea majoritate a lor, implică crearea unei baze de date alcătuită din una sau mai multe tabele legate între ele. Crearea unei astfel de baze de date înMySql, pentru un magazin virtual care se ocupă cu comercializarea produselor IT, se realizează cu comanda:

mysql> create database nume_bază_de_date;“nume_bază_de_date” va trebui să fie înlocuit cu numele pe care utilizatorul doreşte să îl

acorde bazei lui de date, în cazul nostru magazin.Vizualizarea bazelor de date existente pe server-ul Mysql de către administrator se face cu

comanda: [Chip2/2003]:mysql> SOW DATABASES;

Interogarea de mai sus se termină cu punct şi virgulă deoarece toate comenzile SQL trebuie încheiate astfel pentru a semnala server-ului că s-a terminat de scris propoziţia şi că se poate

Page 273: licenta hatz

trece la procesarea cererii. Rezultatul procesării comenzii de mai sus este afişarea tuturor bazelor de date existente în directorul data a serverului MySQL.

Page 274: licenta hatz

Selectarea unei baze de date ca fiind cea curentă se face prin comanda:USE nume_baza_de_data;

Pasul următor în procesul de creare a unei baze de date îl constituie crearea tabelelor ce o compun. Comanda de crearea a unui tabel are următoarea sintaxă:

CREATE TABLE nume_tabelă (nume_câmp tip_câmp);În procesul de creare a unui tabel activităţile sunt:3.11.denumirea câmpurilor;3.12.alegerea unui tip de date potrivit pentru fiecare câmp;3.13.definirea atributelor pentru fiecare câmp în parte;3.14.stabilirea coloanei care va juca rolul de cheie primară sau secundară cu ajutorul căreia se

va stabili legătura către alte tabele ale bazei de date.Indexii pentru o tabelă se pot crea astfel:4.7. fie adăugând la sfârşitul instrucţiunii CREATE TABLE... comanda [Chip2/2003]

INDEX(nume_coloană_index);4.1.10. fie folosind comanda: [WellingThomson2005]CREATE [UNIQUE|FULLTEXT] INDEX nume_index ON nume_tabelă (nume_coloană_index

[(lungime)[ASC|DESC],...);Ştergerea unui tabel, index, bază de date sau o coloană dintr-un tabel se face folosind comanda

DROP astfel[Chip2/2003]:DROP TABLE nume_tabel; DROP

DATABASE nume_baza_de_data;Popularea tabelelor cu înregistrări se face prin comanda INSERT care are următoarea sintaxă

[Chip2/2003]:INSERT INTO nume_tabel (câmp1, câmp2, câmp3) values (valoare1, valoare2, valoare3);

Comanda SELECT se foloseşte pentru a afişa toate înregistrările dintr-o tabelă astfel: mysql>SELECT * FROM nume_tabelă;

Comanda SELECT se foloseşte pentru a afişa toate înregistrările dintr-o tabelă astfel: mysql>SELECT * FROM nume_tabelă;

Modificarea conţinutului unei înregistrări se face utilizând comanda UPDATE care are sintaxa[Chip2/2003]

UPDATE nume_tabel SET nume_coloană1=`noua valoare a coloanei 1`, nume_coloană2=`noua valoare a coloanei 2` WHERE condiţii

Ştergerea înregistrărilor dintr-o tabelă se face prin comanda DELETE care are următorea sintaxă [Chip2/2003]:

DELETE FROM nume_tabel WHERE condiţii;În cadrul prezentului capitol au fost expuse comenzi MySQL cu ajutorul cărora se poate

proiecta şi dezvolta o bază de date care să corespundă în totalitate nevoilor unui magazin virtual care ar putea avea, de exemplu, ca obiect de activitate vânzarea de componente de calculatoare, componente de calculatoare şi nu numai.

1.4. Particularităţi ale programării procedurale în PHP

Page 275: licenta hatz

PHP este un limbaj de scripting folosit pentru crearea paginilor Web dinamice. PHP poate fi folosit pentru scrierea unor programe stocate pe server ce accesează baze de date. PHP este un limbaj eficient şi securizat. Aplicaţiile PHP sunt uşor de configurat pentru exploatare. PHP asigură timpi de răspuns competitivi la rularea aplicaţiilor Web, asigurând în acelaşi timp securitatea informaţiilor şi transparenţa faţă de utilizator [Chip2/2003].

PHP aşa cum este cunoscut astăzi, este, de fapt succesorul produsului numit PHP / FI(prescurtarea de la "Interpret Forms").PHP a fostcreat în 1994 de către Rasmus Lerdorf. Prima versiune PHP a fost un set binar de Common Gateway Interface (CGI),scris în limbajul de programare C. Intre anii 1994-1999 au apărut pe piaţă o serie de versiuni de PHP care s-au bucurat de succes. In 2000 s-a lansat versiunea PHP4 având la bază acest motor Zend Engine. PHP 4.0 a inclus alte caracteristici-cheie, cum ar fi suport pentru mai multe servere de web, sesiuni HTTP, câteva construcţii noi ale limbajului.

PHP 4.0 a fost împărţit în 3 părţi:[Converse_Park_Morgan_2005]1.Motor de bază(ZEND)- responsabil cu parsarea codului PHP şi cu sintaxa limbajului 2.Server API(SAPI)- handlere de comunicare şi interfaţa cu servere web, permit ca PHP să se

integreze uşor cu alte server web. De ex, are un modul ISAPI pentru a perimte ca PHP să lucreze cu Internet Information Server(IIS)

3. Module funcţionabile: MySql,XML,IMAP etcPHP5.0 a fost lansat în iulie 2004, după câteva lansări preliminare, se bazează pe Zend Engine

2.0,oferă suport OOP şi zeci de alte caracteristici noi(clase şi obiecte se crează mult mai simplu decât în PHP 4.0, se îmbunătăţeşte integrarea dintre PHP şi MySql, permite scrierea de XML curat), oferă suport nativ pentru SQLite, pentru SOAP integrat, iteratori pentru date și controlul erorilor prin tratarea de excepții [Converse_Park_Morgan_2005]

PHP 6[site96] a fost lansat în decembrie 2007, și a adus atît noutăți cît și modificări la versiunile anterioare, mai exact: îmbunătățirea suportului pentru Unicode;retragerea definitivă a unor funcții ca register_globals și magic_quotes, și a variabilelor tip $HTTP_*_VARS; var va fi un alias pentru public, și folosirea lui va ridica o atenționare E_STRICT; suport pentru int pe 64 biți; taguri tip ASP sunt retrase definitiv; XMLReader, XMLWriter, Fileinfo sunt incluse în distribuția principală; pachete Freetype1, GD1, mime_magic au fost scoase din distribuția principală; funcția ereg() nu mai este disponibilă; instanțierea obiectelor prin referină (& newObiect()) generează o eroare E_STRICT; erorile tip E_STRICT sunt incluse în E_ALL; adăugarea instrucțiunii goto permite salturi la un alt bloc de comenzi; namespace, import, și goto devin cuvinte rezervate; accesarea caracterelor într-un șir (string) se face prin operatorul []. se scoate din uz ( ex: $str[42] funcționează, $str42 nu funcționează); constantele FILE_BINARYși FILE_TEXT devin disponibile pentru folosirea în funcții de citire/scriere fișiere; foreach va suporta array multi dimensional: foreach($c as $b => list($a, $d)); pentru operatorul ternar expresia pentru valoarea true nu mai este obligatorie ($x = $z ?: ‘s’; // returns $x = $z;) opțiunea safe_mode a fost înlăturată;operatorul and a fost înlăturat; funcția microtime() returnează un float; zend.ze1_compatibility_mode a fost înlăturat.

Limbajul PHP [site97]este un limbaj de programare structurat, ca și C-ul, Perl-ul sau începând de la versiunea 5 chiar Java, sintaxa limbajului fiind o combinație a celor trei. PHP se poate utiliza atât pentru a dezvolta aplicații de sine stătătorare, datorită modularității sale cât și în linia de comandă ca Perl sau Python. PHP permite fărăr dificutăți, conlucrarea cu majoritatea bazelor de date relaționale, de la MySQL și până la Oracle, trecând prin MS Sql Server, PostgreSQL, sauDB2.

Page 276: licenta hatz

Limbajul PHP-ul poate fi folosit pe aproape toate marile sisteme de operare, incluzand Linux, multe variante de Unix , Microsoft Windows, Mac OS X, probabil si altele. PHP are deasemenea suport pentru majoritatea serverelor de web din prezent. Acestea includ serverele Apache, Microsoft Internet Information Server, Personal Web Server, Netscape , iPlanet si multe altele. Pentru majoritatea serverelor PHP are un modul, iar pentru celelalte care suporta standardul CGI, PHP putand sa lucreze ca un procesor CGI.

Cu PHP nu exista limitare in obtinerea unor rezultate doar HTML. Posibilitatile limbajului PHP-ului includ afisarea de imagine, fisiere PDF si chiar filmulete Flash. PHP suporta incarcarea fisierelor de pe calculatorul client upload si ofera suport pentru cookies.

PHP este un limbaj ideal pentru construirea de pagini Web dinamice. El poate fi rulat pe mai multe platforme şi se poate conecta la mai multe baze de date, în particular baze de date relaţionale create cu MySQL. Cel mai important aspect al limbajului este însă posibilitatea de a fi inclus în cod HTML. Se pot crea pagini HTML statice şi din loc în loc, acolo unde este nevoie, să se introducă dinamism cu PHP.

Limbajul PHP fiind open-source beneficează de un sprijin activ din partea comunităţii on-line, acesta fiind şi motivul creşterii explozive a numărului de site-uri bazate pe acest limbaj.

Limbajul PHP oferă următoarele facilităţi [Welling2001]:← manipularea conţinutului paginilor web;← transmiterea header-elor HTTP pentru autentificare;← setarea cookie-urilor;← redirecţionarea utilizatorilor;← asigurarea spargerii (paser) fişierelor XML;← crearea şi manipularea imaginilor, animaţiilor şi a PDF-urilor;← conectarea la un server de e-mail.

4.3.11. 4.1. Principiul de funcţionare a tehnologiei Web pe parte de server ( limbajului PHP)

Modul de funcţionare a limbajului PHP este următorul: browser-ul trimite către server-ul Web o cerere HTTP pentru un fişier PHP. Server-ul recunoaşte că fişierul cerut conţine cod PHP, în consecinţă va lansa parser-ul PHP, care va primi la intrare fişierul respectiv. Parser-ul va identifica secvenţele PHP, care în cadrul codului HTML sunt cuprinse între marcajele „<?” şi „?>” şi le va interpreta. Tot ce nu este cod PHP este trimis spre ieşirea standard fără nici o prelucrare. Codul PHP poate scrie la rândul său în ieşirea standard prin comenzile prestabilite cum ar fi „echo” sau „print”. În final serverul Web intercepteză ieşirea standard a parser-ului şi transferă totul browser-ului care a cerut pagina [McCarty2002].

PHP, şi într-o anumită măsură şi alte limbaje Web, prezintă următoarele caracteristici[Welling2001]:

este interpretativ;execuţia este rapidă deoarece interpretorul este inclus în server-ul Web, prin urmare nu se cheltuiesc resurse cu configurarea;

este bogat în facilităţi, conţinând numeroase funcţii utile;

Page 277: licenta hatz

are o sintaxă simplă, variabilele nu trebuie declarate, tipul acestora se stabileşte la iniţializarea lor cu o valoare şi în plus numele de funcţii sunt intuitive.

Page 278: licenta hatz

Crearea paginilor PHP se reduce la editarea unui fişier PHP care se poate realiza în orice editor de texte: Notepad, editoare PHP, etc. şi acesta poate conţine: [Converse_Park_Morgan_2005]

text;tag-uri HTML sau XML;comenzi şi instrucţiuni PHP;comenzi şi instrucţiuni MySQL.

Pe parcursul dezvoltării fişierului, în fereastra editorului de texte Notepad se va acţiona comanda Save a meniului EDIT după fiecare modificare adusă fişierului, apoi Refresh în browser pentru reflectarea modificărilor astfel efectuate (folosirea butoanelor Back şi Forward din browser trebuie să fie urmată de asemenea de Refresh). Cu condiţia ca fişierele să fie salvate corect, iar URL-urile locale să fie scrise corect, pentru fiecare pagină PHP la care se lucrează simultan trebuie deschisă câte o fereastră a editorului.

O pagină PHP se salvează cu extensia php în directorul serverului Apache numit htdocs şi se va acceseză în browser astfel: http://localhost/numefisier.php. În cazul în care se doreşte ca paginile unui site Web să se păstreze într-un subdirector creat în rădăcina server-ului Web atunci la lansarea în browser a site-ului web se va introduce şi numele acestuia în URL astfel: http://localhost/numesubdirector/numefisier.php. După lansarea în browser a unei pagini PHP se poate folosi opţiunea View source a acestuia, şi se observă că se afişează doar ieşirile scriptului (text, cod HTML, etc.), nu şi codul PHP care generează ieşirile. [Stanca2007]

1.4.2. Accesul la paginile PHP şi afişarea rezultatelor acestora

Comenzile de editare a unei pagini HTML dintr-un script PHP, sunt: echo, print, print_r, şi printf. Toate aceste comenzi mai sunt folosite pentru afişarea rezultatelor unei funcţii, a valorilor unei variabile, a elementelor unui tablou, a mesajelor text, a valorilor introduse de utilizator în câmpurile unui formular HTML, pentru a transmite valorile încadrate între ghilimele la browser, etc. Exemple cu aceste comenzi se vor realiza pe tot parcursul incursiuni în limbajul PHP.

În cele ce urmează se prezintă un exemplu de pagină PHP care foloseşte comenzile print şi echo pentru afişarea în browser a unui pagini web statice ce va conţine două mesaje text.<?phpecho “Exemplu de text scris cu echo”; print “Exemplu de text scris cu print”; ?>

În momentul când fişierul de mai sus este solicitat de un utilizator, server-ul Web va recunoaşte fişierul ca fiind o pagină PHP datorită faptului că are extensia .php. Înainte de a trimite fişierul către browser-ul utilizatorului server-ul Web va prelucra scriptul din fişier. În cazul exemplului anterior, scriptul din fişier este codul sursă scris între <?...?>. După prelucrarea scripturilor va rezulta o pagină HTML în care codul sursă PHP se va înlocui cu rezultatul acestuia.

1.4.3. Particularităţi ale programării procedurale în PHP: variabilele PHP

Variabilele PHP nu trebuie declarate ci sunt create automat în momentul primei utilizări. În acest moment li se defineşte tipul de date. Această facilitate permite programatorului posibilitatea dezvoltării rapide a unor aplicaţii complexe. Odată ce o variabilă a fost creată ea

Page 279: licenta hatz

poate fi folosită oriunde în program, cu excepţia funcţiilor, unde trebuie inclusă explicit în zona locală de alocare prin funcţia global. Sintaxa unei variabile PHP este:

$nume_variabilă=valoare;unde valoare poate fi de orice tip.Comentariile se realizează cu semnul „//” în cazul în care se comentează pe un singur rând. În

cazul în care se doreşte inserarea în codul sursă a unui cometariu pe mai multe rânduri se foloseşte semnul „/*...*/”. Aceste comentarii nu sunt interpretate de browser şi se folosesc la explicarea codului sursă.

Tipurile de variabile acceptate de PHP sunt: Integer [WellingThomson2005] [Chip2/2003] care se utilizează pentru numere întregi, de

exemplu: 5,-5,90. String [WellingThomson2005] [Chip2/2003] care se utilizează pentru şiruri de caractere. Un

string este o succesiune de caractere (şir) încadrate între ghilimele.3.Float (Double) [WellingThomson2005] [Chip2/2003] care se utilizează pentru numere reale; 4.Boolean [WellingThomson2005] [Chip2/2003] utilizat pentru a defini o valoare de adevăr

TRUE sau FALSE. Acest tip se foloseşte, în general, pentru a face diferite verificări în procesul de programare. De exemplu, se verifică dacă un anumit produs există în tabela “Produse”. În

cazul în care acesta există se va returna TRUE şi datele despre acest produs vor putea fi afişate pe ecran, în caz contrar se va returna FALSE şi date despre acesta nu se vor putea afişa în

browser.5.Array [WellingThomson2005] [Chip2/2003] se utilizează pentru extragerea mai multor date

de acelaşi tip. Un array poate fi considerat ca fiind un tablou în care fiecărei valori îi corespunde un număr, adică un indice (o poziţie).

Variabilele superglobale sunt: [WellingThomson2005]$_SERVER este un tablou ce conţine variabile de mediu ale serverului;$_GET este un tablou ce conţine variabile transferate scriptului prin metoda GET;

$_POST este un tablou ce conţine variabile transferate scriptului prin metoda POST; $_COOKIE este un tablou ce conţine blocuri cookie;

$_FILES este un tablou ce conţine variabile legate de încărcarea fişierelor;$_REQUEST este un tablou ce conţine toate variabilele introduse de utilizator, inclusiv conţinutul intrărilor din $_GET, $_POST şi $_COOKIE;

$_SESSION este un tablou ce conţine variabile de sesiune.Variabilele globale cele mai folosite sunt:[site19]$_SERVER['REMOTE_ADDR'] are misiunea de a returna adresa IP a vizitatorului;

$_SERVER['HTTP_USER_AGENT'] are misiunea de a returna informaţii despre browser-ul folosit;

$_SERVER['HTTP_REFERER']are misiunea de a returna adresa paginii vizitată anterior;$_SERVER['SERVER_NAME']are misiunea de a returna numele serverului;$_SERVER['SCRIPT_NAME']are rolul de a returna numele fişierului php accesat.O constantă are un tip şi o valoare. Atât tipul, cât şi valoare, sunt determinate de caracterele

care intră în componenţa constantei. Valoare unei constante nu poate fi schimbată în timpul execuţiei programului în care a fost utilizată. [Negrescu2000]

Constantele se caracterizează prin: [site16]li se atribuie o valoare care nu poate fi modificată sau ştersă de-a lungul execuţiei programului;

constantele nu prezintă în sintaxa lor simbolul $ ;

Page 280: licenta hatz

numele unei constante este o succesiune de litere şi eventual cifre, primul caracter este în mod obligatoriu literă. Aceasta este case sensitiv.

constantele au un caracter global.definirea constantei se realizează cu funcţia define().

9. 4.4. Operatori

Interpretorul PHP permite folosirea a nouă tipuri diferite de operatori. Aceştia operează asupraunor expresii (una, doua sau trei) şi furnizează ca rezultat o altă expresie care este rezultatul operaţiei corespunzătoare.[site14]

Operatorii aritmetici acţionează asupra a doi sau mai mulţi operanzi. Aceştia sunt: [site14][WellingThomson2005] [Chip2/2003]

adunare ('+');scădere ('-'); înmulţire ('*'); împărţire ('/');

restul împărţirii ('%').Operatorii relaţionali se folosesc în procesul de compararea a două valori, variabile, constante,

etc. Expresiile în care aceştia apar au ca rezultat valori logice (true sau false). Aceşti operatori sunt:

Operatorul de atribuire definit de semnul “=” are rolul de a atribui unei variabile, constante o valoare.

Operatorul de egalitate se defineşte prin semnul “==” şi se foloseşte pentru a compara două valori, expresii, etc.

Operatorul diferit este definit prin semnul “!=” şi se foloseşte în acelaşi scop ca şi operatorul de egalitate.

Operatorul mai mare este definit de semnul > . Operatorul mai mare egal este definit de semnul >= . Operatorul mai mic este definit de semnul < . Operatorul mai mic egal este definit de semnul <=.Operatorul condiţional se defineşte prin semnul '?'. Acest operator are sintaxa: expresie1?expresie2:expresie3Operatorul condiţional returnează valoarea expresiei expresie2 în cazul în care valoarea

expresiei expresie1 este true, în caz contrar va returna valoarea expresiei expresie3.Operatorul de concatenare este un operator ce se aplică asupra şirurilor de caractere. Acest

operator este definit prin semnul “.” Operaţia de atribuire a concatenării este definită prin semnul“.=”

Operatorii logici se folosesc în cazul în care se lucrează cu valori de adevăr. Aceşti operatori sunt:

9. Operatorul xor (SAU exclusiv) expresia în care apare operatorul 'xor' va avea valoarea true dacă exact unul dintre operanzi are această valoare.

10. Operatorul de negare este: ! (NOT) returnează TRUE dacă valoarea iniţială de adevăr e FALSE şi FALSE dacă valoarea iniţială este TRUE.

11. Operatorul sau logic este || (OR) returnează TRUE dacă oricare din valorile verificate e TRUE. Returnează FALSE doar dacă amândouă valorile verificate sunt FALSE.

Page 281: licenta hatz

4. Operatorul şi logic este: && (AND) returnează FALSE dacă oricare dintre valori este FALSE (sau dacă amândouă sunt FALSE) şi în caz contrar returnează TRUE

1.4.5. Structurile de control

În cadrul unei pagini web care foloseşte scripturi PHP fără să existe o delimitare clară, impusă de PHP pentru zona de declaraţii şi zona de instrucţiuni aşa cum se întâmplă în alte limbaje de programare cum ar fi, de exemplu, activitatea de declarare a variabilelor şi constantelor se reduce la iniţialializarea lor cu o valoare. În php nu se va scrie explicit tipul de date a unei variabile sau constante deoarece acesta se deduce în mod automat după ce acestora li s-a atribuit o valoare. [stanca2007]

Prelucrarea datelor în scripturile PHP, ca şi în orice alt limbaj de programare, se face cu ajutorul instrucţiunilor. Ordinea în care se execută instrucţiunile în cadrul scripturilor defineşte aşa numita structură de control a acestora. [stanca2007]

Structurile de control complexe prezente în PHP sunt: [stanca2007]structura alternativă care se realizează cu ajutorul instrucţiunii IF;structura repetitivă condiţionată anterior care se realizează cu ajutorul instrucţiunilor

WHILE, FOR şi FOREACH;structura repetitivă condiţionată posterior care se realizează cu ajutorul instrucţiunii DO-

WHILE;structura selectivă care se realizează cu ajutorul instrucţiunii SWICH.instrucţiuni folosite în cadrul ciclurilor care oferă o flexibilitatea mare în programarea în

PHP sunt: CONTINUE, BREAK şi RETURN.Instrucţiunea expresie se obţine scriind punct şi virgulă după o expresie. Deci, formatul acestei

instrucţiuni este: [Negrescu2000]expresie;În cazul în care componenta instrucţiunii expresie este o expresie de atribuire această

instrucţiune se transformă în instrucţiune de atribuire [Negrescu2000],Instrucţiunea break; se foloseşte când se doreşte să se întrerupă forţat execuţia unui ciclu şi

trecerea la următoarea instrucţiune existentă imediat după acesta. Această instrucţiune poate fi folosită în cadrul instrucţiunilor WHILE, DO-WHILE, FOR, FOREACH şi SWITCH.

Instrucţiunea continue; se poate utiliza numai în corpul unui ciclu, având ca efect abandonarea iteraţiei curente. Sintaxa ei este:[Negrescu2000] [WellingThomson2005]

continue;Efectul acestei instrucţiuni este:[Negrescu2000;] în corpul instrucţiunilor WHILE, DO-WHILE, se întrerupe iteraţia curentă şi se trece la

evaluarea condiţiei care stabileşte continuarea sau terminarea ciclului. în corpul instrucţiunilor FOR, FOREACH, se întrerupe iteraţia curentă şi se trece la

executarea pasului de reiniţializare.Instrucţiunea return;[Negrescu2000] [WellingThomson2005] este o instrucţiune de revenire

dintr-o funcţie cu următoarele două formate: return; return $expresie;Primul format al acestei instrucţiuni se foloseşte în corpul unei funcţii care nu returnează nici

o valoare, dar la întâlnirea acestei instrucţiuni se iese forţat din ea.

Page 282: licenta hatz

Cel de al doilea format se foloseşte în cadrul unei funcţii care întoarce o valoare la ieşirea din aceasta $expresie deţinând valoarea întoarsă de funcţie.

Instrucţiunea exit; [WellingThomson2005] are rolul de a opri execuţia întregului script PHP. Această instrucţiune se foloseşte în depistarea şi corectarea erorilor din cadrul unui script PHP.

Instrucţiunea declare [WellingThomson2005] se foloseşte la stabilirea directivelor de executare/rulare a unui cod sursă. Până în prezent a fost implementată o singură directivă de executare, numită ticks care se stabileşte astfel: ticks=n (se permite rularea în cadrul unui cod sursă a unei funcţii după fiecare n linii de cod) Sintaxa acestei instrucţiuni este:

declare(directivă) set instrucţiuni;Funcţiileinclude(); şi require(); sunt echivalente şi au rolul de a insera conţinutul unui fişier în

cadrul unui scipt PHP în locul acestora. Diferenţa dintre cele două funcţii este că în caz de eroare require(); va produse o eroare fatală, în timp ce construcţia include(); va afişa un mesaj de eroare.

1.4.6. Tab lou ri

În majoritatea limbajelor prin tablou se înţelege o mulţime de date de acelaşi tip cu acceaşi structură. Tablourile sunt alcătuite din elemente şi indici. În PHP şi nu numai, tipurile cele mai utilizate de tablouri sunt: tablouri unidimensionale şi bidimensionale. În cadrul unui tablou activităţile care se pot realiza sunt:

1.Crearea tablourilor în PHP se realizează prin atribuirea explicită a unei valori fiecărui elemet al acestuia, cu funcţiile array();. Sintaxa funcţiei array(); este:[site21]

array( [index=>] value, ... ); undeindex poate fi de tipul integer sau string; valoare poate fi de orice tip.Funcţia array(); permite crearea în două moduri a tablourilor şi anume:a)Primul mod de creare a unui tablou cu funcţia array constă în omiterea parametrului opţional

numit indice, existent în sintaxa acesteia, rezultatul fiind următorul: [Stanca2007]

<? $oamenii_la_masa = array(‘Milaș’,’Cristian’,’Mioara’) ;?>

Funcţia array(); este de fapt o construcţie a limbajului PHP la fel ca echo. În exemplul de mai sus s-a creat un tablou numit $oamenii_la_masa care conţine 3 elemente de tipul string.

b) Al doilea mod de creare a unui tablou cu funcţia array(); constă în folosirea parametrului opţional numit indice, existent în sintaxa acesteia, rezultatul fiind următorul: [Stanca2007]

<?$oamenii_la_masa = array (33=>‘Irinel’, 2=>’Mioara’, 7=>’Victorel’ ) ;?>

Deci, indici tabloului nu vor fi 0,1 şi 2 ci cei precizaţi de cel care crează tabloul. În exemplul anterior indicii tabloului vor fi 33, 2, 7.

Tablourile în PHP mai pot fi create fără utilizarea funcţiei array(); prin atribuirea explicită de valori fiecărui element al acestuia, ca în următoarul exemplu: [Stanca2004.3]

< ? $oamenii_la_masa[0]= "Irinel" //elementul este Irinel iar indicele este 0. $oamenii_la_masa[1]= "Mioara" //elementul este Mioara iar indicele este 1.

Page 283: licenta hatz

$oamenii_la_masa[2]= "Victorel" //elementul este Victorel iar indicele este 2. ?>

Acţiunea de creare unui tablou în PHP se mai poate efectua cu ajutorul funcţiei range();. Această funcţie are rolul de a crea un tablou sortat crescător astfel: [Stanca2007]

<? $tablou_caractere = range(‘A’,’Z’);//se crează un tablou care are ca elemente literele alfabetului $tablou_numeric = range(‘10’,’100’);//un tablou creat din elemente numerice cu valori de la 10 la100. $tablou_numeric2 = range(10,100,10);// un tablou creat din elemente numerice cu valori de la 10 la100 din 10 în 10. ?>

2.Modificarea datelor din tablouri se realizează cu următoarea sintaxă: [Stanca2004.3]

$nume_tablou[indice]=valoare ;//indice poate fi atât de tipul întreg// cât şi de tipul string

sau $nume_tablou[]=valoare;

În cazul tabloului creat în exemplele anterioare dacă se doreşte să se modifice valoarea existentă pe poziţia a doua, adică în loc de "Marian" la masă să fie "Mirina" se va face astfel:[Stanca2007]

<? $oamenii_la_masa = array(‘Ionela’,’Marian’,’Mirel’); $oamenii_la_masa[1]= "Mirina";

print_r($oamenii_la_masa);// afişează datele din tabelă împreună cu indicii acestora ?>

3.Ştergerea[site21] unui tablou se face cu ajutorul funcţiei unset();. Dacă se doreşte să se şteargă toate elementele unui tablou se procedează astfel:

<? $oamenii_la_masa = array(33=>‘Ionita’,’Morico’,’Tinel’) ; unset($oamenii_la_masa);// ştergerea unui tablou foreach($oamenii_la_masa as $element)echo $element; // nu se va afisa nimic dearece tablou e şters ?>

Ştergerea unui element din tablou se realizează astfel:

<?$oamenii_la_masa = array(‘Irinel’,’Maria’,’Victorel’); unset($oamenii_la_masa[2]); // se şterge elementul Victorel foreach($oamenii_la_masa as $element)echo $element; // se vor afişa doar primele 2 elemente ale tabloului ?>

4. Copierea datelor din tabloul $oamenii_la_masa în tabloul $oamenii_la_masa1 se face utilizând operatorul de atribuire astfel: [Stanca2007]

Page 284: licenta hatz

< ? $oamenii_la_masa1 =$oamenii_la_masa;?>

5.Afişarea datelor dintr-un tablou se face folosind construcţia echo, numele tabloului şi indicii pe care s-au memorat elementele tabloului ca în exemplul următor : [Stanca2007]

< ?$oamenii_la_masa = array(‘Crinela’,’Mirita’,’Vivi’)echo "$oamenii_la_masa[0] $oamenii_la_masa[1] $oamenii_la_masa[2]"; ?>

Afişarea datelor se mai poate realiza folosind ciclul FOR astfel:

<?$oamenii_la_masa = array(‘Crinela’,’Mimirita’,’Victor’); for($i=0;$i<=count($oamenii_la_masa);$i++)echo "$oamenii_la_masa[$i]";?>

Afişarea datelor se mai poate realiza cu ciclul FOREACH, destinat în principal prelucărilor datelor unui tablou, a cărei sintaxă şi mod de execuţie a fost prezentată anterior. Acest ciclu va avea nevoie de o variabilă în care se vor depune pe rând fiecare element al unui tablou şi pe care o va afişa, ca în exemplul de mai jos:

<?$oamenii_la_masa = array(33=>‘Nicorici’,’Milica’,’Totici’) foreach($oamenii_la_masa as $element)echo $element; ?>

1.4.7. Tablouri multidimensionale

În PHP un tablou multidimensional este o reuniune de tablouri unidimensiomale. Deci, fiecare element al lui este un tablou. Crearea tablourilor multidimensionale în PHP se realizează prin declararea mai multor tablouri unidimensionale ce reprezintă linile tabloului iar elementele acestora reprezintă coloanele. Sintaxa funcţiei array(); pentru crearea tablourilor multidimensionale este:[site21]

array( [index1 =>] array ([index=>] value, ... ), [index2 =>] array ([index=>] value, ... ),...[indexn =>] array ([index=>] value, ... ) );undeindex1,...,indexn poate fi un sting sau un întreg formând liniile tabloului.index poate fi de tipul integer sau string. Acest index poate fi identic (nu e obligatoriu) pentru

fiecare linie fiind interpretat ca numele coloanelor tabloului declarat;valoare poate fi de orice tip.

Page 285: licenta hatz

1.4 .7 .1 . Afişarea şi parcurgerea elementelor unui tablou multidimensional

Afişarea elementelor unui tablou multidimensional atât în PHP cât şi în alte limbaje de programare necesită folosirea a două ciluri FOR cu ajutorul cărora să se parcurgă atât linile cât şi coloanele acestuia. Această acţiune se poate realiza ca în exemplul următor : [Stanca2007]

<?$oamenii_la_masa = array( array('Viorel','elev',10), array('Maria','profesor',39), array('Ionel','pensionar',76) );

for($i=0;$i<count($oamenii_la_masa);$i++) for($j=0;$j<count($oamenii_la_masa[$i]);$j++)

echo $oamenii_la_masa[$i][$j];echo '<br/>';?>

1.4.7.2. Operatori folosiţi în prelucarea datelor din tablouri

PHP prezintă operatori care acţionează atât asupra variabilelor care, au fost prezentate în paginile anterioare cât şi asupra tablourilor. Operatorii care acţionează asupra tablourilor sunt:[WellingThomson2005]

operatorul reuniune care este reprezentat prin “+”. Efectul acestui operator este că se adaugă la sfârşitul primului tablou elementele tabloului de pe a doua poziţie eliminându-se indicii care sunt dubluri.operatorul egalitate reprezentat prin “ = =“ returnează TRUE dacă tablourile care se compară au elemente identice altfel returnează FALSE.operatorul identitate reprezentat prin “ = =“ returnează TRUE dacă tablourile care se compară au aceleaşi elemente şi în aceeaşi ordine, altfel returnează FALSE.operatorul diferit reprezentat “ ! =“ sau “<>“ returnează TRUE dacă tablourile conţin elemente diferite, altfel returnează FALSE.operatorul “ ! = =“ returnează TRUE dacă tablourile care sunt comparate nu conţin aceleaşi elemente pe aceleaşi poziţii, altfel returnează FALSE.

17: 4.8. Funcţii

O funcţie este un ansamblu alcătuit din tipuri de date, variabile, constante şi instrucţiuni scriseîn vederea unei anumite prelucrări(calcule, citiri, scrieri) şi care pot fi rulate doar dacă sunt apelate dintr-un script PHP. Sintaxa unei funcţii este: [Stanca2007]

nume_funcţie( listă parametrilor formali)

corp funcţie;unde:listă de parametrilor formali este de forma: $nume_parametru1, $nume_parametru2,...,$nume_parametru nObservaţie: O funcţie poate să prezinte o listă vidă de parametri formali. Corpul unei funcţii

este alcătuit din două părţi : [Stanca2007.3]partea de declaraţii în care se precizează variabilele locale;

Page 286: licenta hatz

partea de instrucţiuni care conţine instrucţiunile pe care le execută funcţia respectivă. O funcţie poate fi definită oriunde în cadrul unui script. În interiorul unei funcţii pot să apară

orice secvenţă validă de cod care include definirea unor alte funcţii. O funcţie poate fi apelată înainte de definirea acesteia într-un script. Argumentele unei funcţii trebuie separate prin virgulă şi, implicit, acestea sunt transmise prin valoare. Pentru ca funcţia să returneze un rezultat se foloseşte construcţia return; care primeşte ca parametru o expresie care reprezintă valoarea întoarsă de funcţie. În momentul în care este întâlnită construcţia return;, execuţia funcţiei seîncheie. [ScarlatSoroiu]

Exemplu de apel de functie:<?php

function declare_functie($textdeafisat)echo "<h1>$textdeafisat </h1><br>\n";

declare_FUNCTIE("apel 1 al functiei"); dEclare_Functie("apel 2 al functiei"); Declare_functie("apel 3 al functiei"); ?>Din exemplu de mai sus rezultă ca în PHP nu se ţine cont de modul în care este scris un nume

de funcţie.O funcţie definită de utilizator poate avea mai mulţi parametrii. Exemplu de funcţie definită de

utilizator care crează un tabel html şi îl populează:<?phpfunction creare_tabel($data, $border=1,$cellpadding=4,$cellspacing=4) echo "<table border=$border cellpadding=$cellpadding cellspacing=$cellspacing>"; reset($data);//se pointeaza la inceputul tabelului$value=current($data); while($value)echo "<tr><td>$value</td></tr>\n"; $value=next($data);echo "</table>“;echo "Se apeleaza functia:"; $sirul=array('Prima linie.','Linia 2.','Linia 3.'); creare_tabel($sirul);echo "apel cu parametrii optionali precizati:<br/>"; creare_tabel($sirul,3,8,8);creare_tabel($sirul,3); ?>Observaţie: Nu trebuie să se precizeze toţi parametrii opţionali. Parametriivor fi atribuiţi de la

stânga la dreapta.Nu se poate sări peste un parametru opţional şi să se precizie următorul. Dacă se doreşte să se atribuie o valoare lui cellspacing în mod obligatoriu se atribuie şi lui cellpading o valoare. În general parametrii opţionali se precizează ultimii într-o lista de parametrii.

În PHP ca în orice alt limbaj de programare se folosesc 2 metode de trasmitere a valorilor şi anume:

1.Transferul prin valoare:metoda implicită prin care se apelează parametrii unei funcţii. La transferul unui parametru se crează o variabila nouă care conţine valoarea transferată, de fapt

Page 287: licenta hatz

este o copie a originalului.Prin această metodă, se poate modifica valoarea din cadrul unei funcţii în orice mod, dar valoarea variabilei din exteriorul funcţiei rămâne nemodificată.

2.Transmiterea prin referinţă:atunci când un parametru este transferat unei funcţii: funcţia primeşte o referinţă la variabila original, nu crează o variabilă nouă. Aceasta referinţă are un nume de variabila care incepe cu semnul dolarului şi poate fi folosită exact ca orice variabilă. Diferenţa constăîn faptul că această ultimă variabilăîn loc să deţină propria valoare ea se referă la valoarea variabilei originale.Toate modificările facute asupra referinţei afecteazăşi originalul. În PHP, pentru a se specifica faptul ca pentru un parametru se foloseşte transferul prin referinţa, se trece un ampersant (&) în faţa numelui parametrului,în definiţia funcţiei. În apelul funcţiei nu se face nici o modificare.

.

9. 4.9. Funcţii predefinite

Funcţiile predefinite se împart în următoarele categorii:[Stanca2007]1. Funcţiile matematice sunt:[site18]

max(x,y,...) returnează valoarea maximă a unui set de valori; min(x,y,...) returnează valoarea minimă a unui set de valori; pow(x,n) returnează numărul x, ridicat la puterea specificata n; sqrt(x) returnează rădăcina pătrată a lui x.

2. Funcţiile pe şiruri de caractere sunt:11. int strlen(string sir)[site19] are rolul de a returna lungimea şirului sir primit ca

parametru.12. string trim(string sir)[site19] are rolul de a elimina spaţiile albe dintr-un şir primit ca

parametru.13. string ltrim(string sir)[site19] are rolul de a elimina spaţiile albe din stânga şirului

primit ca parametru.14. string rtrim(string sir)[site19] are rolul de a elimina spaţiile albe din dreapta şirului

primit ca parametru.15. int count(string sir)[site19] are rolul de a număra elementele unui şir primit ca

parametru şi returnează numărul lor.16. int strcmp (string sir1, string sir2) [McCatry2002] are rolul de a compara caracter cu

caracte cele două şiruri de caractere primite ca parametru. Valoarea returnată este:← <0, dacă şir1<şir2;← =0, dacă şir1=şir2;← >0, dacă şir1>şir2.

17. string substr (string sir, int n [, int m])) [McCatry2002] are rolul de a returna un subşir, din şirul primit ca parametru începând cu poziţia n şi având lungimea m, în caz că m este specificat. Din cauză că parametrul m este specificat în sintaxa funcţiei între paranteze pătrate înseamnă că este opţional, deci poate lipsi şi atunci se afişează toate caracterele şirului sir primit ce parametru începând cu poziţia n.

18. string htmlspecialchars (string sir, [, int citare]) [McCatry2002] converteşte toate caracterele speciale primite ca parametru în entităţi HTML

Funcţiile calendaristice sunt: [McCatry2002][ [Chip2/2003]2.2.7strftime(a) returnează data curentă, formatată conform conţinutului parametrului a;2.2.8date() returnează ora, luna, anul precum şi alte elemente ale datei curente în funcţie de

context ;

Page 288: licenta hatz

← now() returnează data şi ora curentă.← hour(t) returnează ora din cadrul parametrului. Valorile parametrului pot fi în intervalul

[0-23].Funcţia isset()va returna adevărat dacă o variabilă există şi are o valoare, in caz contrar va

afisa NULL.Funcţiafunc_num_args () va returna numărul total de parametrii transmişi unei funcţii, atât

cei declaraţi cat şi cei anonimi.

4.10.Stocarea datelor în sistemul utilizatorului cu PHP

Utilizarea unui web site de către un utilizator presupune realizarea unor acţiuni succesive caretrebuie memorate pentru a oferi acestuia informaţia de care are nevoie, dar protocolul HTTP nu oferă o astfel de facilitate fapt pentru care a apărut noţiunea de cookie respectiv sesiune cu ajutorul cărora se pot păstra aceste informaţii pe calculatorul utilizatorului astfel:

sesiuni au rolul de a reţine informaţiile care trebuie transmise de la o pagină la alta într-o aplicaţie PHP. Într-o sesiune datele pot fi salvate într-o variabilă de tip array, numită $_SESSION. Înainte de a folosi această variabilă pentru a stoca informaţiile trebuie să se apeleze funcţia predefinită de deschidere, creare sau reiniţializare a sesiunii. Sintaxa acestei funcţii este:[WellingThomson2005] [site27] [McCatry2002]

session_start();Acestă funcţie crează şi porneşte o sesiune în cazul în care nu există niciuna dar în cazul în

care aceasta există o reiniţializează. Informaţiile din sesiune sunt păstrate pe server în directorul pentru fişiere temporare, adică „Temp” dar acestea pot fi memorate şi într-o bază de date.

cookie această noţiune este utilizată generic ca bloc de date. În prezenta abordare se va utiliza această noţiune în sensul uzual din WWW [Microsoft1999]: „...bloc de date pe care un server Web îl stochează într-un sistem client. Când utilizatorul revine la site-ul Web respectiv, browser-ul trimite serverului o copie a prăjiturii. Prăjiturile sunt utilizate pentru a identifica utilizatorii, pentru a instrui server-ul să transmită o versiune personalizată a paginii Web cerute, pentru a prezenta informaţii referitoare la contul utilizatorului şi pentru operaţii cu caracter administrativ”. Dezavantajul folosirii doar a blocurilor cookie în programarea paginilor web provine din faptul că pe de o parte unele browsere nu le acceptă, pe de altă parte există utilizatori care le dezactivează din browser-ele lor. PHP tocmai din acest considerent foloseşte metoda duală bloc cookie/URL.

1.5. PHP şi formulare HTML

Web-ul a dobândit un plus de interactivitate prin utilizarea programelor create, folosind interfaţe CGI, Perl, ASP şi PHP. Aceaste programe au permis scrierea de coduri sursă cu rolul de a trimite de la browser spre server-ul WEB atât a informaţiilor standard conţinute în antetul HTTP al cererii cât şi informaţii în alte două moduri şi anume: [Stanca2004.3]

printr-un formular <FORM> ;ca un şir de cereri adăugate la sfârşitul URL-ului.

Formularele HTML, afişate într-un browser, numite şi intrări HTML, au rolul important în preluarea datelor de la utilizatorul unui web site. Aceste datele vor fi preluate de browser şi transmise la server printr-un program (scris în PHP) care procesează datele din formular. În funcţie de scopul programului rulat de server acesta poate genera un răspuns de tip HTML, pe

Page 289: licenta hatz

care serverul îl trimite către browser cu scopul de al afişa utilizatorului. Mecanismul de funcţionare a prelucrării datelor din cadrul unui formular este prezentat în figura de mai jos:

Figura 4.11. Model Client-Server care foloseşte PHP(adaptare[LalaniChandak1997])

1.5.1. Crearea unui formular

Un formular se crează cu tag-urile <FORM>...</ FORM> între care se folosesc obiecte create în marea lor majoritate cu tag-ul de tip <INPUT> cu diferite valori pentru atributul TYPE al acestuia. În cazul în care atributul TYPE al tag-ului <INPUT> are valoare “SUBMIT” se va crea un buton. Rolul acestui buton este acela de a transmite server-ului informaţiile pe care utilizatorul le introduce, în câmpurile formularului. Server-ul prelucrează şi transmite datele primite din formular: fie unei alte pagini web statice care le afişează în browser, fie unei pagini web dinamice care le memorează într-o tabelă a unei baze de date sau le trimite prin e-mail destinatarului. [Stanca2007]

Folosind PHP-ul, se întâlnesc trei metode de bază pentru colectarea informaţiei din formulare HTML, şi anume : [Stanca2007]

un fişier .html static conţine un formular care trimite valorile sale către un fişier php. un fişier .php poate să creeze un formular care să trimită informaţia către un alt fişier

.php. un fişier .php poate să creeze un formular care să trimită informaţia chiar către fişierul

php care conţine formularul.Datele dintr-un formular existent într-o pagină Web sunt transferate către server utilizând

numele fişierului php ca valoare pentru atributul ACTION şi precizând una din metodele ”GET” sau ”POST” ca valoare pentru atributul METHOD a tag-ului <FORM>. Elemetele formularului au asociate câte un nume căruia i se atribuie de fapt valoarea introdusă de utilizator în acestea, care se vor transmite serveru-lui spre prelucare. Variabilele superglobale ”$_POST” şi ”$_GET” sunt nişte array-uri care conţin toate datele transmise din formular cu una din cele două metode.

Page 290: licenta hatz

1.5.2. Accesul la bazele de date relaţionale din pagini PHP

PHP include o bibliotecă de funcţii care furnizează o interfaţă cu sistemul MySQL. Folosind aceste funcţii, un programator PHP poate obţine accesul la datele rezidente într-o bază de date MySQL şi le poate modifica.

Majoritatea interacţiunilor cu o bază de date se desfăşoară după un model secvenţial simplu şi anume [PHP2-site]:

Se deschide o conexiune cu server-ul MySQL. Pentru a se putea realiza conectarea la un serverMySQL, trebuie să se invoce funcţia mysql_connect( ), a cărei sintaxă este următoarea[PHP2-site]:

mysql_connect (”nume_gazdă”, ”nume_utilizator”, ”parolă”);Conectarea cu succes la baza de date permite realizarea de interogări SQL, urmate de

obţinerea accesului la rezultatele interogărilor şi apoi se execută operaţii nonSQL: mysql_query($interogare);. Funcţia mysql_query(); execută interogarea primită ca parametru şi returnează TRUE dacă interogarea a fost efectuată cu succes şi FALSE în caz contrar. Această funcţie se atribuie unei variabile în care se depune valoarea returnată de aceasta numită identificator de resurse.

Funcţia mysql_num_rows(); se foloseşte în cazul în care se doreşte să se determine numărul de rânduri returnate în urma interogării unei tabele.

Funcţia mysql_fetch_array(); care permite să se acceseze valorile din tabelul returnat de interogare în mai multe moduri şi anume:

folosind un array numeric; folosind un array asociativ; folosind un array mixt.

Acţiunea de închidere a conexiunii cu serverul MySQL se realizează invocând funcţia: mysql_close( );.

Adăugarea de noi înregistrări într-o tabelă a unei baze de date se face cu comanda INSERT. Cel mai frecvent mod de introducere a datelor într-un tabel a unei baze de date este preluarea lor dintr-un formular adecvat structurii acestuia. Sintaxa pentru introducere a datelor într-un tabel a unei baze de date este:[site30]

INSERT INTO nume_tabel (coloana_1, coloana_2,..., coloana_n) values ('valoare_1','valoare_2',...,'valoare_n');

Modificarea datelor în cadrul unei tabele a unei baze de date presupune realizarea următorilor paşi :

conectarea la baza de date şi efectuarea unui SELECT asupra tabelei în funcţie de o condiţie pentru a se obţine înregistrarea care se doreşte a fi modificată;

crearea unui formular în care să se afişeze datele înregistrării care urmează a fi modificate;

acţiunea de modificare efectivă care se va realiza cu ajutorul comenzii UPDATE a cărei sintaxă este :[site30]

UPDATE nume_tabel SET coloana_1='$valoare_1', coloana_2= '$valoare_2',..., coloana_n='$valoare_n' WHERE condiţie;

Ştergerea datelor dintr-o tabelă a unei baze de date presupune realizarea următorilor paşi: conectarea la baza de date şi efectuarea unui SELECT asupra tabelei în funcţie de o

condiţie pentru a se obţine înregistrarea care se doreşte ştearsă ;acţiunea de ştergere efectivă care se va realiza cu ajutorul comenzii DELETE a cărei

sintaxă este :[site30]

Page 291: licenta hatz

DELETE FROM nume_tabel WHERE condiţie;O ultimă acţiune ce se impune a fi executată într-un web site este cea de căutare. Această

acţiune se realizează cu ajutorul instrucţiunilor SQL şi a comenzii LIKE. Comanda LIKE are rolul de a căuta o valoare prin compararea acesteia cu un model. Modelele se formează fie cu caracterul procent (%) şi un text fie cu caracterul liniuţă de subliniere ( _ ) şi un text. Procentul se foloseşte în cazul în care se doreşte o căutare pe un spectru mai larg adică, se furnizează ca rezultat al căutării toate construcţiile care conţin în componenţă textul care înşoţeşte acest caracter neţinându-se cont de numărul de caractere. Liniuţa de subliniere se foloseşte pentru a indica o potrivire a caracterului de înlocuire cu un singur caracter.[WellingThomson2005]

În cadrul acestui capitol au fost prezentate elemente teoretice însoţite de exemple practice ale limbajului de scripting PHP. Aceste exemple puse cap la cap pot constitui piatra de temelie în procesul de creare a oricărui web site dinamic complex.

1.6. PHP – XMLUna dintre cele mai importante modificări efectuate în PHP 5 este modul în care PHP se ocupă

de date XML.Codul care sta la baza motorului PHP a fost transformat şi reorganizat pt a furniza un set de instrumente de analiză XML care respecta recomandările World Wide Web Consortium (W3C). Întrucât PHP 4 utiliza o bibliotecă diferita pentru a pune în aplicare fiecare instrument XML, PHP 5 profită de o singură bibliotecă standardizat: Gnome XML biblioteca (libxml2). În plus, PHP 5 introduce mai multe instrumente noi pentru a simplifica prelucrarea documentelor XML.Pentru a prelucra cu ajutorul PHP-ului datele dintr-un document XML trebuie ca acesta săprezinte structura şi sintaxa corectă, comform standardului XML, nu e nevoie să fie strict valid, adică să conţină DTD. PHP include trei modalităţi deprelucrarea a unui fişierXML: SimpleXML, DOM (Document Object Model)şi SAX (Simple API for XML).Aceste 3 modalităţi prezintă avantaje şi dezavantaje.Se pot utiliza oricare dintre aceste trei moduri de prelucrare(creare, adăugare, modificare şi ştergere) a fişierelor XML. În cele ce urmează vom prezenta modul de prelucrare a fişierelor XML cu ajutorul luiSimpleXML.[Converse_Park_Morgan_2005][Greenspan_Bulger2001][site100]

SimpleXML a apărut în PHP 5, lucrează asemănător cu DOMmai exact cu obiecte, preia tot documentul XML sub forma unui arbore ierarhic in memorie, dar spre deosebire de acesta, e mai flexibil şi foloseşte mai puţină memorie deoarece elementele sunt stocate direct ca variabile PHP (de tip string şi array) şi astfel pot fi imediat utilizate. Foloseşte un minim necesar de cod şi are o formă intuitivă a datelor. În SimpleXML, majoritatea datelor sunt stocate în variabile de tip array.[Greenspan_Bulger2001][site100]

SimpleXML are relativ puţine funcţii predefinite, deoarece se apelează mult la funcţiile pentru array şi string. Funcţiile predefinite ale lui SimpleXML sunt:[Greenspan_Bulger2001][site100]

simplexml_load_file("fisier.xml") - încarcă în memorie, ca obiect, datele din "fisier.xml"; simplexml_load_string("sir_xml") - încarcă în memorie, ca obiect, datele din şirul"sir_xml";simplexml_import_dom("dom_node") –transformă/preia un obiect DOM (sau Nod dintr-un obiect DOM) în obiectul SimpleXML;addChild("nume", "continut") - adaugă un element copil în cel curent (la sfârşit dacă are şi altele) cu numele "nume" şi conţinutul text "continut";addAttribute("nume", "valoare") - adaugă un atribut într-un element (la sfârşit dacă are şi altele) cu numele "nume" şi valoarea "valoare";

children() - preia într-o matrice toţi copiii dintr-un nod (element).

Page 292: licenta hatz

attributes() - preia într-o matrice toate atributele dintr-un element.count() - returnează numărul de copii dintr-un element.

getName() - returnează numele unui element. Această funcţie se foloseşte adesea când se parcurge o matrice cu mai multe elemente.asXML("fisier.xml") - transformă datele obiectului SimpleXML într-un şir, iar dacă parametrul "fisier.xml" e specificat scrie şirul în fişierul specificat.

Prelucrarea fişierelor xml din PHP presupune parcurgerea următorii paşi:[Greenspan_Bulger2001][site100]1. crearea unui fişier cu extensia xml în cazul de fata numit bd.xml cu structura:[site100]<?xml version="1.0"?> <bd><carte isbn="1" pubdata="1983-01-01"> <titlu><!

[CDATA[Manipularea Creierelor]]></titlu> <autor >Armen Victorian</ autor><pret>30</pret>

</carte><carte isbn="2" pubdata="2000-01-01"> <title><!

[CDATA[Marea carte a jocurilor minţii]]></titlu> <autor >Ivan Moscoviciu</autor><pret>50</pret>

</carte><carte isbn="3" pubdata="1999-03-01"> <titlu><!

[CDATA[Maturizarea Personalităţii]]></titlu> <autor>Robert Pacinec</autor><pret>20</pret>

</carte></bd>

2.generarea unui fişier xml dintr-un fişier php cu SimpleXML, datele se vor memoraîntr-un array. Unarray nu permite să se atribuie tipul CDATA pt titlul cărţii:[Greenspan_Bulger2001][site100]

<?phpfunction fnSimpleXMLCreare()$b= array(array('isbn'=>'1', 'pubdate'=>'1983-01-01', 'titlu'=>' Manipularea Creierelor ',

'autor'=>'Armen Victorian', 'pret'=>'30'),array('isbn'=>'2', 'pubdate'=>'2000-01-01',

'titlu'=>'Marea carte a jocurilor minţii ', 'autor'=>'Ivan Moscoviciu', 'pret'=>'50'),

array('isbn'=>'3', 'pubdate'=>'1999-03-01', 'titlu'=>'Maturizarea personalităţii', 'autor'=>'Robert Pacinec', 'pret'=>'20'));

// se creaza un fisier XML in care root va fi <bd> iar nodurile fiu<carte> fiecare carte are subnoduri titlu, autor si pret

$bd = new SimpleXMLElement('<bd/>'); for($i=0;$i<3;$i++)

$carte = $carte->addChild(‘carte'); $carte->addAttribute('isbn', $b[$i]['isbn']);

Page 293: licenta hatz

$carte->addAttribute('pubdate', $b[$i]['pubdate']); $carte->addChild('titlu',$b[$i]['titlu']); //nu se poate crea CDATA in

SimpleXML.$carte->addChild('autor', $b[$i]['autor']); $carte->addChild('pret', $b[$i]['pret']);

$library->asXML('./bd.xml');

fnSimpleXMLCreare();?>2. Modificarea unui fişier XML din PHP cu SimpleXML:[Greenspan_Bulger2001][site100]<?phpfunction fnSimpleXMLEdiaretElementSec()

$bd = new SimpleXMLElement('./bd.xml',NULL,true); $nr = count($lbd);

$bd->carti[$nr-1]->titlu=$bd->carti[$nr-1]->title."----Pedagogie"; header("Content-type: text/xml");

if ($library->asXML('./bd.xml')==1) echo $lbd->asXML();

elseecho "Nu s-a modificat";

fnSimpleXMLEdiaretElementSec();?>

3. Modificarea unui fişier XML din PHP se foloseşte XPath pt poziţionare pe element.[Greenspan_Bulger2001][site100]

<?phpfunction fnSimpleXMLEdiaretElementCond()

$bd = new SimpleXMLElement('./bd.xml',null,true); $carte= $bd->xpath('/bd/carte[autor="Ivan Moscoviciu"]'); $carte[0]->title =$carte[0]->title. 'Volum 1 '; header("Content-type: text/xml");if ($bd->asXML('./bd.xml')==1)

echo $bd->asXML();else

echo "Nu s-a modificat";

fnSimpleXMLEditareElementCond();?>

3.Adaugarea unei noi cărţi la sfârşitul celor existente în fişierulXML.[Greenspan_Bulger2001][site100]

<?phpfunction fnSimpleXMLAdaugElement2sf()

Page 294: licenta hatz

$bd = new SimpleXMLElement('./bd.xml',null,true); $carte = $library->addChild('carte'); $carte->addAttribute('isbn', '4'); $carte->addAttribute('pubdate', '2000-07-11'); $carte->addChild('titlu', "Cartea gesturilor"); $carte->addChild('autor', "Peter Collett"); $carte->addChild('pret', "10"); header("Content-type: text/xml");echo $bd->asXML();

fnSimpleXMLAdaugElement2sf();?>4. Ştergerea elementelor unui fişier XML se face astfel:[Converse_Park_Morgan_2005][site100]

<?php

function fnSimpleXMLStergere()

$bd = new SimpleXMLElement('./bd.xml',null,true); unset($bd->carte[1]);

header("Content-type: text/xml"); echo $lbd->asXML();

fnSimpleXMLStergere();?>SimpleXML este util pentru a realiza o prelucrare uşoara a documentelor XML din PHP.

Prelucrările mai complexe asupra documentelor XML, impun folosirea luiDOM.[Greenspan_Bulger2001][site100]

1.7. Particularităţile programării Orientate Obiect în programarea Web pe parte de server (limbajul PHP)

În limajul PHP, programarea orientată obiect se poate realiza timid începând cu versiunea 4.PHP 5.0 este orientat obiect şi deplin funcţional dar are o compatibilitate redusă cu versiunile precedente.[Converse_Park_Morgan_2005][Greenspan_Bulger2001] Funcționalități bazice de programare orientată pe obiecte au fost adăugate în PHP 3. În versiunile 3 și 4 ale lui PHP obiectele erau tratate ca un tip de dată de bază, și deci de fiecare dată când o variabilă era utilizată într-o funcție tot obiectul era copiat. Felul în care obiectele sunt tratate a fost complet rescris în PHP 5. Din PHP 5 începând obiectele sunt referențiate printr-un vector intern și nu după valoarea pe care o au. PHP 5 a introdus metode private și protejate, clase abstracte, constructori și destructori, functionalități similare cu cele din alte limbaje de programare care folosesc paradigma OOP, precum C++.

Fundamentele programării orientate pe obiecte în PHP ca şi în alte limbaje se bazează pe conceptul de grupare a datelor în unităţi numite clase.[WellingThomson2005] Acest proces în general este numit încapsulare sau ascundere a informaţiilor, pentru că obiectivul său este să împartă o aplicaţie în entităţi separate care sunt component interne care pot fi schimbate fară să

Page 295: licenta hatz

se modifice interfaţa. Astfel clasele sunt în esenţă, o reprezentarea a unui set de funcţii (numite metode) şi variabile (numite proprietăţi) concepute să lucreze împreunăşi să furnizeze o anumită interfaţă.În acest tip de programare este esenţial să se inţeleagăideea:clasele sunt doar planuri care nu pot fi folosite direct, acestea trebuie să fie instanţe de obiecte, care pot să interacţioneze cu restul aplicaţiei.[Converse_Park_Morgan_2005][Greenspan_Bulger2001]Sintaxa de declarare a unei clase este:Class Prima// Conţinutul clasei

Deci, am declarat o clasă numită Prima a cărui conţinut va fi o combinaţie de constante, variabile şi funcţii(numite metode). O clasa se impune să fie instanţată în scopul de a profita de funcţionalităţile pe care le oferă. Acest lucru se face prin utilizând constructorul new astfel:

$nume=new Prima();In PHP5 obiectele sunt tratate diferit în comparaţie cu alte tipuri de variabile. Un obiect este

întotdeauna trimis prin referinţă (în realitate este trimis prin handler).[WellingThomson2005]Unul dintre punctele fundamentale ale conceptului OOP este moştenirea. Aceasta permite unei

clase să se extindă la altă clasă, în esenţă se adaugă noi metode şi proprietăţi, precum şi rescrierea celor existente în funcţie de nevoi.[Converse_Park_Morgan_2005] [Greenspan_Bulger2001]

Asa cum s-a menţionat mai sus clasele conţin atât metode(funcţii) cât şi proprietăţi(variabile). Metodele se declară ca şi funcţiile, astfel:

class Prima function prima_functie() echo "ApelPrima::prima_functie";Din afara domeniului unei clase, metodele sunt apelate folosind operatorul: „->” $obiect = new Prima();$obiect->prima_functie();În exemplul de mai sus obiect este o proprietate care este vizibilă în domeniul de definiţie al

fragmentului de cod de mai sus. În acest context PHP deţine o variabilă specială numită $this. Această variabilă este definită numai în cadrul domeniului de aplicare al unui obiect, şi întotdeauna pointează spre obiectul în sine.

class Prima function prima_functie($val) echo "Valoare este: $val";function apel($val)$this->prima($val);$obiect = new Prima();$obiect->prima_functie(3);//apel direct al funcţiei prima_functie $obiect->apel(4);//apel direct al funcţiei apel

Page 296: licenta hatz

Codul sursă de mai sus va afişa pe ecran: Valoarea este 3 Valoare este: 4Principiu de bază al programării orienate obiect în PHP este: definirea claselor să se realizeze

într-o pagină seprată. Paginile în care se definesc clasele sunt incluse în pagina principală a proiectului cu include sau require.[Converse_Park_Morgan_2005][Greenspan_Bulger2001]Un exemplu de program care utilizează programarea orientat[ obiect pentru a afișa un mesaj de test de genul “Merge!”

<?phpClass merge

function merge()

return "Merge!";

$world = new

merge(); echo world->merge(); ?>

1.7.1. Const ru ctorii

PHP 5 introduce conceptul de constructor unificat şi un nou destructor pentru obiecte. Constructorul şi destructorul sunt metode speciale ale unei clase care sunt apelate, aşa cum sugereazăşi numele lor, la crearea respectiv distrugerea unui obiect. Rolul constructorilor într-un program este de a iniţializa proprietăţile unui obiect, sau pentru a efectua proceduri de pornire, cum ar fi de exemplu, conectarea la o bază de date sau deschiderea unui fişier de la distanţă.Conceptul de constructor nu este nou introdus de PHP5 acest concept exista şi în PHP4.În PHP 4 constructorul era considerat o metoda ce avea acelaşi nume cu cel al clasei. În PHP5 pentru a defini constructorul s-a introdus metoda specială: __construct(), pentru toate clasele indiferent de numele lor.[Converse_Park_Morgan_2005][Greenspan_Bulger2001]class expclasa

function __construct($parametru)

echo “Constructorul apelat cu parametrul $parametru”;

1.7.2. Destructorul

În PHP5 perechea metodei__construct() este metoda __destruct(). Constructorul este apelat pt crearea unui obiect înaintea destructorului. La terminarea unui program este bine ca toate obiectele create în interiorul acestuia să se distrugă apelând destructorul. Această operaţie este

Page 297: licenta hatz

similară cu deconectarea de la o bază de date sau ştergerea fişierelor temporare.[Converse_Park_Morgan_2005]

Page 298: licenta hatz

Distrugerea unui obiect este indicat să se efectueze în momentul în care toate apelurile la obiectul respectiv sunt şterse. PHP oferă posibilitatea deştergere a unei variabile care referă un obiect fie prin apelarea funcţiei unset()fie prin rescrierea valorii acesteia, în aceste cazuri obiectul nu se distruge imediat.

1.7.3. Vizibilitate

Unui obiect pe lângă metode şi proprietăţi i se mai adaugă noţiunea de vizibilitate.Vizibilitatea permite să se precizeze domeniul de aplicare de unde fiecare componenta a clasei poate fi instanţată. Domeniile de vizibilitate în PHP sunt:[Converse_Park_Morgan_2005][Greenspan_Bulger2001]

r Protected:-resursele se pot accesa din interiorul clasei sau a descendenţilor săi acolo unde sunt definiţi

s Private:-resursele pot fi accesate doar din interiorul clasei unde s-au definit.t Final:resursele pot fi accesate din orice clasă dar nu pot fi rescrise în clasele descendente.u Public:resursele pot fi accesate din orice clasă.

Observaţie:1. Nivel de vizibilitate final se aplică numai la metode şi clase. Clase care sunt declarate ca fiind final nu poate fi extended.

← Nivelul de vizibiltate public se foloseşte pentru constructori şi destructori

8. 7.4. Constante, metode si proprietati statice

PHP 5 permite implementarea demetode şi proprietăţi statice. Aces tip de metode şiproprietăţi spre deosebire de toate celălate tipuri de metodele şi proprietăţilei există şi sunt accesibile ca parte dintr-o clasă în sine, si sunt vizibile numai în cadrul domeniului de aplicare al unuia dintre instanţele sale.Acest lucru permit tratarea claselor ca adevarate containere de funcţii interdependente,în scopul de a evita conflictele de denumire.În timp ce PHP 4 a permis să se apeleze orice metodă a unei clase static folosind operatorul de rezoluţie ::în domeniul de aplicare, PHP 5 introduce o sintaxă mai stricta care solicită utilizarea cuvântului cheie static pentru a permite utilizarea de proprietăţi şi metode în acest mod.[Converse_Park_Morgan_2005][Greenspan_Bulger2001]

Moştenirea[WellingThomson2005]constăîn faptul că se pot declara anumite clase ca fiind derivate din alte clase de bază. În cele mai multe situaţii clasa derivată (numităşi clasă copil) extinde, primeşte funcţionalităţile clasei de bază (numităşi clasă parinte). În acest fel se reduce foarte mult cantitatea de cod necesară. În PHP se acceptă doar moştenirea simplă, fiecare copil poate moşteni de la un singur părinte. Nu există restricţii la numărul de copii care pot moşteni de la un singur părinte.[Greenspan_Bulger2001]

1.7.5. Interfeţe şi clase abstracte

PHP5 introduce conceptele de interfeţe şi clase abstracte. Ambele conceptesunt utilizate pentru a crea o serie de constrângeri cu privire la proiectarea de bază a unui grup de clase. O clasa abstractă defineşte scheletul de bază, în esenţă, de un anumit tip de entitate-capsulate de exemplu, aveţi posibilitatea să utilizaţi o clasă abstractă pentru a defini conceptul de bază al unei "maşini", ca având două uşi, un sistem de blocare şi o metodă care blochează sau deblochează

Page 299: licenta hatz

uşile . Clase abstracte nu pot fi folosite în mod direct, dar acestea trebuie să fie extinse, astfel încât clasa descendent oferă o gamă completă de metode. Alte astfel de exemplu ar fi să se definească o clasa “Pagina” având ca rol principal limitarea de cod HTML necesar creării unei pagini noi.Pagina este creată de o clasă ceea ce ar trebui să restrangă libertatea de creare a ei şi permite adaugarea de funcţionalităţi noi in timp scurt.Avantajele unei astfel de abordări în dezvoltarea unui site sunt:[WellingThomson2005][Converse_Park_Morgan_2005][Greenspan_Bulger2001]

Modificarea elementelor paginii unui site se face într-un singur loc(se adaugă un buton) Identificarea paginii care este vizualizată; Conţinut prestabilit dar care se poate modifica de exemplu: titlul, metaetichetele Înlocuirea elementelor standard (butoanele standard cu alte butoane)Elemetele care au o probabilitate mare de modificare se declară ca atribute ale clasei: de

exemplu: conţinutul, titlul, cuvintele cheie şi butoanele unei pagini.Operaţiile în cadrul unei astfel de clase sunt afişarea şi formatarea conţinutului în pagină.

Interfeţele sunt folosite pentru a specifica un API. De exemplu, se pot utiliza interfeţe pentru a abstractiza conceptul de furnizor al bazei de date printr-un API comun care ar putea fi apoi pus în aplicare printr-o serie de clase ca interfaţă pentru DBMS-uri diferite.

În PHP există diferite API cu ajutorul cărora se acceseazăMySql:[WellingThomson2005][Converse_Park_Morgan_2005]

[Greenspan_Bulger2001] 1.mysql- este un API istoric folosit până la versiunea 4 a lui PHP2.mysqli- este versiunea orientată obiect a lui mysql3.PDO_MySQL– este PDO pentru mysql, rolul său este de a asigura o interfaţă comună pentru a accesa orice tip de bază de date, fără a se schimba codul sursă, este de asemenea orientat obiect.PDO furnizează metode pentru prepared statements şi lucrează cu obiecte.Deci, PDO este un layer de acces la baze de date care furnizează metode de a accesa multiple tipuri de baze de date, nu ţine cont de sintaxele specifice ale diferitelor baze de date,permite să comute între diverse tipuri de baze de date prin realizarea unei conexiuni la acestea. Driverele pe care le suportă sunt:[WellingThomson2005][Converse_Park_Morgan_2005][Greenspan_Bulger2001][site100]

5. PDO_DBLIB ( FreeTDS / Microsoft SQL Server / Sybase )6. PDO_FIREBIRD ( Firebird/Interbase 6 )7. PDO_IBM ( IBM DB2 )8. PDO_INFORMIX ( IBM Informix Dynamic Server )9. PDO_MYSQL ( MySQL 3.x/4.x/5.x )10. PDO_OCI ( Oracle Call Interface )11. PDO_ODBC ( ODBC v3 (IBM DB2, unixODBC and win32 ODBC) )12. PDO_PGSQL ( PostgreSQL )13. PDO_SQLITE ( SQLite 3 and SQLite 2 )14. PDO_4D ( 4D )

1.7.6. Exemplu de utilizare

Page 300: licenta hatz

Clasele care se pot folosi in dezvoltarea WEB pot cuprinde pagini, componente de interfețe utilizator, liste de cumpărături, categorii de produse sau clienți, tratare de erori. Obiectele sunt instanțe ale acestor clase. Un exemplu de utilizare a claselor și a avantajelor moștenirii:

Page 301: licenta hatz

Se crează o clasă Pagina având ca rol principal limitarea de cod HTML necesar creării unei pagini noi. Pagina este creată de o clasa. Această abordare ar trebui să restrângă libertatea de creare a ei și să permită adăugarea de functionalitați noi în timp scurt.Avantaje:

31. Modificarea elementelor paginii unui site se face intr-un sg loc(se adauga un buton)32. Identificarea paginii care este vizualizata;33. Continut prestabilit dar care se poate modifica ca ex: titlul, metaetichetele34. Inlocuirea elementelor standard (butoanele standard cu alte butoane)

Elemetele care au o probabilitate mare de modificare se declară ca atribute ale clasei, de exemplu: conținutul, titlul, cuvintele cheie și butoanele unei pagini. Operațiile care pot apărea sunt cele de afișare și formatare a conținutului în pagină. Implementarea se va face într-un fișier cu extensia “inc”. În cazul de față vom crea un fișier numit clasap.inc care se va introduce în toate fișierele php care alcătuiesc site-ul. [WellingThomson2005]<?php class Pagina// continutul paginii HTML+text se numeste

var $continutpagina;//definirea unui titlu predefinit pt o

pagina var $titlu="Magazinul YYY";//metaetichete

var $keywords="search engines"; //butoane minime pe o pagina

var $buton=array("Home"=>"home.php", "Contact"=>"contact.php", "Harta site"=>"harta.php", "help"=>"help.php");// functie de afisare a unei

clase public function Display() echo "<html>\n<head>\n"; $this->DisplayTitle(); $this->Displaykeywords(); $this->DisplayStyles();echo "</head>\n<body>\n"; $this->DisplayHeader(); $this->DisplayMenu($this->buton); echo $this->continutpagina; $this->DisplayFooter();echo "</body>\n</html>\n"; public function DisplayTitle() echo "<title>".$this->titlu."</title>"; public function DisplayKeywords()echo "<meta name=\"keywords\" content=\"".htmlentities($this->keywords)."\"/>"; public function DisplayStyles() ?><style><!--h1 color:white;font-size:24pt;text-align:center; font-family:arial,sans-serif.menu color:white;font-size:12pt;text-align:center; font-family:arial,sans-serif; font-

weight:boldtdbackground:blue

Page 302: licenta hatz
Page 303: licenta hatz

pcolor:blue;font-size:12pt;text-align:justify; font-family:arial,sans-serif p.footcolor:white;font-size:9pt;text-align:center; font-family:arial,sans-serif;font-weight:bold a:link,a:visited,a:activecolor:white--></style><?phppublic function DisplayHeader()?><table width="100% cellpadding="12" cellspacing="0" border="0"> <tr bgcolor="blue"> <td align="left"><img src="a.gif"/></td> <td> <h1>Magazin Virtual</h1> </td>

<td align="left"><img src="a.gif"/></td></tr></table> <?phppublic function DisplayMenu($buton) echo "<table width='100%' bgcolor='white' cellpadding='4' cellspacing='4' border='0'>";

echo "<tr>\n";//dimensiunea butonului $width=50/count($buton); foreach($buton as $nume=>$url)

$this->DisplayButon($width,$nume,$url, !$this->IsURLCurrentPage($url)); echo "</tr>\n";echo "</table>\n";

public function IsURLCurrentPage($url) if(strpos($_SERVER["PHP_SELF"],$url)==false)

return false; else return true;public function DisplayButon($width,$nume,$url, $active=false) if ($active) echo "<td width='".htmlentities($width)."%'><a href='".htmlentities($url)."'><img src='logo.gif' alt='".htmlentities($nume)."' border='0'/></a>

<a href='".htmlentities($url)."'><span class='menu'>$nume</span></a></td>"; elseecho "<td width='".htmlentities($width)."%'><img src='logo2.gif'><span class='menu'>$nume</span></a></td>"; public function DisplayFooter()?>

<table width="100%" bgcolor="blue" cellpadding="12" border="0"><tr> <td> <p class="foot">&copy; Gigel</p><p class="foot"><a href="legea.php">Legea dreptului de

autor</a></p></td></tr></table> <?php?>

Instanțierea clasei pentru crearea paginii de exemplu home.php se face:

<?phprequire('clasapagina.inc'); $paginastart=new Pagina();$paginastart->continutpagina='<p>Bine ati venit</p>'; $paginastart->Display();?>

Page 304: licenta hatz

2Proiectarea sistemelor informatice

Page 305: licenta hatz

1. PROIECTAREA SISTEMELORINFORMATICE

Autor: Mircea Moca

15 Introducere în analiza și proiectarea sistemelor informatice

Expunerea de față legată de Proiectarea sistemelor informatice reprezintă un set de cunoștințe esențiale pentru absolventul specializării de Informatică Economică pentru a putea analiza sisteme noi sau existente și a concepe mecanismele sale de funcționare. Nu ne vom concentra în discuția noastră pe un anumit tip de sistem informatic, însă vom trata din punctul de vedere al aplicațiilor în general. Înainte de a discuta noțiuni legate de faza de proiectare a sistemelor informatice vom prezenta mai întâi analiza acestora, ca fază premergătoare.

În primul rând, sistemul este un ansamblu de elemente, care interrelaționează în interior și cu mediul înconjurător și care acționează în comun sub un aspect unitar pentru aîndeplini obiective bine definite. Orice sistem are un comportament specific, determinat de natura elementelor din care este compus și de relațiile dintre acestea.

O restrângere a sistemului este sistemul informațional, acesta fiind ansamblul elementelor de structură organizatorică din secțiunea societăţii umane (precum o organizație), împreună cu legăturile funcțional-informaționale dintre ele și cu contextul în care se află, care acționează în comun pentru îndeplinirea obiectivelor propuse. Rolul sistemului informațional este de a obține, stoca, prelucra și livra informații factorilor de decizie din organizație.

În continuare putem identifica sistemul informatic, care reprezintă partea automatizată a sistemului informațional (cu toate componentele sale de tip hardware, software) responsabilă cu stocarea și prelucrarea informațiilor utile factorilor de decizie.

Continuarea acestui capitol este organizată astfel: în subcapitolul 10.2 prezentăm elemente de analiză software, în subcapitolul 10.3 discutăm modele uzuale de dezvoltare software, în subcapitolele 10.4-5 vom prezenta proiectarea efectivă, iar în subcapitolul 10.6 vom discuta riscuri pentru proiectul informatic și noțiuni generale de management ale ciclului de viață al produsului software.

1.2 Elemente de analiză software

Pentru realizarea unui produs software este necesară parcurgerea mai multor etape. Acestea formează ciclul de viață al produsului. În prima fază, analiza software, analiștii descriu spațiul problemei și elaborează un set de cerințe care descriu ce se dorește de la noul sistem informatic. În continuare urmează proiectarea, fază în care proiectanții hotărăsc modul de realizare a cerințelor primite din faza anterioară, stabilind tehnologiile ce urmează a fi folosite la nivelul sistemului informatic creat. A treia fază a ciclului de dezvoltare este implementarea, care constă în transpunerea în cod a algoritmilor, a logicii stabilite în faza de

Page 306: licenta hatz

Proiectarea sistemelor informatice 3

proiectare. Realizarea efectivă a produsului informatic se încheie cu testarea sistemului informatic.

Ulterior fazelor prezentate, în urma cărora am obținut un produs informatic, pot fi discutate fazele de instalare și configurare (în engleză deployment) a sistemului informatic (la beneficiar) și întreținerea acestuia. Întreținerea unui sistem informatic reprezintă acțiunile de modificare a unui sistem informatic existent în vederea creșterii performanței acestuia, îmbunătățirii funcționale sau reparării unor disfuncționalități.

Ultimele două faze au și ele o importanță semnificativă, întrucât pot influența dezvoltarea următoarelor versiuni ale produsului informatic și reprezintă confirmarea corectitudinii cu care au fost parcurse primele patru etape. Diverse moduri de parcurgere a acestor faze în dorința de a elabora un sistem informatic vor fi discutate în capitolul 10.3 ca modele de dezvoltare software.

Analiza software reprezintă așadar faza inițială a ciclului de dezvoltare al produsului. Scopul analizei este de a produce un document numit raport de analiză și care să conțină specificații complete cu privire la sistemul informatic dorit. Natura informațiilor este de natura ce trebuie să ofere viitorul sistem utilizatorilor săi și ignorând complet cum le va oferi acesta. Această preocupare este specifică proiectării sistemului.

Raportul de analiză are în general o structură similară cu cea discutată mai jos, și ne ajută mult în înțelegerea înșiruirii etapelor analizei și a conținutului lor:

1. IntroducereÎn introducere se prezintă scurt proiectul pentru care este realizată analiza,

amploarea sa și informații despre grupul țintă/ beneficiarul produsului informatic construit. Cel mai ușor este să scriem această parte la sfârșit, când avem deja o imagine de ansamblu asupra proiectului completă și corect formată.

2. Analiza problemei2.1 ContextAceastă secțiune cuprinde descrierea contextului în care va funcționa sistemul

informatic. Se prezintă informații utile legate de organizația care va utiliza sistemul, incluzând: activitățile principale și sectorul de activitate, mărimea și structura organizației, aspecte motivaționale de business (și nu numai) pe care le are organizația (de exemplu: compania deține o rețea de 10 magazine pe teritoriul țării și în 5 ani își propune deschiderea a încă 10 magazine pentru a-și mări rețeaua de distribuție). Afirmațiile de acest gen vor fi corelate cu modelul de business și scopuri, descrise în secțiunile următoare.

2.2 MotivațieAici se descrie motivația care stă la baza creării sistemului informatic în cadrul

organizației. De ce este acesta necesar? Cum poate ajuta sistemul informatic în cadrul organizației? (Exemple de răspunsuri, desigur care necesită explicații detaliate pot fi creșterea eficienței procesului, reducerea duratei de timp pentru activități, creșterea numărului de clienți etc.). Pentru reprezentarea grafică a ansamblului de motivații se folosește diagramaFish-bone.

Deasemenea este prezentată ierarhia motivelor pentru care se recurge la dezvoltarea sistemului informatic pentru organizația beneficiară și schema de descompunere a obiectivelor (generale-specifice) avute în vedere de organizație.

2.3 Delimitarea sistemului de contextul săuÎn această secțiune se prezintă explicit aspectele care aparțin sistemului (procese,

organizații, sisteme tehnice/nontehnice existente etc.), și totodată aspectele exterioare(persoane, bunuri materiale/imateriale) graniței sistemului, dar cu care sistemul

Page 307: licenta hatz

4Proiectarea sistemelor informatice

Page 308: licenta hatz

interacționează. Aici se prezintă și toate părțile afectate semnificativ de sistem (în engleză - stakeholders).

2.4 Activități și proceseÎn această secțiune se prezintă activitățile principale ale organizației, furnizând

detalii legate de cine, când și ce documente produce sau modifică în cadrul organizației. Pentru fiecare document care este important pentru proces, se inventariază câmpurile sale. Pentru această etapă se prezintă diagrame de flux (flow-charts) pentru fiecare proces. Unele procese pot fi în continuare detaliate în subprocese. Deasemenea, unde este cazul, se folosesc diagrame de activitate.

3. Cerințe3.1 Elicitația (extragerea) cerințelor3.1.1 Surse de cerințeÎn această secțiune se prezintă sursele de cerințe identificate, sunt descrise și se

justifică de ce au fost acestea alese. Se specifică totodată implicația diverselor părți în stabilirea cerințelor.

3.1.2 Procesul de elicitație a cerințelorÎn această secțiune se descriu părțile implicate (stakeholders) și se explică cum îi

va afecta viitorul sistem, discutând în termeni de beneficii, dezavantaje, riscuri.În continuare se descriu metodele de elicitație și particularități ale aplicării lor în

cadrul organizației. Amintim aici metodele: model de business, cazuri de utilizare și metoda interviului.

În cazul metodei cazurilor de utilizare, se realizează următoarele acțiuni:16: Se prezintă lista tuturor actorilor, cu o scurtă descriere pentru fiecare și asocierile

acestuia17: Se prezintă cazurile de utilizare pe tipologii, specificând cine și în ce condiții inițiază

cazul de utilizare și care este înșiruirea de acțiuni realizate în cazul de utilizare.18: Se prezintă cazurile de utilizare la nivel general, prezentând delimitarea sistemului

de contextul său.

Cazurile de utilizare sunt acompaniate de diagrame de cazuri de utilizare folosind UML. Unde este necesar, cazurile de utilizare pot fi însoțite de descrieri sumare ale interfeței grafice pentru o anumită funcționalitate formulată.

Pentru metoda interviului se prezintă lista întrebărilor adresate și răspunsurile relevante obținute, după care lista cerințelor extrase din răspunsuri.

4. Cerințe softwareÎn această secțiune sunt traduse informațiile obținute în faza anterioară aplicând

metode de elicitație în trăsături de sistem, cerințe funcționale, cerințe non-funcționale și constrângeri (limitări), totul într-o manieră organizată. Spre exemplu, această organizare presupune codificarea cerințelor pentru un control precis al acestora și prioritizarea lor.

GlosarGlosarul este o secțiune foarte importantă a raportului de analiză, aici fiind

prezentate definiții, explicații, descrieri detaliate ale conceptelor importante din cadrul organizației și a sistemului analizat. Conceptele sunt prezentate sub formă de listă ordonată alfabetic. În glosar pot fi folosite și scheme sau diagrame pentru o cât mai clară explicare a termenilor. Totodată, pot fi descrise relații între concepte. Se recomandă ca realizarea glosarului să înceapă odată cu realizarea analizei proiectului.

Page 309: licenta hatz

Proiectarea sistemelor informatice 5

1.3 Modele de dezvoltare software

De-a lungul timpului, în practica dezvoltării sistemelor informatice, în funcție de tipurile de abordare pe care le-au avut specialiștii în timpul dezvoltării au apărut mai multe modele de dezvoltare software. Pentru a discuta modelele de dezvoltare software vom defini mai întâi ciclul de viață al produsului software.

Așadar, ciclul de viață al unui produs software este o structură care este urmată în vederea realizării unui produs informatic. Această structură cuprinde etape în care sunt realizate acțiuni specifice.

În această expunere vom discuta câteva dintre modelele cunoscute de dezvoltare existente: modelul cascadă, modelul prototipului (prototipizării) și modelul spirală.

Modelul cascadă este alcătuit din următoarele faze:Analiza, sau specificarea cerințelorConcepția, sau designulImplementarea și integrarea componentelor software

Testarea Instalarea

Mentenanța (Întreținerea)

Modelul cascadă se caracterizează prin faptul că fiecare etapă este parcursă complet, după care se trece la următoarea etapă. În urma parcurgerii fiecărei etape pot apărea ajustări la rezultatul produs, însă cu toate acestea modelul nu încurajează revenirea la etape anterioare pentru modificarea rezultatelor. Acest model este aplicat în general pentru sisteme simple în care cerințele sunt bine cunoscute sau pot fi corect și complet stabilite în faza de analiză.

Modelul prototipului este folosit în general în situațiile când sistemul vizat este complex, cerințele sunt greu de identificat corect și în întregime în faza de analiză. Acest model este folosit pentru sisteme cu grad mare de noutate fie din punct de vedere al funcționalităților oferite, fie al tehnologiei adoptate. Acest model pornește cu stabilirea cerințelor inițiale, după care se realizează concepția și se implementează versiunea inițială de sistem. Sistemul este supus în continuare evaluărilor, și în urma acestora se revine asupra cerințelor. Acest ciclu se reia până când, la evaluare, se constată că sistemul îndeplinește performanța dorită. După acest prag, sistemul este trecut în faza de dezvoltare propriu-zisă (în scopul obținerii produsului software final) și testat. În final, există și faza de mentenanță.Modelul prototipului are o abordare de la simplu la complex, întrucât la fiecare iterație, versiune de prototip sunt adăugate funcționalități.

Modelul spirală reprezintă o combinație a elementelor folosite de modelele în cascadă și prototipului, însă în plus tratează riguros riscul la fiecare etapă. Acest model este utilizat în dezvoltarea sistemelor informatice mari, complexe, realizate cu costuri semnificative, de obicei soluții dedicate. În acest model se începe cu stabilirea obiectivelor pentru sistem, analiza cerințelor, identificând sursele de risc posibile. Pentru fiecare sursă de risc se realizează o analiză și se încearcă găsirea unei metode de minimizare, excludere a sa. În funcție de rezultatul analizei de risc se consultă clientul care poate alege între a opri proiectul sau a continua asumându-și riscurile identificate. În această fază se poate construi un prototip (care presupune costuri mai reduse) pentru a evalua riscul.

Page 310: licenta hatz

6Proiectarea sistemelor informatice

Page 311: licenta hatz

1.4 Proiectarea logică

Sistemele informatice sunt alcătuite din subsisteme, aplicații, unități funcționale, unități de prelucrare (proceduri). La orice nivel din această listă de componente ne-am afla, fiecare entitate necesită intrări, pe care le prelucrează, producând ieșiri. Așadar, există date de intrare, un mecanism de prelucrare a datelor de intrare (care poate fi un algoritm sau formulă) și există date de ieșire, care reprezintă rezultatul prelucrării datelor de intrare.

Relațiile dintre diversele componente ale unui sistem se bazează pe acest mecanism de intrări-prelucrări-ieșiri. Astfel, dacă o componentă A pentru a putea realiza funcționalitatea sa are nevoie de funcționalitatea componentei B, o va apela (executa, rula) pe aceasta din urmă cu anumite date de intrare și va aștepta de la aceasta un rezultat. Datele de intrare și ieșire reprezintă baza informațională, iar într-un sistem informatic aceasta poate fi asigurată de un sistem de gestiune a fișierelor sau a bazelor de date.

Proiectarea logică a unui sistem informatic reprezintă activitatea prin care se stabilesc intrările sistemului informatic, prelucrările pe care acesta le realizează și ieșirile acestuia, pentru toate nivelurile de granularitate specificate mai sus.

Așadar, la nivel de sistem informatic intrările reprezintă modificările din sistemul informațional care determină schimbări de valori în colecțiile de date. Aceste schimbări pot duce mai departe la modificarea altor valori, care constituie intrări pentru alte componente (proceduri). Există deci modificări care sunt cauzate în afara sistemului informatic, în acest caz fiind vorba de intrări pentru sistemul informatic și modificări produse în interiorul acestuia, fiind vorba de intrări la nivel intern pentru componente ale sistemului informatic.

Un fapt important pentru analiza logică cu privire la intrări și la baza informațională este evitarea redundanței. Astfel, trebuie să se asigure o singură sursă de date pentru aspectul din spațiul problemei pe care îl reprezintă. Spre exemplu, într-o bază de date nu vom proiecta pentru documente seria și numărul acestora în mai multe entități, din motive evidente.

În continuare, prelucrările sistemului informatic sunt realizate de către procedurile acestuia, însă trebuie să avem în vedere conceptul de agregare a funcționalităților care spre exemplu la nivel de sistem presupune agregarea funcționalităților subsistemelor. Prelucrările presupun operații pe baza intrărilor în scopul de a produce ieșiri, rezultate.

Componentele care alcătuiesc un sistem informatic sunt reprezentate grafic folosind diagramele de componente (în UML). Acestea permit redarea la diverse niveluri de granularitate agregarea funcționalităților prezentată anterior, dar și relații între componente. Reluând exemplul anterior, componenta B poate fi reprezentată ca fiind inclusă în componenta B.

Ieșirile sistemului informatic reprezintă rezultatele produse de acesta, care pot existaîn mai multe forme: rapoarte, liste, grafice, valori sintetice. Aceste date pot fi salvate în fișiere și pot reprezenta mai departe intrări pentru alte sisteme informatice (de analiză a datelor de exemplu). La un nivel mai detaliat de proiectare trebuiesc desigur specificate ieșirile la nivel de componente. Deasemenea, observăm că ieșirile unui sistem informatic pot fi utile direct utilizatorului uman sau altor sisteme informatice.

Page 312: licenta hatz

Proiectarea sistemelor informatice 7

Page 313: licenta hatz

1.5 Proiectarea tehnică

Ulterior proiectării logice în care proiectantul a stabilit funcționarea de ansamblu a sistemului, a identificat componentele acestuia și relațiile dintre ele la nivel funcțional, urmează proiectarea tehnică (sau fizică) a unui sistem informatic, fază în care sunt căutate soluții tehnice efective pentru a obține funcționalitățile cerute.

În această fază proiectantul poate căuta soluții pentru următoarele aspecte:structura fizică a programelor – algoritmii efectivi care prelucrează datele;

structura fizică a datelor, înțelegând că trebuiesc alese structuri (colecții) de date pe care componentele identificate să le folosească în procesare;înlănțuirea operațiilor – ordinea de inițializare a datelor (variabile, obiecte), apeluri de funcții, tipuri de memorie folosite (statică/dinamică), generarea și tratarea de evenimente;

tehnologii hardware folosite, limbaje de programare folosite;realizarea documentației cu specificații de execuție pentru toate aspectele stabilite, care este utilă mai departe programatorilor (cei care implementează sistemul informatic), testerilor și celor care vor întreține sistemul.

Sintetizând, proiectantul de sisteme informatice realizează următoarele activități:2.3.4 Proiectarea logică (sau conceptuală) a sistemului informatic;2.3.5 Proiectarea tehnică (sau fizică) a sistemului informatic;2.3.6 Proiectarea implementării sistemului informatic;2.3.7 Proiectarea testării sistemului informatic;2.3.8 Proiectarea întreținerii sistemului informatic.

11 Riscuri pentru proiectul informatic și noțiuni de management ale ciclului de viață ale produsului software.

Cu cât amploarea proiectului informatic dezvoltat este mai mare, cu atât este mai mare șansa de apariție a riscurilor. Riscurile amenință reușita proiectului și pot avea diverse surse și consecințe, dintre care enumerăm: întârzierea livrării către beneficiar a proiectului informatic, neplata execuției proiectului, identificarea greșită a părților afectate semnificativ de sistemul informatic, validarea necorespunzătoare a cerințelor de sistem. În continuare vom dezvolta sursele de risc pentru proiectele informatice.

Pentru a trata sursele posibile de risc ale unui proiect informatic, mai întâi acestea trebuiesc identificate. Identificarea din timp a acestora duce la o creștere a șansei de a le gestiona cu succes. Este recomandat ca practicianul care conduce proiecte informatice să realizeze pe parcursul experienței sale de muncă liste cu surse de riscuri pentru proiectul informatic. La fiecare proiect, sursele deja identificate anterior trebuiesc dezvoltate, detaliate dacă se manifestă din nou, și cele noi trebuiesc adăugate listelor existente. Motivațiaîntreținerii listelor de riscuri este evitarea acestora în continuarea proiectului actual și în proiectele viitoare.

Page 314: licenta hatz

8Proiectarea sistemelor informatice

Page 315: licenta hatz

În timp, aceste liste de riscuri au fost standardizate pentru a putea fi înțelese, utilizate și întreținute mai ușor de către managerii de proiect. Astfel, SEI (Software Engineering Institute) oferă un standard [SEI] pentru lista de riscuri. Abordarea standardului este gruparea pe tematici de riscuri. Vom prezenta în continuare un exemplu de listă de activități, prin realizarea cărora se elimină posibile surse de risc:

Părți afectate semnificativ de viitorul sistem informatic:10: Identificarea părților afectate semnificativ de viitorul sistem informatic. Dacă nu

am identificat părțile afectate de sistem, poate apărea de exemplu riscul de refuz al sistemului informatic din cauza neconcordanței cu necesitățile beneficiarului, sau includerea noilor funcționalități să întârzie livrarea finală a produsului sau să presupună costuri ridicate.

11: Identificarea persoanelor cu putere de decizie din părțile afectate semnificativ. Persoanele cu putere de decizie au o contribuție semnificativă în derularea proiectului (de exemplu pentru modificarea resurselor organizației – materiale/imateriale pentru corelarea cu viitorul sistem).

12: Întâlnirea în persoană a persoanelor afectate. Anumiți indivizi pot reprezenta risc dacă nu s-a discutat față în față cu ei – din motive de relații inter-umane, curtoazie, informare mai precisă asupra cerințelor de sistem. Metoda interviului pentru extragerea cerințelor spre exemplu este mai eficace când persoanele se întâlnesc fizic.

13: Obținerea de informații despre părțile afectate de sistem: preferințe, obișnuințe, antecedente etc. Necunoașterea unor aspecte ce țin de cultura, obiceiurile sau istoria organizației pot duce la folosirea parțială a potențialului organizației în utilizarea viitorului sistem informatic.

Frici, rețineri și dorințe:Dezvoltarea unui nou sistem informatic în cadrul unei organizații presupune un

grad de schimbare. Aceasta va impune mai devreme sau mai târziu pentru membrii ei cerința de adaptare, care poate prezenta riscuri pentru proiect.

3.15. Identificarea ideilor de care părțile afectate se tem în general în legătură cu proiectul informatic.

3.16. Identificarea posibilelor grupări în cadrul persoanelor afectate de sistem în funcție de temerile pe care le au.

3.17. Identificarea dorințelor părților implicate în legătură cu

proiectul. Produs informatic și cerințe de sistem:

3.18. Scopul, motivația proiectului trebuie să fie clare.3.19. Identificarea părților din proiect care pot sau nu să fie schimbate pe

parcursul execuției.

Procesul de business:3.20. Identificarea limitărilor (constrângerilor) legate de resurse: timp, bani,

personal disponibil. Personalul disponibil pe durata execuției proiectului trebuie analizat atât din perspectiva organizației care produce sistemul informatic cât și din cea a

Page 316: licenta hatz

Proiectarea sistemelor informatice 9

Page 317: licenta hatz

beneficiarului. Personalul beneficiarului este implicat în anumite faze ale ciclului deviață al sistemului.

4.8. Estimarea măsurii în care aceste limitări pot fi influențate.

Mecanisme de reacție și analiză:4.9. Asigurarea mecanismelor de reacție și analiză pe toată durata realizării proiectului. Lipsa acestora poate

duce la disfuncționalități și uneori la incapacitatea echipei de management de a reacționa în timp util pentru evitarea manifestării riscurilor. Aceste mecanisme sunt menite să ofere reacția părților afectate de proiect, vis-a-vis de execuția acestuia.

Lista prezentată mai sus poate fi dezvoltată în continuare cu aspecte generale privind riscuri de proiect informatic. Pentru fiecare proiect informatic însă există riscuri specifice, care sunt mai greu de identificat dacă experiența în situații cu spațiul problemei similare este redusă.

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 1

Page 318: licenta hatz

2Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

1. NOŢIUNI PRIVIND ARHITECTURA ŞI SECURITATEAREŢELELOR DE CALCULATOARE

Autor: Nicolae TomaiÎn abordarea problematicii reţelelor de calculatoare se foloseşte ierarhia bazată pe straturi (niveluri).

Principalele straturi în ierarhia TCP/IP(folosită în Internet) sunt: nivelul fizic, nivelul legătură de date cu cele două subnivele MAC şi LLC, nivelul reţea, nivelul transport şi nivelul aplicaţie. In continuare vom descrie principalele straturi şi funcţiile lor.

16 Nivelul legătură de date

1.1.1 Metode de acces la mediu

O problemă importantă în cazul reţelelor de calculatoare datorită existenţei mai multor echipamente conectate este cea a accesului la canalul de comunicaţie, mai ales în cazul reţelelor cu difuzare. Vom trece în revistă principalele metode de acces la mediu, precum şi standardele create pentru unele metode.

19: Tehnica CSMA/CD

Această tehnică rezultă din utilizarea tehnicii CSMA împreună cu tehnica "ascultă ce transmiţi" (figura 11.1.). Principiul de bază este că, după ce sursa transmite pachetul, aşteaptă un interval foarte scurt de timp (dependent de întârzierile de propagare şi de sistem) apoi îşi ascultă propria transmisie.

Dacă sursa, atunci când acţionează ca receptor al propriei transmisii, detectează o diferenţă între informaţia recepţionată faţă de cea transmisă, va deduce că s-a produs o coliziune pe canal, va trunchia pachetul în curs de transmisie şi va căuta să rezolve coliziunea, organizând după un algoritm specific retransmiterea ulterioară a acestuia.

Este uzual ca sursa de pachete care detectează prima coliziune să ia imediat decizia de difuzare pe canal a unui semnal de bruiaj specific de scurtă durată ( jamming ), În acest fel este asigurat consensul de coliziune între toate sursele de pe canal implicate în interfaţă.

Avantajul esenţial al acestei tehnici constă în faptul că ea permite detectarea promptă a unei coliziuni, adică imediat ce ea apare şi nu după un interval de timp, evitându-se transmiterea completă a pachetelor colizionate şi se reduc nu numai întârzierile din reţea datorate coliziunilor, dar şi canalul de difuzare devine disponibil mai repede.

Intervalul de timp în care se pot produce coliziuni după ce o staţie a început emisia este de 2τ, unde τ este întârzierea de propagare a semnalelor între cele mai îndepărtate staţii. Deci o staţie poate fi sigură că a ocupat linia, după ce areuşit să transmită o perioadă de lungime 2τ, fără să se producă coliziuni.

Page 319: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 3

Figura 11.1.Algoritmul metodei de transmisie CSMA/CD

Ea nu se poate aplica la reţelele radio, deoarece sunt întârzieri mari pe canal, dar se aplică la cele cu cablu deschis (Ethernet).

Tehnica de reluare a transmisiilor după coliziune foloseşte un algoritm numit backoff, care ia în considerare durata critică, care e definită ca fiind mai mare decât suma dintre timpul de propagare al semnalului dus - întors şi timpul de bruiaj.

Dacă două staţii vor sesiza simultan eliberarea mediului de comunicaţie, ambele vor încerca transmisia cadrului şi va apare o coliziune. După detectarea coliziunii fiecare dintre staţii va genera un bruiaj.

Algoritmul backoff este utilizat pentru calculul întârzierii locale înaintea retransmisiei unui pachet colizionat.După ce s-a produs coliziunea, obiectivul constă în obţinerea de perioade de întârziere care să permită replanificarea fiecărei surse de pachete în cuante discrete de timp. Apar două cerinţe contradictorii: pentru a se garanta utilizarea canalului cuanta de timp trebuie să fie suficient de scurtă, iar pe de altă parte pentru a se evita coliziunile aceasta trebuie să fie mai mare decât fereastra de coliziune. Din acest motiv cuantele de retransmisie sunt uzual fixate să fie puţin mai lungi decăt dublul întârzierii maxime de propagare capăt la capăt, specifică pentru canalul utilizat. Intârzierea de retransmisie este calculată ca produsul dintre un contor de retransmisie şi cuanta de retransmisie. Tipic o cuantă este definită ca fiind egală cu timpul de transmisie minim. De exemplu standardul IEEE 802.3(care va fi tratat mai târziu în acest capitol) CSMA/CD specifică o cuantă de 51,2 microsecunde pentru un mediu de 10Mbs. Dimensiunea minimă de pachet de 512 biţi a fost aleasă pentru a se asigura că timpul de transmisie este mai mare sau egal cu aceastuante timp. Pentru a minimiza probabilitate de coliziuni repetate asupra aceluiaşi pachet fiecare contor este selectat ca un num aleator dintr-un interval de retansmisie [0 , limită superioară]. Acest interval va fi dublat la fiecare coliziune succesivă extinzându-se astfel domeniul întârzierilor de retransmisie. Aceasă dublare face să scadă probabilitatea de coliziune

Staţiile implicate în coliziune vor încerca să retransmită cadrul după un timp de aşteptare de 0 sau 1 cuante de retransmisie( o tranşă de aşteptare este egală cu timpul de propagare prin mediu τ). Dacă o staţie alege cuanta 0 şi alta tranşa 1 atunci totul e în ordine şi vor transmite cadrele fără să mai apară coliziuni ( s-a presupus că în acest timp alte staţii nu au dorit să transmită). Daca aleg aceeaşi cuantă se produce din nou coliziune şi algoritmul va genera 4 cuante posibile. Probabilitatea de a alege transmisia în aceeaşi cuantă scade şi deci si probabilitatea de apariţie de coliziune. Mentionam faptul că la coliziunea i se alege dintr-un număr de cuante cuprins între 0 şi 2i-1 cu trunchiereala 210-1.

Page 320: licenta hatz

4Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

1.1.2 Variante ale standardului Ethernet

Standardul Ethernet curent, este utilizat pe peste 40% din LAN-urile din lume. Aceste reţele operează în mod curent la viteza de 10Mbps şi standardul este cunoscut ca IEEE 802.3. Avem variantele:

6 10Base-5

Operează pe cablu coaxial gros cu o lungime maximă de 500m. Această variantă se bazează pe specificaţia Ethernet dezvoltată de către DEC, Intel şi Xerox. Această specificaţie de mediu defineşte transmisii în banda de bază, utilizând cablu coaxial ce suportă viteze de transmisie de 10 Mb/s. Conexiunile care leagă calculatoarele la cablu sunt făcute în general folosind conectori 'vampir', la care este introdus un pin până în miezul cablului coaxial. Notaţia 10Base-5 înseamnă că funcţionează la 10 Mb/s, utilizează semnalizare în banda de bază şi poate suporta segmente de până la 500m. Se pot conecta până la 100 de noduri pe un segment de reţea.

4 10Base-2

Această variantă operează pe cablu subţire(Thin Ethernet), care este de fapt un cablu coaxial cu un diametru de 5mm şi impedanţa de 50 Ohmi. Se utilizează transmisia în banda de bază, cu aceeaşi viteză ca la specificaţia 10Base-5, 10 Mb/s, dar lungimea maximă a unui segment de cablu este de 200m şi pe un segment de cablu sunt suportate până la 30 de staţii. Prin utilizarea repetoarelor pot fi create lungimi mai mari de segmente. Conexiunile la cablu sunt făcute cu ajutorul unor conectori standard BNC pentru a forma joncţiuni în T şi nu se utilizează conectori-'vampir'. Acest tip de cablu este cu mult mai ieftin şi mai uşor de instalat, fiind foarte des folosit în practică, dar ca şi la varianta anterioară se pune problema detectării întreruperilor în cablu sau a conectorilor defecţi sau desprinşi.

12 Ethernet rapid (Fast Ethernet).

Datorită faptului că noile aplicaţii(mai ales cele multimedia) necesită o bandă de trecere mai mare şi un timp de răspuns cât mai mic, au apărut noi tehnologii pentru reţelele de mare viteză.

Ethernetul rapid este o extensie a standardului Ethernet curent. Tehnologia Ethernet rapid creşte rata de transmisie de la 10Mb/s la 100Mb/s. Există două standarde create şi anume IEEE 802.3u(100Base-T) şi IEEE 802.12(100Vg-AnyLAN), care au fost în competiţie, dar doar prima variantă este folosită actualmente.

14: 100Base-T

Acest standard a fost promovat de companiile 3Com, Intel şi Synoptics. El este de fapt o extensie a standardului original IEEE802.3. Lungimea cablului de transmisie este limitat la 250m, iar dacă se doreşte prelungirea lui, este necesară regenerarea semnalului. Standardul 100Base-T constă din următoarele specificaţii:

la nivelul fizic sunt trei tipuri de medii de transmisie: cablu torsadat neecranat, cablu torsadat ecranat şi cablu cu fibră optică;

la nivelul fizic există un subnivel numit MII(media independent interface), care defineşte interfaţa standard între subnivelul MAC al nivelului legătură de date şi oricare din mediile de transmisie definite mai sus pentru nivelul fizic;

subnivelul de acces la mediu(MAC-media acces control); este localizat deasupra subnivelului MII şi este bazat peprotocolul CSMA/CD, utilizat anterior pentru standardul Ethernet la viteza de 10Mb/s.

Deci, Ethernetul rapid păstrează toate vechile formate de pachete, interfeţe şi reguli procedurale, în schimb reduce durata de bit de la 100ns la 10 ns. De asemenea lungimea minimă a pachetului este de 512 biţi ca şi la Ethernetul clasic. Tehnic, ar fi fost posibil să se copieze 10Base-5 sau 10Base-2 şi să se detecteze coliziunile la timp, numai prin reducerea lungimii maxime a cablului de zece ori. Totuşi avantajele cablării 10Base-T au fost atât de mari încât Ethernetul rapid se bazează în întregime pe acest mod de cablare, folosindu-se concentratoare.

Odată cu creşterea traficului de reţea timpul de răspuns al LAN-urilor cu interfeţe de tip CSMA/CD devine nesatisfăcător. Prin creşterea dimensiunilor fişierelor din calculatoare, pe măsură ce tot mai multă lume utilizează multimedia, se crează probleme dificile pentru beneficiarii reţelelor 100Base-T.

Datorită simplităţii metodei de acces la mediu folosită de standardul IEEE802.3u, el a devenit atractiv pentru multe din companiile care utilizează Ethernetul tradiţional. Odată cu creşterea benzii de 10 ori, fereastra de coliziuni se reduce la o zecime.Tehnologia 100Base-T poate fi împărţită în două subcategorii:100Base-T4 şi 100Base-TX.

4.10. 100Base-T4

Implementarea nivelului fizic pentru 100Base-T4 este diferită în mod semnificativ de cea a nivelului fizic pentu 10Base-T. Această variantă utilizează 4 perechi de fire răsucite de categoriile 1,4 sau 5, tip UTP. Trei perechi

Page 321: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 5

de fire sunt folosite pentru transmisie şi recepţie, deci 100Base-T4 obţine viteza de 100Mb/s prin împărţirea fluxului de date în trei fluxuri de 33Mb/s, iar a patra pereche este folosită pentru ascultarea coliziunilor. Splitarea fluxului de date între fire ajută la asigurarea integrităţii semnalului după standardele FCC(Federal Comunications Commision ). Datorită faptului că această variantă splitează fluxul de date de-a lungul a trei perechi de fire, nu este posibilă transmisia full duplex.

4.1.11. 100Base-TX

Utilizează cablu format din două perechi de fire răsucite de categoria 5 (care este mai scump decât cablurile de categoria 3 şi 4) UTP(unshilded twisted pair) sau cablu format din două perechi de tipul STP(Shilded twisted pair). O pereche este folosită pentru transmisie şi una pentru recepţie. Categoria 5 de cablu (CAT5) creşte numărul de răsuciri a firelor pe unitatea de lungime, pentru a elimina interferenţa electromagnetică(EMI). Sistemul 100Base-TX foloseşte exact acelaşi protocol ca şi Ethernet-ul actual(nu splitează fluxul de date), suportând atât modul full-duplex cât şi cel semi-duplex.

4.3.7 100Base-FX

Foloseşte pentru transmisie două fire de fibră multimod (cablu optic), câte unul pentru fiecare direcţie, astfel încât transmisia este full duplex cu 100Mb/s în fiecare direcţie şi în plus distanţa dintre staţie şi concentrator poate fi până la 2000m.

4.3.12. Distribuitoare(HUB-uri)

Pe lângă plăcile de reţea(NIC-Network Interface Card sau NIU-Network Interface Unit), conectori şi cabluri de legătură avem şi elemente de distribuţie care se mai numesc şi HUB-uri. Hubul este cunoscut sub numele de repetor sau concentrator. Prima lui funcţiune este să primească şi să regenereze semnalele de la dispozitivele conectate. Toate repetoarele 10Base-T sunt considerate ca funcţionând la fel. Repetoarele pentru Ethernetul rapid sunt împărţite în două clase distincte: Clasa I şi Clasa II.

Comutatoare (switch-uri)

Datorită strangulării benzii de trecere de numai 100Mb/s(sau 10 Mbs la Ethernetul calsic), oferită de tehnologia Ethernet rapid şi din cauza necesarului tot mai mare de bandă de trecere cerut de noile aplicaţii multimedia s-a impus utilizarea comutatoarelor Ethernet. Se foloseşte configuraţia de tip stea ca şi la 100Base-T. Avantajul utilizării acestor comutatoare este că fiecare staţie obţine în întregime o bandă de 100Mb/s, fără a mai fi nevoie să o împartă cu alte staţii (fără a avea domeniu comun de coliziuni cu alte staţii). Acest lucru este realizat prin utilizarea unei magistrale de semnale extrem de rapide aflată în comutatorul Ethernet şi poate avea viteze de peste 2Gb/s. Comutatorul "învaţă" adresele MAC şi le stochează într-o tabelă de căutare internă. Între expeditorul şi destinatarul unui cadru este creată o cale comutată temporară, iar cadrul este trimis de-a lungul acestei căi temporare. În acest mod, zeci de staţii utilizând adaptoare Ethernet rapid pot comunica, fără a se mai produce coliziuni.

Intr-un concentrator comutat (comutator care funcţionează pentru Ethernet rapid, deci la 100Mb/s la fiecare port şi deci fiecare statie având propriul său domeniu de coliziuni), fiecare cadru sosit este memorat într-un modul de intrare. Deşi această conectare este cu mult mai scumpă decât cea în care se foloseşte un repetor, datorită faptului că un comutator este cu mult mai scump decât un repetor, totuşi faptul că toate staţiile pot transmite (şi primi) în acelaşi timp pachete, îmbunătăţind semnificativ banda totală a sistemului (de cele mai multe ori cu un ordin de mărime sau chiar mai mult), face acest mod de conectare cu mult mai atrăgător. Cadrele memorate sunt trecute printr-un fund de sertar de viteză mare de la placa sursă la placa destinaţie.

Page 322: licenta hatz

6Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.2.Topologie de conectare folosind Ethernet clasic şi Ethernet rapid

Deoarece cablurile pentru varianta 100Base-Fx sunt prea lungi pentru algoritmul Ethernet de coliziune obişnuit, ele trebuie conectate la concentratoare de tip comutatoare cu memorie tampon, astfel că fiecare este un domeniu de coliziune cu el însuşi.

Cerinţele pentru ambele tehnologii sunt:lungimea maximă a unui segment de cablu cu perechi torsadate (distanţa de la portul partajat a unui repetor la un PC, server sau comutator de LAN), să fie de 100m(aceeaşi ca şi la 10Base-T);diametrul maxim al domeniului de coliziuni(distanţa maximă dintre două staţii de capăt-end to end) să fie de 205m când se utilizează două repetoare de Clasă II şi 200m când se utilizează un repetor de Clasă I.

Intre oricare două Pc-uri sau alte staţii ale reţelei pot fi până la:trei segmente şi doua repetoare de Clasă II sau; două segmente şi un repetor de Clasă I.

Rezultă deci că lungimea maximă a unui segment poate fi de 100m, iar numarul de repetoare de maxim două.Pentru a se evita formarea unui domeniu comun de coliziuni, pentru un număr mare de staţii se pot folosi si comutatoare (care comută canalele şi nu le repetă) care permit formarea mai multor domenii de coliziuni(dar au un preţ ridicat).

Tehnologia Gigabit EthernetGigabit Ethernet este o extindere a standardelor Ethernet de 10 Mbps şi 100 Mbps, oferind o lărgime de bandă de date de 1000 Mbps, Gigabit Ethernet menţine o compatibilitate deplină cu uriaşa bază instalată a nodurilor Ethernet.

Standardul Gigabit Ethernet – IEEE 802.3zIn iulie 1999, după luni de studii iniţiale, grupul IEEE 802.3 a creat grupul operativ Gigabit Ethernet 802.3Z.

Obiectivele–cheie ale acestui grup operativ erau să dezvolte un standard Gigabit Ethernet care face următoarele:Permite operarea semi şi ful-duplex la viteze de 1000 Mbps. Foloseşte formatul cadrului Ethernet 802.3.Foloseşte metoda de acces CSMA/CD cu suport pentru un repetor pe domeniul de coliziune. Realizează o compatibilitate de adresare cu tehnologiile 10 BASE-T şi 100 BASE-T.

Se folosesc trei tipuri pentru liniile de legătură: o legătură prin fibră optică cu o lungime maximă de 550 m – multimod; o legătură prin fibră optică single-mod cu o lungime maximă de 3 km ( extinsă la 5 km) şi o legătură prin fibră de cupru cu o lungime maximă de 25 m. In prezent IEEE investighează tehnologia care ar susţine legătura la distanţe de cel puţin 100 m prin sârmă răsucită în pereche neprotejată (UTP) de categoria 5. În completare grupul operativ IEEE 802 a decis să includă o specificare pentru o interfaţă independentă numită Gigabit Media Independent Interface(GMII) .

1.2 Nivelul reţea

1.2.1 Funcţiile nivelului reţea

Asigură dirijarea pachetelor de date între nodurile sursă şi destinaţie, trecând prin noduri intermediare. Decizia este luată astfel încât să nu existe în acelaşi timp legături supraîncărcate şi legături neutilizate, evitându-se

Page 323: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 7

deci congestionarea reţelei. O altă funcţie importantă a nivelului reţea este de interconectare a reţelelor cu arhitecturi diferite.

In cazul reţelelor cu comutarea pachetelor, serviciile menţionate se bazează pe utilizarea circuitelor virtuale (comutate sau permanente). Un circuit virtual parcurge mai multe rutere (comutatoare) de pachete între doi utilizatorişi permite schimbul unor secvenţe de pachete de date simultan, în ambele sensuri. El păstrează ordinea pachetelor şi permite controlul fluxului datelor astfel încât comunicarea este posibilă şi între terminale sau calculatoare de viteze diferite. Spre deosebire de circuitele virtuale, circuitele comutate se stabilesc şi se desfiinţează în mod dinamic, la cererea utilizatorilor, la fel ca circuitele telefonice între abonaţi.

Dirijarea (rutarea)

Algoritmii de rutare, referiţi ca şi protocoale la nivel reţea, permit ghidarea pachetelor de date prin subsistemul de comunicaţii, de la sursă la destinaţie. In reţelele de tip datagramă, două pachete succesive ale aceluiaşi utilizator pot traversa diverse rute, pentru fiecare pachet individual fiind necesară o decizie de rutare. In reţelele cu circuite virtuale, decizia de rutare este luată la conectare.

Intr-o reţea, rutarea presupune o colecţie de algoritmi care lucrează mai mult sau mai puţin independent pentru schimbul de servicii şi informaţii [Ber92]. Complexitatea este determinată de mai mulţi factori. In primul rând, rutarea presupune coordonarea între nodurile unei subreţele, chiar dacă acestea nu sunt adiacente. In al doilea rând, sistemul de rutare trebuie să facă faţă la defectele legăturilor şi a nodurilor, cerând redirijarea traficului şi o actualizare a bazei de date a sistemului care conţine informaţii cu privire la legături şi noduri. In al treilea rând, pentru a asigura o performanţă ridicată, algoritmii de rutare trebuie să-şi modifice rutele, când anumite zone ale reţelei devin congestionate.

Principalele funcţiuni asigurate de algoritmii de rutare sunt selecţia rutelor pentru diferite perechi origine-destinaţie şi livrarea mesajelor la destinaţia lor corectă, odată ce rutele sunt selectate. A doua funcţiune este implementată utilizând o varietate de protocoale şi structuri de date (cunoscute ca şi tabele de rutare). In acest capitol ne vom concentra eforturile asupra primei funcţiuni(selectarea rutelor) şi a modului în care afectează ea performanţa.

1.2.2 Protocoalele de interconectare TCP/IP

Principalul serviciu al nivelului reţea este rutarea şi furnizarea de pachete de la un nod de reţea emiţător la un nod de reţea receptor [Tan 03]. Activităţile efectuate pentru furnizarea acestui serviciu sunt selectarea nodului ţintă, crearea antetului de cadru, copierea cadrului şi accesarea mediului utilizat. Deoarece funcţionalitatea nivelului reţea este prezentă în cele mai multe din stivele de protocoale reţea, e de aşteptat ca nivelele ce descriu caracteristicile de performanţă a nivelului reţea să fie valide pentru diverse tipuri de stive de protocoale.

Unul din cele mai importante tipuri de protocoale folosite pentru interconectare este seria de protocoaleTCP/IP. La începutul anilor 70 Agenţia de proiecte de cercetare avansată în apărare(DARPA) din departamentul apărării al SUA(DOD) a sprijinit dezvoltarea reţelei ARPANET. Ea includea atât instituţii militare cât şi universităţi şi centre de cercetare fiind folosită ca suport de comunicare. Prin anii 80 s-au dezvoltat seriile de protocoale TCP/IP pentru sistemul de operare UNIX, fiind lansat şi sistemul socluri, iar ARPANET s-a împărţit în două: reţeaua ARPANET pentru cercetare şi MILNET pentru scopuri militare. Seria de protocoale TCP/IP este publică şi poate fi implementată pe orice tip de calculator de la calculatoare personale la supercalculatoare şi se poate utiliza atât pentru reţele locale cât şi pentru reţele pe arii extinse. De asemenea, este utilizat atât de agenţii guvernamentale cât şi de multe reţele comerciale. Această serie s-a folosit la reţeaua ARPANET din care s-a născut o reţea mai mare care conectează mai multe reţele individuale şi care se numeşte INTERNET. Familia de protocoale TCP/IP cuprinde şi alte protocoale aşa cum se arată în Figura 11.3a. IP înseamnă Internet Protocol şi este echivalentul funcţional al nivelului reţea din ierarhia OSI( Figura 11.3b).

Page 324: licenta hatz

8Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.3. Relaţia între ierarhia OSI şi suita de protocoale TCP/IP

Funcţia primară constă în dirijarea pachetelor de date de la sursă la destinaţie. Nivelul inferior numit protocol de acces la reţea(NAP) este echivalent cu primele două nivele(fizic şi legătură de date) din ierarhia OSI. In legătură cu protocolul IP se află protocoalele de la nivelul superior TCP şi UDP care se situează la nivelul transport din ierarhia OSI. TCP înseamnă protocol de control al transmisiei şi este un protocol orientat pe conexiune; funcţia primară a acestui nivel este schimbul corect de pachete de date între nodurile reţelei adică corectarea erorilor şi secvenţierea transportului. Fluxul de octeţi poate fi în ambele sensuri deci full-duplex.

UDP este un protocol de tip datagramă care lucrează fără stabilire de conexiune, transmiţând date între două procese. Este un protocol mai puţin sigur, neexistând nici o garanţie că datagramele UDP vor ajunge la destinaţia dorită. ICMP este un protocol utilizat pentru tratarea erorilor şi a informaţiilor de control, între calculatoarele gazdă şi porţile de interconectare care sunt responsabile de transmiterea pachetelor de date de la calculatorul sursă la calculatorul destinaţie, cele două fiind situate în reţele total diferite. Mesajele ICMP sunt transmise utilizând pachete IP şi sunt generate şi procesate de softul de reţea şi nu de către aplicaţiile utilizator. ARP este un protocol de echivalare a adreselor, făcând o echivalare între o adresă Internet şi o adresă hard. Acest protocol, ca şi următorul (RARP), nu este utilizat în toate reţelele pentru că numai unele reţele au nevoie de el(de exemplu reţelele ETHERNET). RARP este un protocol care face legătura între o adresă hard şi o adresă Internet. EGP este un protocol folosit pentru legătura externă a porţilor de interconectare. IGP(RIP) este un protocol de rutare distribuit care este bazat pe algoritmul DVA (distance vector algorithm). OSPF este un protocol care foloseşte calea cea mai scurtă pentru transmiterea datelor şi este folosit de către varianta ISO a protocolului IP. Utilizarea protocoalelor TCP/IP în opoziţie cu nivelele OSI se datorează faptului că ele sunt larg răspândite, devenind un standard "de facto".

Celelalte protocoale indicate în figură la nivel aplicaţie sunt: Telnet-pentru legarea la calculatoare aflate la distantă, FTP-pentru transferul fişierelor, HTTP-protocol pentru documente Web, NNTP protocol pentru grupuri de discuţii, DNS-protocol pentru nume de domenii, SNMP-protocol pentru gestionarea reţelelor, SMTP-protocol pentru poşta electronică.

Alte protocoale sunt: Finger-protocol pentru vizualizarea utilizatorilor legaţi la un server, NFS-protocol pentru organizarea şi accesarea fişierelor în reţea, RSVP-protocol de rezervarea resurselor pentru aplicaţiile în timp real şi multimedia.

Structura Protocolului TCP/IP

Această structură diferă faţă de structura definită de modelul OSI. Figura 11.3b compară cele două arhitecturi între ele, indicând că deşi ambele standarde folosesc un model pe nivele în definirea funcţionalităţii mediilor reţea, limitele şi definirea exactă a nivelelor diferă. Mai mult, nivelul OSI a definit şi nivelele superioare ale modelului (Prezentare, Sesiune, Aplicaţie) (Figura 11.3.b)

Page 325: licenta hatz

Standardele DOD nu prezintă amănunţit nivelele superioare, dar definesc un set minimal de aplicaţii pentru reţea, care ar trebui să fie prezente într-un mediu reţea compatibil DOD. NAP conţine toate funcţionalităţile necesare

Page 326: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 9

trimiterii unui cadru IP de-a lungul unei reţele fizice la un nod reţea destinaţie. Nivelul NAP este aproximativ nivelelor OSI fizic, legătura de date şi o parte din nivelul reţea. Principala funcţie a nivelului NAP este de a ascunde nivelelor superioare toate detaliile de implementare reţea. Nivelul IP poate fi comparat cu nivelul reţea. Dirijarea, fragmentarea şi adresarea sunt sarcinile principale ale acestui nivel. UDP şi TCP au grijă de majoritatea funcţionalităţilor găsite în nivelele transport şi sesiune ale ierarhiei OSI .

10. Protocolul IP

A fost gândit de la bun început pentru a fi utilizat în sisteme interconectate de reţele de calculatoare care folosesc comutarea de pachete. IP, spre deosebire de X25 care e orientat pe conexiune, asigură transmiterea de pachete de la sursă la destinaţie, sursa şi destinaţia fiind calculatoare gazdă (host computer) identificate prin adrese de lungime fixă. IP asigură de asemenea fragmentarea pachetelor mai lungi decât dimensiunea maximă a unui cadru ce poate fi transmis într-un anumit tip de reţea. Nu trebuie uitat că sursa şi destinaţia se pot găsi în reţele diferite şi că un pachet poate străbate cîteva reţele pînă la destinaţie.

IP nu garantează ajungerea la destinaţie a pachetelor şi nu asigură secvenţierea blocurilor de date. Aceste servicii sunt realizate de protocolul situat la nivelul imediat următor (TCP).

Specificarea protocolului IP înseamnă definirea interfeţei cu nivelul imediat superior nivelului transport şi cu cel aflat sub el. Singura presupunere pe care o face IP în legătură cu protocolul legătură de date este că există o modalitate de transfer pachete de informaţie de la un nod la altul adiacent, în aceeaşi reţea.

Nu se face nici un fel de presupunere privind calitatea legăturii de date, tratarea şi corectarea erorilor fiind atribute ale nivelului transport.Transmiterea unui pachet între două aplicaţii ce rulează pe 2 calculatoare aflate în reţele distincte, între care există o poartă gateway se face astfel:

Aplicaţia ce doreşte transmiterea unui bloc de date face un apel către propriul modul Internet dându-i ca parametri adresa blocului în memorie şi adresa destinaţiei.Modulul IP pregăteşte un antet specific care va fi ataşat blocului de date formând astfel un pachet.Tot el găseşte adresa imediată de destinaţie, adică adresa porţii în cadrul reţelei sursă. Pachetul astfel pregătit este transmis interfeţei locale de reţea, care va adăuga la rândul său un antet specific şi îl va trimite porţii.Interfaţa locală de reţea din cadrul porţii va prelua cadrul, va detaşa antetul reţelei locale şi-l va transmite modulului Internet.

Modulul Internet din poartă va deduce din adresa destinaţiei finale, prezentă în antetul IP, următoarea adresăimediată (adresa finală). Printr-un mecanism similar pachetul va ajunge la modulul Internet din destinaţie. Modulul Internet va elimina antetul propriu, predând blocul de date aplicaţiei destinaţie, la cererea acesteia.

Nivelul IP vede reţeaua ca o colecţie de mai multe reţele fizice interconectate de către rutere IP, prin tradiţie, numite porţi IP. O poartă IP este definită aici ca un nod de reţea care conţine interfeţele la reţelele fizice pe care le conectează şi un nivel IP care primeşte pachetele de date şi le trimite mai departe reţelei fizice corecte. Nivelul IP într-un nod reţea transmite un pachet de date prin încapsularea lui într-un cadru IP şi cere unuia dintre nivelele NAP să transmită cadrul IP. Combinarea gazdelor IP şi a porţilor formează un nivel de reţea virtual care oferă ca şi serviciu principal transport a pachetelor de date între oricare două noduri reţea IP în reţeaua IP. Figura 11.4 arată o configuraţie tipică de reţea IP.

Patru reţele fizice sunt interconectate prin cinci porţi IP. În acest exemplu sunt arătate două aspecte importante ale reţelei IP. Se vede că pot exista mai multe căi între un nod de reţea IP emiţător şi un nod de reţea receptor. De asemenea, se poate remarca faptul că reţelele fizice pot fi realizate din medii diverse de transmisie şi astfel apare necesitatea conversiei semnalelor între aceste medii. Ambele aspecte sunt rezolvate de către nivele IP ale nodurilor reţea IP şi de către porţile IP. Aceasta se face transparent pentru utilizatorii de servicii IP.

Page 327: licenta hatz

10Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.4. Reţele interconectate

Se oferă nodurilor reţea un serviciu de transport al pachetelor de date de la nodul sursă la nodul destinaţie. Transportul este fără conexiune, aceasta însemnând că serviciul IP nu garantează sosirea la destinaţie a datelor, timpul de sosire precum şi ordinea de sosire. Pentru implementare, serviciile IP dirijează pachetele IP conţinând date de-a lungul unor medii diferite. Pachetele de date sunt fragmentate şi reasamblate când este necesar.

Adresarea IP

Fiecărui nod de reţea, într-o reţea IP, i se asignează o adresă IP unică. Când un nod IP este conectat la mai mult de o reţea fizică, nodul are o adresă IP, pentru fiecare conexiune la o altă reţea fizică. O adresă IP constă dintr-un număr pe 32 de biţi

Biţii din primul câmp indică dacă adresa face parte din clasele (Figura 11.5) A, B, C sau dacă este o adresă multicast. O clasă A de reţele poate conţine până la 224 gazde, o clasă de reţele B pînă la 216 gazde şi o clasă de reţeleC pînă la 28 gazde. Sunt posibile 228 adrese multicast.

Al doilea câmp(net_id) identifică reţeaua fizică la care este conectat nodul IP. Toate nodurile IP conectate la aceeaşi reţea fizică împart acelaşi net_id. Acest câmp este folosit pentru determinarea căii la un nod IP. Numărul posibil de adrese pentru diferite reţele al unei clase este determinat de numărul de biţi din net_id care este 7 pentru reţele de clasă A, 14 pentru reţele de clasă B şi 21 pentru reţele de clasa C.

Al treilea câmp (host_id) identifică un nod de reţea IP unic în cadrul reţelei IP date de către net_id. Numărul maxim de noduri IP într-o reţea IP a unei clase date este determinat de către numărul de biţi din host_id şi anume pentru o clasă A 24 de biţi, clasă B 16 biţi, clasă C 8 biţi.

Schema de adresare IP depinde de două reguli pentru asignarea de adrese IP nodurilor reţea. Nodurile de pe o reţea singulară ar trebui să aibă adrese IP cu net_id-uri egale. O reţea singulară în acest context este definită ca o combinaţie de noduri reţea care poate schimba articole de date cu ajutorul serviciilor de pe nivelele NAP.Calculatoarele dintr-o reţea singulară pot deci să schimbe pachete IP fără să treacă prin porţi IP. Aceasta plus convenţia ca fiecare adresă IP să fie unică, asigură că o adresă IP poate fi folosită pentru a dirija un cadru IP de-a lungul reţelei IP. Prin compararea net_id-urilor poate fi luată o decizie pentru a trimite un cadru IP unei porţi IP sau dacă ar trebui trimisă direct nodului IP destinaţie de-a lungul reţelei curente.

Page 328: licenta hatz

Figura 11.5. Clasele de adrese IP

Page 329: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 11

Forma multicast a unei reţele IP este folosită când o gazdă IP vrea să trimită articole de date unui grup de gazde destinaţie. În locul unei trimiteri explicite a articolului de date fiecăruia dintre gazde din grupul destinaţie utilizând schema de adresare, emiţătorul se bazează pe IP pentru a trimite un cadru IP tuturor gazdelor destinaţie. Această formă de adresare este o adăugare recentă la protocolul IP.

Următorul lucru care trebuie avut în vedere este problema adreselor. Adresele IP (Internet Protocol) sunt pe4 octeţi. Aceste adrese se scriu prin convenţie în ceea ce se numeşte "notaţia zecimală cu punct". În această formă fiecare octet este convertit într-un număr zecimal (0-255) iar ei sunt despărţiţi unul de altul printr-un punct. Prin convenţie fiecare maşină gazdă şi ruter au o adresă IP. În mod normal fiecare placă de reţea trebuie să aibă propria ei adresă de IP. Reţelele IP sunt secvenţe continue de adrese IP. Toate adresele din reţea au o parte numerică identică. Acea parte comună la toate adresele din reţeaua respectivă este numită partea de reţea (network portion) iar partea rămasă este numită parte gazdă (host portion). Numărul de biti care sunt împărţiţi de toate adresele din reţea sunt numiţi masca reţelei (netmask). Rolul maştii este de a determina care adrese aparţin reţelei pe care se aplică şi carenu. Astfel, spre exemplu avem:

Adresa calculatorului gazdă: 93.226.40.18Masca reţelei: 255.255.255.0Porţiunea reţelei: 93.226.40.Porţiunea gazdă: .23Adresa de reţea: 193.226.40.0Adresa de broadcast: 193.226.40.255.Adresa de broadcast este o adresă mai specială care este ascultată de toate calculatoarele din reţea. În

general acestă adresă este cea mai mare adresă din reţea. Important este ca toate calculatoarele să fie configurate pe aceeaşi adresă de broadcast

Protocolul IP foloseşte o schemă de adresare care face posibilă identificarea fiecărui calculator conectat la reţea prin intermediul unei adrese unice. Pe undeva, s-a încercat modelarea situaţiei existente în societatea umană, situaţie în care fiecare persoană de pe glob este identificată în mod unic printr-un buletin (carte) de identitate. In continuare vom încerca să vedem modul în care este rezolvată pe înternet problema adresei unice. De la început trebuie spus că adresa nu se referă neapărat la un calculator ci la o anumită conexiune pe Internet. Mai clar spus, fiecare placă de reţea ataşată la Internet trebuie să aibă o adresă unică. In realitate, un calculator poate conţine mai multe plăci de reţea. Aceasta înseamnă că un calculator conectat la Internet poate avea câteva adrese IP valide. O mare parte din literatura referitoare la reţeaua Internet discută despre adresele IP ca aparţinând calculatorului şi nu plăcii de reţea.

In continuare vom adopta aceeaşi metodă de referire. Ca şi programator de aplicaţii Internet trebuie înţeles foarte clar că o adresă identifică o conexiune şi nu calculatorul în sine.

Deci, practic, adresa unei conexiuni este reprezentată pe 32 biţi (sau 4 octeţi) conţinând suficiente informaţii pentru a identifica în mod unic o reţea şi o conexiune la o reţea. In cazul limbajului C, o adresă IP poate fi reprezentată prin intermediul unei date de tip long int. In general, pentru specificarea adreselor IP se foloseşte notaţia dotted-decimal. In cadrul acestei convenţii, adresele IP se reprezintă pintr-o serie de numere (în baza zece) separate prin puncte.

Este de la sine înţeles faptul că notaţia zecimală cu punct (dotted-decimal) vine în întâmpinarea înţelegerii cât mai simple a adresei de către cei care o citesc. Este mult mai greu să lucrăm cu reprezentarea adreselor în format binar sau hexa. Partea mai "complicată" apare în momentul în care se trece la decodificarea informaţiilor cuprinse în cadrul adresei.

Există câteva adrese cu destinaţie specială. Astfel, adresa de forma 127.0.0.1 desemnează o buclă locală ("loopback"). Aceasta nu corespunde unei interfeţe şi are rolul de a permite testarea sotware-ului de reţea. Adresa 255.255.255.255 este folosită ca adresă de broadcast locală, adică orice calculator dintr-o reţea locală recunoaşte pe lângă adresa sa proprie şi această adresă. O adresă de forma 176.58.255.255 înseamnă broadcast la toate calculatoarele din clasa 176.58.0.0, indiferent dacă acestea sunt direct legate cu calculatorul sursă sau nu (e de precizat că o reţea este desemnată de adresa care are toţi biţii corespunzători nodurilor puşi pe zero).

Mai nou a fost introdusă distincţia între adrese publice şi adrese private. Se numesc adrese publice cele care sunt obţinute de la autorităţile de alocare a adreselor şi sunt rutate pe Internet. Aceste adrese au caracter de unicitate, în sensul că nici o adresă nu este alocată multiplu. Datorită creşterii explozive a conectărilor la Internet a apărut preocuparea faţă de epuizarea adreselor pe 32 de biţi şi una din soluţiile adoptate pentru evitarea acestui fenomen a fost să se rezerve câteva adrese care să poată fi utilizate intern(privat) de orice organizaţie, fără a fi vizibile în afara organizaţiei(nu vor fi rutate în afara organizaţiei). Astfel de adrese private sunt:

10.0.0.0-10.255.255.255 -reţea de clasă A 172.16.0.0-172.16.255.255-reţea de clasă B 192.168.0.0.-192.168.255.255-bloc de reţele de clasă C

Page 330: licenta hatz

12Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Rămâne la latitudinea utilizatorului alegerea adreselor private pe care le foloseşte, dar aceasta trebuie făcută conform unor criterii de performanţă. Unul din criteriile de alegere este, evident, dimensiunea reţelei interne: dacă aceasta are doar câteva zeci de calculatoare nu se justifică alegerea adreselor private de clasă B sau A.

Datorită faptului că spaţiul de adresare folosind 32 de biţi devine insuficient, a apărut protocolul IP, varianta 6 care foloseşte 128(16 octeţi), deci spaţiul adreselor IP devine 2128, spaţiu care se consideră a fi suficient pentru necesarul actual şi viitor de adrese.

12. Structura pachetului IP

Principalul serviciu oferit de către nivelul IP este serviciul de transport al unui articol de dată de la un nod IP sursă la unul destinaţie. Pentru aceasta, articolul de dată este încapsulat într-un pachet IP. Un astfel de pachet poate fi definit ca o secvenţă de octeţi divizată în câmpuri. Unul dintre câmpuri conţine octeţii care formează articolul de date. Celelalte câmpuri sunt folosite de către nivelele IP uzitate pentru a transmite cadrul la destinaţia IP corectă şi pentru reconstruirea articolului de date. De asemenea, uneori e necesară fragmentarea unui pachet când acesta provine dintr-o reţea cu o dimensiune mare a cadrului de date. Un pachet poate fi marcat " a nu se fragmenta" şi el va fi îndrumat pe o cale ce evită fragmentarea, iar dacă nu se poate, va fi ignorat.

Fragmentarea trebuie să poată fi făcută într-un număr arbitrar de pachete şi trebuie prevăzută posibilitatea de reasamblare corectă,în secvenţă, la destinaţie. Acest lucru se obţine prin interpretarea câmpurilor de flag-uri şi offset din cadrul antetelor Internet ale fragmentelor.

Un pachet IP are structura indicată în Figura 11.6.

Figura 11.6. Pachetul IP

IP frame :=Ver (octet 1,bit 0:3)IHL (octet 1,bit 4:7)TOS (octet 2)Lenght (octet 3:4)Ident (octet 5:6)Flags (octet 7,bit 0:2)Foff (octet 7:8,bit 3:15)TTL (octet 9)Prot (octet 10)Chech (octet 11:12)Source (octet 13:16)Dest (octet 17:20)Option (octet 21:IHL.4)Data (octet IHL.4+1:...);

Câmpurile din cadrul IP au următoarea semnificaţie:

Page 331: licenta hatz

Ver: Versiunea, identificator de 4 biţi, conţinând versiunea protocolului IP al acestui cadru. Prin verificarea lui Ver-id, un nivel protocol nivel IP poate implementa mai multe versiuni ale protocolului IP. Versiunea curentă este

Page 332: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 13

4(IPv4). S-a propus pentru Internet un protocol îmbunătăţit căruia i s-a dat numele de IPv6(IP versiunea 5 era deja utilizat pentru un protocol pentru fluxuri în timp real). Adresele sursă şi destinaţie la acest nou protocol au lungimi de 16 octeţi, deci un spaţiu de adrese practic nelimitat. Pentru scrierea adreselor pe 16 octeţi se folosesc grupuri de câte patru cifre hexazecimale cu semnul: între grupuri.

IHL: câmp de 4 biţi care dă lungimea antetului din cuvintele de 32 de biţi. Acest câmp este cerut din cauza lungimii variabile a câmpului opţiune. Dacă nu este prezent nici un câmp opţiune, valoarea minimă a câmpului va fi5.

TOS: Tipul serviciului, câmp de 1 octet, specificând tipul de serviciu cerut de acest cadru. Biţii 0-2 specifică precedenţa cadrului care e de la 0 (normal) - 7 (control reţea).

Bit 3 - indică cerere pentru întârziere mică (D-delay) Bit 4 - indică cerere pentru debit mare (T-traffic)Bit 5 - indică cerere pentru siguranţă mare (R-reliability)Biţii D, T, R pot fi utilizaţi de către o poartă IP pentru a selecta o cale spre nodul destinaţie care satisface

serviciul cerut. Trebuie notat că în implementările curente câmpul T, S, O este ignorat de către porţile IP şi nodurile reţele.

Lenght: conţine lungimea totală a cadrului Ethernet, incluzând haderul şi data.Ident: câmpul ident împreună cu câmpurile adresa sursă şi destinaţie, identifică în mod unic datagrama în

timpul existenţei pachetului IP.Flags: câmpul flags conţine câmpurile More şi Fragment. Aceşti biţi indică dacă un mesaj este transmis

într-un singur pachet IP sau este fragmentat în mai multe pachete.Foff: câmpul fragment offset poziţionează octeţii din cadrul IP în articolul de date original.TTL: timpul de trăit dă timpul maxim de existenţă al cadrului IP. Acest câmp este utilizat pentru evitarea

buclelor infinite pentru pachetele IP. Fiecare ruter IP care gestionează un cadru descreşte adresarea cu 1 şi trimite cadrul când valoarea este 0.

Prot: câmpul protocol identifică protocolul datei conţinute în cadrul IP. Normal, acesta va fi TCP sau UDP.Chek: suma de control a antetului IP (excluzând câmpul de date).Source: adresa IP a nodului de reţea IP transmiţător. Destination: adresa IP a nodului de reţea IP destinaţie.Options: câmpul acesta de lungime variabilă poate conţine opţiuni IP.Data: câmpul data nu este o parte din antetul IP şi conţine articole de date de transmis. Datorită limitei

impare a câmpului Lenght, întregul cadru IP are o lungime maximă de 216. Aceasta limitează de asemenea şi lungimea câmpului de date.

Protocolul IPv6

Odată cu creşterea numărului de utilizatori , precum şi cu apariţia noilor aplicaţii multimedia forma curentă a protocolului IP(versiunea 4) nu mai poate satisface noile cerinţe. De asemenea odată cu creşterea numărului de echipamente portabile(calculatoare şi telefoane mobile), e necesar ca acestea să poată comunica fără restricţii, indiferent de aplicaţii. Totodată convergenţa industriilor comunicaţiilor, calculatoarelor şi a celor mas-media face stringentă schimbarea IP-ului actual. Obiectivele majore ale noii versiuni au fost:să suporte mai multe gazde;să reducă dimensiunea tabelelor de dirijare;

să simplifice protocolul, pentru a permite ruterelor procesarea mai rapidă a pachetelor; să asigure o securitate mai bună;să acorde o mai mare atenţie pentru datele aplicaţiilor în timp real; să ajute trimiterea multiplă prin permiterea specificării de domenii; să permită migrarea unei gazde fără schimbarea adresei sale;

să permită coexistenţa cu vechea variantă şi evoluţia în viitor.Ipv6 îndeplineşte în general aceste obiectivele, fiind totodată compatibil cu principalele protocoale din stiva de

protocoale TCP/IP. Caracteristica de bază a variantei Ipv6 constă în faptul că foloseşte pentru adresare 16 octeţi, furnizând adrese pentru dezvoltările Internetului. O altă îmbunătăţire a acestui protocol este simplificarea antetului, care conţine numai 7 câmpuri, ducând la îmbunătăţirea timpului de procesare a pachetelor în nodurile reţelei. O altă facilitate a lui Ipv6 este un suport mai bun pentru opţiuni, unele câmpuri obligatorii ale variantei Ipv4 au devenit opţionale. De asemenea Ipv6 permite o securitate sporită, autentificarea şi confidenţialitatea fiind trăsături importante

Page 333: licenta hatz

14Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

ale noului IP. Totodată Ipv6 acordă o atenţie mai mare tipului de serviciu, ştiindu-se faptul că în viitor va creşte traficul multimedia.

Ne vom concentra atenţia asupra capacităţilor de transmisie multicast ale noului protocol.In adresele de trimitere multiplă, după prefix(care e format din 8 biţi şi are toţi biţii 1 pentru adresa

multiplă), urmează un câmp indicator de 4 biţi şi un câmp domeniu de 4 biţi, apoi un identificator de grup de 112 biţi. Unul din biţii indicatori face distincţia dintre grupurile permanente şi cele temporare. In plus, Ipv6 suportă şi trimiterea către oricine (anycasting), în sensul că destinaţia este un grup de adrese , dar în loc să se încerce livrarea pachetului la toate adresele, se încearcă livrarea la una singură, de obicei cea mai apropiată. De exemplu un client care doreşte să contacteze un grup de servere de fişiere care cooperează poate folosi trimiterea către oricine pentru a ajunge la cel mai apropiat server fără să trebuiască să ştie care este acesta.

Ca şi varianta veche, acesta conţine în antet un câmp numit prioritate, care este folosit pentru a distinge pachetele ale căror surse pot fi controlate ca flux şi acelea care nu pot fi controlate. Dacă acest câmp are valorile 0-7, acestea sunt pentru trafic care poate fi încetinit în cazul evenimentelor de congestie, iar dacă are valori între 8 –15 , acestea sunt pentru trafic al aplicaţiilor în timp real, a cărui rată de transmisie este constantă(audio şi video).

1.2.3 Protocolul de control mesaje (ICMP)

Pe lângă pachetele IP care conţin articole de date ce sunt schimbate de nodurile IP, este nevoie să se schimbe pachete IP conţinând date de control. Aceste date sunt folosite pentru a asigura funcţionarea corectă a reţelei IP ca un întreg şi pentru a raporta orice erori. In stiva de protocoale IP, este inclus un protocol specializat în vârful stivei pentru a sprijini schimbul acestui tip de informaţie între nodurile IP. ICMP se cere a fi suportat de fiecare nod IP din reţea şi include următoarele servicii:

notificarea destinaţiei care nu poate fi atinsă, adică, atunci când un nod IP primeşte un pachet IP care nu poate fi trimis deoarece lipseşte informaţia de rutare sau datorită lipsei unor conexiuni reţea, nodul poate trimite un pachet ICMP nodului IP transmiţător informându-l despre imposibilitatea trimiterii pachetului pe care l-a primit.notificarea timpului depăşit, adică, atunci când un nod IP primeşte un cadru IP care se plimbă prin reţea de prea mult timp (TTL=0), poate descărca acest pachet şi trimite un mesaj ICMP gazdei origine.notificarea parametri ilegali, atunci când un nod IP detectează un pachet IP ilegal, poate trimite un mesaj ICMP gazdei IP origine.notificarea ştergerii sursei, dacă traficul IP într-un nod IP devine prea încărcat, nodul IP poate trimite un cadru "stingere sursă" altor noduri IP pentru a micşora încărcarea. Aceste mesaje sunt utilizate pentru a implementa o schemă de control a disputelor.notificarea redirectării, dacă un mod IP detectează că trebuie să dirijeze un cadru IP către nodul cu acelaşi "net-id" ca şi nodul Ip anterior din rută, informează nodul precedent că există o rută utilizând un mesaj ICMP.notificarea cerere - ecou şi răspuns. Pentru a fi capabil să verificăm dacă o rută în cadrul reţelei IP este disponibilă, este adesea folositor să fim capabili să trimitem un cadru IP unui nod IP arbitrar şi să primim un răspuns. ICMP furnizează un mecanism simplu de ecou întrebare/răspuns.notificarea cerere/răspuns marcă de timp. Pentru a determina întârzierea pe o cale din reţeaua IP, ICPM susţine cererea unei mărci de timp pentru un nod IP. Această marcă de timp poate fi utilizată pentru determinarea timpului necesar unui cadru IP de-a lungul unei căi reţea.

Deşi ICMP utilizează serviciile nivelului IP pentru a trimite mesaje ICMP, este adesea văzut ca parte a nivelelor IP. Serviciile ICMP-ului sunt utilizate de către nivelul IP pentru a menţine operarea corectă a reţelei IP.

1.2.4 Protocoalele ARP şi RARP

După cum am văzut, adresele Ethernet au şase octeţi. Toate datele transmise printr-o reţea cu tehnologie Ethernet trebuie să utilizeze cadre Ethernet. Plăcile de interfaţă nu deţin şi nici nu necesită informaţii despre adresele IP, care au 32 de biţi şi sunt utilizate pentru localizarea plăcii de interfaţă şi a calculatorului care o conţine. Cu alte cuvinte, protocoalele TCP/IP lucrează numai cu adrese IP şi cadrele Ethernet lucrează numai cu adrese Ethernet. Diversele tipuri de adrese reprezintă o problemă a comunicaţiei în reţea. Protocolul de rezoluţie adresă(ARP) şi Protocolul de rezoluţie adresă inversă (RARP) rezolvă această problemă prin conversia adreselor. Acestea transformă adresa IP într-o adresă a nivelului legătură de date şi invers.

Page 334: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 15

1.3 Nivelul transport

1.3.1 Introducere

Nivelul transport este un strat important având rolul de asigurare a unui transfer de date corect. El este asemănător cu nivelul reţea:are servicii orientate şi neorientate pe conexiune;

conexiunile au trei faze: stabilire, transfer de date şi desfiinţare; adresarea şi controlul fluxului se fac similar.

Deoarece nivelul reţea este puternic dependent de reţeaua de comunicaţii, performanţele şi caracteristicile sale fiind determinate de aceasta, iar utilizatorul nu poate interveni în subreţea pentru a-i mări performanţele sau schimba caracteristicile, atunci se poate adăuga subreţelei un nivel care să permită:un transfer sigur al datelor chiar cu o reţea nesigură;

interfaţă uniformă pentru utilizatori, adică un set standard de primitive de serviciu, independent de tipul reţelei utilizate.

Nivelele inferioare(1-3) alcătuiesc furnizorul de servicii al nivelului transport, ele având funcţii orientate spre comunicaţii, iar nivelele superioare sunt orientate spre organizarea dialogului dintre utilizatori.

Nivelul transport realizează o comunicare sigură între două calculatoare gazdă detectând şi corectând erorile pe care nu le tratează nivelul reţea. Dacă pentru nivelele 1,2,3 protocoalele se referă la legătura dintre terminal (calculatorul gazdă) şi subreţea sau între nodurile subreţelei constituind astfel două categorii distincte de protocoale şi anume: protocoale de interfaţare şi protocoale de comunicaţie, începând cu nivelul transport protocoalele sunt capăt-la-capăt, entităţile acestora neavând corespondente în subreţea. Acest nivel furnizează nivelelor superioare o interfaţă independentă de tipul reţelei utilizate.

In funcţie de caracteristicile traficului generat utilizatorii nivelului transport pot cere stabilirea unei conexiuni transport cu o anumită calitate a serviciului furnizat.

Calitatea serviciului transport este caracterizată prin următorii parametri:productivitatea (cantitatea de date transferată într-o unitate de timp )

întârzierea de stabilire a conexiunii; întârzierea de transmisie;

rata erorilor;întârzierea de desfiinţare a conexiunii;

probabilitatea de eşec la desfiinţare a conexiunii; nivelul de protecţie;

prioritatea, conform căreia unele conexiuni sunt servite înaintea altora;rezilierea, care dă posibilitatea ca nivelul transport să închidă o conexiune datorită unor probleme interne;erorile netratate;probabilitatea de eşec la tratarea erorilor;posibilitatea de transmitere expeditivă a datelor.

Calitatea serviciului se negociază la stabilirea conexiunii. Atingerea acestor performanţe depinde în mare măsură de tipul subreţelei utilizate, funcţie de care nivelul transport trebuie să realizeze un număr mai mare sau mai redus de funcţii. Astfel în cazul unor subreţele fără erori, nivelul transport nu trebuie să realizeze corecţii ale transmisiei în timp ce în cazul unor erori semnalate sau nesemnalate de reţea aceste corecţii sunt necesare. Este deci normal să existe mai multe clase de servicii de transport şi corespunzător mai multe clase de protocoale.

Una din funcţiile importante a nivelului transport este multiplexarea conexiunilor. Multiplexarea "în sus" constă în utilizarea unei conexiuni reţea ca suport al mai multor conexiuni de transport. In acest fel se utilizează mai eficient reţeaua în care traficul pe fiecare conexiune de transport este redus.

Multiplexarea "în jos" constă în utilizarea mai multor conexiuni de reţea pentru o singură conexiune de transport astfel încât se urmăreşte viteza de transmitere a datelor în cazul unui flux ridicat.

La fel de important este controlul fluxului datelor, aspect întâlnit şi la nivelul legăturii de date. Complexitatea acestuia, în contextul nivelului transport este determinată de numărul mult mai mare de conexiuni gestionate şi de intervalele de timp mult mai mari în care mesajele trebuie păstrate pentru eventuale retransmiteri.

Page 335: licenta hatz

16Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

O altă problemă se referă la lungimea unităţilor de date care se poate modifica prin blocare, adică se colectează mai multe mesaje într-o singură unitate de date de protocol sau segmentare adică împărţirea unui mesaj în mai multe unităţi de date de protocol.

Deşi nivelul transport asigură conexiuni utilizabile simultan în ambele sesiuni (duplex), multe aplicaţii necesită o coordonare a dialogului în care doar unul din interlocutori poate transmite la un moment dat.

1.3.2 Protocolul TCP (Transmission Control Protocol)

Multe aplicaţii care utilizează servicii pe reţea aşteaptă ca data să fie transmisă şi primită corect de-a lungul conexiunilor reţea. Corect, în acest context înseamnă că articolele de dată ar trebui remise fără erori şi în secvenţă aplicaţiei receptoare.

Aşa cum am văzut în secţiunea anterioară, remiterea corectă nu este asigurată de către UDP şi articolele de dată pot să sosească la aplicaţia destinaţie într-o ordine diferită decât cea în care au fost trimise. TCP este un nivel de protocol alternativ constând în vârful nivelului Ip care oferă remiterea corectă a articolelor de dată. Pentru a asigura remiterea corectă, TCP utilizează o schemă cu confirmări a pachetelor TCP corect primite şi retransmisia altora care nu au ajuns Pentru a furniza o remitere secvenţială a pachetelor (articolelor de dată), nivelul TCP are de asemenea o capacitate de stocare.

Pe lângă asigurarea unei remiteri corecte, nivelul TCP conţine mecanisme pentru evitarea congestionării reţelei şi a utilizării optime a capacităţii de reţea disponibilă.

10. Conexiuni TCP

Nivelul TCP este o alternativă la nivelul UDP, utilizând conceptul de conexiune pentru a lega transmiţători şi receptori ai serviciilor TCP. Când creăm o conexiune între doi utilizatori, nivelul TCP asigură un port TCP ambelor capete, fiecare identificate printr-un număr de port. Combinaţia de adrese IP şi de porturi TCP identifică din nou conexiunea TCP în mod unic. Utilizatorii de servicii la ambele capete de conexiuni primesc şi trimit articole de dată prin porturile TCP. Nivelul TCP nu structurează articolele de dată trimise de către utilizatorii de servicii. Un utilizator de servicii trimite articole de dată de-a lungul conexiunii care sunt văzute de către nivelul TCP ca un şir de octeţi.

Prin stocare şi fragmentare, nivelul TCP formatează articolele de dată în pachete TCP şi le remit nivelului TCP receptor. Acolo, data este receptată ca un şir de octeţi. Conexiunea TCP lucrează ca o conexiune full-duplex astfel încât ambele capete ale conexiunii TCP pot trimite şi primi date în mod concurent.

Este de responsabilitatea utilizatorilor serviciilor TCP să recunoască formatul articolelor de dată trimise de-a lungul unei conexiuni TCP.

Este un protocol fiabil de comunicare între procese aflate între calculatoare interconectate, folosind comutarea de pachete. Este orientat pe conexiuni şi se situează la nivelul transport din ierarhia OSI.

TCP presupune că la nivelul imediat inferior (reţea) există o modalitate, chiar neglijabilă, de transmitere a pachetelor în reţea. El a fost gândit ca având la nivelul reţea un modul Internet (IP) dar poate funcţiona şi cu alte protocoale. Interfaţa dintre modulul TCP şi modulele de nivel superior se face prin apeluri similare celor pe care un sistem de operare le oferă pentru manipularea fişierelor.

19. Funcţiile protocolului TCP

Protocolul TCP trebuie să asigure următoarele facilităţi: transfer de date în mod continuu, în ambele direcţii, între două procese. fiabilitateModulul TCP trebuie să refacă datele din pachetele eronate, să ţină cont de pachetele pierdute, de cele duplicate

sau transmise în altă ordine de sistemul de comunicaţii de la nivelul reţea. Pentru aceasta fiecare pachet primeste un număr de secvenţă şi necesită confirmare de primire. Dacă nu e primită confirmarea într-un interval maxim de timp, datele neconfirmate sunt retransmise. Numerele de secvenţă servesc atât la refacerea fluxului de date cât şi la eliminarea pachetelor duplicate. Deci atât timp cît modulele TCP funcţionează corect şi sistemul de reţele nu devine complet partiţionat, erorile mediului fizic de propagare a datelor nu vor influenţa corectitudinea fluxului de date.

c) controlul fluxului de dateModulul TCP asigură o modalitate prin care receptorul poate controla cantitatea de date furnizată de

transmiţător. Acest lucru se realizează însoţind fiecare confirmare de o fereastră de permisiune care indică domeniul de numere de secvenţe în care transmiţătorul poate furniza date fără a primi o nouă confirmare.

d) servicii orientate pe conexiune

Page 336: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 17

Serviciile de fiabilitate şi control al fluxului de date impun unui modul TCP să menţină pentru fiecare flux de date anumite structuri de control (soclu, numere de secvenţă, dimensiunea ferestrei de comunicaţie). O conexiune este definită de structurile de control din cele două procese ce comunică prin fluxuri de date. Deci pentru a stabili o conexiune între două procese ce doresc să comunice, modulele TCP proprii trebuie mai întâi să stabilească o conexiune (canal de comunicaţie), ceea ce înseamnă iniţializarea celor două structuri de control cu valori corelate. In acest scop are loc un dialog prealabil între cele două module TCP, pentru iniţializarea structurilor de control.

Un modul TCP pune la dispoziţie două funcţii de deschidere de conexiuni, una activă, de iniţiere a conexiunii, alta pasivă, de răspuns la orice cerere de stabilire de conexiune.

e) prioritate şi securitateUtilizatorii modulelor TCP pot indica nivelele de prioritate şi de securitate pentru transferul de date. Pentru

transmiterea datelor modulele TCP folosesc pachete IP.Fiecare pachet va conţine după antetul IP, un antet TCP cu informaţii specifice acestui protocol. Formatul

mesajelor TCP este cel din figura 11.7.

2.2.9 Semnificaţia câmpurilor

Portul sursă (16 biţi) -împreună cu adresa sursei formează soclul sursei.Portul destinaţie (16 biti) -numărul portului destinaţie selectează procesul din calculatorul destinaţie cu care

s-a stabilit o conexiune.Numărul de secvenţă (32 biţi) - reprezintă numărul primului octet de date din cadrul segmentului de date

curent. Dacă bitul de control SYN este setat, numărul de secvenţă este adus la valoarea sa iniţială.Numărul de confirmare (32 biţi) -conţine valoarea următorului număr de secvenţă pe care trebuie să-l

primească.

Figura 11.7. Formatul mesajelor TCP

Lungime antet date (offset date) (4 biti) conţine lungimea antetului TCP în cuvinte de 32 biţi indicând de unde încep datele.

Rezervat (6 biţi) -iniţializaţi cu 0.

Biţii de control

URG- se ia în considerare câmpul indicator urgent; ACK- validează număr confirmare;PSH- cere anunţarea imediată a utilizatorului destinaţie de primirea mesajului;RST- resetare conexiune;SYN- cere sincronizarea numerelor de secvenţă;FIN- anunţă terminarea fluxului de date de la transmiţător.Fereastra ( 16 biţi)- reprezintă numărul de octeţi, începând cu cel imediat din numărul de confirmare pe

care cel ce trimite mesajul îl poate recepţiona.

Page 337: licenta hatz

18Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Suma de control (16 biţi)- este calculată pentru toate cuvintele din antet şi din blocul de date. Dacă numărul de octeţi de date este impar se completează cu octet nul.

Indiacator urgent (Pointer urgent )(16 biţi) reprezintă offset-ul faţă de numărul de secvenţă al datelor ce trebuie transmise urgent.

Opţiuni - au lungimi diferite, apar sau nu în antet.Un număr mare de calculatoare din reţeaua ARPA Internet lucrează sub UNIX, de aceea UNIX-ul

Berkekey suportă TCP/IP care este accesat printr-un set de primitive specifice, care permit utilizatorilor să acceseze serviciul transport.

Aplicaţii şi caracteristici TCP

Multe aplicaţii care acţionează ca utilizatorii de servicii ai stivei TCP/IP utilizează serviciile nivelului TCP ca şi un punct de intrare în stiva TCP/IP. Serviciile oferite de către nivelul TCP ascund majoritatea detaliilor de reţea serviciului utilizator şi oferă servicii de transport, orientate pe flux, corecte.

Aplicaţiile pot stabili o conexiune "egal la egal" de-a lungul reţelei IP. Datorită caracteristicilor de control al fluxului de niveluri TCP, folosirea serviciilor TCP duce la o utilizare eficientă a lărgimii de bandă a reţelei disponibile. Numai aplicaţiile care utilizează serviciile protocolului UDP sunt capabile să opereze folosind servicii de comenzi fără conexiune.

In documentul original al DOD/DCA care defineşte stiva TCP/IP, au fost descrise un număr de aplicaţii care folosesc acest protocol. Aceste aplicaţii includ FTP, SMTP, TELNET. Aceste aplicaţii ar trebui să fie prezente în orice implementare completă a stivei TCP/IP.

FTP este folosită pentru a schimba fişiere între noduri reţea. FTP constă dintr-o aplicaţie client pe nodul reţelei care cere şi o aplicaţie server pe modul de reţea îndepărtat.

Utilizatorul, cu ajutorul terminalului poate transfera în mod interactiv fişiere spre şi de la nodul de reţea îndepărtat şi nodul de reţea local.

SMTP este un serviciu TCP utilizat pentru a interschimba mesaje între nodurile de reţea folosind pachete IP. Un pachet de control constă dintr-un antet cu informaţia despre partea trensmiţătoare şi receptoare, ca şi partea de mesaj care conţine mesajul poştal curent. SMTP oferă facilităţile de transfer mail. Pentru a construi o facilitate mail completă, aplicaţia utilizator-agent trebuie să fie prezentă în toate nodurile de reţea relevante. Un agent-utilizator trebuie să fie capabil să creeze, citească şi să mânuiescă mesaje e-mail.

TELNET este folosită pentru a conecta un nod de reţea ca terminal la un alt nod de reţea. Utilizatorul poate folosi terminalul conectat la nodul de reţea local pentru a se "log-a" la un alt nod de reţea îndepărtat.

1.3.3 Protocolul UDP (User Datagram Protocol)

Serviciile oferite de către nivelul IP nu sunt folosite de către programele de aplicaţie direct. Unul dintre principalele motive( pentru aceasta) este incapacitatea nivelului IP de a distinge între pachetele "către" şi "de la" mai mulţi utilizatori de servicii IP într-un nod IP. Pachetul IP conţine suficientă informaţie pentru a identifica nodul, însă e necesară informaţie suplimentară pentru a dirija pachele pentru mai multe aplicaţii reţea într-un singur nod IP.

UDP este construit în vârful nivelului IP şi oferă multiplexarea şi demultiplexarea mai multor fluxuri de date de-a lungul nivelului IP. Intr-un nod IP, mai mult de o aplicaţie poate schimba date cu alte noduri reţea, utilizând serviciile UDP. Nivelul UDP este responsabil pentru trimiterea datelor nivelului UDP pereche, şi de livrarea lor aplicaţiei receptoare.

In figura 11.8 este arătată o comunicaţie tipică, în care trei aplicaţii din calculatoru A (gazda A) schimbă articole de date cu aplicaţiile pereche din calculatorul B ( gazda B).

Nivelul UDP are grijă de multiplexarea şi demultiplexarea corectă a articolelor de date de-a lungul nivelului IP. De exemplu, dacă aplicaţia 1 din nodul A trimite un pachet de date aplicaţiei 2 din nodul B, nivelul UDP din nodul A efectuează multiplexarea, iar nivelul UDP din gazda B demultiplexarea.

Porturi UDP

Pentru implementarea serviciilor de multiplexare şi demultiplexare pentru nivelul transport, protocolul UDP, s-a introdus ca şi la TCP conceptul de porturi UDP. Un număr de porturi UDP, în combinaţie cu adresa IP a nivelului reţea local formează o identificare unică a portului UDP. Combinarea a două porturi UDP conectate, identifică o legătură UDP. Pachetele de date trimise de un capăt sunt recepţionate la celălalt capăt (de un port) de-a lungul unei legături UDP. Aplicaţiile conectate la un port UDP iau parte la o conversaţie într-o legătură tip UDP.

Page 338: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 19

Figura 11.8. Aplicaţii care folosesc protocolul UDP

Când construim o legătură utilizând serviciile UDP, portul UDP receptor trebuie să fie cunoscut dinainte. Toate serviciile importante de reţea au numere de port fixate.

Aceste porturi cunoscute sunt agreate de către toate implementările UDP. Un nod de reţea poate efectua o legătură UDP cu o aplicaţie, conectând-o la portul cunoscut al serviciului.

Structura pachetului UDP

Structura pachetului UDP este simplă în comparaţie cu structura unui pachet IP. pachet UDP: =

Port Sursă (octet 1:2)Port Destinaţie (3:4)Lungime (5:6)Verificare (7:8) Data (9:...)

;

Câmpurile au următoarea semnificaţie:Port Sursă: portul sursă UDP;Port Destinaţie: portul destinaţie UDP;Lungime: lungimea pachetului UDP în octeţi;Verificare: suma de control opţională a întregului pachet UDP;Data: data propriu zisă transportată de către pachetul UDP, în mod normal un pachet IP.

Un pachet IP este transportat la nivelul UDP destinaţie încapsulat în câmpul dată al pachetului IP. PachetulIP poate, de exemplu, fi transportat într-un cadru Ethernet. Intregul proces de încapsulare este descris în figura 11.9.

:Câmpuri Ethernet:

:Câmpuri IP:

:Câmpuri UDP:

data UDP

Page 339: licenta hatz

20Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.9. Incapsularea unui pachet UDP

Aplicaţiile şi caracteristicile UDP

Principala funcţie a nivelului UDP este de a adăuga facilităţi de conexiune serviciilor deja furnizate de către nivelul IP. Aceasta face ca principalele caracteristici ale serviciilor nivelului IP să fie de asemenea prezente în serviciile nivelului UDP. Datele trimise de-a lungul unei conexiuni UDP pot fi pierdute, pot conţine erori, pot sosiîntr-o ordine aleatoare (nu secvenţial). Deoarece aceste probleme, ce pot apare, fac nesigură remiterea corectă a articolelor de date, apare necesitatea ca utilizatorii serviciilor UDP să trateze erorile ce apar în remiterea pachetelor de date.

Un număr de aplicaţii bine cunoscute utilizează serviciile UDP. Una dintre ele este protocolul de transport fişier (TFTP-Triviale File Transport Protocol).

Serviciile oferite de către această aplicaţie sunt adesea utilizate pentru a "bootstrap"-a un nod reţea. Un mic nucleu de software reţea, incluzând Ethernet, IP, UDP şi TFTP este rezident într-un astfel de nod reţea. Serviciul acestui nucleu este folosit pentru a încărca alt software de-a lungul reţelei. Acest software formează un set mai complet de servicii. TFTP este construit în vârful nivelului UDP din cauza mărimii mici a implementării UDP. El poate fi uşorîncorporat (rezident) într-un ROM dintr-un nod de reţea.

O altă utilizare a UDP este SNMP(Simple Network Management Protocol). Această aplicaţie oferă ca şi serviciu schimbul de informaţie de management între două noduri de reţea. Alegerea UDP pentru SNMP este bazată pe uşurinţa de implementare a mediului UDP/IP şi a mărimii mici a unui astfel de mediu. O stivă UDP/IP cu o aplicaţie SNMP poate fi folosită într-un nod de reţea fără să ceară prea multe resurse.

1.4 Gestionarea reţelelor de calculatoare

1.4.1 Funcţiile sistemului de gestionare a reţelelor

Dezvoltarea legăturilor între reţele de calculatoare integrate produse de diverşi furnizori, în diverse configuraţii, necesită standardizarea în ceea ce priveşte gestionarea lor. Formele privind protocoalele de gestionare sunt dezvoltate mai întâi de principalele organizaţii de standardizare precum IEEE, ISO şi CCITT, iar după aceea sunt identificate specificaţiile pentru implementarea lor.

Figura 11.10. ilustrează un sistem integrat de gestionare a reţelelor, cu o varietate de sisteme care vehiculează date, imagini video precum şi voce.

Figura 11.10. Sistem integrat de gestiune a reţelelor

Există două forme de testare a eficienţei gestionării reţelelor şi anume: testarea interoperabilităţii privind asigurarea compatibilităţii funcţionale între două implementări specifice de produse şi testarea de conformitate, pentru a exercita conlucrarea între două implementări specifice. Eforturile de standardizare făcute de OSI au definit cinci zone specifice de gestionare a reţelelor şi anume: configuraţia, gestionarea defectelor, performanţa, costurile şi securitatea (Figura 11.11).

Page 340: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 21

Gestiunea configuraţiei implică legarea prin punţi şi reconfigurarea sistemelor utilizator precum şi a subreţelelor, incluzând punţi şi rutere, gestionarea folosirii numelor şi asocierea acestora cu adresele de reţea. Acest bloc este fundamental pentru buna funcţionare a sistemului de gestiune a reţelelor. El include următoarele funcţiuni:

gestionarea de atribute ale dispozitivelor, setarea şi modificarea valorilor individuale, colective sau predefinite ale acestora;

gestionarea iniţializării şi a opririi în totalitate sau a anumitor părţi din reţea;inventarierea sarcinilor de gestionare a unei organizaţii care are construită o bază de date privind toate echipamentele (modemuri şi multiplexoare), precum şi a circuitelor şi echipamentelor logice;

actualizarea topologiei de gestionare prin identificarea tuturor relaţiilor de interconectare;schimbarea modului de gestionare a reţelei şi a elementelor de reţea prin adăugarea, ştergerea şi aducerea la zi a informaţiilor care să reflecte schimbările făcute între diverse componente;identificarea gestionării directorilor şi corelaţiile tuturor numelor pentru un serviciu dat şi permiterea sincronizării acestora cu baza de date.

Figura 11.11. Interacţiunea între zonele de gestiune a reţelelor

Gestiunea defectelor este implicată în întreţinerea subreţelelor prin detectarea defectelor, izolarea erorilor şi corectarea defectelor de comunicaţie.

La identificarea problemelor este important să se clarifice diferenţa dintre defecte şi erori. Un defect este o situaţie anormală care necesită atenţionarea managerului.

Erorile pot apare ocazional (ex. erori CRC). Componentele principale în gestionarea defectelor sunt: detectarea defectului în cazul când nivelul erorilor depăşeşte o anumită limită şi atenţionarea utilizatorilor privind componenta defectă, precum şi menţinerea stării reţelei în timpii de răspuns normali.

Diagnoza defectului se face printr-o secvenţă de test capăt la capăt, lansată de la terminal la terminal, de-a lungul unui circuit, iar izolarea lui, prin identificarea componentei specifice care a cauzat erorile. Corectarea defectelor se face prin configurarea managementului de corectare a defectelor şi prin reconfigurarea reţelei pentru evitarea componentei defecte precum şi analiza erorilor pentru a vedea dacă problemele corectate mai pot apare după rezolvare.

Gestiunea performanţei trebuie să urmărească creşterea performanţelor, astfel încât să crească eficienţa reţelei prin evitarea gâtuirilor în noduri şi pe rute. Managerul de reţea defineşte nivelele unei performanţe acceptabile, de exemplu prin măsurarea timpului de răspuns în reţeaua de date sau gradul de servire pentru o reţea de voce. De asemenea, el poate alege componentele reţelei care vor fi monitorizate prin parametrii lor şi nivelele parametrilor.

Monitorizarea este necesară pentru a-l ajuta pe manager să vadă performanţa curentă a reţelei şi să o urmărească de la caz la caz, din oră în oră, zilnic, săptămânal sau lunar precum şi în momentele de trafic maxim.

Gestiunea costurilor reţelei ajută la definirea bugetului pentru reţea. Utilizatorii sunt informaţi asupra costurilor pentru resursele consumate precum şi alocarea acestor costuri pe diverse departamente.

Gestiunea securităţii reţelei este necesară pentru monitorizarea şi controlarea mecanismelor de protecţie a datelor. Aceasta asigură o continuă protecţie a căilor de comunicaţie. Principalii parametri de securitate sunt: confidenţialitatea, integritatea şi disponibilitatea (adică validarea numelor şi controlul accesului). Funcţiile de

Page 341: licenta hatz

22Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

securitate a reţelei cuprind şi responsabilităţi administrative de generare, distribuire şi memorare a căilor de criptare. Aceste caracteristici ale gestionării reţelelor se situează la nivelul aplicaţiei în ierarhia OSI.

1.4.2 Modelul de organizare a gestiunii reţelelor

Funcţionarea gestiunii unei reţele trebuie combinată cu organizarea la nivel informaţional privind situaţia actuală şi de perspectivă. Perspectiva organizaţională sau modelul este cheia în dezvoltarea standardelor de gestiune a reţelei. Există două tipuri de sisteme, unul de gestiune şi unul gestionat.

Gestiunea reţelei conţine aplicaţii care sunt distribuite în ambele sisteme şi anume: în sistemul de gestiune sunt urmărite procesele, iar în sistemul gestionat procesele agent şi obiectele.

Activităţile de gestionare sunt realizate printr-un manager de procese care comunică cu procesele din sistemul gestionat, astfel încât să controleze obiectele gestionate. Pentru fiecare obiect gestionat sunt definite atributele, (precum numărătoare, nivele etc), operaţiile valide asupra lor şi notificarea obiectelor de ieşire.

Atât sistemul de gestionare cât şi procesele din sistemele gestionate trebuie să aibă aceeaşi concepţie de acces concurent asupra obiectelor gestionate.

Un proces din sistemul de gestiune (management) poate monitoriza unul sau mai multe procese din sistemul gestionat.

Un proces din sistemul gestionat este asociat obiectelor; el asigură operaţiile de citire şi modificare ale atributelor obiectelor şi poate returna un răspuns la procesele gestionate. Figura 11.12 ilustrează acest model de organizare.

Figura 11.12. Modelul de gestiune a reţelelor

Modelul informaţional consideră că toate informaţiile referitoare la gestionare se găsesc în baza de informaţie a managementului (MIB).

Resursele de comunicaţii şi de prelucrare a datelor ce vor fi gestionate pot fi numite obiecte. Acestea includ protocoalele cu automate finite, nivelele, conexiunile şi dispozitivele fizice (ca de exemplu modemuri). Informaţia obţinută de la gestionarea de reţea poate la rândul ei să treacă în reţea pentru a redefini caracteristicile fizice cuantificabile şi calitative, constrângerile de intrare logică (incluzând timpul minim de răspuns, costul proiectării reţelei şi măsurătorile de siguranţă).

Sunt făcute îmbunătăţiri iterative astfel încât calculaţia costurilor de reţea şi performanţa sunt evaluate după criterii operaţionale. Acest proces continuă până când proiectarea optimizată reuşeşte să satisfacă obiectivele reţelei.

In ceea ce priveşte protocoalele de gestionare există protocolul CMIP ( Common Management Internet Protocol ) cu soluţii globale de interconectare.

El este puternic şi sofisticat, fiind dezvoltat de OSI pentru rularea pe stiva de protocoale OSI. Preţul plătit pentru implementare e destul de mare şi are multe date adiţionale (overhead).

SNMP (Simple NetWork Management Protocol) este un alt protocol de gestionare a reţelelor, uşor de implementat, cerând memorie puţină, timp redus de UC şi este complet definit astăzi, iar datele adiţionale sunt relativ puţine şi este simplu în operare. Având în vedere aceste caracteristici protocolul SNMP a fost ales de mulţi utilizatori şi producători. Acest protocol permite managerilor de reţea să obţină starea nodurilor şi rutelor, să schimbe parametrii dispozitivelor, să modifice rutele şi să facă asignarea dispozitive-rute.

Producătorii de TCP/IP au adoptat SNMP pentru produsele de gestionare a reţelelor (de ex. comunitatea Internet şi reţelele locale Ethernet).

Page 342: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 23

Pe de altă parte IBM, care foloseşte protocolul de gestionare NetWiew, a construit o poartă pentru CMIP. Alţi producători, precum DEC, au creat ceea ce se numeşte management integrat de reţea (EMA - entreprise management arhitecture).

Acest concept este foarte important în condiţiile gestionării integrate a informaţiei de toate tipurile (voce, date şi imagini) pentru toate tipurile de echipamente (calculatoare, modemuri, multiplexoare, centrale telefonice, reţele LAN, dispozitive telefonice), protocoale standard şi nestandard, de la diverşi producători, baze de date diferite, sisteme de aplicaţii.

1.4.3 Managementul reţelei TCP/IP

Analiza performanţei reţelei de calculatoare poate fi văzută ca o parte integrantă a managementului reţelei. In scopul acestei cercetări, cea mai interesantă parte a managementului reţelei este măsurarea şi colectarea statisticilor reţelei. Aceste statistici sunt folosite în determinarea parametrilor performanţei componentelor reţelei.

Când măsurăm şi gestionăm o reţea de comunicaţii de date, datele trebuie să fie colectate de la nodurile retelei conectate la ea. Datele pot conţine informaţii despre configurare, performanţa şi statutul nodurilor şi reţelelor care sunt conectate între ele. Combinând datele de la un număr de noduri, poate rezulta informaţia despre comportarea reţelei ca un întreg.

Datele colectate sunt cerute când se efectuează managementul activităţii reţelei. Standardul TCP/IP nu dă indicaţii cum să se folosească datele colectate.

SMAEAPLICATIEPREZENTARESESIUNETRANSPORTRETEALEGATURA DATEFIZIC

Figura 11.13. Modelul OSI extins cu servicii SMAE

Furnizorul de servicii la nivelul aplicaţie, numit SMAE este capabil să extragă date de la toate nivelele şi să le schimbe cu un SMAE "egal"(Figura 11.13.). Folosind capacitatea de a schimba între nodurile reţelei, date de gestionare a ei, pot fi implementate mai multe scheme de management. Una dintre cele mai simple scheme este să se folosească o staţie ca NMS. Acest nod de retea colectează toată informaţia relevantă de la toate celelalte noduri de reţea gestionate. Aplicaţia de management reţea care extrage informaţia de la datele colectate, rulează în mod normalîn NMS.

Scheme alternative includ o abordare distribuită, unde există mai mult de un NMS în reţelele gestionate şi activităţile de gestionare reţea sunt împărţite între aceste staţii.

Gestionarea, în cazul Internetului (Figura 11.14) se aseamănă mult cu modelul OSI. Fiecare nod de reţea colectează date despre comportarea funcţiilor interne. Aceste date pot fi colectate folosind SNMP. O staţie de management reţea poate comunica cu nodurile de reţea gestionate şi să extragă informaţia necesară gestionării reţelei. Pentru a face să funcţioneze acest concept, fiecare nod trebuie să fie capabil să suporte cel puţin o parte din stiva TCP/IP şi protocolul de management reţea. Aceste cerinţe sunt uşor satisfăcute de către noduri de reţea complexe cum ar fi staţii de lucru şi alte echipamente.

Page 343: licenta hatz

Figura 11.14. Gestionarea în cazul Internetului

Page 344: licenta hatz

24Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Acest tip de nod de reţea conţine deja o stivă TCP/IP completă şi are nevoie doar de suportul protocolului de management al reţelei. Pentru alte tipuri de noduri de reţea, cum ar fi punţile ethernet sau repetoarele, nu este necesară gestionarea lor cu ajutorul protocoalelor din ierarhia TCP/IP, pentru operaţiunile lor normale. Dacă totuşi aceste tipuri de noduri este necesar să fie incluse în schemele de management a reţelei, ele trebuie să conţină facilităţile de reţea necesare.

Gestionarea nodurilor se realizează prin schimbarea variabilelor şi valorilor lor. Toate datele de management reţea sunt încapsulate în variabile cu un identificator unic. Prin obţinerea sau setarea valorii unei variabile într-un nod de reţea gestionat, staţia de management reţea colectează datele gestionate şi gestionează nodul. Intr-o astfel de configuraţie, NMS ia întotdeauna iniţiativa schimbării datelor de management. Pentru a permite unui nod gestionat să alerteze NMS este utilizat un mecanism capcană.

In cazul în care software-ul de management reţea într-un nod gestionat vrea să notifice NMS despre o excepţie, poate trimite un mesaj capcană NMS-ului. Aceasta permite o notificare asincronă a NMS-ului.

Cadrul de management reţea al Internet-ului necesită un număr de facilităţi. In primul rând e necesară o reprezentare a datelor. Identificatorii de variabilă şi valorile variabilelor ar trebui să fie astfel încât să poată fi mânuite de mai multe platforme hardware diferite. In al doilea rând fiecare variabilă are un identificator care este recunoscut atât de NMS cât şi de nodul gestionat. Pentru a se putea permite NMS-ului să gestioneze noduri arbitrare, trebuie să fie un număr fix de variabile în fiecare nod.

Colecţia se numeşte MIB (Management Information Base). In al treilea rând, un mecanism de mapare şi un protocol de transport sunt definite prin identificatori de variabile, iar valorile variabilelor şi identificatorilor de cerere pot fi schimbate între aplicaţiile de management în NMS şi nodurile gestionate.

1.5 Reţele fără fir

Reţelele fără fir(wireless) sau radio, oferă beneficiul mobilităţii utilizatorilor şi o desfăşurare flexibilă a unei reţele într-o anumită arie. Mobilitatea utilizatorului îi permite unui client al reţelei să se mişte în diferite locaţii ale reţelei fără să-şi piardă conexiunea la reţea. Reţelele fără fir oferă de asemenea avantajul că adăugarea unui nod la reţea se poate face fără prea multă planificare sau costuri suplimentare de recablare. Aceasta face ca viitoarele dezvoltări ale reţelei să fie uşoare şi ieftine.

1.5.1 Provocări ale reţelelor fără fir

Unele dintre principalele provocări cărora trebuie să le facă faţă reţelele fărăfir, privitor la transmisie sunt enumerate mai jos.

Deficitul lăţimii de bandă făcând ca pentru reţelele radio divizarea lăţimii de bandă să fie esenţială de vreme ce spectrul radio nu numai că este destul de scump dar este totodată şi limitat.

Acces multiplu (Multiple access) adică succesul unei transmisii nu este independent de alte transmisii.Pentru a face o transmisie reuşită interferenţa trebuie evitată sau ţinută cel puţin sub control. Pe de altă parte transmisiile multiple pot conduce la coliziuni sau la semnale deformate.

Pierderea de cale (Path loss) adică puterea de transmitere a unui semnal radiază în toate direcţiile şi se atenueză repede cu distanţa. De aceea semnalul ajunge diminuat la receptor.

Direcţii multiple (Multipath), produc erori variabile de transmisie care pot conduce la o conectivitate intermitentă. Aceasta se întâmplă când un singur nod transmite când de fapt interferenţa rezultă dintr-un acces multiplu corespunzător transmiterii de la 2 sau mai multe noduri.

Diminuarea semnalului adică obstrucţia fizică poate cauza diminuarea semnalului când puterea de transmitere este blocată şi de acum încolo atenuată de barieră.

Mobilitatea, securitatea şi calitatea serviciului.

1.5.2 Standarde ale reţelelor fără fir(tabelul 9.1).

Reţele locale WLAN(Wireless Local Area Network) cunoscute ca şi WiFi standardizate prin familia de satndarde IEEE 802.11. Standardul permite mobilitatea şi include optimizări şi tehnici dezvoltate de diferiţi vânzători, având variante precum: 802.11a, 802.11b, şi 802.11g.

Page 345: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 25

HiperLan II: a fost proiectat pentru a administra infrastructura şi distribuirea sistemelor wireless. Operează la 5 GHz şi banda este dedicată numai în Europa.

PAN WLAN WMAN WANStandarde Bluetooth 802.11a,11b,11g 802.16 GSM, GPRS,

HiperLAN2 MMDS, LMDS CDMA, 2.5-3GViteză <1Mbps 2 pînă la 54 Mbps Peste 22 10 până la Kbps

MbpsRază de Mică Medie medie- Lungăacţiune lungă

Aplicaţii Peer-to-Peer Reţele de Acces fix Acces PDA,Device-to-Device întreprindere Reţele de Telefoane mobile

campusTabel 11.1 Diferite tipuri de reţele fără fir

HomeRF: este standardul pentru reţelele la domiciliu. HomeRF este o specificaţie industrială deschisă. Produsele compatibile HomeRF operează în banda de frecvenţă gratuită de 2.4 GHz şi utilizează tehnologia de salturi de frecvenţă.

Reţele metropolitane WiMAX(Worldwide Interoperability for Microwawe Access)standardizate prin standardele IEEE802.16; au fost proiectate pentru distanţe de până la 100Km, pentru legături cu vedere directă(LOS-Line of Sight) sau fără(NLOS-Non Line of Sight), folosind frecvenţe între 0,7-66GHz, pe canale licenţiate sau fără licenţă. Se prevede că acest tip de reţele va cunoaşte o puternică dezvoltare în următorii ani.

1.5.3 Conceptele şi standardele reţelelor locale fără fir

O reţea bazată pe standardul 802.11 are o arhitectură celulară. Sistemul este divizat in celule, unde fiecare celulă este denumită BSS (Basic Service Set) şi este sub controlul unei staţii de bază care este denumită AP(AccesPoint) sau punct de acces.

O reţea fără fir poate fi formată dintr-o singură celulă cu unul sau nici un punct de acces. Cele mai multe topologii au mai multe celule unde toate punctele de acces sunt conectate printr-o magistrală denumită DS (Distribution System) formată dintr-o reţea cablată sau una fără fir(wireless).

Standardul 802.11 defineşte 2 modalităţi de configurare: -de tip infrastructură(figura 11.15)-ad-hoc(figura 11.16).

Figura 11.15. Topologii tip infrastructură

Avem topologie structurată atunci când o reţea wireless are cel puţin un punct de acces conectat la o reţea cablată şi mai multe staţii conectate wireless. Această dispunere este denumită BSS (Basic Service Set). Un set de 2 sau mai multe BSS formează o singură subreţea denumită ESS (Extended Service Set). De vreme ce multe reţele wireless necesită accesul la serviciile reţelei cablate cum ar fi server de fişiere sau imprimante ele vor opera în modalitatea structurată

Page 346: licenta hatz

26Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.16 Topologie ad-hoc

Modalitatea ad-hoc reprezentată în figura 11.16 (modalitatea peer-to-peer sau IBSS – Independent BasicService Set): aceasta apare când un grup de staţii de tip 802.11 wireless comunică direct cu altul fără să folosească un punct de acces sau conexiunea printr-o reţea cablată. Această modalitate este folositoare pentru punerea rapidă şi facilă în funcţiune a unei reţele oriunde nu există o altă infrastructură cum ar fi o cameră de hotel, sau aeroport sau unde accesul la o reţea nu este posibil.

Ca şi în oricare alt protocol, 802.11 are 2 nivele: fizic şi subnivelul MAC.

1Nivelul legătură

LLC sau LLC+SNAPSubnivelul MAC Managementul subnivelului

de date MAC2 Subnivelul PLCP Managementul nivelului

Nivelul fizic Subnivelul PMD fizic PHYTabelul 11.2 Modelul de referinţă OSI şi reţelele radio

Incapsularea datelor pe diferite nivele este ilustrată în figura 11.17. Se observă că avem o încapsulare şi la nivel fizic.

Nivelul fizic

Nivelul fizic (PHY) acoperă interfaţa fizică între dispozitive şi este in legătură directă cu transmiterea şirului de biţi de-a lungul canalului de comunicare. Nivelul fizic este divizat în două subnivele:

Subnivelul PLCP (Physical Layer Convergence Procedure) pentru încapsularea datelor la nivel fizic; Subnivelul PMD (Physical Media Dependent), pentru codificarea datelor şi transmiterea lor pe canalele de

comunicaţie.

Figura 11.17 Incapsularea datelor în reţele fără fir

Cele 4 metode de codificare la nivel fizic sunt:DSSS (Direct Sequence Spread Spectrum);FHSS (Frequency Hopping Spread Spectrum);

Page 347: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 27

HRDSS rate înalte ale DSSS ( pentru IEEE 802.11b);OFDM(Orthogonal Frequency Division Multiplexing, pentru IEEE 802.11a şi IEEE.802.11g), metoda cea mai folosită în standardele actuale.

OFDM (Orthogonal Frequency Division Multiplexing)OFDM lucrează divizând o purtătoare de date de mare viteză în 52 sub-purtătoare de viteză mai mică, din

care 48 sunt folosite la transmiterea datelor în paralel. Aceste sub-purtătoare sunt divizate în aşa fel ca oricare din ele să fie ortogonală, de aici şi numele, cu celelalte, în aşa fel încât să permită să fie grupate împreună mult mai aproape decât standardul de multiplexare a diviziunii de frecvenţă. Datorită acestui fapt OFDM poate furniza o eficenţă spectrală superioară şi astfel asigură succesul pentru 802.11a. Principalele neajunsuri ale sistemului OFDM sunt vulnerabilitatea compensării de frecvenţă şi erorile de sincronizare.

4.1.4. Subnivelul MAC

La subnivelul MAC are loc încapsularea datelor ce vin de la nivelul reţea în cadre. Cadrele subnivelului MAC îndeplinesc diverse funcţiuni şi sunt de mai multe tipuri:v de management(cadre de: informare-beacon, răspuns de probă, autentificare, deautentificare, asociere, reasociere, dezasociere, de acţiune) ;w de control(ACK, RTS, CTS, PS-POLL);xde date(Data, Null-Data, Qos)

Datele în reţelele fără fir(la subnivelul MAC) sunt transmise în trei moduri:r date fără confirmare(Data, Data…)s date cu confirmare(Data, răspuns Ack, Data, răspuns Ack,…..)t date transmise după anunţ RTS/CTS (RTS, răspuns CTS, Data, răspuns Ack, Data,..)

Subnivelului MAC foloseşte protocolul CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Deasemenea subnivelul MAC este responsabil de fragmentare şi de criptare. Fiecare BSS are o adresă unică MAC pe 48 de biţi şi fiecare ESS are o lungime variabilă a adresei.

Protocolul CSMA/CA este similar cu cel de la reţelele Ethernet. Staţia care are ceva de transmis ascultă mediul şi când nu este nici o staţie activă, aici este diferenţa faţă de CSMA/CD aşteaptă un interval de timp aleator înainte de a-şi trimite datele monitorizând în permanenţă mediul. Pierderile de viteză sunt datorate faptului că se transmite după intervale de aşteptare aleatoare, dar acestea sunt compensate de retransmisii mai puţine. Cu cât sunt mai multe staţii cu atât este mai benefică această tehnică. Managementul nivelului MAC este responsabil de sincronizare, managementul energiei, roaming şi de MAC-MIB.

În standardul 802.11 subnivelul MAC, pe lângă funcţiile obişnuite, trebuie să se ocupe de fragmentarea pachetelor, retransmiterea lor şi confirmarea primirii lor. Nivelul MAC defineşte 2 metode diferite de acces:

DCF (Distributed Coordination Function) - funcţie de coordonare distribuită PCF (Point Coordination Function) - funcţie de coordonare punctuală

a)Funcţia de coordonare punctualăAceasta este o funcţie opţională pentru implementarea saltului de timp cum ar fi servicii de transmitere a

vocii şi transmisii video. Această funcţie este folosită pentru a iniţia un punct de acces ca şi un punct de coordonare. În această funcţie punctul de coordonare atribuie o prioritate fiecărui client într-o transmisiune a unui cadru.

b)Funcţia de coordonare distribuităÎn modul DCF o staţie trebuie să verifice mediul înainte de a iniţia transmiterea unui pachet. Ea aşteaptă ca,

pentru un anumit canal DIFS să devină nefolositor, apoi aşteaptă pentru un interval aleator de timp, timp backoff, care are valori între 0 şi valoarea lui CW (Convention Window-CW)(figura9.18).

c)Metoda de acces CSMA/CAPrincipalele beneficii ale CSMA/CA sunt:Reduce probabilitatea de coliziune unde este nevoie; staţiile aşteaptă ca mediul să devină liber; selectarea aleatoare a algoritmului Backoff după o anumită întârziere, rezolvarea acesteia prin evitarea

coliziunilor; algoritm eficient de Backoff stabil pentru trafic mare; creştere exponenţială a ferestrei Backoff pentru retransmisii;

Page 348: licenta hatz

28Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

- cronometrul Backoff se scurge numai când mediul este nefolositor;Implementează diferite nivele de securitate pentru a permite răspunsuri imediate şi coexistenţa PCF.

DIFS Fereastră de

PIFSDIFS

Mediu ocupat SIFS

Fereastră Backoff Următorul cadru

Cuantă de timp

Acces întârziat Selectează cuanta, decrementeazăBackoff cât timp mediul este nefolositor

Figura 11.18 Accesul CSMA/CA

Acesta foloseşte protocolul CSMA/CA (Carrier Sense Multiple Access, Collision Avoidance). Detectarea coliziunilor nu poate fi folosită de către protocoalele wireless din următoarele motive:

Detectarea coliziunilor solicită implementarea unui semnal radio full duplex capabil să trimită şi să receptioneze în acelaşi timp. Această implementare ar costa prea mult.

Premisa majoră în detectarea coliziunilor este că o staţie poate să asculte pe oricare alta. Această premisă nu se aplică şi în mediul wireless. Dacă o staţie detectează mediul liber aceasta nu înseamnă că în mod necesar mediul din jurul receptorului este liber. Figura 9.20 arată problema nodului ascuns, în care staţiile A şi C pot vedea pe B dar A nu poate vedea pe C. Figura 11.19 arată algoritmul de evitare a coliziunii care constă în următorii paşi:

Transmiţătorul verifică mediul. Dacă mediul este ocupat, suspendă transmisiunea. Dacă mediul este liber pentru o anumită perioadă de timp (DIFS), staţia începe să transmită.

Receptorul verifică CRC-ul pachetului recepţionat şi trimite o confirmare transmiţătorului. Dacă transmiţătorul nu primeşte nici o confirmare, el începe să retransmită cadrele după un algoritm aleator

DIFS

Sursă DateSIFS

DestinaţieAck

DIFS Fereastră

Alte Următorul MPDU

Întârziere de acces Backoff după întârziere

Figura 11.19 CSMA/CA + Protocolul ACK

Spaţiul între cadre IFS (Inter Frame Space) defineşte timpul minim pe care trebuie să-l aştepte o staţie după ce detectează mediul ca fiind liber. Cu cât este mai mic IFS cu atât este mai mare prioritatea. Dacă are loc o coliziune avem un algoritm de back-off care este folosit pentru a căuta când este liber mediul. Există patru tipuri de IFS pentru a atribui diferite priorităţi:

SIFS (Short Inter Frame Space) este perioada dintre completarea transmisiei pachetului şi începutul confirmării cadrului.

PIFS (Point Coordination IFS) este folosit de punctele de acces sau de punctele de coordonare; în acest caz pentru a obţine acces la mediu înaintea oricărei alte staţii. Această valoare este IFS plus o cuantă de timp

DIFS (Distributed IFS): Este IFS folosit de o staţie care doreşte să înceapă o nouă transmisie, este calculată adunând la PIFS o cuantă de timp

Page 349: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 29

EIFS (Extended IFS) este practic un IFS mai lung utilizat de o staţie care a primit un pachet ce nu-l poate înţelege. Avem nevoie de acesta pentru a preveni coliziunile.

d)Problema nodurilor ascunseCele două staţii nu se aud, dar fiecare aude punctul de acces(figura 11.20).

Staţie Punct de accesRaza RTS Raza CTSRTS

CTSPunctDate

Staţiede acces

AckStaţiile nu se aud una pe alta

Staţie Dar fiecare aude punctul de

Figura 11.20 Problema nodului ascuns

DIFS

Sursă RTS Date

DestinaţieCTS

Ack

CW

Alte NAV (RTS) Următorul MPDUNAV (CTS)

Acces întârziat Backoff după întârziere

Figura 11.21 Accesul RTS/CTS

Figura 11.21 arată schema care este folosită pentru a reduce coliziunile dintre staţii ca rezultat al faptului că ele nu au fost capabile să se asculte una pe alta.

Când o staţie doreşte să transmită un pachet, ea trimite un pachet de control denumit RTS (Request To Send) care include sursa, destinaţia şi durata următoarei tranzacţii.

Dacă mediul este liber staţia receptoare răspunde cu un pachet de control denumit CTS (Clear To Send) care include aceeaşi durată a informaţiei.

Toate staţiile care recepţionează fie CTS sau RTS îşi setează indicatorul lor Virtual Carrier Sense (denumit NAV, Network Allocation Vector – vector de alocare al reţelei) pentru o perioadă dată şi folosesc această informaţie împreună cu Physical Carrier Sense pentru a determina dacă mediul este liber.

15. Standardele de reţele locale fără fir IEEE 802.11a, b, g

Page 350: licenta hatz

Principalele standarde(Tabelul 11.3) pentru banda de bază sunt:

Page 351: licenta hatz

30Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Standar- Banda Frec-venţa Canale Protocol la nivelul Viteza Dis-tanţa Compati-bilitatea Inter-dul Simultane fizic (domeniul) ferenţă802.11a 5GHz 300- 8-13 OFDM 54Mb/s 10-40m Incompati-bila Puţine

555MHz802.11b 2,4GHz 83,5 3 HR-DSSS 11Mb/s 20-180m Compatibi-la cu Multe

MHz 11g802.11g 2,4GHz 83,5 3 OFDM 54Mb/s 20-180m Compatibi-la cu Multe

MHz 11b802.11n 2.4 si OFDM Medie

5Ghz de15Mbps

Tabelul 11.3 Principalele standarde WLAN şi caracteristicile lor

1.5.4 Securitatea reţelelor fără fir

35. Ameninţări ale securităţii reţelelor fără fir

Intercepţia poate avea loc folosind receptoare standard cum ar fi o antenă;Furtul resurselor atacatorii pot fura un acces valid şi apoi să dobândească acces direct la toate

dispozitivele unei reţele;Redirectarea traficului atacatorii pot face modificări în tabelele ARP din switchuri ale reţelelor cablate

printr-un punct de acces ducând la rutări diferite ale destinaţiei pachetelor;Negarea serviciului acest atac are loc când atacatorii încearcă să inunde reţeaua cauzând congestii

distrugând conexiunea dintre 2 staţii pentru a preveni accesul la servicii;Reţele rătăcite şi staţii redirecţionate o reţea wireless 802.11 este foarte predispusă la atacul din partea

unui punct de acces rătăcit. Acest punct de acces este unul deţinut de un atacator şi acceptă conexiuni STA.

57. Autentificarea în cazul satandardelor IEEE 802.11

IEEE 802.11 are două subtipuri de autentificări: sistem deschis şi cheie partajată. Autentificarea este făcută între două staţii. De aici rezultă că se poate face numai în cazul cadrelor unicast dar nu şi la cele multicast.

Autentificarea sistemelor deschise: sistemul deschis este implicit algoritmul de autentificare şi implică un proces în 2 paşi după cum urmează:

A trimite o cerere de autentificare lui B B trimite rezultatul înapoi lui A

Dacă punctul de autentificare a lui B specifică „sistem deschis” rezultatul acţiunii este reuşit, altfel A nu este autentificat.

Autentificarea cu cheie partajată: aceasta furnizează un grad de autentificare mai bun decât cea a sistemelor deschise. Autentificarea cu cheie partajată suportă autentificarea staţiilor oricărui membru care ştie cheia secretă partajată sau a unui membru care nu o ştie. Cheia secretă partajată se găseşte în MIB-ul fiecărei staţii într-o formă write-only şi este accesibilă numai coordonatorului MAC. Pentru staţiile care folosesc autentificarea cheilor partajate, trebuie să se implementeze WEP. Standardul 802.11 nu a specificat cum trebuie distribuite cheile fiecărei staţii. Cei patru paşi de bază sunt următorii:

O staţie trimite un cadru prin care cere autentificarea altei staţii (sau unui punct de acces)Punctul de acces foloseşte WEP pentru a genera un şir de octeţi ca şi cerere de autentificare şi răspunde lui

A.

Page 352: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 31

Vector de initializareRC4

WEP Secventa a cheii IV

Cheia secreta PRNG +

TextText clar cifrat

Algoritm de integritate

Valoare de controlMesaj

a integritatii

Figura 11.22 Criptarea WEP

Staţia care face cererea copiază textul cadrului cererii de autentificare într-un alt cadru, criptează cadrul folosind cheia secretă partajată apoi transmite cadrul înapoi

La punctul de acces, dacă verificarea lui WEP ICV nu dă erori, respondentul va compara conţinutul decriptat al câmpului cerere text cu cerere de autentificare de la punctul 2. Dacă cele 2 sunt identice, punctul de acces va răspunde cu un cod de reuşită în cel de-al patrulea cadru. Dacă verificarea WEP ICV eşuează, staţia nu va fi autentificată.

WEP (Wired Equivalent Privacy) este protocolul de încapsulare pentru 802.11 al cadrelor de date. Scopul este să furnizeze securitate datelor la nivelul unei reţele cablate. WEP este un algoritm simetric în care aceeaşi cheie este folosită atât pentru criptare cât şi pentru decriptare.

Se foloseşte aceeaşi cheie atât pentru criptare cât şi pentru decriptare. Algoritmul de criptare este descris înfigura 11.22, iar cel de decriptare în figura 11.23.

Asupra textului în clar se aplică 2 procese. Unul este de criptare a textului iar altul este de protejare împotriva modificărilor neautorizate.

Cheie secreta Text clarRC4

Semnatura cheiiIV

WEPPRNG + ICV’

Algoritm de integritate

Text ICV=ICV’

cifrat ICV

Mesaj

Figura 11.23 Decriptarea WEP

Cheia secretă (40 biţi) este concatenată cu IV (Initialization Vector) vector de iniţializare rezultând o lungime totală a cheii de 64 de biţi. Cheia rezultată este preluată ca intrare a PRNG (Pseudorandom number generator). PRNG (RC4) dă ca rezultat o cheie pseudoaleatoare bazată pe cheia de intrare. Secvenţa rezultată este folosită pentru criptare datelor folosind XOR. Lungimea acestui rezultat criptat este egală cu numărul de octeţi ai datelor care sunt transmise plus încă 4 octeţi, aceasta deoarece secvenţa cheii este folosită pentru păstrarea integrităţii datelor (ICV 32 biţi)

Pentru protejarea împotriva modificărilor neautorizate, un algoritm de integritate (CRC-32) operează asupra textului în clar pentru a produce ICV

La decriptarea datelor, vectorul de iniţializare al mesajului primit este folosit pentru a genera secvenţa necesară pentru decriptarea mesajului primit. Combinând textul criptat cu o secvenţă potrivită a cheii ne va furniza textul original şi ICV. Decriptarea este verificată executând algoritmul de verificare a integrităţii asupra textului clar refăcut şi comparând ICV’ astfel rezultat cu ICV transmis odată cu mesajul. Dacă ICV’ nu este egal cu ICV mesajul a fost recepţionat cu erori şi este trimis un mesaj de eroare staţiei transmiţătoare.

Page 353: licenta hatz

32Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

• Protocolul de autentificare 802.1x(EAP) şi subprotocoalele sale

Figura 11.24. Autentificarea 802.1x

Standardul de autentificare 802.1x este relativ simplu şi iniţial nu a fost destinat comunicaţilor fără fir. Pentru802.1x autentificarea clienţilor se face printr-un server de autentificare extern(de obicei RADIUS sau, mai nou,Diameter). Unele produse fără fir folosesc serverul de autentificare nu numai pentru simpla autentificare a utilizatorilor, ci şi pentru politici utilizator şi funcţii de control ale utilizatorilor. Aceste funcţionalităţi avansate pot include asignare VLAN dinamică şi politici utilizator dinamice.

Autentificarea 802.1x este un dialog între un sistem care doreşte să se conecteze la serviciile reţelei şi reţea. Acest dialog foloseşte protocolul extensibil de autentificare EAP. 802.1x constă dintr-un PAE (Port Access Entity) în toate staţiile (STA) şi punctele de acces (AP), încapsularea EAP a reţelei (EAPOL) şi un server de autentificareRADIUS (AS) (figura 11.24.).

Dialogul de autorizare standard constă în:1. AP cere STA să se identifice folosind EAPOL (EAP over LAN);2. STA îşi trimite identitatea la AP;3. AP trimite mai departe identitatea STA la AS, prin intermediul EAP;4. Între AS şi STA are loc un dialog de autentificare;5. Dacă dialogul este terminat cu succes, STA şi AS partajează cheia de sesiune;6. AS trimite cheia de sesiune la AP într-un atribut RADIUS precum şi o parte a mesajului de acceptare a RADIUS.7. AP dă accesul portului său adresei STA a MAC ş,i opţional, permite o cheie WEP printr-un pachet EAPOL.

1.5.4.4 Autentificarea de tip acces protejat la WiFi (WiFi Protected Acces-WPA)

Până la ratificarea standardului IEEE 802.11i, alianţa WiFi a propus WiFi Protected Access(WPA) ca o soluţie interimară care să înlocuiască criptarea bazată pe WEP. Dezvoltarea WPA face parte din eforturile WiFi Alliance şi IEEE de a oferi soluţii de securitate puternice, bazate pe standarde şi interoperabile. WPA a fost creat pentru a fi compatibil, pe viitor cu standardul de securitate 802.11i ce va fi oferit de mulţi comercianţi ca aducere la zi(upgrade) pentru AP –urile existente şi plăcile de reţea fără fir.

WPA aduce îmbunătăţiri securităţii fără fir în mai multe moduri. In primul rând adaugă mecanismele de autentificare care lipseau în implementările WEP tradiţionale. Autentificarea WPA poate fi realizată cu 802.1x sau chei partajate. 802.1x oferă abilitatea de regenerare a cheilor, dar necesită un server de autentificare RADIUS compatibil cu 802.1x/EAP. Folosirea cheilor partajate nu necesită un astfel de server, însă se pierd o parte din funcţionalităţile de autentificare a utilizatorului.

Protocoalele folosite de WPA si RSN pentru implementarea securităţii de acces sunt: IEEE 802.1x EAP( Extensible Authentication Protocol) şi RADIUS (Remote Authentication Dial-In User Service). Acestea sunt sunt obligatorii pentru WAP şi RSN.

WPA cere recodificarea cheilor de criptare folosind TKIP. WPA încearcă să facă referire şi la probleme de interoperabilitate.

1.5.4.5 Protocolul de integritate cu cheie temporară(TKIP)

Protocolul de integritate cu cheie temporară(TKIP-Temporal Key Integrity Protocol) este folosit de WPA pentru recodificarea cheii de criptare a traficului unicast. Fiecare cadru de date transmis prin spaţiul fără fir este

Page 354: licenta hatz

recodificat de către TKIP. TKIP sincronizează schimbul de chei între client şi AP. Cheile de criptare globală sunt schimbate, printr-un anunţ către toţi clienţii conectaţi, de către protocolul WPA.

Page 355: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 33

A fost proiectat pentru a permite unele soluţii pentru câteva probleme software şi firmware întâlnite în WEP. Schimbările majore în cadrul WEP sunt:

un nou cod de integritate a mesajului (MIC ), generat cu algoritmul Michael. MIC este calculat cu textul MSDU, adresele sursă şi destinaţie şi câmpul de prioritate MSDU, înaintea fragmentării în MPDU-uri. MIC asigură apărareîmpotriva atacurilor false;

din cauza limitărilor algoritmului Michael, au fost implementate un set de contramăsuri. Din cauza limitărilor hard, a fost imposibilă folosirea unui algoritm mai puternic, dar totuşi această metodă alternativă reduce probabilitatea unui atac;

TKIP extinde vectorul de iniţializare WEP(IV)( în principiu, este incrementat un numărător la fiecare trimitere a unui cadru) şi utilizează aceasta la MPDU ca un TSC(TKIP Sequence Counter);

managementul de chei RSNA asigură o cheie temporară. Este aplicată o funcţie de mixare la TSC şi adresa de transmitere(TA ). Aceasta asigură nu numai o cheie nouă pentru fiecare secvenţă trimisă, dar previne şi utilizarea unor chei slabe, cu fluxul criptat, folosind RC4.

1.5.4.6 Protocolul 802.11i

Curând după succesul răsunător al reţelelor locale (LAN) fără fir, a devenit foarte evidentă lipsa securităţii acestora. După câţiva ani, a fost introdus un standard IEEE 802.11i(numit şi WPA2) pentru a asigura o securitate robustă acestor reţele. În cele ce urmează vom descrie mecanismele de autentificare, managementul parolelor, protecţia integrităţii şi confidenţialităţii în cadrul acestor reţele cu securitate robustă.

Îmbunătăţirea principală a 802.11i pentru WLAN-uri este definirea unor reţele cu servicii robuste de securitate(RSN-Robust Security Netwok). Standardul IEEE 802.11i urmăreşte rezolvarea deficienţelor asociate cu confidenţialitatea datelor în mediul fără fir.

O reţea RSN este o reţea sigură care permite crearea de asocieri în RSN (ARSN). O ARNS defineşte un număr de trăsături cum ar fi mecanisme de autentificare îmbunătăţite pentru staţii, algoritmi criptografici şi mecanisme de încorporare a datelor îmbunătăţite care asigură confidenţialitate crescută, numite CCMP şi opţionalul TKIP.

Într-o reţea cu securitate robustă, IEEE 802.11i asigură funcţii de protecţie pentru secevenţele de date, 802.1X asigură autentificarea şi controlul porturilor, iar IEEE 802.11i şi IEEE 802.1X colaborează pentru a furniza managementul parolelor. Reţelele capabile RSN adaugă elemente speciale secvenţelor lor, promovându-le capabilităţile. În continuare nu se va discuta despre elementele de bază ale autentificării 802.1x, întrucât acestea au fost tratate anterior. Vom face o descriere a cheilor ierarhice din RSN-uri. Aceste procese se reunesc în protocolul handshake pe 4 căi şi a cheilor stabilite cu acestea. În final, se va aborda utilizarea cheilor generate în cele două moduri confidenţiale.

RSN-urile utilizează protocolul 802.1X pentru a asigura autentificare puternică , managementul cheilor şi controlul accesului. Aplicaţiile variază de la confidenţialitate spre evidenţă, funcţie de modelul de afacere. AsocierileRSN înlocuiesc mecanismele clasice de asociere.

1.5.4.6.1 Ierarhia cheilor în cadrul protocolului 802.11i

În problemele de securitate un aspect important îl constituie cheile. Dacă aceste chei sunt compromise sau furate, nu mai putem vorbi securitate.

Există două tipuri de chei utilizate de protocoalele de criptare la nivelul legăturii de date:Cheile perechi (Pairwise keys), care protejează traficul între staţie şi punctul de acces;

Cheile de grup(Group keys) care protejează traficul broadcast sau multicast de la punctul de acces la clienţi. Cheile perechi sunt obţinute din informaţiile de autentificare, iar cheile de grup sunt create aleator şi

distribuite la fiecare staţie de punctul său de acces. 802.11i foloseşte două protocoale de criptare şi anume TKIP(tratat anterior) şi CCMP (care va fi descris mai jos). Ambele folosesc o cheie master pentru a obţine cheile temporare cerute pentru protecţia cadrelor la nivelul legăturii de date. Cheia master este cheia rădacină şi trebuie protejată deoarece toate celelate chei derivă din ea. În RSN contextul de securitate este definit de posesia cheilor cu viaţă limitată. Faţă de WEP, în RSN sunt o mulţime de chei care formează o ierarhie de chei şi majoritatea acestor chei nu sunt cunoscute la începutul procesului de autentificare. Pentru că sunt create în timp real, ele sunt cunoscute şi sub denumirea de chei temporare. Aceste chei temporare pot fi actualizate(reînnoite) din timp în timp, dar întotdeauna sunt distruse odată cuîncheierea contextului de securitate. RSN-urile folosesc diferite chei pentru diferite scopuri şi pentru diferite nivele. În fruntea ierarhiei cheilor perechi se află cheia master pe 256 biţi(Pairwise Master Key-PMK). În configuraţiile WPA-PSK cheia master este configurată, iar în configuraţiile ce folosesc server de autentificare cheia master este calculată de srverul RADIUS şi trimisă punctului de acces în atributul RADIUS. Din ea derivă patru chei diferite, fiecare pe 128 de biţi şi anume: cheia utilizată la calcularea integrităţii mesajului EAPOL(KCK-Key Confirmation Key), cheia

Page 356: licenta hatz

34Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

utilizată la criptarea mesajelor EAPOL(KEK-Key Encription Key), cheia de criptare a datelor TKIP, cheia de integritate a datelor TKIP(cheia MIC). Împreună, toate cele patru chei sunt cunoscute ca şi cheia pereche tranzitivă pe 512 biţi.

1.6 Securitatea reţelelor de calculatoare

1.6.1 Introducere în criptografie

Reţelele de calculatoare sunt o resursă partajată, folosită de către mai multe aplicaţii în diverse scopuri. Uneori, datele transmise între procesele aplicaţie sunt confidenţiale şi ar fi de dorit ca ele să nu fie citite decât de cei cărora li se adresează. De exemplu, când cumpărăm un produs pe WWW, utilizatorii trimit uneori numărul cărţii de credit (în tările unde este posibil acest lucru) prin reţea. Acest lucru este destul de riscant, deoarece este usor pentru o altă persoană să proiecteze un program aplicaţie care să "asculte" reţeaua şi să citească pachetele care o traversează. Deci e necesară transformarea datelor trimise pe un canal capăt la capăt, prin criptarea lor.

Mesajele ce trebuie criptate, cunoscute sub numele de text clar, sunt transformate într-o funcţie parametrizată de o cheie. Ieşirea procesului de criptare, cunoscută sub numele de text cifrat (figura 11.25). Procesul de transformare a textului cifrat înapoi în text clar se numeşte decriptare caz în care se foloseşte o cheie de decriptare obţinându-se în aceste mod textul original.

Presupunem că intrusul ascultă şi copiază cu acurateţe întreg textul cifrat. Totuşi, el nu ştie care este cheia de criptare şi astfel el nu poate decripta prea uşor textul cifrat. Uneori intrusul poate nu numai să asculte canalul de comunicaţie (intrus pasiv), ci şi să înregistreze mesajele şi să le retransmită mai târziu, să injecteze propriile sale mesaje sau să modifice mesajele legitime înainte ca ele să fie preluate de receptor (intrus activ).

În cadrul ştiinţei criptologiei se disting două componente: criptografia (arta de a concepe cifruri) şi criptanaliza (arta de a sparge cifruri). Criptograful caută metode pentru a asigura siguranţa şi securitatea conversaţiilor în timp ce criptoanalistul încearcă să refacă munca celui de dinainte prin spargerea sistemului.

Figura 11.25. Criptarea şi decriptarea

Obiectivele principale ale criptografiei moderne pot fi văzute ca fiind: autentificarea utilizatorului, autentificarea datelor (integritatea datelor şi autenticitatea datelor de origine), nerespingerea (acceptarea) originii şi confidenţialitatea datelor. În continuare vom studia mai pe larg câteva dintre acestea. Ulterior, vom explica cum pot fi realizate aceste servicii folosind primitivele criptografice.

1.6.2 Servicii criptografice

1.6.2.1 Autentificarea utilizatorului

Dacă ne conectăm la un sistem de calcul trebuie (sau cel puţin ar trebui) să existe un mod prin care să-l convingem pe interlocutor asupra identităţii noastre. Odată ştiută identitatea, se poate verifica dacă avem dreptul de a intra în sistem. Acelaşi principiu se aplică când o persoană încearcă să comunice cu o alta: primul pas este acela de a verifica dacă persoana cu care se comunică este într-adevăr cine susţine că este. Deci, trebuie să existe un mod în care să-ţi dovedeşti identitatea. Procesul este numit autentificarea utilizatorului. Există câteva căi de a obţine această autentificare.

Cel ce vrea să se conecteze va transmite un element de identificare pe care-l ştie numai el: o parolă, un identificator de utilizator, un cod pin etc. Sau poate avea un element specific cu care se poate identifica: un card magnetic, un smart card, un simbol etc. Se mai pot folosi şi proprietăţile biometrice; este un fapt bine cunoscut că amprentele digitale, forma mâinii sau modelul retinal ale unei persoane sunt criterii bune de decizie. Acestea

Page 357: licenta hatz

necesită însă echipamente specializate şi de aceea reprezintă o mare investiţie. Totuşi, aceste sisteme biometrice nu sunt

Page 358: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 35

perfecte: unii utilizatori legitimi vor eşua inevitabil asupra identificării, iar unii intruşi vor fi acceptaţi ca autentici. Alte tehnici includ măsuri despre cum îşi tastează numele sau îşi scrie semnătura, sau se ia în calcul locaţia utilizatorului.

1.6.2.2 Autentificarea datelor

Autentificarea datelor constă din: faptul că datele nu au fost modificate (integritatea datelor) şi faptul că se ştie cine este expeditorul (autentificarea datelor de origine).

a)Integritatea datelor.Serviciul de integritate al datelor garantează faptul că, conţinutul masajelor, care au fost transmise, nu a fost

atins de nimeni. Integritatea datelor în sine nu are un sens precis: nu te ajută să ştii că datele pe care le-ai receptat nu au fost modificate, doar dacă ştii sigur că ţi-au fost trimise direct de la persoana în cauză. De aceea, întotdeauna ar trebui combinată cu autentificarea datelor de origine. Întotdeauna ar trebui să fim în alertă asupra posibililor intruşi în reţea sau în sistemul de comunicaţie. Un exemplu bine cunoscut este Internetul care conţine universităţi şi companii de pe întreaga planetă. Poşta electronică de pe Internet nu oferă nici o securitate. În consecinţă, un utilizator poate intercepta mesajele care sunt transmise de-a lungul liniei de comunicaţie. Este foarte uşor de citit şi de modificat corespondenţa electronică a unei persoane, care este privită în general ca fiind privată.

O persoană A transmite un mesaj unei persoane B. Poate exista un adversar care le poate intercepta mesajul. Dacă nu există integritatea datelor, inamicul poate doar schimba mesajul şi apoi să-l transmită lui B. B nu va observa că mesajul a fost transformat şi va presupune că A a scris într-adevăr mesajul aşa cum l-a primit el. Se poate afirma că interceptarea pe fir este dificilă. În general această interceptare este o problemă de cost în sensul că este mult mai uşor de interceptat o linie telefonică decât un cablu coaxial. Interceptările active de fire (modificare şi apoi retransmiterea mesajelor) sunt mult mai dificile decât interceptările pasive de fire (doar ascultarea mesajelor).

b)Autentificarea datelor de origine.Cineva doreşte să se asigure că o persoană care susţine că este transmiţătorul mesajului în sine, este cel

căruia îi aparţine în original. Dacă A îi trimite un mesaj lui B, dar inamicul interceptează mesajul şi îl retransmite lui B susţinând că l-a transmis A, cum poate fi B sigur de originea datelor? O variantă a acestei probleme este: inamicul poate transmite lui B un mesaj susţinând că A este autorul. Mulţumită criptografiei, există tehnici de asigurareîmpotriva acestor tipuri de fraude.

1.6.2.3 Acceptarea originii

Acceptarea originii protejează împotriva refuzului uneia dintre entităţi care este implicată într-o convorbire, de a participa în totalitate sau parţial la comunicaţie. Acceptarea unei dovezi a originii, protejează împotriva oricărei intenţii a transmiţătorului de a respinge trimiterea unui mesaj, în timp ce acceptarea unei dovezi a livrării, protejează împotriva oricărei tentative a destinatarului de negare, falsificare a mesajului recepţionat. Un exemplu va ilustra importanţa acceptării originii. Presupunem că B este proprietarul unei companii de corespondenţă prin mail. Pentru el este foarte important să poată arăta unei a treia părţi că A într-adevăr a cerut lucrurile pe care le presupune el, altfel, i-ar fi foarte uşor unui client să nege achiziţionarea bunurilor. În limbajul cuvintelor scrise pe hârtie, acceptarea originii este furnizată de semnătura manuală.

1.6.2.4 Confidenţialitatea datelor

Acest aspect al securităţii datelor este cu siguranţă cel mai vechi şi mai cunoscut. Exemplul cifrului lui Caesar, dat în introducere demonstrează acest lucru. Confidenţialitatea a fost considerată a fi mult mai importantă decât autentificarea, atât din punct de vedere al datelor cât şi din punct de vedere al transmiterii. Astfel o scrisoare era scrisă lizibil, cu un sigiliu şi o semnătură. Cu ajutorul confidenţialităţii datelor, ne protejăm împotriva dezvăluirii neautorizate a mesajelor. Dacă A trimite un mesaj lui B pe care îl interceptează un inamic, se doreşte ca inamicul să nu poată înţelege niciodată conţinutul mesajului.

Confidenţialitatea datelor este foarte importantă in lumea medicală şi de asemenea în sectorul bancar. În întreaga lume se fac mii de tranzacţii în fiecare zi şi toate acestea trebuie trecute de la o instituţie financiară la alta. Dacă nu există nici un mod de a proteja confidenţialitatea, toată lumea ar fi în măsură să vadă ce s-a tranzacţionat şi cine a cumpărat şi ce retrageri au avut loc, şi aşa mai departe.În mod evident ar avea loc violări de intimitate asupra indivizilor şi asupra companiilor. Pentru a furniza confidenţialitate, este necesară cifrarea mesajelor.

b)Criptare simetrică.

Page 359: licenta hatz

36Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

În esenţă există două tipuri de scheme de criptare. Cele mai vechi şi cele mai folositoare până în prezent sunt criptările simetrice. În aceste scheme, cheia folosită pentru decriptarea textului cifrat este echivalentă cu cea folosită pentru criptarea textului iniţial.

Figura 11.26 Criptarea simetrică cu cheie secretă

Algoritmii cu cheie secretă sunt simetrici, în sensul că ambii participanţi angajaţi în comunicaţie partajează o singură cheie. Figura 11.26 ilustrează folosirea criptografiei cu cheie secretă pentru a transmite data într-un canal nesigur. DES este cel mai cunoscut exemplu de algoritm de criptare cu cheie secretă.

Cel mai bun algoritm din această categorie este Data Encription Standard (DES), care a fost adoptat în 1977 de către American NBS (National Bureau of Standards). De atunci a fost folosit în întreaga lume şi până acum nu s-au descoperit mari defecte. Algoritmul DES foloseşte o cheie pe 56 de biţi care din păcate este scurtă. O mai bună securitate poate fi realizată folosind algoritmul DES triplu. În acest mod se obţine efectiv o cheie de 112 biţi care este suficient de mare. Nu este suficientă alegerea unui algoritm sigur; mai este nevoie de specificarea unui mod de operaţie securizată. Depinzând de natura canalului de comunicare sau de spaţiul de stocare, se poate alege între Cipher-Block-Chaing (CBC), Cipher-Feedback (CFB), şi Output-Feedback (OFB). Criptarea bloc cu bloc (sau Electronic Code Book(ECB)) va fi folosită doar pentru criptarea cheilor.

j)Criptare asimetrică.Algoritmii de criptare asimetrică sau de criptare cu chei publice sunt cele mai recente unelte criptografice.

Din contră, pentru sistemele asimetrice cheia folosită pentru criptare şi cea folosită pentru decriptare sunt diferite. Astfel, fiecare dintre parteneri are două chei. Se ţine o cheie secretă şi cealaltă se face publică. Dacă A doreşte să transmită un mesaj lui B, acesta doar criptează mesajul cu cheia publică a lui B. Deoarece B este singurul care are acces la cheia secretă, acesta este singurul care poate decripta şi citi conţinutul mesajului.

Pe de altă parte, criptografia cu cheie publică implică faptul ca fiecare participant să aibă o cheie privată care nu este partajată cu nimeni şi o cheie publică care este publicată, astfel încât toată lumea ştie de ea. Pentru a trimite un mesaj sigur la un asemenea participant, se criptează mesajul folosind cheia cunoscută (cheia publică). Participantul decriptează mesajul folosindu-şi cheia privată. Mecanismul este ilustrat în figura 11.27.

Figura 11.27 Criptarea asimetrică cu cheie publică

Cel mai cunoscut algoritm de criptare cu cheie publică este metoda RSA (RSA vine de la numele celor trei inventatori Rivest, Shamir şi Adleman). Această schemă de securitate este înrudită cu problema de factorizare din matematică: este uşor de generat două numere prime mari şi este uşor şi de multiplicat, dar fiind dat un număr mare ce este un produs de două numere prime, este nevoie de o mare cantitate de calcule pentru a găsi cei doi factori primi.

În acest moment, cel mai mare număr care a fost factorizat are o lungime de aproximativ 512 (1997). Din acest motiv, lungimea minimă absolută a cheilor sistemului RSA trebuie stabilită la 640 biţi; 768 sau 1024 biţi sunt necesari pentru orice sistem care cere securitate pentru mai mult de câteva luni.De fapt există un al treilea tip de

Page 360: licenta hatz

algoritm criptografic, numit funcţie hash sau message digest. Spre deosebire de tipurile anterioare, folosirea unei funcţii hash nu

Page 361: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 37

implică folosirea unor chei. In loc de aceasta, ideea este de a mapa un mesaj lung într-un mesaj de o anumită lungime fixă, analog felului în care o funcţie hash obişnuită mapează valori dintr-un spaţiu larg în valori într-un spaţiu îngust. Această metodă calculează o sumă de control criptografică (cryptographic checksum) a unui mesaj. Asta înseamnă că, aşa cum o sumă de control obişnuită protejează destinatarul de schimbări accidentale ale mesajului, o sumă de control criptografică protejează destinatarul de modificări maliţioase ale mesajului.

Aceasta deoarece toţi algoritmii de criptare prin repetiţie sunt aleşi astfel încât să aibă o sumă de control unică pentru un mesaj şi deci este aproape imposibil să găseşti ce mesaj a produs acea sumă de control. Cu alte cuvinte, nu este computational fezabil să găseşti două mesaje care prin repetiţie să te ducă la aceeaşi sumă de control criptografică. Relevanţa acestei proprietăţi este că dacă primeşti o sumă de control pentru un mesaj (împreună cu mesajul), şi eşti capabil să calculezi exact aceeaşi sumă de control pentru mesaj, atunci este foarte posibil ca acel mesaj să fi produs suma de control primită.

Deşi nu-l vom descrie în detaliu, cel mai folosit algoritm pentru a calcula suma de control este MD5(MessageDigest versiunea 5). O proprietate importantă a algoritmului MD5, în plus faţă de cele enumerate mai înainte, este că e mult mai eficient de calculat decât DES sau RSA.

1.6.3 Algoritmul DES

Obiectivul unui sistem criptografic este de a face extrem de dificilă decriptarea unui mesaj pentru care nu se cunosc cheile potrivite. Pentru atingerea acestui obiectiv, proiectarea este confruntată cu două cerinţe contradictorii: să asigure o criptoanaliză foarte dificilă şi să certifice nivelul de securizare realizabil. In prezent se preferă criptarea care operează în mod repetat, în multe runde, asupra unui bloc de simboluri din mesajul de transmis. Aceste coduri sunt de tipul bloc cu iteraţii. Este o idee naturală, simplă şi eficientă, care împacă, cel puţin parţial, simplitatea (puţine operaţii primitive) şi complexitatea.

Folosirea unui număr redus de operaţii (ca XOR, substituţia, permutarea) este de dorit şi din punct de vedere al componentelor hardware necesare implementării unui algoritm de codificare. Până în prezent, alegerile din proiect au fost determinate mai degrabă de tehnologia disponibilă decât de teoria matematică dezvoltată. Spre exemplu, codul IDEA, folosit de la începutul anilor 1990, foloseşte în fiecare rundă: XOR, adunarea modulo 216, înmulţirea modificată modulo (216+1). Toate aceste operaţii sunt rapide pe procesoarele pe 16 biţi disponibile în momentul apariţiei algoritmului IDEA.

Tot din motive de simplitate constructivă (şi implicit cost redus) se foloseşte o aceeaşi porţiune de program sau un acelaşi cip atât la codificare, cât şi la decodificare. Un cifru Feistel ilustrează foarte convingător această idee. Blocul de intrare de 2t biţi este împărţit în două jumătăţi L0;R0 care devin după i runde Li,respectiv Ri. La fiecare rundă, jumătatea dreaptă a rundei precedente devine noua jumătate stângă: L i=Ri-1, iar noua jumătate dreaptă se obţine după operaţia sau exclusiv între jumătatea stângă precedentă şi o funcţie ce depinde de jumătatea dreaptă precedentă şi o subcheie a rundei Ki:Ri=Li-1 (Ri-1,Ki). Inversarea (trecerea de la jumătăţile actuale la cele ale rundei precedente) este imediată: Ri-1=Li şi Li-1=Ri f(Ri-1,Ki). (Se observă că formulele subzistă oricare ar fi funcţia f aleasă!). Decriptarea are loc rulând algoritmul în ordine inversă (ultima subcheie Kr de la criptare devine prima subcheie folosită la decriptare, ş.a.m.d.) şi permutând cele două jumătăţi ale textului cifrat.(Figura 11.28).

Page 362: licenta hatz

38Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

Figura 11.28 Schema algoritmului DES

1.6.4 Algoritmul RIVEST-SHAMIR-ADLEMAN (RSA)

Prima, şi cea mai importantă, implementare a PKC este RSA, numită după cei trei matematicieni de la MIT care au dezvoltat-o - Ronald Rivest, Adi Shamir şi Leonard Adleman. RSA este folosită în sute de produse software şi poate fi folosită pentru schimbul de chei, semnături digitale sau criptarea unor blocuri mici de date. RSA foloseşte un bloc de criptare de dimensiune variabilă, iar cheia este şi ea de lungime variabilă. Perechea de chei este derivată dintr-un număr foarte mare, n, care este produsul a doua numere prime alese după anumite reguli speciale, aceste numere pot avea fiecare mai mult de 100 de cifre, numărul n având mult mai multe cifre. Cheia publică conţine numărul n şi un derivat al unuia dintre factorii folosiţi pentru determinarea lui n; astfel un atacator nu poate determina factorii primi ai lui n (deci nu poate afla cheia privată) numai din aceste informaţii din acest motiv, algoritmul RSA este atât de sigur

1.6.4.1 Descrierea algoritmului RSA

Sistemul RSA este de tip exponenţial. În criptosistemul RSA cu cheie publica, un participant creează cheia sa publica şi secreta prin următoarea procedură:1. Se selectează aleator două numere prime mari, p şi q. Acestea ar putea avea, de exemplu 100 cifre zecimale.2. Se calculează n prin relaţia n=pq.3. Se alege un număr d relativ prim cu Φ(n) (unde Φ(n) este indicatorul lui Euler, iar în cazul de faţă va fi egal cu

Φ(n)=(p-1)*(q-1) şi d în intervalul [max(p,q)+1, n-1].4. Se calculează e ca fiind inversul lui d modulo Φ(n) ( pentru calculul lui e se poate utiliza o versiune extinsă a

algoritmului lui Euclid).5. Se declară perechea P=(e,n) drept cheie RSA publică.6. Se menţine secretă perechea S=(d,n), care este cheie RSA secretă.

Schema poate fi folosită cu succes într-un criptosistem cu chei publice astfel: se vor face publice e şi n, iar d va fi ţinut secret. În consecinţă, cheia publică este formată din perechea (e,n) iar cheia privată din perechea (d,n).

Page 363: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 39

1.6.4.2 Realizarea autentificării folosind RSA

Deoarece cifrarea şi descifrarea sunt funcţii mutual inverse, metoda RSA poate fi utilizata atât la secretizare, cât şi la autentificare. Fiecare utilizator A obţine modulul nA şi exponenţii eA şi dA. Apoi A va înregistra într-un fişier public cheia publică (nA, eA), în timp ce va ţine secretă pe dA.

Un alt utilizator B va putea cripta un mesaj M utilizând cheia publică a lui A:Mesajul criptat este CA(M)=M^eA mod nA (unde mod este restul împărţirii lui M^eA la nA ,, iar semnul ^

este ridicare la putere)La recepţie A va obţine mesajul clar prin decriptare:DA(CA(M)) = (M^eA mod nA) ^dA mod nA = M.Utilizatorul A va putea semna un mesaj M către B calculând:

DA(M) = M^dA mod nA,iar B va autentifica acest mesaj, utilizând cheia publică a lui A:

CA(DA(M)) = (M^dA mod nA) ^eA mod nA = M.Obţinerea mesajului la decriptare se bazează pe rezultate din teoria numerelor care arată că dacă p şi q sunt

prime şi n=p*q atunci: x^ymod n=x^(y mod (p-1)(q-1))mod n.Deci dacă la criptare avem c= m^e mod n atunci la decriptare trebuie să obţinem mesajul m conform

formulei m=c^d mod n.(m^e mod n) ^d mod n= m^(e*d) mod n=m^(e*d mod (p-1)(q-1)) mod n= utilizând rezultatele din teoria numerelor m^1 mod n= deoarece noi am

ales e*d să fie divizibil cu z=(p-1)(q-1) mExemplu:Să considerăm un exemplu care să ilustreze acest algoritm: Fie p=5 şi q=7 două numere prime;Produsul acestor două numere ţinute secrete este n=5*7=35 iar z=(p-1)*(q-1)=4*6=24.Fie e =5 astfel că e şi z sunt relativ prime, va rezulta d=29 , astfel ca ed-1 să fie divizibil cu zPentru a cifra mesajul, M=RETEA, acesta se va împărţi în blocuri de câte un caracter fiecare, unde A=00,

B=01, C=02,.D=03, E=04, F=05, G=06, H=07, I=08, J=09, K=10, L=11, M=12, N=13,O=14, P=15, Q=16, R=17,S=18, T=19, U=20, V=21, W=22, X=23, Y=24, Z=25 şi blanc=26: M=R E T E A = 17 04 19 04 00. Primul bloc se va cifra ca 17^5 mod 35(1419857mod35=12) =12 etc. Criptograma obţinută devine: C =12 09 24 09 00

La descifrare, fiecare literă în clar se obţine folosindu-se cheia secretă d:12^29mod 35(19781359483314150527412524285952mod35=17)=17 etc.

Alegând numere prime mai mari se pot obţine chei mai puternice(de ex pentru p=53 şi q=61 se obţine n=3233, iar pentru d=791 e devine=71 şi în acest caz se pot grupa literele câte două, deci pe 4 digiţi)

1.6.5 Protocoale de autentificare (Kerberos)

Inainte ca doi participanţi să stabilească un canal sigur între ei, adică să folosească DES sau RSA pentru a cripta mesajele pe care le transmit-trebuie să se asigure că celălalt participant este cine pretinde că este. Aceasta este problema autentificării. Dacă gândim această problemă în contextul unei relaţii client/server, atunci este de înţeles că server-ul doreşte să stabilească identitatea clienţilor: dacă clientului îi este permis să modifice sau să şteargă fişierul lui Popescu, atunci server-ul este obligat să se asigure dacă clientul este de fapt Popescu. Uneori clientul doreşte să verifice identitatea serverului. La urma urmei, nu se doreşte să se scrie date importante pe un server, numai pentru a descoperi mai târziu că a fost de fapt un proces impostor.Această secţiune descrie trei protocoale comune pentru implementarea autentificării. Primele două folosesc criptografie cu cheie secretă (DES) în timp ce a treia foloseşte criptografie cu cheie publică(RSA). Să notăm că adesea, în timpul procesului de autentificare, cele două părţi stabilesc cheia sesiunii care va fi folosită pentru asigurarea securităţii în timpul comunicaţiei. In continuare vom arăta cum se porneşte procesul.

1.6.5.1 Protocol „în trei faze”

Un protocol simplu de autentificare este posibil când cei doi participanţi care doresc să se autentifice unul pe celălalt - clientul şi serverul - partajează o cheie secretă. Această situaţie este analoagă cazului în care utilizatorul (clientul ) are un cont pe un sistem (pe server) şi atât clientul cât şi serverul ştiu parola pentru acel cont.

Clientul şi serverul se autentifică unul pe celălalt folosind un protocol simplu "în trei faze". In continuare vom folosi E(m.k) pentru a numi criptarea mesajului m cu cheia k iar D(m.k) pentru a numi decriptarea mesajului m

Page 364: licenta hatz

40Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

cu cheia k. Aşa cum se vede în figura 11.29 clientul selectează pentru început un număr aleator x şi îl criptează folosind cheia secretă, pe care o notăm ca fiind CHK (client handshake key). Clientul trimite apoi E(x,CHK), împreună cu un auto-identificator (ClientId) către server. Serverul foloseşte cheia care crede că corespunde clientului ClientID ( să o numim SHK acronim pentru-server handshake key) pentru a decripta numărul aleator. Serverul adaugă 1 la numărul pe care îl decriptează şi trimite rezultatul înapoi la client. El trimite de asemenea înapoi un număr aleator y care a fost criptat folosind SHK. In continuare clientul decriptează prima jumătate a mesajului şi dacă rezultatul este cu 1 mai mare decât numărul aleator x care este trimis serverului atunci ştie că serverul posedă cheia secretă. In acest moment clientul a autentificat serverul. Clientul decriptează de asemenea numărul aleator trimis de către server ( care ar trebui să returneze y) criptează acest număr + 1 şi trimite rezultatul serverului. Dacă serverul este capabil să refacă y+1, atunci ştie că clientul este cine pretinde că este.

Figura 11.29 Protocol de autentificare în trei faze

După al treilea mesaj, fiecare a fost autentificat faţă de celălalt. Al patrulea mesaj (în figura 11.29) este trimis de server clientului cu o cheie de sesiune(SK) criptată folosind SHK (care este egală cu CHK). De obicei clientul şi serverul folosesc SK pentru a cripta orice date viitoare care sunt trimise de unul celuilalt. Avantajul folosirii unei chei de sesiune este faptul că cheia secretă permanentă este folosită doar pentru un număr mic de mesaje, făcând dificilă misiunea atacatorului de a aduna date care ar putea fi utilizate pentru determinarea cheii.

Se pune întrebarea, de unde provin cheile de protocol ale clientului şi serverului. O posibilitate e ca ele să corespundă parolei tastate de către client; ClientId ar putea fi identificatorul sesiunii. Deoarece o parolă selectată de către utilizator poate fi nepotrivită (nesigură), este nevoie adesea de o modificare care să o transforme într-o cheie de 56 biţi pentru DES.

1.6.5.2 „Încrederea în a treia persoană”

Un scenariu mai plauzibil este că cei doi participanţi nu ştiu nimic unul despre celălalt, dar amândoi au încredere într-o terţă persoană. Această terţă persoană este câteodată numită server de autentificare şi foloseste un protocol pentru a ajuta cei doi participanţi să se autentifice unul pe celălalt. Sunt dealtfel mai multe variaţiuni ale acestui protocol. Cel descris aici este numit Kerberos şi este un sistem bazat pe TCP/IP dezvoltat la MIT.

In continuare numim cei doi participanţi pe care dorim să-i autentificăm ca fiind A şi B şi numim serverul de autentificare S. Protocolul Kerberos presupune că A şi B partajează o cheie secretă cu S, iar cele două chei le notează cu Ka, respectiv Kb. Ca şi înainte, E(m,k) semnifică mesajul m criptat cu cheia k. Aşa cum se vede în figura 11.30, participantul A trimite un mesaj serverului S care îl identifică pe el şi pe B. Serverul generează o cuantă de timp T, un timp de viaţă L şi o nouă cheie de sesiune K. Cuanta de timp T va fi folosită similar numărului aleator din metoda anterioară şi este de asemenea folosită împreună cu L pentru a limita timpul pentru care sesiunea K este validă. Participanţii A şi B vor trebui să se întoarcă la serverul S pentru a primi o nouă cheie de sesiune când expiră acest timp. Ideea aici este de a limita vulnerabilitatea oricărei chei de sesiune.

Page 365: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 41

Figura 11.30. Increderea în a treia persoană

Serverul S răspunde lui A cu un mesaj din două părţi. Prima parte criptează cele trei valori T, L şi K, împreună cu identificatorul pentru participantul B, folosind cheia pe care serverul o partajează cu A. Cea de-a doua parte criptează cele trei valori T, L şi K împreună cu identificatorul participantului A, dar de data aceasta folosind cheia pe care serverul o partajează cu B. E limpede că atunci când A primeşte mesajul va fi capabil să decripteze prima parte dar nu şi pe a doua. A trimite a doua parte lui B, împreună cu criptarea lui A şi T folosind noua cheie de sesiune K( A a fost capabil să refacă T şiK decriptând prima parte a mesajului primit de la S). In final B decriptează partea din mesajul primit de la A, criptat iniţial de către S şi astfel recuperează T, K şi A. Se foloseşte K pentru a decripta jumătate de mesaj criptat de către A şi după ce se constată că A şi T se regăsesc( sunt consistente) în cele două jumătăţi ale mesajului, se replică cu un mesaj care criptează T+1 folosind noua cheie de sesiune K. A şi B pot acum comunica unul cu celălalt folosind cheia secretă de sesiune K, pentru a asigura securitatea comunicării. Serverul se mai numeşte şi KDC-Key Distribution Center-centru de distribuţie a cheilor care după cum s-a văzut acţionează ca un intermediar între entităţi.

1.6.5.3 Autentificare cu cheie publică

Figura 11.31. Autentificarea cu cheie publică

Un alt tip de protocol de autentificare foloseşte criptarea cu cheie publică( de ex. RSA). El este mai utilizat deoarece cele două părţi nu trebuie să partajeze o cheie secretă, ele trebuie doar să cunoască cheia publică a celeilalte părţi. Aşa cum se vede în figura 9.31, participantul A criptează un număr aleator x, folosind cheia publică a lui B, iar B demonstrează că, cunoaşte cheia privată corespunzătoare decriptând mesajul şi trimiţând x înapoi lui A. A poate să se autentifice faţă de B în acelaşi mod.

In privinţa modului cum poate un participant să afle cheia publică a celuilalt participant, este tentant să credem că participanţii trebuie să-şi posteze cheile publice într-un BBS. Această abordare nu funcţionează deoarece ar fi posibil pentru participantul A să posteze propria cheie publică şi să pretindă că este cheia publică a lui B. Aceasta i-ar permite lui A să se dea drept B. In locul acestei metode, cheile publice trebuie obţinute de la o sursă sigură, numită de obicei autoritate de certificare(CA-certificate authority). Pe scurt, se merge la CA pentru a obţine cheia publică a unui alt participant şi trebuie să demonstrezi printr-un altfel de mecanism (exterior) că eşti cine spui că eşti când înregistrezi cheia publică la CA. In acest fel fiecare participant ştie doar o singură cheie publică, cea a CA-lui. Să notăm că în general este posibil să se construiască o ierarhie de CA-uri: se porneşte de la CA-ul rădăcină pentru a primi cheia publică pentru un CA de nivel 2 care îţi dă cheia publică a CA-ului de nivel 3 şi aşa mai departe până găseşti cheia publică a participantului cu care doreşti să comunici. CA-ul rădăcină va putea fi publicat printr-o altă sursă de încredere.O alternativă la ierarhia structurată ca un arbore este construirea unei plase neierarhizate. CA-Certification Authorities- Autoritatea de certificare leagă cheia publică de entitatea particu;ară ( persoană, ruter,etc.). Entitatea poate înregistra cheia ei publică cu CA

Page 366: licenta hatz

42Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

1.6.6 Protocoale de asigurare a integrităţii mesajelor

Câteodată celor doi participanţi care comunică, nu le pasă dacă cineva este capabil să citească mesajele pe care şi le trimit unul celuilalt, dar sunt îngrijoraţi de perspectiva ca un impostor să se dea drept unul dintre ei. Mai pe scurt, participanţii sunt interesaţi de integritatea mesajelor. Un mod de a asigura această integritate este de a cripta mesajul folosind DES cu CBC şi de a folosi restul ( ultimul bloc obţinut în urma procesului CBC) ca un cod de integritate a mesajului (MIC-message integrity code). Textul iniţial, împreună cu MIC, este transmis destinatarului cu MIC având rolul unei sume de control - dacă destinatarul nu poate reproduce MIC-ul folosind cheia secretă pe care o împarte cu expeditorul, atunci fie mesajul nu a fost trimis de către expeditor, fie a fost modificat între timp. Să notăm că nu este recomandată folosirea algoritmului DES împreună cu CBC pentru criptarea mesajului în vederea asigurării secretului şi generarea MIC-ului pentru păstrarea integrităţii, deoarece s-ar trimite mesajul criptat CBC cu ultimul bloc repetat. Deci, oricine ar dori să se interpună şi să modifice mesajul CBC ar putea lua valoarea ultimului bloc şi să-l transmită de două ori.

Această secţiune tratează trei metode de asigurare a integrităţii mesajelor. Prima foloseşte RSA pentru a produce o semnătură digitală. RSA folosit singur este destul de încet, dar folosit împreună cu MD5 este mult mai eficient. A doua şi a treia abordare foloseşte MD5 împreună cu RSA, pentru a garanta integritatea mesajului.

1.6.6.1 Semnături digitale folosind RSA

O semnătură digitală este un cod special, necesar pentru păstrarea integrităţii mesajului, codul putând fi generat de către un participant unic. Algoritmul cel mai uşor de înţeles este cel ce creează o semnătură RSA, care funcţionează în mod evident- deoarece participantul este unica persoană care îşi cunoaşte cheia privată, el/ea foloseşte acea cheie pentru a produce acea semnătură. Oricare alt participant poate verifica acea semnătură folosind cheia publică corespunzătoare. Cu alte cuvinte, pentru a semna un mesaj el se criptează folosind cheia privată, iar pentru a verifica semnătura se decriptează, folosind cheia publică a presupusului expeditor. In mod evident aceasta înseamnă că producerea unei semnături RSA este la fel de înceată ca şi RSA care este, după cum am văzut mai înainte, de două până la trei ordine de mărime mai încet decât DES. Observăm că folosirea cheilor este exact inversă relativ la folosirea lor pentru asigurarea secretului; expeditorul criptează cu cheia sa privată în locul cheii publice a destinatarului, iar destinatarul decriptează folosind cheia publică a expeditorului în locul cheii sale private.

Să notăm că s-a mai propus o semnătură digitală cunoscută ca DSS care este similară abordării descrise, exceptând faptul că foloseşte un algoritm alternativ, numit ElGamal, în loc de RSA.

1.6.6.2 MD5 cu cheie

Să ne amintim că MD5 calculează o sumă de control criptografică pentru un mesaj. Această sumă de control nu depinde de o cheie secretă, deci nu previne faptul ca un impostor să se pretindă drept altcineva şi să calculeze o sumă de control MD5 pentru acel mesaj. Totuşi, există două moduri de a folosi MD5 în combinaţie cu un algoritm cu cheie publică, cum ar fi RSA, pentru a implementa integritatea mesajului. Ambele abordări depăşesc problemele de performanţă inerenteîn folosirea algoritmului RSA.

Prima metodă, numită de obicei MD5 cu cheie, funcţionează după cum urmează: Expeditorul generează o cheie aleatoare k şi aplică MD5 asupra mesajului m şi cheii k. In practică, cheia k este ataşată, fie în fruntea, fie în spatele mesajului înainte de a aplica MD5; k este şters din mesaj odată ce MD5 îşi încheie execuţia. Cheia aleatoare este apoi criptată folosind RSA şi cheia privată a expeditorului. Mesajul original, cheia de control MD5 şi versiunea criptată a cheii aleatoare sunt apoi împachetate împreună şi trimise la destinatar. In continuare vom rezuma mesajul complet trimis la destinatar:

m+MD5(m+k)+E(k,privată)

unde MD5(s) reprezintă aplicarea algoritmului MD5 asupra textului s, iar a+b reprezintă concatenarea textelor aşi b.

Destinatarul reface cheia aleatoare folosind cheia publică RSA a expeditorului şi apoi aplică MD5 asupra concatenării acestei chei aleatoare cu corpul mesajului. Dacă rezultatul corespunde sumei de control trimisă împreună cu mesajul atunci acesta a fost trimis de către participantul care a generat cheia aleatoare.

1.6.6.3 MD5 cu semnătură RSA

Cea de-a doua metodă ce foloseşte MD5 împreună cu RSA funcţionează astfel: expeditorul aplică MD5 asupra mesajului original pe care doreşte să-l protejeze, producând suma de control MD5 şi semnează această

Page 367: licenta hatz

sumă de control cu propria sa cheie RSA. După cum se vede, expeditorul nu semnează întregul mesaj ci doar suma de control. Se transmite

Page 368: licenta hatz

Noțiuni privind arhitectura și securitatea rețelelor de calculatoare 43

apoi mesajul original, suma de control MD5 şi semnătura RSA pentru suma de control transmisă. Folosind notaţia de mai sus, aceasta înseamnă că expeditorul transmite:

m + MD5(m) + E(MD5(m),privata).

Destinatarul verifică mesajul, asigurându-se că semnătura este corectă, prin decriptarea semnăturii cu cheia publică a expeditorului şi comparând rezultatul cu suma de control MD5 trimisă împreună cu mesajul. Acestea două trebuie să fie egale.

1.6.7 Folosirea semnăturilor digitale pentru distribuirea cheilor

Am menţionat mai înainte faptul că semnăturile digitale pot fi folosite pentru construirea unei reţele de încredere prin care să fie distribuite cheile, ca o alternativă la o ierarhie strictă. Acum când cunoaştem modul de funcţionare al cheilor digitale, furnizându-ne o modalitate cu ajutorul căreia să putem spune " acest mesaj a fost creat de către participantul X şi nu a fost alterat" putem descrie abordarea propusă. Pentru a începe, participanţii A şi B schimbă cheile publice în timp ce sunt în aceeaşi cameră, adică pot să verifice că, cheile corespund într-adevăr identităţii persoanelor respective. Mai târziu, A schimbă cheia publică cu C. A poate folosi acum propria sa cheie privată pentru a semna cheia publică a lui C şi să o trimită lui B. Cu alte cuvinte, A trimite un mesaj care spune " Am fost în aceeaşi cameră cu C şi cred că aceasta este cheia publică a lui C" şi apoi semnează mesajul folosind propria sa cheie privată. Deoarece B are o copie de încredere a cheii publice a lui A, B poate verifica semnătura acestui mesaj, Atâta timp cât B are încredere că A nu a fost înşelat pentru a semna cheia lui C, B poate fi sigur că deţine o copie sigură a cheii publice a lui C. Deci, o strategie rezonabilă pentru C este să aibă cheia sa copiată de o mulţime de persoane şi cu un pic de noroc, oricine doreşte să comunice cu C va fi capabil să găsească o persoană, în care are încredere, dintre persoanele care au cheia publică a lui C. Desigur că pot exista un număr arbitrar de legături în această reţea de încredere, dar dacă o persoană din lanţ semnează o cheie de care nu este sigură că aparţine adevăratei persoane, atunci lanţul de încredere este rupt.

1.6.8 Protocoale de securitate a aplicaţiilor

Securizarea se poate face la diferite nivele. La nivel aplicaţie se pot securiza mesajele de e-mail folosind sistemul PGP(pretty good privacy) care este standardul de facto în acest caz. Utilizează criptografia cu cheie simetrică, criptografia cu cheie publică, funcţii hash şi semnătura digitală La nivel transport avem securizarea privind comerţul electronic cu ajutorul protocoalelor: protocolul SSL(Security Socket Layer) şi SET(Secure electronic transactions).

SSL(Security Socket Layer), cu varianta mai nouă TLS(Transport Layer Security) este utilizat între navigatoarele de Web şi serverele pentru e-comerce(shttp-secure http). Serviciile de securitate ale protocolului SSL asigură: autentificarea serverului, criptarea datelor, autentificarea clientului(opţional).

Sesiunea de autentificare a serverului:SSL permite navigatorului includerea cheii publice pentru autoritatea de certificare-CA; Navigatorul cere serverului certificatul trimis de autoritatea de certificare CA;Navigatorul utilizează cheia publică de la CA pentru a extrage cheia publică serverului; Vizitează meniul de securitate al navigatorului pentru a vedea CA-ul său.

Sesiunea de criptare a datelor:Navigatorul generează cheia simetrică de sesiune, o criptează cu cheia publică a serverului şi trimite cheia criptată la server;

Utilizând cheia sa privată, serverul decriptează cheia de sesiune;Navigatorul şi serverul cad de acord că mesajele viitoare vor fi criptate;Toate datele trimise într-un soclu TCP(de client sau server) sunt criptate cu cheia de sesiune;

SSL este baza TLS(Transport Layer Security). SSL poate fi utilizat şi pentru aplicaţii non Web precum IMAP.Atentificarea clientului poate fi făcută cu certificatul clientului.

Securizarea tranzacţiilor electronice(SET-Secure Electronic Transactions).Protocolul a fost proiectat pentru tranzacţii, făcute pe Internet şi plătite cu carduri. Asigură servicii de

securitate pentru 3 participanţi: consumatorul, comerciantul şi banca comerciantului.Toate trebuie să aibă certificate. SET specifică înţelesul legal al certificatelor şi anume:

împărţirea responsabilităţilor pentru tranzacţii;

Page 369: licenta hatz

44Noțiuni privind arhitectura și securitatea rețelelor de calculatoare

numărul cardului consumatorului trecut la banca vânzătorului fără ca acesta să-l vadă în clar; Aceasta previne furtul numărului de card de către vânzător.

Există trei componente soft:Portofelul(trusa) navigatorului; Serve

Page 370: licenta hatz

rul negustorului;

Poarta de primire.

Securitatea la nivel reţea (NLS-Network Layer Security)Trimite gazdei date criptate în pachete de tip IP.Autentificarea la nivel

reţea se face de gazda destinaţie care poate autentifica adresa sursă IP. Există două protocoale:Protocolul de autentificare a antetului( AH- authentification header) şi protocolul de încapsulare a plăţii securizate (ESP-encapsulation security payload). Dialogul sursă destinaţie pentru protocoale AH şi ESP:se creează la nivel reţea un canal logic numit acord de serviciu;Fiecare SA este unidirecţional.

In mod unic determinat de:protocolul de securitate(AH sau ESP);adresa sursă IP;identificator de conectare pe 32 de biţ

Page 371: licenta hatz
Page 372: licenta hatz

1. TEHNOLOGII XML

Autor: Robert Buchmann

1.1 Rolul XML în garantarea interoperabilității

Capitolul de față abordează problema asigurării interoperabilităţii, factor fundamental al eficienţei sistemelor informatice ce deservesc organizaţiile din spaţiul economic virtual oferit de Internet. Impactul interoperabilităţii este unul decisiv în fezabilitatea emergenţei afacerilor în mediul virtual, în primul rând sub aspectul reducerii costurilor şi, ca un tip particular de cost, al reducerii latenţei în comunicaţiile de afaceri. Aria în care acţionează interoperabilitatea este una a cărei funcţionare decide în favoarea sau împotriva adoptării sistemelor distribuite şi colaborative, paradigmă fundamentală în contextul economiei Web globale. Ideal, este vorba de asigurarea dialogului nemijlocit între entităţile supersistemului informaţional al cărui infrastructură este Internetul, un dialog care trebuie să minimizeze intervenţia umană şi să asigure fluiditatea fluxurilor de informaţii între nodurile sistemului. Concret, eforturile de asigurare a interoperabilităţii trebuie să înceapă de la nivelul organizaţiilor, pe baza instrumentelor standard cu disponibilitate globală cum este XML. În practică nodurile cele mai problematice sunt sistemele informatice moştenite, a căror calitate esenţială este că sunt fiabile (fiind îmbunătăţite în timp), amortizate şi nu mai implică costuri de transformare a sistemului informaţional. Pe de altă parte, interoperabilitatea sistemelor moştenite creează costuri de interfaţare care pot să anuleze fezabilitatea interoperabilităţii automate, blocând organizaţiile într-o sferă de manifestare în care primează redundanţa, dialogul asincron, conversiile incorecte de informaţii şi managementul strict intuitiv, deviat de pierderile informaţionale, după cum arată lucrarea Using XML with Legacy Business Applications [Rawlins03]. Astfel, interoperabilitatea trebuie să devină o prioritate a managementului modern, în care deciziile trebuie suportate de instrumentele oferite de sisteme informatice capabile să deruleze schimburi şi conversii de date oportune, conform XML: A Manager's Guide [Dick02]. XML este un standard care şi-a propus iniţierea unei convergenţe tehnologice în sistemul Web şi asigurarea unei coloane vertebrale ca infrastructură software pentru interoperabilitatea sintactică şi, în perspectivă, semantică şi pragmatică între sistemele informatice. Capitolul oferă un tablou de ansamblu asupra modului în care XML realizează acest deziderat, punctat cu unele exemple practice.

Strâns legat de eforturile de omogenizare a spaţiului economic virtual este şi conceptul de document, al cărui încercare de definire a fost o prioritate a forurilor Uniunii Europene în ultimii ani, în încercarea de a standardiza un concept care să unifice semnificaţiile atribuite de mediul juridic, mediul economic, tehnologia informaţiei şi alte domenii în care documentul reprezintă o unitate de reprezentare a informaţiei. Ca specializare a conceptului de document, în domeniul informaticii economice raportul este conceptul care se cere unificat, atât ca definiţie generală, cât şi ca taxonomie şi structură.

XML propune o astfel de convergenţă. În primul rând, la nivelul general al documentului, XML anulează divergenţele între formele tradiţionale de reprezentare a informaţiei simbolice – structuri de text, structuri de date, limbaje formale şi instrucţiunile lor, structuri de cunoştinţe etc. Documentul XML capătă versatilitatea necesară şi un polimorfism care îi permite să fie tratat în funcţie de scopurile receptorului, ca program ce

Page 373: licenta hatz

4 Robert Andrei Buchmann

trebuie executat, ca text ce trebuie formatat, ca structură de date ce trei interogată sau transferată, ca structură de cunoştinţe ce trebuie inferată. De asemenea, XML deserveşte paradigma MVC (Model-View-Control), prin separarea conţinutului informaţional brut (modelul de date) de forma de prezentare (viziunea) şi de entitatea sau agentul de procesare(controlul).

Perspectivele sunt legate de transformarea spaţiului economic virtual într-un spaţiu semantic, subordonat paradigmei Semantic Web. În sfera aplicaţiilor strict economice, primele iniţiative sunt legate de crearea taxonomiilor XBRL, care nu se limitează la a modela structurile de date şi conceptul unificat de raport, ci creează o bază de asociaţii semantice între structurile respective. Atât modelul de date XBRL cât şi baza de asociaţii semantice sunt create cu vocabulare XML. Mai departe, paradigma Semantic Web propune o convergență între metode provenind din inteligența artificială și suportul existent al tehnologiilor Web, dintre care XML garantează stratul de interoperabilitate sintactică.

XML (limbajul de marcare extensibil) este încununarea eforturilor de impunere a limbajelor de marcare într-o lungă istorie a standardizărilor şi a generaţiilor de limbaje formale. În prezent, popularitatea XML îl cimentează la baza tuturor soluţiilor software moderne, având în vedere că orientările actuale au în vedere distribuirea cât mai facilă a datelor pe principii colaborative, între orice tipuri de aplicaţii, organizaţii sau utilizatori. Originile limbajului XML se găsesc în limbajul SGML (limbaj standard general de marcare), care a stabilit şi standardizat principiile limbajelor de marcare. XML se supune acestor principii de aşa natură încât documentele XML să poată fi considerate documenteSGML particularizate (cu constrângeri/reguli specifice aplicate peste principiile generale), cu câteva excepţii1. Din acelaşi SGML s-a dezvoltat, printr-un proces similar de particularizare, şi HTML (limbaj de marcare a hipertextului), folosit în general la construirea documentelor hipertext şi, în particular, la construirea paginilor Web.

Problema imediată care se ridică este înţelegerea marcatorilor - trebuie garantat faptul că atât emiţătorul cât şi receptorul mesajului sunt capabili să interpreteze marcatorii. Acest aspect este condiţia fundamentală a interoperabilităţii.

Într-o definiţie de lucru, putem afirma că marcatorul este un simbol sau un set de simboluri care se aplică asupra informaţiei pe care o însoțesc şi are scopul de a-i stabili ori modifica:

formatul (modul de prezentare, de afişare) – utilizare consacrată de marcatoriiHTML;structura (relaţia dintre componentele mesajului) – utilizare consacrată de marcatorii DIV și SPAN din HTML și de limbajul XML;

semantica (sensul, interpretarea, contextul) – utilizare consacrată de marcatoriiMETA din HTML și de modelul RDF;pragmatica (potenţialul de utilizare, operaţiile la care va fi supusă) – utilizare consacrată de instrucțiunile de procesare din XML, dar și din alte limbaje.În lucrul cu informație marcată:

emiţătorul informaţiei este creatorul acesteia (uman sau software);receptorul informaţiei poate fi un utilizator uman (preocupat de lizibilitate şi

modul de prezentare) sau un receptor software (un program care procesează

1 Cazurile în care această incluziune nu este posibilă apar datorită faptului că XML a fost proiectat pentru utilizare internaţională, deci suportă seturi de caractere internaţionale (non-ASCII) în timp ce SGML a fost proiectat pentru setul de caractere de bază.

Page 374: licenta hatz

Tehnologii XML 5

informaţia, un program care o afişează, o bază de date sau de cunoştinţe care o depozitează etc).Pornind de la această observaţie, modul de utilizare a marcatorilor este strâns legat

de capacitatea de interpretare a acestora de către receptor (uman sau software). Interoperabilitatea este asigurată atunci când atât emiţătorul cât şi receptorul atribuie acelaşi scop unui set comun de marcatori care reprezintă vocabularul de marcatori. Interoperabilitatea este o condiţie esenţială în distribuirea informaţiei şi poate avea loc la diferite nivele:

interoperabilitatea sintactică, asigurată atunci când toţi emiţătorii şi receptorii se pun de acord asupra regulilor de structurare a informaţiei cu ajutorul marcatorilor și a terminologiei acestora (reguli impuse prin vocabularele XML);interoperabilitatea semantică, garantată atunci când toţi emiţătorii şi receptorii se pun de acord asupra semnificaţiei şi modurilor de utilizare atribuite informaţiei marcate şi marcatorilor (necesită modele mai avansate precum RDF).Paradigma marcatorilor se adresează acoperirii întregului spaţiu Web cu metode

de marcare şi vocabulare universale, în condiţiile în care emiţătorii şi receptorii sunt toate entităţile umane sau software care se conectează la acest spaţiu. Principalul avantaj al interoperabilităţii este reducerea efortului (deci a costului) în ce priveşte conversia informaţiei între sisteme diferite, ceea ce, ţinând cont de efectul de reţea implicat de distribuirea pe scară globală, aduce o reducere de efort absolut necesară.

1.2 Structura și corectitudinea documentelor XML

1.2.1 Elementele documentului XML și buna lor formare

XML consolidează paradigma marcatorilor într-un limbaj standard care îşi propune să ofere în acelaşi timp posibilităţi de formatare a documentelor, de structurare, de caracterizare semantică a informaţiei, precum şi de garantare a unui mod de procesare a lor. XML are posibilităţi de exploatare nelimitate datorită faptului că este un metalimbaj. Aceasta înseamnă că standardul XML nu oferă un set fix de instrucţiuni interpretabile/compilabile, ci oferă:

un set de reguli sintactice, regulile de bună formare, care trebuie respectate de orice document XML şi care impun structura pe care trebuie să o respecte orice marcator XML; regulile de bună formare sunt testate de parsere (convertoare menite să extragă datele din cod XML);un limbaj auxiliar, Document Type Definition (DTD), care permite definirea altor limbaje (vocabulare) bazate pe sintaxa de bună formare XML; conformitatea față de vocabulare e testată de validatoare (programe menite să valideze combinația demarcatori și atribute folosite într-un document).

Astfel, puterea XML nu este legată doar de posibilitatea de a reprezenta documente și structuri de date complexe într-o formă serializată, ci și de crearea de vocabulare (limbaje de tip XML) cu marcatori şi atribute personalizate, cu care apoi se construiesc documente, structuri de date sau programe, în funcţie de scopul propus şi de potenţialii receptori. Dacă se urmăreşte distribuirea de documente XML către alţi utilizatori sau alte programe, trebuie ca regulile după care s-au construit marcatorii personalizaţi şi semnificaţia lor să fie aduse la cunoştinţa tuturor receptorilor potențiali. Aceasta necesită un efort suplimentar, dar asigură posibilităţi nelimitate de personalizare şi de

Page 375: licenta hatz

6 Robert Andrei Buchmann

adaptare/extindere sintactică pentru orice platforme hardware şi software. Exemple de vocabulare XML consacrate sunt MathML (limbaj de marcare matematic) şi CML (limbaj de marcare în chimie), XSLT pentru transformarea de documente XML, XSDL e chiar un vocabular XML pentru creare de vocabulare XML (ca alternativă la DTD).

Nu trebuie să se înţeleagă că orice document XML necesită crearea în prealabil a unui vocabular. Se pot crea documente care respectă doar regulile de bună formare, folosind marcatori oarecare, improvizaţi pentru nevoi imediate, ce nu au fost definiţi în prealabil de nici un vocabular. Aceasta presupune că documentul e de uz intern sau are o distribuție limitată (structura sa este deja cunoscută de toți potențialii săi receptori). Chiar și un receptor care nu cunoaște structura în prealabil poate să extragă informațiile din documentul XML datorită modelului arborescent DOM, ce garantează că orice document XML corect sintactic va putea fi parcurs ca un arbore ce stochează date în nodurile sale. Totuși cunoașterea structurii sau definirea sa precisă cu ajutorul unui vocabular avantajează în ce privește înțelegerea modului în care trebuie procesate datele după extragerea lor din document sau a modului în care ar trebui formulat un răspuns la acele date. În schimb, în contextul interoperabilităţii la nivel Web sau al organizaţiilor mari, în care documentele XML devin complexe şi sunt schimbate automat între emiţători şi receptori care nu se cunosc în prealabil, crearea unui vocabular devine necesară ca bază contractuală pentru schimbul de informaţii într-o manieră consistentă şi fără ambiguităţi de interpretare.

Versatilitatea codului XML poate fi înțeleasă pornind de la următorul set de marcatori:

<ListaPreturiFructe><Fruct><Denumire>Mere</Denumire><Pret>10000</Pret></Fruct><Fruct><Denumire>Pere</Denumire><Pret>12000</Pret></Fruct></ListaPreturiFructe>

Acest document ar putea fi văzut ca:7 un document ce trebuie formatat datelor în vederea afişării, dacă atribuim fiecărui

marcator un stil (se poate folosi chiar limbajul CSS în acest scop);8 o structură de date prin care se transferă date între două baze de date; practic,

exemplul de mai sus poate reprezenta tabelul unei baze de date de forma:

Fruct PretMere 10000Pere 12000

Avantajul XML faţă de forma tabelară, consacrată de bazele de date relaţionale, este că marcatorii imbricaţi pot indica relaţii de apartenenţă/subordonare (relaţii tată-fiu între datele marcate), în timp ce câmpurile unui tabel se află doar într-o relaţie de alăturare.

5 O structură de date arborescentă ce poate fi interogată (așa cum bazele de date relaționale se pot interoga cu SQL, pentru XML avem limbajul de interogare XPath sau funcțiile de parcurgere a arborelui DOM):

Page 376: licenta hatz

Tehnologii XML 7

Page 377: licenta hatz

ListaFructe

Fruct Fruct

Denumire Pret Denumire Pret

Mere 10000 Pere 12000Figura 12.1. Forma arborescentă (simplificată) a unei structuri de date XML

Flexibilitatea XML poate fi arătată prin faptul că documentul poate suferi transformări. Aceleaşi date ar putea fi prezentate în următoarea formă, tot de tip XML, dar cu o structură de marcatori diferită:

<ListaPreturiFructe> <Fruct Pret="10000"> Mere</Fruct><Fruct Pret="12000"> Pere</Fruct></ListaPreturiFructe>

sau:

<ListaPreturiFructe><Fruct Denumire="Mere" Pret="10000" /> <Fruct Denumire="Pere" Pret="12000" /> </ListaPreturiFructe>

Transformarea documentelor XML se poate realiza printr-o serie de operaţii de restructurare a marcatorilor, prin programe capabile să manipuleze arbori XML sau cu ajutorul limbajului specific de transformare – XSLT (bazat pe interogări XPath). Ca alternativă, funcțiile modelului DOM pot și ele să extragă orice informații din documentul XML și să le regenereze într-o altă structură, în alt document.

Raţiunile după care alegem modul de structurare a marcatorilor ţin de claritatea conţinutului pentru utilizatorul uman, de relaţiile de subordonare (tată-fiu) între date şi de optimizarea pentru procesare. În ce priveşte ultimul aspect, fişierele ar trebui să aibă dimensiune cât mai mică, pentru transfer rapid în reţea. În plus se ştie că majoritatea programelor care procesează XML lucrează mai rapid cu atribute decât cu marcatori, deci transformarea marcatorilor copii ai lui <Fruct> în atribute ale acestuia ar fi o alegere în sensul optimizării.

Unitatea fundamentală a unui document XML este nodul. Majoritatea nodurilor sunt de tip element (marcatorii efectivi) însoțite de noduri de tip atribut. Acestora li se alătură tipuri de noduri corespunzătoare unor componente care nu e obligatoriu să fieîntâlnite într-un document: comentariul, instrucțiunea de procesare etc. Două noduri importante, între care adesea se face confuzie sunt:

Page 378: licenta hatz

8 Robert Andrei Buchmann

Elementul document – este marcatorul rădăcină, care trebuie să fie unic și să conțină tot conținutul documentului cu excepția unui prolog (declarația XML) și a unui eventual vocabular integrat;Nodul document – este documentul în sine, ce conține obligatoriu prologul și elementul document.Elementele unui document XML sunt:

Declaraţia XML;Elementele şi atributele lor;Datele de tip caracter (conținutul textual);Referinţele entităţilor;Instrucţiunile de procesare;Comentariile;Invocarea DTD (dacă documentul se supune unui vocabular).

În general conceptul de vocabular XML a îmbogăţit noțiunea de validare mult dincolo de accepţiunea sa de bază, care era testarea de valori faţă de şabloane sau tipuri de date preimpuse asupra unor câmpuri. Putem considera în prezent următoarele funcţii ale validării XML, ca proces de verificare a unui document-instanţă faţă de un document-clasă(vocabular):

Validare de conţinut şi structură:3.21. Validarea imbricărilor XML şi a relaţiilor dintre datele asigurate

de elemente, atribute şi conţinutul marcatorilor;4.1.1.Validarea de valori pe bază de şabloane şi intervale;← Validarea restricţiilor de cardinalitate şi

unicitate; Bază contractuală pentru interoperabilitate:← Instanţele XML transferate între organizaţii trebuie să fie tratate

echivalent de ambele părţi;Metodă de augmentare a instanţelor:

← Validarea poate adăuga informaţie la o instanţă, prin valori implicite şi diverse normalizări;

Suport pentru procesare şi documentaţii:← Un vocabular oferă metadate ce descriu posibilele utilizări, mapări

spre modelul relaţional sau alte modele ori informaţii ce pot fi capturate de interfeţele cu utilizatorul generate dinamic (intervalele admise de valori, şabloanele şi tipurile impuse pot sta la baza unor obiecte de formular);

Validarea interogărilor:← Interogările adresate unei colecţii de instanţe în mod implicit nu ţin

cont de restricţiile de validare ale instanţelor. Numeroase erori de interogare pot fi întâmpinate cu ajutorul motoarelor de interogare de tip schema-aware, care blochează interogările asupra unor date nepermise de vocabular, înainte de a se pierde timpul cu consultarea instanţelor2;

Polimorfismul procesărilor:← Este o problemă direct legată de interogările valide, mai precis de

fenomenul schema-awareness, de data asta în ce priveşte procesările

Page 379: licenta hatz

2 Indicăm proiectul Saxon al grupului Saxonica, ce oferă astfel de capabilităţi.

Page 380: licenta hatz

Tehnologii XML 9

(aplicare de stiluri, transformări de arbori etc.). Tipizarea datelor permite modificarea comportamentului unor operaţii (ex: sortarea lunilor calendaristice);

Limbajele de creare a vocabularelor XML cu succes major în prezent sunt:DTD, care a consacrat denumirea tip de document în loc de vocabular sau clasă de documente. Rezumăm caracteristicile DTD:

o Permite crearea vocabularelor interne, ce însoţesc documentul;o Are suport general, fiind adoptat odată cu standardul XML original; o Fixează structura instanţelor XML (ordine, ocurenţe, cardinalitate,

imbricare);o Oferă tipizare slabă şi valori implicite doar pentru atribute;o Permite crearea de notaţii pentru diverse formate de date referite în

instanţă;o DTD nu creează documente XML bine formate, folosind o sintaxă de

tip SGML. Aceasta are implicaţii asupra complexităţii instrumentelor de validare DTD;

o Suportul pentru spaţii de nume este rudimentar.XSDL este rezultatul unor soluţii convergente precum XDR3, SOX4 şi

DDML5. Acest limbaj a consacrat denumirea schemă de documente pentru vocabular. XSDL oferă:

o Tipizare puternică;o Suport pentru spaţiile de nume; o Derivarea tipurilor;o O modularitate ce permite convertirea facilă a documentelor XML în

ierarhii de structuri de date, cu trăsături obiectuale;o Transferă indicaţii de procesare şi documentaţie complexă spre

consumator la nivelul clasei de documente;o Nu permite definirea unui şablon permis pentru elementul rădăcină; o Nu asigură coocurenţa (ocurenţa unui element în funcţie de altul);o Are încă un suport inconsistent în rândul instrumentelor software,

comparativ cu DTD;Relax NG:

o Oferă multe din avantajele XSDL faţă de DTD;o Oferă reguli mai complexe pentru ocurenţa atributelor; o Oferă model polimorf de conţinut al elementelor; Permite modele de conţinut al elementelor nondeterministe şi reguli

relaxate de ordonare a elementelor;o Oferă o gamă foarte redusă de tipuri de date implicite;o Nu transferă informaţii privind procesarea şi documentaţie; o Nu oferă capacităţi de moştenire în sens obiectual;← Nu transferă informaţii privind procesarea şi documentaţie spre

consumator;Schematron:

11. XML Data Reduced, prima soluţie de creare a vocabularelor XML oferită de Microsoft

12. Vocabular pentru XML orientat-obiect, Schema for Object-oriented XML13. Limbaj pentru marcarea definiţiilor de documente, Document Definition Markup Language, prima soluţie care a

propus înlocuirea declaraţiilor DTD cu descrieri pe bază de elemente XML.

Page 381: licenta hatz

10 Robert Andrei Buchmann

o Diferă de celelalte limbaje prin faptul că formează vocabulare bazatepe seturi de reguli şi nu pe declararea modelelor de elemente

opermise;Oferă posibilitatea coocurenţei şi datorită acesteia coopereazăfrecvent cu XSDL;

o Necesită anticiparea erorilor plauzibile şi nu a stărilor valide,acceptabile.

1.3 Procesarea documentelor XML

1.3.1 Modelul SAX

Modelul SAX nu este un standard, ci este o realizare a grupului de lucru XML-Dev ca alternativă la procesarea XML prin DOM, folosind o fereastră de memorie limitată în locul încărcării întregului document în memoria internă. S-au implementat deja un număr mare de parsere SAX, inclusiv pe platforme Microsoft (MSXML versiunea 3.0).Independenţa faţă de limbaj nu este la fel de mare ca în cazul DOM. Majoritatea implementărilor sunt găzduite de Java, dar există și excepții.

Odată ce fereastra de memorie a fost definită, modelul SAX prevede gestionarea evenimentelor care intervin în timpul procesului de citire a şirului de caractere ce constituie codul XML, prin fereastra respectivă. Aşadar, este o interfaţă de programare bazată pe evenimente şi manageri de evenimente. Evenimentele sunt declanşate de apariţia în şirul de caractere a delimitatorilor de bună formare XML: deschiderea unui marcator, închiderea unui marcator, apariţia conţinutului textual etc.

Procesul de citire a şirului de caractere are loc în paralel cu alte două procese:declanşarea evenimentelor pe măsură ce marcatorii trec prin fereastra de citire, are loc automat prin parser, care transmite spre managerii de evenimente numele elementului, atributele şi alte detalii;

menţinerea stărilor asociate elementelor relevante din documentStările SAX asigură localizarea precisă a datelor citite cu SAX în lipsa unei viziuni

complete asupra documentului. Stările SAX nu sunt asigurate de modelul SAX în mod implicit. Acestea trebuie gestionate de către programator prin variabile de stare. Un acelaşi element poate să apară de mai multe ori, în variate contexte. SAX declanşează un evenimente la apariţia elementului şi indică despre ce element este vorba, dar nu indică nici a câta apariţie a elementului este şi nici la ce adâncime în arbore. Variabilele de stare sunt modificate în cadrul managerilor de evenimente şi în mod uzual sunt de două tipuri:

variabile booleene cu rol de comutator asociate elementelor relevante (cu comutare true/false în funcţie de poziţia curentă a procesului de citire faţă de elementul relevant) – acestea indică dacă ne aflăm în element sau în afara lui, dacă a trecut elementul prin fereastra de citire sau nu şi alte situaţii cu caracter boolean;

variabile contor incrementate la mai multe deschideri succesive de element(caz în care măsoară nivelul pe care se află fereastra de citire în arbore) sau la mai multe apariţii succesive ale elementelor relevante (caz în care se numără apariţiile unui element în document sau în lista fraţilor).

Page 382: licenta hatz

Tehnologii XML 11

Asociind variabile de stare elementelor relevante se poate stabili cu precizie poziţia ferestrei de citire SAX în arborele elementelor şi se pot realiza operaţii cu caracter excepţional (care nu se repetă pentru fiecare element).

Considerând exemplul:<produse><produs>Televizor</produs><produs>Calculator</produs></produse>

…evenimentele declanşate la citirea acestui şir de caractere vor fi, în ordinea declanşării:

13. startElement – defineşte starea aferentă elementului produse;14. startElement – defineşte starea aferentă elementului produs;15. characters – defineşte starea aferentă valorii Televizor;16. endElement – anulează starea aferentă elementului produs;17. startElement – defineşte starea aferentă elementului produs (al doilea);18. characters – defineşte starea aferentă valorii Calculator;19. endElement – anulează starea aferentă elementului produs (al doilea);20. endElement – anulează starea aferentă elementului produse.Fiecăreia din stările relevante dintre cele indicate i se pot asocia variabile de stare,

pentru a contoriza imbricările și numărul de apariții ale unui element.

1.3.2 Modelul DOM

Modelul DOM este una din cele două soluţii consacrate (alături de SAX) pentru extragerea informaţiilor dintr-un document XML, indiferent că acestea sunt stocate în numele sau valorile elementelor, numele sau valorile atributelor sau în structurile XML auxiliare. DOM nu este o aplicaţie în sine, ci un model abstract implementat la nivelul parserelor, ca o colecţie de interfeţe de programare (API) ce folosesc paradigma obiectuală pentru a transpune conţinutul oricărui document conform cu standardul XML în clase, obiecte şi metode. Astfel, DOM este independent de platformă şi limbajul de programare, fiind considerat un strat între parser şi aplicaţiile consumatoare de XML. Practic, parserul citeşte date din sursa XML şi alcătuieşte arborele DOM translatând imbricările între marcatori în relaţii tată-fiu şi unităţile XML în noduri ale arborelui.

Nucleul DOM, numit DOM Core, este un set de interfeţe de programare de uz general la care se adaugă module opționale precum cele adaptate pentru manipulare de de stiluri HTML, care nu apar neapărat în toate implementările şi dintre care indicăm:

DOM Views – pentru manipularea unei reprezentări particulare a unui document;

DOM Events – un sistem de evenimente generice;DOM HTML – pentru manipularea de HTML clasic;DOM CSS – pentru manipulare dinamică a foilor de stil;DOM Traversal an Range – pentru identificarea şi parcurgerea unor porţiuni

de document care nu reprezintă neapărat colecţii de noduri (fragmente, conţinut textual).

În modelarea DOM, pornim de la exemplul de mai jos, salvat în fişierul fisier.xml:

<produse><produs cod="p01">Televizor</produs> </produse>

Page 383: licenta hatz

12 Robert Andrei Buchmann

Un parser DOM va crea din acest exemplu următoarea ierarhie de noduri:

Document NodeDocumentul complet

NodeList

Element Node<produse>

NodeList

Element Node<produs>

NodeList NamedNodeMap

Character Data AttrNodeText Node ID=”p01”„Televizor”

Figura 12.2. Modelul arborescent creat de un parser DOM

Nodul document reprezintă întreg documentul în ansamblu. Este important să se evite confuzia între nodul rădăcină (nodul document) şi elementul rădăcină (elementul document), care este primul element XML din document, dar este un fiu al nodului rădăcină, alături de declaraţia XML. Prin aceasta, sugerăm că nodurile DOM sunt de diferite tipuri: elemente, atribute, conţinut textual, comentarii, instrucţiuni de procesare etc. Este important de reţinut că nodurile atribute sunt tratate ca proprietăţi ale nodurilor elemente şi nu ca noduri fii ale acestora, ceea ce afectează rezultatul anumitor operaţii de procesare a fiilor unui nod [Williams03].

Node List este o interfaţă necesară manipulării colecţiilor de noduri ordonate. Faptul că o colecţie de noduri poate să apară chiar în subordinea nodului rădăcină, indică faptul că acesta poate avea şi alţi fii decât elementul rădăcină: declaraţia XML, invocarea DTD, un comentariu etc. Named Node Map este o interfaţă pentru manipularea colecţiilor neordonate de noduri referite prin nume, cum sunt colecţiile de atribute.

Cele două interfeţe sunt specializări care moştenesc interfaţa generică Node, prin care se manipulează toate nodurile DOM. Alte interfeţe specializate din Node sunt Element,

Page 384: licenta hatz

Tehnologii XML 13

Document, Text, Character Data şi Attr al căror rol poate fi intuit. Manipularea arborelui poate avea loc pe două căi:

Generic, prin manipularea interfeţei Node;Ierarhică, prin manipularea specializărilor interfeţei Node.Manipularea generică, denumită şi abordarea aplatizată, este utilă în lucrul cu

documente foarte mari în care performanţa primează. Manipularea ierarhică permite însă un mod de lucru mai facil prin exploatarea unor proprietăţi redundante.

Disponibilitatea parserelor şi implementărilor DOM pe variate platforme şi sub diverse limbaje de programare gazdă face ca platforma să nu fie un factor în alegerea acestui model.

Un factor esenţial în acest sens este dimensiunea documentului, care afectează performanţa drastic deoarece arborele DOM este încărcat integral în memoria internă şi ocupă de regulă de 10 ori mai multă memorie decât documentul XML care stă la baza sa. De asemenea, performanţa este afectată şi de numărul nodurilor element din document, acestea fiind mai dificil de procesat decât atributele şi alte tipuri de noduri. O alternativă superioară ca performanţe este modelul SAX, care încarcă doar fragmente ale documentului XML într-o fereastră de memorie limitată, prin care se derulează şirul de caractere ce alcătuieşte documentul. Utilizarea fragmentelor de document sunt foarte utile în operaţii de citire sau în scrierile unui număr redus de informaţii însă afectează performanţa negativ dacă se doresc actualizări masive ale documentelor mari, fiind necesară o rederulare repetată pentru localizarea punctelor de interes în document. Aşadar, tipul operaţiilor potenţiale afectează decizia de alegere a modelului DOM, SAX sau a unei soluții complementare:

Citirea şi localizarea unor fragmente – se recomandă SAX, cu excepţia cazului în care trebuie să se urmărească relaţii între componente îndepărtate ale documentului care ar putea necesita rederularea codului sursa (exemplu: navigarea de la un atribut IDREF la unul de tip ID care îl precede, deci a fost deja trecut prin fereastra de derulare; SAX este util în special la localizarea unor fragmente mici în conţinut masiv: identificarea fragmentului dorit poate fi urmată de o oprire definitivă a procesului de parsing, fără să se citeascăîntreg documentul;Modificări masive de date – se recomandă DOM; numeroase implementări SAX tratează codul sursă ca read-only, operaţiile de modificare fiind emulate prin recrearea unei alte versiuni a documentului;Modificări de structură, în vederea transformării arborelui XML pentru diverse destinaţii (dintr-un vocabular în altul, pentru generare de prezentări etc.) – se recomandă limbajul XSLT, asupra căruia se va reveni ulterior, în locul manipulării DOM. Totuşi XSLT foloseşte la rândul său o reprezentare de tip DOM, dar are propriul vocabular de manipulare şi nu necesită folosirea interfeţelor DOM. XSLT are şi avantajul reutilizării transformărilor;Generare de XML dinamic – se recomandă DOM, deoarece menţine arborele în memorie pe parcursul procesului de adăugare a noi informaţii;

Generare de XML din componente XML ale altui document – se recomandă oîmbinare între parsere și metode, dar adesea se apelează la XSLT.

Page 385: licenta hatz

14 Robert Andrei Buchmann

1.3.3 Interogarea și transformarea XML

Pe limbajul de interogare Xpath se bazează numeroase limbaje ce manipulează codXML:

XSLT și Xquery pentru transformare de XML,XML Schema pentru crearea de vocabulare,

Xpointer – o variantă mai complexă a lui Xpath care, în plus față de acesta, poate accesa și altceva decât noduri din arborele DOM, de exemplu locații (poziții din documente), fragmente (orice porțiune dintre două poziții, de exempu bucăți de taguri, bucăți de atribute) sau colecții de fragmente;

XML Signature și XML Encryption – pentru semnarea digitală sau criptarea unornoduri din document.Spre deosebire de SQL, Xpath poate doar citi informații, nu și

modifica/insera/șterge. Pentru acestea se apelează la funcțiile standard DOM sau la limbajele de transformare XSLT/Xquery.

Exemple de interogări/comanda/produs/@id...caută atributul ID al elementelor PRODUS din COMANDA/comanda/produs....toate elementele PRODUS din COMANDA /comanda/*...toate elementele din COMANDA /comanda/text()....toate nodurile text din COMANDA /comanda/node()....toate nodurile din COMANDA, indiferent de tip /comanda/produs/@*....toate atributele din toate elementele PRODUS din COMANDA /comanda//@id...returnează toate atributele ID din COMANDA, indiferent de nivelul pe care se

află//@id|//id...returnează toate IDurile din document, indiferent că sunt atribute sau elemente,

indiferent cui aparțin/comanda/produs[1]...returnează primul PRODUS din COMANDA/comanda/produs[id]...returnează acele PRODUSE din COMANDA care conțin elemente ID/comanda/produs[@id]...returnează acele PRODUSE din COMANDA care conțin atribute ID//id/ancestor::node()...returnează toți strămoșii elementelor ID/comanda/produs[3]/preceding::text()...returnează toate nodurile text ce preced al 3-lea PRODUS din COMANDA count(/comanda/node())... returnează numărul de noduri fiu din COMANDA

Page 386: licenta hatz

Tehnologii XML 15

XSLT este limbajul de transformare a documentelor XML și se bazează pe Xpath pentru a extrage informații dintr-un document sursă și a le pune într-un document rezultat(cu structură diferită). De obicei XSLT e folosit pentru a genera pagini HTML din date XML, deci poate fi folosit și ca instrument AJAX (conversia răspunsului de la server în codHTML).

Pornim de la următorul document XML (salvat cu numele comanda.xml)<?xml version="1.0" encoding="UTF-8"?

> <comanda><!-- acesta e un comentariu --><produs denumire="Televizor" id="p1" pret="100"/> <produs id="p2" pret="200">Calculator</produs> <produs>

<id>p3</id><pret>300</pret><denumire>Ipod</denumire>

</produs><prettotal>600</prettotal> Aceasta este o comanda de produse

</comanda>

O foaie XSLT conține una sau mai multe reguli de substituire cu două componente:

match este calea Xpath a elementelor care vor suferi substituția

conținutul lui xsl:template estenoul conținut care va intra în locul celui detectat de match.

Următorul exemplu generează o listă cu numele produselor de mai sus, separate printr-o linie HTML (HR). Documentul XML original are o structură neregulată – primul produs are denumirea într-un atribut, al doilea îl are în conținutul textual, al treilea îl areîntr-un element-fiu. Deci, chiar dacă parcurgem cu un ciclu FOR cele 3 produse, va trebui să implementăm o structură CASE care să extragă denumirea în mod diferit de la caz la caz, prin căi XPath relative la elementul curent (la care a ajuns ciclul FOR):

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0"><xsl:template match="/">

<xsl:for-each select="comanda/produs"> <xsl:choose>

<xsl:template match="/"> Text oarecare

Page 387: licenta hatz

<xsl:when test="@denumire"><xsl:value-of select="@denumire"/>

</xsl:when><xsl:when test="denumire">

<xsl:value-of select="denumire"/>

Page 388: licenta hatz

16 Robert Andrei Buchmann

</xsl:when><xsl:otherwise>

<xsl:value-of select="."/></xsl:otherwise>

</xsl:choose><hr/> </xsl:for-each>

</xsl:template></xsl:stylesheet>

Structura CASE e definită cu xsl:choose. Aceasta conține un șir de variante definite cu xsl:when (fiecare cu câte o condiție testată cu atributul test). Ultima variantă este xsl:otherwise (pentru cazul în care nici una din ramuri nu a funcționat).

XSLT folosește căi XPath RELATIVE la nodul pe care s-a poziționat instrucțiunea-părinte (cea cu match e părinte pentru for-each, acesta e părinte pentru choose și when etc.). XSLT nu conservă implicit codul XML original. Dacă dorim să se conserve anumite elemente, trebuie să creăm o regulă de conservare care să substituie elementele cu ele însele:

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0"><xsl:template match="/">

<xsl:copy-of select="."/></xsl:template>

</xsl:stylesheet>

Această regulă substituie elementul rădăcină cu el însuși, producând o copie a documentului original.

1.4 Modelul AJAX pentru aplicații Web

1.4.1 Paradigma Rich Client și beneficiile aduse de AJAX

AJAX este un termen care promovează paradigma Rich Client în domeniul aplicaţiilor Web. Aplicaţiile Web au evoluat în timp dinspre paradigma Thin Client, în care rolul clientului se reducea la a formata un document, spre modelele încadrate în aşa numita generaţie Web 2.0, printre care Rich Client, ce promovează transferul efortului de procesare dinspre server spre client, pentru a micşora efortul distribuit al serverului şi pentru a minimiza latenţele provocate de comunicarea intermitentă între client şi server (refreshul redundant de pagină) – acestea ducând, în final, la o îmbunătăţire a fluidităţii experienţei utilizatorului care apropie regimul de utilizare a aplicaţiilor Web de regimul de utilizare al aplicaţiilor desktop (în care interfaţa cu utilizatorul şi baza de date se află în aceeaşi memorie, deci latenţa reţelei şi refreshul interfeţei nu există).

Page 389: licenta hatz

Tehnologii XML 17

De-a lungul timpului au existat numeroase tehnologii care să promoveze modelulRich Client, majoritatea orientându-se însă spre aplicaţii Internet non-Web (programe tipMessenger, gestionare locală de e-mail - vezi Outlook, diverse aplicaţii desktop consumatoare de date on-line etc.), toate acestea fiind aplicaţii ce necesită un efort prealabil de instalare şi configurare. Dezvoltarea Web spre această direcţie a presupus găsirea de soluţii care să elimine necesitatea instalării modulelor client. În acest sens, modelul a fost promovat iniţial de appleturile Java şi scripturile client (JavaScript), apoi de produsele Shockwave (Flash) şi, în prezent, de AJAX, bazat pe o utilizare intensivă a limbajuluiJavaScript asupra unor seturi de date schimbate cu serverul în format XML sau JSON.

Spre deosebire de Flash, AJAX este o soluţie necomercială, bazată strict pe standarde WWW (XML, CSS, HTML, JavaScript) și aflată la baza noilor tendințe în dezvoltarea versiunii HTML 5. Termenul AJAX a fost fixat de Jesse James Garrett (Adaptive Path) ca acronim pentru Asynchronous JavaScript and XML. Aceasta sugerează faptul că nivelul logic în AJAX e asigurat de JavaScript şi nivelul datelor de XML. Accesul la datele serverului e gestionat asincron pe diferite căi, cele consacrate fiind obiectul XMLHttpRequest (XHR) sau cadrele invizibile. Nivelul prezentării e asigurat deHTML (structura paginii) şi CSS (formatul paginii), atât elementele HTML cât şi stilurile CSS fiind manipulate dinamic de JavaScript prin intermediul modelului DOM.Partea de server nu mai trebuie să asigure generare dinamică de cod HTML, ci alimentarea modulului Rich Client AJAX cu date (inclusiv XML).

Modelul AJAX e astăzi adoptat pe scară largă de majoritatea actorilor din scena Web, succesul său fiind demonstrat de pionieratul celor de la Google prin Google Maps(http://maps.google.com).

Indicăm în continuare o comparaţie între aplicaţiile tradiţionale şi cele de tipAJAX:

Web tradiţional: Datele se trimit de la client spre server cu ajutorul formularelor sau a

hiperlegăturilor (variabile GET sau POST), aşadar prin decizia conştientăa utilizatorului (în urma unui clic); răspunsul se returnează de la server sub formă de cod HTML;

11.Starea iniţială a aplicaţiei e determinată de transferul dinspre server a primei pagini (homepage);

20.Fiecare stare a aplicaţiei are asociată o nouă pagină generată dinamic (deci stările aplicaţiei sunt pagini diferite din punct de vede al operaţiilor Back/Forward şi Add Bookmark/Favorites);

Fiecare pagină generată dinamic implică un refresh complet al paginii curente, de cele mai multe ori redundant (implică şi reîncărcarea elementelor nemodificate de pe pagină);

2.2.10 Fiecare refresh sau încărcare de pagină nouă blochează temporar aplicaţia, până când noua pagină soseşte de la server, ceea ce afectează fluiditatea experienţei de utilizare (comparativ cu aplicaţiile desktop undedurata dintre clic şi reacţia la clic e de regulă insesizabilă);

Experienţa de utilizare şi utilizabilitatea lasă de dorit, nu doar datorită comunicării intermitente cu serverul care suspendă utilizarea, ci şi datorită gamei reduse de evenimente la care reacţionează pagin (de obicei doar clic-uri);

Page 390: licenta hatz

18 Robert Andrei Buchmann

← Rolul browserului e de a formata o pagină (thin client);AJAX:

← Datele pot fi trimise de la client spre server la orice moment, JavaScriptputând declanşa transferuri HTTP oricând, cu sau fără notificarea utilizatorului; răspunsul se returnează de la server în format text, fie brut, fie structurat (XML, JSON), pentru a fi prelucrat prin funcţii JavaScript;

Starea iniţială a aplicaţiei e determinată de transferul dinspre server a unui întreg modul client, cu toate stările sale posibile (deci are loc untransfer iniţial masiv care e totuşi suportat de calculatoarele moderne şi nu necesită instalare, toate interpretoarele necesare fiind încorporate în browser);

Fiecare stare a aplicaţiei e obţinută prin modificarea la nivel de client a structurii interfeţei cu utilizatorul (structura DOM), pe baza unor date primite de la server (trecerea dintr-o stare în alta nu presupune încărcarede pagină nouă, deci mecanismele Back/Forward şi Bookmark nu funcţionează);

Nu are loc refresh redundant, deoarece după încărcarea stării iniţiale serverul livrează doar datele necesare aplicaţiei, nu toate elementele interfeţei;

Cererile asincrone de date nu blochează funcţionarea interfeţei cu utilizatorul (aşa cum face refreshul de pagină) – interfaţa continuă să funcţioneze în acele stări care nu au nevoie de datele aşteptate de la server; aceasta asigură o fluiditate rezonabilă a experienţei de utilizare,apropiată de cea a aplicaţiilor desktop;

3.5.2 Experienţa de utilizare şi utilizabilitatea sunt mult îmbunătăţite, nefiind foarte afectate de schimbul intermitent de date cu serverul; în plus, gama de evenimente la care reacţionează suprafaţa interfeţei utilizatorului e apropiată de cea a aplicaţiilor desktop (ex: se poate declanşa un transferde date la trecerea cursorului peste o anumită zonă a paginii – care nu trebuie să fie neapărat un buton sau o imagine, deci schimbul de date cu serverul poate fi parţial ascuns faţă de utilizator);

← Browserul execută o aplicaţie JavaScript cu interfaţă HTML.

4.1.5. Obiectul XMLHttpRequest

Detaliile legate de mecanismul de transfer al datelor între clientul AJAX şi server vor fi discutate pe următorul exemplu:

<html><head><script type="text/javascript"> var xhrfunction modifica()

try

xhr = new ActiveXObject("Msxml2.XMLHTTP") catch (e)

Page 391: licenta hatz

Tehnologii XML 19

tryxhr = new ActiveXObject("Microsoft.XMLHTTP") catch (e)xhr = false

if (!xhr && typeof XMLHttpRequest !="undefined")

xhr = new XMLHttpRequest()

xhr.open("GET","script.php")xhr.onreadystatechange=function()if (xhr.readyState != 4) return;

document.getElementById("mesaj").innerHTML = xhr.responseText

xhr.send(null)</script></head>

<body><div id="mesaj"></div><button onclick="modifica()">Click Me</button> </body></html>

Pagina conţine un bloc DIV gol, care este completat la apăsarea unui buton cu textul primit de la server. Sintetizăm în continuare componentele mecanismului XHR:

1. Crearea obiectului XHRy are loc prin trei tentative de instanţiere, datorită faptului că diverse browsere

implementează sub denumiri diferite clasa XMLHttpRequest.2. Trimiterea de date spre serverz e asigurată de metodele open (dacă se trimit variabile GET) şi send (dacă se

trimit variabile POST); în exemplul de faţă open nu trimite nici o variabilă, send trimite caracterul null, aşadar tot ce se transmite spre server e o solicitare a unui script PHP.

3. Generarea datelor de către serveraa scriptul PHP nu primeşte date de la client, aşa că exemplul poate fi

verificat cu un script simplu care generează un şir de caractere:<?php

print "textul mesajului";?>

4. Recepţionarea datelor de la server- are loc doar când proprietatea readyState capătă valoarea 4 (condiţie care poate fi

completată cu status != 200 dacă se doreşte prevenirea erorilor de conexiune);în exemplul de faţă, datele sunt preluate de proprietatea responseText sub formă de text brut, pe care se pot aplica operaţii de manipulare a şirurilor de caractere;în alte situaţii, pe care le vom exemplifica în alte contexte, datele pot fi preluate prin proprietatea responseXML, direct ca arbore DOM, pe care se pot aplica operaţii de manipulare DOM;

Page 392: licenta hatz

20 Robert Andrei Buchmann

în ultimii ani, adepţii AJAX au promovat şi un al treilea format de date, JSON, care se preia din responseText şi se converteşte în obiect JavaScript prin funcţii specifice de conversie; JSON are faţă de XML avantajul simplităţii iar faţă detextul brut avantajul complexităţii structurilor de date – capitolele ce urmează vor prezenta şi exemple în acest sens;5. Utilizarea datelor de la server are loc prin utilizarea datelor extrase din responseText; în acest caz, valoarea sa

este atribuită conţinutului textual al marcatorului cu id=mesaj fiind vorba de comunicare asincronă (metoda open nu a folosit argumentul false),

momentul la care are loc citirea lui responseText este declanşarea evenimentului readystatechange cu readyState=4

6. Reacţia paginii HTML la datele serverului blocul DIV anterior definit în pagină ca o zonă vidă a documentului e completat

cu datele serverului; acest proces e declanşat de evenimentul clic pe butonul paginii; în general reacția paginii la datele serverului e controlată prin etapele:

a.Definirea porţiunilor de document ce urmează a fi manipulate. Se realizează prin alocarea de atribute ID și structurarea paginii cu blocuri DIV și SPAN.

b.Localizarea porţiunii de document de manipulat. Se realizează cu funcții precum getElementById, getElementsByTagName sau funcții oferite de standardul DOM.

c.Generarea de conţinut nou în zona de document localizată. Se realizează cu innerHTML sau funcții DOM ce rescriu anumite noduri ale arborelui.

d.Manipularea de atribute. Se realizează cu setAttribute sau vectorul attributes oferit de DOM.

e.Manipularea de stiluri. Se realizează cu className sau style.cssText pentru a comuta stilul aplicat unui element.

În plus faţă de acest mecanism de bază obiectul XHR poate trimite şi recepta date direct prin antetul HTTP (care în mod normal e construit de către protocol, atât în browser cât şi la server, pentru a descrie mediul de comunicare dintre cele două părţi). Manipularea antetului HTTP poate fi realizată prin metodele setRequestHeader(), getResponseHeader() şi getAllResponseHeader(). Exemplul de mai jos alterează numele browserului din antetul HTTP al cererii, astfel încât serverul să nu mai poată extrage din variabile de mediu identitatea browserului:xhr.setRequestHeader("User-Agent","Browserul meu!")

1.4.3 Cadrele interne invizibile

Cadrele interne invizibile sunt folosite ca alternativă de comunicare cu serverul, atunci când obiectul XHR nu este instalat sau este dezactivat în browser. Cadrele interne s-au folosit frecvent înainte apariţiei obiectului XHR pentru a schimba date cu serverul şi sunt chiar şi în prezent preferate de unii dezvoltatori AJAX. Acestea prezintă totuşi o serie de dezavantaje:

Cadrele interne nu au fost create în acest scop; rolul lor este, asemeni cadrelor normale, să afişeze o pagină Web în interiorul altei pagini – diferenţa faţă de cadrele normale este că cele interne nu se definesc prin împărţirea ferestrei browserului pe orizontală sau verticală (cu FRAMESET), ci prin definirea unei suprafeţe dreptunghiulare în interiorul paginii (cu IFRAME). Cadrele interne devin invizibile dacă sunt create cu dimensiunea 0x0, ceea ce permite ca pagina

Page 393: licenta hatz

Tehnologii XML 21

încărcată de cadru să nu fie o pagină HTML propriu-zisă, ci un set de date invizibil utilizatorului. Acest set de date poate fi apoi accesat prin JavaScript, din proprietăţile cadrului intern;Împrospătarea conţinutului unui cadru, fie şi unul invizibil, generează un sunet în unele browsere care poate deveni iritant pentru utilizator;Accesul la conţinutul unui cadru intern e mai dificil decât accesul la răspunsul XHR; browserul presupune că un cadru intern, fie şi invizibil, conţine o pagină HTML completă (cu head, body etc.). Chiar dacă pagina respectivă este doar un şir de caractere cu datele serverului, acesta se accesează prin proprietatea innerHTML a marcatorului BODY al paginii conţinute în cadru;Un cadru intern poate stoca doar şiruri de caractere interpretabile ca HTML. Cadrul intern nu aplică parsing DOM implicit la pachete XML, aşa cum face obiectul XHR prin proprietatea responseXML. În consecinţă, dacă aplicaţia trebuie să gestioneze date XML, trebuie să instanţieze explicit un arbore DOM în care săsalveze răspunsul XML. Instanţierea unui arbore DOM se realizează în JavaScript prin două metode, ce vor trebui incluse într-o structură try-catch:Modelul AJAX implementat prin cadre invizibile diferă categoric de modelul

bazat pe XHR. Unii autori consideră că folosirea cadrelor invizibile nu ar trebui încadrată în modelul AJAX, fiind mai degrabă o simulare a sa. Alţi autori consideră că nu este nimic în denumirea Asynchronous JavaScript and XML care să excludă cadrele interne şi să impună obiectul XHR. Următorul exemplu prezintă solicitarea unei adrese poștale de la server în urma completării codului poștal într-un formular:

<html><head><script type="text/javascript"> function trimite(cod)

cadru=document.getElementById("cadruint")cadru.src="scripturi.php?CodPostal="+cod

function citestedate(cdr)documentcadru=cdr.contentWindow.documentraspuns=documentcadru.body.innerHTMLprocesare(raspuns)

function procesare(rasp)

vector=rasp.split(",") document.getElementById("TXoras").value=vector[0] document.getElementById("TXjudet").value=vector[1] document.getElementById("TXadresa").value=vector[2]

</script>

</head><body>

<iframe id=cadruint width=400 height=50 src="" onload="citestedate(this)"> </iframe><h1>Introduceti datele</h1>

Page 394: licenta hatz

22 Robert Andrei Buchmann

<form > <table> <tr>

<td>Nume</td><td><input type=text id=TXnume ></td>

</tr><tr>

<td>CodPostal</td><td><input type=text id=TXcodpostal

onblur="trimite(this.value)"></td></tr><tr>

<td>Adresa</td><td><input type=text id=TXadresa size=50></td>

</tr><tr>

<td>Oras</td><td><input type=text id=TXoras ></td>

</tr><tr>

<td>Judet</td><td><input type=text id=TXjudet ></td>

</tr><tr>

<td></td><td><input type=submit value=Trimite ></td>

</tr></table></form>

</body></html>

Modificarea prin DOM a atributului src al cadrului nu e singura metodă de a încărca date (sau documente) într-un cadru. În acelaşi scop se pot folosi orice operaţii care permit încărcarea unei pagini într-un cadru ţintă (prin atributul target):

<a href=script.php?variabila=valoare target=cadru>....</a> - o hiperlegătură acărei pagină ţintă va fi afişată în cadrul indicat prin target; ca şi în exemplul anterior, pagina ţintă poate fi un script server la a cărui adresă se pot concatena variabile GET;

<form action=script.php target=cadru>....</form> - un formular ale cărui datevor fi trimise spre un script al cărui răspuns va fi afişat în cadrul indicat prin target; aceasta este, dealtfel, metoda prin care modelul AJAX bazat pe cadre interne permite trimiterea de variabile POST sau uploadul de fişiere.Totuşi, cele două metode sunt replici ale metodelor tradiţionale prin care

utilizatorul decide, prin clic-uri, când are loc trimiterea de date spre server. Modificarea dinamică a atributului src conferă o dinamică superioară şi o subtilitate a schimburilor de date mai apropiată de cea promovată de modelul AJAX.

1.4.4 XML și JSONÎn cele ce urmează vom realiza o comparaţie între formatele JSON şi XML

aplicate asupra datelor trimise de server. Prezentăm în continuare acelaşi set de date în format XML şi în format JSON:

XML:

Page 395: licenta hatz

<produse>

Page 396: licenta hatz

Tehnologii XML 23

<produs denumire=Televizor pret=100 /> <produs denumire=Calculator pret =200 />

</produse>Valoare JSON atribuită unei variabile:

produse=[ denumire:Televizor, pret:100,denumire:Calculator,pret:200]Obiect JSON de transferat (de exemplu generat de un serviciu Web sau de

server): produse: [denumire:Televizor, pret:100,denumire:Calculator,pret:200]

Astfel, produse devine un vector de două elemente, fiecare element fiind un obiect cu câte două proprietăţi. Insistăm asupra faptului că valorile masive se enumeră între paranteze pătrate, iar proprietăţile obiectelor între acolade, fiind posibilă orice combinaţie de imbricare între acestea (ex: vector de obiecte, obiect cu proprietăţi vectori, obiect cu proprietăţi obiect, vector cu elemente vector etc.).

Se observă că ambele modele (XML şi JSON) pot transpune în format text serializat (şir de caractere) structuri de date arborescente sau obiecte.

Avantajele JSON sunt:performanţa, atunci când se transferă strict seturi date (în schimb XML devine esenţial atunci când se transferă porţiuni de documente ce vor fi manipulate prinDOM, validate sau procesate de instrumente XML);compatibilitatea cu obiectele JavaScript – efortul de extragere a datelor din JSON e minimal în JavaScript;accesul facil la proprietăţile JSON prin sintaxa JavaScript, comparativ cu accesul mai dificil la XML prin DOM/Xpath – în exemplul JSON, al doilea preţ poate fi accesat prin produse[1].pret, în timp ce în exemplul XML ar fi necesarăparcurgerea vectorilor getElementsByTagName sau childNodes pentru nodul rădăcină, urmate apoi de solicitarea atributului pret cu getAttribute.Suporterii JSON susţin că oricum conceptele XML sunt inutile: spaţiile de nume

devin inutile dacă nu se mai folosesc marcatori iar validarea prin vocabulare e considerată o delegare inutilă a responsabilităţiilor:

Principiul XML este că aplicaţiile trebuie să fie restrictive la receptarea datelor(datele fiind validate sau transformate conform regulilor unui vocabular predefinit de destinatar) şi permisive la generarea lor (fiecare aplicaţie poate genera orice structură de date XML);

Principiul JSON este că orice aplicaţie trebuie să fie permisivă la receptareadatelor şi restrictivă la generarea lor, adică să poată prelucra orice structuri de date primite şi să fixeze nişte reguli stricte pentru structurile de date generate;Aşa cum sunt necesare programe de tip parser pentru a converti un şir de caractere

XML într-un arbore de obiecte DOM, parserele JSON convertesc şiruri de caractere JSON în obiecte. Site-ul http://json.org întreţine o listă la zi cu site-urile de la care pot fi procurate parsere JSON pentru diverse limbaje de programare. Pentru JavaScript, parsingul se poate face în mod nativ – funcţia eval() converteşte un şir de caractere într-o expresie sau un bloc de instrucţiuni JavaScript, aşadar prin aplicarea funcţiei asupra unui şir JSON stocat în responseText se obţine chiar un obiect JavaScript, mult mai facil de accesat decât un arbore DOM. Există şi parsere avansate pentru JavaScript, cu metode complexe de manipulare a structurii JSON, dar acestea trebuie instalate şi invocate ca biblioteci de funcţii JavaScript (vezi biblioteca http://json.org/json2.js). Conversia unui şir JSON în obiect se realizează în JavaScript astfel:

Page 397: licenta hatz

24 Robert Andrei Buchmann

obiect=eval('('+xhr.responseText+')')

sau eval('obiect='+xhr.responseText)

Aceasta se realizează în mod nativ. Folosirea funcţiei eval ridică probleme de securitate datorită faptului că argumentul funcţiei va fi evaluat şi executat chiar dacă este un bloc de instrucţiuni JavaScript în locul unui şir JSON. Atunci când sursa datelor din responseText nu e de încredere (ex: responseText conţine informaţii tastate de un vizitator într-un formular), se recomandă folosirea parserelor JSON propriu-zise, disponibile gratuit ca biblioteci de funcţii invocate cu SCRIPT SRC. Aceste parsere realizează înaintea evaluării o verificare a structurii argumentului, astfel încât să se asigure că e o structură JSON şi nu un cod sursă potenţial maliţios. Biblioteca json2, propusă de David Crockford, promotorul modelului JSON, oferă funcţiile:

obiect=xhr.responseText.JSON.parse() – conversie din şir JSON în obiect sir=obiect.JSON.stringify() – coversie din obiect în şir JSON

Aşa cum există protocoale orientate pe transferul de date XML (SOAP, XML-RPC), există şi protocoale de transport JSON (JSON-RPC). Mai mult, comunitatea JSON a propus înlocuirea obiectului XHR cu un obiect similar, JSONRequest, optimizat pentru transferuri JSON (la adresa http://json.org există legături spre instrumente de acest gen, inclusiv o extensie add-on pentru Firefox ce implementează obiectul JSONRequest). În contextul înlocuirii XML cu JSON ca format de transfer al datelor structurate, susţinătorii JSON arată că până şi litera X din acronimul AJAX îşi pierde semnificaţia. Deşi există o tendinţă de migrare a modelului AJAX spre structuri de date JSON, XML rămâne un standard puternic când nu e vorba de structuri de date, ci de documente – spre exemplu, atunci când serverul generează marcatori XML ce trebuie integraţi fără modificări direct în arborele DOM al paginii.

1.4.5 Biblioteci AJAX

Modelul AJAX a dus inevitabil la apariţia unor platforme de dezvoltare a aplicaţiilor cu instrumente şi componente de nivel înalt, uşor de integrat şi reutilizabile. Pe scurt, e vorba de instrumente menite să accelereze procesul de producţie a unui site AJAX. Exemplele anterioare au demonstrat nucleul oricărei aplicaţii AJAX – de la instanţierea prin tentative şi excepţii a obiectului XHR până la recepţionarea datelor de la server. Deoarece acest mecanism e folosit de majoritatea aplicaţiilor AJAX în mod identic, dezvoltatorii Web au definit funcţii de nivel mai înalt care să încapsuleze acest mecanism, mascând detaliile sale. Mai mult, s-au creat componente care să compenseze şi să mascheze neajunsuri AJAX precum imposibilitatea de a face upload de fişiere sau de a crea semne de carte pentru stări diferite ale aplicaţiei. Această tendinţă a dus la apariţia unei multitudini de biblioteci AJAX construite pe nivelele:

Nivel 0: mecanisme de nivel scăzut, reutilizabil, de conectare asincronă la server: obiectul XHR sau cadrele interne;Nivel 1: instrumente de nivel înalt de comunicare cu serverul (ce maschează detaliile nivelului 0) – Dojo, JSON-RPC, Prototype, Direct Web Remoting;Nivel 2: instrumente de nivel înalt de construire a interfeţei cu utilizatorul (construite peste nivelul 1) – Dojo oferă instrumente şi la acest nivel, SmartClient,Script.aculo.us (bazat pe Prototype), JQuery;

Page 398: licenta hatz

Tehnologii XML 25

Nivel 3: medii de dezvoltare a aplicaţiilor AJAX: Rails, Tapestry, AJAX.NET,SAJAX.

Instrumentele de nivel 1 nu sunt altceva decât biblioteci de funcţii sau interfeţe de programare (API) care împachetează instanţierea şi comunicarea asincronă prin obiectul XHR (sau prin alternativă – cadrele interne, folosite pentru browserele care nu suportă nici una din tentativele de instanţiere XHR). Majoritatea instrumentelor de nivel 1 sunt create independent faţă de tehnologia folosită de server. Unele, precum Direct Web Remoting, instalează şi o componentă Java pe server pentru ascultarea şi gestionarea la un nivel maiînalt a cererilor HTTP prin XHR. Altele, precum JSON-RPC, exploatează modelul ORB (Object Request Broker) pentru a permite accesarea obiectelor server direct din scripturi client.

Instrumentele de nivel 2 sunt medii de generare a interfeţei cu utilizatorul – componente GUI, cu funcţionalităţi, animaţii preprogramate şi chiar suport pentru operaţii desktop tradiţionale precum drag-and-drop. Unele instrumente extind gama de componenteGUI pentru a o apropia cât mai mult de cea a interfeţei formularelor Windows sau Mac.Instrumente precum Backbase sunt de fapt limbaje de marcare (limbaje XML) ce folosesc proprii marcatori, superiori celor din HTML, împreună cu funcţii cu rol de interpretor.

Instrumentele de nivel 3 sunt medii de dezvoltare complexe bazate pegeneratoare de cod JavaScript (Ruby on Rails generează cod şi funcţii Prototype la nivelul 1, WebWork2 generează cod pentru Dojo);

componente (AJAX.NET pe.ntru .NET, Tapestry pentru Java).Un număr mare de pachete de funcţii JavaScript pentru AJAX sunt construite pe

funcţiile pachetului Prototype. S-a arătat anterior că pachetul este uşor de instalat (e vorba de un singur fişier de tip .js ce conţine definiţiile tuturor funcţiilor, iar numele fişierului conţine numărul de versiune al bibliotecii).

Detaliem câteva din facilităţile oferite de biblioteca Prototype:prescurtarea sintaxei JavaScript;metode noi de localizare a nodurilor DOM (pe bază de stiluri);extinderea claselor JavaScript;

funcţii noi pentru lucrul cu colecţii de date (masive, obiecte); ascunderea şi eliminarea facilă de noduri DOM;

inserare facilă de cod HTML în orice poziţie a paginii;activarea, dezactivarea şi focalizarea facilă a câmpurilor formularelor; determinarea poziţiei elementelor în pagină.Script.aculo.us este una din cele mai cunoscute biblioteci JavaScript orientate spre

interfaţa cu utilizatorul, ce încapsulează instrumentele oferite de pachetul Prototype în funcţii de nivel şi mai înalt. Componentele pachetului vizează [Crane07]:

Efecte de animaţie aplicabile oricăror şi oricâtor elemente din pagină, similare celor din prezentările Powerpoint;Emularea unui mecanism drag-and-drop similar celui consacrat de aplicaţiile desktop;Componente ce încapsulează funcţionalităţi de nivel înalt precum mecanismele avansate de editare sau completare a casetelor de text;

Componente ce permit testarea interfeţei utilizatorului.

Page 399: licenta hatz

Autorul pachetului este Thomas Fuchs. Succesul Script.aculo.us e garantat de adoptarea pachetului în designul unor site-uri de renume. Pachetul poate fi descărcat gratuit la adresa http://script.aculo.us. Instalarea sa presupune includerea a două apeluri de

Page 400: licenta hatz

26 Robert Andrei Buchmann

biblioteci JavaScript, una pentru Prototype (versiunea sincronizată cu Script.aculo.us) şi una pentru Script.aculo.us:

<script type=text/javascript src=scriptaroot/prototype.js> </script><script type=text/javascript src=scriptaroot/scriptaculous.js> </script>

Pachetul Script.aculo.us oferă un nucleu de efecte fundamentale şi, pe baza acestora, o serie de efecte combinate de nivel mai înalt. Fiecare efect este o tranziţie între două stări, aşadar fiecare efect permite fixarea unui punct iniţial şi a unui punct final, precum şi durata desfăşurării. Unele efecte sunt parametrizate cu coordonate ale ecranului sau distanţe. Toate efectele sunt asincrone în sens AJAX6, deci execuţia lor nu întrerupe execuţia şi experienţa utilizării, deci multiple efecte pot fi aplicate simultan aceluiaşi element. Efectele Script.aculo.us sunt o resursă deosebită pentru promovarea utilizabilităţii aplicaţiilor Web.

Sintaxa generală a unui efect este:

new Effect.NumeEfect(element,parametri,optiuni)

Cuvântul cheie new este opţional (ca şi var la declararea variabilelor), rolul său fiind să indice un obiect nou creat.

Opţiunile sunt enumerate în format JSON. Cele mai uzuale dintre ele sunt:duration – în secunde;

fps – frecvenţa de afişare a stărilor intermediare ale animaţiei (numărul de afişări pe secundă, implicit 25);

sync – boolean, pentru sincronizarea frecvenţei de afişare la efecte simultane;from – punctul de start al efectului; to – punctul de stop al efectului;

transition – algoritmul tranziţiei, cu variante precum (se prefixează cuEffect.Transitions):

o sinoidal – viteză accelerată până la un punct, apoi decelerată; o linear – viteză constantă;o reverse – viteză constantă cu inversarea punctelor de start şi stop; o wobble – mişcare dus-întors repetată pe distanţe aleatoare;o flicker – salt între poziţii intermediare dintre start şi stop;o pulse – mişcări repetate (du-te-vino) între punctele de start şi stop de 5

ori.Punctele de start şi stop sunt definite normalizat, cu valori de la 0.0 la 1.0 mapate

pe extremităţile animaţiei. Considerăm un efect Move ce deplasează un element cu 100 de pixeli la dreapta şi în jos:

optiuni=x:100,y:100,mode:”relative”Effect.Move(“idmarcator”,optiuni)

Lista facilităților oferite de Scriptaculous este următoarea:

6 A nu se confunda execuţia asincronă a efectelor cu posibilitatea afişării lor sincronizate, care se referă strict la aspectul lor vizual.

Page 401: licenta hatz

Tehnologii XML 27

Page 402: licenta hatz

• Efecte fundamentale:– Morph – tranziție între un stil CSS și altul– Opacity – modificarea transparenței– Highlight – evidențiere (colorarea/pâlpâirea fundalului pentru atragerea

atenției)– Move – deplasare pe o direcție;– Scale – dimensionare (mărire/micșorare);– Parallel – definirea unui set de efecte care să se execute sincron și simultan

– Queues – definirea unei cozi (succesiuni) de efecte• Efecte combinate: combinații ale celor fundamentale, cu efecte similare celor

oferite de Powerpoint:– Appear, Fade, Shake, BlindUp, BlindDown etc.

• Helpere:– Transitions, Methods, toggle, multiple

• Comportamente:– Draggable, Droppable, Sortable, DelayedObserver

• Comportamente avansate (controale GUI preprogramate):– InPlaceEditor, Autocompleter, Slider

Page 403: licenta hatz
Page 404: licenta hatz

← WEB SEMANTIC

1.6.2.3 Principiile Web-ului Semantic

Paradigma Semantic Web reprezintă o nouă viziune asupra sistemului World Wide Web, o nouă arhitectură a informației disponibile în acest sistem și un nou mod de regăsire a acestei informații, inspirate de domeniul inteligenței artificiale. Pe scurt, e vorba de o convergență între:

principiile propuse în inteligența artificială încă din anii 70 (în special subdomeniul sistemelor expert) în ce privește reprezentarea cunoștințelor...... și arhitectura modernă a Web-ului, bazată pe colaborare și interoperabilitate.

Obiectivul Semantic Web este să transforme WWW într-o rețea globală de sistemeexpert, capabile să deducă în mod automat informații noi din cele existente și să răspundă la întrebări (interogări) formulate cu ajutorul a ceea ce azi numim motoare de căutare (care e previzibil că vor evolua în motoare de interogare și agenți inteligenți capabili să îndeplinească sarcini și să atragă resurse în numele utilizatorilor). Pentru a se putea îndeplini acest deziderat, datele disponibile în Internet trebuie să fie reorganizate în baze de cunoștințe, față de Web-ul actual, în care sunt stocate cu precădere în baze de date relaționale sau XML. Semantic Web se bazează pe stocarea informației sub formă de baze de cunoștințe accesibile on-line, de regulă folosind tehnologii de stocare din familia bazelor de date de tip graf (modelul de date RDF).

Bazele de cunoștințe sunt alcătuite din fapte și reguli.Faptele sunt descrieri de concepte sau afirmații simple despre un anumit subiect.

Practic, sunt propoziții cu structura de bază: subiect, predicat și complement.Exemplu: Adrian este rudă cu Andrei.Regulile sunt construcții logice de tip Dacă X, atunci Y (interpretat ca”din premisa X, se deduce concluzia Y, unde X și Y sunt fapte”). Exemplu: Dacă a este rudă cu b, atunci și b este rudă cu a. Această regulă va genera faptul Andrei este rudă cuAdrian de câte ori va întâlni afirmația Adrian este rudă cu Andrei. Avertizăm asupra faptului că uneori regulile pot fi mascate și în afirmații (axiome). Regula din acest exemplu poate să arate și astfel:

Relația de rudă este una reciprocă.

Semnificația acestei afirmații este aceeași cu a regulii de mai sus. Pentru a face mai ușoară formularea unor reguli populare și intens reutilizate (precum cea data de reciprocitate), limbaje ca OWL sau RDF Schema oferă sintaxe standardizate ce permit formularea de axiome ce pot fi interpretate ca reguli de către motoarele inferențiale, și executate în consecință.

Este important ca principiile după care se construiesc bazele de cunoștințe să fie cunoscute înainte de a studia limbajele standard ce se folosesc în acest scop.

1. Principiul validității impliciteRăspundere asupra corectitudinii cunoștințelor revine celui care le creează, iar

riscurile revin celui care le utilizează (consumă). Calculatorul nu deține mecanisme implicite de stabilire a măsurii în care cunoștințele stocate reflectă realitatea, Semantic Web

Page 405: licenta hatz

30 Robert Andrei Buchmann

oferă doar metode de reprezentare, distribuire și procesare a cunoștințelor. De aceea, calculatorul va accepta în mod implicit orice cunoștințe ca fiind valide.

Aceasta e o diferență majoră față de bazele de date (atât relaționale, cât și XML).La crearea unei baze de date, se impun reguli de validare care să prevină tastarea de date necorespunzătoare, care ar putea afecta integritatea. Orice date tastate în tabel sunt filtrate automat prin aceste reguli, iar cele care nu corespund sunt respinse cu mesaje de eroare. Astfel, se micșorează riscurile legate de fenomenul GIGO (”garbage in, garbage out”, sau ”oricât de corect ar fi un sistem, dacă introduci date eronate, vei obține rezultate eronate”).În bazele de cunoștințe nu există mecanisme de validare, ci cel mult mecanisme de detectare a contradicțiilor. Deși există și aici reguli, ele nu au rol de verificare a corectitudinii informației, ci de deducere a unor afirmații noi din afirmații existente, așa cum s-a arătat deja. Afirmațiile contradictorii formează un set conflictual, fără însă a se stabili automat care dintre variante e corectă și care nu. Modele de reputație și încredere pot garanta credibilitatea unei baze de cunoștințe.

În inteligența artificială clasică, la construirea sistemelor expert afirmațiile erau selectate prin proceduri de achiziție a cunoștințelor, prin colaborarea între inginerul de cunoștințe (responsabil cu reprezentarea în calculator a afirmațiilor) și experți (autorități în domeniu, dispuși să valideze cunoștințe și să își explice procese decizionale care apoi să fie emulate de calculator). Acest mecanism permitea un anumit nivel de validare a cunoștințelor, însă era extrem de costisitor. În Semantic Web este descurajat controlul autoritativ și e încurajată validarea colaborativă (în spiritul în care s-a dezvoltat și Wikipedia).

2.Principiul AAA (al subiectivității)Acronimul AAA înseamnă ”Anyone may state Anything about Anything”7. Așa

cum oricine poate scrie orice în propriile pagini Web, oricine trebuie să poată stoca orice afirmații într-o bază de cunoștințe. Așadar, principiul e puternic legat de cel precedent, al validității implicite: orice afirmație e considerată validă până când intră în contact cu o afirmație contradictorie. Motivele sunt legate de principiul precedent:

WWW este un mediu liber, nimeni nu trebuie să cenzureze informația pe care o conține. Consumatorii informației din Web trebuie să decidă singuri asupra credibilității surselor de informație. Modelele de reputație (note acordate de cititori, butoane Like/Dislike etc.) pot ajuta în aceste decizii. Ele se adresează atât cititorilor umani, cât și agenților software autonomi care vor trebui să ia decizii în numele oamenilor;Cunoștințele nu trebuie neapărat să reflecte realitatea, trebuie să poată exprima și ”realități alternative” (lumi fantastice din lucrări literare, mitologii, viziuni alternative asupra istoriei sau pur și simplu opinii neconformiste);Nimeni nu este creditat cu deținerea adevărul absolut. În istoria umanității au fost momente în care afirmația Pământul este plat avea valoare axiomatică, autoritativă. Semantic Web trebuie să fie pregătit pentru orice ”răsturnări de situație”, când teorii aparent general acceptate sunt brusc invalidate de noi evidențe și experiențe(sau pur și simplu de interesul individual al unui creator de cunoștințe);Autoritățile ce controlează informație tind să o cenzureze, să o deformeze sau pur și simplu aplică un anumit nivel de subiectivitate în mod involuntar. E preferabil ca subiectivitatea să fie echitabil aplicabilă în tot Internetul.

7 Allemang, Dean and Hendler, James, Semantic Web for the Working Ontologist, Morgan Kaufmann, 2011

Page 406: licenta hatz

Web Semantic 31

3.Principiul identității nonambigueNu e permis să se folosească același identificator pentru concepte diferite.

Dacă se fac afirmații despre oameni diferiți cu același nume, vor trebui să se construiască identificatori diferiți pentru fiecare individ. Această diferențiere trebuie să fie garantată pentru întreaga rețea WWW!

În baze de date, identitatea e asigurată la nivelul unei baze de date (valori-cheie unice, nume unice de tabele etc.). Cheia primară e o coloană creată special pentru a aloca identificatori diferiți fiecărui individ/obiect din tabel, evitând riscul ca alți identificatori tradiționali, precum numele, să se repete în cadrul aceluiași tabel. În programare datele sunt stocate în variabile cu nume unice într-un domeniu de vizibilitate. În aceste cazuri, identitatea e asigurată cel mult la nivelul unei aplicații software, alte aplicații și alte baze de date ar putea reutiliza aceiași identificatori. În Semantic Web însă, identitatea trebuie asigurată la nivelul întregului Internet! Creatorii de cunoștințe trebuie să folosească identificatori despre care au garanția că nimeni altcineva din Internet nu îi va folosi în alte scopuri.

4.Principiul identității multipleE permisă posibilitatea ca un același concept să aibă mai mulți identificatori!

Acesta e principiul identității multiple, care îl completează pe cel al identității nonambigue:Un identificator nu poate fi folosit pentru mai multe concepte diferite, dar un concept poate avea mai mulți identificatori!

Acest principiu permite ca diferiți creatori de cunoștințe să poată stoca afirmații despre aceleași concepte fără a se pune de acord în prealabil asupra identificatorilor (aspect care nici nu ar fi posibil la nivelul întregului Internet!). Fiecare va folosi identificatori convenabil aleși, fără a se îngrijora dacă nu cumva altcineva a memorat afirmații despre același concept.

Ulterior, dacă se dorește fuzionarea afirmațiilor din mai multe surse, și fiecare sursă a folosit alți identificatori pentru aceleași concepte, se pot insera în baza de cunoștințe relații de echivalență8. Mai mult, există chiar situații în care se urmărește deducerea de astfel de relații de echivalență.

5.Principiul Open WorldAcest principiu afirmă că niciodată nu se știe totul despre o situație modelată, că

sistemul trebuie să fie mereu disponibil să primească noi afirmații, care ar putea schimba semnificația celor existente, ar putea produce noi concluzii. Versiuni mai ”tehnice” ale acestui principiu ar putea fi formulate astfel:

să NU se facă deducții bazate pe absența unor afirmații; să NU se echivaleze absența unei afirmații cu negarea sa.Din acest motiv întotdeauna regulile funcționează după tiparul...:Dacă apare afirmația X, atunci se deduce afirmația Y...și nu după tiparul:Dacă apare afirmația X, atunci se deduce afirmația Y, altfel se deduce afirmația Z

Page 407: licenta hatz

8 În calculator, relația de echivalență se va declara într-o modalitate standard, universal acceptată însă deocamdată exemplele sunt oferite în limbaj natural, pentru înțelegerea principiilor.

Page 408: licenta hatz

32 Robert Andrei Buchmann

Așadar, principiul Open World interzice concluziile trase din absența afirmațiilor. Se spune că lumea bazelor de date este de tip Closed World, iar lumea bazelor de cunoștințe este de tip Open World.

Se poate remarca faptul că aceste principii au stat dintotdeauna la baza WWW. Noutatea adusă de Semantic Web este că ele nu se mai aplică doar la pagini Web, ci și conceptelor despre care se vorbește în paginile Web!

2.2 Resurse și identificarea resurselor

Resursa este cea mai vagă noțiune din Semantic Web. Ea reprezintă orice lucru despre care se poate face o afirmație (și cum se pot face afirmații despre orice, putem considera că orice este o resursă). Nu trebuie să se înțeleagă că doar subiectele afirmațiilor sunt resurse. În exemplul:

Andrei este rudă cu Adrian.

...nu doar Andrei este resursă, ci și relația de ”rudă”, precum și Adrian. Resursele nu sunt doar conceptele despre care se fac afirmații, ci toate conceptele despre care s-ar putea face afirmații!

În funcție de semnificația lor, resursele pot fi de mai multe tipuri: proprietăți(utilizate în mod curent ca predicate în afirmații, dar pot servi uneori și ca subiecte atunci când facem afirmații despre relații/atribute), clase (mulțimi de indivizi/instanțe), indivizi/instanțe (elemente ale unor mulțimi/clase). O ontologie este în general constituită din axiome – afirmații ce descriu clasele, proprietățile și modurile în care pot fi utilizate împreună. Axiomele sunt interpretate ca reguli (de tip Dacă X atunci Y) a căror execuție duce la producția de noi fapte. O bază de cunoștințe e formată din ontologie și baza de fapte (afirmații despre indivizi aparținând claselor declarate în ontologie).

Atunci când oamenii comunică unii altora cunoștințe, o fac cu ajutorul unor termeni alocați conceptelor utilizate în afirmații, termeni oferiți de un vocabular asupra căruia interlocutorii se pun de acord. În mod similar, atunci când se stochează cunoștințe în calculator, trebuie să se folosească o terminologie. La debutul ideii de Semantic Web exista deja un sistem de alocare de identificatori lipsiți de ambiguitate la nivel global: adresele URL. Dacă de exemplu pe serverul Yahoo există mai multe fișiere pe care proprietarii doresc să le facă accesibile, adresa se poate prelungi cu o structură virtuală de foldere și subfoldere sau locații (fragmente) din interiorul unor documente:

http://www.yahoo.com/documente/fisier.dochttp://www.yahoo.com/diverse/muzica/piesa.mp3http://www.yahoo.com/documente/CodulluiDaVinci.html#capitolul1http://www.yahoo.com/documente/CodulluiDaVinci.html#capitolul2

Spre deosebire de Web-ul tradițional, în care astfel de construcții au rol de accesare, în Semantic Web ele capătă rol de identificare. Așadar, nu mai vorbim despre adrese URL (Universal Resource Locator), ci despre URI (Universal Resource Identifier). Unii dintre acești identificatori ar putea, teoretic, să funcționeze și ca adrese ale unor paginiWeb descriptive. Spre exemplu, construcțiile...

Page 410: licenta hatz

Web Semantic 33

http://en.wikipedia.org/wiki/Brother

...ar putea avea un dublu rol:1.6.4.3 de a fixa identificatori fără ambiguitate pentru conceptul de ”om” și

relația de”frate”;

1.6.4.4 de a oferi pagini Web pe care se pot citi unele informații despre conceptul de ”om”și relația de ”frate”.Așadar, există numeroase surse on-line care alocă deja URI pentru diverse

concepte (Wikipedia, Facebook pentru persoane și organizații). Deși acestea ar putea fi o sursă valoroasă de identificatori de concepte, e recomandat să nu folosim adrese de pagini existente în acest scop, să diferențiem clar identificatorii față de adresele de pagini, chiar dacă sintactic arată la fel. Principalul motiv este principiul identității non-ambigue: o persoană și un site despre acea persoană nu sunt același lucru (au proprietăți diferite) și nu ar trebui să aibă același identificator. Dacă se dorește ghidarea unui cititor uman spre un site despre un anumit concept, se recomandă construirea de afirmații care să declare că”conceptul X este reprezentat de site-ul Y” (iar X și Y să se păstreze distincte).

Se recomandă ca pentru orice concept să se definească 3 URI cu o rădăcină comună: unul cu rol de identificator, unul cu rol de adresă al unei pagini Web informative (despre acel concept), unul cu rol de adresă al unei baze de cunoștințe interogabile prin HTTP. URI oferă o formă suficient de complexă și independentă de limbă încât să permită definirea unui număr teoretic infinit de concepte (există totuși neajunsul că sunt destul de lungi, dar vom vedea ulterior și câteva moduri de prescurtare a lor).

Cine definește identificatorii? Avem la dispoziție variantele:1.6.5.2 Creatorul bazei de cunoștințe își definește proprii identificatori de

concepte, pornind de la o adresă de domeniu pe care o deține (sau achiziționează una), fără să se intereseze dacă nu cumva altcineva în Internet a stabilit deja identificatori pentru aceleași concepte (în caz că află ulterior și dorește să conecteze cunoștințele sale cu ale altora, va putea afirma echivalența între identificatorii diferiți ai aceluiași concept);

1.6.5.3 Creatorul bazei de cunoștințe este conștient de faptul că altcineva a standardizat sau promovat unii identificatori de concepte (ca parte din vocabulare controlate sau standardizate de alte organizații) și decide să-i adopte la rândul său;

1.6.5.4 Conceptele sunt considerate resurse anonime (fără identitate universală). În acest caz cunoștințele nu vor putea fi conectate cu altele din Internet, deci se încalcă dezideratul interoperabilității semantice. Nu are sens ca o bază de cunoștințe să folosească numai concepte anonime însă acestea pot fi utile într-o serie de scenarii, când nu prezintă interes identitatea conceptului, ci numai poziția sa în afirmații.

A. Legat de prima variantă, oricine poate achiziționa o adresă de domeniu, de exemplu http://expl.ro, apoi să o extindă în mod convenabil cu ierarhii fictive de foldere și ancore, generând identificatori unici în Internet:

http://expl.ro/concepte/persoane/Anahttp://expl.ro/concepte/relatii/a-fi-mamahttp://expl.ro#Anahttp://expl.ro#mama

Page 411: licenta hatz

Dacă fiecare construiește identificatori pornind de la propria adresă, riscul ca același identificator să fie folosit de organizații diferite, pentru concepte diferite, e minimizat (evident, mai trebui să evităm această eroare și pe plan intern).

Page 412: licenta hatz

34 Robert Andrei Buchmann

1.6.5.3 Legat de standardizarea conceptelor, există o serie de organizații preocupate în definirea de identificatori pe care să-i utilizeze toată lumea (terminologii, vocabulare reutilizabile):

Principala organizație care se preocupă de acest lucru este chiar W3C (organizația ce ghidează evoluția Web-ului). Aceștia sunt în special preocupați cu definirea unor concepte primitive de care este nevoie în orice bază de cunoștințe (Clasa, Resursa, Proprietatea, relațiile de Apartenență sau Echivalență etc.). W3C propune o colecție de identificatori standard pentru astfel de concepte fundamentale și utile grupate în vocabularele RDF, RDF Schema, OWL. Motoarele inferențiale asociază acești identificatori cu o serie de reguli axiomatice care se pot aplica pentru a deriva noi afirmații din afirmații existente;

Mai există organizații care standardizează sau promovează identificatori de concepte pentru domenii specifice: FOAF este o colecție de concepte pentru a descrie relații sociale și persoanele implicate în acestea; Dublin Core este o colecție de concepte pentru a descrie surse de informație și autorii lor; GoodRelations este o colecție de concepte dedicată comerțului, pentru a descrie produse, comercianți etc.

Deși au aceeași natură (sunt colecții de concepte populare într-un anumit domeniu) ca și prima categorie, pentru acestea se preferă termenul de ”ontologii” în loc de ”limbaje”;

În ultimii ani, Wikipedia a depus eforturi semnificative în încercarea de a face conținutul existent în enciclopedie să poată fi tratat ca o bază de cunoștințe Semantic Web. În acest scop, au propus la rândul lor o colecție de identificatori (ontologia DBPedia), pentru majoritatea conceptelor prezentate în paginile Wikipedia.

1.6.5.4 Legat de resursele anonime, e vorba de concepte fără identificator universal (URI). Aceasta nu înseamnă că nu au nicio identitate. Creatorul bazei de cunoștințe le va aloca un nume local prefixat, de tipul:

_:x _:concept _:aaa

Aceste nume asigură o identitate locală și instabilă: se modifică în mod imprevizibil, nu pot fi interrogate direct, totuși sunt utile în a conecta la nivel local afirmații.

2.3 Modelul de date RDF

2.3.1 Reprezentarea grafică (abstractă) a cunoștințelor în RDF

În limbajul natural, părțile de bază ale oricărei afirmații (propoziții) sunt subiectul, predicatul și complementul9. Mai multe astfel de afirmații conectate prin diverși delimitatori (conjuncții, semne de punctuație), formează fraze și texte de dimensiuni mai mari. În RDF, terminologia oficială numește cele 3 componente, în ordinea:

9 În lingvistică mai intervine și atributul dar, conform RDF, acesta poate fi substituit de complement.

Page 413: licenta hatz

Web Semantic 35

subiect (conceptul despre care se face afirmația);predicat, numit și proprietate (conceptul prin care se descrie subiectul); obiect (conceptul care asigură descrierea).

Reprezentarea abstractă a afirmațiilor RDF se realizează cu ajutorul grafurilor, în care nodurile corespund subiectului și obiectului, iar arcele corespund proprietății:

http://expl.ro#Andreihttp://expl.ro#FrateCu

http://expl.ro#Alin

Fig. 1 – Reprezentarea grafică a tripletului RDF

Următoarele restricții trebuie respectate în ce privește identificatorii folosiți pentru cele 3 elemente:

Subiectul trebuie să aibă un identificator universal (URI) sau local (anonim). Proprietatea obligatoriu trebuie să aibă un identificator de tip URI.

Obiectul poate fi un identificator de tip URI, un concept anonim sau o valoare(o dată de un anumit tip).

Atunci când obiectul este un concept (cu URI sau anonim), se spune că proprietatea exprimă o relație (între două concepte). Atunci când obiectul este o valoare, se spune că proprietatea exprimă un atribut al subiectului, iar în reprezentări grafice valoarea se încadrează în dreptunghi.

Page 414: licenta hatz

http://expl.ro#Andrei http://expl.ro#areVarsta 20

Page 415: licenta hatz

Fig. 2 – Reprezentarea grafică a tripletului RDF cu obiect-valoareAtunci când în mai multe afirmații apar noduri comune, tripleții pot fi conectați

între ei și graful capătă complexitate. Considerăm următoarele afirmații în limbaj natural:

Ana este mama lui Andrei.Ana este mama lui Alin.Alin este tatăl lui X.X are vârsta 20.

Reprezentarea grafică este:

http://expl.ro#esteMamaLuihttp://expl.ro#Alinhttp://expl.ro#Ana

http://expl.ro#esteMamaLui http://expl.ro#esteTatalLui

http://expl.ro#areVarstahttp://expl.ro#Andrei _:X 20

Fig. 3 – Reprezentarea grafică a mai multor afirmații înlănțuite

În continuare vom discuta despre utilizarea nodurilor anonime: ca structuri de date, mai exact concepte ce grupează mai multe informații.

Page 416: licenta hatz

36 Robert Andrei Buchmann

http://expl.ro#Ana

http://expl.ro#locuiesteLa

_:adresahttp://expl.ro#inOras

http://expl.ro#ClujNapocahttp://expl.ro#laNr

http://expl.ro#peStrada20 http://expl.ro#inAp

Page 417: licenta hatz

200 http://expl.ro#Baita

Page 418: licenta hatz

Fig. 4 – Utilizarea nodurilor anonime în reprezentarea structurilor de date

Am sugerat deja că nodul anonim nu va putea apare în interogări, deci nu se va putea pune întrebarea Care e orasul din _:adresa? însă se va putea pune întrebarea Care e orașul în care locuiește Ana? (profitând de înlănțuirea relațiilor ”locuiesteIn” și ”Oras”, intermediată de nodul anonim, care devine astfel important doar prin poziția sa, nu și prin identitate).

Un alt exemplu relevant în acest sens este reificarea. Aceasta e o noțiune extrem de importantă și controversată, strâns legată de principiul subiectivității: uneori cele 3 părți ale propoziției nu sunt suficiente, mai exact atunci când se fac ”afirmații despre afirmații”:

Marian crede că Alin este frate cu Andrei.

Modelarea corectă în RDF pentru acest caz este următoarea: (a) Subiectul este Marian; (b) Predicatul este ”crede”; (c) Acesta predicat exprimă relația cu o afirmație(formată la rândul său din Alin, relația de frate și Andrei).

Așadar reprezentarea grafică ar arăta mai degrabă astfel:

http://expl.ro#Marian

http://expl.ro#crede

_:afirmatie

http://expl.ro#areSubiect http://expl.ro#areObiecthttp://expl.ro#areProprietate

http://expl.ro#Alinhttp://expl.ro#Andrei

http://expl.ro#frateCu

Fig. 5 – Utilizarea nodurilor anonime în afirmații subiective

Page 419: licenta hatz

Web Semantic 37

Page 420: licenta hatz

Reificarea folosește părțile propoziției secundare ca o structură de date, le grupează sub un nod anonim comun (ce reprezintă afirmația), pe care apoi îl folosește drept obiect pentru propoziția principală. Un alt aspect sugerat de acest exemplu este că reificarea are aplicabilitate atunci când dorim să afirmăm subiectivitatea sau valabilitatea limitată a unor cunoștințe. Afirmația că Alin e frate cu Andrei este o credință personală a lui Marian. Cineva care interoghează baza de cunoștințe va decide dacă să filtreze sau nu credințele respective în funcție de cine le crede.

O a treia utilizare importantă a nodurilor anonime apare în reprezentarea relațiilor de aritate superioară. Este evident din structura de bază a modelului RDF că tripleții pot exprima doar relații binare, între un subiect și un obiect. Uneori cunoștințele trebuie să exprime mai mulți participanți la aceeași relație:

Andrei are 10 la Matematică.Alin, Andrei și Ana sunt colegi.

În primul caz avem o relație de aritate 3 între Andrei, Matematică și nota 10. Se creează în mod artificial un nod anonim care să grupeze cele 3 componente ale relației, permițând interogarea oricăreia pornind de la celelalte:

http://expl.ro#Andrei

10http://expl.ro#are

http://expl.ro#nota

_:relatie

http://expl.ro#curs

http://expl.ro#Matematica

Fig. 6 – Utilizarea nodurilor anonime în relații de aritate 3

2.3.2 Reprezentarea serializată a cunoștințelor RDF

1.6.6.3 Reprezentarea în sintaxa N-triples

N-triples10 este sintaxă brută de serializare RDF. Aceasta e cea mai primitivă sintaxă și are un set minim de reguli cu privire la scrierea afirmațiilor (reguli pe care le-am folosit deja în câteva exemple anterioare):

Între concepte trebuie să apară minim un spațiu sau un Tab;Orice afirmație (triplet) trebuie să se încheie cu un spațiu urmat de un punct și un salt la rând nou (Enter);

Identificatorii de tip URI se încadrează între <...>;Identitatea resurselor anonime e asigurată prin nume prefixate de ”_:”;

Page 421: licenta hatz

10 http://www.w3.org/2001/sw/RDFCore/ntriples/

Page 422: licenta hatz

38 Robert Andrei Buchmann

Obiectele-valoare sunt implicit de tip text (se trec între ghilimele indiferent de tipul/semnificația lor) dar pot fi însoțite de:

o Un cod de limbă (care precizează în ce limbă e scrisă valoarea);o Un tip de dată, de obicei dintre cele oferite de limbajul XML Schema

(dacă dorim ca valoarea să fie considerată de alt tip decât string); unicul tip oferit de RDF este XMLLiteral (un șir de caractere ce conține cod XML bine format).

Comentariile se scriu pe linii noi, începute cu un #.Exemplu:

<http://expl.ro#Alin> <http://expl.ro#esteFrateCu> <http://expl.ro#Andrei> . <http://expl.ro#Alin> <http://expl.ro#areVarsta> "20"^^<http://www.w3.org/XMLSchema#int> . <http://expl.ro#Alin> <http://expl.ro#locuiesteIn> <http://expl.ro#Anglia> . <http://expl.ro#Anglia> <http://expl.ro#areNumele> "Anglia"@ro .<http://expl.ro#Alin> <http://expl.ro#areNumele> "Alin” . <http://expl.ro#Alin> <http://expl.ro#areEmailul> <mailto:[email protected]> . <http://expl.ro#Alin> <http://expl.ro#areSiteul> <http://alin.ro> . <http://expl.ro#Alin> <http://expl.ro#areNumeleFormatat>

"<span class='colorat'>Alin</span>"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

2.3.2.2 Reprezentarea în sintaxa Turtle

Turtle11 este o versiune optimizată sintactic pentru N-triples, creată cu scopul de a face cunoștințele mai ușor de tastat și de citit. Scopul acestei sintaxe a fost să ofere o serie de abrevieri, iar fișierele se salvează cu extensiile .ttl sau .n3.

Cea mai importantă facilitate sintactică e posibilitatea de a evita repetarea porțiunilor comune din identificatorii URI, cu ajutorul unui prefix (spațiu de nume). De exemplu, în loc de:

<http://expl.ro#Alin> <http://expl.ro#esteFrateCu> <http://expl.ro#Andrei> . <http://expl.ro#Alin> <http://expl.ro#locuiesteIn> <http://expl.ro#Anglia> . <http://expl.ro#Alin> <http://expl.ro#areNumele> "Alin” .

...vom putea defini un prefix locțiitor pentru partea de URI care se repetă (de asemenea nu mai sunt necesare parantezele ascuțite):

@prefix x: <http://expl.ro#>. x:Alin x:FrateCu x:Andrei . x:Alin x:locuiesteIn x:Anglia . x:Alin x:areNumele "Alin” .

...sau, și mai simplu, definim un prefix vid:

@prefix :

<http://expl.ro#>. :Alin :FrateCu :Andrei . :Alin :areVarsta 20

.

Page 423: licenta hatz

11 http://www.w3.org/TeamSubmission/turtle/

Page 424: licenta hatz

Web Semantic 39

:Alin :locuiesteIn :Anglia . :Alin :areNumele

"Alin” .

Prefixele Turtle mai au și un alt scop, de a facilita folosirea de identificatori de concepte din alte surse (de exemplu, standardizați), indicând proveniența lor. Spre exemplu, conceptul de Resursă (mulțimea tuturor lucrurilor) este unul primitiv, ce apare în orice bază de cunoștințe. De aceea, W3C a propus un identificator standardizat pentru acesta:

http://www.w3.org/2000/01/rdf-schema#Resource

Pentru a afirma că Alin este o resursă, vom scrie:

@prefix : <http://expl.ro#>.@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Alin :este rdfs:Resource.

Altă categorie de abrevieri oferită de Turtle este eliminarea necesității de a atașatipuri XML Schema atunci când e vorba de numere sau valori booleene. Din acest motiv...

<http://expl.ro#Alin> <http://expl.ro#areVarsta> "20"^^<http://www.w3.org/XMLSchema#int> .

...în Turtle se poate scrie:

@prefix :

<http://expl.ro#>. :Alin :areVarsta 20 .

Următoarea abreviere pe care o prezentăm este posibilitatea de a nu mai repeta un concept care apare ca subiect în mai multe afirmații. Următoarele exemple sunt echivalente:

N-triples:

<http://expl.ro#Alin> <http://expl.ro#esteFrateCu> <http://expl.ro#Andrei> . <http://expl.ro#Alin> <http://expl.ro#areNumele> "Alin” .

Turtle:@prefix :

<http://expl.ro#>. :Alin :esteFrateCu :Andrei; :areNumele

"Alin” .

Mai mult, se simplifică și afirmațiile în care atât subiectul cât și proprietatea suntcomune...

N-triples:

<http://expl.ro#Ana> <http://expl.ro#esteMamaLui> <http://expl.ro#Andrei> . <http://expl.ro#Ana> <http://expl.ro#esteMamaLui> <http://expl.ro#Alin> . <http://expl.ro#Ana> <http://expl.ro#esteMamaLui> <http://expl.ro#Adrian> .

Turtle:

Page 425: licenta hatz

40 Robert Andrei Buchmann

@prefix : <http://expl.ro#>.:Ana :esteMamaLui :Andrei, :Alin, :Adrian.

...și există o notație particulară pentru situațiile în care lista de obiecte este ordonată și închisă:

@prefix : <http://expl.ro#>.:Ana :esteMamaLui (:Andrei :Alin :Adrian).

O altă abreviere utilă în sintaxa Turtle este legată de prezența conceptelor anonime. Am arătat deja că acestea sunt concepte fără identitate universală (URI), însă au o identitate locală (un nume instabil, ce se schimbă la fiecare transfer al cunoștințelor). Din N-triples este moștenită sintaxa clasică pentru indicarea resurselor anonime:

@prefix : <http://expl.ro#>.:Maria :esteMamaLui _:x ._:x :esteTatalLui :Marian.

În Turtle însă, avem și varianta:

@prefix : <http://expl.ro#>.:Maria :esteMamaLui [:esteTatalLui :Marian].

Cu alte cuvinte, parantezele pătrate grupează afirmații cu subiect anonim, fără a mai trebui indicat subiectul. Alt exemplu, de data aceasta o înlănțuire a afirmațiilor prin noduri anonime:

@prefix : <http://expl.ro#>.:Maria :esteMamaLui _:x ._x :esteTatalLui _:y ._y :locuiesteIn :ClujNapoca .

...este echivalent cu:

@prefix : <http://expl.ro#>.:Maria :esteMamaLui [:esteTatalLui [:locuiesteIn :ClujNapoca]].

Afirmația...

Alin este o Resursă.

...se poate scrie:Turtle prefixat:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. <http://expl.ro#Alin> rdf:type rdfs:Resource.

Page 426: licenta hatz

Turtle optimizat:

Page 427: licenta hatz

Web Semantic 41

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. <http://expl.ro#Alin> a rdfs:Resource.

2.4 Reificarea și cunoștințele contextuale

În Semantic Web nu doar proveniența conceptelor (sugerată de URI și prefixe) trebuie explicitată, ci și proveniența afirmațiilor, mai exact contextul în care afirmațiile trebuie considerate valide. Acest model poartă numele de reificare și, după cum s-a amintit deja, are rolul de a permite să se facă ”afirmații despre afirmații”:

Marian crede că Alin este frate cu Andrei.

În acest exemplu, afirmația Alin este frate cu Andrei devine obiect în afirmația careîncepe cu Marian crede că…. Am putea spune că afirmația despre Alin:

este o credință subiectivă a lui Marian; are drept sursă pe Marian;prezumția de validitate implicită trebuie să fie limitată la Marian (adică să se tolereze apariția unei afirmații contradictorii din altă sursă);

sau, la modul cel mai general, îl are drept context pe Marian.Contextul poate fi considerat orice concept ce caracterizează o afirmație în

ansamblu său, nu doar o parte a unei afirmații. Interpretarea pe care o acordăm contextului poate să varieze:contextul ca sursă a afirmației, a unei credințe sau a unei citări:

Marian crede că Alin este frate cu Andrei.contextul ca loc/timp în care e valabilă afirmația – poate servi și la precizarea timpului gramatical al afirmațiilor:

Maria și Alin sunt căsătoriți din 2010.Maria lucrează pentru firma ABC în Cluj Napoca.

contextul ca evaluare a unei relații:Soarele se rotește în jurul Pământului este o afirmație falsă.Pământul se rotește în jurul Soarelui cu 30 km/s.E important de sesizat diferența semantică între a caracteriza o afirmație/relație și

a caracteriza doar o parte a unei afirmații. Considerăm exemplele:Maria lucrează pentru firma ABC din Cluj Napoca.Maria lucrează pentru firma ABC în Cluj Napoca.În primul caz, firma ABC este în Cluj Napoca (indiferent de rolul Mariei). Faptul

că Maria lucrează la ABC și faptul că ABC se află în Cluj Napoca sunt conectate (prin nodul comun ABC) dar nu se influențează reciproc (ABC nu e în Cluj Napoca din cauza relației cu Maria și nici relația Mariei cu firma ABC nu e legată neapărat de Cluj Napoca).În consecință, nu avem de a face cu un context propriu-zis, ci cu două afirmații conectate:

http://expl.ro#lucreazaLa http://expl.ro#localizataInhttp://expl.ro#Maria http://expl.ro#ABC http://expl.ro#ClujNapoca

Page 428: licenta hatz

Fig. 7 – Afirmații înlănțuite

Page 429: licenta hatz

42 Robert Andrei Buchmann

A doua afirmație în schimb spune explicit că relația dintre Maria și ABC se desfășoară în Cluj Napoca. Nu e clar dacă Maria e din Cluj Napoca, nu e obligatoriu ca firma ABC să fie din Cluj Napoca, însă afirmația ca întreg e valabilă în Cluj Napoca:

http://expl.ro#lucreazaLa

http://expl.ro#Maria http://expl.ro#ABC

http://expl.ro#ClujNapoca

Fig. 8 – Afirmație contextuală

În sintaxele RDF tradiționale, contextul poate fi atașat unei afirmații pe multiple căi (s-au demonstrat deja în capitolul dedicat reprezentării grafice RDF):

printr-o relație de aritate 3;folosind modelul standard al reificării;

Din păcate ambele soluții sunt destul de complexe – necesită 4-5 afirmații șiminim 7 noduri (dintre care unul anonim) pentru reprezentare. Cum se estimează posibilitatea ca în viitor Semantic Web să exploateze foarte frecvent astfel de cunoștințe contextualizate, s-a propus o soluție optimală în acest sens: identificatorii de grafuri. Conform acestei idei, nu doar conceptele primesc identificatori de tip URI, ci orice mulțime de afirmații, deci orice graf RDF. Identificatorul alocat unei mulțimi de afirmații (graf) va fi contextul acelei mulțimi și poate fi la rândul său folosit în afirmații despre context.

http://expl.ro#Maria http://expl.ro#lucreazaLa http://expl.ro#ABC

http://expl.ro#esteUn

http://expl.ro#Oras

Fig. 9 – Afirmație cu context și afirmație despre context

În acest exemplu avem afirmațiile:

Page 430: licenta hatz

Maria lucrează pentru firma ABC în Cluj Napoca. Cluj Napoca este un oraș.

Page 431: licenta hatz

Web Semantic 43

Page 432: licenta hatz

Graful Cluj Napoca poate conține oricâte afirmații (care sunt valabile în Cluj Napoca). Pentru a doua afirmație, graful Cluj Napoca este un nod, deci avem de a face cu o situație în care grafurile se transformă în noduri pentru alte grafuri.

Pentru a facilita exprimarea contextelor cu un efort mult mai mic decât al reificării s-a propus extinderea modelului RDF de la triplet la cvadruplet, unde al patrulea concept este contextual (identificatorul de graf). Astfel se promovează ideea de grafuri denumite (identificate). În acest scop s-au propus sintaxe ce le extind pe cele existente deja:

N-quads este o sintaxă similară cu N-triples, dar cu 4 concepte într-o afirmație, ultima fiind contextul (identificatorul de graf)12;

Trig este extensia lui Turtle13

Oferim în continuare un exemplu de reprezentare a unui set de cunoștințe în cele trei variante, pornind de la afirmațiile:

Maria crede că Alin are vârsta 30 și este căsătorit cu Raluca.Andrei crede că Alin are vârsta 20 și este tatăl lui Alina.Andreea crede că toate opiniile Mariei au credibilitate scăzută.

Sintaxa Trig ne permite calificarea oricărui set de cunoștințe cu un identificator de graf (context), prin încadrarea între acolade:

@prefix : <http://expl.ro#>. :Maria

:Alin :areVarsta 30; :casatoritCu :Raluca.:Andrei

:Alin :areVarsta 20; :tatalLui :Alina.:Andreea

:Maria :credibilitate :scazuta.

Între acoladele respective pot apare oricâte afirmații și toate vor aparține grafului denumit, respectiv contextului reprezentat de acesta. S-a câștigat mult în sintaxă, dar s-a pierdut relația :crede, care fie e considerată implicită printr-o convenție între deținătorii cunoștințelor și consumatorii acestora, fie e declarată explicit adăugând afirmații de forma:

:Maria :relatiaCuAfirmatiile :crede. :Andrei :relatiaCuAfirmatiile :crede. :Andreea :relatiaCuAfirmatiile :crede.

După cum am sugerat la început, contextul poate avea orice relații cu conținutul său (loc, timp, evaluare, sursă a unui citat etc.). Afirmații contradictorii pot apare în contexte diferite (vârsta lui Alin) sau contexte diferite își pot completa reciproc cunoștințele (faptele că Alin e căsătorit și are copii). În plus, se pot face afirmații despre contexte,

12 http://sw.deri.org/2008/07/n-quads/ 13http://www4.wiwiss.fu-berlin.de/bizer/trig/

Page 433: licenta hatz

44 Robert Andrei Buchmann

afirmații despre afirmații despre contexte etc. (afirmația Andreei). Limbajul de interogare SPARQL deține opțiuni de filtrare după graf (context) a cunoștințelor, de combinare a cunoștințelor din anumite grafuri sau pur și simplu de ignorare a împărțirii pe contexte, în funcție de precizia informațiilor care se solicită.

Exemplul de mai sus se poate exprima și în N-quads, varianta extinsă la N-triples:

<http://expl.ro#Alin> <http://expl.ro#areVarsta> 30 <http://expl.ro#Maria> .<http://expl.ro#Alin> <http://expl.ro#casatoritCu> <http://expl.ro#Raluca> <http://expl.ro#Maria> . <http://expl.ro#Alin> <http://expl.ro#areVarsta> 20 <http://expl.ro#Andrei> .<http://expl.ro#Alin> <http://expl.ro#tatalLui> <http://expl.ro#Alina> <http://expl.ro#Andrei> . <http://expl.ro#Maria> <http://expl.ro#credibilitate> <http://expl.ro#scazuta> <http://expl.ro#Andreea> .

2.5 Interogarea grafurilor RDF

2.5.1 Interogări SPARQL

Clasificăm interogările în următoarele tipuri:SELECT – instrucțiunea de bază, pentru citire;SELECT cu clauza GRAPH sau FROM – citire cu filtrare după contexte;SELECT cu clauza SERVICE – accesare la distanță a unui serviciu SPARQL endpoint;ASK – interogări booleene (testează prezența sau absența unor cunoștințe);

DESCRIBE – returnează toate cunoștințele deținute despre un concept (interogare de bază în Linked Data, ca răspuns la accesarea conceptelor folosind identificatorii lor ca adrese);LOAD – încărcare de cunoștințe dintr-o sursă externă; INSERT DATA – adăugare de cunoștințe;INSERT WHERE – adăugare de cunoștințe la o anumită poziție în graf; DELETE DATA – ștergere de cunoștințe;

DELETE WHERE – ștergere de cunoștințe de la o anumită poziție în graf;INSERT/DELETE – modificare de cunoștințe (nu există UPDATE);ADD – unifică două contexte (nu se șterge conținutul existent la destinație);

MOVE – mută cunoștințe dintr-un context în altul (redenumește un context, căci se șterge conținutul existent la destinație);COPY – copiază cunoștințe dintr-un context în altul, înlocuind conținutul existent la destinație. Pentru exemplificare;

DROP – elimină un context cu toate cunoștințele sale.

Pentru exemplificarea interogărilor pornim de la următorul exemplu:

@base <http://expl.ro>.<#JamesCameron> <#aRegizat> <#Avatar>, <#Terminator>.<#Arnold> <#aJucat> <#Terminator>;

<#guverneaza> <#California>.<#Terminator> <#Titlu> “Terminator”.<#California> <#Nume> “California”.<#Arnold> <#Nume> "Arnold Schwarzenegger".

Page 434: licenta hatz

Web Semantic 45

<#JamesCameron> <#Nume> “James Cameron”.<#Avatar> <#Titlu> “Avatar”.

Posibile interogări:

base <http://expl.ro> SELECT ?film

WHERE <#JamesCameron> <#aRegizat> ?film

Răspunde la întrebarea Ce a regizat James Cameron?

base <http://expl.ro> SELECT ?propr ?obiect

WHERE <#Arnold> ?propr ?obiect.

Răspunde la Ce se știe despre subiectul Arnold?

base <http://expl.ro> SELECT ?nume

WHERE <#JamesCameron><#aRegizat>?x. ?nume <#aJucat> ?x.?nume <#guverneaza><#California>

Răspunde la Ce guvernator al Californiei a jucat pentru James Cameron?

base <http://expl.ro> SELECT ?film

WHERE <#JamesCameron><#aRegizat>?film. <#Arnold><#aJucat> ?film

Răspunde la Ce filme cu Arnold a regizat James Cameron?

base <http://expl.ro> SELECT ?nume

WHERE ?nume <#aRegizat> <#Terminator>UNION?nume <#aJucat> <#Terminator>

Limbajul SPARQL oferă și facilitatea importantă de a parcurge orice succesiune de arce în graful RDF, cu ajutorul căilor de proprietăți:

base <http://expl.ro> SELECT ?x

WHERE <#JamesCameron> <#ARegizat>/<#Titlu> ?x

Page 435: licenta hatz

46 Robert Andrei Buchmann

Două particularități importante ale limbajului SPARQL sunt posibilitatea de filtrare după context și interogarea la distanță a serviciilor. În setul de cunoștințe aici folosit nu avem contexte, deci oferim doar un exemplu abstract:

base <http://expl.ro>SELECT *

WHERE GRAPH <#context1> ?x ?y ?z

Răspunde la întrebarea Selectează toate cunoștințele din contextul #context1

SELECT *WHERE SERVICE <http://dbpedia.org/sparql> ?x ?y ?z

Răspunde la întrebarea Selectează toate cunoștințele oferite de serverul DBPedia.Un tip important de interogare este CONSTRUCT, care generează afirmații noi

din cele existente. Este important de reținut că nu le adaugă la cele existente ci le oferă doar clientului, deci nu este o operație de scriere în baza de cunoștințe (generarea de afirmații noi cu adăugare se realizează prin componenta SPARQL Update, mai exact interogărileINSERT WHERE).

base <http://expl.ro>CONSTRUCT ?x <#colaboreaza> ?y.WHERE ?x <#aRegizat> ?film. ?y <#aJucat> ?film

Operația creează un nou graf (set de tripleţi) din rezultatele interogării, adăugând totodată o proprietate nouă. Poate fi considerată o metodă de a produce tripleţi noi din tripleți existenți, deci un mod de implementare a regulilor! E vorba de reguli de tip query-time (generează concluzii la momentul interogării fără a le adăuga în baza de cunoștințe). Cealaltă categorie, regulile design-time se stabilesc încă de la crearea bazei de cunoștințe (pot fi modificate și pe parcurs) și produc concluziile imediat ce întâlnesc afirmațiile, fără să aștepte o interogare pentru asta (interogările găsesc concluziile gata generate).

base <http://expl.ro> ASK

?regizor <#aRegizat> ?film. ?actor <#aJucat> ?film

Răspunde la întrebarea Există în baza de cunoștințe regizori și actori care au lucrat la același film? Interogarea ASK are rezultat boolean, verifică doar existența sau absența șablonului.

base <http://expl.ro> DESCRIBE <#Terminator>

Page 436: licenta hatz

Web Semantic 47

Se returnează toate afirmațiile ce conțin conceptul respectiv. Aceasta e interogarea pe care se bazează Linked Data, când tratează un identificator URI ca adresă URL. Pe baza identificatorului, serverul de cunoștințe aplică o interogare DESCRIBE și returnează doar acel set de afirmații care conțin conceptul solicitat.

Interogările de citire își returnează rezultatele în diverse moduri:Există un format standard numit SPARQL results, cu două sintaxe, XML și JSON. Orice motor de interogare trebuie să poată oferi rezultatele în aceste două formate;Dacă interogarea returnează cunoștințe complete (tripleți RDF) se poate opta și pentru una din sintaxele RDF discutate deja, evitând astfel efortul de a extrage rezultatele din XML sau JSON;

Dacă interogarea e executată la distanță, prin unul din protocoalele bazate pe HTTP,programul ce inițiază interogarea poate indica prin câmpul Accept sintaxa în care dorește să primească rezultatele.

Formatul SPARQL Results are următoarea structură în XML și extensia de fișier.SRX:

<sparql><head>

<variable name=“?film” /></head><results>

<result><binding name=“film”>

<uri>http://expl.ro#Terminator</uri></binding>

</result></results>

</sparql>

2.5.2 Interogări SPARQL Update

prefix : <http://expl.ro#>.INSERT DATAGRAPH :Hi5:PopMaria :eRudaCu :PopMarian.:PopMarian :eRudaCu :PopAneta,:PopescuAlin.- se creează contextul Hi5 şi se încarcă în el trei relaţii de rudenie

prefix : <http://expl.ro#>.LOAD <http://server.com/exemplu.ttl> INTO GRAPH :Exemplu- se creează contextul Exemplu și se încarcă în el conținutul fișierului Turtle de pe

serverul indicat

Page 437: licenta hatz

prefix : <http://expl.ro#>. WITH :Exemplu

Page 438: licenta hatz

48 Robert Andrei Buchmann

INSERT ?y :eTatalLui ?xWHERE ?x :eFiicaLui ?y- în contextul Exemplu se generează o relație de tată pentru fiecare relație de fiică

găsit (prin inversarea subiectului și obiectului); acest tip de interogare seamănă cu CONSTRUCT prin aceea că generează relații noi din cele existente dar în timp ce CONSTRUCT oferă rezultatele direct consumatorului, INSERT le adaugă la baza de cunoștințe pentru a putea fi interogate și în viitor; practic e un mecanism de executare de reguli, căci o regulă nu e altceva decât un mecanism de generare de afirmații noi la descoperirea unui anumit șablon în afirmații existente.

prefix : <http://expl.ro#>. WITH :Facebook DELETE ?x ?y ?zWHERE :Ana :CunoastePe ?x- din contextul :Facebook se șterg toate afirmațiile despre indivizii pe care îi

cunoaște :Ana

prefix : <http://expl.ro#> WITH :Facebook DELETE :Ana ?x ?y INSERT :PopAna ?x ?y WHERE :Ana ?x ?y- în contextul :Facebook se modifică identificatorul Anei în :PopAna; e vorba de o

operație UPDATE însă, spre deosebire de SQL, aici nu avem o instrucțiune dedicată acestei operații și suntem nevoiți să îmbinăm o ștergere cu o inserare

DROP GRAPH :Facebook- elimină toate afirmațiile din contextul :Facebook

2.6 Reguli și concepte standardizate RDF/S

2.6.1 Vocabulare și ontologii

Un vocabular este un set de concepte cu identificatori fixați și semnificație ce se recomandă să fie adoptate de creatorii de cunoștințe pentru o mai bună performanță. Programele pot fi configurate să recunoască apariția acestor concepte și să le interpreteze ca reguli, apoi să execute acele reguli pentru a produce noi afirmații. Avem și vocabulare(impropriu numite limbaje) cu care se pot crea vocabulare, precum RDF Schema14 sau OWL15. Diferența între cele două este expresivitatea, bogăția de reguli care pot fi extrase din conceptele standardizate. O distincție particulară este că OWL oferă mecanisme de detectare a contradicțiilor, deci o formă de validare a cunoștințelor care până la acel nivel nu există. Vocabularele OWL mai sunt numite și ontologii, datorită posibilității lor de a defini relații complexe între toate conceptele unui domeniu de cunoaștere. Vocabularele RDF Schema mai sunt numite și taxonomii, datorită structurii lor ierarhice, de la concepte

14 http://www.w3.org/TR/rdf-schema/ 15http://www.w3.org/TR/owl-features/

Page 439: licenta hatz

Web Semantic 49

Page 440: licenta hatz

vagi, cu proprietăți puține (generale) la concepte specifice, cu proprietăți detaliate(specializate) - ierarhie care de obicei constituie scheletul unei potențiale ontologii.

Vocabularele nu sunt neapărat standardizate. Ele pot fi și vocabulare controlate, propuse de diverse organizații pentru a deservi un anumit domeniu, devenind suficient de populare încât să fie adoptate pe scară largă:

FOAF16, set de concepte cu care se pot descrie relațiile dintre oameni; GoodRelations17, pentru a descrie cataloage de produse;

Dublin Core18, pentru a descrie resurse informaționale (documente, cărți etc.);OpenGraph19, cu același scop ca FOAF, dar conceput de Facebook pentru a stoca relațiile sociale;voID20, pentru a descrie baze de cunoștințe (de exemplu câte clase, proprietăți, subiecte, obiecte conține);SPARQL Service Description21, pentru a descrie capabilitățile oferite de un server de tip SPARQL endpoint (ce contexte oferă, ce versiune de SPARQL suportă etc.);OWL-Time22, pentru a indica în mod precis momente și perioade de timp (utilă în a atașa contexte temporale afirmațiilor);GeoOWL23, pentru a indica în mod precis locații și concepte spațiale (utilă în a atașa contexte spațiale afirmațiilor);DBPedia24, setul de concepte oferite de Wikipedia, fără a avea un domeniu de utilizare specific. Obiectivul său este să devină un dicționar de referință pentru diverși termeni comuni, o limbă comună la care să se alinieze cât mai multe baze de cunoștințe (undeziderat periculos sub anumite aspecte, ce riscă să încalce principiile descentralizăriiWeb).

În continuare vom dedica acest capitol conceptelor standard oferite de vocabularele RDF și RDF Schema, prezentând identificatorii lor stabiliți, semnificația, idei de utilizare și eventualele reguli pe care ar trebui să le declanșeze în sisteme dotate cu capacități inferențiale.

2.6.2 Concepte RDF/S

Deși RDF și RDF Schema au fost inițial propuse ca vocabulare diferite, primul prefixat cu rdf, al doilea cu rdfs, adesea e nevoie să fie folosite împreună chiar în aceeași afirmație, deci trasarea unei linii de demarcare între cele două vocabulare e inutilă. Prefixul rdf trebuie asociat spațiului de nume:

<http://www.w3.org/1999/02/22-rdf-syntax-ns#>

Prefixul rdfs trebuie asociat spațiului de nume:

16 http://www.foaf-project.org/ 17http://www.heppnetz.de/projects/goodrelations/ 18http://dublincore.org/ 19http://developers.facebook.com/docs/opengraph/ 20http://vocab.deri.ie/void 21http://www.w3.org/TR/2009/WD-sparql11-service-description-20091022/ 22http://www.w3.org/TR/owl-time/ 23http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/ 24http://dbpedia.org/About

Page 441: licenta hatz

50 Robert Andrei Buchmann

<http://www.w3.org/2000/01/rdf-schema#>

Conceptele acestor vocabulare sunt următoarele, începând cu cele mai primitive:

Conceptul de resursă (rdfs:Resource)Aceasta e considerată mulțimea tuturor lucrurilor și include orice concept, orice

clasă, orice dată indiferent de tip. Nu există în univers entități care să nu poată fi clasificate drept resurse. Definiția oficială a resursei este una extrem de vagă: orice lucru despre care se poate face o afirmație, și e inspirată de una din definițiile filosofice ale obiectului, care, conform lui Charles Peirce, este anything we can think or talk about25. Din acest motiv, conceptul e asociat unei reguli de forma:

Dacă avem:?x ?y ?zSe va genera:?x a rdfs:Resource ?y a rdfs:Resource ?z a rdfs:Resource

De exemplu, din afirmația…@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Ana :esteMamaLui :Alin.…se va deduce:Ana a rdfs:Resource. :esteMamaLui a rdfs:Resource. :Alin a rdfs:Resource.

Această regulă înseamnă că indiferent ce afirmație RDF am face, toate elementele sale vor deveni resurse. Prin întrebarea Ce este X? trebuie înțelegem o interogare SPARQL de forma:

SELECT ?multimeWHERE X a ?multime

Conceptul de proprietate (rdf:Property)Aceasta e mulțimea tuturor proprietăților pe care le-ar putea avea conceptele,

indiferent că sunt atribute sau relații cu alte lucruri. Definiția sa e dată de convenția RDF privind structura unei afirmații: orice lucru care apare la mijlocul unei afirmații (între subiect și obiect), deci e un răspuns suplimentar care se poate da despre conceptul din mijloc: pe lângă a fi resursă, mai este și o proprietate. Regula este următoarea:

Dacă avem:?x ?y ?zSe va genera: ?y a rdf:Property

Page 442: licenta hatz

25 http://www.helsinki.fi/science/commens/terms/object.html

Page 443: licenta hatz

Web Semantic 51

Conceptul de mulțime (rdfs:Class) și proprietatea de a aparține unei mulțimi(rdf:type, a în Turtle):

Mulțimea e sinonimă cu clasa în RDF. Aceasta e o posibilă sursă de confuzie pentru cei familiarizați cu programarea obiectuală, obișnuiți să vadă clasa drept un model din care se creează mai multe obiecte (proprietățile sunt deduse din apartenența la clasă). Aici, clasa e mulțimea obiectelor care sunt aliniate unui anumit model (apartenența la clasă e dedusă din prezența unei proprietăți). Clasele sunt extrem de importante deoarece oferă un răspuns mai detaliat la întrebările de forma Ce este X? Răspunsul că este resursă e unul foarte vag, cu încărcătură semantică minimă. Rolul RDF Schema și OWL este să rafineze acest răspuns, să detecteze cât mai precis ce sunt lucrurile în funcție de relațiile pe care le au, deci clasa funcționează și ca o etichetă aplicată unui lucru: Om (eticheta/mulțimea tuturor oamenilor), Animal (eticheta/mulțimea animalelor), AnimalPatruped (eticheta/submulțimea patrupedelor, ceva mai precisă decât a animalelor), Student (eticheta/mulțime generală a studenților), StudentBun (eticheta/submulțime ceva mai precisă a studenților), StudentDeNota10 (submulțime și mai precisă). Deși cel mai des apartenența la o clasă se deduce prin reguli (RDF Schema și OWL), avem și posibilitatea de a o afirma direct, caz în care din afirmații precum…

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Ana a :Om.…se va deduce::Om a rdfs:Class.

În astfel de afirmații, regula aplicată este următoarea:

Dacă avem:?x a ?zSe va genera: ?z a rdfs:Class.

Conceptele de tip (rdfs:Datatype) și de valoare (rdfs:Literal)Primul este mulțimea tuturor tipurilor de date, al doilea este mulțimea tuturor

datelor posibile, a valorilor pe care le pot lua obiectele RDF. Regulile pot deduce că orice tip de date este un element al primei mulțimi și o submulțime a celei de-a doua. Pornind de la afirmația…

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix xsd: <http://www.w3.org/2001/XMLSchema#>. :Ana :areVarsta "20"^^<xsd:integer>.

…se va deduce că:<xsd:integer> a rdfs:Datatype; rdfs:subClassOf rdfs:Literal.(orice tip de date este o mulțime de valori, un element al mulțimii tipurilor și o

submulțime a mulțimii tuturor valorilor posibile)

Page 444: licenta hatz

Relația de incluziune între clase (rdfs:subClassOf)

Page 445: licenta hatz

52 Robert Andrei Buchmann

Aceasta este una din relațiile cele mai importante din RDF Schema, care exprimă incluziunea dintre două mulțimi. Cu ajutorul ei se creează ierarhia de clase (taxonomia) ce constituie scheletul unui vocabular și al unei potențiale ontologii care se poate dezvolta din acesta. Pornind de la afirmațiile…

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Andrei a :Barbat.:Barbat rdfs:subClassOf :Om. :Om rdfs:subClassOf :Fiinta.

…se vor deduce::Andrei a :Om, :Fiinta.:Barbat rdfs:subClassOf :Fiinta. :Barbat a rdfs:Class.:Om a rdfs:Class. :Fiinta

a rdfs:Class.

Regulile aplicate sunt:Dacă avem

?x a ?c1.?c1 rdfs:subClassOf ?c2.

Se vor genera:?x a ?c2.?c1 a rdfs:Class. ?c2 a rdfs:Class.

Dacă avem?c1 rdfs:subClassOf ?c2. ?c2 rdfs:subClassOf ?c3.

Se va genera:?c1 rdfs:subClassOf ?c3. ?c1 a rdfs:Class.?c2 a rdfs:Class. ?c3 a rdfs:Class.

Această relație are două roluri esențiale:De a defini taxonomia schelet din care se poate dezvolta mai departe o ontologie;

De a oferi mecanisme de mapare între baze de cunoștințe diferite ce folosesc clase înrudite, chiar identice.

În ce privește primul punct, o taxonomie este o clasificare pe mai multe nivele, unarbore în care toate nodurile sunt clase și toate arcele sunt relații de incluziune(rdfs:subClassOf):

Relația de particularizare între proprietăți (rdfs:subPropertyOf)Acesta e cea de-a doua relație fundamentală a unui vocabular XML Schema. E

menită să completeze taxonomia claselor cu o taxonomie a relațiilor și una a atributelor ce vor fi folosite în baza de cunoștințe.

E important să nu se confunde această relația cu cea de incluziune. Proprietățile RDF nu sunt mulțimi, deci nu e vorba de elemente comune între două proprietăți.

Page 446: licenta hatz

Web Semantic 53

Subproprietatea e un ceva cu sens mai specific, particularizat la anumite situații, față de supraproprietatea sa. Pornind de la exemplul…

:JamesCameron :aRegizat :Terminator. :aRegizat rdfs:subPropertyOf :aCreat. :aCreat rdfs:subPropertyOf :aLucratLa.

…se vor deduce::JamesCameron :aCreat :Terminator. :JamesCameron :aLucratLa :Terminator. :aRegizat

rdfs:subPropertyOf :aLucratLa. :aRegizat a rdf:Property.

:aCreat a rdf:Property. :aLucratLa a

rdf:Property.

Regulile aplicate au fost:Dacă avem:?x ?p1 ?y?p1 rdfs:subPropertyOf ?p2 Se va genera:?x ?p2 ?y

Dacă avem:?p1 rdfs:subPropertyOf ?p2 ?p2 rdfs:subPropertyOf ?p3 Se va genera:?p1 rdfs:subPropertyOf ?p3 ?p1 a rdf:Property?p2 a rdf:Property ?p3 a rdf:Property

Prima regulă permite înlocuirea unei relații cu alta, mai generală, între aceiași indivizi. A doua regulă reprezintă tranzitivitatea acestor înlocuiri, precum și detectarea faptului că toate conceptele implicate într-o astfel de ierarhie sunt proprietăți.

owl:topObjectProperty

:ALucratLa

:ACreat

:ARegizat:JamesCameron :Terminator

Fig. 10 – Propagarea proprietăților

Ca și în cazul incluziunii, putem folosi această relație pentru a defini taxonomii de proprietăți sau pentru a mapa proprietăți cu semnificație similară dar identificatori diferiți

Page 447: licenta hatz

54 Robert Andrei Buchmann

(din baze de cunoștințe diferite). Vocabularul OWL completează tabloul cu câteva proprietăți standard:

owl:topObjectProperty – relația universală între două concepte, care există între oricare două resurse din univers (faptul că aparțin aceluiași univers?);owl:topDataProperty – atributul universal, pe care îl are orice concept și poate lua orice valoare;owl:bottomObjectProperty – relația absurdă între două concepte, nu are voie să apară în nicio bază de cunoștințe (sau apariția sa poate fi folosită ca semnal de apariție a unei contradicții);owl:bottomDataProperty – atributul absurd (nu poate avea valoare pentru nici un concept).

Proprietatea unei proprietăți de a avea domeniu (rdfs:domain) și codomeniu(rdfs:range)

După ce s-au creat taxonomiile de clase și de proprietăți, se recomandă ca acestea să fie conectate. Aceasta presupune ca pentru fiecare proprietate din taxonomie să se indice cu ce fel (clasă) de subiecte (domeniul) și cu ce fel de obiecte (codomeniul) va fi folosită.Pornind de la afirmația…

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :JamesCameron :ARegizat :Terminator.:ARegizat rdfs:domain :Regizor; rdfs:range :Film.…regulile vor deduce::JamesCameron a :Regizor. :Terminator a :Film.

Regulile aplicate sunt:Dacă avem:?x ?p ?y?p rdfs:domain ?cRezultă:?x a ?c

Dacă avem:?x ?p ?y?p rdfs:range ?cRezultă:?y a ?c

Conceptul de Container (rdfs:Container, rdf:Bag, rdf:Seq, rdf:Alt) și relațiile de apartenență la un container (rdf:_1, rdf:_2 etc.; rdfs:member, rdfs:ContainerMembershipProperty)

Un container se aseamănă cu clasa prin aceea că este o mulțime, însă relația pe care fiecare concept o are cu containerul este de altă natură. Apartenența la o clasă (rdf:type) ar trebui să fie dictată de o oarecare asemănare între indivizi, de prezența unor proprietăți comune (de aceea poate fi dedusă din rdfs:domain și rdfs:range). În schimb un container poate fi un set de elemente grupate după orice criterii. Apartenența elementelor la un container poate fi afirmată prin două relații (spre deosebire de apartenența la clase, aici containerul apare ca subiect iar elementele sale ca obiecte):

Page 448: licenta hatz

Web Semantic 55

Page 449: licenta hatz

@prefix : <http://expl.ro#>.:calculator rdfs:member :procesor, :placaBaza, :disc.sau@prefix : <http://expl.ro#>.:mapaDocumente rdf:_1 :certificatNastere; rdf:_2 :diplomaBacalaureat; rdf:_3 :adeverintaSalariu.

Din prima construcție, regulile vor putea deduce::calculator a rdfs:Container.Din a doua::mapaDocumente a rdfs:Container.:mapaDocumente rdfs:member :certificatNastere, :diplomaBacalaureat, :adeverintaSalariu.

Se recomandă adăugarea unor declarații explicite asupra tipului de container (multțime, secvență sau set de alternative):

:calculator a rdf:Bag. :mapaDocumente

a rdf:Seq.

:VarianteCadou a rdf:Alt; rdf:_1 :Automobil; rdf:_2 :Canapea; rdf:_3 :Bicicleta.

Conceptul de Listă (rdf:List, rdf:nil) și relațiile de apartenență la o listă(rdf:first, rdf:rest).

Lista este o colecție de concepte ordonată și închisă, pentru care Turtle oferă o abreviere sintactică des folosită:

@prefix : <http://expl.ro#>.:Ana :areCopiii (:Alin :Maria :Marian).

Regulile vor converti întotdeauna o astfel de afirmație în următorul set::Ana :areCopiii [a rdf:List; rdf:first :Alin; rdf:rest [a rdf:List; rdf:first :Maria; rdf:rest [a rdf:List;

rdf:first :Marian; rdf:rest rdf:nil]]].

Interpretarea acestei construcții e următoarea: copiii Anei sunt cuprinși într-o listă al cărei prim element e :Alin, urmat de o sublistă al cărei prim element e :Maria, urmată de o sublistă al cărei prim element e :Marian, urmat de un final de listă (rdf:nil reprezintă încheierea listei). Așadar e o structură de concepte ordonate asemănătoare cu rdf:Seq dar care oferă o informație în plus: e închisă, are un element despre care se poate zice că e ultimul și nimic după el nu mai există. Cu ajutorul interogărilor SPARQL se poate afla relativ ușor care e ultimul element al listei, căutând conceptul rdf:nil:

prefix : <http://expl.ro#> SELECT ?element

WHERE ?x rdf:first ?element; rdf:rest rdf:nil

Listele sunt mai apropiate claselor decât containerele, prin aceea că de obicei elementele enumerate într-o listă au o semnificație comună, ar putea deveni elementele unei clase. De aceea, vom vedea mai târziu, OWL se bazează pe liste la definirea claselor: permite ca o clasă să fie creată prin enumerarea listei elementelor sale (și prin aceasta aplică și o închidere clasei); în plus mai permite ca o clasă să fie definită prin intersecție sau reuniune aplicate asupra unei liste de alte clase.

Page 450: licenta hatz

56 Robert Andrei Buchmann

Conceptul de valoare principală (rdf:value)Acesta e un concept util în relațiile de aritate superioară, pentru a indica nodul ce

reprezintă valoarea principală a relației respective. Programele care cunosc deja structura relației de aritate superioară vor putea folosi interogări SPARQL care să extragă doar această valoare principală, ignorând restul structurii.

Andrei are 10 la Matematică.

Exprimarea Turtle a acestei afirmații se poate realiza în multiple moduri, fiind recomandată o relație de aritate 3 construită în jurul unui nod anonim:

:Andrei :areNota [rdf:value 10; :curs :Matematica].

Presupunând că un program cunoaște deja despre ce note este vorba, va putea formula interogări SPARQL care să acceseze direct valorile rdf:value.

Conceptul de afirmație reificată (rdf:Statement) și relațiile de apartenență la o afirmație reificată (rdf:subject, rdf:predicate, rdf:object)

O afirmație reificată e o afirmație ce poate fi folosită ca subiect sau obiect al altei afirmații, de obicei pentru a preciza contextul în care e valabilă afirmația sau sursa sa. Am arătat deja că reificarea nu e un model foarte popular deoarece transformă afirmația reificată într-un grup de tripleți. Dacă dorim să exprimăm…

Ana crede că Alin are vârsta 30.…vom scrie:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. :Ana :crede _:x._:x rdf:subject :Alin; rdf:predicate :areVarsta; rdf:object 30 . _:x a rdf:Statement.

Proprietatea de denumire (rdfs:label)Denumirile sunt șiruri de caractere menite a fi folosite în rapoarte, pagini Web și

orice document bazat pe cunoștințe ce se adresează unui cititor uman pentru care URI ar putea crea probleme la citire (mai ales că nu e obligatoriu ca URI să sugereze în vreun fel semnificația conceptului, poate fi un șir aleatoriu de caractere!). RDF Schema oferă o proprietate standard pentru alocarea de denumiri. Dacă dorim totuși să folosim propriile proprietăți în acest scop (situație uzuală!), putem realiza o mapare față de rdfs:label. Pornim de la:

@prefix : <http://expl.ro#>.@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Ana :Nume "Popescu Ana".:DieHard :Titlu "Die Hard"@en, "Greu de ucis"@ro...declarăm maparea::Nume rdfs:subPropertyOf rdfs:label. :Titlu rdfs:subPropertyOf rdfs:label.

…se va deduce:

Page 451: licenta hatz

:Ana rdfs:label "Popescu Ana".:DieHard rdfs:label "Die Hard"@en, "Greu de ucis"@ro.

Page 452: licenta hatz

Web Semantic 57

Page 453: licenta hatz

…apoi agenții software vor putea prin interogări SPARQL să identifice etichetele textuale relevante pentru fiecare concept!

Proprietatea de a avea un comentariu (rdfs:comment)Această proprietate funcționează similar cu rdfs:label, ne permite să atașăm un șir

de caractere unui concept, însă rolul șirului de caractere nu e de a oferi o denumire lizibilă, ci de a atașa un comentariu care să explice cât mai detaliat semnificația acelui concept pentru un cititor uman care ar putea opta să parcurgă cunoștințele noastre în sintaxa lor brută, mai ales dacă denumirea sau identificatorul URI nu. sunt foarte sugestive:

:ProABC rdfs:comment "acest concept reprezintă compania Prosperitas ABC, cu sediul în ClujNapoca".

Proprietatea de a avea o pagină Web definitorie (rdfs:isDefinedBy)În capitolul legat de identitatea în Semantic Web s-a atras atenția asupra crizei

identității, prin care un identificator nu ar trebui folosit și pe post de pagină Web. De aceea, chiar dacă Wikipedia oferă pagini Web pentru numeroase concepte, sau Facebook pentru numeroase persoane, nu ar trebui să folosim acele adrese pentru a identificarea de concepte. În schimb putem să indicăm faptul că dacă se doresc informații detaliate despre concept, pot fi găsite pe o pagină Wikipedia sau pe alt site. Exemplul următor indică faptul că relația de frate poate fi înțeleasă depe pagina oferită de Wikipedia pentru cuvântul brother:

@prefix : <http://expl.ro#>.@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :esteFrateCu rdfs:isDefinedBy <http://en.wikipedia.org/wiki/Brother>.

Într-un capitol ulterior, dedicat fenomenului Linked Data vom arăta că un server poate oferi simultan informații despre un concept în format HTML și în format RDF. În acest caz, e recomandat ca baza de cunoștințe să conțină asocieri precum cea de mai sus, pentru a indica fișierele care sunt reprezentative pentru concept.

Proprietatea de a avea pagini Web descriptive alternative (rdfs:seeAlso)Cum același concept poate fi descris de numeroase pagini Web (site propriu, o

pagină Wikipedia, o pagină Facebook, un blog etc.) avem posibilitatea de a anexa oricâte pagini Web secundare, considerate nedefinitorii pentru înțelegerea conceptului, dar totuși relevante. Printre acestea se pot număra chiar baze de cunoștințe RDF disponibile direct peWeb, precum cele oferite de DBPedia:

@prefix : <http://expl.ro#>.@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :MichaelJackson rdfs:isDefinedBy <http://www.michaeljackson.com>;

rdfs:seeAlso <http://en.wikipedia.org/wiki/Michaeljackson>; rdfs:seeAlso < http://dbpedia.org/resource/Michael_Jackson>.

Mai menționăm că rdfs:isDefinedBy e o subproprietate a lui rdfs:isDefinedBy, deci se generează automat:

:MichaelJackson rdfs:seeAlso <http://www.michaeljackson.com>.Aceasta ne permite să obținem toate paginile despre MichaelJackson printr-o

singură interogare SPARQL, căutând doar relațiile rdfs:seeAlso.

În încheiere, sintetizăm 4 tipuri de ierarhii care pot apare într-o bază de cunoștințe:

Page 454: licenta hatz

58 Robert Andrei Buchmann

ierarhia de clase, bazată pe relația rdfs:subClassOf, toate nodurile fiind clase; o posibilă ramură într-un astfel de arbore ar fi::Femeie rdfs:subClassOf :Om. :Om rdfs:subClassOf :Fiinta. :Fiinta rdfs:subClassOf owl:Thing.ierarhia de proprietăți, bazată pe relația rdfs:subPropertyOf, toate nodurile sunt proprietăți; o posibilă ramură într-un astfel de arbore ar fi::ARegizat rdfs:subPropertyOf :ACreat. :ACreat rdfs:subPropertyOf owl:topObjectProperty.ierarhia de containere, bazată pe relații rdfs:member sau rdfs:_1, rdfs:_2 (deoarece aceste concepte oricum nu deduc concluzii foarte valoroase, în practică sunt adesea ignorate și înlocuite cu concepte și relații improvizate); o posibilă ramurăîntr-un astfel de arbore ar fi::Calculator rdfs:member :UnitateCentrala. :UnitateCentrala rdfs:member :PlacaBaza.teoretic e posibilă și o ierarhie de tip instanță-(clasă/instanță)-(clasă/instanță)-…, atunci când un același concept e tratat ca individ și ca mulțime în afirmații diferite; o posibilă ramură într-un astfel de arbore ar fi::Andrei rdf:type :Om. :Om rdf:type rdfs:Class. rdfs:Class rdf:type rdfs:Resource.

2.7 Reguli și concepte standardizate OWL

Vocabularul OWL, ajuns la versiunea 226, vine să completeze cu o expresivitate superioară și noi reguli conceptele oferite de RDF Schema. Un beneficiu important pe careîl aduce este posibilitatea de a detecta contradicții. Cu conceptele RDF Schema acest lucru nu e posibil, deoarece nu există nicio metodă de a exprima negarea, iar pentru a exprima o contradicție e nevoie să existe simultan în baza de cunoștințe o afirmație și negarea sa. Vocabularul OWL oferă prin conceptele sale:

posibilitatea de a afirma explicit că o afirmație este falsă;posibilitatea de a defini tipuri de date personalizate prin restricții XML Schema;posibilitatea de a descrie o bază de cunoștințe în ansamblul ei;

concepte în care negarea este implicită; e vorba de acele relații care exprimă incompatibilitatea între concepte: distincția între indivizi, disjuncția între clase și proprietăți;relații pentru exprimarea mai facilă a echivalenței, făcând mai ușoare mapările prin echivalențe explicite între indivizi, clase și proprietăți;

reguli ce pot deduce echivalența și distincția;noi tipuri de proprietăți;o serie de tehnici de definire a claselor și de deducere a apartenenței indivizilor:

o prin enumerarea directă a elementelor;o prin operații pe mulțimi (reuniune, intersecție, complement);o prin restricții aplicate asupra utilizării proprietăților (o rafinare a modului

de lucru prezentat la rdfs:domain și rdfs:range, în care, pentru a fi inclus într-o clasă, nu e suficient să folosești o proprietate, contează și cum o folosești).

Page 455: licenta hatz

26 http://www.w3.org/TR/owl-overview/

Page 456: licenta hatz

Web Semantic 59

2.7.1 Clase și relații introduse de OWL 2

Conceptul de instanță, individ (owl:NamedIndividual) și cel de clasă OWL(owl:Class)

Aceasta este mulțimea tuturor indivizilor, pe același nivel de abstractizare cu mulțimea tuturor claselor. Am prezentat în capitolul precedent posibilitatea de a deduce că un concept e clasă, din afirmații precum cea de apartenență a unui element la o mulțime. RDF nu oferă însă și o metodă explicită de a afirma că un concept este un individ. OWL completează acest neajuns. Ca și declarația de clasă, de obicei această afirmație se deduce din relații instanță-clasă, nu se afirmă direct:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana a :Femeie.Pe lângă deducția asigurată de RDF, un program ce execută și reguli OWL va mai

deduce::Ana a owl:NamedIndividual. :Femeie a

owl:Class.

Prin prima concluzie se afirmă că :Ana este un individ cu identitate, prin a doua se afirmă că :Femeie este o clasă. Observați că pentru mulțimea tuturor claselor aveam deja conceptul standard rdfs:Class, și totuși aici s-a dedus owl:Class. Aceasta este considerată o submulțime a lui rdfs:Class.

Conceptele universale (owl:Thing, owl:topObjectProperty, owl:topDataProperty), absurde (owl:Nothing, owl:bottomObjectProperty, owl:bottomDataProperty) și depreciate (owl:DeprecateClass, owl:DeprecatedProperty).

O parte din aceste concepte au fost prezentate deja în secțiunea dedicată taxonomiilor RDF Schema. Conceptele universale și absurde sunt menite să întregească taxonomia de clase cu mulțimea tuturor lucrurilor din univers (owl:Thing) și mulțimea vidă (owl:Nothing), respectiv să întregească taxonomia de proprietăți cu proprietățile care există pentru orice concept (owl:top…Property) și cele care nu au voie să apară pentru niciunul (owl:bottom…Property). Rolul conceptelor absurde este să fie folosite în concluziile unor reguli menite să surprindă contradicțiile. De exemplu, orice concept detectat ca fiind contradictoriu poate fi declarat membru al lui owl:Nothing și orice relație contradictorie poate fi declarată subproprietate a uneia dintre cele două owl:bottom…Property. Apoi, o interogare SPARQL poate lista conceptele contradictorii bazându-se pe aceste relaționări.

Cele două clase depreciate (una pentru clase, una pentru proprietăți) sunt două mulțimi în care se pot încadra explicit clase sau proprietăți care au fost redefinite în versiuni mai noi și urmează să fie șterse sau sunt păstrate din rațiuni de documentare:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :ClasaVeche a owl:DeprecatedClass.:ProprietateVeche a owl:DeprecatedProperty.

Page 457: licenta hatz

60 Robert Andrei Buchmann

Categorii de proprietăți: relație (owl:ObjectProperty), atribut(owl:DataProperty), adnotare (owl:AnnotationProperty), adnotare de ontologie (owl:OntologyProperty)

Acestea sunt mulțimile relațiilor, atributelor, adnotărilor și proprietăților bazelor de cunoștințe, toate submulțimi ale lui rdf:Property:

în categoria relațiilor intră (prin deducție) orice proprietate ce are drept obiect un identificator URI sau nod anonim;în cea a atributelor intră (prin deducție) orice proprietate ce are drept obiect o valoare;în cea a adnotărilor sunt încadrate implicit proprietăți standard ce atașează explicații suplimentare unui concept: rdfs:label, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, la care se adaugă owl:versionInfo ce atașează un comentariu unei baze de cunoștințe în ansamblul său, preferabil unul care să indice informații de versiune (data creării, autor, număr de versiune); subiectul acestei proprietăți e întotdeauna o bază de cunoștințe, iar obiectul un șir de caractere;celelalte proprietăți ale bazelor de cunoștințe sunt încadrate în clasa owl:OntologyProperty, le detaliem în continuare:

Conceptul de afirmație falsă (owl:NegativePropertyAssertion, cu componentele owl:sourceIndividual, owl:assertionProperty, și owl:targetIndividual/owl:targetValue)

OWL introduce posibilitatea de a afirma explicit valoarea de adevăr a afirmațiilor. Tehnica nu e una comodă, fiind inspirată din modelul afirmațiilor reificate, în care o afirmație e transformată în nod anonim și conectată cu cele trei componente ale sale. Presupunem că dorim să exprimăm:

Ana are varsta 20 este o afirmație falsă.Ana este mama lui Alin este o afirmație falsă.Vom introduce cunoștințele:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>._:afirmatie1 a owl:NegativePropertyAssertion.

owl:sourceIndividual :Ana;owl:assertionProperty :areVarsta;owl:targetValue 20 .

_:afirmatie2 a owl:NegativePropertyAssertion.owl:sourceIndividual :Ana;owl:assertionProperty :esteMamaLui;owl:targetIndividual :Alin.

Teoretic regulile ar putea deduce apartenența celor două noduri anonime la mulțimea owl:NegativePropertyAssertion (liniile îngroșate), din prezența celor trei componente, scutindu-ne de a afirma explicit acest lucru. Totuși, e posibil ca cele trei relații să aibă în viitor și alte utilizări sau să fie eliminate cu totul (unii practicieni preferă să folosească structura de la reificare, folosind tot rdf:subject, rdf:predicate, rdf:object pentru a separa componentele unei afirmații false). În plus poate fi nevoie frecvent să facem afirmații false într-o bază de cunoștințe ce nu suportă reguli, caz în care e preferabil să exprimăm complet ideea că vorbim de afirmații false.

Page 458: licenta hatz

Web Semantic 61

Conceptul de axiomă adnotată (owl:Axiom, cu componentele owl:annotatedSource, owl:annotatedProperty, owl:annotatedTarget)

Este o construcție asemănătoare afirmațiilor false sau reificate, dar rolul său este să ofere o adnotare (comentariu, denumire, site lămuritor) despre o întreagă afirmație. Seamănă cu reificarea, dar o afirmație reificată e descrisă mai departe tot prin tripleți RDF, în timp ce afirmația adnotată e descrisă prin proprietățile de adnotare oferite de RDF Schema. Adnotarea de afirmații e folosită adesea pentru a scrie aceeași afirmație și în limbaj natural, oferind astfel o "traducere" din RDF.

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. _:afirmatie1 owl:annotatedSource :Ana;

owl:annotatedProperty :esteMamaLui; owl:annotatedTarget :Alin;rdfs:label "Ana este mama lui Alin ".

_:afirmatie1 a owl:Axiom.

Relația de reciprocitate între două relații (owl:inverseOf)Sunt frecvent întâlnite situațiile în care introducem un set de relații între indivizii

din baza de cunoștințe și ne așteptăm ca în mod automat să se deducă și relațiile inverse: dacă X e parintele lui Y, să nu mai tastăm și faptul că Y e copilul lui X. Dacă serverul de cunoștințe nu suportă reguli, astfel de inversiuni se pot genera dinamic prin interogăriCONSTRUCT sau INSERT, atunci când e nevoie. Totuși, OWL permite generarea automată a relațiilor inverse printr-o simplă declarare de reciprocitate. Din următorul exemplu…

@prefix : <http://expl.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :eParinteleLui owl:inverseOf :eCopilulLui.

:Alin :eParinteleLui :Andrei.…se va deduce::Andrei :eCopilulLui :Alin.

Proprietatea de simetrie a unei relații (owl:SymmetricProperty)O variație a situației precedente este situația în care dorim să afirmăm că relația

funcționează în ambele sensuri fără a i se schimba identificatorul. În mod implicit tripletul RDF e unidirecțional – pentru a afirma că două persoane sunt căsătorite trebuie să facem două afirmații, indicând relația de căsătorie în ambele sensuri. Ca și în cazul precedent, putem rezolva această situație la momentul interogării, sau stabilind de la bun început o regulă OWL care să genereze automat relațiile inverse. Din exemplul…

@prefix : <http://expl.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :eRudaCu a owl:SymmetricProperty.

:Ana :eRudaCu :Alin.…se va deduce::Alin :eRudaCu :Ana.

Proprietatea de reflexivitate a unei relații (owl:ReflexiveProperty)Aceasta este o submulțime a lui owl:SymmetricProperty și conține acele relații

care conectează un individ cu el însuși. Cu alte cuvinte, toate lucrurile din univers au acea

Page 459: licenta hatz

62 Robert Andrei Buchmann

relație cu ele însele. De exemplu, putem indica faptul că orice om se cunoaște pe sine, astfel:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :CunoastePe a owl:ReflexiveProperty.:Ana a :Femeie.…se va deduce::Ana a owl:NamedIndividual.…iar în baza faptului că Ana este un individ…:Ana :CunoastePe :Ana.

Proprietatea de tranzitivitate a unei relații (owl:TransitiveProperty)Aceasta e o altă submulțime a lui owl:ObjectProperty, prin care afirmăm că o

relație care înlănțuie mai mulți indivizi e aplicabilă între primul și ultimul individ din lanț. Din următorul exemplu…

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:eFrateCu a owl:TransitiveProperty. :Alin :eFrateCu :Andrei.

:Andrei :eFrateCu :Mihai.…se va deduce::Alin :eFrateCu :Mihai.

Conceptul de lanț de proprietăți (owl:propertyChainAxiom).Aceasta e o generalizare a tranzitivității, când lanțul de relații poate conține relații

diversificate și dorim să indicăm semnificația pe care o poate produce o combinație de relații înlănțuite. De exemplu, o relație de fiu înlănțuită cu una de frate trebuie interpretată ca o relație de nepot între primul și ultimul individ din lanț:

@prefix : <http://expl.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :eNepotulLui owl:propertyChainAxiom (:eFiulLui :eFrateCu). :Alin :eFiulLui :Andrei.:Andrei :eFrateCu :Mihai.…se va deduce::Alin :eNepotulLui :Mihai.Relațiile de echivalare a indivizilor (owl:sameAs), a claselor

(owl:equivalentClass), a proprietăților (owl:equivalentProperty).Aceste concepte ne scutesc de a folosi reciprocitatea relațiilor rdfs:subClassOf și

rdfs:subPropertyOf pentru a declara echivalența. Principalele utilizări sunt:Atunci când sunt direct afirmate, echivalențele facilitează maparea între baze de cunoștințe din organizații diferite sau alinierea unei baze de cunoștințe la un vocabular standard / controlat, fără a substitui conceptele originale;În alte situații echivalențele sunt deduse, nu afirmate direct, prin reguli menite să surprindă situațiile în care un același concept are multiple identități;În sfârșit, echivalențele mai sunt folosite la detectarea contradicțiilor (când un set de reguli concluzionează simultan că două concepte sunt identice și distincte). Din următorul exemplu:@prefix : <http://expl.ro#>.@prefix alt: <http://altdomeniu.ro#>.

Page 460: licenta hatz

Web Semantic 63

Page 461: licenta hatz

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana :este :Femeie. alt:Ann a alt:Woman. :Ana owl:sameAs alt:Ann.:Femeie owl:equivalentClass alt:Woman. :este owl:equivalentProperty rdf:type.

Se vor deduce::Ana :este alt:Woman. :Ana a alt:Woman. :Ana a :Femeie.

alt:Ann :este alt:Woman. alt:Ann :este :Femeie. alt:Ann a :Femeie.

Așadar, echivalența produce dublarea afirmațiilor pentru fiecare pereche de concepte echivalente găsite. Această tehnică poate duce la expandarea puternică a bazei de cunoștințe și poate afecta grav performanța interogărilor. Din păcate numeroase produse demo sau gratuite se bazează pe ea. Produsele comerciale încearcă să rezolve problema prin mecanisme optimizate, de exemplu întreținerea unui index de echivalențe pe baza căruia se generează afirmațiile echivalente doar la momentul interogării, apoi sunt șterse (după ce nu mai e nevoie de ele).

Relațiile de distincție între indivizi (owl:differentFrom), între clase (owl:disjointWith, owl:complementOf), între proprietăți (owl:propertyDisjointWith).

Aceste proprietăți sunt menite să introducă negația implicită în afirmații și să genereze prin regulile lor contradicții, când apar în aceeași bază de cunoștințe alături de cele de echivalare. Ca și echivalențele, distincțiile pot fi afirmate direct (de exemplu pentru a realiza o contra-mapare, afirmarea clară a faptului că două ontologii ce par să conțină aceleași lucruri nu vor să fie echivalate) sau pot fi deduse din alte reguli. Se poate afirma distincția între indivizi (owl:differentFrom), faptul că două clase nu pot avea elemente comune (owl:disjointWith) și faptul că două proprietăți nu au voie să apară între același subiect și obiect (owl:propertyDisjointWith).

Putem afirma direct o serie de contradicții:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana owl:sameAs :Ann. :Ana owl:differentFrom :Ann.

:Femeie owl:equivalentClass :Barbat. :Femeie

owl:disjointClass :Barbat.

:areCopilPe

owl:propertyDisjointWith :esteCopilulLui. :Maria :areCopilPe :Andrei.

:Maria :esteCopilulLui :Andrei.

Page 462: licenta hatz

…și se vor deduce trei contradicții. Contradicția poate să ia diverse forme, variate de la un sistem la altul și uneori configurabile prin reguli personalizate (care nu folosesc concepte standard, ci doar structuri IF…THEN…). Moduri de semnalare a contradicțiilor

Page 463: licenta hatz

64 Robert Andrei Buchmann

pot fi: semnalarea unei erori, listarea conceptelor contradictorii sau pur și simplu clasificarea rezultatelor cu ajutorul clasei sau relației absurde, care apoi pot fi interogate cuSPARQL pentru a obține o listă a contradicțiilor. Exemple de astfel de concluzii ar putea fi:

:Ana a owl:Nothing. :Ann a owl:Nothing.:Femeie rdfs:subClassOf owl:Nothing. :Barbat rdfs:subClassOf owl:Nothing.:areCopilPe rdfs:subPropertyOf owl:bottomObjectProperty. :esteCopilulLui rdfs:subPropertyOf owl:bottomObjectProperty.

Evident, în general nu are sens să afirmăm direct aceste contradicții. De obicei măcar una din afirmațiile contradictorii e produsă dintr-o succesiune de deducții.

2.7.2 Deducerea distincțiilor

În continuare vom sugera o serie de căi pe care se poate deduce distincția indivizilor. În practică distincția trebuie dedusă fie pentru a verifica dacă există discrepanțe logice între concepte din baze de cunoștințe diferite (cu prefixe diferite), fie pentru a verifica dacă o anumită baze de cunoștințe nu este cumva contradictorie cu ea însăși.

Deducerea distincției dintre indivizi din disjuncție (owl:disjointWith). Din afirmațiile:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana a :Femeie. :Marian a :Barbat.

:Femeie owl:disjointWith :Barbat.…se va deduce::Ana owl:differentFrom :Marian.

Deducerea disjuncției dintre clase (și a distincției dintre indivizi) din complement (owl:complementOf). Din afirmațiile:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana a :Femeie._:x owl:complementOf :Femeie. :Marian a _:x.

…se va deduce:_:x owl:disjointWith :Femeie.

…și de aici::Ana owl:differentFrom :Marian.

Deducerea distincției dintre indivizi, din proprietăți incompatibile(owl:propertyDisjointWith). Din afirmațiile:

@prefix : <http://expl.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :Ana :eMamaLui :Alin.:Maria :eCopilulLui :Alin.

Page 464: licenta hatz

Web Semantic 65

:eMamaLui owl:propertyDisjointWith :eCopilulLui.…se va deduce::Ana owl:differentFrom :Maria.Idem se poate deduce distincția obiectelor, dacă subiectul e fix și obiectele variază.

Deducerea disjuncției claselor sau proprietăților din listă de clase disjuncte (owl:AllDisjointClasses), respectiv listă de proprietăți incompatibile(owl:AllDisjointProperties). Din afirmațiile:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :StudentGrupa1 owl:members (:Ana :Ann :Andrei). :StudentGrupa1 a owl:AllDifferent.:Gen owl:members (:Femeie :Barbat). :Gen a owl:AllDisjointClasses.:RelatieRudenie owl:members (:eMamaLui :eCopilulLui). :RelatieRudenie a owl:AllDisjointProperties.

…se vor deduce (pe seturi)::StudentGrupa1 a owl:Class. (din prima listă):Ana a :StudentGrupa1, owl:NamedIndividual.:Ann a :StudentGrupa1, owl:NamedIndividual.:Andrei a :StudentGrupa1, owl:NamedIndividual.:Ana owl:differentFrom :Ann, :Andrei.:Ann owl:differentFrom :Ana, :Andrei.:Andrei owl:differentFrom :Ann, :Ana.:Gen a owl:Class. (din a doua listă):Femeie a :Gen, owl:Class.:Barbat a :Gen, owl:Class.:Femeie owl:disjointWith :Barbat.:RelatieRudenie a owl:Class. (din a treia listă):eMamaLui a :RelatieRudenie, rdf:Property.:eCopilulLui a :RelatieRudenie, rdf:Property.:eMamaLui owl:propertyDisjointWith :eCopilulLui.

Deducerea disjuncției (dar și a unor relații de incluziune) din reuniune declase disjuncte. Din afirmația:

@prefix : <http://expl.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :Om owl:disjointUnionOf (:Femeie :Barbat).…se va deduce::Femeie rdfs:subClassOf :Om. :Barbat rdfs:subClassOf :Om. :Femeie owl:disjointWith :Barbat.

Practic e vorba de o nouă variantă a lui owl:AllDisjointClasses în care avem și posibilitatea de a crea o supraclasă ce sunt înglobeze mulțimile disjuncte.

2.7.3 Deducerea echivalențelor

Deducerea echivalenței indivizilor din proprietatea funcțională (owl:FunctionalProperty).

Page 465: licenta hatz

66 Robert Andrei Buchmann

Proprietatea funcțională se comportă ca o funcție matematică: oricărui subiect îi poate aloca un singur obiect. Dacă îi alocă mai multe, se va deduce că acestea sunt identități multiple ale unui același obiect.

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Alin :areMamaPe :Ana. :Alin :areMamaPe :Aneta.

:areMamaPe a owl:FunctionalProperty.…se va deduce::Ana owl:sameAs :Aneta.O persoană nu poate avea două mame naturale, deci cele două mame trebuie să fie

una și aceeași.

Dacă ajungem pe alte căi și la concluzia că :Ana și :Aneta nu au cum să fie aceeași persoană, ajungem la contradicție. Acest aspect e valabil pentru toate exemplele ce urmează: regulile prezentate vor detecta echivalențe atâta timp cât nu există alte reguli care să detecteze distincția între aceiași indivizi. Altfel se vor produce contradicții. Detectarea automată a echivalențelor poate automatiza maparea semantică între baze de cunoștințe din surse diferite, generând automat echivalențe.

Deducerea echivalenței indivizilor din proprietatea invers funcțională(owl:inverseFunctionalProperty).

Aceasta se comportă invers față de cea funcțională: pe orice obiect îl poate pune în relație cu un singur subiect. Dacă apar mai multe subiecte, se va deduce echivalența lor.

@prefix : <http://expl.ro#>.@prefix alt: <http://altdomeniu.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana :areEmail <mailto:[email protected]>. alt:Aneta :areEmail <mailto:[email protected]>. :areEmail a owl:InverseFunctionalProperty.

…se va deduce::Ana owl:sameAs alt:Aneta.(ne bazăm pe prezumția că două persoane nu pot avea același e-mail, deci dacă

apare o astfel de situație e vorba de aceeași persoană)

Deducerea echivalenței indivizilor din setul de proprietăți cheie (owl:hasKey)Aceasta este o versiune mai precisă a proprietății funcționale, sub două aspecte:se aplică la o combinație de mai multe proprietăți, care nu vor putea lua aceeași combinație de valori (obiecte) pentru două subiecte din aceeași clasă;

efectul e limitat doar la membrii unei clase.Așadar, putem considera că e o transpunere a noțiunii de cheie primară mutiplă din

bazele de date relaționale! Din afirmațiile:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Ana :NrMatricol 100; :studentaLa :ASE, a :Student. :Aneta :NrMatricol 100; studentaLa :ASE; a :Student. :Student owl:hasKey (:NrMatricol :studentaLa).

Page 466: licenta hatz

…se va deduce:

Page 467: licenta hatz

Web Semantic 67

Page 468: licenta hatz

:Ana owl:sameAs :Aneta.

Deducerea echivalenței indivizilor din cardinalitatea maximă (owl:maxCardinality) aplicată ca restricție (owl:Restriction) asupra unei proprietăți(owl:onProperty):

Prin cardinalitate putem impune de câte ori poate fi implicat un anumit subiect într-o anumită relație. Dacă numărul de relații depășește limita pe care o impunem, obiectele suplimentare trebuie să fie echivalente cu unele dintre celelalte. Din afirmațiile:

@prefix : <http://expl.ro#>.@prefix alt: <http://altdomeniu.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:CopilCuUnParinte owl:onProperty :areParintePe; owl:maxCardinality 1 . :Alin a :CopilCuUnParinte; areParintePe :Ana, alt:Maria.…se va deduce::CopilCuUnParinte a owl:Restriction, owl:Class. :Ana owl:sameAs alt:Maria.Deoarece în prima fază am afirmat că Alin face parte din clasa celor cu un parinte

(mai exact, care au relația :areParintePe cu un singur obiect), iar apoi am indicat doi părinți, s-a dedus că aceștia trebuie să fie una și aceeași persoană.

Observați modul de creare a clasei CopilCuUnParinte. Aceasta e de un tip particular, owl:Restriction care e mulțimea acelor clase ce sunt create prin astfel de mecanisme de restricționare a relațiilor (deci orice owl:Restriction e și clasă). Dacă proprietatea ce suferă restricția are deja un domeniu declarat, clasa generată prin restricție va fi o submulțime a acesteia. Din următorul set:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:areParintePe rdfs:domain Copil.:CopilCuUnParinte owl:onProperty :areParintePe; owl:maxCardinality 1 .se va deduce, pe lângă echivalența amintită, și că::CopilCuUnParinte rdfs:subClassOf :Copil.Cu alte cuvinte, mulțimea copiilor cu un singur părinte e o submulțime a mulțimii

copiilor, obținută prin restricționarea numărului de utilizări.

Deducerea echivalenței indivizilor din cardinalitate îmbinată cu distincții cunoscute (owl:cardinality):

Exemplul e similar celui de mai sus, dar cardinalitatea e mai mare decât 1, deci avem nevoie și de o serie de distincții pentru a putea concluziona echivalența:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :ParinteCuDoiCopii owl:onProperty :AreCopilPe; owl:cardinality 2 . :Alin a :ParinteCuDoiCopii, :AreCopilPe :Ana, Andreea, Mihai. :Mihai owl:differentFrom :Ana, :Andreea.Diferențierea lui Mihai față de restul copiilor lui Alin ne permite să concluzionăm

care copii ar putea fi echivalenți pentru a menține corectitudinea afirmației că Alin are 2 copii:

Page 469: licenta hatz

:ParinteCuDoiCopii a owl:Restriction.

Page 470: licenta hatz

68 Robert Andrei Buchmann

:Ana owl:sameAs :Andreea.

Aici nu am mai folosit owl:maxCardinality ci cardinalitatea precisă: Alin are exact doi copii distincți. Atenție însă, aceasta nu înseamnă că baza de cunoștințe trebuie să conțină doi copii pentru Alin! În numele principiului Open World, o bază de cunoștințe nu e niciodată completă, pot apare în viitor noi afirmații, deci se tolerează absența afirmațiilor despre copii lui Alin. Nu se tolerează însă depășirea acestui număr (mai exact, se încearcă interpretarea depășirii prin astfel de echivalențe, dacă nu există probe contrarii care să afirme distincția).

Deducerea echivalenței indivizilor din listă de elemente nedistincte (owl:oneOf) îmbinată cu distincții cunoscute:

@prefix : <http://expl.ro#>.@prefix alt: <http://altdomeniu.ro#>.@prefix owl: <http://www.w3.org/2002/07/owl#>. :LunaIarna owl:oneOf (:Decembrie :Ianuarie :Februarie).alt:Gerar a :LunaIarna; owl:differentFrom :Februarie, :Decembrie.…se va deduce:alt:Gerar owl:sameAs :Ianuarie.Deducția e explicabilă prin caracterul închis al listei. Enumerarea indică faptul că

pot fi maxim 3 elemente în clasa :LunaIarna, iar dacă apare un al patrulea, trebuie să fie echivalent cu unul din ceilalți (altfel ajungem la contradicție).

2.7.4 Deducerea poziționării în taxonomie

Încadrăm în această categorie regulile care contribuie la clasificarea indivizilor (distribuirea lor pe clase), mecanism pe care l-am demonstrat deja la conceptele:

rdfs:domain și rdfs:range, care detectează clasa unui individ după relațiile la care participă;

rdfs:subClassOf, care asigură propagarea apartenenței unui individ în sus peierarhia de clase.OWL vine să rafineze criteriile prin care are loc această distribuirea a indivizilor

pe clase: sunt luate în considerare numărul de relații ale unui individ, cu cine are loc relația, ce relații există între clasa curent alocată și alte clase existente în arbore etc.

Enumerarea elementelor unei mulțimi (owl:oneOf, owl:distinctMembers)O primă categorie, ce lărgește posibilitățile de descriere a taxonomiei de clase,

sunt operațiile cu mulțimi. Cea mai simplă este enumerarea directă a indivizilor unei mulțimi, ca o listă ordonată și închisă (demonstrată deja și la deducerea echivalențelor). Avem două moduri de a realiza acest lucru:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :EchipaFotbal owl:oneOf (:Steaua :Dinamo :Rapid :CainiiRosii).sau:EchipaFotbal owl:distinctMembers (:Steaua :Dinamo :Rapid).

Diferența între owl:oneOf și owl:distinctMembers este că în al doilea caz se garantează distincția între indivizi (se deduc automat distincții între fiecare doi membri,

Page 471: licenta hatz

Web Semantic 69

după cum s-a arătat deja în secțiunea dedicată deducerii distincțiilor) în timp ce primul caz lasă loc posibilității ca unele elemente să fie același element cu mai mulți identificatori. Cele două afirmații vor produce:

:Steaua a :EchipaFotbal.:Dinamo a :EchipaFotbal.:Rapid a :EchipaFotbal.:CainiiRosii a :EchipaFotbal. (doar din owl:oneOf)A doua enumerare produce și distincțiile de care aminteam pentru fiecare pereche

de indivizi.

Intersecția și reuniunea (owl:intersectionOf, owl:unionOf)În capitolul dedicat conceptelor RDF (secțiunea privind maparea) am arătat cum se

pot adăuga la taxonomie mulțimi-reuniune și mulțimi-intersecție prin folosirea lui rdfs:subClassOf. OWL oferă o metodă mai directă de a preciza acest lucru:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :ScriitorClujean owl:intersectionOf (:Scriitor :Clujean).:Om owl:unionOf (:Barbat :Femeie). :Andrei a :ScriitorClujean, :Barbat.

…se vor deduce::Scriitor rdfs:subClassOf :ScriitorClujean. (din reuniune):Clujean rdfs:subClassOf :ScriitorClujean.

:Barbat rdfs:subClassOf :Om. (din intersecție):Femeie rdfs:subClassOf :Om.…iar din acestea deducțiile discutate deja produc mai departe::Andrei a :Scriitor, :Clujean, :Om(plus declarațiile de individ, clasă etc.)

Complementul și diferența (owl:complementOf)Complementul unei mulțimi se folosește cu precădere pentru a detecta contradicții,

într-o manieră similară cu disjuncția, după cum s-a demonstrat deja. Complementul unei clase e format din toate acele concepte ale lui owl:Thing care nu aparțin clasei respective. Începătorii ar putea fi tentați să considere corectă afirmația de mai jos, considerând că cine nu e femeie trebuie să fie bărbat:

:Barbat owl:complementOf :Femeie.În realitate complementul mulțimii :Femeie e format din toate lucrurile din univers

care nu sunt femei, de exemplu o piatră. Pentru a defini corect mulțimea Barbat pornind de la Femeie, va trebui să afirmăm:

:Barbat owl:intersectionOf (:Om _:X). _:X complementOf :Femeie.OWL nu oferă un concept aparte pentru operația de diferență, ci se bazează tocmai

pe acest șablon ce îmbină complementul cu intersecția.

În plus, un motor inferențial complet ar trebui să poată deduce toate legile matematice legate de operații cu mulțimi, dintre care amintim:

complementul reuniunii a două mulțimi e intersecția complementelor celor două mulțimi::Om owl:unionOf (:Barbat :Femeie).

Page 472: licenta hatz

70 Robert Andrei Buchmann

_:complOm owl:complementOf :Om…se poate deduce:

_:x owl:complementOf :Barbat. _:y owl:complementOf :Femeie._:complOm owl:intersectionOf (_:x _:y).complementul intersecției a două mulțimi e reuniunea complementelor celor două mulțimi::ScriitorClujean owl:intersectionOf (:Scriitor :Clujean). _:complSC owl:complementOf :ScriitorClujean.

…se poate deduce:_:x owl:complementOf :Scriitor. _:y owl:complementOf :Clujean. _:complSC owl:unionOf (_:x _:y).complementul submulțimii unei mulțimi e submulțimea complementului acelei mulțimi::Barbat rdfs:subClassOf :Om. _:complBarbat owl:complementOf :Barbat.

…se poate deduce:_:x owl:complementOf :Om._:x rdfs:subClassOf _:complBarbat.

Necesitatea și suficiența (owl:Restriction, owl:onProperty, owl:hasValue, owl:allValuesFrom, owl:someValuesFrom, owl:hasSelf)

Un individ poate fi alocat unei clase în funcție de relațiile la care participă (veziRDF Schema) dar și în funcție de indivizii cu care participă la acea relație, sau clasele cărora acești indivizi aparțin. Demonstrăm mai întâi deducțiile posibile dintr-o relație cu un anumit individ clar specificat:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:SatelitAlPamantului owl:onProperty :Orbiteaza; owl:hasValue :Pamantul.Am afirmat că mulțimea :SatelitAlPamantului e formată din toate acele lucruri X

care au relația :Orbiteaza cu :Pamantul (care apar în afirmații de forma X :Orbiteaza :Pamantul). Aceasta permite două tipuri de deducții:

dacă se mai știe că…:Luna :Orbiteaza :Pamantul.

…se poate deduce::Luna a :SatelitAlPamantului.

în schimb dacă se știe că…:Luna a :SatelitAlPamantului.

…se deduce::Luna :Orbiteaza :Pamantul.Deci avem o deducție posibilă în ambele sensuri – apartenența la o clasă poate fi

produsă de existența unei relații cu un anumit individ dar și invers, relația cu un individ dedusă din apartenența la o clasă.

În plus, din ambele situații se mai deduce::SatelitAlPamantului a owl:Restriction, owl:Class.Cu alte cuvinte, avem de a face cu o clasă-restricție, noțiune explicată deja în

exemplele cu cardinalitatea: o clasă restricție este detectată automat din utilizarea lui owl:onProperty, este formată din toți indivizii ce respectă restricția și este o submulțime a domeniului proprietății ce suferă restricția. De exemplu, :Orbiteaza ar putea avea ca

Page 473: licenta hatz

Web Semantic 71

Page 474: licenta hatz

domeniu clasa :Satelit, ceea ce ar face să se deducă următoarea afirmație, asigurând astfel și alipirea restricției la taxonomia existentă de clase:

:SatelitAlPamantului rdfs:subClassOf :Satelit.

În continuare generalizăm puțin această situație:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Dramaturg owl:onProperty :aScris; owl:someValuesFrom :PiesaTeatru. :Alin :aScris :VenireaPrimaverii.:VenireaPrimaverii a :PiesaTeatru.Am afirmat că oricine scrie o piesă de teatru poate fi considerat dramaturg (dar că

poate să scrie și altceva), apoi am arătat că Alin a scris o piesă de teatru. Se va deduce::Alin a :Dramaturg.:Dramaturg a owl:Restriction, owl:Class.Avem de a face cu un mecanism de deducere a tipului subiectului din tipul

obiectelor cu care are relații! Dacă adăugăm la cele de mai sus:@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :aScris rdfs:domain :Scriitor; rdfs:range :Opera.

putem deduce următoarele, poziționând astfel în taxonomie cele două clase implicate în restricție:

:Dramaturg rdfs:subClassOf :Scriitor. :PiesaTeatru

rdfs:subClassOf :Opera.

Avem și posibilitatea de a deduce tipul obiectului din tipul subiectelor cu care arerelații:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Vegetarian owl:onProperty :Mananca; owl:allValuesFrom :MancareVegetariana. :Alin a :Vegetarian; :Mananca :Salata.Am afirmat că poți fi vegetarian doar dacă mănânci NUMAI elemente ale mulțimii

:MancareVegetariana, apoi am indicat că Alin mănâncă așa ceva. Se va deduce::Salata a :MancareVegetariana. :Vegetarian a owl:Restriction, owl:Class.Din nou, clasa-restricție e submulțime al domeniului, iar clasa-obiect e

submulțime a codomeniului relației ce suferă restricția:@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. :Mananca rdfs:domain :Fiinta; rdfs:range :Mancare.Putem deduce::Vegetarian rdfs:subClassOf :Fiinta. :MancareVegetariana

rdfs:subClassOf :Mancare.

Următorul exemplu este un caz particular al restricției owl:hasValue și se aplică indivizilor care au proprietăți reflexive (relații cu ei înșiși).

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:PersoanaSiguraPeSine owl:onProperty :CunoastePe; owl:hasSelf true.

Page 475: licenta hatz

72 Robert Andrei Buchmann

Am afirmat că oricine se cunoaște pe sine aparține clasei :PersoanaSiguraPeSine și oricine aparține acestei clase se cunoaște pe sine, deducția funcționează în ambele sensuri, ca în cazul lui owl:hasValue. Dacă pornim de la…

:Alin :CunoastePe :Alin.…obținem…:Alin a :PersoanaSiguraPeSine.Dacă pornim de la…:Alin a :PersoanaSiguraPeSine.…obținem…:Alin :CunoastePe :Alin.În ambele cazuri mai obținem::PersoanaSiguraPeSine a owl:Restriction, owl:Class.Ca și în cazurile precedente, :PersoanaSiguraPeSine devine submulțime a

domeniului proprietății, dacă acesta a fost stabilit deja.

Cardinalitatea (owl:cardinality, owl:minCardinality, owl:maxCardinality, owl:qualifiedCardinality, owl:minQualifiedCardinality, owl:maxQualifiedCardinality, owl:onClass)

Am arătat în capitolul dedicat deducerii echivalențelor câteva exemple de restricții prin cardinalitate. Impunând o limită superioară numărului permis de relații pe care le poate avea un același subiect, am putut detecta obiecte echivalente la depășirea numărului de relații (sau contradicții, dacă echivalențele se contrazic cu distincții garantate de alte reguli).

Cardinalitățile pot fi folosite și pentru a deduce apartenența la o clasă, dacă în loc să folosim limitarea superioară, precizăm valori minime pentru numărul de relații al aceluiași subiect. Orice subiect care va acumula în timp acel număr de relații va fi alocat clasei-restricție. Presupunem că avem:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Parinte owl:onProperty :areCopilPe; owl:minCardinality 1 . :Alin :areCopilPe :Andrei.Am afirmat că oricine are măcar un copil se poate numi părinte, apoi am făcut o

astfel de afirmație despre Alin, deci obținem concluzia::Alin a :Parinte.:Parinte a owl:Restriction, owl:Class.Dacă :areCopilPe ar avea și un domeniu, :Parinte ar deveni submulțime a acestuia.

Dacă folosim cardinalitate mai mare de 1 avem nevoie și de unele distincții pentru a putea trage concluzia:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>. :ParinteCuDoiCopii owl:onProperty :areCopilPe; owl:cardinality 2. :Alin :areCopilPe :Ana, :Maria.Din acest exemplu nu se poate deduce o concluzie până nu adăugăm::Ana owl:differentFrom :Maria.În acest moment există garanția că :Alin are doi copii distincți și obținem::Alin a :ParinteCuDoiCopii.Deoarece am folosit cardinalitatea precisă și nu pe cea minimă, dacă mai adăugăm

un copil distinct:

Page 476: licenta hatz

:Alin :areCopilPe :Andrei.

Page 477: licenta hatz

Web Semantic 73

:Andrei owl:differentFrom :Ana, :Maria.…obținem o contradicție.În concluzie:limitând inferior numărul de relații ale unui subiect (cu owl:minCardinality) putem deduce apartenența subiectului la o clasă;limitând superior numărul de relații (cu owl:maxCardinality) putem deduce echivalența indivizilor (dacă are relații cu mai mult de n obiecte, o parte din acele obiecte trebuie să fie echivalente) sau contradicții (dacă echivalența respectivă e contrazisă de distincții derivate din alte reguli);folosind cardinalitatea precisă (owl:cardinality) putem obține oricare din aceste efecte, în funcție de cum evoluează numărul de relații (dacă e sub sau peste cardinalitatea declarată).La aceste construcții oferite de OWL 1, OWL 2 a adus o rafinare superioară, cu

ajutorul cardinalității calificate. Aceasta e o combinație între restricțiile de cardinalitate și cele de necesitate/suficiență, căci constrânge simultan numărul de relații ale unui subiect și obiectele cu care acel număr de relații trebuie afirmate:

@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.:Parinte owl:onProperty :areCopilPe; owl:minCardinality 1.:Bunic owl:onProperty :areCopilPe; owl:minQualifiedCardinality 1; owl:onClass :Parinte. :areCopilPe rdfs:domain :Om.:Ana :areCopilPe :Andrei. :Alin :areCopilPe :Ana.

Am afirmat că părinții sunt acei indivizi care au măcar o relație :areCopilPe (indiferent cu cine), iar bunicii sunt acei indivizi care au măcar o relație :areCopilPe cu un individ din clasa părinților. Prima e o restricție cu cardinalitate simplă, a doua are cardinalitate calificată (dependentă) de clasa :Parinte. Se deduce din prima regulă…

:Ana a :Parinte.…apoi din a doua:

:Alin a :Bunic.…și din a treia, includerea celor două clase în taxonomie:

:Parinte a owl:Restriction; rdfs:subClassOf :Om. :Bunic a owl:Restriction; rdfs:subClassOf :Parinte.

În mod similar, prin limitarea superioară a cardinalității calificate se poate deduce echivalența obiectelor. Pentru a diversifica puțin exemplul față de precedentele, presupunem că e vorba de două baze de cunoștințe diferite, cu prefixe diferite, dar care conțin informații despre o aceeași persoană:

În prima bază de cunoștințe avem:@prefix : <http://expl.ro#>.@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix owl: <http://www.w3.org/2002/07/owl#>.<> owl:imports <http://altdomeniu.ro/cunostinte2.owl>.:Om owl:onProperty :esteCopilulLui; owl:maxQualifiedCardinality 1; owl:onClass :Femeie. :Alin :esteCopilulLui :Maria; :areTelefonul 01234567; a :Om.:Maria :lucreazaLa :FirmaABC.:areTelefonul a owl:InverseFunctionalProperty.Se observă că această bază de cunoștințe o importă pe următoarea. Creatorii celei

de-a doua au pregătit posibilul import cu o serie de mapări (echivalențe menite să conecteze

Page 478: licenta hatz

74 Robert Andrei Buchmann

afirmațiile din cele două surse în momentul în care intră în contact, prin import, interogări federative sau alte căi):

@prefix alt: <http://altdomeniu.ro#>.alt:Mary alt:parentOf alt:Aly; alt:worksAt :CompanyX; a alt:Woman. alt:Aly rdf:type alt:Human; alt:hasPhoneNo 01234567 . :areTelefonul owl:equivalentProperty :hasPhoneNo.:lucreazaLa owl:equivalentProperty alt:worksAt. :Femeie owl:equivalentClass alt:Woman. :esteCopilulLui owl:inverseOf alt:parentOf.

În urma importului, prin maparea proprietății de a avea număr de telefon, se vaobține:

:Alin :areTelefonul 01234567 . alt:Aly areTelefonul 01234567 .Coroborat cu faptul că numărul de telefon e o proprietate invers funcțională, se

deduce că e vorba de aceeași persoană::Alin owl:sameAs alt:Aly.Aceasta are mai departe consecința::Alin :esteCopilulLui :Maria. alt:Mary alt:parentOf :Alin.Coroborat cu declararea faptului că aceste două relații sunt inverse una față de

cealaltă, obținem::Alin :esteCopilulLui :Maria, alt:Mary.Coroborat cu echivalența claselor :Femeie și alt:Woman, obținem::Maria a :Femeie. alt:Mary a :Femeie.Coroborat cu faptul că :Alin a :Om și membri clasei :Om pot fi copiii unei singure

femei, se deduce::Maria owl:sameAs alt:Mary.Iată un exemplu de echivalență descoperită, ce completează echivalențele declarate

direct în scopul mapării. Echivalența ne permite mai departe să coroborăm următoarele::Maria :lucreazaLa :firmaABC; alt:worksAt :CompanyX.Dar cum cele două relații de a lucra sunt și ele declarate echivalente, avem de fapt::Maria :lucreazaLa :firmaABC, :CompanyX.Iată cum am descoperit faptul că Maria lucrează în două locuri, pornind de la

informații din două organizații diferite și de la o mapare prealabilă, între cele două organizații, a conceptelor de Femeie, număr de telefon, relație de părinte și proprietate de a lucra. Acest exemplu evidențiază importanța detectării echivalențelor și a mapărilor între taxonomii pentru descoperirea de conexiuni între concepte create izolat în primă fază. Pentru a obține aceste beneficii, organizațiile trebuie să fie dispuse să își pună în comun cunoștințele deținute.

2.8 Accesarea cunoștințelor la distanță

Cunoștințele pot fi extrase în Web prin multiple metode. Cele mai populare sunt interogările SPARQL și accesul prin protocolul HTTP la servere ce oferă interfețe de tip serviciu Web. Unele servere oferă și posibilitatea îmbinării celor două metode, pe două căi:

Acceptă interogări SPARQL și operații HTTP la interfețe (adrese) diferite;

Page 479: licenta hatz

Web Semantic 75

Page 480: licenta hatz

La aceeași interfață permit îmbinarea unei operații HTTP cu o interogare SPARQL (atașată ca variabilă GET sau POST).Paradigma Linked Data se bazează pe accesarea prin HTTP a identificatorilor de

concepte, la care serverul să răspundă fie cu un set de cunoștințe despre acel concept (identificatori cu foldere fictive), fie cu toată baza de cunoștințe din care clientul să-și selecteze informația relevantă (identificatori cu ancore). Filtrarea informației relevante se poate realiza cu SPARQL fie la nivelul clientului, fie la al serverului. Așadar sunt posibile diferite scenarii de combinare între interogări și accesul la distanță, în funcție de ce facilități oferă serverul.

S-au consacrat două protocoale bazate pe HTTP prin care are loc accesul la cunoștințe oferite de servicii Web:

Protocolul SPARQL27; Protocolul Graph Store28.Ambele se bazează pe metodele cererilor HTTP:GET – pentru a accesa cunoștințe, cu posibilitatea de a atașa la adresa accesată variabile care să indice mai precis ce anume dorim să accesăm;

POST – pentru a trimite cunoștințe;PUT – pentru a înlocui cunoștințe existente pe server cu unele noi; DELETE – pentru a șterge cunoștințe de pe server;

HEAD – pentru a testa dacă un server de cunoștințe răspunde;OPTIONS – pentru a verifica ce facilități oferă serverul de cunoștințe; PATCH – pentru a trimite o interogare capabilă să modifice cunoștințe.Deși limbajul SPARQL este unul uniform implementat, nu același lucru se poate

spune despre aceste protocoale. Pe servere diferite se acceptă operații HTTP diferite, deci nu e obligatoriu ca toate aceste metode să fie oferite de un serviciu. Spre exemplu, majoritatea implementărilor protocolului SPARQL permit doar operația GET, prin care se pot citi informații, cu posibiliatea de a atașa orice interogare SPARQL la adresa accesată:

http://serviciu.com/cunostinte?query=…..

Operația POST este una de adăugare de cunoștințe, iar PUT una de înlocuire a cunoștințelor existente (înlocuirea unui graf/context). Cunoștințele trebuie transmise ca upload de fișier sau prin inserarea conținutului complet al unui fișier în corpul cererii HTTP. Dacă sunt permise, ambele operații pot preciza contextul în care să aibă loc modificarea, tot printr-o variabilă atașată la adresă:

http://serviciu.com/cunostinte?context=….. - pentru protocolul SPARQLhttp://serviciu.com/cunostinte/rdf-graphs/service?graph=….. - pentru protocolul Graph Store.

Operația DELETE este și ea suportată de ambele protocoale, pentru a șterge cunoștințe dintr-un context, fără a transmite vreo interogare.

Operația HEAD e menită să testeze dacă un serviciu e accesibil, deci nu se transmite și nu se primește nimic altceva decât antetul HTTP.

Operația OPTIONS e menită să obțină o descriere a capabilităților oferite de un serviciu, precum versiunea SPARQL suportată, lista de contexte pe care le conține,

27 http://www.w3.org/TR/rdf-sparql-protocol/ 28http://www.w3.org/TR/sparql11-http-rdf-update/ 76 Robert Andrei Buchman

Page 481: licenta hatz

10Proiectarea sistemelor informatice

Page 482: licenta hatz