ARHITECTURA BAZEI DE DATE

Exista 3 niveluri: fizic sau intern (cum se stocheaza datele), mediu sau logic (unde exista 3 modele: ierarhic-graf, retea graf oarecare, relational - tuple) si extern sau nivelul vederilor. Toate acestea sunt legate de un SGBD (sist de gestiune a BD). Vederi->Transformare vedere-model Conceptual -> modelul conceptual (descrierea BD descrierea struct. Logice prin intermediul LDD) -> transf Model Conceptual nivel intern -> Nivel intern

SGBD
SGBD - Intregul ansamblu software care trateaza toate cererile de acces la baza de date. Interogarea unei BD se realizeaza in 3 pasi: 1. Cererea de acces este formulata de catre utilizator in termenii conceptelor de la nivelul uneia din vederile definite in sistem (pe nivelul extern al arhitecturii b.d.); 2. Cererea este interceptata de catre SGBD; 3. Cererea este interpretata de catre interpretorul LMD (componenta a SGBD) ce este Limbaj de Manipulare Date. SGBD consulta o serie de tabele ce au in vedere autorizarea accesului la date sau accesul concurent si executa optimizarea datelor. Cererile de acces la fisierele fizice sunt preluate si rezolvate de catre un sistem de gestiune a fisierelor, iar aceste date extrase din fisierele fizice parcurg calea inversa (de jos in sus pana la utilizator). Facilitati (functionalitati de baza) cuprinse in SGBD: - facilitati de descriere a datelor (LDD) si de manipulare a datelor (LMD) LDD (eng. DDL): descrierea modelelor externe, descrierea modelului conceptual, descrierea interfetelor dintre cele trei niveluri ale arhitecturii b.d. sau a structurii fizice de date si operatii de intretinere a b.d: incarcarea bazei de date, specificarea restrictiilor de integritate, etc. LMD (eng. DML): constituie limbajele de interogare ca interfata intre SGBD si utilizatori, concretizare in set de comenzi si primitive ce corespund operatiilor uzuale in exploatare a b.d.: accesarea, adaugarea, stergerea si actualizarea datelor.

ADMINISTRAREA BAZEI DE DATE

Administrarea bazei de date = ansamblul de activitati menite a gestiona si corela in mod optim totalitatea resurselor bazei de date, atat la nivel software cat si hardware, implicand totodata si raspundere personala privind starea bazei de date in orice moment. I. Atributiile de proiectare : I.a) Atributii premergatoare proiectarii propriu-zise: determina necesitatile de informatie ale tuturor utilizatorilor si decide apoi continutul de informatie al bazei de date, stabilind toate entitatile care trabuie reprezentate precum si legaturile dintre ele. I.b) Atributii de proiectare propriu-zisa: descrierea modelului conceptual si al modelelor externe, folosind LDD; stabilirea structurii fizice de date si a strategiilor de acces la datele fizice, in functie de caracteristicile echipamentului hardware si ale sistemului de operare care gazduiesc baza de date; stabilirea drepturilor de acces ale diferitelor categorii de utilizatori, la diferitele parti ale bazei de date, drepturi ce se stabilesc atat la nivel global (model conceptual), cat si la nivel local (la nivelul fiecarei vederi corespunzatoare unui utilizator sau unui grup de utilizatori). Ca si activitati specifice: stabilirea naturii transformarilor dinte nivele, definirea constrangerilor de integritate a datelor ca parte a modelului conceptual al bazei de date, folosind clauzele specifice din contextul comenzilor LDD si elaborarea unor proceduri de validare cu rol in verificarea integritatii datelor. Atributii de administrare propriu-zisa : Contact permanent al ABD cu toti utilizatorii, impunerea unor standarde in ceea ce priveste priveste reprezentarea datelor si elaborarea documentatiilor si Intocmirea listelor de achizitii de echipamente de calcul noi si accesorii specifice in exploatarea bazelor de date.

Atributii operative : alegerea celor mai potrivite dispozitive de memorare; stabilirea structurii fizice a datelor care se potriveste cel mai bine pentru dispozitivele fizice alese; stabilirea strategiei de backup si recovery; modificarea drepturilor de acces la date pentru unele categorii de utilizatori, daca acest lucru este impus de catre anumite conditii obiective. Atributii de coordonare : target: optimizarea si cresterea eficientei in exploatarea bazei de date si o serie de sarcini concrete: determinarea modului de utilizare a resurselor, urmarirea si monitorizarea parametrilor de functionare a sistemului, masurarea performantelor echipamentelor. SGBD-urile clasice: concepute si proiectate pt. un anumit gen de aplicatii, relativ limitate ca domeniu de aplicabilitate (adresandu-se in special domeniului economic). Ex tipice: - probleme de gestiune a intreprinderilor, sisteme de rezervare a locurilor (ticketing). Caracteristici (trasaturi specifice): - volum mai mare sau mai mic de date, asupra carora se aplica o serie de operatii relativ simple: oparatii de adaugare, stergere, actualizare, regasirea unor inregistrari care satisfac anumite conditii prescrise. Aceste SGBD-uri au o putere de expresie limitata (ex. LMD clasice nu permit exprimarea unor operatii cu caracter recursiv!) SGBD-urile moderne: concepute si proiectate pt. o mare varietate de domenii de aplicabilitate: ex. domeniul proiectarii : proiectarea circuitelor VLSI, CAD, B. D. Grafice, geografice, pt. ingineria programelor, MultiMedia. Caracteristici ale SGBD-urilor moderne: facilitatea de a accesa si manipula volume mari si foarte mari de date, insotita de facilitatea de a efectua operatii mult mai complexe decat in cazul SGBDurilor clasice; implementarea de LMD-uri cu o putere de expresie mult mai apropiata sau chiar egala cu cea a limbajelor de programare conventionale. Solutiile care au stat la baza conceperii si realizarii SGBD-urilor evoluate: 1. Abordarea Orientata Obiect ->realizarea Sistemelor de Gestiune a BD de tip SGBD- OO (ex. IRIS, Orion, GemStone, O2, Ontos); 2. Abordarea logica: realizarea Sistemelor de Gestiune a Bazelor de Cunostinte: SGBC. Caracteristici ale SGBC: furnizarea tuturor serviciilor oferite de celelalte tipuri de SGBD-uri, posesia de Limbaje Declarative cu putere de expresie apropiata sau chiar egala cu cea a limbajelor conventionale (famile de limbaje DATALOG)

MODELUL RELATIONAL
Modelele de date sunt de 3 tipuri: retea, ierarhic si relational. Modelul ierarhic: se gaseste pe niv.mediu (model conceptual) in arhitectura ABD si structura: arbore de definitie ierarhic. Modelul retea: model conceptual de tip retea; diagrama struct de date este un graf oarecare si sensul nu mai este unidirectional. Modelul relational: diag struct de date este o schema relationala = colectie de tuple (NumeEntitate(atr1,..., atrn)) si fiecare tupla se numeste schema de relatie. LMD navigational: se bazeaza pe utilizarea conceptului de cursor (indica pozitia curenta in baza de date).Actiuni utilizator asupra cursorului: modificare pozitie cursor sau modificare date din pozitia curenta cursor. LMD navigationale exploateaza direct legaturile explicite existente in baza de date >rezolvarea interogarilor presupune in general navigatia cursorului pe lanturile de legaturi. Limbaje de Interogare pt. Modelul Relational: 1.Limbaje care au la origine Algebra Relationala (interogarile sunt exprimate prin aplicarea unor operatori specializati asupra relatiilor). Limbajele derivate se numesc Limbaje Algebrice. 2.Limbaje care au la origine Calculul Relational (interogarile descriu multimea tuplelor rezultat prin specificarea unui predicat pe care aceste tuple trebuie sa-l satisfaca). Predicat = conditie ( in acest context); Obiecte primitive cu care se opereaza in Calculul Relational: tuple ==> Calculul Relational al Tuplelor si valori din domenii ==> Calculul Relational al Domeniilor.

Normalizarea = tehnica obligatorie in proiectarea conceptuala a oricarei b.d., dar in mod special in b.d. relationale, pt a avea bd coerenta, robusta si neredundanta. Se fol. alg. de normalizare care det. Obtinerea de forme normale pe masura complexitatii structurii de date. Exista 6 forme: 1. dependente functionale - tehnica obligatorie in proiectarea conceptuala a oricarei b.d., dar in mod special in b.d. relationale (FN1 - toate atributele sale iau numai valori atomice, FN2 relatia este in FN1 si orice atribut neprim este total dependent fata de orice cheie a relatiei, FN3 relatia este este in FN2 si nici un atribut neprim nu este functional dependent fata de un alt atribut neprim al relatiei), 2. dependenta multivalorica - Spunem ca exista o Dependenta Multivalorica a atributului Z fata de Y (sau Y multidetermina pe Z) si notam Y->-> Z daca pt. orice valori x1, x2,y, z1 si z2, cu x1 x2 si z1 z2 , astfel incat tuplele (x1,y, z1) si (x2,y, z2) fac parte din relatia R, atunci si tuplele (x1,y, z2) si (x2,y, z1) fac parte din relatia R (FN4 - oricare ar fi dependenta multivalorica X Y, unde Y nu este un subset al lui X si X Y nu contine toate atributele lui R, atunci atributul simplu sau compus X este o cheie sau contine o cheie a lui R;, FN Boyce Code - pentru orice dependenta functionala X A din cadrul relatiei R, unde A este un atribut care nu face parte din X, atributul X (care poate fi si un atribut compus) este o cheie in R sau include o cheie din R) 3. dependenta de cuplare - (FN5 - toate dependentele de cuplare existente in relatie sunt implicate de o cheie a acesteia). FN1 - se obtine prin atomizarea tuturor atributelor relatiei; FN2= FN1 + eliminarea tuturor dependentelor functionale partiale ale atributelor neprime in raport cu orice cheie a relatiei; FN3=FN2+eliminarea tuturor dependentelor functionale dintre toate atributele neprime ale relatiei; FNBC = eliminarea tuturor dependentelor functionale fata de atribute care nu sunt chei sau nu contin o cheie. O relatie este in FNBC (respectiv FN4 sau FN5) ddaca singurele dependente functionale (respectiv multivalorice sau de cuplare) existente sunt cele implicate de o cheie a relatiei R. Cele 12 reguli de baza: Regula informaiei, Acces garantat, Suportul sistematic al valorii nule, Catalogul relaional activ on-line, Sublimbajul multilateral al datelor, Regula actualizrii vederilor, Inserarea, actualizarea i tergerea la nivel de mulimi, Independena fizic, logica a datelor, Independena integritii si a distributiei, Nesubversiunea. Cele 8 servicii furnizate de un SGBD Relational Complet: Functia fundamentala: Stocarea, Regasirea si Reactualizarea datelor, Furnizarea unui Catalog accesibil utilizatorului care contine descrierile articolelor de date: se foloseste un catalog de sistem care este este un depozit de informatii, care descrie datele din bazele de date; deci, contine date despre date = metadate si datele sunt stocate central; Furnizarea de servicii de asigurare a tranzactiilor (Program de Aplicatie prin care se acceseaza sau se schimba continutul bazei de date; respecta principiul Atomicitate, Consistenta, Integrabilitate, Durabilitate); Furnizarea de Servicii de Control al Concurentei (BD este corect reactualizata, atunci cand mai multi utilizatori efectueaza simultan astfel de operatii); Furnizarea unui mecanism de reconstituire al bazei de date in cazul in care aceasta este deteriorata intr-un fel oarecare; Furnizarea de Servicii de autorizare a accesului: asigurare acces la BD numai pentru utilizatorii autorizati; Furnizarea de Servicii Suport pentru Comunicarea Datelor (de jos in sus si invers pe cele 3 nivele); Furnizarea de Servicii de Integritate (se folosesc aceleasi reguli pt toti). STRUCTURA GENERALA A UNUI SISTEM DE GESTIUNE A BD 1. Date&Metadate: datele operationale, metadatele ce contin informatii despre structurile de date . Pentru SGBD-urile relationale metadatele includ: numele relatiilor si al atributelor, tipurile datelor aferente atributelor.

2. Administratorul pentru Stocare (AS): are drept scop gestionarea sarcinilor de obtinere a datelor necesare de la nivelul mediului de stocare si memorare avand ca destinatie mediul datelor actualizate. Pentru SGBD-urile simple, AS poate fi chiar SGF (Sistemul de Gestiune a Fisierelor) din SO (Sistemul de Operare). 3. Procesorul de Comenzi (PC): este componenta care manipuleaza cererile de acces la date sau de modificare a datelor respectiv a metadatelor. Sarcina specifica a PC: identificarea si executia celei mai bune cai de rezolvare a operatiilor solicitate. Descompunerea analitica a PC: - Compilatorul DDL, Procesorul de Interogari, Procesorul de Comenzi DML 4. Administratorul de Tranzactii (AT): este componenta care raspunde de pastrarea integritatii sistemului, garantand faptul ca mai multe tranzactii care ruleaza, simultan nu interfereaza una cu cealalta, cat si faptul ca sistemul nu pierde date nici in cazul aparitiei unui defect. Functii SGBD de care raspunde AT: Asigurarea Tranzactiilor, Controlul Concurentei, Recuperarea Bazei de Date dupa Defecte ARHITECTURI MULTIUTILIZATOR pentru sisteme SGBD 1. Teleprocesarea Teleprocesarea = arhitectura traditionala pentru sisteme multiutilizator. Caracteristici: Existenta unui calculator cu o singura Unitate Centrala; un numar variabil de Terminale nestiutoare legate la calculatorul central, unde se face intreaga procesare. 2.Arhitectura Fisier-Server (Server de Fisiere) = Distribuirea procesarii in retea Caracteristici: Aplicatiile cat si SGBD sunt executate pe fiecare statie de lucru, iar acestea solicita fisiere de la Severul de Fisiere. Se executa si sarcini complexe, precum: controlul concurentei; refacerea bazei de date; asigurarea integritatii. 3. Arhitectura Client-Server: denumirea se refera la modul in care interactioneaza componentele software pentru a forma un sistem. Procesul Client: administreaza interfata cu utilizatorul, accepta si verifica sintaxa intrarilor utilizatorilor, proceseaza aplicatiile, genereaza cerintele pentru baza de date, transmite cerintele utilizator catre Server, preia raspunsul de la Server si-l transmite inapoi la utilizator. Procesul Server: primeste si proceseaza cererile clientilor pentru BD, verifica autorizarea, garanteaza respectarea constrangerilor de integritate, efectueaza procesarea interogarilor, transmite raspunsul procesului Client, intretine Catalogul de Sistem, ofera acces concurent la baza de date si ofera controlul reconstituirii. Arhitectura permite accesul larg la bazele de date existente; Daca serverul si clientii se afla pe calculatoare diferite, atunci se pot obtine performante crescute, costurile de comunicatie fiind reduse.

DB2 UDB
Caracteristici generale: (1) DB2 Universal Database este un SGBD relational (deci construit pentru contextul arhitecturii bazelor de date relaionale) i reprezint o foarte bun alegere pentru aplicaiile de tip e-Commerce, Business Intelligence i Information Integration (de ex.). (2) DB2 este uor de administrat, beneficiaz de capabiliti de autoconfigurare i autooptimizare, ofer performane ridicate, disponibilitate maxim, posibilitate de scalare i toate acestea la un cost minim de utilizare i exploatare. (3) DB2 Universal Database suport ultimele nouti n tehnologia XML i permite programatorilor integrarea facil a coninutului de tip Web i XML cu baza de date.

(4) DB2 are la dispoziie un set de utilitare pentru integrare n orice fel de aplicaii i sisteme, precum i pentru interconectarea cu alte baze de date. (5) IBM ofer pentru DB2 Universal Database o unealt construit pe OpenStandards destinat programatorilor pentru construirea i dezvoltarea de aplicaii n medii Java sau Microsoft.

Pachetele continute in Familia de produse IBM DB2 Universal Database: Pach1: DB2 Universal Database Enterprise Server Edition (ESE): Acest produs este un
sistem de baze de date multiutilizator obiectual-relaional pentru configuraii complexe i baze de date de dimensiuni mari ce pot fi implementate pe platforme de tip Intel, UNIX sau SMP. ESE ofer conectivitate i integrare pentru alte surse de date DB2 i Informix. Caracteristici specifice: 1. Produsul este proiectat s lucreze cu servere de orice dimensiune, putnd folosi unul sau mai multe procesoare (pn la cteva sute) i este ideal n cazul soluiilor la cerere pentru baze de date de dimensiuni mari, cum ar fi lucrul cu depozite de date de ordinul teraocteilor. 2. Este produsul ideal din punct de vedere al disponibilitii, aceasta fiind asigurat de 24 de ore timp de 7 zile pe sptmn. 3. Produsul poate fi ales pentru soluii ce folosesc tranzacii cu volume mari de date, sau pentru soluii ce se bazeaz pe utilizarea Web. 4. Exemple de utilizare: Business Intelligence, Content Management, e-Commerce, ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), sau SCM (Supply Chain Management). Sistemele de operare pe care poate rula acest produs sunt: AIX, HP-UX, Linux, Solaris i Windows.

Pach2: DB2 Universal Database Workgroup Server Unlimited Edition (WSUE): Este un
model simplificat cu licen pe procesor destinat organizaiilor de dimensiuni mici ce au utilizatori ce acceseaz bazele de date prin intermediul Internet-ului, sau au un numr relativ mic de utilizatori ce face mai atractiv folosirea acestui produs dect acea a produsului WSE. Caracteristici specifice: (1) Produsul este potrivit dezvoltrii de baze de date relaionale folosite n medii departamentale sau n medii de afaceri de dimensiuni intermediare. (2) Produsul DB2 WSUE poate fi folosit pe sistemele de operare AIX, HP-UX, Linux, Solaris, Windows pe sisteme cu pn la 4 procesoare

Pach3: DB2 Universal Database Workgroup Server Edition (WSE): WSE este un sistem de
gestiune a bazelor de date multiutilizator, obiectual-relaional destinat aplicaiilor i datelor folosite n reele de tip LAN. Caracteristici specifice: (1) Produsul este un server relaional de baze de date ce poate fi ales pentru lucrul n medii departamentale sau medii de afaceri de dimensiuni intermediare ce posed un numr suficient de mare de utilizatori interni. (2) Licena produsului Workgroup Server Edition se acord pe utilizator i pe server, oferind un pre atractiv n cazul adoptrii soluiilor de dimensiuni medii, punnd n acelai timp la dispoziie ntreaga putere i funcionalitate a serverului relaional de baze de date.

(3)Utilizatorii pot fi fie utilizatori concureni, fie utilizatori specificai. Un utilizator concurent este acea persoan, aplicaie sau dispozitiv care stabilete o conexiune la una sau mai multe baze de date aflate pe un singur server. Un utilizator cu mai multe conexiuni la un singur server este considerat c este un singur utilizator concurent. Singurele excepii apar n situaiile n care se realizeaz conexiuni multiple de ctre programe multiplexoare, servere de aplicaii, alte programe, sau server de Web care se conecteaz la serverul DB2 oferind acces pe baza comportamentului altor utilizatori. Un utilizator specificat sau utilizator nregistrat este aceea persoan, aplicaie sau dispozitiv destinat stabilirii uneia sau mai multora conexiuni ctre oricare server autorizat DB2 fie direct, fie prin intermediul unei aplicaii sau server de aplicaii. (4) DB2 WSE poate fi folosit pe sistemele de operare AIX, HP-UX, Linux, UNIX i Windows pe sisteme cu pn la 4 procesoare.

Pach4: DB2 Universal Database Universal Developers Edition: Conine toate instrumentele
necesare dezvoltrii aplicaiilor de tip client/server n cadrul oricrei maini din mediul DB2 UDB. Caracteristici specifice: DB2 Universal Developers Edition ofer un pachet la un pre redus pentru dezvoltarea de aplicaii n scopul proiectrii, obinerii i elaborrii de prototipuri corespunztoare oricrui client DB2 sau server. Pachetul permite utilizatorilor elaborarea de soluii care folosesc cele mai recente tehnologii de baze de date. Partea de software din acest pachet nu se poate folosi la sisteme de producie. Serverul bazei de date poate fi configurat astfel nct s funcioneze doar n scopuri de dezvoltare. Licenele trebuie obinute pentru fiecare dezvoltator n parte.

Pach5: DB2 Universal Database Personal Developers Edition (PDE): PDE este un pachet cu
o singur licen ce include toate instrumentele necesare dezvoltrii de aplicaii de tip desktop sau de aplicaii destinate mediilor DB2. Caracteristici specifice: (1) DB2 Personal Developers Edition (PDE) permite proiectarea i elaborarea de aplicaii de tip desktop (pentru un singur utilizator). (2) Pachetul conine att suportul propriu-zis DB2 ct i extensii DB2, putndu-se folosi urmtoarele produse: DB2 Personal Edition, DB2 Connecr Personal Edition, Application Developer Client, Distributed Debugger for Java Stored Procedures, DB2 Net Search Extender, DB2 Spatial Extender, WebSphere Studio Site Developer. (3) DB2 Universal Database Personal Developers Edition (PDE) poate fi folosit pe sisteme de operare Linux, UNIX i Windows (NT/2000/2003/XP). Pach6: DB2 Universal Database Express Edition: Acesta este un sistem de gestiune a bazelor de date relaional special destinat organizaiilor de dimensiuni mici i mijlocii. Caracteristici specifice: DB2 UBD Express Edition (ultima aparitie din familia DB2) este un produs simplu de instalat i configurat; se integreaz uor cu aplicaiile utilizatorilor; este construit pe baza standardelor open-

source; se poate instala pe Linux, Windows, pe servere de maxim 2 procesoare; se poate integra usor cu software Lotus, Tivoli sau WebSphere i reprezint cea mai avantajoas soluie din punct de vedere al raportului calitate, utilitate/pre pentru companii mici i mijlocii, prezentnd avantajele substaniale fa de competitorii tradiionali (Oracle, Microsoft).

SQL-DDL(Data Definition Language)

Un limbaj DDL (Data Definition Language sau Data Description Language) este un limbaj de tip computer language (limbaj de programare a calculatoarelor) dedicat definirii structurilor de date. Structura DDL: La fel ca orice alt limbaj de descriere date, limbajul DDL al SQL utilizeaza o colectie de verbe imperative, al caror efect este de a modifica Schema sau Modelul Conceptual al unei baze de date prin adaugarea, modificarea sau stergerea unor tabele sau a altor obiecte ale bazei de date. Aceste expresii pot fi combinate in orice mod cu alte instructiuni SQL, ca atare DDL nu este, efectiv, complet separat de celelalte componente ale SGBD. [CREATE statements] Instructiunea CREATE Instructiunea Create este utilizata pentru a genera (a crea) o noua baza de date, o noua tabela, un nou index, o noua interogare stocata sau vedere, in contextul unei baze de date. O instructiune SQL CREATE creaza un obiect in contextul unui RDBMS (Relational DataBase Management System). Tipul obiectelor care pot fi create depind de tipul de RDBMS (sau SGBDR) utilizat, cu specificatia ca majoritatea acestora suporta crearea de tabele (tables), indecsi (indexes), useri (users), sinonime (synonims) si baze de date (databases). Anumite sisteme (cum ar fi PostgreSQL) permit utilizarea comenzii CREATE, cat si a altor comenzi DDL, in contextul unei tranzactii, ca atare, intr-un astfel de context, aceste comenzi pot fi supuse si unor operatii de rollback. In general, in tehnologia bazelor de date, o operatie rollback determina refacerea bazei de date la o stare anterioara specificata. Operatiile rollback sunt deosebit de importante pentru integritatea bazelor de date, deoarece permit refacerea bazei de date la o versiune curata (clean copy), anterioara efectuarii eventuale a unor operatii eronate. De asemenea, operatiile rollback sunt cruciale pentru recuperarea bazei de date in urma caderilor server-elor de date (recovery from database server crashes), deoarece prin aplicarea unui rollback in urma efectuarii unor tranzactii care au fost active in momentul unei caderi a server-ului de date, baza de date poate fi readusa la o stare anterioara consistenta. Implementare rollback: Functionalitatea rollback este implementata in mod uzual prin intermediul: (a) unui log de tip transaction log, sau (b) prin intermediul unei metode multiversion concurrency control. Un rollback in cascada (cascading rollback) apare in sistemele de baze de date atunci cand o tranzactie (T1) cauzeaza (produce) o cadere (failure) astfel incat este necesar un rollback ; in plus, o alta tranzactie care depinde de T1, trebuie de asemenea supusa unui rollback din cauza caderii tranzactiei T1, etc. In acest mod, apare un efect de tip cascada, numit rollback cascadat sau cascading rollback. (a) Transaction log: In domeniul administrarii bazelor de date un log de tip transaction log (denumit si database log sau binary log) este un history al actiunilor executate de catre un SGBD pentru a garanta proprietatile ACID (atomicitate, consistenta, izolare optima, durabilitate) in raport cu posibilele caderi hardware sau software. Din punct de vedere fizic, un log este un fisier in care se inregistreaza toate

actualizarile efectuate asupra bazei de date, acest fisier fiind stocat pe un suport stabil, care nu poate fi afectat de catre caderile accidentale ale sistemului. O inregistrare a unui log de tip database log este formata din urmatoarele elemente: Log Sequence Number (LSN): este un id care identifica in mod unic o inregistrare log; prin intermediul LSN, log-urile pot fi recuperate untr-un timp constant, bine definit; in general LSN-urile sunt asignate in ordine monoton crescatoare, acest lucru fiind util pentru algoritmii de recuperare (recovery algorithms) (ex. Algoritmul ARIES); Prev LSN: este un link la ultima (cea mai recenta) inregistrare log (last log record); log-urile de tip database log sunt structurate ca liste inlantuite (linked list); Transaction ID number: este o referinta la tranzactia care a generat inregistrarea log; Type: denumeste tipul inregistrarii database log; Informatii despre modificarile care au declansat scrierea inregistrarii log. Algoritmul ARIES (Algorithm for Recovery and Isolation Exploiting Semantics): Este is un algoritm de recuperare (recovery) utilizat (implementat) in IBM DB2, Microsoft SQL Server , precum si in multe alte SGBD-uri. Principiile care stau la baza algoritmului ARIES: Write ahead logging: orice modificare (actualizare) efectuata asupra unui obiect al bazei de date, trebuie inregistrata mai intai intrun log, aceasta inregistrare trebuind sa fie inscrisa intr-o locatie stabila inainte ca actualizarea respectiva sa fie inscrisa definitiv pe hard-disk; Repeating history during Redo: la repornirea BD dupa o cadere (crash), ARIES retraseaza (reface) actiunile performate inaintea crash-ului, aducand sistemul in starea de dinaintea caderii; apoi sterge tranzactiile care au fost active in momentul caderii (crash-ului); Logging changes during Undo: schimbarile efectuate asupra bazei de date anterior stergerii tranzactiilor active in momentul crash-ului, sunt inregistrate in fisierul log pentru a se asigura nerepetarea acestor actiuni in cazul restartarilor repetate ale sistemului. Tipuri de inregistrari ale database log: Update Log Record noteaza o actualizare (update) efectuata in baza de date, incluzand urmatoarele informatii suplimentare(PageID: referinta la ID-ul paginii modificate, Length and Offset: lungimea in biti si offset-ul paginii modificate, Before and After Images: include valoarea octetilor paginii dinaintea si de dupa efectuarea modificarii); Compensation Log Record noteaza recuperarea unei actualizari particulare din baza de date, incluzand urmatoarea informatie suplimentara (undoNextLSN: acest camp contine LSN-ul inregistrarii log care urmeaza a fi stearsa in maniera undo); Commit Record noteaza o decizie de efectuare (commit) a unei tranzactii; Abort Record noteaza o decizie de a aborta si apoi de a relua o tranzactie; Checkpoint Record noteaza faptul ca a fost fixat un checkpoint in vederea rapidizarii operatiilor de recuperare; informatiile suplimentare aferente acestui tip de inregistrare sunt: redoLSN: referinta la prima inregistrare log care corespunde unei pagini alterate (eronate); undoLSN: referinta la cea mai veche inregistrare log a celei mai vechi tranzactii; Completion Record noteaza faptul ca au fost efectuate toate acvtivitatile aferente unei tranzactii. (b) Metoda Multiversion Concurrency Control (abreviat MCC sau MVCC) : Este o metoda utilizata in mod curent in SGBD-uri, pentru a asigura accesul concurent la bazele de date, dar si in unele limbaje de programare pentru a implementa asa-numita metoda a memoriei tranzactionale (transactional memory).

Implementarea curenta a operatiilor de Actualizare in contextul Bazei de Date:

Actualizarile sunt implementate la nivelul bazei de date nu prin stergerea propriu-zisa a valorii datei care trebuie inlocuita prin actualizare, pentru a se inscrie peste aceasta o noua valoare, ci prin marcarea datei vechi (a valorii vechi a datei care se actualizeaza) ca valoare depasita (deci neactuala), adaugandu-se valoarea noua cu marcajul de valoare actuala a datei care se actualizeaza. Se obtin deci in acest mod mai multe versiuni, stocate succesiv (in timp) in zona de memorie fizica alocata bazei de date, doar una singura dintre aceste versiuni fiind marcata ca valoare actuala; un astfel de mecanism permite chiar depasirea spatiului de disc alocat initial bazei de date (overhead), doar ca, in situatia in care se ajunge la limita fizica a dispozitivului de memorare, datele cele mai vechi (deci versiunile cele mai vechi ale valorilor datelor bazei de date), incep sa se piarda pe masura ce se efectueaza noi actualizari asupra datelor. In cazul Bazelor de Date Orientate pe Documente (Document- Oriented Databases), cum ar fi CouchDB, Riak sau MarkLogicServer, SGBD-ul optimizeaza documentele (si/sau gestiunea memoriei interne) in sensul de a inscrie intregul document in sectoare contigue de disk, ca atare intregul document actualizat se poate suprascrie in zona de memorie alocata acestuia, ceea ce reprezinta o solutie mult mai buna (mult mai rapida) decat scrierea de fragmente de document in zone de memorie disparate. Functionalitati speciale furnizate de MVCC: MVCC furnizeaza o functionalitate numita point in time consistent views (vederi consistente localizate concret si explicit in timp): tranzactiile de citire sub control MVCC utilizeaza time stamp; de fapt este vorba de un ID (timestamp or transaction ID), pentru a identifica starea concreta a bazei de date la care se face acces pentru citire (read). Acest lucru permite managementul locks-urilor pentru a sincroniza accesul concurent la obiecte in contextul bazelor de date cu acces concurent (deci pentru citirea corecta a tranzactiilor), deoarece operatiile de scriere pot fi izolate in virtutea functionalitatii de mentinerea versiunilor anterioare succesive; de fapt, scrierile curente vor afecta practic o noua versiune, in timp ce tranzactia in care se face citirea, identificata prin intermediul ID-ului de tranzactie, este garantata din punctul de vedere al consistentei si stabilitatii tocmai prin faptul ca a fost deja salvata intr-o stare stabila, identificabila prin ID-ul respectiv. Practic, MVCC furnizeaza fiecarui utilizator conectat la baza de date, un snapshot (o imagine) al/a bazei de date consistent, robust si stabil, cu care poate lucra utilizatorul respectiv in conditii de maxima siguranta. Orice schimbare efectuata la nivelul unui anumit ultilizator conectat, nu poate fi vizualizata si nu poate produce efecte la nivelul celorlalti utilizatori, pana cand nu se incheie tranzactia in contextul careia se efectueaza modificarea. Comanda SQL Rollback In SQL, comanda ROLLBACK asigura revenirea bazei de date la o stare anterioara consistenta, coerenta si corecta, sub camanda SGBDR/ sau a RDBMS. Practic, toate schimbarile efectuate dupa ultima comanda de tip BEGIN WORK sau START TRANSACTION sunt abandonate, astfel incat starea tuturor datelor din baza de date este refacuta la valorile anterioare sesiunii curente de lucru. O comanda ROLLBACK va abandona de asemenea toate punctele de tip savepoints existente la momentul lansarii acestei comenzi. Sintaxa comenzii ROLLBACK: ROLLBACK [to SavePoint name]

LMD (DML)
DEF: Alaturi de LDD, LMD este o a doua componenta importanta a SGBD, dar importanta acesteia in Administrarea Bazei de Date este intrucatva inferioara rolului pe care-l are LDD in contextul atributiilor si operatiilor de administrare; practic, instructiunile LMD (DML) sunt utilizate pentru regasirea si actualizarea valorii datelor inregistrate in tabelele Bazei de Date. In cazul situatiei in care suntem conectati la mai multe baze de date cu arhitectura multi-utilizator (multi-user databases), fie prin intermediul unei componente client (client program), fie prin intermediul unei conexiuni din contextul unei secvente script a unei pagin WEB (Web page script), lucram de fapt cu o copie privata a tabelelor din vederea la care suntem conectati, copie privata care nu poate fi vazuta de nimeni altcineva pe intreaga durata a operatiei pe care o efectuam. Clauza SELECT (SELECT statement) este considerata ca facand parte din LMD (DML), in virtutea faptului ca ea este utilizata mai degraba pentru regasirea datelor decat pentru actualizarea propriu-zisa. Instructiuni (clauze) LMD propriu-zise: 1. Clauza INSERT utilizata pentru adaugarea de noi randuri (noi instantieri) in tabelele Bazei de Date
INSERT INTO <table name> VALUES (<value 1>, ... <value n>); 2.Clauza

UPDATE utilizata pentru modificarea (actualizarea) valorii datelor inregistrate in tabelele Bazei de Date
UPDATE <table name> SET <attribute> = <expression> WHERE <condition>; 3. Clauza DELETE: utilizata pentru stergerea de

date din tabelele Bazei de Date (stergerea de randuri- deci

de instantieri ale tabelelor BD) Baze de Date multi-utilizator, in momentul in care dorim sa facem cunoscute tuturor utilizatorilor autorizati modificarile DML efectuate la nivelul unei copii private; de altfel, acest lucru este realizat in mod automat in urma operatiei de log out, dar in cazul in care dorim sa facem vizibile modificarile anterior delogarii, putem sa scriem pur si simplu comanda: in cazul in care dorim sa refacem starea Bazei de Date din contextul unei copii private a acesteia, la o starea initiala (deci starea anterioara efectuarii ultimei comenzi COMMIT aceste comenzi sunt vitale in sistemele de control tranzactii si in sistemele multi-user in general). Sintaxa:
ROLLBACK; COMMIT; 5. Clauza ROLLBACK se utilizeaza DELETE FROM <table name> WHERE <condition>; 4. Clauza COMMIT utilizata in contextul unei

In cazul in care au fost definite Puncte de Reluare (Save Points), sintaxa este:
ROLLBACK [to SavePoint name];

Privilegii aferente comenzilor LMD: In cazul in care dorim ca si alti utilizatori sa poata vedea sau manipula datele din tabelele care se afla in Vederea din contextul Bazei de Date pentru care avem atribuite drepturi de acces, la randul nostru putem conferi si altor utilizatori (grant to other users) anumite privilegii (cum ar fi pentru anumite operatii precum: select, insert, update, delete).Acest lucru se face in mod explicit, pentru fiecare tabela in parte;cea mai frecventa utilizare a conferirii in maniera grant a unor privilegii se refera la cazul tabelelor pe care dorim sa le facem accesibile pe WEB (deci, din contextul script-urilor unei pagini WEB de pe un WEB server); ex:
GRANT select, insert ON customers TO webuser;

VEDERI SI INDECSI
Caracteristici Generale. Obiectele bazei de date DB2 UDB: 1. Creare/modificare obiecte ale b.d. DB2: prin comenzi lansate in linia de comanda sau prin intermediul utilitarelor; 2. Toate datele se pastreaza in tabelele bazei de date: un tabel este un obiect DB2 UDB format din una sau mai multe coloane, care au tipuri de date predefinite sau definite de utilizator (user defined), datele sunt pastrate in randurile tabelelor (inregistrari); 3.Tabelele Catalogului Sistemului: orice baza de date contine un astfel de set de tabele pentru a pastra informatii privind toate obiectele bazei de date: tabelul syscat.tables: contine cate o inregistrare pt. fiecare tabel al bazei de date si tabelul syscat.columns: contine cate o inregistrare pt. fiecare coloana a fiecarui tabel al bazei de date; 4. Definirea Spatiilor Rezervate Tabelelor (Tablespaces): La crearea unui nou tabel, DB2 poate fi lasat sa plaseze acest tabel intr-un spatiu rezervat implicit sau Utilizatorul poate opta pt. alegerea unui spatiu propriu; 5.Lista completa a Obiectelor unei baze de date DB2:baza de date, grup(uri) de noduri, tabele, vederi, indecsi, scheme de identificare, tabele ale Catalogului Sistemului Detalierea obiectelor unei baze de date DB2: 1. Instante: Def1: Instanta = un proces al sistemului DB2 care gestioneaza datele, controleaza tot ceea ce se intampla cu datele din baza de date si gestioneaza resursele sistemului care sunt alocate bazei de date. Fiecare instanta reprezinta un mediu complet care contine toate partitiile definite in cazul unui sistem paralel de baze de date. Partitia = o diviziune logica a unei baze de date sau a elementelor sale constitutive in parti distincte, independente.Partitionarea unei baze de date se face de obicei din motive de performanta, disponibilitate sau de gestiune optimizata a resurselor si ea se poate realiza prin: crearea unor baze de date mai mici separate, fiecare avand propriile tabele, indecsi si jurnale ale tranzactiilor; descompunerea elementelor selectate (ex. descompunerea unui singur tabel). O instanta are propriile baze de date (ce nu pot fi accesate de alte instante!) toate partitiile sale folosind aceleasi directoare ale sistemului; O instanta are un sistem de securitate separat de alte instante care se afla pe aceeasi masina. 2. Baza de Date: Baza de date ca obiect DB2 este implicit o baza de date relationala, care prezinta datele sub forma unei colectii de tabele (care au un numar prestabilit de coloane si un numar oricat de mare de randuri). Componenta bazei de date DB2: tabelele continand datele bazei de date, tabelele care alcatuiesc Catalogul Sistem (descriu structura logica si fizica a datelor), fisierul de configurare (contine valorile parametrilor bazei de date), jurnalul de refacere a datelor impreuna cu tranzactiile aferente. 3. Grupuri de Noduri: set de una sau mai multe partitii ale unei baze de date. Atunci cand se doreste crearea tabelelor intr-o baza de date trebuie: sa se creeze un grup de noduri in care se stocheaza spatiile rezervate tabelelor si sa se creeze spatiile ce pastreaza tabelele (TableSpace-urile). 4. Tabele: In DB2 toate datele bazei de date, cat si datele privind tabelele ( cele stocate in Catalogul Sistem) sunt atasate spatiilor rezervate tabelelor (TableSpace-urilor). Datele din tabele sunt accesate prin intermediul Limbajului Structurat de Interogare (SQL = Structured Query Language) 5. Vederi = modalitate eficienta de structurare logica a datelor, fara a fi necesara reprezentarea fizica directa a structurii respective. O vedere este un tabel virtual (sau o colectie de tabele virtuale), care nu cere spatiu propriu de stocare in baza de date, deoarece datele unei vederi sunt compuse dinamic din tabelele fizice sau logice ale bazei de date, sau din alte vederi deja existente.O vedere poate include toate sau doar o parte din coloanele tabelelor din baza de date. 6. Indecsi: index = obiect al bazei de date DB2 care poate mari semnificativ viteza interogarilor efectuate relativ la baza de date; un index este format dintr-o serie de chei, fiecare cheie

reprezentand un pointer catre inregistrarile bazei de date indecsii permit un acces mult mai eficient la date prin crearea unei cai directe de acces catre acestea prin intermediul unor pointeri. OBS1: Optimizatorul de interogari SQL alege in mod automat calea directa de acces bazata pe indecsi, la datele din tabelele bazei de date DB2. Cheia de Indexare reprezinta o coloana sau o colectie de coloane pe care se defineste un index. Pot fi creati indecsi unici pentru a asigura unicitatea cheii de indexare. Prin folosirea unui index unic se asigura faptul ca valoarea fiecarui index din coloana (coloanele) indexate este unica. 7. Scheme de identificare: O schema de identificare = un identificator care ajuta la gruparea tabelelor si a altor obiecte ale bazei de date; ea poate fi creata automat odata cu crearea primului obiect din cadrul unei baze de date; pt. acest lucru, utilizatorul are nevoie sa fie autorizat cu drepturile IMPLICIT_SCHEMA. O schema de identificare poate sa apartina unui utilizator individual, care are acces, prin intermediul ei, la toate datele si obiectele din cadrul acesteia. Identificarea fara echivoc a unui obiect poate fi facuta prin prefixarea numelui obiectului cu cel al schemei care il contine; daca nu se specifica explicit numele acesteia, obiectul este considerat ca apartinand schemei implicite (corespunzatoare identificatorului utilizatorului care a creat obiectul respectiv). 8. Tabelele Catalogului Sistem: set de tabele continute in orice baza de date, pentru a descrie structura logica si fizica a datelor; contin informatii referitoare la: (a) definirea obiectelor bazei de date (tabele, vederi, indecsi etc); (b) securitatea bazei de date (drepturi si privilegii). Aceste tabele se creeaza la crearea bazei de date, actualizandu-se permanent, odata cu efectuarea oricarei noi operatii in baza de date. Nu pot fi create sau eliminate explicit, dar pot fi interogate, cat si vizualizate la nivelul continutului lor, folosindu-se vederile Catalogului Sistem. Modelul de inmagazinare a datelor in baza de date DB2: 1. Spatiile rezervate tabelelor: tipul de spatiu obisnuit (datele utilizatorului si obiectele BD), tipul de spatiu temporar (inmagazineaza datele temporare ale aplicatiilor) si long (optional).; 2. Containere: dispozitiv fizic de inmagazinare a datelor. Poate fi identificat prin interm. unui nume de dispozitiv sau nume de fisier. Un container este afisat unui spatiu rezervat tabelelor; un singur astfel de spatiu poate contine mai multe containere, dar fiecare container poate apartine unui singur spatiu destinat tabelelor.

Indecsi in DB2 UDB

Indexarea este o metod eficient de acces la baza de date si se bazeaza pe asigurarea faptului c o coloan respect condiia de unicitate ntr-o tabel. Un index este o metod logic de acces la date si scopul indexrii este de a indica adresa exact a datei de interes. Mecanismul de generare index in DB2 UDB: un index este construit uzual dup o singur coloan a tabelei, numit i coloan index sau cmp index, iar indexul asociaz la fiecare valoare a coloanei index o list de pointeri ctre toate blocurile ce conin nregistrarea cu valoarea specificat. Avantajel indexrii: valorile n index sunt ordonate, aa ca aici pot fi aplicate metode de cutare binar; cum structura index este mult mai restrns dect tabela de date, eficiena cutrii binare pe aceast structur crete Index primar: Un index primar se construiete avnd coloana de indexare o cheie primar, coloan dup care este ordonat i tabela de date; in acest caz ordinea fizic i ordinea logic sunt identice. Indexul primar nu conduce la cretere substanial a eficienei accesului la date dar definete metoda de realizare a indexrii multinivel; in situaia n care coloana de indexare nu este o cheie primar sau o coloan cu valori unice indexul mai poart denumirea de index de grup (sau clustering index). Index secundar: Un index secundar este construit dup orice coloan a tabelei de date indiferent dac coloana conine valori unice sau nu. Un index este numit i Index unic dac coloana de indexare este

unic sau Index nonunic dac s-a indexat dup o coloan ce permite valori identice la mai multe inregistrri. Ca urmare, la o tabel de date se pot construi mai multe structuri index funcie de criteriile de acces, materializate n indeci unici sau neunici. Indiferent de tipul de index, un index este o colecie ordonat de valori ale coloanei dup care indexul a fost creat. Putem considera c fiecare valoare a cheii de indexare are un RID (Row IDentifier) care indic nregistrarea sau nregistrrile pentru care cmpul de indexare conine acea valoare a cheii. O tabel poate avea mai muli indeci construii pe baza unei coloane sau a unei asociaii de coloane. Structura: Indexul primar: structura de date conine dou coloane, prima coloan a indexului fiind o coloan cheie unic dup care este ordonat tabela de date i a doua coloan pointerul ctre un bloc n care se pstreaz nregistrarea (o adres a blocului), asociaia celor dou coloane formand intrarea index sau inregistrarea index, cte una pentru fiecare bloc al tabelei de date. Cum tabela de date este ordonat dup valorile coloanei index, n index se va pstra cte o intrare pentru fiecare bloc, intrare corespunztoare primei nregistrri a blocului; a doua coloan avnd semnificaia de pointer ctre bloc va indica adresa blocului Descrierea structurii index: perechi de forma < K(i), P(i) >, pentru i lund valori de la 1 la numrul blocurilor. Numarul total al intrrilor index este egal cu numrul blocurilor folosite pentru stocarea tabelei de date. Valoarea coloanei index a primei nregistrri dintr-un bloc se mai numete i valoare de ancorare iar nregistrarea, nregistrare de ancorare a blocului. Un index primar este un exemplu de index nondens datorit faptului c are o intrare pentru fiecare bloc fa de un index dens ce asociaz cte o intrare pentru fiecare nregistrare a tabelei de date.Volumul necesar pentru stocarea indexului primar este mic datorit urmtoarelor motive: necesit cte o singur intrare pentru un bloc al tabelei de date; o intrare index ocup mult mai puini octei dect o nregistrare a tabelei de date deoarece intrarea index are o structur predefinit cu numai dou coloane; Ca urmare cutarea n index este mult mai rapid dect ntr-o tabel de date, fiind vehiculat un volum mult mai mic de informaii. Exemplificare concreta: o nregistrare pentru care valoarea cheii primare este k se gsete n blocul i dac este ndeplinit condiia k(i)<=k<k(i+1). Adresa blocului i este dat de P(i) i inregistrarile n acest bloc sunt fizic ordonate dup coloana cheie unic. Pentru a accesa o nregistrare cu valoarea coloanei de indexare k, se procedeaz la cutarea binar n index, urmat de o cutare n blocul de date cu adresa indicat de P (i). Indexarea este cu att mai avantajoas cu ct tabela de date conine mai multe nregistrri; o problem major la manipularea tabelelor indexate apare n situaia inserrii, tergerii sau modificrii coloanei unice de ordonare a tabelei, necesitnd refacerea indexului; In general se pstreaz n baze de date tabelele sortate numai dac modificrile acestora sunt realizate foarte rar. Indexul asociat unei tabele de date se numete de grup, dac nregistrrile tabelei de date sunt ordonate fizic dup o coloan neunic; valorile unei astfel de coloane identific un grup de nregistrri (clustering field), si n acest caz poate fi construit un index care s faciliteze acesul la nregistrrile ce aparin unui grup. Poate cea mai uzual metod de indexare este indexarea secundar, ce se aplic la tabele neordonate, indiferent dac valorile coloanei dup care se face indexarea din tabela de date sunt sau nu unice; Indexul secundar fiind o structur ordonat cu dou coloane, similar cu ali indeci, n care prima coloan este o coloan a tabelei de date iar a doua un pointer, orice coloan a tabelei de date poate fi coloan pentru indexare cu index secundar.

Definirea vederilor in DB2 UDB

Vederile permit ca diferii utilizatori ai unei aplicaii de baze de date s priveasc datele n diverse moduri, din punctul de vedere al gruparii acestora pe criterii de interese sau de drepturi de acces. Un astfel de mod nu asigur numai un acces mai uor la date ci i posibilitatea de a restriciona ce

nregistrri i coloane pot fi vizualizate i modificate. Vederile pot fi creeate pe baza tabelelor existente, a altor vederi sau orice combinaie a acestora Modalitatea de definire a vederilor: Vederile se pot defini cu diverse nume de coloane care corespund coloanelor tabelelor de baz. O vedere poate fi definit pentru a verifica la inserarea sau modificarea datelor ndeplinirea condiiilor. Localizarea elementelor de definire ale vederilor este urmatoarea: lista vederilor definite n baza de date este pstrat n tabela catalog sistem, anume (in DB2 UDB): sysibm.sysviews , iar definirea vederii se afla n syscat.views ; lista si informatiile privind vederile dependente de o anumita vedere sunt continute tot in Catalogul Sistem, anume in syscat.viewdep, unde pentru fiecare vedere definit n baza de date apare cte un rnd pentru fiecare tabel sau vedere dependent. Fiecare vedere are cte o intrare n sysibm.systables si sysibm.syscolumns ; vederea poate fi utilizat ca o tabel virtuala. De multe ori o vedere definete o tabel rezultat a unei cereri SQL. Specificarea vederii determina ca o interogarea SQL s fie executat ori de cte ori vederea este referit ntr-o cerere SQL. Coninutul unei vederi este dat de rezultatul execuiei unei cereri. Acest rezultat poate s conin volume mari de date ce ar consuma spaiu de stocare. Baza de date nu va stoca rezultatul ci definiia cererii ce creeaz vederea, mai departe aceast vedere putand fi utilizat similar cu o tabel de baz. Utilitatea acestei abordari: in cazurile in care pentru vizionarea anumitor date sunt necesare operaii complexe de tip join sau cnd un utilizator are acces numai la anumite date stocate n baz. Caracteristicile vederilor: 1. Atunci cnd o vedere este creat ea are asociat un nume similar cu numele oricrei tabele a bazei de date, nume ce este utilizat pentru a referi vederea n alte cereri SQL. 2. n parantez, dup nume se poate specifica numele coloanelor vederii. Tipul datelor acestor coloane este motenit din cererea SQL. Dac nu se specific numele coloanelor n vedere atunci acestea motenesc numele coloanelor specificate la clauza SELECT a cererii SQL ce definete vederea. 3. Pentru ca un utilizator s aib acces la vedere este necesar existena privilegiilor de acces la vedere, fr a necesita privilegii de acces la tabelele din care vederea este realizat. 4. 4. Atunci cnd o vedere este creat ea poate fi definit ca o vedere read-only (ce poate fi numai citit) sau care poate fi modificat; cererea SELECT utilizat la definirea vederii determin dac o vedere este numai citit sau poate fi modificat; in general, dac nregistrrile unei vederi pot fi mapate la nregistrrile tabelei de baz vederea poate fi modificat. 5. Regulile pentru definirea vederilor dup care acestea pot fi modificate sunt destul de complexe i dependente de definirea cererii; vederile care utilizeaz VALUES, DISTINCT, JOIN funcii de grupare nu pot fi modificate. 6. Este foarte uor de determinat dac o vedere poate fi modificat prin valoarea coloanei read only din syscat.views, n care Y nseamn c este read-only, iar N inseamna ca este non read only. 7. Datele pot fi inserate sau modificate n tabelele corespondente prin intermediul vederii; definirea unei vederi utiliznd WITH CHECK OPTION va specifica DB2 UDB s verifice dac modificarea prin vedere satisface condiiile. O declaraie posibil la definirea vederilor este WITH CASCADED CHECK OPTION prin care se asigur satisfacerea condiiilor vederii i a tuturor vederilor nlnuite chiar dac acestea nu sunt definite cu check option. Atunci cnd se definete o vedere pe baza altei vederi, opiunea check poate fi utilizat pentru a restriciona anumite operaii; pentru specificarea modului n care restriciile sunt motenite se poate opta pentru CASCADED, sau, in caz contrar LOCAL.CASCADED este opiunea default dac nu se specific altceva. Atunci cnd o vedere este creat cu opiunea CASCADED toate operaiile executate n vedere trebuie s satisfac restriciile vederii i ale vederilor nlnuite, indiferent dac aceste vederi sunt definite sau nu cu opiune check.

MONITORIZAREA SI IMBUNATATIIREA PERFORMANTELOR

Monitorizarea performanelor este o activitate important la nivelul SGBD-urilor, dar i la nivelul bazelor de date definite de utilizatori. Monitorizarea performantelor cade n principal n sarcina administratorului bazei de date, dar este indicat ca i celelalte tipuri de utilizatori ai bazei de date, precum programatorii de aplicaii sau utilizatorii finali, s fie capabili s consulte i s interpreteze informaiile de monitorizare. In general, SGBD-urile dispun de unelte(tools-uri) special create pentru activitile de monitorizare, menite a pune in evidenta situatiile in care performanele sistemului nu sunt dintre cele mai bune, pentru ca acestea s poata fi mbuntite. Exista mai muli parametri de configurare, care pot fi folosii pentru mbuntirea performanelor la nivelul managementului SGBD-urilor, sau la cel al bazelor de date create de utilizatori (spre ex., in comanda pentru autoconfigurarea sistemului). Parametrii de configurare care influeneaz performana: La nivelul categoriei de atributii operative, Administratorul Bazei de Date (DBA) raspunde de operaiile de monitorizare i mbuntire a performaelor Bazei de Date: el trebuie s urmreasc n permanen modul cum baza de date satisface cerinele utilizatorilor ei i s ia msurile adecvate dac performaele sunt sczute. Performana este definit ca fiind capacitatea sistemului de a produce rezultatele dorite cu un cost minim n ceea ce privete timpul sau resursele folosite i este msurat cu ajutorul unor metrici precum: timpul de rspuns, numrul de operaii executate n unitatea de timp i disponibilitatea. Performana ntr-un sistem de gestiune a bazelor de date poate fi mbuntit prin: mrirea capacitii de memorie, adugarea unor discuri mai rapide, adugarea unor noi procesoare, printr-o mai bun utilizare a resurselor existente, in general. Tuningul (ajustarea) performanei este procesul prin care sunt modificai diferii parametri ai sistemului n ncercarea de a face ca sistemul s ruleze mult mai eficient. Scopul procesului de Tuning al sistemului pentru o performan optim include: S se poat procesa un numr mai mare de operaii fr a fi nevoie s se achiziioneze noi componente hardware, S se obin timpi de rspuns mai mici din partea sistemului fr a se mri costurile de procesare; S se reduc costurile de procesare fr s se afecteze negativ serviciile furnizate utiliztorilor Atunci cnd o baz de date este creat pentru prima dat, muli dintre parametrii ei de configurare sunt lsati la valorile implicite. Parametrii de configurare cu valori implicite sunt potrivii pentru sistemele cu baze de date mici i cu o cantitate relativ mic de memorie. Aceste valori implicite nu sunt ntotdeauna suficiente pentru orice instalare a SGBD-ului Paralelism in DB2 UDB: Atunci cnd calculatorul pe care ruleaz DB2 UDB dispune de mai multe porcesoare, el este capabil s exploateze acest avantaj executnd unele interogri SQL n paralel. Procesarea paralel este posibil doar pentru acele interogri care nu implic operaii de modificare. Autoconfigurare: SGBD DB2, spre exemplu, dispune de o comand special care i permite s fac o autoconfigurare a sistemului, astfel nct acesta s aib pe ct posibil o structur optim. Comanda i permite s fac recomandri cu privire la valorile ce trebuie folosite pentru un buffer pool i pentru configurarea bazei de date i a managerului bazei de date. Aceste valori recomandate pot opional s fie i aplicate la nivelul sistemului. Sintaxa pentru comanda de autoconfigurare este urmtoarea: AUTOCONFIGURE [USING cuvnt_cheie_de_intrare parametru_valoare] [APPLY {DB ONLY| DB AND DBM | NONE] unde: cuvnt_cheie_de_intrare este numele unei resurse care poate fi setat s furnizeze informaii suplimentare pentru autoconfigurare; parametru_valoare este valoarea care va fi atribuit resursei; DB ONLY indic faptul c doar modificrile de configurare

pentru baza de date curent vor fi aplicate; aceasta este starea folosit n mod implicit; DB AND DBM indic faptul c att modificrile de configurare sugerate n cazul bazei de date ct i modificrile de configurare sugerate n cazul managerului bazei de date vor fi aplicate; NONE indic faptul c modificrile sugerate vor fi doar afiate i nu vor fi i aplicate la nivelul sistemului

Monitorizarea performanelor
Monitorizarea activitilor care sunt legate de accesele la baza de date i de procesarea interogrilor SQL, este necesar pentru a putea optimiza performana obinut de sistem. Este important s se poat nelege: -cum o anumit interogare care nu se comport prea bine i care se execut ntr-un mediu specific al unei aplicaii poate fi optimizat; cum aplicaiile care ruleaz n sistem utilizeaz resursele managerului bazei de date la un moment specific n timp; ce evenimente apar la nivelul managerului bazei de date atunci cnd sunt rulate aplicaiile. Activitile de monitorizare sunt executate in DB2 spre exemplu, cu ajutorul unor utilitare specializate pentru aceste funcii. Aceste utilitare pot colecta informaie: de la nivelul managerului bazei de date de la momentul pornirii unei instane i pn la momentul opririi ei; la nivelul bazei de date din momentul primei conectri a unei aplicaii la baza de date i pn n momentul deconectrii ultimei aplicaii; de la nivelul aplicaiilor care ruleaz asupra bazei de date din momentul conectrii aplicaiei la baza de date i pn n momentul deconectrii ei. Pe lng informaiile de baz, care sunt ntotdeauna monitorizate, se mai pot monitoriza: operaiile de sortare blocrile, activitatea la nivelul tabelelor, activitatea la nivelul buffer pool-ului, declaraiile SQL, tranzaciile, etc. DB2 dispune de urmtoarele unelte pentru monitorizarea performanelor: Monitorul de Instantanee, Monitorul de Evenimente, Monitorul de Sntate. Monitorul de Instantanee (Snapshot Monitor) colecteaz informaie despre activitatea bazei de date de la un anumit moment de timp. Datele despre activitatea bazei de date sunt nregistrate doar o singur dat, i anume momentul cnd instantaneul este luat. Cantitatea de informaie colectat de Monitorul de Instantanee este determinat cu ajutorul unor parametri de configurare care se comport ca un fel de comutatori pentru monitor. Aceti comutatori sunt n numr de 6 i controleaz cantitatea de informaie colectat de monitor, precum i dac aceast informaie este colectat pentru o ntreag instan a bazei de date sau numai pentru o singur aplicaie care ruleaz asupra bazei de date. Monitorul de Evenimente (Event Monitor) colecteaza activitatea bazei de date ori de cate ori un eveniment specific are loc. Acest tip de monitor este diferit fata de Monitorul de Instantanee, prin faptul ca el nu inregistreaza numai starea activitatilor bazei de date dintr-un anumit moment de timp, ci din mai multe momente succesive de timp care corespund aparitiei unor evenimente de acelasi tip. Acest tip de monitor este de preferat celui de instantanee in situatii precum blocarile mortale si monitorizarea declaratiilor SQL individuale. Pot fi monitorizate evenimente si elemente precum: baza de date, tabelele, blocarile mortale, spatiile tabel (table-spaces), buffer pool-ul, conexiunile, declaratiile SQL, tranzactiile. Se pot crea monitoare de evenimente individuale care sa monitorizeze anumite tipuri de evenimente. Odata create, aceste monitoare trebuie sa fie activate. Monitorul de Sanatate (Health Monitor) este o componenta deosebit de importanta, care se foloseste pentru monitorizarea performantelor sistemului. El furnizeaza informatii despre starea sistemului si despre datele pe care acesta le controleaza. Acest monitor este o unealta grafica ce poate fi configurata

corespunzator cu mediul bazei de date. Pot fi definite valori de prag pe zone, care declanseaza atentionari sau alarme, atunci cand valorile care sunt colectate de monitor nu se afla in limitele declarate acceptabile pentru ele. Pot fi monitorizate obiecte precum: instante, baze de date, tabele, spatii tabel, conexiuni. Acest lucru se poate face foarte simplu, doar printr-o simpla apasare pe butonul mouse-ului: anterior se face pozitionarea cursorului pe obiectul vizat, ce se gaseste in Arborele de Obiecte (Object Tree), sau in panoul Continut (Content) bdin Centrul de Control (Control Center), dupa care prin click dreapta pe mouse se poate selecta din meniul care se deschide, optiunea de incepere a activitatii de monitorizare. Atunci cand un obiect este monitorizat, culoarea pictogramei care il insoteste poate avea culoarea verde, galbena sau rosie, pentru a indica starea monitorului. Culoarea indica severitatea problemei aparute, raportat la valorile de prag setate anterior.

BACKUP i RECOVERY
Procesul de recuperare apare n bazele de date atunci cnd este nevoie s se refac o instan la o stare consistent, stare din care s-a ieit datorit unor evenimente care au generat nesincronizri ntre diferitele pri ale instanei . n mod normal se ntlnesc probleme ale mediilor de stocare, probleme de alimentare cu energie a sistemelor defecte ale aplicaiilor; in aceste situaii pot fi realizate copii de siguran ale bazei de date sau ale tablespace-urilor individuale, care pot fi apoi reconstituite chiar dac sunt distruse sau deteriorate. Reconstruirea acestor obiecte se numete recuperare. De exemplu: (a)recuperarea dup un defect logic al programului poate fi fcut doar pn n momentul nceperii programului eronat; (b)recuperarea dup o pan de curent poate restaura baza de date la starea consistent a acesteia de la ultimul commit. Pentru a realiza refacerea bazei de date n urma tuturor problemelor poteniale, administratorul bazei de date trebuie s cunoasc toate caracteristicile recuperrii n SGBD-ul in contextul caruia ruleaza baza de date. Ca urmare, o instalare necesit i precizarea nevoilor de recuperare, nevoi care pot s nu solicite n totalitate facilitile oferite de sistem. Datele din tabele sunt plasate n tablespace-uri; un tablespace este nivelul logic dintre baza de date i tabelele stocate n aceasta. Tablespace-urile permit atribuirea unei locaii pentru baza de date i pentru tabele direct n containere, un container putand fi numele unui director, al unui dispozitiv sau al unui fiier; un singur tablespace se poate ntinde pe mai multe containere (din motive de performan, fiecare container ar trebui s utilizeze un disc diferit). In DB2, utilitarul DB2 BACKUP permite realizarea unei copii de siguran la nivelul bazei de date i al tablespace-ului. Pentru copii ale tabelelor individuale pot fi folosite utilitarele EXPORT i db2move. n contextul SGBD-ului DB2 exist 3 tipuri de metode de recuperare: Crash (1), Version (2) si Roll forward (3).(1) Recuperarea Crash utilizeaz jurnalele pentru a reface baza de date dup o pan de curent sau n urma unei aplicaii abandonate; acest tip de recuperare se face automat dac parametrul AUTORESTART este configurat la valoarea implicit, iar dac nu se folosete AUTORESTART, este necesar o intervenie manual pentru a iniializa recuperarea.(2) Recuperarea Version sau Restore utilizeaz o copie de siguran a bazei de date pentru a nlocui datele curente din baza de date; aceast metod asigur recuperarea dup probleme ale mediilor de stocare, hardware sau software dar doar pn n momentul n care s-a realizat copia bazei de date. De aceea cu ct sunt realizate copii mai dese, cu att baza de date recuperat va fi mai apropiat de forma avut naintea apariiei problemei.(3) Recuperarea Roll forward utilizeaz o copie de siguran a bazei de date pentru nlocuirea datelor curente dar i

nregistrrile jurnarului pentru a recupera schimbrile de dup realizarea copiei bazei de date. Metoda asigur recuperarea dup probleme media, hardware, software i operaionale i aceasta se realizeaz pn n momentul ultimei aciuni validate. O recuperare Roll forward ce utilizeaz o copie de siguran recent va necesita mai puine nregistrri din jurnal dect o astfel de recuperare ce utilizeaz o copie mai veche, ca urmare, frecvena realizrii de copii de siguran trebuie s fie n atenia administratorului bazei de date. Jurnalizarea tranzaciilor (tranzaction logging) reprezint procesul prin care se nregistreaz fiecarea modificare produs n baza de date pentru a face posibil recuperarea acesteia la nevoie. Fiierele log ( jurnal ) sunt folosite pentru a pstra nregistrri ale tuturor modificrilor realizate asupra obiectelor bazei de date. Dimensiunea maxim a unui fisier log este de 256 GB. Schimbrile asupra bazei de date sunt scrise mai nti n memorie, n buffer-ele jurnalului, dup care sunt scrise (flushed) din memorie n fiierele jurnal de pe disc, fiiere care constituie jurnalul stabil. Tranzaciile scrise n jurnal definesc o unitate de lucru, unitate ale crei rezultate pariale pot fi anulate dac nu se finalizeaz cu succes. Jurnalul este necesar pentru realizarea reacuperrii care const n succesiunea a dou faze: (I) Prima dintre aceste faze este reaplicarea tuturor tranzaciilor, indiferent dac acestea au fost sau nu validate, dup care urmeaz (II) anularea (rularea napoi- rollback) a acelor tranzacii ce nu au fost validate. nregistrarea circular este metoda implicit de jurnalizare n DB2. Fiierele jurnal principale sunt folosite pentru nregistrarea tuturor schimbrilor i sunt reutilizate dup ce schimbrile au fost validate. Fiierele jurnal secundare sunt alocate atunci cnd se atinge limita fiierelor principale. Aceast metod de nregistrare circular permite recuperarea unei versiuni valide n cazul unei cderi a bazei de date. Versiunea V8 a DB2 UDB a introdus o metod de nregistrarea nelimitat. Aceasta permite unei uniti active de lucru s extind i s arhiveze jurnalele, permind astfel unei tranzacii s utilizeze efectiv un numr infinit de fiiere jurnal. Cnd nu este activat nregistrarea nelimitat, nregistrrile unei uniti de lucru trebuie s se ncadreze n spaiul alocat jurnalelor principale. nregistrarea dubl (dual logging) ofer o posibilitate de a menine o copie n oglind att pentru jurnalele principale, ct i pentru cele secundare. Dac fiierele principale sau secundare sunt corupte, sau dispozitivul unde sunt stocate aceste fiiere devine indisponibil, totui baza de date poate fi recuperat. nregistrarea dubl este activat setnd parametrul de configurare al bazei de date MIRRORLOGPATH la valoarea cii unde vor fi salvate copiile jurnalelor. O salvare de siguran (backup) se realizeaz prin rularea comenzii BACKUP din Comand Line Processor sau prin utilizarea unei interferene grafice BACKUP lansat din Control Center al SGBD DB2.Pentru a realiza un backup al bazei de date trebuie s avem drept de SYSADM, SYSCTRL sau SYSMAINT. La rularea utilitarului BACKUP, acesta realizeaz o copie a datelor n memoria tampon (buffer), apoi ctre locaia final. Se poate indica dimensiunea i numrul de buffere folosite i locul de pstrare a copiei de siguran: pe disc, band magnetic, TSM (Tivoli Storage Manager - IBM), interfaa XBSA (X/Open Backup Services Application Programmer's Interface), sau ctre nume de bibliotec partajat ce conine funciile I/O ale productorului. Utilitarul db2ckbkp va permite afiarea de informaii desprea copiile fcute. Acest utilitar permite testarea integritii copiei stabilind dac poate fi folosit pentru refacere sau nu, precum i pentru afiarea metadatelor coninute n antetul acesteia. Copiile de siguran pentru o baz de date DB2 UDB, pot fi fcute i prin utilizarea comenzii BACKUP DATABASE, a crei sintax este urmtoarea:

BACKUP DATABASE database_alias [USER user_name[USING password]] [TABLESPACE tablespace_name][ONLINE] [USE TSM|XBSA][OPEN num_sessions SESSIONS] |[TO target_area] |[LOAD library_name[OPEN num_sessions SESSIONS]] [WITH num_buffers BUFFERS][BUFFER buffer_size] [WITHOUT PROMPTING] Comanda BACKUP DATABASE ofer control concurent asupra proceselor ce realizeaz copii de siguran ale diferitelor baze de date. Controlul menine un container deschis (pe dispozitivul destinaie) pn cnd ntreaga operaie s-a ncheiat. Dac n timpul operaiei de salvare apare o eroare, containerul deschis nu va putea fi nchis. Avnd containerul deschis, alte procese ctre acelai disc vor genera erori de acces. Pentru a corecta aceste erori de acces se va abandona complet operaia ce a cauzat eroarea i se va face deconectarea de la dispozitivul destinaie. Utilitarul RESTORE Restaurarea unei copii de siguran const n refacerea bazei de date sau a tablespace-ului cruia i s-a aplicat comanda BACKUP. Restaurarea poate fi iniializat din Comand Line Processor sau din Control Center al SGBD DB2 UDB. Pentru a putea restaura o baz de date trebuie sa avem drept de acces de nivel SYSADM, SYSCTRL sau SYSMAINT. Pentru a restaura baza de date ntr-o nou baz de date gradul de autoritate trebuie s fie SYSADM sau SYSCTRL. Comanda Restore functioneaza asupra copiilor realizate fol. Comanda BACKUP, pe acelasi sistem de operare. Poate folosi programe externe de management al stocarii, cum ar fi: Trivoli Storage Management Solutions (ADSM). Procesul de restaurare necesit conexiune exclusiv la baza de date, care poate fi local sau pe un server la distan. Comanda RESTORE DATABASE reface o baz de date distrus sau corupt creia i-a fost fcut n prealabil o copie de siguran cu BECKUP DATABASE. Baza de date ctre care se face restaurarea poate fi aceeai baz de date la care s-a fcut copia de siguran, sau poate fi o baz de date nou. Odat ce comanda RESTORE DATABASE este lansat asupra unei baze de date, aceasta nu mai poate fi accesat pn ce operaia de restaurare nu se ncheie cu succes. Este posibil ca o operaie de roll forward s fie necesar nainte de a fi permis accesul la baza de date. Considerente privind salvrile de siguran/restaurarea tablespace-urilor: (C1) Pentru a putea face backup sau restaurare la nivel de tablespace trebuie folosit arhivarea jurnalelor. Un subset de tablespace-uri poate fi restaurat dintr-o imagine a unei baze de date sau tablespace. (C2) Unul dintre cele mai importante motive pentru a utiliza restaurarea la nivel de tablespace l constituie reducerea timpului de backup i restaurare. Aceasta este realizat reducnd cantitatea de date implicat n cele dou procese. Totui, administratorul bazei de date nu trebuie s se rezume doar la a minimiza cantitatea de date dintr-un backup. Dei acest lucru s-ar putea realiza plasnd un singur tabel ntr-un tablespace, acest lucru ar creea probleme de management privind operaiunile de salvare i restaurare. (C3) Dac tabelele de catalog sunt implicate ntr-o situaie de recuperare, accesul la ntreaga baz de date este afectat. Din aceast cauz, este de preferat s se foloseasc salvri la nivel de tablespace pentru tabelele de catalog. Dac dorim s recuperam catalogul, durata procesului va fi redus dac putem restaura imaginea unui tablespace n loc de imaginea ntregii baze de date. (C4) Tabelele aplicaiilor considerate critice ar trebui s fie printre primele luate n considerare pentru un backup. Motivul l reprezint reducerea timpului datorit strategiei de salvare/restaurarea tablespaceului.