SQL Server 2000SQL Server 2000 StandardInstante diferite (sau mai multe servere intr-unul singur)Sa consideram urmatorul scenariu: avem SQL Server instalat pe un server si care ruleaza o baza de date de contabilitate. Dorim sa creem o copie a acestui server, pentru niste teste de optimizare a performantelor, dar nu dispunem de banii necesari achizitionarii unui server nou. Pe serverul curent, spatiul de pe hardisk nu este o problema, este un server cu 4 procesoare si memorie avem destula (comparativ cu specificatiile producatorului).

Ce putem face este sa mai instalam o data SQL Server, ca o noua instanta (sau named instance). In acest fel, vom putea experimenta diferite setari la nivel de server (alocare de memorie, etc) fara a afecta functionarea celeilalte instante. Acest mod de lucru este posibil datorita faptului ca fiecare instanta ruleaza intr-un spatiu propriu de memorie si resurse hardware, fara sa afecteze celelalte instante daca se modifica setarile uneia din ele. Este ca si cum am avea inca un server fizic disponibil pe care sa rulam inca un SQL Server. Identificarea unui server SQL in retea, in scopul conectarii la acesta se face dupa numele NetBIOS asociat acestuia. In cazul in care avem mai multe instante SQL instalate pe acel server, identificarea acestora se va face dupa sablonul numeserver\numeinstanta. De exemplu, avem serverul cu numele SQLDBSRV01 si avem 2 instante SQL instalate pe acesta. Prima instanta, cea default, va fi identificata dupa numele NetBIOS al serverului, adica SQLDBSRV01. Instanta 2 cu numele CONTAB_DB, va fi putea fi accesata folosind identificatorul SQLDBSRV01\CONTAB_DB.

SQL Server ruleaza ca serviciu in cadrul sistemului de operare. In cazul in care avem mai multe instante, fiecare instanta va crea propriul serviciu in cadrul sistemului de operare. Identificarea acestora se face similar cu identificarea instantelor, cu urmatoarea diferenta: numele serviciilor pentru instantele din exemplul de mai sus sint astfel MSSQLServer si SQLServerAgent pentru instanta default si MSSQL$CONTAB_DB si SQLAgent$CONTAB_DB pentru instanta CONTAB_DB.

Descrierea componentelor

SQL Enterprise Manager (sau EM in unele documentatii) permite inregistrarea serverelor SQL intr-o lista de administrare disponibila unui administrator. Inscrierea serverelor in aceasta lista presupune ca userul respectiv are permisiuni pe acel server. SQL Query Analyzer (sau QA) permite interogarea bazelor de date existente pe un server SQL folosind limbajul Transact-SQL (sau T-SQL).

SQL Books Online este documentatia SQL in format electronic. Contine 90% din informatiile necesare unui administrator sa-si faca munca in conditii optime.

Client Network Utility permite conifgurarea protocoalelor de retea pe care sa le utilizeze SQL Server pentru a permite conectarea clientilor la bazele de date gestionate de acesta.

Utilitarele linie de comanda (osql) permit interogarea bazelor de date din linia de comanda, folosind parametri pentru a specifica interogarea, numele serverului, numele bazei de date, etc. Mai multe detalii despre utilitarele linie de comanda se gasesc in SQL Books online.

Conceptul de baze de date relationaleConceptul de baze de date relationale este indeobste cunoscut. Tot mai des putem auzi sintagme de genul Nu va gasesc in baza de date, Nu avem produsul asta in baza de date. As dori sa fac o clarificare importanta, dupa parerea mea, pentru ca acest termen, de baza de date, este destul de larg. Bazele de date, conform definitiei largi, sint o colectie de date, inregistrari, care pot fi parcuse secvential sau dupa un alt algoritm si care permit stocarea, regasirea si procesarea datelor conform unor nevoie specifice. Bazele de date relationale difera putin de aceasta definitie, prin extinderea acesteia si anume prin introducerea termenului de relational. De exemplu, in Excel exista conceptul de database pe o foaie de calcul. Dar nu este neaparat relationala, sau nu este relationala 100%. SQL si alte motoare de baze de date folosesc relationarea pentru optimizarea bazelor de date.

Sa luam un exemplu. Avem 100 de CD-uri si am vrea sa le ordonam cumva, intr-o baza de date. Asociat unui CD, avem o serie de atribute: casa de discuri, an aparitie, gen muzical, artist, etc. Aceasta baza de date o putem dezvolta si implementa foarte simplu si rapid si in Excel, cu toate detaliile. Ce se intimpla insa, cind casa de discuri este scrisa gresit la 25 de CD-uri ? Sau genul muzical ? Trebuie parcurse toate inregistrarile si corectate manual. Insa, folosind relatiile, in loc sa stocam textul explicit al, sa luam un exemplu, numelui casei de discuri, stocam un cod al acestei case de discuri in tabela de CD-uri, iar in baza codului, regasim numele acesteia, dintr-o tabela relationata prin intermediul codului. Folosind aceasta abordare, schimbam doar numele casei de discuri in acea tabela cu casele de discuri, iar interogarea noastra va afisa numele corect la toate inregistrarile, cu o singura modificare. In imaginea de mai jos este afisat, schematic, exemplul de mai sus:

Diagrama 1 Tabela cu CD-urile (structura partiala) Fara relatii, cu atributele in text clar

Diagrama 2 Tabela cu CD-urile (structura partiala) Cu relatii spre tabele auxiliare, de unde se preiau textele asociate atributelor unui CD

Din diagrama 2 se poate vedea destul de usor faptul ca daca dorim sa schimbam ceva in denumirile unor genuri muzicale sau ale unor case de discuri, sau sa adaugam niste atribute asociate acestor 2 tabele este mult mai usor decit in prima varianta. Aceasta abordare are si unele dezavantaje (orice moneda are 2 fete), dar aceste dezavantaje sint umbrite, ca sa zicem asa, de usurinta in administrare. Acest proces de separare a datelor se numeste normalizare. Nu vom intra in detalii care tin de acest proces, pentru ca nu face obiectul acestui tutorial, dar se gasesc destule articole pe net care explica in detaliu si pe intelesul tuturor ce presupune normalizarea bazelor de date si avantajele pe care aceasta le aduce.

Obiectele unei baze de dateIntr-o baza de date, datele sint stocate in tabele. Pe linga aceste tabele, intr-o baza de date SQL mai gasim si alte obiecte, cum ar fi: views (sau vederi), users (userii care au acces la baza de date respectiva), stored procedures (sau proceduri stocate bucati de cod sau instructiuni Transact-SQL proiectate sa execute anumite operatii bine determinate), etc. Obiectele unei baze de date :

Diagrams contine diagramele care reprezinta schematic legaturile dintre tabelele bazei de date

Tables contine tabelele care, la rindul lor, contin datele utile ale bazei de date

Views contine definitia vederilor (sau a interogarilor salvate) folosite de aplicatie pentru a interoga baza de date

Stored Procedures contine definitiile procedurilor stocate folosite pentru a efectua anumite operatii predefinite asupra datelor si / sau a tabelelor din baza de date

Users contine utilizatorii care au permisiuni (pe diferite nivele) in cadrul bazei de date curente

Roles contine grupurile de utilizatori pre-definiti in cadrul SQL Server si in cadrul bazei de date. Aceste grupuri contin permisiuni predefinite care se pot aplica userilor pentru accesul la date

Rules contine regulile de validare a datelor de la nivelul bazei de date. Regulile de validare a datelor se pot implementa pe 2 nivele (cel putin), si in cazul nostru mai specific, la nivelul tabelelor (la nivel declarativ al tabelelor) si la nivelul interfetei utilizator (asa numita validare pe client). Avantajele folosirii validarii la nivelul bazei de date sint in principal la capitolul performanta (clientul nu mai trebuie sa faca validarile, deci va rula mai rapid, validarile pe server merg mai rapid datorita resurselor hardware mai mari, etc).

Defaults contine definitiile valorilor implicite definite de utilizator pentru baza de date. Aceste defaults sint folosite la definirea tabelelor la specificarea valorilor implicite care sa fie introduse in tabele cind utilizatorul, prin interfata oferita, nu furnizeaza toate datele pentru a actualiza tabelele. Vom vedea in cadrul exercitiului practic utilitatea acestor defaults.

User Defined Datatypes am discutat putin mai sus despre tipurile de date. Aici se pot defini tipuri de date conform cerintelor sau specificului aplicatiei sau a bazei de date.

User Defined Functions contine definitiile functiilor definite de dezvoltator / implementator si care functii fac diferite operatii asupra datelor sau a altor obiecte ale bazei de date

Full-Text Catalogs contine cataloagele full-text existente in cadrul bazei de date. Aceste cataloage contin referinte sistem cu privire la indecsii full-text. Un exemplu de indecsi full-text si o baza de date care foloseste acest tip de indecsi ar fi o baza de date cu CV-uri, cind se doreste cautarea in cadrul acestor CV-uri dupa cuvinte cheie.

Din pacate, nu avem mai mult spatiu la dispozitie pentru a detalia aceste obiect, dar pentru cei interesati, SQL Server Books Online contine detalii despre aceste tipuri de obiecte.

Noi vom merge mai departe cu exercitiul practic si vom trece la definirea tabelelor bazei de date, folosind SQL Server Enterprise Manager.Natura datelorDupa cum se observa din descrierea cerintelor de mai sus, majoritatea datelor folosite sint de tip data calendaristica sau de tip caracter. Natura datelor afecteaza si tipul de data pe care urmeaza sa-l folosim in SQL Server. Foarte pe scurt, SQL Server permite ca pentru acelasi cimp sa avem mai multe optiuni dintre care sa alegem. Astfel, pentru un cimp numeric, in functie de valorile pe care le determinam ca vor fi stocate in acel cimp, putem opta intre mai multe feluri de date numerice: tinyint, smallint, int, bigint, numeric si real (cu zecimale si nivele de precizie), bit, etc. Mai multe detalii despre data types se gasesc in SQL Server Books Online, cu cautare pe keyword-ul data types si selectind in lista de optiuni sectiunea Overview.

Ca si concluzie, intelegerea naturii datelor vehiculate si determinarea plajei de valori pe care urmeaza sa o stocam intr-un cimp anume este critica pentru faza de design a bazei de date si ne poate aduce un plus de performanta si o economie de spatiu necesar pe disc. O data facut designul unei baze de date cu privire la acest aspect, prea multe modificari nu se mai pot face, fara a afecta negativ partea de dezvoltare a aplicatiei care urmeaza sa foloseasca baza de date.

Aceste tipuri de date reprezinta o caracteristica importanta, in ceea ce priveste spatiul necesar, si anume faptul ca valorile care pot fi stocate in aceste cimpuri pot avea lungimi variabile, aspect deloc de neglijat in cazul cimpurilor care vor stoca date de tip sir de caractere (dar si in cazul cimpurilor cu date de tip intreg, in acest caz insa cistigul de spatiu este mai putin evident). Aceasta facilitate ne permite sa economisim spatiu fizic pe disc, in cazul in care acest aspect este o constringere. Ca si best-practice, este bine de stiut acest aspect si indusa obisnuinta folosirii cimpurilor cu lungime variabila. Poate parea un amanunt, dar cind vorbim de baze de date mari, acest amanunt devine important.

Dupa cum se poate vedea din tabelul de mai sus, prin simpla folosire a unui tip de data sau a altuia se pot realiza economii importante de spatiu. Aceasta economie este obtinuta in mod nativ, datorita modului in care SQL Server trateaza aceste tipuri de date. In exemplul nostru, daca in baza de date avem de stocat 3 bytes, SQL Server va aloca exact spatiul de care e nevoie (3 bytes) in loc sa aloce 50 bytes. Acest tip de data este identificat in SQL Server sub numele de varchar (variable character). Mai multe detalii despre tipurile de date veti gasi studiind SQL Books online, cautind keyword-ul data types.

Aceasta economie se traduce in final prin performante imbunatatite, cerinte de administrare mai scazute, cerinte hardware mai reduse. Din aceasta cauza, alegerea unui tip de data sau a altuia, poate avea un impact major pe termen lung, desi la o prima vedere, acest aspect poate parea un amanunt.

Sa continuam si sa discutam putin despre tabelele care vor compune baza noastra de date.

Vom avea nevoie de o tabela care sa contina numele caselor de discuri sau, in cazul DVD-urilor, a caselor de productie filme, cu structura urmatoare:Cod casa de discuri, numeric, identityDenumire casa de discuri, varchar(50)

Vom mai avea nevoie de o tabela care sa contina diferitele standarde de discuri (mp3, audio, etc), cu urmatoarea structura:Cod standard, numeric, identityDenumire standard, varchar(50)

Vom mai avea nevoie de o tabela care sa contina diferitele genuri muzicale sau de filme (hip-hop, R&B, drama, etc), cu urmatoarea structura:Cod gen muzical, numeric, identityDenumire gen muzical, varchar(50)

Vom mai avea nevoie de o tabela care sa contina un fel de agenda cu datele de contact ale persoanelor care ne-au imprumutat discuri sau carora le-am imprumutat noi discuri. Aceasta tabela va trebui sa ne ofere, ca un minim, urmatoarele detalii: numele persoanei, adresa completa, numar de telefon si adresa de email. Pentru acesta, propun urmatoarea structura:Cod persoana, numeric, identityNume persoana, varchar(50)Adresa, varchar(100)Numar de telefon, varchar(20)Adresa email, varchar(30)

Cele de mai sus, sint doar tabelele auxiliare care vor fi folosite de catre aplicatie. Tabela urmatoare contine datele de baza ale aplicatiei, si anume colectia de discuri. In aceasta tabela, vom memora, in loc de denumirea in clar a genurilor muzicale sau a numelor caselor de discuri sau de filme, codul asociat acestora, pentru a permite modificarea facila a acestor detalii in tabelele care contin aceste detalii, fara sa afectam tabela de discuri.Structura pe care v-o propun pentru aceasta tabela este descrisa in imaginea de mai jos:

Toate tabelele definite pina acuma, le-am definit cu ajutorul Microsoft Visio 2003 for Enterprise Architects. Acest proces poarta numele de modelare si are unele avantaje deloc de neglijat. Cel mai important este faptul ca permite modificarea structurii bazei de date pina cind se ajunge la un model stabil, functional, care sa acopere toate nevoile aplicatiei si a clientului. Toate acestea fara sa lucram inca cu SQL Server sau sa scriem o singura linie de cod in Transact-SQL sau MS-Access. Microsoft Visio 2003 for Enterprise Architects (disponibil in pachetul Microsoft Visual Studio 2003 Enterprise Architect) ofera aceasta facilitate si in plus, cind totul este gata, prin conectori ODBC se poate conecta la serverul SQL dorit si sa creeze baza de date conform modelului construit de noi.

Pentru a definitiva modelul bazei de date, vom trece la modelarea relatiilor dintre tabele. Voi lasa schema sa vorbeasca de la sine si vom vedea in lectiile urmatoare cum ne vom folosi de aceste relatii.

Creerea tabelelor folosind Enterprise ManagerPentru creerea tabelelor, vom incepe prin a creea baza de date. Modul in care SQL Server gestioneaza bazele de date nu face obiectul acestui tutorial, dar foarte pe scurt, lucrurile se intimpla in felul urmator. Fiecare baza de date are 2 componente: fisierele cu date (sau data files) si log-ul operatiilor (sau transaction log). Data files contin tabelele si toate celelalte obiecte dintr-o baza de date. Transaction log-ul contine un istoric al modificarilor efectuate asupra datelor. Dimensiunea acestui istoric variaza la fiecare baza de date, in functie de nevoile specifice ale acestei baze de date.

Ca si functionare, orice modificare se doreste a fi operata asupra datelor, se inregistreaza intii in transaction log (care este o scriere fizica pe disc) si abia apoi trimisa spre executie. SQL Server lucreaza la nivel de tranzactii. Adica o modificare asupra datelor se considera un bloc unitar, care se executa integral cu succes sau nu se executa deloc (un exemplu ar fi un update asupra unor inregistrari urmat de un insert de inregistrari noi, insert care este conditionat de primul update ori se executa ambele instructiuni cu succes ori deloc). Este treaba aplicatiei sa detecteze erorile tranzactionale si sa trateze aceste erori. Acesta este, foarte schematic, modul in care lucreaza SQL Server.

Fiecare din cele 2 componente (data files si transaction log) sint formate din 1 sau mai multe fisiere pe disc. Data files au extensia MDF iar transaction log-ul are extensia LDF.

In cele ce urmeaza, vom creea o baza de date in care vom trece la creerea tabelelor necesare aplicatiei noastre.

Se lanseaza Enterprise Manager, se expandeaza in lista serverul curent si se da click dreapta pe Databases, click pe New Database.