1

Cuprins

CAPITOLUL 1 Noiuni introductive privind sistemele de gestiune a bazelor de date ........................... 4
1.1 Noiuni teoretice ...................................................................................................................... 4
1.1.1 Modelul relaional .................................................................................................................. 4
1.2. Instalarea i pornirea SGBD ......................................................................................................... 8
1.2.1 Sistemul de gestiune SQL Server ............................................................................................ 8
1.3 Arhitectura Microsoft SQL Server .............................................................................................. 12
1.3.1 Arhitectura administrativ SQL Server ................................................................................. 14
1.3.2 Suport pentru dezvoltarea data tier-ului ............................................................................. 15
1.3.3 Setul de comenzi SQL ........................................................................................................... 15
1.3.4 Securitate i autentificare ...................................................................................... 19
1.3.5 SQL Server 2005/2008 .......................................................................................................... 19
CAPITOLUL 2 Crearea bazelor de date Microsoft SQL Server ........................................................... 21
2.1 Introducere................................................................................................................................... 21
2.2 Tranzaci ..................................................................................................................................... 21
2.3 Crearea bazelor de date ............................................................................................................... 23
2.3.1 Managementul creterii dimensiunii fiierelor de date i de log ......................................... 24
2.4 Aspecte de performan a bazelor de date ................................................................................... 26
2.5 Estimarea dimensiunii bazelor de date ........................................................................................ 29
CAPITOLUL 3 Metode de autentificare server de baze de date ........................................................... 31
3.1 Autentificarea Microsoft Windows ............................................................................................. 32
3.1.1 Autentificarea Kerberos ....................................................................................................... 33
3.1.2 Autentificarea Windows NT LAN Manager(NTLM) .............................................................. 34
3.1.3 Procesul de autentificare al unei conectri Windows(Windows Login). ............................. 35
3.2 Autentificarea SQL Server .......................................................................................................... 35
3.3 Compararea autentificrii Windows cu autentificarea SQL. ....................................................... 36
3.3.1 Avantajele autentificrii Microsoft Windows ....................................................................... 36
CAPITOLUL 4 Implementarea vederilor pentru baze de date Microsoft SQL Server ......................... 37
4.1 Introducere................................................................................................................................... 37
4.2 Clasificarea vederilor .................................................................................................................. 40
4.3 Restricii la crearea vederilor....................................................................................................... 41
4.4 Modificarea i tergerea vederilor ............................................................................................... 41
2

4.5 Afiarea informaiilor despre vederi ............................................................................................ 43
4.6 Modificarea datelor prin vederi ................................................................................................... 44
4.7 Folosirea vederilor indexate ....................................................................................................... 44
4.8 Folosirea vederilor pentru a partiiona datele ............................................................................. 45
CAPITOLUL 5 Implementarea procedurilor stocate pentru baze de date Microsoft SQL Server ........ 46
5.1 Introducere................................................................................................................................... 46
5.2 Crearea procedurilor stocate utilizator ........................................................................................ 47
5.3 Crearea procedurilor stocate sistem............................................................................................. 48
5.4 Declararea variabilelor i folosirea parametrilor ........................................................................ 48
5.5 Controlul fluxului de execuie .................................................................................................... 51
CAPITOLUL 6 Implementarea triggerelor pentru baze de date Microsoft SQL Server ....................... 53
6.1 Introducere ................................................................................................................................ 53
6.2 Exemple de triggere ................................................................................................................... 56
6.3 Modificarea i tergerea triggerelor ......................................................................................... 58
6.4 Restricii de utilizare a declanatorilor.................................................................................... 59
6.5 Tipuri de declanatoare ........................................................................................................... 59
CAPITOLUL 7 Implementarea funciilor pentru baze de date Microsoft SQL Server ......................... 61
7.1 Introducere................................................................................................................................... 61
7.2 Crearea unei funcii definite de utilizator .................................................................................... 61
7.3 Crearea funciilor scalare ............................................................................................................. 63
7.4 Crearea funciilor multi-instruciune ........................................................................................... 64
7.5 Crearea funciilor mono-linie ...................................................................................................... 64
7.6 Ghid de utilizare a funciilor....................................................................................................... 65
CAPITOLUL 8 Managementul accesului la baza de date ..................................................................... 66
8.1 Administrarea utilizatorilor ......................................................................................................... 66
8.1.1 Crearea utilizatorilor ............................................................................................................. 66
8.1.2 Modificarea utilizatorilor ...................................................................................................... 67
8.1.3 tergerea unui utilizator ....................................................................................................... 67
8.2 Administrarea rolurilor ................................................................................................................ 67
8.2.1 Rolul public ........................................................................................................................... 68
8.2.2 Alte roluri fixe ....................................................................................................................... 68
8.2.3 Roluri definite de utilizator ................................................................................................... 68
8.3. Managementul securitii obiectelor .......................................................................................... 69
8.3.1 Tipuri de permisiuni .............................................................................................................. 69
3

8.3.2 Implementarea permisiunilor............................................................................................... 72
8.3.3 Conflicte ntlnite la acordarea permisiunilor ...................................................................... 73
8.3.4 Lanul drepturilor de proprietate asupra obiectelor ............................................................ 74
8.4. Securitatea aplicaiilor ................................................................................................................ 75
8.4.1 Analizarea cerinelor sistemului ........................................................................................... 75
8.4.2 Protejarea tabelelor ............................................................................................................. 76
8.4.3 Strategiile de acces la date. .................................................................................................. 78
CAPITOLUL 9 Salvarea i restaurarea bazelor de date ........................................................................ 81
9.1 Salvarea bazelor de date ........................................................................................................ 81
9.1.1 Generaliti ........................................................................................................................... 81
9.1.2 Efectuarea i stocarea copiilor de backups .......................................................................... 83
9.1.3 Tipuri de salvri de baze de date .......................................................................................... 89
9.2 Restaurarea bazelor de date ................................................................................................... 93
9.2.1 Generaliti ........................................................................................................................... 93
9.2.2 Pregtirea pentru restaurare a unei baze de date .............................................................. 94
9.2.3 Restaurarea backup-urilor unei baze de date - opiuni ....................................................... 95
9.2.4 Restaurarea bazelor de date din diferite tipuri de backup-uri ............................................. 97













4


CAPITOLUL 1
Noiuni introductive privind sistemele de gestiune a bazelor de date

1.1 Noiuni teoretice
O baza de date (database) este o colectie de date creat i meninut computerizat,
care permite operaii de inserare, actualizare, tergere i interogare a datelor. Utilizatorii unei
baze de date pot accesa datele memorate prin intermediul unui program numit Sistem de
Gestiune a Bazei de Date(SGBD).
SGBD - (DataBase Management System - DBMS), este un sistem de programe care
recepioneaz cererile utilizatorilor (pentru operaii de introducere, tergere, modificare sau
interogare), le interpreteaz, execut operaiile corespunzatoare i returneaz rezultatul ctre
utilizatori. Fiecare sistem de gestiune administreaz datele conform unui anumit model de
date. Exist mai multe modele de date utilizate n sistemele SGBD: modelul ierarhic, modelul
reea, modelul relaional, modelul obiect-orientat, modelul obiectrelaional. Dintre acestea, n
momentul de fa, modelul relaional este cel mai larg rspandit, n special n aplicaiile
comerciale i acesta va fi studiat n continuare n aceast lucrare.

1.1.1 Modelul relaional
n modelul relational o baz de date este compus dintr-o mulime finit de relaii,
fiecare relaie reprezentnd un tip de entitate sau o asociere dintre dou sau mai multe tipuri
(mulimi) de entiti. Din aceast definiie rezult c ntr-o baz de date fiecare relaie este
unic (nu exist dou sau mai multe relaii de acelai fel), dat fiind c o baz de date este o
mulime de relaii.
1) Relaii
O relaie se definete prin intermediul atributelor sale. Atributele unei relaii sunt
atributele tipului de entitate sau de asociere pe care l reprezint relaia respectiv. Fiecare
atribut al unei relaii are un domeniu de definiie i poate lua o singur valoare (din domeniul
su de definiie) pentru fiecare tuplu, adic atributele au numai valori scalare.
Un domeniu de definiie (domain) este o mulime cu nume de valori atomice de
acelai tip, avnd o anumit semnificaie, din care si iau valori atributele relaiilor.
Denumirea de valori atomice nseamn c aceste valori nu pot fi descompuse din punct de
vedere al sistemului de gestiune al bazei de date i reprezint cea mai mic entitate semantic
de date.
Schema relaiei (relation schema), notat R(A1,A2,...Ai,...An), este compus din
numele relaiei (R) i din lista ordonat a atributelor sale A1,A2,...Ai,..An, fiecare atribut Ai
definit pe domeniul su de definiie, D(Ai).
Schema relaiei este folosit pentru a descrie relaia respectiv i se mai numete i
tipul relaiei. Numrul de atribute ale schemei unei relaii se numete gradul relaiei.
O relaie (relation) R definit de schema R(A1,A2,...Ai,...An) este o mulime de n-
tupluri t, fiecare tuplu fiind o lista ordonat de n valori t = <v1,v2,...vi,...vn>, unde 1 i n si
vi este valoarea atributului Ai, aparinnd domeniului su de definiie D(Ai).
Din aceast definiie rezult imediat c ntr-o relaie nu exist tupluri duplicat (dou
sau mai multe tupluri identice), relaia fiind o mulime (n sens matematic) de tupluri.
Numrul de tupluri al unei relaii se numete cardinalitatea relaiei.
O relaie se reprezint printr-un tabel (table) care este compus din urmtoarele pri:
Numele tabelului, care este identic cu numele relaiei pe care o reprezint.
Un numar de coloane egal cu numrul de atribute ale relaiei, fiecare coloan
reprezentnd un atribut.
5

Capul tabelului, n care se nscriu numele atributelor relaiei, fiecare atribut fiind
nscris n coloana corespunzatoare.
O mulime de linii, fiecare linie corespunznd unui tuplu (deci unei entiti); n fiecare
element al unei linii se nregistreaz valoarea atributului corespunzator coloanei n
care se afl elementul respectiv.
Dei n numeroase documentaii se folosete termenul de tabel pentru a desemna
relaia pe care o reprezint, cele doua noiuni nu sunt identice: relaia este o noiune abstract
(o mulime n sens matematic), n timp ce tabelul este o reprezentare a relaiei.
Sistemele de baze de date relaionale utilizeaz ca limbaj de programare limbajul SQL
(Structured Query Language), pentru care au fost propuse mai multe standarde de ctre
Organizaia International de Standardizare (International Standardization Office - ISO).
Majoritatea sistemelor de gestiune a bazelor de date relaionale actuale implementeaz
versiunea din anul 1992 a standardului pentru limbajul SQL, denumit SQL92 (sau SQL2).
2) Constrngerile de integritate a datelor
Relaiile unei baze de date reflect realitatea modelat i de aceea valorile pe care le
conin trebuie s respecte anumite reguli, care s corespund celor din realitate.
Constrngerile de integritate (integrity constraints) sunt reguli care se definesc la
proiectarea unei bazei de date i care trebuie s fie respectate de orice stare a acesteia.
Din punct de vedere al locului unde sunt definite, constrngerile pot fi constrngeri
intra-relaie i constrngeri inter-relaii. Constrngerile intra-relaie sunt reguli care se impun
n cadrul unei singure relaii i asigur integritatea datelor acesteia. Ele sunt, la rndul lor, de
trei categorii: constrngeri de domeniu, constrngeri de tuplu i constrngeri impuse prin
dependene de date (dependene funcionale, multivalorice sau de jonciune).
Constrngerile inter-relaii sunt reguli care se impun ntre dou sau mai multe relaii.
Cele mai importante constrngeri inter-relaii sunt constrngerile de integritarea referenial,
care se realizeaz prin intermediul cheilor strine i asigur asocierea corect a relaiilor.
Din punct de vedere al modului de definire, constrngerile unei baze date pot fi
inerente, implicite i explicite.
Constrngerile inerente sunt cele ale modelului de date nsui, care nu trebuie s fie
specificate la definirea relaiilor, dar sunt respectate prin modul n care se construiesc relaiile.
Constrngerile implicite sunt cele reprezentate n mod implicit n schemele relaiilor
prin intermediul instruciunilor de definire a datelor. Pentru fiecare model de date exist un set
de constrngeri implicite care se definesc odat cu definirea schemelor de date ale acestuia.
Pentru modelul relaional, constrngerile de domeniu, constrngerile de tuplu i constrngerile
de integritate referential sunt exemple de constrngeri implicite. Constrngerile implicite
sunt memorate n baza de date i sistemul de gestiune impune automat respectarea acestora.
Constrngerile explicite sunt constrngeri suplimentare pe care trebuie s le respecte
relaiile unei baze de date i care nu sunt impuse automat de sistemul SGBD, ci prin proceduri
special proiectate sau triggere. Ca exemplu de constrngeri explicite avem unele dependene
ntre date.
Constrngerile de domeniu sunt condiii impuse valorilor atributelor, astfel nct
acestea s corespund semnificaiei pe care o au n realitatea modelat. Dat fiind c, n
reprezentarea unei relaii printr-un tabel, valorile atributelor sunt reprezentate de coloane,
constrngerile de domeniu se mai numesc i constrngeri de coloan. Dintre constrngerile de
domeniu, constrngerea NOT NULL i constrngerea de valoare implicita (DEFAULT) sunt
constrngeri cu caracter mai general, care se pot aplica oricrui atribut; constrngerea de
verificare (CHECK) se poate aplica unor anumite atribute, n funcie de semnificaia acestora.
Constrngerile de tuplu: cheia primar i chei secundare. O relaie este definit ca
o multime de tupluri, deci tuplurile unei relaii trebuie s fie distincte. Aceasta nseamn c
ntr-o relaie nu pot exista dou (sau mai multe) tupluri care s conin aceeai combinaie de
6

valori ale tuturor atributelor. De obicei, ntr-o schem de relaie exist o submulime de
atribute SK cu proprietatea c, n orice stare s-ar afla relaia, nu exist dou tupluri distincte
ale relaiei care s aib aceeai combinaie de valori ale atributelor submulimii respective.
O supercheie (superkey) a unei relaii este o submulime (SK) de atribute ale relaiei
care prezint proprietatea de unicitate, adic orice combinaie de valori ale atributelor
supercheii este unic pentru orice stare a relaiei.
Acest lucru nseamn c, dac se cunoate combinaia de valori ale atributelor
supercheii (valoarea supercheii), atunci acel tuplu poate fi identificat n mod unic. Orice
relaie are cel puin o supercheie: multimea tuturor atributelor sale. Un concept mai util n
dezvoltarea bazelor de date l reprezinta conceptul de cheie candidat (sau, mai simplu,
cheie).
O cheie candidat (candidate key) este o supercheie ireductibil (minimal).
Conform definiiei de mai sus, o cheie candidat CK trebuie s prezinte proprietatea
de unicitate (nu exist dou tupluri diferite ale relaiei care s conin aceeai combinaie de
valori ale atributelor cheii CK) i proprietatea de ireductibilitate (nu exist nici o submulime
proprie, nevid a cheii CK care s aib proprietatea de unicitate).
O cheie candidat poate s fie simpl (alcatuit dintr-un singur atribut), sau compus
(alcatuit din mai multe atribute).
Atunci cnd exist mai multe chei candidate, una dintre ele se alege ca i cheie
primar, celelalte chei candidate fiind numite chei secundare, alternative sau unice.
O cheie primar (primary key) este o cheie candidat creia proiectantul i confer un
rol special de accesare i identificare a tuplurilor relaiei. n plus, se impune ca atributele
cheii primare s nu admit valori de NULL i s nu fie modificate prin operaii de actualizare
a datelor.
O cheie secundar (alternativ, unic) (secondary, alternate, unique key) este o cheie
candidat care nu a fost desemnat de proiectant ca i cheie primar.
Cheile secundare admit valori NULL pentru unele din atributele lor dac se respect
condiia de unicitate a valorilor.
O cheie primar compus din atributele existente ale tipului de entitate se numete
cheie natural. n general, cheile naturale sunt compuse din mai multe atribute (ceea ce
produce scderea eficienei operaiilor relaionale) i de cele mai multe ori se folosesc chei
artificiale . O cheie primar artificial este un atribut care se adaug n schema relaiei pentru
identificarea unic a tuplurilor. De exemplu, n relaia ANGAJATI se adaug atributul
IdAngajat, ca numr de identificare al fiecrui angajat al instituiei:
ANGAJATI(IdAngajat, Nume, Prenume, DataNasterii, Adresa, Salariu)
Acest atribut este o cheie artificiala a relaiei i poate identifica n mod unic un tuplu,
deoarece (prin convenie) nu se atribuie acelai numr de identificare la mai mult de un
angajat.
Constrngeri ntre relaii: cheia strain. O cheie strain (foreign key) este o
mulime de atribute FK ale unei relaiei R1 care refer relaia R2 i satisface urmtoarele
condiii:
(a) atributele cheii strine FK sunt definite pe domenii compatibile cu cele ale
atributelor unei cheii candidate CK a relaiei R2 i
(b) combinaia de valori ale atributelor FK ntr-un tuplu din relaia R1, fie este
identic cu combinaia de valori ale atributelor CK a unui tuplu oarecare din starea curent
a relaiei R2, fie ia valoarea NULL. Cheia strain realizeaz asocierea N:1 ntre relaiile R1 i
R2 (ceea ce este echivalent cu asocierea 1:N ntre relaiile R2 i R1) i reprezint o
constrngere ntre dou relaii, numit constrngere referenial . Relaia care conine cheia
strain se numeste relaia care refer (R1 n definiia de mai sus), iar relaia care conine
cheia candidat se numete relaia referit (R2 n definiia de mai sus).
7

Integritatea referenial (referential integrity) este proprietatea bazei de date care
garanteaz c oricare valoare a unei chei strine se regsete printre valorile cheii candidate
corespunztoare din relaia referit, sau cheia strain are valoarea NULL (daca atributele
acesteia nu sunt supuse constrngerii NOT NULL).
Majoritatea sistemelor SGBD implementeaz constrngerea de meninere a integritii
refereniale n mod implicit, refuznd modificri ale datelor (introducere, tergere, actualizare)
care ar putea viola integritatea referenial. Dac sistemul nu asigur aceast funcionalitate,
ea trebuie implementat n programele de aplicaii (de regul prin intermediul triggerelor).
Un index al unei relaii (index) este o structur auxiliar memorat n baza de date
care permite accesul rapid la nregistrrile (tuplurile) relaiilor prin ordonarea acestora.
La definirea unei relaii se stabilesc doua categorii de indeci: indexul primar al
relaiei, care determin localizarea tuplurilor n fiierele bazei de date, i zero, unul sau mai
multe indexuri secundare, care nu modific localizarea tuplurilor, dar sunt folosite pentru
ordonarea i regsirea tuplurilor dup un criteriu dat. Indexul primar (primary index) se
definete pe unul sau mai multe atribute ale relaiei i reprezint cheia (eticheta) dup care
ordoneaz tuplurile relaiei, folosind structuri de ordonare (arbori, tabele de dispersie, etc.).
Indexul primar determin adresa de memorare a nregistrarilor (tuplurilor) n fiierele bazei de
date. Un index secundar pe un atribut A al unei relatii (secondary index) este o structu care
conine o mulime de perechi (v,L) ordonate dup v; fiecare pereche corespunde unui tuplu al
relaiei, v este valoarea atributului A, iar L este adresa tuplului respectiv n structura indexului
primar al relaiei.
Fiecare SGBD prevede anumite modaliti de reprezentare i de creare a indecilor i
de aceea aceast parte a proiectarii unei baze de date depinde de sistemul folosit.
3) Securitatea i protecia bazelor de date
O descriere complet a problemelor de securitate n cadrul sistemelor de calcul i a
bazelor de date este n afara scopului acestui capitol. ns, exist cteva aspecte fundamentale
privind protecia i securitatea bazelor de date care trebuie s fie cunoscute de orice proiectant
sau programator de baze de date i acestea vor fi prezentate pe scurt n continuare.
Cu problemele de protecie i securitate este responsabil administratorul bazei de date,
care are un cont privilegiat n sistemul de gestiune (numit n general cont de sistem -system
account) care prevede capabiliti foarte puternice, pe care alte conturi sau utilizatori nu le au.
Prin intermediul contului de sistem administratorul bazei de date poate efectua mai multe
operaii: crearea conturilor, acordarea sau retragerea privilegiilor, etc.
Orice persoan care dorete s se conecteze (log in) la o baz de date trebuie s dein
un cont (account user) i o parol (password). Sistemul de gestiune verific contul i parola i
autentific acel utilizator, dac acestea sunt corecte. Programele de aplicaii sunt considerate
de asemenea utilizatori i se conecteaz pe un anumit cont, trebuind s furnizeze parola
acestuia.
Conectarea unui utilizator al unei baze de date (printr-un cont i o parol) nu este
suficient pentru ca acel utilizator s beneficieze de toate funcionalitile oferite de SGBD, ci
el poate beneficia numai de acelea pentru care a primit drepturi (autorizri). n cele mai multe
sisteme SGBD exist dou niveluri de autorizare: nivelul contului i nivelul relaiilor; fiecrei
relaii i se asigneaz un cont proprietar (owner account), care este, n general, contul care a
fost folosit atunci cnd a fost creat relaia respectiv.
n limbajul SQL2 sunt prevzute instruciuni de acordare (GRANT) i de revocare
(REVOKE) a drepturilor de acces ale utilizatorilor (conturi) la diferite obiecte ale bazei de
date. Cteva exemple de astfel de instruciuni vor fi date n seciunile urmtoare.n plus, n
sistemele SGBD performante, pot exista numeroase alte posibiliti de organizare a
drepturilor utilizatorilor (grupuri, roluri, etc.). Controlul acestor drepturi face parte din
8

activitatea de administrare a bazei de date, care reprezint n sine un domeniu foarte vast, n
care activeaz numeroi specialiti (administratori de baze de date).

1.2. Instalarea i pornirea SGBD
Dintre sistemele de gestiune a bazelor de date relaionale existente la ora actual, vom
studia Microsoft SQL Server, in laborator fiind instalat varianta Microsoft SQL Server
2008.

1.2.1 Sistemul de gestiune SQL Server
O versiune de test a sistemului SQL Server se poate obine de la firma Microsoft
(www.microsoft.com) i poate fi instalat sub sistemele de operare Windows (NT/2000/XP)
i utilizat pentru a testa diferitele aspecte de lucru cu bazele de date relaionale.
Un server SQL gestioneaz mai multe baze de date, care pot fi accesate partajat de mai
muli utilizatori aflai n reea.
Instalarea serverului SQL Server 2000 (Server and Client Tools) se face pe o singur
staie din reea, iar pe celelalte staii se instaleaz programele client. La instalare trebuie sa fie
selectat modul de autentificare Mixed (Windows and SQL Server).
Trebuie reinut faptul c dup instalarea serverului SQL Server 2000 trebuie verificat
vulnerabilitatea la virusul SQL Worm (folosind, de exemplu, programul FixSQLex de la
Symantec). Eliminarea acestei vulnerabiliti (dac exist) se face fie instalnd SQL Server
Service Pack 3, fie instalnd un pachet de actualizare de la Microsoft (SQL_MSDE_
CriticalUpdate_ENU.msi). Dac la o nou rulare a programului FixSQLex nc se mai
raporteaz vulnerabilitate, aceasta este cel mai probabil provocat de faptul c biblioteca
vulnerabil (ssnetlib.dll) a fost salvat (n directorul.. \SQL
Server\80\Tools\Binn\backup\data_corectiei\) nainte de a fi nlocuit cu o versiune sigur n
cursul instalrii pachetelor de actualizare. Se poate terge acest fiier i se testeaz din nou
vulnerabilitatea.
Dupa instalarea serverului SQL Server, utilizatorul are la dispoziie mai multe
faciliti de creare, administrare i lucru cu bazele de date, precum i cteva exemple de baze
de date preinstalate (pubs, Northwind), care pot fi folosite pentru studiu.
Pornirea i oprirea serverului se fac folosind programul Service Manager (selectnd
Start ->Programs->Microsoft SQL Server 2000->Service Manager), care permite selectarea
unui server din reea (dac sunt mai multe servere instalate), oprirea serverului, introducerea
unei pauze de funcionare, sau continuarea funcionrii dup o pauz.
Exist mai multe programe utilitare (instrumente) care permit administrarea sistemului
i executarea diferitelor operaii: crearea unor noi baze de date, crearea tabelelor i a altor
obiecte (triggere, indeci, vederi, proceduri stocate), crearea utilizatorilor, salvarea i
refacerea bazelor de date, etc. Dintre aceste programe, unele pot fi executate la nivel de linie
de comanda (osql, isql), iar altele prezint interfa grafic i sunt mai uor de folosit (SQL
Server Enterprise Manager, SQL Query Analizer).
a) Utilizarea programului Enterprise Manager
Programul utilitar Enterprise Manager se lanseaz selectnd Start->Programs-
>Microsoft SQL Server->Enterprise Manager. Acest program este foarte puternic i permite
att administrarea sistemului (crearea utilizatorilor, refacerea bazelor de date, etc.) ct i
proiectarea bazelor de date (crearea bazelor de date i a tabelelor, asocierea ntre tabele, etc.).
n continuare vor fi prezentate numai noiunile strict necesare pentru a ncepe lucrul cu SQL
Server, restul informaiilor fiind destul de uor de gsit n manualul Books Online al
sistemului SQL Server.
9

Lansarea programului Enterprise Manager se poate face att de pe staia pe care a fost
instalat serverul, ct i de pe orice staie pe care s-a instalat un client.
Pentru staia serverului se poate nregistra serverul local (al crui nume este, de regul,
numele calculatorului pe care este instalat, de exemplu PC30_ServerBD) pentru contul (login)
de administrare (sa), creat implicit la instalare. Acest cont are toate drepturile, att la nivelul
sistemului (adminstrare, securitate, etc) ct i la nivelul fiecrei baze de date. De regul, noii
utilizatori se creeaz utiliznd contul sa i acestora li se acord mai puine drepturi, attea cte
sunt necesare pentru ca s realizeze sarcinile dorite, far s afecteze administrarea sistemului
de gestiune, care trebuie s ramn numai n atribuiile administratorului (contul sa).
n panoul din stnga al ferestrei Enterprise Manager, elementul Console Root
reprezint rdcina unui arbore care conine n primul nivel toate instalrile SQL Server
disponibile n reeaua respectiv, organizate n mai multe grupuri de servere. Iniial n grupul
implicit SQL Server Group nu exist nici un server nregistrat i nregistrarea se face cu
comanda New SQL Server Registration selectat din meniul de context care se deschide la
apsarea butonului dreapta al mouse-ului, atunci cnd este selectat directorul SQL Server
Group.
Dup nregistrare, se poate rula Enterprise Manager cu conectare pe contul sa n mod
de autentificare Windows. n acest mod este bine sa fie stabilit (sau modificat) parola
contului sa i s fie editat nregistrarea serverului cu comanda Edit SQL Server Registratuion
Properties din meniul de context care se deschide la apsarea butonului dreapta al mouse-
ului, atunci cnd este selectat numele instanei serverului . n fereastra care se deschide (cu
titlul Registered SQL Server Properies) se selecteaz opiunile Use SQL Server
Authentication i Always prompt for login name and password.
Din contul sa se creeaz conturile de conectare login cu comanda New Login din
meniul de context care se deschide la apsarea butonului dreapta al mouse-ului, aunci cnd
este selectat subdirectorul Logins din directorul Security . n laborator aceste conturi sunt
denumite user1, user2, ..etc. Pe orice staie pe care este instalat un client SQL, se poate lansa
programul Enterprise Manager, i prima operaie care trebuie s fie facut este nregistrarea
serverul dorit din reea. n cursul nregistrrii (cu comanda New SQL Server Registration din
meniul de context) se aleg opiunile SQL Server Authentication i Always prompt for login
name and password. Dupa aceasta se poate face conectarea pe contul propriu (login) i parola
acestuia, cont care trebuie s fi fost creeat mai nainte pe server.
Fereastra principal a programului SQL Server Enterprise Manager conine un meniu,
o bar de instrumente i dou panouri. n panoul din stnga se afiseaz numele serverului,
mpreuna cu apte subdirectoare ale acestuia, iar n panoul din dreapta al ferestrei sunt
prezentate informaii privind directorul selectat. Dintre directoarele afiate, cele mai utile sunt
directorul Databases, care conine bazele de date gestionate de serverul respectiv, i directorul
Security , care permite administrarea utilizatorilor i a drepturilor de acces la bazele de date.
n directorul Databases se afl mai multe directoare care conin bazele de date ale
sistemului (care reprezint catalogul sistemului de gestiune: Master, Model, Msdb), bazele de
date preinstalate ca exemple (Northwind, pubs) i toate bazele de date create de utilizatori.
n fiecare baz de date sunt memorate mai multe categorii de obiecte: diagrame
(Diagrams), tabele (Tables), vederi (Views), proceduri stocate (Stored Procedures),
utilizatorii care au acces la baza de date reaspectiv (Users), roluri (grupri de privilegii)
(Roles) i altele.
Din fiecare categorie de obiecte se poate selecta unul dintre acestea pentru a fi accesat,
editat sau executat (n functie de obiect i de drepturile utilizatorului) i se pot crea obiecte noi
cu comanda New, care se poate aciona din bara de instrumente sau dintr-un meniu de context
(care se obine prin apsarea butonului dreapta al mouse-ului, atunci cnd este selectat un
obiect din acea categorie).
10

n directorul Security se pot inspecta i modifica conturile de conectare (logins) i
rolurile definite pentru serverul SQL la care s-a realizat conexiunea.
Lista tuturor conturilor de conectare existente (logins) se afieaza n panoul din
dreapta, atunci cnd se selecteaz opiunea Logins n arborele de selecie i pentru fiecare cont
se poate selecta o opiune din cele existente n meniul contextual. La opiunea Properties se
pot inspecta i modifica diferite proprieti ale contului respectiv (parola, baza de date
implicit la deschidere, rolul contului n sistemul SQL server,etc.). Fiecrui cont de conectare
i se pot atribui unul sau mai multe roluri n sistemul de gestiune: System Administrators, care
permite orice operaie n sistemul SQL Server, Security Administrators, care permite
administrarea utilizatorilor, Database Creators, care permite crearea de noi baze de date, etc.
Pentru ca un cont de conectare s poat accesa o baz de date, trebuie s i se acorde
drepturi asupra acelei baze de date (de ex., prin rolul public , db_owner, etc.). Atunci cnd se
acord drepturile, se creaz un utilizator (user) al acelei baze de date corespunzator contului
de login i acestui utilizator i se dau drepturi.
Contul de conectare sa (System Administrator) are o comportare special. El este creat
automat la instalarea serverului SQL cu rolul de adminstrator de sistem i primete drepturi de
acces la orice baz de date existent sau nou creat, atribuindu-i-se rolul public i rolul de
proprietar (dbo_owner) al bazei de date.
Pentru fiecare baz de date sistemul creeaz automat un tip de utilizator special (dbo)
care are drepturi de proprietate asupra bazei de date respective. Acest utilizator este atribuit
contului de conectare n momentul crerii bazei de date, precum i oricrui utilizator al bazei
de date corespunztor unui cont de conectare cu rol de System Administrators.
Pentru lucrul n siguran cu SQL server se recomand crearea unor conturi care s
aib toate drepturile asupra bazelor de date proprii, i numai drepturi de citire (prin rolul
public) asupra bazelor de date preinstalate.
Dupa conectarea unui utilizator cu rolul Database Creators, acesta poate s creeze una
sau mai multe baze de date asupra crora are drept de proprietar (dbo).
Conectarea pe un cont care nu are drepturi de administrare ofer drepturi limitate de
acces la obiectele bazei de date. Utilizaorul poate s deschid fereastra de proprieti ale
contului propriu (cu comanda Properties din meniul de context) i poate s modifice baza de
date implicit. De asemenea, se pot vedea tabelele, funciile, etc, ale bazei de date Northwind,
la care are accees, dar nu le poate modifica. n baza de date proprie utilizatorul are toate
drepturile (creare, modifcare i tergere tabele, creare proceduri, etc.). Dup crearea bazei de
date proprii, este recomandabil s se setezee aceast baz de date ca baz de date implicit a
contului respectiv (prin comanda Properties n meniul de contex al contului). De asemenea, se
poate anula (din contul sa) rolul Database Creators al contului.
n general, atunci cnd se modific elementele unui director (Databases, Logins, etc),
ele vor fi actualizate n panoul din Enterprise Manager numai dac se d comanda Refresh
(din meniul de context corespunzator).
Pentru acomodarea cu sistemul SQL Server se selecteaz baza de date preinstalat
Northwind i se inspecteaz tabelul Employees (prin comanda dublu clic, atunci cnd este
selectat tabelul respectiv sau prin selectarea optiunii Properties din meniul de context). La
aceast comand se deschide o ferestr n care pentru fiecare atribut al relaiei (tabelului) sunt
afiate numele, tipul de date, valoarea implicit, marcajul de cheie primar, etc. (Fig. 1.1).
Un tabel se poate deschide i n alte moduri: modul de proiectare (prin selecia opiunii
Design Table din meniul de context) sau modul Open care afieaz coninutul tabelului, dac
utilizatorul are drepturi suficinte.
n Enterprise Manager proiectarea tabelelor, ca i a altor obiecte ale bazei de date, se
poate realiza vizual, cele mai multe valori putnd fi introduse prin selectarea unei opiuni din
11

valorile valide oferite pentru fiecare tip de introducere, ceea ce face ca proiectarea s fie
deosebit de uoar.
b) Utilizarea programului OSQL
Utilitarul osql permite conectarea la serverul SQL pentru executarea instruciunilor
Transact-SQL (extensia procedural a limbajului SQL pentru sistemul SQL Server), a
fiierelor de scripturi (fiiere care conin comenzi n limbajul Transact-SQL) i a procedurilor
stocate. Sintaxa simplificat de lansare a utilitarului osql pentru conectarea utilizatorului
user1 cu parola parola1 la baza de date nume_baza_date este:
osql U user1 d nume_baza_de_date P parola1
Dac nu se specific numele bazei de date, atunci are loc conectarea la baza de date
implicit a contului respectiv. Dup conectare, programul afiseaz ca prompt de comand
numrul liniei de comand (n ordine cresctoare ncepnd cu 1) i se pot transmite spre
execuie loturi de execuie Transact SQL (succesiune de instruciuni terminate cu comanda
GO) care pot accesa baza de date respectiv. Baza de date curent se poate schimba cu
comanda: USE noua_baza_date. Execuia unui fiier script care conine unul sau mai multe
loturi Transact SQL se realizeaz cu comanda:
osql U user i nume_fisier P parola




Figura 1.1 Structura unei tabele

c) Utilizarea programului SQL Server Query Analyzer
Programul utilitar SQL Server Query Analyzer este un instrument grafic care permite
executarea mai multor activiti de proiectare a bazelor de date i de execuie a aplicaiilor,
12

cum sunt: crearea i executarea interogrilor, testarea procedurilor stocate, operaii de
introducere, tergere sau modificare a datelor n tabele, etc.
Programul SQL Server Query Analyzer se poate lansa din sistemul de operare cu
comenzile Start->Programs->Microsoft SQL Server->Query Analyzer, sau din Enterprise
Manager cu comenzile Tools ->SQL Query Analyzer. La conectare trebuie s se specifice
serverul, contul i parola de conectare. n fereastra programului Query Analyzer sunt afiate o
bar de meniu, o bar de instrumente i dou panouri (Fig. 1.2).
n panoul din stnga sunt afiate obiectele serverului la care este conectat programul,
grupate n dou directoare. Primul director are numele instanei serverului SQL i este
rdcina subdirectoarelor corespunzatoare bazelor de date administrate de server. Cel de-al
doilea director are numele Common Objects i este rdcina mai multor subdirectoare
(Configuration Functions, Cursor Functions, etc.).



Figura 1.2 Fereastra Query Analyzer

n panoul din dreapta este afiat o fereastr pentru interogari (Query) i pentru
execuia unor operaii asupra bazei de date selectate n bara de instrumente (n figura de mai
sus s-a selectat baza de date Northwind). Rezultatul execuiei este afiat n partea de jos a
panoului n dou pagini selectabile, o gril de date (Grids) i o list de mesaje privind modul
de executie a interogarii (Messages).
Comenzile din fereastra Query sunt instruciuni SQL (sau Transact-SQL) care se pot
introduce fie manual (de la tastatur), fie prin citirea (deschiderea) unui fiier de script (cu
comanda File>Open). Lansarea n execuie a comenzilor din ferestra Query se realizeaz cu
comanda Execute, care se poate lansa fie din meniul de context al ferestrei, fie din meniul
Query.

1.3 Arhitectura Microsoft SQL Server
Sistemul de gestiune a bazelor de date, Microsoft SQL Server, ajuns la versiunea a 10
a (SQL Server 2008), este un sistem din clasa Enterprise, oferind din punct de vedere
tehnologic caracteristici i performane care permit dezvoltarea unor aplicaii la scar mare,
extensibile i performante.
13

Dezvoltarea aplicaiilor de baze de date necesit limbaje de programare ct mai flexibile care
s permit utilizatorului implementarea unui set ct mai mare de funcii i de algoritmi de
programare. n acest sens, limbajul SQL este un mediu performant prin intermediul cruia pot
fi manipulate obiectele i nregistrrile din baza de date. Totui SQL prezint un oarecare
dezavantaj care const n esena neprocedural a acestuia. SQL nu include instruciuni
condiionale (IF) sau instruciuni prin intermediul crora pot fi repetate anumite seciuni de
cod (While).
SQL Server reprezint un fragment dintr-un miez al unei familii de produse integrate care
include dezvoltarea de unelte de management al sistemelor, componente distribuite de sistem
i dezvoltarea deschis de interfee.



Figura 1.3 Uneltele i structura SQL Server

SQL (Structured Query Language limbaj de interogare structurat) este utilizat n
comunicarea cu baza de date. Potrivit ANSI (American National Standards Institute) SQL este
limbajul standard pentru sistemele de management al bazelor de date relaionale. Propoziiile
SQL sunt utilizate pentru a efectua actualizri ale datelor sau retrageri de date dintr-o baz de
date. Cteva dintre sistemele de management al bazelor de date relaionale pe care SQL le
utilizeaz sunt: Oracle, Sybase, Microsoft SQL Server, Access, Ingres, etc. Dei aproape toate
sistemele de baze de date folosesc SQL, unele dintre ele au proprile extensii, care se folosesc
de obicei doar in sistemul lor. Cu toate acestea, comenzile SQL standard ca: \"Select\",
\"Insert\", \"Update\", \"Delete\", \"Create\" i \"Drop\" sunt suficiente pentru a lucra cu baza
de date.
14

Un sistem de baze de date relaionale conine unul sau mai multe obiecte (componente logice)
numite tabele, care stocheaz datele sau informaile bazei de date. Tabelele sunt identificate
unic prin numele lor i conin linii i coloane. Coloanele conin numele coloanelor, tipul de
date i oricare alte atribute pentru coloane. Liniile conin nregistrrile sau datele pentru
coloane.
Implementarea fizic a fiierelor este transparent. n mod normal, doar administratorul bazei
de date lucreaz cu implementarea fizic.
Fiecare instan a SQL Server deine patru baze de date sistem:
Master
Model
Tempdb
Msdb
i una sau mai multe baze de date utilizator. Unele organizaii au doar o baz de date utilizator
care conine toate datele; altele au baze de date diferite pentru fiecare grup din organizaie, iar
uneori o baz de date este utilizat doar de o singur aplicaie.
Nu este necesar rularea mai multor copii a motorului bazei de date pentru a permite mai
multor utilizatori s acceseze baza de date pe un server. O instan a versiunii SQL Server
Standard sau Enterprise Edition poate face fa miilor de utilizatori care lucreaz n baze de
date multiple simultan. Fiecare instan a SQL Server face disponibile toate bazele de date din
instan tuturor utilizatorilor care se conecteaz la instan, n conformitate cu permisiunile de
securitate definite.
La conectarea la o instan SQL Server, conexiunea este asociat unei anumite baze de date
de pe server. Aceast baz de date se numete baz de date curent. De obicei, conexiunea se
face la baza de date definit ca implicit de ctre administratorul de sistem, dar se poate
specifica o alt baz de date la opiunile conexiunii. Trecerea de la o baz de date la alta se
poate face prin statement-ul Transact-SQL USE database_name sau printr-o funcie API care
modific contextul curent al bazei de date.
SQL Server permite detaarea bazelor de date de la o instan SQL Server i reataarea lor la
alt instan, sau chiar la aceeai instan. Dac avem un fiier de baz de date SQL Server,
putem specifica la conectare s se ataeze acel fiier la un anumit nume de baz de date.

1.3.1 Arhitectura administrativ SQL Server
Fiecare nou versiune Microsoft SQL Server incearc s automatizeze sau s elimine
repetiia n lucrul cu bazele de date. Datorit faptului c administratorii bazelor de date sunt
unii dintre cei mai bine antrenai n problemele de baze de date, aceste mbuntiri permit un
timp de lucru mai mare acordat proiectrii bazei de date i problemelor de accesare a
aplicaiilor de date.
Caracteristici:
SQL Server reduce munca administrativ n multe domenii prin achiziionarea i eliberarea
dinamic a resurselor. Serverul achiziioneaz dinamic resursele cum ar fi: memoria i spaiul
de pe disc ori de cte ori este nevoie i elibereaz resursele cnd nu mai sunt necesare. Dei
marile sisteme OLTP cu performane critice sunt nc monitorizate de administratori
competeni, SQL Server poate fi utilizat i la implementarea bazelor de date desktop sau
workgroup mici care nu necesit atenie permanent din partea administratorului.
SQL Server ofer un set de unelte grafice care permit administratorilor s efectueze sarcini
administrative simplu i eficient.
SQL Server ofer un set de servicii care permit administratorilor s programeze execuia
automat a sarcinilor repetitive.
Administratorii SQL Server pot programa serverul astfel nct acesta s trateze condiiile de
excepie sau cel puin s trimit e-mail sau sms administratorului de serviciu.
15

SQL Server public aceeai interfa API (Application Programming Interfaces) care
suport toate sarcinile administrative ale SQL Server.

1.3.2 Suport pentru dezvoltarea data tier-ului
Pentru nivelul de date, avem nevoie de metode de interogare i modificare ntr-un regim
tranzacional care s ofere protecie la erori i verificarea permanent a integritii datelor.
n general, accesul la datele dintr-o baz de date se face prin limbajul de manipulare a datelor
(LMD). n cadrul SQL Server se folosete limbajul SQL.
Nivelul de acces la date va accesa baza de date printr-o interfa oferit de un set de proceduri
stocate. Accesul prin proceduri stocate i nu prin cod SQL generat de nivelul de acces la date
ofer siguran i control asupra structurii de date. Avnd n vedere c sarcina de a scrie
procedurile stocate revine administratorului bazei de date, controlul asupra operaiilor
permise, a modului de realizare a lor i ndeplinirea condiiilor de integritate se pstreaz n
mediul dezvoltatorilor bazei de date, adic cei ce construiesc, modific i ntrein acea
structur. Dei distribuia e o paradigm modern i la mod, n acest caz, luarea deciziei de a
menine controlul centralizat asupra mijloacelor de acces la baza de date ofer o siguran
sporit a bazei de date n sine i a datelor coninute de ea.
Baza de date suport a sistemului informatic universitar este o baz de date integrat, cu o
structur puternic normalizat i care trebuie s permit acces permanent i rapid tuturor
departamentelor i structurilor universitare. Datele coninute trebuie bine structurate pentru a
modela ntregul proces i flux de informaii i date ale universitaii i trebuie bine protejate,
avnd o valoare incontestabil. Din aceste motive, accesul la baza de date se va face numai
prin intermediul procedurilor stocate, proiectate, scrise i verificate de ctre administratorul
bazei de date. Pentru a realiza acestea, sistemul Microsoft SQL Server ofer posibilitatea de a
crea i rula proceduri stocate, buci de cod SQL, care pot conine interogri sau operaii de
modificare i tergere, ele fiind parametrizabile i putnd ntoarce rezultate programului
apelant. O caracteristic foarte important a sistemului este oferirea unui mediu tranzacional
sigur, acesta fiind indispensabil pentru ndeplinirea cu succes a unor operaii complexe asupra
datelor.

1.3.3 Setul de comenzi SQL
Operaia fundamental n SQL este maparea reprezentat din punct de vedere sintactic
printr-o construcie SELECT-FROM-WHERE. Aceast construcie corespunde unei
succesiuni de operatori algebrici de forma selecie-proiecie-cuplare, foarte frecvent n
algebra relaional.
Clauza SELECT realizeaz operaie de proiecie i este urmat de lista atributelor care se rein
n relaia rezultat. Proiecia SQL difer de operatorul de proiecie din algebra relaional prin
faptul c nu elimin tuplurile duplicat. Eliminarea tuplurilor duplicat se face de ctre
utilizator, atunci cnd se dorete, prin folosirea operatorului DISTINCT.
Operaia de cuplare poate fi realizat prin clauza FROM, atunci cnd este urmat de o list
format din cel puin dou nume de relaie, mpreun cu condiia de cuplare formulat n
cazul predicatului din clauza WHERE.
1. Selecia
Selecia este realizat prin clauza WHERE, care, de obicei, este urmat de un predicat
referitor la atributele relaiilor folosite n clauza FROM. Expresia care urmeaz aceast clauz
poate conine comparaii de atribute i/sau expresii aritmetice, operatori logici (AND, OR,
NOT), operatori pe mulimi (UNION, INTERSECT, MINUS) i operatori de apartenen la
mulimi cu negrile acestora (X IN S, X NOT IN S, S CONTAINS X, S DOES NOT
CONTAIN X, unde S este o relaie, iar X este un tuplu sau o relaie, caz n care este vorba de
incluziune ntre mulimi). Expresia care urmeaz clauzei WHERE poate s conin operanzi
16

care sunt relaii rezultate din alte construcii SELECT, asigurndu-se astfel posibilitatea
imbricrii acestora n interogri complexe.
Sintaxa complet a instruciunii SELECT:
SELECT [DISTINCT] nume_atribut1
FROM nume_relaie[variabila_de_tuplu]
[WHERE condiie_de_cutare]
[GROUP BY expresie_de_grupare]
[HAVING conditie_de_selecie_grup]
[ORDER BY expresie_de_ordonare[ASC|DESC]]
n SQL Server se poate folosi operatorul UNION pentru a reuni rezultatele mai multor fraze
SELECT ntr-o singur relaie rezultat.
Sintaxa:
{}
UNION[ALL]

UNION[ALL]

[n]]

2. Operaii de tergere, inserare i actualizare
Operatorii de tergere, inserare i actualizare acioneaz la un moment dat doar asupra
unei singure relaii.
Operatorul SQL pentru efectuarea operaiilor de tergere este DELETE FROM a crui sintax
complet este:
DELETE
[FROM]
{ nume_tabel |nume_vedere}
[WHERE{condiie_cutare>
|{[CURRENT OF
{{[GLOBAL] nume_cursor} |nume_variabil_cursor}
]}
}
]
Exist dou forme de operaii de tergere:
tergere cu cutare se specific o condiie de cutare pentru tuplurile de ters
tergere poziionat se folosete clauza CURRENT OF pentru a specifica un cursor, iar
tergerea se refer la tuplul aflat la poziia curent a cursorului. Acest mod de tergere permite
eliminarea dintr-o tabel doar a unuia dintre mai multe tupluri identice.
Operatorul SQL pentru inserare este INSERT INTO i prezint dou variante:
Inserare simpl, pentru inserarea unui tuplu individual
Inserare multipl, pentru inserarea mai multor tupluri
Comanda pentru inserare simpl are sintaxa:
INSERT INTO nume_relaie(nume_atribut...)
VALUES(valoare)
ntre valori i numele de atribute trebuie s existe o coresponden unu la unu.
Comanda pentru inserare multipl are sintaxa:
INSERT INTO nume_relaie(nume_atribut...)
Construcie_SELECT
Operatorul SQL pentru actualizarea tuplurilor este UPDATE i are sintaxa:
UPDATE {nume_tabel|nume_vedere}
17

SET
{nume_coloan={expresie|DEFAULT|NULL}
|@variabil=expresie
|@variabil=coloan=expresie}[,...n]
[FROM{}[,n]]
[WHERE{
|{[CURRENT OF
{{[GLOBAL]nume_cursor}|nume_variabil_cursor}
]}
}
]
Operatorul de actualizare ndeplinete dou funcii:
Selecteaz prin condiia de cutare din clauza WHERE tuplurile care urmeaz a fi
actualizate (n lipsa clauzei, se actualizeaz implicit toate tuplurile relaiei specificate).
n tuplurile selectate modific valorile atributelor specificate. Expresiile de actualizare pot
conine: constante, nume de atribute, valoarea NULL sau expresii aritmetice construite cu
acestea. n SQL este permis chiar i actualizarea atributelor care fac parte dintr-o cheie
primar.
3. Begin transaction, rollback transaction i commit transaction
Aceste comenzi permit gruparea unor instruciuni SQL ntr-un bloc de tipul totul sau
nimic. Sistemul SQL Server implementeaz complet conceptul ACID (Atomicitate,
Consisten, Izolare i Durabilitate)
Tranzaciile asigur meninerea ntr-o stare consistent a unei baze de date accesate n regim
concurent i cu posibiliti de apariie a erorilor. Blocul de operaii SQL de scriere i citire se
va executa ca o singur comand, apariia unei erori pe parcursul execuiei uneia dintre ele
ducnd la anularea efectelor comenzilor deja executate i anularea tranzaciei. ndeplinirea cu
succes a tuturor sarcinilor din blocul de comenzi permite ncheierea tranzaciei cu succes i
scrierea pe suport permanent a modificrilor efectuate asupra bazei de date.
Toate procedurile stocate n care apare mai mult de o comand SQL care modific date se vor
scrie folosind o tranzacie, prin aceasta asigurndu-se consistena bazei de date chiar i n
cazul apariiei unor erori.
n plus, izolarea automat a tranzaciilor permite efectuarea operaiilor doar dac starea
actuala a bazei de date o permite.
n regim concurenial, s-ar putea ca ntre momentul de timp n care un utilizator lanseaz o
cerere i momentul n care aceasta se execut efectiv, baza de date s se fi modificat de alt
utilizator(tranzacie) i s nu mai existe condiiile logice de a duce la bun sfrit cererea, chiar
dac n momentul lansrii cererii, aceasta era perfect legitim.
4. Crearea vederilor
Vederea este o tabel virtual al crei coninut este definit printr-o interogare. La fel ca
o tabel real, vederea conine un set de coloane i linii de date cu nume. Cu toate acestea,
vederea nu exist ca un set stocat de valori de date. Liniile i coloanele de date ale vederii
provin din tabelele refereniate n interogarea din vedere i se obin dinamic atunci cnd se
refereniaz vederea.
Vederea acioneaz ca un filtru asupra tabelelor pe care le implic. Interogarea care definete
vederea poate proveni din unul sau mai multe tabele sau din alte vederi ale bazei de date. Se
pot utiliza i interogri distribuite pentru a defini vederi care utilizeaz date din mai multe
surse heterogene. Acest lucru este util dac se dorete combinarea structurilor de date similare
din diferite servere, fiecare stocnd date pentru diferite zone ale organizrii. Nu exist
restricii n ceea ce privete interogrile n vederi i sunt puine restricii n ceea ce privete
modificarea datelor din ele.
18

Comanda pentru definirea unei vederi este CREATE VIEW i are sintaxa:
CREATE VIEW nume_vedere(nume_atribut...)
[WITH ENCRYPTION]
AS construcie_SELECT
[WITH CHECK OPTION]
Comanda CREATE VIEW creeaz n catalogul sistem o intrare corespunztoare denumirii
nume_vedere, creia i asociaz definiia specificat prin comanda: lista de atribute i
construcia SELECT. Construcia SELECT dintr-o vedere poate avea orice form exceptnd
clauza ORDER BY. Aceast restricie este impus de necesitatea de a conferi vederilor un
statut ct mai apropiat de cel al relaiilor de baz n care, prin definiie, ordinea tuplelor este
arbitrar. Dac se omite lista nume_atribut... din definiia vederii, atunci atributele acesteia
vor avea aceeai denumire cu cele specificate n construcia SELECT asociat. Acest lucru
este posibil doar dac atributele din construcia SELECT nu sunt rezultatul unor funcii de
agregare sau al unor expresii aritmetice, caz n care este necesar specificarea ntregii liste de
atribute ale vederii.
5. Proceduri stocate
n SQL se poate vorbi despre dou opiuni de baz pentru stocarea i executarea
programelor:
Programele pot fi memorate local la nivelul aplicaiilor care trimit comenzi ctre SQL
Server i prelucreaz rezultatele returnate de acesta.
A doua opiune presupune dezvoltarea i nregistrarea programelor ca proceduri
stocate n SQL Server i crearea de aplicaii care apeleaz aceste proceduri i
prelucreaz rezultatele returnate de acestea. Procedurile stocate din SQL Server sunt
similare procedurilor din alte limbaje de programare n sensul c:
accept parametri de intrare i returneaz valori prin parametri de ieire ctre un
program apelant;
conin instruciuni de programare care efectueaz operaii n baza de date i pot
apela, la rndul lor, alte proceduri stocate;
returneaz ctre apelant o valoare care indic succesul sau eecul execuiei
procedurii, eventual cauza eecului.
Avantajele utilizrii procedurilor stocate:
permit programarea modular procedura se creeaz o dat, se stocheaz n baza de
date i se apeleaz de cte ori vrem n program.
permit execuie rapid dac operaia necesit un numr mare de linii de cod
Transact-SQL sau se aplic repetat, procedurile stocate pot fi mai rapide. Ele sunt
parcurse i optimizate la creare, iar o versiune a procedurii aflat in memoria cache a
serverului de baze de date poate fi folosit dup prima execuie a ei. Declaraiile
Transact-SQL trimise repetat de la client la fiecare rulare sunt compilate i optimizate
la fiecare execuie.
pot reduce traficul de reea o operaie care necesit sute de linii de cod Transact-
SQL poate fi efectuat printr-o singur declaraie care execut codul unei proceduri,
dect s se trimit sute de linii de cod prin reea.
pot fi folosite ca mecanism de securitate utilizatorii pot primi permisiunea de a
executa o procedur stocat, chiar dac nu au permisiunea de a executa direct
instruciunile componente ale procedurii.
Procedura stocat poate fi creat prin comanda CREATE PROCEDURE, care are
sintaxa:
CREATE PROC[EDURE] nume_procedur[;numr]
[
{@parametru tip_de_dat}[VARYING][=valoare_implicit]
19

[OUTPUT]
][,n]
[WITH
{RECOMPILE
|ENCRYPTION
|RECOMPILE,ENCRYPTION}
}
[FOR REPLICATION]
AS
instruciuni_sql[...n]
La primul apel de execuie a procedurii stocate are loc compilarea acesteia i
construirea unui plan de execuie optimizat. Lansarea n execuie a unei proceduri
stocate se realizeaz cu comanda EXECUTE, care are sintaxa:
[[EXEC[UTE]]
{
[@valoare_retur=]{nume_procedura[;numar]|@nume_procedur
}
[[@parametru=]{valoare|@variabila[OUTPUT]|[DEFAULT]][,n]
[WITH RECOMPILE]

1.3.4 Securitate i autentificare
Se poate restriciona accesul la datele gestionate de Microsoft SQL Server:
Se pot impune limitri administratorilor care au acces la datele Analysis Services prin
intermediul Analysis Manager i vor s efectueze funcii administrative.
Se pot impune restricii i utilizatorilor care acceseaz date pe serverul de analiz cu
ajutorul aplicaiilor client.
Se pot specifica utilizatorii care s aib acces la date i tipurile de operaii pe care le
pot efectua.
n plus, se pot controla permisiunile de acces ale utilizatorilor la diferite nivele de date
Analysis Services, incluznd cubul, dimensiunea i celula cub. Securitatea
administrativ este controlat utiliznd grupul Microsoft Windows NT 4.0 sau
Windows 2000 numit Administratori OLAP. Securitatea utilizatorului final este
controlat utiliznd:
Autentificarea pe durata conectrii la serverul de analiz
Rolurile bazei de date, cubului i modelului mining definite n Analysis manager
Fiecare rol definete un set de utilizatori i accesul partajat. Un rol este definit la
nivelul bazei de date Analysis Services i apoi asignate cuburilor la care utilizatorul
din rol are acces. Dup asignare sunt permise anumite schimbri ale rolului de la
nivelul cubului. Aceste schimbri nu afecteaz rolul de la nivelul bazei de date. De
aceea, un rol poate avea o definiie diferit pentru fiecare cub cruia i este asignat.
Serviciile de analiz permit sistemul Windows de securitate integrat.

1.3.5 SQL Server 2005/2008
Versiunea SQL Server 2005/2008 este un software de management de date i analiz
care se caracterizeaz prin scalabilitate crescut, disponibilitate i securitate a datelor riscante
i a aplicaiilor analitice simplificnd crearea, dezvoltarea i tratarea lor.
Avnd la baz puterea SQL Server 2000, noua versiune ofer o soluie de tratare integral a
informailor care va ajuta diferitele tipuri de organizri la:
construirea i dezvoltarea aplicailor enterprise care sunt mai scalabile, mai de ncredere i
sigure.
20

maximizarea productivitii IT reducnd complexitatea de creare, dezvoltare i tratare a
aplicailor de baze de date.
ofer utilizatorilor posibilitatea de a folosi un mediu de dezvoltare bogat, flexibil i modern
pentru a crea aplicaii de baze de date mai sigure.
partajarea datelor pe parcursul mai multor platforme, aplicaii i dispozitive pentru a
simplifica interconectarea sistemelor interne i externe.
oferirea de soluii inteligente i robuste care ajut la luarea unor decizii de gestiune bine
informate i crete productivitatea ntregii organizri.
controlul costurilor fr sacrificarea performanei, disponibilitii sau scalabilitii.
Pe pia, exist mai multe SGBD-uri care susin arhitectura client-server. Intre ele, se
nscriu Microsoft SQL Server, Oracle, Informix, Sybase, Interbasc etc.
SQL Server a evoluat rapid de la un mic desktop SGBD la un sistem puternic orientat
pe performan i scalabilitate nalt. Deja se cunoate faptul c sistemul SQL Server este un
SGBD de tip client-server, iar odat cu apariia versiunii noi a acestui sistem au aprut i
posibiliti noi de creare i gestiune a bazelor de date. Cteva faciliti, ce merit o deosebit
atenie, constau in faptul c sunt oferite capaciti avansate de lucru cu date XML. Este
mbuntit modelul de securitate ce include schimbri n definirea politicilor de securitate,
criptare i gestiunea cheilor. Este modernizat GUI-ul, ce ofer posibilitatea de a prelucra date
n orice limbaj oferit de .NET Framework, fr a limita utilizatorul la utilizarea limbajelor
SQL i T-SQL. Este important de menionat facilitarea mecanismelor de administrare a
SGBD-ului - mbuntirea operaiunilor de mirroring, colectarea datelor despre
productivitatea sistemului, gestiunea resurselor hardware, comprimarea datelor etc.
Una din ariile importante acoperite de SQL Server 2008 este dezvoltarea de aplicaii.
Printre nouti pot fi enumerate: tipuri noi de date, instrumente de dezvoltare mbuntite
(SQL Server Management Studio, Microsoft Visual Studio Tools for Applications, Analysis
Services Design Tools etc.), noi instruciuni Transact-SQL, suport extins pentru tipul de date
XML, introducerea clauzei Let pentru limbajul XQUERY i multe altele.











21

CAPITOLUL 2
Crearea bazelor de date Microsoft SQL Server

2.1 Introducere
Acest capitol descrie cum se creeaz o baz de date, cum se seteaz opiunile acesteia , cum se
creaz grupurile de fiiere, optimizarea SQL Server folosind RAID i grupurile de fiiere,
precum i managementul unei baze de date i al lui transaction log.
Dup parcurgerea capitolului vei cunoate:
Cum SQL Server stocheaz datele i trateaz tranzaciile
Crearea bazelor de date, cu specificarea opiunilor n timpul i dup crearea acestora
Creterea, reducerea sau tergerea unei baze de date
Amplasarea fiierelor bazei de date i a celor de log pentru creterea performanei i a
asigurrii toleranei la defectri
Optimizarea unei baze de date folosind arhitectura hardware bazat pe RAID
Estimarea spaiului necesar stocrii unei baze de date
Cnd se creeaz o baz de date, este important s nelegem cum stocheaz datele SQL
Server(fig. 2.1), aceasta permindu-ne s calculm i s specificm spaiul de disc alocat
pentru fiierele de date i pentru cele de loguri tranzacionale. n acest context, trebuie s
avem n vedere:
Toate bazele de date au un fiier de date primar (.mdf) i unul sau mai multe fiiere de
log tranzacionale (.ldf). De asemenea, o baz de date poate avea i fiiere de date
secundare (.ndf). Aceste fiiere au nume logice i fizice care pot fi folosite n
instruciuni Transact-SQL. Locaia implicit pentru aceste fiiere este :
C:\Program Files\Microsoft SQLServer\MSSQL\Data.
Cnd creeai o baz de date, o copie a bayei de date model, care include tabelele
sistem, este copiat n baza de date.
Datele sunt stocate n blocuri de 8 KB de spaiu de disc continuu, numite pagini.
Aceasta nseamn c o baz de date poate stoca 128 de pagini pe 1 MB.
Liniile nu se pot ntinde pe mai multe pagini. Astfel, dimensiunea maxim a unei linii,
scznd spaiul ocupat de antet, este de 8060 B.
Tabelele i indecii sunt stocate n extensii; o extensie are 8 pagini contigue sau 64
KB, ceea ce nseamn 16 extensii/1 MB. Tabelele mici pot folosi n comun extensii cu
alte obiecte din baza de date.
Fiierele de log tranzacionale(jurnal) pstreaz informaia necesar pentru restabilirea
unei baze de date dac apare o defectare.

2.2 Tranzaci
O tranzacie este un set de una sau mai multe instruciuni Transact-SQL care sunt tratate ca o
singur unitate de lucru i restabilire (recovery). Unitatea trebuie executat n totalitate sau
deloc. Aplicaiile controleaz tranzaciile prin specificarea de ctre programator a nceputului
i a sfritului acestora; pentru aceasta se pot folosi instruciuni Transact-SQL sau funcii
API(Application Programming Interface ). SQL Server execut tranzacii n mod implicit sau
explicit.
Tranzacii implicite
SQL Server execut o tranzacie implicit cnd este executat oricare dintre urmtoarele
instruciuni:


22



Figura 2.1 Structura unei baze de date Microsoft SQL Server

ALTER TABLE, CREATE, DELET, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE,
SELECT, TRUNCATE TABLE, UPDATE.
Modul autocommit este implicit pentru SQL Server. Aceasta nseamn c fiecare instruciune
este comis sau anulat la terminare; dac apare o eroare, aceasta este anulat. O conexiune
SQL Server opereaz n modul autocommit dac modul implicit nu a fost suprascris de
tranzaciile implicite sau explicite.
Tranzacii explicite
SQL Server execut o tranzacie explicit dac nceputul i sfritul acesteia sunt definite
explicit cu instruciunile BEGIN TRANSACTION i COMMIT TRANSACTION.
Explicarea funcionrii fiierului de log tranzacional
SQL Server nregistreaz ntr-un fiier de log tranzacional pentru a menine consistena
datelor i a fi folosit n procesul de recuperare. Log-ul este o zon de stocare care pstreaz
automat modificrile dintr-o baz de date, nainte ca acestea s fie scrise n baza de date.
Operaiile care se deruleaz sunt:
1. Aplicaia dorete s modifice datele.
2. Cnd se execut o modificare, paginile de date afectate sunt ncrcate de pe disc n
memorie (n buffer cache), presupunnd c nu exist deja n buffer cache dintr-o
interogare anterioar.
3. Fiecare instruciune de modificare a datelor este nregistrat n log pe msur ce este
fcut. Modificarea este ntotdeauna nregistrat n log i scris pe disc nainte ca
modificarea s fie operat n baza de date. Acest tip de log este denumit write-ahead
log.
4. n mod repetat, procesul de checkpoint scrie toate tranyaciile finalizate n baza de
date de pe disc.
Dac sistemul se defecteaz, n mod automat procesul de restabilire va folosi log-ul pentru a
relua tranzaciile comise(finalizate) i a le anula pe cele incomplete.
If the system fails, he automatic recovery process uses the transaction log to roll forward all
committed transactions and roll back any incomplete transactions. n timpul procesului de
recovery se folosesc markerii de tranzacii pentru a determina nceputul i sfritul unei
tranzacii. O tranzacie este complet dac markerul BEGIN TRANSACTION are un marker
COMMIT TRANSACTION asociat. Cnd apare un proces de checkpoint paginile de date
sunt scrise pe disc.
23

2.3 Crearea bazelor de date
O baz de date se poate crea folosind utilitarele SQL Server Enterprise Manager/SQL Server
Management Studio sau instruciunea Transact-SQL CREATE DATABASE.
Cnd se creeaz o baz de date:
SQL Server creeaz un fiier de date i unul de log.
Trebuie ca proprietarul i creatorul bazei de date s aib permisiunea de-a folosi baza
de date master, deoarece informaiile despre fiecare baz de date sunt nregistrate n
tabelele sistem sysdatabases i sysaltfiles din baza de date master.
V permite s definii:
o Numele bazei de date.
o Proprietile bazei de date.
o Locaiile fiierelor bazei de date.
SQL Server folosete o copie a bazei de date model pentru a iniializa baza de date i
metadatele. Orice opiune sau setare din baza de date model este copiat n noua baz
de date.
SQL Server completez restul bazei de date cu pagini goale, exceptnd paginile care
conin informaii despre utilizarea spaiului n baza de date.
Obs.: Ar trebui s salvai baza de date master de fiecare dat cnd creeai, modificai sau
tergei o baz de date.
Opiunile specificate la crearea unei baze de date
Cnd creeai o baz de date putei specifica urmtoarele opiuni:
Primary File
Secondary Files
Transaction Log
File Name and Location
Size
File Growth
Maximum Size
Collation
Fiierul primar(primary file) conine fiierul iniial de date din grupul de fiiere primar. Un
grup de fiiere este o colecie de fiiere de date care primete un nume. Grupul de fiiere
primar conine toate tabele sistem ale bazei de date; conine i obiectele i datele crora nu le-
au fost asignate grupuri de fiiere definite de utilizator. Fiierul de date primar este punctul de
start al unei baze date i pointeaz la restul fiierelor din baza de date. Fiecare baz de date are
un fiier de date primar i un grup de fiiere primar. Extensia recomandat pentru fiierul de
date primar este .mdf.
Bazele de date pot avea i fiiere de date secundare; unele baze de date pot conine mai multe
fiiere de date secundare, iar acestea se pot afla pe discuri diferite- fiierele de date secundare
pot s fie situate n grupul de fiiere primar sau n grupuri de fiiere definite de utilizator.
Extensia recomandat pentru fiierele de date secundare este .ndf.
Fiecare baz de date trebuie s aib un log tranzacional. Dac nu se specific altfel, acesta se
creeaz automat cu un nume generat de sistem. Extensia recomandat pentru logul
tranzacional este .ldf. De obicei, dimensiunea log este de 10%-15% din dimensiunea
fiierelor de date.
Fiecare fiier al unei baze de date are un nume logic i altul fizic(locaia acestuia). Fiierele ar
trebui s fie plasate pe mai multa discuri pentru performan i redundan.
Se pot specifica dimensiuni(Size) pentru fiecare fiier de date de log. Dimensiunea minim
este de 512 KB; dimensiunea pentru fiierul de date primar trebuie s fie cel puin egal cu
cea a fiierul ui de date primar din baza de date model.
24

Putei specifica dac este nevoie de creterea dimensiunii (autogrow); implicit se valideaz
aceast cretere(File Growth). Dimensiunea maxim de cretere(Maximum Size) se poate
specifica n MB sau procentual-valoarea implicit este de 10%. Se recomand s se specifice
dimensiunea maxim permis la care poate ajunge un fiier. Dac nu procedai aa i se
permite creterea fiierului n mod implicit, acesta poate crete pn se epuizeaz spaiul de
pe disc.
Parametrul Collation specific pagina de cod pentru baza de date. Implicit, o baz de date
motenete collation al instanei din care face parte.
Schimbarea opiunilor unei baze de date
Dup ce creeai o baz de date, putei schimba opiunile acesteia; ele pot fi setate cu SQL
Server Enterprise Manager/SQL Server Management Studio, instruciunea Transact-SQL
ALTER DATABASE sau procedura stocat sp_dboption.
Sunt 5 categorii de opiuni baz de date:
Opiuni auto care controleaz comportrile automate.
Opiuni cursor care controlez comportamentul cursorului.
Opiuni Recovery care controleaz modelul de recuperare al bazei de date.
Opiuni SQL care controleaz aderena la standardele ANSI.
Opiuni de control al strii:
o Dac baza de date este online/offline.
o Cine se poate conecta la baza de date.
o Dac baza de date este n mod read only.
Vizualizarea proprietilor bazei de date
Pentru a vedea proprietile i informaiile aferente, putei folosi SQL Server Enterprise
Manager/SQL Server Management Studio, funcii de sistem, proceduri stocate de sistem sau
instruciuni Database Consistency Checker (DBCC).
Urmtorul tabel(tabelul 2.1) prezint cele mai folosite proceduri i instruciuni.

Procedur stocat de sistem /instruciune
DBCC
Descriere

sp_helpdb
Afieaz numele, dimensiunea, proprietarul,
ID-ul, data de creare i opiuni ale tuturor
bazelor de date.

sp_helpdb database_name
Afieaz numele, dimensiunea, proprietarul,
ID-ul, data de creare i opiuni ale bazei de
date database_name. Listez, de asemenea,
fiierele d e date i de log.
sp_spaceused [objname] Afieaz spaiul ocupat de o baz de date sau
de obiectele acesteia.
DBCC SQLPERF (LOGSPACE) Ofer statistici despre utilizarea spaiului de
log n toate bazele de date.

Tabelul 2.1 Afiarea proprietilor unei baze de date

2.3.1 Managementul creterii dimensiunii fiierelor de date i de log
Cnd fiierele de date cresc sau cnd sunt modificri frecvente ale datelor, poate s
apar necesitatea expandrii fiierelor de date sau log. Putei face acest lucru utiliznd SQL
Server Enterprise Manager/SQL Server Management Studio sau instruciunea ALTER
DATABASE (trebuie s fii n baza de date master pentru a folosi instruciunea). Putei
controla dimensiunea bazei de date configurnd fiierele de date i de log s creasc automat/
manual, ori crend fiiere de log i fiiere de date secundare.
25

Creterea automat a dimensiunii fiierelor
Se poate seta creterea automat a unui fiier cu o anumit dimensiune sau procentual.
Acest mod de abordare reduce timpul de administrare cerut de creterea manual a
dimensiunii. Se pot specifica spaiul alocat, dimensiunea maxim i incrementul de cretere
pentru fiecare fiier. Pentru o performan optim, ar trebui s:
Alocai spaiu suficient bazei de date i logului pentru a evita activarea frecvent a
creterii automate.
S setai o dimensiune maxim pentru fiierele de date.
S setai incrementele de cretere pentru fiierele de date i de log la mrimi suficiente
pentru a evita activarea frecvent a creterii automate.
Creterea manual a dimensiunii fiierelor
Putei crete manual dimensiunea oricrui fiier de date sau de log ale unei baze de date
utiliznd SQL Server Enterprise Manager/SQL Server Management Studio sau instruciunea
ALTER DATABASE. Acest lucru controleaz momentul apariiei expandrii-expandarea
fiierelor cu incremente mici crete fragmentarea i poate afecta performana, dac fiierele
sunt extinse cnd baza de date este ocupat.
Cnd alegei un anumit mod de expandare a fiierelor bazei de date, avei n vedere:
ntr-un mediu de producie mare ar trebui s alocai spaiu suficient fiierelor de date
i de log la creare i s le expandai manual, dac este nevoie.
n mediile productive de mic dimensiune(mici sau desktop) alegei creterea
automat pentru a reduce activitile administrative.
Crearea fiierelor de date i de log secundare
Putei crea fiiere de date i de log secundare pentru a extinde dimensiunea unei baze de date;
se recomand plasarea acestora pe discuri separate sau utiliznd sistemul RAID.
Reducerea dimensiunii unei baze de date automat
Cnd se aloc prea mult spaiu sau cnd cerinele de spaiu scad, putei reduce o baz de date
sau un anumit fiier de date sau log. Putei seta ca aceast reducere s apar automat, n unul
din urmtoarele moduri:
Autoshrink (cu SQL Server Enterprise Manager/SQL Server Management Studio)
ALTER DATABASE AUTO_SHRINK (executai instruciunea Transact-SQL)
sp_dboption(executai aceast procedur stocat).
Reducerea dimensiunii unei baze de date manual
Pentru a reduce manual bazele de date i fiierele acestora la o dimensiune specificat, putei
folosi SQL Server Enterprise Manager/SQL Server Management Studio ori putei executa
instruciunea DBCC SHRINKDATABASE sau DBCC SHRINKFILE. Putei:
S reducei fiierele de date i de log ca un grup sau individual.
S reducei individual fiierele de date i de log mai mici dect dimensiunea avut la
creare, folosind instruciunea DBCC SHRINKFILE.
Obs.: Nu putei reduce o ntreag baz de daet la o dimensiune mai mic dect dimensiunea
iniial sau dect a bazei de date model.
Cnd se reduc manual fiierele de log, SQL Server ncearc s le reduc imediat. Pentru
aceasta:
Reduce poriunile inactive ale log care sunt mai mari dect dimensiunea dorit.
Dac nu poate reduce logul la dimensiunea dorit, SQL Server:
o D un mesaj de avertizare care spune c logul este dincolo de dimensiunea
dorit.
o V sftuiete ce trebuie s facei. Dup ce executai activitile sugerate,
reexecutai instruciunea DBCC SHRINKDATABASE sau DBCC
SHRINKFILE.
26

tergerea unei baze de date
Putei terge o baz de date folosind SQL Server Enterprise Manager/SQL Server
Management Studio sau executnd instruciunea DROP DATABASE. Dup tergere, fiecare
ID de login, care avea acea baz de date ca implicit, va rmne fr o baz de date implicit.
Restriciile urmtoare se aplic la tergerea unei baze de date. Nu putei terge:
O baz de date care este n procesul restaurrii.
O baz de date deschis pentru citire/scriere de alt utilizator.
O baz de date care-i public tabelele ntr-o replicare SQL Server.
O baz de date sistem.

2.4 Aspecte de performan a bazelor de date
Putei imbunti performana i implementa tolerana la defectri prin tehnici de
plasare a fiierelor de date i de log pe disc. Serverul de baze de date utilizeaz sistemul de
operare gazd pentru a rezolva operaiile de intrare/ieire necesare n citirea i scrierea datelor
n bazele de date. Subsistemul de intrare/ieire utilizeaz magistrala calculatorului,
controlerele de hard disc, hard discurile, CD-ROM-urile i alte dispozitive de intrare/ieire
necesare. Discurile sunt, de cele mai multe ori, cele mai accesate n sistem, de aceea pot crea
fire de ateptare n execuia operaiilor de citire i scriere.
Managementul spaiului pe disc
n contextul managementului spaiului de stocare pe disc, putem da cteva scurte definiii:
Performana se refer la viteza operaiilor de citire i scriere pe suporii
informaionali.
Tolerana la defectri vizeaz abilitatea sistemului de-a continua s funcioneze fr
pierdere de date, cnd anumite pri ale sistemului se defecteaz.
Se recomand formatarea hard discurilor de tip NTFS, cu unitatea de alocare de 64 KB; nu se
pot folosi volume comprimate.
Stocarea fiierelor de date pe mai multe hard discuri
Ar trebui s divizai fiierele de date pe cte hard discuri avei la dispoziie; acest lucru
mbuntete limea de band disponibil, prin accesarea paralel a datelor stocate n mai
multe fiiere. De obicei se creeaz un fiier pe fiecare disc fizic i se grupeaz n mai multe
grupuri de fiiere. SQL Server poate executa:
Scanri paralele de date dac sistemul de calcul are procesoare i hard discuri
multiple.
Scanri paralele multiple pentru un singur tabel, dac grupul de fiiere al tabelului
conine fiiere multiple.
Pentru a diviza datele pe toate discurile se folosete tehnologia RAID i apoi se utilizeaz
grupurile de fiiere definite de utilizator.
Crearea fiierelor de log tranzacional pe mai multe discuri
Ar trebui s creai fiierele de log pe mai multe hard discuri sau s folosii tehnologia RAID.
Deoarece logul este scris serial, se recomand utilizarea discurilor dedicate pentru a pstra
capetele de citire/scriere poziionate pentru operaiile care urmeaz. Folosirea RAID ofer
toleran la defectri. De exemplu, dac mediul de lucru are mai multe baze de date pe un
server, se poate utiliza disc separat pentru fiecare log-strategia aceasta permite performan
optim.
Utilizarea tehnologiei RAID
Hardware-ul bazat pe RAID v permite s administrai discuri multiple prin tratarea unei
matrice de discuri ca i cum ar fi un singur disc. Se recomand utilizarea RAID-ului hardware
i nu a celui software al sistemului de operare pentru mbuntirea performanei.
RAID-ul software consum cicluri de ceas CPU, utile altor aplicaii; RAID-ul de tip hardware
v permite s nlocuii discurile defecte fr s oprii sistemul de calcul.
27

Cnd folosii RAID hardware pentru optimizarea bazei de date, avei n vedere urmtoarele
tipuri de RAID:
Disk mirroring sau disk duplexing (RAID 1) pentru redundana fiierului de log
tranzacional.
Disk striping cu paritate (RAID 5) pentru performana i redundana fiierelor de date
i de log.
Disk mirroring cu striping (RAID 10 sau RAID 1 + RAID 0) pentru performan
maxim a fiierelor de date.
Utilizarea grupurilor de fiiere definite de utilizator
Dac serverul de baze de date are mai multe hard discuri, putei stoca anumite obiecte i
fiiere pe discuri individuale, grupnd fiierele bazei de date n unul sau mai multe grupuri de
fiiere (fig. 2.2).
SQL Server are un grup de fiiere primar i, opional, unul sau mai multe grupuri de fiiere
definite de utilizator:
Grupul de fiiere primar conine fiierul de date primar, cu tabelele sistem.
Un grup de fiiere definit de utilizator conine fiiere de date grupate n scopul alocrii
i administrrii comune.



Figura 2.2 Organizarea bazei de date pe grupuri de fiiere

Fig. 2.2 ilustreaz un exemplu de plasare a fiierelor bazei de date pe discuri separate:
Ar trebui s creai un grup de fiiere definit de utilizator pentru a separa fiierele
interogate frecvent de acelea care sunt modificate foarte des. n figur fiierele
OrdHist1.ndf i OrdHist2.ndf sunt plasate pe un disc separat de tabelele Products,
Customers i Orders deoarece sunt interogate pentru suport decizional i mai puin
pentru modificare.
De asemenea, ai putea plasa fiierele OrdHist1.ndf i OrdHist2.ndf pe discuri
separate, dac sunt interogate frecvent.
Fiierele de log nu aparin unui grup de fiiere. Spaiul pentru aceste fiiere este
ntreinut separat de fiierele de date.
Putei crea fiiere de date multiple pe discuri separate i apoi grupuri de fiiere care s le
includ. Dac se utilizeaz grupurile de fiiere, este bine s existe doar un fiier pe un disc
fizic.

28

Metode de creare a grupurilor de fiiere
Putei crea un grup de fiiere definit de utilizator cnd creai baza de date sau mai
trziu. Pentru aceasta putei utiliza utilitarul SQL Server Enterprise Manager/SQL Server
Management Studio sau instruciunile Transact-SQL CREATE DATABASE sau ALTER
DATABASE. SQL Server seteaz un grup de fiiere ca implicit-cnd baza de date este creat
acesta va fi cel primar, dac nu specificai un alt grup de fiiere. Grupul implicit conine
paginile pentru toate tabelele i indecii care nu au un grup de fiiere specificat cnd au fost
create. Dac grupul implicit este lsat grupul primar, trebuie s-l dimensionai adecvat sau s
setai creterea automat a spaiului pentru el, pentru a nu ajunge la epuizarea acestuia.
Grupul de fiiere primar trebuie s fie suficient de mare pentru a pstra toate tabelele sistem i
toate tabelele i indecii care nu au fost alocai unui grup de fiiere definit de utilizator.
Dac grupul de fiiere primar i epuizeaz spaiul alocat nu vei putea modifica tabelele
sistem, pe cnd n cazul grupurilor de fiiere definite de utilizator sunt afectate doar fiierele
specifice din cadrul grupului.
Vizualizarea informaiilor despre grupurile de fiiere
Putei vizualiza informaiile despre grupurile de fiiere folosind SQL Server Enterprise
Manager/SQL Server Management Studio sau proceduri stocate sistem (tabelul 2.2).

Numele procedurii stocate Descriere
sp_helpfile [[@filename =] 'name'] ntoarce numele fizice i atributele fiierelor
care compun baza de date curent. Aceast
procedur stocat se folosete pentru a afla
numele fiierelor care se ataeaz/detaeaz
de pe server.
sp_helpfilegroup [filegroup_name] ntoarce numele i atributele grupurilor de
fiiere din baza de date curent.

Tabelul 2.2 Afiarea informaiilor despre grupurile de fiiere ale unei baze de date

Grupurile de fiiere se mai pot utiliza pentru a facilita operaiile de mentenan:
Se pot salva sau restaura fiiere ale bazei de date individual sau pe grupuri de fiiere,
n loc de a salva toat baza de date, n special pentru bazele de date foarte mari, pentru
a micora timpii respectivi.
Se pot grupa tabelele i indecii cu cerine similare de mentenan n aceleai grupuri
de fiiere.
Se pot plasa obiectele cu cerine speciale de mentenan ntr-un grup dedicat; de
exemplu, o tabel care e actualizat frecvent poate cere salvarea/restaurarea separat de
baza de date n totalitate.

Crearea grupurilor de fiiere este o tehnic avansat de design. Trebuie s nelegei structura
bazei de date, natura datelor, tranzaciile i interogrile executate pentru a determina cea mai
bun modalitate de a plasa tabelele i indecii n grupurile de fiiere.
Cnd se creeaz grupuri de fiiere ar trebuie avute n vedere urmtoarele:
Se d ntietate cerinelor de mentenan, mai degrab dect celor de performan, n
determinarea numrului de grupuri de fiiere. De multe ori folosirea facilitilor
oferite de RAID (de exemplu, utilizarea mai multor discuri) ofer acelai ctig de
performan ca i n cazul utilizrii grupurilor de fiiere, fr a mai fi nevoie de un
plus de activitate administrativ.
Schimbai grupul de fiiere implicit dac ai creat grupuri de fiiere utilizator. Acest
lucru va preveni creterea dimensiunii tabelelor peste spaiul alocat, putndu-se
accesa tabelele sistem aflate n grupul de fiiere primar, ntr-o asemenea situaie de

29

avarie.
Grupurile de fiiere nu ofer toleran la defectri. Pentru a include acest mecanism,
putei face mirror (oglindire) pentru fiecare hard disc folosind RAID 1, dar este o
opiune costisitoare.

2.5 Estimarea dimensiunii bazelor de date
Cnd planificai crearea unei baze de date setai structura logic. Sub aceast structur
se gsesc fiierele fizice i obiectele care ocup spaiu pe disc-sunt incluse aici fiierele de
log, precum i tabelele i indecii din fiierele de date. Cnd creai o baz de date, SQL
Server creeaz o copie a bazei de date sistem model, incluznd tabelele sistem care conin
informaii despre fiiere, obiecte, permisiuni i constrngeri. Aceste tabele cresc n
dimensiune cnd se creeaz obiecte n baza de date; fiecare obiect creat genereaz o linie
nou, care va fi inserat n unul sau mai multe tabele sistem.
Avei n vedere urmtorele aspecte cnd estimai spaiul alocat la crearea bazelor de date:
Dimensiunea bazei de date model i a tabelelor sistem, incluznd i creterea
prognozat.
Cantitatea de date din tabele, incluznd i creterea estimat.
Numrul i imensiunea indecilor, n special dimensiunea cheii, numrul de linii i
parametrul fill factor(factor de umplere a paginii).
Dimensiunea fiierului de log, care e determinat de frecvena activitilor de
modificare, dimensiunea tranzaciilor stocate i ct de des se salveaz(se terg
tranzaciile comise).
Dimensiunea tabelelor sistem(funcie de numrul de utilizatori, obiectele create .a.).
Obs.: Ca punct de plecare, ar trebui s alocai 10-25% din dimensiunea bazei de date
fiierului de log n cazul mediilor OLTP(OnLine Transaction Processing) i s alocai mai
puin pentru bazele de date utilizate mai mult n interogri(citire).
Estimarea cantitii de date din tabele
Dup ce luai n considerare dimensiunea bazei de date model, ar trebui s estimai
cantitatea de date din tabele, inclusiv creterea prognozat, calculnd numrul total de linii,
dimensiunea liniei, numrul de linii care ncap ntr-o pagin i numrul total de pagini
ocupate defiecate tabel din baza de date. Putei estima numrul de pagini necesare unui tabel
i spaiul de disc ocupat de acesta dac tii numrul de caractere al fiecrei linii i numrul
aproximativ de linii. Pentru aceasta utilizai urmtoarea metod:
Calculai numrul de octei dintr-o linie prin adunarea numrului de octei ocupai de
fiecare coloan; dac exist coloane de lungime variabil se va aduna lungimea medie
la total.
Determinai numrul de linii coninute ntr-o pagin de date mprind 8060 la
numrul de octei ocupai de o linie. Rotunjii rezultatul la valoarea ntreag, prin
scdere.
mprii numrul de linii din tabel la numrul de linii dintr-o pagin de date, astfel
determinnd numrul de pagini din tabelul respectiv.
Respectarea urmtoarelor sfaturi va conduce la crearea unor baze de date adecvate:
Salvai baza de date master imediat dup ce creai sau modificai o baz de date.
Specificai o dimensiune maxim cnd folosii creterea automat de fiier. Acest
lucru va preveni ca un fiier s ajung s ocupe ntreg hard discul.
Alegei dimensiunea iniial a unei baze de date i incrementul de autocretere
suficient de mari, pentru a evita creterile frecvente de fiier. Astfel vei reduce
activitatea administrativ a serverului de baze de adte i vei evita fragmentarea
fiierelor pe hard disc.
30

Folosii disk mirroring, disk striping with parity, or disk mirroring with striping
pentru performan i toleran la defectri.
Creai cte un fiier pentru fiecare disc fizic i grupai-le ntr-un singur grup de
fiiere primar.
Schimbai grupul de fiiere implicit dac folosii grupuri de fiiere definite de
utilizator. Dac baza de date are mai multe grupuri de fiiere, ar trebui s asignai
unul dintre grupuri ca fiind implicit; acest lucru va evita s se blocheze accesul la
tabelele sistem, cci ele se afl n grupul de fiiere primar, fiind mpreun cu cele
utilizator(care cresc n dimensiune, putnd epuiza spaiul alocat).









































31

CAPITOLUL 3
Metode de autentificare server de baze de date

Fiecare discuie c securitatea unui server de baze de date are legtur cu procesele
gemene de autentificare i autorizare. Autentificarea se refer la procesul de identificare a
unui utilizator, iar autorizarea se refer la procesul de determinare a ceea ce poate face
utilizatorul. Pentru SQL Server, autentificarea are loc att n timpul conectrii iniiale, ct i
de fiecare dat cnd un utilizator ncearc s utilizeze o baz de date pentru prima dat n
timpul unei sesiuni. Autorizarea se produce de fiecare dat cnd un utilizator ncearc s
efectueze orice operaiune ntr-o baz de date. Autorizarea se va realiza, de asemenea, n
momentul n care un utilizator ncearc s schimbe configuraia SQL Server, atunci cnd se
execut proceduri stocate i cnd se fac modificri la configuraia bazei de date, i aa mai
departe.
Autentificarea formeaz baza oricrui model de securitate:



Figura 3.1 Poziia autentificrii ntr-un model de securitate.

Un cont de login(conectare) trebuie s fie creat pentru fiecare utilizator care vrea s
efectueze diferite interogri asupra bazelor de date din SQL Server. Administratorul bazei de
date (DBA) are responsabilitatea de a crea i gestiona datele de conectare la serverul SQL. O
conectare este un cont de securitate creat n SQL Server sau un link ctre un anumit cont de
utilizator sau grup din Windows. Atunci cnd utilizatorii ncercearc s acceseze SQL Server,
acetia furnizeaz datele lor de conectare (credeniale) i serviciul SQL Server i autentific.
Procesul de autentificare a unui utilizator depinde de metoda de autentificare aleas.
Urmtoarele paragrafe vor detalia opiunile disponibile pentru prelucrarea unei ncercri de
conectare: autentificarea Microsoft Windows sau autentificarea SQL Server.
A treia metod de autentificare, modul mixt, este o combinaie ntre autentificarea
Microsoft Windows i autentificarea SQL server. Aceast configuraie permite integrarea
securitii Microsoft Windows i SQL Server sau pune n aplicare conturile de autentificare
SQL care nu depind de Windows.
Audit
Criptarea
(Cine o poate
vedea?)
Autorizarea
(Cine o poate face?)
Autentificarea
(Cine este?)
32




Figura 3.2 Arborele de decizie pentru alegerea metodei de autentificare.

3.1 Autentificarea Microsoft Windows
Autentificarea Windows este folosit pentru a integra securitatea Microsoft Windows n
Microsoft SQL Server. Cu aceast opiune de autentificare clientul poate utiliza acelai cont
pentru conectarea att n Windows ct i n SQL Server. Acest tip de autentificare depinde de
prima conectare cu succes n domeniul Windows. Atunci cnd un utilizator se conecteaz la
SQL Server utiliznd autentificarea Windows, conexiunea este menionat ca o conexiune de
ncredere. Utilizatorul prezint un simbol de acces n SQL Server pentru a reprezenta
identitatea utilizatorului. SQL Server utilizeaz acest simbol de acces i l compar cu o list
de utilizatori al cror acces la SQL Server a fost acordat. Autentificarea este uor diferit
pentru un client de Active Directory dect pentru un client care nu are suport Active
Directory. Clienii care suport Active Directory sunt autentificai prin Kerberos, n timp ce
Conectare la SQL Server
folosind aplicaia client
Modul de
auentificare
Windows Authentication Mod mixt
Folosete cont
de Windows?
Conexiune refuzat de SQL Server
Conexiune acceptat de SQL Server

Permisiune de
conectare?
Folosete
autentificarea
SQL Server?
Cont de
autentificare
valid?
Parola
valid?
NU
NU
NU
NU
NU
DA
DA
DA
DA
Conexiune refuzat de SQL Server
33

clieni care nu utilizeaz Active Directory sunt autentificai cu Microsoft Windows NT LAN
Manager (NTLM).

3.1.1 Autentificarea Kerberos
Kerberos este protocolul preferat de autentificare pentru un domeniu Windows. n cazul
n care clientul nu suport Kerberos, se utilizeaz autentificarea NTLM. Kerberos definete
serviciile reea de autentificare pentru accesul clientului la resursele domeniului. Kerberos are
capacitatea de a pune n aplicare autentificarea reciproc, n sensul c serviciul de reea ct i
clientul trebuie s se identifice ntre ei reciproc. SQL Server utilizeaz autentificarea
reciproc la autentificarea clientilor, precum i la autentificarea serviciilor SQL. Atunci cnd
un client furnizeaz credenialele reelei, Windows-ul localizeaz un controler de domeniu
Active Directory. Serviciul Kerberos emite apoi un tichet de acceptare (ticket granting ticket
TGT), ce conine date criptate prin care confirm identitatea clientului.
Aceast identitate este trimis apoi la centrul de distribuie a cheilor (Key Distribution
Center KDC).



Figura 3.3 Alocarea unui tichet de acceptare TGT de ctre serviciul Kerberos.

n cazul n care clientul dorete s accese un serviciu, TGT este trimis la KDC, iar apoi i
se acord clientului un tichet de sesiune pentru serviciul solicitat serverului n cazul n care
serviciul este nregistrat. Clientul poate trimite apoi tichetul sesiunii la serviciul serverului
care gestioneaz resursa i utilizeaz apoi biletul pentru a se identifica pe sine.
Dup ce un client a furnizat datele sale de autentificare serverului, serviciul serverului
este obligat apoi s se identifice la client. Serverul i va rspunde clientului, n format criptat,
cu un mesaj pentru a se identifica pe sine. Fiecare tichet al unei sesiuni are un timp de
expirare. Timpul implicit de expirare este determinat de KDC. Tichetele pot fi refolosite
pentru accesul la resurse, pn cnd acesta expir. Tichetul va trebui, de asemenea, s fie
reconstruit n cazul n care clientul se deconecteaz din domeniu.
Autentificarea reciproc cu Kerberos impune ca serverul i clientul s se autentifice
reciproc. Service Principal Name(SPN) trebuie s fie configurat pentru serviciul SQL Server.
SPN este folosit de SQL Server pentru a se autentifica. Fr SPN, SQL Server este limitat n a
permite autentificarea reciproc i Kerberos.

CDC
Client 2. CDC verific
baza de date i
trimite TGT
1. La autentificare,
clientul cere un TGT
care i permite s
obin tichete pentru
anumite servicii
TGT
3. Clientul utilizeaz
parola pentru a decripta
TGT i acum poate utiliza
TGT pentru a obine alte
tichete
TGT= Tichet acceptare CDC= Centru distribuie chei

34



Figura 3.4 Autentificarea reciproc cu Kerberos ntre un client i server.

3.1.2 Autentificarea Windows NT LAN Manager(NTLM)
Autentificarea Windows NT LAN Manager (NTLM) este utilizat n Windows numai
n cazul n care clientul i / sau serverul nu suport Kerberos. Windows NT LAN Manager nu
este o metod de autentificare reciproc. NTLM este un proces criptat prin care clientul este
autentificat n cadrul serverului. n cazul n care utilizatorul se conecteaz n domeniu,
utilizatorului i se acord un simbol (token) de acces.
Acest token de acces este utilizat pentru a identifica utilizatorul, identitile grupurilor
i drepturile asociate cu acel utilizator. Clientul poate folosi acest simbol de acces ca o
identitate atunci cnd ncearc s acceseze resursele de reea. Simbolul de acces este trimis la
server, acolo unde se gsesc resursele. Subsistemul de securitate de pe server compar
simbolul de acces cu lista de utilizatori i grupuri (ACL) care au acces la resurs; utilizatorul
primete dreptul de acces la resurs sau i se refuz dreptul de acces.
Cu NTLM, SPN nu trebuie s fie configurat. SPN nu este necesar, deoarece
autentificarea clientului nu depinde de identitatea serverului. Windows NT LAN Manager nu
suport tichetul Kerberos i autentificarea reciproc. Fr aceste caracteristici, NTLM nu este
la fel sigur cum este Kerberos.

Faza I
Autentificare 1
Auth:Cosmin 2
Controler domeniu
OK
Faza II
Controler domeniu
Am nevoie de un tichet pentru SQL Server 3
Utilizatorul primete tichetul de la controlerul de domeniu
Faza III
Am un tichet pentru a incepe autentificarea 4
5 OK
SQL Server
Faza IV
Autentificare:Cosmin 6
Cosmin s-a autentificat
SQL Server
35



Figura 3.5 Metoda de autentificare Windows NT LAN Manager(NTLM).

3.1.3 Procesul de autentificare al unei conectri Windows(Windows Login).
Dup ce utilizatorul s-a conectat la domeniu, utiliznd fie Kerberos sau NTLM, clientul
poate solicita accesul la un anumit server SQL. Clientul trimite identitatea sa la server i, pe
baza listei de utilizatori a serverului (care este stocat n tabelul sysxlogins din baza de date
master), utilizatorul primete sau i este refuzat accesul la serverul SQL. Paii detaliai ai
autentificrii Windows sunt urmtorii:
1. Atunci cnd un utilizator se conecteaz iniial la SQL Server, acesta solicit o
conexiune de ncredere cu SQL Server.
2. Utilizatorul paseaz tichetul Kerberos sau simbolul de acces serverului SQL. Serverul
SQL folosete tichetul sau token-ul pentru a verifica dac utilizatorul a fost deja validat n
Windows.
3. n cazul n care SQL Server gsete contul n lista sa de utilizatori, serverul accept
conexiunea. SQL Server nu are nevoie s evalueze parola deoarece Windows-ul a autentificat
deja utilizatorul.

3.2 Autentificarea SQL Server
Atunci cnd domeniul Windows nu a autentificat un utilizator, singura opiune pentru
accesarea serverului SQL este printr-un cont de securitate SQL. Aceast metod de
autentificare este deosebit de benefic n cazul n care utilizatorul se conecteaz la serverul
SQL de pe Internet sau dintr-o infrastructur de reea far Windows. n astfel de cazuri, nu ai
vrea ca utilizatorul s se autentifice prin intermediul unui domeniu Windows. Utilizatorul
poate furniza datele de autentificare, nume de utilizator i parola serverului SQL, ocolind
astfel securitatea Windows-ului. Dup ce utilizatorul trimite datele de conectare la server,
SQL Server compar numele de utilizator cu cele nregistrate n lista conturilor de securitate
din SQL Server. n cazul n care serverul SQL gsete numele de utilizator, n tabelul
sysxlogins, utilizatorul primete dreptul de acces la SQL Server. Folosind autentificarea SQL
Server, numele de utilizator i parola sunt furnizate serverului n format text clar, cu excepia
cazului cnd att clientul ct i serverul folosesc criptarea Secure Socket Layer (SSL) pentru
ntrega sesiune. Atunci cnd este utilizat SSL, att clientul ct i serverul trebuie s obin un


Client


Server
(1) Utilizatorul solicit accesul
(3)Clientul trimite rspunsul la mesaj
(2) Serverul trimite un mesaj de autentificare
(6) Serverul trimite rspunsul clientului

Active
Directory
Autentificare
NTLM
Controler domeniu
(5) Controlerul de domeniu compar
mesajul de autentificare cu rspunsul
pentru a autentifica utilizatorul
(4) Serverul trimite mesajul de
autentificare i rspunsul la
controlerul de domeniu
36

certificat. Fr SSL, autentificarea SQL este o metod nesigur de autentificare. Etapele de
autentificare a conturilor SQL sunt urmtoarele:
1. Un utilizator solicit o conexiune nesigur la serverul SQL. Numele de utilizator i
parola sunt trimise la server.
2. Datele de conectare sunt comparate cu lista de utilizatori SQL stocat n tabelul
sysxlogins. Att numele de utilizator ct i parola trebuie s fie verificate.
3. Dac contul nu exist, sau dac parola nu este validat, conectarea va eua, iar
utilizatorului i va fi refuzat accesul.

3.3 Compararea autentificrii Windows cu autentificarea SQL.
Cu toate c autentificarea Windows este metoda preferat de accesare a serverului
SQL, att autentificarea Windows ct i autentificarea SQL pot fi necesare n mediul de
afaceri. Urmtoarele seciuni vor oferi o justificare pentru punerea n aplicare a acestor
metode de autentificare.

3.3.1 Avantajele autentificrii Microsoft Windows
Atunci cnd un utilizator se conecteaz la un domeniu Windows , datele de conectare
sunt criptate nainte de a fi trecute la controlerul domeniului;
Dup ce utilizatorul este autentificat n domeniul Windows, parola nu este niciodat
trimis la SQL Server;
Toate tichetele Kerberos i jetoanele de acces sunt criptate;
Microsoft Windows accept politici de management al parolelor pentru a ntri
cerinele de securitate ale parolelor. Aceste politici pot ajuta la gestionarea unui mediu sigur;
Utilizatorul trebuie s tie un singur ID de conectare. Domeniul conturilor de utilizator
i al conturilor necesare pentru accesul la SQL Server sunt la fel;
Grupurile din Microsoft Windows pot primi permisiuni de acces la serverul SQL.
Acordarea acestor permisiuni poate scdea securitatea administrrii serverului;
Un singur nume de utilizator poate fi folosit pentru accesul la mai multe servere SQL.
Autentificarea SQL poate fi nc necesar n multe organizaii. De fapt, o organizaie
poate avea un singur server care accept autentificarea Windows i altul care permite
autentificare SQL, de asemenea. Acest metod de autentificare este potrivit atunci cnd nu
este realist pentru toi utilizatorii s se autentifice n domeniul Windows. Autentificarea SQL
este utilizat frecvent pentru aplicaiile Internet i pentru autentificarea n reelele care nu
folosesc Microsoft Windows. Autentificarea SQL este configurat prin setarea securitii
serverului SQL n modul mixt. n modul mixt, un DBA(DataBase Administrator) poate avea o
combinaie de conturi de securitate SQL i conturi de autentificare Windows pentru accesarea
unui singur server SQL. Metoda mixt de autentificare este, de asemenea, necesar pentru a
permite conectarea la un server SQL a mainilor de la Novell, Banyan, Apple i a clienilor
Unix.
Autentificarea SQL este folosit deoarece:
Microsoft Windows nu trebuie s autentifice utilizatorul. Acest lucru este benefic n
cazul n care v aflai ntr-un mediu care nu are un domeniu Windows;
Multe dintre aplicaiile de la teri nu suport autentificarea Windows. Autentificarea
SQL v ofer o mai mare flexibilitate atunci cnd avei de-a face cu furnizori din afar;
Cu autentificarea SQL putei separa securitatea Windows i securitatea SQL Server.
Dac se dorete separarea complet a modelelor de securitate, exist aceast opiune.




37

CAPITOLUL 4
Implementarea vederilor pentru baze de date
Microsoft SQL Server



4.1 Introducere
Multe modele de date create pentru a rula pe SGBD mari tind s devin prea mari i
denormalizate. Cele mai noi sisteme nu au un design extins pentru a aborda structura de date
i a o normaliza pentru a oferi cea mai bun performan a utilizrii suporilor magnetici de
stocare. Aceasta nu este, de obicei, o problem pn cnd serverul de baze de date ncepe s
funcioneze lent din cauza unor tabele suplimentare sau cnd spaiul de pe disc este epuizat
din cauza unor date stocate redundant. O structur de date normalizat i bine planificat
poate salva foarte mult spaiu pe disc i s ofere performan foarte bun pentru interogrile
ce ruleaz pe sistem. Indicele de utilizare este esenial pentru o performan a datelor
normalizate ridicat.
Sintaxa pentru crearea vederilor
Ca i n cazul celorlalte obiectele stocate n baza de date, o vedere este creat prin
utilizarea instruciunii Transact-SQL CREATE. Se poate cripta definiia unei vederi(opiunea
WITH ENCRYPTION) pentru mai mult securitate oferit obiectelor pe care se axeaz
crearea acesteia. Toi utilizatorii au posibilitatea de a accesa tabelele sistem, iar definiiile
vederilor sunt stocate n tabelul Syscomments din baza de date master. Pentru a obine textul
unei vederi (din CREATE VIEW), trebuie s explorm coninutul tabelei sistem
syscomments cu comanda:
exec sp_helptext nume_vedere
O alt opiune prezent n sintax este opiunea CHECK. Aceast opiune permite
vederii s verifice dac toate modificrile de date operate prin intermediul ei vor intra n
domeniul de filtrare a datelor din momentul crerii acesteia(impus prin clauza WHERE).
Dac o modificare va elimina din setul de rezultate o nregistrare inclus iniial, interogarea va
genera o eroare. Aceast opiune este util pentru vederile departamentale care trebuie s
restricioneze modificrile utilizator la un set de date definite n mod clar.
Exemplu de script pentru crearea de vederi :
/*
Syntaxa
CREATE VIEW [owner.] view_name
[(column_name [, column_name ])]
[WITH ENCRYPTION]
AS select_statement [WITH CHECK OPTION]
*/
CREATE VIEW titleAuthor
AS
SELECT title,
au_ord,
au_lname,
price,
ytd_sales,
pub_id
FROM authors, titles, titleAuthor
WHERE authors.au_id = titleAuthor.au_id
38

AND titles.title_id = titleAuthor.title_id
Vederea titleAuthor este o vedere eantion furnizat mpreun cu Microsoft SQL
Server. Acest vedere combin informaii din trei tabele ntr-o singur reprezentare n raport
cu care aplicaia client poate rula interogri sau proceduri stocate.
Date normalizate
Cheia normalizrii cu succes a datelor este analizarea atent a fiecrei entiti definite
i determinarea dac datele reprezentate ca un atribut al entitii sunt stocate potenial de
multe ori n seturi de nregistrari, fr schimbare. Localizarea datelor redundante este un prim
mare pas n normalizarea de date. Analizarea datelor se face la un nivel mai cuprinztoare
dect cel al unui tabel individual; trebuie cutate date redundante n mai multe tabele, care ar
putea fi combinate ntr-o singur tabel.
De exemplu, dac stocai adresa unui autor i adresa unui magazin n dou tabele
separate, ai putea dori s se combine ambele adrese ntr-un singur tabel. Aceast metod
economisete spaiu de disc i face gestionarea datelor dvs. mult mai uoar. Baza de date
Pubs oferit cu Microsoft SQL Server a fost normalizat la un anumit grad, astfel nct l
putei folosi ca o structur de date exemplu. n unele cazuri, Pubs poate este normalizat un
pic prea mult pentru utilizarea practic, dar, pe ansamblu, este un bun exemplu de normalizare
a datelor.
Scrierea de interogri pentru anumite modele complexe de date se poate dovedi a fi
foarte dificil. Aceste modele sunt, de obicei, prea normalizate i se poate aplica ingineria
invers pentru a mbunti performana i pentru a uura scrierea interogrilor. Dac gsii c
accesai n mod constant dou tabele mpreun, ai putea dori s luai n considerare
combinarea lor. Nu exist nici un anumit fel de a normaliza datele, i nimeni nu va deveni un
expert in normalizare, fr a avea o cunoatere bun a cererii de design i a caracteristicilor pe
care trebuie sa le suporte modelul de date.
Cteva dintre beneficiile normalizrii sunt:
Creterea vitezei de sortare i de creare/recreare de indeci (datorit scderii
dimensiunii tablelelor )
Indeci mai restrni i mai compaci
Mai puini indeci pe tabel, crescnd viteza de execuie pentru instruciunile
Transact-SQL INSERT, UPDATE i DELETE
Mai puine valori nule i date redundante, reducnd cantitatea de spaiu necesar
pe disc
Creterea performanelor la executarea diagnosticrilor cu instruciunea DBCC

Odat ce ai normalizat datele in modelul dvs., trebuie s prezentai datele la cererea
clientului sau utilizatorului ntr-un format uor de neles. Aici i intr in rol vederile. Putei
furniza titluri de coloane i formata sau converti datele n ceea ce utilizatorul se ateapt s
vad, mai degrab dect a implementa cea mai logic metod de a stoca datele pe server.
Date partiionate
O caracteristic util a unei vederi este faptul c utilizatorul final vede numai acele
coloane i rnduri la care dorii s le permitei accesul. Aceast vedere definete care coloane
s fie incluse i pstreaz datele la care nu oferii vizibilitate protejate.
Exemplu:
CREATE VIEW view_Authors
AS
SELECT au_id,
au_lname,
au_fname,
address,
39

city,
state,
zip
FROM authors

Permind utilizatorilor s interogeze vederea i nu tabela, ai implementat de fapt o
form de securitate la nivel de coloane. n timp ce Microsoft SQL Server suport securitatea
la nivel de coloan sau la nivel de tabel, folosirea de vederi pentru a ntri accesul este mult
mai eficient i consum mai puine resurse de sistem.
Partiii verticale
Partiionarea vertical a datelor ntr-o structur de tabel, dup cum se arat n
exemplul de mai sus, se realizeaz prin specificarea coloanelor n lista de coloane din cadrul
declaraiei SELECT. Modificarea vederii este la fel de simpl ca adugarea sau eliminarea
unui nume de coloan i recompilrea definiiei vedereii.
Partiii orizontale
Pentru a restriciona rndurile pe care le va conine o vedere, trebuie sa adugati o
clauz WHERE la definiia vederii (a se vedea exemplul urmtor). Acest exemplu de cod ar
putea fi aplicat la datele stocate pe divizii sau regiuni ntr-un tabel mare, pentru a limita
domeniul de aplicare a modificrii departamentelor pe subseturi de nregistrri din baza de
date.
Exemplu:
CREATE VIEW view_CA_Authors
AS
SELECT 'Author_ID' = au_id,
'Nume'= au_lname,
Prenume' = au_fname,
'Adresa' = address,
'Oras' = city,
'Stat' = state,
'Cod' = zip
FROM authors
WHERE state = 'CA'
Putei combina partiionrile orizontale i verticale pentru a furniza utilizatorilor date
clare, uor de citit. Observai c am folosit identificatori noi de coloane pentru a ajuta
utilizatorul s neleag setul de rezultate. Declaratia SELECT standard poate fi folosit n
definirea vederii pentru a oferi seturi de date lizibile pentru aplicaiile clientului.
Tabele multiple
Putei combina date din mai multe tabele ntr-o singur interogare, iar din
perspectiva utilizatorului final s par c provin dintr-un singur tabel. Chiar daca tabelele ce
stau la baza interogarilor pot fi la fel de multe ca i numrul de cmpuri ce apar n
instruciunea SELECT, nu este recomandat s vizualizai mai mult de 4 tabele (atta timp ct
instruciunea este SELECT).
De obicei, vederea este folosit ca prim nivel de securitate in baza de date. Se creeaz
interogrile pe baza necesitii clientului de a vizualiza date i de a traduce datele normalizate
ce stau la baza vizualizrii funcionale.
Valori calculate
Valorile calculate pot fi reinute in tabele, dar nu se recomand acest lucru, deoarece
pot aprea modificri care s afecteze coninutul cmpurilor din expresia calculat, ceea ce ar
impune recalcularea expresiei. Dac, de exemplu, utilizatorul dorete s vizualizeze un
procentaj de ctig sau o medie de pariere, se selecteaz coloana ce conine informaiile
40

necesare i se calculeaz valorile prin crearea unei coloane noi pentru a putea vizualiza
valorile dorite, evident prin intermediul unei vederi.
4.2 Clasificarea vederilor
Dac am dori s clasificm tipurile de vederi pe care le putem crea, am putea afirma c
ntlnim:
Vederi de tip proiecie (extrag coloane dintr-un tabel)
Exemplu:
CREATE VIEW vedere1
AS SELECT nume, prenume
FROM salarii
Vederi de tip jonciune
Aceste vederi conecteaz rnduri din dou sau mai multe tabele, comparnd valorile din
coloanele specificate. De exemplu, dac se dorete afiarea unei liste cu autorii din
tabelul autori i titlurile crilor scrise de acetia din tabelul titluri, se parcurg urmtorii
pai:
- deoarece ntre tabele exist o relaie mai muli la mai muli, se creaz un tabel
auxiliar, numit autori_titluri.











-
-
- se creeaz vederea (prin jonciunea celor trei tabele)
CREATE VIEW Autori_Titluri_View
AS SELECT autori.nume, autori.prenume, titluri.nume_titlu
FROM autori INNER JOIN autori_titluri
ON autori.au_id = autori_titluri.au_id
INNER JOIN titluri
ON titluri.titlu_id = autori_titluri.titlu_id
- putem face o interogare a vederii: de exemplu, ne intereseaz numele, prenumele si
titlurile crilor scrise de autorii al cror nume de familie incepe cu PO:
SELECT * FROM Autori_Titluri_View
WHERE nume LIKE PO%
Alte tipuri de vederi
Prin utilizarea functiilor de centralizare (AVG, SUM i COUNT), a coloanelor calculate
i a altor vederi se pot obine noi vederi. Vom vedea o vedere care conine coloane
calculate:
CREATE VIEW pret_carti_autor_view
AS SELECT au_id,titlu_id, cant * pret AS Total
FROM autori_titluri
1
n 1
autori
au_id
nume
prenume
telefon
adresa



au_id
titlu_id
pret
cant
autori_titluri


titlu_id
nume_titlu
titluri
n
41

4.3 Restricii la crearea vederilor
Pentru a executa instruciunea CREATE VIEW trebuie s fii membru al rolului server
prefixat sysadmin, ori al rolului baz de date prefixat db_owner sau db_ddladmin sau
trebuie s vi se fi acordat permisiunea CREATE VIEW.
De asemenea, trebuie s avei permisiunea SELECT pe toate tabelele sau vederile refereniate
n vedere. Pentru a evita situaia n care proprietarul vederii i cel al tabelelor refereniate
difer, se recomand ca utilizatorul special dbo s fie proprietarul tuturor obiectelor dintr-o
baz de date.
De aceea se specific dbo ca nume de proprietar cnd se creeaz obiectul, altfel va fi creat cu
numele dumneavoastr de utilizator ca proprietar.
Coninutul unei vederi se specific cu instruciunea SELECT i poate fi, cu unele limitri, ct
de complex dorii. Trebuie s specificai numele de coloane dac:
Oricare coloan a vederii deriv dintr-o expresie aritmetic, funcie intern sau
constant.
Coloanele vederii din tabelele joncionate au acelai nume.
Cnd creai vederi, luai n considerare urmtoarele restricii:
Instruciunea CREATE VIEW nu poate include clauzele COMPUTE sau COMPUTE
BY sau cuvntul cheie INTO.
Instruciunea CREATE VIEW poate include clauza ORDER BY numai dac se
folosete cuvntul cheie TOP.
Vederile nu pot referenia tabele temporare.
Vederile nu pot referenia mai mult de 1024 de coloane.
Instruciunea CREATE VIEW nu poate fi combinat cu alte instruciuni Transact-SQL
ntr-un singur batch.
Exemplu:
Se creeaz o vedere care folosete o coloan calculat Subtotal(valoarea comenzii) pentru o
anumit comand utiliznd coloanele UnitPrice, Quantity i Discount:
CREATE VIEW dbo.OrderSubtotalsView (OrderID, Subtotal)
AS
SELECT OD.OrderID,
SUM(CONVERT
(money,(OD.UnitPrice*Quantity*(1- Discount)/100))*100)
FROM [Order Details] OD
GROUP BY OD.OrderID
GO

Pentru a afia rezultatul se folosete interogarea:
SELECT * FROM OrderSubtotalsView
4.4 Modificarea i tergerea vederilor
Vederile se pot modifica de foate multe ori ca urmare a cererilor venite de la utilizatori
ori ca urmare a schimbrii structurii tabelelor refereniate. Putei modifica o vedere tergnd-o
i recrend-o sau prin execuia instruciunii ALTER VIEW.
Modificarea vederilor
Instruciunea ALTER VIEW modific definiia vederilor, incluznd vederile indexate, fr a
afecta procedurile stocate i triggerele care depind de ele. Instruciunea v permite s reinei
permisiunile acordate vederilor. Dac, n schimb, tergei o vedere i o recreai trebuie s
reasignai permisiunile acordate anterior.
Sintaxa:
ALTER VIEW owner.view_name
42

[(column [,...n ])]
[WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA} [,...n]]
AS
select_statement
[WITH CHECK OPTION]
Dac utilizai opiunea WITH CHECK OPTION, WITH ENCRYPTION, WITH
SCHEMABINDING sau WITH VIEW_METADATA cnd creai vederea, trebuie s o
includei n instruciunea ALTER VIEW dac dorii s reinei funcionalitatea
opiunii(opiunilor).
Urmtorul exemplu modific vederea EmployeeView pentru a aduga coloana Extension:
USE Northwind
GO
ALTER VIEW dbo.EmployeeView
AS
SELECT LastName, FirstName, Extension
FROM Employees
SELECT * from dbo.EmployeeView
Obs.: Dac definii o vedere cu instruciunea SELECT * i apoi modificai structura tabelelor
folosite prin adugarea de coloane, noile coloane nu apar n vedere. Cnd se selecteaz
coloanele ntr-o instruciune CREATE VIEW, lista de coloane este interpretat numai la
prima creare. Pentru a vedea noile coloane n vedere, trebuie s o modificai(cu ALTER).
tergerea vederilor
Vederile pot fi terse folosind instruciunea DROP VIEW; n urma tergerii se elimin corpul
acesteia i permisiunile care i-au fost asignate. Dac vor fi interogate vederi care refereniaz
vederea tears, se primete un mesaj de eroare. tergerea unui tabel refereniat n vedere nu
elimin vederea n mod automat-va trebui s-o tergei explicit.
Permisiunea de-a terge vederea o are proprietarul acesteia i nu este transferabil. Totui,
administratorul de sistem sau proprietarul bazei de date poate terge orice obiect specificnd
numele proprietarului n instruciunea DROP VIEW.
SQL Server permite proprietarului s menin controlul utilizatorilor autorizai s acceseze
obiectul. Vederile depind de anumite obiecte(tabele sau vederi). Aceste dependene pot fi
vzute ca un lan de proprietari. Dac proprietarul vederii este proprietarul i al obiectelor
refereniate, numai el trebuie s acorde permisiuni pe vedere. Cnd se utilizeaz obiectul,
permisiunile sunt verificate numai pe vedere. Pentru a evita ruperea lanului de proprietari,
utilizatorul dbo ar trebui s fie proprietarul tuturor vederilor. Cnd se folosete obiectul, se
verific permisiunile pentru fiecare obiect refereniat i care are un proprietar diferit.
Exemplu
Maria creeaz vederea view2. Ea acord permisiunea lui Pierre s-o interogheze cu
instruciunea:
GRANT SELECT ON view2 TO pierre
Oricum, maria.view2 depinde de un obiect (view1) care-l are proprietar pe Lucia.
Permisiunile vor fi verificate pentru orice obiect refereniat cu proprietar diferit. Pierre
interogheaz vederea cu instruciunea:
SELECT * FROM maria.view2
Deoarece maria.view2 depinde de lucia.view1,SQL Server verific permisiunile acestuia pe
obiectele maria.view2 i lucia.view1. Dac Lucia a acordat anterior permisiunea lui Pierre pe
view1, i se permite acestuia accesul pe view1, altfel accesul i este interzis, permindu-i
Luciei s controleze cine este autorizat s acceseze obiectele create de ea.
43

4.5 Afiarea informaiilor despre vederi
Putei vizualiza coninutul unei vederi(instruciunea SELECT folosit la creare)
utiliznd SQL Server Enterprise Manager/SQL Server Management Studio sau interognd
urmtoarele vederi i tabele sistem(Tab. 4.1):

Vederea Information Schema sau tabel sistem Afieaz
INFORMATION_SCHEMA.TABLES sau sysobjects Numele vederii
INFORMATION_SCHEMA.VIEW_TABLE_USAGE
sau sysdepends
Numele obiectelor folosite
INFORMATION_SCHEMA.VIEWS sau syscomments Coninutul vederii
INFORMATION_SCHEMA.VIEW_COLUMN_USAGE
or syscolumns
Coloanele definite n vedere

Tabelul 4.1 Afiarea coninutului unei vederi

Pentru a afia textul instruciunii SELECT folosit la crearea vederii, apelai utilitarele SQL
Server Enterprise Manager/SQL Server Management Studio, care interogheaz vederea
INFORMATION_SCHEMA.VIEWS, sau folosii procedura stocat sistem sp_helptext
objname.
Localizarea obiectelor de care depind vederile
Pentru a obine un raport cu tabelele i vederile de care depinde o vedere sau care sp_depind
de o vedere, folosii utilitarele SQL Server Enterprise Manager/SQL Server Management
Studio sau procedura stocat sistem sp_depends. Dependenele ar trebui vzute nainte de a
terge obiectul:
sp_depends objname
Ascunderea coninutului unei vederi
Deoarece utilizatorii pot afia coninutul unei vederi cu SQL Server Enterprise Manager/SQL
Server Management Studio sau interognd tabela sistem syscomments, putei interzice
aceasta
folosind opiunea WITH ENCRYPTION la crearea vederii.
nainte de a cripta vederea, asigurai-v c definiia acesteia este salvat ntr-un fiier. Pentru
a decripta textul vederii, trebuie s-o tergei i s-o recreai sau s modificai vederea(ALTER
VIEW) i s folosii sintaxa original.
Exemplu
n acest exemplu se creeaz vederea dbo.[Order Subtotals], utiliznd opiunea WITH
ENCRYPTION pentru a ascunde definiia acesteia:
USE Northwind
GO
CREATE VIEW dbo.[Order Subtotals]
WITH ENCRYPTION
AS
SELECT OrderID,
Sum(CONVERT(money,(UnitPrice*Quantity*(1-Discount)/100))*100)
AS Subtotal
FROM [Order Details]
GROUP BY OrderID
Cnd considerentele de securitate primeaz, folosii criptarea i nu tergei niciodat intrri
din tabela syscomments nu vei putea vedea coninutul vederii i nu permite SQL Server s
recreeze vederea cnd facei upgrade al unei baze de date pentru o versiune mai nou.
44

4.6 Modificarea datelor prin vederi
Ori de cte ori modificai datele prin intermediul vederilor, de fapt modificai tabelele
din care se extrag datele la crearea vederii. Cu unele restricii, putei insera, modifica sau
terge date dintr-un tabel folosind vederile. n general, vederea trebuie s fie definit pe un
singur tabel i nu trebuie s foloseasc funcii agregat(SUM, AVG, MIN, MAX,etc) sau
clauza GROUP BY n instruciunea SELECT.
Modificrile fcute prin intermediul vederilor trebuie s respecte urmtoarele condiii:
Nu pot afecta mai mult de un tabel.
Putei modifica vederi care deriv din mai multe tabele, dar fiecare actualizare sau
modificare poate afecta doar o tabel.
Nu pot fi fcute pe anumite coloane. SQL Server nu permite s modificai o coloan
calculat sau care conine funcii sistem sau agregat.
Nu pot fi modificate coloane care nu sunt refereniate n vedere. Se va primi un mesaj
de eroare, de exemplu, dac inserai o linie ntr-o vedere definit pe o tabel care
conine coloane nerefereniate n vedere i care nu permit valori de tip NULL sau
implicite.
Se verific prezena opiunii WITH CHECK OPTION i dac este folosit n
instruciunea SELECT, serverul va respinge orice modificare ulterioar aflat n afara
domeniului specificat.
4.7 Folosirea vederilor indexate
Se pot crea indeci pentru vederi. O vedere indexat stocheaz rezultatul unei vederi
dintr-o baz de date(nregistrrile extrase)- folosirea vederilor indexate sporete viteza de
extragere a nregistrrilor din tabele. Creai o vedere indexat implementnd indexul
UNIQUE CLUSTERED pe o vedere - rezultatele vederii sunt pstrate n nodurile frunz ale
indexului de tip cluster. Dup ce se creeaz indexul UNIQUE CLUSTERED, putei crea ali
indeci pe acea vedere. O vedere indexat reflect automat modificrile fcute n tabelele
utilizate, pentru c indexul UNIQUE CLUSTERED este actualizat i el.
Optimizatorul de interogri determin automat dac o interogare poate beneficia de folosirea
unei vederi indexate, chiar dac interogarea nu o refereniaz.
Se recomand crearea de vederi indexate cnd:
Creterea vitezei de extragere a nregistrrilor e mai important dect costurile de
mentenan a indecilor.
Datele sunt actualizate rar.
Interogrile din vederi fac joinuri multiple i agregri care proceseaz multe
nregistrri sau sunt executate frecvent de ctre muli utilizatori.
Dac vom utiliza vederile indexate, vom avea i o serie de restricii:
Primul index creat pe o vedere trebuie s fie unique clustered.
Vederea trebuie creat cu opiunea SCHEMA BINDING.
Vederea poate referenia tabele, dar nu i alte vederi.
Tabelele i funciile folosite n vedere trebuie s aib sintaxa de apel
nume_proprietar.nume_obiect.
Conexiunile ulterioare ale utilizatorului trebuie s foloseasc aceleai setri pentru a
utiliza vederile indexate.

45

4.8 Folosirea vederilor pentru a partiiona datele
Putei folosi vederile pentru a partiiona datele din mai multe baze de date sau instane
SQL Server pentru a mbunti performana. Pentru aceasta, se utilizeaz operatorul UNION
ntr-o vedere pentru a combina rezultatele obinute din dou sau mai multe interogri din
tabele separate ntr-un singur set acest lucru apare utilizatorului ca o singur tabel numit
vedere partiionat. Putei modifica vederile partiionate, chiar dac refereniaz tabele
multiple.
Ele se bazeaz pe date obinute din surse heterogene, cum ar fi servere aflate la distan, i nu
doar pe tabele din aceeai baz de date.
Dac tabelele dintr-o vedere partiionat sunt pe servere diferite sau pe un calculator cu mai
multe procesoare, fiecare tabel poate fi scanat n paralel, aceasta mbuntind performana
interogrii respective. Nu se pot crea indeci pe vederi partiionate(vederile indexate cer
folosirea obiectelor cu sintaxa proprietar.obiect, iar vederile indexate folosesc sintaxa de apel
de forma Servername.databasename.ownername.objectname) .




































46

CAPITOLUL 5
Implementarea procedurilor stocate pentru baze de date
Microsoft SQL Server


5.1 Introducere
n acest capitol se vor prezenta procedurile stocate i avantajele utilizrii acestora pe
serverul de baze de date Microsoft SQL Server. De asemenea, vom prezenta o serie de
elemente privind modalitile de folosire i respectiv privind integrarea procedurilor stocate n
cadrul diverselor aplicaii realizate. n plus, vor mai fi expuse cteva exemple practice de
utilizare i implementare a acestei tehnologii.
Dezvoltarea aplicaiilor de baze de date presupune gsirea de soluii care s permit
construcia eficienta i posibilitatea de modificare a procedurilor care realizeaz operaiunile
asupra informaiei incluse n bazele de date. Procedurile stocate pe serverul de baze de date
sunt soluia principal pentru crearea unor aplicaii performante, constituind n acelai timp
modalitatea cea mai eficient de implementare a operaiunilor asupra bazelor de date n
sistemele client/server.
Definirea procedurilor stocate
Procedurile stocate reprezint o colecie precompilat de instruciuni SQL salvate pe
serverul de baze de date sub un nume unic (pentru o anumit schem) i procesate unitar. Ele
permit utilizatorului s realizeze operaiuni complexe asupra bazei de date prin intermediul
unui singur apel transmis de aplicaia surs. De asemenea, utilizatorul are posibilitatea de a
folosi variabilele declarate, instruciunile condiionale i alte elemente puternice de
programare. Procedurile stocate sunt o component omniprezent n cadrul sistemelor de baze
de date relaionale bazate pe tehnologia client/server (MS SQL Server sau Oracle).
Avantajele utilizrii procedurilor stocate
Prezentm cteva dintre avantajele fundamentale care rezult din folosirea acestor
obiecte:
- Procedurile stocate sunt salvate ntr-o form compilat, deci prezint o viteza de execuie
mai mare dect a unor interogri SQL realizate ad-hoc.
- Exist posibilitatea de a executa o succesiune de instruciuni SQL n cadrul unei singure
proceduri stocate.
- n cadrul unei proceduri stocate exist posibilitatea de a face referin la alte proceduri
stocate, ceea ce determin posibilitatea de execuie nlnuit a acestora.
- Facilitatea de a folosi un set suplimentar de instruciuni fa de standardul SQL determin
creterea flexibilitii acestora. De asemenea, instruciunile condiionale sau repetitive
permit construcia unor adevrate programe de manipulare a bazelor de date.
- Posibilitatea de utilizare a variabilelor determin, printre altele, facilitatea de a construi
interogri SQL parametrizabile.
- Asupra procedurilor stocate pot fi setate drepturi de acces, independent de cele care au
fost acordate asupra celorlalte elemente ale bazei de date (tabele, indeci, vederi etc.).
- De asemenea, prin intermediul procedurilor stocate este posibil "ruperea" nivelului
aplicaiei de baze de date i a elementelor de interfa ale acesteia de nivelul propriu-zis al
bazei de date. n acest mod, modificrile ce vor afecta procedurile de manipulare a datelor
se vor realiza direct la nivelul bazei de date, neafectnd sursele propriu-zise ale aplicaiilor
(aplicaia nu va include dect instruciunile de execuie a procedurilor stocate).
- Utilizarea procedurilor stocate permite diminuarea fluxului de date n reea micornd
secvenele de cod SQL ce sunt transmise serverului;
- Deoarece planurile de execuie sunt pstrate de server, performanele aplicaiilor pot fi
mbuntite n mod semnificativ.
47

5.2 Crearea procedurilor stocate utilizator
Utilizarea procedurilor stocate presupune parcurgerea urmtoarelor etape:
1. Crearea procedurii (prin intermediul comenzii CREATE PROCEDURE).
2. Executarea de ctre utilizator (prin intermediul unei comenzi EXEC).
3. Compilarea (n timpul unei comenzi EXEC serverul va compila i optimiza
procedura).
4. Executarea de ctre server (conform planului de execuie compilat al procedurii).
Pentru a crea o procedur stocat se poate iniia o nou interogare n baza de date
(New Query) i se va utiliza comanda:
CREATE PROCEDURE nume_procedura AS instruciuni_SQL
Pentru a modifica o procedur stocat se va utiliza comanda:
ALTER PROCEDURE nume_procedura AS instruciuni_SQL
O procedur stocat poate conine orice fel de instruciuni SQL valide, cu cteva
excepii, dintre care amintim: CREATE PROCEDURE, CREATE VIEW i CREATE
TRIGGER (poate ns conine comenzi de tip CREATE TABLE sau chiar CREATE
DATABASE).
Procedurile stocate pot fi create i prin intermediul interfeei oferite de Microsoft SQL
Server Management Studio. n cadrul ferestrei Object Explorer, procedurile stocate pot fi
vizualizate n cadrul coleciei Programmabilty .



Figura 5.1

Exemplul 1:

CREATE PROCEDURE ListaAngajati2010 AS
SELECT Nume, DataAngajare FROM Angajati
WHERE DataAngajare BETWEEN 1/1/2010 AND 12/31/2011


Lansarea n execuie a procedurii stocate se poate realiza prin simpla specificare a
numelui acesteia, sau prin plasarea instruciunii EXEC naintea numelui procedurii:

EXEC ListaAngajati2010


48


Figura 5.2

Exemplul 2:

Folosind tabela creat la Exemplu 1, se insereaz cteva nregistrri. Se dorete s
se creeze o procedur stocat care s tearg un anumit articol din tabela angajai.

CREATE PROCEDEURE TERGERE (codang IN NUMBER) IS
BEGIN
DELETE FROM Angajai WHERE cod angajat= codang;
END

5.3 Crearea procedurilor stocate sistem
n afara procedurilor definite de utilizatori, SQL server pune la dispoziia
programatorilor o serie de proceduri predefinite ce sunt memorate n baza de date Master.
Aceste proceduri permit executarea unor rutine utile i sunt caracterizate prin prefixul sp_ n
faa numelui de procedur.
Cteva exemple de astfel de proceduri sunt:

sp_databases permite afisarea listei bazelor de date de pe server
sp_columns permite afiarea informaiilor privind coloanele unui tabel specificat ca
parametru
sp_executesql permite executarea unor instruciuni SQL specificate ca parametru
sp_help afieaz toate informaiile disponibile privind un anumit obiect din baza
de date
sp_rename permite redenumirea obiectelor din baza de date
sp_spaceused afiseaza numrul de nregistrri i spaiul utilizat de un anumit tabel sau
view pe server

5.4 Declararea variabilelor i folosirea parametrilor
n cadrul procedurilor stocate se pot utiliza variabile pentru a facilita prelucrarea
datelor. Variabilele se declar n cadrul instruciunilor ce urmeaz dup cuvntul cheie AS din
definiia procedurii stocate prin intermediul unei instruciuni DECLARE. Numele de
49

variabile sunt precedate de simbolul @. Atribuirea unei valori se poate realiza prin
instruciunile SET sau SELECT.

Exemplul 3:

CREATE PROCEDURE Impozite AS
DECLARE @cota as numeric(3,2)
SET @cota = 0.16
SELECT Nume, Salariu, Salariu*@Cota As [Impozit de plata]
FROM ANGAJATI

Parametrizarea procedurilor stocate
Parametrii procedurilor SQL Server sunt de doua tipuri:
- Parametri de intrare (Input)
- Parametri de ieire (Output)
Parametrii de intrare permit preluarea n cadrul procedurilor stocare a unuia sau mai
multor elemente variabile ce pot fi utilizate n cadrul expresiilor. Parametrii de ieire sunt
utilizai pentru returnarea de rezultate n urma prelucrrilor efectuate de procedura stocat.
O sintax simplificat a comenzii CREATE PROCEDURE, care permite i
adugarea de parametri, este prezentat n continuare:

CREATE PROCEDURE nume_procedura [;numr]
[ [ @parametru tip_de_date] [OUTPUT] [ , .n] ]
AS { <instruciuni SQL> [;] [. n ;]}

Procedurile pot utiliza mai muli parametri de tip input (tipul implicit de parametru,
dac nu se specific opiunea OUT). Parametrii nsoii de opiunea OUT sunt tratai ca
parametri de ieire (output) i sunt utilizai pentru a returna valori.

Exemplul 4:

Parametrizai procedura din Exemplul 1 pentru a selecta doar persoanele de la un
anumit departament, ale cror salarii depesc o anumit limit. Limita salarial i codul
departamentului vor fi precizate prin parametri. ntruct procedura a fost deja creat la
Exemplul 1 (ListaAngajati2010), vom utiliza comanda ALTER PROCEDURE pentru
modificare, n loc de CREATE PROCEDURE.

ALTER PROC ListaAngajai2010
@sal money,
@Depart Char(3)
AS
SELECT Nume, DataAngajare FROM Angajai
WHERE DataAngajare BETWEEN '1/1/2011' AND '12/31/2011'
AND Salariu>@sal AND CodDepartament=@depart

Pentru a lansa n execuie o astfel de procedur trebuie atribuite valori parametrilor.
Atribuirea de valori se poate realiza prin enumerarea valorilor parametrilor n aceeai ordine
n care au fost declarai n procedur sau prin specificarea exact a numelui parametrului n
faa fiecrei valori:

50

EXEC ListaAngajai2010 1900, 'IT'
sau
EXEC ListaAngajai2010 @sal=1900, @depart='IT'

Comenzile prezentate mai sus vor afia lista persoanelor angajate n 2011 la
departamentul IT care au salarii peste 1900 RON.
n exemplul precedent, nespecificarea valorii pentru unul dintre cei doi parametri va
genera o eroare i imposibilitatea de a executa procedura. Pentru a prentmpina astfel de
situaii, parametrilor de intrare li se pot asocia valori implicite care vor fi utilizate atunci cnd
nu se precizeaz o alt valoare.
Pentru a atribui valoarea implicit 1000 parametrului @sal i valoarea fin
parametrului @depart se va modifica procedura astfel:

ALTER PROCEDURE ListaAngajai2010
@sal money = 1000,
@Depart Char(3) = 'fin' AS
AS
SELECT Nume, DataAngajare FROM Angajai
WHERE DataAngajare BETWEEN '1/1/2011' AND '12/31/2011'
AND Salariu>@sal AND CodDepartament=@depart


Exemplul 5:

Pentru a exemplifica utilizarea parametrilor de ieire vom lua n considerare
urmtoarea situaie: Se dorete calculul unei prime pentru toi salariaii. Prima va fi egal cu
50% din valoarea salariului propriu + 10% din valoarea celui mai mare salariu din firm.

1. Vom crea o pocedur stocat pentru a determina salariul maxim. Procedura va conine
un parametru de tip OUTPUT care va prelua valoarea salariului maxim calculat pe
ansamblul firmei.



CREATE PROCEDURE AflaSalariuMaxim
@SalMax Money OUTPUT
AS
SELECT @SALMAX=MAX(SALARIU)
FROM Angajai

2. Pentru a calcula prima fiecrui angajat conform algoritmului propus este necesar s
executm procedura anterior creat i s prelum valoarea parametrului de tip Output ntr-o
variabil de memorie.

DECLARE @VariabilaSalariu AS money
EXECUTE AflaSalariuMaxim @VariabilaSalariu OUTPUT=@SalMax
SELECT Nume, Salariu, Salariu*0.5 + @VariabilaSalariu*0.1 AS PRIMA
FROM Angajai


51

Instruciunea RETURN

Prin intermediul comenzii RETURN, se poate fora ntreruperea execuiei unei
proceduri stocate. Comenzile ce urmeaz dup instruciunea RETURN nu vor mai fi
executate.
Sintaxa instruciunii return este RETURN [ expresie de tip intreg ]
Dup cum se poate observa, opional, dup instruciunea RETURN se poate preciza
un numr ntreg ce poate fi utilizat ulterior n cadrul blocului de instruciuni ce a lansat n
execuie procedura.

Exemplul 6:

S se creeze o procedur stocat pentru a afia datele unui angajat al crui CNP este
specificat ca parametru. n cazul n care parametrul nu este specificat (rmne NULL) se va
afia un mesaj de eroare.

CREATE PROCEDURE DateAngajat
@cnp char(13) = NULL
AS
IF @cnp IS NULL
BEGIN
PRINT Nu ai furnizat un cnp!
RETURN
END
ELSE
SELECT * FROM Angajai WHERE cnp = @cnp

Orice procedur stocat care se execut cu succes va returna valoarea zero. Procedurile
stocate care provoac la execuie o eroare vor returna un cod negativ (de la -1 la -14).

5.5 Controlul fluxului de execuie
Transact SQL permite realizarea de prelucrri complexe n cadrul procedurilor stocate
prin intermediul instruciunilor ce controleaz fluxul execuiei n pachetele de comenzi.
Instruciunile de limbaj pentru controlul fuxului n Trasnasct SQL faciliteaz crearea de
structuri alternative sau repetitive complexe.
Cele mai importante instruciuni din aceast categorie sunt:

IF ELSE
WHILE
GO TO
WAIT FOR
BREAK
CONTINUE

Exemplul 7:

Exemplu cu variabile de memorie: n tabela Angajai exist pentru fiecare salariat
DataAngajare i DataPlecare n/din firm. Realizai o procedur stocat cu parametru care
s vizualizeze, pentru o anumit persoan (CNP-ul transmis ca parametru), care au fost
angajaii care au lucrat n firm cu respectivul angajat(pe perioada cnd acesta era angajat).
52



CREATE PROCEDURE Vizualizare
@cnp AS CHAR(13)
DECLARE @Data1 AS datetime
DECLARE @Data2 AS datetime
//Se memoreaz data angajrii i data plecrii angajatului n dou variabile
SET @Data1 = (SELECT DataAngajare FROM Angajai WHERE cnp = @cnp)
SET @Data2 = (SELECT DataPlecare FROM Angajai WHERE cnp = @cnp)
SELECT Nume, DataAgajare, DataPlecare FROM Angajai WHERE
DataAngajare BETWEEN @Data1 AND @Data2 // salariaii venii n timpul n care a
lucrat agajatul
OR DataPlecare BETWEEN@ Data1 AND @ Data2 // salariaii plecai n intervalul n
care a lucrat angajatul

Concluzii
Procedurile stocate constituie, incontestabil, o cale pentru eficientizarea operaiunilor
realizate asupra bazelor de date. Acest lucru se impune din cel puin dou elemente eseniale:
primul const n forma compilat a acestora, fapt ce determin rularea mai rapid; iar cel de-al
doilea privete elementele de programare n cazul aplicaiilor de baze de date, procedurile
stocate determinnd n acest sens o integrare mai fireasc a elementelor de limbaj SQL.






























53

CAPITOLUL 6
Implementarea triggerelor pentru baze de date
Microsoft SQL Server



6.1 Introducere
Un declanator (trigger) este o procedur stocat care este executat n mod implicit
cnd asupra tabelului asociat se execut o comand insert, update sau delete.
Declanatoarele sunt medii prin care SQL ofer programatorilor de aplicaii i proiectanilor
de baze de date asigurarea integritii datelor.
Declanatoarele sunt utile deoarece impun reguli fr a fi cuprinse n aplicaiile utilizatorilor.
Proiectantul declanatorului specific i momentul cnd trebuie executat n raport cu
instruciunile Limbajului de Manipulare a Datelor(LMD).SQL Server ia n seam regulile i
valorile implicite nainte ca informaiile s fie scrise n baza de date.
Acestea reprezint pre-filtre care pot s mpiedice manipulrile de date, prin controlarea
activitilor din cadrul bazei de date. Un declanator poate fi i un post-filtru care se execut
dup ce modificarea datelor a trecut de reguli.
Declanatorii permit s executm o procedur rezident ori de cte ori este executat o
instruciune INSERT, UPDATE sau DELETE asupra unui tabel predefinit. Declanatorul
este o procedur special stocat care:
- genereaz automat anumite valori ce deriv din valorile coloanelor;
- determin respectarea restriciilor i privilegiilor ;
- face posibil jurnalizarea transparent a evenimentelor;
- strnge informaii statistice n legtur cu accesarea tabelelor.
Un declanator este o procedur stocat special care este executat de SQL Server la
efectuarea unei operaii de inserare, modificare sau tergere. Pentru c declanatorii sunt
executai dup efectuarea operaiei de inserare, modificare sau tergere, ei reprezint un fel de
ultim cuvnt la acestea. Dac un declanator respinge cererea, modificarea informaiilor este
refuzat, iar aplicaia care a iniiat operaia trimite un mesaj de eroare. Cea mai simpl
utilizare este determinat de impunerea regulilor de integritate n baza de date.
Observaie: Deoarece declanatoarele sunt executate dup regulile de integritate, dac
acestea nu sunt trecute atunci declanatorul nu este executat. Pentru ca un declanator s fie
executat trebuie ca operaia n cauz s nu fi euat.
Componentele unui declanator
Un declanator are trei componente:
- o instruciune de declarare aceasta specific instruciunile SQL care activeaz
declanatorul;
- o restricie de declanare specific condiia care trebui s fie adevarat pentru ca
declanatorul s fie activat;
- aciunea declanatorului, care specific blocul de instruciuni ce trebuie executate.
Pentru a crea un declanator trebuie s fii proprietarul bazei de date. Atunci cnd se adaug
un declanator pentru o coloan, linie sau tabel se schimb uneori i modul de accesare i felul
cum interacioneaz alte obiecte cu acesta. La folosirea obiectelor declanator se presupune
respectarea condiiilor:
- Declanatoarele nu pot fi create pentru tabele temporare.
- Declanatoarele trebuie s fie create numai pentru tabele din baza de date curent.
- La eliminarea unui tabel, toate obicetele declanator asociate cu acest tabel sunt eliminate
automat mpreun cu tabelul.
Crearea unui declanator se realizeaz cu instruciunea:
54


CREATE TRIGGER nume_declanator
ON { Nume_ tabel | Nume_ view }
[ WITH ENCRYPTION ]
{
{ { FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [
DELETE ] }
[ WITH APPEND ]
[ NOT FOR REPLICATION ]
AS
[ { IF UPDATE ( coloana )
[ { AND | OR } UPDATE ( coloana ) ] [ ...n ]
| IF ( COLUMNS_UPDATED ( ) { bitwise_operator } updated_bitmask )
{ operator de comparare } coloana_bitmask [ ...n ]
} ]
Instruciuni_SQL [ ...n ]
}
}

Sau urmtoarea form mai simpl

CREATE TRIGGER [posesor.]nume_declanator
ON [posesor.]nume_tabela
FOR {INSERT, UPDATE, DELETE }
[WITH ENCRYPTION]
AS
Instruciuni SQL , unde:

Nume_declanator este numele declanatorului (trigger-ului). Un nume de declanator
trebuie s respecte regulile pentru identificatori i trebuie s fie unic n cadrul unei baze de
date.
Nume_ tabel | Nume_ view este numele tabelului sau vederii n care declanatorul este
executat.
INSERT, UPDATE, DELETE - acestea definesc scopul declanatorului i specific operaiile
care iniiaz declanatorul.
WITH ENCRYPTION aceast opiune este utilizat pentru a mpiedica utilizatorii s
citesc definiia declanatorului dup ncrcarea lui pe server. SQL Server stocheaz definiia
unui declanator n tabela sistem syscomments, din baza de date master. Cripteaz intrrile
n tabela syscomments care conine textul comenzii CREATE TRIGGER.
AFTER specific faptul c declanatorul este executat doar cnd toate operaiile din enunul
SQL al declanatorului au fost execuate cu succes. Toate aciunile refereniale n cascad i
verificrile de constrngere, de asemenea trebuie s reuseasc nainte de executarea acestui
trigger. Folosirea clauzei AFTER este identic cu folosirea clauzei FOR utilizat mai mult n
ultimele versiuni de SQL Server. Declanatorii AFTER nu pot fi definii pentru vederi.
INSTEAD OF specific faptul c declanatorul este executat n locul enunului SQL
declanat, astfel suprapunnd operaiile din enunul declanatorului.
Acest tip de declanator poate fi definit pentru un tabel sau pentru o vedere cnd se realizeaz:
INSERT, UPDATE sau DELETE.
Este posibil s definim vederi unde fiecare s aib propriul declanator INSTEAD OF.
55

{ [DELETE] [,] [INSERT] [,] [UPDATE] } - sunt cuvinte cheie care specific pentru ce
operaie are loc declanatorul. Este obligatorie apariia cel puin a unei opiuni.
Pentru declanatori INSTEAD OF, opiunea DELETE nu este permis pentru tabelele care au
legturi refereniale ce specific o aciune n cascad pentru opiunea ON DELETE.
Asemntor, opiunea UPDATE nu este permis pe tabele care au legturi refereniale ce
specific o aciune n cascad pentru opiunea ON UPDATE.
Instruciuni_sql reprezint condiia (condiiile) i aciunea (aciunile) declanatorului.
Aciunile declanatorului sunt scrise n Transact-SQL i pot cuprinde oricte instrucini sau
comenzi Transact-SQL. Cteva tabele speciale, de care am mai amintit, sunt folosite n
instruciunea CREATE TRIGGER i anume: inserted i deleted.
IF UPDATE (coloana) testeaz aciunea unei comenzi INSERT sau UPDATE pentru
coloana specificat i nu este folosit pentru DELETE. Mai multe coloane pot fi specificate.
Deoarece numele tabelului este specificat dup clauza ON, nu este nevoie s includem numele
tabelului nainte de numele coloanei n clauza IF UPDATE. Pentru a testa o adugare sau o
modificare pentru mai multe coloane, specificm separat clauza UPDATE(coloana) dup ce
am scris-o pe prima. IF UPDATE va returna valoarea TRUE n aciunea INSERT deoarece
coloanele vor fi explicit sau implicit (NULL) inserate.
Coloana este numele unei coloane pentru testarea aciunii INSERT sau UPDATE. Aceast
coloan poate avea orice tip de date SQL Server.Oricum coloanele calculate nu pot fi utilizate
n acest context.
IF (COLOANAS_UPDATED()) testeaz, dac ntr-un declanator INSERT sau UPDATE,
coloanele menionate au fost inserate respectiv modificate.
COLOANAS_UPDATED returneaz un tip varbinary (tip binar variabil) ce indic ce
coloane din tabel au fost inserate sau modificate.
Funcia COLOANAS_UPDATED returneaz biii n ordine de la stnga la dreapta, cu
cel mai puin semnificativ bit n partea cea mai din stnga. Cel mai din stnga bit reprezentnd
prima coloan din tabel, urmtorul bit reprezentnd cea de-a dou coloan etc.
COLOANAS_UPDATED returneaz mai muli octei pentru declanatorul care a fost creat
coninnd mai mult de 8 coloane, cu cel mai puin semnificativ byte n partea din stnga.
COLOANAS_UPDATED va returna TRUE pentru toate coloanele din aciunea
INSERT deoarece coloanele au fost inserate cu valori explicite sau cu valori implicite
(NULL).
COLOANAS_UPDATED poate fi folosit oriunde n corpul declanatorului.
bitwise_operator este un operaor pe bit folosit n comparri.
updated_bitmask este o masc de tip ntreg pentru acele coloane care tocmai au fost
modificate sau inserate. De exemplu, tabela t1 conine coloanele C1, C2, C3, C4 i C5.
Pentru a verifica dac coloanele C2, C3 i C4 sunt toate modificate (tabela t1 avnd un
declanator UPDATE), specific valoarea 14 (01110). Pentru a verifica dac doar coloana C2
este modificat, specific valoarea 2(00010).
Operaor de comparare este unul din operatorii de comparare. Folosii semnul egal (=)
pentru a verifica dac toate coloanele specificate n updated_bitmask sunt realmente
modificate.Folosii semnul mai mare (>) pentru a verifica dac oricare sau cteva din
coloanele specificate n updated_bitmask sunt modificate.
Coloana_bitmask este o masc de tip ntreg pentru acele coloane pentru care verificm dac
au fost modificate sau inserate.
SQL Server permite declanatori multiplii ce pot fi creai pentru fiecare eveniment de
modificare de date (DELETE, INSERTsau UPDATE). De exemplu, dac este executat
CREATE TRIGGER FOR UPDATE pentru un tabel care deja are un declanator UPDATE,
atunci este creat un declanator adiional de tip UPDATE.

56

6.2 Exemple de triggere
Exemplul 1:
Declanator ce afieaz pe ecran un mesaj cnd se adaug sau se modific date din tabela
Catalog.

IF EXISTS (SELECT name FROM sysobjects
WHERE name = 'declans_mesaj ' AND type = 'TR')
DROP TRIGGER declans_mesaj
GO
CREATE TRIGGER declans_mesaj
ON Catalog
FOR INSERT, UPDATE
AS RAISERROR ('S-a executat un INSERT sau un UPDATE', 16, 1)
GO
INSERT INTO Catalog VALUES ('101','5',7,'11-17-2006')
GO
UPDATE Catalog
SET Nota=5
WHERE NrLeg='101' and Cod_disciplina='5'

Exemplul 2:
Declanator pentru tergeri i modificri n tabelul Catalog.

IF EXISTS (SELECT name FROM sysobjects
WHERE name = 'dec1' AND type = 'TR')
DROP TRIGGER dec1
GO
CREATE TRIGGER dec1
ON Catalog
FOR INSERT, UPDATE
AS
DECLARE
@@nota integer,
@@Nr_leg varchar(5)
SELECT @@Nr_leg = i.NrLeg, @@nota = i.Nota
FROM Catalog C, inserted i
WHERE C.NrLeg = i.NrLeg
IF (@@nota <5 )AND(@@Nr_leg like '101')
BEGIN
RAISERROR ('Studentul cu NrLeg=101 are Nota <5', 16, 1)
ROLLBACK TRANSACTION
END
ELSE
BEGIN
RAISERROR ('Studentul cu NrLeg=%s are Nota de admitere %d ',
16, 1, @@Nr_leg, @@nota)
COMMIT TRANSACTION
END
go
INSERT INTO Catalog VALUES ('101','5',6,'11-10-2006')
57

Go
INSERT INTO Catalog VALUES ('101','5',2,'12-01-2006')
go
UPDATE Catalog SET Nota=7 WHERE NrLeg='101' AND Cod_disciplina='4'
go

Exemplul 3:
Declanator ce adaug 1 punct la orice not din tabelul Catalog.

IF EXISTS (SELECT name FROM sysobjects
WHERE name = ' dec3' AND type = 'TR')
DROP TRIGGER dec3
GO
CREATE TRIGGER dec3
ON Catalog
AFTER INSERT
AS
UPDATE Catalog
SET Catalog.nota = Catalog.nota + 1
FROM inserted
WHERE Catalog.NrLeg = inserted.NrLeg
go
INSERT INTO Catalog VALUES ('103','4',4,'12-01-2006')
go
SELECT * FROM Catalog WHERE NrLeg='103'

Exemplul 4:
Crearea unui declanator ce afiseaz un mesaj dac s-a modificat Nota i un alt mesaj n caz
contrar.

IF EXISTS (SELECT name FROM sysobjects
WHERE name = 'dec4' AND type = 'TR')
DROP TRIGGER dec4
GO
CREATE TRIGGER dec4
ON Catalog
FOR UPDATE
AS
IF UPDATE(Nota)
RAISERROR ('S-a modificat campul Nota',16,1)
ELSE
RAISERROR ('S-a modificat alt camp al tabelei CATALOG',16,1)
go
UPDATE Catalog SET Nota=10 WHERE NrLeg='105'
go
SELECT * FROM Catalog WHERE NrLeg='105'
go
UPDATE Catalog SET Cod_materie='3' WHERE NrLeg='105'
go
UPDATE Catalog SET Cod_materie='3', Nota=8 WHERE NrLeg='105'
58


Exemplul 5:
Crearea unui declanator pentru operaia DELETE .

IF EXISTS (SELECT name FROM sysobjects
WHERE name = 'sterge_stud' AND type = 'TR')
DROP TRIGGER sterge_stud
GO
CREATE TRIGGER sterge_stud
ON Student
FOR DELETE
AS
DECLARE @NL varchar(5)
SELECT @NL=deleted.NrLeg
FROM deleted
IF (cast(@NL as integer)>0)
PRINT 'S-a Sters'
ELSE
BEGIN
PRINT 'Acest NrLeg nu exista!'
ROLLBACK TRANSACTION
END
GO
DELETE FROM Student WHERE NrLeg='17'

6.3 Modificarea i tergerea triggerelor
Modificarea unui declanator se face cu comanda ALTER TRIGGER, care are sintaxa:

ALTER TRIGGER nume_declan
ON ( table | view )
[ WITH ENCRYPTION ]
{
{ ( FOR | AFTER | INSTEAD OF ) { [ DELETE ] [ , ] [ INSERT ] [ , ] [ UPDATE ] }
[ NOT FOR REPLICATION ]
AS
sql_statement [ ...n ]
}
|
{ ( FOR | AFTER | INSTEAD OF ) { [ INSERT ] [ , ] [ UPDATE ] }
[ NOT FOR REPLICATION ]
AS
{ IF UPDATE ( coloana )
[ { AND | OR } UPDATE ( coloana ) ] [ ...n ] | IF ( COLOANAS_UPDATED ( ) {
bitwise_operator } updated_bitmask )
{ comparison_operator } coloana_bitmask [ ...n ]
}
sql_statement [ ...n ]
}
}

59

tergerea unui declanator se face cu comanda:
DROP TRIGGER { nume_declan } [ ,...n ]
Un declanator poate s conin oricte instruciuni, cu condiia s fie ncadrate ntr-un
bloc BeginEND. La executarea unui declanator, SQL Server acceseaz o tabel special,
aflat n memoria intern a serverului de baze de date, ce conine datele ce au determinat
rularea declanatorului. Aceast tabel este INSERTED (conine liniile inserate sau
modificate) pentru operaiile INSERT i UPDATE i respectiv DELETED (conine liniile
terse din tabel) pentru operaiile DELETE i UPDATE. Deoarece un declanator este
executat ntotdeauna dup operaie, liniile din INSERTED reprezint ntotdeauna o dublur a
uneia sau a mai multor nregistrri din tabela de baz. Existena acestor tabele din cache se
impune deoarece datele ce sunt inserate, modificate sau terse la nivelul unor tranzacii, nu
pot fi accesate din fiierul de log tranzacional (are acces aicidoar serverul de baze de date);
ele exist doar pe durata execuiei unei tranzacii, fiind terse i recreate de fiecare dat, dar
putnd fi accesate foarte rapid(nu se ncarc de pe hard disc).

6.4 Restricii de utilizare a declanatorilor
SQL-Server impune anumite restricii asupra tipurilor de instruciuni care pot fi
executate n cadrul unui declanator. Majoritatea restriciilor sunt determinate de
imposibilitatea de anulare a consecinelor unei operaii insert, update sau delete.
n corpul unui declanator nu poate apare nici una din instruciunile:

- CREATE DATABASE, CREATE TABLE INDEX, PROCEDURE, DEFAULT, RULE,
TRIGGER i VIEW.
- Toate instruciunile DROP.
- Instruciunile de modificare a obiectelor din baza de date ALTER TABLE, ALTER
DATABASE i TRUNCATE TABLE.
- UPDATE STATISTICS.
- Operaiile de ncrcare a bazei de date LOAD DATABASE i LOAD TRANZACTION.
- Toate instruciunile care realizeaz modificri fizice pe disc:DISK.
- Crearea de fiiere temporare implicit sau prin SELECT.
- Nu se poate crea un declanator pentru o vedere, ci numai pentru o tabel de baz care
definete vederea.

6.5 Tipuri de declanatoare
Exist dou tipuri de declanatoare:
-Declanator linie care se execut ori de cte ori tabelul este afectat de instruciunea
declanatoare. Dac o instruciune UPDATE actualizeaz 20 de linii, declanatorul se execut
de 20 de ori. Dac instruciunea nu afectez nici o linie, declanatorul nu este executat.
-Declanatorul instruciune- este executat o singur dat pentru instruciunea
declanatoare. De exemplu, dac este executat o instruciune UPDATE care actualizeaz 10
linii, este executat o singur dat.
Declanatorele INSERT i UPDATE sunt utile pentru c impun restriciile refereniale
i asigur validarea datelor nainte de a le scrie n tabele. De obicei se folosesc pentru a
verifica dac datele urmrite satisfac anumite criterii. Declanatoarelor DELETE (pentru
tergere) se folosesc pentru a preveni tergerea acolo unde aceasta ar afecta integritatea
datelor (este exemplul cheilor strine pentru alte tabele; al doilea exemplu este tergerea unui
articol n cascad care s elimine nregistrrile copie ale unei nregistrri particulare ):
CREATE TRIGGER sterg
ON vanzri
FOR DELETE
60

AS
IF @@row COUNT>1 /*verifica nr de linii afectate impiedicnd stergerea a mai mult de
o linie*/
BEGIN
ROLLBACK
RAISERROR(Puteti sterge o singur inregistrare la un moment dat!,16, 10)
END
DECLARE @stare_id char(4)
SELECT @stare_id=s.stare-id
FROM deleted s
IF NOT EXIST (SELECT * FROM vanzri
WHERE stare_id=@s.stare_id)
BEGIN
RAISERROR(Stergere esuata! Articol inexistent! ,16,10)
ROLLBACK
END
GO

































61

CAPITOLUL 7
Implementarea funciilor pentru baze de date
Microsoft SQL Server

7.1 Introducere
Acest capitol ofer o prezentare general a funciilor definite de utilizator. Acesta
explic de ce e nevoie de funcii i cum se utilizeaz acestea, precum i sintaxa pentru crearea
lor.
Dup terminarea acestui modul, vei fi capabil s:
1. Descriei cele trei tipuri de funcii definite de utilizator.
2. Creai i modificai funciile definite de utilizator.
3. Creai fiecare dintre cele trei tipuri de funcii definite de utilizator.
Cu Microsoft SQL Server avei posibilitatea s proiectai propriile funcii pentru
completarea i extinderea funciilor sistemului (built-in).
O funcie definit de utilizator ia zero sau mai muli parametri de intrare i ntoarce o valoare
scalar sau un tabel. Parametrii de intrare pot fi de orice tip de date, cu excepia
timestamp, cursor sau tabel. Funciile definite de utilizator nu accept parametri de ieire.
SQL Server permite trei tipuri de funcii definite de utilizator:
Funcii scalare
O funcie scalar este asemntoare cu o funcie built-in.
Funcii multi-instruciuni, care returneaz un tabel
O declaraie de funcie multi-instruciuni returneaz un tabel construit de unul sau mai multe
instruciuni Transact-SQL i este similar cu o procedur stocat. Spre deosebire de o
procedur stocat, o declaraie de funcie multi-instruciuni poate fi refereniat n clauza
FROM a unei instruciuni SELECT, ca n cazul unei vederi.
Funcii mono-instruciune, care returneaz un tabel
O asemenea funcie returneaz un tabel care este rezultatul unei singure instruciuni
SELECT. Este similar cu o vedere, dar ofer mai mult flexibilitate dect vederile n
utilizarea de parametri i extinde caracteristicile vederilor indexate.
7.2 Crearea unei funcii definite de utilizator
O funcie definit de utilizator se poate crea n aproape acelai fel n care creai o
vedere sau o procedur stocat. Putei crea funcii definite de utilizator prin utilizarea
instruciunii CREATE FUNCTION. Fiecare nume de funcie este complet calificat, la
specificarea acesteia, (database_name.owner_name.function_name) i trebuie s fie unic.
Declaraia specific parametrii de intrare cu tipurile lor de date, instruciunile de prelucrare i
valoarea returnat cu fiecare tip de date:
CREATE FUNCTION [OWNER_NAME. ] numele_functiei
([{@ Parameter_name scalar_parameter_data_type [= implicit]} [, ... n]])
RETURNS scalar_return_data_type
[WITH <function_option> [,... n]]
[AS]
BEGIN
corp funcie
RETURN scalar_expression
END
Acest exemplu creeaz o funcie definit de utilizator pentru a nlocui o valoare nul
cu cuvintele Nu se aplic.
USE Northwind
62

GO
CREATE fn_NewRegion FUNCTION
(@myinput nvarchar (30))
RETURNS nvarchar (30)
BEGIN
IF @myinput IS NULL
SET @myinput = 'Nu se aplic "
RETURN @myinput
END
Atunci cnd referii o funcie scalar definit de utilizator, specificai proprietarul i numele
funciei( n sintax cu dou pri):
SELECT LastName, City, dbo.fn_NewRegion(Region) AS Region,
Country
FROM dbo.Employees

Rezultatul va fi:
LastName City Region Country

Davolio Seattle WA USA
Fuller Tacoma WA USA
Leverling Kirkland WA USA
Peacock Redmond WA USA
Buchanan London Not Applicable UK
Suyama London Not Applicable UK
King London Not Applicable UK
Callahan Seattle WA USA
Dodsworth London Not Applicable UK

Restricii privind funciile
Funciile nedeterministe sunt funcii, cum ar fi GETDATE( ), care ar putea
ntoarce diferite valori rezultat de fiecare dat cnd sunt apelate cu acelai set de
de valori pentru parametrii de intrare. Funciile nedeterministe nu sunt permise n corpul
funciilor definite de utilizator. Urmtoarele funcii predefinite sunt nedeterministe:
@@ERROR, FORMATMESSAGE, IDENTITY, USER_NAME, @@IDENTITY,
GETANSINULL , NEWID, @@ROWCOUNT, GETDATE, PERMISSIONS,
@@TRANCOUNT, GetUTCDate , SESSION_USER, APP_NAME, HOST_ID,
STATS_DATE, CURRENT_TIMESTAMP, HOST_NAME, SYSTEM_USER,
CURRENT_USER, IDENT_INCR, TEXTPTR,DATENAME , IDENT_SEED,
TEXTVALID.
Crearea unei funcii cu opiunea SCHEMA BINDING
Avei posibilitatea s utilizai opiunea SCHEMA BINDING pentru a lega funcia de
obiectele bazei de date pe care le refereniai. Dac o funcie este creat cu opiunea
SCHEMA BINDING, obiectele bazei de date refereniate nu pot fi modificate(prin utilizarea
instruciunii ALTER) sau terse (folosind instruciunea DROP).
O funcie poate fi SCHEMA BINDING numai dac sunt adevrate urmtoarele condiii:
Oricare alte funcii definite de utilizator i vederi, referite de funcie, sunt, de
asemenea,
SCHEMA BINDING.
Obiectele refereniate de funcie nu sunt referite n formatul cu dou nume
owner.objectname.
63

Funcia i obiectele la care face referire fac parte din aceeai baz de date.

Utilizatorul care a executat instruciunea CREATE FUNCTION are permisiunea

REFERENCE pe toate obiectele bazei de date pe care funcia le folosete.
Setarea permisiunilor pentru funcii definite de utilizator
Cerinele legate de permisiuni pentru funciile definite de utilizator sunt similare cu cele ale
altor obiecte din baze de date:

Trebuie s avei permisiunea de CREATE FUNCTION pentru a crea, modifica, sau

terge funcii definite de utilizator.

Utilizatorilor, alii dect proprietarul, trebuie s li se acorde permisiunea de

EXECUTE pe o funcie nainte de a o putea folosi ntr-o instruciune Transact-SQL.

n cazul n care funcia este schema-bound, trebuie s avei permisiunea

REFERENCE pe tabele, vederi i funcii referite de aceasta. Permisiunile de
REFERENCE pot fi acordate prin instruciunea GRANT pentru vederi i funcii
definite de utilizator, precum i pentru tabele.

Dac o instruciune CREATE TABLE sau ALTER TABLE refereniaz o funcie

utilizator ntr-o constrngere CHECK, clauz DEFAULT, sau coloan calculat,
proprietarul tabelei trebuie s fie, de asemenea, proprietarul funciei.
Putei modifica funciile definite de utilizator prin utilizarea instruciunii ALTER
FUNCTION.
Beneficiul de a modifica o funcie, n loc de a o terge i recrea, este acelai ca i pentru
vederi i proceduri. Permisiunile cu privire la funcie rmn i se aplic imediat la funcia
revizuit.
Modificarea funciilor
Modificai o funcie definit de utilizator prin utilizarea instruciunii ALTER FUNCTION:
ALTER dbo.fn_functie FUNCTION
<Noul continut functie>
tergerea funciilor
Putei terge o funcie definit de utilizator prin utilizarea instruciunii DROP FUNCTION.
Acest exemplu arat cum s se renune la o funcie.
DROP FUNCTION dbo.fn_functie
7.3 Crearea funciilor scalare
O funcie scalar returneaz o valoare unic de date de tipul celui definit ntr-o clauz
RETURNS. Corpul funciei, definit ntr-un bloc BEGIN ... END, conine seria de instruciuni
Transact-SQL care returneaz valoarea. Tipul de dat ntors poate fi oricare, cu excepia
ntext, image, cursor sau timestamp.
O funcie scalar definit de utilizator este similar cu o funcie built-in. Dup ce o creai,
avei posibilitatea s o reutilizai.
Exemplul urmtor creeaz o funcie scalar definit de utilizator care primete data zilei i
coloana separatoare ca variabile i reformateaz data ca un ir de caractere.
CREATE FUNCTION fn_DateFormat
(@indate datetime, @separator char(1))
RETURNS Nchar(20)
AS
BEGIN
RETURN
CONVERT(Nvarchar(20), datepart(mm,@indate))
+ @separator
+ CONVERT(Nvarchar(20), datepart(dd, @indate))
+ @separator
64

+ CONVERT(Nvarchar(20), datepart(yy, @indate))
END
Avei posibilitatea s apelai o funcie scalar definit de utilizator n acelai mod n care
apelai o funcie intern:
SELECT dbo.fn_DateFormat (GETDATE (), ":")
7.4 Crearea funciilor multi-instruciune
O funcie multi-linie, care returneaz un tabel, este o combinaie dintr-o vedere i o
procedur stocat. Avei posibilitatea s utilizai funcii definite de utilizator care returneaz
un tabel pentru a nlocui procedurile stocate sau vederile.
O funcie multi-linie (ca i o procedur stocat) poate utiliza logic complex i mai multe
instruciuni Transact-SQL pentru a construi un tabel. n acelai mod n care se utilizeaz o
vedere, avei posibilitatea s utilizai o funcie multi-linie n clauza FROM a unei instruciuni
Transact-SQL.
Cnd se folosete o funcie multi-linie, se iau n considerare urmtoarele aspecte:

BEGIN i END delimiteaz corpul funciei.

Clauza RETURNS specific table ca tip de date returnat.

Clauza RETURNS definete un nume pentru tabel i formatul acestuia. Domeniul de

aplicare a numelui variabilei ntoarse este local funciei.
Putei crea funcii utiliznd instruciuni multiple care efectueaz operaiuni complexe.
Exemplul urmtor creeaz o funcie multi-instruciuni care returneaz numele de familie sau
numele i prenumele unui angajat, n funcie de parametrul furnizat.
USE Northwind
GO
CREATE FUNCTION fn_Employees
(@length nvarchar(9))
RETURNS @fn_Employees TABLE
(EmployeeID int PRIMARY KEY NOT NULL,
[Employee Name] Nvarchar(61) NOT NULL)
AS
BEGIN
IF @length = 'ShortName'
INSERT @fn_Employees SELECT EmployeeID, LastName
FROM Employees
ELSE IF @length = 'LongName'
INSERT @fn_Employees SELECT EmployeeID,
(FirstName + ' ' + LastName) FROM Employees
RETURN
END
Putei apela funcia n loc de un tabel sau o vedere:
SELECT * FROM dbo.fn_Employees('LongName')
sau
SELECT * FROM dbo.fn_Employees('ShortName').
7.5 Crearea funciilor mono-linie
Funciile mono-linie ntorc o tabel i sunt folosite n clauza FROM, ca i o vedere.
Cnd se utilizeaz funcii mono-linie definite de utilizator, luai n considerare urmtoarele
aspecte:

Clauza RETURN conine o singur instruciune SELECT ntre paranteze.Rezultatul

instruciunii SELECT formeaz tabelul pe care funcia l ntoarce. Instruciunea
65

SELECT utilizat ntr-o funcie mono-linie este condiionat de aceleai restricii ca
instruciunile SELECT utilizate n vederi.

BEGIN i END nu delimiteaz corpul funciei.

RETURN specific table ca tip de date returnat.

Nu trebuie s se defineasc formatul variabilei ntoarse, pentru c acesta este stabilit

de ctre formatul din rezultatul dat de instruciunea SELECT.
Avei posibilitatea s utilizai funcii mono-linie pentru a realiza funcionalitatea vederilor
parametrizate. Nu vi se permite s utilizai parametri de intrare cnd se creeaz o vedere.
Putei rezolva, de obicei, acest lucru folosind o clauz WHERE atunci cnd se apeleaz
vederea. Cu toate acestea, acest lucru poate necesita construirea unui ir dinamic de execuie,
care poate crete complexitatea cererii. Avei posibilitatea s atingei functionalitatea unui
vederi parametrizate folosind o funcie mono-linie.
Acest exemplu creeaz o funcie mono-linie care ia valoarea de regiune ca parametru de
intrare:
USE Northwind
GO
CREATE FUNCTION fn_CustomerNamesInRegion
( @RegionParameter nvarchar(30) )
RETURNS table
AS
RETURN (
SELECT CustomerID, CompanyName
FROM Northwind.dbo.Customers
WHERE Region = @RegionParameter
)
Pentru a apela funcia, furnizai numele funciei n clauza FROM i dai valoarea regiunii ca
parametru.
SELECT * FROM fn_CustomerNamesInRegion (N'WA ")
7.6 Ghid de utilizare a funciilor
Urmtoarele practici recomandate ar trebui s v ajute s punei n aplicare funciile
definite de utilizator:

Utilizai funcii scalare complexe pe seturile de rezultate mici. Funciile definite de

utilizator ofer o modalitate, pentru dumneavoastr, de a ngloba calcule complexe
ntr-o simpl interogare. Nu aplicai o agregare complex pe fiecare membru al unui
set de rezultate mare.

Utilizai funcii multi-linie n loc de proceduri stocate care returneaz

tabele. Scrierea procedurilor stocate care returneaz tabele ca funcii multi-linie
poate mbunti eficiena.

Folosii funcii mono-linie pentru a crea vederi cu utilizare de parametri.Folosirea

parametrilor cu funcii mono-linie poate simplifica referinele la tabele i vederi.

Folosii funciile mono-linie pentru a filtra vederile. Utilizarea de funcii mono-linie

cu vederi indexate poate crete foarte mult performana.


66

CAPITOLUL 8
Managementul accesului la baza de date


Accesul la serverul SQL nu i permite utilizatotorului accesul la o anumit baz de
date din SQL Server. n plus, cu excepia membrilor din rolul sysadmin, apartenena la un rol
de la nivelul serverului nu i acord permisiunea de acces la o baz de date specific.
Drepturile de acces la baza de date trebuie s fie n mod special acordate de un administrator
al sistemului sau de un membru al unui rol de administrator din baza de date. Dup ce
utilizatorul s-a autentificat n cadrul serverului SQL, urmtorul pas este s solicite accesul la
nivelul bazei de date. Accesul clientului la baza de date este determinat de contul de utilizator
i apartenena la un rol din cadrul bazei de date. Urmtoarele pagini vor detalia informaiile
necesare pentru a implementa utilizatorii i rolurile din cadrul unei baze de date.

8.1 Administrarea utilizatorilor
Utilizatorii, sau mai corect ID-urile de utilizator, reprezint persoanele sau programele
care efectueaz diferite aciuni asupra obiectelor din baza de date. Ori de cte ori se creeaz
un tabel n SQL server, se insereaz, se terg sau se modific nregistrri din acel tabel, aceste
operaii se realizeaz n numele ID-ului de utilizator. Serverul Sql acord ID-urilor de
utilizator permisiuni pentru a efectua aciuni specifice pentru anumite baze de date.
Utilizatorii reprezint fundamentul securitii SQL Server. Cel puin un utilizator este
creat de ctre baza de date, cunoscut ca proprietarul bazei de date (DBO-DataBase Owner),
asociat administratorului de sistem (SA-Sistem Administrator). Acest utilizator este un
superuser care ncepe, de obicei, crearea primelor tabele i crearea tuturor ID-urilor de
utilizator care au permisiuni n acel tabel.
n bazele de date simple, este o metod destul de utilizat autentificarea tututor
utilizatorilor ca administratori de sistem, ceea ce nseamn c fiecare utilizator are acces la
toate obiectele i anume oricine poate face orice cu orice obiect din baza de date.
Un ID de utilizator este o pereche nume / parola care permite unei entiti s
efectueze aciuni n baza de date. Entitatea poate fi o persoan, un program, sau un program
manipulat direct de ctre o persoan, dar rezultatul final este c entitatea trebuie s se
conecteze la baza de date, oferind un nume de utilizator i o parol valid. SQL Server
verific numele de utilizator i parola, efectueaz validarea pentru a se asigura c aceast
pereche este legal n sistem, i apoi determin ce poate s fac utilizatorul n baza de date.

8.1.1 Crearea utilizatorilor
Administratorul de sistem (SA) stabilete utilizatorii i definete privilegiile pe care
aceti utilizatori le au. Principiile utilizatorului bazei de date reprezint contextul de securitate
la nivelul bazei de date sub care sunt executate solicitrile din baza de date i sunt asociate cu
un cont de autentificare SQL Server sau Windows. Pentru a crea un utilizator pentru o baz de
date, nu ar trebui s se foloseasc procedura stocat sistem sp_adduser, care acum este
depit, ci comanda CREATE USER n baza de date int:

USE AdventureWorks
GO
CREATE USER Utilizator
FOR LOGIN [cont_login_utilizator]
GO
67

Cnd un utilizator cu acest cont de autentificare ncearc s acceseze baza de date, acel
utilizator va face acest lucru n cadrul contextului de securitate al utilizatorului Utilizator din
aceast baz de date. Se poate crea, de asemenea, un utilizator asociat cu un certificat sau o
cheie asimetric:

CREATE USER UtilizatorCertificat
FOR CERTIFICATE CertificatSQLServer
GO

n acest caz, dac un utilizator (sau o aplicaie), identificat printr-un certificat
particular sau cheie asimetric se conecteaz la un serviciu Web, interogarea se va executa n
contextul de securitate al utilizatorului asociat cu acel certificat sau cheie asimetric.

8.1.2 Modificarea utilizatorilor
Se poate modifica ntotdeauna utilizatorul prin schimbarea numelui, parolei sau fcnd
un utilizator s fie inactiv; de asemenea, se poate opta pentru stabilirea zilei sau zilelor din
sptmn n care utilizatorul se poate conecta la baza de date. De exemplu, instruciunea
pentru modificarea unui utilizator poate arata:

USE AdventureWorks
ALTER USER Utilizator WITH NAME = Utilizator1
GO

8.1.3 tergerea unui utilizator
i, n sfrit, ceea ce poate face administratorul de sistem, ntotdeauna poate s i
anuleze, n acest caz tergerea complet a utilizatorului, dac este necesar. Urmtoarea
instruciune terge un utilizator din baza de date:

USE AdventureWorks
DROP USER Utilizator1
GO

8.2 Administrarea rolurilor
Un rol al bazei de date este un obiect creat ntr-o baz de date care poate fi utilizat
pentru a grupa (la nivel de roluri) utilizatorii individuali ai bazei de date crora nu trebuie s
li se acorde permisiuni. Fiecare baz de date vine cu un set de roluri de baze de date fixe.
Cnd unui grup Windows i se acord accesul la SQL Server, grupul primete un singur
cont de autentificare la SQL Server. Atunci cnd acestui login i este acordat accesul la o baz
de date, un utilizator al bazei de date este creat pentru grupul Windows. Prin urmare, dac se
acord accesul grupurilor Windows la SQL Server, utilizatorii sunt grupai la nivelul
Windows-ului i administrarea rolurilor ar putea fi minim. Rolurile sunt utilizate n cadrul
SQL Server pentru a grupa utilizatorii bazelor de date. Cnd se acord accesul la SQL Server
grupurilor Windows, utilizatorii sunt deja grupai.
Rolurile fixe ale bazei de date sunt roluri construite cu un scop predefinit. Cele mai
multe dintre permisiunile atribuite acestor roluri sunt de natur administrativ. Permisiunile
acordate unui rol al bazei de date fix, altul dect rolul public, nu pot fi schimbate. Calitatea de
membru al rolului public pentru toi utilizatorii bazei de date nu poate fi schimbat. Dac
utilizatorului i se acord accesul la o baz de date, utilizatorul este automat un membru al
rolului public.
68

8.2.1 Rolul public
Toi utilizatorii unei baze de date sunt adugai automat rolului public. Utilizatorii nu
pot fi eliminai din rolul public. Urmtoarele caracteristici definesc rolul public:
Ar trebui s fie utilizat pentru permisiunile implicite din baza de date;
Este coninut n toate bazele de date;
Nu poate fi ters din nici o baz de date;
Implicit nu se acord permisiuni de acces n nici o baz de date, cu excepia bazelor de date
sistem.

8.2.2 Alte roluri fixe
Rolurile fixe ale bazei de date sunt stocate in tabelul sysusers din fiecare baz de date.
Pot fi grupate n grupuri de utiilizatori pentru a furniza funcionalitatea bazei de date.

ROL SCOP
Db_owner Execut orice activitate n baza de date
Db_accesadmin Adaug i terge utilizatori i roluri
Db_ddladmin Manipuleaz obiectele bazei de date
Db_securityadmin Atribuie permisiunile pentru obiecte i instruciuni
Db_backupoperator Execut backup-ul bazelor de date
Db_datareader Citete datele din orice tabel al bazei de date
Db_datawriter
Insereaz, modific i terge datele din orice tabel al bazei
de date
Db_denydatareader Refuz accesul pentru citirea datelor din baza de date
Db_denydatawriter
Refuz inserarea, modificarea i tergerea datelor din baza
de date

Tabelul 8.1 - Rolurile fixe ale unei baze de date.

Apartenena la rolurile fixe ale bazei de date poate fi modificat prin executarea
procedurilor stocate sp_addrolemember i sp_droprolemember.

8.2.3 Roluri definite de utilizator
Rolurile definite de utilizator pot fi create pentru grupurile de utilizatori care au nevoie
s ndeplineasc aceleai sarcini n baza de date. Permisiunile pot fi atribuite rolurilor, n loc
de a le acorda utilizatorilor individuali. Acest lucru va reduce lista de permisiuni pentru un
obiect dat i va scdea managementul asociat permisiunilor. Ar trebui s se ia n considerare
utilizarea rolurilor definite de utilizator, dac exist una dintre urmtoarele condiii:
Se utilizeaz modul de autentificare SQL;
Grupul de utilizatori curent Windows nu satisface cerinele bazei de date;
69

Mai multe grupuri Windows au nevoie de acelai acces la baza de date.
Procedurile stocate sp_addrole i sp_droprole sunt utilizate pentru a aduga sau a
terge roluri utiliznd Transact-SQL. n plus, se folosesc procedurile stocate
sp_addrolemember i sp_droprolemember pentru a modifica membrii rolurilor.

8.3. Managementul securitii obiectelor
Atunci cnd un utilizator se conecteaz la o instan Microsoft SQL Server,
activitile pe care acesta le poate efectua sunt determinate de permisiunile acordate rolurilor
i utilizatorilor bazelor de date. Pentru a interaciona cu baza de date, utilizatorul trebuie s
aib permisiuni asupra obiectelor bazei de date. Printre acestea se include i dreptul de a
schimba schema (designul) bazei de date i de a interaciona cu datele stocate n tabelele
bazei de date. Fiecare baz de date este format din mai multe obiecte, care pot include tabele,
vederi, proceduri stocate, funcii, reguli, indeci i triggere. Aceste obiecte de baz i structura
lor de organizare sunt menionate ca fiind schema bazei de date. Acestea sunt obiectele prin
intermediul crora utilizatorii pot manipula informaiile stocate n baza de date. Permisiunile
utilizatorilor cu privire la tabelele, vederile, precum i la procedurile stocate ale bazei de date
definesc activitile pe care utilizatorul le poate efectua aupra obiectelor bazei de date din
SQL Server.

8.3.1 Tipuri de permisiuni
Managementul permisiunilor n SQL Server este, n general, efectuat de ctre
administratorul bazei de date(DBA), dar administratorii unor organizaii ar trebui s
gestioneze un numr mare de baze de date, astfel nct acest rol a fost acordat dezvoltatorilor
bazelor de date. n aceste cazuri, administratorii ar trebui s fie n continuare responsabili
pentru securitatea la nivelul serverului. Dezvoltatorul poate gestiona apoi permisiunile la
nivelul obiectelor din baza de date. Indiferent de strategia implementat, este important ca
aceasta s fie bine documentat i neleas de ctre toate persoanele care au responsabiliti
pentru gestionarea securitii bazei de date. Managementul permisiunilor n SQL Server
include administrarea urmtoarelor trei tipuri de permisiuni:
Permisiuni la nivelul obiectelor;
Permisiunile la nivelul intruciunilor;
Permisiuni implicite.
1) Permisiuni la nivelul obiectelor
Permisiunile la nivelul obiectelor reprezint un set de permisiuni care permit
clientului s interacioneze cu obiectele bazei de date. Prin urmare, aceste permisiuni necesit
cel mai mare nivel de atenie continu. Majoritatea celorlalte permisiuni sunt stabilite
mpreun sau deriv, pe linie de motenire, de la un rol al servererului din care face parte
utilizatorul.
Permisiunile la nivelul obiectelor sunt gestionate de ctre un administrator sau
dezvoltator i trebuie s fie monitorizate pentru a asigura o baz de date sigur. Este
important s existe o strategie de implementare a permisiunilor nainte ca baza de date s fie
creat. Permisiunile care sunt alese pentru a fi utilizate depind de tipul obiectelor ce sunt
implementate n baza de date.
Urmtoarele aspecte ar trebui s fie avute n vedere atunci cnd se stabilesc
permisiunile la nivelul obiectelor:
Instruciunile Insert i Delete au efect asupra ntregului rnd dintr-un tabel i pot fi
aplicate numai asupra tabelelor i vederilor. Permisiunile Update i Select pot fi aplicate
coloanelor individuale;
Permisiunile Execute pot fi aplicate instruciunilor SQL precompilate (proceduri
stocate i funcii). Permisiunea Execute poate fi permisiunea cea mai puternic utilizat pentru
70

managementul securitii. De exemplu, unui utilizator i se poate acorda dreptul de a executa o
procedur stocat care introduce o inregistrare nou ntr-un tabel, fr a avea permisiunea de
inserare n tabel. Permisiunea Execute poate fi un mijloc eficient de a restrnge acest tip de
inserri care pot s apar;
Permisiunea References este necesar pe un obiect asupra cruia se face referire de o
funcie sau vedere folosind clauza WITH SCHEMABINDING.

Permisiunea Funcia Obiecte
Select Extrage datele pentru citire
Tabele, coloane, funcii definite
de utilizator i vederi
Insert
Adaug date n anumite
obiecte
Tabele, coloane, funcii definite
de utilizator i vederi
Update
Modific nregistrrile care
exist deja n tabel
Tabele i vederi
Delete
terge nregistrri dintr-un
tabel
Tabele i vederi
Execute
Execut o instruciune
procompilat
Proceduri stocate i funcii
References
Creeaz o cheie strin care
refereniaz un tabel
Tabele
All
Aplic toate permisiunile
disponibile unui obiect
Toate

Tabelul 8.2 - Permisiuni la nivelul obiectelor i funcia pe care o ndeplinete fiecare.

2) Permisiuni la nivelul instruciunilor
Permisiunile la nivelul intruciunilor sunt folosite pentru a manipula obiectele bazei de
date. Permisiunile la nivel de instruciune, atunci cnd sunt acordate, permit modificarea
schemei bazei de date. Aceast clas de permisiuni este stabilit la nivelul bazei de date i ar
trebui s fie utilizat n contextul regulilor de proprietate adecvate asupra obiectului.
Permisiunile la nivelul intruciunilor, cum ar fi CREATE VIEW, sunt aplicate intruciunilor i
acord dreptul de a efectua instruciunea indiferent de obiectul n cauz. Toi membrii rolului
sysadmin au capacitatea de a efectua toate permisiunile la nivelul instruciunilor.
Permisiunea la nivelul
instruciunilor
Funcionalitate
Create Table
Folosit la crearea, modificarea i tergerea
tabelelor(CREATE, ALTER, DROP)
Create View
Folosit la crearea, modificarea i stergerea
vederilor
Create Stored Procedure
Folosit la crearea, modificarea i stergerea
procedurilor
Create Default
Folosit la crearea, modificarea i tergerea
regulilor. O regul este o expresie condiional
scris n Transact-SQL care definete o
constrngere de intergritate a datelor. Regula este
atribuit unei coloane pentru a defini tipul de
date care este acceptat n coloan
71

Create Function
Folosit la crearea, modificarea i tergerea
funciilor definite de utilizator
Backup Database
Folosit pentru a efectua un backup complet sau
diferenial al bazei de date
Backup Log
Folosit pentru a efectual un backup al log-ului
de tranzacii

Tabelul 8.3 - Permisiuni la nivelul instruciunilor i funcionalitatea acestora.

3) Permisiuni implicite
Permisiunile implicite sunt permisiunile acordate prin calitatea de membru al unui rol.
De exemplu, un membru al rolului fix al serverului sysadmin poate ndeplini orice aciune n
SQL Server. Permisiunile implicite nu sunt modificate, ele sunt motenite de la un set de
permisiuni predefinite la nivelul unui rol. Proprietarii de obiecte pot avea, de asemenea,
permisiuni implicite, ceea ce le permite s efectueze orice activitate cu privire la obiectul pe
care l dein.
Exist unele instruciuni Transact-SQL care nu pot fi acordate ca permisiuni; capacitatea
de a executa aceste instruciuni necesit calitatea de membru ntr-un rol fix care are
permisiuni implicite pentru a le executa. De exemplu, pentru a executa instruciunea de
nchidere (shutdown), utilizatorul trebuie s fie un membru al rolurilor de la nivelul
serverului, sysadmin sau serveradmin. Rolurile fixe ale serverului i rolurile fixe ale bazei
de date au un set de permisiuni pe care toi membrii rolurilor le primesc ca permisiuni
implicite.
Urmtoarele instruciuni nu au nevoie de permisiuni specifice; prin urmare, un
membru al rolul public permite utilizatorului, n mod automat, utilizarea acestor comenzi
Transact-SQL:
Begin Transaction;
Commit Transaction;
Rollback Transaction;
Save Transaction;
Raiserror;
Print;
Set.
Implicit, toi utilizatorii crora li se acord accesul la o baza de date devin membrii
rolului public.


Rol Permisiune efectiv
sysadmin Toate permisunile de pe server i bazele lui de date
serveradmin
Reconfigure, Shutdown i cteva comenzi de verificare a
consistenei bazelor de date(DBCC)
securityadmin Instruciunile DENY, GRANT i REVOKE
processadmin Terminarea proceselor serverului SQL
bulkadmin Comenzi de inserare n volum mare
dbcreator Instruciunile CREATE, ALTER, BACKUP i RESTORE
72

diskadmin
Nu are nici o permisiune la nivelul instruciunilor, poate
efectua unele proceduri stocate sistem
setupadmin
Nu are nici o permisiune la nivelul instruciunilor, poate
efectua unele proceduri stocate pentru a configura
replicarea

Tabelul 8.4 - Rolurile de la nivelul serverului i permisiunile efective ale acestora.

Rol la nivelul bazei de date Permisiune efectiv
db_owner Poate efectua orice aciune asupra bazei de date
db_datareader Instruciunile READTEXT i SELECT
db_datawriter
Instruciunile UPDATE, INSERT, DELETE,
WRITETEXT i UPDATETEXT
db_dlladmin
Instruciuni asupra obiectelor: CREATE, DROP
i ALTER i instruciunea Truncate Table
db_backupoperator
Instruciunile Backup Database, Checkpoint i
unele instruciune DBCC
db_securityadmin Instruciunile DENY, GRANT i REVOKE
db_accesadmin
Nu se acord permisiuni la nivelul instruciunilor,
poate efectua unele proceduri stocate sistem

Tabelul 8.5 - Rolurile de la nivelul bazei de date i permisiunile efective ale acestora.

8.3.2 Implementarea permisiunilor
Atunci cnd o permisiune este acordat, retras sau refuzat unui utilizator la un
server SQL, contul utilizatorului specificat este singurul afectat de aciunile asupra
permisiunilor sale. Dac o permisiune se acord unui rol SQL Server, permisiunea afecteaz
toi utilizatorii din baza de date care sunt membri ai rolului. Permisiunile sunt implementate
cu instruciunile GRANT, DENY i REVOKE. Structura permisiunilor pentru o baz de date
este stocat n tabelul sistem sysprotects.
1) Acordarea permisiunilor
Instruciunea GRANT acord unui utilizator o permisiune la nivelul unui obiect sau la
nivelul instruciunilor. Instruciunea GRANT este folosit pentru a acorda unui utilizator sau
rol al bazei de date dreptul de a lucra cu datele stocate ntr-o baz de date.

GRANT [Permisiune] ON [Obiect sau instructiune] TO [Cont de securitate]

Permisiunile la nivelul obiectelor pot fi acordate doar unui utilizator din baza de date
n care se afl obiectul. n cazul n care un utilizator dintr-o baz de date are nevoie de
permisiunea asupra unui obiect din alt baz de date, contul de utilizator trebuie s fie creat n
cealalt baz de date. n cazul n care unui utilizator al bazei de date nu i este acordat
permisiunea la un obiect al bazei de date, utilizatorul nu va avea acces la obiect. Procedurile
stocate sistem reprezint o excepie, deoarece permisiunea EXECUTE este deja acordat
rolului public. Aceast permisiune EXECUTE acord fiecrui utilizator din baza de date
abilitatea de a rula proceduri stocate sistem. Oricum, dup ce instruciunea EXECUTE a fost
rulat, prodecura stocat sistem verific apartenena utilizatorului la un rol. Unele dintre
73

procedurile stocate sistem depind de apartenena utilizatorului la rolurile fixe al bazei de date.
Dac utilizatorul nu este un membru al rolului adecvat fix de la nivelul serverului sau al bazei
de date, necesar pentru a executa proceduri stocate, execuia procedurii stocate nu va
continua.
2) Refuzarea permisiunilor
Microsoft SQL Server permite utilizatorilor i grupurilor Windows accesul la SQL
Server. n plus, pot fi create login-uri SQL crora li se acord permisiunile adecvate pentru
accesul la SQL Server. Oricrui dintre aceste login-uri poate s i se acorde apoi accesul la o
baz de date n calitate de utilizator i se poate introduce ntr-unul sau mai multe roluri.
Rezultatul este un sistem ierarhic de securitate, care permite permisiunilor s fie aplicate mai
multor niveluri de roluri i membri. Mai multe permisiuni la nivelul instruciunilor pot afecta
un singur individ, prin diferite apartenene la grupuri i roluri. Dar pot exista momente cnd se
dorete limitarea permisiunilor unui utilizator sau unui rol, pentru a mpiedica accesul la o
instruciune special sau obiect. Refuzarea permisiunilor unui cont de utilizator:
Elimin permisiunea n cazul n care a fost acordat anterior utilizatorului sau rolului;
Anuleaz orice permisiunea GRANT care este acordat unui alt rol sau utilizator care
este legat de acest login;
Dezactiveaz permisiunea motenit de la un alt rol sau cont de utilizator din baza de
date;
Asigur faptul c utilizatorul nu va avea acces la obiecte sau instruciuni prin
intermediul altor utilizatori sau roluri n viitor.

DENY [Permisiune] ON [Obiect sau instructiune] TO [Cont de securitate]

Se pot refuza permisiunile unui utilizator sau ale unui rol, dac utilizatorul produce
probleme de securitate continue; atunci permisiunea DENY poate s fie o metod de
asigurare c utilizatorul este blocat.
3) Revocarea permisiunilor
Permisiunea REVOKE nltur o permisiune care a fost anterior acordat sau
refuzat. Permisiunea de revocare este similar cu refuzarea permisiunii, n sensul c ambele
elimin o permisiune acordat. Dar, dei revocarea permisiunii nltur o permisiune acordat,
aceasta nu mpiedic un utilizator, grup sau rol de la motenirea permisiunii de la un nivel mai
ridicat. Prin urmare, permisiunea REVOKE nu garanteaz faptul c o persoan nu va avea
acces la obiect. n cazul n care utilizatorul face parte dintr-un alt rol cruia i-a fost acordat
permisiunea sau dac contulului de utilizator i se acord permisiunea de a accesa obiectul,
individul poate nc accesa obiectul. De aceea, dac revocai permisiunea unui utilizator de
a vizualiza un tabel, nu nseamn c utilizatorul a fost mpiedicat s vizualizeze tabelul.
Instruciunea REVOKE nltur pur i simplu o permisiune n prealabil refuzat.
Instruciunile GRANT i DENY adaug o intrare n tabelul sistem sysprotects. Ambele
instruciuni foreaz o permisiune asupra unui obiect. Instruciunea REVOKE terge pur i
simplu nregistrarea anterioar din tabelul sysprotects. Acest lucru ajut la gestionarea
dimensiunii tabelelor din sistem. Instruciunea REVOKE poate neutraliza instruiunile
GRANT i DENY.

REVOKE [Permisiune] ON [Obiect sau instructiune] FROM [Cont de securitate]

8.3.3 Conflicte ntlnite la acordarea permisiunilor
O persoan poate aparine mai multor grupuri i, prin urmare, i se poate acorda accesul
la SQL Server prin intermediul mai multor conturi de login. Fiecare dintre aceste login-uri
sunt gestionate separat n SQL Server. Este posibil ca fiecare dintre aceste login-uri s acorde
74

accesul la aceeai baz de date. Deci, o singur persoan poate avea mai multe conturi de
utilizator i poate fi membrul mai multor roluri pentru o baz de date unic. Login-urile
multiple cresc complexitatea managementului permisiunilor.
Permisiunile GRANT sunt cumulative. De exemplu, un utilizator face parte din rolul
rTbl pentru tabelul Tbl. Utilizatorului i se acord permisiunea SELECT pentru tabel i rolul
rTbl primete permisiunea INSERT i DELETE asupra tabelului. Permisiunile cumulate ale
utilizatorului sunt SELECT, INSERT i DELETE. Permisele GRANT sunt cumulative pentru
diferitele apartenene ale utilizatorului la roluri sau grupuri. Problema devine complicat
atunci cnd se adaug o permisiune DENY.
n cazul n care exist conflicte ntre permisiunile unui grup sau rol i ale membrilor
si, permisiunea cea mai restrictiv (DENY) are prioritate. Permisiunea DENY are
ntotdeauna preceden asupra permisiunii GRANT. Prin urmare, utilizarea instruciunii
DENY necesit pruden sporit. Folosind instruciunea DENY pentru un rol sau grup
Windows, se poate limita n mod eficient accesul utilizatorilor, care, printr-un alt utilizator
sau rol, ar putea accesa datele. Instruciunea REVOKE nltur permisiunile acordate;
instruciunea DENY poate fi utilizat pentru a mpiedica un utilizator s obin permisiuni,
prin acordarea unei permisiuni GRANT pentru contul utilizatorului. Permisiunea REVOKE
se utilizeaz pentru a elimina intrrile permisiunilor inutile sau pentru a schimba accesul la
baza de date. Cele mai multe dintre instruciunile de securitate ar trebui s fie GRANT sau
REVOKE.

8.3.4 Lanul drepturilor de proprietate asupra obiectelor
Dreptul de proprietate asupra obiectelor reprezint o problem critic n SQL Server.
n multe alte sisteme de baze de date, este important s se defineasc dreptul de proprietate pe
baza utilizatorului care a creat obiectul. n SQL Server nu este cazul. O baz de date ar trebui
s aib acelai proprietar pentru toate obiectele.
Vederile i procedurile stocate reprezint o metod secundar de a oferi accesul
utilizatorilor la date i dreptul de a efectua anumite activiti. Acestea furnizeaz utilizatorilor
dreptul de acces la elementele fundamentale din baza de date, prin ocolirea permisiunilor
definite direct pentru un obiect sau o instruciune. Vederile i procedurile stocate sunt
dependente de obiectele pe care le refereniaz.
Vederile pot depinde de alte vederi sau tabele. Procedurile pot depinde de alte
proceduri, vederi sau tabele. Aceste dependine pot fi gndite ca un lan al drepturilor de
proprietate. Lanurile drepturilor de proprietate se aplic doar instruciunilor SELECT,
INSERT, UPDATE i DELETE.
De obicei, proprietarul unei vederi deine de asemenea i obiectele din interior, alte
tabele i vederi, i proprietarul unei proceduri deine, de cele mai multe ori, toate procedurile,
tabelele i vederile refereniate. Proprietarul unei vederi sau proceduri stoacate ar trebui s fie
un cont DBO. Toate obiectele ar trebui create n contextul unui proprietar DBO. Acest lucru
va preveni ruperea lanului de proprietate. De asemenea, vederile i obiectele din interior se
afl, de obicei, n aceeai baz de date, precum i procedurile stocate cu obiectele refereniate.
Atunci cnd obiecte temporare sunt create n interiorul unei proceduri stocate, acestea sunt n
proprietatea deintorului procedurii stocate i nu n proprietatea utilizatorului care execut
procedura. Atunci cnd un utilizator acceseaz o vedere, SQL Server nu verific permisiunile
nici unui obiect din interior, dac obiectele i vederea sunt toate deinute de acelai utilizator
i sunt n aceei baz de date. Dac acelai utilizator deine o procedur stocat i toate
vederile i tabelele, procedurile i obiectele pe care le refereniaz se afl n aceeai baza de
date, SQL Server verific doar permisiunile asupra proceduri stocate. Verificarea acestei
permisiuni reprezint o metod solid de securizare a tabelelor.
75

n cazul n care lanul drepturilor de proprietate asupra unei proceduri sau vederi este
rupt din cauza unor obiecte din cadrul lanului care nu sunt deinute de acelai utilizator, SQL
Server verific permisiunile asupra fiecrui obiect din lan al crui nivel urmtor de
refereniere este deinut de ctre un alt utilizator. n acest fel , SQL Server permite
proprietarului datelor iniiale s pstreze controlul asupra accesibilitii sale. Atunci cnd SQL
Server trebuie s verifice permisiunile n aceast manier, performana instruciunii este uor
sczut. n plus, administratorul trebuie s in cont de fiecare obiect i de fiecare utilizator
care interacioneaz cu obiectele pentru a asigura securitatea bazei de date.
Atunci cnd un dezvoltator creeaz o baz de date, dezvoltatorul poate include
proprietarul ca o parte din numele obiectului. Numele proprietarului este adugat la inceputul
numelui obiectului i numele de identificare al obiectului este separat de proprietar printr-un
punct.

CREATE TABLE DBO.Tbl

Creatorul obiectului poate folosi proprietarul DBO dac acesta este autentificat ca un
sysadmin, care include i contul SA, sau aparine rolului bazei de date db_owner.
Dac proprietarul nu este specificat n instruciunea CREATE, SQL Server va
specifica un proprietar implicit. Proprietarul implicit depinde de contextul de autentificare al
utilizatorului. n cazul n care contul de autentificare este un membru al rolului sysadmin la
nivelul serverului, proprietarul implicit este DBO. Dac utilizatorul lucreaz n orice alt
context, SQL Server va delega username-ul curent autentificat ca proprietar implicit.
Pentru ca toate obiectele s fie create de DBO poate fi utilizat procedura stocat
sp_changeobjectowner pentru a schimba proprietarul obiectului n DBO, n orice moment
dup ce obiectul a fost creat. Acest procedur stocat ar trebui s fie executat pentru fiecare
obiect al crui proprietar e diferit de DBO.

8.4. Securitatea aplicaiilor
Dezvoltarea aplicaiilor este instrumentul cheie pentru interaciunea cu datele stocate n
SQL Server. Dei exist medii de interogare ad-hoc, accesul la datele din SQL Server se face
prin intermediul unei aplicaii front-end. Pe msur ce se proiecteaz o aplicaie, este bine s
se ia n considerare caracteristicile de securitate care urmeaz s fie incluse n cadrul
aplicaiei (de exemplu, dac se dorete autentificarea Windows sau SQL Server pentru a
accesa datele stocate n bazele de date SQL Server). Diveri factori ajut la stabilirea
metodelor adecvate de acces la date. n plus fa de accesul la aplicaie, este necesar i
proiectarea securitii pentru baza de date care va fi utilizat.

8.4.1 Analizarea cerinelor sistemului
Sarcina cea mai important n procesul de elaborare a structurii de securitate a
aplicaiei este analiza cerinelor sistemului. Acest lucru este, de asemenea, zona de securitate
cea mai adesea trecut cu vederea. Cerinele sistemului care trebuie proiectat ar trebui
reflectate n proiectarea securitii aplicaiei. De exemplu, dac toat lumea dintr-o
organizaie trebuie s citeasc datele din sistem, , atunci structura securitii ar trebui s fie
uor de neles. Dup ce se realizeaz o nelegere corect a cerinelor curente, se poate trece
la celelalte probleme de securitate.
n analiza cerinelor, ar trebui s se ia n considerare urmtoarele serii de probleme:
Cerinele de auditare;
Accesul la date. Care utilizatori au nevoie de acces i la ce pri din date au
permisiunea de acces;
76

Numrul de utilizatori. Acest lucru ar putea afecta alegerea metodei de autentificare i
nivelul de securitate ales pentru aplicaie;
Limitrile i cerinele dezvoltrii unei mediu frond-end. Unele produse dezvoltate nu
suport autentificarea Windows, pe cnd altele da;
Ateptrile utilizatorilor. Aceast zon este cea mai important, pentru c trebuie s se
cunoasc asteptrile utilizatorilor de la aplicaie.

8.4.2 Protejarea tabelelor
Cele dou obiecte ale bazei de date care sunt utilizate, de obicei, pentru a implementa
securitatea sunt procedurile stocate i vederile. Permisiunile pentru a executa procedurile
stocate se pot acorda far a acorda permisiunile de acces la tabelele refereniate n procedurile
stocate. Este important de reinut c aceste tipuri de permisiuni sunt dependente ntr-un lan de
proprietate consistent.
Dac aplicaia este proiectat s execute proceduri stocate i vederi n schimbul
acordrii permisiunilor de acces la tabelele din baza de date, controlul accesului la date este
mai eficient. n acest scenariu, asupra tabelelor nu trebuie s se acorde nici o pemisiune,
pentru c se configureaz mai degrab securitatea obiectelor cu care interacioneaz
utilizatorul , dect securitatea tabelelor.
a) Proceduri stocate
Atunci cnd scripturile sunt executate, comenzile utilizate n ele sunt procesate de
SQL Server pentru a afia setul de rezultate, pentru a administra SQL Server i pentru a
manipula datele coninute n bazele de date. Atunci cnd scripturile sunt salvate, ele sunt
stocate ntr-un fiier sistem i li se d n general o extensie SQL. Alternativ, scripturile
Transact-SQL pot fi numite i salvate n SQL Server ca proceduri stocate. Procedurile stocate
pot fi executate n mai multe feluri, cum ar fi prin intermediul utilitarului Query Analyzer,
pentru a procesa instruciunile Transact-SQL.
Procedurile stocate ofer beneficii de performan, un cadru de programare, comenzi i
caracteristici de securitate care nu sunt disponibile la instruciunile Transact-SQL trimise la
server pentru prelucrare. Performana este mbuntit prin stocarea datelor n baze de date
locale, precompilarea codului i utilizarea cache-ului. Un cadru de programare este furnizat
prin intermediul unei construcii de programare comune, cum ar fi parametrii de intrare i
ieire i refolosirea procedurii.
Caracteristici de securitate includ criptarea i limitarea privilegiilor care in utilizatorii
departe de structura bazei de date, dar acordndu-le n acelai timp permisiuni pentru a
executa proceduri stocate.
Performana
De fiecare dat cnd sunt trimise comenzile Transact-SQL la server pentru procesare,
serverul trebuie s stabileasc dac expeditorul are permisiunile corespunztoare pentru a
executa comenzi i dac comenzile sunt valide. Odat ce sintaxa i permisiunile sunt
verificate, SQL Server construiete un plan de executie pentru a procesa cererea. O procedur
stocat este mult mai eficient n folosirea comenzilor Transact-SQL, deoarece procedura este
stocat n SQL Server, atunci cnd este creat. Prin urmare, coninutul din cadrul procedurii
se ruleaz n cadrul serverului, atunci cnd aceasta este executat. Un script complex
Transact-SQL coninut ntr-o procedura stocat este apelat printr-o singur instruciune
Transact-SQL, mai degrab dect prin trimiterea de sute de comenzi prin reea.
nainte ca o procedur stocat s fie creat, sintaxa comenzii este verificat pentru
corectitudine. Dac nu exist erori returnate, numele procedurii este stocat n tabelul
SysObjects i textul procedurii este stocat n tabelul SysComments. Prima dat cnd este
executat procedura stocat, se creaz un plan de execuie i procedura stocat este compilat.
Prelucrarea ulterioar a procedurii stocate compilate este mai rapid, pentru c SQL Server nu
77

va verifica din nou sintaxa comenzii, nu va recrea un plan de executie i nu va recompila
procedura. Cache-ul este verificat pentru un plan de execuie nainte ca un plan nou s fie
creat.
Programarea Framework-ului
Odat ce o procedur stocat este creat, ea se poate apela ori de cte ori este nevoie.
Aceast caracteristic ofer modularitate i ncurajeaz refolosirea codului, care crete
mentenabilitatea unei baze de date. n cazul n care se schimb cerinele unei aplicaii,
procedurile stocate pot fi modificate pentru a se conforma noilor reguli. Toate aplicaiile care
apeleaz procedura stocat se vor acomoda cu noile cerine, fr o modificare direct.
Ca i alte limbaje de programare, procedurile stocate accept parametri de intrare/
ieire, ofer un feedback al execuiei n sub form de coduri de stare i text descriptiv i pot,
de asemenea, s apeleze alte proceduri. De exemplu, o procedur stocat poate returna un cod
de stare unei proceduri apelante , astfel nct procedura apelant efectueaz o operaie pe baza
codului primit.
Dezvoltatorii de software pot scrie programe sofisticate ntr-un limbaj de programare
cum ar fi C++, C#, Java i apoi pot fi folosite un tip special de proceduri stocate numite
proceduri stocate extinse pentru a apela un program din SQL Server. O procedur stocat ar
trebui scris pentru a executa o singur activitate. Cu ct este mai general procedura stocat,
cu att va fi mai util pentru mai multe baze de date. De exemplu, procedura stocat
sp_rename schimb numele unui obiect creat de utilizatori, cum ar fi un tabel, o coloan sau
un tip de date definit de utilizator n baza de date curent. Astfel, se poate folosi sp_rename
pentru a redenumi un tabel ntr-o baz de date sau o coloan de tabel ntr-o alt baz de date.
Securitatea
O alt caracteristic important a procedurilor stocate este faptul c acestea pot s
consolideze securitatea prin izolare i criptare. Utilizatorii bazei de date pot primi
permisiunea de a executa o procedur stocat, fr a avea permisiuni acordate pentru a accesa
n mod direct obiectele bazei de date cu care procedura stocat opereaz. n plus, o procedur
stocat poate fi criptat atunci cnd este creat sau modificat, astfel nct utilizatorii nu sunt
n msur s citeasc comenziile Transact-SQL din procedura stocat. Aceste funcii de
securitate pot izola structura bazei de date de utilizatorii bazei de date, asigurnd n
continuare integritatea datelor i fiabilitatea bazei de date.
b) Vederile
Vederile sunt n general folosite pentru a concentra, simplifica i personaliza concepia
fiecrui utilizator despre baza de date. Vederile se pot utiliza ca un mecanism de securitate,
permind utilizatorilor accesul la date, fr a le acorda permisiunea de a accesa direct tabelele
de baz care sunt utilizate pentru construcia vederii. Vederile se mai pot utiliza, de asemenea,
pentru a mbunti performana i s partiioneze datele atunci cnd acestea sunt copiate
din/n SQL Server.
O vedere se comport ca un filtru pentru tabelele refereniate n ea. Interogarea care
definete vederea poate fi din una sau mai multe tabele sau din alte vederi din baza de date
curent sau din alte baze de date. Se pot utiliza, de asemenea, interogri distribuite pentru a
defini vederile care utilizeaz datele din mai multe surse heterogene. Sursele heterogene ar
putea s includ alte sisteme de gestiune a bazelor de date, cum ar fi Oracle sau Access.
Aceast funcionalitate este folositoare, de exemplu, atunci cnd se dorete combinarea mai
multor structuri de date similare din servere diferite, fiecare stocnd date pentru diferite
regiuni din organizaie.
O vedere poate fi gndit ca un tabel virtual sau o interogare stocat. Datele care sunt
accesibile prin intermediul unei vederi standard nu sunt stocate n baza de date ca un obiect
distinct. n baza de date este stocat o instruciune SELECT. Rezultatul instruciunii SELECT
formeaz tabelul virtual returnat de vedere. Un utilizator poate folosi acest tabel virtual prin
78

referenierea numelui vederii n instruciunile Transact-SQL, n acelai fel n care este
refereniat un tabel. O vedere se poate utiliza pentru a ndeplini urmtoarele tipuri de funcii:
S restricioneze accesul unui utilizator la anumite rnduri dintr-un tabel;
S restricioneze accesul unui utilizator la anumite coloane dintr-un tabel;
S uneasc coloane din mai multe tabele, astfel nct s arate ca un singur tabel;
S colecioneze informaii, n loc s furnizeze detalii.

8.4.3 Strategiile de acces la date.
Strategia de acces la date depinde n mare msur de metoda de autentificare pe care
aplicaia o folosete. O aplicaie se poate conecta prin intermediul autentificrii la nivelul
Windows-ului sau la nivelul SQL Server.
1) Autentificarea la nivelul Windowsului
Cnd se utilizeaz autentificarea Windows, trebuie s se gestioneze mai nti
conectarea la SQL Server. Fiecare utilizator care folosete aplicaia are nevoie de un login
valabil pentru SQL Server. Acordarea accesului unui utilizator sau grup Windows la SQL
Server creeaz acest login. Dup ce i este acordat accesul utiliazatorului la SQL Server,
accesul la baza de date i la infrastructura permisiunilor este legat de autentificarea original.
Al doilea pas este managementul conectrilor. n primul rnd, un domeniu Windows
trebuie s autentifice utilizatorul. Utilizatorul va fi autentificat utiliznd Kerberos sau NTLM.
Dup ce utilizatorul a fost autentificat n domeniu, informaiile se pot folosi pentru a stabili o
conexiune ntre aplicaie i SQL Server. Atunci cnd se conecteaz, trebuie s se asigure o
conexiune de ncredere pentru SQL Server.
Dup ce conexiunea a fost fcut, aplicaia poate trimite comenzile Transact-SQL
direct la server sau poate executa proceduri stocate. Este de preferat s se execute proceduri
stocate, pentru a profita de caracteristicile lor de securitate. Prin utilizarea procedurilor stocate
se izoleaz aplicaia utilizator de tabelele bazei de date. Login-ul utilizatorului este stabilit de
conectarea din domeniul Windows. Acest lucru permite tuturor aplicaiilor care acceseaz
datele s profite de permisiunile stabilite. n cazul n care permisiunile sunt configurate la
nivel de tabel, atunci toate aplicaiile pe care un utilizator le poate folosi pentru a se conecta la
tabel va trebui s aib aceeai permisiune. Dac se utilizeaz proceduri stocate, utilizatorii
le-ar putea executa, de asemenea, din alt aplicaie. Diferena dintre configurarea
permisiunilor la nivelul unui tabel i executarea procedurilor stocate, este modul n care
datele sunt accesate. Atunci cnd un utilizator se poate conecta direct la tabel, utilizatorul are
capacitatea de a defini propriul lui context de modificare a datelor (interogri ad-hoc de
modificare).
2) Autentificarea la nivelul SQL Server
O aplicaie poate necesita accesul la datele din SQL Server prin utilizarea autentificrii
la nivelul severului SQL, n loc de autentificarea la nivelul Windows-ului. Un exemplu ar fi
cazurile n care nu este indicat ca toi utilizatorii s se autentifice prin intermediul unui
domeniu Windows, aa cum se ntmpl, n general, n aplicaiile folosite n Internet i n
mediile eterogene.
Autentificarea la nivelul SQL Server nu cripteaz numele de utilizator i parola atunci
cnd acestea sunt trimise la SQL Server. n plus, la autentificarea la nivelul SQL Server nu
este utilizat nici o politic pentru managementul parolelor. Ca o consecin, nu este
recomandat, de obicei, s se creeze un login pentru fiecare utilizator n SQL Server, pentru c
nu se dorete ca fiecare utilizator s trimit informaii text n clar la server de fiecare dat
cnd se conecteaz la aplicaie. Ar trebui s se utilizeze un singur cont SQL Server pentru a
efectua aciunile necesare n SQL Server. Acest cont ar trebui s fie creat n SQL Server i ar
trebui s aib acordate permisiunile de acces la baza de date a aplicaiei, precum i cele
necesare pentru a efectua toate aciunile pe care aplicaia trebuie s le ndeplineasc.
79

Pentru a face acest design s funcioneze, este necesar integrarea securitii n
aplicaie. Managementul utilizatorilor i autentificarea ar trebui s fie prevzute n aplicaie.
n multe cazuri datele despre utilizatori i parolele lor sunt stocate ntr-un tabel din baza de
date a aplicaiei. Utilizatorii aplicaiei nu sunt creai ca utilizatori SQL Server. Singurul
utilizator SQL Server este utilizatorul care este folosit n codul compilat pentru a se conecta la
server. Clientului i se atribuie un nume de utilizator i o parol pentru a accesa aplicaia.
Acest cont nu este un utilizator SQL Server valid, i aadar clientul nu poate utiliza acest cont
pentru a accesa tabelele SQL Server din alt aplicaie. Contul de conectare are toate
permisiunile i privilegiile acordate i este ascuns de utilizatori.
Dac acest model este acceptat, acesta nu este lipsit de slbiciunile sale. Deoarece
toate conexiunile la SQL Server sunt de fapt efectuate prin intermediul contului de conexiune,
SQL Server va vedea toate conexiunile la server ca fiind acelai utilizator. Dac se dorete
urmrirea utilizatorului care a efectuat o aciune, trebuie s se implementeze informaiile de
audit n aplicaie. n plus, toate administrrile de securitate sunt efectuate n cadrul aplicaiei
i nu n interiorul SQL Server.
3) Rolurile aplicaiei
Sistemul de securitate din Microsoft SQL Server este implementat, la cel mai mic
nivel, i anume la nivelul bazei de date. Aceasta este cea mai bun metod pentru controlul
activitilor utilizatorilor, indiferent de aplicaia utilizat pentru a comunica cu SQL Server.
Dar, uneori, controalele de securitate trebuie s fie personalizate pentru a veni n ntmpinarea
cerinelor speciale ale aplicaiei, mai ales atunci cnd se utilizeaz cantiti mari de date sau
modele logice complicate. n astfel de cazuri, se urmrete izolarea aplicaiei propriu-zise de
toate celelalte aplicaii. Prin implementarea rolurilor la nivelul aplicaei se poate izola, de
asemenea, securitatea n cadrul aplicaiei.
Rolurile la nivelul aplicaei sunt diferite n multe aspecte de rolurile standard de la
nivelul bazelor de date. Rolurile aplicaiilor ar trebui folosite ca un mecanism de izolare i
ncorporate n structura securitii. Acestea nu trebuie s fie grupate n aceeai categorie ca
alte roluri. Rolurile la nivelul aplicaiei au urmtoarele caracteristici:
Rolurile la nivelul aplicaiei nu conin membri. Ele sunt activate cu execuia unei
proceduri stocate, nu cu un nume de utilizator i parol;
Utilizatorii i grupurile Windows, utilizatorii bazelor de date i rolurile la nivelul
bazelor de date nu pot fi adugate rolurilor la nivelul aplicaiei, contextul de securitate fiind
stabilit de aplicaia cu care utilizatorul interacioneaz;
Implicit, rolurile la nivelul unei aplicaii sunt inactive i pentru a fi activate necesit
execuia unei proceduri stocate i livrarea unei parole;
Permisiunile sunt acordate rolurilor aplicaiei similar cu celelalte tipuri de roluri;
Rolurile aplicaiei ocolesc permisiunile standard. Contextul de securitate al
utilizatorului este definit de rolul de la nivelul aplicaiei i aadar orice permisiune acordat
utilizatorului este ignorat, fiind utilizate doar permisiunile acordate rolului de la nivelul
aplicaei;
Auditarea este limitat. Toi utilizatorii unei aplicaii vor aprea ca acelai rol i nu cu
propriile lor nume de utilizatori.
n cazul n care un rol de la nivelul aplicaiei este activat de ctre aplicaie pentru o
conexiune dat, conexiunea pierde toate permisiunile acordate contului de autentificare,
contului de utilizator, altor grupuri de utilizator sau roluri la nivelul bazei de date pe durata
conexiunii. Conexiunea obine permisiunile asociate cu rolul la nivelul aplicaiei pentru baza
de date n care exist acel rol. Deoarece rolurile la nivelul aplicaiilor sunt aplicabile doar
pentru baza de date n care ele se afl, conexiunea poate obine accesul la o alt baz de date
prin intermediul permisiunilor acordate contului de utilizator guest n alt baz de date.
Aadar, dac un cont de utilizator guest nu exist ntr-o baz de date , conexiunea nu poate
80

obine accesul la baza de date. Dac contul de utilizator guest exist n baza de date, dar
permisiunile necesare pentru a accesa un anumit obiect nu sunt acordate acestuia, conexiunea
nu poate obine accesul la obiect, indiferent de cine a creat obiectul. Permisiunea pe care
utilizatorul a obinut-o de la rolul aplicaiei rmne activ pn cnd conexiunea este
ntrerupt.
Pentru a se asigura c toate funciile aplicaiei pot fi efectuate, o conexiune trebuie s
piard permisiunile implicite asociate contului de autentificare i contului de utilizator sau ale
altor grupuri sau roluri ale bazei de date, pe durata de conectare, i s obin permisiunile
asociate cu rolul aplicaiei. De exemplu, dac un utilizator nu are permisiunea de acces la un
tabel pe care aplicaia trebuie s l acceseze, atunci accesul refuzat trebuie s fie revocat, astfel
nct utilizatorul s poat folosi aplicaia cu succes. Rolurile aplicaiei depesc orice conflicte
cu permisiunile implicite ale unui utilizator, prin suspendarea temporar a permisiunilor
implicite ale unui utilizator i atribuirea utilizatorului numai a permisiunilor acordate rolului
de la nivelul aplicaiei.
Permisiunile rolului de la nivelul aplicaiei pot fi acordate, revocate i refuzate ca oricare
alte roluri ale bazei de date.
Rolurile aplicaiei poart rspunderea pentru autentificarea utilizatorilor i nu SQL
Server. Cu toate acestea, pentru c SQL Server trebuie s autentifice totui aplicaia atunci
cnd acceseaz baza de date, aplicaia trebuie s furnizeze o parol, pentru c nu exist un alt
mod de a autentifica aplicaia. Parola este trimis la server ca un parametru pentru procedura
stocat sp_setapprole. Procedura stocat sistem este executat de client pentru a stabili
contextul de securitate al rolului aplicaiei i pentru a trimite parola pentru autentificare.
Dac nu este necesar accesul ad-hoc la baza de date, nu este nevoie s li se acorde nici
o permisiune grupurilor de utilizatori, deoarece toate permisiunile sunt atribuite de aplicaiile
utilizate pentru a accesa baza de date.
Exist mai multe opiuni pentru securizarea parolelor. De exemplu, poate fi folosit o
cheie criptat stocat ntr-o baz de date SQL Server, pentru care numai aplicaia are cheia de
decriptare. Aplicaia citete cheia, o decripteaz i i folosete valoarea pentru a stabili rolurile
la nivelul aplicaiei. Se poate folosi protocolul SSL pentru a cripta pachetul reea care conine
parola. n plus, atunci cnd rolul este activat, parola poate fi criptat nainte de a fi trimis
unei instane SQL Server.
Dup ce un rol la nivelul aplicaiei este activat cu procedura stocat sp_setapprole, rolul
nu poate fi dezactivat din baza de date curent pan cnd utilizatorul nu se deconecteaz de la
SQL Server.
Procedura stocat sp_setapprole poate fi executat direct numai prin intermediul
instruciunilor Transact-SQL. Procedura nu poate fi executat n alt procedur stocat sau
ntr-o tranzacie definit de utilizator. Orice utilizator poate executa procedura stocat att
timp ct cunote parola corect. Sistemul este la fel de sigur ca parola care a fost aleas.

EXEC sp_setapprole 'AppRole', 'P@r0la'
Instruciunea va executa procedura stocat i va trimite parola P@r0la n formatul text
clar la server.







81

CAPITOLUL 9
Salvarea i restaurarea bazelor de date


9.1 Salvarea bazelor de date

9.1.1 Generaliti
Acest modul ofer noiunile fundamentele de salvare a bazelor de date Microsoft
SQL Server, precum i sugestii cu privire la momentul cnd s se fac salvarea
bazelor de date i paii pentru a efectua backup-uri. Dup ce ai nvat diferite
metode de backup SQL Server, vei fi n msur s stabilii o strategie de backup
care este adecvat pentru mediul de afaceri n care se utilizeaz baza de date.
Dup terminarea acestui modul, vei fi capabil s:

Creai fiiere de backup i seturi de backup.

Setai i schimbai un model de recuperare a bazei de date.

Salvai bazele de date utilizator i de sistem prin utilizarea Transact-SQL i SQL Server
Enterprise Manager.

Salvai bazele de date care sunt create pe mai multe fiiere i filegroups.

Aplicai opiunile corespunztoare de backup pentru fiecare dintre diferitele metode de

backup.

Proiectai o strategie de backup adecvat.

Prevenirea pierderilor de date este una dintre problemele cele mai critice pe care
administratorii de baze de date le ntlnesc.
Trebuie s avei o strategie de backup pentru a minimiza pierderea de date i a recupera datele
pierdute. Se pot pierde date ca rezultat al defectelor hardware sau software sau ca urmare a:

Utilizarea accidental sau ru intenionat a instruciunii DELETE.

Utilizarea accidental sau ru intenionat a instruciunii UPDATE -de exemplu, nu se

folosete o clauz WHERE cu instruciunea UPDATE (toate rndurile sunt actualizate,
mai degrab dect un singur rnd dintr-un tabel).

Virui distructivi.

Dezastre naturale, cum ar fi incendii, inundaii, cutremure.

Furt.
Dac avei o strategie de rezerv adecvat, avei posibilitatea s restabilii datele cu cost
minim
de producie i n timp util, pentru a minimiza ansa de pierdere permanent de date. Gndii-
v
la strategia de backup ca la o poli de asigurare. Strategia de backup ar trebui s aduc
sistemul dvs. cum a fost nainte de a fi aprut o problem. Ca i cu o poli de asigurare,
ntrebai-v: "Ct de mult sunt eu dispus s pltesc i ct de mult pierderea este acceptabil
pentru mine? "
Costurile care sunt asociate cu o strategie de backup includ cantitatea de timp
care este cheltuit pentru proiectarea, implementarea, automatizarea i testarea
procedurii de backup. Dei nu se poate evita complet pierderea de date, ar trebui s
elaborai strategii de salvare pentru a reduce gradul de pierdere a lor. Atunci cnd
planificai strategia de BACKUP, luai n considerare durata acceptabil de timp n care
sistemul poate fi neoperaional, precum i valoarea acceptabil a pierderilor de date (dac
exist) n ipoteza c a survenit o eroare de sistem.
Ct de des v salvai bazele de date depinde de cantitatea de date care suntei dispus s o
82

pierdei i de volumul de activitate a bazelor de date. Atunci cnd salvai bazele de date
utilizator, luai n considerare urmtoarele aspecte:
S-ar putea salva baza de date frecvent dac sistemul dvs. este ntr-un mediu de procesare a
tranzaciilor online (OLTP- OnLine Transaction Processing).
S-ar putea ssalva baza de date mai puin frecvent n cazul n care sistemul are activitate
redus sau este folosit n principal pentru suport decizional.
Ar trebui s programai backup-uri atunci cnd SQL Server nu se afl n proces de
actualizare intens.
Dup ce a stabili strategia de backup, putei automatiza procesul de salvare cu ajutorul
Database Maintenance Plan Wizard.
Avei posibilitatea s setai sau s modificai modelul dvs. de recuperare n orice moment, dar
ar trebui s planificai un model de recuperare atunci cnd v creai o baz de date.
Stabilirea unui model de recuperare de date
SQL Server are trei modele de recuperare a bazelor de date . Fiecare dintre modele menine
datele n cazul unei defeciuni de server, dar exist diferene eseniale n modul n care SQL
Server recupereaz datele i legat de performan(n caz de eroare).
Modelul Full Recovery
Avei posibilitatea s utilizai modelul de recuperare complet atunci cnd recuperarea
integral de date de la dispozitive media deteriorate este cea mai mare prioritate. Acest model
foloseste copii ale bazei de date i toate copiile de log pentru a restabili baza de date. SQL
Server nregistreaz toate modificrile din baza de date, inclusiv operaiunile bulk i crearea
de indeci. Cu condiia c fiierele de log nu sunt deteriorate, SQL Server poate recupera
toate datele, cu excepia tranzaciilor aflate n derulare n momentul incidentului.
Pentru c toate tranzaciile sunt nregistrate n log, recuperarea se poate face la orice moment
de timp. SQL Server suport introducerea de mrci n log pentru a permite recuperarea la o
marc specific.
Pentru c mrcile de tranzacie n jurnal consum spaiu, ar trebui s le utilizai doar pentru
tranzaciile care joac un rol important n strategia de recuperare a bazei de date.
Cea mai important limitare a acestui model este dat de dimensiunea mare a fiierelor de
jurnal i de costurile de stocare i de performan.
Modelul Bulk_Logged Recovery
Similar cu modelul full recovery, modelul de recuperare Bulk_Logged folosete att
backups de baze de date ct i de jurnal pentru a recrea o baz de date. Cu toate acestea,
modelul Bulk_Logged de recuperare utilizeaz mai puin spaiu jurnal pentru urmtoarele
operaiuni: CREATE INDEX, operaiuni bulk load, SELECT INTO, WRITETEXT i
UPDATETEXT. Jurnalul constat numai apariia acestor operaiuni ca bits n extensii, n loc
de a stoca detaliile operatiunilor n sine.
Pentru a pstra modificrile pentru o intreaga operatiune de tip bulk load, extensiile marcate
ca fiind schimbate, de asemenea, sunt stocate n jurnal. Stocnd doar rezultatul final al
operaiunilor multiple, jurnalul este de obicei mai mici i operaiile de tip bulk load se pot
derula mai repede.
Folosind acest model se pot restaura toate datele, dar un dezavantaj este c nu este posibil
a se restabili doar o parte a unei copii de rezerv, cum ar fi restabilirea la o marc specific
Modelul Simple Recovery
Utilizai modelul de recuperare simpl pentru baze de date mici sau baze de date n care datele
se modific rar. Acest model foloseste copii complete sau difereniale ale bazei de date i
recuperarea se limiteaz la refacerea bazei de date la punctul n care a fost fcut ultima copie
de rezerv. Toate modificrile fcute dup backup s-au pierdut i trebuie s fie recreate.
Beneficiul principal al acestui model este c este nevoie de puin spaiu de stocare i este cel
mai simplu model de pus n aplicare.
83

Schimbarea unui model de recovery
n mod implicit, SQL Server Standard Edition i SQL Server Enterprise Edition utilizeaz
modelul de recuperare full. Avei posibilitatea s modificai modelul de recuperare la orice
moment, dar trebuie s facei o copie de siguran suplimentar la momentul schimbrii.
Pentru a afla ce model de recovery utilizeaz o baz de date, se folosete funcia
DATABASEPROPERTYEX.
ALTER DATABASE database_name
SET RECOVERY {FULL | SIMPLE | BULK_LOGGED}
Acest exemplu seteaz modelul de recuperare a bazei de date Northwind la Bulk_Logged:
ALTER DATABASE Northwind SET RECOVERY BULK_LOGGED
n timpul operaiunii de backup, SQL Server:

V permite s efectuai copii de rezerv ale bazei de date n timp ce utilizatorii continu s
lucreze cu baza de date.

Salveaz fiierele originale ale bazei de date i nregistreaz locaiile lor.Bacup-ul conine:
o
Schema i structura de fiiere.
o
Datele.
o
Poriuni din fiierele de tranzacii.Partea din tranzacii care este salvat conine activitile
din de baza de date de la nceputul procesului de backup.SQL Server utilizeaz aceste
backup-uri pentru a recrea fiierele n locaiile originale, complet cu obiecte i de date,
atunci cnd restaurai o baz de date.

Capteaz activitile din baza de date care apar n timpul procesului de backup. Procesul de
backup este dinamic i, cu unele excepii, poate aprea n timp ce baza de date este online i
este modificat activ. Procesul de backup dinamic este realizat atunci cnd SQL Server:
o
Declaneaz un punct de control (checkpoint) n baza de date i nregistreaz numrul de
ordine jurnal (LSN- Log Sequence Number) pentru cea mai veche tranzacie activ.
o
Scrie toate paginile pe dispozitivul de backup prin citirea direct a discurilor t (ocolind
buffer cache).
o
Scrie toate nregistrrile din log scrise n timpul procesului de backup. Concret, SQL
Server scrie nregistrrile tranzaciilor din jurnal nregistrate de la LSN pn la sfritul
jurnalului.

9.1.2 Efectuarea i stocarea copiilor de backups
Pentru a salva o baz de date SQL Server, trebuie s se ia n considerare cui i este
permis s efectueze copierea i unde o poate pstra. Putei crea copii de baze de date
executnd instruciuni Transact-SQL sau prin utilizarea SQL Server Enterprise
Manager(sau SQL Server Management Studio).
Cine efectueaz backups
Membrii urmtoarelor roluri au permisiunea de salva o baz de date:

Rolul server fixat sysadmin

Rolul baz de date fixat db_owner

Rolul baz de date fixat db_backupoperator

Pot fi create roluri suplimentare i li se acord permisiunea de salva o baz de date.
Unde se pstreaz backups
SQL Server poate face un backup ntr-un fiier de pe hard disk, pe band, sau pipe cu nume.

Fiierele disc (locale sau de reea) sunt cele mai comune medii utilizate pentru a stoca nite
copii de rezerv.

Atunci cnd se face un backup pe o band, unitatea de band trebuie s fie ataat la nivel
local la SQL Server.
84

SQL Server ofer posibilitatea de a salva o baz de date pe un pipe cu nume, n scopul de a
permite utilizatorilor s profite de caracteristicile de salvare i restaurare ale altor pachete
software.
Cnd s se fac backups
Cnd i ct de des salvai o baz de date depinde de mediul dvs. de lucru. Cu toate acestea,
exist situaii n care ar putea fi necesar s se completeze strategia de backup. De exemplu, ai
putea avea nevoie ocazional s salvai bazele de date de sistem sau o anumit baz de date
utilizator.
Dei backup-ul SQL Server este dinamic, unele activiti nu pot s apar n baza de date n
timpul operaiilor de backup.
Salvarea bazelor de date system
Bazele de date sistem stocheaz date importante despre SQL Server i toate bazele de date
utilizator. Prin urmare, se recomand s salvai bazele de date de sistem n mod regulat i, n
mod special, ori de cte ori le modificai:

Dup modificarea bazei de date master

Baza de date master conine informaii despre toate bazele de date de pe SQL Server.
Salvai baza de date master atunci cnd este creat orice baz de date de ctre un utilizator.
n caz c master devine corupt, dup ce va fi restaurat, avei posibilitatea s restaurai alte
baze de date sistem i utilizator , care sunt referite.
Cnd executai anumite instruciuni sau proceduri stocate, SQL Server modific baza de date
master n mod automat. Prin urmare, salvai baza de date master atunci cnd executai
urmtoarele aciuni:
CREATE DATABASE, ALTER DATABASE sau DROP DATABASE, instruciuni
care creeaz, modific sau elimin o baz de date.
Procedura stocat sistem sp_logdevice, care modific transaction log.
Procedurile stocate sistem sp_addserver, sp_dropserver i sp_addlinkedserver, care
adaug sau terg servere.
Procedura stocat sistem sp_addmessage, sau adugarea de mesaje de eroare
cu Server SQL Enterprise Manager sau SQL Server Management Studio.

Dup modificarea bazei de date msdb

Salvai baza de date msdb dup ce o modificai, deoarece msdb conine informaii despre jobs,
alerte i operatorii care sunt utilizai de ctre SQL Server Agent. Dac nu avei o copie de
rezerv actual a bazei de date msdb, trebuie s reconstruii toate bazele de date de sistem n
cazul unei defeciuni i apoi s recreai fiecare job, alert i operator.

Dup modificarea bazei de date model

Facei o copie de rezerv a bazei de date model dac o modificati pentru a include
configurarea implicit pentru toate bazele de date utilizator nou create. Deoarece bazele de
date de utilizator sunt reconstruite n cazul n care bazele de date model sau msdb sunt
reconstruite, modificrile bazei de date model sunt, de asemenea, pierdute. Avei posibilitatea
s restaurai o copie de rezerv a bazei de date model n cazul apariiei unei erori de sistem.
Salvarea bazelor de date utilizator
Ar trebui s planificai salvarea bazelor de date ceate de dumneavoastr n mod regulat.
Trebuie, de asemenea, s efectuai o copie de rezerv dup ce o baz de date sau index se
creaz i atunci cnd anumite operaii nenregistrate n log sunt executate:

Dup crearea bazelor de date.

Ar trebui s facei o copie de rezerv pentru o baz de date dup ce a fost creat sau ncrcat
cu date. Fr o copie de rezerv a bazei de date complet, nu se pot restaura backup-uri de
jurnal tranzacionale, pentru c trebuie s avei o linie de baz la care se pot aplica logurile
tranzacionale.

Dup crearea indecilor.

85

Ar trebui s salvai baza de date ori de cte ori creai un index. Cu toate c nu suntei obligai
s facei acest lucru, dac baza de date este pierdut, vei economisi timp n cursul procesului
de restaurare. Salvarea unei baze de date, dup ce un index este creat, asigur c fiierul de
backup conine datele i structurile de index.
Dac salvai numai log-ul dup ce un index este creat, iar apoi restabilii acel log la un
moment dat, SQL Server trebuie s reconstruiasc indexul. Timpul necesar pentru a reconstrui
indexul poate fi mai mare dect timpul necesar pentru a restaura o copie de rezerv complet
a bazei de date.

Dup execuia unor operaii nenregistrate n log.

Operaiile care nu sunt nregistrate n jurnalul de tranzacii sunt numite operaii nenregistrate.
Cu unele modele de recovery, nu se pot recupera modificrile fcute de ctre urmtoarele
operaii nenregistrate:
Instruciunea WRITETEXT sau UPDATETEXT. SQL Server modific datele n
coloanele de tip text i, n mod implicit, nu nregistreaz aceast activitate n
jurnal. Cu toate acestea, avei posibilitatea s specificai opiunea WITH LOG pentru a
scrie aceste activiti n log.
Instruciunea SELECT INTO, atunci cnd creai un tabel permanent sau folosii un
program de bulk copy.
Salvai o baz de date dup ce efectuai o operaie nenregistrat, pentru c, dac dac
sistemul eueaz, log-ul tranzacional ar putea s nu conin informaiile necesare
pentru a restabili baza de date ntr-o stare consistent.
Activiti restricionate n timpul salvrii bazelor de date
Putei salva o baz de date n timp ce este on-line i activ. Cu toate acestea, cteva operaii
nu sunt recomandabile n timpul procesului de backup. Evitai urmtoarele activiti n timpul
backup-ului:

Crearea sau modificarea bazelor de date cu instruciunea CREATE DATABASE sau

ALTER DATABASE.

Efectuarea operaiunilor de autogrow.

Crearea indecilor.

Efectuarea oricrei operaii nenregistrate, inclusiv operaii de tip bulk load i

instruciunile SELECT INTO, WRITETEXT i UPDATETEXT.

Micorarea unei baze de date.

Efectuarea salvrii bazelor de date
Cnd efectuai un backup, mai nti trebuie s creai fiierele de rezerv (permanente
sau temporare) care s conin backupul. SQL Server ofer opiuni care se pot aplica la
fiecare dintre metodele de backup care sunt disponibile.
Dei SQL Server, de asemenea, v permite s alegei un numr mare de destinaii de backup,
discul i banda sunt cele mai ntlnite.
Primul pas n realizarea unei copii de rezerv este de a crea fiierele care vor conine
backupul. Un fiier de backup care este creat nainte de a fi folosit pentru o copie de siguran,
se numete dispozitiv de backup.
De ce este nevoie de dispozitive de backup permanente
Dac dorii s reutilizai fiierele de backup pe care le creai sau s automatizai operaia de
salvare a bazei de date, trebuie s v creai dispozitive permanente de backup. Avei
posibilitatea s creai dispozitive de backup cu SQL Server Enterprise Manager/ SQL Server
Management Studio sau executnd procedura stocat sistem sp_addumpdevice.
Atunci cnd creai dispozitive de backup, luai n considerare urmtoarele fapte:

SQL Server creeaz nume logice i fizice n tabelul sistem sysdevices din baza de date
master.

Trebuie s specificai numele logic i fizic ale fiierului de backup.

86

Putei crea pn la 64 fiiere de backup pentru o baz de date.

Cnd creai un dispozitiv de backup nou cu SQL Server Enterprise Manager/ SQL Server
Management Studio, SQL Server execut procedura stocat de sistem sp_addumpdevice.
Sintaxa:
sp_addumpdevice [@devtype = ] device_type,
[@logicalname = ] logical_name,
[@physicalname = ] physical_name
[,{ [@cntrltype =] controller_type | [@devstatus = ] device_status}]
Where device_type este {DISK | TAPE | PIPE}.
Exemplul 1:
Acest exemplu creeaz un fiier de backup permanent pe un hard disk:
USE master
EXEC sp_addumpdevice 'disk', 'mybackupfile',
'C:\ Backup\MyBackupFile.bak'
Exemplul 2:
Acest exemplu creeaz un dispozitiv de backup pe o band cu numele logic Mytape1 i cel
fizic \\.\tape0:
USE master
EXEC sp_addumpdevice 'tape', 'mytape1', '\\.\tape0'
De ce este nevoie de dispozitive de backup temporare
Dac crearea unui dispozitiv de backup permanent este de preferat, de asemenea, avei
posibilitatea s creai fiierele temporare de rezerv cu instruciunea BACKUP DATABASE,
fr a specifica un dispozitiv de backup.
Dac nu intenionai s reutilizai fiierele de backup, creai un fiier de backup fr un
dispozitiv permanent. De exemplu, dac efectuai un backup doar o dat sau testai o operaie
de salvare pe care intenionai s o automatizai, putei s creai un fiier de backup temporar.
Creai fiierele de backup temporare cu instruciunea BACKUP DATABASE sau cu
Enterprise Manager/ SQL Server Management Studio. Dac creai un fiier de backup
temporar, trebuie s:

Specificai un tip de media (disc, band, sau pipe cu nume).

Specificai calea complet i numele fiierului.

Sintaxa:
BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [, ...n]
Where <backup_device> is:
{{backup_device_name | @backup_device_name_var} | {DISK | TAPE |
PIPE} =
{'temp_backup_device' | @temp_backup_device_var}
Exemplu:
Acest exemplu creeaz un fiier de backup temporar pe un disc i salveaz baza de date
master n acesta:
USE master
BACKUP DATABASE Northwind TO DISK = 'C:\Temp\MyCustomers.bak'
Folosirea fiierelor de backup multiple

87




SQL Server poate scrie n mai multe fiiere de backup n acelai timp (n paralel).
Cnd avei mai multe fiiere de backup, datele sunt scrise n toate fiierele care sunt folosite
pentru a crea copia de rezerv. Aceste fiiere alctuiesc un set de backup. Un set de backup
este
un rezultat al unei operaiuni de salvare pe unul sau mai multe fiiere.
Folosii mai multe benzi magnetice sau controlere de disc pentru a reduce timpul total necesar
pentru a salva o baz de date. De exemplu, dac o operaiune de backup care folosete o
unitate de band dureaz n mod normal patru ore pentru a se finaliza, avei posibilitatea s
folosii o a doua band, ce conduce la reducerea duratei operaiei la numai dou ore.
Sintaxa:
BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [, ...n]
[WITH
[MEDIANAME = {media_name | @medianame_var}]
]
Atunci cnd utilizai mai multe fiiere pentru a stoca backupuri, luai n considerare
urmtoarele aspecte:

Toate dispozitivele care sunt folosite ntr-o operaiune de backup trebuie s fie de acelai tip
de media (disc sau band). Nu putei amesteca dispozitive disc i banda pentru un singur set
de backup. Un set media este o colecie de fiiere care sunt utilizate pentru a conine unul sau
mai multe seturi de backup.

Avei posibilitatea s utilizai o combinaie de fiiere permanente i temporare atunci cnd a

creai un set de backup.
88

Dac definii un fiier ca membru al unui set de backup, trebuie s utilizai ntotdeauna
fiierele mpreun.

Nu putei utiliza doar un membru al setului de backup pentru o operaiune de backup,

exceptnd cazul n care reformatai fiierele.

Dac reformatai un membru al unui set de backup, datele care sunt coninute n
ali membri ai setului de backup nu sunt valide i utilizabile.
De exemplu, dac un set de backup a fost creat cu dou fiiere, toate operaiunile de backup
ulterioare care implic setul de backup trebuie s foloseasc aceleai dou fiiere. Putei
aduga backup-uri suplimentare pentru aceste dou fiiere. Cu toate acestea, n cazul n care
dorii s utilizai numai unul dintre aceste fiiere pentru a salva o alt baz de date sau pentru
a-l folosi ca parte dintr-un alt set de backup, trebuie s reformatai fiierul.
Utilizarea instruciunii BACKUP
Putei efectua operaiuni de backup cu SQL Server Enterprise Manager/ SQL Server
Management Studio, Backup Wizard, sau cu instruciuni Transact-SQL. Ar trebui s fii
familiarizat cu opiunile care sunt disponibile atunci cnd utilizai oricare dintre metodele de
backup.
Sintaxa:
BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [, ...n]
[WITH
[FORMAT]
[[,] {INIT | NOINIT}]
]
Atunci cnd salvai o baz de date, determinai dac suprascriei sau adugai la un fiier de
backup:

n mod implicit SQL Server adug (NOINIT) backup la un fiier. Dac utilizai opiunea
NOINIT, SQL Server adaug un backup la un fiier de backup sau de backup set existent.

Dac utilizai opiunea INIT, SQL Server suprascrie orice date existente pe setul de backup,
dar pstreaz informaiile din antet. n cazul n care primul fiier din setul de backup de pe
dispozitiv are o etichet ANSI-standard, SQL Server determin dac setul de backup anterior
poate fi suprascris.
Operaiunea de backup nu reuete i datele nu sunt suprascrise dac:

Opiunea EXPIREDATE specificat pe dispozitivul de backup nu a expirat.

Parametrii backup_set_name pe care i-ai specificat n opiunea NAME nu se

potrivesc cu backup_set_name din dispozitivul de backup.

ncercai s suprascriei un membru al unui set de backup denumit anterior.SQL

Server detecteaz faptul c fiierul este un membru al unui set de backup.
Utilizarea opiunii FORMAT
Utilizai opiunea FORMAT pentru a suprascrie coninutul unui fiier de backup i a despri
un set de backup cnd:

Un nou antet media este scris pe toate fiierele din backup.

SQL Server suprascrie att coninutul media existent, ct i coninutul fiierului de

backup.

Utilizai opiunea FORMAT cu atenie. Formatarea numai a unui fiier de backup al

unui set face ntregul set de backup inutilizabil. De exemplu, dac o band care
conine o singur parte a unui set de backup este reformatat, ntregul set de backup
este inutilizabil.



89

9.1.3 Tipuri de salvri de baze de date
SQL Server ofer diferite metode de backup pentru a satisface nevoile utilizatorilor
pentru o gam larg de medii de afaceri i activiti cu baze de date.
La nivelul unei baze de date, n raport de modelul de recovery ales, pot exista mai multe tipuri
de backupuri:

Efectuarea unei salvri de tip full

Efectuarea unei copii de rezerv difereniale

Efectuarea unei Backup de Transaction Log

Efectuarea unui Database File or Filegroup Backup

Backup de tip full
Dac baza de date este n primul rnd o baz de date read-only, backup-ul complet de baz de
date poate fi suficient pentru a preveni pierderea de date. O copie de siguran complet de
baz de date servete ca baz n varianta apariiei unei erori de sistem. Cnd efectuai un
backup full, SQL Server:

Salveaz orice activitate care a avut loc n timpul procesului de backup.

Salveaz orice tranzacie necomis din jurnalul de tranzacii. SQL Server utilizeaz
poriuni de tranzacii care au fost capturate din fiierul de log pentru a asigura
consistena datelor n cazul n care backup-ul este restaurat.
Exemplul 1:
Acest exemplu creeaz un dispozitiv de backup cu numele logic NwindBac i face un backup
full al bazei de date Northwind.
USE master
EXEC sp_addumpdevice 'disk', 'NwindBac',
'D:\MyBackupDir\NwindBac.bak'
BACKUP DATABASE Northwind TO NwindBac
Exemplul 2:
Acest exemplu execut un backup full al bazei de date Northwind n fiierul NwindBac i
rescrie backup-urile anterioare din acel fiier.
BACKUP DATABASE Northwind TO NwindBac WITH INIT
Exemplul 3:
Acest exemplu adaug un backup full al bazei de date Northwind n fiierul NwindBac.
Fiierele de backup anterioare rmn intacte.
BACKUP DATABASE Northwind TO NwindBac WITH NOINIT
Exemplul 4:
Acest exemplu execut un backup full al bazei de date Northwind n fiierul temporar
MyTempBackup.bak.
BACKUP DATABASE Northwind TO
DISK = D:\Temp\MyTempBackup.bak

90



Backup de tip diferenial
Ar trebui s efectuai o copie de rezerv diferenial pentru a minimiza timpul care este
necesar pentru restabilirea unei baze de date frecvent modificat. Efectuai o copie de rezerv
diferenial numai dac ai efectuat o salvare de tip full a bazei de date. ntr-un backup
diferenial,
SQL Server:

Salveaz pri ale bazei de date care s-au schimbat de la ultimul backup complet al bazei de
date. Pentru a determina care pagini s-au schimbat de la ultimul backup complet al bazei de
date, SQL Server compar LSN de pe o pagin actual cu LSN al ultimului backup complet al
bazei de date. Atunci cnd se efectueaz o copie diferenial, SQL Server salveaz extensii,
mai degrab dect pagini individuale. Se salveaz extensiile al cror LSN din orice pagin
coninut este mai mare dect LSN din ultimul backup complet al bazei de date.

Se salveaz orice activitate care are loc n timpul procesului de backup, inclusiv tranzaciile
necomise din log.
Cnd efectuai o copie de rezerv diferenial, luai n considerare urmtoarele lucruri:

Dac un articol din baza de date a fost modificat de mai multe ori de la ultimul backup full de
baz de date, backup-ul diferenial conine doar ultimul set de valori pentru acel rnd. Acest
lucru este diferit de backup de log tranzacional, care conine un istoric al tuturor
modificrilor rndului respectiv.

Reducei la minimum timpul care este necesar pentru salvarea bazei de date, deoarece
seturile de backup diferenial sunt mai mici dect cele de backup-uri complete.

Reducei la minimum timpul care este necesar pentru a restaura o baz de date, deoarece nu
trebuie s aplicai o serie de loguri tranzacionale.
91

Ar trebui s se stabileasc o convenie de denumire pentru fiierele care conin

backup-urile difereniale, pentru a le deosebi de fiierele care conin backup-uri complete
ale bazei de date.
Sintaxa:
BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [, ...n]
[WITH
[DIFFERENTIAL]
]
Exemplu:
Acest exemplu creeaz un backup diferenial ntr-un fiier temporar.
BACKUP DATABASE Northwind TO
DISK = 'D:\MyData\MyDiffBackup.bak'
WITH DIFFERENTIAL
Backup de log tranzacional
Salvai logurile tranzacionale pentru a nregistra orice schimbare din baza de date. Efectuai,
de obicei, backup-uri de log tranzacional dup ce facei backup-uri complete de baze de date:

Nu ar trebui s facei o copie de rezerv pentru un jurnal de tranzacii dac nu s-a efectuat un
backup full de baz de date cel puin o dat.

Logurile tranzacionale nu pot fi restaurate dac nu exist backup-uri corespunztoare.

Nu se pot face backup-uri de log dac baza de date utilizeaz modelul simple recovery.
Atunci cnd se face un backup de log, SQL Server:

Salveaz logul tranzacional de la ultima instruciune BACKUP LOG executat cu succes

pn la sfritul logului tranzacional curent.

Trunchiaz jurnalul de tranzacii pn la nceputul poriunii active i elimin informaiile din

partea inactiv. Partea activ pornete din punctul n care s-a deschis cea mai veche tranzacie
i continu pn la sfritul logului tranzacional.
Sintaxa:
BACKUP LOG {database_name | @database_name_var}
TO <backup_device> [, n]
[WITH
[{INIT | NOINIT}]
]
Exemplu:
Acest exemplu creeaz un dispozitiv de backup i salveaz logul tranzacional al bazei de date
Northwind
USE master
EXEC sp_addumpdevice 'disk', 'NwindBacLog',
'D:\Backup\NwindBacLog.bak'
BACKUP LOG Northwind TO NwindBacLog
Backup de tip fiier sau grup de fiiere
Efectuarea de backup-uri complete pe baze de date foarte mari (VLDBs- Very Large
DataBases) nu este practic, de aceea avei posibilitatea s efectuai backup-uri la nivel de
fiier sau grup de fiiere ale bazei de date, avnd n vedere urmtoarele:

Se salveaz doar fiierele specificate n opiunea FILE sau FILEGROUP.

V permite salvarea anumitor fiiere componente i nu a bazei de date n ntregime.

Cnd efectuai backup-uri la nivel de fiiere sau grup de fiiere, avei n vedere c:

Trebuie s specificai numele logice de fiiere sau grupuri de fiiere.

Trebuie s efectuai backup-uri de log pentru a aduce fiierele restaurate n concordan cu

restul bazei de date.
92

Ar trebui s se stabileasc un plan de backup pentru fiecare fiier pe baz de rotaie, n scopul
de a v asigura c toate fiierele sau grupurile de fiiere ale bazei de date sunt salvate cu
regularitate.

Se pot specifica pn la 16 fiiere sau grupuri de fiiere.

Sintaxa:
BACKUP DATABASE {database_name | @database_name_var}
[<file_or_filegroup> [, ...m]] TO <backup_device> [, n]]
Where <file_or_filegroup> is:
{FILE = {logical_file_name | @logical_file_name_var}
|
FILEGROUP = {logical_filegroup_name | @logical_filegroup_name_var}
}
Exemplu:
Acest exemplu salveaz fiierul Orders2 al unui grup de fiiere al bazei de date PhoneOrders.
Baza de date PhoneOrders conine trei fiiere: Orders1, Orders2 i Orders3.
Fiierul jurnal este pstrat n fiierul Orderlog. Se consider c deja exist fiierele de
backup:
OrderBackup1, OrderBackup2, OrderBackup3 i OrderBackupLog.
BACKUP DATABASE PhoneOrders
FILE = Orders2 TO OrderBackup2
BACKUP LOG PhoneOrders to OrderBackupLog
Atunci cnd salvai o baz de date care const din mai multe fiiere sau grupuri de fiiere, ar
putea s fie necesar s salvai mai multe fiiere de baze de date ca o singur unitate, dac vei
crea indeci.
SQL Server detecteaz automat dac un index a fost creat de la ultima salvare a unui fiier al
bazei de date i impune ca setul complet de fiiere afectate s fie salvat ca o singur unitate.
n cazul n care un index i un tabel de baz sunt create ntr-un grup de fiiere, aa cum se
arat n scenariul 1, trebuie s se copieze ntregul grup ca o singur unitate.
Dac indecii sunt creai n mai multe grupuri de fiiere, i tabela de baz este creat n
un altgrup de fiiere, dup cum se arat n scenariul 2, trebuie s se salveze toate grupurile de
fiiere ca o singur unitate.
De exemplu, dac baza de date Contact const din trei grupuri de fiiere, n care
Filegroup1conine tabelul Clieni i indecii pe tabela Clieni sunt creai n Filegroup2 i
Filegroup3, cele trei grupuri de fiiere trebuie s se salveze ca o singur unitate.



93






9.2 Restaurarea bazelor de date

9.2.1 Generaliti
Procesul de recuperare SQL Server este un mecanism intern care ne asigur c baza de
date este consistent, prin examinarea jurnalului de tranzacii, i necesit aciuni adecvate:

SQL Server examineaz fiierul de tranzacii de la ultimul punc de control(checkpoint) la

punctul n care SQL Server a nregistrat o eroare sau a fost oprit. Un punct de
control(checkpoint) este ca un marcaj, marcnd punctul n care toate schimbrile de date sunt
scrise n baza de date.

n cazul n care fiierul de jurnalizare are tranzacii comise care nu au fost nc scrise n baza
de date, SQL Server reia aceste tranzacii, pentru a aplica modificrile n baza de date.

n cazul n care logul conine tranzacii nefinalizate, SQL Server anuleaz aceste tranzacii i
ele nu sunt scrise n baza de date.
Procesul de recuperare(recovery) apare automat sau manual:
Apare automat
Cnd sistemul este repornit dup un eec sau o oprire, SQL Server ncepe procesul de
recuperare automat a datelor pentru a asigura consistena. Nu trebuie s startai acest proces
manual, acesta apare n mod automat.
Poate fi iniiat manual
Putei iniia manual procesul de recuperare atunci cnd efectuai operaii de tip restore.
94

Procesul de recuperare pe care l iniiai este similar cu procesul de recuperare automat care
are loc atunci cnd SQL Server este repornit.
Cnd restaurai baze de date, SQL Server execut n mod automat anumite aciuni pentru a se
asigura c baza de date este restabilit rapid i cu impact minim asupra activitii de
producie.
SQL Server efectueaz o verificare de siguran atunci cnd executai instruciunea
RESTORE
DATABASE. Acest mecanism intern v mpiedic s suprascriei accidental o baz de date
existent, cu o copie de backup dintr-o alt baz de date sau cu informaii incomplete.
SQL Server nu restaureaz o baz de date dac:

Baza de date, care este numit n instruciunea RESTORE DATABASE, exist deja pe server
i numele bazei de date care se nregistreaz n fiierul de backup este diferit de numele bazei
de date din instruciunea RESTORE DATABASE.

Setul de fiiere ale bazei de date de pe server este diferit de setul de fiiere care sunt coninute
n setul de backup.

Toate fiierele care sunt necesare pentru a restaura o baz de date sau grup de fiiere nu sunt
furnizate. SQL Server genereaz un mesaj de eroare, specificnd care fiiere trebuie s fie
restaurate ca o unitate (ntr-o singur operaiune de restaurare).
De exemplu, dac ncercai s restaurai o copie a bazei de date Northwind ntr-o baz de
date numit Accounting i Accounting exist deja pe server, SQL Server v mpiedic s
facei restaurarea. Dac intenionai s restaurai o copie de rezerv a Northwind i s
suprascriei datele din Accounting , trebuie s trecei peste verificarea de siguran.
Cnd restaurai o baz de date dintr-un backup full, SQL Server recreeaz fiierele originale
ale baze de date i le plaseaz n locaiile n care au fost nregistrate atunci cnd a fost fcut
salvarea. Toate obiectele bazei de date sunt recreate n mod automat. Nu avei nevoie s
reconstruii schema bazei de date nainte de a o restaura.

9.2.2 Pregtirea pentru restaurare a unei baze de date
Ar trebui s verificai copiile de backup pentru a vi se confirma c restaurai datele i
obiectele dorite i c backup-urile conin informaii valide.
nainte de a restaura o copie de rezerv, trebuie s efectuai operaii specifice care v permit
s ncepei procesul de restaurare.
Avei posibilitatea s utilizai SQL Server Enterprise Manager/SQL Server Management
Studio pentru a vizualiza foaia de proprieti pentru fiecare dispozitiv de backup. Pentru mai
multe detalii despre backup-uri, avei posibilitatea s executai urmtoarele instruciuni
Transact-SQL:
Instruciunea RESTORE HEADERONLY
Utilizai aceast instruciune pentru a obine informaii de antet ale unui anumit fiier sau
set de backup. n cazul n care pe un fiier de backup sunt mai multe backup-uri, SQL Server
returneaz informaii antet pentru toate copiile de backup care sunt coninute n acel fiier.
Cnd executai instruciunea RESTORE HEADERONLY, primii urmtoarele informaii:

Denumirea i descrierea fiierului sau setului de backup.

Tipul de media folosit pentru backup, cum ar fi o band sau pe hard disk.

Metoda de backup: complet, diferenial, tranzacional sau fiier.

Data i ora la care a fost efectuat backup-ul.

Dimensiunea backup-ului.

Numrul de ordine al unui backup ntr-un lan de fiiere de backup.

95

Instruciunea RESTORE FILELISTONLY
Utilizai aceast instruciune pentru a obine informaii despre baza de date sau fiierele de
tranzacii care sunt coninute ntr-un fiier de backup. Aceast instruciune v poate ajuta s
evitai restaurarea greit a fiierelor de backup.
Cnd executai instruciunea RESTORE FILELELISTONLY, SQL Server returneaz
urmtoarele informaii:

Numele logice ale fiierelor bazei de date i de tranzacii

Numele fizice ale fiierelor bazei de date i de tranzacii

Tipul de fiier, cum ar fi o baz de date sau un fiier de tranzacii

Apartenena la un grup de fiiere

Dimensiunea setului de backup, n megaoctei (MO)

Dimensiunea maxim permis a fiierului, n MB.

Instruciunea RESTORE LABELONLY
Utilizai aceast instruciune pentru a obine informaii despre suportul care deine un
fiier de backup.
Instruciunea RESTORE VERIFYONLY
Utilizai aceast instruciune pentru a verifica dac fiierele individuale care alctuiesc setul
de backup sunt complete i c toate copiile de backup pot fi citite. SQL Server nu verific
structura de date care este coninut n backup.
nainte s restaurai backup-uri trebuie s restricionai accesul la baza de date i s salvai
logul curent.
Restricionare acces la baza de date
Este important s se restricioneze accesul la o baz de date nainte de restaurare. Setai
opiunea bazei de date Members of db_owner, dbcreator, or sysadmin la true.
Salvare fiier de log tranzacional
Avei posibilitatea s asigurai consistena bazei de date dac salvai fiierul jurnal naintea
oricrei operaii de restaurare:

Backup-ul de jurnal tranzacional este folosit pentru a recupera baza de date ca ultim pas n
procesul de restaurare.

Dac nu salvai fiierul de log nainte de a v restaura copiile de siguran, vei pierde
modificrile de date care au avut loc ntre ultimul backup de log i momentul n care baza de
date a devenit offline.

9.2.3 Restaurarea backup-urilor unei baze de date - opiuni
Putei folosi utilitarele SQL Server Enterprise Manager/SQL Server Management
Studio sau instruciunea RESTORE i s specificai opiunile care sunt proprii tipului de
backup pe care l restaurai. Putei determina, de asemenea, dac s iniiai sau nu procesul de
recovery dup fiecare operaie de restaurare.
Folosirea instruciunii RESTORE
Avei posibilitatea s utilizai instruciunea RESTORE sau SQL Server Enterprise
Manager/SQL Server Management Studio pentru a efectua operaii de restaurare.
Opiunile de restaurare v permit s specificai detalii cu privire la modul de a restaurare
backup-uri.
Sintaxa:
RESTORE DATABASE {database_name | @database_name_var}
[FROM <backup_device> [, ... n]]
[WITH
[FILE = file_number]
[[,] MOVE 'logical_file_name' TO 'operating_system_file_name']
[[,] REPLACE]
96

[[,] {NORECOVERY | RECOVERY | STANDBY = undo_file_name}]]
[[.] RESTART]
Unde <backup_device> este
{{backup_device_name | @backup_device_name_var} |
{DISK | TAPE | PIPE} = {'temp_backup_device' |
@temp_backup_device_var}
}
Exemplu:
Acest exemplu restaurez baza de date Northwind dintr-un fiier de backup permanent.
USE master
RESTORE DATABASE Northwind
FROM NwindBac
Restaurarea bazelor de date distruse
Dac o baz de date devine deteriorat, utilizai instruciunea RESTORE sau SQL Server
Enterprise Manager SQL Server Management Studio pentru a restaura baza de date, cu
suprascriere. Cnd restaurai o baz de date cu suprascriere:

Nu avei nevoie s tergei baza de date deteriorat.

SQL Server recreeaz n mod automat fiierele i obiectele bazei de date .

Iniierea procesului de recuperare
Trebuie ntotdeauna s se precizeze opiunea RECOVERY sau NORECOVERY pentru
prevenirea erorilor administrative n timpul procesului de restaurare i pentru a spori
lizibilitatea instruciunii. Opiunea RECOVERY este implicit pentru SQL Server; utilizai
aceast opiune cu ultimul log tranzacional care urmeaz s fie restaurat sau cu un backup
full de baz de date, pentru a ajunge ntr-o stare consistent:

SQL Server anulez orice tranzacie necomis n logul tranzacional i reia orice tranzacie
comis.

Baza de date este disponibil pentru utilizare dup ce procesul de recuperare se termin.
Utilizai opiunea NORECOVERY atunci cnd avei mai multe copii de siguran pentru a fi
restaurate. Gndii-v la urmtoarele lucruri atunci cnd utilizai opiunea NORECOVERY:

Specificai opiunea NORECOVERY pentru toate copiile de backup, cu excepia ultimei.

SQL Server nu anuleaz tranzaciile necomise din log i nici nu le reia pe cele comise.

Baza de date nu este disponibil pentru utilizare pn ce nu este recuperat.

Specificarea opiunilor de restaurare:

Opiune de restaurare Descriere
FILE
Restaureaz un backup specific
Trebuie dat numrul de fiier
RESTART
Continu o operaie de recuperare
ntrerupt
MOVE TO
Specific unde s restaureze fiierele
de backup
Utilizat pentru restaurare pe disc sau
server diferite dect la salvare
REPLACE
nlocuiete o baz de date existent
SQL server nu face o verificare de
siguran


97


9.2.4 Restaurarea bazelor de date din diferite tipuri de backup-uri
Pentru a restaura o baz de date, trebuie s tii tipul de metod de salvare care a fost
utilizat i dac exist backup-uri. Asigurai-v c backup-urile sunt valide i c avei toate
fiierele sau benzile care conin setul de backup.
A. Restaurarea dintr-un backup de baz de date complet (full)
Cnd restaurai o baz de date dintr-un backup complet, SQL Server recreeaz baza de
date i toate fiierele sale asociate i apoi le plaseaz n locaiile lor originale. Toate obiectele
bazei de date sunt recreate n mod automat. Nu avei nevoie s reconstruii schema bazei de
date nainte de a o restaura. De obicei, se va face restaurarea bazei de date dintr-un backup
complet atunci cnd:

Discul fizic al bazei de date este deteriorat.

ntreaga baz de date este deteriorat, corupt sau tears.

O copie identic a bazei de date este n curs de restaurare pe un alt SQL Server.
Specificarea opiunii RECOVERY
Opiune RECOVERY iniiaz procesul de recuperare, astfel nct baza de date este adus la o
stare consistent:

Dac implementai o strategie de backup full de baz de date i nu avei nici un backup de log
sau diferenial, specificai opiunea RECOVERY .

Dac exist cel puin un backup de log sau diferenial, specificai opiunea NORECOVERY
pentru a amna procesul de recuperare pn ce este restaurat ultimul
backup.
Exemplu:
Acest exemplu presupune c exist un backup full pe fiierul permanent NwindBac i c dou
backup-uri sunt adugate la acest fiier. Baza de date Northwind este complet nlocuit cu
backup-ul al doilea din dispozitiv de backup NwindBac. La final, procesul de recuperare
aduce baza de date ntr-o stare consistent (reia tranzaciile comise i le anulez pe cele
necomise).
USE master
RESTORE DATABASE Northwind
FROM NwindBac
WITH FILE = 2, RECOVERY
B. Restaurarea dintr-un backup de baz de date diferenial
Cnd restaurai o baz de date dintr-un backup diferenial SQL Server:

Restaurai backup-ul full nainte de a restaura un backup diferenial.

Sintaxa pentru a restaura un backup diferenial este aceeai ca pentru a restaura un backup full
de baz de date. Mai degrab dect specificarea de backup full n clauza FROM, specificai
fiierul backup care conine backup-ul diferenial.

Specificai opiunea NORECOVERY atunci cnd exist loguri tranzacionale care trebuie
restaurate; n caz contrar, specificai opiunea RECOVERY.
Exemplu:
Urmtorul exemplu restaureaz un backup diferenial fr recuperarea bazei de date. Fiierul
NwindBacDiff conine un backup diferenial. SQL Server v permite s restaurai logurile
tranzacionale nainte de a aduce baza de date Northwind la o stare consistent prin
specificarea opiunii NORECOVERY.
USE master
RESTORE DATABASE Northwind
FROM NwindBacDiff
WITH NORECOVERY
98

C. Restaurarea dintr-un backup de log
Cnd restaurai un backup de log, SQL Server restabilete modificrile bazei de date
nregistrate n jurnalul de tranzacii.
De obicei, vei restaura logurile tranzacionale n scopul de a aplica modificrile care sunt
facute n baza de date de la ultimul backup full sau diferenial. Mai mult, avei posibilitatea s
restaurai jurnalul de tranzacii n scopul de a aduce o baza de date pn la un anumit moment
n timp. Dei restaurarea unui backup diferenial poate accelera procesul de restaurare, pentru
a asigura consistena datelor poate fi necesar s restaurai backup-uri de log suplimentare care
au fost create dup un backup diferenial.
nainte s restaurai logurile tranzacionale, trebuie mai nti s restaurai backup-ul full al
bazei de date. Cnd avei mai multe loguri tranzacionale de aplicat, specificai opiunea
NORECOVERY pentru toate logurile tranzacionale, cu excepia ultimului. SQL Server
suspend procesul de recuperare pn cnd ultimul log tranzacional este restaurat.
Sintaxa:
RESTORE LOG {database_name | @database_name_var}
[FROM <backup_device> [, n]]
[WITH
[{NORECOVERY | RECOVERY | STANDBY = undo_file_name}]
[[,] STOPAT = {date_time | @date_time_var}]
[[,] STOPBEFOREMARK = mark_name [AFTER date_time]
[[,] STOPATMARK = mark_name [AFTER date_time]
Dac planificai o operaie de mare risc, este posibil s dorii s adugai un semn de jurnal,
astfel nct baza de date s se poat restaura nainte de nceperea acelei operaii. Pentru a face
restaurarea la o marc de jurnal specificat:

Utilizai clauza WITH STOPATMARK = 'mark_name' pentru a relua toate tranzaciile pn

la inclusiv tranzacia care conine marca.

Utilizai clauza WITH STOPBEFOREMARK='mark_name' pentru a relua toate tranzaciile

pn la tranzacia care conine marca, mai puin aceasta.
Exemplul 1:
Acest exemplu presupune c exist un backup full al bazei de date Northwind pe un fiier
backup i nc dou backup-uri de log pe un alt fiier de backup. Trei restaurri separate sunt
efectuate pentru a asigura consistena bazei de date.
a. Primul pas restaureaz baz de date dintr-un backup full, fr recuperarea
bazei de date.
USE master
RESTORE DATABASE Northwind
FROM NwindBac
WITH NORECOVERY
b. Al doilea pas restaureaz primul log tranzacional, fr recuperarea bazei de date. Progresul
procesului de restaurare este afiat.
USE master
RESTORE LOG Northwind
FROM NwindBacLog
WITH FILE = 1,
STATS,
NORECOVERY
c. Al treilea pas restaureaz al doilea log tranzacional, reia tranzaciile comise i le anuleaz pe
cele necomise. Opiunea RECOVERY aduce baza de date Northwind ntr-o stare consistent.
USE master
ESTORE LOG Northwind
99

FROM NwindBacLog
WITH FILE = 2,
RECOVERY
Exemplul 2:
Acest exemplu presupune c exist un backup full al bazei de date Northwind i dou
backup-uri de log ntr-un singur fiier de backup. Cu toate acestea, doar modificrile care au
avut loc nainte de ora 01:00 A.M. pe 03 ianuarie 2000 sunt restaurate. Trei operaii de
restaurare separate sunt efectuate pentru a restabili consistena bazei de date.
a. Primul pas restaureaz baza de date dintr-un backup full, fr recuperarea bazei de date
USE master
RESTORE DATABASE Northwind
FROM NwindBac
WITH NORECOVERY
b. Al doilea pas restaureaz un jurnal de tranzacii, fr recuperarea bazei de date.
USE master
RESTORE LOG Northwind
FROM NwindBacLog
WITH FILE = 1,
NORECOVERY
c. Al treilea pas restabilete al doilea jurnal de tranzacii, se aplic modificrile care
au avut loc nainte de 01:00 A.M., pe 03 ianuarie 2000, i se recupereaz baza de date.
USE master
RESTORE LOG Northwind
FROM NwindBacLog
WITH FILE = 2,
RECOVERY,
STOPAT = 'January 3, 2000 1:00 AM'
D. Restaurarea dintr-un backup de fiier sau grup de fiiere
SQL Server v permite s restaurai o baz de date dintr-un backup de baz de date
complet sau un backup de fiier individual. Dac avei backup-uri de fiier sau grupuri de
fiiere, le putei restaura pentru:

Reducerea timpului care este necesar pentru a restaura o baz de date foarte mare (VLDB-
Very Large DataBase).

Recuperarea de date atunci cnd un anumit fiier a fost ters din greeal sau deteriorat.
Atunci cnd restaurai baza de date dintr-un fiier sau grup de fiiere, trebuie s:

Aplicai toate jurnalele de tranzacii care au fost create de cnd s-a fcut un backup de fiier,
pentru a aduce fiierul sau grupul de fiiere restaurat ntr-o stare care este consistent cu restul
bazei de date.

Restaurai backup-urile de grup de fiiere ca o unitate, n cazul n care un tabel i indecii

asociai acesteia exist n dou grupuri de fiiere diferite.
Sintaxa:
RESTORE DATABASE {database_name | @database_name_var}
<file_or_filegroup> [, ...m]
[FROM <backup_device> [, n]]
Where <file_or_filegroup> is
{FILE = logical_file_name | FILEGROUP = logical_filegroup_name}




100

Exemplu:
Acest exemplu presupune c exist o baz de date numit Northwind pe trei fiiere: Nwind1,
Nwind2 i Nwind3. Fiierul Nwind2 conine un singur tabel i indecii corespunztori.
Fiierul Nwind2 a fost salvat n fiierul de backup Nwind2bac. Un backup de log a fost
efectuat, de cnd Nwind2 a fost ultima dat salvat. Nwind2 trebuie s fie restaurat, deoarece
mediul de stocare este deteriorat fizic. Se impun dou etape pentru a asigura consistena bazei
de date.
a. Primul pas restaureaz backup-ul fiierului bazei de date Nwind2, fr a relua tranzaciile
comise sau de a le anula pe cele necomise.
USE master
RESTORE DATABASE Northwind
FILE = Nwind2
FROM Nwind2Bac
WITH NORECOVERY
b. Al doilea pas restaureaz backup-ul de log tranzacional, reia tranzaciile comise i le
anuleaz pe cele necomise.
USE master
RESTORE LOG Northwind
FROM NwindBacLog
WITH RECOVERY






























101

BIBLIOGRAFIE

1. Ion Lungu, Constana Bodea, Georgeta Bdescu, Crsitian Ioni, Baze de date-
Organizare, proiectare i implementare, Ed. ALL Educational, Bucureti, 1995.
2. Mihai Popescu, Baze de date relaionale, Editura Academiei Tehnice Militare,
Bucureti, 2001.
3. tefan Ardeleanu, Transact SQL, Ed. Niculescu.
4. Magnolia Tilca, Radu Boriga, Baze de date, Ed. Univ. Titu Maiorescu, 2007.
5. Robert Dellinger, Baze de date i gestionarea tranzaciilor, Ed. Albastr, Cluj-
Napoca, 2000.
6. *** Documentaie Microsoft SQL Server (format electronic).
7. Teme de cas date studenilor din facultatea de informatic, UTM.