UNIVERSITATEA DE VEST DIN TIMIȘOARA

Transcriere

1 UNIVERSITATEA DE VEST DIN TIMIŞOARA FACULTATEA DE ECONOMIE ŞI DE ADMINISTRARE A AFACERILOR CENTRUL DE EDUCAŢIE CONTINUĂ ŞI ÎNVĂŢĂMÂNT DESCHIS LA DISTANŢĂ Lect.univ.dr. Diana Târnăveanu Asist.univ.dr. Ileana Hauer Baze de date. Access 2007 MANUAL PENTRU ÎNVĂŢĂMÂNTUL LA DISTANŢĂ, ANUL I, CONTABILITATE ŞI INFORMATICĂ DE GESTIUNE

2 Capitolele 1-3: asist. univ. dr. Ileana Hauer Capitolele 4-6: lect. univ. dr. Diana Târnăveanu 6

3 CUPRINS OBIECTIVELE CURSULUI CAPITOLUL 1 CONCEPTE GENERALE DESPRE BAZELE DE DATE ŞI SISTEMELE DE GESTIUNE A BAZELOR DE DATE Revoluţia relaţională Conceptul de bază de date Conceptul de sistem de gestiune a bazelor de date Introducere Obiectivele unui SGBD Funcţiile unui SGBD Regulile lui Codd Modelarea datelor Modele de date: perspectivă istorică Sistemul de gestiune bazat pe fişiere (SGF) Modele prerelaţionale Modelul relaţional Modelele postrelaţionale şi noi funcţionalităţi Rezumatul capitolului Întrebări de auto-evaluare CAPITOLUL 2 PROIECTAREA ŞI IMPLEMENTAREA BAZELOR DE DATE Arhitectura ANSI-SPARC Proiectarea bazelor de date Utilizarea modelelor de date în etapa de proiectare Modelul conceptual al bazei de date Modelul logic al bazei de date Modelul fizic al bazei de date Rezumatul capitolului Întrebări de autoevaluare

4 CAPITOLUL 3 MODELUL CONCEPTUAL AL BAZELOR DE DATE RELAŢIONALE Entitaţi şi instanţe Atribute Concept şi tipologie Cheia primară, un atribut special Entitate sau atribut Relaţii Definiţie Gradul şi cardinalitatea relaţiilor Schema conceptuală şi diagrama entitate-relaţie Modelul relaţional: fundamentarea teoretică Concepte de bază Stabilirea relaţiilor între entităţi Reguli de integritate pentru bazele de date relaţionale Valoarea specială Null a atributelor Integritatea entităţilor Integritatea referenţială Restricţii procedurale Implementarea modelului conceptual Rezumatul capitolului Întrebări de auto-evaluare CAPITOLUL 4 NORMALIZAREA BAZELOR DE DATE Introducere Organizarea datelor Dependenţe Dependenţe funcţionale simple Dependenţe funcţionale directe şi tranzitive Dependenţe funcţionale multiple Dependenţe multivaloare Dependenţe joncţiune Matricea dependenţelor funcţionale Forme normale Forma normală Forma normală

5 4.4.3 Forma normală Concluzii Rezumatul capitolului Întrebări de autoevaluare din partea teoretică Exemple Problemă rezolvată Filiala CEC Probleme propuse CAPITOLUL 5 ELEMENTE INTRODUCTIVE ÎN ACCESS Introducere SGBD Access: prezentare generală Caracteristici generale Operaţii cu baze de date Obiectele bazei de date Obiecte Tables Obiecte Queries Interogări de selecţie Interogări de sintetizare a datelor Interogări de acţiune Obiecte Forms Formulare create cu ajutorul butonului Form Formulare create cu ajutorul butonului Form Wizard Formulare create cu ajutorul butonului Form Design Formulare cu sub-formulare Obiecte Reports Obiecte Macros Obiecte Modules Concluzii Rezumatul capitolului Întrebări de autoevaluare din partea teoretică Exemple Problemă rezolvată Tabelă creată în Datasheet View Problemă rezolvată Tabele create în Design View Problemă rezolvată Formulare şi controale Problemă rezolvată Formulare cu controale calculate, Switchboard Problemă rezolvată Interogări Problemă rezolvată Rapoarte

6 5.13 Probleme propuse Problema propusă Crearea tabelelor Filială CEC Problemă propusă Crearea formularelor Problemă propusă Crearea interogărilor Problemă propusă Crearea rapoartelor CAPITOLUL 6 ELEMENTE SQL Introducere Comenzi SQL Comanda CREATE TABLE Comanda ALTER TABLE Comanda DROP TABLE Comanda INSERT INTO Comanda DELETE Comanda SELECT Comanda UPDATE Concluzii Rezumatul capitolului Întrebări de autoevaluare din partea teoretică Exemple Problemă rezolvată Produse Problemă rezolvată Aprovizionare Problemă propusă Bibliotecă Problemă propusă Amenajări interioare BIBLIOGRAFIE GLOSAR DE TERMENI

7 OBIECTIVELE CURSULUI Calculatorul va fi utilizat ca instrument de lucru pentru prelucrarea automată a volumelor mari de date organizate sub formă de baze de date, extrem de importante ca suport de date pentru sistemele informatice integrate de management al activităţii organizaţiilor. Obiectivele cursului sunt însuşirea conceptelor de bază legate de : organizarea volumelor mari de date sub formă de baze de date şi prelucrarea acestora; formarea deprinderilor de a utiliza facilităţile specifice programului Microsoft Access; construirea şi gestionarea unor baze de date proprii (prelucrări de complexitate medie). În cadrul cursului sunt expuse principiile de bază ale proiectării bazelor de date după modelul relaţional al şi se prezintă principalele obiecte ale bazelor de date Access, precum şi modul de proiectare şi utilizare a acestora. În cadrul seminarului se exersează crearea bazelor de date Access, a tabelelor, interogărilor, formularelor, rapoartelor şi a comenzilor SQL. 11

8 12

9 CAPITOLUL 1 CONCEPTE GENERALE DESPRE BAZELE DE DATE ŞI SISTEMELE DE GESTIUNE A BAZELOR DE DATE 1.1 Revoluţia relaţională Astăzi beneficiem de avantajele aduse de bazele de date relaţionale: capacitatea de stocare, accesare, şi modificare rapidă a datelor pe calculatoarele low-cost. Totuşi, până la sfârşitul anilor 1970, bazele de date au stocat cantităţi mari de date într-o structură ierarhică, care a fost dificil de navigat şi inflexibilă. Programatorii aveau nevoie să ştie ce doreau clienţii să facă cu datele înainte de a proiecta baza de date. Adăugarea sau schimbarea modului de analiză a datelor a fost un proces îndelungat şi costisitor. În 1970, Edgar "Ted" Codd, un matematician angajat de IBM, a scris un articol care va schimba toate astea. La acea vreme, nimeni nu şi-a dat seama că teoriile lui Codd vor declanşa o revoluţie tehnologică la egalitate cu dezvoltarea calculatoarelor personale şi Internet (Coronel, et al., 2009) Don Chamberlin, coinventor al SQL, cel mai popular limbaj utilizat de sistemele de baze de date de astăzi, şi-a amintit cum teoriile matematice ale lui Codd nu au fost luate în seamă. Apoi Ted Codd a organizat un simpozion, iar Chamberlin a ascultat cum Codd a redus cinci pagini complicate de program la o linie. Simpozionul a convins IBM pentru a finanţa Sistem R, un proiect de cercetare care a construit o prototip al unei baze de date relaţionale şi care va duce în cele din urmă la crearea limbajelor SQL şi DB2. Adevăratele sisteme relaţionale s-au afirmat pe piaţă începând cu anul 1984: sistemul DB2 (IBM Corp.) funcţionează pe mainframe-urile IBM şi, prin urmare, e portabil pe RS/6000; Oracle (Oracle Systems) a devenit un sistem de gestiune relaţional portabil pe mai multe platforme; sistemul RDBMS (AWB) funcţionează pe calculatoarele AT&T 3B; sistemele de gestiune Informix (Informix Software) şi Sybase (Sybase Inc.) funcţionează în mediul Unix. Mai multe sisteme de gestiune ale bazelor de date relaţionale (FoxPro, Paradox etc.) au fost elaborate pentru calculatoarele personale. Dezvoltarea teoriei bazelor de date relaţionale a căpătat o amploare nemaivăzută în domeniul aplicării tehnicii de calcul. Au apărut o serie de reviste specializate în domeniul respectiv. Între elaborările teoretice şi producerea sistemelor comerciale s-a creat un spaţiu de cel puţin 20 ani. Acesta e un rar exemplu când necesităţile software considerabil depăşesc capacităţile hardware. Rezultatele obţinute în teoria relaţională au influenţat esenţial sistemele de gestiune ce se bazează pe celelalte două modele de date: 13

10 ierarhic şi reţea. Modelul relaţional de date e aplicat pe larg şi în bazele de date deductive. Pe de altă parte, se observă convergenţa modelului relaţional şi tehnologiilor orientate pe obiecte. "Revoluţia relaţională" a introdus mai multe idei valoroase în lumea bazelor de date. Printre acestea progrese tehnologice şi beneficii ale sistemelor de gestiune ale bazelor de date pot fi menţionate: Tabelele sunt un mijloc simplu de reprezentare a datelor. Ele permit programatorilor şi utilizatorilor finali să-şi organizeze datele în mod acceptabil. Extinderea modelului relaţional a confirmat puterea de atracţie a acestei reprezentări. SQL este un standard de limbaje de interpelări foarte comod. El e un limbaj nonprocedural de manipulare a datelor şi a contribuit mult la creşterea popularităţii sistemelor de gestiune ale bazelor de date relaţionale. Operaţiile orientate pe mulţimi permit programatorilor şi utilizatorilor ordinari să găsească şi să actualizeze mari colecţii de înregistrări fără a scrie programe speciale. Joncţiunile sunt instrumente puternice de asociere a înregistrărilor anterior independente. Utilizatorii pot crea noi seturi de înregistrări (aşa-numitele tabele virtuale), apelând la joncţiune. Interpelările interactive. Căutarea şi prelucrarea datelor în mod dinamic a adus la utilizarea largă a bazelor de date relaţionale. Gestionarea tabelelor, vizualizarea interactivă şi îmbunătăţirea interactivă a contribuit ca utilizatorul să-şi dea votul pentru sistemele relaţionale. Consistenţa datelor. Sistemele de gestiune relaţionale asigură că nici un utilizator şi nici o aplicaţie nu pot modifica baza de date, dacă modificarea e în contradicţie cu constrângerile de integritate. 14

11 1.2 Conceptul de bază de date Apariţia şi dezvoltarea calculatoarelor electronice au condus la amplificarea activităţilor legate de stocarea, interogarea şi administrarea colecţiilor de date. O colecţie de date reuneşte date despre o anume clasă de obiecte (reale sau conceptuale). Folosirea tehnologiilor informaţionale în colectarea, stocarea, procesarea şi transmiterea colecţiilor de date a impus definirea unor tehnici şi metode de organizare a acestora. Se cunosc două metode de organizare a colecţiilor de date: - organizarea în fişiere de date; - organizarea în baze de date. Organizarea datelor în fişiere de date este specifică anilor 60 şi poate fi utilizată şi astăzi, îndeosebi în cazul folosirii limbajelor procedurale de programare 1, cum ar fi limbajele Cobol, Fortran, Basic. Ca limite ale organizării datelor în fişiere menţionăm: - descrierea datelor se face în fiecare program în care ele sunt utilizate; spunem că datele sunt dependente de program. - lipsa unui formalism riguros de definire şi validare a datelor. - menţinerea unei redundanţe ridicate în cadrul colecţiilor de date memorate pe suporturi tehnice. - performanţe scazute pentru procesarea datelor îndeosebi cand este necesar să se facă asocieri între datele memorate în fişiere de date distincte. Limitele organizării datelor în fişiere şi posibilităţile oferite de noile tehnologii informaţionale au dus la promovarea metodei de organizare a datelor în baze de date. Astăzi, cele mai multe dintre activităţile noastre zilnice necesită accesarea şi actualizarea informaţiei dintr-o bază de date: extragerea unei sume de bani din cortul bancar, rezervarea unei camere de hotel, cumpărarea unui bilet de avion, împrumutul unei cărţi de la bibliotecă, plata facturilor de telefon, curent electric etc. Toate acestea se pot face rapid şi în siguranţă, pentru că datele respective sunt bine organizate într-o bază de date şi administrate de un sistem de gestiune a bazelor de date. Pentru baza de date 2 avem mai multe definiţii: este un ansamblu integrat de înregistrări sau de fişiere legate între ele în mod logic (Lungu, et al., 1995). 1 Versiuni recente ale acestor limbaje permit și accesarea datelor organizate în baze de date. 2 Termenul database (bază de date în limba engleză) a apărut pentru prima dată în titlul unei conferințe organizate în Santa Monica, SUA, în 1964: Development and Management of Computer Centered Database. 15

12 ansamblu structurat de date înregistrate pe suporturi accesibile de calculator pentru a satisface, chiar simultan, mai mulţi utilizatori de o manieră selectivă şi în timp oportun (Delobel, Adiba, 1982). colecţie de date aflate în interdependenţă, împreună cu descrierea datelor şi a relaţiilor dintre ele (Pescaru, et al, 1976). colecţie de date utilizată într-o organizaţie, colecţie care este automatizată, partajată, definită riguros (formalizată) şi controlată la nivel central (Everest, 1986). Faţă de modelul bazat pe fişier, noutatea adusă de organizarea datelor în baze de date o constituie existenţa unui fişier de descriere globală al bazei, astfel încât să se poată asigura independenţa programelor faţă de date. Acest fişier de descriere globală al bazei este denumit dicţionar de date sau catalog al sistemului. După cum se observă din figura 1.1, lucrul cu fişierele de date, deci extragerea şi modificarea datelor, se desfăşoară exclusiv prin intermediul dicţionarului de date în care se găsesc informaţii privitoare la structura datelor şi restricţiile îndeplinite de acestea. 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) 16

13 Figura 1.1 Schema de principiu a unei baze de date Adaptare după Fotache, M., 1997 A proiecta o bază de date înseamnă a-i stabili structura, adică elementele componente, caracteristicile acestora, restricţiile pe care trebuie să le respecte, relaţiile dintre ele. A construi o bază de date înseamnă a memora (a introduce) datele în baza de date, după proiectarea acesteia. A administra o bază de date înseamnă a asigura: (1) accesul la date al utilizatorilor, în funcţie de drepturile fiecăruia (funcţia şi importanţa fiecăruia în organizaţia respectivă), (2) coerenţa bazei de date (recuperarea informaţiei atunci când au loc incidente: întreruperea alimentării cu curent electric, operaţii contradictorii etc), (3) securitatea datelor stocate etc. A interoga o bază de date înseamnă a extrage şi a vizualiza datele care îndeplinesc anumite criterii şi condiţii. A actualiza o bază de date înseamnă a modifica structura sau informaţiile stocate în baza de date. Nu orice colecţie de date este o bază de date. De exemplu, lista cărţilor dintr-o bibliotecă nu este o bază de date, ci un simplu inventar de obiecte, o listă, un tabel. Dacă la această listă adăugăm lista cititorilor abonaţi la bibliotecă (eventual şi lista angajaţilor bibliotecii) şi luăm în considerare activităţile specifice bibliotecii (achiziţionarea de cărţi noi, împrumutul şi restituirea cărţilor de către cititori, eventual administrarea sarcinilor de serviciu ale angajaţilor), atunci avem de a face cu o bază de date. 17

14 În concluzie, faţă de un inventar (un tabel), o bază de date are următoarele proprietăţi: reprezintă un anumit aspect al lumii reale, numit microuniversul bazei de date; orice modificare care se produce în acest microunivers se reflectă în baza de date (de exemplu: cumpărarea unui nou DVD în vederea închirierii, modificarea diferenţei permise între cursul de cumpărare şi cel de vânzare al valutei etc); este o colecţie de date coerentă din punct de vedere logic şi având un înţeles intrinsec (de exemplu: din baza de date asociată bibliotecii universităţii nu vor face parte cărţile de telefon sau lista de materiale didactice din laboratorul de informatică); este proiectată, construită şi administrată, având permanent în vedere un anumit scop; o bază de date este destinată utilizării de către un anumit grup de persoane şi permite efectuarea unui anumit set de operaţii. 18

15 1.3 Conceptul de sistem de gestiune a bazelor de date Introducere O bază de date apare ca o colecţie de date stocată pe memorii externe adresabile, folosite de o multitudine de utilizatori, dar dacă baza de date care nu are asociat un sistem de gestiune al acesteia, ea nu îşi atinge obiectivele pentru care a fost creată. Prin urmare un SGBD 3 (în engleză Database Management System abreviat DBMS) este un pachet software de nivel înalt, care permite proiectarea, construirea şi administrarea bazelor de date dedicate rezolvării problemelor din cele mai variate domenii ale vieţii reale. Sistemul de gestiune al bazei de date reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activităţi (Lungu, et al., 1995): - definirea structurii bazei de date; - încărcarea datelor în baza de date; - accesul la date (interogare, actualizare); - întreţinerea bazei de date (colectarea şi refolosirea spaţiilor goale, refacerea bazei de date în cazul unui incident); - reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces); - securitatea datelor. Aşadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigură interfaţa între o bază de date şi utilizatorii acestuia Obiectivele unui SGBD După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea, transmitarea, stocarea şi prelucrarea automată a datelor cu ajutorul mijloacelor electronice de calcul, în scopul satisfacerii diferitelor nivele de conducere cu informaţii necesare luării deciziilor, în condiţii de eficienţă economică sporită. În aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de cerinţe prin care să se asigure: minimizarea costului procesului de prelucrare a datelor; creşterea vitezei de răspuns la întrebările solicitate de utilizatori; adaptarea facilă a sistemului informatic la evoluţia în timp a sistemului informaţional din care face parte; posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanţii de sistem; posibilitatea 3 Exemple de SGBD: Microsoft Access, FoxPro (de la Microsoft), Paradox, Visual dbase (de la Borland), Oracle 10g (de la Oracle Corporation), Sybase Adapted Server (de la Sybase Inc.), Iris (de la Hewlett-Packard), IMS, DB2 (până DB9 de la IBM). 19

16 folosirii sistemului de informare dispunând de un minim de cunoştinţe despre modul de organizare a lui în general şi informatică în special; integritatea şi securitatea datelor etc. În acest context, sistemului de gestiune al bazei de date îi revin o serie de de obiective, cum sunt: 1) Asigurarea independenţei datelor. O aplicaţie, în general, este dependentă de date în sensul că modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi aplicaţia. Independenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele considerente: diferite aplicaţii au nevoie de viziuni diferite ale aceloraşi date; administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de acces, ca răspuns la cerinţe (schimbări de standarde, priorităţile aplicaţiilor, unităţile de memorare etc), fără a modifica aplicaţiile existente; baza de date existentă, precum şi programele de exploatare a ei, care au fost folosite o perioadă de timp, reprezintă o investiţie majoră la care nu trebuie să se renunţe prea uşor. Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică; independenţa logică a datelor. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorarea să poată fi modificate fără a determina rescrierea programelor de aplicaţie. Independeţa logică a datelor se referă la posibilitatea adăugării de noi articole de date sau extinderea structurii conceptuale (globale), fără ca aceasta să impună rescrierea programelor existente. 2) Asigurarea unei redundanţe minime şi controlate a datelor din baza de date. Spre deosebire de sistemele clasice de prelucrare automată a datelor, stocarea datelor în cazul bazelor de date se face astfel încât flecare dată să apară o singură dată. Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performanţe sporite, referitoare la timpul de acces la date şi răspuns la solicitările utilizatorilor, să se accepte o anumită redundanţă a datelor, însă în acest caz se va institui un control automat asupra ei în vederea asigurării coerenţei datelor din bază. 3) Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta presupune: - folosirea datelor de către mai mulţi utilizatori în diferite scopuri (aplicaţii); - accesul cât mai simplu al utilizatorilor la date, fără ca aceştia să fie nevoiţi să cunoască structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei de date; - existenţa unor limbaje performante de regăsire a datelor, care permit exprimarea sub forma unei conversaţii, a unor criterii de selecţie a datelor şi indicarea unor reguli cât mai generale pentru editarea informaţiilor solicitate; 20

17 - spre deosebire de sistemul clasic de prelucrare pe fişiere, unde exista un singur criteriu de adresare (cel care a stat la baza organizării fişierului) în cazul bazelor de date, sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la fişierele clasice implică reorganizarea lor; - utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod facil a bazei de date şi de către utilizatorii neinformaticieni. 4) Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. În condiţiile bazelor de date, administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai prin canale corespunzătoare, şi poate, totodată, defini, verificări de autorizare realizate oricând se încearcă accesul la anumite date. 5) Asigurarea integrităţii datelor împotriva unor ştergeri intenţionate sau neintenţionate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor proceduri de refacere a bazei de date după incidente. 6) Asigurarea partajabilităţii datelor. Partaj abilitatea datelor trebuie înţeleasă nu numai sub aspectul asigurării accesului mai multor utilizatori la aceleaşi date, ci şi acela al posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date Funcţiile unui SGBD Pentru realizarea obiectivelor enumerate anterior, sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit efectuarea numeroaselor operaţii. În funcţie de natura lor şi scopul urmărit, operaţiile pot fi grupate pe activităţi. Activităţile acceptă şi ele o grupare pe funcţii (una sau mai multe activităţi, relativ omogene, vor realiza o anumită funcţie). Ţinând seama de multitudinea sarcinilor ce revin unui sistem de gestiune a bazelor de date şi grupând aceste sarcini pe activităţi şi apoi pe funcţii, se deduc, în final, funcţiile sistemului de gestiune. Ţinând seama de complexitatea sistemului de gestiune, de facilităţile propuse a fi oferite de acesta, de limbajele utilizate 4 şi tipul bazei de date ce urmează a fi gestionată de SGBD, gruparea activităţilor pe funcţii are un oarecare caracter relativ. În situaţia sistemelor de 4 Un SGBD pune la dispoziție utilizatorilor limbaje distincte pentru 1) descrierea bazei de date (limbaj de descriere a datelor- LDD) și 2) manipularea bazelor de date (limbaj de manipulare a datelor-lmd). Limbajele de manipulare (interogare) a bazelor de date pot fi: declarative (permit utilizatorului să declare de ce informații are nevoie) și procedurale (obligă utilizatorul să descrie procedura de obținere a informațiilor). 21

18 gestiune ce utilizează limbaje gazdă de nivel înalt, identificarea şi delimitarea funcţiilor nu este atât de evidentă. În ciuda acestor particularităţi, totuşi, se pot deduce câteva funcţii cu caracter de generalitate pentru toate sistemele de gestiune a bazelor de date. Prezentăm în continuare câteva astfel de funcţii: 1) Funcţia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. Definirea datelor poate fi realizată la nivel logic, conceptual şi fizic. La nivelul acestei funcţii se descriu multitudinea atributelor (câmpurilor) din cadrul structurii bazei de date, legăturile dintre entităţile bazei de date sau dintre atributele aceleiaşi entităţi, se definesc eventualele criterii de validare a datelor, metodele de acces la date, aspectele referitoare la asigurarea integrităţii şi confidenţialităţii datelor, etc. Rezultatul acestei funcţii se va concretiza în schema bazei de date, memorate în cod intern. 2) Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează următoarele activităţi: - crearea (încărcarea) bazei de date; - adăugarea de noi înregistrări (tupluri); - suprimarea unor înregistrări; - modificarea valorilor corespunzătoare unor câmpuri; - căutarea, sortarea şi editarea parţială sau totală a unei înregistrări virtuale etc. Funcţia de manipulare a datelor se realizează prin intermediul limbajului de manipulare a datelor. 3) Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utlizatorilor cu baza de date. În cadrul realizării acestei funcţii, apar mai multe categorii de utilizatori: - utilizatori liberi sau conversaţionali. Aceaştia reprezintă categoria beneficiarilor de informaţii (utilizatori finali) care utilizează limbajele de interogare a bazei de date într-o formă simplistă. Ei apar ca utilizatori neinformaticieni; - utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri complexe de exploatare a bazei de date; - administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor în ceea ce priveşte funcţionarea optimă a întregului ansamblu. 4) Funcţia de administrare a bazei de date apare ca o funcţie complexă şi este de competenţa administratorului bazei de date. 22

19 1.3.4 Regulile lui Codd Un sistem de gestiune a bazelor de date relaţionale (Relational Database Management System - RDBMS) este o un sistem de gestiune a bazelor de date care foloseşte modelul relaţional. În anul 1985, E.F. Codd a publicat un set de 13 reguli de fidelitate pe baza cărora se apreciază dacă un sistem de gestiune de baze de date poate fi considerat relaţional. Tabelul 1.1 prezintă pe scurt aceste reguli. Nr. Nume regulă Descriere 0 Principiu de Orice SGBD Relaţional (SGBDR) bază trebuie să gestioneze întreaga bază de date numai prin posibilităţile modelului relaţional. Dacă un SGBD este dependent de un instrument de manipulare al datelor la nivel de 1 Stocarea informaţiei 2 Garantarea accesului 3 Lipsa informaţiei 4 Catalogul de sistem întregistrare, nu este total relaţional. Toate datele unui SGBD relaţional se reprezintă explicit ca valori în tabele. Datele nu pot fi stocate prin alte metode. Fiecare element de dată trebuie să fie accesibil logic printr-o combinaţie de forma: cheie primară, nume de tabel şi nume de câmp. Valorile vide (Null) trebuie să fie suportate explicit. Null-urile reprezintă informaţia lipsă sau imposibil de aplicat. Descrierea bazei de date sau catalogul trebuie să se facă la nivelul logic sub forma unor valori în tabele. Limbajul relaţional (SQL) trebuie să poată acţiona asupra proiectului bazei de date în acelaşi mod în care acşionează asupra datelor stocate în structură. Implementare Access Access a fost primul SGBD care rula sub Windows şi respecta această regulă. Access nu foloseşte numere de înregistrări. Access îşi stochează datele în tabelele motorului bazei de date Microsoft Jet. Access respectă această regulă prin folosirea Cheii Primare (Primary Key) Access suportă lucrul cu valori Null pentru descrierea informaţiilor lipsă. Catalogul rezidă în motorul bazei de date Microsoft Jet. Se poate folosi OpenSchema din ADO pentru interogarea catalogului de sistem. Limbajul DDL SQL al motorului bazei de date Microsoft Jet oferă posibilitatea creării tabelelor, cheilor etc. 23

20 5 Limbaj cuprinzăto 6 Actualizarea vederilor 7 Actualizări la nivel de mulţime 8 Independenţa fizică a datelor 9 Independenţa logică a datelor 10 Independenţa integrităţii datelor Un SGBD trebuie să suporte un limbaj clar pentru manipularea datelor (SQL) care asigură modalităţi cuprinzătoare pentru manipularea datelor, definirea datelor, definirea vederilor, constrângerile de integritate, limitările de tranzacţii şi de autorizare. Toate vederile trebuie să poată fi actualizate de sistem. Într-un SGBD total relaţional majoritatea vederilor ar trebui să se poată actualiza. Un SGBDR trebuie să facă mai mult decât simpla extragere a datelor. Trebuie să aibă capacitatea de inserare, actualizare şi ştergere a datelor, privite ca o mulţime relaţională. Datele trebuie să fie fizic independente de programul aplicaţie. SGBDR trebuie să fie în stare să urmărească modificările fizice la nivelul datelor pe "sub aplicaţie". De exemplu, SGBDR nu se va modifica dacă un index se adaugă sau se şterge dintr-un tabel. Pe cât este posibil, aplicaţiile software trebuie să fie independente de modificările făcute în tabelele de bază. De exemplu, nu trebuie să se rescrie codul în cazul în care tabelele sunt combinate într-o vedere. Integritatea datelor trebuie să se poată defini într-un limbaj relaţional şi să fie stocată în catalog. Constrângeri de integritate a datelor trebuie să poată fi construite la nivel de aplicaţie. Acest concept este oarecum străin modelului relaţional. În modelul relaţional, integritatea trebuie să fie inerentă proiectului bazei de date. Access, prin motorul Jet, asigură SQL pentru manipularea datelor, crearea vederilor (Select Queries), constrângerile de intergritate (Relationships şi Create Constraint. Access a fost primul SGBD pe PC-uri care a permis interogări de actualizare (Update Query) Access suportă interogări de acţiune (Action Query) Access permite modificarea obiectelor bazei de date fără alterarea celorlalte componete ale Accessului. Jet are motor de stocare logic. În Access, o interogare se poate lega la un formular sau la un raport la fel de simplu ca un tabel. Deşi Microsoft nu a documentat modul în care Jet stochează integrităţile, se pot crea reguli de integritate via SQL. Jet va stoca aceste informaţii în proiectul bazei de date ca parte a catalogului. 24

21 11 Independenţa distribuţiei 12 Inexistenţa subminărilor Capacităţile SGBDR nu au voie să fie limitate datorită distribuţiei unor componente ale acestuia în baze de date separate. Dacă un SGBDR are un limbaj de manipulare "a unei singure înregistrări la un moment dat", acest limbaj nu va putea fi folosit la ocolirea regulilor de integritate sau a constrângerilor modelului relaţional. Astfel nu numai că SGBDR trebuie să fie guvernat de reguli relaţionale, ci aceste reguli trebuie să fie şi primare. Pentru că motorul Jet stochează regulile de integritate la nivel de motor, alte componente ale motorului nu afectează regulile de integritate. Access permite folosirea lui DAO şi ADO pentru manipularea a câte unei singure înregistrări la un moment dat prin intermediul mulţimilor de înregistrări actualizabile (updateable recordsets) Nici unul dintre SGBD disponibile astăzi nu respectă complet cerinţele exprimate de Codd, în cadrul celor 13 reguli. De aceea pentru caracterizarea unui SGBD nu sunt utilizate regulile lui Codd, fiind formulate în schimb o serie de cerinţe minimale pe care trebuie să le îndeplinească programul pentru a fi considerat relaţional (Lungu, et al., 1995). Un SGBD este minimal relaţional dacă datele din cadrul bazei de date sunt reprezentate prin valori în tabele, nu există pointeri observabili de către utilizatori, iar sistemul suportă operatorii relaţionali de proiecţie, selecţie şi compunere naturală, fără limitări impuse din considerente interne. Un SGBD este complet relaţional dacă este minimal relaţional şi, în plus, sistemul suportă restricţiile de integritate de bază (unicitatea cheii primare, constrângerile de referinţă, integritatea entităţii) şi precum şi toate operaţiile de bază ale algebrei relaţionale. Un obiectiv important a proiectării unei baze de date de tip relaţional îl reprezintă gruparea atributelor în relaţii astfel încât redundanţa datelor să fie minimă. Relaţiile care conţin date redundante pot crea probleme, denumite anomalii de reactualizare, care clasificate în: o anomalii de ştergere constau în faptul că anumite date care urmează să fie şterse, fac parte din tupluri în care se găsesc şi alte date care mai sunt necesare în continuare, ori ştergerea făcându-se la nivelul tuplului, acestea se pierd; o anomalii de inserare (adăugare) constau în faptul că anumite date care urmează să fie adăugate fac parte din tupluri incomplete (pentru care nu se cunosc toate datele), ceea ce face ca acestea să nu poată fi adăugate; 25

22 o anomalii de modificare rezultă din faptul că este dificil de modificat o valoare a unui atribut atunci când ea apare în mai multe tupluri ale relaţiei. Eliminarea acestor anomalii se realizează cu ajutorul operaţiei numite normalizare 5, care este o tehnică formală care se bazează pe cheile primare, respectiv cheile candidat ale relaţiilor şi pe dependenţele funcţionale. Tehnica include o mulţime de reguli care pot fi utilizate pentru testarea relaţiilor individuale. 5 Subiect dezvoltat în capitolul 4. 26

23 1.4 Modelarea datelor Pentru cunoaşterea realităţii înconjurătoare şi prelucarea datelor cu ajutorul calculatoarelor este necesară modelarea acestei realităţi. O bază de date oferă un anumit grad de abstractizare a datelor (asemenea celor mai multe limbaje de programare), ascunzând detaliile de implementare, detalii care nu sunt necesare celor mai mulţi dintre utilizatori. Cu alte cuvinte, programele specifice unei baze de date nu depind de modul de stocare şi accesare a datelor la nivel fizic. Acest concept se numeşte independenţă a datelor, se realizează cu ajutorul unui model de date (Data Model 6 ) şi este principalul mecanism care asigură partajarea datelor din baza de date între diferitele aplicaţii care le accesează Modele de date: perspectivă istorică Evoluţia modelelor de date pentru bazele de date şi SGBD-uri a fost sugestiv sintetizată de R.G.G. Canttell în articolul său What Are Next- Generation DB Systems?", publicat în revista Communications of the ACM, în octombrie 1991: Istoria informaticii a cunoscut multe generaţii de sisteme de gestiune a datelor, începând cu sistemele de fişiere indexate, continuând apoi cu sistemele de tip ierarhic şi de tip reţea, iar - mai nou - cu sistemele relaţionale. Acum suntem pe punctul de a intra într-o nouă generaţie de sisteme de gestiune a bazelor de date care oferă administrare de obiecte şi care acceptă tipuri de date mult mai complexe". Cu toate că a generat o activitate de cercetare foarte susţinută dar şi o activitate practică, industrială extrem de productivă, domeniul bazelor de date este unul dintre cele mai tinere domenii ale informaticii. Este general acceptat faptul că rădăcinile" sale trebuie căutate aproximativ acum 40 de ani (data apariţiei primului sistem comercial de gestiune a bazelor de date), în obiectivul fixat de preşedintele J.F. Kennedy pentru programul Apollo: aducerea primului om pe Lună până la sfârşitul anilor 60. În acel moment, nu exista nici un instrument informatic care să funcţioneze efectiv şi care să poată administra uriaşele volume de date implicate în programul spaţial. Ca urmare, North American Aviation (NAA), primul contractor al proiectului, a dezvoltat un software bazat pe o structură ierarhică (părţile se agregă în componente din ce în ce mai ample) denumit GUAM (Generalized Update Access Method). Spre 6 E.F.Codd este considerat a fi părintele conceptului de model de date, în general, și al conceptului de model de date relațional, în particular. 27

24 mijlocul anilor '60, IBM s-a alăturat NAA dezvoltând în continuare GUAM şi producând unul dintre primele sisteme comerciale de gestiune a bazelor de date: IMS (Information Management System). IBM a preluat modelul ierarhic pentru a respecta cerinţa de stocare a datelor pe benzi magnetice (deci în acces secvenţial). Ulterior, această restricţie a fost înlăturată şi IMS continuă să fie principalul SGBD ierarhic utilizat de majoritatea calculatoarelor mainframe 7. Construirea bazelor de date a cunoscut o evoluţie foarte rapidă, trecând prin mai multe abordări, clasificate după cum urmează: sistemele de fişiere; sistemele prerelaţionale (sau istorice", numite şi navigante sau tradiţionale -legacy systems): ierarhic şi reţea; sistemul relaţional; sistemele postrelaţionale: orientat obiect şi hibrid (obiect-relaţional); sistemele semantice: multidimensional şi logic (deductiv) Sistemul de gestiune bazat pe fişiere (SGF) Considerat de fapt un predecesor al sistemelor de gestiune a bazelor de date, SGF reprezenta o colecţie de programe care realizau - fiecare - câte un serviciu" pentru utilizatorii datelor (de obicei: generarea de rapoarte). Fiecare program îşi definea şi îşi administra propriile date. Chiar dacă a avut numeroase dezavantaje (abordarea descentralizată în stocarea informaţiilor, gradul mare de redundanţă şi dependenţă program-date), sistemul de gestiune bazat pe fişiere a constituit un salt semnificativ faţă de fişierele administrate manual: saltul de la abordarea informaţională la cea informatică. 7 Un calculator mainframe este un calculator cu capacitate de memorie şi viteză de lucru foarte mari, utilizat de marile corporaţii pentru a stoca volume foarte mari de date şi pentru a coordona sute sau mii de terminale (inclusiv calculatoare personale) conectate la el. 28

25 1.4.3 Modele prerelaţionale Aceste modele pot fi caracterizate ca modele de moment: au oferit soluţii pentru problemele vremii lor, dar nu au avut un fundament teoretic puternic şi riguros. Atât în modelul ierarhic, cât şi în modelul reţea datele erau reprezentate ca mulţimi de înregistrări (în sensul limbajului de programare Pascal: colecţii de pate de diferite tipuri: Integer, Boolean, Real etc.). Relaţiile dintre ele erau reprezentate prin legături de tip pointer (adrese de locaţii fizice de memorie) Înregistrările care formau baza de date erau organizate: în modelul ierarhic: ca o mulţime de arbori ; în modelul reţea: ca o mulţime de grafuri. Ambele modele prerelaţionale permiteau accesul la date de-a lungul unor drumuri (căi) predefinite, explicit stabilite la nivelul programelor de aplicaţii (de şi numele de modele navigante). Ca urmare, orice modificare a structurii bazei de date antrena modificarea acestor căi în programele deja scrise. Exemple: :tru modelul ierarhic: IMS (amintit mai sus); pentru modelul reţea: IDS II (de Honeywell), IMAGE (de la Hewlett Packard). Studiu de caz: modelarea activităţii didactice Într-o facultate, cadrele didactice desfăşoară activităţi didactice de curs sau examen; aceste activităţi sunt pentru studenţi şi se desfăşoară în locaţii (amfiteatre sau laboratoare). De asemenea, cadrele didactice participă la proiecte de cercetare ştiinţifică. Figura 1.2 prezintă modelul ierarhic al facultăţii iar figura 1.3 prezintă modelul reţea. Figura 1.2 Modelul ierarhic 29

26 Figura 1.3 Modelul reţea Modelul relaţional Considerat drept cel mai important eveniment din istoria bazelor de date, apariţia modelului relaţional s-a produs în iunie 1970, odată cu publicarea - în revista Communications of the ACM - a articolului fundamental al lui Edgar Frank Codd 8 (de la IBM Research Laboratory): A Relaţional Model of Data for Large Shared Databanks". În acest articol, autorul aplica o serie de concepte din algebra relaţională pentru a rezolva problemele legate de stocarea volumelor mari de date şi enunţa celebrele" 12 reguli (condiţii) pe care trebuie să le îndeplinească un SGBD pentru a fi declarat relaţional. Să amintim însă existenţa unui precursor: modelul bazat pe teoria mulţimilor, propus de D.L. Childs în articolul său: Feasability of a Set- Theoretical Data Structure", apărut în Cele mai importante prototipuri de sisteme de gestiune a bazelor de date de tip relaţional au fost: System R, dezvoltat la San Jose Research Laboratory din California spre sfârşitul anilor '70. Acest model a condus la: 8 E.F. Codd s-a născut la 23 august 1923 în Portland, Marea Britanie, şi a murit în 18 aprilie 2003, în Florida. A făcut studii de matematică şi chimie la Oxford şi s-a mutat în Statele Unite, în 1948, pentru a lucra la IBM. A introdus termenul OLAP (OnLine Analytical Processing) şi a impus modelul relaţional; a avut, de asemenea, contribuţii în domeniul modelelor de calculabilitate prin lucrările sale privind automatele celulare. A obţinut de două ori Premiul Turing: în 1981 şi

27 o apariţia unui limbaj structurat de interogare a bazelor de date: SQL. o producerea mai multor SGBD-uri relaţionale comerciale: DB2 şi SQL/DS de la IBM şi, respectiv, ORACLE de la Oracle Corporation (în deceniul 9 al secolului trecut). INGRES (Interactive Graphics Retrival System), dezvoltat la Universitatea Berkeley din California. Peterlee Relaţional Test Vehicle, dezvoltat la IBM UK Centre din Peterlee, Marea Britanie. Numărul sistemelor relaţionale comerciale a ajuns acum la câteva sute, dintre care cele mai cunoscute sunt: DB2 (de la IBM), Ingres II (de la Computer Associates International Inc.), Oracle 10g (de la Oracle Corporation), Ms Access, FoxPro (de la Microsoft), Paradox, Visual dbase (de la Borland), Sybase Adapted Server (de la Sybase Inc.). Succesul acestui model continuă să fie atât de mare încât multe sisteme nerelaţionale oferă acum şi o interfaţă cu utilizatorii de tip relaţional, indiferent de modelul de date pe care se bazează de fapt. Informal putem defini model relaţional de date ca pe un model în care: datele sunt percepute de utilizatori ca nişte tabele şi numai ca nişte tabele; operaţiile disponibile pentru utilizatori (spre exemplu, pentru obţinerea informaţiilor) sunt operaţii care generează noi tabele pe baza tabelelor vechi: operaţia de selecţie (SELECT) extrage o submulţime de rânduri dintr-o tabelă, operaţia de proiecţie (PROJECT) extrage o submulţime de coloane, operaţia de juxtapunere (JOIN) asociază două tabele pe baza valorilor identice pe care le conţin în anumite coloane, de asemenea identice; or, toate aceste submulţimi rezultate pot fi privite şi ele însele ca nişte tabele. Numele modelului relaţional provine de la conceptul matematic de relaţie. Aşa cum o funcţie f : {1, 2,...,n} N R are mai multe reprezentări convenţionale, dintre care cea mai comodă este cea de vector, tot astfel relaţia poate avea mai multe reprezentări, una dintre ele fiind tabela. Din acest motiv, cel puţin la nivel informal, termenii de relaţie şi tabelă pot fi consideraţi sinonimi. 31

28 1.4.5 Modelele postrelaţionale şi noi funcţionalităţi Chiar dacă se regăseşte în descrierea unor situaţii reale, cu organizare intrinsec piramidală, modelul ierarhic şi-a atins rapid limitele. La fel, modelul relaţional a devenit impropriu pentru rezolvarea unor probleme din realitatea înconjurătoare care presupun manipularea unor volume uriaşe de informaţie, a unei mari varietăţi de tipuri de date: hărţi meteorologice sau geografice necesare previziunilor meteorologice sau dirijării traficului, imagini transmise prin satelit utilizate în măsurarea factorilor poluanţi, date neconvenţionale pentru proiectarea asistată de calculator în inginerie sau arhitectură, serii dinamice implicate în tranzacţiile bursiere sau bancare, stocarea obiectelor binare mari (BLOBs = Binary Large Objects) necesare în digitalizarea informaţiei conţinută în fişierele audio sau video. Au apărut astfel şi s-au dezvoltat modelele postrelaţionale, de generaţia a treia: modelul orientat obiect şi modelul obiectrelaţional. Alături de acestea observăm noi funcţionalităţi ale bazelor de date: baze de date partajate în reţea, baze de date distribuite, baze de date deductive, depozite de date, baze de date multidimensionale. (I) Modelul orientat obiect permite înglobarea semanticii obiectelor celor mai variate, la fel ca în limbajele de programare orientate-obiect. De altfel, una dintre deosebirile majore faţă de modelul relaţional constă în distanţarea de conceptul de independenţă faţă de limbajele de programare şi dezvoltarea conceptului de integrare a limbajelor de programare în sistemul de gestiune a bazei de date (invocarea unor funcţii C++ mai degrabă decât înglobarea unui limbaj special pentru interogarea datelor, ca de exemplu SQL). Acest fapt a fost determinat de: utilizarea aproape exclusivă a limbajelor de programare orientate-obiect pentru dezvoltarea aplicaţiilor software; includerea în aproape orice aplicaţie software a unei baze de date ca element fundamental al acesteia. Cele mai cunoscute prototipuri de baze de date orientate-obiect sunt: OPENOODB (de la Texas Instruments), IRIS (de la Hewlett Packard), iar ca variantă comercială: GEMSTONE/OPAL (de la GemStone Systems), VERSANT (de la Versant Object Technology). Deşi cu o cotă de piaţă semnificativ inferioară sistemului relaţional (150 milioane dolari faţă de 10 miliarde, numai în SUA în anul 1999), modelul orientat-obiect este creditat cu o creştere anuală extrem de rapidă: 50%. În ciuda caracterului intuitiv şi a altor avantaje evidente ale modelului orientat-obiect, modelul relaţional continuă să domine piaţa sistemelor de gestiune a bazelor de date. Motivele sunt numeroase: fundamentarea matematică riguroasă, simplitatea, volumul mare de date deja stocate după acest model şi costul enorm al migrării spre un model complet diferit. 32

29 (II) Modelul obiect-relaţional extinde modelul relaţional, oferind un set de tipuri de date mai bogat, şi include şi orientarea obiect. Se încearcă astfel combinarea avantajelor celor două abordări, cea relaţională şi cea orientatăobiect: atributele şi instanţele entităţilor pot avea tipuri complexe şi pot evita unele dintre restricţiile specifice modelului relaţional. De exemplu, în timp ce în modelul relaţional fiecare atribut trebuie să ia pentru fiecare instanţă a unei entităţi o valoare şi numai una din domeniul lui de definiţie, în acest model poate lua un sub-set de valori (de exemplu: pentru un angajat oarecare, atributul Telefon poate lua ca valori numărul telefonului fix de acasă şi de la serviciu, al telefonului mobil propriu şi de serviciu, dacă angajatul dispune de toate patru). Cel mai cunoscut exemplu: Informix Universal Server care combină tehnologiile relaţionale şi orientate obiect din două produse preexistente: Informix şi Illustra. Noi funcţionalităţi ale bazelor de date: a. baze de date partajate în reţea; în condiţiile lucrului în reţea este posibil să se stocheze baza de date pe un calculator ce are loc de server. Astfel toţi utilizatorii vor partaja între ei baza de date. Administratorul bazei de date are sarcini pe linia modelării datelor, a implementării bazei de date, definirii utilizatorilor şi a drepturilor de acces şi întreţinerea bazei de date. Drepturile de acces la nivel utilizator vizează operaţiile pe care acestea le pot realiza. b. baze de date distribuite; unităţile economice dispersate geografic sunt nevoite să acceseze baze de date care sunt distribuite. Lucrul într-o reţea de calculatoare permite distribuirea unei baze de date, din punct de vedere fizic, pe mai multe site-uri. Fiecare site găzduieşte un sistem local de gestiune a bazelor de date. Utilizatorii unui site au acces la bază de date locală şi, în plus, la bazele de date distribuite în celelalte site-uri. Conexiunile inter-site-uri pot fi stabilite într-o manieră diversă. c. baze de date deductive; acest gen de baze de date se fundamentează cuplarea unei baze de date relaţionale cu un procesor din clasa sistemelor expert. d. depozite de date (datawarehouse); un depozit de date reprezintă un sistem de baze de date 1) ce acoperă un sistem temporal mai mare; 2) ce conţine date interne şi externe; 3) optimizat pentru a răspunde interogărilor complexe (de la manageri la analişti). e. baze de date multidimensionale; acest gen de baze de date au apărut ca urmare a necesităţilor crescânde de procesare multidimensională a datelor. Aplicaţiile care se bazează pe analiza multidimensională a datelor sunt cunoscute sub numele de OLAP (On Line Analytical Processing 9 ) 9 Se face distincție între:- OLTP (On-Line Transactional Processing) care privilegiază: integritatea și securitatea datelor și tratarea cererilor informaționale simple de către servicii operaționale (producție, comercial, resurse umane).și OLAP, care privilegiază analiza și manipularea datelor (folosind cereri complexe) în vederea elaborării stategiei și sunt destinate îndeosebi conducerii și controlului de gestiune. 33

30 1.5 Rezumatul capitolului A proiecta o bază de date înseamnă a-i stabili structura, adică elementele componente, caracteristicile acestora, restricţiile pe care trebuie să le respecte, relaţiile dintre ele. A construi o bază de date înseamnă a memora (a introduce) datele în baza de date, după proiectarea acesteia. A administra o bază de date înseamnă a asigura: (1) accesul la date al utilizatorilor, în funcţie de drepturile fiecăruia (funcţia şi importanţa fiecăruia în organizaţia respectivă), (2) coerenţa bazei de date (recuperarea informaţiei atunci când au loc incidente: întreruperea alimentării cu curent electric, operaţii contradictorii etc), (3) securitatea datelor stocate etc. A interoga o bază de date înseamnă a extrage şi a vizualiza datele care îndeplinesc anumite criterii şi condiţii. A actualiza o bază de date înseamnă a modifica structura sau informaţiile stocate în baza de date. Sistemul de gestiune al bazei de date (SGBD) reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activităţi: - definirea structurii bazei de date; - încărcarea datelor în baza de date; - accesul la date (interogare, actualizare); - întreţinerea bazei de date (colectarea şi refolosirea spaţiilor goale, refacerea bazei de date în cazul unui incident); - reorganizarea bazei de date (restructurarea şi modificarea strategiei de acces). SGBDR se defineşte ca fiind un sistem de gestiune care utilizează organizarea datelor conform modelului relaţional. 34

31 1.6 Întrebări de auto-evaluare 1) Explicaţi conceptul de bază de date. 2) Definiţi sistemul de gestiune al bazelor de date şi daţi exemple. 3) Enumeraţi obiectivele unui SGBD. 4) Enumeraţi funcţiile unui SGBD. Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns: 5) Un model de date este: a. mecanismul care asigură partajarea datelor dintr-o bază de date între aplicaţiile care o accesează. b. tehnica prin care pot fi organizate informaţiile într-o întreprindere. 6) Modelul ierarhic şi modelul reţea sunt: a) modele relaţionale; b) modele prerelaţionale; c) modele hibride. 7) Asociaţi fiecare tip de model de date cu conceptul teoretic pe care se bazează: Model Ierarhic Reţea Relaţional Concept Relaţie Arbore Graf 35

32 36

33 CAPITOLUL 2 PROIECTAREA ŞI IMPLEMENTAREA BAZELOR DE DATE 2.1 Arhitectura ANSI-SPARC Asigurarea independenţei fizice şi logice a datelor impune adoptarea unei arhitecturi organizată pe cel puţin 3 nivele (arhitectura ANSI-SPARC 10 ): 1. nivelul intern (baza de date fizică) 2. nivelul conceptual 3. nivelul extern Obiectivul arhitecturii cu 3 nivele este separarea vederii fiecărui utilizator asupra bazei de date de modul în care este ea reprezentată fizic (figura 2.1). Figura 2.1 Arhitectura ANSI-SPARC pe trei nivele pentru bazele de date 10 ANSI = American National Standards Institute SPARC = Standards Planning and Requirements Committee 37

34 Nivelul intern (baza de date fizică) este o colecţie de fişiere conţinând datele fizice la care se adaugă diverse structuri auxiliare menite să asigure accesul operativ la date. Structurile auxiliare pot fi: directoare, indexi, pointeri, tabele de dispersie. Modul de organizare a bazei de date fizice este în mare măsură influenţat de configuraţia echipamentelor hardware care suportă baza de date şi de sistemul de operare. Schimbarea sistemului de operare sau modificări în configuraţia hardware pot atrage modificări ale bazei de date fizice. Dacă este satisfăcută condiţia de independenţă fizică, aceste modificări în nivelul intern al bazei de date nu vor ataca nivelele superioare ale acesteia. Nivelul intern tratează chestiuni cum ar fi: alocarea spaţiului de stocare pentru date şi indexi ; descrierea înregistrărilor pentru stocare (cu dimensiunile de stocare pentru date) ; plasarea înregistrărilor ; tehnici de comprimare a datelor şi de codificare a acestora. Nivelul conceptual conţine structura logică a bazei de date, aşa cum este ea văzută de administratorul bazei de date. Fiecare bază de date are un model conceptual propriu prin care sunt numite şi descrise toate entităţile logice din baza de date împreună cu legăturile dintre acestea. El reprezintă o imagine completă a cerinţelor organizaţiei privind datele. Ex: în descrierea bazei de date a unei întreprinderi pot apărea concepte ca: angajat, produse, furnizor, beneficiar, etc. Nivelul conceptual integrează viziunile tuturor utilizatorilor asupra bazei de date, fiind rezultatul unui compromis între cerinţele diferiţilor utilizatori. Nivelul conceptual reprezintă: toate entităţile, atributele şi relaţiile dintre ele; constrângeri asupra datelor; informaţii semnatice asupra datelor; informaţii privind securitatea şi integritatea. De reţinut că nivelul conceptual este o descriere a conţinutului de date din baza de date şi NU cuprinde nici un fel de referire la modul de memorare a datelor sau la strategia de acces. De ex. descrierea unei entităţi trebuie să conţină numai tipurile de date (integer, real, character) şi lungimea lor (numărul maxim de cifre sau caractere), dar nici o informaţie privind stocarea, cum ar fi numărul de octeţi ocupat. Nivelul extern este cel mai apropiat utilizatorului. Este ceea ce vede acesta din baza de date, sau modul cum vede acesta baza de date. Nivelul extern este derivat din cel conceptual dar poate prezenta deosebiri substanţiale faţă de acesta. Un termen deseori folosit pentru modelul extern este acela de vedere sau 38

35 viziune. Prin aceste viziuni, utilizatorii au acces doar la părţi bine definite din baza de date, fiindu-le ascunse părţile care nu interesează. Prin modelul extern se realizează independenţa logică a datelor. Fiecărei viziuni îi corespunde o descriere în termenii entităţilor logice din modelul conceptual. Diferite vederi pot avea reprezentări diferite ale aceloraşi date. De ex, un utilizator poate vedea datele calendaristice în format an-lună-zi, altul le poate vedea ca zi-lună-an.vederile pot include chiar date combinate sau derivate din entităţi diferite. 2.2 Proiectarea bazelor de date Proiectarea unei baze de date= procesul de creare a unui proiect pentru baza de date care să asigure desfășurarea corectă a activităților și rezolvarea cerințelor utilizatorilor. Realizarea unei baze de date se desfăşoară în mai multe etape; cele mai importante sunt: (1) analiza, (2) proiectarea şi (3) implementarea. (1) în etapa de analiză se examinează în mod sistematic şi aprofundat acel aspect al lumii reale care trebuie transpus într-o bază de date: o tipografie, magazin universal, organizarea unei expoziţii etc; se stabilesc gradul de generalitate, dimensiunea bazei de date, categoriile şi numărul de viitori utilizatori. O bază de date trebuie să conducă la ameliorarea activităţii din organizaţia respectivă şi se realizează la cererea proprietarului. (2) Etapa de proiectare se poate descompune în trei subetape: 2a) proiectarea bazei de date la nivel conceptual, 2b) proiectarea bazei de date la nivel logic şi 2c) proiectarea bazei de date la nivel fizic. În această etapă se poate selecta sistemul de gestiune a bazei de date, se proiectează interfeţele şi aplicaţiile de utilizare şi administrare a bazei de date. (3) Etapa de implementare constă din realizarea propriu-zisă a bazei de date: scrierea programelor, conversia şi încărcarea datelor. 39

36 Principalele scopuri ale etapei de proiectare sunt: reprezentarea datelor şi a relaţiilor dintre date, conform cerinţelor formulate de utilizatori şi condiţiilor impuse de programele de calculator; furnizarea unui model de date care să asigure orice tip de prelucrare a datelor; schiţarea unui proiect astfel structurat încât să satisfacă parametrii de eficienţă specificaţi (de exemplu: obţinerea datelor solicitate într-un interval de timp cel mult egal cu o valoare prestabilită). Proiectarea bazei de date se poate face prin metoda: bottom-up: se începe cu stabilirea atributelor şi - prin analiza asocierilor dintre ele - se obţin entităţile şi relaţiile dintre entităţi; top-down: se dezvoltă un model de date constând din câteva entităţi şi relaţii foarte generale. Apoi, modelul este rafinat, obţinându-se modele din ce în ce mai detaliate; mixtă: se combină şi se iterează metodele de mai sus. 2.3 Utilizarea modelelor de date în etapa de proiectare Indiferent de metoda de proiectare folosită, identificarea entităţilor şi a relaţiilor dintre ele necesită: înţelegerea semnificaţiei datelor care circulă în organizaţia respectivă; înţelegerea cerinţelor specifice modului de lucru din organizaţie; reprezentarea coerentă şi sugestivă a acestor informaţii. Candance Fleming şi Barbara von Halle (1989) au identificat câteva criterii pe care ar trebui să le îndeplinească un model de date pentru a fi considerat optim în raport cu realitatea modelată: corectitudine, simplitate, expresivitate, neredundanţă, extensibilitate, integritate. 40

37 Figura 2.2 Succesiunea fazelor în modelarea bazelor de date Instrumentul universal capabil să asigure realizarea acestor obiective printr-o bună comunicare între specialiştii care proiectează baza de date şi viitorii utilizatori ai acesteia este modelarea datelor. Modelul de date de nivel înalt cel mai frecvent folosit este modelul entitate-relaţie (Entity-Relationship Model), iar cea mai larg utilizată reprezentare grafică a acestuia (asupra căreia vom reveni în capitolul următor) este diagrama entitate-relaţie (figura 2.3). Figura 2.3 Diagrama entitate-relaţie a bazei de date a unei facultăţi 41

38 2.4 Modelul conceptual al bazei de date Proiectarea bazei de date la nivel conceptual = procesul de construire a unui model privind informaţiile care circulă într-o organizaţie, independent de orice implementare a acestora la nivel fizic. Proiectarea schemei conceptuale a bazei de date constituie prima fază a proiectării şi conduce la realizarea modelului conceptual. Acest model este complet independent de orice detalii de implementare: ce SGBD, ce programe de aplicaţie (scrise în ce limbaj de programare) se vor folosi, pe ce platformă hardware şi sub ce sistem de operare. Această fază a proiectării bazei de date se desfăşoară iterativ: fiecare variantă a modelului este testată în raport cu cerinţele utilizatorilor (condiţiile sau restricţiile formulate de aceştia) pentru a verifica adecvarea modelului de date la situaţia reală modelată. De exemplu, pentru domeniul comercial schema conceptuală va conţine următoarele colecţii de date: agenţi comerciali, clienţi (beneficiari), furnizori, produse finite, materii prime, comenzi de produse finite, comenzi pentru aprovizionarea cu materii prime, facturi, înregistrări contabile în contul furnizori şi de clienţi. 2.5 Modelul logic al bazei de date Proiectarea baze de date la nivel logic = procesul de construire a unui model privind informaţiile care circulă într-o organizaţie pe baza unui model conceptual independent de alegerea unui SGBD, precum şi de orice detalii de implementare la nivel fizic. Proiectarea logică a bazei de date este a doua fază a proiectării şi conduce la realizarea modelului logic. întrucât porneşte obligatoriu de la modelul conceptual, deci se bazează implicit pe un anumit tip de model de date - relaţional, ierarhic, orientat-obiect etc, modelul logic orientează proiectul bazei de date spre un anumit tip de SGBD - relaţional, ierarhic etc, fără a alege, spre exemplu, între MS Access şi Oracle. În continuare, detaliile de implementare fizică - 42

39 precum modul de stocare a datelor, tipurile de indexare etc. - sunt complet ignorate. Pe parcursul acestei etape, modelul este permanent testat şi validat, cu ajutorul datorilor, pentru a descoperi eventualele neconcordanţe cu restricţiile formulate de aceştia. Tehnica folosită se numeşte normalizare şi urmăreşte asigurarea corectitudinii modelului logic (de exemplu, prin eliminarea redundanţelor în date, redudanţe care - o dată implementate - pot genera erori în timpul operaţiilor de actualizare a bazei). Proiectarea conceptuală şi proiectarea logică a bazei de date sunt etape foarte importante, critice, pentru realizarea unui proiect bun al bazei de date. Dacă unul dintre ele nu reprezintă corect aspectul modelat, implementarea fizică a bazei de date va fi eronată şi corectarea ulterioară aproape imposibilă. De aceea, rafinarea modelului conceptual şi a celui logic este un proces iterativ, virtual infinit. 2.6 Modelul fizic al bazei de date Proiectarea baze de date la nivel fizic = procesul de construire a unei specificaţii privind memorarea datelor din baza de date pe suporturile fizice de memorie; sunt descrise: structura memoriei și metodele de accesare menite să asigure accesul eficient la informaţii. Proiectarea fizică a bazei de date este ultima fază a proiectării, cea în care proiectantul alege modul concret de implementare a bazei de date. Prima operaţie constă în alegerea unui SGBD care să poată implementa modelul logic. Urmează comunicarea între modelul fizic şi cel logic, similară celei dintre modelul logic şi cel conceptual: orice decizie privind implementarea fizică (ameliorarea performanţelor, asigurarea securităţii etc.) poate afecta structura modelului logic. Cu toate acestea, modelul conceptual şi modelul logic trebuie să fie în continuare complet separate de modelul fizic al bazei de date şi fiecare trebuie să-şi păstreze scopul: primele să răspundă la întrebarea: CE trebuie făcut"; ultimul la: CUM trebuie făcut". Această abordare a proiectării bazelor de date este compatibilă cu arhitectura pe trei nivele a acestora, aşa cum a fost ea stabilită de ANSI-SPARC în Figura 2.4 prezintă modelarea datelor şi arhitectura ANSI-SPARC. 43

40 44 Figura 2.4 Modelarea datelor şi arhitectura ANSI-SPARC.

41 2.7 Rezumatul capitolului Asigurarea independenţei fizice şi logice a datelor impune adoptarea unei arhitecturi organizată pe cel puţin 3 nivele (arhitectura ANSI-SPARC):. nivelul intern (baza de date fizică); nivelul conceptual şi nivelul extern. Nivelul intern (baza de date fizică) este o colecţie de fişiere conţinând datele fizice la care se adaugă diverse structuri auxiliare menite să asigure accesul operativ la date. Nivelul intern tratează chestiuni cum ar fi: alocarea spaţiului de stocare pentru date şi indexi ; descrierea înregistrărilor pentru stocare (cu dimensiunile de stocare pentru date) ; plasarea înregistrărilor ; tehnici de comprimare a datelor şi de codificare a acestora. Nivelul conceptual conţine structura logică a bazei de date, aşa cum este ea văzută de administratorul bazei de date. Fiecare bază de date are un model conceptual propriu prin care sunt numite şi descrise toate entităţile logice din baza de date împreună cu legăturile dintre acestea. Nivelul conceptual reprezintă: toate entităţile, atributele şi relaţiile dintre ele; constrângeri asupra datelor; informaţii semnatice asupra datelor; informaţii privind securitatea şi integritatea. Nivelul extern este cel mai apropiat utilizatorului. Prin modelul extern se realizează independenţa logică a datelor. Fiecărei viziuni îi corespunde o descriere în termenii entităţilor logice din modelul conceptual. Proiectarea unei baze de date este procesul de creare a unui proiect pentru baza de date care să asigure desfăşurarea corectă a activităţilor şi rezolvarea cerinţelor utilizatorilor. Realizarea unei baze de date se desfăşoară în mai multe etape; cele mai importante sunt: (1) analiza se examinează în mod sistematic şi aprofundat acel aspect al lumii reale care trebuie transpus într-o bază de date; (2) proiectarea, are 3 subetape: 2a) proiectarea bazei de date la nivel conceptual, 2b) proiectarea bazei de date la nivel logic şi 2c) proiectarea bazei de date la nivel fizic. În această etapă se poate selecta sistemul de gestiune a bazei de date, se proiectează interfeţele şi aplicaţiile de utilizare şi administrare a bazei de date. (3) implementarea: realizarea propriu-zisă a bazei de date. Proiectarea bazei de date se poate face prin metoda: bottom-up, top-down sau mixtă. 45

42 2.8 Întrebări de autoevaluare Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns: 1) Care este ordinea corectă a celor trei niveluri care compun arhitectura ANSI-SPARC pentru bazele de date: a) nivelul conceptual, nivelul intern, nivelul extern; b) nivelul conceptual, nivelul extern, nivelul intern; c) nivelul extern; nivelul conceptual, nivelul intern. 2) Proiectarea bazelor de date se poate face prin: a) metoda bottom-up; b) metoda top-down; c) combinarea şi iterarea metodelor bottom-up şi top-down. d) oricare dintre metodele de mai sus. 3) Un model de date optim îndeplineşte următoarele criterii: a) corectitudine, simplitate; b) expresivitate, neredundanţă; c) extensibilitate, integritate; d) toate cele de mai sus. 4) Care dintre cele trei modele ale unei baze de date: logic, conceptual, fizic, răspunde" la întrebarea: CE trebuie făcut? a) modelul logic şi modelul conceptual; b) modelul conceptual şi modelul fizic; c) modelul fizic şi modelul logic. 46

43 CAPITOLUL 3 MODELUL CONCEPTUAL AL BAZELOR DE DATE RELAŢIONALE Aşa cum am văzut în capitolul anterior, proiectarea unei baze de date începe cu analiza situaţiei reale care trebuie modelată prin baza de date. Această analiză necesită un dialog între proiectantul bazei de date şi viitorii ei utilizatori. Astfel, sunt puse în evidenţă: cerinţele utilizatorilor privind datele care trebuie stocate şi administrate; cerinţele utilizatorilor privind operaţiile care trebuie efectuate cu aceste date. Etapa următoare constă în realizarea modelului conceptual al bazei de date. în cazul modelului relaţional, se începe cu o descriere detaliată a entităţilor şi atributelor, a relaţiilor dintre entităţi şi a condiţiilor pe care trebuie să le îndeplinească. Această descriere poate fi fi reprezentată prin mai multe forme: schema conceptuală, diagrama entitate-relaţie (diagrama ER). 3.1 Entitaţi şi instanţe În literatura dedicată bazelor de date există mai multe definiţii pentru termenul entitate: Entitate = un lucru" sau un obiect" din lumea reală care poate fi distins (deosebit) de toate celelalte lucruri sau obiecte. Entitate = un obiect (un tablou etc), un eveniment (naşterea unei persoane etc), o activitate (închirierea unei maşini etc.) din lumea reală care poate fi descris(ă) prin racteristici bine definite (despre care există date care pot fi stocate). Trebuie să facem distincţie între conceptele de entitate şi instanţă a unei entităţi, istă distincţie este similară celei dintre tipul de dată şi valoare într-un limbaj programare. Prin entitate înţelegem mulţimea tuturor elementelor de un anumit tip (care prezintă aceleaşi caracteristici). Prin instanţă a unei entităţi înţelegem un singur element, bine individualizat, unic, din mulţimea elementelor care formează entitatea respectivă. 47

44 Exemplu: fiecare client al unei bănci este o instanţă a entităţii Clienţi; fiecare curs predat într-o facultate este o instanţă a entităţii CursuriUniversitare etc. OBSERVAŢII. O entitate poate avea subentităţi; acestea trebuie să fie disjuncte; de exemplu, entităţile Piloţi şi MecaniciDeBord sunt disjuncte şi sunt subentităţi ale entităţii PersonalNavigant. Într-o bază de date pot exista entităţi a căror existenţă este determinată de alte entităţi; primele se numesc entităţi dependente, celelalte se numesc entităţi principale (de exemplu, entitatea Persoaneînîntreţinere depinde de entitate Salariaţi). 3.2 Atribute Concept şi tipologie Atribut = o caracteristică a unei entităţi. Un atribut posedă un nume şi - pentru fiecare instanţă a entităţii - poate lua o valoare dintr-o mulţime fixată de valori, numită domeniul de valori ale atributului. Exemplu: Fie entitatea Ţări; considerăm atributele Nume, Continent, Capitală, Formă DeGuvernământ, Suprafaţă, SărbătoareNaţională. Tabelul 3.1 prezintă câteva instanţe ale acestei entităţi şi valorile luate de atribute. NumeŢară Continent Capitala Forma de Nr.km Sărbătoare guvernământ pătraţi naţională Slovacia Europa Bratislava Republică Sept. constituţională Franţa Europa Paris Republică Iul. prezidenţială România Europa Bucureşti Republică Dec. constituţională Japonia Asia Tokyo Monarhie Apr. constituţională SUA America de Nord Washington Republică prezidenţială Iul. Tabel 3.1. Instanţele entităţii Ţări şi valorile atributelor sale 48

45 Clasificarea atributelor A) Atributele se pot clasifica după complexitate: o atribute compuse; o şi atribute simple sau elementare, după cum ele se mai descompune sau nu în alte atribute, de mai mică complexitate. Există atribute nu pot fi decât simple (atributele Capitală, Suprafaţă, Continent ale entităţii Ţări). Există însă atribute care pot fi considerate fie simple, fie compuse. De exemplu atributul DataNaşterii cu valorile: 1 ianuarie 2000, 2 Mai 1990 etc. poate fi privit fie ca un atribut simplu, fie ca unul compus din atributele Zi, Lună, An. Este indicat să îl tratăm ca un atribut compus, dacă prevedem necesitatea de a avea acces direct la luna sau anul de naştere al unei persoane înregistrate în baza de date. Dacă însă o astfel de necesitate nu este probabilă şi dacă dorim să simplificăm structura entităţii (şi deci a bazei de date), atunci este preferabil să îl tratăm ca atribut simplu. B) Atributele se pot clasifica după mulţimea de valori în: o atribute cu valori unice; o şi atribute cu valori multiple, după cum ele pot lua câte o singură valoare (de exemplu, atributele Capitală, Suprafaţă, Continent ale entităţii Ţări) sau, dimpotrivă, pentru unele instanţe pot lua câte o singură valoare, pentru altele mai multe valori, iar pentru altele nici o valoare (de exemplu, atributul OraşCuMinimumlMilioane Locuitori al entităţii Ţări). Când este cazul se pot defini limite inferioare şi/sau superioare pentru numărul de valori pe care le poate lua un astfel de atribut pentru o instanţă oarecare (de exemplu, putem specifica faptul că atributul NrTelefon al entităţii Persoane poate lua minimum o valoare - telefonul de serviciu - şi maximum trei). C) Atributele se pot clasifica după stabilitate în: o atribute de bază; o şi atribute derivate, după cum ele au valori de sine stătătoare sau valori care pot fi calculate din valorile altor atribute. De exemplu, să considerăm entităţile corelate Cărţi, cu atributul NumărAutori - şi Autori, cu atributul Titlu; atributul NumărAutori este un atribut derivat: valorile pe care le ia pentru diferite instanţe ale entităţii Cărţi pot fi calculate pe baza numărului de apariţii ale atributului Titlu pentru diferite instanţe ale entităţii Autori. 49

46 3.2.2 Cheia primară, un atribut special Un atribut special îl reprezintă identificatorul unic. Utilizarea instanţelor unei entităţi ridică două probleme foarte importante: - modul de adresare a fiecărei instanţe a unei entităţi; - determinarea instanţelor care se repetă. Să presupunem că dispunem de o bază de date a trenurilor care circulă în România şi vrem să prelucrăm informaţiile legate de un rapid care leagă oraşul Timişoara de Cluj Napoca. Ca să ne referim la această instanţă Trenuri ar trebui să enumerăm toate valorile pe care le iau atributele entităţii. Dacă ar fi 5 sau 10 atribute nu ar fi prea greu; dar dacă ar fi 50? Pentru a simplifica referirea la instanţele unei entităţi s-a recurs la mecanismul identificatorului unic, adică al cheii primare. Cheia primară= un atribut sau cea mai mică mulţime de atribute ale unei entităţi care iau, fiecare instanţă a entităţii respective, o valoare şi numai una, sugestiv prin sensul figurat al cuvântului cheie. Atunci când niciun atribut sau pe atribute ale entităţii, rezonabil de numeros, nu iau valori distincte pentru fiecare instanţă a acesteia, se poate adăuga un atribut convenţional" care să îndeplinească această condiţie. De obicei, acest atribut este denumit cu ajutorul prefixelor cod sau id. Exemple: 1) pentru entităţi precum Studenţi, Profesori, Angajaţi un exemplu de identificator unic este codul numeric personal; un contraexemplu: numele (chiar însoţit de prenume) sau data naşterii. Se poate utiliza şi atributul convenţional CodStudent (CodProfesor etc), cu valori formate din iniţialele numelui şi prenumelui, urmate de numere distincte formate din 2 sau 3 cifre. 2) Pentru entitatea Comenzi putem folosi un atribut convenţional (de exemplu: CodComandă, cu valori numere distincte) sau putem folosi trei atribute ale sale: NumeFurnizor, NumeClient, DataEmiterii. În alte situaţii, identificatorul unic este compus dintr-o combinaţie de două sau mai multe atribute (identificator unic compus). De exemplu combinaţia dintre titlu, numele autorului şi data apariţiei poate forma unicul identificator al 50

47 entităţii CARTE. Oare combinaţia titlu şi nume autor nu era suficientă? Răspunsul este NU, deoarece pot exista de exemplu mai multe volume scrise de Mihai Eminescu având toate titlul Poezii, dar apărute la date diferite. O entitate (de exemplu: Angajaţi, având atributele Nume, IniţialaTatălui, Prenume, Adresă, Funcţie, CodDepartament, Salariu, DataAngajării) poate avea mai multe atribute care pot juca rolul de identificator unic; de exemplu: Nume, Prenume, Adresă; Nume, Prenume, IniţialaTatălui, Adresă; Nume, Prenume, Funcţie, CodDepartament; Nume, Prenume, Adresă, Funcţie, CodDepartament. Toate aceste combinaţii de atribute se numesc chei candidate. Prima combinaţie îndeplineşte condiţia de minimalitate (pe care a doua nu o poate satisface). Ca atare, dintre cele două, numai aceasta poate constitui un identificator unic sau o cheie primară pentru entitatea Angajaţi, în timp ce a doua este numai o cheie candidat. Acelaşi lucru este valabil şi pentru a treia şi a patra combinaţie de atribute, ca şi pentru prima şi a patra combinaţie de atribute. La alegerea cheia candidate ţinem cont de următoarele: compusă din cel mai mic număr de atribute; compusă din atribute ale căror valori nu sunt susceptibile de modificări în viitor; care nu este susceptibilă să-şi piardă unicitatea în viitor; care are valorile cele mai mici (cuvintele cele mai scurte, numerele cu cel mai mic număr de cifre etc); care este cel mai uşor de utilizat Entitate sau atribut Suntem adeseori confruntaţi cu problema: fiind dată o informaţie care trebuie inclusă în baza de date, cum o modelăm ca entitate sau ca atribut al unei entităţi deja existente? De exemplu adresa unui cadru didactic ar trebui să fie un atribut al entităţii CadruDidactic sau o entitate (corelată cu entitatea CadruDidactic)? Răspunsul depinde de: semantica (semnificaţia, înţelesul) datelor, modul în care vom utiliza informaţia respectivă. În exemplul nostru, adresa va fi modelată ca entitate în oricare dintre următoarele cazuri: 51

48 o cadrul didactic are mai multe adrese. Motivul: într-o bază de date corect proiectată (normalizată) un atribut nu poate lua simultan mai multe valori pentru aceeaşi instanţă a unei entităţi; o structura adresei (localitate, stradă, sectorul/judeţul etc.) este importantă ( exemplu, trebuie să extragem din baza de date cadrele didactice care loc iese într-o anumită localitate sau într-un anumit sector din Bucureşti). Motivul: valorile atributelor sunt atomice. Este indicată modelarea prin atribut în oricare dintre situaţiile complementare (o singură adresă, tratarea adresei ca un tot unitar). 52

49 3.3 Relaţii Definiţie Ori de câte ori un atribut al unei entităţi se referă la altă entitate din baza de date se stabileşte, de fapt, o relaţie între cele două entităţi (de exemplu, atributul Destinaţie al entităţii Trenuri se referă la oraşul către care circulă un tren, indicând astfel o relaţie între entitatea Trenuri şi entitatea Oraşe). Când proiectăm baza de date, aceste referiri nu ar trebui să fie reprezentate ca atribute ale entităţilor, ci ca relaţii (atât în sensul real, cât şi în sensul matematic al cuvântului) între entităţi. Atributele prin care se stabileşte această relaţie se numesc chei sau câmpuri de legătură. Relaţie într-o bază de date = o legătură logică între două sau mai multe entităţi Gradul şi cardinalitatea relaţiilor Relaţiile sunt caracterizate prin grad şi cardinalitate (sau tip). Gradul unei relații = numărul de entităţi care participă la relaţia respectivă După grad, relaţiile pot fi: grad binar (între două entităţi; de exemplu: relaţia Joacăîn este o relaţie binară între entităţile Actori şi Filme); grad de tip n (între mai multe entităţi; de exemplu: relaţia Montează este o relaţie de gradul cinci între entităţile Regizori, Scenografi, DesigneriCostume, Actori şi PieseDeTeatru). Cardinalitatea (tipul) unei relaţii binare = numărul de instanţe ale celor două entităţi care sunt asociate prin relaţia respectivă. Să considerăm două entităţi E 1 şi E 2 ; după cardinalitate (sau tip), relaţiile dintre cele două entităţi pot fi : o 1-1 (one-to-one): o relaţie între două entităţi E 1 şi E 2 în care unei instanţe a entităţii E 1 îi corespunde o singura instanţă din entitatea E 2 şi reciproc. o 1 - m (one-to-many): o relaţie între două entităţi E 1 şi E 2 în care unei instanţe a entităţii E 1 (numită entitate dominantă) îi pot corespunde mai multe instanţe din entitatea E 2 (dar unei instanţe din E 2 nu-i poate corespunde decât cel mult o instanţă din E 1 ). 53

50 o n - m (many-to-many): o relaţie între două entităţi E 1 şi E 2 în care unei instanţe a entităţii E 1 îi pot corespunde mai multe instanţe din entitatea E 2 şi, reciproc, unei instanţe din entitatea E 2 îi pot corespunde mai multe instanţe din entitatea E 1. În baza de date a facultăţii putem avea următoarele tipuri de relaţii: 1-1: un student are o singură foaie matricolă (în care sunt înregistrate notele sale); o foaie matricolă aparţine unui singur student; 1-m: un student participă la mai multe cursuri opţionale; un curs pentru un student; m-m: un profesor predă la mai mulţi ani de studiu; la un an de studiu predau mai mulţi profesori. 3.4 Schema conceptuală şi diagrama entitate-relaţie Aşa cum am descris anterior, primul pas în realizarea unei aplicaţii de baze de date este analiza datelor şi realizarea unei scheme conceptuale (model conceptual) al acestor date. În această etapă sunt analizate natura şi modul de utilizare a datelor. Sunt identificate datele care vor trebui memorate şi procesate, se împart aceste date în grupuri logice şi se identifică relaţiile care există între aceste grupuri. Analiza datelor este un proces uneori dificil, care necesită mult timp, însă este o etapă absolut obligatorie. Fără o analiză atentă a datelor şi a modului de utilizare a acestora, vom realiza o bază de date care putem constata în final că nu întruneşte cerinţele beneficiarului. Informaţiile necesare realizării modelului conceptual se obţin folosind metode convenţionale precum intervievarea oamenilor din cadrul organizaţiei şi studierea documentelor folosite. Odată obţinute aceste informaţii ele trebuiesc reprezentate într-o formă convenţională care să poată fi uşor înţeleasă de toată lumea. O astfel de reprezentare este diagrama entitate-relaţie 11, numită şi harta relaţiilor, sau ERD-ul (Entity Relationship Diagram). Aceste scheme sunt un instrument util care uşurează comunicarea dintre specialiştii care proiectează bazele de date şi programatori pe de o parte şi beneficiari, pe de altă parte. Aceştia din urmă pot înţelege cu uşurinţă o astfel de schemă, chiar dacă nu sunt cunoscători în domeniul IT. Schema conceptuală a unei baze de date este o descriere de forma Cheile primare sunt atribute subliniate. nume_entitate={listă de atribute}. 11 Modelul entitate-relație a fost descries de Chen în 1976 și perfecționat ulterior. 54

51 Tabelul 3.2 şi Tabelul 3.3 prezintă convenţiile de reprezentare grafică (în diagramele ER) a entităţilor, atributelor şi relaţiilor din modelul conceptual al unei baze de date relaţionale. Observaţie. Entităţile şi atributele sunt denumite prin substantive; relaţiile dintre entităţi sunt denumite prin verbe precedate sau urmate de prepoziţii; există situaţii în care ordinea entităţilor aflate în relaţie este importantă (atunci avem, de fapt, două relaţii care trebuie citite de la stânga la dreapta, respectiv de la dreapta la stânga) şi situaţii în care ordinea nu este importantă. Numele date entităţilor, respectiv relaţiilor, trebuie să fie unice la nivelul bazei de date. Numele atributelor trebuie să fie unice numai la nivelul aceleiaşi entităţi; eventualele confuzii la nivelul bazei de date se rezolvă prin cuplarea numelui atributului cu numele entităţii. Este totuşi indicat- pentru simplificarea referirilor- ca numele atributelor care constituie cheile primare să fie unice la nivelul bazei de date. Reprezentare grafică Entitate principală dreptunghi simplu Entitate dependentă dreptunghi dublu Atribut elipsă Atribut cu valori multiple elipsă dublă Atribut derivat elipsă punctată Cheie primară elipsă şi subliniere cu linie continuă Cheie externă elipsă şi subliniere cu linie punctată Relaţie romb Tabelul 3.2. Un set de convenţii pentru diagrama entitate-relaţie Reprezentare grafică Entitate principală dreptunghi cu colţurile rotunjite Atribut obligatoriu asterisc Atribut opţional cerc Cheie primară diez Relaţie Linii cu sau fără bifurcaţii Tabelul 3.3. Un alt set de convenţii pentru diagrama entitate-relaţie În figura 3.1 este prezentată schema conceptuală şi diagramele entitate-relaţie (conform convenţiilor de mai sus) pentru baza de date a unei companii cinematografice care deţine mai multe studiouri unde se produc filme în care joacă actori. Actori={IdActor, Nume, Prenume}; Studiouri={Nume, Adresa}; Filme={Titlu, An, Buget, Tip} 55

52 Figura 3.1 Diagrama entitate-relaţie În concluzie putem sublinia câteva caracteristici ale ERD-urilor: - sunt un instrument de proiectare ; - sunt o reprezentare grafică a unui sistem de date ; - oferă un model conceptual de înalt nivel al bazelor de date ; - sprijină înţelegerea de către utilizatori a datelor şi a relaţiilor dintre acestea ; - sunt independente de implementare. 56

53 3.5 Modelul relaţional: fundamentarea teoretică Concepte de bază Modelul relaţional a fost fundamentat în anul de E.F.Codd ş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 13, care constituie o parte a teoriei mulţimilor. Noţiunile fundamentale ale modelului relaţional sunt: relaţie, domeniu, atribut, tuplu şi schemă relaţională. Conceptul matematic aflat la baza modelului relaţional al bazelor de date este cel de relaţie: Se numeşte relaţie peste mulţimile M 1, M 2,...M n orice submulţime a produsului lor cartezian: R M 1 x M 2 x... x M n Fie mulţimile Marca = {Dacia, Ford, Fiat, Audi, Opel, Volvo}, Tip = {benzină, motorină}, CapacCil = {1100, 1200, 1300, 1400, 1600}, NrLoc = {4,5}, NrUşi = {2, 4, 5}. Atunci, entitatea Automobil poate fi reprezentată ca o relaţie peste aceste mulţimi: Automobil Marca x Tip x CapacCil x NrLoc x NrUşi Iată câteva instanţe ale acestei entităţi: (Dacia, benzină, 1400, 5, 4), (Dacia, motorină, 1400, 5, 4), (Dacia, benzină, 1100, 5, 4), (Dacia, motorină, 1400, 5. 5), (Ford, motorină, 1400, 5, 5), (Ford, benzină, 1600, 5, 4), (Fiat, benzină. 1300, 5, 4), (Fiat, benzină, 1100, 5,4), (Audi, motorină, 1600, 5, 4), (Opel, benzină, 1400, 5, 5), (Volvo, benzină, 1400, 5, 5), (Volvo, motorină, 1600, 5, 4). Generalizând exemplul de mai sus, obţinem: E A 1 x A 2 x... x A n unde am notat cu E entitatea şi cu A 1, A 2,...A n mulţimile de valori (domeniile) ale atributelor sale. Un element al acestei relaţii (adică un tuplu al produsului cartezian) reprezintă o instanţă e i a entităţii E şi constă din valori particulare ale atributelor). 12 Ideea îi aparţine lui D.F.Childs care a publicat în 1968 o lucrare în care a arătat că orice structură de date poate fi reprezentată sub formă de tabele în interiorul căreia trebuie să existe şi informaţie de legătură (Lungu, et al, 1995). 13 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. 57

54 Pentru simplitatea reprezentării, entităţile nu sunt reprezentate ca mulţimi de tupluri (ca în exemplul nostru de mai sus), ci ca tabele (tabelul 3.4), tot aşa cum în loc să notăm cu <(3,5) instanţa relaţiei de ordine < NXN dintre naturale 3 şi 5, scriem 3 < 5. Marca Tip CapacCil NrLoc NrUşi Dacia benzină Dacia motorină Dacia benzină Dacia motorină Ford motorină Ford benzină Fiat benzină Fiat benzină Audi motorină Opel benzină Volvo benzină Volvo motorină Tabelul 3.4 Instanţe ale entităţii Automobil Puterea şi eleganţa modelului relaţional sunt date de faptul că relaţiile dintre entităţi conduc la asocieri ce pot fi reprezentate tot prin tabele. Conform modelului relaţional avem următoarele: o Orice entitate este reprezentată printr-o tabelă; numele entităţii devine numele tabelei. o Oricărui atribut al unei entităţi îi corespunde o coloană (numită şi câmp) în tabela corespunzătoare entităţii; numele atributului devine antetul coloanei respective din tabelă. o Orice instanţă a unei entităţi este reprezentată printr-un rând în tabelă asociată entităţii, numit înregistrare; fiecare celulă din înregistrare conţine valoarea luată de atributul corespunzător pentru instanţa respectivă. 58

55 3.5.2 Stabilirea relaţiilor între entităţi La nivelul modelului conceptual, cardinalitatea relaţiilor este o caracteristică intrinsecă a acestora; când proiectăm baza de date, relaţiile dintre entităţi trebuie definite în mod efectiv. Acest lucru se realizează în mod diferit pentru fiecare tip de relaţie. Fie două entităţi U şi V şi fie T 1 şi T 2 tabelele prin care sunt reprezentate (conform convenţiilor din paragraful 3.4). Pentru simplitate, vom presupune că entităţile aflate în relaţie sunt identificate prin chei primare formate dintr-un singur atribut. Relaţii 1-1 Să presupunem că proiectăm baza de date a unei policlinici. În fiecare cabinet lucrează un singur medic şi o singură asistentă. Este evident că (din punctul de vedere al ocupării cabinetelor, al lucrului în echipă) cele două entităţi, Medici şi Asistente, se află în relaţia 1-1. Pentru a stabili o relaţie (numită LucreazăCu) de 1-1 între entităţile Medici şi Asistente vom utiliza acelaşi atribut pe post de cheie primară (aici atributul CodCabinet). Figura 3.2. O relaţie 1-1 Figura 3.3. Implementarea unei relaţii 1-1 în MS Access 59

56 Relaţii 1-m Fie două entităţi U şi V (de exemplu: Pacienţi şi Programări) având atributele a 1, (cheie primară), a 2,..., a n şi respectiv b 1 (cheie primară), b 2,..., b m, ap (de exemplu: codpacient, numepren, datanaşterii, adresa, telefon, nrserieci, CNP, respectiv nrprogramare, dataprogramare, oraprogramare, codpacient). Prin cheie externă înţelegem un atribut al entităţii V a cărui mulţime de valori coincide cu mulţimea valorilor cheii primare din entitatea U (aici: atributul codpacient este cheie primară pentru entitatea Pacienţi şi cheie externă pentru entitatea Programări). Figura 3.4. O relaţie 1-m Observaţii: Figura 3.5. Implementarea unei relaţii 1-m în MS Access În diagrama entitate-relaţie, cheile externe se reprezintă la fel ca şi cheile primare, dar sublinierea se face punctat. Observăm că în timp ce, la nivelul entităţii U, valorile luate de atributul a1 sunt unice (el fiind cheie primară), la nivelul entităţii V valorile luate de atributul a1 pot fi duplicate (el fiind cheie externă). Din punctul de vedere al relaţiei 1-m dintre entităţile U şi V, entitatea U poate fi privită drept entitate principală, iar entitatea V drept entitate secundară. 60

57 Pentru a stabili o relaţie (numită Areprogramare) de 1-m între entităţile Pacienţi şi Programări procedăm astfel: 1. includem în descrierea ambelor entităţi un acelaşi atribut (aici: CodPacient); 2. definim acest atribut drept cheie primară pentru entitatea principală şi cheie externă pentru entitatea secundară. Relaţii n-m În acest caz, ne bazăm pe faptul că în modelul relaţional nu numai entităţile, ci şi relaţiile dintre ele sunt relaţii în sens matematic şi, ca urmare, pot fi reprezentate prin tabele. Să considerăm baza de date a unei facultăţi care conţine cel puţin entităţile Curs (IdCurs, denumire) şi Student (NrMatricol, nume, prenume, grupa). Evident un student poate să se înscrie la mai multe cursuri, iar la un curs pot participa mai mulţi studenţi.avem de-a face cu o relaţie n-m, numită CerereŞiOfertă. Pentru a o relaţie n-m între două entităţi (aici CerereŞiOfertă între entităţile Curs şi Student) procedăm astfel: 1. identificăm cheile externe - două atribute care să corespundă atributelor care funcţionează drept chei primare pentru cele două entităţi (aici: IdCurs şi NrMatricol); 2. definim o entitate nouă, CursStudent descrisă prin cele două atribute; această entitate este numită si entitate intersecţie. 3. reducem astfel stabilirea unei relaţii n-m (aici: relaţia dintre Curs şi Student) la stabilirea a două relaţii 1-m (aici: relaţiile dintre Curs şi CursStudent, şi respectiv dintre Student şi CursStudent (figurile 3.6 şi 3.7). Observăm că singurele relaţii dintre entităţi care conduc la tabele intermediare sunt relaţiile de cardinalitate n-m. Tabela corespunzătoare trebuie să conţină cel puţin cheile externe necesare relaţionalii celor două entităţi; în acest caz, cheia primară a relaţiei este formată din cele două atribute; altfel: se poate adăuga relaţiei un alt atribut care va fi definit drept cheie primară a acesteia. Figura 3.6 prezintă diagrama entitate pentru o relaţie n-m, iar figura 3.7 prezintă implementarea acesteia în Access. 61

58 Figura 3.6. Diagrama entitate pentru o relaţie n-m Figura 3.7. Implementarea unei relaţii de tip n-m în Access 62

59 3.6 Reguli de integritate pentru bazele de date relaţionale După modelarea bazei de date la nivel structural (definirea entităţilor, atributelor lor şi a relaţiilor dintre ele), urmează nivelul operaţional al modelării: stabilirea tipurilor de operaţii care se pot efectua asupra datelor stocate (sortare, căutare, vizualizare, adăugare, ştergere, modificare etc.); verificarea respectării regulilor de integritate (ceea ce va asigura corectitudinea şi consistenţa datelor). Distingem următoarele tipuri de reguli de integritate: reguli de integritate a entităţilor; reguli de integritate a relaţiilor (numite şi reguli de integritate referenţială) La acestea se adaugă şi regulile de integritate impuse de situaţia reală modelată prin baza de date, numite restricţii procedurale Valoarea specială Null a atributelor Pentru a analiza regulile de integritate trebuie să analizăm situaţia unei valori speciale pe care o pot lua atributele entităţilor: valoarea Null. Null= valoarea pe care o ia un atribut pentru o instanţă a unei entităţi atunci când pentru respectiva instanţă: nu există o valoare (de exemplu, pentru entitatea Angajaţi, în cazul salariaţilor care nu sunt membri de sindicat, atributul Restanţă cotizaţie nu poate lua nici o valoare, deci i se atribuie valoarea Null. există o valoare dar nu a fost înregistrată (de exemplu, atributul SerieNrCI), nu ştim dacă există sau nu o valoare (de exemplu, atributul NrApartament). Prin urmare, această valoare (artificială), care nu trebuie confundată cu valoarea 0 sau cu şirul vid de caractere, a fost incorporată modelului relaţional bazelor de date pentru a permite tratarea excepţiilor şi a datelor incomplete. 63

60 3.6.2 Integritatea entităţilor Prima regulă de integritate se aplică cheilor primare. Oricare ar fi entitatea E din baza de date, nici un atribut care face parte din cheia sa primară nu poate lua valoarea NULL pentru nici o instanţă a entităţii. Dacă un atribut din structura cheii primare a entităţii primeşte valoarea NULL este contrazisă cerinţa de minimalitate a cheii primare (ar însemna că restul atributelor care formează cheia şi care iau numai valori din domeniile lor de definiţie ar fi suficiente pentru a identifica în mod unic fiecare instanţă a entităţi) Integritatea referenţială A doua regulă de integritate se aplică cheilor externe. Fie două entităţi U şi V relaţionate; pentru orice instanţă a entităţii V (secundară) valoarea cheii externe trebuie să corespundă valorii cheii primare a unei instanţe oarecare a entităţii U (principală) sau să fie NULL. Exemplu Exemplu Fie baza de date cu tabele Pacienţi (codpacient, numepren, datanaşterii, adresa, telefon, nrserieci, CNP) şi Programări (nrprogramare, dataprogramare, oraprogramare, codpacient) aflate în relaţie 1-m (Figura 3.8). Regula de integritate referenţială nu permite să înregistrăm datele personale ale unui pacient şi să-l includem într-o listă de programări care nu există" (adică să dăm atributului său Codpacient - cheie externă pentru entitatea Programări - o valoare pe care nu a luat-o atributul CodPacient -cheie primară pentru entitatea Pacienţi-pentru niciuna dintre instanţele entităţii). Observaţie: Dacă trebuie să înregistrăm datele unui pacient înainte de a înregistra datele din tabela căreia îi aparţine, putem face acest lucru dând atributului Codpacient. al entităţii programări valoarea NULL (lucru permis, întrucât aici atributul Codpacient este externă, şi nu primară). 64

61 Figura 3.8 Stabilirea integrităţii referenţiale în Access Restricţii procedurale În etapa de analiză a situaţiei reale care trebuie modelată prin baza de date, în discuţiile dintre proiectanţii bazei de date şi viitorii ei proprietari şi utilizatori, pot apărea informaţii suplimentare privind restricţiile pe care trebuie să le îndeplinească datele stocate şi operaţiile efectuate asupra lor. Restricţii procedurale = reguli suplimentare privind modul de înregistrare a datelor şi de efectuare a operaţiilor, specifice situaţiei reale sau impuse de diferitele categorii de participanţi la proiectarea, construirea, administrarea şi utilizarea bazei de date. 65

62 3.7 Implementarea modelului conceptual Regulile ce se pot extrage studiu de caz pot fi descrise prin elemente ale modelului conceptual: atribute, identificatori unici, relaţii între entităţi. Trecerea de la modelul conceptual la modelul fizic se face prin implementarea într-un SGBD (Microsoft Access în această carte) a elementelor specifice reprezentate simbolic în Figura 3.9. Model Conceptual Model Fizic Entitate Atribut Identificator unic Relaţie Tabelă Coloană Cheie primară Cheie străină (externă) Figura 3.9. Trecerea de la modelul conceptual la modelul fizic Un pas important în construirea bazei de date îl reprezintă crearea tabelelor a relaţiilor dintre ele, conform regulilor de integritate. Tabela = o structură utilizată pentru stocarea şi organizarea datelor. Tabelele sunt formate din linii şi coloane. Fiecare coloană reţine date de anumit tip şi corespunde unui atribut al entităţii; numele atributului devine antetul coloanei. Un rând din tabelă corespunde unui element al entităţii (instanţă) şi se num înregistrare. Aceasta descrie complet proprietăţile unei instanţe. Dacă ne imaginăm un tabel sub forma unei grile asemănătoare unei foi de calcul tabelar, coloanele verticale din grilă sunt coloanele tabelului, iar rândurile orizontale reprezintă rândurile tabelului. 66

63 O cheie primară este reprezentată de o coloană sau o combinaţie de coloane ale căror valori sunt unice la nivelul tabelei şi sunt completate obligatoriu. Cheile primare provin din identificatorii unici ai entităţii. O relaţie dintre două entităţi va fi transformată într-o coloană cheie străină. O constrângere de integritate implementează o regulă referitoare la o coloană sau la întregul tabel. Constrângerile de integritate pot fi stocate în baza de date, ca parte a definiţiei tabelului. Crearea unei tabele se realizează în două etape: a) în prima etapă, se stabileşte structura tabelei, specificându-se numele câmpurilor, lungimile acestora, precum şi tipul informaţiilor care vor fi introduse în fiecare câmp; b) în a doua etapă, se încarcă efectiv datele în tabelă. 67

64 3.8 Rezumatul capitolului Modelul relaţional a fost fundamentat în anul de E.F.Codd ş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. Noţiunile fundamentale ale modelului relaţional sunt: relaţie, domeniu, atribut, tuplu şi schemă relaţională. Conform modelului relaţional avem următoarele: o Orice entitate este reprezentată printr-o tabelă; numele entităţii devine numele tabelei. o Oricărui atribut al unei entităţi îi corespunde o coloană (numită şi câmp) în tabela corespunzătoare entităţii; numele atributului devine antetul coloanei respective din tabelă. o Orice instanţă a unei entităţi este reprezentată printr-un rând în tabelă asociată entităţii, numit înregistrare; fiecare celulă din înregistrare conţine valoarea luată de atributul corespunzător pentru instanţa respectivă. Prin entitate înţelegem mulţimea tuturor elementelor de un anumit tip (care prezintă aceleaşi caracteristici). Prin instanţă a unei entităţi înţelegem un singur element, bine individualizat, unic, din mulţimea elementelor care formează entitatea respectivă. Atributul este o caracteristică a unei entităţi. Cheia primară este un atribut sau cea mai mică mulţime de atribute ale unei entităţi care iau, fiecare instanţă a entităţii respective, o valoare şi numai una, sugestiv prin sensul figurat al cuvântului cheie Relaţia într-o bază de date este o legătură logică între două sau mai multe entităţi. La proiectarea bazei de date, relaţiile dintre entităţi trebuie definite în mod efectiv şi pot fi de următoarele tipuri: 1-1, 1-m, n-m. După modelarea bazei de date la nivel structural (definirea entităţilor, atributelor lor şi a relaţiilor dintre ele), urmează nivelul operaţional al modelării: stabilirea tipurilor de operaţii care se pot efectua asupra datelor stocate (sortare, căutare, vizualizare, adăugare, ştergere, modificare etc.); verificarea respectării regulilor de integritate (ceea ce va asigura corectitudinea şi consistenţa datelor). Distingem următoarele tipuri de reguli de integritate: 14 Ideea îi aparţine lui D.F.Childs care a publicat în 1968 o lucrare în care a arătat că orice structură de date poate fi reprezentată sub formă de tabele în interiorul căreia trebuie să existe şi informaţie de legătură (Lungu, et al, 1995). 68

65 reguli de integritate a entităţilor; reguli de integritate referenţială. La acestea se adaugă şi regulile de integritate impuse de situaţia reală modelată prin baza de date, numite restricţii procedurale. Prima regulă de integritate se aplică cheilor primare (cheia sa primară nu poate lua valoarea NULL pentru nici o instanţă a entităţii). A doua regulă de integritate se aplică cheilor externe (pentru orice instanţă a entităţii secundare, valoarea cheii externe trebuie să corespundă valorii cheii primare a unei instanţe oarecare a entităţii principale sau să fie NULL. 69

66 3.9 Întrebări de auto-evaluare I) Entităţi disjuncte; entităţi dependente. a) Fie baza de date a unei facultăţi şi entităţile Persoane, CadreDidactice, Studenţi, PersonalAdministrativ. Identificaţi entităţile disjuncte. În ce situaţie se află entităţile Persoane, CadreDidactice şi PersonalAdministrativ? b) Fie baza de date a unui club dotat cu săli de gimnastică, saloane de cosmetică, solare şi saună. Identificaţi entităţile disjuncte, subentităţile, precum şi entităţile principale şi cele dependente. II) Entităţi, atribute şi chei primare a) Daţi exemple de instanţe ale entităţii Studenţi. b) Daţi exemple de valori ale atributului Viteză al entităţii Microprocesor. c) Descrieţi atributele următoarelor entităţi şi identificaţi un atribut/grup de atribute cu proprietatea de identificator unic: (i) persoană; (ii) abonat telefonic; (iii) automobil; (iv) calculator. III) Exemple de relaţii: grad şi cardinalităţi Daţi exemple de relaţii binare din baza de date a unui club sportiv. Daţi exemple de relaţii 1-1, 1-m şi n-m din baza de date a unui spital. Citiţi întrebările de mai jos şi alegeţi varianta corectă de răspuns: IV) Modelul conceptual 1.Elementele de bază ale modelului conceptual sunt: a) entităţile şi atributele; b) instanţele şi relaţiile; c) cheile primare şi cheile candidat; d) entităţile, atributele şi relaţiile. 2.Entităţile principale sunt entităţi care: a) admit subentităţi; b) admit entităţi dependente; c) constau dintr-o singură instanţă. 3. După gradul de complexitate, atributele pot fi: a) atribute de bază şi atribute derivate: b) atribute elementare şi atribute compuse; c) atribute cu valori unice şi atribute cu valori multiple. 4.O entitate poate avea: a) cel puţin două chei primare; b) oricâte chei primare, dar o singură cheie candidat; c) oricâte chei candidat, dar o singură cheie primară. 70

67 5.Modelul conceptual al unei baze de date poate fi reprezentat: a) printr-o schemă logică; b) printr-o diagramă relaţionată; c) printr-o schemă conceptuală sau printr-o diagramă entitate-relaţie. V) Reguli de integritate 1.Principalele reguli de integritate pentru bazele de date se referă la: a) entităţi şi relaţii; b) entităţi şi atribute; c) entităţi şi chei primare; d) atribute şi relaţii. 2. Regula de integritate a entităţilor interzice unui atribut care face parte din cheia primară a unei entităţi: a) să ia valoarea 0; b) să ia valoarea 1; c) să ia valoarea NULL; d) să ia oricare dintre valorile 0, 1 sau NULL. 3. Integritatea referenţială se referă la valorile luate de: a) fiecare dintre cheile candidat ale entităţii principale; b) fiecare dintre cheile candidat ale entităţii dependente; c) cheia primară; d) cheia externă. 71

68 72

69 CAPITOLUL 4 NORMALIZAREA BAZELOR DE DATE 4.1. Introducere Normalizarea bazelor de date este o tehnică de proiectare a bazelor de date relaţionale. Scopul acesteia este de a elimina redundanţele şi anomaliile la adăugare, ştergere şi modificare. Crearea mai multor relaţii poate încetini timpul de acces la date. În cadrul acestui capitol sunt prezentate toate tipurile de dependenţe funcţionale care stau la baza creării formelor normale, cu exemple. Modul în care se pot stabili relaţiile unei baze de date nu este unic, eficienţa variantei aleasă fiind dată de raportul dintre accesibilitatea datelor şi eliminarea anomaliilor. 4.2 Organizarea datelor Dacă datele sunt simple, ele pot fi organizate într-un tabel simplu. O bază de date simplă poate fi întreţinută chiar şi cu ajutorul unui procesor de texte sau a unei aplicaţii cu foi de calcul tabelar. Pentru a lucra cu un tabel simplu nu sunt necesare cunoştinţe despre teoria bazelor de date. De exemplu o listă de contacte Figura 1. Fiecare coloană de date (nume, adresă, număr de telefon) este logic legată de celelalte. Fig. 1. Tabela non-relaţională Contacte (în Microsoft Excel) Bazele de date din viaţa reală conţin adeseori sute de mii sau chiar milioane de înregistrări, datele fiind legate instrinsec între ele. Definiţie: Relaţia redă informaţiile despre un obiect reprezentat (o entitate concretă sau abstractă). Schema relaţiei este expresia proprietăţilor comune şi 73

70 invariante ale liniilor care compun relaţia şi este relativ constantă în timp. Atributul este o caracteristică a obiectului reprezentat într-o relaţie. 15 Un exemplu de relaţie este prezentat în figura 1. Exemple de atribute: ID, Nume Contact, Adresa Contact şi Nr_tel Contact. Utilizarea unei singure relaţii pentru a menţine o bază de date conduce la repetări inutile ale datelor, adică redundanţă 16. Redundanţa reprezintă o proprietate a unei colecţii de date care se referă la faptul că unele componente sunt memorate de mai multe ori pe suportul de memorare. Fig 2. Relaţie simplă în Microsoft Access După cum se poate vedea din figura 2, redundanţa excesivă poate determina un proiectant de baze de date să evite folosirea unei singure relaţii. În afara redundanţei, mai există trei probleme importante legate de acest tip de organizare: Anomalia la modificare: pentru a modifica adresa furnizorului Pop Ion este necesară modificarea fiecărui rând care conţine acea adresă. Dacă o înregistrare nu este modificată, apare anomalia la modificare, rezultând o relaţie care conţine inexactităţi. Anomalia la inserare: dacă se doreşte adăugarea unui nou furnizor, dar nu există nici o factură a acestuia sau nici un detaliu despre produsele facturate, se poate adăuga un rând nou, iar în câmpurile în care informaţiile nu sunt disponibile se va plasa valoarea NULL (o valoare 15 Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p Giulvezan C., Mircea G., Târnăveanu D. Baze de date: Teorie şi practică. Access, VBA şi SQL, Editura Universității de Vest, Timişoara, 2009, p

71 care indică o valoarea necunoscută sau care lipseşte). Aceasta cauzează aşa-numita anomalie la inserare. Anomalia la ştergere: În contradicţie cu problema precedentă, dacă se doreşte ştergerea tuturor apariţiilor furnizorului Pop Ion, automat vor fi şterse toate informaţiile legate de produsele livrate şi facturile pe care acesta apare. Aceasta constituie anomalia la ştergere. Această listă de probleme potenţiale oferă suficiente argumente în favoarea utilizării mai multor relaţii. 4.3 Dependenţe În procesul de normalizare a bazei de date este necesar să se ţină seama de anumite reguli (dependenţe, forme normale) care permit eliminarea anomaliilor prezentate în paragraful anterior. Dependenţele de date reprezintă constrângeri care se impun valorilor atributelor unei relaţii şi care determină proprietăţile relaţiei în raport cu operaţiile care pot genera anomalii (inserare, ştergere, actualizare) Dependenţe funcţionale simple Dependenţele sunt structuri logice ce se stabilesc între atributele modelului relaţional. Acestea nu se determină inspectând conţinutului relaţiei la un moment dat, ci studiind semnificaţia atributelor acesteia. Definiţie: Între două atribute A şi B există o dependenţă funcţională 17 dacă fiecărei valori a lui A îi corespunde o singură valoarea a lui B (simbolizată A B). A poartă numele de determinant iar B poartă numele de determinatul dependenţei. De exemplu, în cazul studenţilor, unei valori a numărului matricol îi corespunde un singur nume şi prenume, deci între nrmatr şi numeprenstudent există o dependenţă funcţională: nrmatr numeprenstudent 17 Tamaş I. (coord.), Stanciu V., Gheorghe M. Access 2007 Proiectare şi realizare pas cu pas, Editura Infomega, Bucureşti, 2010, p.23 75

72 unde nrmatr este determinantul, iar numeprenstudent este determinatul. Observaţie: Dacă A B, atunci la două linii cu aceeaşi valoare pentru atributul A le corespund aceeaşi valoare a atributului B 18. Alte exemple: nr_f cod_furn cod_p unit_masura unde nr_f este numărul facturii, cod_furn este codul furnizorului, iar cod_p este codul de bare al produsului, unit_masura fiind unitatea de măsură a produsului. Observaţie: Între câmpul de tip cheie primară al unei relaţii şi celelalte câmpuri ale relaţiei există dependenţe funcţionale. Definiţie: O dependenţă funcţională în care determinatul este alcătuit dintrun singur atribut se numeşte dependenţă funcţională canonică 19. Exemple de dependenţe funcţionale canonice: cod_p den_p nr_document data document unde den_p este denumirea produsului, nr_document este seria şi numărul documentului de plată. Definiţie: O dependenţă funcţională este trivială dacă şi numai dacă determinatul este un subset al determinantului: dacă B A atunci A B. Exemple de dependenţe funcţionale triviale: (cod_p, nr_f) cod_p (nr_document, tip_document) nr_document Definiţie: Dependenţele funcţionale compuse 20 prezintă ca determinant două sau mai multe atribute, care se scriu între paranteze. 18 Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p.56 76

73 Exemple de dependenţe funcţionale compuse: (nr_f, cod_p) pret_unitar unde un număr de factură şi un cod produs (cu presupunerea că pe o factură codul produsului apare o singură dată) determină un unic preţ unitar. Definiţie: Se numeşte dependenţă funcţională completă 21, o dependenţă funcţională de forma A B unde B este dependent funcţional de A, fără să fie dependent de nici una din componentele lui A. Între grupul de câmpuri (nr_matr, cod_disciplina) şi nota există o dependenţă funcţională completă, deoarece: (nr_matricol, cod_disciplina) nota nr_matricol nota cod_disciplina nota Pentru un student, numărul matricol şi codul disciplinei determină în mod unic nota, dar pentru un număr matricol există mai multe note (la discipline diferite), iar unui cod de disciplină îi corespund mai multe note (ale mai multor studenţi). Definiţie: O dependenţă A B se numeşte dependenţă funcţională parţială 22 dacă şi numai dacă B este dependent funcţional atât de A, cât şi de o componentă a lui B. De exemplu, între grupul de câmpuri (nr_document,tip_document) şi suma există o dependenţă funcţională parţială, deoarece: (nr_document, tip_document) suma nr_document suma tip_document suma unde nr_document semnifică seria şi numărul de pe documentul de plată (valoare unică), suma seminifică suma de plată iar tip_document are una din valorile: chitanţă, ordin de plată, etc. Pentru un număr de document suma de plată este unică. Dar pentru fiecare tip de document suma de plată poate fi diferită (de exemplu, nu toate chitanţele au aceeaşi sumă de plată). 21 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p.41 77

74 4.3.2 Dependenţe funcţionale directe şi tranzitive Definiţie: O dependenţă funcţională tranzitivă este acea dependenţă A B care se poate descompune în A C B. Exemplu de dependenţă funcţională tranzitivă: Fiecare bancă are mai multe agenţii, fiecare agenţie are propria adresă. Definiţie: O dependenţă funcţională directă este acea dependenţă A B pentru care nu există dependenţe tranzitive A C B. Exemplu de dependenţă directă: cod_banca adresa cod_banca cod_agenţie cod_agenţie adresa cod_banca denumire_banca Dependenţe funcţionale multiple Definiţie: Între două atribute A şi B există o dependenţă funcţională multiplă, notată A B, dacă şi numai dacă unei valori a atributului A îi corespund două sau mai multe valori ale atributului B 23. cod_banca cod_agenţie nr_f cantitate Dependenţe multivaloare Definiţie: Tuplul reprezintă o linie distinctă de valori din cadrul unei relaţii Tamaş I. (coord.), Stanciu V., Gheorghe M. Access 2007 Proiectare şi realizare pas cu pas, Editura Infomega, Bucureşti, 2010, p Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p.84 78

75 Definiţie: Se consideră relaţia R(A,B,C), unde A, B şi C sunt atribute ale acesteia (simple sau compuse). Fie a i,b i şi c i valorile atributelor A, B şi C. Spunem că există o dependenţă funcţională multivaloare a atributului C faţă de B, notată B C dacă pentru orice valori a 1, a 2, b, c 1, c 2 şi a 1 a 2 şi c 1 c 2, astfel încât tuplurile (a 1,b,c 1 ) şi (a 2,b,c 2 ) fac parte din relaţia R, atunci şi tuplurile (a 1,b,c 2 ) şi (a 2,b,c 1 ) fac parte din relaţia R. Ca exemplu de dependenţă multivaloare putem considera: R(cod_depozit, cod_magazie, cod_p) unde cod_depozit este codul depozitului, cod_magazie este codul magaziei şi cod_p este codul produsului. Este esenţială presupunerea că magaziile se aprovizionează de la acelaşi depozit şi comercializează toate produsele cumpărate de la depozitul respectiv. Din relaţia R se pot extrage următoarele dependenţe multivaloare: cod_depozit cod_depozit cod_magazie cod_p Există dependenţă multivaloare a atributului cod_p faţă de cod_magazie dacă pentru orice valori de tipul: cod_depozit cod_magazie cod_p atunci următoarele valori aparţin relaţiei: cod_depozit cod_magazie cod_p Toate magazinele aprovizionându-se din acelaşi depozit, şi comercializând aceleaşi produse, dacă magazinul 49 comercializează produsul 1234 şi magazinul 51 comercializează produsul 1235 atunci putem fi siguri că şi magazinul 49 comercializează produsul 1235 şi magazinul 51 comercializează produsul Dependenţele funcţionale sunt un caz particular al dependeţei multivaloare. 79

76 4.3.5 Dependenţe joncţiune O relaţie R{X, Y, Z} este joncţiunea proiecţiilor sale XY, XZ şi YZ dacă (x 1,y 1 ) XY, (y 1,z 1 ) YZ, atunci (x 1, y 1, z 1 ) XYZ. Dacă în R{X, Y, Z} există trei tupluri (x 1, y 1, z 2 ), (x 2, y 1, z 1 ) şi (x 1, y 2, z 1 ) atunci obligatoriu apare şi tuplul (x 1, y 1, z 1 ) (condiţia de joncţiune). Fie relaţia R(A 1, A 2,... A n ) şi X 1, X 2,..., X m, m subansambluri de atribute din R. Definiţie: Se spune că există o dependenţă joncţiune 25 de ordinul m între X 1, X 2,..., X m, notată * X 1 X 2... X m sau *{X 1, X 2,..., X m } dacă şi numai dacă R reprezintă joncţiunea proiecţiilor sale pe X 1, X 2,..., X m, deci R=R(X 1 )* R(X 2 )*...* R(X m ). Considerând relaţia R(cod_prof, nr_matr, cod_facultate) unde cod_prof este codul profesorului universitar, nr_matr este numărul matricol al studentului, iar cod_disc este codul disciplinei. Dacă profesorul 111 predă studentului 1234, profesorul 111 predă disciplina cu codul 13 şi studentul 1234 studiază disciplina cu codul 13, atunci profesorul 111 intră în relaţie cu studentul 1234 prin intermediul disciplinei cu codul 13. Se presupune că relaţia R conţine următoarele înregistrări: cod_prof nr_matr cod_disc atunci există şi cod_prof nr_matr cod_disc iar proiecţiile relaţiei R sunt: cod_prof nr_matr nr_matr cod_disc cod_prof cod_disc cod_prof nr_matr nr_matr cod_disc cod_prof cod_disc Dependenţa multivaloare este un caz particular al dependenţei joncţiune. 25 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p.44 80

77 4.3.6 Matricea dependenţelor funcţionale Pentru obţinerea modelului relaţional se parcurg următorii paşi 26 : 1. Construirea dicţionarului de atribute (DA) atributele se vor prelua din documente primare, rapoarte, indicatori, etc şi se vor adăuga în DA. Reguli de formare a dicţionarului de atribute: fiecare atribut este scris o singură dată; se vor elimina atributele calculate şi atributele sinonime. 2. Stabilirea cheilor primare se vor alege cheile primare dintre atributele candidate (cele care au valori unice). 3. Specificarea dependenţelor se vor identifica tipurile de dependenţe care există între fiecare cheie primară şi restul atributelor din DA. 4. Determinarea atributelor izolate se vor căuta determinanţii acestora. Se selectează mai întâi grupurile de chei primare, apoi grupurile de atribute non-cheie, iar în final, dacă este cazul, se vor adăuga chei surogat. 5. Formarea relaţiilor. Se va ţine cont de următoarele reguli: a. Fiecare determinant împreună cu atributele determinate, vor forma câte un tabel. b. Dacă între două chei primare există o dependenţă multiplă reciprocă, atunci această dependenţă va genera un tabel. Cheia primară a acestei relaţii va fi formată din cele două atribute, care, individual vor avea şi rol de chei externe. Exemplu: Se doreşte informatizarea unei părţi din activitatea unei firme. Furnizorii sunt identificaţi prin cod furnizor, denumire furnizor (numele şi prenumele furnizorului), localitatea, adresa, , banca furnizor şi cont furnizor. Despre produse se cunosc cod produs, denumire produs, unitate de măsură, stoc, preţ unitar. Produsele sunt depozitate în magazii, pentru care se cunosc cod magazie, denumire magazie, gestionar (numele persoanei care are în gestiune depozitul respectiv). Operaţiunile se desfăşoară pe baza unor facturi, care trebuie să conţină numărul facturii şi data facturii. Fiecare factură conţine detaliate liniile facturii şi anume denumirea produsului, preţul unitar, cantitatea facturată, calculându-se valoarea produsului (cu şi fără TVA) şi valoarea totală a facturii (cu şi fără TVA). 26 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p.44, p.57 81

78 Rezolvare: 1. Inventarierea atributelor Pe baza analizei rezultă următoarele atribute: cod_f (cod furnizor), den_f (denumire furnizor), localit (localitatea furnizorului), adresa, , banca, cont, nr_f (numărul facturii), data_f (data facturii), nr_crt (numărul curent asociat fiecărui produs de pe factură), cod_p (codul produsului), cantit (cantitatea facturată), val_f_tva (valoarea produsului fără TVA), val_c_tva (valoarea produsului cu TVA), val_totala_f_tva (valoarea totală a facturii fără TVA), val_totala_c_tva (valoarea totală a facturii cu TVA), TVA (TVA-ul din valoarea produsului), cotatva (valoarea cotei TVA), den_p (denumirea produsului), um (unitatea de măsură a produsului), stoc (stocul din produsul respectiv), pret_u (preţul unitar facturat al produsului), cod_m (codul magaziei în care este depozitat), den_m (denumirea magaziei) şi gestionar (numele gestionarului). 2. Specificarea regulilor de gestiune o factură este emisă de un singur furnizor, un furnizor poate să apară pe mai multe facturi; o factură poate conţine mai multe produse, iar un produs poate să apară pe mai multe facturi; un produs poate fi depozitat în mai multe magazii, iar o magazie poate depozita mai multe produse. Algoritmi de calcul Val_f_tva = cantit*pret_u TVA=cantit*pret_u*cotaTVA Val_c_TVA=Val_f_TVA+TVA Val_totala_f_TVA= Val_totala_c_TVA= 3. Întocmirea dicţionarului de atribute Dicţionarul de atribute DA: cod_f, den_f, localit, adresa, , banca, cont, nr_f, data_f, nr_crt, cod_p, cantit, cotatva, den_p, um, stoc, pret_u, cod_m, den_m şi gestionar. 4. Stabilirea cheilor primare: cod_f, cod_p, cod_m, nr_f. 5. Stabilirea dependeţelor funcţionale Graful dependenţelor funcţionale simple 82

79 Graful dependenţelor funcţionale multiple cod_f nr_f cod_m cod_p cod_p cod_m nr_f cod_p cod_p nr_f 6. Atribute izolate: cantit, cotatva şi preţ_u sunt determinate de un grup de atribute după cum urmează: 7. Formarea tabelelor: Fiecare cheie primară şi atributele determinate direct şi intranzitiv vor forma un tabel. 8. Identificarea cheilor externe: atributele subliniate prin linie discontinuă la nivelul modelului relaţional. unde Fig. 3 Graful dependenţelor funcţionale multiple semnifică reprezentarea grafică a unei chei compuse. 83

80 9. Matricea dependenţelor funcţionale unde 1 = dependenţe funcţionale simple 1 T = dependenţe funcţionale simple tranzitive # = chei primare 10. Definitivarea modelului relaţional: Furnizori(cod_f, den_f, localit, adresa, , banca, cont) Facturi(nr_f, data_f, cod_f) Produse(cod_p, den_p, um) ProduseFacturate(nr_f, nr_crt, cod_p, cantit, pret_u, cotatva ) Magazii(cod_m, den_m, gestionar) ProduseMagazii(cod_p, cod_m, stoc) Prin linie continuă se simbolizează cheile primare, iar prin linie întreruptă, cheile străine. 11. Implementarea în Access Fig. 4. Fereastra Relationship din Access 84

81 4.4 Forme normale O formă normală a unei relaţii implică anumite condiţii pe care trebuie să le îndeplinească valorile atributelor şi dependenţelor de date definite pe acea relaţie 27. E.F. Codd a prezentat în 1972 o tehnică pentru proiectarea bazelor de date relaţionale pe care a numit-o normalizare 28. Acesta a propus trei forme normale, numite prima formă normală (FN1), a doua formă normală (FN2) şi a treia formă normală (FN3). Ulterior, a mai fost introdusă o formă normală care completa FN3, aceasta fiind numită Boyce-Codd (FNBC). Acestor forme normale le corespund dependenţe funcţionale între atributele unei relaţii. Formele normale superioare cum ar fi (FN4) şi (FN5) impun condiţii dependeţelor multivaloare, respectiv de joncţiune între atributele unei relaţii şi sunt atribuite cercetătorului Fagin Forma normală 1 O relaţie se află în forma normală 1 (FN1) dacă toate atributele sale sunt atomice (nu se mai pot descompune) şi nerepetitive. Pentru aducerea relaţiilor în FN1 se parcurg următorii paşi: atributele compuse sunt înlocuite cu atribute complete; pentru grupurile de atribute repetitive, se formează o altă relaţie; cheia primară a noii relaţii va fi compusă din cheia primară a primei relaţii şi din atributele adiţionale din noua relaţie. Cheia primară a noii relaţii va fi cheie externă. O relaţie nu este în FN1 dacă are câmpuri care conţin valori care pot fi descompuse în mai multe câmpuri (cum ar fi adresa) sau valori redundante figura Ionescu F. Baze de date relaționale şi aplicații, Editura Tehnică, Bucureşti, 2004, p Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p.60 85

82 De exemplu: Fig. 5 Relaţia Factura nu respectă FN1 Fig. 6 Relaţiile Furnizori, Facturi, LiniiFacturi şi Produse respectă FN Forma normală 2 O relaţie se află în forma normală 2 (FN2) dacă respectă FN1 şi orice atribut non-cheie este complet dependent de cheia primară a relaţiei. FN2 interzice existenţa dependenţelor funcţionale parţiale între atributele cu rol de cheie primară şi celelalte atribute. Pentru aducerea relaţiilor din FN1 în FN2 se parcurg următorii paşi: se identifică dependenţele funcţionale parţiale; acestea vor genera o nouă relaţie, având ca structură atributele participante în dependenţa funcţională parţială; atributele determinante devin chei externe în relaţiile iniţiale şi chei primare în relaţiile nou create. 86

83 Fig. 6 Relaţia FacturiProduse nu respectă FN2 Relaţia FacturiProduse nu se află în forma normală 2 deoarece: (Nrfact, Nrprod) DenProd Nrprod DenProd Relaţia FacturiProduse prezintă următoarele anomalii: redundanţă pentru câmpul DenProd (care depinde parţial de cheia primară) figura 6; anomalii la adăugare: nu se pot adăuga produse dacă nu există o factură pentru acestea; anomalii la ştergere: ştergerea unei facturi poate duce la ştergerea definitivă a unor produse; anomalii la modificare: dacă se modifică denumirea unui produs, atunci trebuie modificate toate înregistrările care conţin denumirea produsului respectiv. Fig. 7 Relaţiile LiniiFacturi şi Produse respectă FN2 87

84 4.4.3 Forma normală 3 O relaţie este în forma normală 3 (FN3) dacă respectă FN2 şi toate atributele non-cheie sunt dependente direct de cheia primară. Altfel spus, FN3 interzice dependenţele tranzitive. O relaţie care nu respectă FN3 prezintă anomalii la ştergere, inserare şi modificare, precum şi redundanţe pentru atributele determinate funcţional tranzitiv. Pentru aducerea unei relaţii FN2 în FN3, se parcurg următorii paşi: se identifică dependenţele funcţionale tranzitive; determinantul non-cheie împreună cu atributul sau atributele determinate funcţional de către acestea, vor forma o nouă relaţie; determinantul non-cheie devine cheie primară în relaţia nou formată şi cheie externă în relaţia iniţială. Fig. 8 Relaţia FacturiFurnizori nu respectă FN3 Relaţia FacturiFurnizori nu se află în forma normală 3 deoarece există o dependenţă funcţională tranzitivă: Nrfact Nrfurn Numefurn Relaţia FacturiFurnizori prezintă următoarele anomalii: redundanţă pentru câmpul Numefurn (determinat funcţional tranzitiv din Nrfurn) figura 8; anomalii la adăugare: nu se pot adăuga furnizori dacă nu există o factură a acestora; anomalii la ştergere: ştergerea unei facturi poate duce la ştergerea definitivă a furnizorului; anomalii la modificare: dacă se modifică denumirea unui furnizor, atunci trebuie modificate toate înregistrările care conţin denumirea furnizorului respectiv. Majoritatea specialiştilor sunt de acord că o bază de date aflată în FN3 asigură un raport satisfăcător între rezolvarea redundanţelor şi a anomaliilor pe de o parte şi viteza de lucru şi accesibilitatea datelor, de pe altă parte. 88

85 4.5 Concluzii Normalizarea presupune efectuarea de verificări asupra datelor dintr-o relaţie pentru a determina dacă aceasta satisface regulile formelor normale. Formele normale se bazează pe dependenţele funcţionale ce se pot stabili între atributele unei relaţii. Obiectivele normalizării sunt: minimizarea redundanţei, eliminarea anomaliilor, facilitarea interogărilor bazei de date şi diminuarea nevoii de modificare periodică a structurii bazei de date. 29 O bază de date riguros normalizată nu este neapărat şi o bază de dată optimă datorită vitezei de lucru, a accesibilităţii datelor de aceea în unele cazuri se introduc selectiv date redundante pentru a creşte performanţa sistemului. Acest proces poartă numele de denormalizare. 4.6 Rezumatul capitolului Obiectivul central al normalizării îl constituie conceperea bazelor de date. O bază de date normalizată trebuie să conţină relaţii în care să nu existe redundanţe şi anomalii. Eliminarea acestor anomalii se poate realiza prin descompunerea relaţiei în mai multe tabele. Modul în care se pot stabili relaţiile unei baze de date nu este unic, de aceea este necesar să existe criterii de evaluare a calităţii relaţiilor. Pe baza dependenţelor de date se pot stabili reguli de definire a relaţiilor, astfel încât acestea să prezinte anumite proprietăţi care caracterizează formele normale ale relaţiilor. 29 Hurbean L., Dănăiață D., Negovan A.-M. Baze de date: de la teorie la practică utilizând Access 2007, Editura Mirton, Timişoara, 2008, p.85 89

86 4.7 Întrebări de autoevaluare din partea teoretică 1. Să se definească conceptul de normalizare. Să se detalieze obiectivele normalizării. 2. Să se definească conceptul de redundanţă. Să se susţină cu argumente necesitatea redundanţelor necesare. 3. Să se exemplifice dependenţele funcţionale, directe şi tranzitive. 4. Să se exemplifice dependenţele complete şi parţiale. 5. Să se formuleze un enunţ de bază de date care să conţină mai multe tabele şi să se detalieze schema bazei de date pe baza matricii dependenţelor funcţionale. 6. Să se exemplifice o relaţie care nu este în FN1 şi să se detalieze rezolvarea problemei. 7. Să se exemplifice o relaţie care nu este în FN2 şi să se detalieze rezolvarea problemei. 8. Să se exemplifice o relaţie care nu este în FN3 şi să se detalieze rezolvarea problemei. 90

87 4.8 Exemple Problemă rezolvată Filiala CEC Se cere informatizarea activităţii la o filială CEC. Clienţii filialei sunt identificaţi prin nume şi prenume, cnp, seria şi numărul de buletin, data eliberării buletinului şi adresă. Fiecare client poate să deţină unul sau mai multe cecuri. Pentru fiecare cec se cunoaşte: seria, numărul, data la care a fost eliberat, suma depusă în momentul eliberării şi tipul cecului (poate fi la termen sau la vedere). De asemenea, fiecare cec poate să aibă unul sau mai mulţi titulari. Fiecare client poate efectua depuneri şi restituiri. Depunerile se efectuează prin intermediul unei foi de depunere (FD) caracterizată prin: număr, dată şi suma depusă. Restituirile se efectuează prin intermediul foilor de restituire (FR) caracterizate prin: număr, data şi suma restituită. Fiecare cec se poate lichida de către unul din titulari prin intermediul unei foi de lichidare (FL) caracterizată prin: număr, data şi suma din momentul lichidării. Dobânda acordată pentru cecuri se modifică de la o zi la alta şi este diferită pentru cecurile la termen faţă de cele la vedere. Rezolvare 1. Inventarierea atributelor Pe baza analizei rezultă următoarele atribute: codcl, numepren, cnp, serieci, nrci, dataelibci, adresa, serie_nrcec, dataelibcec, titularcec, codtipcec, tipcec, termen, coddep, datadep, sumadep, codrest, datarest, sumarest, codlich, datalich, sumalich, datadob, dobanda. 2. Specificarea regulilor de gestiune un client poate avea mai multe cecuri, un cec poate avea mai mulţi titulari (clienţi); pe un cec se pot face mai multe depuneri; pe un cec se pot face mai multe restituiri; un cec poate fi lichidat doar o singură dată; mai multe cecuri sunt de acelaşi tip. 3. Întocmirea dicţionarului de atribute Dicţionarul de atribute DA eliminăm atributul titularcec (este echivalent cu client) şi unim atributele seriecec şi nrcec într-un singur câmp, rezultând: codcl, numepren, cnp, serieci, nrci, dataelibci, adresa, serie_nrcec, dataelibcec, tipcec, 91

88 termen, coddep, datadep, sumadep, codrest, datarest, sumarest, codlich, datalich, sumalich, datadob, dobanda. 4. Stabilirea cheilor primare: codcl, serie_nrcec, codtipcec, coddep, codrest, codlich, codtipcec+datadob. 5. Stabilirea dependeţelor funcţionale Graful dependenţelor funcţionale simple Graful dependenţelor funcţionale multiple codcl serie_nrcec serie_nrcec codcl serie_nrcec coddep serie_nrcec codrest codtip serie_nrcec Atribute izolate: pentru un tip de cec, într-o anumită dată, se calculează o dobândă. codtip datadob dobanda 6. Formarea tabelelor: Fiecare cheie primară şi atributele determinate direct şi intranzitiv vor forma un tabel. 7. Identificarea cheilor externe: atributele subliniate prin linie discontinuă la nivelul modelului relaţional. 92

89 8. Graful dependenţelor funcţionale Matricea dependenţelor funcţionale unde 1 = dependenţe funcţionale simple 1 T = dependenţe funcţionale simple tranzitive # = chei primare 93

90 9. Definitivarea modelului relaţional: Clienti (codcl, numepren, cnp, serieci, nrci, dataelibcl, adresa) TipuriCecuri (codtip, tipcec, termen) Cecuri (serie_nrcec, dataelibcec, codtip) CecuriClienti (codcl, serie_nrcec) Depuneri (coddep, datadep, sumadep, serie_nrcec) Restituiri (codrest, datarest, sumarest, serie_nrcec) Lichidari (codlich, datalich, sumalich, serie_nrcec) Dobanzi (codtip, datadob, dobanda) 10. Implementarea în Access Fig. 9 Fereastra Relationships Probleme propuse Agenţie de turism 30 O agenţie de turism doreşte să-şi informatizeze activitatea de gestionare a contractelor încheiate pentru pachetele de servicii pe care le oferă. Turiştii sunt persoane fizice care se identifică printr-un cod unic, nume prenume, CNP, serie şi număr CI, data naşterii, telefon, număr paşaport. Agenţia oferă mai multe categorii de servicii (excursii, cazare, bilete de avion); fiecare categorie de servicii include tipuri de servicii (excursii circuit sau sejur, cazare all inclusive sau demipensiune, bilete de avion dus, întors, dus-întors) pentru 30 Stanciu A. (coord.), Mihai F, Mangiuc D, et al Baze de date Access 2007: studii de caz, Editura Infomega Bucureşti, 2009, p

91 care se memorează un cod unic şi denumirea serviciului. Indiferent de denumirea serviciului, se impune specificarea ţării destinaţie identificată prin cod şi denumire; pentru ţara de destinaţie se precizează localitatea destinaţie, pentru care se reţine codul şi numele. Pentru ca să fie cât mai atractivă, agenţia oferă anumite reduceri în funcţie de vâsrta turiştilor, astfel pentru turiştii cu vârsta mai mică sau egală cu 12 ani, se acordă o reducere de 40% din tariful standard aferent fiecărui serviciu, iar copii care nu au împlinit încă 12 ani beneficiază de gratuitate. Fiecare prestator de servicii se identifică printr-un cod unic, denumire, numărul de telefon, categoria în care se încadrează (companie aeriană, firmă de transport terestru, unitate cazare). Pentru serviciile prestate, agenţia încheie un contract de care pot beneficia mai mulţi turişti (de exemplu, o familie). În cadrul contractului, pe lângă numărul şi data încheierii acestuia, se precizează turistul/turiştii beneficiar(i), clauzele contractuale (drepturile/obligaţiile părţilor contractuale), avansul, data până la care se poate achita valoarea integrală a contractului, tariful standard aferent serviciului respectiv, data plecării şi data sosirii. Dacă turistul renunţă din vina sa la serviciile care fac obiectul respectivului contract, el datorează agenţiei despăgubiri diferenţiate în funcţie de momentul renunţării (mai exact, numărul de zile înainte de data plecării) Registrul de casă 31 Firma ABC SRL are ca obiect de activitate realizarea de cursuri de pregătire şi perfecţionare în domeniul limbilor străine. Se doreşte realizarea unei baze de date pentru evidenţa operaţiilor realizate în lei în cadrul casieriei. Zilnic se va realiza registrul de casă ce va conţine data realizării operaţiei, explicaţia operaţiei, suma operaţiei şi tipul operaţiei (încasare sau plată) precum şi numărul şi tipul documentului (cec de numerar, chitanţa, foaie de vărsământ, dispoziţie de plată sau încasare, state de salarii, etc). Registrul de casă va conţine soldul iniţial al zilei, totalul sumelor încasate precum şi soldul final al zilei. Fiecare operaţie înregistrată în baza de date va primi un număr unic folosit la identificare. Încasările pot să provină din vânzarea de servicii proprii (taxele cursanţilor) sau ridicări de numerar de la bancă, aport de capital. Plăţile se pot face pentru achitarea drepturilor salariale, avansuri spre decontare, cumpărări de bunuri, 31 Stanciu A. (coord.), Mihai F, Mangiuc D, et al Baze de date Access 2007: studii de caz, Editura Infomega Bucureşti, 2009, p

92 depuneri de numerar la bancă. Operaţiile sunt grupate pe categorii în funcţie de sursa acestora, reţinându-se pentru fiecare operaţie codul categoriei, denumirea acesteia şi tipul. Principalele categorii de operaţii sunt taxă cursanţi, ridicare numerar bancă, aport capital, achitare drepturi salariale, avans spre decontare, cumpărare bunuri, depunere de numerar la bancă, la care pot fi adăugate ulterior (în timpul exploatării bazei de date) şi alte plăţi sau încasări. O categorie specială de operaţii o reprezintă avansurile spre decontare. Acestea trebuie justificate prin intermediul unor documente în cadrul deconturilor de cheltuieli. Pentru fiecare decont de cheltuieli este necesară reţinerea numărului şi datei acestuia, a documentelor (număr, data, suma, tip) ce justifică cheltuirea avansului precum şi a datelor titularului avansului. Pot să beneficieze de avansuri spre decontare salariaţii firmei. Datele fiecărui salariat (nume, data naşterii, adresa) vor fi înregistrate în cadrul bazei de date o singură dată, acesta fiind identificat cu ajutorul mărcii. Avansul neutilizat este restituit la casierie pe baza documentului de încasare. Documentele justificative pentru avansuri se vor scana şi se vor arhiva Societate de asigurări 32 Se cere informatizarea activităţii unei societăţi de asigurări. Clienţii societăţii pot fi persoane fizice sau juridice, caracterizate printr-un număr unic, nume şi prenume/denumire, adresă şi telefon. Aceştia pot să încheie diferite tipuri de asigurări (de bunuri, de viaţă). Asigurările sunt încheiate de agenţii care sunt identificaţi printr-un cod unic, nume şi prenume. Contractul de asigurare este caracterizat print-un număr, data încheierii, obiectul încheierii, obiectul asigurării, perioada (în luni), valoarea asigurată şi prima ce va trebui plătită în fiecare lună de către client. Clienţii efectuează plata primelor din ordin de plată (persoane juridice) sau direct la casierie (persoane fizice), eliberându-se chitanţe. Documentul de plată conţine: numărul documentului, data la care a fost întocmit şi suma plătită. În momentul producerii riscului pentru care a fost întocmită asigurarea societatea plăteşte clientului despăgubiri. La plata despăgubirilor se întocmeşte un proces verbal care este caracterizat printr-un număr, data încheierii, descrierea cauzei care a generat despăgubirea şi procentul în care este despăgubit clientul. 32 Năstase P., Cosăcescu L., Covrig L., et al Tehnologia bazelor de date Access 2000, Editura Economică, Bucureşti, 2000, p

93 CAPITOLUL 5 ELEMENTE INTRODUCTIVE ÎN ACCESS 5.1 Introducere Sistemele informatice din domeniul economic conţin un volum relativ mare de date care se organizează cel mai bine în baze de date. Microsoft Access 2007 face parte din suita Microsoft Office 2007, având caracteristicile specifice unui sistem de gestiune al bazelor de date relaţionale. Access este totodată şi un instrument complex de dezvoltare al aplicaţiilor de baze de date. 5.2 SGBD Access: prezentare generală Microsoft Office Access 2007 este un sistem de gestiune a bazelor de date (SGBD) dezvoltat de firma Microsoft care oferă următoarele facilităţi 33 : permite lucrul atât pe staţii individuale cât şi în reţea, cu exploatarea partajată a datelor; are în structură un limbaj neprocedural SQL (Structured Query Language) larg răspândit în toate SBDG-urile; modul de lucru vizual facilitează crearea rapidă a unor aplicaţii; este autodocumentat şi conţine Wizard-uri; are access la reţeaua Internet. Access 2007 include facilităţi oferite de sistemul de operare Microsoft Windows (de exemplu meniu contextual al obiectelor) şi permite şi facilităţi de tipul drag and drop. Microsoft Access este compatibil cu tehnicile de legare şi încapsulare din tehnologia OLE Microsoft (Object Linking and Embedding). Este recomandată utilizarea Microsoft Access dacă: sunt necesare baze de date relaţionale (tabele multiple sau multidimensionale) sau dacă se anticipează adăugarea unor noi tabele pe viitor; cantitatea de date este mare; este necesară o legătură permanentă cu o bază de date externă de dimensiuni mari, cum ar fi una construită cu Microsoft SQL Server sau cu sistemul integrat al organizaţiei; 33 Tamaş I. (coord.), Stanciu V., Gheorghe M. Access 2007 Proiectare şi realizare pas cu pas, Editura Infomega, Bucureşti, 2010, p.7 97

94 este necesară regruparea datelor din diverse tabele într-un singur loc cu ajutorul unor interogări complexe; baza de date este accesată de mai mulţi utilizatori (se poate beneficia de mecanismele de modificare furnizate de baza de date). Este recomandată utilizarea Microsoft Excel dacă: sunt suficiente tabelele simple, fără relaţii între ele; se doresc efectuarea de calculi şi comparaţii statistice; setul de date nu depăşeşte de înregistrări Caracteristici generale Primul lucru care se poate observa la deschiderea Microsoft Access este noua interfaţă grafică prietenoasă cu utilizatorul (GUI Graphical User Interface), folosită atât de Access cât şi de toată gama de produse Office De pe bara de meniuri evidenţiem: pagina Home (Views, Clipboard, Font, Rich Text, Records, Sort&Filter, Find) pagina principală Access, conţine funcţii de editări de bază cum ar fi Cut şi Paste, împreună cu marea majoritate a opţiunilor de formatare; pagina Create (Tables, Forms, Reports, Other) grupează toate opţiunile de creare; pagina External Data (Import, Export, Collect Data, SharePoint Lists) conţine toate operaţiile care facilitează colaborarea şi schimbul de date; pagina Database tools (Macro, Show/Hyde, Analyze, Move Data, Database Tools) coloana vertebrală a Access-ului. Aici se pot crea sau menţine relaţiile dintre tabele, se analizează performanţele fişierului şi se execută rutine de întreţinere. Fereastra Access Options furnizează acces rapid la aproape toate opţiunile care pot fi configurabile în Access. Dintre acestea vom evidenţia următoarele opţiuni: Popular: opţiunile cele mai populare printre utilizatori (selectate de Microsoft); Current Database: opţiuni care afectează baza de date curentă, de exemplu, opţiuni pentru adăugarea unui titlu sau a unei icoane, selectarea unui formular care să apară la deschiderea aplicaţiei, dezactivarea opţiunii Layout view, şi o opţiune utilă programatorilor, activarea sau dezactivarea panoului de navigare (Navigation Pane). În 98

95 cadrul acestei opţiuni, utilizatorii pot crea o panglică specială şi o pot folosi în locul celei predefinite; Datasheet: opţiuni de formatare pentru Datasheet View. Utilizând această opţiune, se poate selecta tipul literelor folosite, afişarea liniilor de ghidaj pe formulare şi setarea efectelor implicite ale celulelor; Object Designers: opţiuni care pot fi setate şi afectează modul în care uneltele de design sunt configurate în Access. Opţiunile sunt grupate astfel: Table Design, Query Design, Form Design, Error Checking; Proofing: include opţiuni legate de verificări gramaticale cum ar fi: spell checking, grammar checking, şi auto correction; Advanced: opţiuni care pot fi setate şi care controlează modul în care Access interacţionează cu datele şi utilizatorul cu aplicaţiile. Sunt disponibile următoarele grupuri de opţiuni: Editing, Display, Printing, General, Advanced; Customization: utile pentru a adăuga sau şterge opţiuni de pe panglică. Add-Ins: o listă a utilitarelor add-ins disponibile pentru Access; Trust Center: accesează Trust Center. Mulţi utilizatori setează nivelul de securitate la nivelul minim pentru a evita mesajele care apar atunci când se deschide o bază de date care conţine o macrocomandă. Microsoft recomandă păstrarea nivelului de securitate la valoarea implicită, şi anume funcţionalitate deplină. În Trust Center sunt disponibile două opţiuni: Show the message bar in all applications when content has been blocked şi Never show information about blocked content. Resources: conţine link-uri către resurse online care asistă utilizatorul care lucreză cu Access. Sunt disponibile linkuri la pagina Office, diagnostice interactive Office 2007, help online şi actualizări de software. Există multe opţiuni, controale şi unelte disponibile pentru a ajuta la modificarea programului şi a aplicaţiei fără a fi necesare cunoştinţe de programare Operaţii cu baze de date Pentru a deschide Microsoft Access 2007 se acţionează butonul Start de pe bara de sarcini, se selectează Microsoft Office, apoi Microsoft Office Access

96 Fig. 1 Deschiderea mediului de lucru Microsoft Access 2007 La deschiderea Microsoft Access 2007 pe ecran va apare fereastra Getting Started with Microsoft Office Access. Butonul Office Fig. 2. Fereastra Getting Started with Microsoft Office Access 100

97 În partea din dreapta a ecranului sunt vizibile link-uri către ultimele fişiere de tip bază de date utilizate. În cazul închiderii accidentale a bazei de date, aceasta poate fi deschisă rapid selectând primul link din lista Open Recent Database. Dacă se doreşte modificarea locaţiei implicite de salvare a bazelor de date se selectează butonul Office, se alege opţiunea Access Options, modificând cu ajutorul butonului Browse opţiunea Default database folder. Fig. 3. Modificarea locaţiei implicite în care sunt salvate bazele de date Crearea unei baze de date Pentru a crea o bază de date vidă se alege butonul Blank Database figura 2. Folosind icoana de folder din partea din dreapta a ecranului se alege locaţia unde va fi salvată baza de date, se tastează numele dorit, apoi se apasă butonul Create figura 4. Fig. 4 Stabilirea locaţiei şi a denumirii bazei de date 101

98 Odată cu crearea unei baze de date vide, Microsoft Access crează o nouă tabelă în care să fie salvate datele. Aceasta poarta numele implicit Table1 şi este deschisă în Datasheet View (mod de vizualizare care permite afişarea datelor din tabel). Pentru a crea o tabelă în acest mod de vizualizare se poate studia problema rezolvată Parolarea unei baze de date Pentru a parola baza de date, aceasta trebuie să fie deschisă exclusiv. Pentru aceasta, se închide baza de date folosind butonul Office, opţiunea Close Database figura 5. Fig. 5 Închiderea unei baze de date Pentru a uşura accesul la anumite butoane se poate folosi bara de acces rapid. Pentru a afişa mai multe butoane pe aceasta (în cazul de faţă butonul Open) se apasă săgeata din partea dreaptă a barei, selectându-se comanda Open. Butonul Open va fi afişat pe bara de acces rapid. Analog se pot selecta alte butoane pentru a fi afişate pe bara de acces rapid. Dacă acestea nu sunt afişate implicit, se pot căuta utilizând comanda More Commands. 102

99 Fig. 6 Adăugarea butonului Open pe bara de acces rapid Pentru a deschide exclusiv baza de date creată anterior se apasă butonul Open de pe bara de acces rapid figura 7. Fig. 7 Butonul Open de pe bara de acces rapid În fereastra Open se selectează locaţia, numele bazei de date, apoi de pe butonul Open se selectează opţiunea Open Exclusiv figura 8. Fig. 8 Deschiderea exclusivă a unei baze de date Baza de date fiind deschisă exclusiv, de pe bara de meniuri se alege opţiunea Database Tools, apoi comanda Encrypt with Password figura 9. În fereastra Set Database Password se cere introducerea parolei de două ori, la apăsarea butonului OK baza de date fiind protejată. 103

100 Fig. 9 Parolarea bazei de date Protejarea bazei de date este vizibilă doar la deschiderea acesteia, deci pentru a verifica acest lucru se închide şi se deschide din nou baza de date. Pentru a elimina parola setată la deschiderea bazei de date, aceasta trebuie deschisă exclusiv, selectându-se mai apoi opţiunea Decrypt Database figura 10. Fig. 10 Decriptarea bazei de date În cazul în care panoul de navigare este ascuns, acesta poate fi afişat selectând săgeţile laterale figura 11. Fig. 11 Afişarea/ascunderea panoului de navigare 104

101 Afişarea sau ascunderea panglicii (Ribbon) poate fi controlată folosind opţiunea Minimize the Ribbon de pe bara de acces rapid figura 12. Fig. 12 Minimizarea/afişarea panglicii (Ribbon) Observaţie: Baza de date se salvează automat, dar obiectele conţinute trebuie salvate de către utilizator. Numele bazei de date este setat la începutul creării acesteia. Dacă se doreşte salvarea bazei de date cu alt nume, de pe butonul Office se alege Save as.. urmată de opţiunea Access 2007 Database, specificându-se locaţia şi numele bazei de date Salvarea unei baze de date Pentru a salva o bază de date cu un alt nume, se apelează butonul Office, opţiunea Save as, apoi Access 2007 Database, selectându-se apoi locaţia şi/sau noul nume al fişierului Închiderea unei baze de date Pentru a închide o bază de date, de pe butonul Office se apelează comanda Close Database Deschiderea unei baze de date Pentru a deschide o bază de date se poate folosi lista din partea dreaptă a ecranului, priul link fiind către ultima bază de date utilizată, sau utilizând butonul Office, opţiunea Open Obiectele bazei de date Principalele obiecte conţinute în Microsoft Access 2007 sunt: Tabele (Tables): structuri elementare în care sunt stocate datele în cadrul unei baze de date. Tabelele sunt inima oricărei baze de date. De exemplu, o bază de date legată de fitness poate să reţină informaţii legate de antrenamentul efectuat, echipamentele utilizate şi numărul 105

102 milkshake-urilor consumate în fiecare zi în trei tabele separate. O tabelă este containerul în care sunt stocate datele. Restul obiectelor permit manipularea datelor stocate în tabele. Construirea tabelelor Access se poate rezuma la două activităţi principale: crearea structurii tabelei (în modul de vizualizare Design View) şi popularea tabelului cu date fie în Datasheet View, prin intermediul formularelor sau a instrucţiunilor SQL; Interogări (Queries): sunt structuri care permit efectuarea unei acţiuni rapide asupra unei tabele sau mai multor tabele. Aceste acţiuni implică de obicei obţinerea unei informaţii necesare (de exemplu, cumpărăturile efectuate pe parcursul unei zile cu cardul de credit), sau aplicarea unor modificări. Interogările sunt obiecte virtuale de tip tabelă care nu au corespondent fizic, fiind definite cu ajutorul tabelelor create deja în baza de date. Ele permit efectuarea selecţiilor şi sortărilor în tabele, a calculelor simple şi analizelor încrucişate, a acţiunilor (crearea unui nou tabel, adăugarea, ştergerea sau actualizarea înregistrărilor) sau execuţia unor comenzi SQL. Formulare (Forms) sunt ferestre atractive folosite pentru a consulta sau actualiza datele dintr-un tabel sau o interogare. Ele permit totodată crearea unui meniu interactiv construit de către utilizator, furnizând şi o facilitate specială pentru aceasta (Switchboard). Pe un formular pot fi plasate butoane care pot încorpora comenzi SQL; Rapoarte (Reports) sunt utilizate pentru a tipări unele sau toate informaţiile din tabele sau interogări. Permit gruparea şi sortarea datelor, adăugarea unor câmpuri calculate, numere de pagină, etc; Macrocomenzi (Macros) mini-programe care automatizează sarcinile curente. Macrocomenzile sunt formate dintr-o suită de acţiuni; Module (Modules) fişiere care conţin cod Visual Basic Application. VBA este un mediu de programare orientat obiect. Se pot defini variabile, constante, funcţii şi proceduri globale întregii aplicaţii sau asociate unui anumit obiect. Cu ajutorul acestor coduri se poate executa aproape orice. 5.3 Obiecte Tables Înaintea descoperirii bazelor de date, organizaţiile lucrau cu datele manual. Ei plasau hârtii în dosare şi organizau dosarele în sertare ale unui dulap. Dulapul este echivalentul bazei de date. Fiecare sertar plin de dosare corespunde unui tabel din baza de date. 106

103 Un câmp este o unitate elementară sau o categorie cum ar fi titlurile cărţilor sau numerele de telefon. Un câmp nu conţine în mod necesar o valoare. De exemplu, un câmp numit poate rămâne necompletat dacă furnizorul nu deţine o adresă de . O înregistrare este un set complet de date (câmpuri) care se referă la o persoană, loc, eveniment, idee. De exemplu, pentru un profesor numărul matricol, numele, prezenţa şi nota finală compun o înregistrare. O tabelă, fundaţia oricărei baze de date, este o colecţie de înregistrări care au legătură unele cu altele, şi conţine câmpuri pentru a organiza datele. O coloană reprezintă un câmp, o linie reprezintă o înregistrare. Fiecare înregistrare conţine aceleaşi câmpuri în aceeaşi ordine. Fişierul profesorului cu prezenţele studenţilor este o tabelă care conţine înregistrări despre toţi studenţii având o structură comună. O bază de date constă în una sau mai multe tabele şi obiectele suport care permit introducerea datelor, prelucrarea şi extragerea lor din tabele. baza de date valoarea câmpului înregistrare tabel Fig 13. Bază de date primitivă Definiţie: O cheie primară este un câmp (sau o combinaţie de câmpuri) a cărui valori identifică în mod unic o înregistrare într-un tabel. Cheie primară Câmp Înregistrare valoare Fig. 14 Concepte de bază 107

104 Codul produsului este cheie primară în tabela produse. Cheia primară poate conţine numere, litere, sau o combinaţie a acestora. Puterea bazelor de date relaţionale stă în abilitatea SGBD-ului de a organiza datele şi a le recombina pentru a obţine o imagine completă a evenimentelor descrise. Un design eficient a bazelor de date conectează datele din diferite tabele sub forma unui sistem de legături. Legătura dintre tabele este ca un fir electric care traversează baza de date conectând tabelele astfel încât să permită obţinerea răspunsului la cererea utilizatorului (figura 15). Odată identificat răspunsul, câmpurile şi înregistrările sunt rearanjate astfel încât să poate fi înţelese cu uşurinţă de către utilizator. Capătul de început al firului este creat odată cu setarea cheii primare într-unul dintre tabele. Celălalt capăt la firului este legat de un câmp dintr-un alt tabel. Acel câmp poartă numele de cheie străină. De exemplu câmpul cod_f (cod furnizor) din tabela furnizori este un câmp de tip cheie străină. Definiţie: O cheie străină este un câmp dintr-o tabelă, care într-o altă tabelă este cheie primară. Fig. 15 Fereastra Relationships După cum se poate observa din figura 15, chiar şi în relaţia normalizată încă mai există redundanţe. De exemplu, codul produsului (cod_p) apare în mai multe tabele. De fapt nu pot fi eliminate toate câmpurile duplicate şi în acelaşi timp menţinute legăturile dintre tabele. Acest tip de redundanţă (cheie primarăcheie străină) poartă numele de redundanţă necesară. Orice legătură dintre două tabele poată fi întărită utilizându-se regulile de integritate referenţială. Integritatea sugerează încredere. Atunci când regulile de integritate sunt stabilite, utilizatorul poate avea încredere în firul care leagă tabelele bazei de date, fiind păstrată acurateţea datelor. Regulile de tip cascadă permit ca modificările datelor să se perpetueze dintr-o tabelă în alta figura

105 Definiţie: Regula Cascade Update Related Records va fi setată în cazul în care dacă o valoare a câmpului pe care este setată cheia primară este modificată, atunci toate valorile corespunzătoare din tabela referită sunt modificate automat cu aceeaşi valoare. Regula Cascade Delete Related Records va fi setată în cazul în care dacă o valoare din tabela de referinţă este ştearsă prin ştergerea înregistrării care o conţine, atunci toate înregistrările din tabela referită care conţin acea valoare referită vor fi automat şterse. Fig. 16 Setarea regulilor de integritate referenţială Legăturile dintre tabele în Microsoft Access 2007 sunt de mai multe tipuri: One-to-Many (unu-la-mai-mulţi) această legătură se crează între o cheie primară dintr-un tabel şi o cheie străină din alt tabel. În prima tabelă există o singură înregistrare care conţine o valoare a câmpului de tip cheie primară. În cea de-a doua tabelă există mai multe înregistrări care conţin în câmpul comun aceeaşi valoare a câmpului comun. One-to-One (unu-la-unu) se crează între două tabele care au aceeaşi cheie primară sau un câmp de tip cheie primară în prima tabelă şi un câmp cheie străină pe care este setat un index Unique din a doua tabelă. În acest caz în ambele tabele există o singură înregistrare cu valoarea câmpului comun identică. Acest tip de relaţie se foloseşte foarte rar, în special datorită necesităţii menţinerii securităţii datelor din tabele. Many-to-Many (mai-mulţi-la-mai-mulţi) acest tip de relaţie este construită artificial (nu există în Access) şi corespunde mai multor valori ale câmpului comun din ambele tabele. În acest caz este necesară construirea unui nou tabel numit tabel de joncţiune. Într-o bază de date bine definită, relaţia de tip one-to-many este cel mai frecvent întâlnită. Pentru a crea un nou tabel, de pe panglică, opţiunea de meniu Create, se selectează Table Design. Design View este un mod de vizualizare care oferă cele mai puternice opţiuni pentru definirea unei tabele. 109

106 Atunci când se proiectează o tabelă este importantă cunoaşterea operaţiilor de bază care pot fi efectuate cu câmpurile acesteia: pentru adăugarea unui nou câmp între alte câmpuri existente se poziţionează cursorul pe câmpul deasupra căruia se doreşte adăugarea unui nou câmp, se apelează meniul contextual (clic cu butonul din dreapta al mouse-ului) şi se alege opţiunea Insert Rows; mutarea unui câmp un câmp poate fi mutat folosind drag-and-drop, selectându-se pătratul gri din stânga numelui câmpului şi repoziţionându-se câmpul în poziţia dorită; ştergerea unui câmp se apelează meniul contextual al pătratului gri din stânga numelui câmpului şi se selectează Delete Rows. De reţinut faptul că odată cu ştergerea unui câmp se şterg toate datele depozitate în acel câmp, acţiunea nefiind reversibilă, de aceea Access afişează un mesaj pentru a preveni eventualele ştergeri accidentale. Fiecare câmp are un nume (Field Name) cu ajutorul căruia sunt identificate datele introduse în acel câmp. Numele câmpului trebuie să fie descriptiv pentru datele conţinute şi poate conţine maxim 64 de caractere incluzând litere, cifre şi spaţii. Este interzisă utilizarea caracterelor.,!, [, şi ], iar numele câmpului nu poate începe cu cu spaţiu. Fiecare câmp este definit ca fiind de un anumit tip (Data Type), care determină valorile care pot fi introduse şi operaţiile care pot fi efectuate cu datele. Access recunoaşte 10 tipuri de date: Text date alfanumerice cele mai multe caractere care se află pe tastatură (incluzând numere), cu limita maximă de 255 de caractere. Câmpurile care conţin doar numere care nu sunt folosite pentru a efectua calcule ar trebui setate ca fiind de tip Text (numere de telefon, coduri poştale, numărul cărţii de identitate, numărul de paşaport); Number conţine o valoare care poate fi folosită în calcule, ca de exemplu numărul creditelor pe care le are un student. Conţinutul câmpului de tip Number este restricţionat la numere, virgula zecimală şi simbolurile + şi -: Byte numere între 1 şi 255 (ocupă 1 byte); Integer numere în intervalul [-32768,+32757] (ocupă 2 bytes); Long Integer [ , ] (ocupă 4 bytes); Single numere reprezentate în simplă precizie: [-3.40*10 38,3.40*10 38 ] (ocupă 4 bytes şi are precizie de 7 zecimale); 110

107 Double numere reprezentate în dublă precizie, [-1.797*10 308, 1.797* ] (ocupă 8 bytes şi are precizie de 15 zecimale); Replication ID GUID (Global Unique IDentifier) identificator unic global, (ocupă 16 bytes) este folosit pentru un câmp care este sau compun un câmp de tip cheie străină corespondentul unui câmp de tip cheie primară Autonumber; Decimal [-10 28, ] (ocupă 12 bytes şi implicit are o precizie de 18 zecimale care poate să crească până la 28 de zecimale). Memo blocuri mari de text de lungime maximă caractere. Câmpurile de tip Memo sunt utilizate pentru a păstra date descriptive (propoziţii, paragrafe). Lungimea maximă este de is 2 GB. Date/Time conţine date calendaristice formatate, ore, sau ambele, permiţând calcule aritmetice cu acestea. Anii din datele calendaristice sunt în intervalul dintre anii 100 şi Datele sunt salvate sub formă de număr pe 8 bytes, cu dublă precizie; Currency numere cu 4 zecimale urmate de simbolul monetar, cu care pot fi efecuate calcule. Ocupă 8 bytes şi sunt utilizate pentru calcule financiare, dacă nu se doreşte rotunjirea valorilor; AutoNumber un număr care este incrementat automat pentru fiecare înregistrare. Valoarea unui câmp de tip Autonumber este unică pentru fiecare înregistrare din tabel, de aceea tipul Autonumber se utilizeză în mod frecvent ca tip de date al unui câmp cheie primară. Numărătoarea poate fi secvenţială sau întâmplătoare (random). Valoarea acestuia nu poate fi modificată şi ocupă 4 bytes; Yes/No permite alegerea unei valori din 2 posibile, o informaţie discretă care poate avea doar două valori cum ar fi: True/False, Yes/No, On/Off, (ocupă 1 byte); OLE Object conţine un obiect creat cu o altă aplicaţie, cum ar fi Microsoft Excel, Microsoft Word sau poze. Dimensiunea maximă a fişierului este de 2GB, dar baza de date este încetinită considerabil prin înglobarea obiectelor externe; Hyperlink utilizat pentru a stoca adrese Web (URL Uniform Resource Locators). Toate fişierele din suita Office permit facilităţi Web dacă se selectează un link, automat este afişată pagina Web asociată (1 GB); Attachment cel mai nou tip de date introdus doar în MS Access 2007, permite ataşarea mai multo obiecte create cu alte aplicaţii. Măreşte flexibilitatea bazei de date prin utilizarea technicilor OLE (Object Linking and Embedding=Legare şi Încorporare de Obiecte); 111

108 Lookup Wizard este utilizat pentru valori care vor fi completate selectând o valoare dintr-o casetă combinată. Nu este un tip de date propriu-zis, ci un program utilitar care crează relaţii cu tabela părinte sau o listă definită de utilizator. Pentru a crea o legătură între tabele, se va crea tabela de referinţă cu cheia primară, se inserează date în tabelă, apoi se crează tabela referită, iar pentru câmpul care va fi cheie străină se va selecta opţiunea Lookup Wizard, cu prima opţiune I want the lookup column to lookup the values in a table or query; se selectează numele tabelei de referinţă, câmpul de tip cheie primară din tabela de referinţă şi ordinea de sortare. Atunci când se introduc date în câmpul de tip cheie străină din tabela referită se utilizează caseta combinată creată cu ajutorul opţiunii Lookup Wizard, selectându-se din valorile din listă. Dacă se doreşte crearea unei liste predefinite de către utilizator, se va selecta Lookup Wizard cu a doua opţiune I will type in the values that I want, apoi se vor insera toate valorile pe o coloană. Atunci când se inserează datele în câmpul respectiv, se utilizează caseta combinată creată automat de către Lookup Wizard. Description este o coloană opţională care se utilizeză dacă se doreşte afişarea descrierii câmpului pe bara de stare atunci când câmpul este selectat (activ). O proprietate este o caracteristică sau un atribut care determină cum va arăta şi cum se va comporta obiectul. Fiecare obiect Access are o mulţime de proprietăţi. Proprietăţile tabelei sunt afişate şi pot fi modificate în fereastra Property Sheet. Aceasta se găseşte pe panglică, în modul de vizualizare Design View, opţiunea de meniu Design. Fiecare câmp are o mulţime de proprietăţi. Proprietăţile sunt setate pe valoarea implicită în concordanţă cu tipul de date selectat, dar pot fi modificate. Ele sunt afişate în modul de vizualizare Design View, în partea de jos a ecranului. Field Size (dimensiunea câmpului) ajustează dimensiunea unui câmp de tip text sau limitează valoarea permisă într-un câmp de tip numeric. Microsoft Access utilizează doar cantitatea de spaţiu de stocare necesară, chiar dacă dimensiunea câmpului permite o dimensiune mai mare. Multe SGBD-uri folosesc tot spaţiul specificat ca dimensiune a cîmpului. De aceea, este utilă crearea obişnuinţei de a reduce dimensiunea spaţiului cu scopul ajustării la cerinţele de stocare ale sistemului (optimizarea spaţiului de stocare); 112

109 Decimal Places specifică numărul de zecimale. Valoare predefinită este Auto sunt afişate toate zecimalele rezultate în urma calculelor, dar nu mai mult de 15 zecimale; Format modifică modul de afişare al valorii unui câmp, dar nu afectează valoarea stocată; pentru unele tipuri de date cum ar fi Number, Date/Time şi Yes/No se poate alege formatul dorit dintr-o listă; pentru câmpuri de tip Number pot fi afişate valori pozitive, negative, zero sau valoarea Null folosind caractere speciale (0, #, $, %, E+, E-, e+, e-); pentru câmpuri de tip Date/Time: se utilizează următoarele caractere (d zi între 1 şi 31, dd zi între 01 şi 31, ddd primele 3 litere în engleză din numele zilei (de exemplu, Mon de la Monday pentru ziua de Luni), dddd numele întreg al zilei, etc ); pentru câmpuri de tip Text:! dacă se introduc numere; < litere mici; > majuscule; text textul va apărea exact cum este scris: text crează grupuri de cum ar fi Input Mask facilitează introducerea datelor afişând caractere care nu sunt stocate, cum ar fi caracterul slash într-o dată calendaristică (/). De asemenea, asigură validarea datelor pentru a corespunde formatului ales (de exemplu, previne introducerea unei cifre în plus sau în minus în cazul unui număr de telefon); 0 o cifră obligatorie între 0 şi 9; 9 o cifră opţională între 0 şi 9; A o literă sau o cifră obligatorie; a o literă sau o cifră opţională; # o cifră opţională între 0 şi 9 sau un spaţiu opţional; & orice caracter sau spaţiu; C un caracter opţional sau un spaţiu L o literă obligatorie de la A la Z;? o literă opţională de la A la Z; > litere care vor fi transformate în majuscule; < litere care vor fi transformate în majuscule. Când ambele proprietăţi sunt setate, (Format şi Input Mask), Format este cea impusă (are prioritate). 113

110 Caption specifică o etichetă diferită faţă de numele câmpului, care va fi afişată în DataSheet View în capul de tabel, pe formulare şi rapoarte. Lungimea maximă a valorii introduse în Caption este 2084 caractere. Valoarea proprietăţii Caption nu are nici o semnificaţie în cadrul interogărilor sau când se utilizează cod în Visual Basic Application; Default value introduce automat o valoare predefinită pentru câmpul respectiv atunci când o nouă înregistrare este inserată într-un tabel. De exemplu, dacă foarte mulţi dintre studenţi sunt născuţi în Timişoara, valoarea proprietăţii Default Value poate fi modificată în Timişoara; Validation Rule respinge orice înregistrare pentru care valoarea introdusă în câmpul respectiv nu respectă regula stabilită. Expresia poate fi tastată în interiorul casetei de text, sau se poate selecta butonul pentru a deschide fereastra Expression Builder. Această proprietate nu poate fi folosită pentru tipuri de date cum ar fi: Autonumber, OLE Object, Attachment, Number cu sub-tipul Replication ID. Pentru a construi o regulă de validare pot fi folosite funcţii Access, operatori şi constante. Numele câmpului trebuie să apară între paranteze drepte, de exemplu [cod produs]. Exemple de reguli de validare: >200 and <=400 pentru un câmp numeric; <>NULL, IS NOT NULL pentru orice fel de câmp; Timisoara pentru un câmp de tip Text; >=#03/12/2011# pentru o dată calendaristică; >=Date() pentru o dată calendaristică; Year([data factura])=year(date()) unde fucţia Year extrage anul dintr-o dată calendaristică (în acet caz câmpul data facturii), iar funcţia Date() extrage data curentă; Validation Text specifică mesajul de eroare care va fi afişat în cazul în care regula de validare nu este respectată; Required dacă este setată pe Yes, respinge orice înregistrare care nu conţine o valoare în câmpul respectiv; valoarea predefinită este No; Allow Zero Length dacă este setată pe Yes, permite şirul de lungime zero în cazul câmpurilor de tip text sau memo; valoarea predefinită este No; Indexed măreşte eficacitatea căutărilor în acel câmp (câmpul pe care este setată cheia primară este întotdeauna indexat): No nu este setat nici un index; Yes (No Duplicates) este setat un index care nu permite duplicarea valorilor, ca în cazul CNP-ului, de exemplu. Este valoarea care apare atunci când se setează cheia primară; 114

111 Yes (Duplicates Ok) este setat un index care permite duplicarea valorilor, ca în cazul numelui pacientului, de exemplu. Indecşii mai pot fi definiţi şi prin intermediul butonului Indexes de pe panglică figura 17. Se poate seta numele indexului (Index Name), câmpul pe care acesta va fi setat (Index Field), şi ordinea de sortare (Sort Order), specificându-se pentru fiecare index tipul acestuia: Primary (dacă se doreşte crearea unui index de tip Primary Key), Unique (crearea unor chei candidate cu valori unice) sau Ignore Null (crearea unui index care ignoră valorile Null). Fig. 17 Fereastra Indexes Unicode Compression pentru câmpurile Text, Memo şi Hyperlink, are valoarea implicită setată pe Yes şi este folosită pentru a eficientiza modul de stocare a datelor; IME Mode and IME Sentence Mode specifică modul Input Method Editor cu opţiunea implicită No Control pentru versiunea în engleză şi tipul de dată pentru modul Input Method; Smart Tags pentru utilizatorii avansaţi, permite adăugarea butoanelor de acţiune asociate unui câmp. Atunci când o bază de date oferă produse la ofertă, un buton de tip Smart Tag încorporat câmpului nume produs ar putea deschide un fişier de inventar pentru a vizualiza produsele din stoc; Text Align aliniază textul, furnizând următoarele opţiuni: General (aliniere predefinită), Left (aliniere la stânga), Center (aliniere centrată), Right (aliniere la dreapta) şi Distributed (aliniere şi la stânga şi la dreapta). Datasheet View este utilizat pentru inserarea datelor în tabele. Vizualizarea de tip Pivot Table View furnizeză un mod convenabil de sumatizare şi organizare a datelor în grupuri de înregistrări. Vizualizarea Pivot Chart View afişează un 115

112 grafic asociat modului de vizualizare Pivot Table View. Pentru a trece de la un mod de vizualizare la altul, se poate utiliza fie butonul View de pe panglică, opţiunea de meniu Home, fie butonul corespunzător de pe bara de stare (Status bar). O tabelă poate fi deschisă din panoul de navigare direct în modul de vizualizare dorit apelându-se meniul contextual al tabelei şi selectându-se modul de vizualizare dorit. 5.4 Obiecte Queries Interogarea este un obiect ce permite vizualizarea informaţiilor din una sau mai multe tabele pe baza unor criterii de selecţie. Microsoft Access prevede o interfaţă prietenoasă cu utilizatorul, de tip QBE (Query By Example) pentru a construi o interogare. Rezultatul unei interogări este o foaie de răspuns dinamică care poartă numele de Dynaset. Aceasta este volatilă (dispare odată cu închiderea interogării). Cu ajutorul unei interogări pot fi grupate datele din mai multe tabele, pe baza leagăturilor create între ele, pot fi create noi câmpuri calculate, dar pot fi efectuate şi următoarele acţiuni: crearea unui nou tabel, adăugarea înregistrărilor din alt tabel, modificarea valorii câmpurilor sau ştergerea înregistrărilor. Interogările se crează de obicei în modul de vizualizare Query Design. Pentru a vedea rezultatul interogării, se trece în modul de vizualizare Datasheet View sau se apasă butonul Run de pe panglică, opţiunea de meniu Design. O altă modalitate de a crea o interogare este folosind modul de vizualizare SQL View. Această metodă necesită cunoştinţe de SQL (Structured QueryLanguage) detaliate în capitolul următor. Interogările sunt de mai multe tipuri: de selecţie (SELECT) permit afişarea datelor din una sau mai multe tabele, pe baza unor criterii de selecţie, calcularea unor câmpuri şi afişarea datele ordonate după anumite câmpuri crescător sau descrescător; de sintetizare a datelor (TOTAL) permit selectarea unor câmpuri ca criterii de grupare, fiind aplicate diverse funcţii: SUM, MIN, MAX, COUNT, etc; de analiză încrucişată (CROSSTAB) de analiză încrucişată a datelor; de acţiune (MAKE TABLE, APPEND, UPDATE, DELETE); speciale (UNION, PASS THROUGH, DATA DEFINITION). Cel mai des întâlnite şi utilizate sunt interogările de selecţie. 116

113 Interogări de selecţie Pentru a crea o interogare, de pe panglică, opţiunea de meniu Create, se apasă butonul Query Design. Fig. 18 Fereastra QBE În fereastra Show Table se va preciza sursa datelor executând dublu-clic pe numele tabelei sau tabelelor figura 18. De reţinut că dacă se selectează mai multe tabele, trebuie specificate toate tabele intermediare pentru a fi vizibile legăturile dintre ele în caz contrar rezultatul interogării nu este cel dorit. După închiderea ferestrei, dacă se doreşte redeschiderea ferestrei pentru a adăuga o nouă tabelă, se selectează butonul cu acelaşi nume de pe panglică. Dacă se doreşte ştergerea unei tabele, se apelează meniul contextual asociat acesteia, selectându-se comanda Delete. După ce tabelele au fost selectate, ferestra Show Table se închide. Următorul pas este selectarea câmpurile din tabele. Se execută dublu clic pe numele de câmpurilor din tabele, acestea fiind selectate automat în partea de jos a ecranului, find completate liniile Field şi Table. Linia Sort permite ordonarea valorilor câmpurilor în ordine crescătoare (Ascending) sau descrescătoare (Descending). Pe linia Show sunt selectate implicit toate câmpurile ca fiind vizibile. Dacă se doreşte ascunderea unui câmp din vizualizarea finală, se debifează check-box-ul corespunzător. Liniile Criteria şi Or permit impunerea unor condiţii. Dacă operatorul dintre condiţii este AND, atunci toate condiţiile se scriu pe linia Criteria. Dacă între condiţii operatorul este OR, atunci a doua condiţie se scrie pe linia Or. Pentru a vizualiza rezultatul interogării se trece de pe bara de stare în Datasheet View. 117

114 Dintre operatorii folosiţi în construirea expresiilor de pe linia Criteria amintim: + (adunare), - (scădere), * (înmulţire), / (împărţire), MOD (restul împărţirii a două numere), ^ (ridicarea la putere, de exemplu x 2 se scrie x^2), & (concatenare a două şiruri de caractere), = (verifică egalitatea a două valori), <> (operatorul diferit, de exemplu ), < (strict mai mic), > (strict mai mare), <= (mai mic sau egal), >= (mai mare sau egal), LIKE (format general LIKE masca, de exemplu nume LIKE A* se vor afişa toate numele care încep cu A, indiferent din câte caractere, dar LIKE A?? va afişa doar numele care începe cu A şi are lungimea de trei caractere), IN (formatul general IN (listă de valori), de exemplu condiţia: sex IN ( m, f ) sau [tip client] IN ( persoana fizica, persoana juridica )), BETWEEN (format general Between Val_minimă AND Val_maximă, de exemplu, dacă se doreşte afişarea studenţilor cu note între 9 şi 10 se va utiliza condiţia BETWEEN 9 AND 10), NOT (negaţie), AND (conjuncţie), OR (disjuncţie), NOT NULL (va afişa toate înregistrările care nu au valori introduse în acel câmp), Date() (returnează data curentă), MONTH (afişează luna dintr-o dată calendaristică, de exemplu MONTH(# #) va returna valoarea 12), YEAR (afişează anul dintr-o dată calendaristică, de exemplu YEAR(# #) va returna valoarea 2011), IIF (cu formatul general IIF (condiţie, val_dacă_adevarat, val_daca_fals), de exemplu dacă se doreşte afişarea situaţiei bursierilor: pentru studenţi care au media peste 9,50 se va afişa bursă de merit, celor între 8 şi 9,50 bursă de studiu iar celorlaţi nimic, se va scrie următoarea condiţie: IIF ([media]>9,5; bursa de merit ; IIF([media] BETWEEN 8 AND 9,50; Bursa de studiu ; )) ) şi multe altele. Simbolul ; care desparte argumentele funcţiei depinde de setările regionale. Setările regionale utilizate în cadrul aceszui capitol sunt cele corespunzătoare României (Control Panel, Clock Language and Region, Change Location, pagina Location, Current Location: Romania). Data calendaristică este astfel formatată ca dd.mm.yyyy, iar punctul zecimal este simbolul virgulă. În cazul în care este selectată o altă locaţie, atât separatorul care desparte argumentele funcţiei, simbolul zecimal, formatul Currency cât şi formatele Date/Time sunt modificate în consecinţă. Dacă se doreşte adăugarea unui câmp care va fi calculat după o formulă, se selectează prima coloană liberă în Design View, iar pe linia Field se tastează numele care se doreşte să apară în capul de table ca titlul al coloanei respective, urmat de simbolul : şi formula de calcul. Numele de câmpuri se scriu între paranteze drepte. De exemplu: Valoare: [cant]*[pret]. Dacă se doreşte formatarea câmpului (de exemplu, Currency), în Design View se apelează meniul contextual pe câmpul proaspăt construit, se selectează Properties, apoi la proprietatea Format se selectează Currency. 118

115 Interogări cu parametru În cazul interogărilor de selecţie se pot utiliza parametrii. Dacă se doreşte citirea interactivă de la tastatură a unei valori a unui câmp, în vederea verificării unui criteriu şi a afişării datelor din tabelă/tabele, pe linia Criteria se introduce între paranteze drepte un text, de exemplu [Introduceti data facturii]. Acest text va fi interpretat ca un parametru, construindu-se automat pentru acest parametru o casetă de introducere a valorii. Va fi evaluată valoarea citită de la tastatură, se verifică egalitatea cu valorile din câmpul pe care este plasat parametrul, şi anumte [data facturii], şi sunt afişate înregistrările care verifică condiţia [data facturii]=valoarea introdusă de la tastatură Interogări de sintetizare a datelor Interogarea de selecţie poate fi transformată într-o interogare de sintetizare a datelor apelîndu-se butonul Totals de pe panglică. Aceasta are ca efect crearea unei linii noi denumită Total, unde automat apare condiţia Group by. Pentru a crea o interogare de sintetizare a datelor: 1. se crează o interogare în Design View; 2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe numele tabelelor, neapărat acestea trebuie să fie toate legate între ele), apoi se închide fereastra Show Table; 3. se selectează câmpurile după care se grupează datele şi câmpurile care trebuie calculate (de exemplu dacă se doreşte afişarea mediei anului, se aleg câmpuri an şi medie; dacă se doreşte afişarea medie studenţilor pe grupe, se aleg câmpurile an, grupa şi medie); 4. se selectează butonul Totals. Pe linia Totals vor apare opţiunile Group By utilizate pentru a defini grupurile de înregistrări asupra cărora se vor executa funcţii agregat (SUM, MIN, MAX, COUNT, AVG, etc); 5. pe coloana/coloanele care se doresc a fi calculate şi linia Totals se alege o funcţie de agregare sau condiţia WHERE care permite impunerea unor criterii suplimentare. Toţi operatorii amintiţi mai sus pot fi folosiţi în clauza Where; 6. dacă se doreşte ascunderea unor câmpuri, se deselectează caseta corespunzătoare de pe linia Show; 7. pentru a vizualiza rezultatul se apelează opţiunea Datasheet View. 119

116 5.4.3 Interogări de acţiune Interogările de acţiune sunt nu au ca efect afişarea unui rezultat, ele au un alt scop: manipularea datelor din tabele. Operaţiile care pot fi executate cu ajutorul interogărilor de acţiune sunt: Make Table, Append, Update şi Delete. Pentru ca toate aceste interogări de acţiune să poată fi executate, este necesară setarea unui nivelul de securitate mai scăzut prin selectarea butonului Options de pe bara Security Warning, selectându-se opţiunea Enable this content Interogări pentru crearea unei noi tabele (MAKE TABLE) Interogările care crează o nouă tabelă sunt utilizate de obicei pentru a obţine un tabel unic cu date din mai multe tabele legate între ele. Pentru a crea o interogare de tip Make Table se parcurg următorii paşi: 1. se crează o interogare în Design View; 2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra Show Table; 3. se selectează câmpurile dorite, se ordonează datele, se adăugă condiţii; 4. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în Design View; 5. se transformă interogarea de selecţie într-una de acţiune selectându-se butonul Make Table de pe panglică. În fereastra Make Table se va tasta numele noului tabel care va fi creat figura 19; 6. se va salva interogarea: 7. se execută interogarea prin apăsarea butonului Run de pe panglică. Observaţie: Dacă se doreşte deschiderea interogării pentru modificare, se apelează meniul contextual ataşat interogării din panoul de navigare, apoi se alege Design View. De fiecare dată când interogarea este apelată, tabela este rescrisă. 120

117 Fig. 19 Interogare de tip Make Table Se observă că icoana asociată interogării de tip Make Table este diferită faţă de cea asociată interogărilor de selecţie Interogări pentru actualizarea datelor (UPDATE) Interogările care permit actualizarea datelor sunt folosite pentru a efectua anumite calcule asupra unor câmpuri din tabele (de exemplu, se măreşte preţul pâinii cu 2%). Pentru a crea o interogarea de tip Update se parcurg următorii paşi: 1. se crează o interogare în Design View; 2. se selectează sursa datelor (din fereastra Show Table, dublu-clic pe numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra Show Table; 3. se selectează câmpul a cărui valoare trebuie modificată şi cel ce limitează modificarea la anumite înregistrări (în acest caz, câmpul denumirea produsului pe care se va seta condiţia pe linia Criteria (= paine, şi câmpul pret, căruia i se va modifica valoarea în urma interogării); 4. se transformă interogarea de selecţie într-una de acţiune selectându-se butonul Update de pe panglică. În fereastra QBE va apare o nouă linie numită Update To. Pe acea linie, sub pret se va scrie formula de calcul: [pret]+[pret]*2/100; 5. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în Design View; 6. se salvează interogarea; 7. se execută interogarea prin apăsarea butonului Run de pe panglică. 121

118 Observaţie: Dacă se doreşte deschiderea interogării pentru modificare, se apelează meniul contextual ataşat interogării din panoul de navigare, apoi se alege Design View. De fiecare dată când interogarea este apelată, valoarea câmpului este modificată. Se observă că icoana asociată interogării de tip Update este diferită faţă de cea asociată interogărilor de selecţie şi de cea a interogării de tip Make Table Interogări pentru adăugarea datelor din alte tabele (APPEND) Interogările de acest tip permit adăugarea unor înregistrări din alte tabele care au în componenţă câmpuri de acelaşi tip. Pentru a crea o interogarea de tip Append se parcurg următorii paşi: 1. se crează o interogare în Design View; 2. se selectează sursa datelor tabelul sursă, de unde se doreşte transferul datelor în celălalt tabel (din fereastra Show Table, dublu-clic pe numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra Show Table; 3. se selectează câmpurile care se doresc a fi trimise într-o altă tabelă. În acea tabelă vor trebui să existe câmpuri de acelaşi tip cu cele selectate la acest pas; 4. se selectează o ordine de sortare a înregistrărilor şi/sau se completează liniile Criteria şi Or (dacă este cazul); 5. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în Design View; 6. se transformă interogarea de selecţie într-una de acţiune selectându-se butonul Append To. Se selectează numele tabelei destinaţie. Se observă adăugarea unei noi linii în fereastra QBE, cu numele Append To. Dacă numele câmpurilor din cele două tabele diferă, celula corespunzătoare din tabela destinaţie, de pe linia Append to, va rămâne necompletată. Ea poate fi completată utilizându-se caseta combinată, alegând numele câmpului dorit din tabela destinaţie; 7. se salvează interogarea; 8. se execută interogarea prin apăsarea butonului Run de pe panglică. Aceeaşi observaţie este valabilă ca şi la interogarea de tip Update. Totodată, icoana asociată acestui tip de interogare este diferită de celelalte. 122

119 Interogări pentru ştergerea înregistrărilor (DELETE) Acest tip de interogare se utilizează pentru a şterge automat anumite înregistrări din una sau mai multe tabele. Pentru a crea o interogarea de tip Delete se parcurg următorii paşi: 1. se crează o interogare în Design View; 2. se selectează sursa datelor tabelul sursă, de unde se doreşte ştergerea datelor (din fereastra Show Table, dublu-clic pe numele tabelelor, acestea fiind legate între ele), apoi se închide fereastra Show Table; 3. se selectează câmpul/câmpurile care conţin valorile care compun condiţia de ştergere; 4. se completează liniile Criteria şi Or (dacă este cazul în caz contrar vor fi şterse toate înregistrările din tabela sau tabelele respective); 5. se transformă interogarea de selecţie într-una de acţiune selectându-se butonul Delete. Pe linia Delete va apare clauza Where, care permite construirea condiţiei de ştergere ; 6. se verifică trecând în Datasheet View rezultatul dorit, apoi se revine în Design View; 7. se salvează interogarea; 8. se execută interogarea prin apăsarea butonului Run de pe panglică. Aceeaşi observaţie este valabilă ca şi la interogarea de tip Append. Icoana asociată acestui tip de interogare este diferită de celelalte. Observaţie: În cazul ştergerii înregistrărilor din mai multe tabele, aceasta poate fi împiedicată datorită setării regulilor de integritate referenţială (dacă în fereastra Relationship, fiind selectată legătura dintre tabele, este selectată caseta Enforce Referential Integrity iar Cascade Delete Related Records nu este bifată). 5.5 Obiecte Forms Formularul este un obiect al bazei de date care permite vizualizarea, modificarea sau introducerea a noi informaţii în tabela pe baza căruia a fost creat. Pe un formular pot fi adăugate următoarele tipuri de controale: legate: sunt create pe baza unui tabel, a mai multor tabele sau a unei interogări, permit vizualizarea înregistărilor, actualizarea valorilor câmpurilor sau adăugarea unor câmpuri calculate; 123

120 nelegate: destinate creării unui meniu, afişării unor mesaje, informaţii despre sistem, etc. Formularele pot fi create utilizând butoanele de pe panglică. Vom prezenta în continuare crearea formularelor cu ajutorul butoanelor Form, Form Wizard şi Design Form Formulare create cu ajutorul butonului Form Pentru a crea un formular, se selectează din panoul de navigare numele tabelei sau interogării care va conţine sursa datelor. Dacă tabelul este tabel de referinţă pentru mai multe alte tabele sau este tabel referit de alte tabele (copil) atunci Access va crea automat un formular cu layout-ul Columnar (este afişat conţinutul unei singure înregistrări la un moment dat) figura 20. Pentru a vizualiza toate înregistrările se poate utiliza bara de navigare Record aflată în partea de jos a formularului, utilizându-se butoanele Next Record (trecerea la următoarea înregistrare), Previous Record (trecerea la înregistrarea anterioară), First Record (trecerea la prima înregistrare), Last Record (trecerea la ultima înregistrare), New (Blank) Record (adăugarea unei noi înregistrări) şi Search. Fig. 20 Formularul Furnizori Dacă tabelul este tabel de referinţă pentru un singur tabel, atunci Access va crea automat un formular cu subformular, afişând în subformular doar acele înregistrări din tabela referită care verifică condiţia ca valoarea cheie străină este egală cu valoarea afişată în câmpul cheie primară din tabela de referinţă afişată în formular. Pentru tabela de referinţă layout-ul formularului este Columnar (este afişată o singură înregistrare la un moment dat), iar pentru sub- 124

121 formular layout-ul este Tabular (sunt afişate toate înregistrările care verifică condiţia de legătură) figura 21. Totodată câmpul cheie străină (din tabelul referit) este ascuns (nu este necesară afişarea aceluiaşi câmp de mai multe ori în cadrul unui formular). Se observă că pentru fiecare formular apare câte o bară de navigare Record. Cea mai de jos este pentru datele din tabelul de referinţă (părinte), cea din interior va fi pentru datele din tabelul referit (copil). Pentru a naviga prin înregistrări se utilizeză bara corespunzătoarelor formularului creat pentru tabelul de referinţă. Fig. 21. Formular cu sub-formular Modul de afişare afişat implicit va fi Form View. Dacă se doreşte, se poate trece la Design View pentru a modifica proprietăţile controalelor de pe formular cu ajutorul butonului View de pe panglică Formulare create cu ajutorul butonului Form Wizard Access 2007 pune la dispoziţia utilizatorilor un asistent care permite crearea rapidă a înregistrărilor urmând anumiţi paşi. Pentru a utiliza butonul Form Wizard este necesară selectarea butonului More forms de pe panglică, opţiunea de meniu Create figura

122 Fig. 22 Selectarea butonului Form Wizard Pentru a crea un formular utilizând Form Wizard trebuie parcurşi următorii paşi: se selectează sursa datelor numele tabelului sau a interogării pe baza căruia se doreşte crearea formularului şi a câmpurilor care se doreşte să apară pe formular figura 23, apoi se apasă butonul Next; Fig. 23 Selectarea sursei formularului se selectează layout-ul formei (modul în care sunt aranjate înregistrările pe formulare; Columnar şi Justified afişează o singură înregistrare la un moment dat, Tabular şi Datasheet afişează toate înregistrările la un moment dat) figura 24, apoi se apasă butonul Next; Fig. 24 Alegerea Layout-ului formularului 126

123 se alege stilul (combinaţiile de culori şi obiectele grafice de pe formular) figura 25, apoi se apasă butonul Next; Fig. 25 Alegerea stilului formularului se alege un titlu pentru formular şi modul de vizualizare al acestuia, în cazul de faţă deschiderea în modul de vizualizare Form View (Open the form to view or enter information) figura 26, apoi se apasă butonul Finish. Fig. 26 Crearea unui titlu şi deschiderea formularului în modul Form View Formularul astfel creat va arăta ca în figura 27. Fig. 27 Formularul Furnizori1 în Form View 127

124 Orice formular conţine următoarele zone figura 28: Form Header antetul formularului, utilizat pentru afişarea unui titlu, sigla unei companii, data întocmirii; Detail zona în care sunt amplasate controalele corespunzătoare înregistrărilor din tabelul sau interogarea sursă; Form Footer: subsolul formularului, utilizat pentru comentarii, semnături, numărul paginii, butoane de comandă. Fig. 28 Formularul Furnizori1 în Design View Pentru a activa zonele Form Header/Footer se apelează meniul contextual al formularului, selectându-se opţiunea cu acelaşi nume Formulare create cu ajutorul butonului Form Design Pentru a creea un formular cu ajutorul butonului Form Design se parcurg următorii paşi: 1. se selectează butonul Form Design de pe panglică, opţiunea de meniu Create figura 29; Fig. 29 Un formular gol în Design View 128

125 2. de pe panglică, opţiunea de meniu Design, se selectează butonul Property Sheet. În fereastra cu acelaşi nume, în cadrul casetei combinate Selection Type se alege obiectul Form. De pe pagina All, apelând săgeata din dreptul casetei Record Source numele tabelei pe baza căreia se va creea formularul: de exemplu furnizori figura 30; Fig. 30 Selectarea sursei formularului 3. se selectează butonul Add Existing Fields iar din fereastra Field List se execută dublu-clic pe numele câmpurilor care se doreşte să apară pe formular figura 31. Acestea vor apărea pe formular în zona de Detail a formularului; Fig. 31 Adăugarea controalelor pe formular 4. se salvează formularul butonul Save de lângă butonul Office; 5. pentru a vizualiza înregistrările se trece în modul de vizualizare Form View (folosind butonul View de pe panglică) figura 32. Fig. 32 Formular în modul de vizualizare Form View Pe formulare pot fi plasate diverse obiecte care poartă numele de controale. 129

126 Dintre cele mai des utilizate controale amintim: Label (etichete) control cu un conţinut fix, corespunzător constantelor, utilizat pentru afişarea unor comentarii, titluri, mesaje. Access generează automat câte o etichetă pentru majoritatea controalelor definite de utilizator. De obicei ele sunt plasate în stânga controlului pe care îl însoţeşte. Toate etichetele vor fi salvate cu nume care încep cu prefixul de 3 litere lbl (label). Pentru fiecare control de tip etichetă se vor modifica proprietăţile Name şi Caption. Proprietatea Caption controlează textul care va apare pe formular figura 33. Pentru a crea o etichetă, se selectează butonul de pe panglică, opţiunea de meniu Design. În fereastra Property Sheet se modifică proprietatea Name: lbltitlufurnizor, Caption: Lista furnizorilor; Fig. 33 Controale de tip etichetă Text-box (casete de text) sunt controale cu conţinut variabil, corespunzătoare câmpurilor dintr-o tabelă sau interogare, sau variabilelor. Conţinutul acestora se modifică în funcţie de înregistrarea curentă figura 34. Pentru toate casetele de text se modifică proprietatea Name în fereastra Property Sheet. Prefixul pentru casetele de text este txt (text). Pentru casetele de text legate de un câmp, proprietatea Control Source apare automat completată în cazul formularului creat după paşii prezentaţi anterior. De exemplu, pentru caseta de text Nr_furn se va modifica proprietatea Name: txtnr_furn, proprietatea Control Source va fi automat completată cu valoarea Furnizori.Nr_furn (numele tabelei sursă urmată de punct apoi numele câmpului de unde provin datele). Dacă se doreşte crearea unei casete de text, se selectează de pe panglică butonul. Vor fi create automat atât o casetă de text cât şi o etichetă care va explicita valorile afişate în caseta de text. Pentru etichetă se vor modifica proprietăţile Name şi 130

127 Caption, iar pentru caseta de text se vor modifica proprietăţile Name şi Control Source (dacă nu este deja completat); Fig. 34 Controale de tip casete de text Button (butoane de comandă) serveşte la declanşarea unor acţiuni predefinite sau a unor acţiuni definite prin intermediul unor proceduri Visual Basic Application. În capitolul următor este prezentată o modalitate de a crea butoane de comandă fără ajutorul asistentului. Vom prezenta în continuare crearea unui buton cu ajutorul asistentului. Pentru a crea un buton fără a cunoaşte comenzi Visual Basic Application este necesară selectarea butonului Use Control Wizards de pe panglică. Se selectează butonul Button de pe panglică apoi se execută un clic în zona Form Footer figura 35. La primul pas se alege categoria de acţiuni (navigare prin înregistrări, operaţii cu înregistrări, operaţii cu formulare, operaţii cu rapoarte, închiderea aplicaţiei şi diverse tipărirea tabelelor, execuţia unei interogări, execuţia unei macrocomenzi, etc). Fig. 35 Crearea unui buton de comandă cu ajutorul asistentului După ce s-a ales categoria, se alege acţiunea din partea dreaptă. În cazul de faţă, s-au ales operaţiile cu formulare pentru că se doreşte crearea unui buton care să închidă forma, de aceea a fost selectată acţiunea Close Form. Se trece cu Next la pasul următor. 131

128 Se va alege opţiunea Text specificându-se textul care se doreşte să apară pe buton: Închidere figura 36, apoi se apasă butonul Next. Fig. 36 Specificarea textului care va apare pe buton În cadrul ultimei ferestre se specifică numele controlului. Butoanele de comandă au prefixul cmd, deci numele controlului va fi cmdinchidere figura 37. Pentru a finaliza crearea butonului se apasă selectează opţiunea Finish. Fig. 37 Denumirea controlului de tip buton de comandă Pentru a încerca butonul trebuie selectat modul de vizualizare Form View figura 38. Fig. 38 Butonul Inchidere În mod similar pot fi create multe alte butoane de comandă pentru a automatiza baza de date. 132

129 Pe un formular pot fi plasate controale care să afişeze valori calculate. Pentru a crea un control calculat, se parcurg următorii paşi: 1. se selectează butonul Text box de pe panglică, apoi execută clic în zona Detail, sub controalele existente; 2. se modifică proprietăţile Name şi Caption ale etichetei; 3. se modifică proprietatea Name a casetei de text; 4. în cadrul proprietăţii Control Source se tastează formula de calcul, începând cu semnul =. Numele câmpurilor sunt scrise între paranteze drepte, de exemplu: =[valoare fara TVA]*1, Formulare cu sub-formulare Crearea unui formular cu subformular permite actualizarea mai multor tabele prin intermediul unui singur obiect. Subformularele sunt create pentru tabelele referite din cadrul unei relaţii de tip one-to-many. Formularul principal are ca sursă tabelul de referinţă, reprezentând partea de one (unu). Pentru acest formular se va utiliza un layout de tip Columnar sau Justified (permite afişarea unei singure înregistrări). Sursa subformular este tabelul referit, reprezentând partea many (mai mulţi). Subformularul va fi construit pe baza unui layout de tip Tabular sau Datasheet (sunt afişate toate înregistrările). Crearea unui formular cu subformular presupune înglobarea formularului many în formularul one. Pentru a crea un formular cu subformular se parcurg următorii paşi: 1. se crează un formular utilizându-se Form Wizard pentru tabela de referinţă, pe un layout de tip Columnar. Se salvează formularul. Formularul rămâne deschis în Design View; 2. se crează un formular utilizându-se Form Wizard pentru tabela referită (copil), pe un layout de tip Tabular. Se salveză formularul şi se închide; 3. în primul formular, se extinde zona Detail. Din panoul de navigare se alege numele formularului corespunzător tabelului referit şi se depozitează pe formular în zona Detail, sub celelalte controale. Se salvează formularul utilizându-se butonul Office, opţiunea Save as, Save object as, cu numele celor două formulare care compun formularul cu subformular (de exemplu FurnizoriFacturi). 133

130 5.6 Obiecte Reports Raportul este un obiect al bazei de date care permite vizualizarea informaţiilor pe ecran sau trimiterea acestora la imprimantă. Raportul poate fi creat fie pe baza unui tabel, fie pe baza unei interogări. Un obiect de tip report poate conţine următoarele zone: Report Header/Footer zona de antet şi subsol ale raportului, ele apar o singură dată la începutul, respectiv finalul raportului; Page Header/Footer zona de antet şi subsol ale fiecărei pagini a raportului; Group Header/Footer zona de antet şi subsol al câmpului/câmpurilor după care se realizează o grupare; Detail se afişează pentru fiecare înregistrare în parte; Subrapoarte sunt obiecte de tip raport conţinute în cadrul raportului părinte; Controale obiecte care pot fi plasate în cadrul raportului. Varianta cea mai simplă de creare a rapoartelor este Report Wizard. Dacă se doreşte afişarea datelor din mai multe tabele, poate fi creată o nouă tabelă pe baza unei interogări, raportul fiind construit pe baza acesteia. Dacă se doreşte afişarea unor câmpuri calculate, acestea pot fi create cu ajutorul unei interogări, raportul fiind creat pe baza interogării. Raportul creat cu ajutorul instrumentului Report Wizard poate fi deschis în modul Design View şi modificat prin adăugarea unui nivel de grupare, a unei sortari sau a unor câmpuri calculate. Pentru a construi un raport în Report Wizard se parcurg următorii paşi: 1. se selectează opţiunea de meniu Create, butonul Report Wizard; 2. din caseta Tables/Queries se alege sursa raportului (tabelul sau interogarea), iar cu ajutorul săgeţilor din mijlocul ferestrei se selectează câmpurile care se doresc a fi afişate în raport, ele apărând în fereastra Selected Fields, apoi se apasă butonul Next figura 39; 134

131 Fig. 39 Selectarea sursei raportului 3. Se pot adăuga unul sau mai multe niveluri de grupare selectând numele câmpului din partea din stânga. Se folosesc butoanele cu săgeţi pentru a selecta câmpul/câmpurile ca nivel de grupare. Pot fi adăugate până la 10 niveluri de grupare figura 40. Fig. 40 Adăugarea unor criterii de grupare Dacă se doresc grupări mai speciale, se poate selecta butonul Grouping Options. În funcţie de tipul câmpului selectat pot fi alese intervale de grupare, de exemplu în cazul unui câmp de tip Text grupare după prima literă, după primele 2 litere, etc figura 41. Pentru a trece la pasul următor se apasă butonul Next; Fig. 41 Opţiuni de grupare 135

132 4. se poate stabili o ordine de afişare a înregistrărilor în cadrul raportului, sortând până la 4 câmpuri simultan figura 42, apoi se apasă butonul Next figura; Fig. 42 Opţiuni de ordonare 5. Se pot alege diverse modalităţi de aranjare a datelor (Stepped, Block sau Outline) şi se poate seta orientarea paginii (Portrait pe verticală sau Landscape pe orizontală), apoi se apasă butonul Next figura 43; Fig. 43 Opţiuni legate de formatare 6. se poate alege un stil dintr-o listă cu stiluri disponibile, fiind vizibil un Preview al acestuia în partea din stânga al ferestrei, apoi se apasă Next figura 44; Fig. 44 Alegerea unui stil 136

133 7. la ultimul pas se alege titlul raportului şi vizualizarea acestuia în modul Preview figura 45, apoi se apasă butonul Finish. Fig. 45 Adăugarea unui titlu Raportul va fi afişat în modul Print Preview figura 46. Pentru a reveni la modul de Design, se apasă butonul Close Print Preview de pe panglică. Fig 47 Raport în modul Print Preview Raportul în modul Design View seamănă cu un obiect de tip formular în Design View figura

134 Fig. 48 Raport în Design View Pentru câmpurile numerice care conţin valori multiple în cadrul aceluiaşi grup, la pasul 4 se va afişa un buton în plus, denumit Summary Options figura 49. Fig. 49 Butonul Summary Options Dacă acesta este selectat, pune la dispoziţia utilizatorilor funcţii totalizatoare: SUM, MIN, MAX şi AVG figura 50. Fig. 50 Fereastra Summary Options Se poate selecta una din opţiunile Detail and Summary (vor fi afişate subtotaluri la nivelul fiecărui grup şi la nivel de raport) sau Summary Only (doar subtotal la nivel de grup) figura

135 Fig. 51 Raport cu grupare şi subtotaluri la nivel de grup şi raport Pe orice raport pot fi create casete de text care pot fi calculate după modelul prezentat în paragraful Pentru a adăuga o funcţie totalizatoare (de exemplu, calcularea valorii totale a tuturor facturilor, în zona Report Footer se va adăuga o casetă de text. Se vor modifica proprietăţile Name şi Caption corespunzătoare etichetei. Se va modifica proprietatea Name asociată casetei de text. În cadrul proprietăţii Control Source asociată casetei de text se va tasta formula =SUM([cantitate]*[pret]*1,24)). Din cadrul proprietăţii Format asociată casetei de text se va alege opţiunea Currency, pentru afişarea simbolului valutar. 5.7 Obiecte Macros Obiectele de tip Macro sunt un instrument util atunci când se doreşte execuţia unor acţiuni şi evitarea programării. Ele automatizează operaţiunile din cadrul unei baze de date Access. Obiectele de tip Macro pot fi încorporate în cadrul unui formular, depinzând de obiectul în care este plasat, sau pot fi autonome, fiind apelabile de oriunde. În cadrul unui obiect de tip Macro pot fi selectate mai multe acţiuni, acestea fiind alese dintr-o listă şi executate în ordinea în care au fost create. O macrocomandă se execută folosindu-se butonul Run (ca şi în cazul interogărilor de acţiune). Cu ajutorul macrocomenzilor pot fi create meniuri personalizate pentru a înlocui panglica (Ribbon-ul). Pentru a crea o macrocomandă se selectează opţiunea de meniu Create, iar din zona Other, Macro. De exemplu, dacă se doreşte crearea unei macrocomenzi 139

136 care să deschidă o interogarea în mod Read-Only se vor parcurge următorii paşi: în coloana Action se alege dintr-o listă de acţiuni predefinite, Open Query; în partea de jos a ecranului se selectează Query Name (numele interogării); se selectează modul de vizualizare în care va fi deschisă interogarea (în cazul de faţă Datasheet); în caseta Data Mode se alege Read-Only. Macrocomanda va fi salvată cu numele Deschidere Interogare Furniz şi poate fi executată apăsând butonul Run figura 52. Fig. 52 Crearea unei macrocomenzi De regulă macrocomenzile sunt ataşate fie unei opţiuni de meniu fie unui buton de comandă plasat pe un formular. 140

137 5.8 Obiecte Modules Obiectele de tip Module sunt module de program scrise în Visual Basic Application. Ne vom ocupa de module de cod în capitolul următor, ca suport al execuţiei comenzilor SQL (Structured Query Language). Utilizarea limbajului de programare Visual Basic Application nu face obiectul prezentului curs. 5.9 Concluzii Microsoft Access oferă utilizatorilor un mediu vizual cu o interfaţă grafică prietenoasă, capabil de a dezvolta aplicaţii complexe, fără a avea nevoie de cunoştinţe de programare. Faţă de versiunile anterioare, Access conţine o serie de îmbunătăţiri (sunt puse la dispoziţia utilizatorului o serie de şabloane, oferă suport pentru introducerea datei calendaristice, apariţia unui nou tip de câmp Attachment, pentru stocarea mai multor obiecte create cu alte aplicaţii, etc). Noua interfaţă Microsoft Access 2007 este una unitară în pachetul Microsoft Office, utilizatorul putând regăsi cu uşurinţă comenzile uzuale Rezumatul capitolului Gestionarea obiectelor Access se realizează într-o manieră centralizată prin înglobarea lor în baza de date. Sunt disponibile interfeţe simple pentru construirea structurii bazei de date (tabelele, relaţiile dintre ele şi dicţionarul de date), crearea unor formulare pentru inserarea datelor în tabele sau actualizarea datelor din tabele, automatizarea acestora cu ajutorul butoanelor de comandă, crearea unor panouri de comandă care vor gestiona operaţiile efectuate cu baza de date, selecţia datelor din una sau mai multe tabele, după anumite criterii, actualizarea tabelelor prin interogări care permit crearea unor noi tabele, inserarea de noi înregistrări, modificarea sau ştergerea automată a acestora în funcţie de anumite criterii, crearea macrocomenzilor pentru anumite acţiuni uzuale sau crearea unor secvenţe de cod şi afişarea datelor sau trimiterea acestora către imprimantă. Mediul de lucru Access se bazează pe utilizarea ferestrelor, oferindu-se posibilitatea vizualizării într-o fereastră cu mai multe tab-uri. Panoul de navigarea grupează toate obiectele bazei de date. 141

138 5.11 Întrebări de autoevaluare din partea teoretică 1. Specificaţi caracteristicile SGBD-ului MS Access Specificaţi care sunt cazurile în care se utilizează Microsoft Access. 3. Specificaţi care sunt cazurile în care se utilizează Microsoft Excel. 4. Detaliaţi opţiunile de pe bara de meniu MS Access Detaliaţi cinci proprietăţi importante care pot fi setate utilizându-se butonul Access Options. 6. Definiţi obiectul Table din Acces. Daţi exemple de tabele. 7. Definiţi conceptele de câmp şi înregistrare. Daţi exemple. 8. Definiţi conceptele de cheie primară şi chei străine. Daţi exemple. 9. Definiţi conceptul de redundanţă necesară. 10. Explicaţi regulile de integritate referenţială. 11. Detaliaţi tipurile de legături dintre tabele în Access. Daţi exemple la fiecare tip de legătură. 12. Detaliaţi operaţiile care pot fi efectuate cu câmpurile unei tabele. 13. Daţi exemple de completare a proprietăţii Input Mask. 14. Daţi exemple de reguli de validare (Validation Rule). 15. Definiţi obiectul Query din Access. Daţi exemplu de interogare de selecţie. 16. Detaliaţi operatorii Like, Between şi In. 17. Daţi un exemplu de interogare care să ilustreze utilizarea pentru funcţiei IIF. 18. Definiţi interogarea cu parametru. Exemplu. 19. Daţi exemple pentru fiecare tip de interogare de acţiune. 20. Detaliaţi modul de creare a unui formular cu subformular. 21. Definiţi controalele de tip Label, Text Box şi Button. Exemple. 22. Definiţi obiectul Report din Access. 23. Definiţi obiectul Macros din Access. 24. Definiţi obiectul Modules din Access. 142

139 5.12 Exemple Problemă rezolvată Tabelă creată în Datasheet View Să se creeze o bază de date cu numele Exemplul 1 care să conţină un tabel cu numele Studenţi. Acesta va avea structura ID, nume, prenume, an, serie, grupa, data naşterii, adresa, căsătorit, , fotografie. Se vor introduce 3 studenţi în tabelă. Rezolvare Se va crea o bază de date cu numele Exemplul 1, salvată pe Desktop. Odată cu crearea bazei de date, Access crează automat o tabelă cu numele care va conţine un câmp ID (identificator) de tip Autonumber, care va fi cheia primară a tabelei. Figura 53. Crearea unei tabele Pentru a salva tabela şi a modifica numele acesteia, se apasă butonul Save aflat pe bara panglică figura 53. Construirea a structurii tabelei va continua cu adăugarea unui nou câmp (o nouă coloană) executându-se dublu-clic pe linia cu ID, celula în care apare Add New Field figura 53. După tastarea numelui câmpului, se apasă Enter, trecerea fiind făcută la următoarea coloană. După ce s-a editat capul de tabel se trece la introducerea datelor în tabel. Câmpul ID fiind de tip Autonumber, acesta va fi completat automat odată cu selectarea primei litere din numele studentului. Se completează toate câmpurile până la fotografie. Se observă faptul că nu există posibilitatea completării acestui câmp. Pentru aceasta trebuie modificat tipul. Pentru aceasta se alege de pe bara de meniuri opţiunea de meniu Datasheet, caseta Data Type şi se selectează OLE Object. 143

140 Fig. 54. Meniul Datasheet, caseta Data type Se observă faptul că valoarea din coloana anul, faţă de valorile din coloanele seria şi grupa, este aliniată la stânga, faţă de celelalte două valori care sunt aliniate la dreapta. Microsoft Access 2007 păstrează acelaşi mod de aliniere ca şi Microsoft Excel 2007, şirurile de caractere sunt aliniate la stânga, iar numerele aliniate la dreapta. Deci câmpul an nu este recunoscut ca fiind de tipul potrivit (Number). De aceea se selectează coloana an şi se procedează în acelaşi mod ca în cazul fotografiei, selectând tipul de date Number. Microsoft Access afişează un mesaj de avertizare atunci când tipul de date este schimbat, unele valori putând fi pierdute figura 55. Fig. 55 Mesaj de avertizare la schimbarea tipului de date Se poate selecta fiecare câmp pentru a se verifica formatul dorit. În cazul în care valoarea care a fost introdusă nu corespunde cu valorile care trebuie introduse în cadrul acestui câmp, valoarea existentă este pierdută. În cazul câmpului data naşterii acesta trebuie să fie de tip Date/time, adresa de tip memo (texte mai mari de 255 de caractere), casatorit un câmp de tip Yes/No. Formatul clasic de afişare fiind un check-box (casetă de opţiune) care poate fi bifat sau nu, corespunzător celor două valori posibile. Fig. 56 Valorile câmpului de tip Yes/No Câmpul trebuie să fie de tip Hyperlink. 144

141 Pentru a introduce o fotografie în câmpul omonim, se selectează celula corespunzătoare, se selectează meniul contextual, apoi opţiunea Insert Object. Fig. 57 Introducerea unui obiect într-un câmp de tip OLE Object Sunt disponibile două opţiuni Create New sau Create from File. În acest caz vom presupune faptul că fotografia există deja, deci alegem a doua opţiune. Tehnologia OLE (Object Linking and Embedding) legare şi încorporare de obiecte, permite înglobarea obiectului în tabel, deci în baza de date, sau, dacă se selectează opţiunea Link, crearea unei legături către obiectul respectiv, fără ca acesta să fie încorporat în tabel. Fig. 58 Alegerea unei fotografii Câmpul fotografie va fi completat cu textul Package. La execuţia unui dubluclic, fotografia va fi deschisă pentru a fi vizualizată cu softul predefinit pentru vizualizarea fotografiilor. Se introduc încă 2 studenţi. Dacă este necesar, se poate utiliza bara orizontală de derulare (Scroll) aflată în partea de jos a ecranului figura 59. Fig. 59 Bara de derulare orizontală 145

142 Modul de vizualizare utilizat se observă de pe bara de stare Datasheet View. Pentru a trece de la un mod de vizualizare la altul se pot utiliza butoanele de pe bara de stare: Datasheet View, PivotTable View, PivotChart View sau Design View. Modul de vizualizare Datasheet View se utilizează în general pentru a vizualiza datele din tabelă, iar modul Design View se utilizează pentru a modifica proprietăţile structurii tabelei. Opţiunile PivotTable View şi PivotChart View permit crearea unui tabel, respectiv a unui grafic pivot. În modul de vizualizare Datasheet View, bara de unelte Record permite navigarea prin înregistrări. Cu ajutorul acesteia se permit în ordine: selectarea primei înregistrări, trecerea la înregistrarea anterioară, afişarea numărului înregistrării curente din numărul total de înregistrări, trecerea la următoarea înregistrare, selectarea ultimei înregistrări, crearea unei noi înregistrări, dezactivarea unui filtru (dacă există activat un criteriu de filtrare) precum şi căutarea unei valori în tabel figura 60. De reţinut faptul că la un moment dat suntem poziţionaţi pe o singură înregistrare din tabel. Fig. 60 Bara de navigare Records fără filtrare Pentru a şterge o înregistrare se selectează antentul de linie şi se apasă tasta Delete de pe tastatură. În cazul exemplificat în figura 61 s-au selectat 2 înregistrări pentru ştergere. Fig. 61 Mesajul de atenţionare afişat la ştergerea a două înregistrări Pentru a şterge un câmp se poziţionează cursorul pe antetul de coloană (unde este afişat numele cîmpului) şi se selectează din meniul contextual opţiunea Delete Column. Sistemul afişează un mesaj de avertizare figura 62. Fig. 62 Mesaj de avertizare la ştergerea unui câmp 146

143 Tabelul va fi automat deschis în modul de vizualizare Datasheet View. Pentru a trece la modul de vizualizare special pentru modificarea proprietăţilor tabelului se selectează butonul Design View de pe bara de stare figura 63. Fig. 63 Trecerea la modul de vizualizare Design View. Modul de vizualizare Design View permite setarea unor caracteristici (proprietăţi) nivel de fiecare câmp în parte figura 64. Fig. 64 Modul de vizualizare Design View Modul uzual de lucru pentru crearea unei tabele este în modul de vizualizare Design View, acesta permiţând setarea unor valori implicite, reguli de validare, moduri de afişare a datelor în câmp, etc. 147

144 Problemă rezolvată Tabele create în Design View Se doreşte informatizarea activităţii unei firme. Furnizorii sunt identificaţi prin cod furnizor, denumire furnizor (numele şi prenumele furnizorului), localitatea, adresa, , banca furnizor şi cont furnizor. Despre produse se cunosc cod produs, denumire produs, unitate de măsură, stoc, preţ unitar. Produsele sunt depozitate în magazii, pentru care se cunosc cod magazie, denumire magazie, gestionar (numele persoanei care are în gestiune depozitul respectiv). Operaţiunile se desfăşoară pe baza unor facturi, care trebuie să conţină numărul facturii şi data facturii. Fiecare factură conţine detaliate liniile facturii şi anume denumirea produsului, preţul unitar, cantitatea facturată, calculându-se valoarea produsului (cu şi fără TVA) şi valoarea totală a facturii cu şi fără TVA. Rezolvare În urma analizei datelor şi a aplicării metodei matricii dependenţelor funcţionale din capitolul anterior, se obţine următoarea schemă a bazei de date: Fig. 65 Fereastra Relationship Primul pas este crearea bazei de date. Aceasta va purta numele Firme. Pentru a crea baza de date, se deschide mediul de lucru Access, apoi se alege opţiunea Blank Database. Pentru a alege locaţia în care va fi salvat fişierul se alege icoana galbenă de folder, selectându-se Desktop-ul ca destinaţie, apoi se tastează denumirea: Firme. După crearea bazei de date se trece la analiza fiecărui tabel în parte şi alegerea tipului de câmp cel mai potrivit datelor care vor fi salvate în acesta. Este foarte importantă ordinea în care tabelele voi fi create. Pentru aceasta se aleg tabelele de referinţă (tabelele părinte, cum ar fi Furnizori, Magazii, Produse) urmând ca după crearea acestora să se creeze tabelele referite (Facturi, ProduseFacturate, ProduseMagazii). În momentul în care se crează baza de date, Access deschide automat un tabel cu numele Table1. Se va modifica tabelul Table1 în tabelul Furnizori. Pentru aceasta vom salva tabelul cu numele Furnizori, apelând butonul Save de lângă butonul Office. Pentru a adăuga câmpuri şi pentru a modifica proprietăţile acestora, se va trece 148

145 în modul de vizualizare Design View, fie folosind butonul View de pe panglică, fie butonul cu acelaşi nume de pe bara de stare. Se vor introduce următoarele câmpuri: primul câmp îl vom modifica din ID în cod_f (codul furnizorului), vom alege tipul de date Number, Field Size: Integer, şi Caption: cod furnizor, Validation Rule: >0, Validation Text: Introduceţi un număr pozitiv, Required: Yes; pentru câmpul den_f (denumirea furnizorului) tipul de dată Text, Field Size: 30, Format: >, Caption: denumire furnizor, Required: Yes, Allow Zero Length: No, Indexed: Yes (Duplicates OK); localit (localitate) de tip Text, Field Size: 30, Caption: localitate, Default Value: Timisoara; adresa de tip Memo; de tip Hyperlink; banca de tip Text, Field Size: 30, Format: >, Required: Yes, Allow Zero Length: No; cont (contul din bancă, IBAN) de tip Text, Fields Size: 24, Input Mask: "RO"99LLLL Fig. 66 Butonul View După ce toate câmpurile au fost create, se salvează tabela alegând butonul Save, apoi se apasă săgeata de pe butonul View, de unde se alege Datasheet View figura 66, pentru a introduce datele a trei furnizori în tabelă figura 67. Fig. 67 Tabela Furnizori în Datasheet View 149

146 După ce tabela a fost creată şi s-au introdus înregistrări în ea, aceasta va fi închisă. Pentru a crea o nouă tabelă, de pe bara de meniuri se alege opţiunea Create, butonul Table Design. Pentru tabela Magazii se inserează următoarele câmpuri: cod_m (cod magazie) Primary key, de tip Number, Field Size: Byte, Caption: Cod magazie, Required: Yes; den_m de tip Text, Field Size: 15, Caption: Denumire magazie, Indexed: Yes (Duplicates OK); gest de tip Text, Field Size: 30, Caption: Gestionar. Se vor introduce 3 magazii, cu codurile magazinelor 111, 112 şi 113; Fig. 67 Tabela Magazii în Datasheet View Pentru tabela Produse: cod_p (codul produsului) Primary key, de tip Number, Field Size: Long Integer, Caption: Codul produsului, Required: Yes; den_p (denumirea produsului) tipul câmpului Text, Field Size:15, Caption: Denumirea produsului; um (unitate de măsură) de tipul Lookup Wizard, apoi opţiunea I will type in the values that I want, în caseta Number of Columns nu se modifică valoarea 1, iar în lista col1 vor fi tastate pe rând, una sub alta, valorile dorite: kg, l, m, buc, selectând butonul Next, apoi Finish. În tabela Produse se vor introduce 3 produse, cu codurile 11111, şi figura 68. Fig. 68 Tabela Produse 150

147 Tabela ProduseMagazii: cod_p (cod produs) un câmp de tip Lookup Wizard pentru care se selectează opţiunea I want the lookup column to lookup the values in a table or query, apoi se alege tabela Produse, apoi se selectează butonul Next; se alege câmpul cod_p, apoi se apasă butonul Next figura 69. Ordonarea va fi făcută după acelaşi câmp cod_p, apoi se alege butonul Next. Fig. 69 Crearea legăturii cu tabela Produse În ecranul următor pot fi observate valorile introduse anterior în tabela Produse, apoi se apasă butonul Next figura 70. Fig. 70 Valorile introduse în câmpul cod_p din tabela Produse La ultimul pas este posibilă modificarea numelui câmpului (acesta va fi lăsat neschimbat) apoi se apasă butonul Finish; Între cele două tabele (Produse(tabela părinte) şi ProduseMagazii (tabela copil) va fi creată automat o relaţie. De aceea Access cere salvarea tabelei cu un nume (ProduseMagazii). Datorită faptului că nu a fost creată nici o cheie primară, sistemul sugerează crearea uneia. Se va alege No (cheia primară compusă va fi creată după crearea câmpului cod_m). cod_m (cod magazie) un câmp pentru care se alege Lookup Wizard se selectează opţiunea I want the lookup column to lookup the values 151

148 in a table or query, apoi se alege tabela Magazii; selectăm câmpul cod_m (cod magazie). Ca ordine de sortare se alege cod_m, se vizualizează codurile magaziilor introduse în tabela Magazii, apoi se lasă neschimbat numele câmpului şi se apasă Finish. Se cere din nou salvarea tabele; stoc (stocul disponibil în magazie) de tip Number, Field Size: Long Integer, Caption: Stoc produs, Required: Yes. Pentru a crea o cheie primară compusă, se selectează utilizându-se pătratul gri din faţa numelui câmpului ambele câmpuri cod_p şi cod_m şi se apasă butonul Primary Key de pe panglică. Se salveză tabela şi se trece în modul de vizualizare Datasheet View pentru a introduce date în tabelă. Pentru ca ambele relaţii să fie de tipul one-to-many, se vor introduce minim 4 înregistrări, un produs fiind depozitat în două magazii (de exemplu ). Fig. 71 Tabela ProduseMagazii Pentru tabela Facturi: nr_f (numărul facturii) Primary key, de tip Number, Field Size: Long integer, Caption: Numarul facturii, Required: Yes; data_f de tip Date/Time, Caption: Data Facturii, Required: Yes, Format: Short date, Default Value =Date(); cod_f (cod furnizor) tipul de date Lookup Wizard, se crează o legătură cu tabela Furnizori, câmpul cod_f, Caption: Cod furnizor. Tabela Facturi este copilul tabelei Furnizori. Având 3 furnizori în tabela părinte, vom introduce minim 4 facturi, codul furnizorului 1 repetându-se de 2 ori: Fig. 72 Tabela Facturi 152

149 Tabela ProduseFacturate: nr_f (numărul facturii) un câmp pentru care se alege Lookup Wizard, se crează a legătură cu tabela Facturi, câmpul nr_f; Caption: Numarul facturii. Se salvează tabela cu numele ProduseFacturate, iar la întrebarea dacă se doreşte alegerea unei chei primare se alege No; nr_crt (număr curent) un câmp de tip Number, Field Size: Integer, Caption: Numar curent; cod_p (codul produsului) un câmp pentru care se selectează Lookup Wizard, se crează o legătură cu tabela Produse, pe baza câmpului câmpul cod_p; cantit un câmp de tip Number, Field Size: Integer, Caption: Cantitate; pret_u un câmp de tip Currency, Caption: Pret unitar; cotatva un câmp de tip Number, Field Size: Single, Default Value: 0,24, Caption: Cota TVA. Se selectează câmpurile nr_f şi nr_crt şi se crează o cheie primară compusă apăsând butonul Primary Key de pe panglică. Acest tabel fiind copilul tabelelor Produse şi Facturi, vom introduce 8 înregistrări: Fig. 73 Tabela ProduseFacturate Pentru a verifica relaţiile şi a seta regulile de integritate referenţială, se selectează butonul Relationships de pe panglică figura 74. Fig. 74 Butonul Relationship 153

150 Pentru fiecare legătură în parte, se apelează meniul contextual, se alege opţiunea Edit Relationships... Pentru a seta regulile de integritate referenţială se selectează opţiunea Enforce Referential Integrity, bifând opţiunea Cascade Update Related Field. Dacă se doreşte modificarea tipului de relaţie dintre cele două tabele, se selectează butonul Join Type..., alegând una dintre cele trei tipuri de relaţii (Left Join, Inner Join sau Right Join). Fig. 75 Fereastra Edit Relationships Selectând pentru fiecare relaţie în parte opţiunile respective şi reordonând tabele, se obţine următoarea situaţie: Fig. 76 Fereastra Relationships Problemă rezolvată Formulare şi controale Să se creeze un folder pe Desktop cu numele şi prenumele dvs. În acesta, să se creeze o bază de date cu numele Programari care să conţină informaţiile legate despre pacienţi: un cod unic al pacientului, numele şi prenumele acestuia, data naşterii, adresa, telefonul formatat de tipul , seria şi numărul cărţii de identitate exact 2 litere şi 6 cifre. Pentru fiecare programare se cunoaşte data programării implicit data de azi, ora programării, doctorul la care se face programarea şi suma de plată. Pentru fiecare doctor se cunoaşte numele doctorului, adresa, numărul de telefon, titlul (rezident, primar, specialist) şi 154

151 specialitatea sa (cardiolog, ORL, etc). Să se introducă 3 înregistrări în tabela (tabelele) părinte şi numărul necesar de înregistrări în tabela (tabelele) copil. 1. Să se afişeze toţi pacienţii ordonaţi alfabetic după nume. 2. Să se creeze un formular de meniu care să conţină 4 butoane de comandă: primul va deschide forma Pacienţi cu subformularul Programări, al doilea va deschide forma Programari (care va fi creat în Design, modificând culoarea fundalului), al treilea buton va deschide forma Doctori (care va avea un titlu şi o poza pe fundal), iar ultimul buton permite închiderea formei. Rezolvare În urma analizei problemei, s-a ajuns la următoarea structură a datelor: Fig. 77. Fereastra Relationships 1. Pentru a sorta datele dintr-o tabelă se pot folosi fie butoanele Ascending sau Descending aflate pe panglică (Ribbon), dacă este selectată opţiunea de meniu Home, tabelul fiind deschis în Design View, fie săgeata din dreptul numelui câmpului în modul Datasheet View figura78. Fig. 78 Sortarea crescătoare a valorilor din câmpul IDdoctor 155

152 2. Formularul de meniu va fi creat ultimul, acesta apelând formularele create anterior. Pentru a crea primul formular cu subformular, vom selecta tabela părinte (Pacienţi) din panoul de navigare şi apăsăm butonul Form de pe panglică (Ribbon), fiind selectată opţiunea de meniu Create figura 79. Se observă că dacă au fost create relaţiile dintre tabele, apelarea butonului Form nu crează un formular simplu, ci un formular pentru tabela părinte cu un subformular corespunzător tabelei copil. Formularul se va salva cu numele PacientiProgramari. Dacă se doreşte vizualizarea formularului în Design View, se foloseşte fie butonul View de pe panglică, opţiunea de meniu Home, opţiunea Design View, fie butonul cu acelaşi nume de pe bara de stare. Se pot observa 3 zone: Form Header, Detail şi Form Footer. Fig. 79 Formular cu subformular Pentru a crea un formular în Design View, se alege opţiunea de meniu Create, apoi butonul Form Design de pe panglică (Ribbon). Se observă faptul că pe formular este vizibilă doar zona de Detail. Pentru a afişa şi celelalte zone de meniu, se apelează meniul contextual (clic cu butonul din dreapta al mouse-ului pe formular), apoi se selectează opţiunea Form Header/Footer. Formularul se salvează (butonul Save din dreapta butonului Office) cu numele Programari figura

153 Fig.80 Formular în Design View Pentru a schimba proprietăţile formularului, se apelează meniul contextual, apoi se alege opţiunea Properties. Pentru a selecta tabela sursă a formularului, se selectează în cadrul casetei Selection type: Form, apoi opţiunea Recourd Source de unde alegem selectând săgeata, se alege numele tabelei Programari figura 81. Fig. 81 Fereastra Property Sheet De pe panglică se selectează opţiunea de meniu Design, apoi se selectează butonul Add Existing Fields, adăugându-se prin dublu-clic sau drag-and-drop toate câmpurile din tabela Programari în zona de Design a formularului figura

154 Fig. 82 Adăugarea controalelor pe formular Pentru a schimba culoarea fundalului se foloseşte butonul Fill/Back Color. Se utilizează pentru fiecare zonă în parte figura 83. Pentru a vizualiza rezultatul, se foloseşte opţiunea Form View fie de pe bara de stare, fie din cadrul butonului View de pe panglică (opţiunea de meniu Home). Fig. 83 Modificarea culorii fundalului Pentru a crea formularul Doctori vom urma aceeaşi paşi ca şi la punctul b. Pentru a adăuga un titlu vom selecta butonul Label de pe panglică (opţiunea de meniu Design) şi vom executa clic în zona Form Header. Titlul adăugat va fi Lista doctorilor. Când s-a terminat introducerea textului, se execută clic oriunde pe formă pentru a finaliza editarea. Vom executa clic cu butonul din dreapta al mouse-ului pe titlu, selectând opţiunea Properties. În fereastra Property Sheet vom modifica proprietatea Name: lbltitlu. De observat faptul că proprietatea Caption apare deja completată cu textul care apare pe formă. Se pot alege opţiuni de formatare cum ar fi dimensiunea literelor, culoarea literelor, îngroşare, înclinare, centrare, etc. Aceste se găsesc în zona Font de pe panglică. Dacă este nevoie se va redimensiona controlul. 158

155 Pentru a adăuga adăuga o poză de fundal vom selecta butonul Property Sheet de pe panglică. De la Selection type vom alege Form, apoi opţiunea Picture. Selectând butonul cu trei puncte se va alege o poză pentru fundal. Dacă este nevoie, se va modifica culoarea textului etichetelor pentru a crea un contrast cu fundalul. Pentru formă se va selecta proprietatea Picture Size Mode şi se vor alege opţiunea Stretch figura 84. Pentru a vizualiza formularul se va alege opţiune Form View. Se închide formularul. Fig. 84 Adăugarea unei poze de fundal Pentru a crea un formular de meniu, se va selecta butonul Form Design de pe panglică, fiind selectată opţiunea Create de pe bara de meniuri. Nu se va mai selecta Form Hearde/Footer. Se verifică dacă pe panglică butonul Use Control Wizard este selectat, iar dacă nu este selectat, îl selectăm. Se alege apoi butonul Button. La execuţia unui clic pe formă, fereastra Command Button Wizard va apare pe ecran figura

156 Fig. 85 Fereastra Command Button Wizard Se alege categoria Form Operations, apoi acţiunea Open Form, apoi se apasă butonul Next. Se alege formularul PacientiProgramari, apoi se apasă Next. Se va alege opţiunea Open the form and show all the records, apoi se apasă butonul Next. Se selectează opţiunea Text, modificând textul în Forma PacientiProgramari, apoi se apasă butonul Next. Numele butonul va fi cmdpaccons, apoi se apasă Finish. Analog se construiesc butoanele corespunzătoare celorlalte două formulare. Pentru ultimul buton se va alege categoria Application, acţiunea Quit Application. Se va selecta pentru opţiunea Text: Ieşire, numele butonului fiind cmdieşire. Formularul va fi salvat cu numele Meniu Figura 86. Se va testa formularul trecând în Form View. Fig. 86 Crearea unui formular de meniu 160

157 Problemă rezolvată Formulare cu controale calculate, Switchboard Să se creeze pe Desktop un folder cu numele şi prenumele dvs. Să se creeze o bază de date cu numele Transporturi. Clienţii pot fi atât persoane fizice, caz în care pe fişă sunt specificate numele, adresa clientului şi numărul de telefon, cât şi persoane juridice, caz în care se specifică denumirea firmei şi codul fiscal. Transporturile sunt realizate prin intermediul unei fişe de transport, caracterizate prin data şi ora plecării, numărul autovehicolului, destinaţia şi tariful. Angajaţii firmei (şoferii) sunt identificaţi prin nume, adresă şi număr de telefon. 1. Să se creeze relaţii de tip one-to-many între tabele. Să se introducă 3 înregistrări în tabela (tabelele) părinte şi numărul necesar de înregistrări în tabela (tabelele) copil. Să se modifice relaţiile pentru a realiza modificarea datelor în cascadă. 2. Să se creeze un formular cu subformular pentru Clienţi şi transporturile efectuate utilizându-se Form Wizard. 3. Să se creeze un formular pentru tabela FişeTrans, afişându-se toate câmpurile, şi în plus, TVA-ul şi valoarea cu TVA a tarifului pentru fiecare fişă de transport. Să se adauge un buton de comandă în Form Footer pentru a închide forma. 4. Să se creeze un formular de tip Switchboard denumit Meniu cu 2 butoane de comandă: primul, denumit Vizualizare formulare, va apela un alt Switchboard care va grupa toate formele create anterior. Al doilea buton de pe primul Switchboard, denumit Ieşire, va permite închiderea mediului de lucru Access. Să se seteze Switchboardul Meniu ca fiind prima formă afişată atunci când va fi deschisă aplicaţia. Rezolvare 1. Analizând problema, s-a ajuns la următoarea structură a datelor figura 87. Fig. 87 Fereastra Relationship 2. Pentru a construi un formular cu subfomular se vor construi câte un formular pentru fiecare tabel, urmând a le uni într-unul singur. Pentru tabela 161

158 părinte se va alege un formular de tip Columnar, iar pentru tabela copil, un formular de tip Tabular. Pentru a crea primul formular, se alege opţiunea de meniu Create, butonul More forms... apoi Form Wizard. La primul pas se alege tabela Clienti, selectându-se toate câmpurile cu ajutorul butonului cu două săgeţi, apoi se apasă Next figura 88. Aspectul (layout-ul) formularului va fi Columnar, apoi se selectează butonul Next. Se alege un stil, apoi se apasă Next. La ultimul pas se apasă doar butonul Finish. Se salvează formularul cu numele Clienti. Fig. 88 Form Wizard pentru tabela Clienţi În mod similar se crează un formular pentru tabela FiseTrans, selectând ca layout Tabular (la pasul 2). Se salvează formularul cu numele FiseTrans. Pentru clasificarea obiectelor, în panoul de navigare din partea din stânga a ecranului (Navigation Pane) se alege de la All Tables săgeata, apoi Object Type. Obiectele vor fi ordonate după tipul lor. Se deschide formularul Clienti in Design View. Se măreşte zona de Detail şi se trage formularul FiseTrans din panoul de navigare în zona de detaliu a formularului părinte. Se trage în jos de butonul de redimensionare (portocaliu) a subformularul astfel încât să fie vizibilă zona acestuia de Detaliu. Se salveză utilizând butonul Office, Save as..., Save Object As cu numele ClientiFiseTrans figura

159 Fig. 89 Formularul Clienti cu subformularul FiseTrans 3. Pentru a crea un formular în Design View, se alege de pe panglică opţiunea Create, apoi Form Design. Din fereastra Properties (de pe panglică, opţiunea de meniu Design, butonul Property Sheet), se alege la Selection Type Form, iar la opţiunea RecordSource (sursa înregistrărilor) se selectează din listă FiseTrans. Se apelează butonul Add Existing Fields (de pe panglică, opţiunea de meniu Design) şi prin dublu-click pe câmp sau drag-and-drop se selectează pe formular toate câmpurile. Pentru a adăuga un nou câmp pe formular, se foloseşte butonul Text Box de pe panglică (drag-and-drop). Controlul va fi plasat pe formular în zona Detail, sub celelalte controale. Acesta este format dintr-o etichetă (în engleză Label) (partea din stânga, Text8 în acest caz), şi cutia de text (Text Box în engleză) (partea din dreapta, care apare completată cu cuvântul Unbound nelegat). Efectuând clic cu butonul din dreapta pe etichetă, alegem opţiunea Properties. În fereastra Property Sheet se vor modifica două proprietăţi pentru etichetă: Name: lbltva şi Caption: TVA (pe pagina All sunt primele două opţiuni). Pentru cutia de text vom modifica proprietăţile Name: txttva şi ControlSource: semnul egal urmat de formula de calcul a TVA-ului, punând numele câmpului între paranteze drepte. În mod similar se calculează şi valoarea tarifului cu TVA. Se va adăuga un nou Text box de pe panglică în zona Detail a formularului, sub celelalte controale. Pentru etichetă se modifică proprietăţile Name:lblTarifTVA şi Caption: Tarif cu TVA. Pentru text-box se modifică proprietăţile Name:txtTarifTVA şi Control Source: semnul egal urmat de formula de calcul, numele câmpului sau a câmpurilor fiind scrise între paranteze drepte figura

160 Fig. 90 Crearea unui câmp calculat Pentru a formata cele două cutii de text create astfel încât să conţină simbolul valutar, în fereastra Property Sheet, se va selecta proprietatea Format de unde se alege Currency. Formularul va fi salvat cu numele FiseTransport. Pentru a adăuga un buton de comandă care va închide formularul, se verifică dacă este apăsat butonul Use Control Wizard din opţiunea de meniu Design (de pe panglică). Dacă este selectat, se alege butonul Button, apoi se execută un clic pe formular, sub restul controalelor. Se alege categoria Forms, acţiunea Close Form, apoi se apasă butonul Next. Se selectează opţiunea Text unde se tastează Închidere, apoi se apasă butonul Next. Pentru a finaliza, se tastează numele controlului, cmdinchidere, apoi se apasă butonul Finish. 4. Pentru a crea un Switchboard, de pe bara de meniuri se alege opţiunea Database Tools, apoi Switchboard Manager. La apariţia mesajului The Switchboard Manager was unable to find a valid switchboard in this database. Would you like to create one? se alege opţiunea Yes. În fereastra Switchboard se selectează butonul Edit pentru a modifica formularul principal (Main Switchboard(Default)). În fereastra Edit Switchboard Page se modifică opţiunea Switchboard Name din Main Switchboard în Meniu. Se apasă butonul Close şi se crează al doilea formular care va avea numele Vizualizare formulare. Pentru aceasta se apasă butonul New şi se modifică numele formularului din New Switchboard page în Vizualizare formulare figura

161 Fig. 91 Crearea celui de-al doilea formular Se vor adăuga în continuare elemente pe fiecare formular în parte. Primul formular, Meniu va avea două elemente: unul care permite vizualizarea formularului Vizualizare formulare şi al doilea care permite părăsirea aplicaţiei. Pentru aceasta, se selectează Meniu, apoi se apasă butonul Edit. În caseta Item on this Switchboard vor fi afişate cele două elemente create. Pentru a adăuga un element nou, se apasă butonul New figura 92. Fig. 92 Adăugarea unui item pe primul formular În cadrul casetei Text se va completa textul care dorim să apară în dreptul butonului: Vizualizare formular. În caseta Command se lasă neschimbat Go to Switchboard, iar din ultima casetă Switchboard se alege numele formularului care va fi apelat atunci când butonul acesta va fi acţionat: Vizualizare formulare. Se apasă butonul OK. Pentru a adăuga al doilea element, se apasă butonul New. În cadrul casetei Text se va completa Ieşire, iar în caseta Command se va alege Exit Application, apoi se apasă butonul OK figura

162 Fig. 93 Adăugarea unui item pe primul formular Pentru a ieşi din modul de editare al formularului Meniu se utilzează butonul Close. Se alege formularul Vizualizare formulare, apoi se apasă butonul Edit, pentru a adăuga butoane. Pentru aceasta se utilizează butonul New Figura 94. În caseta Text se tastează Formularul urmat de numele formularului ales, în cutia de text Command se alege Open form in Edit Mode iar din caseta Form se alege primul formular. Se apasă butonul OK. Fig. 94 Adăugarea unui item pe formularul Vizualizare formulare În mod similar se crează butoane pentru fiecare formular. Ultimul buton va face trecerea înapoi la formularul Meniu. Pentru aceasta se apasă din nou butonul New figura

163 Fig. 95 Adăugarea item-ului Intoarcere pe formularul Vizualizare formulare Pentru a încheia modul de editare al formularului Vizualizare formulare se apasă butonul Close. Dacă formularul Meniu nu este formularul principal (dacă în dreptul lui nu apare cuvântul Default în paranteză), acesta se selectează, apoi se apasă butonul Make Default. Odată cu apăsarea butonului Close observăm crearea unui nou formular cu numele Switchboard şi a unei tabele cu numele Switchboard Items în panoul de navigare din stânga Figura 96. Fig. 96 Formularul Meniu (de tip Switchboard) Pentru a seta formularul ca fiind primul obiect care apare la deschiderea bazei de date, se selectează butonul Office, se alege butonul Access Options, apoi Current Database. Se poate alege un titlu pentru aplicaţie, în caseta Application Title: Transporturi, iar din lista Display Form se alege Switchboard figura

164 Fig. 97 Crearea unui titlu a aplicaţiei şi setarea formularului principal Problemă rezolvată Interogări Se consideră baza de date creată la punctul Să se creeze o interogare care să permită afişarea informaţiilor de pe toate facturile (nr_f, data_f, den_p, cantit, preţ_u şi cota TVA) pentru data curentă. 2. Să se creeze o interogare afişându-se pentru fiecare înregistrare TVA-ul şi Valoarea. 3. Să se creeze o interogare care să permită citirea interactivă în momentul execuţiei a unui număr de factură şi afişarea informaţiilor legate de aceasta. 4. Să se creeze o interogare care să permită afişarea tuturor facturilor eliberate între 2 date calendaristice (operatorii Between cu And). 5. Să se creeze prin intermediul unei interogări un nou câmp cu numele Observaţii care va conţine textul Produs eficient dacă valoarea este mai mare decât o anumită valoare sau Produs ineficient daca valoarea este mai mică decât acea valoare. 6. Să se afişeze toate facturile eliberate luna aceasta. 7. Operatorul Like: a. Să se afişeze toate produsele care încep cu litera l. b. Să se afişeze doar produsele care sunt din 6 litere si încep cu litera l. 168

165 8. Să se afişeze toate produsele care au preţurile 50 şi 1000 lei. 9. Să se determine pentru fiecare factură valoarea totală. 10. Să se creeze un nou tabel pe baza tabelelor Facturi, Produse şi LiniiFact, rezultatul unei interogări, care să conţină toate datele din toate tabele, suprimând apariţia dublată a câmpurilor de legătură, tabelul fiind ordonat alfabetic după denumirea produselor. Rezolvare: 1. Pentru a crea o interogare, de pe bara de meniuri se alege opţiunea Create, apoi Query Design. În fereastra Show table se vor selecta prin dublu-clic tabelele Facturi, ProduseFacturate şi Produse, apoi se închide fereastra. Pentru a alege câmpurile dorite, acestea se selectează prin dublu-click. Sub coloana data_f, pe linia Criteria, se va introduce =Date(). Se salvează interogarea apăsând pe butonul Save (numele interogării fiind Facturi curente). Pentru a vizualiza rezultatul interogării, de pe butonul View se alege Datasheet View. Fig. 98 Interogare în Query Design Observaţie: Dacă interogarea nu returnează nici un rezultatul, înseamnă că nici o înregistrare nu a verificat condiţia ca data facturii să fie data curentă. Fig. 99 Interogare în Datasheet View Se închide interogarea. 169

166 2. Pentru a crea a doua interogare, se alege de pe panglică opţiunea de meniu Create, apoi Query Design. Din tabela ProduseFacturate se selectează cantitatea, preţul şi cotatva, iar din tabela Produse denumirea produsului şi unitatea de măsură. Deci în fereastra Show Tables, se vor alege ambele tabele, selectându-se câmpurile respective. Pe prima coloană liberă se calculează TVA-ul după următoarea formulă TVA: [cantit]*[pret_u]*[cotatva] Pe următoarea coloană se calculează valoarea: Valoare: [cant]*[pret_u]+[tva] Se salvează şi vizualizeză rezultatul interogării. Pentru a afişa simbolul valutar într-o anumită coloană din interogare (de exemplu pt. TVA), în modul de vizualizare Design View se selectează coloana, se apelează din meniul contextual opţiunea Properties, iar la opţiunea Format se alege Currency. Analog se procedează şi cu coloana Valoare. Fig. 100 Interogare în Design View 3. Se selectează tabelele Facturi, Produse şi ProduseFacturate, câmpurile: nr_f, data_f, den_p, pret_u şi cantit. Pentru a crea o interogare cu parametru, care să permită citirea interactivă a numărului facturii de pe tastatură, pe coloana nr_f, linia Criteria se tastează [Introduceti numarul facturii]. Se închide interogarea şi se lansează în execuţie prin dublu-clic pe numele interogării din panoul de navigare. Fig. 101 Interogare cu parametru 170

167 4. Se selectează tabela Facturi, ProduseFacturate şi Produse, câmpurile: nr_f, data_f, den_p, pret_u şi cantit: Fig. 102 Operatorul Between 5. Se deschide interogarea de la punctul 2, în Design View, se salvează cu numele Observaţii (Save as de pe butonul Office, Save object as...). Se apelează meniul contextual asociat unui nou câmp (prima coloană liberă), se alege opţiunea Build figura 103. Fig. 103 Funcţia IIF Se selectează funcţia IIF, modificând-o astfel: Observatii: IIf([valoare]>=50000;"Produs eficient";"produs ineficient") Fig. 104 Funcţia IIF 171

168 Dacă se trece în modul de vizualizare Datasheet View se poate observa rezultatul aplicării funcţiei IIf figura 105. Fig. 105 Rezultatul funcţiei Iif 6. Vom folosi 2 funcţii care pot fi aplicate unor date calendaristice: Datepart (o parte dintr-o dată calendaristică) şi funcţia Month (extrage luna dintr-o dată calendaristică). Fig. 106 Funcţii pentru dată calendaristică 7. a). Se alege tabela Produse, câmpurile: den_p, pret_u. Pe coloana den_p, linia Criteria se tastează condiţia: LIKE "l*". b) Se deschide interogarea de la punctul a), se salvează cu alt nume, se trece în modul de vizualizare Design View şi se modifică condiţia: LIKE "l?????". 8. Se alege tabela ProduseFacturate, coloana pret_u, utilizându-se operatorul IN figura

169 Fig. 107 Operatorul IN 9. Se crează o nouă interogare. Se adaugă tabelele Produse şi ProduseFacturate. Se calculează valoarea. Se adaugă câmpul nr_f şi se selectează butonul Totals de pe bara de unelte, iar sub valoare, pe linia Total, se alege funcţia SUM figura 108. Fig. 108 Interogări de sintetizare a datelor 10. Pentru a crea o nouă tabelă cu toate înregistrările din tabelele Facturi, Produse şi ProduseFacturate, se adaugă toate câmpurile din aceste tabele, fără a le duplica. Se salvează interogarea cu numele Creare tabela. De pe panglică se alege butonul Make Table figura 109, se tasteată numele noii tabele: Reuniune, apo se apasă butonul OK. Pentru a se executa interogarea se va selecta Run. Dacă nivelul de securitate nu este setat astfel încât să permită execuţia codurilor Visual Basic, interogarea nu va funcţiona. Pentru a permite utilizarea codurilor, de pe 173

170 bara Security Warning se alege butonul Options, apoi opţiunea Enable this content. Fig. 109 Interogare de tip Make Table Dacă interogarea este închisă, se va lansa în execuţie prin dublu-clic pe numele acesteia din panoul de navigare figura 109. Sistemul Access avertizează asupra eventualelor riscuri care pot apare la execuţia unei interogări de acţiune. Vom alege butonul Yes. Fig. 110 Mesaj de avertizare Şi mesajul următor este doar unul de avertizare, şi anume că datele salvate în tabele vor fi adăugate în tabelul nou creat. Deci vom apăsa butonul Yes. 174

171 Fig. 111 Mesaj de avertizare la transferarea înregistrărilor într-un nou tabel Problemă rezolvată Rapoarte 1. Să se creeze un raport pentru tabelul ProduseFacturate, datele fiind grupate după nr_f. 2. Să se creeze un raport pentru afişarea datelor de pe fiecare factură în parte, calculându-se valoarea facturii şi valoarea totală a tuturor facturilor. Rezolvare: 1. Pentru a crea un raport cu ajutorul asistentului, se alege opţiunea de meniu Create, butonul Report Wizard. La primul pas se alege tabela sau interogarea pe baza căreia se va crea raportul (Tables/Queries). Din caseta Available Fields se selectează câmpurile dorite, apoi se apasă butonul Next. Fig. 112 Report Wizard pentru tabela ProduseFacturate La pasul 2 se selectează criteriul de grupare, în cazul de faţă vom grupa produsele facturate după nr_f. Dacă se apasă butonul Grouping Options se pot alege mai multe variante de grupare: după primele 10, 50, 100, etc numere de factură. În cazul de faţă opţiunea Normal rămâne selectată figura

172 Fig. 113 Fereastra Grouping Intervals La pasul următor se selectează ordinea în care vor fi afişate înregistrările în raport: Fig. 114 Ordonarea datelor de pe raport Dacă este selectat butonul Summary Options... se pot selecta funcţii ce vor fi aplicate pe câmpurile numerice din tabel sau interogare figura

173 Fig. 115 Summary Options În continuare se selectează orientarea paginii (verticală, orizontală), precum şi modul de afişare al informaţiilor pe pagină: Fig. 116 Opţiuni de formatare a paginii La pasul următor se alege un stil din lista afişată figura 117. Fig. 117 Alegerea stilului raportului 177

174 Ultimul pas permite modificarea titlului raportului (nu este vorba de numele cu care va fi salvat raportul, ci doar textul care va apare în antentul raportului), apoi putem alege între a vizualiza raportul şi a modifica raportul. Pentru a încheia crearea raportului se alege opţiunea Finish. figura 118 Fig Alegerea unui titlu şi vizualizarea raportului în mod Print Preview Raportul în modul Print Preview va apare ca în figura următoare figura 119. Fig 119 ProduseFacturate în Print Preview 178

175 În Design View raportul arată ca în figura 120. Fig. 120 Raportul ProduseFacturate în Design View Dacă datele provin din mai multe tabele, sau sunt necesare unele câmpuri calculate, se poate crea o interogare în care se selectează tabelele, se calculează câmpurile dorite, apoi se creează raportul pe baza interogării. Dacă se doreşte adăugarea unui câmp care va fi calculat, se alege de pe panglică controlul Text Box. Se modifică pentru etichetă proprietăţile Name: lblvaloare şi Caption: Valoare. Aceasta va fi mutată în zona nr_f Header. Pentru controlul de tip Text Box se vor modifica proprietăţile Name: txtvaloare şi Control Source: =[cantit]*[pret_u]* [cotatva]. 2. Pentru a crea raportul, se va alege ca sursă a datelor interogarea cu numele Valoare. Având câmpuri numerice, la pasul 3 se selectează butonul Summary Option, bifând check-box-urile de sub funcţia SUM pentru câmpurile TVA şi Valoare. Fig. 121 Fereastra Summary Options 179

176 Pentru a vizualiza raportul, de pe butonul View se alege opţiunea Print Preview figura 122. Fig. 122 Raportul în Print Preview Pentru a modifica raportul (adăuga controale calculate) este necesară vizualizarea acestuia în modul Design View. Fig. 123 Raportul în Design View 180

177 5.13 Probleme propuse Problema propusă Crearea tabelelor Filială CEC Se cere informatizarea activităţii la o filială CEC. Clienţii filialei sunt identificaţi prin seria şi numărul de buletin, data eliberării buletinului, nume, prenume şi adresă. Fiecare client poate să deţină unul sau mai multe cecuri. Pentru fiecare cec se cunoaşte: seria, numărul, data la care a fost eliberat, suma depusă în momentul eliberării şi tipul cecului (poate fi la termen şi la vedere). De asemenea, fiecare cec poate să aibă unul sau mai mulţi titulari. Fiecare client poate efectua depuneri şi restituiri. Depunerile se efectuează prin intermediul unei foi de depunere (FD) caracterizată prin: număr, data şi suma depusă. Restituirile se efectuează prin intermediul foilor de restituire (FR) caracterizate prin: număr, data şi suma restituită. Fiecare cec se poate lichida de către unul din titulari prin intermediul unei foi de lichidare (FL) caracterizată prin: număr, data şi suma din momentul lichidării. Dobânda acordată pentru cecuri se modifică de la o zi la alta şi este diferită pentru cecurile la termen faţă de cele la vedere Problemă propusă Crearea formularelor Să se creeze o interfaţă grafică cu utilizatorul cu ajutorul opţiunii Switchboard, fiind create formulare cu subformulare pentru toate tabelele părinte-copil, îmbogăţite cu butoane de comandă care să permită închiderea formelor şi câmpuri calculate pe baza tabelelor create în baza de date de la punctul Problemă propusă Crearea interogărilor Să se creeze toate tipurile de interogări pentru baza de date creată la punctul Problemă propusă Crearea rapoartelor Să se creeze rapoarte pentru toate tabelele şi interogările create la punctul şi

178 182

179 CAPITOLUL 6 ELEMENTE SQL 6.1 Introducere Unul dintre cele mai puternice limbaje structurate pentru interogarea datelor, SQL (Structured Query Language), a devenit un standard pentru o gamă din ce în ce mai largă de sisteme pentru gestiunea bazelor de date. A fost construit în 1986 de către ANSI (American National Standards Institute). De atunci, este considerat a fi un standard interaţional avizat de către ISO (International Organization for Standardization) şi IEC (International Electrotechnical Comission). A fost adoptat ca fiind standard federal de către FIPS (american Federal Information Processing Standard). În cadrul acestui capitol se vor prezenta comanda Select care permite realizarea interogării bazelor de date, precum şi instrucţiunile care permit actualizarea datelor (adăugarea, modificarea şi ştergerea datelor prin comenzi SQL). 6.2 Comenzi SQL Limbajul SQL (Structured Query Language) este un limbaj structurat de interogări şi gestionare a bazelor de date relaţionale. Access foloseşte SQL ca limbaj de interogare. În momentul creării unei interogări în modul de interogare Design, Access construieşte în paralel instrucţiunile SQL echivalente. De altfel, majoritatea proprietăţilor interogărilor în modul de interogare Design prezintă clauze echivalente şi opţiuni accesibile în limbajul SQL. Avantajele utilizării instrucţiunii SQL în VBA sunt următoarele: viteza de execuţie: o instrucţiune Select este mai rapidă decât parcurgerea secvenţială a unui tabel. performanţă mai bună: în modul client/server, interogările sunt compilate de SGBD care le optimizează performaţele. întreţinere mai uşoară: codul de instrucţiuni SQL este mai scurt, deci mai uşor de citit, decât echivalentul său în VBA. 183

180 standardizare: limbajul SQL este standardul de interogare al bazelor de date relaţionale. 34 SQL are următoarele componente: 1. DDL Data Definition Language (limbaj de definire a datelor): include comenzi legate de crearea, modificarea şi ştergerea schemei de structură a bazei de date şi/sau a tabelelor. Dintre comenzile cele mai des întâlnite amintim: CREATE TABLE, ALTER TABLE, DROP TABLE; 2. DML Data Manipulation Language (limbaj de manipulare a datelor): include comenzi pentru a realiza interogări şi pentru a modifica datele stocate în tabele. Dintre cele mai des utilizate comenzi amintim: SELECT, INSERT INTO, UPDATE, DELETE; 3. DCL Data Control Language (limbaj de control a datelor): include comenzi pentru menţinerea securităţii şi a confidenţialităţii bazei de date. Dintre comenzile uzuale amintim: GRANT (acordarea drepturilor unui utilizator) şi REVOKE (revocarea drepturilor unui utilizator). Vocabularul SQL cuprinde o serie de cuvinte cheie, dintre care amintim 35 : instrucţiuni determină execuţia unei anumite acţiuni (de exemplu Create Table, Select, Delete); clauze permit specificarea unor argumente care nuanţează instrucţiunile, delimitând entităţile participante la interogare (exemple de clauze: From, Where, Group By, Order By); funcţii efectuează prelucrări asupra anumitor date denumite argumentele sau parametrii funcţiei, rezultatele returnate fiind utilizate în cadrul unei clauze SQL. Funcţiile şi operatorii prezentaţi în paragraful sunt valabili şi în SQL. Principalele reguli de sintaxă sunt: orice instrucţiune SQL se termină cu simbolul punct şi virgulă ; SQL utilizează ierarhia obiectelor din modelele orientate pe obiecte, caracterul punct separând un obiect de un atribut sau o metodă a acestuia. De exemplu, numele_tabelei.numele_câmpului; parantezele drepte se utilizeză atunci când un nume de tabel sau câmp conţine caracterul spaţiu, de exemplu [Denumire Furnizor]; 34 Giulvezan C., Mircea G., Târnăveanu D., Margea C. Baze de date, Editura Universităţii de Vest, Timişoara, 2009, p Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p

181 caracterul virgulă este utilizată pentru a delimita valorile unei liste (de exemplu lista câmpurilor); valorile de tip Number sunt scrise direct, fără a fi încadrate de nici un alt caracter; valorile de tip Text sunt încadrate între caracterul apostrof (de exemplu: Timişoara ); valorile de tip dată calendaristică sunt încadrate între caracterul diez (de exemplu: #31/12/2011#). Reguli de editare în cazul instrucţiunilor SQL 36 : fiecare clauză a interogării se plasează pe câte o linie separată, indentată faţă de instrucţiunea din care face parte; începutul fiecărei clauze va fi aliniat cu începutul celorlalte; dacă o clauză este fragmentată, fiecare din părţile ei constitutive se poziţionează pe câte o linie separată şi se indentează faţă de începutul clauzei; pentru evidenţierea cuvintelor rezervate, specifice SQL, se folosesc majuscule. Atunci când se scriu instrucţiunile în format general, există mai multe convenţii de notare: cuvintele rezervate sunt scrise cu majuscule; cuvintele definite de utilizator se scriu cu litere mici; bara verticală semnifică separarea mai multor elemente alternative care se exclud reciproc (doar unul din acestea poate fi să apară); parantezele drepte [ ] încadrează un element opţional; acoladele {} încadrează un element obligatoriu; punctele de suspensie semnalează repetarea opţională a unui element al unei liste. 36 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p

182 6.2.1 Comanda CREATE TABLE Pentru a crea o tabelă de referinţă se poate utiliza următorul format general: CREATE TABLE numet1 (numec1 tip1 [CONSTRAINT nn_c1 NOT NULL] [CONSTRAINT pk_c1] PRIMARY KEY, numec2 tip2 [CONSTRAINT nn_c2 NOT NULL], ); unde numet1 este numele tabelului creat, numec1, numec2,... sunt numele câmpurilor care vor constitui structura tabelului. Tip1, tip2,... sunt tipurile de date suportate de limbajul SQL vezi figura 1. PRIMARY KEY semnifica setarea unui câmp ca fiind de tip cheie primară. Atributul NOT NULL semnifică faptul că acel câmp este este obligatoriu să fie completat (echivalentul proprietăţii Required din Access). Programatorii folosesc o denumire pentru fiecare constrângere utilizată (Primary Key, Foreign Key, Not Null, Unique). Denumirea constrângerii este poziţionată în faţa constrîngerii, după cuvântul predefinit CONSTRAINT. Numele constrângerilor sunt formate dintr-un prefix urmat de numele câmpului pe care este setat. Prefixul este prestabilit: pk (pentru PRIMARY KEY); nn (pentru NOT NULL); un (pentru UNIQUE); fk (pentru FOREIGN KEY). Între tipurile de date din Access (din Design View) şi tipurile de date din SQL nu există o corespondenţă perfectă figura 1. Access Double Long Integer Yes/No Date/Time Text SQL Number Integer Logical Date Text Fig. 1 Corespondenţele între tipurile de date din Access şi SQL Pentru tipul de date Text, dacă nu se specifică lungimea acestuia, valoarea implicită este de 255 de caractere. Dacă un nume de câmp conţine caracterul space, acesta trebuie pus între paranteze drepte. De exemplu, [Nume Prenume]. 186

183 Exemplu: Să se creeze o tabelă cu turiştii unei agenţii de turism. Pentru aceştia vom cunoaşte CNP-ul, numele şi prenumele, seria şi numărul de pe cartea de identitate, data naşterii, telefonul şi numărul de paşaport. CREATE TABLE Turisti (CNP_turist TEXT(13) CONSTRAINT pk_cnp_turist PRIMARY KEY, numepren_turist TEXT(30), serienrci TEXT (8), datanast_turist DATE, telefon TEXT (12), nrpass_turist NUMBER); Pentru a crea o tabelă cu o cheie primară compusă, se utilizează următorul format general: CREATE TABLE numet2 (numec1 tip1 [CONSTRAINT nn_c1] [NOT NULL], numec2 tip2 [CONSTRAINT nn_c2][not NULL],, [CONSTRAINT pk_nc1c2] PRIMARY KEY (numec1,numec2)); Pentru crearea unei chei primare compuse, constrângerea va fi specificată la sfărşit, numele acesteia va fi format din prefix şi numele celor două câmpuri. După PRIMARY KEY se specifică între paranteze câmpurile care compun cheia primară. Exemplu: Să se creeze o tabelă cu o cheie primară compusă. Tabela va avea numele ProduseFacturate şi va conţine următoarele câmpuri: numărul facturii, numărul curent al produsului de pe factură, cantitate, preţ unitar, unitatea de măsură şi cotatva. Cheia primară va fi compusă din câmpurile nr_f şi nr_crt. CREATE TABLE ProduseFacturate (nr_f INTEGER NOT NULL, nr_crt INTEGER NOT NULL, cantitate NUMBER, pret_u NUMBER, um TEXT (10), cotatva NUMBER, CONSTRAINT pk_nrfcrt PRIMARY KEY (nr_f, nr_crt)); 187

184 Pentru a crea o tabelă referită, se utilizează următorul format general: CREATE TABLE numet3 (numec1 tip1 [CONSTRAINT nn_c1 NOT NULL] [CONSTRAINT pk_c1 ]PRIMARY KEY, numec2 tip2 [CONSTRAINT nn_c2 NOT NULL] [CONSTRAINT fk_nc2] REFERENCES numet1(numec1), ); Pentru a crea o tabelă referită este necesară crearea legăturii cu tabela de referinţă. Când se defineşte câmpul de legătură, acesta trebuie să fie de acelaşi tip ca şi câmpul corespunzător din tabela de referinţă, apoi se creează o constrângere de tip FOREIGN KEY, iar după cuvântul predefinit REFERENCES se alege numele tabelei de referinţă şi în paranteză numele câmpului de legătură din tabela de referinţă. Numele celor două câmpuri nu trebuie să fie identice. Exemplu: Să se creeze o tabelă cu contractele încheiate de către turiştii agenţiei de turism. Se presupune că un turist încheie mai multe contracte, cunoscându-se numărul contractului, data contractului, tipul serviciului, data plecării, data sosirii, ţara şi beneficiarii (numele celorlalte persoane din familie, dacă este cazul). CREATE TABLE Contracte (nrc INTEGER CONSTRAINT pk_nrc PRIMARY KEY, datac DATE CONSTRAINT nn_datac NOT NULL, tip_serv TEXT(30), data_plec DATE, data_sos DATE, tara TEXT (20), benef TEXT (120), CNP_turist TEXT(13) CONSTRAINT fk_cnp_turist REFERENCES Turisti (CNP_turist)); Comanda ALTER TABLE Comanda ALTER TABLE modifică structura tabelei, permiţând adăugarea unui nou câmp sau ştergerea unui câmp, precum şi modificarea proprietăţilor acestora. 188

185 Dacă se doreşte adăugarea unui nou câmp: ALTER TABLE numet1 ADD COLUMN (numec1 tip1, numec2 tip2,...); Exemplu: Să se adauge în tabela Contracte câmpul suma_platita. ALTER TABLE Contracte ADD COLUMN (suma_platita NUMBER); Dacă se doreşte ştergerea unui câmp: ALTER TABLE numet1 DROP COLUMN numec1; Exemplu: Să se şteargă câmpul ţara din tabela Contracte. ALTER TABLE Contracte DROP COLUMN tara; Dacă se doreşte modificarea proprietăţilor unui câmp: ALTER TABLE numet1 ALTER COLUMN numec1 tip_nou; Exemplu: Să se modifice dimensiunea câmpului benef din tabela Contracte. ALTER TABLE Contracte ALTER COLUMN benef TEXT(100); Dacă se doreşte adăugarea unei constrângeri: ALTER TABLE numet1 ALTER COLUMN numec1 [CONSTRAINT numeconst] {PRIMARY KEY UNIQUE NOT NULL}; Exemplu: Să se adauge o constrângere de tip NOT NULL pentru câmpul data_plec din tabela Contracte. ALTER TABLE Contracte ALTER COLUMN data_plec CONSTRAINT nn_data_plec NOT NULL; 189

186 Dacă se doreşte ştergerea unei constrângeri: ALTER TABLE numet1 DROP CONSTRAINT numeconst; Exemplu: Să se şteargă constrângerea de tip NOT NULL impusă pe câmpul datac. ALTER TABLE Contracte DROP CONSTRAINT nn_datac; Comanda DROP TABLE Comenda DROP TABLE şterge fizic tabela (nu doar datele din tabelă ci şi structura acesteia). DROP TABLE numet1; Exemplu: Să se şteargă tabela Turisti. DROP TABLE Contracte; Dacă o tabelă este de referinţă, nu poate fi ştearsă datorită relaţiei pe care o are cu tabela referită. Pentru a rezolva acest neajuns, se şterge condiţia de legătură dintre tabele cu ajutorul comenzii ALTER TABLE, apoi se şterge tabela. Exemplu: Să se şteargă tabela Turisti. ALTER TABLE contracte DROP CONSTRAINT fk_cnp_turist; DROP TABLE Turisti; Comanda INSERT INTO Comanda INSERT INTO inserează o înregistrare într-un tabel. Formatul general este: INSERT INTO numet1 [(numec1, numec2, )] VALUES (valoare1, valoare2,...); 190

187 Specificarea listei câmpurilor este opţională. Dacă lista câmpurilor este omisă, toate câmpurile din tabelă vor fi completate, în ordinea în care ele au fost create, cu valorile specificate în lista de valori. Dacă lista câmpurilor apare dar nu este completă, unele câmpuri lipsind, acele câmpuri care nu apar în listă vor fi completate cu valoarea NULL, sau cu valoarea setată ca valoare implicită (DEFAULT). Din păcate, în standardul minimal, setarea unei valori predefinite nu este permisă. Numărul câmpurilor din lista de câmpuri trebuie să fie identic cu numărul valorilor din lista valorilor, iar valorile trebuie să corespundă ca tip tipului de date a câmpurilor din lista de câmpuri. Exemplu: Să se introducă o înregistrare în tabela Turişti şi două înregistrări în tabela Contracte (presupunem că tabela are structura de la creare). INSERT INTO Turisti VALUES ( , POP Ion, TM569856, # #, , ); INSERT INTO Contracte VALUES (1452, # #, Charter, # #, # #, Cuba, POP Maria, POP Carla, ); INSERT INTO Contracte (nrc, datac, tip_serv, data_plec, data_sos, tara, CNP_turist) VALUES (1453, # #, Bilete avion, # #, # #, Italia, ); Comanda DELETE Comanda Delete şterge înregistrările care verifică condiţia specificată în clauza Where dintr-o tabelă. Dacă clauza Where nu apare, sunt şterse automat toate înregistrările. Tabela nu dispare fizic, sunt şterse doar înregistrările, structura tabelei rămânând neschimbată. Formatul general: DELETE FROM numet1 [WHERE conditie]; Exemplu: Să se şteargă din tabela Contracte contractul cu codul DELETE FROM Contracte WHERE nrc=1453; 191

188 6.2.6 Comanda SELECT Comanda SELECT permite filtrarea datelor din una sau mai multe tabele pe baza unor condiţii. Formatul general al comenzii: SELECT [DISTINCT] * lista_campuri FROM lista_tabele [WHERE conditie] [GROUP BY crit_grupare] [HAVING crit_dupa_grupare] [ORDER BY el_ordonare [ASC DESC]]; unde: comanda SELECT afişează înregistrări din una sau mai multe tabele; clauza From specifică numele tabelei sau a tabelelor sursă a interogării. Dacă datele provin din mai multe tabele, este necesară adăugarea unei condiţii de legătură în cadrul clauzei WHERE sau setarea unei jocţiuni între tabele. Dacă se doreşte afişarea unui câmp care apare în două tabele, este necesară precizarea numelui tabelei din care acesta face parte. Numele tabelei este separat de numele câmpului prin caracterul punct (de exemplu: Produse.CodProdus); înregistrările pot fi distincte (dacă clauza DISTINCT este selectată o valoare va apare o singură dată) sau nu; filtrarea înregistrărilor se face în funcţie de evaluarea condiţiei logice din cadrul clauzei Where (dacă aceasta este selectată); dacă se utilizeză clauza Group By, aceasta va grupa înregistrările în funcţie de criteriul de grupare. În acest caz pot fi adăugate condiţii pentru grupurile astfel create utilizându-se clauza Having; poate fi impusă o ordine de sortare dacă se utilizează clauza Order by, valoarea implicită fiind Ascending; simbolul * semnifică selecţia tuturor câmpurilor din acea tabelă. Dacă se doreşte omiterea unor câmpuri, se va specifica lista câmpurilor fără a specifica câmpurile respective. Ambele liste lista_campuri şi lista_tabele conţin elemente despărţite între ele prin virgulă. În scrierea interogărilor de selecţie este posibilă utilizarea funcţiilor totalizatoare. Dintre acestea amintim: COUNT returnează numărul total de înregistrări; SUM afişează suma valorilor unui câmp (se poate folosi doar pentru câmpuri numerice); 192

189 AVG calculează media aritmetică a valorilor unui câmp numeric; MAX afişează valoarea maximă din cadrul valorilor unui câmp, dar nu poate fi folosită în cadrul clauzei WHERE; MIN afişează valoarea minimă din cadrul valorilor unui câmp, dar nu poate fi folosită în cadrul clauzei WHERE Comenzi SELECT simple Comenzile SELECT simple au ca sursă înregistrările dintr-un singur tabel. Considerăm următorul tabel: Studenţi cu structura CNP, nume_prenume, serie _numărci (seria şi numărul cărţii de identitate), localitate, adresa, data_nasterii, an_studiu şi medie_an_anterior. Exemplul 1: Să se afişeze toţi studentii. SELECT * FROM studenti; Exemplul 2: Să se afişeze CNP-ul şi numele tuturor studenţilor. SELECT CNP, nume_prenume FROM studenti; Exemplul 3: Să se afişeze CNP-ul şi numele tuturor studenţilor din Timişoara. SELECT CNP, nume_prenume FROM studenti WHERE localitate= Timisoara ; Exemplul 4: Să se afişeze numărul studenţilor din Timişoara. SELECT COUNT(*) FROM studenti WHERE localitate= Timisoara ; Exemplul 5: Să se afişeze numele şi să se calculeze vârsta studenţilor din anul 2 de studiu. SELECT nume_prenume, YEAR(Date())-YEAR(data_nasterii) FROM studenti WHERE an_studiu=2; 193

190 Exemplul 6: Să se afişeze numele studenţilor care încep cu litera A şi sunt născuţi în luna octombrie SELECT nume_prenume FROM studenti WHERE nume_prenume LIKE A* AND datan BETWEEN #01/10/1980# AND #31/10/1980#; Comenzi SELECT complexe Comenzile SELECT complexe au ca sursă înregistrările din mai multe tabele conectate între ele pe baza unei relaţii de legătură. Se pot distinge mai multe tipuri de joncţiuni: joncţiunea naturală (echijoncţiunea, joncţiunea echivalentă), care prespune folosirea clauzei Where urmată de o condiţie de legătură de egalitate între câmpurile corespondente (=). Această condiţie vizează egalitatea valorilor din câmpurile corespondente; joncţiuni ne-echivalente determinaţi de folosirea clauzei Where şi a unei condiţii de legătură exprimată prin comparaţii (<, >, <=, >=, <>, BETWEEN, IN, LIKE); cross (joncţiunea încrucişată) mai puţin utilizată, cu rol în analiza multidimensională a datelor. Se va prezenta în continuare joncţiunea naturală. Formatul general: SELECT [domeniu_selectie] lista_campuri FROM numet1, numet2,... WHERE conditie_jonctiune [AND criterii_de_selectie]; unde domeniul de selecţie poate fi: ALL (vor fi returnate toate înregistrările), DISTINCT, DISTINCTROW (vor fi afişate doar înregistrările distincte), TOP n [PERCENT] (vor fi returnate doar primele n înregistrări sau un procent din numărul total de înregistrări, înregistrările fiind ordonate cu ajutorul clauzei Order By). În acest caz, înregistrările unui tabel se combină rând pe rând cu toate înregistrările din celălalt table (se efectuează produsul cartezian), relaţia dintre cele două tabele fiind stabilită ulterior, prin condiţia de joncţiune specificată în clauza Where. 194

191 În mod uzual, compunerile de tabele au la bază condiţii de tipul cheie primarăcheie străină. Considerând tabela Studenti creată anterior, se consideră tabela Centrepractică, cu structura: IDcentru, Den_centru, Adresa, Localitate, NumeTutore. În tabela studenţi se va adăuga câmpul IDcentru (unui centru de practică sunt arondaţi mai mulţi studenţi). Exemplul 1: Să se afişeze numele tutorelui şi a studenţilor arondaţi acestuia. SELECT NumeTurore, nume_prenume FROM studenti, Centrepractica WHERE studenti.idcentru=centrepractica.idcentru; Exemplul 2: Să se afişeze numărul şi numele centrelor de practică din Timişoara şi CNP-ul studenţilor. SELECT Centrepractica.IDcentru, Den_centru, CNP FROM studenti, Centrepractica WHERE studenti.idcentru=centrepractica.idcentru AND Centrepractica.localitate= Timisoara ; O altă abordare a jocţiunilor împarte compunerile tabelelor în: interne (INNER JOIN) liniile celor două tabele se combină pe baza valorilor identice ale câmpurilor corespondente; externe (OUTER JOIN) destul de rar utilizate, sunt de două tipuri: de stânga LEFT [OUTER] JOIN şi de dreapta RIGHT [OUTER] JOIN. Acestea produc linii în setul de rezultate chiar dacă condiţia de legătură nu este verificată. Setul de înregistrări rezultat conţine liniile celor două tabele, combinate pe baza valorilor identice ale câmpurilor de legătură, la care se adaăugă înregistrările fără corespondent în tabelul care constituie fie membrulstâng al compunerii, fie membrul drept. Specificatorul Outer este opţional. În cazul compunerilor externe este importantă poziţia tabelelor Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p

192 Formatul general al interogărilor ce include compuneri de tabele: SELECT [domeniu_selectie] lista_campuri FROM numet1 {INNER LEFT[OUTER] RIGHT[OUTER]} JOIN numet2 ON conditie_jonctiune [WHERE criterii_de_selectie]; Se vor considera în continuare tabelele Studenti şi CentrePractica. Exemplul 1: Să se afişeze numele tutorelui şi a studenţilor arondaţi acestuia. SELECT NumeTurore, nume_prenume FROM studenti INNER JOIN Centrepractica ON studenti.idcentru=centrepractica.idcentru; Exemplul 2: Să se afişeze numărul şi numele centrelor de practică din Timişoara şi CNP-ul studenţilor. SELECT Centrepractica.IDcentru, Den_centru, CNP FROM studenti INNER JOIN Centrepractica ON studenti.idcentru=centrepractica.idcentru WHERE Centrepractica.localitate= Timisoara ; Agregări de date Funcţiile de grup permit constuirea unor interogări de sintetizare a datelor (Totals). Utilizatorul poate efectua calcule pentru grupuri de înregistrări care au câmpuri cu aceeaşi valoare (de exemplu calcularea mediei studenţilor pe fiecare grupă în parte). Formatul general al instrucţiunii 38 : SELECT [domeniu_selectie] [functie_agregata (numec1) AS alias1] [,lista_selectie] FROM numet1, numet2,... GROUP BY camp_de_grupare [HAVING criteriu_de_grupare] [WHERE criterii_de_selectie]; 38 Năstase P., Cosăcescu L., Covrig L., et al Tehnologia bazelor de date Access 2000, Editura Economică, Bucureşti, 2000, p

193 unde: funcţiile agregate sunt cele amintite în cadrul instrucţiunilor SELECT simple: COUNT, SUM, MIN, MAX, AVG, etc. lista_selectie seminifică una sau mai multe funcţii agregate care au ca argumente câmpuri ale bazei de date; AS alias asociază un pseudonim rezultatului utilizării funcţiei agregat; GROUP BY precizează câmpul sau câmpurile care vor fi criterii de grupare (echivalentul liniei Total din cadrul unei interogări de sintetizare a datelor); HAVING criteriu care va fi aplicat câmpului definit ca argument al funcţiei agregat. Spre deosebire de clauza Where, criteriul va acţiona înaintea grupării înregistrărilor. Se vor considera în continuare tabelele Studenti şi CentrePractica. Exemplul 1: Să se afişeze numele tutorelui şi numărul studenţilor arondaţi acestuia. SELECT Den_centru, NumeTutore, COUNT(CNP) AS Nrstud FROM studenti, Centrepractica GROUP BY Den_centru, NumeTutore WHERE studenti.idcentru=centrepractica.idcentru ORDER BY NumeTutore; Exemplul 2: Să se afişeze denumirea centrelor de practică din Timişoara, Arad şi Deva care au mai mult de 5 studenţi şi numărul studenţilor arondaţi. SELECT Den_centru, COUNT(CNP) As NrStud FROM studenti INNER JOIN Centrepractica ON studenti.idcentru=centrepractica.idcentru GROUP BY Den_centru HAVING COUNT(CNP)>5 WHERE Centrepractica.localitate IN ( Timisoara, Arad, Deva ); 197

194 Subinterogări O subinterogare este formată dintr-o interogare în care este plasată (imbricată) o altă interogare. Formatul general 39 : SELECT [domeniu_selectie] lista_selectie FROM numet1, numet2,... WHERE {numec1 expresie} operator_comparatie (SELECT {camp expresie} FROM numet1, numet2,... [WHERE criterii_selectie_subinterogare]); unde operator_comparatie poate fi =, <, <=, >, >=, <>, IN, LIKE, Between. Observaţii: subinterogările trebuie incluse între paranteze rotunde; subinterogările trebuie plasate în partea dreaptă a operatorului de comparare; nu se va adăuga o clauză ORDER BY într-o subinterogare; atât în interogare cât şi în subinterogare, sursa datelor poate fi simplă (un singur tabel) sau compusă (mai multe tabele), putând fi chiar identică, necesitând crearea legăturilor dintre tabele; clauzele Group By, Having şi Order pot să apară în ambele interogări; dacă se utilizează operatorul IN, rezultatul subinterogării va fi o coloană cu mai multe valori; domeniul rezultatelor unei subinterogări poate fi influenţat prin recurgerea la următoarele cuvinte cheie: ALL, ANY şi EXISTS. În cazul în care se doreşte negarea condiţiei, se plasează operatorul NOT în faţa specificatorului: - ANY/SOME comparaţia este adevărată dacă se găseşte cel puţin o valoare în valorile din coloana returnată de subinterogare. În cazul utilizării acestui specificator, ; - ALL comparaţia este adevărată dacă este verificată de toate valorile din coloana returnată de subinterogare. În mod uzual, comparaţia constă într-o inegalitate: <, <=, >, >=, <>. De regulă, rezultatul comparaţiei este False; 39 Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p

195 - EXISTS comparaţia este adevărată dacă subinterogarea returnează cel puţin o valoare din coloana sau coloanele returnate de subinterogare. Tipuri de subinterogări - subinterogări care au ca rezultat o singură linie (single-row subquery); - subinterogări care au ca rezultat mai multe linii (multiple-row subquery); - subinterogări care au ca rezultat mai multe coloane (multiple-column subquery). Se vor considera în continuare tabelele Studenti şi CentrePractica. Exemplul 1: Să se afişeze numele studenţilor care sunt în acelaşi an cu studentul cu CNP-ul (s-a considerat câmpul CNP ca fiind de tip Text). SELECT nume_prenume FROM studenti WHERE an=(select an FROM Studenti WHERE CNP= ); Exemplul 2: Să se afişeze numele şi media studenţilor cu media anului anterior mai mică decât media tuturor studenţilor. SELECT nume_prenume, medie_an_anterior FROM studenti WHERE medie_an_anterior <= (SELECT AVG(medie_an_anterior) FROM Studenti); Exemplul 3: Să se afişeze toate informaţiile despre studenţii care au media mai mare decât toţi studenţii timişoreni. SELECT * FROM studenti WHERE medie_an_anterior > ALL (SELECT medie_an_anterior FROM studenti WHERE localitate= Timişoara ); 199

196 6.2.7 Comanda UPDATE Comanda Update permite modificarea valorilor unuia sau mai multor câmpuri. Formatul general este: UPDATE numet1 SET numec1={expresie1 (SELECT...)} numec2={expresie2 (SELECT...)} [WHERE conditie]; Dacă clauza WHERE nu apare, vor fi modificate toate valorile câmpului respectiv. În partea din dreapta egalităţii se poate folosi o expresie de calcul (o formulă) care să aibă ca rezultat valoarea care va fi depozitată în câmpul respectiv, sau valoarea poate fi obţinută ca rezultat al unei interogări (comanda SELECT). Exemplul 1: Să se modifice valoarea câmpului ţara din tabela Contracte în Spania, pentru contractul cu numărul UPDATE Contracte SET tara= Spania WHERE nrc=1453; Exemplul 2: Presupunând că în tabela Contracte s-a adăugat câmpul suma_platita, să se micşoreze valoarea sumei cu 2% pentru contractul cu numărul 1453 (clientului i se acordă o reducere de 2%). UPDATE Contracte SET suma_platita=suma_platita-(2/100*suma_platita) WHERE nrc=1453; 200

197 6.3 Concluzii SQL este unul dintre cele mai puternice şi larg răspândite limbaje folosite pentru definirea şi accesarea bazelor de date relaţionale. El permite consultarea bazei de date sau efectuarea anumitor acţiuni prin simpla specificare a comenzilor, fără a fi necesară specificarea unor modalităţi concrete sau a algoritmilor de obţinere a rezultatului. SQL este suportat de diferite sisteme de gestiune a bazelor de date cum ar fi: MS Access, MS SQL Server, DB2, Informix (IBM), Oracle, MySql, etc, diferenţele dintre dialecte fiind minore Rezumatul capitolului SQL nu se încadrează în categoria limbajelor de programare, fiind un limbaj de aplicaţii, destinat bazelor de date relaţionale. Pronunţat sequel, a devenit un standard pentru o gamă largă de sisteme de gestiune a bazelor de date. SQL este un limbaj declarativ, utilizatorul descriind doar informaţiile pe care doreşte să le obţină în urma interogării, fără a fi nevoie să stabilească modalităţile de a ajunge la rezultatele dorite. Pe lângă manipulearea şi regăsirea datelor, se efectuează operaţii complexe privind actualizarea şi administrarea bazei de date. Sistemul de gestiune a bazelor de date Access 2007 acceptă utilizarea limbajului de interogarea SQL. Dialectul Access conţine unele particularităţi în raport cu standardul ANSI SQL, fiind conceput în special pentru crearea interogărilor de selecţie. Existenţa interfeţei grafice QBE permite proiectarea facilă a unei interogări complexe, informaţia astfel definită fiind transformată într-o instrucţiune SQL Florescu V. (coord.), Ionescu B. (coord.), Cozgarea G., et al Baze de date, Editura Infomega, Bucureşti, 2009, p Năstase P., Cosăcescu L., Covrig L., et al Tehnologia bazelor de date Access 2000, Editura Economică, Bucureşti, 2000, p

198 6.5 Întrebări de autoevaluare din partea teoretică 1. Să se specifice avantajele utilizării instrucţiunilor SQL. 2. Să se descrie cele trei componente SQL. 3. Să se creeze următoarele tabele, precum şi relaţia dintre acestea: discipline (codd, dend, an_studiu, sem, obs);note (nrmatr, codd, nota, dataex). 4. Sa se insereze disciplina: codd = 2; dend = baze de date, precum si notele a 2 studenţi la aceasta disciplină. 5. Să se şteargă una dintre notele înregistrate (se va şterge înregistrarea corespunzătoare). 6. Să se elimine câmpul obs din structura tabelei discipline. 7. Să se afişeze disciplinele care se predau în anul 2, sem = Să se afiseze notele obţinute de către studentul cu nrmatr = 1001 la disciplinele din anul 1. Se va afişa şi denumirea disciplinelor. 9. Să se afişeze mediile studenţilor luaţi în evidenţă. 202

199 6.6 Exemple Problemă rezolvată Produse Să se creeze următoarea formă de meniu. Fig. 2 formularul Meniu Rezolvare: Se crează o nouă bază de date cu numele Produse. Se crează tabela Produse cu următoarea structură: cod_p, den_p, um_p, stoc_p, pret_p, cod_magazin. Se vor introduce 3 înregistrări în tabelă. Se crează un nou formular folosind de pe bara de meniuri opţiunea Create, butonul Form Design. De pe panglică se verifică dacă butonul Use Control Wizards este selectat. Acesta trebuie să fie deselectat pentru a permite crearea manuală a controalelor, fără ajutorul asistentului. În continuare se alege butonul Button, executându-se un clic pe formă. Apelând meniul contextual asociat butonului de comandă de pe formă, se selectează opţiunea Properties şi se modifică proprietăţile Name şi Caption pentru fiecare buton în parte. În total sunt 8 butoane de comandă, fiecare având un alt Name şi Caption. Proprietatea Name va fi completată întotdeauna cu prefixul cmd urmat de un cuvânt sau alăturare de cuvinte semnificativă pentru acţiunea executată de buton, fără caracterul spaţiu între ele. Numele butoanelor vor fi în ordine: cmddespr, cmddespr1, cmdinspr, cmdmodden, cmdcrtnou, cmdviz, cmdvaloare, cmdiesire. Proprietatea Caption va fi completată cu textul care apare pe butonul corespunzător din figura 1 şi admite orice fel de caractere, inclusiv caracterul spaţiu. Se selectează butonul dorit, iar în fereastra Property Sheet se modifică cele două proprietăţi aflate pe pagina All. Dacă fereastra Property Sheet nu apare, ea poate fi 203

200 activată folosind butonul Property Sheet de pe panglică, atunci când este selectată opţiunea de meniu Design. Se salvează forma cu numele Meniu (butonul Save din dreapta butonului Office). Pentru a introduce instrucţiuni ataşate butoanelor trebuie apelat editorul Visual Basic. Pentru aceasta, se apelează meniul contextual al fiecărui buton în parte (clic cu butonul din dreapta al mouse-ului), se alege Build Event, Code builder, OK. Mediul de programare Visual Basic Application arată ca în figura următoare: Fig. 3 Mediul de lucru Visual Basic Deasupra procedurii se tastează: DIM v_cod as Integer, v_den as String, v_um as String şi se apasă tasta Enter. Pentru fiecare buton în parte se scrie codul corespunzător. Tot ce este scris după caracterul apostrof semnifică un comentariu, este un mesaj pentru programator, o explicaţie. Dacă acesta apare, nu influenţează cu nimic execuţia programului, dar poate fi ignorat dacă se consideră oportun. Private Sub cmddespr_click() ' se deschide tabela Produse pt. vizualizare in Design DoCmd.OpenTable "Produse", acviewdesign End Sub 204

201 DoCmd este o comandă Visual Basic care permite execuţia unei comenzi (Do Command). Open Table este comanda care permite deschiderea unei tabele. Numele tabelei este scris între ghilimele, iar parametrul acviewdesign specifică deschiderea tabelei în modul Design, nu în Datasheet View. Private Sub cmddespr1_click() ' se deschide tabela Produse pt. vizualizare in Datasheet View DoCmd.OpenTable "Produse" End Sub Private Sub cmdinspr_click() 'adaugarea unei noi inregistrari DoCmd.RunSQL "insert into produse values (cod_produs, den_produs, um_produs, stoc_produs, pret_produs, cod_mag)" End Sub Comanda RunSQL este comanda care permite execuţia unei instrucţiuni SQL (Structured Query Language). Dintre cel mai des utilizate instrucţiuni SQL amintim: SELECT, INSERT INTO, UPDATE, ALTER TABLE, DELETE TABLE. Toate instrucţiunile SQL se scriu între ghilimele, simbolul ; de la sfârşitul comenzilor SQL fiind ignorat. În acest caz s-a folosit instrucţiunea INSERT INTO, care permite introducerea unei singure înregistrări în tabela Produse. Pentru fiecare din parametrii din paranteză, aceştia fiind consideraţi nişte variabile, este creat automat un InputBox (o casetă de introducere a valorilor de la tastatură) care permite citirea lor de la tastatură. Comanda Insert Into conţine cuvântul Values, iar numărul parametrilor din paranteză (care ca nume sunt diferite de numele câmpurilor din tabela Produse) trebuie să fie acelaşi cu numărul câmpurilor din tabelă şi să corespundă ca tip de valori şi semnificaţie. De exemplu, dacă în tabela Produse avem 5 câmpuri, în paranteză, după cuvântul Value, trebuie să avem 5 parametrii, în aceeaşi ordine. Private Sub cmdmodden_click() 'modificarea denumirii unui produs la care este cunoscut codul v_cod = InputBox("Introduceti codul produsului la care doriti sa ii modificati denumirea:") DoCmd.RunSQL "update produse set den_p=denumire where cod_p=" & v_cod End Sub 205

202 Pentru a modifica denumirea unui produs pentru care se cunoaşte codul, se utilizează o variabilă pentru a citi de la tastatură codul respectiv. Variabila v_cod este definită la începutul aplicaţiei, în secţiunea DIM (de dimensionare a variabilelor). Cu ajutorul unei casete de introducere a datelor (Inputbox), valoarea variabilei cod produs este reţinută în variabila v_cod. Pentru a modifica valoarea denumirii produsului, se utilizează instrucţiunea Update. După cuvântul predefinit SET avem o atribuire. Membrul din stânga este numele câmpului den_p din tabela Produse, iar în partea din dreapta avem un parametru. Pentru parametru, Access construieşte automat o casetă de introducere a datelor, permiţând citirea acestuia de la tastatură. Valoarea citită va înlocui valoarea veche a denumirii. Dacă nu este adăugată condiţia Where, toate denumirile produselor vor fi modificate. Pentru a modifica doar un anumit câmp, în cadrul condiţiei Where este specificată o condiţie logică. Cod_p este câmpul cod produs din tabela Produse. Pentru a se utiliza valoarea reţinută în variabila v_cod, acesta va fi scris în afara ghilimelelor. Simbolul & este simbolul care semnifică concatenarea mai multor valori de tip şir de caractere. Private Sub cmdcrtnou_click() 'selectarea produselor cu stoc 0 si crearea unei tabele cu aceste produse DoCmd.RunSQL "Select cod_p, den_p, um_p, stoc_p, pret_p, cod_m into StocNul from produse where stoc_p=0" DoCmd.OpenTable "StocNul" End Sub În cazul instrucţiunii SQL SELECT, este necesară introducerea clauzei INTO (care crează automat o nouă tabelă ca rezultat al interogării). Noua tabelă creată se numeşte StocNul. Condiţia de filtrare este ca stocul produsului să fie zero. Dacă în tabela Produse nu există nici o înregistrare în care stocul produsului să fie zero, noua tabelă va fi creată dar nu conţine nici o înregistrare. Noua tabelă creată va fi deschisă pentru a fi vizualizată. Private Sub cmdviz_click() 'vizualizarea produselor cu codul >= o valoare introdusa de la tastatura v_cod = InputBox("Introduceti un cod pentru a fi afisate produsele cu codul mai mare decat aceasta valoare") DoCmd.RunSQL "Select cod_p,den_p,um_p,stoc_p, pret_p, cod_m into Temp1 from produse where cod_p>=" & v_cod DoCmd.OpenTable "Temp1" End Sub 206

203 Pentru a citi o valoare de la tastatură este necesară declararea unei variabile în care valoarea să fie stocată. Variabila poartă numele v_cod. Valoarea este citită de la tastatură prin intermediul comenzii InputBox (crearea unei casete de introducere a textului). Comanda Select crează o nouă tabelă numită Temp1, fiind selectate doar câmpurile definite în lista câmpurilor (cod_p, den_p, um, stoc, pret_u, cod_m) şi acele înregistrări care verifică condiţia Where (codul produsului să fie mai mare decât valoarea care a fost introdusă în variabila v_cod). Tabela Temp1 va fi apoi deschisă pentru a vizualiza rezultatul interogării. Private Sub cmdvaloare_click() DoCmd.RunSQL "select cod_p, den_p, um_p, pret_p, stoc_p, pret_p*stoc_p as valoare into Valoare from produse" DoCmd.OpenTable "Valoare" End Sub Acest buton permite calcularea unui câmp în cadrul unei interogări. Acesta se scrie în lista de câmpuri, începând cu formula de calcul, urmată de cuvântul predefinit AS şi numele care se doreşte să apară în capul de tabel ca nume de câmp: valoare. Rezultatul interogării este un nou tabel cu numele Valoare. Pentru a vedea rezultatul interogării se deschide tabelul Valoare. Private Sub cmdiesire_click() DoCmd.Quit End Sub Comanda Quit permite închiderea aplicaţiei. Pentru a putea utiliza butoanele trebuie setat nivelul de securitate astfel încât să permită utilizarea codurilor Visual Basic Application. Pentru aceasta, de pe bara Security Warning se selectează butonul Options..., selectând opţiunea Enable this content. 207

204 Fig. 4 Setarea nivelului minimal de securitate Problemă rezolvată Aprovizionare Să se creeze o bază de date cu numele Aprovizionare. Să se creeze o formă de meniu cu butoane de comandă figura 1 care să permită următoarele operaţii: 1. Crearea tabelelor necesare gestionării procesului de recepţie a materialelor. Toate materialele achiziţionate de firmă sunt cuprinse întrun nomenclator de materiale în care sunt specificate: codul materialului, denumire material, unitate de măsură şi clasa de calitate. În momentul realizării unei aprovizionări se întocmeşte o notă de recepţie pe care sunt consemnate: numărul recepţiei, data recepţiei, denumirile materialului, cantităţile şi preţurile aferente fiecărui material; 2. Inserarea înregistrărilor în tabele (3 înregistrări în tabelele de referinţă, mai multe înregistrări în tabela referită). 3. Să se modifice structura tabelei receptiemateriale adăugându-se un câmp denumit cotatva. Să se şteargă câmpul clasa din tabela Materiale. 4. Să se modifice toate valorile câmpului cotatva cu valoarea 0,24. Să se modifice data pentru numărul de receptie în Să se afişeze toate produsele cu unitatea de măsură bucăţi. Să se afişeze toate notele de recepţie din data de , inclusiv denumirea produselor, cantitatea şi preţul, calculându-se valoarea. Să se afişeze pentru fiecare număr de recepţie valoarea totală (suma valorilor). 208

205 6. Să se şteargă toate notele de recepţie corespunzătoare codului material 111 din tabela receptiemateriale. Să se şteargă toate înregistrările din tabela receptiemateriale. 7. Să se şteargă toate tabele din baza de date (inclusiv cele create în cadrul interogărilor). Fig. 5 formularul Meniu Rezolvare: Se va crea o nouă bază de date cu numele Aprovizionare. Table 1 se închide, fără a fi salvat. Tabelele nu vor fi create cu ajutorul instrumentelor vizuale, ci tot cu ajutorul comenzilor SQL. Construind matricea dependenţelor funcţionale se ajunge la următoarea structură a bazei de date figura 6. Fig. 6 Fereastra Relationship Baza de date Aprovizionare Pentru a crea un formular nou, se selectează opţiunea de meniu Create, apoi butonul Form Design. Se salvează formularul cu numele Meniu. 1. Pentru a adăuga primul buton de comandă pe formă se deselectează butonul de pe panglică, se alege butonul şi 209

206 se execută clic pe formular. Se apelează meniul contextual asociat butonului şi se alege opţiunea Properties. În fereastra Property Sheet se modifică proprietăţile Name: cmdcreare şi Caption: Crearea tabelelor figura 7. Fig. 7 Butonul cmdcreare Pentru a asocia cod butonului, se apelează meniul contextual al butonului şi se alege opţiunea Build Event/Code builder. Codul asociat butonului de Creare este detaliat în continuare: Private Sub cmdcreare_click() DoCmd.RunSQL "CREATE TABLE materiale (codm integer CONSTRAINT pk_codm PRIMARY KEY CONSTRAINT nn_codm NOT NULL, denm TEXT(15), um TEXT(10), clasa TEXT(10))" MSG = MsgBox("Tabela materiale a fost creata!", vbokonly) DoCmd.RunSQL "CREATE TABLE receptii (nrrec INTEGER CONSTRAINT pk_nrrec PRIMARY KEY CONSTRAINT nn_nrrec NOT NULL, datarec DATE)" MSG = MsgBox("Tabela receptii a fost creata!", vbokonly) DoCmd.RunSQL "CREATE TABLE receptiemateriale (nrrec INTEGER CONSTRAINT fk_nrrec REFERENCES receptii(nrrec), codm INTEGER CONSTRAINT fk_codm REFERENCES materiale(codm), cantitate INTEGER, pret_unitar NUMBER, CONSTRAINT pk_recmat PRIMARY KEY(nrrec,codm))" MSG = MsgBox("Tabela receptiemateriale a fost creata!", vbokonly) End Sub 210