Baze de Date - Access - Curs mocian ioan

Ioan Mocian

Baze de date - pentru uzul studenţilor -

- 2008 -

Tehnoredactare computerizată: Ioan Mocian Tiparul executat la Atelierul de multiplicare al Universităţii Petru Maior Copyright © Ioan Mocian

Cuvânt înainte O carte despre bazele de date nu e uşor de scris, cel puţin din două motive: sunt foarte multe astfel de cărţi şi sunt foarte mulţi cunoscători ai domeniului. Pe de altă parte sunt şi multe persoane care ar dori să se iniţieze în domeniu, dar cărţile pe care le-au deschis i-au descurajat, datorită nivelului ridicat de prezentare. Acestora li se adresează această carte, oameni cu pregătire academică într-un domeniu conex, dar care au nevoie de cunoştinţe pentru a înţelege bazele de date, fie pentru cultura generală, fie pentru necesităţi profesionale. Pentru a înţelege şi utiliza bazele de date nu trebuie să fii informatician, trebuie să ai dorinţa de a studia şi să ai o carte bună, orientată spre scopul imediat şi uşurată de balastul greoi al explicaţiilor teoretice de strictă specialitate, care oricum nu vor fi înţelese de un începător şi nu le va folosi niciodată. În acest spirit a fost scrisă această carte, pentru oameni care doresc să aplice imediat cunoştinţele dobândite. Cartea e structurată pe 5 capitole într-o cronologie logică, de la explicarea noţiunilor şi conceptelor până la conceperea de aplicaţii în ACCESS. Capitolul 1 este axat pe prezentarea domeniului bazelor de date relaţionale unde se folosesc şi la ce sunt folosite acestea. Capitolul 2 se ocupă cu prezentarea termenilor şi conceptelor folosite în bazele de dare relaţionale, pentru ca acestea să fie corect înţelese şi folosite. Capitolul 3 este consacrat iniţierii în proiectarea bazelor de date relaţionale, având în vedere că mulţi specialişti şi manageri sunt implicaţi în proiectarea de baze de date şi sisteme informatice fără să aibă un minim de pregătire în domeniu. Se pleacă de la constatarea că proiectarea bazelor de date nu are legătură cu implementarea lor (pe care o fac specialiştii în informatică), iar cei care dau, în ultimă instanţă, specificaţiile sunt chiar utilizatorii finali. De fapt, sunt aceia care formulează cerinţele şi obiectivele bazei de date, prin intermediul caietului de sarcini. Capitolul 4 este dedicat iniţierii în limbajul SQL, un limbaj apropiat de limbajul uman şi uşor de înţeles. Practica mi-a demonstrat că limbajul SQL este repede asimilat şi folosit pentru interogarea bazelor de date de către începători. Exemplele prezentate aici sunt foarte sugestive, bine alese şi pot fi folosite ca modele pentru situaţii concrete. Capitolul 5 este dedicat iniţierii în sistemul de gestiune a bazelor de date ACCESS, folosind cunoştinţele dobândite în capitolele anterioare. Aici se învaţă crearea tabelelor, formularelor, interogărilor şi rapoartelor.

3

Exemplele prezentate sunt inspirate din situaţii concrete, reale, care sunt bune modele pentru propriile aplicaţii. Expresiile SQL vor fi acum testate „pe viu” putându-se verifica imediat corectitudinea lor şi rezultatele obţinute. Tot aici sunt prezentate modalităţile de transpunere a rapoartelor în format HTML pentru a fi publicate pe Internet. Lucrarea se adresează studenţilor facultăţilor de inginerie, dar este utilă şi persoanelor care au învăţat bazele de date „din mers” şi doresc să-şi verifice şi săşi sistematizeze cunoştinţele. După ce aţi parcurs acest curs, trebuie să dobândiţi capacitatea:

 de a proiecta baze de date simple la început, a căror complexitate să crească odată cu experienţa acumulată;  de a implementa aplicaţii de baze de date în ACCESS, la nivelul firmelor mici şi instituţiilor;  de a avea o bază de plecare pentru un viitor job într-o echipă profesionistă de dezvoltare a aplicaţiilor de baze de date. Dacă această carte a reuşit să vă îmbogăţească bagajul de cunoştinţe generale, dacă aţi reuşit să înţelegeţi ce este o bază de date şi la ce este bună, dacă aţi reuşit să creaţi o bază de date ACCESS şi să o folosiţi întrun scop util, dacă aţi reuşit să publicaţi pe Internet cel puţin un raport din baza de date pe care aţi creat-o sau din alta, înseamnă că efortul depus pentru scrierea ei nu a fost zadarnic.

Tg. Mureş, 2008 Autorul

4

Cuprins Cuvânt înainte ............................................................................................... 3 Capitolul 1. Noţiuni de bază despre bazele de date ................................... 11 Modelul de bază de date relaţională .......................................................... 12 Regăsirea datelor ....................................................................................... 13 Sisteme de gestiune a bazelor de date relaţionale ..................................... 14 Dincolo de modelul relaţional ................................................................... 15 Întrebări pentru autoevaluare .................................................................... 16 Capitolul 2. Terminologia bazelor de date relaţionale ............................. 17 Importanţa terminologiei .......................................................................... 17 Termeni referitori la valoare ..................................................................... 18 Date şi informaţii ................................................................................. 18 Valoare nulă ......................................................................................... 19 Termeni referitori la structură ................................................................... 20 Tabel .................................................................................................... 20 Câmp .................................................................................................... 22 Înregistrare ........................................................................................... 23 Vedere .................................................................................................. 24 Chei ...................................................................................................... 26 Index .................................................................................................... 28 Termeni referitori la relaţie ....................................................................... 29 Relaţii ................................................................................................... 29 Relaţii unu cu unu ................................................................................ 30 Relaţii unu cu mai mulţi ....................................................................... 31 Relaţii mai mulţi cu mai mulţi ............................................................. 32 Tipuri de participare ............................................................................. 34 Gradul de participare ............................................................................ 35 Termeni referitori la integritate ................................................................. 36 Specificaţie de câmp ............................................................................ 36 Integritatea datelor ............................................................................... 36 Întrebări pentru autoevaluare .................................................................... 37 Capitolul 3. Proiectarea bazelor de date relaţionale ................................. 39

5

Etapa 1 – Definirea unei declaraţii de intenţie şi a obiectivelor misiunii .. 40 Compunerea unei declaraţii de intenţie ................................................ 41 Definirea obiectivelor misiunii ............................................................. 42 Întrebări pentru autoevaluare ................................................................ 43 Etapa 2 - Analiza bazei de date curente .................................................... 44 Întrebări pentru autoevaluare ................................................................ 46 Etapa 3 - Crearea structurilor de date ........................................................ 46 Definirea listei finale de tabele ............................................................. 47 Asocierea câmpurilor fiecărui tabel ...................................................... 50 Utilizarea unui câmp ideal pentru rezolvarea anomaliilor .................... 52 Stabilirea cheilor pentru fiecare tabel ................................................... 53 Întrebări pentru autoevaluare ................................................................ 56 Revizuirea structurilor iniţiale de tabel ................................................ 57 Specificaţii de câmp ............................................................................. 58 Anatomia unei specificaţii de câmp .................................................. 60 Întrebări pentru autoevaluare ............................................................... 66 Etapa 4 - Determinarea şi instituirea relaţiilor între tabele ...................... 67 Diagrama relaţiilor unu cu unu ............................................................ 67 Diagrama relaţiilor unu cu mai mulţi ................................................... 70 Diagrama relaţiilor mai mulţi cu mai mulţi ......................................... 73 Relaţii cu autoreferire .......................................................................... 77 Identificarea relaţiilor existente ........................................................... 80 Stabilirea caracteristicilor relaţiilor ..................................................... 87 Definirea unei reguli de ştergere ....................................................... 87 Identificarea tipului de participare a fiecărui tabel ........................... 88 Identificarea gradului de participare a fiecărui tabel ........................ 90 Integritatea la nivel de relaţie .............................................................. 92 Etapa 5 - Determinarea şi definirea regulilor de desfăşurare a activităţii

93

Reguli specifice câmpurilor ................................................................. 93 Reguli specifice relaţiilor ..................................................................... 96 Tabele de validare ................................................................................ 97 Etapa 6 - Determinarea şi definirea vederilor .......................................... 98 Etapa 7 - Revizuirea integrităţii datelor ................................................... 102 Revizuirea şi îmbunătăţirea integrităţii datelor ................................... 103

6

Alcătuirea documentaţiei bazei de date ............................................... 105 Studiu de caz. Proiectarea unei baze de date ............................................ 106 Declaraţia de intenţie ........................................................................... 106 Obiectivele misiunii ............................................................................. 106 Analiza bazei de date curente .............................................................. 106 Crearea structurilor de date ................................................................. 107 Determinarea şi instituirea relaţiilor între tabele ................................. 110 Determinarea şi definirea regulilor de desfăşurare a activităţii ........... 111 Determinarea şi definirea vederilor ..................................................... 115 Verificarea integrităţii datelor ............................................................. 118 Concluzii privind proiectarea bazelor de date relaţionale ................... 118 Capitolul 4. Iniţiere în limbajul SQL ......................................................... 120 Prezentare generală ................................................................................... 120 Operaţiuni simple folosind limbajul SQL ................................................. 122 Regăsirea datelor ............................................................................... 122 Sortarea datelor ................................................................................. 123 Filtrarea datelor ................................................................................. 124 Operatorii clauzei WHERE .................................................. 125 Filtrare avansată ................................................................... 126 Operaţiuni avansate folosind limbajul SQL .............................................. 132 Câmpuri calculate ............................................................................. 132 Funcţii pentru manipularea datelor ................................................... 134 Gruparea datelor ............................................................................... 137 Crearea grupurilor ................................................................ 137 Filtrarea grupurilor ............................................................... 139 Lucrul cu subselecţii ......................................................................... 141 Unirea tabelelor ................................................................................ 147 Crearea unei uniri simple ..................................................... 147 Uniri avansate ...................................................................... 138 Compunerea interogărilor ................................................................. 151 Inserarea, actualizarea şi ştergerea datelor ........................................ 155 Inserarea datelor ................................................................... 155 Actualizarea datelor ............................................................. 157 Ştergerea datelor .................................................................. 159

7

Principii privind actualizarea şi ştergerea datelor ................ 160 Crearea şi manipularea tabelelor ....................................................... 162 Elemente performante ale limbajului SQL ................................................ 164 Concluzii ........................................................................................... 167 Capitolul 5. Utilizarea programului ACCESS .......................................... 168 Prezentare generală ................................................................................... 168 Interfaţa programului Access ..................................................................... 170 Crearea tabelelor ....................................................................................... 172 Relaţii între tabele ............................................................................. 174 Crearea relaţiilor cu Lookup Wizard ................................................ 177 Introducerea datelor în tabele ........................................................... 179 Formulare .................................................................................................. 181 Crearea unui formular ....................................................................... 181 Crearea automată a unui formular ......................................... 182 Crearea manuală a unui formular ......................................... 185 Formulare cu subformulare ............................................................... 189 Interogări ................................................................................................... 195 Crearea interogărilor folosind limbajul SQL .................................... 195 Crearea interogărilor cu aplicaţia Wizard(Design view) .................. 196 Legarea permanentă a două tabele .................................................... 200 Interogări cu parametri ...................................................................... 203 Rapoarte .................................................................................................... 206 Crearea unui raport simplu ................................................................ 206 Crearea unui raport cu Report Wizard .............................................. 208 Particularizarea unui raport ............................................................... 214 Macro-uri ................................................................................................... 217 Crearea macrocomenzilor cu o singură acţiune ................................. 218 Crearea macrocomenzilor cu mai multe acţiuni ................................ 220 Rularea macrocomenzilor .................................................................. 221 Rularea unei macrocomenzi din fereastra Database ............ 222 Rularea unei macrocomenzi dintr-un grup ........................... 222 Utilizarea acţiunii RunMacro ............................................... 222 Macrocomenzi ataşate evenimentelor .................................. 223 Utilizarea macrocomenzilor AutoExec şi AutoKeys ........... 223

8

Metodă rapidă de pornire a aplicaţiilor ............................... 224 Publicarea datelor pe Internet ................................................................... 225 Pagini Web statice ............................................................................ 226 Pagini Web dinamice ........................................................................ 228 Crearea unei pagini dinamice de date cu AutoPage .......... 228 Crearea paginilor dinamice cu Page Wizard ....................... 229 Comunicarea între aplicaţiile pachetului Office ....................................... 231 Exportul şi importul de date ............................................................. 232 Recomandări privind crearea aplicaţiilor Access ..................................... 232 Anexe ............................................................................................................. 235 Anexa A. Administratorul de bază de date .......................................... 235 Anexa B. Sintaxa instrucţiunilor SQL ................................................. 237 Bibliografie ..................................................................................................... 239

9

Pagină goală

10

Baze de date

Capitolul 1

Noţiuni de bază despre bazele de date Sintagma “bază de date” este folosită atât în viaţa de zi cu zi, în mijloacele de comunicare în masă, cât şi de specialiştii din domeniul tehnologiei informaţiei. E greu să ne gândim la un domeniu de activitate care să nu folosească, într-un fel sau altul, baze de date. Astfel, când scoatem bani de la bancomat, parola noastră este verificată cu o bază de date, medicul ne identifică dintr-o bază de date cu pacienţi, când ne prezentăm la vot suntem identificaţi dintr-o bază de date, iar exemplele pot continua. Există mai multe definiţii ale bazelor de date, dar cea mai simplă pentru această fază de studiu este: baza de date este un set de date stocate într-un mod organizat. Înţelegerea acestei definiţii va fi uşurată de un exemplu. Astfel, cărţile dintr-o bibliotecă nu sunt puse la întâmplare, ele sunt aşezate pe rafturi, după o anumită logică, împărţite pe domenii, pentru ca atunci vrem să ajungem la o carte, ea să poată fi localizată uşor. Prin urmare, este clar că atunci când căutăm o carte în biblioteca personală, o găsim mai uşor dacă este ordine şi o găsim greu sau deloc dacă ne ţinem cărţile în dezordine. Această idee o să fie aplicată în proiectarea bazelor de date, unde este foarte importantă organizarea corectă a informaţiilor. Termenul de bază de date este folosit de multe ori în mod eronat, confundându-se cu softul pentru bază de date care este utilizat. În realitate, softul pentru baze de date este numit sistem de gestiune a bazelor de date (SGBD), iar baza de date este recipientul care conţine informaţiile, recipient creat şi manipulat prin intermediul SGBD. Conţinutul acestui recipient se schimbă foarte des, atunci când se lucrează cu baza de date (adăugări, ştergeri şi modificări de informaţii). Baza de date este percepută de multe persoane ca fiind un simplu tabel. Acest lucru nu este greşit, atâta vreme cât la studiul limbajului Excel am descoperit tabele la care le spuneam şi baze de date. Într-adevăr, acele tabele erau baze de date foarte simple care aveau nişte comenzi şi funcţii cu care le putem sorta, filtra şi chiar făceam unele calcule cu ele. Cu aceste baze de date puteam rezolva multe probleme de gestionare a unor informaţii. Bazele de date clasice conţin mai multe tabele care sunt legate între ele prin relaţii care vor fi studiate mai târziu. Există mai multe modele de baze de date clasice: Model de bază de date ierarhică Model de bază de date reţea

11

Baze de date

Capitolul 1

Model de bază de date relaţională Primele două modele au numai valoare istorică, se mai folosesc foarte puţin sau deloc, aşa că nu ne vom opri asupra lor. Modelul relaţional este cel care se foloseşte astăzi datorită avantajelor pe care îl prezintă şi care va fi studiat în această carte.

Modelul de bază de date relaţională Baza de date relaţională a fost concepută în anul 1969 şi este azi cel mai folosit model de baze de date în gestiunea bazelor de date. Acest model este fundamentat pe două ramuri ale matematicii – teoria mulţimilor şi logica predicatelor de ordinul întâi. Într-adevăr, numele modelului provine de la termenul relaţie, care constituie o parte a teoriei mulţimilor. O concepţie greşită, larg răspândită, este aceea că modelul relaţional şi-ar fi preluat numele de la faptul că între tabelele unei baze de date relaţionale există relaţii. O bază de date relaţională stochează datele în relaţii, pe care un utilizator le percepe ca pe nişte tabele. Fiecare relaţie este compusă din înregistrări şi câmpuri, iar ordinea fizică a înregistrărilor sau a câmpurilor dintr-un tabel este complet lipsită de importanţă, iar fiecare înregistrare a tabelului este identificată, nu după locul unde se află, ci după un câmp care conţine o valoare unică. Prin urmare, utilizatorul nu este obligat să cunoască locaţia fizică a unei înregistrări aşa cum se întâmplă la celelalte modele de bază de date (ierarhic şi reţea), pentru regăsirea datelor. Modelul relaţional clasifică relaţiile ca fiind de tip: unu la unu, unu la mai mulţi şi mai mulţi la mai mulţi. Aceste relaţii vor fi studiate în detaliu mai târziu. O relaţie dintre două tabele este stabilită în mod implicit prin intermediul valorilor echivalente ale unui anumit câmp. În figura 1, tabelele tblStudenti şi tblSectii sunt corelate prin intermediul câmpului SectiaID; un anumit student este corelat cu o secţie prin intermediul unui identificator de secţie identic. Atâta timp cât utilizatorul cunoaşte relaţiile dintre tabelele incluse într-o bază de date, poate avea acces la date într-un mare număr de moduri. De exemplu, după cum se vede în figura 1.1, prin intermediul acelei relaţii, putem afla numele secţiei şi cărei facultăţi aparţine. Dacă tabelul ar conţine mai multe coloane, am avea acces la toate coloanele, aşa cum vom vedea mai târziu.

12

Baze de date

Capitolul 1 tblSectii SectiaID 1 2 3 4

Denumire TCM IEI Informatica Istorie

tblStudenti StudentID 1 2 3 4

Facultate Inginerie Inginerie Stiinte Stiinte

Nume Pop Ban Pop Lazar

Prenume Ioan Lucia Dorin Liviu

SectiaID 1 2 3 2

Telefon 234675 234375 234076 233777

Fig. 1.1. Exemplu de tabele corelate

Regăsirea datelor Datele stocate într-o bază de date trebuie regăsite rapid ori de câte ori este nevoie de ele. Datele dintr-o bază de date relaţională se regăsesc prin intermediul unui limbaj specializat de interogare numit SQL(Structured Query Language). SQL este limbajul standard folosit pentru crearea, modificarea, întreţinerea şi interogarea bazelor de date relaţionale. În figura 1.2 este prezentat un exemplu de interogare SQL pe care o putem utiliza pentru a obţine o listă cu studenţii de la IEI. SELECT Nume, Prenume, Telefon FROM tblStudenti WHERE SectiaID = ”2” ORDER BY Nume, Prenume Fig. 1.2. Exemplu de instrucţiune de interogare SQL

Această instrucţiune s-ar putea traduce astfel: extrage din tabelul tblStudenti câmpurile Nume, Prenume şi Telefon, înregistrările care au valoarea câmpului SectiaID egală cu 2, ceea ce corespunde secţiei IEI. Ordonează lista după câmpul Nume.

13

Baze de date

Capitolul 1

Cele trei componente fundamentale ale unei interogări SQL le reprezintă instrucţiunea SELECT…FROM, clauza WHERE şi clauza ORDER BY. Dar despre toate acestea vom discuta detaliat în capitolul 4.

Sistemele de gestiune a bazelor de date relaţionale Un sistem de gestiune a bazelor de date relaţionale (SGBDR) este un program software folosit pentru crearea, întreţinerea, modificarea şi manipularea unei baze de date relaţionale. Numeroase programe SGBDR furnizează şi instrumentele necesare pentru a putea crea aplicaţii destinate utilizatorilor finali care lucrează cu datele din baza de date. Numeroasele facilităţi oferite de diferiţi producători evoluează foarte rapid, devenind din ce în ce mai performante. Primele SGBDR-uri au fost concepute pentru sisteme de tip desktop. Acestea presupun existenţa unei copii a bazei de date pe fiecare calculator care nu este un mare avantaj, în ceea ce priveşte actualizarea datelor. În acest context a apărut necesitatea amplasării în mod centralizat a întregii baze de date care să fie accesată de toţi utilizatorii. Aşa au apărut SGBDR-urile de tip client-server în care bazele de date se stochează pe un server de baze de date, iar utilizatorii interacţionează cu datele prin intermediul unor aplicaţii rezidente pe propriul calculator numit clientul bazei de date. Creatorul de baze de date foloseşte programul client-server SGBDR pentru a crea şi întreţine programele de aplicaţie de baze de date şi programele accesorii pentru utilizatorul final. Acesta implementează integritatea şi securitatea datelor din serverul de baze de date, având astfel posibilitatea de a fundamenta o diversitate de aplicaţii utilizator pe acelaşi set de date, fără a afecta integritatea şi securitatea datelor. Cele mai cunoscute SGBDR-uri sunt:  Microsoft Access  Microsoft SQL Server  Oracle  MySQL  PostgreSQL Microsoft Access este un SGBDR comercial de tip desktop, folosit pentru gestionarea bazelor de date de dimensiuni mici şi medii. Poate acoperi fără probleme segmentul firmelor mici şi mijlocii. Este sistemul de gestiune pe care îl vom studia şi noi în această carte.

14

Baze de date

Capitolul 1

Microsoft SQL Server este un SGBDR de tip client-server care acceptă baze de date foarte mari şi un număr foarte mare de tranzacţii şi rulează numai pe sistemele de operare Windows. Este soluţia ideală pentru firmele mari, la un preţ de cost relativ scăzut. Oracle este liderul mondial al pieţei SGBDR-urilor de tip client-server. Oracle acceptă baze de date enorme şi un număr imens de tranzacţii. Oracle rulează pe numeroase sisteme de operare, este un SGBDR complex a cărui operare şi întreţinere trebuie făcute de un administrator special instruit pentru acest scop. Se întâlneşte la marile companii transnaţionale, deoarece preţul său este pe măsura performanţelor. MySQL este un SGBDR din categoria open-source(codul sursă este pus gratuit la dispoziţia utilizatorilor) fiind unul din liderii pieţei. MySQL este rapid, stabil şi acceptă baze de date de mari dimensiuni, dar îi lipsesc câteva din caracteristicile importante ale limbajului SQL. Versiunile viitoare îşi propun includerea acestor caracteristici. Rulează pe mai multe sisteme de operare şi este gratuit pentru utilizarea în scopuri personale(care nu aduc un câştig). PostgreSQL este un SGBDR din categoria open-source, fiind unul din liderii pieţei. Acceptă baze de date de mari dimensiuni, este recunoscut pentru setul său bogat de caracteristici.

Dincolo de modelul relaţional Programele SGBDR au fost acceptate pe scară largă fiind utilizate în aplicaţii de afaceri concrete, precum inventarele, gestiunea pacienţilor, a materialelor şi pieselor, în domeniul bancar, dar s-au dovedit a lipsi în aplicaţii de genul proiectării asistate de calculator (CAD), sisteme informaţionale geografice (GIS) şi sisteme de stocare multimedia. Ca răspuns la această problemă au apărut două noi modele de bază de date: modelul orientat spre obiect şi modelul relaţional obiect. Modelul orientat spre obiect încorporează toate caracteristicile unui limbaj de programare orientat spre obiect, iar baza de date relaţională este retrogradată la statutul de magazie de date. Ideea fundamentală este că dezvoltatorul bazei de date tratează fiecare aspect al acesteia, inclusiv setul de operaţiuni care manipulează datele din baza de date, din interiorul limbajului de programare a bazei de date orientată obiect. Nu mai există o diferenţă clară între programul de bază de date şi programul de realizare a aplicaţiilor. Deşi este un pas înainte, modelul orientat spre obiect nu întruneşte consensul tuturor specialiştilor din domeniu. Viitorul va da însă verdictul în această problemă delicată.

15

Baze de date

Capitolul 1

Modelul relaţional obiect a extins modelul bazei de date relaţionale prin încorporarea a diferite elemente şi caracteristici orientate spre obiect, precum clase, încapsulare şi moştenire. Ideea era ca aceste extensii să permită unei baze de date relaţionale să gestioneze şi să manipuleze tipuri de date complexe, precum secvenţe audio sau video şi desene sau reprezentări grafice. Modelul relaţional obiect încă nu a fost definitivat, se mai lucrează la el, majoritatea specialiştilor consideră că aceasta este direcţia corectă. El este exploatat şi rafinat în continuare. Internetul exercită o mare influenţă asupra modului de utilizare a bazelor de date în cadrul organizaţiilor. Multe companii şi afaceri folosesc Web-ul pentru a-şi extinde baza de consumatori, iar o bună parte din datele oferite acestor consumatori, respectiv pe care le preiau de la aceştia, sunt stocate într-o bază de date. Internetul a generat un limbaj numit XML (eXtensible Markup Language) capabil să partajeze date din diferite sisteme eterogene. Mulţi producători de SGBDR se orientează spre încorporarea a cât mai multe caracteristici XML în propriile produse. Cu toate noile orientări prezentate, bazele de date relaţionale pe care le vom studia nu vor dispare în viitorul apropiat.

Întrebări pentru autoevaluare De unde vine termenul de bază de date relaţională? Cum se stochează datele într-o bază de date relaţională? Denumiţi cele trei tipuri de relaţii existente într-o bază de date relaţională. Indicaţi câteva avantaje ale bazelor de date relaţionale. Ce este un sistem de gestiune a bazelor de date relaţionale? Care sunt cele mai cunoscute sisteme de gestiune a bazelor de date relaţionale?

16

Baze de date

Capitolul 2

Capitolul 2. Terminologia bazelor de date relaţionale În acest capitol vom clarifica termenii folosiţi în teoria şi practica bazelor de date relaţionale, pentru a evita confuziile făcute de unii membri implicaţi în procesul de proiectare sau exploatare.

Importanţa terminologiei Este important să înţelegem termenii prezentaţi în acest capitol înainte de a începe studiul bazelor de date relaţionale. Proiectarea bazelor de date are un set de termeni specifici ca, de altfel, orice profesie, meserie sau disciplină. Iată câteva motive care justifică importanţa învăţării acestor termeni:  Termenii respectivi sunt utilizaţi pentru a exprima şi defini ideile şi conceptele speciale ale modelului de baze de date relaţionale. O bună parte din terminologie derivă din ramurile matematice ale teoriei mulţimilor şi respectiv logicii predicatelor de ordinul întâi.  Termenii respectivi sunt utilizaţi pentru a exprima şi defini însuşi procesul de proiectare a bazelor de date. Procesul de proiectare devine mai clar şi mult mai simplu de înţeles, după ce v-aţi familiarzat cu aceşti termeni.  Termenii respectivi sunt utilizaţi oriunde se discută despre o bază de date relaţională sau despre un program SGBDR. Veţi întâlni aceşti termeni în publicaţii cum ar fi reviste de comerţ, manuale de programare SGBDR, suporturi de cursuri etc. De asemenea, veţi auzi aceşti termeni în conversaţiile între diferite categorii de profesionişti din domeniul bazelor de date.

Există patru categorii de termeni de care o să ne ocupăm în acest capitol, termeni referitori la: valoare, structură, relaţie şi integritate.

17

Baze de date

Capitolul 2

Termeni referitori la valoare Date şi informaţii Valorile pe care le stocăm în bazele de date se numesc date. Acestea sunt statice în sensul că rămân aceleaşi până nu intervine o modificare manuală sau automată. În figura 2.1 este prezentat un exemplu de date. George Fodor 6582421 12/05/2004 57.50 Fig. 2.1. Exemplu de date elementare

La prima vedere, aceste date sunt lipsite de sens pentru că nu ne putem da seama ce reprezintă numărul 6582421 sau celelalte, chiar dacă observăm că una din valori este o dată calendaristică iar ultima este un număr zecimal. Nu ne putem da seama până nu prelucrăm datele. Informaţiile reprezintă date pe care le prelucrăm într-un mod care le conferă semnificaţie şi utilitate pentru noi atunci când lucrăm cu Fodorsunt 6582421 12/05/2004 respectivele date.George Informaţiile dinamice, în sensul că se modifică în 57.50 permanenţă după cum se modifică datele din baza de date, dar şi în sensul că pot fi prelucrate într-un număr nelimitat de moduri. Ideea care trebuie reţinută este că trebuie să prelucrăm datele pentru a le putea transforma în informaţii cu sens. Figura 2.2 demonstrează un mod în care datele din exemplul precedent pot fi prelucrate şi transformate în iformaţii. Datele respective au fost manipulate încât au ajuns într-o factură pentru un pacient – încât acum au sens pentru oricine le citeşte. George Fodor 6582421 12/05/2004 57.50 Spitalul Municipal Tg. Mures Str. Clinicilor nr.66 Sectia Cardiologie

Consultaţii

x x

Pacient: Cod pacient: Data consultaţiei: Medic:

Analize

General

30.00

Sânge

EKG

27.50

Urina

Ultrasunete

George Fodor 6582421 12/05/2004 dr. Hipocrate B.

Glicemie

Total plată: 57.50

George Fodor 6582421 12/05/2004 57.50 Total plată: Fig. 2.2. Exemplu de date transformate în informaţii 57.50 18 Total plată: 57.50

Baze de date

Capitolul 2

Este foarte important să înţelem diferenţa dintre date şi informaţii. O bază de date este proiectată astfel încât să furnizeze informaţii semnificative pentru orice persoană abilitată din cadrul unei firme sau organizaţii. Aceste informaţii pot fi puse la dispoziţie numai dacă datele corespunzătore există în baza de date şi dacă aceasta din urmă este astfel structurată încât să permită obţinerea informaţiilor respective. Dacă uitaţi vreodată care este diferenţa dintre date şi informaţii, reţineţi următoarea axiomă: Datele se stochează, iar informaţiile se regăsesc. Din păcate, există cărţi comerciale în care se confundă datele cu informaţiile. Valoare nulă O valoare nulă reprezintă o valoare care lipseşte sau care nu este cunoscută. Deseori, valoarea nulă se confundă cu un zero sau unul sau mai multe spaţii albe, ceea ce este total greşit, din următoarele motive: Un zero poate avea mai multe semnificaţii cum ar fi nivelul stocului unui anumit produs, numărul de apariţii a unui cod etc. Deşi un şir text format din unul sau mai multe spaţii albe nu înseamnă nimic pentru cei mai mulţi dintre noi, reprezintă categoric semnificaţie pentru un limbaj de interogare cum ar fi SQL. Un spaţiu alb este un caracter ca oricare altul cum ar fi “a”. Un şir de lungime zero – adică două ghilimele consecutive fără spaţiu între ele “”, este de asemenea o valoare acceptabilă pentru limbaje precum SQL şi poate fi semnificativă în anumite circumstanţe.

De menţionat faptul că în practică, apar multe cazuri când la completarea unui câmp al unui tabel este împiedicată de necunoaşterea, pe moment, a valorii respective şi în acest caz va apare o valoare nulă. Acest câmp poate fi completat ulterior, după ce se află valoarea respectivă (ex., un număr de telefon, un cod etc.). Principalul dezavantaj al valorilor nule este acela că pot avea efect negativ asupra calculelor matematice, ştiut fiind că rezultatul unei operaţii matematice în care este implicată o valoare nulă, este o valoare nulă. Problema valorilor absente, necunoscute, precum şi faptul că vor fi folosite 19

Baze de date

Capitolul 2

sau nu în expresii matematice sau funcţii agregat, vor fi luate în considerare în decursul procesului de proiectare a bazelor de date relaţionale.

Termeni referitori la structură Tabel În conformitate cu modelul relaţional, datele dintr-o bază de date relaţională sunt stocate în relaţii, care sunt percepute de utilizator sub formă de tabele. Fiecare relaţie este alcătuită din înregistrări (tupluri) şi câmpuri (atribute). În figura 2.3 este prezentată o structură de tabel caracteristică. StudentID 5001 5002 5012 5065 5032

Nume Pop Ban Lazăr Ban Pop

Prenume Mariana Ioan Ana Lucia Dorin

Sectia TCM TCM IEI IMPI MEC

<>

Înregistrări

Câmpuri Fig. 2.3. O structură de tabel

Tabelele reprezintă structurile esenţiale dintr-o bază de date, iar fiecare tabel reprezintă întotdeauna un singur subiect concret, cum ar fi studenţi, produse, vânzări etc. Ordinea logică a înregistrărilor şi a câmpurilor din cadrul unui tabel nu are nici o importanţă, iar fiecare tabel conţine cel puţin un câmp – cunoscut sub numele de cheie primară – care identifică în mod unic fiecare înregistrare a tabelului. În figura 2.3, StudentID este cheia primară a tabelului tblStudenti. Datele dintr-o bază de date relaţională pot exista independent de modul în care sunt stocate fizic în calculator, datorită acestor ultime două caracteristici ale unui tabel. Pentru utilizator acest lucru este foarte bun, deoarece acesta nu mai trebuie să cunoască locaţia fizică a unei înregistrări pentru a putea regăsi datele.

20

Baze de date

Capitolul 2

Subiectul pe care îl reprezintă un tabel dat poate fi un obiect sau un eveniment. Când subiectul este un obiect, tabelul reprezintă o cantitate palpabilă, precum o persoană, un produs sau un lucru oarecare. Indiferent de tipul său, un obiect are caracteristici care pot fi stocate sub formă de date, care vor putea fi prelucrate ulterior într-un număr mare de moduri. Când subiectul unui tabel este un eveniment, înseamnă că tabelul reprezintă ceva care se produce la un anumit moment de timp şi care are caracteristici pe care doriţi să le înregistraţi. Exemplul clasic care se poate da aici este tabelul cu consultaţiile ţinute de un medic de familie. În figura 2.4 este prezentat un astfel de tabel. PacientID 92001 97004 98023 93034 94001

Data cons. 12-1-2005 12-1-2005 12-1-2005 12-1-2005 12-1-2005

Ora cons. 8:30 9:00 9:30 10:30 11:45

Medic Avram I. Avram I. Popescu D. Popescu D. Avram I.

Tensiune 120/80 125/80 130/82 145/90 132/86

<>

Fig. 2.4. Tabel care reprezintă un eveniment

Tabelele pot fi, într-o altă clasificare, de două tipuri: Tabele de date care furnizează date folosite pentru furnizarea de informaţii şi reprezintă tipul de tabel cel mai frecvent întâlnit într-o bază de date. Datele din acest tip de tabel sunt dinamice deoarece se pot manipula (modificare, ştergere) şi converti în informaţii într-o anumită formă sau manieră. Cu astfel de tabele veţi lucra foarte frecvent în decursul lucrului cu baza de date. Tabele de validare care stochează date pe care le veţi folosi cu scopul precis de a implementa integritatea datelor. De obicei, un tabel de validare conţine nume de localităţi, coduri de produse, categorii de activităţi etc. Datele din acest tip de tabel sunt statice, adică se modifică foarte rar.

În figura 2.5 este prezentat un tabel de validare pentru secţiile facultăţii de inginerie. SectieID

Denumire

11 13 12 15 19

TCM IEI Mecatronica Ingineria mediului Design

Fig. 2.5. Tabel de validare

21

Baze de date

Capitolul 2

În loc să introducem greşit într-un alt tabel, numele unei secţii, vom introduce codul său, asigurând în acest fel integritatea datelor. Câmp Un câmp reprezintă cea mai mică structură din baza de date şi reprezintă o caracteristică a subiectului tabelului căruia îi aparţine. Câmpurile sunt structurile care stochează efectiv datele, care apoi pot fi regăsite şi prezentate ca informaţii în aproape orice configuraţie pe care o puteţi imagina. Calitatea informaţiilor pe care o veţi obţine din datele pe care le aveţi este direct proporţională cu timpul dedicat asigurării integrităţii structurale şi de date a câmpurilor înseşi. Fiecare câmp dintr-o bază de date corect proiectată conţine singură valoare, iar numele său va identifica tipul de valoare admis. Astfel, procesul de introducere a datelor devine foarte intuitiv. Dacă vedeţi câmpuri cu nume precum Nume, Prenume, Judet, Localitate, Telefon sau Cod postal, atunci veţi şti exact ce tipuri de date veţi introduce în fiecare câmp. De asemenea, va fi foarte simplu să sortaţi datele în funcţie de judeţ ori să căutaţi persoanele dintr-o anumită localitate a unui judeţ. Într-o bază de date slab proiectată sau proiectată inadecvat, veţi întâlni în mod caracteristic alte trei tipuri de câmpuri, după cum urmează: Un câmp multiplu (numit şi câmp cu mai multe părţi) care conţine două sau mai multe elemente distincte în cadrul valorii acestuia. Un câmp cu valori multiple (numit şi câmp cu mai multe valori) care conţine mai multe apariţii ale aceluiaşi tip de valoare. Un câmp calculat, care conţine o valoare de text concatenat sau rezultatul unei expresii matematice.

În figura 2.6 este prezentat un tabel care conţine câte un câmp din fiecare tip amintit mai sus.

22

Baze de date

Capitolul 2

Câmp calculat

Câmp multiplu

ProdusID 5001 6023

Denumire Planetara Rulment

Furnizor SC Lion SC RPA

Pret 900 23

Cant 5 10

Valoare 4500 230

6034

Acumulat or

500

4

2000

5098 5067

Bujie Antigel

SC Rulment ul SC ARC SC Lion

12 10

100 40

1200 400

Valori multiple

Loc, Judet Dej, Cluj Brasov,Bra sov Bistrita, Bistrita

Agent Pop, Rusu Danciu

Cluj,Cluj Dej, Cluj

Danciu, Pop Pop, Rusu

Danciu

Fig. 2.6. Tabel cu câmpuri normale, calculate, multiple

Înregistrare O înregistrare reprezintă o instanţă unică a subiectului unui tabel. Înregistrarea este alcătuită din întregul set de câmpuri dintr-un tabel, indiferent dacă respectivele câmpuri conţin sau nu valori. Datorită modalităţii de definire a unui tabel, fiecare înregistrare este definită în baza de date prin intermediul unei valori unice a câmpului cheie primară a înregistrării respective. Astfel, dacă avem un tabel de persoane, o înregistrare din tabel trebuie să identifice fiecare persoană din tabel, care este un unicat. În figura 2.6, fiecare înregistrare reprezintă un produs unic din cadrul tabelului, iar câmpul ProdusID este folosit pentru a identifica un produs din cadrul bazei de date. La rândul său, fiecare înregistrare include toate câmpurile din tabel, iar fiecare câmp descrie un aspect al produsului reprezentat de înregistrare. Înregistrările reprezintă un element cheie pentru înţelegerea relaţiilor dintre tabele, deoarece va trebui să cunoaşteţi relaţia dintre o înregistrare a unui tabel şi alte înregistrări din alt tabel.

23

Baze de date

Capitolul 2

Vedere O vedere este un tabel “virtual” compus din câmpuri dintr-unul sau mai multe tabele ale bazei de date; tabelele care alcătuiesc vederea sunt cunoscute sub numele de tabele de bază. Modelul relaţional îi atribuie unei vederi atributul de virtuală deoarece îşi preia datele din tabele de bază, nuşi stochează propriile sale date. De fapt, singurele informaţii referitoare la o vedere care sunt stocate în baza de date se referă la structura vederii respective. Numeroase programe SGBDR principale lucrează cu vederi, dar unele (precum Microsoft Access) le denumesc interogări salvate. Programul SGBDR pe care îl utilizaţi va determina dacă obiectul respectiv va fi denumit interogare sau vedere. Vederile permit privirea informaţiilor din baza dumneavoastră de date din diferite unghiuri, furnizând o mare flexibilitate în lucrul cu datele. Puteţi crea vederi într-o varietate de moduri, iar o vedere este utilă mai ales când se bazează pe mai multe tabele corelate. Într-o bază de date cu orare şcolare, de exemplu, puteţi crea o vedere care sintetizează date din tabelele ELEVI, CURSURI şi ORARE CURSURI. În figura 2.7 este prezentată o vedere cu situaţia împrumuturilor de cărţi, ale cărei date au fost extrase din trei tabele: Studenti, Imprumuturi, Carti.

24

Baze de date

Capitolul 2

Studenti StudentID 60001 60002 60003 60004

Nume Crişan Lazăr Mocean Mocean

Prenume Ovidiu Denisa Gabriel Olimpiu

Imprumuturi StudentID CarteID 60001 1001 60002 1001 60003 1099 60004 1099

Carti CarteID 1001 1099 1023 1009

Denumire PUC Baze de date Fizica Chimie

Telefon 0745-328092 0722-7575823 0744-7575939 0723-6564321

<> ….. ….. ….. …..

Data 3/10/2004 3/10/2004 5/10/2004 5/11/2004

Categorie P1 P1 F1 F1

<> ...... ...... ..... …..

Situatie împrumuturi (vedere) Nume Crişan Lazăr Mocean Mocean

Prenume Ovidiu Denisa Gabriel Olimpiu

Denumire PUC PUC Baze de date Baze de date

Data 3/10/2004 3/10/2004 5/10/2004 5/11/2004

Fig. 2.7. Un exemplu de vedere caracteristică

Există trei motive majore care conferă importanţă vederilor: Vederile permit lucrul simultan cu date preluate din mai multe tabele, între care există relaţii. Vederile permit împiedicarea anumitor utilizatori de a vedea sau manipula anumite câmpuri dintr-un tabel sau grup de tabele. Această posibilitate se poate dovedi foarte avantajoasă din punctul de vedere al securităţii datelor.

25

Baze de date

Capitolul 2

Vederile se pot utiliza pentru implementarea integrităţii datelor, numite în acest caz vederi de validare.

Chei Cheile sunt acele câmpuri speciale care îndeplinesc roluri foarte bine determinate în cadrul unui tabel, iar tipul cheii defineşte rolul acesteia în interiorul tabelului. Un tabel poate conţine numeroase tipuri de chei, dar cele mai importante sunt cheia primară şi cheia externă. O cheie primară este un câmp sau un grup de câmpuri care identifică în mod unic fiecare înregistrare din cadrul unui tabel; dacă o cheie primară este compusă din două sau mai multe câmpuri, este cunoscută sub numele de cheie primară compozită. O valoare a unei primare identifică o anumită înregistrare din întreaga bază de date. Cheia primară impune integritatea la nivel de tabel şi facilitează stabilirea relaţiilor cu alte tabele din baza de date. Reţineţi faptul că o cheie primară are valori unice în cadrul unui, aceasta fiind cea mai importantă proprietate a acesteia. De regulă, cheile primare vor fi nişte coduri numerice, uneori generate chiar de sistemul de gestiune a bazei de date, cum ar fi sistemul Access, pe care o să-l studiem în cadrul acestui curs şi care tipul de dată AutoNumber, special gândit pentru generarea cheilor primare. O cheie externă dintr-un tabel este acea cheie care este cheie primară în alt tabel. Ea nu trebuie să fie unică după cum veţi observa în următorul exemplu, rolul ei este, în special, de a asigura legătura cu alt tabel. În figura 2.8 se pot vedea o cheie primară şi o cheie externă.

26

Baze de date

Capitolul 2

Cheie primară

Cheie primară Sportivi SportivID 8001 8002 8003

Impresari ImpresarID 100 101 102

ImpresarID 100 101 100

Nume Becali Popescu Becali

Nume sportiv Mutu Adrian Neaga Ioan Chivu Cristian

Prenume Ioan Gică Victor

Telefon

Telefon 0745-655482 0745-658312 0744-547212 <>

0745-657329 0744-768432 0723-546291

Cheie externă Fig. 2.8. Exemplu de câmpuri cheie primară şi cheie externă

Se observă cum câmpul ImpresarID este cheie primară pentru tabelul Impresari şi cheie externă pentru tabelul Sportivi. Acolo unde este cheie externă, valoarea ei se poate repeta, ceea ce este firesc, deoarece un impresar poate avea mai mulţi sportivi. Câmpul ImpresarID din cele două tabele asigură legătura dintre ele, asigurând în acelaşi timp şi integritatea datelor, adică fiecare sportiv are un impresar valabil. Când determinaţi că între două tabele există o relaţie, în mod caracteristic stabiliţi relaţia respectivă preluând o copie a cheii primare din primul tabel şi încorporând-o în structura celui de-al doilea tabel, unde devine cheie externă. Numele de „cheie externă” derivă din faptul că al doilea tabel are deja o cheie primară proprie, iar cheia primară pe care o introduceţi din primul tabel este „externă” pentru al doilea tabel. Dincolo de facilitatea stabilirii relaţiilor dintre perechi de tabele, cheile externe contribuie şi la implementarea şi asigurarea integrităţii la nivel de relaţie. Aceasta înseamnă că înregistrările din ambele tabele vor fi întotdeauna corelate în mod adecvat, deoarece valorile unei chei externe trebuie să fie identice cu valorile existente ale cheii primare la care face referire. O greşeală frecventă care se face de către începători, este că dau tipuri de dată diferite unor câmpuri pe care doresc să le folosească pentru legătura a două tabele. De asemenea, integritatea la nivel de relaţie permite evitarea periculoaselor înregistrări „orfane”, un exemplu clasic în acest sens reprezentându-l 27

Baze de date

Capitolul 2

înregistrarea unei comenzi fără un client asociat. Dacă nu ştiţi cine a emis comanda, nu o puteţi prelucra şi, evident, nu o puteţi factura, iar asta o să vă ducă de râpă vânzările trimestriale. Câmpurile cheie joacă un rol important într-o bază de date relaţională, iar dumneavoastră trebuie să învăţaţi să le creaţi şi să le utilizaţi. Index Un index este o structură pe care un program SGBDR o pune la dispoziţie pentru îmbunătăţirea procesului de prelucrare a datelor. Un index nu are nici o legătură cu structura logică a bazei de date. Unicul motiv pentru care discutăm despre termenul index în acest capitol este faptul că oamenii îl confundă deseori cu termenul cheie. Index şi cheie reprezintă o altă pereche de termeni folosiţi eronat în mod frecvent şi pe scară largă în industria bazelor de date. (Mai ţineţi minte deosebirile dintre date şi informaţii?). Veţi sesiza întotdeauna diferenţa dintre cei doi termeni dacă reţineţi că, în timp ce cheile sunt structuri logice pe care la identificarea înregistrărilor dintr-un tabel, indecşii reprezintă structuri fizice utilizate la optimizarea procesului de prelucrare a datelor. Prin folosirea indecşilor, sortările şi filtrările unei baze de date se face într-un timp mult mai scurt.

28

Baze de date

Capitolul 2

Termeni referitori la relaţie Relaţii Între două tabele există o relaţie atunci când înregistrările din primul tabel pot fi asociate cu înregistrările din al doilea tabel. Relaţia se poate stabili prin intermediul unui set de chei primare şi chei externe sau cu ajutorul unui al treilea tabel, numit tabel de legătură (cunoscut şi sub numele de tabel asociativ). Figura 2.8 ilustrează o relaţie stabilită prin intermediul cheilor primare şi al cheilor externe, iar figura 2.9 exemplifică o relaţie stabilită cu ajutorul unui tabel de legătură. Studenti StudID 6001 6002 6003 6004 6004

Nume Pop Szabo Costea Timocea Mocean

Prenume Remus Zoltan Florian Sebastian Vasile

Orar student(table de legătură) StudID 6001 6002 6002 6001 6002 6003 6003 6001 6003 6001

CursID C001 C213 C001 C213 C015 C001 C213 C015 G001 G001

OrasStudent Reghin Oradea Zalau Brasov Fagaras

Cursuri CursID Denumire C001 PUC C213 Baze de date C032 SIM C015 GD G001 AutoCAD G004 Inventor G007 Intellicad

<> ........ ........ ........ ........ ........ Credite 5 5 4 5 4 5 4

ProfesorID 25461 25461 56821 12843 32584 3212 25461

Fig.2.9. O relaţie stabilită între două tabele prin intermediul unui tabel de legătură

29

Baze de date

Capitolul 2

O relaţie este o componentă importantă a unei baze de date relaţionale. O relaţie permite crearea de vederi din tabele multiple şi este crucială pentru integritatea datelor, întrucât contribuie la cantităţii de date redundante şi la eliminarea datelor duplicate. Puteţi caracteriza o relaţie în trei moduri: în funcţie de tipul relaţiei dintre tabele, de maniera în care fiecare tabel participă la relaţie şi de gradul de participare al fiecărui tabel. Relaţii „unu cu unu” Două tabele au o relaţie unu cu unu când o singură înregistrare din primul tabel este corelată cu o singură înregistrare din al doilea tabel şi o singură înregistrare din al doilea tabel este corelată cu o singură înregistrare din primul tabel. În figura 2.10 este reprezentată o astfel de relaţie. Într-o asemenea relaţie, un tabel serveşte ca “tabel părinte”, iar celălalt îndeplineşte rolul de “tabel copil”. Relaţia se stabileşte prin preluarea unei cópii a cheii primare a tabelului părinte şi încorporarea acesteia în structura tabelului copil, unde devine o cheie externă. Acesta este un tip special de relaţie, deoarece este unicul în cadrul căruia ambele tabele pot folosi efectiv aceeaşi cheie primară. În figura 2.10 este prezentat un exemplu clasic de relaţie unu la unu. În acest caz SALARIAŢI este tabelul părinte, iar SALARIU este tabelul copil. Se observă că fiecare salariat din primul tabel are un singur corespondent din al doilea tabel. Salariaţi SalariatID 100 101 102 103

Nume Ban Pop Lazăr Crişan

Prenume Ioan Dorin Liviu Ovidiu

Telefon 0745-646321 0723-548211 0264-542138 0740-764282

<> ….. ….. ….. …..

Salariu SalariatID 100 101 102 103

Salar orar 34.50 23.00 17.45 16.00

Sporuri 10% 5% 20% 18%

30

<> ….. ….. ….. …..

Baze de date

Capitolul 2 Fig. 2.10. Exemplu de relaţie „unu la unu”

Relaţia unu la unu poate fi imaginată ca o “rupere” în două a tabelului. Deşi câmpurile din aceste tabele pot fi combinate într-un singur tabel, proiectantul bazei de date a ales să plaseze în tabelul SALARIAŢI câmpurile ce pot fi văzute de orice membru al organizaţiei şi în tabelul SALARIU câmpurile ce pot fi văzute doar de personalul autorizat, ştiut fiind că salariile sunt, de obicei, confidenţiale. Relaţii „unu cu mai mulţi” Între două tabele există o relaţie unu cu mai mulţi când o înregistrare din primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea tabel, în timp ce o înregistrare din al doilea tabel poate fi corelată cu o singură înregistrare din primul tabel. Să studiem un exemplu generic pentru acest tip de relaţie. Modelul părinte/copil pe care l-am utilizat pentru a descrie o relaţie „unu cu unu” se aplică şi în acest caz, partea unu a relaţiei este tabelul părinte, iar tabelul din partea mai mulţi este tabelul copil. O relaţie de tipul unu cu mai mulţi se stabileşte prin preluarea unei cópii a cheii primare a tabelului părinte şi încorporarea acesteia în structura tabelului copil, unde devine o cheie externă. Exemplul din figura 2.11 ilustrează o relaţie de tip unu cu mai mulţi caracteristică. Clienti ClientID 9001 9002 9003 9004 9005

Nume Pop Ban Lazăr Buzan Beldean

Prenume Dorin Ion Ana Maria Vian

....... ....... ....... ....... .......

Imprumuturi ClientID 9002 9001 9004 9003 9003 9003 9002 9005 9005

Fig. 2.11. Exemplu de relaţie „unu cu mai mulţi”

31

CarteID 5648 690423 6563 65323 09542 64823 75001 10045 76100

Data .... .... .... .... .... .... .... .... ....

Baze de date

Capitolul 2

O singură înregistrare din tabelul CLIENTI poate fi corelată cu una sau mai multe înregistrări din tabelul IMPRUMUTURI, dar o înregistrare din tabelul IMPRUMUTURI este corelată cu o singură înregistrare din tabelul CLIENTI. După cum probabil aţi dedus, câmpul ClientID este o cheie externă în tabelul IMPRUMUTURI. Relaţia unu cu mai mulţi este cea mai obişnuită relaţie care există între două tabele dintr-o bază de date şi este cea mai uşor de identificat. Relaţia este extrem de importantă din punct de vedere al integrităţii datelor, deoarece ea vă ajută să eliminaţi datele duplicate. Relaţii de tip ”mai mulţi cu mai mulţi” Între două tabele există o relaţie de mai mulţi cu mai mulţi când o înregistrare din primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea tabel şi o înregistrare din al doilea tabel poate fi corelată cu una sau mai multe înregistrări din primul tabel. O relaţie din această categorie se stabileşte cu ajutorul unui tabel de legătură. Un tabel de legătură facilitează asocierea înregistrărilor dintr-un tabel cu înregistrările din celălalt tabel şi asigură lipsa oricăror probleme la operaţiile de adăugare, ştergere sau modificare a datelor corelate. Un tabel de legătură se defineşte prin preluarea unor cópii ale cheii primare din fiecare tabel şi utilizarea lor pentru a forma structura noului tabel. În realitate, aceste câmpuri îndeplinesc două roluri distincte: împreună formează cheia primară compozită a tabelului de legătură, iar separat, fiecare poate fi asimilată unei chei externe. O relaţie de tip mai mulţi cu mai mulţi care nu este stabilită în mod corespunzător se numeşte „nerezolvată”. Figura 2.12 prezintă un exemplu clasic şi clar de relaţie de tip mai mulţi cu mai mulţi nerezolvată. În acest exemplu, o înregistrare din tabelul STUDENTI poate fi corelată cu mai multe înregistrări din tabelul CURSURI, în timp ce o singură înregistrare din tabelul CURSURI poate fi corelată cu mai multe înregistrări din tabelul STUDENTI.

32

Baze de date

Capitolul 2

Studenti StudID 6001 6002 6003 6004 6004

Nume Pop Szabo Costea Timocea Mocean

Prenume Remus Zoltan Florian Sebastian Vasile

<> ........ ........ ........ ........ ........

OrasStudent Reghin Oradea Zalau Brasov Fagaras

Cursuri CursID C001 C213 C032 C015 G001 G004 G007

Denumire PUC Baze de date SIM GD AutoCAD Inventor Intellicad

Credite 5 5 4 5 4 5 4

ProfesorID 25461 25461 56821 12843 32584 3212 25461

Sala 208 208 209 207 207 208 208

<> ........ ........ ........ ........ ........ ........ ........

Fig. 2.12. Un exemplu tipic de relaţie „mai mulţi cu mai mulţi” nerezolvată

Această relaţie este nerezolvată datorită particularităţii intrinseci a relaţiei de tip mai mulţi cu mai mulţi. Principala problemă este următoarea: cum se pot asocia cu uşurinţă înregistrări din primul tabel cu înregistrările din al doilea tabel? Pentru a reformula întrebarea folosind tabelele din figura 2.12, cum se asociază un student cu mai multe cursuri sau un anumit curs cu mai mulţi studenţi? Se inserează câteva câmpuri Student în tabelul CURSURI sau mai multe câmpuri Curs în tabelul STUDENTI? Oricare din aceste metode va îngreuna lucrul cu datele şi va afecta în mod negativ integritatea datelor. Cea mai bună metodă constă în din crearea şi utilizarea unui tabel de legătură, care va rezolva relaţia de tip mai mulţi cu mai mulţi în maniera cea mai adecvată şi mai eficientă. Figura 2.13 prezintă implementarea practică a cestei soluţii. Este important ca dumneavoastră să cunoaşteţi tipul de relaţie care există între tabelele dintr-o pereche, deoarece acesta determină modul în care sunt corelate tabelele, dacă înregistrările din tabele sunt interdependente sau nu, precum şi numărul minim şi maxim de înregistrări corelate care pot exista în cadrul relaţiei.

33

Baze de date

Capitolul 2

Studenti StudID Nume 6001 Studenti Pop 6002 Szabo 6003 Costea 6004 Timocea 6004 Mocean

Prenume Remus Zoltan Florian Sebastian Vasile

Orar StudID 6001 6002 6002 6001 6002 6003 6003 6001 6003 6001

CursID C001 C213 C001 C213 C015 C001 C213 C015 G001 G001

OrasStudent Reghin Oradea Zalau Brasov Fagaras Cursuri CursID C001 C213 C032 C015 G001 G004 G007

<> ........ ........ ........ ........ ........

Denumire PUC Baze de date SIM GD AutoCAD Inventor Intellicad

Credite 5 5 4 5 4 5 4

ProfID 25461 25461 56821 12843 32584 3212 25461

Fig.2.13. Rezolvarea unei relaţii de tip mai mulţi cu mai mulţi cu ajutorul unui tabel de legătură

Tipuri de participare Când stabiliţi o relaţie între două tabele, fiecare tabel participă la relaţie într-o manieră particulară. Tipul de participare pe care îl atribuiţi unui tabel dat determină dacă în respectivul tabel trebuie să existe o înregistrare înainte de a putea introduce înregistrări în tabelul corelat. Există două tipuri de participări: Obligatorie - tabelul trebuie să conţină cel puţin o înregistrare înainte de a putea introduce înregistrări în tabelul corelat. Opţională – nu este obligatoriu ca tabelul să conţină vreo înregistrare înainte de a putea introduce înregistrări în tabelul corelat.

34

Baze de date

Capitolul 2

De obicei, pentru majoritatea tabelelor, veţi determina tipul de participare după ce definiţi regulile de lucru cu baza de date. În majoritatea cazurilor, tipul de participare este evident, este de bun simţ sau este în concordanţă cu un anumit set de standarde. Să examinăm perechea de tabele din figura 2.11, care se găsesc într-o relaţie unu cu mai mulţi. Ne propunem să stabilim tipul de participare a celor două tabele în această relaţie. Pentru aceasta trebuie să răspundem la câteva întrebări. Putem introduce înregistrări în tabelul CLIENTI dacă nu avem nici o înregistrare în tabelul IMPRUMTURI? Răspunsul este DA, pentru că tabelul cu potenţialii clienţi se completează la început, deci tabelul IMPRUMUTURI are un tip de participare opţională, pentru această relaţie. La întrebarea dacă putem introduce înregistrări în tabelul IMPRUMTURI dacă nu avem nici o înregistrare în tabelul CLIENTI, răspunsul este NU, pentru că trebuie să avem cel puţin un client la care să împrumutăm, deci tabelul CLIENTI are un tip de participare obligatorie, pentru această relaţie. Gradul de participare Gradul de participare determină numărul minim de înregistrări existente într-un tabel al unei relaţii, asociate cu o singură înregistrare a unui tabel corelat, respectiv numărul maxim de înregistrări care pot exista într-un tabel al unei relaţii, asociate cu o singură înregistrare din tabelul corelat. Să luăm în considerare, o relaţie dintre două tabele A şi B. Se stabileşte gradul de participare pentru tabelul B prin indicarea numărului minim, respectiv maxim de înregistrări din tabelul B, prin indicarea numărului minim, respectiv maxim de înregistrări din tabelul B care pot fi corelate cu o singură înregistrare din tabelul A. Dacă o înregistrare din tabelul A poate fi corelată cu minimum o înregistrare din tabelul B, respectiv cu maximum 10 înregistrări din tabelul B, atunci gradul de participare al tabelului B, la respectiva relaţie, este 1,10. (Gradul de participare se notează cu numărul minim în stânga şi numărul maxim în dreapta, separate prin virgulă). Puteţi stabili gradul de participare pentru tabelul A, în acelaşi mod. Puteţi identifica gradul de participare, pentru fiecare tabel al unei relaţii prin determinarea modului de corelare a datelor din fiecare tabel, precum şi a modului de utilizare a datelor respective. Să luă din nou exemplul din figura 2.11, care reprezintă două tabele care se găsesc într-o relaţie unu cu mai mulţi. Dacă se impune (de către conducere) 35

Baze de date

Capitolul 2

ca un cititor (client) să poată împrumuta între 1 şi 4 cărţi, atunci gradul de participare al tabelului IMPRUMUTURI este 1,4. Dacă doriţi să impuneţi ca un cititor să poată împrumuta numai o carte, atunci veţi indica gradul de participare ca fiind 1,1.

Termeni referitori la integritate Specificaţii de câmp O specificaţie de câmp reprezintă toate elementele unui câmp. Fiecare specificaţie de câmp încorporează trei tipuri de elemente: generale, fizice şi logice.  Elementele generale reprezintă informaţiile fundamentale referitoare la câmp şi includ elemente precum numele câmpului, descrierea şi tabelul părinte.  Elementele fizice determină modul de construire a unui câmp şi modul de reprezentare a acestuia pentru persoana care îl utilizează. Această categorie include elemente precum tipul de date, lungimea şi formatul de afişare.  Elementele logice descriu valorile stocate într-un câmp şi includ articole precum valoarea obligatorie, intervalul de valori şi valoarea prestabilită. Aceste specificaţii de câmp o să le completaţi folosindu-vă de nişte formulare, care vor fi descrise în detaliu în capitolul următor. Integritatea datelor Prin integritatea datelor se înţelege validitatea, consecvenţa şi acurateţea datelor incluse într-o bază de date. Nu pot accentua suficient faptul că nivelul de acurateţe al informaţiilor pe care le regăsiţi din baza de date este direct proporţional cu nivelul de integritate al datelor pe care îl impuneţi bazei de date. Integritatea datelor reprezintă unul dintre cele mai importante aspecte ale procesului de proiectare a bazelor de date şi nu vă este permis să-l subestimaţi, să-l treceţi cu vederea şi nici măcar să-l neglijaţi parţial. Trebuie să fiţi conştient de faptul că dacă nu respectaţi regulile de integritate, sunteţi pasibili de a obţine informaţii cu grave erori, care sunt greu de depistat. Gândiţi-vă numai la implicaţiile posibile atunci 36

Baze de date

Capitolul 2

când baza dumneavoastră de date e folosită pentru tranzacţii comerciale sau financiare. Există patru tipuri de integritate a datelor pe care le veţi implementa pe durata procesului de proiectare a bazelor de date. Trei dintre acestea se bazează pe diferite aspecte ale structurii bazei de date şi sunt denumite în conformitate cu zona (nivelul) la care operează. Cel de-al patrulea tip de integritate a datelor se bazează pe modul în care o organizaţie îşi percepe şi îşi utilizează datele. În continuare vor fi prezentate descrierile fiecărui tip de integritate.  Integritatea la nivel de tabel asigură lipsa înregistrărilor duplicate în interiorul tabelului şi faptul că acel câmp care identifică fiecare înregistrare din tabel este unic şi nu are niciodată valoare nulă.  Integritatea la nivel de câmp asigură faptul că structura fiecărui câmp este solidă, că valorile din fiecare câmp sunt valide, consecvente şi precise, precum şi că se asigură o definire consecventă, în întreaga bază de date, a câmpurilor de acelaşi tip (Cod postal, de exemplu).  Integritatea la nivel de relaţie (cunoscută şi sub numele de integritate referenţială) asigură soliditatea relaţiei dintre două tabele, precum şi faptul că înregistrările din tabele sunt sincronizate ori de câte ori se introduc, se actualizează sau se şterg date din oricare dintre cele două tabele.  Reguli de desfăşurare a activităţii impun restricţii sau limitări asupra anumitor aspecte ale bazei de date, pe baza modalităţilor în care o organizaţie îşi percepe şi îşi actualizează datele. Aceste restricţii pot afecta aspecte ale proiectării bazelor de date, precum şi intervalul şi tipurile de valori stocate într-un câmp, tipul şi gradul de participare a fiecărui tabel în cadrul unei relaţii, precum şi tipul de sincronizare utilizat pentru integritatea la nivel de relaţie, în anumite relaţii. Întrebări pentru autoevaluare 1. De ce este importantă terminologia? 2. Care sunt cele patru mari categorii de termeni? 3. Care este diferenţa dintre date şi informaţii? 4. Ce reprezintă valoarea nulă şi de ce este importantă? 37

Baze de date

Capitolul 2

5. Care sunt principalele structuri ale unei baze de date? 6. Denumiţi cele două tipuri de tabele? 7. Ce este o vedere? 8 .Care este diferenţa dintre o cheie şi un index? 9. Care sunt cele trei tipuri de relaţii care pot exista între două tabele? 10. Ce este o specificaţie de câmp? 11. Care sunt cele trei grupe de elemente ale unei specificaţii de câmp? 12. Ce este integritatea datelor? Care sunt tipurile de integritate?

38

Baze de date

Capitolul 3

Capitolul 3. Proiectarea bazelor de date relaţionale Acest capitol va defini paşii prin care trebuie să trecem pentru a proiecta corect o bază de date relaţională. Cunoştinţele dobândite vă vor permite să puteţi proiecta singuri o astfel de bază de date.

Acum când am văzut din ce e formată o bază de date, când cunoaştem şi înţelegem termenii bazelor de date relaţionale, e momentul să trecem la proiectarea acestora. A înţelege cum se proiectează o bază de date relaţională nu este foarte complicat, e cu mult mai simplu decât ne imaginăm. Totuşi, este foarte important să aveţi o idee de ansamblu cu privire la procesul de proiectare a bazelor de date relaţionale, precum şi o imagine generală a etapelor pe care le implică procesul respectiv. Înainte de a implementa o bază e date, aceasta trebuie proiectată, chiar dacă este una mai simplă. De menţionat faptul că indiferent de baza de date proiectată, trebuie parcurşi aceeaşi paşi sau etape. Acestea sunt: Etapa 1 – Definirea unei declaraţii de intenţie şi a obiectivelor misiunii; Etapa 2 – Analiza bazei de date curente; Etapa 3 – Crearea structurilor de date; Etapa 4 – Determinarea şi instituirea relaţiilor între tabele; Etapa 5 – Determinarea şi definirea regulilor de desfăşurare a activităţii; Etapa 6 – Determinarea şi definirea vederilor; Etapa 7 – Verificarea integrităţii datelor.

Trebuie să mai menţionez faptul că întregul proces de proiectare se face fără ajutorul vreunui program, calculatorul este folosit numai la editarea documentelor acestui proces, aşa cum vom vedea mai departe şi la orele de laborator. În continuare se vor detalia etapele de proiectare a unei baze de date relaţionale. 39

Baze de date

Capitolul 3

Etapa 1 – Definirea unei declaraţii de intenţie şi a obiectivelor misiunii Prima fază în procesul de proiectare a bazelor de date constă din definirea unei declaraţii de intenţie şi a obiectivelor misiunii bazei de date. Această declaraţie stabileşte finalitatea bazei de date şi oferă o orientare distinctă pentru activitatea de proiectare. Fiecare bază de date este creată cu un anumit rost, fie pentru rezolvarea unei anumite probleme de afaceri, gestiunea unor tranzacţii zilnice, gestiunea unei magazii, fie pentru a fi utilizată ca parte a unui sistem informaţional. Destinaţia bazei dumneavoastră de date este identificată şi definită într-o declaraţie de intenţie. Aceasta contribuie la asigurarea dezvoltării unei structuri de baze de date adecvate, precum şi identificarea acelor date care duc la atingerea scopului propus. Pe lângă declaraţia de intenţie, în această etapă trebuie definite şi obiectivele misiunii. Obiectivele misiunii sunt declaraţii care reprezintă sarcinile generale pe care utilizatorii le pot îndeplini folosind baza de date. Aceste obiective sprijină şi completează declaraţia de intenţie, determinând în acelaşi timp diferitele aspecte ale structurii bazei de date. Obiectivele misiunii se mai pot numi şi caiet de sarcini, termen încă folosit pentru definirea cerinţelor beneficiarului. Declaraţia de intenţie şi obiectivele misiunii fiind documente foarte importante în proiectarea unei baze de date se pune întrebarea, cine elaborează aceste documente? Declaraţia de intenţie este elaborată de dezvoltatorul bazei de date (Dvs.) împreună cu conducătorul(patronul) firmei şi personalul de conducere care este responsabil de definirea acesteia. Este necesară participarea celor două părţi pentru a se putea ajunge la o exprimare corectă care să fe înţeleasă la fel atât de dezvoltator cât şi de beneficiar, altfel s-ar putea ajunge la situaţii de genul ”nu asta am cerut” sau ”eu altceva am înţeles din această frază”. Obiectivele misiunii sunt elaborate de dezvoltatorul bazei de date (Dvs.) împreună cu personalul de conducere şi utilizatorii finali (cei care vor lucra efectiv cu aplicaţia). Această componenţă este necesară pentru că utilizatorii finali pot avea idei valoroase pentru proiectarea corectă a bazei de date.

40

Baze de date

Capitolul 3

Compunerea unei declaraţii de intenţie O declaraţie de intenţie bună este succintă şi la obiect. Declaraţiile vagi sau ambigui nu fac altceva decât, mai degrabă, să ascundă scopul bazei de date. Iată o declaraţie de intenţie bună: Rolul bazei de date Clienţi/Furnizori este de a ţine la zi situaţiile de plăţi şi încasări, precum şi de a furniza situaţii concrete referitoare la un anume client sau furnizor, într-un anumit interval de timp sau la o anumită dată. Această declaraţie este foarte generală, nu conţine date inutile, este scurtă şi se vede clar la ce va fi folosită: să furnizeze informaţii despre starea unui client sau furnizor, atât de importante în activitatea unei firme. Faceţi analogia dintre o declaraţie de intenţie şi o lumânare cu care traversăm un tunel întunecos, adică lumânarea nu ne dă amănunte despre cum să traversăm tunelul dar ne ghidează spre capătul lui. Iată un exemplu de declaraţie de intenţie formulată defectuos: Rolul bazei de date a firmei SC AZUR SRL constă din a păstra evidenţa aplicaţiilor pentru utilizarea terenurilor, păstrarea datelor cu privire la solicitanţi, păstrarea unei înregistrări a tuturor audierilor, a tuturor deciziilor, a tuturor apelurilor, păstrarea datelor referitoare la angajaţii departamentului şi întreţinerea datelor în vederea utilizării generale în cadrul biroului. Această declaraţie de intenţie are următoarele neajunsuri:  este prolixă, adică nu este succintă şi la obiect;  finalitatea bazei de date nu este clară; este astfel scrisă încât este dificil de identificat finalitatea bazei de date;  descrie numeroase operaţii concrete, care nu-şi au rostul. Cum am putea corecta această declaraţie de intenţie? Iată un exemplu: Rolul bazei de date a firmei SC AZUR SRL constă din a păstrarea datelor utilizate de biroul judecătorului de instrucţie pentru luarea de decizii privind solicitările de utilizare a terenurilor trimise de cetăţenii judeţului X.

41

Baze de date

Capitolul 3

Se observă că finalitatea bazei de date a devenit mult mai clară, s-au eliminat operaţiile şi nu dă impresia că ar fi incompletă. Compunerea unei declaraţii de intenţie presupune din partea dumneavoastră, a dezvoltatorului purtarea de discuţii cu patronul sau managerul societăţii respective, pentru aflarea de informaţii despre aceasta, profilul ei de activitate etc. Deci, prima discuţie cu patronul apoi cu ceilalţi membrii ai conducerii sau alţi specialişti indicaţi de patron. Aţi putea să vă întrebaţi de ce atâta zarvă pentru una sau două fraze pe care le conţine declaraţia de intenţie? Nu uitaţi că declaraţia de intenţie este sinteza unor discuţii, păreri contradictorii, opinii ale mai multor persoane şi că ea trebuie să fie lumina călăuzitoare pentru finalizarea proiectului bazei de date. Cel mai important aspect care trebuie reţinut este acela că declaraţia de intenţie trebuie să fie logică pentru dumneavoastră (dezvoltatorul bazei de date) şi beneficiarii bazei de date. Tipul de declaraţii diferă de la un grup de persoane la altul, iar formularea depinde mult de terminologia specifică domeniului de activitate. Declaraţia dumneavoastră de intenţie este completă atunci când conţine o propoziţie care descrie finalitatea concretă a bazei de date, care este înţeleasă şi aplicată de toate părţile implicate. Definirea obiectivelor misiunii Obiectivele misiunii sunt declaraţii care reprezintă sarcinile generale acceptate de datele păstrate în baza de date. Fiecare obiectiv reprezintă o singură sarcină. Obiectivele misiunii furnizează informaţii pe care le veţi folosi în decursul procesului de proiectare a bazei de date. De exemplu, obiectivele misiunii permit definirea structurii tabelelor, a specificaţiilor de câmp, a caracteristicilor de relaţie şi a vederilor. De asemenea, vă ajută să impuneţi integritatea datelor şi să definiţi regulile de desfăşurare a activităţii. În final, obiectivele misiunii sunt de natură să îndrume demersurile de dezvoltare şi asigură faptul că structura finală a bazei de date permite îndeplinirea declaraţiei de intenţie. Un obiectiv de misiune bine scris reprezintă o propoziţie cu caracter declarativ, care defineşte fără echivoc o sarcină de ordin general şi care este lipsită de detalii inutile. Un obiectiv se exprimă în termeni generali, succint, la obiect şi fără ambiguităţi. Iată câteva exemple de obiective de misiune caracteristice: 42

Baze de date

Capitolul 3

Dorim să păstrăm informaţii complete despre studenţi. Dorim să păstrăm evidenţa tuturor facturilor emise. Dorim să păstrăm evidenţa tuturor recepţiilor. Dorim să ne asigurăm că un agent de vânzări nu răspunde de mai mult de 15 clienţi. Dorim să păstrăm evidenţa tuturor reparaţiilor maşinilor din dotare. Dorim să generăm agende cu numerele de telefon ale angajaţilor.

După cum se observă, obiectivele prezentate sunt foarte clare şi uşor de înţeles. Fiecare obiectiv reprezintă o sarcină unică de ordin general şi defineşte clar sarcina respectivă, fără detalii inutile. De exemplu, ultimul obiectiv de misiune prezentat în lista anterioară indică faptul că se doreşte generarea unor liste cu angajaţi nu şi modul în care vor fi generate. Nu este necesară indicarea modalităţii de generare a listelor de angajaţi, deoarece acest aspect face parte din procesul de dezvoltare a aplicaţiei. De reţinut că finalitatea unui obiectiv de misiune constă din definirea diferitelor structuri din compoziţia bazei de date şi din orientarea direcţiei generale a dezvoltării bazei de date. Dacă un obiectiv de misiune reprezintă mai multe sarcini generale, acesta va trebui descompus în două sau mai multe obiective de misiune. În concluzie, această etapă are ca rezultat un document care ne spune de ce trebuie să proiectăm baza de date (declaraţia de intenţie) şi cam ce probleme rezolvăm cu ea (obiectivele misiunii). Întrebări pentru autoevaluare 1. Ce este o declaraţie de intenţie ? 2. Indicaţi două caracteristici ale unei declaraţii de intenţie bine scrise. 3. Daţi exemple de declaraţii de intenţie. 4. Când se consideră finalizată o declaraţie de intenţie? 5. Ce este un obiectiv de misiune? 6. Indicaţi două caracteristici ale unui obiectiv de misiune bine scris. 7. Daţi exemple de obiective de misiune. 8. Cine concepe declaraţia de intenţie şi obiectivele misiunii? 43

Baze de date

Capitolul 3

Etapa 2 - Analiza bazei de date curente Înainte de a începe proiectarea noii noastre baze de date trebuie să fim conştienţi că nu suntem pe un pământ virgin, că înaintea noastră s-au mai folosit baze de date, s-au manipulat informaţii, aşa că este înţelept să vedem ce există pentru a putea prelua unele informaţii. De multe ori chiar există o bază de date care a fost proiectată după posibilităţile de atunci. Această bază de date poate fi folosită ca resursă pentru noua bază de date. Fiind în etapa 2-a de proiectare, deja ştiţi obiectivele pe care trebuie să le îndeplinească noua bază de date. Pentru vă face o imagine despre organizaţie (firmă) şi informaţiile cu care lucrează, va trebui să răspundeţi la următoarele întrebări:

 Ce tipuri de date foloseşte organizaţia?  Cum foloseşte organizaţia datele respective?  Cum gestionează şi păstrează organizaţia datele respective? Răspunsurile la aceste întrebări, vă oferă informaţii vitale, pe care le puteţi utiliza eficient în proiectarea bazei de date care răspunde cel mai bine cerinţelor organizaţiei. Actorii acestei etape sunt, pe de o parte dezvoltatorul bazei de date (cel care pune întrebări şi prelucrează răspunsurile) şi beneficiarii (cei care răspund la întrebări). Este foarte probabil ca organizaţia să utilizeze un tip sau altul de bază de date care ar putea fi asociată cu una din următoarele categorii: Baze de date pe suport de hârtie – sunt formate din diferite formulare şi documente manuscrise stocate în dosare. Dosarele sunt identificate cu ajutorul unor coduri scrise pe ele, apoi sunt puse în fişete prin intermediul unei scheme de codificare, în funcţie de dimensiunea bazei de date. Aceste baze de date sunt mai dificil de înţeles, de aceea este necesară conlucrarea cu persoane din firmă care lucrează efectiv cu aceste informaţii. Baze de date moştenite – sunt acele baze de date care au existat şi au fost folosite mai mulţi ani. Ele sunt alcătuite din diferite tipuri de structuri de date şi ecrane de interfaţă cu utilizatorul, care se găsesc toate într-un calculator personal. Randamentul, funcţionalitatea şi eficienţa structurilor şi ecranelor sunt extrem de dependente de limbajul de programare şi programele de gestiune a bazelor de date folosit. În general, structurile şi 44

Baze de date

Capitolul 3

ecranele sunt nefinisate conform standardelor moderne, deoarece au fost create atunci când aceste standarde nu existau. Baze de cunoştinţe umane se bazează pe memoria unuia sau mai multor angajaţi din cadrul organizaţiei. Aceste persoane posedă un anumit volum de informaţii (de exemplu date despre clienţi, furnizori sau detalii despre un anumit produs) care sunt foarte importante pentru derularea activităţii organizaţiei respective. Aceste informaţii trebuie interceptate în vederea introducerii lor în baza de date pe care o proiectaţi. Obiectivul analizei dumneavoastră constă în a determina tipul de date pe care le foloseşte organizaţia, modul în care le gestionează şi păstrează, modul în care le vizualizează şi le utilizează. În decursul analizei veţi trece în revistă diferitele moduri în care organizaţia îşi colectează şi prezintă datele, după serii de discuţii purtate cu utilizatorii direcţi şi cu personalul de conducere. Cum se procedează? Informaţiile pe care le-aţi adunat le folosiţi pentru a sintetiza o listă iniţială de câmpuri. Apoi rafinaţi această listă pentru eliminarea câmpurilor duplicate şi a celor calculate şi plasarea acestora din urmă într-o listă separată, care va fi folosită mai târziu în procesul de proiectare. Lista rafinată constituie necesităţile informaţionale ale organizaţiei respective şi furnizează un punct de început pentru proiectarea unei noi baze de date. După cum se ştie, nimic nu este niciodată finalizat, aşa că nici lista noastră de câmpuri, oricât de rafinată ar fi, va fi modificată de multe ori. După ce aţi finalizat lista de câmpuri, trimiteţi-o utilizatorilor şi personalului de conducere, pentru o examinare succintă şi posibile modificări. Încurajaţi opiniile celorlalţi şi luaţi în considerare sugestiile lor de modificare. În concluzie, această etapă se va încheia cu un document care conţine o listă preliminară de câmpuri şi o listă de câmpuri calculate.

Întrebări pentru autoevaluare 1. În ce constă analiza bazei de date curente? 2. Care sunt cele trei surse pe care le analizăm? 3. Care este rolul dezvoltatorului şi al beneficiarului? 45

Baze de date

Capitolul 3

4. Cum se finalizează această etapă?

Etapa 3 - Crearea structurilor de date În această etapă se definesc tabelele cu câmpurile lor, se stabilesc cheile şi se stabilesc specificaţii pentru fiecare câmp. Tabelele sunt primele structuri care se definesc într-o bază de date. Determinarea diferitelor subiecte pe care le vor reprezenta tabelele se execută pe baza obiectivelor misiunii, pe care le-aţi determinat în timpul primei faze a procesului de proiectare şi a necesităţilor de date pe le-aţi adunat pe durata celei de-a doua faze. În principiu, un subiect trebuie să se regăsească într-un tabel, care la rândul său conţine un număr de câmpuri care definesc complet acel subiect. Cum se procedează? Iată paşii care vor trebui parcurşi:  Se face o listă preliminară cu toate tabelele identificate;  Fiecărui tabel i se definesc câmpurile;  Se stabilesc cheile adecvate pentru fiecare tabel, principala grijă fiind aceea ca fiecare tabel să aibă cheie primară corect definită. Această cheie identifică în mod unic fiecare înregistrare din tabel;  Pasul final al acestei etape constă în stabilirea specificaţiilor de câmp aferente fiecărui câmp al bazei de date. După ce au fost parcurşi aceşti paşi se vor purta discuţii cu utilizatorii şi personalul de conducere pentru a verifica încă o dată specificaţiile de câmp stabilite. În această fază pot apare mici modificări, fie la componenţa câmpurilor unui tabel sau la specificaţiile de câmp.

Definirea listei finale de tabele După analizarea listei de tabele şi a discuţiilor cu viitorii utilizatori ai bazei de date pe care o proiectaţi, veţi putea defini o listă finală de tabele. Această listă trebuie să conţină nouă noi elemente şi anume: 46

Baze de date

Capitolul 3

 Tipul tabelului – tabel de date, tabel de legătură, tabel subset sau tabel de validare;  Descrierea tabelului – care cuprinde o definire clară a subiectului reprezentat de tabel şi precizează de ce este important acest subiect pentru organizaţia care utilizează baza de date. Există câteva principii de bază care vă ghidează în descrierea tabelului. În continuare vor fi prezentate câteva principii sau linii directoare legate de numele pe care îl daţi tabelelor şi câmpurilor.

Iată câteva linii directoare care vă vor ajuta să alegeţi numele tabelelor:  Creaţi un nume unic, descriptiv, care să fie semnificativ pentru întreaga organizaţie. Utilizarea numelor unice vă ajută să vă asiguraţi că fiecare tabel reprezintă clar un subiect diferit şi că toată lumea va înţelege ce reprezintă tabelul. Alegeţi nume suficient de descriptive pentru a fi înţelese de la sine. “Întretinere aparate” este un nume bun şi descriptiv.  Creaţi un nume care identifică cu precizie, clar şi fără ambiguităţi subiectul tabelului. Numele vagi sau ambigue indică de obicei faptul că tabelul reprezintă mai mult de un subiect, ceea ce nu este de dorit. Când întâlniţi astfel de nume, identificaţi subiectele reprezentate cu adevărat de tabel, apoi trataţi fiecare subiect ca tabel separat. “Date” este un exemplu de nume de tabel ambiguu, care poate însemna orice fel de date, referitoare la facturi, persoane, aparate, parametri tehnologici etc.  Utilizaţi numărul minim de cuvinte necesar comunicării subiectului tabelului. Orice persoană din organizaţie trebuie să poată înţelege ce reprezintă un tabel, fără a citi descrierea acestuia. Cu toate că obiectivul dumneavoastră este de a crea un nume cât mai scurt, nu este indicat să folosiţi un nume ca de exemplu “TD_1”, care este exagerat de scurt şi generează neclaritate.  Nu folosiţi cuvinte care comunică anumite caracteristici fizice. În numele tabelelor evitaţi folosirea unor cuvinte ca “fisier”, “tabel”, “câmp”, deoarece ele ar putea introduce un grad de confuzie de care nu aveţi nevoie. 47

Baze de date

Capitolul 3

 Nu folosiţi acronime şi abrevieri. Acronimele sunt greu de descifrat, abrevierile rareori reuşesc să comunice subiectul unui tabel, iar împreună încalcă primul principiu prezentat.  Folosiţi forma de plural a numelui. După cum ştiţi, un tabel reprezintă un singur subiect, care poate fi un obiect sau eveniment. Puteţi extinde această definiţie spunând că un tabel reprezintă o colecţie de obiecte sau evenimente similare. Prin urmare, puteţi da nume de tabel de forma “Calculatoare” sau “Consultatii”.  Evitaţi folosirea diacriticelor în numele de tabele. Diacriticele ş, ţ, ă, î, â pot influenţa negativ dezvoltarea aplicaţiilor de bază de date, deoarece unele funcţii ar putea să nu înţeleagă aceste caractere speciale, caracteristice numai limbii române. Pentru descrierea unui tabel ţineţi seamă de următoarele principii:  Includeţi un enunţ care să definească cu exactitate tabelul. Din descrierea tabelului oricine ar trebui să poată determina uşor identitatea acestuia, fără confuzii sau ambiguităţi. Iată o definiţie de tabel căruia îi lipseşte precizia: Furnizori – companii care ne livrează materii prime şi materiale. Ce se întâmplă dacă firma (o brutărie) primeşte ingrediente şi de la fermierii locali, care nu sunt companii? Iată o definiţie corespunzătoare: Furnizori – persoane şi organizaţii care ne livrează materii prime şi materiale. Acest enunţ poate fi utilizat ca definiţie de tabel în descrierea unui tabel.  Includeţi un anunţ care explică de ce acest tabel este important pentru organizaţie. Un tabel conţine date ce sunt adunate, întreţinute, manipulate şi preluate de către organizaţie pentru un anumit motiv. Enunţul trebuie să explice de ce respectivele date sunt importante pentru organizaţie.  Compuneţi o descriere care să fie clară şi succintă. Evitaţi greşeala obişnuită de a enunţa din nou sau reformula numele tabelului în descrierea acestuia, ca în exemplul următor: 48

Baze de date

Capitolul 3

Orar Student – orarul unui student. Evitaţi să fiţi laconic. Prin orar se pot înţelege multe. Descrierea de mai sus nu este de mare folos pentru oricine din organizaţie. Iată un exemplu de descriere, care este destul de lungă şi oferă mai multă informaţie decât e necesar: Orar Student – toate cursurile care vor fi urmate de către un student (inclusiv zile, ore şi titularul de curs) pe parcursul unui an şcolar. Datele din acest tabel sunt importante deoarece permit studentului să cunoască numele, momentul şi locul în care se presupune că se va desfăşura cursul. De asemenea, studentul va cunoaşte atât durata cursului, cât şi numele profesorului care îl predă. Toată această definiţie poate fi reformulată mai clar şi mai succint, astfel: Orar Student – cursurile pe care studentul trebuie să le urmeze în anul şcolar curent. Informaţia oferită de acest tabel ajută studentul la gestionarea timpului iar şcolii să realizeze statistici despre cursuri, studenţi, săli şi profesori. Prima propoziţie din acest tabel oferă definiţia tabelului, iar a doua de ce este important pentru organizaţie (şcoală).  În descrierea tabelului nu includeţi informaţii care ţin de implementare, ca de exemplu modul în care sau locul unde este folosit tabelul. Evitaţi enunţuri care indică modul specific de utilizare a tabelului sau cum îl veţi accesa fizic.  Nu realizaţi o descriere care face trimitere la descrierea unui alt tabel. Fiecare tabel trebuie să aibă o descriere proprie şi independentă de orice altă descriere a unui alt tabel. După ce aţi definitivat lista de tabele, urmează, în mod firesc, ca fiecărui tabel să i se asocieze un număr de câmpuri. Asocierea câmpurilor fiecărui tabel Etapa 2-a s-a finalizat cu o listă de câmpuri. Atribuirea câmpurilor la un tabel este un proces relativ simplu: determinaţi care câmpuri reprezintă cel mai bine caracteristicile subiectului unui tabel şi atribuiţi aceste câmpuri 49

Baze de date

Capitolul 3

respectivului tabel. Repetaţi această procedură pentru toate tabelele din lista finală de tabele. Se poate întâmpla ca un câmp sau un set de câmpuri să fie cerut de mai multe tabele, aceasta este un lucru acceptat. Observaţie importantă!! Sunteţi în faza de proiectare a bazei de date şi nu aveţi nevoie decât de hârtie şi creion pentru a vă face treaba. Când lucraţi la un proiect de baze de date, primul lucru pe care trebuie să-l faceţi este achiziţia unui dosar plic în care să ţineţi toate listele pe care le-aţi scris, schiţele şi notaţiile care se vor aduna. Se va trece la calculator numai după ce aveţi proiectul complet al bazei de date. De altfel, în cadrul acestui curs o să găsiţi un studiu de caz în care se proiectează o bază de date. Începeţi acest proces luând o foaie de hârtie (A4) aşezată culcat (landscape). În partea de sus a foii scrieţi numele fiecărui tabel din lista finală de tabele, având grijă să lăsaţi suficient spaţiu pentru a încape numele câmpurilor pe care le veţi scrie sub ele (figura 3.1).

Studenti Nume Prenume Data nasterii .........

Discipline Denumire Credite Profesor ........

Profesori Nume Prenume Grad didactic ........

.....

Fig. 3.1. Crearea unei foi pentru scrierea structurilor de tabel

Practica spune că în această fază tabelele nu au încă o structură definitivă, de aceea trebuie analizată în continuare această structură, mai ales că avem imaginea de ansamblu a tuturor tabelelor. O primă problemă ar fi verificarea numelor câmpurilor care au primit nume după inspiraţia de moment, de aceea trebuie să dăm nume câmpurilor după nişte criterii sau principii. Iată câteva principii pe care le puteţi folosi pentru crearea numelor de câmpuri:  Creaţi un nume unic, descriptiv, care să aibă sens pentru întreaga organizaţie. Un nume de câmp trebuie să apară o 50

Baze de date

Capitolul 3

singură dată în toată baza de date; singura excepţie de la această regulă apare în cazul în care câmpul serveşte la stabilirea unei relaţii între două tabele. Asiguraţi-vă că numele este suficient de descriptiv pentru a comunica exact înţelesul câmpului pentru oricine îl vede.  Creaţi un nume care să identifice cu precizie, clar şi fără ambiguităţi caracteristica reprezentată de câmp. “Număr de telefon” este un exemplu clasic de nume de câmp ambiguu pentru că nu ştim la ce telefon se referă, la cel de acasă, de la birou sau la telefonul mobil. Învăţaţi să fiţi exact. Acest nume de câmp ar putea să fie foarte exact dacă ar avea numele “Numar telefon acasa” sau “Numar telefon birou”.  Utilizaţi numărul minim de cuvinte necesar comunicării înţelesului caracteristicii reprezentate de câmp. Este bine să evitaţi numele de câmpuri lungi, dar în acelaşi timp ar fi bine să evitaţi utilizarea unui singur cuvânt ca nume de câmp, dacă acel cuvânt este necorespunzător. De exemplu “Angajare” este prea scurt pentru un nume de câmp, iar “Data la care a fost angajata persoana” este mult prea lung! Însă “Data angajarii” este un nume de câmp foarte bun.  Nu folosiţi acronime, iar abrevierile trebuie utilizate judicios. Acronimele pot fi greu de descifrat şi deseori duc la neînţelegeri. Imaginaţi-vă un câmp „CAD-UPM”. Ce aţi înţelege din această denumire? Abrevierile se pot folosi doar dacă îmbunătăţesc numele câmpului, o abreviere nu trebuie să facă ambiguu un nume de câmp.  Utilizaţi forma de singular a numelor. Un câmp cu nume de plural, cum ar fi “Functii”, implică faptul că acel câmp ar putea conţine două sau mai multe valori pentru o înregistrare dată, ceea ce nu e de loc o idee bună. Un nume de câmp este la singular deoarece el reprezintă o singură caracteristică a subiectului tabelului căruia îi aparţine. Ţinând cont de aceste principii, reluaţi fiecare tabel şi vedeţi dacă nu cumva puteţi aduce îmbunătăţiri la vreunul din numele de câmpuri. Mai departe se vor prezenta elementele unui câmp ideal pentru a ne ajuta să rezolvăm anomaliile legate de câmpuri. 51

Baze de date

Capitolul 3

Utilizarea unui câmp ideal pentru rezolvarea anomaliilor Cu toate că în lista preliminară de câmpuri aţi identificat cu atenţie câmpurile, este foarte posibil să fi creat câteva câmpuri ce ar putea pune probleme în structura tabelului. Câmpurile definite neglijent pot duce la apariţia datelor duplicate sau a datelor redundante şi ele pot fi dificil de utilizat. Dacă nu cunoaşteţi semnele de avertizare, vă va fi dificil să vă daţi seama dacă vreunul dintr-un tabel va provoca probleme. Cea mai bună cale de identificare a câmpurilor ce ar putea crea probleme este să determinaţi dacă respectivele câmpuri respectă elementele câmpului ideal. Aceste elemente constituie un set de principii pe care le puteţi utiliza pentru a crea structuri solide de câmpuri şi pentru a depista uşor câmpurile neglijent proiectate. Iată elementele câmpului ideal:  Reprezintă o caracteristică distinctă a subiectului tabelului. După cum ştiţi, un tabel reprezintă un anumit subiect, care poate fi un obiect sau un eveniment. Câmpul ideal reprezintă o caracteristică distinctă a respectivului obiect sau eveniment.  Conţine doar o singură valoare. Un câmp care poate stoca două sau mai multe apariţii ale aceleiaşi valori este cunoscut câmp cu mai multe valori. Câmpul ideal nu conţine decât o singură valoare.  Nu poate fi descompus în elemente mai mici. Un câmp care poate stoca două sau mai multe elemente distincte în interiorul unei valori este cunoscut drept câmp cu mai multe părţi. Similar câmpului cu mai multe valori, acest tip de câmp provoacă probleme atunci când încercaţi să editaţi sau să sortaţi datele din interiorul lui. Aceste probleme nu apar la câmpul ideal deoarece acesta reprezintă o caracteristică unică, distinctă a subiectului tabelului căruia îi aparţine.  Nu conţine o valoare calculată sau concatenată. Valorile câmpurilor dintr-un tabel trebuie să fie independente, adică valoarea unui câmp anumit câmp să nu depindă de valoarea altor câmpuri. Un câmp a cărui valoare depinde de valorile altor câmpuri se numeşte câmp calculat. Un astfel de câmp nu se actualizează automat când se schimbă o valoare a unui câmp implicat, ceea ce devine o responsabilitate nedorită a 52

Baze de date

Capitolul 3

utilizatorului sau programului aplicaţiei de bază de date să actualizeze aceste câmpuri. Din această cauză trebuie să vă ocupaţi separat de câmpurile calculate, în cadrul rapoartelor.  Este unic în interiorul structurii întregii baze de date. Singurele câmpuri duplicate care apar într-o bază de date corect proiectată sunt cele care stabilesc relaţiile dintre tabele. Stabilirea cheilor pentru fiecare tabel Suntem în situaţia în care am creat structurile de tabele, respectând anumite principii care sunt garanţia unui proiect bun. După cum se ştie, fiecare tabel trebuie să aibă o cheie primară. Imediat veţi afla că există tipuri diferite de chei, fiecare dintre acestea având un rol particular în interiorul bazei de date. În timpul acestei etape vor fi atribuite toate cheile, mai puţin una (care o veţi stabili ulterior când stabiliţi relaţiile între tabele). Cheile sunt importante pentru o structură de tabel din următoarele motive:  Cheile ne asigură că fiecare înregistrare dintr-un tabel este identificată cu precizie. După cum se ştie, un tabel reprezintă o colecţie unică de obiecte sau evenimente asemănătoare. Colecţia este compusă din setul complet de înregistrări din interiorul tabelului, iar, în interiorul acestei colecţii, fiecare înregistrare reprezintă o instanţă unică a subiectului tabelului. Aveţi nevoie de un mijloc de identificare cu precizie a fiecărei instanţe, iar o cheie este instrumentul care vă permite să faceţi acest lucru.  Cheile ajută la stabilirea şi impunerea diferitelor tipuri de integritate. Cheile sunt o componentă majoră a integrităţii la nivel de tabel şi a integrităţii la nivel de relaţie. De exemplu, ele vă permit să vă asiguraţi că un tabel are înregistrări unice şi că acele câmpuri pe care le utilizaţi la stabilirea relaţiilor între două tabele conţin întotdeauna valori corespondente.  Cheile servesc la stabilirea relaţiilor între tabele. Asiguraţi-vă întotdeauna că aţi definit chei corespunzătoare pentru fiecare tabel. Pentru stabilirea cheilor pentru fiecare tabel, ne reamintim că există două tipuri principale de chei: chei primare şi chei externe.

53

Baze de date

Capitolul 3

Într-un paragraf anterior (Cap 1/Chei), am văzut că fiecare tabel trebuie să aibă o cheie, altfel nu putem spune că acesta este corect definit. De asemenea, ştim că rolul de cheie poate fi îndeplinit de un anume câmp al tabelului sau o combinaţie de câmpuri. Am spus un anume câmp, deoarece nu orice câmp poate fi cheie într-un tabel, acesta trebuie să îndeplinească anumite condiţii. Iată condiţiile pe care trebuie să le îndeplinească o cheie primară:  Nu poate fi un câmp cu mai multe părţi.  Trebuie să conţină valori unice.  Nu poate conţine valori nule.  Valoare ei nu trebuie să conţină date confidenţiale cum ar fi cod numeric personal, vreun cod de acces etc.  Valoare ei nu poate fi opţională, adică trebuie neapărat introdusă.  Conţine numărul minim de câmpuri necesar definirii unicităţii.  Valorile ei trebuie să identifice în mod unic şi exclusiv fiecare înregistrare din tabel.  Valoarea ei trebuie să identifice exclusiv valoarea fiecărui câmp dintr-o înregistrare dată.  Valoarea ei nu poate fi modificată decât în cazuri rare sau extreme. Cum se procedează efectiv?  Se ia un tabel în care se introduc un eşantion de date.  Se ia pe rând câte un câmp şi se verifică dacă acesta îndeplineşte condiţiile pentru a fi cheie primară, alcătuindu-se o listă care se numeşte lista cheilor candidate.  Dintre cheile candidate se va alege cheia cea mai potrivită (ceva asemănător cu alegerea preşedintelui din lista de candidaţi). Este adevărat că aici, un rol important îl are experienţa dumneavoastră anterioară. Se poate întâmpla ca lista dumneavoastră de chei candidate să fie goală, adică nici un câmp al tabelului nu poate fi cheie primară. În acest caz, se poate utiliza o cheie candidată artificială care nu este altceva decât un câmp introdus forţat, care nu apare în mod “natural” în tabel. Fiind un 54

Baze de date

Capitolul 3

câmp artificial care nu are nici o legătură cu tabelul, putem să-i impunem foarte uşor condiţiile pentru a fi cheie primară. Iată un astfel de caz, prezentat în figura 3.2. Nume piesa schimb Curea ventilator Acumulator Bujie Curea ventilator Maneta viteza Bucsa directie

Model XP-035 TR-78-02

Producator Auto Service SRL ROMBAT SA

GF-25 Dacia

Dacia SA

Pret cu amanuntul 34.75 1250 16.90 29.35 23.85 12.55

Fig. 3.2. Tabel fără cheie candidată

După cum se poate vedea nici un câmp nu îndeplineşte condiţiile de a fi cheie candidată:  Câmpul NUME PIESA SCHIMB nu poate fi ales deoarece ar putea conţine valori duplicat.  Câmpul MODEL nu poate fi ales deoarece ar putea avea valori nule.  Câmpul PRODUCATOR nu poate fi ales pentru că ar putea avea valori nule (lipsă).  Câmpul PRET CU AMANUNTUL nici nu poate fi luat în discuţie. Pentru a rezolva problema, introducem un câmp nou numit NUMAR PIESA SCHIMB, care va deveni cheie primară. În figura 3.3 este prezentat tabelul completat cu câmpul respectiv. Nr piesa schimb 4100 4105 4158 4198 4122 4108

Nume piesa schimb Curea ventilator Acumulator Bujie Curea ventilator Maneta viteza Bucsa directie

Model

Producator

Pret cu amanuntul

XP-035 TR-78-02

Auto Service SRL ROMBAT SA

GF-25 Dacia

Dacia SA

34.75 1250 16.90 29.35 23.85 12.55

Fig. 3.3. Tabel cu cheie candidată artificială

55

Baze de date

Capitolul 3

Din practică pot spune (nu numai eu) că pentru a avea cât mai puţine probleme cu cheile primare, este înţelept să introducem de la început o cheie candidată artificială, imediat ce avem dubii că un anumit câmp vizat ar putea încălca regulile. Pentru aceasta mulţi proiectanţi de baze de date aleg pentru cheia primară un câmp introdus artificial care are un nume compus din literele “ID” şi numele tabelului. Iată câteva sugestii pentru alegerea cheii primare artificiale (figura 3.4):

Nume tabel

Nume cheie artificială

Profesori

ProfesorID

Studenti

StudentID

Discipline

DisciplinaID

Plan de învatanint

PlanInvID Fig. 3.4. Exemple de chei artificiale

În acest moment aţi finalizat o etapă importantă a procesului de proiectare în care aţi definitivat structura tabelelor şi aţi atribuit fiecăruia chei primare. Întrebări pentru autoevaluare 1. Ce este lista finală de tabele? 2. Enunţaţi trei principii pentru crearea numelor de tabel. 3. Enunţaţi două principii pentru compunerea descrierilor de tabel. 4. Cum se atribuie câmpuri tabelelor din lista finală de tabele? 5. Enunţaţi trei principii pentru crearea numelor de câmpuri. 6. Enunţaţi trei elemente ale câmpului ideal. 7. Enunţaţi trei motive pentru care sunt importante cheile. 8. Ce este lista cheilor candidate? 9. Ce este o cheie artificială? Daţi un exemplu. 10. Ce este o cheie primară? 56

Baze de date

Capitolul 3

11. Care sunt elementele unei chei primare? 12. Ce este o cheie externă? Daţi exemple.

Revizuirea structurilor iniţiale de tabel Ca în orice activitate omenească, este bine să ne oprim, să ne evaluăm stadiul în care suntem şi să verificăm dacă suntem pe drumul cel bun. E ca într-o călătorie când din când în când verificăm harta sau întrebăm pe cineva dacă suntem pe traseu bun. Acum avem deja tabelele şi înainte de a merge mai departe vom arunca o privire peste ce am lucrat până acum. Primul lucru de care trebuie să avem grijă este integritatea la nivel de tabel. Acest tip de integritate este o componentă majoră a integrităţii generale a datelor. Verificaţi următoarele aspecte:  Într-un tabel nu există înregistrări duplicat;  Cheia primară identifică exclusiv fiecare înregistrare din tabel;  Orice cheie primară este unică;  Valorile cheilor primare nu sunt nule. Pentru revizuirea structurilor de tabel este bine să staţi de vorbă cu beneficiarul şi împreună veţi îndeplini următoarele sarcini:  Asiguraţi-vă că în baza de date sunt reprezentate toate subiectele. Deşi în această fază de proiectare este puţin probabil să fi uitat vreun de vreun subiect, totuşi acest lucru se poate întâmpla. Dacă se întâmplă, identificaţi subiectul şi transformaţi-l în tabel cu tehnica pe care aţi mai folosit-o.  Asiguraţi-vă că numele de tabele şi descrierile acestora sunt potrivite şi semnificative pentru toată lumea. Dacă un nume sau o descriere pare a fi ambiguă pentru mai multe persoane, lucraţi cu aceste persoane pentru clarificarea lucrurilor.  Asiguraţi-vă că numele de câmpuri sunt potrivite şi semnificative pentru toată lumea. Alegerea numelor de câmpuri generează de 57

Baze de date

Capitolul 3

obicei multe discuţii, care vor duce în final la armonizarea acestora.  Verificaţi dacă la fiecare tabel au fost atribuite toate câmpurile corespunzătoare. Acum aveţi cea mai bună oportunitate de a vă asigura că toate caracteristicile necesare, referitoare la subiectul unui tabel se găsesc la locul lor. Nu este neobişnuit să descoperiţi că aţi uitat una sau două caracteristici. Dacă s-a întâmplat, identificaţi respectivele caracteristici şi transformaţi-le în câmpuri adăugate tabelului. După ce aţi terminat consultările cu viitorii beneficiari ai bazei de date, treceţi la pasul următor, în care veţi stabili specificaţii de câmp pentru fiecare câmp din baza de date. Specificaţii de câmp Câmpurile sunt fundaţia bazei de date, ele reprezentând caracteristicile subiectelor importante pentru o organizaţie. Câmpurile stochează date vitale pentru organizaţia respectivă, de care depind atât succesul cât şi dezvoltarea sa ulterioară. Deşi au o importanţă aşa de mare, paradoxal, câmpurilor din baza de date li se acordă cea mai mică importanţă, se pierde cel mai puţin timp pentru asigurarea integrităţii lor structurale şi logice. Se consideră că se pierde prea mult timp pentru a stabili integritatea datelor, dar se pierde timp înzecit pentru repararea bazelor de date prost proiectate. În acest paragraf veţi învăţa cum să stabiliţi integritatea datelor prin definirea specificaţiilor de câmp pentru fiecare câmp al bazei de date. Timpul folosit pentru stabilirea acestor specificaţii nu este un timp pierdut ci un timp câştigat, dacă ne referim la necazurile apărute datorită datelor inconsecvente şi eronate, a căror consecinţe negative sunt greu de estimat. Există mai multe motive pentru care specificaţiile de câmp sunt importante:  Specificaţiile de câmp vă ajută să stabiliţi şi să impuneţi integritatea la nivel de câmp. Implementarea acestor specificaţii vă permite să garantaţi că datele din fiecare câmp sunt consecvente şi valide. 58

Baze de date

Capitolul 3

 Definirea specificaţiilor de câmp pentru fiecare îmbunătăţeşte integritatea generală a datelor. Nu uitaţi că integritatea la nivel de câmp este una din cele patru componente ale integrităţii generale a datelor.  Definirea specificaţiilor de câmp vă obligă să ajungeţi la o înţelegere totală a naturii şi scopului datelor din baza de date. Înţelegerea datelor înseamnă că puteţi hotărî dacă anumite date sunt cu adevărat necesare şi importante pentru organizaţie şi puteţi învăţa cum să le utilizaţi în avantajul dumneavoastră.  Specificaţiile de câmp constituie „dicţionarul de date” al bazei de date. Fiecare specificaţie de câmp stochează date despre caracteristicile unui câmp dintr-o bază de date. Acest dicţionar de date este util, în special la implementarea bazei de date într-un program SGBDR – îl puteţi folosi drept ghid pentru crearea câmpurilor şi stabilirea proprietăţilor fundamentale. De asemenea, aceste specificaţii vă ajută să stabiliţi ce tip de proceduri de introducere şi validare a datelor trebuie să implementaţi în orice tip de aplicaţie de interfaţă cu utilizatorul pe care o creaţi pentru baza de date. Trebuie să aveţi în vedere faptul că nivelurile de consecvenţă, calitate şi acurateţe a datelor din baza de date (respectiv a informaţiei scoase din aceste date) sunt direct proporţionale cu gradul de completare a acestor specificaţii. Un câmp atinge integritatea la nivel de câmp după ce aţi definit un set complet de specificaţii de câmp pentru respectivul câmp. Integritatea la nivel de câmp asigură următoarele:  Identitatea şi scopul unui câmp sunt clare şi toate tabelele în care apare respectivul câmp sunt identificate corect;  Definiţiile câmpurilor sunt consecvente în întreaga bază de date;  Valorile unui câmp sunt consecvente şi valide;  Tipurile de modificări, comparaţiile şi operaţiile ce pot fi aplicate valorilor din câmp sunt clar identificate. În continuare vor fi prezentate toate informaţiile de care aveţi nevoie pentru a putea completa o specificaţie de câmp. 59

Baze de date

Capitolul 3

Anatomia unei specificaţii de câmp

O specificaţie de câmp încorporează diferite elemente care definesc atributele unui câmp. Elementele dintr-o specificaţie sunt împărţite în categoriile:  Elemente generale  Elemente fizice  Elemente logice Practic, scrierea specificaţiilor pentru fiecare câmp se face într-un formular, aşa cum se vede în figura 3.5. Deşi pare un document birocratic, nu este de loc aşa, deoarece este foarte util, mai ales în faza de implementare când nu mai trebuie să analizăm fiecare câmp în parte, ci consultăm numai dosarul. Se observă clar cele trei grupe de specificaţii, fiecare cu specificaţiile sale. Variantele pe care le puteţi alege, acolo unde e cazul, sunt puse într-un dreptunghi, ceea ce face ca formularul să aibă claritate. Toţi parametrii care apar în formularul cu specificaţiile de câmp vor fi explicate tabelar, ceea ce ne ajută să găsim relativ uşor explicaţiile despre o specificaţie pe care am uitat-o.

60

Baze de date

Capitolul 3 Specificaţii de câmp

Elemente generale Nume câmp: StatComer Tip specificaţie: □ Unică □ Generică □ Copie Tabel părinte: Comercianti Specificaţie sursă: Stat Eticheta: Stat Partajat de: Alias(-uri): Descriere: Statul in care se afla cartierul general al producatorului.Aceasta informatie este o componenta a adresei postale generale a producatorului.

Elemente fizice Tip de date:Alfanumeric Lungime : 2

Suport caractere:

□ Litere(A-Z) □ Cifre (0-9)

Numar de cifre zecimale:

□ De pe tastatura (., /, $, #, %) □ Speciale (©, ®, ™, ∞)

Masca de introducere: AA Format de afisare: Ambele litere trebuie sa fie majuscule. Elemente logice Tip cheie:

Structură cheie: Unicitate: Suport valori nule:

□ Non-Cheie □ Externă □ Simplă □ Non-unică □ Se acceptă

Reguli de editare: □ Primară Se introduce imediat, □ Alternativă □ permite editarea □ Compusă □ Se introduce imediat, nu permite editarea □ Unică □ Se introduce ulterior,

□ Nu se acceptă

valori nule Valori introduse de: Valoare obligatore:

valori nule

□ Utilizator □ Nu

Valoare prestabilită:

WA

Interval de valori:

CA, ID, MT, OR, WA

se se

permite editarea

□

□ Sistem □ Da

se

□

Se introduce ulterior, nu se permite editarea Reguli nedeterminate în acest moment

Comparaţii permise:

□Acelaşi câmp □ Toate □Alt câmp □ Toate □Valoare de expresie □ Toate

□= □= □=

□> □> □>

□ >= □ >= □ >=

□≠ □≠ □≠

□< □< □<

□+ □+ □+

□□□-

□x □x □x

□÷ □÷ □÷

□ □ □

□ <= □ <= □ <=

Operatii premise:

□ Acelaşi câmp □ Toate □ Alt câmp □ Toate □ Valoare de expresie □ Toate

Fig. 3.5. Formular 61 Specificaţie câmp

Concatenare Concatenare Concatenare

Baze de date

Capitolul 3

Elementele generale reprezintă atributele fundamentale ale câmpului. Ele oferă informaţii despre scopul câmpului, numele tabelului în care apare câmpul etc. În tabelul 3.1 sunt prezentate aceste elemente generale. Tab. 3.1. Elemente generale Denumire element Nume de câmp Tabel părinte

Eticheta

Partajat de

Alias(-uri)

Descriere

Tip specificaţie

Explicaţii Un număr minim de cuvinte care identifică în mod unic un anumit câmp în întreaga bază de date. Tabelul care conţine în structura sa câmpul respectiv. Acesta este singurul tabel în care va apărea câmpul, cu excepţia cazului în care câmpul participă la stabilirea unei relaţii. Este un nume alternativ (de obicei, o formă scurtă a numelui câmpului) prin care puteţi identifica respectivul câmp în interfaţa aplicaţiei cu utilizatorul final pe care o creaţi pentru baza de date. De exemplu, câmpul PRET UNITAR poate avea ca etichetă PU sau PUNIT. Etichetele sunt utile, în special, când dorim să economisim spaţiu, sau să „înghesuim” cât mai multe câmpuri într-un raport. Indică numele celorlalte tabele (dacă există) care conţin câmpul respectiv. Singurele nume de tabel care trebuie să apară aici sunt cele care au o relaţie explicită cu tabelul părinte al câmpului. Este un nume pe care îl utilizaţi pentru acel câmp, în situaţii extrem de rare. Una din situaţiile în care trebuie să utilizaţi un alias este când în acelaşi tabel trebuie să existe două apariţii ale câmpului. Aceasta este o explicaţie completă a câmpului. Compunerea unei descrieri de câmp este extrem de benefică deoarece vă obligă să vă gândiţi cu atenţie la natura datelor care vor fi stocate în câmpul respectiv. Dacă aveţi dificultăţi în descrierea unui câmp, puteţi fi sigur că acel câmp necesită îmbunătăţiri suplimentare. Elementele pe care le stabiliţi pentru un câmp dat depind de tipul de specificaţie pe care îl definiţi pentru acel câmp. O specificaţie poate fi definită în 3 moduri:  Unică – este specificaţia prestabilită pentru toate câmpurile, excepţia celor care servesc ca şablon pentru alte câmpuri sau a celor care participă drept chei externe într-o relaţie între tabele. În acest tip de specificaţie puteţi include toate elementele, mai puţin specificaţia sursă, iar parametrii de element pe care îi precizaţi se vor aplica doar asupra câmpului indicat elementul Nume câmp.  Generică – această specificaţie serveşte ca şablon pentru alte specificaţii de câmp şi vă ajută să asiguraţi definiţii consecvente pentru câmpurile care au acelaşi înţeles general. De exemplu, puteţi crea acest tip de specificaţie pentru un câmp generic numit JUDET, pe care să o utilizaţi apoi ca bază pentru orice alt câmp JUDET din baza de date, cum ar fi JUDET_CLIENT, JUDET_ANGAJAT, JUDET_FURNIZOR.  Copie – este specificaţia prestabilită pentru un câmp bazat pe

62

Baze de date

Specificaţie sursă

Capitolul 3 un câmp generic sau pentru un câmp care joacă rol de cheie externă într-o relaţie între tabele şi ea preia majoritatea parametrilor de element dintr-o specificaţie existentă. Puteţi include elementele care nu sunt încorporate în specificaţia sursă şi puteţi altera orice parametri de element preluaţi din specificaţia sursă. Acest element este precizat doar într-o specificaţie copie şi indică numele specificaţiei unui anumit câmp pe care se bazează specificaţia curentă.

Elementele fizice se referă la structura unui câmp. Ele sunt exprimate în termeni generali, deoarece fiecare program SGBDR le implementează întrun mod uşor diferit. Stabilirea acestor elemente în timpul acestei faze a procesului de proiectare vă ajută să asiguraţi definiţii consecvente ale câmpurilor în întreaga bază de date şi reduce timpul necesar implementărilor structurilor de câmp într-un program SGBDR. În tabelul 3.2 sunt prezentate aceste elemente. Tab. 3.2. Elemente fizice Tip de date

Lungime Număr de zecimale Mască de

Acest element indică natura datelor stocate de câmp. Standardul SQL defineşte câteva tipuri majore de date şi fiecare tip de date are una sau mai multe variante unice. Iată o scurtă definire a lor:  Character – acest tip de dată stochează un şir alfanumeric de lungime fixă sau variabilă.  Bit – acest tip de date stochează şiruri cu secvenţe binare, cum ar fi imagini digitizate sau secvenţe audio.  Exact Numeric – stochează numere întregi sau zecimale. Majoritatea programelor SGBDR implementează acest tip sub numele de NUMERIC, ZECIMAL şi INTEGER.  Approximate Numeric – stochează numere cu zecimale şi numere exponenţiale. Majoritatea programelor SGBDR implementează acest tip sub numele de FLOAT, REAL şi DOUBLE.  Date/Time – stochează date calendaristice, de timp şi combinaţia lor. De menţionat faptul că acest tip de dată diferă destul de mult de la un SGBDR la altul. Va trebui să studiaţi documentaţia SGBDR pentru a afla cum gestionează programul datele şi orele.  Boolean – se foloseşte pentru valorile TRUE şi FALSE.  Currency – se foloseşte pentru indicarea monedei. Precizează numărul total de caractere ce pot fi introduse de un utilizator pentru o valoare oarecare de câmp. Se foloseşte numai pentru datele de tip Character. Precizează numărul de zecimale ale unui număr. Precizează modul în care utilizatorul trebuie să introducă data

63

Baze de date introducere

Format de afişare

Suport caractere

de

Capitolul 3 calen-daristică în câmp. Există mai multe moduri de introducere a unei date calendaristice, cum ar fi „01/03/05”, „01-03-05” şi „01mar-2005”. Utilizarea unei măşti de introducere vă ajută să vă asiguraţi că un utilizator va introduce valorile în câmp în mod unitar. Iată un exemplu de introducere a unei măşti: „zz/ll/aa”, pentru o dată de forma „01/03/05”. Acest element gestionează aspectul valorii câmpului atunci când este afişată pe ecran sau este tipărită într-un raport. Un format de afişare vă permite să afişaţi valorile într-un mod mai firesc, mai lizibil, ca de exemplu „18/04/05” ar putea fi afişat „18 aprilie 2005” care este mult mai uşor de citit şi înţeles. Acest element indică tipul de caractere pe care un utilizator le poate introduce într-o valoare de câmp dată. Stabilirea şi impunerea acestui element vă ajută să vă asiguraţi că utilizatorul nu poate introduce în câmp date lipsite de sens, iar prin acest lucru îmbunătăţiţi integritatea la nivel de câmp. Puteţi opta pentru includerea sau excluderea oricăruia dintre următoarele tipuri de caractere:  Litere – toate literele alfabetului inclusiv cele speciale ş, ţ, ă, î.  Cifre – de la 0 la 9.  Caractere de pe tastatură - &, ^, =, virgula, !, (, ), %, $ etc.  Caractere speciale – orice caracter pe care îl puteţi produce prin combinaţii specifice de taste standard şi tastele Ctrl, Alt şi Shift.

Elementele logice – se referă în special la valorile din interiorul unui câmp. Elementele ei stabilesc lucruri cum ar fi unicitatea unei valori, când trebuie introdusă o valoare, dacă o valoare poate fi editată sau nu, tipurile de comparaţii şi operaţii ce pot fi efectuate cu fiecare valoare. Precizarea acestor elemente vă ajută să stabiliţi şi să impuneţi mare parte din integritatea la nivel de câmp. În tabelul 3.3 sunt prezentate aceste elemente. Tab. 3.3. Elemente logice Denumire element Tip cheie Structură cheie

Unicitate

Suport valori nule

Explicaţii Acest element indică rolul câmpului într-un tabel, rol pe care l-aţi identificat când aţi stabilit cheia primară pentru tabel. Acest element precizează dacă un câmp desemnat cheie primară este o cheie primară simplă (un singur câmp) sau o cheie primară compusă (cu mai multe câmpuri). Acest element precizează dacă valorile câmpului sunt unice. Îi atribuiţi valoare „Unică” atunci când elementul Tip cheie are valoarea „Primară”; în caz contrar acest element primeşte valoarea „Non-unică”. Acest element precizează dacă un câmp acceptă sau nu valori nule. Recitiţi paragraful Valoare nulă din capitolul 1 pentru a vă reaminti ce sunt valorile nule. Pentru a verifica decizia luată, gân-

64

Baze de date

Valori introduse de

Valoare obligatorie Valoare prestabilită Interval de valori

Reguli de editare

Comparaţii permise

Operaţii permise

Capitolul 3 diţi-vă ce urmări ar avea necompletarea acelui câmp (valoare nulă). Utilizaţi judicios valorile nule şi nu folosiţi spaţii goale. Acest element indică sursa valorilor câmpului. Această sursă poate fi un operator, fie programul de aplicaţie al bazei de date care îl completează automat. Acest element precizează dacă utilizatorul este obligat să introducă o valoare pentru câmpul respectiv. Aceasta este valoare pe care utilizatorul o poate introduce într-un câmp atunci când nu este disponibilă o valoare mai bună şi când nu sunt permise valorile nule. Acest element precizează toate posibilele valori valide pentru un câmp. Acest lucru se poate face prin mai multe căi, ca de exemplu cu un interval (1-999) sau cu ajutorul unei liste (CJ, MS, BN, AB). Acest element precizează în ce moment utilizatorul poate introduce o valoare într-un câmp şi dacă poate modifica respectiva valoare. Momentul de referinţă este momentul când se creează o nouă înregistrare. Acest element indică tipurile de comparaţii pe care utilizatorul le poate aplica asupra unei valori de câmp date, atunci când preia informaţie din câmp. Există 6 tipuri de comparaţii, =, diferit de, >, <, >=, <=, aşa cum se poate observa din formular. De asemenea, se indică dacă un utilizator poate compara o valoare de câmp dată cu una din următoarele:  Altă valoare din acelaşi câmp.  Valoarea unui alt câmp din tabelul părinte sau dintr-un alt tabel al bazei de date.  O valoare de expresie, care este o operaţie oarecare în care este inclusă valoarea câmpului. Controlul asupra tipului de comparaţii îl împiedică pe utilizator să facă anumite comparaţii lipsite de sens. Acest element precizează tipurile de operaţii pe care utilizatorul le poate efectua cu valorile unui câmp. Există 5 tipuri de operaţii: adunare, scădere, înmulţire, împărţire şi concatenare. De asemenea, acest element indică dacă o operaţie poate include vreuna din următoarele:  Altă valoare din acelaşi câmp.  Valoarea unui alt câmp din tabelul părinte sau dintr-un alt tabel al bazei de date.  Rezultatul unei expresii în care este implicată valoarea câmpului. Controlul asupra tipului de operaţii previne efectuarea unor operaţii fără sens, limitând tipurile de operaţii care se pot face cu valorile unui câmp.

Această fază este o mare consumatoare de timp, de aceea tentaţia de a „economisi” timp este foarte mare, ceea ce este o mare greşeală. Timpul 65

Baze de date

Capitolul 3

astfel economisit este iluzoriu, deoarece pierderile cu repararea mai târziu a bazei de date va fi înzecit. Acordaţi acestei faze importanţa cuvenită, altfel tot efortul dumneavoastră de până acum va fi zadarnic.

Întrebări pentru autoevaluare 1. Enunţaţi două motive majore pentru care sunt importante specificaţiile de câmp. 2. Ce câştigaţi prin stabilirea integrităţii la nivel de câmp? 3. Care sunt cele trei categorii de elemente dintr-o specificaţie de câmp? 4. Numiţi trei tipuri de specificaţii. 5. Ce indică elementul Tip de date? 6. Ce indică elementul Suport de caractere? 7. Care este scopul elementului Format de afişare? 8. Care este semnificaţia elementului Interval de valori? 9. Care este scopul unei reguli de editare? 10. Care este scopul elementului Comparaţii permise? Cine îl foloseşte efectiv? 11. Ce este o valoare de expresie? 12. Când se utilizează o specificaţie generică? Daţi un exemplu. 13. Explicaţi formularul de specificaţii.

66

Baze de date

Capitolul 3

Etapa 4 - Determinarea şi instituirea relaţiilor între tabele Suntem în faza în care avem tabelele definitivate, completate cu câmpurile lor bine definite şi cu cheile lor primare. Sarcina noastră următoare este de a stabili relaţiile existente între aceste tabele. Ne reamintim că între două tabele poate exista NUMAI o relaţie. De asemenea, un tabel poate avea relaţii cu mai multe tabele, aşa cum să vedem în studiile de caz viitoare. În capitolul 2, la paragraful Termeni referitori la relaţie au fost prezentate pe scurt cele trei tipuri de relaţii care pot exista între două tabele. Vă recomand să revedeţi acel paragraf pentru a vă reîmprospăta memoria. În această etapă veţi învăţa cum să identificaţi şi să stabiliţi relaţii între tabelele unei baze de date şi apoi cum să stabiliţi caracteristicile fiecărei relaţii. De asemenea, veţi învăţa cum să creaţi diagrame cu tabele şi relaţii, lucru care vă va permite să realizaţi o reprezentare grafică a structurii întregii baze de date. Despre importanţa relaţiilor nu mai trebuie să vorbim, decât că ele sunt capitale pentru funcţionarea corectă a bazei de date. Ele asigură conexiuni între tabelele corelate logic, ajută la îmbunătăţirea structurilor de tabel şi permit extragerea datelor din mai multe tabele simultan. În continuare vor fi prezentate pe larg cele trei tipuri de relaţii cunoscute. Stabilirea relaţiilor “unu cu unu” Două tabele au o relaţie unu cu unu când o singură înregistrare din primul tabel este corelată cu o singură înregistrare din al doilea tabel şi o singură înregistrare din al doilea tabel este corelată cu o singură înregistrare din primul tabel. Figura 3.6 prezintă un exemplu generic de relaţie „unu cu unu”. Tabel A

Tabel B

Fig. 3.6. Exemplu generic de relaţie „unu la unu”

67

Baze de date

Capitolul 3

După puteţi vedea, o înregistrare din TABELUL A este corelată cu o singură înregistrare din TABELUL B, iar o înregistrare din TABELUL B este corelată cu o singură înregistrare din TABELUL A. O relaţie unu cu unu implică de obicei un tabel subset. Figura 3.7 prezintă un exemplu de relaţie „unu cu unu” tipică pe care o puteţi găsi într-o bază de date pentru departamentul Personal al unei organizaţii. Angajati SalariatID 100 101 102 103

Nume Ban Pop Lazăr Crişan

Prenume Ioan Dorin Liviu Ovidiu

Telefon 0745-646321 0723-548211 0264-542138 0740-764282

<> ….. ….. ….. …..

Retributii SalariatID 100 101 102 103

Salar orar 34.50 23.00 17.45 16.00

Sporuri 10% 5% 20% 18%

<> ….. ….. ….. …..

Fig. 3.7. Exemplu de relaţie „unu la unu”

Deşi câmpurile din aceste tabele pot fi combinate într-un singur tabel, proiectantul bazei de date a ales să plaseze în tabelul ANGAJATI câmpurile ce pot fi văzute de orice membru al organizaţiei şi în tabelul RETRIBUTII câmpurile ce pot fi văzute doar de personalul autorizat. Pentru stocarea datelor privitoare la retribuţia unui angajat dat este necesară doar o singură înregistrare, deci între o înregistrare din tabelul ANGAJATI şi una din tabelul RETRIBUTII există o relaţie distinctă „unu cu unu”. Figura 3.8 prezintă un exemplu generic al modului în care se creează o diagramă de relaţie pentru o relaţie “unu la unu”.

68

Baze de date

Capitolul 3

Această linie arată că o înregistrare din TABELUL B este corelată cu o singură înregistrare din TABELUL A

Această linie arată că o înregistrare din TABELUL A este corelată cu o singură înregistrare din TABELUL B

Tabel B

Tabel A

Tabel normal

Tabel subset

Fig. 3.8. Realizarea unei diagrame generice pentru o relaţie „unu la unu”

Observaţi că tabelul din stânga este un tabel normal (simbolizat printr-un dreptunghi), iar cel din dreapta este un tabel subset (simbolizat printr-un dreptunghi cu colţurile rotunjite). Linia care apare între tabelele din diagramă indică tipul de relaţie şi pentru fiecare tip de relaţie veţi utiliza un anumit tip de linie. Aici fiecare capăt are o „liniuţă” pentru relaţia “unu la unu”. Această linie arată o Observaţi că tabelul dincăstânga este un tabel normal (simbolizat printr-un înregistrare din TABELUL dreptunghi), iar cel din dreapta B este un tabel subset (simbolizat printr-un este corelată cu o singură dreptunghi cu colţurile rotunjite). Linia care apare între tabelele din înregistrare din TABELUL diagramă indică tipul de relaţie şi pentru fiecare tip de relaţie veţi utiliza un A tip de linie. Aici fiecare capăt are o „liniuţă” pentru relaţia “unu la anumit unu”. În figura 3.9 este prezentată diagrama relaţiei dintre tabelele ANGAJATI şi RETRIBUTII.

Angajati

Retributii

Nume tabel

Fig. 3.9. Diagrama relaţiei dintre tabelele SALARIATI şi SALARIU

Nume tabel

69

Nume tabel

Baze de date

Capitolul 3

Observaţi că cele două tabele sunt simbolizate diferit, un dreptunghi şi un dreptunghi cu colţurile rotunjite, primul fiind considerat tabel de date iar al doilea este considerat tabel subset. Stabilirea relaţiilor “unu cu mai mulţi” Între două tabele există o relaţie “unu cu mai mulţi” când o înregistrare din primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea tabel, în timp ce o înregistrare din al doilea tabel poate fi corelată cu o singură înregistrare din primul tabel. Să studiem un exemplu generic pentru acest tip de relaţie. Să presupunem că lucraţi cu două tabele TABEL A şi TABEL B, între care există o relaţie „unu cu mai mulţi”. Datorită relaţiei, o înregistrare din TABEL A poate fi corelată cu una sau mai multe înregistrări din TABEL B. De asemenea, în sens invers, o înregistrare din TABEL B poate fi corelată cu singură înregistrare din TABEL A Figura 3.10 prezintă acest tip de relaţie.

Tabel A

Tabel B

Tabel A

Tabel B

Fig. 3.10. Exemplu generic de relaţie „unu cu mai mulţi”

70

Baze de date

Capitolul 3

Relaţia “unu cu mai mulţi” este cea mai obişnuită relaţie care există între două tabele dintr-o bază de date şi este cea mai uşor de identificat. Relaţia este extrem de importantă din punct de vedere al integrităţii datelor, deoarece ea vă ajută să eliminaţi datele duplicate. Figura 3.11 prezintă un exemplu obişnuit de relaţie “unu cu mai mulţi” pe care o puteţi întâlni la o secţie de împrumut a unei biblioteci. Imprumuturi Clienti ClientID 9001 9002 9003 9004 9005

Nume Pop Ban Lazăr Buzan Beldean

Prenume Dorin Ion Ana Maria Vian

<> ....... ....... ....... ....... .......

ClientID 9002 9001 9004 9003 9003 9003 9002 9005 9005

CarteID 5648 690423 6563 65323 09542 64823 75001 10045 76100

Data .... .... .... .... .... .... .... .... ....

Fig. 3.11. Exemplu de relaţie „unu cu mai mulţi”

Un client al bibliotecii poate împrumuta oricâte cărţi, deci o înregistrare din tabelul CLIENTI poate fi corelată cu una sau mai multe înregistrări din tabelul ÎMPRUMUTURI. Însă o carte este asociată, în orice moment, doar cu un singur client, deci o înregistrare din tabelul ÎMPRUMUTURI este corelată doar cu o singură înregistrare din tabelul CLIENTI. Evident, am introdus o ipoteză, cum că o carte se găseşte într-un singur exemplar. În figura 3.12 este prezentat un exemplu generic pentru modul de creare a diagramei de relaţie „unu cu mai mulţi”.

71

Baze de date

Capitolul 3 Această linie arată că o înregistrare din TABELUL B este corelată cu o singură înregistrare din TABELUL A

Tabel A

Tabel B

Nume tabel Această „labă de gâscă” arată că o Nume tabel înregistrare din TABELUL A este corelată cu mai multe înregistrări din TABELUL B

Fig. 3.12. Realizarea diagramei pentru o relaţie „unu cu mai mulţi”

Nume tabel

Observaţi că simbolul „labă de gâscă” este întotdeauna localizat în dreptul tabelului din partea „mulţi” a relaţiei. Figura 3.13 prezintă diagrama relaţiei dintre Această tabelelelinie CLIENTI arată că şi o ÎMPRUMUTURI din figura 3.11. Reţineţi acesteînregistrare notaţii pentru că le veţi Bfolosi în prezentarea structurii din TABELUL Nume tabel bazelor de date pe care le veţi proiecta. este corelată cu o singură înregistrare din TABELUL A Imprumuturi Imprumuturi

Clienti

Nume tabelDiagrama relaţiei dintre tabelele Clienti Numeşitabel Fig. 3.13. Imprumuturi Acest tip de relaţie cel mai reprezentativ dintre două tabele a unei baze de Nume date, este uşor de identificat şi de înţeles. tabel(B) Nume tabel

Nume tabel Nume tabel Nume tabel(A)

72 Această linie arată că o

Baze de date

Capitolul 3

Stabilirea relaţiilor ”mai mulţi cu mai mulţi” Între două tabele există o relaţie de “mai mulţi cu mai mulţi” când o înregistrare din primul tabel poate fi corelată cu una sau mai multe înregistrări din al doilea tabel şi o înregistrare din al doilea tabel poate fi corelată cu una sau mai multe înregistrări din primul tabel. Să presupunem că lucraţi cu două tabele, TABEL A şi TABEL B şi între ele există o relaţie de “mai mulţi cu mai mulţi”. Datorită relaţiei, o înregistrare TABEL A poate fi corelată cu una sau mai multe înregistrări din TABEL B şi o înregistrare din TABEL B poate fi corelată cu una sau mai multe înregistrări din TABEL A, aşa cum se poate vedea în figura 3.14. Tabel A

Tabel B

Tabel A

Tabel B

Tabel A

Tabel B

Tabel A Tabel A

Tabel B Tabel B

Fig. 3.14. O relaţie „mai mulţi cu mai mulţi” din perspectiva ambelor tabele

Tabel A Tabel B Tabel A Tabel B între două tabele Acest tip de relaţie este al doilea ca frecvenţă de apariţie dintr-o bază de date. Ea este ceva mai dificil de identificat decât o relaţie „unu cu mai mulţi”, deci trebuie să vă asiguraţi că aţi examinat tabelele cu atenţie. Tabel A Tabel B Tabel A Figura 3.15 prezintă un exemplu tipic de relaţie “maiB mulţi cu mai mulţi” Tabel pe care o puteţi întâlni în baza de date a unei instituţii de învăţământ, respectiv tabelul cu studenţii şi tabelul cu toate cursurile care se ţin în acea universitate. Tabel A Tabel B Tabel A Tabel B 73 Tabel A

Tabel B

Baze de date Studenti StudentID 6001 6002 6003 6004 6005

Capitolul 3 Nume Pop Szabo Costea Timocea Mocean

Prenume Remus Zoltan Florian Sebastian Vasile

<> .....

OrasStudent Reghin Oradea Zalau Brasov Fagaras

..... ..... ..... .....

Cursuri CursID C001 C213 C032 C015 G001 G004 G007

Denumire PUC Baze de date SIM GD AutoCAD Inventor IntelliCAD

Credite 5 5 4 5 4 5 5

ProfesorID 2001 2001 2045 2014 2009 2006 2032

Sala 208 208 208 207 207 209 209

<> ..... ..... ..... ..... ..... ..... .....

Fig. 3.15. Exemplu tipic de relaţie „mai mulţi cu mai mulţi”

Pe parcursul unui an şcolar, un student poate participa la unul sau mai multe cursuri, deci o înregistrare din tabelul STUDENTI poate fi corelată cu una sau mai multe înregistrări din tabelul CURSURI. În sens invers, la un curs pot participa unul sau mai mulţi studenţi, deci o înregistrare din tabelul CURSURI poate fi corelată cu una sau mai multe înregistrări din tabelul STUDENTI. Figura 3.16 prezintă un exemplu generic al modului de creare a diagramei de relaţie “mai mulţi cu mai mulţi”. În acest caz, lângă fiecare tabel există un simbol “labă de gâscă”. Figura 3.17 prezintă diagrama relaţiei dintre tabelele STUDENTI şi CURSURI din figura 3.15.

74

Baze de date

Capitolul 3

Această „labă de gâscă” arată că o înregistrare din TABELUL B este corelată cu mai multe înregistrări din TABELUL A

Tabel B

Tabel A

Această „labă de gâscă” arată că o înregistrare din TABELUL A este corelată cu mai multe înregistrări din TABELUL B

Fig. 3.16. Realizarea diagramei pentru o relaţie „mai mulţi cu mai mulţi”

Studenti

Cursuri

Fig. 3.17. Diagrama relaţiei dintre tabelele STUDENTI şi CURSURI

O astfel de relaţie este una nerezolvată, adică nu se poate stabili o legătură coerentă între înregistrările celor două tabele, neputându-se efectua o interogare în care să fie implicate cele două tabele. După cum vedeţi, între cele două tabele nu există o legătură reală, deci nu aveţi cum să asociaţi înregistrările dintr-un tabel cu înregistrările din celălalt tabel. O metodă cu care aţi putea stabili o legătură între cele două tabele ar fi preluarea unui câmp dintr-unul din tabele şi introducerea lui de un număr de ori în celălalt tabel. Această idee este prima care ne vine în minte, dar nu este o idee bună, deoarece măreşte nejustificat unul din tabele, fără a rezolva însă, în totalitate problema. O altă metodă pentru a stabili o legătură coerentă, este introducerea unui tabel de legătură între cele două tabele. 75

Baze de date

Capitolul 3

Un tabel de legătură facilitează asocierea înregistrărilor dintr-un tabel cu înregistrările din celălalt tabel şi asigură lipsa oricăror probleme la operaţiile de adăugare, ştergere sau modificare a datelor corelate. Un tabel de legătură se defineşte prin preluarea unor cópii ale cheii primare din fiecare tabel şi utilizarea lor pentru a forma structura noului tabel. În realitate, aceste câmpuri îndeplinesc două roluri distincte: împreună formează cheia primară compozită a tabelului de legătură, iar separat, fiecare poate fi asimilată unei chei externe. Să reluăm tabelele din figura 3.15, şi ne punem întrebarea cum putem asocia cu uşurinţă înregistrări din primul tabel cu înregistrări din al doilea tabel? Altfel spus, cum putem asocia un student cu mai multe cursuri sau un anumit curs cu mai mulţi studenţi? Cea mai bună metodă este de crea şi utiliza un tabel de legătură care va rezolva relaţia de tip mai mulţi cu mai mulţi în maniera cea mai adecvată şi mai eficientă. Figura 3.18 prezintă rezolvarea practică a acestei soluţii. Studenti StudID 6001 6002 6003 6004 6005

Nume Pop Szabo Costea Timocea Mocean

Prenume Remus Zoltan Florian Sebastian Vasile

OrasStudent Reghin Oradea Zalau Brasov Fagaras

<> ..... ..... ..... ..... .....

Orar(tabel de legătură) StudID 6001 6002 6002 6001 6002 6003 6004 6001 6003 6001 6005

CursID C001 C213 C032 C213 C015 C001 C213 C015 G001 G004 G007

Cursuri CursID C001 C213 C032 C015 G001 G004 G007

Denumire PUC SIM Baze de date GD AutoCAD Inventor IntelliCAD

Credite 5 5 4 5 4 5 5

ProfID 2001 2001 2045 2014 2009 2006 2032

Fig.3.18. Rezolvarea unei relaţii de tip mai mulţi cu mai mulţi cu ajutorul unui tabel de legătură

76

Baze de date

Capitolul 3

Se observă că tabelul de legătură are mai multe înregistrări decât oricare din tabelele pe care le leagă. De asemenea, între fiecare din cele două tabele şi tabelul de legătură există o relaţie de tip unu cu mai mulţi. Prin urmare, o relaţie de tip mai mulţi cu mai mulţi s-a transformat în două relaţii unu cu mai mulţi, aşa cum se poate vedea în figura 3.19.

Orar

Studenti

StudentID CursID

StudentID Nume Prenume OrasStudent --------

Cursuri CursID Denumire Credite ProfesorID Sala --------

Fig. 3.19. Diagrama de relaţie a problemei rezolvate

Observaţi din figura 3.19 reprezentarea tabelului de legătură, cu cel două linii verticale, în stânga şi dreapta dreptunghiului. Relaţii cu autoreferire Acest tip particular de relaţie nu există între două tabele, motiv pentru care nu a fost amintit la tipuri de relaţii. Acest tip de relaţie există însă înregistrările dintr-un tabel. Pe parcursul procesului de proiectare o vom considera, totuşi, ca fiind o relaţie între tabele. Un tabel are cu el însuşi o relaţie cu autoreferire (cunoscută şi sub numele de relaţie recursivă) dacă o anumită înregistrare din tabel este corelată cu alte înregistrări din acelaşi tabel. Similar tipului echivalent de relaţie pentru perechi de tabele, o relaţie cu autoreferire poate fi „unu cu unu”, „unu cu mai mulţi” şi „mai mulţi cu mai mulţi”. Relaţia „unu cu unu” există când o înregistrare dată dintr-un tabel poate fi corelată cu o singură înregistrare din acelaşi tabel. Tabelul MEMBRII din figura 3.20 este un exemplu de tabel care are acest tip de relaţie. Astfel, un membru dat poate sponsoriza un singur alt membru din organizaţie; câmpul SponsorID stochează numărul de identificare al membrului care 77

Baze de date

Capitolul 3

joacă rolul de sponsor. Observaţi că Mocean Pavel sponsorizează pe Obădău Anica. Membrii MembruID 1001 1002 1003 1004 1005

Nume Pop Mocean Ban Ban Obădău

Prenume Dorin Pavel Ionel Lucia Anica

SponsorID 1001 1003 1002

<> --------------------------

Fig. 3.20. Relaţie cu autoreferire „unu cu unu”

Diagrama unei astfel de relaţii se poate vedea în figura 3.21. Membrii

Această linie laterală a tabelului arată natura de auto-referiere a relaţiei şi tipul relaţiei.

Fig. 3.21. Diagrama unei relaţii cu auto-referire „unu cu unu”

Relaţia „unu cu mai mulţi” cu autoreferire există atunci când o înregistrare dată din tabel poate fi corelată cu una sau mai multe înregistrări din acelaşi tabel. Figura 3.22 arată un exemplu în care un angajat poate fi şeful mai multor angajaţi. Observaţi că Pop Dorin este şeful la alţi trei angajaţi. Personal AngajatID 1001 1002 1003 1004 1005

Nume Mocean Pop Ban Ban Obădău

Prenume Pavel Dorin Ionel Lucia Anica

Sef 1002

1002 1002

<> --------------------------

Fig. 3.22. Relaţie cu autoreferire „unu cu mai mulţi”

78

Baze de date

Capitolul 3

Figura 3.23 arată diagrama acestei relaţii.

Personal Fig. 3.23. Diagrama relaţiei cu auto-referire „unu cu mai mulţi”

Relaţia „mai mulţi cu mai mulţi” cu autoreferire există când o înregistrare dată dintr-un tabel poate fi corelată cu una sau mai multe înregistrări din acelaşi tabel şi una sau mai multe înregistrări pot fi corelate cu înregistrarea dată. La început, acest lucru poate apărea confuz, dar exemplul care urmează o să vă ajute să clarificaţi problema (figura 3.24). În acest caz, o anumit subansamblu poate fi compus din mai multe piese componente diferite şi poate fi la rândul lui component al unui alt subansamblu. Piese PiesaID 7001 7002 7003 7004 7005 7006 7007 7008 7009 7010 7011

Denumire piesa Clema superioară Clema inferioară Şurub de strângere Piulită Ansamblu clemă Scaun Ansamblu scaun Corp tubular Suport spate Ansamblu cadru Şa

<> .....

..... ..... ..... ..... ..... ..... ..... ..... ..... .....

Fig. 3.24. Exemplu de relaţie cu autoreferire „mai mulţi cu mai mulţi”

Subansamblu clemă (7005) este compus din patru piese (7001, 7002, 7003, 7004), deci înregistrarea respectivă poate fi corelată cu 4 înregistrări din acelaşi tabel. În plus, subansamblu clemă intră în componenţa ansamblului 79

Baze de date

Capitolul 3

scaun (7007) şi al ansamblului cadru (7010), deci 2 înregistrări din tabel pot fi corelate cu ea. Figura 3.25 prezintă diagrama pentru acest tip de relaţie. Piese Fig. 3.25. Diagrama unei relaţii cu autoreferire „mai mulţi cu mai mulţi”

Pasul următor pe care trebuie să-l facem este identificarea relaţiilor care există în mod curent între tabelele dintr-o bază de date. Identificarea relaţiilor existente În această fază avem structura finală a tabelelor, împreună cu descrierea lor. Am văzut în paragrafele anterioare care sunt cele trei relaţii care pot exista între tabele. Problema care se pune acum este aceea de a afla tehnica prin care veţi identifica relaţiile dintre tabelele bazei de date la proiectarea căreia lucraţi, ştiut fiind că această activitate nu este simplă. Experienţa personală joacă aici un rol important deoarece nu există reguli foarte clare pe cale să le aplicaţi. În analiza pe care aţi făcut-o în timpul proiectării bazei de date, aţi stat de vorbă cu multe persoane din organizaţia beneficiară, atât din conducere cât şi din compartimentele care vor folosi nemijlocit baza de date. Ei bine, aceste persoane vă vor fi de un real folos în identificarea relaţiilor dintre tabele, chiar dacă ele nu au o viziune completă asupra problemei în cauză. Începeţi procesul de identificare a relaţiilor prin crearea unei matrice cu toate tabelele bazei de date. Pentru aceasta puteţi folosi o foaie de hârtie, o tablă sau programul Excel. De exemplu, să presupunem că lucraţi cu următoarele tabele: CLADIRI CURSURI INDEMNIZATIE CATEDRA 80

Baze de date

Capitolul 3

SALI PERSONAL STUDENTI Scrieţi tabelele în partea de sus a matricei şi încă o dată în partea stângă a matricei, ca în figura 3.26.

Cladiri

Cursuri

Indemnizatie

Catedra

Sali

Personal

Studenti

Cladiri Cursuri Indemnizatie Catedra Sali Personal Studenti Fig. 3.26. Realizarea unei matrice de tabele pentru stabilirea relaţiilor

Selectaţi câte un tabel din partea stângă a matricei şi verificaţi dacă el are vreo relaţie cu vreunul din tabelele din partea de sus, parcurgând matricea pe linie. Ţineţi minte că nu căutaţi decât relaţiile directe – între tabelele care participă la relaţie trebuie să existe o conexiune specifică. De exemplu, tabelul CURSURI are o relaţie directă cu tabelul STUDENTI, deoarece cursurile există ca să fie urmate de studenţi. Tabelul CURSURI are o relaţie indirectă cu tabelul PERSONAL, prin intermediul tabelului CATEDRA; un curs este predat de un membru al catedrei, nu de un membru al personalului. Nu trebuie să vă ocupaţi încă de relaţiile indirecte. Dacă nu vedeţi de la început relaţia dintre două tabele, o bună metodă este de a „popula” tabelele cu câteva înregistrări care vă vor ajuta în depistarea acestor relaţii. În şedinţa de lucru pentru stabilirea relaţiilor între tabele veţi pune întrebări de genul:  Poate o înregistrare din CURSURI să fie asociată cu una sau mai multe înregistrări din tabelul CLADIRI?  Se poate găsi o legătură între PERSONAL şi STUDENTI? Reţineţi că pentru a stabili relaţia corectă dintre două tabele, veţi pune două întrebări, una din perspectiva primului tabel şi una din perspectiva celuilalt tabel. Răspunsurile la aceste două întrebări vor identifica tipul de relaţie care există între cele două tabele.

81

Baze de date

Capitolul 3

După ce aţi identificat relaţia, indicaţi tipul relaţiei în celula aflată la intersecţia dintre liniile celor două tabele. Pentru tipurile de relaţii folosiţi următoarele prescurtări:  1:1 - pentru relaţia unu cu unu.  1:M - pentru relaţia unu cu mai multi.  M:M - pentru relaţia mai mulţi cu mai mulţi. În figura 3.27 este arătată matricea de tabele cu completată cu relaţiile tabelului CURSURI. Cladiri Cladiri Cursuri Indemnizatie Catedra Sali Personal Studenti

Cursuri 1:M

Indemnizatie

1:1

Catedra 1:M

Sali 1:M 1:1

Personal

Studenti

Fig. 3.27. Intrările în matricea de tabele, pentru tabelele CLADIRI şi CURSURI

Iată cum putem comenta notaţiile din figura 3.21, începând din stânga sus:  1:M - într-o clădire se pot ţine mai multe cursuri.  1:M - o clădire are mai multe săli.  1:1 - un curs se poate ţine numai într-o clădire.  1:M - un curs poate aparţine mai multor catedre  1:1 - un curs se ţine numai într-o sală. Dacă între tabele nu există nici un fel de relaţie, lucru perfect normal, celula corespunzătoare va fi goală. Deseori, relaţiile între două tabele vor diferi de la o perspectivă la alta (depinde din ce parte privesc) şi trebuie să ştiţi cum să determinaţi tipul oficial de relaţie dintre fiecare pereche de tabele din matrice. Veţi stabili acest lucru utilizând următorul set de formule:  1:1 + 1:1 = 1:1  1:M + 1:1 = 1:M  1:M + 1:M = M:M 82

Baze de date

Capitolul 3

Iată, în rezumat, procedura specifică pe care o veţi utiliza la identificarea relaţiei oficiale între două tabele din matrice, procedura incluzând formulele de relaţie de mai sus: 1. Selectaţi o pereche de tabele şi notaţi intrarea de la intersecţia dintre linia primului tabel şi coloana celui de-al doilea. 2. Localizaţi al doilea tabel pe aceeaşi parte a matricei pe care lucraţi şi notaţi intrarea de la intersecţia liniei acestuia cu coloana primului tabel. 3. Asupra celor două intrări aplicaţi una din formulele de mai sus şi stabiliţi relaţia oficială dintre cele două tabele. 4. Construiţi diagrama relaţiei în mod corespunzător. 5. Tăiaţi ambele intrări din matrice. Pentru cazul concret al perechii de tabele CLADIRI şi CURSURI, rezultatul se vede în figura 3.28. Cladiri Cladiri Cursuri Indemnizatie Catedra Sali Personal Studenti

Cursuri 1:M

Indemnizatie

1:1

1:1

Catedra 1:M

Sali 1:M 1:1

Personal

Studenti 1:M

1:1 1:1

1:M 1:M 1:1

1:1

1:M

1:M

Fig. 3.28. Identificare relaţiei oficiale pentru perechea CLADIRI şi CURSURI

Relaţia oficială rezultată este 1:M – unu cu mai mulţi, rezultată din compunerea relaţiilor din cele două sensuri. Relaţia „unu cu unu” poate fi identificată observând că un tabel joacă rol de tabel părinte şi celălalt joacă rol de tabel copil (subordonat). În tabelul părinte trebuie să existe cel puţin o înregistrare înainte să puteţi introduce în tabelul copil o înregistrare corelată, adică un copil nu poate exista fără părinte, nu-i aşa? Atribuirea rolului de părinte şi copil nu este totdeauna un lucru foarte clar, existând cazuri când această atribuire se face arbitrar. Un lucru trebuie să vă fie clar: relaţia unu cu unu poate fi asemuită cu un tabel mare rupt în două, iar într-unul dintre ele s-a copiat câmpul cheie primară, care devine 83

Baze de date

Capitolul 3

cheie externă. De fapt, acesta este şi mecanismul cu care se relaţiile unu cu unu. Iată un caz concret de construcţie a unei relaţii unu cu unu (figura 3.29). Presupunem că avem tabelul Personal, care conţine toate câmpurile legate de descrierea unui angajat. Acest tabel se va „rupe” în două pentru a separa datele confidenţiale de cele publice.

Personal-1 AngajatID ChP Nume Prenume Data nasterii Data angajarii Specializare Adresa Telefon acasa Mobil E-mail Web

Personal AngajatID ChP Nume Prenume Data nasterii Data angajarii Specializare Adresa Telefon acasa Mobil E-mail Web Salariu Indemnizatie Asigurare Tip plan medical

Personal-2 AngajatID ChE Salariu Indemnizatie Asigurare Tip plan medical

Fig. 3.29. Exemplu de creare a unei relaţii unu cu unu

Între PERSONAL-1 şi PERSONAL-2 există o relaţie unu cu unu foarte clară şi uşor de depistat. Cheia primară în primul tabel, AngajatID a devenit cheie externă în al doilea tabel, după cum se vede în figură. În unele cazuri, mai pot fi forţate unele relaţii unu cu unu, fără ca aceste tabele sa aibă altceva comun decât cheia primară a unuia copiată în celălalt tabel. Practica o să vă scoată în cale şi un astfel de caz. Relaţia „unu cu mai mulţi” poate fi stabilită într-un mod asemănător cu relaţia „unu cu unu”. Veţi lua, pur şi simplu, o copie a cheii primare din 84

Baze de date

Capitolul 3

tabelul aflat în partea „unu” a relaţiei şi o veţi include în structura tabelului din partea „mai mulţi”, unde va deveni cheie externă. Pentru exemplificare, fie relaţia „unu cu mai mulţi” dintre tabelele CLADIRI şi SALI, prezentată în figura 3.30.

Sali

Cladiri

SalaID ChP Tip sala Nr locuri Acces Intrenet

CladireID ChP Numar etaje Acces lift Acces parcare

Fig. 3.30. Relaţia de tip „unu cu mai mulţi” existentă între tabelele CLADIRI şi SALI

Relaţia logică între aceste tabele este că o clădire are mai multe săli, dar o sală se găseşte numai într-o clădire. Utilizând procedura anterioară, veţi stabili această relaţie luând o copie a cheii primare (CladireID) din tabelul CLADIRI pe care o includeţi drept cheie externă în tabelul SALI. Diagrama revizuită trebuie să fie ca cea prezentată în figura 3.31. Sali Cladiri SalaID ChP CladireID ChE Tip sala Nr locuri Acces Intrenet

CladireID ChP Numar etaje Acces lift Acces parcare

Fig. 3.31. Stabilirea relaţiei „unu cu mai mulţi” între tabelele CLADIRI şi SALI

Relaţia „mai mulţi cu mai mulţi” se stabileşte cu ajutorul unui tabel de legătură. Deci, va trebui să creaţi un nou tabel în baza de date, parcurgând următorii paşi: 85

Baze de date

Capitolul 3

 Se defineşte tabelul de legătură luând cópii ale cheii primare din fiecare tabel al relaţiei şi utilizând aceste chei pentru a forma structura tabelului. În tabelul de legătură, aceste câmpuri au două scopuri distincte: împreună ele constituie cheia primară compusă a tabelului şi fiecare este o cheie externă unică care ajută la stabilirea unei relaţii unu cu mai mulţi între tabelul său părinte şi tabelul de legătură.  Se dă tabelului de legătură un nume care să reprezinte natura relaţiei dintre cele două tabele. De exemplu, între tabelele STUDENTI şi CURSURI, numele tabelului de legătură ar putea fi CURSURI STUDENT sau ORAR STTUDENT.  Se adaugă tabelul de legătură în lista finală de tabele şi se completează rubricile „Tip tabel” şi „Descriere tabel”. Figura 3.32 vă arată cum stabiliţi o relaţie „mai mulţi cu mai mulţi” între tabelele STUDENTI şi CURSURI. (Observaţi noul simbol de diagramă pentru tabelul de legătură.) Studenti StudentID ChP Nume Prenume Data nasterii Adresa Telefon E-mail

Cursuri Cursuri Student StudentID ChPC/ChE CursID ChPC/ChE

CursID ChP Denumire Credite ProfesorID Categorie

Fig. 3.32. Stabilirea unei relaţii „mai mulţi cu mai mulţi” între tabelele STUDENTI şi CURSURI

Observaţi că mecanismul de stabilire a relaţiei „mai mulţi cu mai mulţi” nu face altceva decât să transforme această relaţie în două relaţii „unu cu mai mulţi”, adăugând în acelaşi timp un tabel nou în baza de date. Relaţiile cu autoreferire se stabilesc relativ simplu deoarece se aplică aceleaşi proceduri ca şi la cele 3 relaţii dintre două tabele diferite. Pentru rezolvarea elegantă a relaţiilor cu autoreferire, o idee bună e să evităm aceste relaţii prin regândirea structurii tabelului şi crearea altor tabele subset. Este o idee pe care o aplic curent şi a dat rezultate bune. 86

Baze de date

Capitolul 3

Astfel, cazul tabelului prezentat la paragraful „Relaţii cu autoreferire”, cel din figura 3.22, se poate rezolva mai simplu dacă introducem în baza de date un nou tabel numit SEFI, cu care să stabilim o relaţie „unu cu mai mulţi”. În acest fel câmpul SEF ar putea deveni cheie externă, numindu-se SefID.

Stabilirea caracteristicilor relaţiilor După ce aţi stabilit toate relaţiile care se găsesc între tabelele bazei dumneavoastră de date, urmează să stabiliţi caracteristicile fiecărei relaţii. Aceste caracteristici arată ce se întâmplă atunci când ştergeţi o înregistrare, care este tipul de participare şi gradul de participare a fiecărui tabel în relaţie. Definirea unei reguli de ştergere

Prima caracteristică pe care o stabiliţi pentru relaţie este o regulă de ştergere. Această regulă stabileşte ce trebuie să facă programul SGBDR când cereţi să şteargă o anumită înregistrare din tabelul părinte al relaţiei. Regulile de ştergere sunt extrem de importante pentru integritatea la nivel de relaţie deoarece ele vă protejează împotriva înregistrărilor orfane – înregistrări din tabelul copil care nu au nici un fel de relaţie cu nici o înregistrare din tabelul părinte. Puteţi defini 5 tipuri de reguli de ştergere, iar acţiunile pe care le va efectua programul SGBDR, în cazul fiecărei reguli sunt următoarele:  Interdicţie. Programul SGBDR nu va şterge înregistrarea din tabelul părinte, ci o va păstra şi o va desemna ca “inactivă”.  Restricţie. Programul SGBDR nu va şterge înregistrarea din tabelul părinte dacă în tabelul copil există înregistrări corelate. Programul SGBDR trebuie să şteargă toate înregistrările corelate din tabelul copil înainte să poată şterge înregistrarea din tabelul părinte.  În cascadă. Programul SGBDR va efectua două acţiuni specifice: va şterge înregistrarea din tabelul părinte, apoi automat, va şterge toate înregistrările corelate din tabelul copil.  Anulare. Programul SGBDR va şterge înregistrarea din tabelul părinte apoi va actualiza la valoare nulă valorile cheii externe ale 87

Baze de date

Capitolul 3

înregistrărilor corelate din tabelul copil. Dacă intenţionaţi să utilizaţi această regulă de ştergere, trebuie să modificaţi specificaţia de câmp a cheii externe şi să atribuiţi elementul logic Suport valori nule, valoarea “Se acceptă valori nule”.  Folosire valoare prestabilită. Programul SGBDR va şterge înregistrarea din tabelul părinte apoi va actualiza valoarea cheii externe ale înregistrărilor corelate din tabelul copil la valoarea curentă a elementului logic Valoare prestabilită din specificaţia de câmp a cheii externe. Evident, ca să puteţi utiliza această regulă, trebuie să fi introdus o valoare la elementul Valoare prestabilită. În general, este recomandabil să utilizaţi regula de ştergere Restricţie şi celelalte reguli, după necesităţi. Identificarea tipului de participare a fiecărui tabel

După cum se ştie de la capitolul 1, când stabiliţi o relaţie între două tabele, fiecare tabel participă la relaţie într-o manieră particulară. Tipul de participare pe care îl atribuiţi unui tabel dat determină dacă în respectivul tabel trebuie să existe o înregistrare înainte de a putea introduce înregistrări în tabelul corelat. Există 2 tipuri de participări: Obligatorie - tabelul trebuie să conţină cel puţin o înregistrare înainte de a putea introduce înregistrări în tabelul corelat. Opţională – nu este obligatoriu ca tabelul să conţină vreo înregistrare înainte de a putea introduce înregistrări în tabelul corelat.

De obicei, pentru majoritatea tabelelor, veţi determina tipul de participare după ce definiţi regulile de lucru cu baza de date. În majoritatea cazurilor, tipul de participare este evident, este de bun simţ sau este în concordanţă cu un anumit set de standarde. Pentru exemplificare, să luăm relaţia „unu cu mai mulţi” dintre tabelele ANGAJATI şi CLIENTI, din figura 3.33.

88

Baze de date

Capitolul 3

Angajati AngajatID ............

Clienti ClientID ChP AngajatID ChE

ChP

Fig. 3.33. Ce tip de participare trebuie atribuit fiecărui tabel?

Să presupunem că fiecare client trebuie atribuit unui anumit angajat. Acest angajat acţionează ca reprezentant al clientului şi se ocupă de toate tranzacţiile şi comunicarea dintre organizaţie şi respectivul client. Deşi fiecare client trebuie asociat cu un anumit angajat, un angajat dat nu este obligat să fie asociat cu vreun client. Mulţi angajaţi se ocupă de alte probleme ale organizaţiei. Prin urmare, cele 2 tabele vor participa la relaţie astfel:  Tabelul ANGAJATI trebuie să primească tipul de participare Obligatorie. Acest lucru vă asigură că există cel puţin un angajat pe care să-l puteţi atribui unui client dat.  Tabelul CLIENTI trebuie să primească tipul de participare Opţională. Acest lucru vă permite să introduceţi în tabelul ANGAJATI orice persoană angajată de organizaţie. După ce aţi determinat tipul de participare a fiecărui tabel în relaţie, marcaţi acest tip pe diagrama relaţiei. Pentru tipul Obligatorie, folosiţi o linie verticală, iar pentru tipul Opţională un cerc mic. Figura 3.34 prezintă diagrama revizuită a relaţiei dintre tabelele ANGAJATI şi CLIENTI, arătându-vă marcarea tipului de participare. Observaţi că simbolurile tipului de participare (linia şi cercul mic) se află între simbolurile tipului de relaţie (linia şi laba de gâscă).

89

Baze de date

Capitolul 3 Această linie simbolizează tipul de participare Obligatorie pentru acest tabel

Clienti Angajati AngajatID ............

ClientID ChP AngajatID ChE

ChP

Acest cerc simbolizează tipul de participare Opţională pentru acest tabel

Fig. 3.34. Precizarea tipului de participare pentru tabelele ANGAJATI şi CLIENTI

Identificarea gradului de participare a fiecărui tabel

După ce aţi determinat cum va participa fiecare tabel în cadrul relaţiei, trebuie să stabiliţi gradul în care va participa fiecare tabel. După cum ştim din capitolul 1, gradul de participare precizează numărul minim de înregistrări pe care un tabel dat trebuie să le aibă asociate cu o înregistrare din tabelul corelat şi numărul maxim de înregistrări din tabel care pot fi asociate cu o înregistrare din tabelul corelat. Factorii pe care îi utilizaţi la determinarea gradului de participare – situaţii evidente, bunul simţ sau respectarea unui set oarecare de standarde – sunt aceiaşi pe care îi folosiţi şi la determinarea tipului de participare. De obicei, în acest moment al procesului de proiectare veţi identifica gradul de participare pentru unele dintre tabele, iar altele le veţi revedea atunci când stabiliţi regulile de lucru pentru baza de date. Pentru a reprezenta gradul de participare al unui tabel dat, veţi utiliza 2 numere, separate prin virgulă şi închise între paranteze. Primul număr precizează numărul minim de înregistrări corelate, iar al doilea număr arată numărul maxim permis, de înregistrări corelate. De exemplu, un grad de participare cum ar fi (2,11) arată că tabelul trebuie să aibă cel puţin 2, dar nu mai mult de 11 dintre înregistrările sale corelate cu o singură înregistrare dintr-un alt tabel. 90

Baze de date

Capitolul 3

Să luăm din nou tabelele ANGAJATI şi CLIENTI. Între aceste 2 tabele există o relaţie „unu cu mai mulţi”, ceea ce înseamnă că un client dat poate fi asociat cu singur angajat şi un angajat dat poate fi asociat cu orice număr de clienţi. Judecând după o regulă de bun simţ sau decizie a conducerii organizaţiei, un angajat nu poate să răspundă de mai mult de 10 clienţi simultan. Pe baza acestui scenariu, puteţi deduce că gradul de participare pentru tabelul ANGAJATI este (1,1) şi gradul de participare pentru tabelul CLIENTI este (0,10). După ce aţi identificat gradul de participare al unui tabel, adăugaţi această informaţie în diagrama relaţiei. Plasaţi gradul de participare deasupra liniei de legătură a tabelului corespunzător. Figura 3.35 prezintă diagrama relaţiei dintre tabelele ANGAJATI şi CLIENTI, completată cu simbolizarea gradului de participare. Aceasta indică numărul minim şi Aceasta indică numărul minim şi numărul numărul maxim de angajaţi cu maxim de clienţi cu care poate fi asociat care poate fi asociat un client un angajat

Clienti

Angajati

(0,10) ClientID

ChP AngajatID ChE

(1,1)

AngajatID ............

ChP

Fig. 3.35. Indicarea gradului de participare pentru tabelele ANGAJATI şi CLIENTI

Puteţi, de asemenea să indicaţi gradul de participare nelimitată pentru orice tabel dintr-o relaţie între două tabele, folosind litera „N” în locul celui deal doilea număr (1,N). Următoarea sarcină pe care o aveţi este să parcurgeţi toate relaţiile din baza de date la care lucraţi şi să stabiliţi caracteristicile fiecăruia, după modelul prezentat mai sus. Pe măsură ce finalizaţi munca la o relaţie dată, nu uitaţi să actualizaţi diagrama relaţiei, astfel încât aceasta să reflecte rezultatele obţinute.

91

Baze de date

Capitolul 3

Integritatea la nivel de relaţie O relaţie atinge integritatea la nivel de relaţie după ce aţi verificat ca ea să fi fost corect stabilită şi ca toate caracteristicile ei să fi fost precizate în mod corespunzător. Integritatea la nivel de relaţie garantează următoarele:  Conexiunea între cele două tabele (sau câmpuri cheie) implicate într-o relaţie este solidă. Veţi obţine acest lucru folosind câmpurile cheie primară şi externă la stabilirea relaţiilor „unu cu unu” sau „unu cu mai mulţi” şi un tabel de legătură la stabilirea relaţiei de tip „mai mulţi cu mai mulţi”.  În fiecare tabel puteţi insera înregistrări noi într-o manieră semnificativă. Acest lucru îl asiguraţi indicând tipul corespunzător de participare pentru fiecare tabel (sau câmp cheie) implicat în relaţie.  Puteţi şterge o înregistrare existentă fără a produce efecte negative. Acest lucru este garantat prin atribuirea unei reguli corespunzătoare de ştergere pentru relaţie.  Există o limită semnificativă pentru numărul de înregistrări ce pot fi corelate într-o relaţie. Acest lucru îl implementaţi indicând gradul corespunzător de participare pentru fiecare tabel (sau câmp cheie) implicat în relaţie. După cum ştiţi, integritatea la nivel de relaţie este a treia componentă a integrităţii generale a datelor. (Prima este integritatea la nivel de tabel şi a doua este integritatea la nivel de câmp.)

92

Baze de date

Capitolul 3

Etapa 5 - Determinarea şi definirea regulilor de desfăşurare a activităţii În această etapă vom determina regulile care trebuie să fie cunoscute şi respectate de toţi utilizatorii bazei de date. Cea mai bună abordare a acestei etape este definirea şi stabilirea regulilor de desfăşurare a activităţii specifice câmpurilor, urmate de regulile de desfăşurare a activităţii specifice relaţiilor. Această abordare vă ajută să rămâneţi concentrat pe tipul de regulă pe care o definiţi. De asemenea, se evită saltul înainte şi înapoi, de la un tip de regulă la altul, fapt care poate determina confuzie şi sentimente de frustrare. Reguli specifice câmpurilor În mod normal, ar trebui ca fiecare câmp al bazei de date să aibă regulile sale, cuprinse în dosarul de documentare a bazei de date. Practic însă, datorită faptului că unele câmpuri nu au nevoie de reguli, acestea fiind evidente (nume de persoane, câmpuri numerice, date calendaristice etc.), numai unele câmpuri au într-adevăr nevoie de reguli pentru funcţionarea corectă a bazei de date. Pentru stabilirea regulilor de desfăşurarea activităţii specifice câmpurilor, veţi parcurge următoarele etape:  Selectaţi un tabel;  Analizaţi fiecare câmp şi determinaţi dacă acesta necesită vreo restricţie;  Definiţi, dacă e cazul, regulile de desfăşurare a activităţii necesare pentru respectivul câmp;  Determinaţi cum se verifică regula;  Notaţi regula în formularul Foaie de specificaţii pentru regula de desfăşurare a activităţii, prezentat în pagina următoare. Regulile de desfăşurare a activităţii se scriu într-un formular special numit Foaie de specificaţii pentru regula de desfăşurare a activităţii, a cărui rol este de a uniformiza modalităţile de prezentare a acestor reguli. De asemenea, fiecare regulă este prinsă într-un document ceea ce face mai simplă gestionarea lor. O regulă fiind tipărită pe un format A4, acestea se pot arhiva în dosare, se pot multiplica, putând fi accesate de oricine are nevoie de aceste reguli. În figura 3.36 este prezentat acest formular. 93

Baze de date

Capitolul 3

Fig. 3.36. Formular pentru o regulă de desfăşurare a activităţii

94

Baze de date

Capitolul 3

Documentul Foaie de specificaţii pentru regula de desfăşurare a activităţii conţine următoarele elemente:  Enunţ. Acesta este textul regulii de desfăşurare a activităţii. El trebuie să fie clar, succint şi ar trebui să comunice restricţiile necesare, fără confuzii sau ambiguităţi. Iată un exemplu concret de regulă: „O grupă nu poate conţine mai mult de 30 de studenţi.”  Restricţie. Aici se pune o scurtă explicaţie a modului în care restricţia se aplică tabelelor şi câmpurilor. De exemplu, puteţi utiliza următoarea explicaţie pentru restricţia impusă de regula din exemplul precedent:

  









„O singură înregistrare din tabelul tblGrupe poate fi asociată cu maximum 30 de înregistrări din tabelul tblStudenti.” Tip. Aici indicaţi dacă regula este orientată spre baza de date sau este orientată spre aplicaţie. Categorie. Aici indicaţi dacă regula este specifică unui câmp sau unei relaţii. Testare la. Aici indicaţi care acţiuni (inserare, ştergere, actualizare) vor determina testarea restricţiei impusă de regula de desfăşurare a activităţii. Structuri afectate. În funcţie de tipul de regula de desfăşurare a activităţii, restricţia va afecta fie un câmp, fie o relaţie. Aici specificaţi numele câmpurilor care vor fi afectate de regulă sau numele tabelelor implicate în relaţie care vor fi afectate. Elemente de câmp afectate. O regulă de desfăşurare a activităţii care ţine de un câmp poate afecta unul sau mai multe elemente ale respectivei specificaţii de câmp. Aici indicaţi elementele afectate de regulă. Caracteristici de relaţie afectate. O regulă de desfăşurare a activităţii care ţine de o relaţie va afecta una sau mai multe caracteristici ale respectivei relaţii. Aici indicaţi caracteristicile afectate de regulă. Acţiune întreprinsă. Aici indicaţi modificările aduse elementelor unei specificaţii de câmp sau diagramei de relaţie. Ceea ce scrieţi aici trebuie să fie foarte clar şi fără ambiguităţi.

95

Baze de date

Capitolul 3

Reguli specifice relaţiilor Procedura de efectuare a acestei operaţii presupune parcurgerea următorilor paşi:  Selectaţi o relaţie;  Revizuiţi relaţia şi determinaţi dacă aceasta necesită vreo restricţie;  Definiţi regulile de desfăşurare a activităţii pentru relaţie;  Modificaţi caracteristicile relaţiei;  Determinaţi ce acţiuni vor determina testarea regulii, altfel spus când se vede regula;  Notaţi regula în formularul Foaie de specificaţii pentru regula de desfăşurare a activităţii, prezentat în figura 3.36. Se observă că această procedură este asemănătoare cu cea utilizată pentru regulile de desfăşurare a activităţii specifice câmpurilor. Uşurinţa cu care veţi stabili aceste reguli, depinde de experienţa pe care o aveţi. Pentru începători, recomand studiul cu atenţie a paragrafului „Studiu de caz. Proiectarea unei baze de date”, unde veţi găsi modele de reguli pentru desfăşurarea activităţii, precum şi alte informaţii practice. Regulile de desfăşurare a activităţii specifice relaţiilor se referă, în special, la tipul de participare şi gradul de participare (vezi capitolul 2, paragraful Termeni referitori la relaţie). Pentru determinarea acţiunilor care testează regula, gândiţi-vă, de exemplu, ce se întâmplă dacă se şterge o înregistrare dintr-un tabel care este legat cu alt tabel. Dacă un tabel conţine cursuri, iar celălalt conţine profesori care ţin aceste cursuri, este clar că nu putem şterge un profesor care are cel puţin un curs de ţinut. Dacă s-ar putea şterge, ar apărea aşanumitele înregistrări orfane cu grave prejudicii în funcţionarea bazei de date. Referitor la numărul de cursuri pe care le poate preda un profesor, acesta poate fi stabilit, de exemplu la 6. În acest caz, regula de desfăşurare a activităţii ar putea fi următoarea: „Un profesor trebuie să aibă cel puţin un curs, dar nu poate depăşi 6 cursuri.” 96

Baze de date

Capitolul 3

Dacă veţi ajunge să lucraţi în echipe complexe de proiectare şi implementare a bazelor de date şi a sistemelor informatice, stabilirea regulilor de desfăşurare a activităţii va deveni activitate de rutină. Tabele de validare În timp ce definiţi reguli pentru desfăşurarea activităţii specifice unui câmp poate apărea situaţia în care acel câmp nu poate avea decât anumite valori, adică un set distinct de valori. Se poate aminti aici câmpul numit JUDETE, e clar că acesta nu poate avea altă valoare decât una din cele 42 de judeţe ale ţării. De asemenea, câmpul cu secţiile unei facultăţi nu poate avea altă valoare decât numele acelor secţii. Se pune firesc întrebarea, cum stabilim acel set distinct de valori pe care le poate lua un anumit câmp. O soluţie ar fi enumerarea valorilor într-un „Interval de valori” de pe Foaia de specificaţii a câmpului. Acest lucru merge bine când avem puţine valori (ex. Sex: M/F, Note: 1-10), dar nu în cazul judeţelor ca în exemplul amintit mai sus. Pentru un număr mare de valori trebuie neapărat să folosim un tabel de validare. Acest tabel are cel puţin 2 câmpuri (ID şi Valoare) şi o caracteristică utilă, aceea de a nu se schimba de loc sau foarte rar, vezi exemplul cu judeţele şi cu secţiile unei facultăţi. Iată cum apare tabelul de validare pentru judeţele ţării noastre, figura 3.37. JudetID 1 2 ... 26 ...

Abreviere AB AR ... MS ...

Denumire Alba Arad ... Mures ...

Fig. 3.37. Tabel de validare

Este evidentă utilitatea tabelelor de validare în integritatea datelor unei baze de date, deoarece este împiedicată posibilitatea introducerii unor valori greşite, cum ar fi în cazul nostru, introducerea unui judeţ sub mai multe denumiri: Bistriţa, Bistriţa-Năsăud, Bistrita-Nasaud. Toate aceste denumiri ale judeţului respectiv ar fi posibile, dacă ele ar fi introduse de 97

Baze de date

Capitolul 3

către un operator uman, dar dacă se introduce cheia primară (JudetID), sigur nu vor fi mai multe denumiri ale acestuia.

Etapa 6 - Determinarea şi definirea vederilor Am văzut în capitolul 2 ce este o vedere, un tabel virtual alcătuit din câmpuri care provin din unul sau mai multe tabele ale unei baze de date. De asemenea, poate să conţină câmpuri şi din alte vederi. Tabelele şi vederile care compun o anumită vedere sunt cunoscute sub denumirea de tabele de bază ale vederii. O vedere este „virtuală” pentru că extrage date din tabelele de bază în loc să stocheze singură date. Pentru o vedere se stochează în baza de date numai structura ei, sistemul de gestiune a bazei de date (SGBDR) reconstruieşte şi „repopulează” vederea de fiecare dată când este accesată. Unele SGBDR –uri folosesc pentru vedere şi denumirea de interogare cum ar fi Microsoft Access, de care o să ne ocupăm şi noi în capitolul 5. Vederile vă permit să vedeţi informaţiile din baza de date din puncte de vedere diferite, oferindu-vă multă flexibilitate când lucraţi cu datele. Puteţi crea vederi în mai multe moduri, iar acestea sunt deosebit de utile când se bazează pe mai multe tabele între care există relaţii. Există mai multe motive pentru care ar trebui să definiţi şi să utilizaţi vederi în baza de date pe care o proiectaţi. Iată câteva dintre ele:  Lucrul cu date din mai multe tabele. Legătura dintre tabele se materializează practic în vederi.  În vederi se afişează cele mai frecvent folosite informaţii. Deoarece SGBDR reconstruieşte şi repopulează vederea de fiecare dată când o activaţi, informaţiile afişate în vedere ilustrează cele mai recente modificări ale datelor din tabelele de bază ale acesteia.  Le puteţi particulariza pentru a corespunde cerinţelor specifice fiecărui individ sau grupe de indivizi. Se pot construi vederi care să corespundă oricărui set de cerinţe.  Le puteţi utiliza pentru a ajuta la asigurarea integrităţii datelor. Puteţi defini o vedere de validare care funcţionează ca şi un tabel de validare – scopul acesteia fiind să furnizeze o gamă de valori acceptabile pentru un câmp dat al bazei de date. 98

Baze de date

Capitolul 3

 Le puteţi utiliza în scopuri de securitate sau confidenţialitate. Puteţi determina ce date sunt disponibile unui anumit grup de utilizatori. Definiţi vederile cu atenţie şi îndemnare, iar acestea vor deveni elemente valoroase în exploatarea bazei de date. Desigur, nu toate vederile o să le identificaţi încă din faza de proiectare a bazei de date. Multe dintre ele vă vor fi sugerate de utilizatori sau de practică. Vederile sunt de 3 tipuri şi anume:  Vederi de date. Acestea extrag date din unul sau mai multe tabele. Sunt cele mai întâlnite vederi.  Vederi agregate. Sunt folosite pentru a afişa informaţii produse prin agregarea unui set de date, într-un mod specific. Aceste vederi folosesc funcţiile agregate Sum, Average, Minim, Maxim şi Count.  Vederi de validare. Sunt folosite pentru a ajuta la implementarea integrităţii datelor. Vederile sunt create cu ajutorul limbajului SQL, aşa cum veţi învăţa în capitolul 4. După ce aţi identificat vederea, aceasta va trebui trecută în documentaţia proiectului, cu ajutorul unui document numit Foaie de specificaţii pentru o vedere, prezentată în figura 3.38. Aceasta conţine următoarele elemente:  Nume. Aici indicaţi numele vederii. Aveţi grijă ca aceste nume să fie cât mai sugestive.  Tip. Aici precizaţi dacă vederea este de date, agregată sau de validare.  Tabelele de bază. Aici specificaţi tabelele de bază ale vederii.  Expresii de câmp calculat. Aici notaţi expresiile pentru câmpurile calculate, pe care le-aţi inclus în vedere.  Filtre. Aici notaţi criteriile pe care le va folosi vederea pentru a filtra înregistrările pe care le afişează. Veţi nota atât câmpul testat cât şi expresia utilizată pentru a-l testa. Vedeţi Foaia de specificaţii pentru o vedere, prezentată în figura 3.38.

99

Baze de date

Capitolul 3

100

Fig. 3.38. Formular pentru vedere

Baze de date

Capitolul 3

Documentarea unei vederi se face prin 2 documente de bază: foaie de specificaţii şi diagrama de vedere. Foaia de specificaţii a fost prezentată în figura 3.38, iar pentru diagrama de vedere, cea mai bună explicaţie este prezentarea unui exemplu concret, aşa cum se va vedea în continuare. Să presupunem că dorim o vedere care să conţină toţi studenţii din baza de date cu secţia de la care provin şi numărul de telefon. Această vedere are ca tabele de bază tblStudenti şi tblSectii, iar ca şi câmpuri Student, Sectia, Telefon. Câmpul Student este un câmp calculat, care se obţine din alăturarea numelui şi prenumelui studentului care se găsesc în câmpuri separate. Numele secţiei se va lua din tabelul tblSectii cu care este legat tabelul tblStudenti. Diagrama de vedere este prezentată în figura 3.39.

tblSectii tblStudenti SectiaID Sectia ……..

StudentID Nume Prenume SectiaID Telefon ………

Lista studenti Student Sectia Telefon

Fig. 3.39. Diagramă de vedere

Această diagramă, împreună cu foaia de specificaţii oferă informaţiile necesare pentru crearea vederii de către echipa care implementează baza de date proiectată.

101

Baze de date

Capitolul 3

Etapa 7 – Revizuirea integrităţii datelor Aceasta este ultima etapă a procesului de proiectare a bazelor de date. Până aici aţi realizat multe lucruri şi dacă le-aţi făcut bine la timpul potrivit, în mod normal, acum nu prea ar trebui să aveţi probleme. Totuşi, această etapă este importantă pentru că oferă posibilitatea de a privi în ansamblu proiectul bazei de date, legăturile dintre părţile sale curente, o survolare a tuturor problemelor rezolvate. Este ca şi cum aţi terminat de construit o casă nouă, iar înainte de a vă muta în ea mai faceţi o verificare a lucrărilor. După această etapă proiectul este gata pentru a fi livrat beneficiarului. În primele 6 etape de elaborare a proiectului aţi:  Înţeles avantajele modelului relaţional de baze de date;  Învăţat să creaţi o declaraţie de intenţie pentru o nouă bază de date;  Învăţat ce sunt şi cum se definesc obiectivele misiunii pentru noua bază de date;  Efectuat o analiză complexă a bazei de date vechi;  Identificat cerinţele organizaţiei în privinţa informaţiilor;  Definit structuri de tabel potrivite;  Atribuit chei primare tabelelor;  Stabilit specificaţii de câmp;  Stabilit relaţii între tabele;  Definit reguli de desfăşurare a activităţii organizaţiei pentru care aţi proiectat baza de date;  Definit vederile adecvate; Cu toate acestea, este în avantajul dumneavoastră să faceţi o revizie finală a integrităţii generale a datelor din noua bază de date proiectată. Această revizie finală ar trebui să se bazeze pe principiul „decât să regret că n-am făcut-o, mai bine să regret că am făcut-o”, altfel spus e mai avantajos să revizuiesc şi să nu găsesc nimic, decât să rămână o anomalie care oricum va ieşi la iveală mai târziu, a cărui eliminare însemnând costuri înzecite.

102

Baze de date

Capitolul 3

Revizuirea şi îmbunătăţirea integrităţii datelor Revizuirea integrităţii datelor este o sarcină relativ simplă dacă folosiţi o abordare modulară, adică să revizuiţi secvenţial fiecare componentă a integrităţii generale a datelor: integritatea la nivel de tabel, la nivel de câmp, la nivel de relaţie, la regulile de desfăşurare a activităţii şi a vederilor. Dacă aţi urmat regulile de proiectare prezentate în acest curs, în mod normal nu trebuie să aveţi probleme. Mai departe vor fi prezentate pe scurt ideile pe care ar trebui reţinute în timp ce efectuaţi revizuirea. La nivel de tabel. Pentru a vă asigura că aţi stabilit corect integritatea la nivel de tabel, revizuiţi fiecare tabel şi asiguraţi-vă că tabelul respectă condiţiile următoare:  Nu există câmpuri duplicat în tabel;  Nu există câmpuri duplicate în tabel;  Nu există câmpuri cu mai multe valori în tabel;  Nu există câmpuri cu mai multe părţi în tabel;  Fiecare înregistrare din tabel este identificată de o valoare a cheii primare;  Fiecare cheie primară respectă setul de criterii de la definirea unei chei primare. Dacă întâlniţi vreo problemă, rezolvaţi-o folosind tehnicile învăţate. La nivel de câmp. Vă puteţi asigura că aţi stabilit corect integritatea la nivel de câmp după ce aţi făcut următoarele:  Aţi verificat ca fiecare câmp să respecte setul de criterii Elementele câmpului ideal;  Aţi verificat că aţi definit un set de specificaţii de câmp pentru fiecare câmp. La nivel de relaţie. Examinaţi fiecare relaţie între tabele pentru a vă asigura că aţi stabilit corect integritatea la nivel de relaţie. Aţi stabilit integritatea la acest nivel după ce aţi efectuat următoarele operaţii: 103

Baze de date

   

Capitolul 3

Aţi stabilit corect relaţia; Aţi definit regulile de ştergere adecvate; Aţi identificat tipul de participare pentru fiecare tabel al relaţiei; Aţi stabilit corect gradul de participare pentru fiecare tabel.

Dacă identificaţi vreo problemă legată de relaţie, rezolvaţi-o folosindu-vă de cunoştinţele referitoare la relaţii. La nivel de reguli de desfăşurare a activităţii. Vă puteţi asigura că regulile de desfăşurare a activităţii sunt solide, verificând următoarele aspecte:  Sunteţi sigur că fiecare regulă impune o restricţie care are sens;  Aţi determinat categoria potrivită pentru regulă;  Aţi definit şi stabilit corect fiecare regulă;  Aţi modificat elementele de specificaţie de câmp adecvate sau caracteristicile relaţiei între tabele;  Aţi stabilit tabelele de validare adecvate;  Aţi completat o Foaie cu specificaţii pentru fiecare regulă de desfăşurare a activităţii. Rezolvaţi problemele apărute folosindu-vă de cunoştinţele dobândite la stabilirea regulilor de desfăşurare a activităţii. La nivelul vederilor. Deşi vederile nu sunt legate direct de vreo componentă a integrităţii datelor, datorită importanţei lor, ar trebui să verificaţi toate structurile de vederi. La examinarea vederilor, veţi testa următoarele aspecte:  Fiecare vedere conţine tabelele de bază necesare pentru a furniza informaţiile solicitate;  Aţi atribuit câmpurile adecvate fiecărei vederi;  Fiecare câmp calculat furnizează informaţii pertinente sau îmbunătăţeşte maniera de prezentare a datelor;  Fiecare filtru returnează setul adecvat de înregistrări;  Fiecare vedere are o diagramă de vedere;  Fiecare vedere este însoţită de o Foaie de specificaţii pentru vedere. 104

Baze de date

Capitolul 3

După ce aţi toate aceste revizuiri, puteţi fi încredinţat că baza de date pe care aţi proiectat-o are o structură solidă, datele pe care le va conţine sunt unitare şi acceptabile, iar informaţiile pe care le veţi extrage din ea vor fi exacte. Alcătuirea documentaţiei bazei de date Pe parcursul procesului de proiectare a bazei de date, aţi generat mai multe liste, ciorne, foi de specificaţii şi diagrame utilizate pentru a înregistra diverse aspecte ale proiectării bazei de date. Toate acestea ar trebui să le arhivaţi într-un depozit centralizat, de preferat, un set de dosare. Proiectul propriu-zis al bazei de date va trebui să conţină numai documente necesare implementării bazei de date. Setul de documente care compun un proiect are următoarea structură:  Lista finală de tabele;  Foi de specificaţii pentru câmpuri;  Lista câmpurilor calculate;  Diagrame ale structurii tabelelor;  Diagrame de relaţii;  Foi de specificaţii pentru regulile de desfăşurare a activităţii;  Diagrame ale vederilor;  Foi de specificaţii pentru vederi. Toate aceste documente constituie setul complet de articole necesar structurii logice a bazei de date. După cum aţi observat, în timpul procesului de proiectare nu s-a făcut nici o referire la sistemul de gestiune a bazelor de date (SGBDR) în care va fi implementată baza de date. Asta înseamnă că un proiect de bază de date poate fi implementat în orice SGBDR. În paragraful următor va fi prezentat un studiu de caz din care veţi putea vedea la modul concret cum se proiectează o bază de date.

105

Baze de date

Capitolul 3

Studiu de caz. Proiectarea unei baze de date În acest paragraf va fi prezentată modalitatea practică de abordare a proiectării unei baze de date. Vor fi parcurse toate etapele de proiectare aşa cum au fost ele prezentate în acest capitol. După parcurgerea acestui paragraf, studenţii trebuie să ştie ce să facă pentru a proiecta corect o bază de date şi cum să arate un proiect. Declaraţia de intenţie Dorim o bază de date pentru o bibliotecă cu ajutorul căruia să gestionăm cărţile, cititorii şi împrumuturile care se fac de către această bibliotecă. Obiectivele misiunii În urma discuţiilor şi analizării documentelor obţinute de la diferite persoane aparţinând bibliotecii, împreună cu directorul ei am convenit că baza de date care va fi proiectată va îndeplini următoarele obiective: O evidenţă a cărţilor din bibliotecă. O evidenţă a cititorilor cu posibilitatea de a obţine informaţii despre natura profesiilor lor, a preocupărilor etc. Dorim să avem evidenţa împrumuturilor de cărţi. Alte informaţii utile.

Analiza bazei de date curente Informaţiile care există la ora actuală se găsesc în special în tabele Excel, documente Word şi registre scrise de mână. Preluarea informaţiilor se va prelua manual, iar acolo unde există posibilitatea vor fi concepute programe de transfer direct în tabelele bazei de date. Aici se pot aminti, în special, informaţiile conţinute în tabelele Excel. Această etapă trebuie să se termine cu o listă preliminară de câmpuri care se vor folosi în etapa următoare pentru crearea tabelelor. Aşa spune teoria şi aşa este corect, dar în practică această listă de câmpuri este finalizată odată cu tabelele din care fac parte. Nu este o abatere care să pună în pericol proiectul nostru, trebuie mai multă atenţie din partea noastră dar se câştigă timp preţios. Crearea structurilor de date 106

Baze de date

Capitolul 3

În urma analizării obiectivelor misiunii au rezultat tabelele cu date, stabilindu-se câmpurile şi cheile, primare sau externe. În această etapă se vor definitiva şi specificaţiile de câmp, completând formularul Specificaţii de câmp care se găseşte în anexa acestei cărţi. Lista cu tabelele bazei de date este prezentată în tabelul care urmează. Tabel tblAutori

tblEdituri

tblCarti

tblDomenii

tblImprumuturi

tblCititori

tblJudete

tblProfesii

Cimp AutorID ChP Nume Prenume Nationalitate DataN DataD EdituraID ChP Denumire Localitate Tara CarteID ChP AutorID ChE EdituraID ChE Denumire DomeniuID ChE AnAparitie Pagini Valoare Stoc DomeniuID ChP Denumire Explicatii ImprumutID ChP CarteID ChE CititorID ChE DataImprumut Perioada DataRestituire CititorID ChP Nume Prenume ProfesiaID ChE DataN Adresa Localitate JudetID ChE Observatii JudetID ChE Denumire Abreviere ProfesiaID ChP Denumire Explicatii

Tip data AutoNumber Character(150) Character(150) Character(15) Data/Time Data/Time AutoNumber Character(150) Character(150) Character(50) AutoNumber Long Integer Long Integer Character(250) Long Integer Integer Integer Single Integer AutoNumber Character(50) Character(250) AutoNumber Long Integer Long Integer Data/Time Integer Data/Time AutoNumber Character(150) Character(150) Long Integer Data/Time Character(150) Character(150) Long Integer Character(150) AutoNumber Character(75) Character(2) AutoNumber Character(75) Character(200)

107

Constringeri Not Null Not Null Not Null

Observatii

zz-lll-aa zz-lll-aa Not Null Not Null

Not Null Not Null Not Null Not Null Not Null

Not Null Not Null Not Null Not Null Not Null zz-lll-aa zz-lll-aa Not Null Not Null Not Null Not Null zz-lll-aa

Not Null Not Null Not Null Not Null Not Null Not Null

Baze de date

Capitolul 3

În acest moment avem toate tabelele bazei de date, cu cheile principale şi externe, cu specificaţiile de câmp pentru toate câmpurile existente în toată baza de date. Urmează partea ca mai spectaculoasă a proiectului nostru, stabilirea relaţiilor dintre tabelele bazei de date. Reamintesc că între 2 tabele nu poate exista decât o singură relaţie. De asemenea, reamintesc că există 3 tipuri de relaţii 1:1, 1:N şi N:N, iar ultima relaţie trebuie transformată în 2 relaţii 1:N, pentru a putea fi folosită în rapoarte. În acest sens, au apărut tabelele de legătură tblAutoriCarti, tblAutoriArticole, tblAutoriActivitati şi tblAutoriContracte. Documentaţia proiectului ar trebui să cuprindă doi de specificaţii pentru toate câmpurile tabelelor. Din motive de spaţiu, nu vom completa aici decât o astfel de foaie, care va fi prezentată în pagina următoare. Câmpul descris în această specificaţie va fi DataN.

108

Baze de date

Capitolul 3

Fig. 3.40. Foaia de specificaţie 109 pentru câmpul DataN

Baze de date

Capitolul 3

Determinarea şi instituirea relaţiilor între tabele Aceasta este etapa a 4-a din proiectarea unei baze de date. În urma parcurgerii ei, va rezulta diagrama structurii bazei de date, folosind notaţiile şi simbolurile învăţate în acest capitol. Este documentul care va fi folosit cel mai mult la implementarea bazei de date şi care conţine cea mai multă informaţie concentrată într-un spaţiu redus, de regulă o pagină tipărită. Pentru realizarea diagramelor pot fi folosite cunoştinţele dobândite la studiul Word-ului sau Excel-ului. Pentru cei care cunosc alte programe cu care se pot concepe diagrame, cum ar Microsoft Visio sau SmartDraw, această etapă va fi mult mai uşoară şi chiar plăcută. În cazul de faţă, s-a optat pentru o diagrama de relaţii scoasă din mediul Access, cu un program de captare de imagini (figura 3.41). Această imagine o să mai fie întâlnită cu ocazia aplicaţiilor pe care le veţi face în Access (cap. 5).

Fig. 3.41. Diagrama de relaţii a bazei de date ”Biblioteca”

Observaţi că relaţia 1:N, partea ”mai mulţi”, este aici notată cu simbolul ”infinit”.

110

Baze de date

Capitolul 3

După ce s-a creat diagrama bazei de date urmează stabilirea regulilor de desfăşurare a activităţii, care va fi abordată în pasul următor. Determinarea şi definirea regulilor de desfăşurare a activităţii În această etapă trebuie să determinăm regulile de desfăşurare a activităţii pentru baza de date proiectată. După cum ştim, există 2 tipuri de reguli de desfăşurare a activităţii, care se referă la câmp respectiv la relaţii. Din motive de spaţiu vom prezenta numai 2 formulare completate cu regulile respective, una pentru câmpuri şi cealaltă pentru relaţii, pentru a avea un model complet. Pentru stabilirea regulilor de desfăşurare a activităţii specifice unui câmp trebuie să parcurgem următoarele etape:  Alegem un tabel;  Analizăm fiecare câmp şi stabilim dacă acesta necesită vreo restricţie;  Dacă e necesar, definim regulile de desfăşurare a activităţii pentru acel câmp;  Dacă e necesar vom modifica şi elementele adecvate din specificaţia de camp;  Determinăm acţiunile care verifică regula;  Înregistrăm regula pe o Foaie de specificaţii pentru regula de desfăşurare a activităţii. Desigur, stabilirea regulilor de desfăşurare a activităţii nu este o treabă prea simplă, experienţa joacă aici un rol important. Pentru a vă ajuta în înţelegerea acestor aspecte se va prezenta mai jos o astfel de regulă cu care s-a completat o foaie de specificaţii. În figura 3.42 este prezentat un formular cu specificaţii pentru o regulă de desfăşurare a activităţii specifică unui câmp.

111

Baze de date

Capitolul 3

Fig. 3.42. Regulă de desfăşurare a activităţii specifică unui câmp

112

Baze de date

Capitolul 3

După ce s-au stabilit regulile de desfăşurare a activităţii specifice câmpurilor, este necesar să se stabilească asemenea reguli şi pentru relaţii. Pentru stabilirea regulilor de desfăşurare a activităţii specifice unei relaţii trebuie să parcurgem următoarele etape:  Selectăm o relaţie;  Revizuim relaţia şi determinăm dacă aceasta necesită vreo restricţie;  Definim regulile de desfăşurare a activităţii pentru această relaţie;  Stabilim regula modificând în acelaşi timp caracteristicile adecvate relaţiei;  Determinăm ce acţiuni verifică regula;  Notăm regula pe o Foaie de specificaţii pentru regula de desfăşurare a activităţii. În figura 3.43 este prezentat un formular cu specificaţii pentru o regulă de desfăşurare a activităţii specifică unei relaţii.

113

Baze de date

Capitolul 3

Fig. 3.43. Regulă de desfăşurare a activităţii specifică unei relaţii

114

Baze de date

Capitolul 3

Determinarea şi definirea vederilor Oricâtă experienţă am avea, e greu de presupus că vom putea identifica toate vederile în faza de proiectare. Nici nu ne propunem acest lucru. Scopul acestui paragraf este de identifica câteva vederi ale proiectului la care lucrăm şi a completa un formular de specificaţii pentru una dintre ele. Iată câteva vederi care n-ar trebui să lispsească din proiectul nostru:  Cititorii cu profesiile lor;  Cărţile;  Editurile; Aceste vederi îşi extrag datele dintr-unul sau mai multe tabele. Pentru exemplificare să luăm vederea ”Lista cititorilor bibliotecii” a cărei structură o vedem în figura 3.44.

tblCititori tblJudete JudetID Denumire Abreviere

CititorID Nume Prenume ProfesiaID …….. JudetID

Lista cititori Cititor Profesia Adresa

Fig. 3.44. Diagrama de vedere ”Lista cititorilor bibliotecii”

115

tblProfesii ProfesiaID Denumirea Explicatii

Baze de date

Capitolul 3

Observaţi că această vedere are ca tabele de bază tabelele tblJudete, tblCititori şi tblProfesii. Între aceste tabele există relaţii ”unu la mai mulţi” după cum se poate vedea din diagramă. Observaţi, de asemenea, că există un câmp calculat, câmpul Cititor care rezultă din adunarea(concatenarea) câmpurilor Nume şi Prenume. În figura 3.45 este prezentată Foaia de specificaţii pentru vederea ” Lista cititorilor bibliotecii”. Studiaţi cu atenţie acest document şi încercaţi să faceţi foi de specificaţii pentru celelalte vederi.

116

Baze de date

Capitolul 3

Fig. 3.45. Foaie de specificaţii117 pentru vederea ”Lista cititorilor bibliotecii”

Baze de date

Capitolul 3

Verificarea integrităţii datelor În această etapă sunt rezolvate toate problemele legate de proiect. Practic se poate trece la implementarea bazei de date într-un SGBDR, dar o ultimă verificare a proiectului nu este de prisos, deoarece ar fi putut scăpa unele mici erori care se vor descoperi oricum într-o anumită fază a procesului de implementare. Se verifică toate documentele proiectului, plecând de la declaraţia de intenţie şi obiectivele misiunii, pentru a verifica dacă proiectul şi-a atins scopul. Liniştea pe care o dobândiţi ştiind că aveţi o bază de date temeinic proiectată merită timpul petrecut şi efortul depus pentru această revizuire finală. Informaţiile pe care le va furniza această bază de date vor fi exacte. Este un fel de recepţie finală a proiectului, făcută de executantul său. Presupunem că aţi verificat integritatea datelor la nivel de tabel, câmp, relaţie, desfăşurarea activităţii şi la nivel de vedere. Din păcate, această etapă nu are un document bine definit care să ateste că a fost făcută. Concluzii privind proiectarea bazelor de date relaţionale Proiectarea bazelor de date relaţionale este o activitate complexă, executată, de regulă, de o echipă de specialişti formată din informaticieni, ingineri şi economişti. În acest studiu de caz, aţi parcurs toate etapele elaborării unui proiect temeinic de baze de date. După cum spuneam, orice bază de date are un scop de la care nu trebuie să ne abatem nici o clipă. E adevărat că unele obiective ale bazei de date nu sunt clar exprimate de către beneficiari, dar asta nu e o problemă pentru că echipa de dezvoltare poate să clarifice aceste aspecte chiar de la început. Pe tot parcursul elaborării proiectului, aţi adunat o documentaţie consistentă care va fi de un real folos în procesul de implementare, mai ales atunci când vor trebui operate modificări în proiect. Dacă aţi înţeles etapele prin care aţi trecut, dacă aţi completat formularele cerute (foile de specificaţii pentru câmp, relaţie, vedere) înseamnă că puteţi deveni un component de bază al unei echipe de dezvoltare a unei aplicaţii de baze de date. Ce rol aţi putea avea într-o echipă de dezvoltare a aplicaţiilor de baze de date? Aţi putea definitiva declaraţia de intenţie şi obiectivele misiunii, aţi 118

Baze de date

Capitolul 3

putea lucra la completarea formularelor de specificaţii pentru câmp, relaţie, vedere şi reguli de desfăşurare a activităţii. Un rol important aţi putea avea în culegerea de informaţii de la viitorii utilizatori ai bazei de date. Dacă sunteţi angajatul firmei beneficiare, veţi putea colabora eficient cu echipa de dezvoltare, ca viitor utilizator al bazei de date. Dacă împrejurările o cer, aţi putea deveni administrator al bazei de date, o muncă extrem de importantă şi cu mare resposabilitate (vezi Anexa A).

119

Baze de date

Capitolul 4

Capitolul 4. Iniţiere în limbajul SQL În acest capitol vom studia elementele de bază ale limbajului de interogare şi manipulare a bazelor de date SQL. Vom folosi acest limbaj pentru a scoate informaţii dintr-o bază de date, pentru a modifica datele tabelelor şi chiar pentru crearea de noi tabele sau ştergerea lor din baza de date. Abordarea limbajului se va face de la simplu spre complex, iar exemplele prezentate vor fi foarte sugestive pentru înţelegerea operaţiunilor executate.

Prezentare generală Limbajul SQL este abrevierea de la Structured Query Language (limbaj structurat de interogare) şi este un limbaj conceput special pentru comunicarea cu bazele de date. Spre deosebire de alte limbaje de programare, SQL se compune din foarte puţine cuvinte (instrucţiuni), ceea ce face să fie uşor de învăţat şi folosit. Toate bazele de date importante acceptă limbajul SQL, aşa că învăţarea lui este de un real folos. În ciuda aparentei simplităţi, SQL este un limbaj foarte puternic, cu care, dacă-i utilizaţi cu inteligenţă facilităţile, puteţi efectua operaţii complexe şi sofisticate cu bazele de date. Limbajul SQL este un limbaj neprocedural sau declarativ deoarece nu conţine instrucţiuni precum IF, GOTO, WHILE sau altele care să ofere un flux de control; utilizatorul lui descrie numai informaţiile pe care vrea să le obţină în urma interogării bazei de date, fără a fi nevoie să stabilească şi modalităţile de a ajunge la rezultatele dorite. Este ceea ce visează fiecare dintre noi, nu? Există un anumit grad de standardizare a limbajului SQL, mai multe SGBDR recunoscând principalele instrucţiuni ale acestuia. Pe plan mondial, standardul în domeniu este considerat ANSI (American National Standards Institute) SQL care are în vedere atât aspectele de definire, interogare, manipulare a datelor, procesare a tranzacţiilor, cât şi caracteristicile complexe privind securitatea informaţiilor. 120

Baze de date

Capitolul 4

Se cunosc în literatura de specialitate trei metode de bază privind implementarea limbajului SQL şi anume: cea prin apelare directă, cea modulară şi cea de tip încapsulat. Prima metodă costă în introducerea instrucţiunilor SQL de la prompter, cea de a doua foloseşte anumite proceduri apelate de programele aplicaţiei, iar cea de a treia variantă de implementare are în vedere instrucţiuni încapsulate în codul program, fiind de tip static şi dinamic. Instrucţiunile SQL se grupează astfel:  Instrucţiuni de definire a datelor;  Instrucţiuni de manipulare a datelor (adăugare, modificare, ştergere);  Instrucţiuni de selecţie a datelor (consultare a bazei de date);  Instrucţiuni de procesare a tranzacţiilor. După cum spuneam, instrucţiunile SQL sunt puţine, dar ele sunt completate cu clauze care le măresc puterea. Practic, noi trebuie să înţelegem şi să folosim clauzele care însoţesc instrucţiunile. Sintaxa folosită nu este pretenţioasă, singura noastră grijă este să folosim expresii lizibile, prin evidenţierea instrucţiunilor şi a parametrilor lor. În cadrul acestui curs vom folosi limbajul SQL corespunzător programului ACCESS. În acest capitol vom învăţa folosirea limbajului scriind expresii SQL pe hârtie folosind o bază de date existentă, completată cu date. Abia în capitolul următor vom folosi limbajul SQL în cadrul programului ACCESS. Baza de date pe care o vom folosi în acest capitol, cea pe care o să ne exersăm talentele, este cea proiectată în capitolul anterior şi se numeşte BD_ITM, a cărei structură este cunoscută. Pentru unele instrucţiuni vom folosi şi alte baze de date dacă necesităţile vor impune acest lucru. Metoda pe care o vom folosi pentru a învăţa limbajul SQL este cea a învăţării „din mers” a instrucţiunilor şi clauzelor, adică executăm operaţiuni şi învăţăm instrucţiunile folosite. Operaţiunile vor fi în aşa fel alese ca să acopere tot spectrul practic pe care o să-l întâlniţi în realitate. Într-o anexă vor fi sistematizate instrucţiunile SQL cu clauzele şi sintaxa lor. Această anexă vă va fi de un real folos după ce veţi dobândi o anumită experienţă în utilizarea limbajului SQL. 121

Baze de date

Capitolul 4

Operaţiuni simple folosind limbajul SQL Regăsirea datelor Regăsirea datelor se face cu instrucţiunea SELECT, folosită pentru a regăsi una sau mai multe coloane. Aceasta este cea mai folosită instrucţiune din SQL. Din tabelul tblStudenti prezentat în figura 4.1 ne propunem să extragem numele şi prenumele studenţilor. StudID 1 2 3 4 5 6 7 8 9 10

Nume Bogdan Meruta Pop Bucur Chirila Cotirla Cotoara Cozma Damian Farcas

Init P. I. T. P. I. L. G. D. N. I.

Prenume Mircea Florin Cosmin Marius Traian Mihaela Laura Raluca Adina Ovidiu Dumitru Daniel Calin Florin

Sectia IEI IEI IEI IEI IEI TCM TCM TCM MEC MEC

An 1 3 2 2 3 1 1 2 4 4

Fig. 4.1. Tabelul tblStudenti simplificat

Expresie SQL: SELECT Nume, Prenume FROM tblStudenti;

Rezultat: Nume Bogdan Meruta Pop Bucur Chirila Cotirla Cotoara Cozma Damian Farcas

Prenume Mircea Florin Cosmin Marius Traian Mihaela Laura Raluca Adina Ovidiu Dumitru Daniel Calin Florin

122

Grupa 1311 1332 1321 1321 1331 1111 1111 1121 1241 1241

Stare Bugetar Bugetar Bugetar Bugetar Bugetar Bugetar Bugetar Bugetar Bugetar Taxa

Baze de date

Capitolul 4

Observaţi expresia SQL care se citeşte astfel: selectează coloanele Nume şi Prenume din tabelul tblStudenti. S-a folosit şi clauza FROM, aşa cum se vede. Rezultatul obţinut este evident. Dacă doriţi să selectaţi toate coloanele tabelului se foloseşte expresia următoare: Expresie SQL: SELECT * FROM tblStudenti

În locul listei de coloane se pune acest simbol „ * ”. Sortarea datelor Prin sortarea datelor se înţelege aranjarea înregistrărilor unui tabel într-o anumită ordine, de regulă, alfabetică sau crescătoare/descrescătoare. Sortarea datelor se face cu ajutorul clauzei ORDER BY a instrucţiunii SELECT. La tabelul din figura 4.1 ne propunem să scoatem numai numele şi prenumele studenţilor dar în ordine alfabetică. Expresie SQL: SELECT Nume, Prenume FROM tblStudenti ORDER BY Nume;

Rezultat: Nume Bogdan Bucur Chirila Cotirla Cotoara Cozma Damian Farcas Meruta Pop

Prenume Mircea Florin Mihaela Laura Raluca Adina Ovidiu Dumitru Daniel Calin Florin Cosmin Marius Traian

123

Baze de date

Capitolul 4

Observaţi clauza ORDER BY care ordonează înregistrările în ordine alfabetică după valorile din câmpul Nume. Se pune întrebare, ce ne facem dacă vrem să ordonăm invers alfabetic (de la Z la A)? Sau dacă avem un câmp numeric şi dorim să ordonăm descrescător după acest câmp. Iată răspunsul:  Pentru a indica ordinea descrescătoare de sortare se foloseşte cuvântul cheie DESC.  Dacă câmpul după care se face sortarea este alfanumeric, sortarea se face alphabetic, iar dacă este numeric sau de dată calendaristică, sortarea se face crescător/descrescător.  Dacă nu se indică direcţia de sortare, se ia sortarea crescătoare care este implicită. (Cazul prezentat.) Iată cum arată o expresie SQL în care apare şi cuvântul cheie DESC: Expresie SQL: SELECT Nume, Prenume FROM tblStudenti ORDER BY Nume DESC

Reţineţi că rezultatul sortării datelor este un tabel care are acelaşi număr de înregistrări ca şi originalul. Filtrarea datelor Prin filtrarea datelor se înţelege extragerea dintr-un tabel numai a anumitor înregistrări de care avem nevoie, de exemplu, din tabelul de studenţi avem nevoie numai de cei din anul 2. Pentru a executa această operaţiune veţi folosi clauza WHERE a instrucţiunii SELECT. Regăsirea numai a înregistrărilor dorite, presupune includerea în expresia SQL a unui criteriu de căutare a înregistrărilor dorite. Într-o instrucţiune SELECT, datele sunt filtrate prin specificarea criteriilor de căutare în clauza WHERE. Locul acesteia este imediat după numele tabelului (clauza FROM), ca în exemplul următor. Fie tabelul din figura 4.1.

124

Baze de date

Capitolul 4

Ne propunem să filtrăm studenţii din anul 2. expresia SQL este următoarea: Expresie SQL: SELECT StudID, Nume, Init, Prenume, Sectia, Grupa FROM tblStudenti WHERE An = ”2”;

Rezultat: StudID 3 4 8

Nume Pop Bucur Cozma

Init T. P. D.

Prenume Marius Traian Mihaela Dumitru

Sectia IEI IEI TCM

Grupa 1321 1321 1121

Operatorii clauzei WHERE

Clauza WHERE pe care am examinat-o a testat egalitatea – determină dacă o coloană conţine valoarea specificată. Limbajul SQL acceptă mai mulţi operatori condiţionali, după cum urmează:  = Egalitate  <> Non-egalitate  != Non-egalitate  < Mai mic decât  <= Mai mic sau egal cu  !< Nu mai mic decât  > Mai mare decât  >= Mai mare sau egal cu  !> Nu mai mare decât  BETWEEN Între două valori specificate  IS NULL Este o valoare NULL Observaţi că pentru non-egalitate există două simboluri, aceasta pentru că diversele SGBDR-uri acceptă pe unul sau altul dintre ele.

125

Baze de date

Capitolul 4

Iată câteva cazuri concrete de folosire a operatorilor: Interval de valori: WHERE Pret BETWEEN 2.5 AND 10; (afişează toate înregistrările care au în coloana „Pret” valori între 2.5 şi 10). Valoare NULL: WHERE Pret IS NULL; (afişează toate înregistrările care nu au preţ). Non-egalitate: WHERE Stare <> ”Bugetar”; (afişează toate înregistrările din tabelul studenţi, folosit mai înainte, care nu sunt bugetari). Este evident că putem formula şi altfel condiţia, dar aici am folosit non-egalitatea. Ceilalţi operatori se folosesc la fel ca cel de egalitate prezentat puţin mai în faţă. Filtrare avansată

Filtrările prezentate mai sus se întâlnesc mai rar în practică deoarece sunt foarte simple. Filtrările pe care le veţi folosi în mod curent, sunt filtrări mai complicate la care criteriile sunt exprimate prin expresii complexe. Aceste criterii creează condiţii puternice de căutare. Vom folosi alţi operatori cum sunt AND, OR, NOT şi IN. De multe ori, filtrarea după o coloană nu rezolvă problema pe care o avem. Pentru a filtra după mai multe coloane se foloseşte operatorul AND. Fie tabelul din figura 4.2. Ne propunem să facem diferite filtrări. StudID 1 2 3 4 5 6 7 8 9 10

Nume Bogdan Meruta Pop Bucur Pop Cotirla Cotoara Cozma Damian Cozma

Init P. I. T. P. I. L. G. D. N. I.

Prenume Mircea Florin Cosmin Marius Traian Mihaela Laura Raluca Adina Ovidiu Dumitru Daniel Calin Florin

Sectia IEI IEI IEI IMPI IEI TCM TCM TCM MEC MEC

Fig. 4.2. Tabel cu studenţi

126

An 1 1 2 2 3 1 1 2 4 4

Grupa 1311 1312 1321 1321 1331 1111 1111 1121 1241 1241

Stare Bugetar Taxa Bugetar Bugetar Taxa Bugetar Bugetar Bugetar Bugetar Taxa

Baze de date

Capitolul 4

Operatorul AND. Prima filtrare ar fi studenţii de la IEI din anul 1. Iată expresia SQL: Expresie SQL: SELECT Nume, Prenume, Grupa, Stare FROM tblStudenti WHERE Sectia=”IEI” AND An = ”1”;

Rezultat: Nume Bogdan Meruta

Prenume Mircea Florin Cosmin

Grupa 1311 1312

Stare Bugetar Taxa

Urmăriţi expresia SQL şi verificaţi rezultatul obţinut. Încercaţi şi alte filtrări asemănătoare. Observaţi folosirea operatorului AND. Cum ar trebui modificată expresia SQL, pentru a afişa rezultatul în ordine alfabetică inversă? Operatorul OR. O altă filtrare pe care ne-o propunem, este să filtrăm studenţii din anul 2 de la IEI sau TCM. Expresie SQL: SELECT Nume, Prenume,Sectia, Grupa, Stare FROM tblStudenti WHERE (Sectia=”IEI” OR Sectia=”TCM”) AND An = ”2”;

Rezultat: Nume Pop Cozma

Prenume Marius Traian Dumitru

Sectia IEI TCM

Grupa 1321 1121

Stare Bugetar Bugetar

Observaţi folosirea parametrilor OR şi AND, respectiv apariţia celor două paranteze. Aceste paranteze au legătură cu ordinea operaţiilor OR şi AND. În ordinea operaţiilor, operatorul AND se execută înaintea operatorului OR, ceea ce ar duce la rezultate eronate, de aceea a fost pus operatorul OR în paranteză, ca să-l execute primul, ştiut fiind că parantezele au prioritate la execuţie. Operatorul IN. Folosirea acestui operator are ca scop specificarea unui domeniu de condiţii, oricare dintre ele putând fi îndeplinite. Operatorul IN 127

Baze de date

Capitolul 4

necesită o listă de valori valide, care să fie separate prin virgule şi cuprinse între paranteze. Ne propunem să alegem din tabelul din figura 4.2 toţi studenţii care au numele Pop şi Cozma. Expresie SQL: SELECT Nume, Prenume,Sectia, Grupa, Stare FROM tblStudenti WHERE Nume IN (“Pop”, “Cozma”);

Rezultat: Nume Pop Pop Cozma Cozma

Prenume Marius Traian Laura Dumitru Calin Florin

Sectia IEI IEI TCM MEC

Grupa 1321 1331 1121 1241

Stare Bugetar Taxa Bugetar Taxa

Din analiza acestui exemplu, putem observa fără greutate că operatorul IN face cam acelaşi lucru ca şi operatorul OR, deci se poate scrie o expresie SQL cu acesta. Care este această expresie? Se pune, pe bună dreptate, întrebarea de ce mai avem nevoie de încă un operator dacă avem unul care face acelaşi lucru. Răspunsul este că operatorul IN are unele avantaje care îl fac de preferat faţă de operatorul OR. Iată aceste avantaje:  Când lucraţi cu liste lungi de opţiuni valide, sintaxa operatorului IN este mai simplă şi uşor de citit, principalul avantaj.  Ordinea de evaluare este mai simplu de gestionat, când operatorul IN este folosit în asociaţie cu operatorii AND şi OR.  Aproape totdeauna, operatorii IN se execută mai rapid decât listele de operatori OR.  Un mare avantaj este că operatorul IN poate să conţină o altă instrucţiune SELECT, şi astfel vă permite să construiţi clauze WHERE foarte dinamice. Acest aspect va fi reluat mai târziu. Operatorul NOT. Acest operator al clauzei WHERE are o singură funcţie – neagă orice condiţie care îl urmează. Deoarece NOT nu este utilizat niciodată în sine (totdeauna se foloseşte în asociaţie cu alt operator), sintaxa lui e diferită de toţi ceilalţi operatori. Spre deosebire de alţi 128

Baze de date

Capitolul 4

operatori, cuvântul cheie NOT poate fi utilizat înaintea coloanei după care se face filtrarea, nu imediat după aceasta. Iată un exemplu sugestiv, extragerea studenţilor nebugetari din tabelul din figura 4.2. Expresie SQL: SELECT Nume, Prenume,Sectia, Grupa, Stare FROM tblStudenti WHERE NOT Stare=”Bugetar”;

Rezultat: Nume Meruta Pop Cozma

Prenume Cosmin Laura Calin Florin

Sectia IEI IEI MEC

Grupa 1312 1331 1241

Stare Taxa Taxa Taxa

După cum se vede, acelaşi lucru îl puteam obţine şi cu operatorul „<>”. Iarăşi se pune întrebarea de ce să folosim, totuşi, operatorul NOT? Întradevăr, pentru clauzele WHERE simple, cum e cea prezentată, nu se poate spune că ar exista un avantaj real în folosirea operatorului NOT. Acesta este însă foarte util în clauzele mai complexe. De exemplu, dacă folosiţi operatorul NOT în asociaţie cu un operator IN, va fi mult mai simplu să găsiţi toate înregistrările care nu corespund cu o listă de criterii. Operatorul LIKE. Aici veţi învăţa ce sunt caracterele de înlocuire, cum se folosesc ele şi cum să faceţi căutări cu ajutorul lor. Până acuma, toţi operatorii, foloseau valori cunoscute, iar ei se ocupau de căutarea corespondenţelor dintre valori, dacă sunt mai mari sau mai mici decât altele, dacă verifică un domeniu de valori etc. De multe ori apare necesitatea filtrării înregistrărilor după unele criterii care nu folosesc valori cunoscute în totalitate. De exemplu, doriţi să căutaţi nume de persoane care încep cu o literă, care conţin un grup de litere etc. Acest lucru nu se poate face cu criterii simple comparare. O soluţie, pe care ne-o propune SQL, este folosirea caracterelor de înlocuire. Caracterele de înlocuire sunt caractere ce au înţelesuri speciale în clauzele WHERE din SQL, iar limbajul SQL acceptă diverse tipuri de caractere de înlocuire.

129

Baze de date

Capitolul 4

Pentru a utiliza caracterele de înlocuire în clauzele de căutare, trebuie utilizat operatorul LIKE. Acesta anunţă sistemul de gestiune a bazei de date că în următorul model de căutare se va folosi o potrivire după caractere de înlocuire, nu o simplă potrivire de egalitate. Căutarea cu caractere de înlocuire poate fi utilizată numai cu câmpuri de tip text. Reţineţi acest lucru! În continuare vor fi prezentate caracterele de înlocuire folosite de programul ACCESS. Caracterul de înlocuire *. Este cel mai frecvent utilizat. Într-un şir de căutare, „ * ” înseamnă „corespunde cu oricâte apariţii a oricărui caracter”. Exemplul care urmează vă va ajuta să înţelegeţi acest caracter.

StudID 1 2 3 4 5 6 7 8 9 10

Nume Bogdan Brustur Popescu Brucan Pop Cotirla Popa Popovici Branea Cozma

Init P. I. T. P. I. L. G. D. N. I.

Prenume Mircea Florin Cosmin Marius Traian Mihaela Laura Raluca Adina Ovidiu Dumitru Daniel Calin Florin

Sectia IEI IEI IEI IMPI IEI TCM TCM TCM MEC MEC

Fig. 4.3. Tabel cu studenţi

130

An 1 1 2 2 3 1 1 2 4 4

Grupa 1311 1312 1321 1321 1331 1111 1111 1121 1241 1241

Stare Bugetar Taxa Bugetar Bugetar Taxa Bugetar Bugetar Bugetar Bugetar Taxa

Baze de date

Capitolul 4

Ne propunem să filtrăm toate înregistrările în care numele studenţilor, din tabelul din figura 4.3, începe cu „Pop”. Expresie SQL: SELECT Nume, Prenume,Sectia, Grupa, Stare FROM tblStudenti WHERE Nume LIKE ”Pop*” ORDER BY Nume;

Rezultat: Nume Pop Popa Popescu Popovici

Prenume Laura Ovidiu Marius Traian Dumitru

Sectia IEI TCM IEI TCM

Grupa 1331 1111 1321 1121

Stare Taxa Bugetar Bugetar Bugetar

Observaţi ghilimelele care se pun şi ordonarea rezultatului după câmpul Nume. Încercaţi şi alte filtrări folosind această tehnică. Caracterul de înlocuire „ ? ”. Acest caracter (semnul întrebării) este utilizat la fel ca simbolul „ * ”, dar nu asigură corespondenţa mai multor caractere, ci numai a unuia singur. Exemplul care urmează vă ajută să înţelegeţi folosirea lui. Folosind tabelul din figura 4.3, scrieţi expresii SQL care să ilustreze folosirea acestui caracter de înlocuire. Observaţie! În diferite SGBDR semnele de înlocuire ar putea să fie diferite. Astfel, în Oracle „ * ” este înlocuit cu „ % ”, iar „ ? ” este înlocuit cu liniuţa de subliniere „ _ ”. Pentru a nu avea probleme este bine să studiaţi documentaţia SGBDR-ului pe care îl veţi folosi.

131

Baze de date

Capitolul 4

Operaţiuni avansate folosind limbajul SQL Câmpuri calculate După ştiţi de la proiectarea bazelor de date, o regulă de bază ne spune că fiecare câmp trebuie să fie independent, adică valoare sa să nu depindă de valorile din alte câmpuri. Exemplul clasic care se poate da aici este cel al câmpului Valoare care nu trebuie să apară într-un tabel care are Pretul unitar şi Cantitatea, dar avem nevoie de acest câmp care este rezultatul înmulţirii dintre preţ şi cantitate. Ei bine, acest câmp trebuie calculat. Un alt exemplu este cel al adresei care se compune din concatenarea rezultatelor din mai multe câmpuri. În ambele exemple, datele stocate în tabele nu sunt exact ceea ce are nevoie aplicaţia dumneavoastră. În loc să regăsiţi datele aşa cum sunt, pentru ca după aceea să le reformataţi în aplicaţia client sau în raport, doriţi să regăsiţi datele transformate, calculate sau reformatate direct din baza de date. Aici intervin câmpurile cu valori calculate, pe care le vom numi în continuare câmpuri calculate. Spre deosebire de toate coloanele de până acum, câmpurile calculate nu există, de fapt, în baza de date. Un câmp calculat este creat din mers, în interiorul unei instrucţiuni SELECT din limbajul SQL. De menţionat faptul că numai baza de date ştie care coloane dintr-o instrucţiune SELECT sunt realmente coloane din tabele şi care sunt câmpuri calculate. Din perspectiva unui client, datele unui câmp calculat sunt returnate în acelaşi mod ca şi datele din oricare coloană. Cel mai simplu mod de a înţelege crearea câmpurilor calculate este de a alege exemple sugestive pe care să le comentăm. Câmpuri calculate prin concatenare. De multe ori apare necesitatea concatenării valorilor text din mai multe coloane. De exemplu, într-un raport trebuie să scriem identitatea unei persoane formată din numele complet, aşa cum se obişnuieşte în practică. Să scriem expresia SQL care face acest lucru pentru persoanele din tabelul din figura 4.3.

132

Baze de date

Capitolul 4

Expresie SQL: SELECT Nume + “ “ + Init + “ “ + Prenume AS Student, Sectia, An, Grupa, Stare FROM tblStudenti ORDER BY Nume;

Rezultat: Student Bogdan P. Mircea Florin Branea N. Daniel Brucan P. Mihaela Brustur I. Cosmin Cotirla L. Raluca Adina Cozma I. Calin Florin Pop I. Laura Popa G. Ovidiu Popescu T. Marius Traian Popovici D. Dumitru

Sectia IEI MEC IMPI IEI TCM MEC IEI TCM IEI TCM

An 1 4 2 1 1 4 3 1 2 2

Grupa 1311 1241 1321 1312 1111 1241 1331 1111 1321 1121

Stare Bugetar Bugetar Bugetar Taxa Bugetar Taxa Taxa Bugetar Bugetar Bugetar

Observaţi sintaxa folosită şi ceva nou a apărut, cuvântul cheie AS după care urmează cuvântul Student, pe care îl regăsim în capul de tabel, ca nume a noului câmp, obţinut prin concatenarea celor trei. Cuvântul cheie AS introduce un alias care este un nou nume dat unui câmp. Reţineţi această tehnică de creare a unor câmpuri. Câmpuri calculate aritmetic. Aceste câmpuri calculate rezultă după efectuarea unor calcule aritmetice asupra datelor regăsite. Pentru a înţelege mecanismul creării acestor câmpuri, vom lua un exemplu practic. Presupunem că avem un tabel în care ţinem intrările într-o magazie de produse, al unei firme de comerţ cu piese auto. Tabelul se numeşte tblProduse şi are coloanele Cod, Denumire, Furnizor, PU, Cantitate. Se cere un raport al intrărilor în magazie în care apare şi câmpul Valoare, obţinut prin produsul câmpurilor PU şi Cantitate. În figura 4.4 este prezentat acest raport.

133

Baze de date Cod 1001 1023 1231 1089 1904

Capitolul 4

Denumire Bujie DK1 Acumulator 56A Parbriz VW Antigel -30 Ulei PKT 1

Furnizor Sinterom SA Rombat SA Cobra SRL Promaxim SRL Calota SRL

PU 12 124 512 5.2 6.4

Cantitate 30 25 12 50 60

Valoare 360 3100 6144 26 384

Fig. 4.4. Raport cu câmpul valoare calculate

Expresie SQL: SELECT Cod, Denumire, Furnizor, PU, Cantitate, PU*Cantitate AS Valoare FROM tblProduse;

Observaţi şi reţineţi sintaxa folosită pentru crearea noului câmp VALOARE.

Funcţii pentru manipularea datelor Ca aproape toate limbajele de programare, SQL acceptă folosirea funcţiilor pentru manipularea datelor. Funcţiile sunt operaţii care, de obicei, se efectuează asupra datelor, în general pentru a facilita transformarea şi manipularea acestora. Trebuie să aveţi în vedere că fiecare SGBDR are propriile funcţii şi propria sintaxă, chiar dacă ele seamănă foarte mult, există mici diferenţe pe care trebuie să le ştiţi studiind documentaţia sistemului pe care îl folosiţi. Descrierea funcţiilor din acest paragraf nu o să vă creeze probleme în folosirea funcţiilor pentru orice SGBDR întâlnit în practică. Majoritatea implementărilor SQL acceptă următoarele tipuri de funcţii:  Funcţiile text sunt folosite la manipularea şirurilor de text (de exemplu, pentru ajustarea sau completarea valorilor în majuscule şi minuscule).  Funcţiile numerice sunt folosite pentru operaţii matematice cu date numerice (de exemplu, pentru returnarea valorilor absolute şi efectuarea de calcule algebrice).

134

Baze de date

Capitolul 4

 Funcţii de dată şi timp sunt folosite la manipularea valorilor calendaristice de dată şi oră, şi la extragerea unor componente caracteristice din aceste valori (an, lună, zi, oră) pentru a verifica validitatea unor date introduse. Funcţiile text. În această categorie vom regăsi clasicele funcţii de text care se găsesc în toate limbajele de programare. Iată-le pe cele mai folosite:  LEFT() şirului.  RIGHT()  LENGTH()  LOWER()  UPPER()  LTRIM()  RTRIM()

- returnează caracterele indicate din stânga - returnează caracterele indicate din dreapta şirului. - returnează lungimea unui şir. - transformă toate caracterele şirului în minuscule. - transformă toate caracterele şirului în majuscule. - înlătură spaţiile albe din stânga şirului. - înlătură spaţiile albe din stânga şirului.

Funcţiile numerice. În această categorie intră funcţiile folosite pentru calcule algebrice, geometrice şi trigonometrice. Sunt mai puţin folosite la bazele de date decât celelalte tipuri. Iată-le pe cele mai folosite:           

ABS() COS() SIN() TAN() SQRT() indicat. PI() AVG() COUNT() MAX() coloană. MIN() coloană. SUM()

- returnează valoarea absolută a unui număr. - returnează cosinusul unui unghi indicat. - returnează sinusul unui unghi indicat. - returnează tangenta unui unghi indicat. - returnează rădăcina pătrată a unui număr - returnează valoarea lui PI. - returnează valoarea medie a unei coloane. - returnează numărul de linii dintr-o coloană. - returnează valoarea cea mai mare dintr-o - returnează valoarea cea mai mică dintr-o - returnează suma valorilor unei coloane.

135

Baze de date

Capitolul 4

Ultimele cinci funcţii se mai numesc şi funcţii agregat, deoarece au în spate algoritmi complecşi. Funcţiile de dată şi timp. Valorile datei şi orei sunt stocate în baza de date în formate speciale, de aceea este nevoie de funcţii speciale pentru a le manipula. Ele sunt cele mai importante funcţii din limbajul SQL. Aceste funcţii ne ajută să extrageţi ora, luna, ziua, anul dintr-o astfel de dată şi să faceţi diferenţa dintre două date calendaristice. Cele mai importante sunt:  Date()

- returnează data curentă a sistemului.

 DateAdd(interval, numar, data) – returnează o dată rezultată din adăugarea unui interval la data specificată. Parametrul “interval” poate avea valorile: yyyy – an, q – trimestru, m – lună, d – zi etc. Exemple: DateAdd(„yyyy‟,3,#22/11/2003#) – returnează 22/11/2006 DateAdd(„m‟,5,#22/11/2003#) – returnează 22/04/2004

 DateDiff(interval, data1, data2) – returnează diferenţa dintre două date calendaristice, bazate pe intervalul specificat. Exemple: DateDiff(‘d’,#15/10/2003#,#22/11/2003#) – returnează 38

 Day(data) – returnează numărul de ordine al zilei lunii dintr-o dată calendaristică. Exemplu Day(#15/10/2003) – returnează 15.  Hour(data) – returnează ora dintr-o dată calendaristică.  Month(data) - returnează luna dintr-o dată calendaristică.  Now(data) – returnează data şi ora curentă a calculatorului pe care lucraţi.  Time() – returnează ora calculatorului dumneavoastră.  Year(data) – returnează anul dintr-o dată calendaristică. Alte funcţii de dată şi sintaxa lor puteţi găsi în documentaţia SGBDR pe care îl folosiţi.

136

Baze de date

Capitolul 4

Gruparea datelor Crearea grupurilor

Am văzut în paragraful precedent că funcţiile agregat din SQL pot fi utilizate pentru a genera sumare de date. Aceasta vă permite să număraţi liniile, să calculaţi sume şi medii, respectiv să obţineţi valorile cele mai mari sau cele mai mici, fără necesitatea regăsirii tuturor datelor. Toate calculele de până acum au fost efectuate asupra tuturor datelor dintrun tabel, sau asupra datelor ce corespundeau clauze WHERE specifice. Dacă aţi dori să faceţi asemenea calcule asupra unor seturi logice se înregistrări? Aici intervine gruparea datelor. De exemplu, gruparea vânzărilor săptămânale după numele vânzătorului care le-a făcut. Grupurile sunt create folosind clauza GROUP BY în instrucţiunea SELECT. Modul cel mai simplu de a înţelege crearea şi utilitatea lor este un exemplu practic. Presupunem că avem într-o bază de date un tabel în care ţinem evidenţa produselor vândute de mai mulţi vânzători şi dorim la un moment dat să vedem cât a vândut fiecare, pentru a face o analiză a activităţii, nu-i aşa? Tabelul se numeşte tblProduse şi se vede în figura 4.5. Cod_produs 100001 100345 100037 100445 100090 100552

Cod_vinzator MR-01 KL-02 MR-01 MR-01 PR-02 GH-04

Denumire produs Acumulator Capota fata Set motor Cauciuc R13 Ulei M30 Antigel 34

Pret produs 250 120 356 65 50 20

Fig. 4.5. Tabelul tblProduse

O înregistrare din acest tabel reprezintă o vânzare a unui produs, făcută de un anumit vânzător. Ne propunem să aflăm câte vânzări a făcut fiecare vânzător. Expresie SQL: SELECT Cod_vinzator, COUNT(*) AS Numar_vinzari FROM tblProduse GROUP BY Cod_vinzator;

137

Baze de date

Capitolul 4

Rezultat:

Cod_vinzator MR-01 KL-02 PR-02 GH-04

Numar_vinzari 3 1 1 1

Clauza GROUP BY instruieşte sistemul de gestionare a bazei de date să sorteze datele şi să le grupeze după coloana Cod_vinzator. În felul acesta, numărul de vânzări va fi calculat câte o dată pentru fiecare vânzător în parte. După cum se vede şi în rezultat, vânzătorul MR-01 a făcut 3 vânzări, iar colegii săi, câte una. Deoarece aţi folosit clauza GROUP BY, n-a trebuit să specificaţi fiecare grup care trebuie evaluat şi calculat, acest lucru s-a făcut în mod automat. Clauza GROUP BY instruieşte sistemul de gestionare a bazei de date să grupeze datele şi apoi să aplice funcţia agregat fiecărui grup, nu asupra întregului set de rezultate. Iată câteva reguli pe care trebuie să le ştiţi despre utilizarea clauzei GROUP BY:  Clauzele GROUP BY pot conţine oricâte coloane doriţi. Asta vă permite să imbricaţi grupuri, asigurându-vă mai mult control asupra felului în care sunt grupate datele.  Orice coloană enumerată în clauza GROUP BY trebuie să fie o coloană originală sau o expresie validă (calculată, dar nu o funcţie agregat). Dacă o expresie este utilizată în instrucţiunea SELECT, aceeaşi expresie trebuie să fie specificată şi în clauza GROUP BY. Nu pot fi folosite aliasuri.  Dacă o coloană grupată conţine o linie cu o valoare NULL, NULL va fi returnată ca grup. Deci, dacă există mai multe linii cu valoarea NULL, ele vor fi grupate laolaltă, ceea ce este foarte important din punct de vedere practic. De multe ori dorim să vedem liniile cu valori nule pe o coloană, de exemplu, când dorim să vedem integritatea datelor.  Clauza GROUP BY trebuie plasată după toate clauzele WHERE şi înainte de orice clauză ORDER BY. 138

Baze de date

Capitolul 4

Filtrarea grupurilor

Pe lângă faptul că este capabil să grupeze datele folosind clauza GROUP BY, limbajul SQL vă permite, de asemenea, să filtraţi grupurile pe care le includeţi sau le excludeţi. De exemplu, dacă doriţi lista tuturor cumpărătorilor care au emis minimum 2 comenzi, trebuie să efectuaţi o filtrare bazată pe grupul complet, nu pe linii individuale. După cum ştim clauza WHERE filtrează liniile întregului tabel, nu a unui grup aşa cum am dori noi. Pentru filtrarea grupurilor, limbajul SQL ne pune la dispoziţie clauza HAVING, care este foarte asemănătoare cu clauza WHERE. Prin urmare, clauzele WHERE şi HAVING se ocupă de acelaşi lucru, filtrare, singura diferenţă este că prima filtrează linii, iar a doua grupuri. Clauza HAVING acceptă toţi operatorii clauzei WHERE. Tot ce am învăţat despre WHERE este valabil şi pentru HAVING. Pentru a înţelege clauza HAVING, să reluăm exemplul precedent şi să filtrăm numai acei vânzători care au făcut mai mult de 2 vânzări. Iată cazul: Expresie SQL: SELECT Cod_vinzator, COUNT(*) AS Numar_vinzari FROM tblProduse GROUP BY Cod_vinzator HAVING COUNT(*) > 2;

Rezultat:

Cod_vinzator MR-01

Numar_vinzari 3

Primele trei rânduri ale instrucţiunii SELECT sunt similare cu cele anterioare, ultimul rând, însă, adaugă o clauză HAVING care filtrează grupurile respective cu o clauză COUNT(*) > 2 – adică 3 sau mai multe vânzări. După cum se vede, clauza WHERE nu funcţionează în cazul acesta, deoarece filtrarea se bazează pe valoarea agregată a grupului, nu valorile unor linii specifice.

139

Baze de date

Capitolul 4

De multe ori, în practică, apare necesitatea folosirii ambelor clauze, ceea ce duce la mărirea vitezei de execuţie. În acest caz ordinea de execuţie ar fi WHERE, GROUP BY şi HAVING. De exemplu, un caz real ar fi acela de a vedea ce cumpărători au depus la noi mai mult de 2 comenzi în ultimele 12 luni. E clar că nu vom face grupuri din tot tabelul de cumpărători, ci numai după ce i-am filtrat cu o clauză WHERE numai pe cei din ultimul an. Încercaţi să concepeţi un astfel de tabel şi să-i aplicaţi expresia SQL care să facă aceste lucruri. Reţineţi că clauza HAVING se foloseşte numai în asociere cu clauza GROUP BY. Pentru a nu confunda ordinea de folosire a clauzelor instrucţiunii SELECT studiate până acum, iată această ordine: SELECT FROM WHERE GROUP BY HAVING ORDER BY

140

Baze de date

Capitolul 4

Lucrul cu subselecţii Instrucţiunile SELECT sunt interogări SQL. Toate instrucţiunile SELECT de până acum, regăseau date din tabele izolate ale bazei de date. Limbajul SQL vă permite, de asemenea, să creaţi subselecţii: interogări înglobate în alte interogări. De ce ar fi nevoie de aşa ceva? Exemplele care vor urma vă vor edifica asupra acestui lucru. Presupunem că avem structura de tabele din figura 4.6. tblDetaliiCom tblComenzi

DetComID Nr_comanda ArticolID PretArt Cantitate

Nr_comanda ChP DataCom CumparatorID ChE

tblCumparatori CumparatorID NumeCump Oras

ChP ChE ChE

Fig. 4.6. Diagrama de relaţii

ChP

Se vede că avem 3 tabele, câte unul pentru cumpărători, comenzi şi detalii comenzi, între care există relaţiile desenate. Pentru a înţelege mai bine conceptul de subselecţii vom completa aceste tabele cu date. În figura 4.7 se văd aceste tabele.

141

Baze de date

Capitolul 4

tblComenzi ComandaID 10010 10011 10012 10013 10014 10015 10016 10017 tblDetaliiCom DetComID 20010 20011 20012 20013 20014

DataCom 16.04.2005 16.04.2005 16.04.2005 16.04.2005 16.04.2005 20.04.2005 20.04.2005 20.04.2005

ComandaID 10010 10010 10011 10011 10012

ArticolID 1001 1002 1001 1052 1008

CumparatorID 6001 6083 6014 6025 6001 6083 6001 6014

PretArt 250.50 115.00 95.25 65.00 147.00

Cantitate 10 12 8 50 16

tblCumparatori CumparatorID 6001 6002 6025 6083 6014

NumeCump ROMBAT SRL AutoNET SRL COMPACT SA ANCONA SA SAVINA SRL

Oras Tg. Mures Tg. Mures Brasov Sibiu Ludus

<> ...... ...... ...... ...... ......

Fig. 4.7. Cele 3 tabele completate

Aceste 3 tabele fac parte dintr-o bază de date a unei firme de comerţ. Cumpărătorii sunt firme, care comandă diferite articole produse de firma noastră. În tabelul tblComenzi sunt ţinute comenzile, în tabelul tblDetaliiCom sunt ţinute articolele tuturor comenzilor, iar în tabelul tblCumparatori sunt stocaţi toţi cumpărătorii. Ne propunem să aflăm toţi cumpărătorii care au comandat articolul 1001. Cum procedăm? Iată paşii care trebuie urmaţi:  Regăsiţi numele tuturor comenzilor ce conţin articolul 1001.  Regăsiţi indicatorii tuturor cumpărătorilor care au comenzi cu numerele returnate în pasul anterior. 142

Baze de date

Capitolul 4

 Regăsiţi informaţiile despre cumpărători pentru toţi identificatorii returnaţi în pasul anterior. Fiecare dintre aceşti paşi poate fi executat de o interogare separată. Procedând astfel, folosiţi datele returnate de o singură instrucţiune SELECT pentru a popula clauza WHERE a următoarei instrucţiuni SELECT. Puteţi, de asemenea, să folosiţi subselecţii, care să combine cele 3 interogări într-o singură instrucţiune. Pentru primul pas, instrucţiunea SELECT care afişează numărul comenzilor care conţin articolul 1001, este evidentă, nu-i aşa? Expresie SQL: SELECT ComandaID FROM tblDetaliiCom WHERE ArticolID = „1001‟;

Rezultat: ComandaID .......... 10010 10011

Urmăriţi instrucţiunea SQL şi verificaţi în tabelele din figura 4.7 dacă rezultatele întoarse sunt corecte. Următorul pas este să găsiţi identificatorii cumpărătorilor asociaţi cu comenzile 10010 şi 10011. Iată cum trebuie să procedaţi: Expresie SQL: SELECT CumparatorID FROM tblComenzi WHERE ComandaID IN (10010, 10011);

Rezultat: CumparatorID .......... 6001 6083

143

Baze de date

Capitolul 4

Remarcaţi folosirea clauzei IN pe care aţi studiat-o puţin mai înainte. Având indicatorii pentru cumpărătorii căutaţi, nu vă rămâne decât să căutaţi cine sunt aceştia, în tabelul cu toţi cumpărătorii. Iată cum trebuie să procedaţi: Expresie SQL: SELECT CumparatorID, NumeCump FROM tblCumparatori WHERE CumparatorID IN (6001, 6083);

Rezultat: CumparatorID NumeCump .......... ......... 6001 ROMBAT SRL 6083 ANCONA SA

V-aţi descurcat foarte bine până aici, dar nu cred că sunteţi mulţumiţi cu această metodă „băbească” de găsi informaţiile dorite. Aţi observat cum sau transferat rezultatele unei interogări în parametrii altei interogări. Soluţia este să încercaţi să uniţi aceste 3 interogări într-una singură. Iată această cale: Expresie SQL: SELECT CumparatorID, NumeCump FROM tblCumparatori WHERE CumparatorID IN (SELECT CumparatorID FROM tblComenzi WHERE ComandaID IN (SELECT ComandaID FROM tblDetaliiCom WHERE ArticolID = „1001‟));

Rezultat: CumparatorID NumeCump .......... ......... 6001 ROMBAT SRL 6083 ANCONA SA

Rezultatul obţinut este identic cu cel obţinut pas cu pas, dar aici aţi folosit o singură expresie SQL. Observaţi că pentru a putea citi şi înţelege mai

144

Baze de date

Capitolul 4

bine această expresie am grupat-o într-un anume fel. Este o idee bună, mai ales atunci când expresiile pe care le folosiţi sunt complicate. O altă modalitate de utilizare a subselecţiilor este crearea de câmpuri calculate. Să presupunem că doriţi să afişaţi numărul total al comenzilor emise de fiecare cumpărător din tabelul tblCumparatori. Ştim că aceste comenzi sunt stocate în tabelul tblComenzi, împreună cu identificatorii cumpărătorilor. Pentru a efectua această operaţie, trebuie efectuaţi următorii paşi:  Regăsiţi lista cumpărătorilor din tabelul tblCumparatori.  Pentru fiecare cumpărător regăsit, număraţi comenzile asociate în tabelul tblComenzi. Iată cum trebuie procedat (tabelele sunt cele din figura 4.7): Expresie SQL: SELECT NumeCump, Oras, (SELECT COUNT(*) FROM tblComenzi AS C WHERE C.CumparatorID=tblCumparatori.CumparatorID) AS Comenzi FROM tblCumparatori ORDER BY NumeCump;

Remarcaţi utilizarea aliasului C pentru tabelul tblComenzi pentru a simplifica scrierea expresiei clauzei WHERE. Rezultat: NumeCump .......... ANCONA SA AutoNET SRL COMPACT SA ROMBAT SRL SAVINA SRL

Oras ......... Tg. Mures Tg. Mures Brasov Bistrita Ludus

Comenzi ........ 2 0 1 3 2

Deşi subselecţiile sunt foarte utile în construirea acestui tip de instrucţiune SELECT, trebuie avut grijă în privinţa identificării corecte a coloanelor implicate, ştiind că sunt coloane cu acelaşi nume care apar în tabele diferite. Aceste coloane se identifică corect dacă înaintea numelui se pune 145

Baze de date

Capitolul 4

numele tabelului din care face parte, ca de exemplu, tblComenzi.CumparatorID sau tblCumparatori.CumpatatorID. Se vede clar că câmpul CumparatorID face parte din două tabele. Reţineţi această regulă pentru că o s-o folosiţi de multe ori!

146

Baze de date

Capitolul 4

Unirea tabelelor Una din caracteristicile extrem de puternice din limbajul SQL este capacitatea de a uni tabele din mers, în interogările de regăsire a datelor. Unirile constituie unele dintre cele mai importante operaţii pe care le puteţi efectua folosind instrucţiunile SELECT, şi o bună înţelegere a lor şi a sintaxei pentru unire reprezintă o parte esenţială din învăţarea limbajului SQL. Ceea ce aţi învăţat în capitolele anterioare despre chei, relaţii, diagrame sunt acum hotărâtoare pentru construirea corectă a expresiilor SQL. Ca definiţie simplă, unirea este un mecanism folosit pentru asocierea tabelelor într-o instrucţiune SELECT. Utilizând o sintaxă specială, mai multe tabele pot fi unite astfel încât să fie returnat un singur set de rezultate, iar unirea asociază din mers liniile corectate din fiecare tabel. Crearea unei uniri simple

Crearea unei uniri este foarte simplă. În exemplul următor, vom uni două tabele tblProduse şi tblVinzatori, al cărui rezultat este produsul cartezian al acestora, având un număr de înregistrări egal cu produsul numerelor acestora (figura 4.8). tblProduse ProdusID 1001 1002 1003

tblVinzatori VinzatorID V01 V02

VinzatorID V01 V03 V01

NumeVinzator Ban Lucia Pop Mariana

DenumireProdus Piine Banane Biscuiti

OrasVinzator Naoiu Sarmasel

PretProdus 2.00 2.50 1.25

<> ...... ......

Fig. 4.8. Tabelele pentru unire

Unirea celor două tabele cu o expresie SQL va genera un nou tabel cu 6 înregistrări (3 x 2).

147

Baze de date

Capitolul 4

Expresia SQL: SELECT NumeVinzator, DenumireProdus, PretProdus FROM tblVinzatori, tblProduse;

Rezultat: NumeVinzator Ban Lucia Ban Lucia Ban Lucia Pop Mariana Pop Mariana Pop Mariana

DenumireProdus Piine Banane Biscuiti Piine Banane Biscuiti

PretProdus 2.00 2.50 1.25 2.00 2.50 1.25

Acest tip de unire nu se foloseşte niciodată sub această formă, deoarece nu are nici un sens. Aici nu s-a pus nici un fel de condiţie, nici o legătură între cele două tabele. Adevărata unire este cea când se fac legături între tabele, aşa cum se vede mai departe. Expresia SQL: SELECT NumeVinzator, DenumireProdus, PretProdus FROM tblVinzatori, tblProduse; WHERE tblVinzatiri.VinzatorID=tblProduse.VinzatorID;

Rezultat: NumeVinzator Ban Lucia Ban Lucia

DenumireProdus Piine Biscuiti

PretProdus 2.00 1.25

Ce s-a întâmplat de fapt? Clauza WHERE a filtrat înregistrările produsului cartezian, rezultând numai 2 înregistrări. Acest tip de uniri, bazate pe verificarea egalităţii dintre două tabele, se mai numesc şi uniri interioare. Unele SGBGR-uri au sintaxe diferite, specificând explicit tipul de unire. Studiaţi cu atenţie documentaţia SGBDR-ului cu care lucraţi pentru a-i folosi corect sintaxa.

148

Baze de date

Capitolul 4

O altă variantă de unire este cea făcută în clauza FROM prin folosirea clauzei speciale INNER JOIN ... ON, după cum se vede mai jos: SELECT NumeVinzator, DenumireProdus, PretProdus FROM tblVinzatori INNER JOIN tblProduse ON tblVinzatiri.VinzatorID=tblProduse.VinzatorID;

Această variantă este preferată de programatori, dar ea este şi cea indicată de specificaţiile SQL.

149

Baze de date

Capitolul 4

Uniri avansate

Limbajul SQL nu impune limite asupra numărului de tabele ce pot fi unite într-o instrucţiune SELECT. Regulile de bază pentru crearea unei uniri rămân aceleaşi. În primul rând, enumeraţi toate tabelele, apoi definiţi relaţiile dintre ele. Iată un exemplu: tblProduse ProdusID 1001 1002 1003 1004 1052 1078

VinzatorID V01 V03 V01 V01 V02 V03

DenumireProdus Piine Inghetata Biscuiti Ciocolata Bricheta Banane

PretProdus 2.00 1.25 0.25 2.65 0.35 2.50

DescriereProdus

tblDetaliiComenzi DetComID 20010 20011 20012 20013 20014

ComandaID 10010 10010 10010 10010 10012

ProdusID 1001 1002 1078 1052 1008

Cantitate 10 12 8 50 16

tblVinzatori VinzatorID V01 V02 V03 V04

NumeVinzator Ban Lucia Pop Mariana Baciu Mia Ban Ionel

Oras Naoiu Sarmasel Naoiu Roma

<> ...... ...... ...... ......

Fig. 4.9. Tabele implicate în unire

Ne propunem să aplicăm unirea într-un caz concret de regăsire a unor informaţii care se găsesc în trei tabele. Căutăm produsele care compun comanda 10010, precum şi vânzătorul asociat. Studiaţi expresia SQL care urmează şi verificaţi rezultatul obţinut. Expresie SQL: SELECT DenumireProdus, NumeVinzator, PretProdus, Cantitate FROM tblProduse, tblDetaliiCom, tblVinzatori WHERE tblDetaliiComenzi.ProdusID=tblProduse.ProdusID

150

Baze de date

Capitolul 4

AND tblProduse.VinzatorID=tblVinzatori.VinzatorID AND ComandaID= „10010‟;

Rezultat: DenumireProdus Piine Inghetata Banane Bricheta

NumeVinzator Ban Lucia Baciu Mia Ban Lucia Pop Mariana

PretProdus 2.00 1.25 2.50 0.35

Cantitate 10 12 8 50

Primele două rânduri ale clauzei WHERE fac legătura între perechile de tabele tblDetaliiComenzi-tblProduse şi tblProduse-tblVinzatori, iar al treilea filtrează doar produsele pentru comanda 10010. Iată câteva aspecte esenţiale legate de uniri şi folosirea lor:  Consultaţi-vă documentaţia sistemului de gestionare a bazei de date, pentru a afla sintaxa exactă a unirii pe care o acceptă.  Asiguraţi-vă că utilizaţi condiţia corectă de unire, indiferent de sintaxa folosită, altfel vor fi returnate date incorecte.  Asiguraţi-vă că prevedeţi întotdeauna o condiţie de unire, altfel veţi sfârşi cu un produs cartezian.  Într-o unire, puteţi include mai multe tabele, ba chiar să aveţi tipuri diferite de unire pentru fiecare. Deşi metoda este corectă şi adesea utilă, asiguraţi-vă că testaţi separat fiecare unire, înainte de a le testa împreună. În felul acesta depanările vor fi mult simplificate.  O metodă bună este folosirea aliasurilor pentru tabele, pentru a simplifica scrierea expresiilor SQL.

Compunerea interogărilor Interogarea bazelor de date este chiar sensul existenţei lor. Nimeni n-a creat vreo bază de date fără să o interogheze cândva, când se adună suficiente date în ea. Până acum noi am făcut interogări folosind o singură instrucţiune SELECT, care returna date din unul sau mai multe tabele. Limbajul SQL vă permite să efectuaţi mai multe interogări (mai multe 151

Baze de date

Capitolul 4

instrucţiuni SELECT) şi să returnaţi rezultatele sub forma unui singur set de rezultate de interogare. De obicei, aceste interogări sunt cunoscute drept reuniuni sau interogări compuse. În esenţă, există două situaţii generale în care să folosiţi interogările compuse:  Pentru a returna date structurate similar din tabele diferite, într-o singură interogare.  Pentru a efectua mai multe interogări asupra unui singur tabel, returnând datele ca o singură interogare. Pentru a compune interogările SQL se foloseşte operatorul UNION. Cu ajutorul lui pot fi specificate instrucţiuni SELECT multiple, iar rezultatele acestora pot fi combinate într-un singur set de rezultate. Folosirea operatorului UNION este destul de simplă, tot ce aveţi de făcut este să specificaţi toate instrucţiunile SELECT şi să plasaţi între ele cuvântul cheie UNION. Să luăm un exemplu. Presupunem că trebuie să întocmiţi un raport despre toţi cumpărătorii din judeţele Bistriţa-Năsăud, Braşov şi Cluj. În acelaşi raport doriţi să includeţi toate locaţiile firmei ANCONA SA, indiferent în ce judeţ s-ar afla ele. Desigur, se poate crea o clauza WHERE care să realizeze acest lucru, dar acum veţi folosi operatorul UNION. Figura 4.10 conţine tabelul cu cumpărătorii, care o să fie folosit în acest exemplu. CumparatorID 6001 6002 6004 6025 6083 6084

NumeCumparator ROMBAT SA AutoNET SRL SAVINA SRL COMPACT SRL ANCONA SA ANCONA SA

JudCump BN MS MS BV MS CJ

PersContact Pop Petru Beldean Vian Parauan Bicu Pietroi Sorina Palade Sorin Crisan Ovidiu

Email [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Fig. 4.10. Tabelul tblCumparatori

După cum ştiţi deja, folosirea operatorului UNION implică scrierea mai multor instrucţiuni SELECT, de aceea veţi crea mai întâi fiecare instrucţiune SELECT, apoi le veţi compune.

152

Baze de date

Capitolul 4

Prima instrucţiune SELECT va căuta cumpărătorii din cele 3 judeţe amintite. Expresie SQL: SELECT NumeCumparator, JudCump, PersContact, Email FROM tblCumparatori WHERE JudetCumparator IN ('BN', 'BV','CJ');

Rezultat: NumeCumparator ROMBAT SA COMPACT SRL ANCONA SA

JudCump BN BV CJ

PersContact Pop Petru Pietroi Sorina Crisan Ovidiu

Email [email protected] [email protected] [email protected]

A doua instrucţiune SELECT va căuta toate locaţiile firmei ANCONA SA. Expresie SQL: SELECT NumeCumparator, JudCump, PersContact, Email FROM tblCumparatori WHERE NumeCumparator= 'ANCONA SA';

Rezultat: NumeCumparator ANCONA SA ANCONA SA

JudCump MS CJ

PersContact Palade Sorin Crisan Ovidiu

Email [email protected] [email protected]

După cum se vede, există două locaţii pentru firma ANCONA SA, una în judeţul Mureş şi una în judeţul Cluj. Pentru a compune cele 2 interogări veţi proceda astfel: Expresie SQL: SELECT NumeCumparator,JudCump, PersContact, Email FROM tblCumparatori WHERE JudetCumparator IN ('BN', 'BV','CJ') UNION SELECT NumeCumparator, JudCump, PersContact, Email FROM tblCumparatori WHERE NumeCumparator= 'ANCONA SA';

153

Baze de date

Capitolul 4

Rezultat: NumeCumparator ROMBAT SA COMPACT SRL ANCONA SA ANCONA SA

JudCump BN BV CJ MS

PersContact Pop Petru Pietroi Sorina Crisan Ovidiu Palade Sorin

Email [email protected] [email protected] [email protected] [email protected]

Deoarece ANCONA SA se găseşte în ambele interogări, SQL nu îl scrie de două ori. Dacă totuşi, dorim să apară şi dublurile, atunci vom folosi clauza UNION ALL. Fără extensia ALL, duplicatele se elimină automat. Dacă dorim ca rezultatele să fie sortate, vom adăuga clauza ORDER BY după ultima clauză WHERE. De remarcat, că operaţiile UNION acceptă o singură clauză ORDER BY, după ultima instrucţiune SELECT. Iată cum arată o expresie SQL cu afişarea tuturor înregistrărilor care sunt şi ordonate: Expresie SQL: SELECT NumeCumparator, PersContact, Email FROM tblCumparatori WHERE JudetCumparator IN ('BN', 'BV','CJ') UNION ALL SELECT NumeCumparator, PersContact, Email FROM tblCumparatori WHERE NumeCumparator= 'ANCONA SA' ORDER BY NumeCumparator;

Rezultat: NumeCumparator ANCONA SA ANCONA SA ANCONA SA COMPACT SRL ROMBAT SA

JudCump CJ CJ MS BV BN

PersContact Crisan Ovidiu Crisan Ovidiu Palade Sorin Pietroi Sorina Pop Petru

Email [email protected] [email protected] [email protected] [email protected] [email protected]

Observaţi înregistrarea dublă ANCONA SA, care apare din cauza operatorului UNION ALL. Iată câteva reguli pentru operaţii cu operatorul UNION:  Toate interogările dintr-o operaţie UNION trebuie să conţină aceleaşi coloane, expresii sau funcţii agregat. 154

Baze de date

Capitolul 4

 Coloanele, expresiile şi funcţiile agregat trebuie să apară exact în aceeaşi ordine în fiecare instrucţiune SELECT din operaţia UNION.  Tipurile de date din coloane trebuie să fie compatibile. Nu este necesar ca datele să fie exact de acelaşi tip, dar trebuie să fie de un tip pe care SGBDR-ul îl poate transforma implicit (de exemplu tipuri de date numerice diferite sau tipuri de date calendaristice diferite). Inserarea, actualizarea şi ştergerea datelor Datele unei baze de date trebuie periodic actualizate, pentru a reflecta activităţile unei firme sau organizaţii. Întreţinerea datelor este o activitate continuă, plină de responsabilitate, fără de care, utilitatea bazei de date este îndoielnică. Limbajul SQL oferă instrucţiuni dedicate întreţinerii datelor unei baze. Întreţinerea unei baze de date constă, de fapt, în introducerea de noi date, modificarea unor date existente sau ştergerea datelor din tabelele acesteia. Toate aceste operaţii o să le învăţaţi în cele ce urmează. Inserarea datelor se face cu instrucţiunea INSERT Inserarea datelor

Toate expresiile SQL de până acum începeau cu instrucţiunea SELECT. Pe lângă aceasta, mai sunt alte 4 instrucţiuni pe care le vom învăţa în continuare. Acestea sunt INSERT, UPDATE, DELETE şi CREATE TABLE. Prima dintre ele este instrucţiunea INSERT, folosită pentru inserarea de linii (înregistrări) într-un tabel de bază de date. Inserarea se poate face în mai multe moduri:  Inserarea unei singure linii complete;  Inserarea unei singure linii parţiale;  Inserarea rezultatelor unei interogări. Le vom studia pe rând. 155

Baze de date

Capitolul 4

Inserarea unei linii complete. Cel mai simplu mod de a insera o linie într-un tabel este folosirea sintaxei de bază a instrucţiunii INSERT, care cere numele tabelului şi valorile care vor fi inserate în noua linie. Iată un exemplu: INSERT INTO tblProduse ( ProdusID, CodProdus, Denumire, UM, Pret, Observatii ) VALUES ('32', '20033', 'Cafea_Jacobs', 'kg', '12.23', 'Conform normelor UE');

Această expresie SQL, inserează în tabelul tblProduse un rând cu valorile prezentate în paranteza de după VALUES. Valorile corespund, în ordine, cu denumirile câmpurilor din prima paranteză a expresiei SQL, indiferent de ordinea în care apar în tabel. Dacă numărul coloanelor indicate nu este acelaşi cu numărul valorilor, se va produce un mesaj de eroare care precizează acest lucru. Inserarea unei singure linii parţiale. Există cazuri în care nu este nevoie să se completeze toate câmpurile unei înregistrări, fie că nu se cunosc valorile în acel moment, fie că nu e necesară valoarea acelui câmp pentru înregistrarea respectivă. În acest caz, se completează numai acele câmpuri pentru care există valori. Este de la sine înţeles că prin proiectarea bazei de date, este prevăzut că acele câmpuri necompletate au voie să aibă valori nule. Din exemplul anterior, se poate scoate câmpul Observatii care nu este obligatoriu. Expresia SQL va arăta astfel: INSERT INTO tblProduse ( ProdusID, CodProdus, Denumire, UM, Pret) VALUES ('32', '20033', 'Cafea_Jacobs', 'kg', '12.23');

Deci, câmpul Observatii şi valoarea corespunzătoare nu apar în expresia SQL. Inserarea rezultatelor unei interogări. Inserarea într-un tabel a unei singure înregistrări, complete sau parţiale, este o acţiune obişnuită, de rutină, utilizată de obicei de administratorul bazei de date pentru completări minore ale unui tabel. Cele mai spectaculoase completări ale tabelelor sunt cele cu înregistrări provenite din interogări ale altor tabele.

156

Baze de date

Capitolul 4

Aceste inserări se pot face manual de către administratorul bazei de date, dar cel mai probabil mod de a insera într-un tabel înregistrările provenite dintr-o interogare, este folosirea limbajului VBA, în cadrul unor aplicaţii integrate. Această formă de instrucţiune INSERT, care poate fi utilizată pentru a insera rezultatul unei instrucţiuni SELECT se numeşte INSERT SELECT, fiind alcătuită dintr-o instrucţiune INSERT şi o instrucţiune SELECT. Să presupunem că aveţi într-o bază de date un tabel numit tblClienti care conţine clienţii unei firme. Pentru a adăuga noi clienţi, în practică se procedează astfel: nu toţi clienţii se introduc direct în tabel, ci mai întâi se introduc într-un tabel temporar, apoi se decide care sunt clienţii care merită introduşi în baza de date şi numai atunci, se introduc în tabelul tblClienti. Această expresie SQL este prezentată mai jos: INSERT INTO tblClienti (ClientID, Denumire, CodFiscal, PersoanaContact, Adresa) SELECT (ClientID, Denumire, CodFiscal, PersoanaContact, Adresa) FROM tblClientiNoi;

După cum se vede, tabelul tblClienti este completat cu înregistrări din tabelul tblClientiNoi, dar pot fi şi alte surse de interogare. Totul este ca numărul de câmpuri şi tipul lor de dată să coincidă. Actualizarea datelor

Datele unei baze de date suferă dese modificări. Cum datele se găsesc în tabele, este nevoie ca aceste tabele să fie periodic actualizate. Ca să modificaţi datele dintr-un tabel, trebuie să folosiţi instrucţiunea UPDATE. Ea poate fi folosită în două moduri:  Pentru actualizarea numai a anumitor linii dintr-un tabel;  Pentru actualizarea tuturor liniilor unui tabel. Instrucţiunea UPDATE folosită defectuos, poate să vă producă mari neplăceri, ştiut fiind că aici nu există posibilitatea de revenire în sensul „undo”. Prin urmare trebuie să fiţi foarte atenţi la folosirea ei. De altfel, unele sisteme de gestiune a bazelor de date au restricţii de securitate pentru a împiedica unele acţiuni greşite asupra bazei de date. Instrucţiunea UPDATE este foarte simplu de utilizat. Sintaxa ei este alcătuită din 3 părţi: 157

Baze de date

Capitolul 4

 Tabelul care trebuie actualizat;  Numele coloanelor şi noile lor valori;  Condiţia filtru care determină liniile care trebuie actualizate. Să examinăm un caz banal. Clientul cu codul 1000245, are acum adresă de e-mail şi ar trebui să apară şi tabelul cu clienţii, numit tblClienti. Expresia SQL care efectuează această actualizare este următoarea: UPDATE tblClienti SET E_mail = ‘[email protected]’ WHERE ClientID = ’1000245’;

Este de la sine înţeles că cele 2 câmpuri (E_mail şi ClientID) sunt câmpuri ale tabelului tblClienti. Instrucţiunea UPDATE începe întotdeauna cu numele tabelului care este actualizat (aici tblClienti). Urmează comanda SET, care atribuie noua valoare unei coloane (aici coloana E_mail). Instrucţiunea UPDATE se termină cu o clauză WHERE, care anunţă sistemul de gestionare a bazei de date ce linie să actualizeze. Atenţie, fără clauza WHERE sistemul ar actualiza toate liniile din tabelul tblClienti, punând adresa de e-mail ‘[email protected]’ la toţi clienţii, ceea ce ar fi un lucru inadmisibil. Actualizarea mai multor coloane necesită a sintaxă corespunzătoare cum se poate vedea mai jos: UPDATE tblClienti SET E_mail = ‘[email protected]’, PersoanaContact = ‘Mocian Ioan’ WHERE ClientID = ’1000245’;

Din această expresie SQL se pot deduce următoarele:  Perechile de câmpuri şi valorile lor (între ele este semnul = ) se despart prin virgulă;  Avem atâtea egaluri câte câmpuri trebuie actualizate;  Înregistrarea care trebuie actualizată este identificată cu câmpul ClientID, care este cheie primară în tabelul tblClienti, vă mai amintiţi desigur ea. 158

Baze de date

Capitolul 4

Pentru a şterge valoarea unei coloane, tehnica este ca acea coloană să fie setată pe valoarea NULL (condiţia este ca acel câmp să accepte valoarea NULL). Iată expresia SQL care face acest lucru: UPDATE tblClienti SET E_mail = NULL WHERE ClientID = ’1000245’;

Această expresie SQL, şterge adresa de e-mail a clientului 1000245. Mai târziu, în capitolul 5 veţi putea face teste şi simulări cu actualizări de date pe o bază de date de test. Ştergerea datelor

Pentru a şterge linii dintr-un tabel, necesitate practică frecventă, se foloseşte instrucţiunea DELETE. Ea poate fi utilizată în două modalităţi:  Pentru ştergerea numai a anumitor linii dintr-un tabel;  Pentru ştergerea tuturor liniilor unui tabel. Deşi este o necesitate practică, folosirea instrucţiunii DELETE antrenează mari riscuri, de aceea este bine să faceţi teste pe o copie a unei baze de date. Oricum, ca începători nu vă va pune nimeni să „curăţaţi” tabelele unei baze de date reale de înregistrările inutile. Să presupunem că printre clienţi, există câţiva care şi-au închis firma, deci nu mai e necesar să-i avem în tabelul tblClienti, aşa că trebuie să-i ştergem din tabel. De exemplu, clientul cu codul 1000378 trebuie şters din tabel. Expresia SQL care face acest lucru este următoarea: DELETE FROM tblClienti WHERE ClientID = ’1000378’;

Această expresie SQL ar trebui înţeleasă imediat, pentru că e foarte clară: din tabelul tblClienti se şterge clientul care are câmpul ClientID la valoarea 1000378. De remarcat faptul că instrucţiunea DELETE nu conţine nume de coloane, ea şterge linii întregi, nu coloane. Pentru a şterge valorile din anumite coloane veţi folosi instrucţiunea UPDATE, prezentată puţin mai înainte. 159

Baze de date

Capitolul 4

De asemenea, instrucţiunea DELETE nu şterge tabele, ci numai înregistrări din tabele. Chiar dacă şterge toate înregistrările unui tabel, aceste rămâne, dar va fi gol. Aţi văzut cum se poate şterge dintr-un tabel o înregistrare. Întrebarea firească este cum se pot şterge dintr-un tabel toate înregistrările. Şi aici, ca în orice acţiune de distrugere, este foarte simplu: trebuie eliminată clauza WHERE. Iată ce simplu puteţi „scăpa” de înregistrările unui tabel: DELETE FROM tblClienti ;

Luaţi-vă măsurile de precauţie când lucraţi cu această instrucţiune! Principii privind actualizarea şi ştergerea datelor

După cum spuneam, instrucţiunile UPDATE şi DELETE sunt instrucţiuni, pe cât de utile, pe atât de periculoase. Trebuie să reţineţi faptul că în SQL nu există un buton Undo, de anulare a unei operaţiuni greşite, de aceea fiţi foarte atenţi când folosiţi aceste 2 instrucţiuni. În sinteză, iată câteva principii pe care trebuie să le respectaţi, ca utilizator al limbajului SQL:  Nu executaţi niciodată instrucţiunile UPDATE şi DELETE fără o clauză WHERE, decât atunci când doriţi să realmente să actualizaţi sau să ştergeţi toate liniile unui tabel;  Asiguraţi-vă că toate tabelele au o cheie primară (dacă aţi uitat ce este aceasta, consultaţi capitolul respectiv) pe care să o folosiţi într-o clauză WHERE;  Înainte de a folosi o clauză WHERE cu instrucţiunile UPDATE sau DELETE, testaţi-o mai întâi cu o instrucţiune SELECT, ca să vă asiguraţi că filtrează înregistrările corecte – din cauză că la clauza WHERE puteţi greşi destul de uşor.  Folosiţi integritatea referenţială (vezi paragraful Integritatea la nivel de relaţie) impusă bazelor de date astfel ca sistemul de gestiune al bazelor de date (SGBD) să nu permită ştergerea liniilor care au date în alte tabele asociate lor.  Unele SGBD-uri permit administratorilor de baze de date să impună limitări ce împiedică executarea instrucţiunilor UPDATE şi DELETE fără o clauză WHERE. 160

Baze de date

Capitolul 4

 Nu vă apucaţi să executaţi operaţiuni de actualizare sau ştergere, înainte să faceţi o copie de siguranţă a bazei de date. Veţi fi astfel mai relaxaţi, iar în caz de o manevră greşită (oameni suntem, nu?), puteţi reveni la ce a fost, fără nici o problemă.  Nu executaţi operaţii de ştergere printre „alte activităţi” pentru că aici aveţi nevoie de concentrare maximă (amintiţi-vă că aici nu este Undo şi „ce aţi făcut, făcut rămâne”). Respectaţi aceste câteva principii enumerate, care vă ajută mult, gândinduvă că oricâte lucruri bune aţi face în firma la care lucraţi ca administrator de baze de date, o greşeală ca ştergerea completă a unor tabele sau câmpuri vă descalifică definitiv în ochii celor care vă plătesc.

161

Baze de date

Capitolul 4

Crearea şi manipularea tabelelor Limbajul SQL nu este folosit numai pentru manipularea datelor. Cu ajutorul limbajului SQL se pot crea, modifica şi şterge tabele, chiar dacă toate SGBD-urile au propriile unelte pentru aceste acţiuni. În general, există două modalităţi de creare a tabelelor de baze de date:  Majoritatea SGBD-urilor deţine propriul instrument de gestionare, folosit şi la crearea şi administrarea interactivă a tabelelor bazei de date.  Tabelele pot fi create, de asemenea, în mod direct, prin intermediul instrucţiunilor SQL. Instrucţiunea de creare a tabelelor cu limbajul SQL este CREATE TABLE. Trebuie menţionat faptul că atunci când folosim instrumente interactive, de fapt folosim instrucţiuni SQL care sunt generate şi executate de sistem, fără să ne dăm seama pentru că totul se face „în spatele” interfeţei. Pentru a crea un tabel folosind instrucţiunea CREATE TABLE, trebuie specificate următoarele informaţii:  Numele noului tabel, specificat după cuvântul cheie CREATE TABLE;  Numele şi definirea coloanelor din tabel, separate prin virgulă; Iată cum arată o expresie SQL de creare a unui tabel (în Access): CREATE TABLE tblProduse ( ProdusID

Integer

NOT NULL,

CodProdus

Text(50) NOT NULL,

Denumire

Text(80) NOT NULL,

UM

Text(10) NOT NULL,

PretUnitar

Number NOT NULL,

Observatii

Text(255)

); După cum se vede, instrucţiunea de mai sus creează tabelul tblProduse care are 6 câmpuri, despărţite prin virgule. Observaţi tipurile de date 162

Baze de date

Capitolul 4

folosite, întreg, text şi număr real (Number). De asemenea, pentru a specifica faptul că un câmp cere valoare obligatorie trebuie pusă expresia NOT NULL, iar dacă lipseşte se consideră că s-a pus NULL, adică acel câmp poate să rămână necompletat. Din cele 6 câmpuri, numai Observatii nu este obligatoriu de completat. Între numele coloanei, tipul de dată şi cuvântul cheie NOT NULL se pune spaţiu. Modul de aranjare a expresiei SQL nu este important, deoarece spaţiile suplimentare sunt ignorate, se poate folosi un singur rând pentru definirea tuturor coloanelor sau se pot aranja pe mai multe rânduri ca în exemplul prezentat mai înainte, pentru lizibilitate. Numele tabelului care se creează nu trebuie să existe în baza de date, dacă există se va produce un mesaj de eroare care indică acest lucru. Adăugarea unei coloane. De multe ori în practică apare necesitatea adăugării unei coloane la un tabel care a fost creat şi care are chiar date. Limbajul SQL ne pune la dispoziţie o instrucţiune pentru a face acest lucru, numită ALTER TABLE şi clauza ADD. Iată un exemplu de folosire a acestei instrucţiuni: ALTER TABLE tblProduse ADD Furnizor Text(50);

Această expresie SQL adaugă tabelului tblProduse coloana Furnizor. Ştergerea unei coloane. Dacă diagrama de relaţii permite, adică acel câmp nu este implicat în vreo relaţie, coloana (câmpul) poate fi ştearsă dintr-un tabel. Această manevră se face cu ajutorul instrucţiunii ALTER TABLE şi clauza DROP COLUMN. Iată un exemplu de folosire a acestei instrucţiuni: ALTER TABLE tblProduse DROP COLUMN Furnizor;

Această expresie SQL şterge din tabelul tblProduse coloana Furnizor. Ştergerea unui tabel. Aşa cum se poate crea un tabel într-o bază de date cu ajutorul limbajului SQL, tot aşa se poate şi înlătura un tabel din baza de date. Operaţiunea este foarte simplă, chiar periculos de simplă. Astfel, pentru a elimina din baza de date tabelul tblProduse folosim expresia SQL următoare: 163

Baze de date

Capitolul 4

DROP TABLE tblProduse;

Operaţiunea nu este însoţită de nici un mesaj, nu poate fi anulată, tabelul rămânând şters definitiv, aşa că trebuie să fiţi extrem de precauţi când faceţi o astfel de manevră.

Elemente performante ale limbajului SQL Ceea ce am studiat până acum se încadrează în nivelul propus pentru acest curs, însă limbajul SQL nu şi-a terminat posibilităţile, oferind programatorilor profesionişti elemente cu adevărat performante. În acest capitol vor fi prezentate, pe scurt, aceste elemente de performanţă fără a intra în amănunte de ordin tehnic. În continuare vor fi prezentate aceste posibilităţi avansate ale limbajului SQL. Proceduri stocate. Instrucţiunile SQL folosite până acum sunt simple, deoarece folosesc o singură instrucţiune aplicată unuia sau mai multor tabele. Însă, nu toate operaţiile sunt atât de simple, adesea sunt necesare mai multe instrucţiuni. Iată un caz de operaţie complexă:  Pentru a onora o comandă trebuie mai întâi să vedem dacă avem în stoc articolele respective;  Dacă există, ele trebuie trecute pe o listă rezervată şi scăzute din stoc pentru a nu fi vândute altor cumpărători;  Articolele care nu există în stoc şi sunt cerute de comandă, trebuie trecute pe o listă pentru a fi aprovizionate;  Cumpărătorul trebuie anunţat asupra articolelor existente în stoc (adică livrabile imediat) şi asupra celor care urmează să fie aprovizionate. Scenariul prezentat necesită mai multe instrucţiuni SQL adresate mai multor tabele. În plus, instrucţiunile SQL trebuie efectuate într-o anumită ordine, iar ordinea depinde de existenţa produselor în stoc (dacă există, nu mai trebuie comandate).

164

Baze de date

Capitolul 4

Cum trebuie scrise aceste instrucţiuni? Am putea să scriem individual fiecare instrucţiune SQL, apoi pe baza rezultatului să executăm alte instrucţiuni condiţionate. Acţiunea ar trebui repetată pentru fiecare comandă, iar persoana care face acest lucru trebuie să aibă cunoştinţe şi experienţă corespunzătoare. Acelaşi lucru se poate face printr-o procedură stocată. Procedurile stocate nu sunt altceva decât seturi de una sau mai multe instrucţiuni SQL salvate pentru o viitoare folosire. De ce trebuie folosite procedurile stocate? Iată câteva din motive:  Pentru a simplifica operaţiile complexe (ca cea prezentată ma înainte), prin înglobarea proceselor într-o singură unitate, uşor de utilizat;  Prin eliminarea paşilor individuali se elimină erorile umane şi se asigură coerenţa datelor;  Limitarea accesului la datele de bază, prin intermediul procedurilor stocate, reduce şansa deteriorării datelor, intenţionată sau nu.  Procedurile stocate au formă compilată, deci se execută mult mai repede;  În limbajul SQL există elemente şi caracteristici disponibile numai pentru cereri unice. Procedurile stocate le pot folosi pentru a scrie cod mai puternic şi mai flexibil. Prin urmare există 3 beneficii majore ale procedurilor stocate: simplitate, securitate şi performanţă. Pentru a practica efectiv în folosirea procedurilor stocate, va trebui să folosiţi surse de informare care se găsesc din belşug în librării şi pe Internet. Tranzacţii. Tranzacţiile sunt facilităţi ale limbajului SQL care asigură că loturile de operaţii SQL sunt executate complet sau deloc. Ştim că tabelele unei baze de date relaţionale sunt legate între ele prin intermediul cheilor primare şi cheilor externe. Prin urmare, unele modificări dintr-un tabel produce modificări de date în alt tabel.

165

Baze de date

Capitolul 4

De exemplu, dacă se adaugă o comandă în tabelul tblComenzi, în tabelul tblDetaliiComenzi trebuie introduse articolele acelei comenzi. Mai întâi se completează tabelul tblComenzi, apoi se completează tabelul tblDetaliiComenzi. Se pune întrebarea, ce se întâmplă dacă în timpul completării articolelor comenzii în tabelul tblDetaliiComenzi, se întrerupe curentul sau nu există suficient spaţiu pe hard-disc? Evident, va apare o comandă care nu are articole, sau o comandă care nu are toate articolele, oricum o situaţie nereală. Cu siguranţă, au fost multe astfel de situaţii, ceea ce i-a forţat pe creatorii limbajului SQL să găsească soluţii de rezolvare. Astfel au fost inventate tranzacţiile. Prelucrarea de tranzacţii este un mecanism folosit pentru gestionarea seturilor de operaţii SQL ce trebuie executate în loturi, pentru ca baza de date să nu conţină niciodată rezultatele unor operaţii parţiale. Prin intermediul prelucrării de tranzacţii, vă puteţi asigura că seturile de operaţii nu sunt întrerupte în mijlocul prelucrării – ele sunt fie complet executate, fie deloc. Dacă nu intervine nici o eroare, întregul set de instrucţiuni este executat, iar datele sunt trecute în tabelele bazei de date. Dacă apare o eroare, atunci se poate derula în mod automat o revenire la starea iniţială, stare cunoscută şi sigură. Datorită importanţei şi complexităţii tranzacţiilor, acestea sunt folosite numai de programatorii profesionişti, iar nivelul acestui curs este de a vă iniţia în folosirea limbajului SQL. Dacă aţi înţeles până acum mecanismul acestui limbaj, veţi putea trece fără probleme şi la părţile sale avansate, pentru că oricum aveţi baza de plecare. Desigur, trebuie să mai studiaţi bibliografie, care se găseşte azi din belşug, atât scrisă cât şi pe Internet. Cursoarele. Uneori şi nu de puţine ori, în aplicaţiile performante este nevoie de parcurgerea unui set de date provenite dintr-o interogare, aşa cum se parcurg liniile unui tabel al bazei de date. Acest lucru este realizat cu ajutorul cursoarelor. Un cursor este o interogare în baza de date stocată în serverul SGBD – nu o instrucţiune SELECT, ci rezultatul acesteia, adică date efective. Odată ce cursorul este stocat, aplicaţia poate să deruleze sau să răsfoiască în sus şi în jos prin date, după cum este nevoie.

166

Baze de date

Capitolul 4

Concluzii SQL este limbajul cel mai răspândit în lucrul cu bazele de date. Indiferent dacă sunteţi programator de aplicaţii, administrator de baze de date (vezi Anexa A), designer de aplicaţii Web sau utilizator al suitei Microsoft Office, o bună cunoaştere a limbajului SQL, constituie o parte importantă a interacţiunii cu bazele de date. Sunt azi o mulţime de cărţi despre limbajul SQL şi unele sunt chiar foarte bune, toate au însă un lucru comun: conţin prea multe informaţii pentru majoritatea utilizatorilor. Lipsesc exemplele simple, sugestive care, de multe ori, fac mai mult decât pagini întregi de explicaţii sterile. Capitolul 4, pe care tocmai l-aţi parcurs, va pus la dispoziţie acele cunoştinţe care vă pot ajuta să dezvoltaţi aplicaţii de baze de date la un nivel cerut de multe firme mici sau medii în care aţi putea lucra. Exemplele prezentate vă pot ajuta să înţelegeţi multe din aspectele practice ale folosirii limbajului SQL. Acei dintre dumneavoastră care vor ajunge administratori de baze de date, găsesc aici informaţii preţioase pentru activitatea lor curentă. Pentru cei care doresc mai mult, pot trece la studierea şi aplicarea elementelor avansate ale limbajului SQL, cum sunt procedurile stocate, tranzacţiile, cursoarele etc.

În capitolul următor, veţi avea ocazia să folosiţi limbajul SQL în cadrul sistemului de gestiune a bazelor de date relaţionale ACCESS.

167

Baze de date

Capitolul 5

Capitolul 5. Utilizarea programului ACCESS În acest capitol veţi învăţa să folosiţi cel mai popular sistem de gestiune a bazelor de date relaţionale, numit Access. Acesta face parte din produsul Microsoft Office al firmei Microsoft. Veţi aplica „pe viu” tot ce aţi învăţat în capitolele precedente, veţi da viaţă bazelor de date pe care le-aţi proiectat. Acum veţi înţelege cu adevărat unele lucruri peste care aţi trecut mai uşor în faza de proiectare.

Prezentare generală Microsoft ACCESS este baza de date folosită la birou de mii de utilizatori, care doresc să-şi stocheze şi să-şi acceseze cu uşurinţă datele de interes personal, precum şi în medii cu mai mulţi utilizatori. În această prezentare se va lucra cu varianta ACCESS 2002 din pachetul MS OFFICE XP, al cărui format standard este de ACCESS 2000. Trebuie reţinut faptul că ACCESS este atât un sistem de stocare a datelor, cât şi un sistem de gestiune a acestora. Una dintre facilităţile sale importante este interfaţa grafică uşor de înţeles care permite crearea interogărilor, formularelor şi rapoartelor – facilitate care lipseşte din multe baze de date mai mari şi mai complexe. Cu alte cuvinte, chiar şi programatorii fără prea mare experienţă pot să se folosească de ACCESS pentru a transforma un vraf de facturi, un fişier cu numele clienţilor, un registru contabil şi o listă de stocuri într-o bază de date relaţională, în care introducerea, actualizarea şi raportarea informaţiilor să se poată face cu un clic pe un buton. O caracteristică importantă a bazelor de date ACCESS este faptul că toate componentele sale tabele, formulare, interogări şi rapoarte se păstrează într-un singur fişier. Acest lucru face ca operaţiunile din interiorul bazei de date să se facă rapid. Acest fişier are extensia .mdb şi poate fi copiat cu uşurinţă dintr-o locaţie în alta. Limbajul SQL din ACCESS are toate posibilităţile descrise în capitolul anterior.

168

Baze de date

Capitolul 5

Tot ce aţi învăţat în capitolele precedente, începând cu terminologia, relaţiile între tabele, integritatea datelor şi diagrame veţi regăsi în ACCESS într-o formă specifică acestui program. Mulţi începători sunt frustraţi de faptul că tabelele ACCESS, deşi seamănă oarecum cu cele din Excel, au un comportament total diferit. Dacă aceştia încearcă să facă vreo analogie cu tabelele din Excel, înseamnă că au mari lacune în înţelegerea bazelor de date. Deoarece elementele teoretice ale bazelor de date au fost tratate în capitolele precedente, în mediul ACCESS vom pune accent numai pe aplicarea în practică a acestor cunoştinţe. Conceptele teoretice vor fi amintite ca nişte lucruri cunoscute. Veţi observa că ACCESS tratează anumite concepte într-o manieră proprie, chiar abuzează de anumite ajutoare (wizard), care de multe ori derutează utilizatorii, împiedicându-i să abordeze logic anumite operaţii. Principalele caracteristici ale sistemului de gestiune a bazelor de date ACCESS sunt:  Lucrează sub sistemul de operare Windows;  Este deschis comunicării cu alte sisteme de gestiune a bazelor de date cum ar fi FoxPro sau Paradox;  Este compatibil cu tehnologia ActiveX care permite realizarea aplicaţiilor client/server;  Permite aplicarea unor aplicaţii complexe prin utilizarea limbajului Visual Basic;  Permite comunicarea cu SQL Server, un alt produs Microsoft care gestionează baze de date;  Permite accesul la baze de date din reţeaua Internet, fiind un instrument util pentru publicarea informaţiilor în paginile Web;  Conţine instrumente wizard care permit utilizatorului crearea facilă a unor obiecte componente ale bazei de date (tabele, formulare, interogări, rapoarte).  Oferă posibilitatea creării unei cópii a bazei de date;  Permite utilizarea instrumentului wizard pentru crearea a peste 20 de tipuri comune de aplicaţii;

169

Baze de date

Capitolul 5

 Permite utilizarea obiectelor ACCESS în alte aplicaţii rulate sub Windows.  Permite utilizarea de adrese şi legături Internet.

Interfaţa programului ACCESS Pentru a lucra cu orice aplicaţie informatică, primul lucru pe care trebuie să-l facem este să-i cunoaştem interfaţa de pornire. Pentru ACCESS interfaţa de pornire apare după lansarea acestuia cu metoda generală Start / Programs / Microsoft Access. Veţi găsi repede programul observând că iconiţa sa conţine mică cheie de yală. Toate capturile şi descrierile se referă la versiunea Access 2002. Dacă aveţi altă versiune trebuie să ţineţi cont de diferenţele care ar putea apare, care nu sunt, oricum, esenţiale. Spre deosebire de alte programe Microsoft, programul ACCESS începe cu o casetă de dialog în care vi se cere numele şi să alegeţi directorul bazei de date pe care doriţi să o deschideţi, chiar dacă este una nouă (Blank Database). După ce aţi dat numele bazei de date noi, numită aici „db1”, va apare interfaţa din figura 5.1.

Fig. 5.1. Interfaţa de pornire Access (fereastra Database)

După cum se vede, o bază de date ACCESS poate fi definită ca o colecţie de obiecte:  Tabele (tables)  Cereri de interogare (queries) 170

Baze de date

    

Capitolul 5

Formulare (forms) Rapoarte (reports) Pagini Web (pages) Comenzi macro (macros) Module (modules)

În continuare vor fi prezentate, pe scurt, aceste obiecte, urmând să fie reluate atunci când le vom folosi efectiv. Tabele (tables) sunt obiecte definite de utilizator în care sunt stocate datele. Sunt obişnuitele tabele ale bazelor de date. Formulare (forms) sunt obiecte care permit introducerea datelor, afişarea acestora sau controlul întregii aplicaţii. Acestea vă permit să faceţi aplicaţii performante chiar dacă sunteţi un începător în baze de date. Cereri de interogare (queries) sunt obiecte care permit vizualizarea informaţiilor obţinute prin prelucrarea datelor din una sau mai multe tabele şi/sau alte cereri de interogare. Aici veţi folosi din plin cunoştinţele dobândite despre limbajul SQL. Rapoarte (reports) sunt obiecte care permit formatarea şi tipărirea informaţiilor obţinute în urma consultării bazei de date, sub formă de documente pe hârtie. Pagini Web (pages) reprezintă un obiect care include un fişier HTML şi alte fişiere suport în vederea furnizării accesului la date prin intermediul Internet-ului. Comenzi macro (macros) reprezintă un obiect care conţine o definiţie structurată a uneia sau mai multor acţiuni pe care ACCESS le realizează ca un răspuns la un anumit eveniment. Module (modules) reprezintă un obiect care conţine proceduri definite de utilizator, scrise în limbajul Visual Basic. Iată o ocazie de a vă etala cunoştinţele de Visual Basic. Pe lângă obiectele prezentate, pe interfaţa de pornire, mai există câteva butoane (Open, Design, New, un buton de ştergere şi câteva de afişare a

171

Baze de date

Capitolul 5

obiectelor) a căror înţelegere şi rol este uşor de dedus, de aceea nu vor mai fi prezentate. După cum spuneam, ACCESS-ul are un instrument numit wizard care vă va ajuta să construiţi mai uşor tabele, formulare sau interogări, dar un singur lucru nu poate face: să vă suplinească lipsa cunoştinţelor dobândite în capitolele precedente. Astfel, dacă nu aţi înţeles mecanismul legăturilor dintre tabele, e puţin probabil că veţi ajunge la rezultate mulţumitoare, chiar dacă sunteţi „monitorizaţi” îndeaproape de instrumentul wizard.

Crearea tabelelor Înainte de a începe să creaţi tabele, este de la sine înţeles că aveţi deja un proiect de bază de date, sau dacă sunteţi la început de studiu, măcar o diagramă de relaţii şi structurile tabelelor. Spuneam la începutul acestui curs, cât de important e să aveţi un proiect corect de bază de date, pentru a nu avea probleme la faza de implementare. Crearea structurii tabelelor se poate face în trei moduri:  Utilizând fereastra de proiectare (Create table in design view);  Utilizând instrumentul Wizard (Create table by using wizard);  Prin introducerea datelor (Create table by entering data). Consider că modul cel mai eficient de creare a tabelelor, care se potriveşte utilizatorilor români, îl reprezintă primul mod (Create table in design view), motiv pentru care va fi prezentat numai acesta. Pentru a vă satisface curiozitatea nu aveţi decât să le încercaţi pe celelalte două, pentru a ajunge la o concluzie. Revenind la primul mod de creare a unui tabel, daţi un dublu clic pe Create table in design view şi pe ecran va apare fereastra Table din figura 5.2.

Fig. 5.2. Fereastra Table

172

Baze de date

Capitolul 5

Înţelegerea acestei ferestre nu e grea: sunteţi invitaţi să daţi numele câmpurilor (Field Name), să alegeţi din combobox tipul de dată pentru câmpul respectiv (Data Type) şi să introduceţi o scurtă descriere, acolo unde este cazul, despre ce va conţine acel câmp (Description). Pentru alegerea tipului de dată, revedeţi paragraful Anatomia unei specificaţii de câmp din capitolul 3. În toolbar-ul de sub meniul din figura 5.2, există mai multe butoane, unele cunoscute din alte aplicaţii Windows. Există un buton (cel cu o cheiţă) pe care nu l-aţi mai întâlnit până acum. Acest buton vă ajută să stabiliţi cheia principală a tabelului pentru câmpul curent (cel cu săgeata din stânga), printr-un simplu clic pe el. În funcţie de tipul de dată ales pentru câmp, în partea de jos apare un subtabel în care puteţi seta proprietăţile câmpului curent. Aceste proprietăţi sunt adaptate tipului de dată: număr, text, data calendaristică etc. Să luăm pe rând aceste proprietăţi, având ca reper tipul de dată numeric: Field Size este dimensiunea câmpului. Executarea unui clic pe săgeata derulantă va deschide o listă de opţiuni privind dimensiunea câmpului. Format este formatul sub care se prezintă valoarea introdusă în câmp. Executarea unui clic pe săgeata derulantă va deschide o listă de opţiuni privind formatul câmpului. Decimal Places este proprietatea care stabileşte numărul de zecimale ce pot fi atribuite câmpului. Se poate alege un număr între 0 şi 15, sau Auto pentru determinarea automată a numărului de zecimale. Input Mask reprezintă impunerea unui format de introducere pentru toate datele acelui câmp. Formatul de introducere are o mare importanţă în cadrul câmpurilor ce conţin date de tip text sau dată calendaristică. Caption este eticheta pentru specificarea unui nume atribuit câmpului, în cazul în care acesta este utilizat în cadrul formularelor sau când tabelul respectiv este afişat. Default Value este o valoare care este atribuită automat, în momentul când utilizatorul nu introduce nici o valoare în acel câmp.

173

Baze de date

Capitolul 5

Validation Rule este criteriul care va fi verificat înainte de validarea valorii introduse în acel câmp. Criteriul este introdus sub formă de expresii care folosesc:  Operatorii: =, +, -, *, /, <, >, <=, >=, AND, OR, BETWEEN, IN, IS NULL;  Identificatorii se dau în paranteze drepte [];  Funcţii;  Constante; Validation Text reprezintă textul care va apărea pe bara de mesaje în cazul în care valoarea introdusă nu respectă criteriul impus de regula de validare. Required este proprietatea care stabileşte dacă introducerea unei valori în acel câmp este obligatorie. Acest câmp poate avea una din valorile Yes / No. Indexed este proprietatea care stabileşte dacă acel câmp are un index care acceptă valori duplicat sau numai valori unice. Dacă nu dorim un index pentru acel câmp se alege valoare No. Proprietăţile descrise mai sus se refereau la tipul de câmp Numeric. Pentru alte tipuri de câmp vor apare şi proprietăţi noi (cele mai multe rămân). Astfel, datele de tip Text şi Memo au o proprietate numită Allow Zero Length, adică admiterea lungimii zero. Această proprietate are valoarea Yes sau No. O proprietate importantă pentru câmpul care conţine date de tip Autonumber este New Values. Opţiunile Increment sau Random permit stabilirea modului în care câmpului respectiv i se vor acorda valori automat de către sistem. Relaţii între tabele Relaţiile dintre tabele sunt lucruri cunoscute, deja, de către oricare dintre dumneavoastră, nu-i aşa? Să vedem acum ce modalitate foloseşte ACCESS-ul pentru a face legătura între tabele. Din punct de vedere al momentului creării acestora, există 2 tipuri de relaţii între tabelele unei baze de date ACCESS şi anume:  Relaţii permanente – se stabilesc după definirea tabelelor şi sunt cerute de modelul relaţional făcând parte din structura bazei de 174

Baze de date

Capitolul 5

date. Aceasta se realizează, de obicei, prin corespondenţa cheie primară – cheie externă şi sunt memorate în baza de date.  Relaţii temporare – se stabilesc între tabele cu ocazia definirii unor cereri de interogare, nefiind înregistrate în structura bazei de date. După cum ştim, între două tabele între care există o relaţie, datele nu pot fi introduse oricum. De exemplu, dacă într-o bază de date avem tabelele tblFacturiPrimite şi tblFurnizori între care există o relaţie „unu cu mai mulţi”, nu putem introduce date în tabelul tblFacturiPrimite până nu avem cel puţin un furnizor în tabelul tblFurnizori. Cum rezolvă ACCESS-ul această prevedere din proiectul bazei de date (tipul de participare)? Prin impunerea integrităţii referenţiale (Enforce Referential Integrity), după cum se vede în figura 5.3.

Fig. 5.3. Stabilirea integrităţii referenţiale

Cele 2 opţiuni din partea de jos, Cascade Update Related Fields şi Cascade Delete Related Fields, se referă la actualizarea respectiv ştergerea tuturor câmpurilor legate prin această relaţie. În urma acestei setări, s-a făcut o legătură unu cu mai mulţi între cele două tabele, a cărei reprezentare se vede în figura 5.4. Fig. 5.4. Diagrama de relaţie între cele 2 tabele, aşa cum apare în ACCESS.

175

Baze de date

Capitolul 5

Stabilirea legăturilor între tabele se face, fie în faza de creare a tabelului (folosind Lookup Wizard), fie în fereastra Relationship care se afişează cu butonul , din toolbar-ul din fereastra Database. Printr-un clic pe acest buton se deschide tabela Relationship prezentată în figura 5.5. Dacă nu apar toate tabelele în fereastra Relationship, cu un clic-dreapta în interiorul acesteia apoi alegând opţiunea Show Table va fi afişată fereastra Show Table, cu care se pot adăuga şi celelalte tabele. Legătura dintre tabele se face „trăgând cu mouse-ul” câmpul de legătură dintr-un tabel „peste” câmpul corespunzător din celălalt tabel. După ce s-a făcut legătura, putem face un clic-dreapta pe legătură, apar 2 posibilitaţi: Edit Relationship... şi se deschide caseta de dialog pentru stabilirea integrităţii referenţiale arătată în figura 5.3, respectiv Delete cu care putem şterge legătura. Când citiţi această secvenţă, este bine să o faceţi cu calculatorul în faţă, deoarece altfel, aceste manevre sunt greu de înţeles. Dacă ceva nu aţi înţeles, întrebaţi profesorul care vă îndrumă la laborator.

Fig. 5.5. Tabela Relationship

176

Baze de date

Capitolul 5

Tabelele nu sunt de la început aşa frumos aranjate. O să vedeţi cum veţi găsi aceste tabele, dar prin „tragere” cu mouse-ul se pot aranja ca să fie mai uşor de urmărit. Încercaţi aceste manevre pentru a vă obişnui cu ele. Crearea relaţiilor cu Lookup Wizard...

Cea mai comodă cale de a crea relaţii permanente între două tabele este folosirea facilităţii Lookup Wizard, pusă la dispoziţia noastră de programul ACCESS. Această metodă constă în „legarea” tabelelor în faza de proiectare prin intermediul unei chei primare şi a unei chei externe. Prima dată de proiectează tabelul din partea „unu” a relaţiei unu cu mai mulţi. La cel de-al doilea tabel, când se defineşte câmpul de legătură, pentru tipul de dată (Data Type) se alege opţiunea Lookup Wizard... (ultima dintre opţiuni). În urma acestei manevre se deschide caseta de dialog din figura 5.6.

Fig. 5.6. Primul pas al procedurii Lookup Wizard

Se alege prima opţiune, cea care ne spune că vom lega câmpul nostru cu un alt câmp dintr-un tabel sau o interogare, I want the lookup.... Merită explicată şi opţiunea a doua I will type in the values that I want, care ne spune că putem lega acest câmp cu o listă de valori introduse de noi chiar în această fază. Această opţiune este indicat să o folosiţi când aveţi un număr mic de valori pe care poate să le ia un anumit câmp. Încercaţi şi această variantă pentru a-i înţelege rolul. Cu butonul Next se avansează în pasul următor când vi se cere să alegeţi, dintr-o listă, tabelul cu care va fi legat. După alegerea tabelului, veţi alege cheia primară şi un alt câmp pentru a identifica înregistrarea (acest lucru îl veţi înţelege când veţi introduce, efectiv, date în tabel). Această manevră se vede în figura 5.7. 177

Baze de date

Capitolul 5

Fig. 5.7. Alegerea câmpului de legătură

În cazul nostru se vor selecta câmpurile TaraID şi Denumire, care vor fi trecute în fereastra din dreapta. Cu butonul Next se va trece la pasul următor (figura 5.8) care ne recomandă să face invizibilă coloana cu cheia primară, pentru că la operare nu ne va ajuta cu nimic, fiind un cod numeric fără semnificaţie pentru noi.

Fig. 5.8. Recomandarea pentru a face invizibilă cheia primară

Cu butonul Next se trece la pasul următor care vă cere să stabiliţi numele câmpului care va apare în rapoarte, de regulă se lasă cel implicit, propus de calculator. După această manevră se alege butonul Finish care ne va avertiza că o relaţie a fost creată şi că ar trebui salvată. Dacă nu s-a greşit nimic, se apasă butonul Next.

Fig. 5.9. Avertizarea de salvare a relaţiei create.

178

Baze de date

Capitolul 5

Pentru a verifica relaţia creată se apasă butonul , care va deschide foaia Relationships. Cu un clic-dreapta pe linia relaţiei o puteţi edita sau şterge. Încercaţi această manevră pentru a înţelege ce se întâmplă. Diferenţa între cele două tipuri de legături permanente, legarea prin metoda ”tragerii” (drag and drop) în fereastra Relationship şi legarea prin metoda Lookup Wizard..., nu prea iese în evidenţă decât la crearea formularelor de introducere a datelor. La prima metodă Access-ul va pune automat o casetă de text (textBox) în care trebuie să introducem manual valori de la tastatură, iar la a doua metodă va apare în formular o casetă combinată (comboBox), din care putem alege elegant valoarea din lista afişată. Dacă aţi reuşit să înţelegeţi aceste diferenţe, înseamnă că aţi făcut un pas important spre a putea crea aplicaţii Access tot mai performante. Poate în acest moment nu sesizaţi diferenţele dintre cele două metode, dar cu siguranţă, le veţi înţelege atunci când veţi crea formulare, puţin mai târziu.

Introducerea datelor în tabele După ce s-au definit tabelele, s-au creat legăturile între ele, urmează, firesc, completarea acestora cu date. Cea mai simplă metodă este să faceţi un dublu-clic pe numele tabelului, ceea ce face să se deschidă tabelul, care seamănă mult cu un tabele Excel, şi să introduceţi pur şi simplu date. Adesea, anumite înregistrări din tabel prezintă un interes deosebit, de aceea acestea trebuie filtrate temporar, adică trebuie făcute invizibile celelalte. Un filtru poate fi aplicat unui tabel, unei cereri de interogare, unui formular sau unui raport. Filtrul este salvat împreună cu fiecare obiect şi poate fi activat sau nu, după nevoie. Un filtru este util pentru realizarea următoarelor operaţii:  Selectarea unui număr de înregistrări similare;  Lucrul cu un subset de înregistrări;  Vizualizarea datelor într-o anumită ordine;  Localizarea unei înregistrări folosind doar informaţiile cunoscute. 179

Baze de date

Capitolul 5

În momentul în care un tabel sau un formular este vizualizat, în cadrul barei de meniuri va apare opţiune Records care permite operaţiile de filtrare. Există mai multe opţiuni de filtrare, dar cele mai folosite sunt următoarele două:  Filtrarea by Selection – filtrare conform selecţiei, este cea mai rapidă şi mai simplă metodă de aplicare a unui filtru. Pentru a stabili criteriul de filtrare, se selectează un set de date dintr-unul din câmpurile unui tabel, după care se apasă butonul

,

rezultând tabelul filtrat. Pentru revenire se apasă butonul (Remove Filter). Cu această metodă se pot filtra înregistrările numai pe baza unui criteriu aplicat unui singur câmp al tabelului.  Filter by Form – filtrare conform formularului, este metoda în care criteriul de filtrare se introduce într-un tabel gol. Pentru a aplica această metodă apăsaţi butonul , care va deschide tabelul fără nici o înregistrare. Nu aveţi decât să alegeţi valorile dorite din câmpurile vizate, rezultând un criteriu de filtrare oricât de complex, poate (atenţie) aşa de complex că nu vă afişează nimic, având în vedere că toate condiţiile trebuie îndeplinite în acelaşi timp. Pentru revenire se apasă butonul Filter).

(Remove

Salvarea tabelelor se face la ieşirea din modul de proiectare, când sunteţi întrebat ce nume va avea noul tabel, sau în orice moment al procesului de proiectare a tabelului, dând comanda Save, sau apăsând cunoscutul buton de salvare a documentelor Windows. Puteţi schimba numele unui tabel făcând un clic dreapta pe numele său. De asemenea, puteţi face oricâte cópii ale unui tabel pentru diferite acţiuni, mai ales când încercaţi expresii SQL, având în vedere că după ce aţi executat o operaţie SQL nu mai puteţi reveni la starea iniţială a tabelului. În aplicaţii, introducerea datelor se face elegant folosind formularele specializate, cu tot felul de facilităţi, aşa cum se va vedea mai departe în cadrul acestui curs.

180

Baze de date

Capitolul 5

Formulare Formularele sunt obiecte de comunicaţie între un utilizator şi o aplicaţie de baze de date ACCESS. Ele permit atât introducerea, cât şi vizualizarea datelor într-o manieră cât mai atractivă. Într-o aplicaţie formularele îndeplinesc următoarele roluri:  Afişarea şi editarea datelor. Este rolul cel mai des folosit al unui formular, prin care se pot afişa şi modifica date dintr-o bază de date.  Controlul operaţiilor realizate de o aplicaţie. Se pot proiecta formulare de aplicaţie care să conţină interfeţe de interacţiune cu utilizatorul, folosind proceduri Visual Basic sau macro-uri.  Introducere de date. Introducerea datelor cu formulare clare, pe înţelesul operatorului este una din premisele unei aplicaţii de succes.  Tipărirea informaţiilor. Chiar dacă mai rar, formularele pot fi folosite pentru tipărirea de informaţii la imprimantă. În general, un formular este compus din 3 părţi: antetul, zona de detaliu şi subsolul. În zona de detaliu sunt prezentate, de fapt, datele. În antet şi subsol sunt prezentate acele informaţii statice care nu se schimbă pe măsură ce edităm alte înregistrări. Reţineţi faptul că, în spatele fiecărui formular există un tabel sau o interogare. Excepţie fac formularele folosite ca interfaţă a unei aplicaţii. Majoritatea formularelor cu care lucrăm noi, în cadrul acestui curs, fac parte din prima categorie, adică cele care au ataşate un tabel sau o interogare. Crearea unui formular Un formular se poate crea prin mai multe moduri, dar cele mai utilizate sunt cele pe care o să le folosim şi noi:  Creare automată – prin utilizarea instrumentului wizard;  Creare manuală – cu ajutorul ferestrei de proiectare. 181

Baze de date

Capitolul 5

În continuare vor fi prezentate pe larg cele două metode de creare a formularelor. Crearea automată a unui formular

Această metodă este cea mai facilă, practic, calculatorul face tot, noi trebuie să alegem numai anumite opţiuni care sunt foarte sugestive şi clare. Pentru a crea formularul, în fereastra Database se apasă, în ordine, butoanele Forms (din stânga) şi New (de sus). În figura 5.10 se poate vedea fereastra Database.

Fig. 5.10. Fereastra Database

În urma acestei acţiuni va apare fereastra New Form, aşa cum se vede în figura 5.11.

Fig. 5.11. Fereastra NewForm

Din acest comboBox se alege tabelul asociat formularului

182

Baze de date

Capitolul 5

Din această fereastră alegem opţiunea Form Wizard şi alegem tabelul tblGrupe din caseta comboBox, apoi apăsăm butonul OK. În urma acestei manevre va apare fereastra din figura 5.12, cu ajutorul căreia putem alege câmpurile care vor face parte din formular.

Fig. 5.12. Alegerea câmpurilor formularului

În fereastra următoare putem selecta modul cum vor apare datele în cadrul formularului, aşa cum se vede în figura 5.13.

Fig. 5.13. Alegerea formei de prezentare

Puteţi încerca mai multe opţiuni pentru a vedea diferenţele dintre ele. După ce v-aţi decis asupra unei opţiuni şi aţi apăsat butonul Next, va apare fereastra cu ajutorul căreia puteţi alege fundalul formularului, după cum se vede în figura 5.14. 183

Baze de date

Capitolul 5

Fig. 5.14. Alegerea fundalului formularului

După ce v-aţi decis asupra unui fundal şi aţi apăsat butonul Next, va apare ultima fereastră a acestui scenariu, în care puteţi alege numele noului formular pe care tocmai l-aţi creat. Acest pas se poate vedea în figura 5.15.

Fig. 5.15. Alegerea numelui formularului şi încheierea operaţiunii

Pe această fereastră există 2 butoane de opţiune, primul ne spune că la ieşirea din el, formularul va fi automat deschis, iar al doilea ne spune că forma va fi deschisă în modul Design în care putem să facem modificări ale acesteia. Încercaţi ambele opţiuni pentru a vedea efectul. După apăsarea butonului Finish va apare afişat formularul pe care tocmai l-am construit, aşa cum se vede în figura 5.16.

Fig. 5.16. Forma finală a formularului

184

Baze de date

Capitolul 5

Deşi crearea automată a formularului este mai rapidă şi mai uşoară, adevăraţii profesionişti o folosesc mai rar, deoarece este mai rigidă şi îşi cam impune punctul de vedere. Formularele cu adevărat profesionale se fac manual, aşa cum se va vedea în continuare. Crearea manuală a unui formular

Cu această metodă se pot crea formulare pornind de la zero. Chiar dacă la început această metodă poate părea dificilă, este o cale de a construi formulare adaptate nevoilor utilizatorilor, atât din punct de vedere funcţional cât şi al design-ului. Abilitatea de a concepe formulare utile şi atractive se obţine numai prin experienţă, de aceea nu trebuie să vă faceţi probleme dacă primele voastre formulare sunt criticate de utilizatorii lor. Reţineţi aceste critici pentru a modifica formularele sau pentru a le folosi în viitoarele formulare pe care le veţi proiecta. De altfel, cei care veţi ajunge proiectanţi de baze de date veţi avea propriile voastre şabloane, obţinute în urma experienţei acumulate. Cel mai simplu mod de a înţelege cum se crează un formular plecând de la zero, fără nici un ajutor, este să prezentăm un exemplu. Ne propunem construim acelaşi formular plecând de la zero. Vom executa paşii următori: 1. Din interfaţa Database selectăm Forms din bara de obiecte. 2. Din fereastra care se deschide alegem New – Design view. 3. Se va deschide fereastra din figura 5.17, care arată forma în faza iniţială. Se observă apariţia Toolbox-ului cu obiecte care se pot pune pe interfaţă, care seamănă cu cel din Visual Basic.

185

Baze de date

Capitolul 5

Bara de titlu

Toolbox – caseta cu obiecte

Fig. 5.17. Forma iniţială a formularului

Caseta Toolbox poate fi mutată cu mouse-ul oriunde pe suprafaţa formei ca să nu ne încurce vizibilitatea.Secţiunile formularului se văd în figura 5.17. Acestea sunt: Form Header şi Form Footer sunt antetul şi subsolul formularului în care se afişează informaţii precum titlurile. Dacă se tipăreşte formularul, informaţiile din antet şi subsol apar o singură dată, pe prima pagină. Nu ezitaţi să plasaţi în antet sau subsol oricare din butoanele asociate unor operaţii. Page Header şi Page Footer sunt antetul şi subsolul paginilor, şi sunt similare cu cele ataşate direct la formular, cu principala diferenţă că secţiunile de pagină se tipăresc pe fiecare pagină, iar cele de formular numai pe prima. Secţiunile de antet şi subsol de pagină nu apar la vizualizareaformularului, dar sunt folosite de Access la tipărirea acestuia. Detail este secţiunea de bază a fiecărui formular care nu poate lipsi, spre deosebire de celelalte care pot lipsi. Aici sunt afişate, practic, informaţiile pentru care a fost conceput formularul.

186

Baze de date

Capitolul 5

În exemplul nostru, mergem mai departe şi populăm formularul cu obiectele potrivite, etichete, casete de text, butoane de navigare etc. Mai întâi scăpăm de secţiunile de antet şi subsol ale formularului şi paginilor dând comanda View şi deselectând opţiunile Page Hedear/Footer şi Form Hedear/Footer. Construim apoi obiectele de pe interfaţă, aşa cum făceam în Visual Basic. Nu uitaţi să afişaţi instrumentele folosite, cu ajutorul butonului Toolbox ( ). Rezultatul este prezentat în figura 5.18.

Proprietatea Record Source stabileşte tabelul asociat formularului

Fig. 5.18. Formularul, aşa cum arată în modul Design Proprietatea Control Source face asocierea între cele 3 casete de text şi câmpurile tabelului asociat formularului

Observaţi cum se face legătura fiecărui câmp cu obiectul corespunzător. Trebuie numai să selectăm fiecare obiect şi la proprietatea Control Source să alegem câmpul corespunzător. Pentru întregul formular trebuie să alegem tabelul asociat, în cazul prezentat acesta este tblGrupee.

187

Baze de date

Capitolul 5

După ce activăm formularul cu butonul următoare, 5.19.

, acesta va arăta ca în figura

Fig. 5.19. Formular obţinut de la zero

Se observă că acest formular este mai arătos, are un titlu pus şi are introdusă şi data la care se foloseşte – Data curenta:, în care s-a folosit funcţia Now() ataşată de caseta de text respectivă, care-l face mai util. Exemplul prezentat nu este unul spectaculos, dar este un bun început care vă poate folosi ca model. După modelul prezentat, încercaţi să creaţi un formular după un tabel pe care l-aţi conceput singuri. Observaţie importantă! În practică se foloseşte o tehnică mixtă, adică se porneşte cu metoda wizard, după care se intervine manual pentru a o modifica, ştergând unele controale inutile şi adăugând alte obiecte.

188

Baze de date

Capitolul 5

Formulare cu subformulare Un formular ca cel prezentat în paragraful anterior este unul banal, bun pentru a înţelege cam cum se pune problema. Cu siguranţă, nu vă veţi opri la acest stadiu şi veţi dori să faceţi formulare cu adevărat utile, mai ales că aplicaţiile cu baze de date este un domeniu tot mai căutat, nu-i aşa? Este puţin probabil că veţi crea formulare profesionale fără să folosiţi şi nişte subformulare. Un subformular, nu este altceva decât un formular inclus în alt formular, pentru a permite afişarea informaţiilor din mai multe tabele sau cereri de interogare, aflate în relaţii 1:1 sau 1:N. Astfel, în formularul principal vor fi afişate datele din partea unu a relaţiei, iar în subformular cele din partea mai mulţi. Prin urmare, la un moment dat în formular va fi afişată o înregistrare din partea unu a relaţiei, iar în subformular înregistrările corespondente din partea mai mulţi a relaţiei. Un formular poate conţine chiar mai multe subformulare. Pentru a crea un formular cu subformulare incluse se poate proceda în 3 moduri:  Crearea formularului şi subformularului concomitent;  Crearea subformularului şi adăugarea lui la un formular existent;  Crearea separată a celor două formulare şi apoi combinarea lor. Dintre acestea, ultima variantă este cea mai simplă, aşa că pe aceasta o vom folosi şi noi. În acest sens se parcurg următoarele etape:  Se creează formularul principal şi se salvează;  Se creează subformularul, la fel ca şi formularul principal;  Se face legătura între formularul principal şi subformular;  Se testează rezultatul. Pentru a înţelege mecanismul creării unui formular care conţine un alt formular inclus, vom lua un exemplu concret. Presupunem că avem o porţiune dintr-o bază de date care conţine 4 tabele: - tblFacturi - tblDetaliiFacturi - tblProduse - tblFurnizori 189

Baze de date

Capitolul 5

Toată lumea ştie ce este o factură, mai ales comercianţii, toate fiind stocate în tabelul tblFacturi. Fiecare factură are mai multe poziţii, corespunzătoare mărfurilor care se facturează, dacă ne gândim la o factură din comerţ. Aceste mărfuri facturate sunt cuprinse în tabelul tblDetaliiFacturi. Pot fi facturate numai produsele cuprinse în tabelul tblProduse. Fiecare factură provine de la un singur furnizor, aceştia fiind cuprinşi în tabelul tblFurnizori. Între aceste tabele există legături, aşa cum am învăţat în capitolul 3, la proiectarea bazelor de date. În figura 5.20 este arătată structura acestei porţiuni a bazei de date. tblFacturi FacturaID ChP NrFactura Data FurnizorID ChE

tblDetaliiFacturi FacturaID ChE ProdusID ChE Cantitate Observatii

tblProduse ProdusID ChP Denumire UM Pret ..............

tblFurnizori FurnizorID ChP Furnizor CodFiscal ...........

Fig. 5.20. Tabelele implicate în formular

Ne propunem să construim un formular cu ajutorul căruia să putem vedea toate facturile primite de la furnizori, precum şi detaliile fiecăreia, adică produsele facturate. Observăm că facturile se află în tabelul tblFacturi, care este în relaţie 1:N cu tabelul tblDetaliiFacturi. De asemenea, observăm că cele 2 tabele conţin câte un câmp care reprezintă coduri (FurnizorID, ProdusID) ceea ce nu ne încântă când le vedem afişate în locul unei denumiri clare, înţelese de oricine. După cum ştim, în spatele fiecărui formular se găseşte un tabel sau o interogare, iar faptul că cele 2 tabele implicate conţin coduri numerice care nu au nici o semnificaţie pentru utilizatorul obişnuit, ne face să ne gândim

190

Baze de date

Capitolul 5

la o interogare. Noi ştim deja să facem interogări cu limbajul SQL, învăţat în capitolul precedent, nu-i aşa? Prin urmare, vom scrie 2 interogări SQL, una pentru formularul principal (cel cu facturile) şi alta pentru subformular (cel cu detaliile facturilor). Iată cele 2 interogări: Interogarea 1. Formularul principal: SELECT tblFacturi.FacturaID, tblFacturi.NrFactura, tblFacturi.Data, tblFurnizori.Furnizor FROM tblFacturi INNER tblFacturi.FurnizorID=tblFurnizori.FurnizorID;

JOIN

tblFurnizori

ON

Interogarea 2. Subformular: SELECT FacturaID, Denumire, UM, Cantitate, Pret, Cantitate*Pret AS Valoare FROM tblDetaliiFacturi AS df INNER JOIN tblProduse AS pr ON df.ProdusID=pr.ProdusID;

Observaţi în aceste expresii SQL cum se face legătura între 2 tabele folosind clauza INNER JOIN ... ON, precum şi expresia AS cu care stabilim alias-uri pentru numele prea lungi ale tabelelor. Observaţi, de asemenea, cum s-a creat câmpul calculat Valoare care este produsul dintre cantitate şi preţ. Pentru a scrie interogările, tabelele bazei de date trebuie să fie completate cu date pentru a putea vedea rezultatele. Fereastra Database trebuie să arate ca în figura 5.21.

Fig. 5.21. Tabelele bazei de date

Pentru a crea cele două interogări trebuie să ajungem în fereastra în care putem scrie expresiile SQL. Pentru aceasta trebuie să parcurgem paşii: 191

Baze de date

Capitolul 5

 Apăsăm butonul Queries, apoi dublu-click pe opţiunea Create query in Design view.  Se deschide fereastra cu cele 4 tabele.  Apăsăm butonul Close.  În partea stângă-sus apare butonul , a cărui apăsare deschide fereastra în care se scriu pe rând cele 2 expresii SQL, adică Interogarea 1 şi Interogarea 2.  Pentru a verifica interogările se apasă butonul Run toolbar-ul superior.

din

 Interogările vor primi numele următoare: Interogarea 1 – qryFacturi, iar Interogarea 2 – qryDetaliiFacturi. Dacă totul a decurs bine, trebuie să obţineţi ca rezultat al interogărilor tabelele din figura 5.22-1, cu observaţia că datele vor fi, probabil, altele. Interogarea 1

Interogarea 2

Fig. 5.22-1. Cele 2 interogări rezultate

În acest moment putem crea 2 formulare care să aibă în spate aceste interogări. Este evident că pentru formularul principal folosim interogarea qryFacturi, iar pentru subformular interogarea qryDetaliiFacturi. Crearea celor 2 formulare se face după metoda prezentată în paragraful precedent, cu observaţia că în loc de tabele alegem interogări pentru a le ataşa acestora. Prima dată se creează formularul frmDetaliiFacturi, după care se crează formularul principal frmFacturi, în care se introduce obiectul 192

Baze de date

Capitolul 5

Subform/Subreport din Toolbox. Când se cere formularul de introdus, alegeţi frmDetaliiFacturi. Când se introduce subformularul, trebuie setate unele proprietăţi care spun programului Access cum se leagă subformularul frmDetaliiFacturi de formularul principal frmFacturi. Aceste proprietăţi sunt Source Object, Link Child Fields şi Link Master Fields, adică numele subformularului şi cele două câmpuri de legatură. Valorile setate pentru aceste proprietăţi se pot vedea în figura 5.22-2. Câmpul de legătură, corespunzător fiecărui formular este FacturaID.

Fig. 5.22-2. Setarea proprietăţilor pentru subformular

La setarea proprietăţilor amintite, cele 2 formulare implicate trebuie sa arate ca în figura 5.23. Câteva precizări:  La subformularul frmDetaliiFacturi se va alege modul de prezentare Datasheet, adică sub formă de tabel.  Pentru a elimina butoanele de navigare din subformular, proprietatea Navigation Buttons se va seta la valoarea No.

193

Baze de date

Capitolul 5

frmFacturi

frmDetaliiFacturi

Fig. 5.23. Formularul cu subformular, în modul Design

Când se activează formularul, adică se scoate din modul Design, acesta va arăta ca în figura 5.24.

Butoane de navigare

Fig. 5.24. Formularul nostru în stare de funcţionare

Cu ajutorul butoanelor de navigare, navigăm printre facturi. La o anumită factură va fi afişată data emiterii şi furnizorul, precum şi detaliile facturii respective, cu ajutorul subformularului. Încercaţi să construiţi şi alte formulare după procedura prezentată, pentru a câştiga experienţă.

194

Baze de date

Capitolul 5

Interogări Fără îndoială, interogările sunt acţiunile cele mai numeroase acţiuni pe care o să le faceţi asupra unei baze de date. Prin interogări nu facem altceva decât să extragem informaţii dintr-o bază de date, motivul pentru care acestea au fost create, nu-i aşa? Interogările care se definesc încă din faza de proiectare a bazei de date se mai numesc şi vederi, aşa cum am văzut în capitolul 2 la definirea terminologiilor. Rezultatul unei interogări este un tabel virtual, adică unul care nu există în baza de date, dar care se generează ori de câte ori este nevoie. Prin aceasta deducem că o interogare se va actualiza de fiecare dată, dacă tabelele implicate au suferit modificări. Interogările şi tabelele sunt singurele obiecte ale bazei de date care se asociază formularelor. Pentru afişarea informaţiilor extrase dintr-o bază de date se parcurge, în general traseul Interogare – Formular. După cum am învăţat în capitolul 4, pentru extragerea informaţiilor dintr-o bază de date se foloseşte limbajul SQL. Cunoştinţele dobândite acolo sunt de un real folos în ceea ce vom face în continuare. În Access există o mare problemă: generarea interogărilor se face cu ajutorul unei aplicaţii grafice, care în faza de învăţare, cum este cazul nostru, produce mai mult confuzii decât să clarifice lucrurile. Din acest motiv, o să folosim limbajul SQL pentru crearea interogărilor, scriind expresiile de la zero. O să vedem mai târziu că şi modulul grafic Wizard generează expresii SQL, dar care nu sunt aşa de clare ca cele scrise de noi, adică conţin şi lucruri inutile, ca orice activitate automată. Crearea interogărilor folosind limbajul SQL Când am învăţat limbajul SQL, am scris expresii pe care am încercat să le înţelegem la nivel de concept, nu ne-am pus problema cum să le verificăm. Acum avem ocazia să testăm expresiile SQL în interiorul programului Access. De aceea este indicat să verificaţi expresiile din capitolul 4 folosind metoda explicată în continuare. Pentru a scrie expresiile SQL corespunzătoare. Veţi proceda astfel:

trebuie

195

să

deschidem

fereastra

Baze de date

Capitolul 5

 În fereastra Database se apasă butonul Queries apoi se dă dubluclick pe opţiunea Create query in Design view .  Se va deschide fereastra Show table unde se apasă butonul Close.  În partea stângă a Toolbar-ului superior, va apare butonul prin apăsarea căruia se deschide fereastra din figura 5.25.

,

Fig. 5.25. Fereastra pentru scrierea expresiilor SQL

Observaţi că în mod automat apare scrisă instrucţiunea „SELECT; ” care se termină cu punct şi virgulă, care semnifică terminarea expresiei SQL. În această fereastră se scriu de mână expresiile SQL. Nu uitaţi de simbolul „ ; ” punct şi virgulă de la sfârşitul expresiei. Pentru verificarea expresiei SQL introduse folosiţi butonul Run SQL localizat conform figurii 5.26.

Fig. 5. 26. Butonul Run SQL

Dacă totul a decurs bine, se va afişa un tabel cu datele generate de interogare. Ca exerciţiu, reluaţi toate exemplele din capitolul 4 şi verificaţi-le cu ajutorul Access-ului. Este evident că mai întâi trebuie să introduceţi şi să populaţi tabelele prezentate acolo. Crearea interogărilor cu aplicaţia Wizard(Design view) A crea o interogare cu vrăjitorul(aplicaţia Wizard) este foarte simplu şi rapid. Singura mare problemă este că începătorii nu prea înţeleg ce fac, 196

Baze de date

Capitolul 5

pentru că prea îi conduce calculatorul. Este mult mai utilă atunci când aveţi o oarecare experienţă şi v-aţi însuşit limbajul SQL. În ce constă problema de fapt? Access-ul ne pune la dispoziţie nişte unelte cu care putem construi interogări numai cu mouse-ul, „trăgând” tabele şi câmpuri, punând condiţii, toate făcându-se la vedere într-o aşa-numită grilă de proiectare a interogării. În final se obţine tot o expresie SQL, pe care o generează calculatorul, în funcţie de manevrele făcute de noi. Pentru a crea o interogare în modul Design view se procedează astfel:  În fereastra Database se dă click pe Queries, apoi pe New. Se va deschide fereastra din figura 5.27

Fig. 5.27. Pasul 1 de creare a unei interogări

 Din caseta New Query se se alege opţiunea Design View – OK. Se obţine caseta din figura 5.28.

Fig. 5.28. Grila de proiectare a interogărilor

197

Baze de date

Capitolul 5

 În caseta de dialog se dă dublu-click pe tabelul care dorim să fie implicat în interogare, iar acesta va apare în zona de sus a formularului. Dacă e nevoie de mai multe tabele, se repetă acţiunea iar la sfârşit se închide caseta cu butonul Close.  Grila de proiectare seamănă cu un tabel, a căror rânduri au următoarele semnificaţii: Field – aici se trag cu mouse-ul câmpurile interogării; Table – aici va apare automat numele tabelului la care aparţine câmpul; Sort

- aici se stabileşte ordinea de sortare, ascendent sau descendent. Dacă nu se scrie nimic sortarea va fi ascendentă;

Show - dacă este bifat, câmpul va fi vizibil, altfel nu; Criteria

- aici se stabilesc criteriile pe care trebuie să le îndeplinească câmpul;

or - se foloseşte pentru criterii complexe.  După ce sau ales tabelele, se fac legăturile între tabele, apoi se trag câmpurile, pe linia Field. Legătura între câmpuri se face trăgând cu mouse-ul un câmp dintr-un tabel şi suprapunându-l peste câmpul corespunzător din celălalt tabel. Această legătură este numai una temporară, folosită numai la interogarea respectivă. O grilă completată se poate vedea în figura 5.29.

Fig. 5.29. Grilă completată

198

Baze de date

Capitolul 5

Se observă că primul câmp a fost folosit numai pentru sortare, el nefiind vizibil în interogare. Pentru vizualizarea interogării se apasă butonul Run ( ), iar rezultatul se vede în figura 5.30.

Fig. 5.30. Rezultatul interogării

Expresia SQL generată automat de Access este următoarea: SELECT tblFacturi.NrFactura, tblFacturi.Data, tblFurnizori.Furnizor, tblFurnizori.CodFiscal FROM tblFacturi INNER JOIN tblFurnizori ON tblFacturi.FurnizorID = tblFurnizori.FurnizorID WHERE (((tblFurnizori.Furnizor)="Promax")) ORDER BY tblFacturi.FacturaID;

Prin urmare, toate manevrele făcute cu mouse-ul au avut ca rezultat această expresie SQL care ar fi putut fi scrisă de la bun început manual. Rămâne la alegerea voastră care metodă este mai bună şi mai instructivă. Practica spune că metoda cea mai eficientă, din punct de vedere al însuşirii cunoştinţelor, este varianta SQL pentru că ajută la înţelegerea deplină a creării interogărilor şi a rolului fiecărei clauze. Deci nu ezitaţi să o folosiţi chiar dacă vi se pare la început mai grea.

199

Baze de date

Capitolul 5

Legarea permanentă a două tabele Încă din faza de proiectare a unei baze de date am văzut că între tabelele sale există legături. Aceste legături se fac între două câmpuri fiecare aparţinând unui tabel, aşa cum se vede din diagrama bazei de date. Ne punem problema „traducerii” acestor legături arătate în diagrame, în cadrul programului Access. Am văzut că în limbajul SQL, legarea a două tabele se face prin clauza INNER JOIN ... ON. Rolul legăturilor dintre tabele se vede în timpul interogărilor. Cum se face legătura între 2 tabele? Există 2 tipuri de legături pe care Access-ul le permite:  Legături permanente, stabilite în faza de proiectare a tabelelor;  Legături temporare, care se stabilesc în timpul creării interogărilor. Legăturile permanente se pot face, la rândul lor în 2 moduri: cu ajutorul ferestrei Relationships (a), respectiv cu vrăjitorul Lookup Wizard (b). a) Fereastra Relationships se deschide cu comanda Tools – Relationships. Se va deschide fereastra care la început este goală, urmând ca noi să tragem în ea tabelele şi să le legăm. În figura 5.31 este arătată o fereastră Relationships, cu legături stabilite. Intuiţi că relaţia 1:N este aici simbolizată prin caracterele 1 şi ∞.

Fig. 5.31. Fereastra Relationships

200

Baze de date

Capitolul 5

Din lista tabelelor, cu un dublu-click, acestea ajung în fereastra Relationships, după care se face legătura între câmpuri prin operaţia drag and drop, de la câmpul de legătură din tabelul sursă, la câmpul de legătură din tabelul destinaţie. După ce s-a făcut legătura apare fereastra Edit Relationships, care stabileşte şi integritatea datelor prin bifarea proprietăţilor arătate acolo, referitoare la actualizarea şi ştergerea câmpurilor legate, figura 5.32.

Fig. 5.32. Fereastra Edit Relationships

Stabilirea tipului de legătură se face prin fereastra Join Properties, care se deschide cu butonul Join Type (figura 5.33).

Fig. 5.33. Fereastra Join Properties

Cele 3 tipuri de opţiuni au următoarele semnificaţii: 1: - extrage numai înregistrările din tabelul sursă care au înregistrări echivalente în tabelul destinaţie. 2:

- se mai numeşte legătură la stânga.

3:

- se mai numeşte legătură la dreapta.

b) Legătura prin Lookup Wizard se face în faza de creare a tabelului, când la alegerea tipului de dată se alege opţiunea din figura 5.34. 201

Baze de date

Capitolul 5

Fig. 5.34. Alegerea câmpului Lookup Wizard

În continuare „vrăjitorul” ne conduce pentru a realiza legătura propusă, procedura este foarte clară, aşa că nu mai e cazul să fie prezentată aici. Încercaţi-o şi nu veţi avea probleme. Observaţie importantă!! Chiar dacă legăturile permanente dintre tabele în Access creează unele facilităţi, evitaţi să le creaţi deoarece ar putea să vă creeze unele neplăceri la crearea interogărilor din mai multe tabele, mai ales când sunteţi începători. Dacă baza de date este corect proiectată, iar legăturile dintre tabele se văd în documentaţia acesteia, cel mai înţelept lucru este să folosiţi legăturile temporare, valabile numai pentru interogarea respectivă.

202

Baze de date

Capitolul 5

Interogări cu parametri Dacă într-o interogare este necesar să se schimbe foarte des criteriile de selecţie, este recomandabil ca aceasta să fie transformată într-o interogare cu parametri. Astfel, la apariţia oricărei schimbări, cererea trebuie reproiectată, modificând criteriile, ceea ce este total ineficient. Avantajul unei interogări cu parametri, constă în faptul că aceste criterii care se modifică primesc valori în momentul execuţiei cererii. Astfel, dacă într-un tabel cu facturi avem datele calendaristice la care au fost emise şi furnizorii acestora, este foarte probabil că vom dori obţinerea unor situaţii ca acestea: - facturile primite într-o lună oarecare sau un interval de timp; - facturile primite de la un anumit furnizor; - facturile primite de la un furnizor într-un interval de timp. Astfel de interogări nu sunt greu de făcut, inconvenientul este că pentru orice situaţie scoasă trebuie să punem alte criterii, care de altfel, diferă foarte puţin între ele, adică numele furnizorului sau a intervalului de timp. Mai mult, cel care face interogarea trebuie să stăpânească procedura de construcţie a acesteia, ceea ce ar fi prea mult pentru un utilizator obişnuit. Dacă ar trebui să introducă numai nişte parametri pentru ca interogarea să funcţioneze, ar fi altceva. În continuare vom încerca să construim câteva interogări cu parametri care să poată fi folosite ca modele pentru aplicaţiile pe care le veţi face singuri. Să reluăm baza de date cu diagrama din figura 5.35. tblFacturi FacturaID ChP NrFactura Data FurnizorID ChE

tblDetaliiFacturi FacturaID ChE ProdusID ChE Cantitate Observatii

tblProduse ProdusID ChP Denumire UM Pret ..............

tblFurnizori FurnizorID ChP Furnizor CodFiscal ...........

Fig. 5.35. Diagrama bazei de date

203

Baze de date

Capitolul 5

Ne propunem mai întâi să construim o interogare care să găsească toate facturile primite de la un furnizor, al cărui nume să-l dăm în momentul interogării. Pentru aceasta executăm paşii următori: 1. Deschideţi o nouă interogare în modul Design View. Introduceţi tabelele tblFacturi şi tblFurnizori. Trageţi câmpurile aşa cum se vede în figura 5.36.

Fig. 5.36. Grila de proiectare

2. În rândul Criterii de la câmpul Furnizor introduceţi între paranteze drepte: [Introduceti furnizorul:]

3. Vizualizaţi interogarea cu butonul figura 5.37.

, care va deschide caseta din

Fig. 5.37. Introducerea parametrului interogării

Introducând un furnizor existent, se va afişa un tabel cu toate facturile emise de acesta. Dacă dorim, putem vedea ce expresie SQL a generat Access-ul:

204

Baze de date

Capitolul 5

SELECT tblFurnizori.Furnizor, tblFacturi.NrFactura, tblFacturi.Data FROM tblFacturi INNER tblFurnizori.FurnizorID

JOIN

tblFurnizori

ON

tblFacturi.FurnizorID

=

WHERE (((tblFurnizori.Furnizor)=[Introduceti furnizorul:]));

Reluăm procedura şi vom încerca să afişăm facturile primite într-un interval de timp. Grila de proiectare trebuie să arate ca în figura 5.38.

Fig. 5.38. Grila de proiectare pentru un interval de timp.

Cele 2 cereri de parametri sunt arătate în figura 5.39.

Fig. 5.39. Introducerea celor 2 parametri

Pornind de la aceste exemple, încercaţi să construiţi şi alte interogări cu parametri pentru a acumula experienţă.

205

Baze de date

Capitolul 5

Rapoarte Rapoartele nu sunt altceva decât nişte formulare cu informaţii extrase din baza de date, care se tipăresc pe hârtie şi sunt folosite ca documente care se pot pune în dosare sau se arhivează. Tehnica de lucru este asemănătoare cu cea de la formulare. Ca şi formularele, rapoartele au o sursă de date care poate fi un tabel sau o interogare. Crearea rapoartelor este cea mai spectaculoasă acţiune dintr-o aplicaţie de baze de date. Acest lucru se datorează faptului că rapoartele conţin tocmai informaţiile care au stat la baza obiectivelor bazei de date. Aceste rapoarte ajung în mâna unor persoane care au mai puţină legătură cu bazele de date, dar sunt foarte exigente în legătură cu exactitatea acestor informaţii. Aceste persoane pot fi manageri de top care ar putea fi singurele care înţeleg semnificaţia unor informaţii. Forma de prezentare a acestora în cadrul raportului este foarte importantă. Crearea unui raport simplu Cu siguranţă, primul raport pe care o să-l faceţi va fi unul fără pretenţii, făcut cu ajutor din partea programului Access. Modalitatea cea mai simplă de preluare a informaţiilor dintr-un tabel şi aducerea acestora într-un format corespunzător pentru tipărire este folosirea procedurii AutoReport. Aceasta permite crearea unui raport în format tabelar sau de tip coloană. Un raport în format tabelar, cel mai uzual de altfel, este asemănător unei foi de date Excel. Dezavantajul procedurii AutoReport este că raportul se bazează pe un singur tabel sau interogare. De asemenea, forma de prezentarea este una rigidă, impusă. Cel mai indicat lucru pentru a înţelege cum se creează rapoartele este să luăm un exemplu practic. Pentru aceasta, luăm ca exemplu baza de date pe care am folosit-o la crearea formularelor. Această bază de date are structura prezentată în figura 5.40.

206

Baze de date tblFacturi FacturaID ChP NrFactura Data FurnizorID ChE

Capitolul 5 tblDetaliiFacturi FacturaID ChE ProdusID ChE Cantitate Observatii

tblFurnizori FurnizorID ChP Furnizor CodFiscal ...........

tblProduse ProdusID ChP Denumire UM Pret ..............

Fig. 5.40. Diagrama bazei de date

Baza de date conţine 4 tabele pentru urmărirea facturilor cu detaliile lor, primite de o firmă de la diverşi furnizori. Tabelele conţin produsele, facturile şi furnizorii aferenţi. Ne propunem să creăm diferite rapoarte cu informaţii din această bază de date. Vom crea un raport simplu care să ne afişeze toate produsele din tabelul tblProduse, folosind procedura AutoReport. Pentru aceasta vom parcurge următorii paşi: 1. Deschidem baza de date din figura 5.40 care are completate tabelele cu date. 2. Executăm clic pe obiectul Reports, situat în stânga ferestrei Database. 3.Executăm clic pe butonul New din bara de instrumente, situată în partea de sus a ferestrei Database. Ca urmare va apare caseta de dialog din figura 5.41.

Fig. 5.41. Alegem tabelul tblProduse şi opţiunea Tabular

207

Baze de date

Capitolul 5

4. Selectăm opţiunea AutoReport: Tabular. 5. Din lista derulantă din partea de jos, alegem tabelul tblProduse care va fi sursa pentru raportul nostru. 6. Executăm clic pe butonul OK. În urma acestei manevre va apare raportul în Print Preview, aşa cum se vede în figura 5.42.

Fig. 5.42. Partea de sus a raportului creat

După cum se vede, acest raport ar mai trebui aranjat puţin, în special la alinierea coloanelor, dar pentru că l-am obţinut atât de uşor, îl putem accepta şi aşa. Crearea unui raport cu Report Wizard Report Wizard este o aplicaţie inclusă în programul Access, cu ajutorul căreia se pot face rapoarte cu adevărat performante, fără prea mare efort. Această aplicaţie oferă un bun compromis între uşurinţa în utilizare şi nivelul de control pe care îl avem asupra raportului în cursul elaborării lui. Pentru a înţelege cum se elaborează un raport cu această metodă, vom lua un exemplu concret. Având baza de date din paragraful anterior, adică evidenţa facturilor cu detaliile lor şi pe furnizor, ne propunem să scoatem un raport cu toate facturile şi detaliile lor pentru fiecare furnizor. Este evident că vom avea nevoie de subtotaluri pe facturi, respectiv pe furnizori.

208

Baze de date

Capitolul 5

Se ştie că în spatele fiecărui raport se află, fie un tabel, fie o interogare. Prin urmare, primul pas care trebuie să îl facem este identificarea acelui tabel sau crearea interogării. La primul exemplu de raport am folosit un tabel, la următorul exemplu vom folosi o interogare. Ne propunem să elaborăm un raport care să aibă următoarele câmpuri: Denumire, UM, Cantitate, Pret, Valoare, pentru fiecare produs primit şi să avem subtotaluri pe facturi şi pe furnizori. Ne vom folosi acum de cunoştinţele de SQL pentru a scrie o expresie care să execute interogarea propusă. Iată cum arată această expresie: SELECT Furnizor, f.NrFactura, pr.Denumire, pr.UM, df.Cantitate, pr.Pret, Cantitate*Pret AS Valoare FROM tblFacturi AS f, tblFurnizori, tblDetaliiFacturi AS df INNER JOIN tblProduse AS pr ON df.ProdusID = pr.ProdusID WHERE df.FacturaID=f.FacturaID AND f.FurnizorID=tblFurnizori.FurnizorID;

Observaţi că pe lângă câmpurile specificate s-au mai introdus câmpurile Furnizor şi NrFactura care vor servi în raport pentru calcularea de subtotaluri. Rezultatul acestei interogări se poate vedea în figura 5.43.

Fig. 5.43. Interogarea folosită în raportul care va fi creat

Analizând această interogare, mare lucru nu înţelegem, nu putem trage nici o concluzie despre facturi, furnizori etc. Sunt cam amestecate, dar sunt reale şi corecte. Ceea ce va trebui să facem este să aranjăm aceste date întrun raport tipărit care să fie inteligibil şi apoi să-l prezentăm şefului, nu-i aşa?

209

Baze de date

Capitolul 5

Pentru a crea raportul propus vom parcurge etapele următoare: 1. Deschidem baza de date, care conţine interogarea de mai sus. 2. Executăm clic pe pictograma Reports. 3. În fereastra care s-a deschis, execută, dublu-clic pe opţiunea Create Report by Using Wizard, pentru a lansa aplicaţia Report Wizard, după cum se vede în figura 5.44.

Fig. 5.44. Primul ecran al aplicaţiei Report Wizard permite selectarea câmpurilor raportului

4. Din comboBox-ul Tables/Queries se alege interogarea pregătită mai devreme, în cazul nostru qryDetaliiFacturi cu furnizori. 5. Din lista Available Fields se aleg câmpurile raportului, în cazul nostru toate, prin apăsarea butonului (>>). După ce am transferat toate câmpurile în partea dreaptă, se apasă butonul Next pentru a trece la ecranul următor. 6. În acest ecran putem să grupăm înregistrările după câmpul furnizor, iar în cadrul furnizorului după numărul facturii. Pentru aceasta trecem primele 2 câmpuri în partea dreaptă cu butonul (>). Rezultatul acţiunii se vede în figura 5.45.

Fig. 5.45. Fereastra în care configurăm nivelul de grupare

210

Baze de date

Capitolul 5

Se observă că prima grupare se face după câmpul NrFactura, iar a doua după câmpul Furnizor. Se trece la ecranul următor apăsând butonul Next. 7. În ecranul următor, putem sorta înregistrările din detalii după un anumit câmp. Noi am ales sortarea ascendentă după câmpul Denumire, după cum se vede în figura 5.46.

Fig. 5.46. Ecran pentru modul de sortare

Din acest ecran, prin apăsarea butonului Sumary Options se deschide un nou ecran în care putem indica câmpurile pe care se fac totalurile parţiale. Acest ecran este arătat în figura 5.47.

Fig. 5.47. Stabilirea coloanelor pentru sume.

Observaţi că au fost afişate numai coloanele cu valori numerice, iar pe lângă sumă se pot calcula media aritmetică, minimul şi maximul de pe coloane. Dacă nu vrem să apară în raport toate detaliile, activăm opţiunea Summary Only. Cu butonul OK se ajunge la ecranul precedent. Se apasă butonul Next. 211

Baze de date

Capitolul 5

8. În acest ecran aplicaţia ne cere să alegem un model de aranjare a datelor în raport, figura 5.48.

Fig. 5.48. Aranjarea datelor în pagină

Alegem prima opţiune Steped, care este mai potrivită pentru raportul nostru. Tot în acest ecran putem alege forma paginii, Portrait sau Landscape. Se apasă butonul Next. 9. În ecranul următor aplicaţia ne cere să alegem o formă de prezentare a raportului, figura 5.49. Alegem opţiunea Formal.

Fig. 5.49. Alegerea modului de prezentare a raportului

Se apasă butonul Next pentru a trece la ecranul următor. 10. În fine, am ajuns la ultimul pas al elaborării raportului, în care ni se cere să îi dăm un nume, figura 5.50.

212

Baze de date

Capitolul 5

Fig. 5.50. Alegerea numelui şi terminarea raportului.

Când apăsăm butonul Finish va apare pe ecran previzualizarea raportului. S-ar putea ca aranjamentele coloanelor, a subtotalurilor să nu fie cea mai potrivită. De aceea trebuie să intram în modul Design apăsând butonul , în urma căruia va apare imaginea din figura 5.51.

Fig. 5.51. Raportul afişat în modul Design.

În acest mod de afişare a raportului, putem să mişcăm cu mouse-ul obiectele, să le schimbăm proprietăţile, aşa cum făceam la crearea intefeţelor în Visual Basic. După terminarea acestei operaţiuni raportul nostru ar trebui să apară ca în figura 5.52.

213

Baze de date

Capitolul 5

Fig. 5.52. Forma finală a raportului

Din analiza acestui raport, se poate afla ce facturi are fiecare furnizor, ce conţine fiecare factură, se văd totalurile facturilor şi totalul general pe fiecare furnizor. Este un document util pentru managerii firmei respective. Particularizarea unui raport Am prezentat până acum două metode de obţinere a rapoartelor: AutoReport şi Report Wizard. Aceste metode ne ajută să elaborăm rapoarte tipizate, prefabricate, adică ni se propun variante iar noi alegem pe cea mai convenabilă. Deşi se fac relativ repede, aceste rapoarte nu ne satisfac întrutotul, de aceea este nevoie să intervenim pentru îmbunătăţirea lor, cu unelte puse la dispoziţie de programul Access.

214

Baze de date

Capitolul 5

În principiu, pentru elaborarea rapoartelor performante, se pleacă cu una din cele 2 metode amintite AutoReport sau Report Wizard, după care se procedează la editarea acestora pentru a le aduce la forma finală. Prin editare se pot adăuga sau şterge anumite elemente, conform cerinţelor practice. Pentru a edita un raport se procedează într-o manieră asemănătoare cu editarea unui formular, de aceea este indicat să revedeţi paragraful Crearea manuală u uni formular. Ca şi un formular, raportul are 3 părţi: Header, Footer şi Detail. Acestea sunt puse în evidenţă în afişarea în modul Report Design a raportului. Pentru a ajunge în această stare executaţi, în ordine clic pe butoanele Reports şi Design, a cărui rezultat se vede în figura 5.53.

Fig. 5.53. Afişarea în modul Design a formularului

După ce se intră în modul Design, trebuie activate casetele Toolbox şi Properties cu butoanele arătate prin săgeţi în figura 5.53. Cu ajutorul mouse-ului puteţi acum să selectaţi obiectele de pe formular şi să le schimbaţi proprietăţile. De cele mai multe ori veţi schimba poziţiile casetelor de text şi a etichetelor, mărimea şi tipul de font etc. După se aţi făcut unele schimbări, urmăriţi-le activând raportul cu butonul View ( din partea stângă a Toolbar-ului. 215

)

Baze de date

Capitolul 5

Este evident faptul că obţinerea unor rapoarte aspectuoase şi performante este legată direct de experienţa pe care o veţi dobândi. Această experienţă nu e greu de obţinut, trebuie numai să faceţi cât mai multe rapoarte şi să aveţi răbdarea de a le perfecţiona cât mai mult. Este o muncă migăloasă dar merită, deoarece formularele sunt cele care se văd din întreaga aplicaţie, şi pe care le înţelege toată lumea şi de aici pericolul de a fi mereu criticate.

216

Baze de date

Capitolul 5

Macrouri Din cele studiate până acum, am văzut că o bază de date Access este o colecţie de obiecte, tabele, interogări, formulare, rapoarte etc. Noi am învăţat să construim aceste obiecte. Toate obiectele unei baze de date trebuie legate într-un flux continuu de operaţii, care împreună se constituie într-o aplicaţie de baze de date. Exploatarea unei aplicaţii de baze de date presupune o mulţime de operaţii manuale care sunt executate de orice operator implicat. În cadrul unei aplicaţii Access, de o mare importanţă este automatizarea acesteia. Prin automatizare înţelegem că pe baza unei acţiuni a utilizatorului, cum ar fi apăsarea unui buton al interfeţei, un dublu-clic etc, se determină realizarea uneia sau mai multor operaţii (activarea unuia sau mai multor obiecte, rularea unor interogări etc.). Această automatizare a aplicaţiilor realizate în Access se poate face în două moduri:  Prin utilizarea limbajului Visual Basic for Applications (VBA);  Prin utilizarea macrocomenzilor, care reprezintă o formă simplificată a limbajului VBA. Comenzile macro sunt deosebite prin caracteristica lor unică şi anume că permit automatizarea diverselor evenimente fără ca realizatorul aplicaţiei să fie nevoit să cunoască un anumit limbaj de programare. Prin evenimente putem înţelege:  Modificări ale datelor;  Deschiderea sau închiderea unui formular sau raport;  Acţiunea asupra unor obiecte de control din formulare. În Microsoft Access există un mare număr de tipuri de acţiuni care pot fi executate în cadrul unor comenzi macro. Totul depinde de noi, să le cunoaştem şi să le aplicăm corect, în cunoştinţă de cauză. Iată câteva din aceste acţiuni:

217

Baze de date

Capitolul 5

 Deschiderea sau închiderea unor tabele, interogări, formulare sau rapoarte;  Vizualizarea sau tipărirea rapoartelor;  Rularea cererilor de interogare de acţiune;  Apelarea altor comenzi macro;  Efectuarea condiţionată a anumitor acţiuni;  Căutarea anumitor date în tabele;  Deschiderea sau închiderea unor meniuri din Access;  Afişarea anumitor mesaje;  Ştergerea, redenumirea, copierea sau salvarea diferitelor obiecte ale aplicaţiei;  Comunicarea cu alte produse soft, cum ar fi Word şi Excel. Cea mai bună metodă de a începe să proiectăm macrocomenzi este să ne gândim la un proces pe care îl parcurgem în mod repetat, ceva care facem de mai multe ori pe zi sau săptămânal. De exemplu, dacă în fiecare zi avem de dat conducerii un raport cu vânzările zilei sau avem frecvent de făcut unele modificări cu ajutorul unor interogări de acţiune. Presupunem că am găsit un astfel de scenariu, deci putem trece la automatizarea lui. Crearea macrocomenzilor cu o singură acţiune Crearea macrocomenzilor se face cu ajutorul ferestrei Macro Design prezentată în figura 5.54. Coloana Macro Name

Coloana Condition

Coloana Action

Coloana Comment

Zonă în care vor fi afişate argumentele acţiunii curente.

Fig. 5.54. Fereastra Macro Design

218

Baze de date

Capitolul 5

Rolul fiecărei coloane, îl puteţi deduce după numele ei. Pentru început, cele mai importante sunt coloanele Action şi Comment, adică cele în care veţi defini şi comenta acţiunile. De altfel, numai aceste două coloane vor fi afişate la început. Pentru afişarea celorlalte va trebui să apăsaţi butoanele ( ) şi (

) din toolbar-ul situat în partea de sus a ecranului.

Observaţi că acţiunile pe care doriţi să le executaţi trebuie alese din coloana Action dintr-un comboBox, în care sunt peste 50 de acţiuni care acoperă necesarul pentru macro-urile obişnuite. Este un obicei bun de a comenta fiecare acţiune pentru o bună informare, mai ales pentru intervenţiile ulterioare în modificările aduse aplicaţiei. În partea de jos-stânga, vor fi afişate cererile de argumente pentru acţiunea selectată. O macrocomandă poate fi alcătuită dintr-o singură acţiune, sau din mai multe. Ca să adăugaţi în macrocomandă o acţiune, mutaţi cursorul în coloana Action şi deschideţi lista derulantă, de unde alegeţi una din cele peste 50 de acţiuni, dintre care multe au subacţiuni suplimentare. Un exemplu simplu vă va ajuta să creaţi şi să executaţi o primă macrocomandă. Ne propunem să afişăm un formular care există în baza noastră de date. Macrocomanda rezultată se vede în figura 5.55.

Fig. 5.55. Macromandă cu o singură acţiune

Macrocomenzile se salvează ca şi formularele şi se lansează cu un dubluclic sau cu butonul Run din fereastra Database. În figura 5.56 se pot vedea 2 macrocomenzi, una care deschide un formular şi alta care produce un semnal sonor. 219

Baze de date

Capitolul 5

Fig. 5.56. Frereastra Database cu 2 macro-uri

Crearea unei macrocomenzi cu mai multe acţiuni De multe ori în practică, este necesar de mai multe acţiuni grupate sub aceeaşi macrocomandă. Pentru a defini acţiuni multiple, care să se execute una după alta, trebuie doar să le adăugaţi pe următoarele linii ale ferestrei Macro Design. Un exemplu de folosire a mai multor acţiuni poate fi acela în care ar trebui rulată o expresie SQL, apoi deschiderea unui formular. Desigur, folosirea eficientă a macrocomenzilor din Access, nu este chiar la îndemâna începătorilor. Folosirea lor curentă va veni în mod natural, pe măsură ce practica o cere, iar experienţa o permite. O facilitate importantă a acţiunilor multiple este folosirea condiţiilor în macrocomenzi. Utilizând coloana Condition puteţi adăuga unele decizii, cum ar fi, de exemplu, afişarea unor mesaje în funcţie de o anumită condiţie. Expresiile introduse drept condiţii trebuie evaluate la valorile True sau False. În cazul când condiţia este evaluată la True, se execută acţiunea corespunzătoare; dacă este False, acţiunea nu se mai execută. O altă facilitate oferită de fereastra Macro Design este posibilitatea de a grupa macrocomenzile. Coloana Macro Name vă permite să vă gestionaţi mai uşor macrocomenzile, mai ales când numărul lor creşte foarte mult. Dacă specificaţi un nume în această coloană, pe prima linie, macrocomanda dumneavoastră va fi considerată a fi un grup de macromenzi. Într-un astfel de grup puteţi stoca sub un singur nume mai 220

Baze de date

Capitolul 5

multe macrocomenzi înrudite, care vor primi un nume sugestiv, ales de dumneavoastră. În acest fel organizarea macrocomenzilor va fi mult mai practică. Când se rulează macrocomanda, se va rula doar primul grup. Întrebarea, firească, pe care v-o puneţi este cum puteţi rula şi celelalte grupuri? Răspunsul este simplu: nu puteţi. Dacă aveţi într-o macrocomandă mai multe grupuri, pentru a rula şi alte grupuri decât primul va trebui să folosiţi o acţiune RunMacro. În acest caz veţi putea alege numele macrocomenzii care se va rula, vezi figura 5.57.

Fig. 5.57. Grupuri de acţiuni

Observaţi că la acţiunea RunMacro a fost ales numele grupului Raportari care face parte din macrocomanda Macro1. Cu ajutorul grupurilor de macrocomenzi puteţi ţine toate acţiunile legate de un formular sau raport într-o singură macrocomandă. După cum spuneam, există în Access peste 50 de acţiuni care au fiecare propriile argumente. Dacă doriţi să obţineţi o listă completă a acestor acţiuni, precum şi descrieri succinte ale lor şi a argumentelor pe care le folosesc, deschideţi o macrocomandă nouă şi selectaţi acţiunea care vă interesează. Toate informaţiile importante vor fi afişate pe ecran. Dacă doriţi mai multe exemple, le puteţi găsi în sistemul Help din Access. Rularea macrocomenzilor În acest paragraf vom studia diferitele moduri de accesare a macrocomenzilor pe care le creaţi în diferite aplicaţii Access, precum şi unele macrocomenzi speciale, native, ale sistemului Access, cum ar fi AutoExec şi AutoKeys. 221

Baze de date

Capitolul 5

Rularea unei macrocomenzi din fereastra Database

Paşii pe care trebuie să-i parcurgeţi sunt următorii: 1. În fereastra Database, selectaţi obiectul Macros (dacă nu e selectat); 2. Selectaţi macrocomanda pe care doriţi să o rulaţi; 3. Executaţi clic pe butonul Run pentru a executa macrocomanda. Deşi puteţi rula în acest mod toate macrocomenzile pe care le-aţi creat, vă reamintesc că în cazul macrocomentilor care conţin grupuri, în acest mod se execută numai primul grup de acţiuni, celelalte fiind ignorate. Pentru a executa un anumit grup dintr-o macrocomandă, folosiţi meniul. În cazul în care vreţi să rulaţi manual o anumită macrocomandă dintr-un grup folosiţi metoda descrisă în continuare. Rularea unei macrocomenzi dintr-un grup

1. Selectaţi din meniul principal opţiunea: deschide caseta de dialog din figura 5.58.

Tools – Macro – Run Macro.

Se va

Fig. 5.58. Caseta Run Macro

2. Selectaţi din lista derulantă macromanda pe care doriţi să o executaţi. 3. Executaţi clic pe butonul OK pentru a executa macrocomanda. Observaţi cum caseta de dialog Run Macro prezintă toate macrocomenzile disponibile în baza de date, grupurile fiind reprezentate sub forma macroname.macrogrup, unde macroname este numele din fereastra Database, iar macrogrup numele unui grup din cadrul macrocomenzii respective. Utilizarea acţiunii RunMacro

O altă metodă de execuţie a macrocomenzilor, este rularea lor dintr-o altă macrocomandă cu ajutorul acţiunii RunMacro. În figura 5.57 se poate vedea cum se foloseşte această metodă. La sfârşitul unui grup de acţiuni se 222

Baze de date

Capitolul 5

introduce acţiunea RunMacro care va lansa în execuţie macrocomanda nominalizată de argumentul Macro Name. Macrocomenzi ataşate evenimentelor

Probabil că metoda cea mai utilizată pentru rularea macrocomenzilor din aplicaţiile Access, nu este rularea directă, ci ca răspuns la un eveniment Access. Aceste evenimente pot fi declanşate de tot felul de lucruri care se pot întâmpla la nivel de formular, raport sau chiar de control individual din cadrul acestora – de exemplu, deschiderea unui formular declanşează evenimentul OnOpen al formularului respectiv, la introducerea unei valori într-o casetă de text declanşează evenimentul OnClick, iar dacă utilizatorul actualizează datele dintr-un control al unui formular se declanşează evenimentul AfterUpdate ataşat controlului respectiv. Pentru a identifica evenimente ale diferitelor obiecte, nu aveţi decât să selectaţi obiectul respectiv şi să-i studiaţi evenimentele, activând opţiunea Event din fereastra Properties. Este de la sine înţeles că vă sunteţi pe un formular aflat în modul Design. În aplicaţia dumneavoastră vă puteţi folosi de aceste evenimente spunândui programului ruleze la apariţia unui anumit eveniment ataşat unui formular, raport sau control o anume macrocomandă. Utilizând evenimentele în acest mod vă puteţi perfecţiona aplicaţia, astfel încât ea să ofere ceva în plus faţă de funcţiile oferite de Access – permiţând, de exemplu, utilizatorilor să se deplaseze între diferite obiecte ale aplicaţiei fără să ştie măcar de existenţa ferestrei Database. Utilizarea macrocomenzilor AutoExec şi AutoKeys

Aceste macrocomenzi au nume speciale, rezervate şi sunt mocrocomenzi native ale programului Access. Macrocomanda AutoExec. Atunci când deschideţi baza de date, Access verifică dacă în cadrul acesteia nu există o macrocomandă cu numele AutoExec. Dacă există o astfel de macrocomandă, ea este executată automat. Această macrocomandă poate fi folosită pentru pregătirea aplicaţiei; de regulă ea este folosită împreună cu opţiunile de pornire a Access-ului.

223

Baze de date

Capitolul 5

Observaţie importantă!! Dacă doriţi să evitaţi rularea macrocomenzii AutoExec, menţineţi apăsată tasta Shift în timp ce deschideţi baza de date. În general, se foloseşte comanda AutoExec pentru a apela o funcţie VBA (prin intermediul acţiunii RunCode) personalizată pentru fiecare aplicaţie în parte. Macrocomanda AutoKeys. Acestei macrocomenzi, Access-ul îi acordă un tratament special. Cu ajutorul acestei macrocomenzi puteţi să asociaţi oricărei acţiuni, o combinaţie de taste dintre cele disponibile. Mai mult puteţi chiar să modificaţi comportamentul prestabilit al anumitor combinaţii de taste. Iată un exemplu de utilizare prezentat în figura 5.59.

Fig. 5.59. Exemplu de atribuire a unei combinaţii de taste unei macrocomenzi

În exemplul nostru, combinaţia de taste SHIFT + p lansează macrocomanda care afişează o listă cu produse. Reţineţi că macrocomanda se numeşte AutoKeys, iar combinaţia de taste a fost trecută în coloana Macro Name. Metodă rapidă de pornire a aplicaţiilor

Ca o alternativă a macrocomenzii AutoExec, trebuie amintit aici că începând cu versiunea Access 95, a fost introdusă o posibilitate de setare a opţiunilor de pornire a aplicaţiilor. 224

Baze de date

Capitolul 5

Având deschisă aplicaţia ale cărei opţiuni de pornire vrem să le automatizăm, dăm comanda Tools – Startup, care va deschide caseta de dialog din figura 5.60.

Fig. 5.60. Caseta de dialog Startup

Setările din această casetă de dialog sunt destul de evidente. Practic, putem să înlocuim toată ”faţada” programului Access. Reţineţi că această manevră este ultima, după ce aplicaţia a fost testată şi nu mai avem nimic de modificat la ea. Nu încercaţi să ascundeţi meniul principal şi toolbar-urile, înainte de forma finală, pentru că aţi putea ajunge să nu mai puteţi interacţiona cu aplicaţia deoarece nu mai aveţi instrumente de acces. Pentru astfel de încercări, faceţi-vă o copie de rezervă.

Publicarea datelor pe Internet Toată lumea ştie ce înseamnă azi Internetul, dar mai ales ce va însemna mâine, mai ales după integrarea României în Uniunea Europeană. Internetul a ajuns să fie cea mai avansată formă de comunicare a zilelor noastre. Prin conectarea la Internet întreprinderile îşi creează un avantaj concurenţial, demn de luat în seamă. Având în vedere că o serie de rapoarte de sinteză ale unei firme interesează clienţii, cum să fie informaţi aceştia dacă nu prin Internet. Rapoartele obţinându-se, în principal, dintr-o aplicaţie de bază de date, iată legătura dintre Access şi Internet. 225

Baze de date

Capitolul 5

Tot ce avem de făcut este să transformăm un raport sau un formular în document HTML, care poate fi postat pe un site de Internet. Din fericire, programul Access, începând cu versiunea 2000, oferă facilităţi de a scoate rapoarte direct în format HTML. Prin urmare, pe lângă formulare şi rapoarte, vom învăţa să scoatem din Access şi documente care pot fi publicate pe Internet. În principiu, paginile cu documente HTML se pun pe un server Web, de unde pot fi accesate prin intermediul unui soft numit browser. Deci noi trebuie doar să creăm fişiere HTML şi să le punem pe serverul Web, de unde pot fi vizualizate de oricine. În cele ce urmează vom încerca să creăm câteva pagini HTML direct din programul Access. Există 2 tipuri de documente pe Internet:  Pagini Web statice;  Pagini Web dinamice. Le vom studia pe rând, în paragrafele următoare.

Pagini Web statice Pagina Web statică este un document de tip prospect, adică are tot timpul acelaşi conţinut, cum a avut la crearea sa. Acest tip de documente se pot crea cel mai simplu dintr-un obiect al bazei de date, folosind metoda Export. Această metodă creează o pagină Web bazată pe un singur tabel sau interogare din baza de date curentă. Iată paşii care trebuie parcurşi pentru a crea un document static: 1. În fereastra Database, selectaţi obiectul pe care pe care doriţi să-l salvaţi în format HTML. 2. Selectaţi opţiunea File – Export. 3. În caseta de dialog Save, selectaţi lista derulantă HTML Documents (*.html; *.htm). Vezi figura 5.61.

226

Save as Type,

opţiunea

Baze de date

Capitolul 5

Bifaţi această opţiune pentru a exporta şi capul de tabel

Fig. 5.61. Crearea unei pagini HTML statice

4. Apăsaţi butonul Export lăsând implicite celelalte opţiuni cerute (Default endcoding). Veţi obţine o pagină HTML, aşa cum se vede în figura 5.62.

Fig.5.62. Pagina HTML obţinută, afişată cu Internet Explorer

Această pagină afişează în format HTML rezultatul unei interogări. Tot aşa puteţi afişa conţinutul unui tabel. Reţineţi că dacă se schimbă ceva în tabelele de bază ale interogării, această modificare nu se reflectă în pagina HTML. Când folosiţi această tehnică trebuie să aveţi în vedere acest lucru. Paginile Web statice, chiar dacă provin din exportul de obiecte din Access, nu sunt obiecte Access, ele vor fi salvate ca pagini independente cu extensia *.html, într-un director pe care îl puteţi alege.

227

Baze de date

Capitolul 5

Pagini Web dinamice Pagina web dinamică este acel document care poate oferi mai multe informaţii, în funcţie de cererile lansate de utilizator. Un exemplu ar putea fi formularul creat într-o aplicaţie Access care ne permite să parcurgem înregistrările unui tabel. Orice modificare în tabelele de bază se va reflecta în pagina Web dinamică. Acest tip de documente o să ne preocupe în continuare. Versiunea 2000 a programului Access şi următoarele, permit realizarea de pagini Web dinamice. În fapt aceste pagini sunt formulare şi rapoarte care pot fi publicate pe Internet. Observaţi în lista obiectelor din fereastra Access, apariţia obiectului Pages, care grupează paginile Web ale bazei de de date curente. Există două moduri de creare a unei pagini Web dinamice din Access: prin utilizarea instrumentului Wizard şi constructia lui de la zero în cadrul ferestrei de proiectare. La fel ca la formulare, nu? Când suntem ajutaţi de instrumentul Wizard, avem două posibilităţi: AutoPage şi Page Wizard. Le vom folosi pe rând. Crearea unei pagini dinamice de date cu AutoPage

Cu AutoPage puteţi crea rapid o pagină Web dinamică, servind pentru introducerea şi afişarea de date pe Web. Iată paşii pe care trebuie să-i parcurgeţi: 1. Din fereastra Database selectaţi Pages – New. 2. În caseta de dialog New Data Access Page, selectaţi sursa de înregistrări (un tabel sau o interogare), selectaţi AutoPage:Columnar, apoi apăsaţi butonul OK. 3. AutoPage creează o pagină Data Access folosind toate câmpurile conţinute în sursa de înregistrări selectată, pagină pe care o afişează în modul Page. În figura 5.63 este afişată o astfel de pagină.

228

Baze de date

Capitolul 5

Fig. 5.63. Pagină Web dinamică obţinută cu AutoPage

Dacă nu sunteţi mulţumiţi de aspectul paginii, intraţi în modul Design şi schimbaţi ce doriţi, la fel cum aţi procedat la tabele şi rapoarte. După modificările aduse salvaţi pagina cu comanda File – Save As. Atenţie însă că numele şi salvarea sunt stabilite de către programul Access, asupra cărora nu aveţi nici un control. Acest lucru vă este anunţat după cum se vede în figura 5.64.

Fig. 5.64. Avertismentul legat de conectarea la pagină

Pentru a vă putea conecta la paginile create, folosind reţeaua trebuie să editaţi conexiunea intrând în codul HTML. Aceasta nu este o operaţiune chiar simplă, de aceea trebuie efectuată de administratorul bazei de date. Crearea paginilor dinamice cu Page Wizard

Utilizarea vrăjitorului (wizard) pentru crearea paginilor Data Access este similară cu folosirea AutoPage, cu observaţia că primul oferă mai multă flexibilitate. Utilizând Page Wizard puteţi folosi mai multe surse de date şi aveţi posibilitatea de a selecta câmpurile pe care doriţi să le afişaţi. Iată paşii pe care trebuie să-i parcurgeţi:

229

Baze de date

Capitolul 5

1. Din fereastra Database selectaţi Pages – New. 2. În caseta de dialog New Data Access Page, selectaţi Page wizard, apoi apăsaţi butonul OK. Puteţi selecta şi o sursă de date, dar nu este obligatoriu. 3. În caseta Page Wizard, selectaţi sursa de date, un tabel sau o interogare, şi câmpurile pe care doriţi să le afişaţi, apoi apăsaţi butonul OK. 4. În următoarea casetă de dialog puteţi selecta opţiunile de grupare. Dacă selectaţi o asemenea opţiune, pagina va deveni read-only. Când sunteţi gata, apoi apăsaţi butonul OK. 5. Următoarea casetă de dialog vă cere să specificaţi o ordine de sortare. 6. Ultima casetă de dialog vă permite să acordaţi paginii un nume, să selectaţi o temă (fundal) şi să deschideţi pagina în modul Design sau View. Dacă deschideţi pagina în modul de afişare View, Access o va salva în dosarul prestabilit; de aceea, dacă doriţi să specificaţi şi locaţia fişierului, recomandarea este să afişaţi mai întâi pagina în modul Design. Executaţi clic pe butonul Finish pentru a vă putea vizualiza pagina. 7. Când sunteţi mulţumit de aspectul paginii şi doriţi să o salvaţi, daţi comanda File – Save As, astfel încât să puteţi specifica şi locaţia fişierului. În figura 5.65 este prezentată o pagină Web dinamică, obţinută prin această metodă.

Fig. 5.65. Pagină Web dinamică obţinută cu Page Wizard

230

Baze de date

Capitolul 5

Pagina este afişată cu browserul Internet Explorer. Pentru a exersa puteţi încerca să puneţi în pagină Web şi alte informaţii din baza de date, pentru că nu e departe momentul când şeful o să vă ceară să puneţi un raport la care aţi trudit din greu, într-o locaţie de pe Internet, pentru că el e plecat la o specializare în SUA. Comunicarea între aplicaţiile pachetului Office

Pachetul Office al firmei Microsoft a fost conceput ca un instrument util şi foarte performant cu ajutorul căruia să se poată realiza un număr mare de sarcini în cadrul unui birou al unei firme sau chiar la domiciliu. Popularitatea produsului Office se datorează, pe lângă gradul sporit de complexitate, facilităţii sale deosebite de a permite diferitelor aplicaţii care îl compun, să comunice între ele. Astfel, informaţiile dintr-o aplicaţie Access pot fi transferate (exportate) în Excel, unde se pot face anumite calcule, după care acestea pot fi transferate (exportate) în Word în vederea realizării unui document de sinteză. Sistemul de operare Windows conţine o facilitate Object Linking and Embedding (Introducere şi legarea obiectului) sau pe scurt OLE. În fond OLE este o metodă de transfer a informaţiei între diferite aplicaţii Windows sub formă de obiecte. Metoda OLE oferă un mare avantaj aplicaţiilor realizate în Access, putând fi create baze de date de tip multimedia în care pot fi stocate fişiere audio(WAV), fotografii şi desene, animaţie şi chiar filme(AVI). Începând cu Access 2000, au fost introduse trei facilităţi noi:  Dynamic Data Exchange, DDE - schimbul dinamic de date;  ActiveX Objects – obiecte ActiveX;  ActiveX Custom Controls – controale personalizate ActiveX. Facilitatea DDE permite executarea unor funcţii precum transmiterea de date între Access şi orice altă aplicaţie Windows care suportă facilitatea DDE. Se pot crea conexiuni de tip DDE cu alte aplicaţii prin utilizarea comenzilor macro sau a limbajului VBA. 231

Baze de date

Capitolul 5

ActiveX este o facilitate avansată a sistemului de operare Windows care permite crearea unor anumite legături între obiecte precum şi includerea lor în cadrul bazelor de date Access. Prin obiecte înţelegem fotografii, desene, grafice, foi de calcul Excel şi documente. Access poate fi folosit ca un server ActiveX, permiţând deschiderea şi lucrul cu obiecte ale bazei de date Access (tabele, interogări şi formulare) din cadrul altor aplicaţii de tip Windows. Exportul şi importul de date Comunicarea programului Access cu celelalte componente ale pachetului Office, rămâne un element de bază. Spre exemplu dorim să realizăm un export de date dintr-un tabel Access către un document Word. Datele vor apare în Word într-un tabel. Un alt caz des utilizat este exportul din Access către Excel al unui tabel sau interogări. În ambele cazuri se foloseşte comanda File - Export. Încercaţi această comandă pentru cazuri concrete. De multe ori este nevoie ca anumite informaţii să fie prelucrate şi sintetizate în Excel, înainte de a fi cuprinse într-un raport. Importul este operaţia inversă care se execută cu comanda File – Get External Data – Import. Încercaţi şi funcţionarea acestei comenzi.

Recomandări privind aplicaţiile ACCESS Cu siguranţă, la primul proiect de aplicaţie Access, nu sunteţi un specialist al domeniului. Aveţi încă multe lucruri neclare, peste care aţi trecut mai uşor în timpul studiului. Fiţi liniştit pentru că toate acestea se vor clarifica în timpul aplicaţiilor pe care le veţi aborda în viitor. Practica este aceea care ar putea fi numită „evaluatorul perfect” al cunoştinţelor acumulate (si nu numai în cazul de faţă). Programul Access are câteva handicapuri de apreciere pe care, sincer, nu le merită:  Programatorii profesionişti îl evită pentru că ar fi dedicat începătorilor şi are anumite limite, pe care e greu să le 232

Baze de date

Capitolul 5

argumenteze. Ei folosesc baze de date cum ar fi Oracle, SQL Server, MySQL care sunt mult mai scumpe.  Ceilalţi dezvoltatori de aplicaţii, au probleme cu folosirea Access-ului din cauza lipsei de pregătire, deci sunt mai puţin dispuşi să se aventureze într-un domeniu necunoscut. Prin urmare, pentru unii este prea simplu iar pentru alţii prea complicat. Posibilităţile oferite de Access, mai ales ultimele versiuni, sunt de-a dreptul extraordinare, aşa încât utilizarea lui în firmele mici şi mijlocii pe scară largă ar fi benefică, mai ales că aplicaţiile ar putea fi abordate cu resurse proprii. Programul Access e folosit de milioane de utilizatori de pe tot mapamondul, sunt forumuri de discuţii pentru aceşti utilizatori, care se ajută între ei cu sfaturi şi experienţe proprii. Cu siguranţă, că mulţi dintre ei trăiesc de pe urma Access-ului, alţii îi folosesc din plin facilităţile. Dacă aţi reuşit să înţelegeţi programul Access şi aţi făcut câteva aplicaţii cu el, înseamnă că aţi înţeles bazele de date relaţionale şi puteţi trece şi la alte produse de baze de date, dacă împrejurările o cer. Înseamnă că aveţi o bază de plecare solidă. În multe firme e nevoie de o metodă simplă de gestionare a tuturor informaţiilor care există pe hârtie sau în aplicaţii stufoase: facturi, înregistrări, informaţii contabile, contacte cu clienţi şi furnizori etc. De asemenea, este nevoie de tipărirea unor rapoarte şi scrisori care nu ies niciodată cum aţi dori, în care aveţi informaţii care trebuie calculate sau completate de mână. De asemenea, apare necesitatea publicării pe Web a unor informaţii detaliate şi la zi despre afacerile firmei, pentru a fi studiate de către parteneri sau de către alte filiale ale firmei care pot fi oriunde în lume. Aceste oportunităţi pot fi exploatate folosind programul Access care este o componentă a pachetului Microsoft Office. Practica mi-a demonstrat că studenţii care au urmat acest curs au reuşit să acumuleze suficiente cunoştinţe despre bazele de date, care au fost apoi aplicate în elaborarea unor proiecte de diplomă valoroase sau la locurile de muncă de după absolvire. Wizard-urile care se găsesc din abundenţă în Access sunt nişte unelte extrem de utile în dezvoltarea aplicaţiilor. Un formular sau un raport este 233

Baze de date

Capitolul 5

început cu un wizard, apoi este completat sau modificat de către dezvoltator. Folosirea macrourilor şi a formularului de start vă ajută să concepeţi aplicaţii de baze de date care par a fi făcute de o echipă de profesionişti, pentru că prin eliminarea ferestrei Database nu se mai vede că suntem în Access (vezi pagina 208). Exemplele care sunt prezentate în carte sunt inspirate din realitate, au fost testate înainte de a ajunge aici, aşa că pot fi folosite fără nici o reţinere, ca modele pentru aplicaţiile pe care le veţi face.

234

Baze de date

Anexe

ANEXE Anexa A. Administratorul de baze de date Pentru a proiecta şi implementa o bază de date a unei firme sau instituţii este nevoie de o echipă de profesionişti formată din reprezentaţi ai beneficiarului şi ai furnizorului de soluţii informatice. După ce s-a implementat şi testat baza de date şi instruit personalul care o va folosi, echipa de dezvoltare se retrage din firmă şi începe, probabil, un nou proiect. Se pune problema, ce se întâmplă cu baza nostră de date după ce echipa de dezvoltare a plecat şi au rămas numai utilizatorii finali? Aceştia ştiu să-şi facă treaba pentru care au fost intruiţi, să opereze acolo unde au dreptul. Ce se întâmplă dacă într-o dimineaţă, când porneşte aplicaţia, un utilizator primeşte nişte mesaje ciudate pe care nu le înţelege, iar aplicaţia se blochează? Cui ne adresăm? Înainte era acolo echipa de dezvoltare, care rezolva orice problemă. În acest moment, intră în joc administratorul bazei de date. Este de neconceput ca o bază de date a unei firme sau instituţii, în jurul căreia se învârte întrega activitate, să funcţioneze fără un adminstrator. Un manager inteligent este conştient de acest lucru şi va rezolva problema chiar de la început. Cine poate fi aministrator de baze de date? O persoană care poate să rezolve toate problemele cerute de post. O astfel de persoană a participat, de regulă, din partea firmei la dezvoltarea proiectului şi a acumulat cunoştinţe care îl ajută să-şi ducă la indeplinire sarcinile. Echipa managerială trebuie să aibă înţelepciunea ca să numească în acest post o persoană pregătită, pentru că datele firmei nu trebuie să fie compromise. Prin persoană pregătită nu trebuie înţeles, o persoană cu diplomă (se ştie cât de uşor se obţin acestea), ci una care trece nişte teste de competenţă. Un administrator de baze de date are cunoştinţe, cel puţin la nivelul celor prezentate în această carte, de la noţiuni de proiectare a unei baze de date, cunoaşterea limbajului SQL, până la implementarea de aplicaţii în ACCESS. Această meserie, este una a viitorului, pentru că tot mai multe firme şi instituţii se informatizează şi au mult de suferit din cauză că au 235

Baze de date

Anexe

probleme, de genul „nu merge bine”, rezultatele rapoartelor nu sunt corecte etc., şi toate astea se întâmplă pentru că nu există acel administrator de bază de date sau de sistem informatic. Dacă firma nu-şi poate permite să ţină un administrator de baze de date cu normă întreagă, există şi soluţia angajării unor consultanţi externi, care să vină numai atunci când este nevoie de ei. Ar fi o soluţie temporară, până când un angajat al firmei poate să îndeplinească această funcţie. Sigur, decizia este luată de către conducerea firmei respective, în cunoştinţă de cauză. Care sunt sarcinile administratorului de bază de date? Administratorul bazei de date are sarcini precise, care ar putea fi enumerate astfel:  Răspunde de corectitudinea datelor introduse în baza de date;  Răspunde de securitatea bazei de date, prin drepturile acordate utilizatorilor;  Salvează copii de siguranţă ale bazei de date, periodic;  Dacă s-a produs o deteriorare a datelor, poate să intre direct în tabele şi să le repare manual sau folosind limbajul SQL;  Să acorde asistenţă utilizatorilor finali, pentru a elimina pe cât posibil erorile umane;  Să scoată rapoarte noi, care nu au fost prevăzute în proiect dar care sunt cerute de anumite împrejurări;  Să ţină legătura cu echipa de dezvoltare pentru a rezolva orice problemă care îi depăşeşte competenţele;  Să stabilească, când e cazul, reguli suplimentare pentru operatorii finali;  Să intercepteze şi să prevină orice evenimente care ar putea afecta buna funcţionare a bazei de date. Ca o concluzie a celor prezentate în această anexă, am putea spune că administratorul de baze de date şi dacă extrapolăm, administrator de sistem informatic, este o meserie a viitorului care va fi foarte căutată şi bine plătită. Va fi un post cheie în orice organizaţie, o poziţie de mare responsabilitate. Nu ar fi lipsit de interes să vă gândiţi la o carieră profesională în acest domeniu. 236

Baze de date

Anexe

Anexa B. Sintaxa instrucţiunilor SQL În această anexă vor fi prezentate pe scurt principalele instrucţiuni SQL. SELECT Este instrucţiunea SQL cea mai utilizată, prima cu care luaţi contact. Se foloseşte pentru regăsirea(interogarea) datelor din unul sau mau multe tabele sau vederi. Sintaxa este următoarea: SELECT NumeColoana1, NumeColoana2, ... FROM tblTabel1, tblTabel2, ... [WHERE ...] [GROUP BY ...] [HAVING ...] [ORDER BY ...];

UPDATE Instrucţiunea UPDATE actualizează una sau mai multe linii dintr-o coloană. Sintaxa este următoarea: UPDATE NumeTabel SET NumeColoana1=valoare, NumeColoana2=valoare, ... [WHERE ...];

INSERT Instrucţiunea INSERT adaugă o singură linie într-un tabel. Sintaxa este următoarea: INSERT INTO NumeTabel [Coloana1, Coloana2, …)] VALUES (Valoare1, Valoare2, ...);

INSERT SELECT Instrucţiunea INSERT SELECT inserează rezultatele unei interogări, întrun tabel. Sintaxa este următoarea: INSERT INTO NumeTabel [Coloana1, Coloana2, …)] SELECT Coloana1, Coloana2, … FROM Tabel1, Tabel2, … [WHERE ...];

237

Baze de date

Anexe

DELETE Instrucţiunea DELETE şterge una sau mai multe linii dintr-un tabel. Sintaxa este următoarea: DELETE FROM NumeTabel [WHERE ...];

DROP Instrucţiunea DROP şterge permanent obiecte din bazele de date (tabele, vederi, etc). Sintaxa, pentru ştergerea unui tabel, este următoarea: DROP NumeTabel;

CREATE TABLE Instrucţiunea CREATE TABLE este folosită pentru crearea de noi tabele într-o bază de date. Sintaxa este următoarea: CREATE TABLE NumeTabel ( Coloana1 Tip de dată [NULL / NOT NULL], Coloana2 Tip de dată [NULL / NOT NULL], ... );

ALTER TABLE Instrucţiunea ALTER TABLE este folosită pentru actualizarea schemei unui tabel (adăugare şi ştergere de coloane). Sintaxa este următoarea: - adăugarea unei coloane (exemplu): ALTER TABLE tblProduse ADD Furnizor Text(50);

- ştergerea unei coloane (exemplu): ALTER TABLE tblProduse DROP COLUMN Furnizor;

DROP TABLE 238

Baze de date

Anexe

Instrucţiunea DROP TABLE este folosită pentru eliminarea unui tabel din baza de date. Sintaxa este următoarea(exemplu, ştergerea tabelului tblProduse): DROP TABLE tblProduse;

CREATE VIEW Instrucţiunea CREATE VIEW este folosită pentru crearea unei vederi noi a unuia sau mai multor tabele. Sintaxa este următoarea: CREATE VIEW NumeVedere AS SELECT Coloana1, Coloana2, … FROM Tabel1, Tabel2, ... [WHERE ...] [GROUP BY ...] [HAVING ...] ;

Bibliografie [1]

Mocian Ioan, Baze de date – Terminologie, Proiectare, SQL, Access, Editura MATRIX ROM, 2007.

[2]

Michael J. Hernandez, Proiectarea bazelor de date, traducere din limba engleză, Editura Teora, 2003.

[3]

Susan Sales Harkins, Ken Hensen, Tom Gerhart, Utilizare Microsoft Access 2000, traducere din limba engleză, Editura Teora, 2000.

[4

Năstase Pavel, s.a., Baze de date Microsoft Access 2000, Editura Teora, 2004.

[5]

Ben Forta, SQL pentru începători, traducere din limba engleză, Editura Teora, 2002.

239