CAPITOLUL 1. BAZE DE DATE RELAIONALE 1.1.

NOIUNI INTRODUCTIVE DESPRE BAZE DE DATE

nc de la nceputurile sale, informatica a fost confruntat nu numai cu efectuarea de calcule sofisticate, tiinifice, dar i cu stocarea i gestionarea unui volum de informaii din ce n ce mai mare. Astfel nct apariia unor instrumente software dedicate gestiunii i prelucrrii datelor a fost doar o problem de timp. Prima care a resimit acut nevoia unor instrumente software dedicate administrrii unor cantiti imense de informaii a fost armata SUA. n a doua parte a anilor '50 Departamentul Aprrii al SUA a format un grup de specialiti pentru elaborarea unui limbaj destinat aplicaiilor administrative, n care dificultatea major inea de volumul imens de resurse materiale i financiare ce trebuia "chivernisit" i pentru care erau necesare rapoarte dintre cele mai diverse. La acel moment apruse FLOWMATIC, limbaj precursor celui care a fost considerat cteva decenii regele informaticii economice COBOL (Common Business Oriented Language). Arhitectura aplicaiilor de acest tip aveau ca specific faptul c fiecare dat (Data1, Data2,... Datan) este descris (nume, tip, lungime), autonom, n toate fiierele n care apare. Mai mult, descrierea fiecrui fiier de date (cmpurile care-l alctuiesc, tipul i lungimea fiecruia, modul de organizare (secvenial, indexat, relativ etc.)) este obligatorie n toate programele care l citesc sau modific. ntre FIIER1, FIIER2, ... FIIERn nu exist nici o relaie definit explicit. Acest mod de lucru este referit ca file-based sau flat files (fiiere independente). Spre exemplu, marca angajatului (Marca) este prezent n dou fiiere de date, FIIER1 (ANGAJAT) i FIIER2 (PONTAJ). Dac, prin program, se modific formatul sau valoarea acesteia n FIIER1, modificarea nu se face automat i n FIIER2; prin urmare, o aceeai dat, Marca, va prezenta dou valori diferite n cele dou fiiere, iar informaiile furnizate de sistemul informatic sunt redundante i prezint un mare risc de pierdere a coerenei. De exemplu, era posibil ca marca angajatului s fie declarat ntr-un fiier ca fiind format din 4 caractere, iar n cellalt din 5 cifre. Meninerea integritii datelor devine extrem de dificil n aceste condiii. Chiar numai i din cele prezentate mai sus, se pot desprinde cteva dezavantaje ale organizrii datelor dup modelul fiierelor independente: Redundana i inconsistena datelor: o aceeai dat apare n mai multe fiiere; n aceste cazuri exist riscul modificrii acesteia ntr-un fiier fr a face modificrile i n toate celelalte fiiere. Dificultatea accesului. ntr-o ntreprindere, o aceeai informaie este exploatat de mai muli utilizatori. Spre exemplu, pentru departamentul care se ocup cu gestiunea stocurilor, intrrile de materiale trebuie ordonate pe magazii (depozite) i repere, n timp ce pentru departamentul care se ocup cu decontrile cu partenerii de afaceri ai ntreprinderii, intrrile trebuie ordonate pe furnizori ai materialelor. Or, fiierele tradiionale nu faciliteaz accesarea datelor dup mai multe criterii, specifice diferiilor utilizatori sau grupuri de utilizatori. Problemele de securitate in de dificultatea crerii unui mecanism care s protejeze pe deplin datele din fiiere de accesul neautorizat. Inabilitatea de a obine rspunsuri rapide la probleme ad-hoc simple.

Costul ridicat se datoreaz gradului mare de redundan a datelor, eforturilor deosebite ce trebuie depuse pentru interconectarea diferitelor tipuri de fiiere de date i pentru asigurarea funcionrii sistemului n condiiile respectrii unui nivel minim de integritate i securitate a informaiilor. Aceste dezavantaje sunt mai mult dect convingtoare, determinndu-i pe specialiti s caute alte soluii, concretizate prin conceptul de baz de date. Sintagma baz de date apare pentru prima dat n titlul unei conferine organizate la Santa Monica (California) n 1964 de System Development Corporation. Consacrarea definitiv a termenului este marcat de publicarea n anul 1969, de ctre CODASYL, n cadrul unei conferine dedicate limbajelor de gestiune a datelor, a primului raport tehnic n care este prezentat conceptul de baz de date. Fa de modelul fiierelor independente, noutatea o constituie existena unui fiier de descriere global a bazei, astfel nct s se poat asigura independena programelor fa de date. Avantajele organizrii informaiilor n baze de date decurg tocmai din existena acestui fiier de descriere global a bazei, denumit, n general, dicionar de date. Extragerea i modificarea datelor, altfel spus, lucrul cu fiierele de date, se deruleaz exclusiv prin intermediul dicionarului n care se gsesc informaii privitoare la structura datelor i restriciile ndeplinite de acestea. O baz de date (BD) reprezint un ansamblu structurat de fiiere, care grupeaz datele prelucrate n aplicaiile informatice ale unei persoane, grup de persoane, ntreprinderi, instituii etc. Formal, BD poate fi definit ca o colecie de date aflate n interdependen, mpreun cu descrierea datelor i a relaiilor dintre ele, sau ca o colecie de date utilizat ntr-o organizaie, colecie care este automatizat, partajat, definit riguros (formalizat) i controlat la nivel central. Atunci cnd vorbim despre o baz de date, trebuie avute n vedere dou aspecte fundamentale ale acesteia, schema i coninutul. Organizarea bazei de date se reflect n schema sau structura sa, ce reprezint un ansamblu de instrumente pentru descrierea datelor, a relaiilor dintre acestea, a semanticii lor i a restriciilor la care sunt supuse. Ansamblul informaiilor stocate n baz la un moment dat constituie coninutul sau instanierea sau realizarea acesteia. n timp ce volumul prezint o evoluie spectaculoas n timp, schema unei baze rmne relativ stabil pe tot parcursul utilizrii ei. Datele stocate ntr-o BD prezint, ntr-o msur mai mare sau mai mic, urmtoarele caracteristici: partajabilitate disponibilitate pentru un mare numr de utilizatori i aplicaii; persisten existen permanent, din momentul prelurii n baz pn n momentul actualizrii sau tergerii; securitate protejarea de accesul neautorizat, att n ceea ce privete citirea i copierea, ct i modificarea i tergerea; validitate referit i ca integritate sau corectitudine privete gradul de adecvare dintre datele din baz i realitatea, procesele pe care le reflect aceste date; consisten ori de cte ori diverse aspecte ale proceselor sau fenomenelor reale sunt preluate n baz sub forma a doua sau mai multor entiti sau atribute, aceste entiti /atribute trebuie s fie n concordan unele cu celelalte, s respecte relaiile existente ntre aspectele proceselor /fenomenelor reale; nonredundan - pe ct posibil, o entitate din realitate ar trebui s aib un singur corespondent n baza de date; independen privete autonomia logic i fizic evocate mai sus.

De-a lungul istoriei bazelor de date au existat mai multe modele de organizare a datelor. Fr a intra n detalii, s le amintim totui: Modelul ierarhic. Primele Sisteme de Gestiune a Bazelor de Date - SGBD lucrau cu baze de date ierarhice, n care structura datelor era prezentat sub forma unui arbore. Modelul reea. Este o dezvoltare a modelului ierarhic, prin care se pot reprezenta i situaiile n care un fiu "posed" mai muli tai. Modelul relaional a fost urmtorul n ordinea cronologic i rmne cel care domin copios piaa bazelor de date i la acest moment, motiv pentru care vom cu prezentarea ceva mai detaliat a sa. Modelul obiectual. S-a ncercat aplicarea abordrii orientate pe obiecte (OO) i n lumea bazelor de date ns, spre deosebire de domeniile analizei, proiectrii i programrii, fr prea mult succes. Piaa SGBD OO se afl sub 6% din valoarea total a pieei bazelor de date. Modelul relaional-obiectual. Este un model mai recent ce ncearc s valorifice deopotriv atuurile relaionalului cu orientarea pe obiecte. Dei privit mai degrab cu nencredere n cercurile teoreticienilor, acest model se impune ncet-ncet datorit marilor productori de software dedicat bazelor de date.

1.2. PREZENTARE GENERAL A MODELULUI RELAIONAL

Un model de date are trei piloni: componenta structural, adic modul n care, efectiv, la nivel logic, datele sunt stocate n baz, componenta de integritate, adic regulile ce pot fi declarate pentru datele din baz i o component manipulatorie, adic modul n care obinem informaii din bazele de date (ceea ce presupune o serie de operatori aplicabili uneia sau mai multor relaii). Dei puternic contestat, i cu neajunsurile sale, modelul relaional de organizare a bazelor de date rmne cel mai utilizat. Cu foarte puine excepii, toate aplicaiile software realizate pentru companii mai mici sau mai mari, bnci, universiti sunt realizate cu produse/instrumente ce gestioneaz baze de date relaionale. n acest paragraf vom discuta aspectele structurale ale modelului (paragraful 2.2) i pe cele de integritate (paragraful 2.3), urmnd ca n capitolul urmtor, mai ales n ultimile trei paragarafe, s ne ocupm de manipularea datelor, altfel spus, de modalitile n care stoarcem de informaii baza de date.

1.2.1. Puin istorie

Modelul relaional de organizare a datelor s-a conturat n dou articole publicate n 1969 i 1970 de ctre E.F. Codd, matematician la centrul de cercetri din San Jose (California) al firmei IBM1. n acel moment, tehnologia bazelor de date era centrat pe modelele ierarhic i reea, modele ce depind ntr-o mai mare msur de organizarea intern a datelor pe suportul de stocare. Codd a propus o structur de date tabelar, independent de tipul de echipamente i software de sistem pe care este implementat, structur "nzestrat" cu o serie de operatori pentru extragerea datelor. Dei puternic matematizat, modelul relaional este relativ uor de neles. Modelul relaional al datelor se poate defini printr-o serie de structuri de date (relaii alctuite din tupluri), operaii aplicate asupra structurilor de date (selecie, proiecie, jonciune etc.) i reguli de integritate care s asigure consistena datelor (chei primare, restricii refereniale s.a.). Modelarea realitii se concretizeaz n tabele de valori numite relaii, avndu-se n vedere c: o relaie are un nume; o coloan reprezint un atribut; o linie reprezint un n-uplet (tuplu) de valori ale celor n atribute din relaie;

ordinea liniilor i coloanelor n cadrul tabelei nu este relevant pentru coninutul informaional. Fiecare linie a tabelei reprezint o entitate sau un fapt al realitii, n timp ce o coloan reprezint o proprietate a acestei entiti sau fapt. Introducnd un plus de rigoare, se cuvine de remarcat c entitatea poate fi nu numai un obiect concret/proces (o persoan, un lucru oarecare), dar i o relaie ntre obiecte (persoane, lucruri), cum ar fi: contractele de afaceri, cstoriile (exist totui cteva deosebiri ntre acestea i precedentele), structura ierarhic a unei organizaii etc. n plus, nu e ntotdeauna evident care dintre informaii sunt entiti, care atribute i care asociaii (relaii). Ansamblul valorilor stocate n tabelele reprezint coninutul bazei de date, coninut ce poate fi modificat prin operaiuni de actualizare: introducerea unor linii (tupluri) noi, tergerea unor linii, modificarea valorii unor atribute. Modelului relaional i este asociat teoria normalizrii, care are ca scop prevenirea comportamentului aberant al relaiilor n momentul actualizrii lor, eliminarea datelor redundante i nlesnirea nelegerii legturilor semantice dintre date. Dei IBM a fost prima care a iniial un proiect destinat elaborrii unui SGBD relaional (System/R, ncepnd cu 1974), prima firm care a lansat primul SGBDR comercial a fost Relational Software Inc., astzi Oracle. Infiinarea firmei a avut loc n 1977, iar lansarea produsului n 1979. Impunerea pe pia a SGBD-urilor grefate pe modelul relaional a fost mult mai dificil dect s-ar putea nelege astzi. Abia n deceniul 9, datorit vitezei ameliorate, securitii sporite i mai ales productivitii dezvoltatorilor de aplicaii, modelul relaional a ctigat supremaia. Exist o larg tipologie a SGBDR-urilor, aa nct orice categorisire i are riscul su. Cele mai accesibile i, implicit, cele mai utilizate sunt SGBD-urile dedicate iniial uzului individual: Access, Paradox, Visual FoxPro. Astzi, multe dintre acestea au caracteristici profesionale i pot fi folosite la dezvoltarea aplicaiilor pentru simultan a zeci de utilizatori.

Extrase din lucrarea [Codd70] se gsesc la adresa http://www.acm.org/classics/nov95/. De asemenea, o excelent analiz a articolelor lui Codd este n [Date98].

Pentru aplicaiile complexe din bnci, corporaii, organizaii i instituii de mari dimensiuni sau impus SGBDR-urile de "categoria grea": Oracle, DB2 (IBM), Informix (DB2), Sybase, SQL Server (Microsoft). Acestea sunt mult mai robuste, mult mai fiabile, dar i costisitoare. n ultimul timp i-au fcut apariia, ca alternative la marii coloi, aa zisele Free-DBMS-uri, precum PostgreSQL, MySQL, Interbase etc. Acestea ruleaz, de obicei, pe sisteme de operare de tip Linux (foarte ieftine) i se ntrevd ca adversari serioi ai marilor productori.

1.2.2. Concepte de baz utilizate n modelul relaional

O baz de date relaional (BDR) poate fi definit ca un ansamblu de relaii (tabele); fiecare tabel (sau tabel), alctuit din linii (tupluri), are un nume unic i este stocat pe suport extern (de obicei disc). La intersecia unei linii cu o coloan se gsete o valoare atomic (elementar). O relaie conine informaii omogene legate de anumite entiti, procese, fenomene: CRI, STUDENI, FACTURI, CLIENI, PRODUSE etc. n figura 1.1 este prezentat tabela Angajat i evideniaz principalele concepte ale modelului relaional.
Atribute/Coloane Tu ANGAJAT plu/ Lin ie
Marca 1001 1002 1003 1004 Nume Minculescu Roman Titulescu Porumb Prenume Cristi Teodor Radu Maria CNP 1520909371540 1680818225541 1540101374074 2670905221199 Sex B B B F Adresa Primaverii, 22 NULL Husului,231 Viilor, 88A SalarTarifar 2400 1250 1400 1900 CodDepart 1 3 1 2

Do menii

Valoare atomic

Figura 1.1. Relaia (tabela) ANGAJAT ntre relaii (tabele) se stabilesc legturi prin intermediul unor atribute (coloane) comune. n figura 1.2 este prezentat un exemplu simplificat de baz de date pentru evidena personalului.
DEPARTAMENT CodDepart DenumireDepart 1 Resurse umane 2 Contabilitate 3 Aprovizionare NrPosturi 3 5 4

ANGAJAT Marca Nume 1001 Minculescu 1002 Roman 1003 Titulescu 1004 Porumb

Prenume Cristi Teodor Radu Maria

CNP 1520909371540 1680818225541 1540101374074 2670905221199

Sex B B B F

Adresa Primaverii, 22 NULL Husului,231 Viilor, 88A

SalarTarifar 2400 1250 1400 1900

CodDepart 1 3 1 2

PONTAJ Luna Anul Marca 9 2007 1001 9 2007 1002 9 2007 1003 9 2007 1004 10 2007 1001 10 2007 1002

OreZi OreSuplimentare OreNoapte 162 10 0 164 8 0 84 0 24 168 0 0 152 12 0 162 0 28

Fig. 1.2 Exemplu de baz de date relaional n tabelul 1.1 sunt prezentate principalele noiuni utilizate n descrierea modelului relaional, precum i termenii corespondeni din teoria mulimilor i din domeniul prelucrrii datelor.

Tabel 1.1 Terminologia diferitelor domenii de lucru Baze de date Convenii din prelucrarea relaionale datelor Tabel Fiier Toate valorile Toate valorile posibile pe posibile pe care le poate care le poate avea un cmp avea o coloan Tuplu Linie nregistrare n modelul relaional, datele sunt stocate sub forma tabelelor, numite i relaii (de aici provine i numele de model relaional). Conceptul de relaie (tabel) permite reprezentarea unei entiti din universul modelat. n exemplul nostru din figura 1.2 se regsesc trei tabele: ANGAJAT, DEPARTAMENT i PONTAJ. Fiecare linie dintr-o tabel (relaie), numit tuplu, conine date despre un caz sau o instan a entitii reprezentate prin tabela respectiv. De exemplu, fiecare linie din tabela ANGAJAT conine datele necesare despre un anumit angajat al firmei. Prin urmare, tabela ANGAJAT va conine attea linii ci angajai are firma. Ordinea tuplurilor (liniilor) nu prezint importan din punctul de vedere al coninutul informaional al tabelei. Fiecare coloan (atribut) conine informaii despre o anumit caracteristic a entitii reprezentate, ele fiind cunoscute i sub numele de valori ale caracteristicii. Astfel, fiecare instan a entitii ANGAJAT este descris prin urmtoarele caracteristici: marca, numele, prenumele, CNP-ul, sexul, adresa, salariul tarifar i codul departamentului n care lucreaz. Atributele reinute ntr-o tabel depind de nevoile informaionale ale utilizatorilor. La intersecia fiecrei linii i coloane se va introduce o valoare atomic, adic o valoare care nu mai poate fi descompus. De exemplu, la intersecia coloanei SalarTarifar cu ultima linie din tabela ANGAJAT se regsete o singur valoare, 1900, care nu mai poate fi descompus (vezi figura 1.1). Totui, n exemplul nostru se poate considera c unele coloane nu conin valori atomice. Coloana Adresa din tabela ANGAJAT ar putea fi descompus cel puin n ora, strada i numr. Este adevrat ns, fr a intra n alte detalii legate de procesul de normalizare, trebuie s spunem c atomicitatea valorilor stocate ntr-o tabel este o noiune relativ. Ea depinde de nevoile informaionale ale utilizatorului. Astfel, dac utilizatorul va avea nevoie s extrag din baza de date i s prelucreze doar datele despre angajaii care locuiesc pe o anumit strad sau la un anumit numr indiferent de numele strzii, atunci se justific descompunerea atributului Adresa n mai multe atribute, precum Strada, Numar, Bloc, Scara, Apartament, Localitate. n cazul n care nu se solicit prelucrarea datelor despre angajai n funcie de pri ale adresei, atributul Adresa poate fi considerat atomic. Fiecare atribut este caracterizat printr-un nume i un domeniu de valori pe care le poate lua. Domeniul poate fi definit ca mulimea tuturor valorilor acceptate (autorizate) pentru un atribut (coloan) al relaiei: pentru atributul Sex, domeniul este alctuit din dou valori: Femeiesc (F) i Brbtesc (B); domeniul atributului Judet este alctuit din numele fiecrui jude (plus Bucureti). domeniul unui atribut precum SalarTarifar este cu mult mai larg, fiind alctuit din orice valoarea cuprins ntre 460 (salariul minim) i 99999 RON. n figura 1.1 pe a doua linie a tabelei n coloana Adresa apare o valoarea curioas notat NULL. Valoarea NULL este considerat o metavaloare i indic faptul c, n acel loc, informaia este 6 Teoria mulimilor Relaie Domeniu

necunoscut sau inaplicabil. Valoarea NULL este diferit, ns de valorile 0 sau spaiu. n exemplul nostru, valoarea NULL semnific faptul c nu se cunoate nc adresa angajatului cu marca 1002. Orice relaie (tabel) posed cel puin o cheie, adic un atribut sau un grup de atribute prin care se poate identifica n mod unic orice tuplu (linie). Cnd cheia este constituit dintr-un singur atribut, poart numele de cheie simpl, iar atunci cnd este format din mai multe atribute ea se numete cheie compus. Dac o tabel dispune de mai multe chei, una va fi aleas drept cheie primar. n figura 1.2, coloanele care reprezint cheia primar sunt evideniate cu caractere ngroate (bold). Tabelele ANGAJAT i DEPARTAMENT au cheie primar simpl, respectiv Marca i CodDepart, n timp ce tabela PONTAJ are o cheie compus, format din Luna, Anul i Marca. Remarcai n figura 1.1 c doar unul din cele trei atribute nu poate juca rolul de cheie deoarece exist valori care se pot regsi pe mai multe linii. n mulimile matematice nu este permis ca un obiect s apar de mai multe ori. Ct timp o relaie este o mulime de tupluri, teoretic nici o linie a unei relaii nu poate fi duplicatul altei linii (SQL admite existena unor linii duplicat ntr-un tabel, considerndu-se c exist modaliti de eliminare a lor, dac se dorete). Dac o coloan sau o combinaie de coloane nu poate s identifice n mod unic o linie, atunci trebuie inventat o coloan-cheie special. Oricum, fiecare relaie trebuie s dispun de o cheie primar. Vom reveni asupra noiunii de cheie n paragraful urmtor cnd vom discuta despre restricia de unicitate. Legtura ntre tupluri din tabele diferite se realizeaz prin intermediul unei coloane comune, utilizndu-se noiunea de cheie strin, ntlnit uneori n literatur i sub numele de cheie extern. O cheie strin este un atribut care apare ntr-o tabel i care este cheie primar ntr-o alt tabel cu care se afl n legtur. n exemplul nostru din figura 1.2 cheile strine sunt evideniate prin caractere nclinate (italic). Legtura dintre tabelele DEPARTAMENT i ANGAJAT este realizat prin intermediul atributului comun CodDepart. Acest atribut joac rolul de cheie primar n tabela-printe DEPARTAMENT i rolul de cheie strin n tabela-copil ANGAJAT. Legtura dintre tabelele ANGAJAT i PONTAJ se realizeaz prin intermediul atributului Marca, care este cheie primar n prima tabel i cheie strin n cea de-a doua. n legtur cu cheia strin se definete restricia de integritate referenial, asupra creia vom reveni n paragraful urmtor.

1.3. RESTRICII ALE BAZEI DE DATE

Restriciile definesc o serie de reguli pe care trebuie s le ndeplineasc datele din baz. Cei care lucreaz cu bazele de date sunt foarte interesai n declararea restriciilor, pentru c, odat definite, de respectarea lor se va ngriji sistemul de gestiune a bazelor de date (adic programele de lucru cu bazele de date). Esenial este c, ajutai de restricii, putem crete gradul de corectitudine i de ncredere al datelor din baz. Cele mai importante restricii definibile ntr-o baz de date relaional sunt: restricia de domeniu, de atomicitate, de unicitate, referenial i restriciile-utilizator. Restricia de atomicitate, care evoc obligativitatea ca orice valoare aflat la intersecia unei linii cu o coloan s fie atomic, am lmurit-o (sperm) n paragraful anterior, prin discuia asupra atributului Adresa. Celelalte vor fi descrise n continuare.

1.3.1. Restricia de domeniu

Dup cum am vzut n paragraful anterior, un atribut este definit printr-un nume i un domeniu. Orice valoare a atributului trebuie s se ncadreze n domeniul definit. Exist mai multe moduri de percepie a acestei restricii. O parte din informaticieni substituie domeniul tipului atributului: numeric, ir de caractere, dat calendaristic, logic (boolean) etc. i, eventual, lungimii (numrul maxim de poziii/caractere pe care se poate ntinde un atribut). De exemplu, dac vom declara atributul SalarTarifar de tip numeric, cu lungimea de 5 cifre, atunci domeniul su va orice numr natural cuprins ntre 0 i 99999 (nu am declarat nicio zecimal). Dup cum se observ, este luat n calcul numai aspectul sintactic al domeniului. Faptul c indicativul auto al unui jude (vezi plcuele de nmatriculare) poate fi una din valorile: IS, TM, B etc. reprezint o restricie de comportament sau, mai simplu, o restricie definit de utilizator. Cea de-a doua categorie privete domeniul deopotriv sintactic i semantic. Astfel, domeniul sintactic al atributului Judet este un ir de dou caractere, obligatoriu litere (sau o liter i un spaiu, pentru Bucureti), i, chiar mai restrictiv, literele sunt obligatoriu majuscule. Din punct de vedere semantic, indicativul poate lua una din valorile: IS, TM Pentru atributul SalarTarifar putem introduce o restricie semantic prin care salariul tarifar s fie mai mare dect salariul minim pe economie.

1.3.2. Restricia de nenulitate

Modelul relaional accept ca, atunci cnd nu se cunoate valoarea unui atribut pentru o anumite entitate, sau cnd pentru acel obiect, entitate, persoan etc. atributul este inaplicabil, s se foloseac valoarea NULL. Celui de-al doilea angajat din figura 1.1 nu i se cunoate adresa. ntr-o baz de date relaional avem posibilitatea de a le impune unor atribute s aib ntotdeauna valori specificate, altfel spus, le interzicem valorile nule, n timp ce altor atribute li se pot permite valori nule. Prin urmare, la adugarea unor noi date n baz, utilizatorii sunt obligai s specifice valoarea pentru anumite atribute, n timp ce pentru altele nu. Modul n care se declar i se afieaz o restricie de nulitate depinde de la SGBD la SGBD. n capitolul urmtor vom vedea cum poate fi declarat o astfel de restricielaxat Ca regul, atributele importante, ce in de identificarea sau caracterizarea unei entiti, proces, fenomen, precum i cele implicitate n calculul unor informaii importante, sunt declarate NOT NULL, iar pentru atributele fr importan deosebit se pot accepta valori nule.

1.3.3. Restricia de unicitate

ntr-o relaie nu pot exista dou linii identice (dou linii care prezint aceleai valori pentru toate atributele). Mai mult, majoritatea relaiilor prezint un atribut, sau o combinaie de atribute, care difereniaz cu siguran un tuplu de toate celelalte tupluri ale relaiei. Cheia primar a unei relaii (tabele) este un atribut sau un grup de atribute care identific fr ambiguitate fiecare tuplu (linie) al relaiei (tabelei). Dup Codd, exist trei restricii pe care trebuie s le verifice cheia primar: unicitate: o cheie identific un singur tuplu (linie) al relaiei. compoziie minimal: atunci cnd cheia primar este compus, nici un atribut din cheie nu poate fi eliminat fr distrugerea unicitii tuplului n cadrul relaiei; n cazuri limit, o cheie poate fi alctuit din toate atributele relaiei. 8

valori non-nule: valorile atributului (sau ale ansamblului de atribute) ce desemneaz cheia primar sunt ntotdeauna specificate, deci ne-nule i, mai mult, nici un atribut din compoziia cheii primare nu poate avea valori nule; aceast a treia condiie se mai numete i restricie a entitii. Dac ntr-o relaie exist mai multe combinaii de atribute care confer unicitate tuplului, acestea sunt denumite chei candidate. Proiectantul va alege una dintre ele drept cheie primar. O cheie candidat care nu a fost aleas cheie primar este referit ca i cheie alternativ. Revenind la exemplul nostru, tabela ANGAJAT conine dou atribute cu rol de identificator: marca, un cod unic atribuit n firm fiecrui angajat n momentul angajrii, i CNP, un cod unic atribuit fiecrei persoane din Romnia n momentul naterii i care rmne neschimbat pe tot parcursul vieii persoanei. Celelalte atribute ale tabelei nu pot avea rol de identificator. De exemplu, atributele Nume i Prenume nu poate fi cheie, deoarece chiar i ntr-o ntreprindere de talie mijlocie, este posibil s existe doi angajai cu acelai nume sau prenume. Nici mcar combinaia lor nu garanteaz unicitatea att timp ct pot exista dou persoane cu acelai nume i prenume. Din cele dou atribute, am ales marca drept cheie primar, iar CNP va fi cheie alternativ. Dup cum am spus i n paragraful anterior, unele tabele prezint o cheie primar compus. Tabela Pontaj are cheia format din Luna, Anul i Marca. Poate o discuie suplimentar ar fi binevenit. n primul rnd, se poate observa c nici un atribut al tabelei nu poate fi identificator, de unul singur. Atributele OreZi, OreSuplimentare i OreNoapte nu intr n discuie, deoarece este foarte probabil ca doi sau mai muli angajai s aib acelai numr de ore lucrate ntr-o lun; Luna i/sau Anul nici vorb, de vreme ce n orice firm exist doi sau mai muli angajai, nsemnnd c tabela va avea mai multe linii cu aceleai valori pentru cele dou atribute. Atributul Marca este singurul care se apropie de cerinele unui identificator, ns nici el nu rspunde ntrutotul acestor cerine, deoarece pentru fiecare lun se va aduga o linie pentru angajatul respectiv n tabela Pontaj. Dup cum se poate observa n figura 1.2, angajaii cu mrcile 1001 i 1002 se regsesc pe cte dou linii, una pentru luna septembrie i una pentru octombrie, anul 2007. Aadar, singura combinaie posibil pentru cheia primar este cea format din cele trei atribute. O alternativ la aceast soluie ar fi introducerea unui atribut artificial, s-i spunem IdPontaj, care s aib valori unice pentru fiecare linie din tabel.

1.3.4. Restricia referenial

n paragraful 1.2 am vzut c legturile ntre dou tabele se stabilete prin intermediul unui atribut sau grup de atribute comun i al noiunii de cheie strin. Tabelele DEPARTAMENT i ANGAJAT au n comun atributul CodDepart. Cheile strine sau coloanele de referin sunt deci atribute sau combinaii de atribute care pun n legtur linii (tupluri) din tabele diferite. Tabela n care atributul de legtur este cheie primar se numete tabel-printe (n cazul nostru, DEPARTAMENT), iar cealalt tabel-copil (ANGAJAT). Mecanismul cheii strine impune declararea restriciei de integritate referenial. Aceast restricie presupune c, pentru o cheie strin se admite orice valoare nenul care se regsete ntre valorile cheii primare din tabela-printe. n tabela ANGAJAT toate valorile coloanei CodDepart, care este cheie strin, au coresponden n valorile aceleiai coloane din tabela DEPARTAMENT, unde ea este definit cheie primar. Instituirea restriciei refereniale ntre tabela DEPARTAMENT (printe) i ANGAJAT (copil) este foarte important, deoarece permite cunoaterea, pentru fiecare angajat, a departamentului n care 9

lucreaz. Dac n ANGAJAT ar exista vreo linie n care valoarea atributului CodDepart ar fi, spre exemplu 9, este clar c acea linie ar fi orfan (nu ar avea linie corespondent n tabela printe DEPARTAMENT). Declararea restriciei refereniale presupune definirea aspectelor de comportament al datelor n cazul celor trei operaiuni de actualizare: adugarea, modificarea i tergerea de linii. n cazul operaiunii de adugare, nu este permis introducerea unei noi linii n tabela-copil care s nu aib corespondent n tabela-printe. De exemplu, nu este corect adugarea unui angajat n tabela ANGAJAT cu valoarea 9 pentru atributul CodDepart, att timp ct aceast valoare nu se regsete ntre valorile atributului CodDepart din tabela DEPARTAMENT. Ori este o greeal de introducere, ori trebuie adugat mai nti departamentul cu codul 9 n tabela DEPARTAMENT. Celelalte dou operaiuni privesc comportamentul datelor din tabela-printe. Astfel, nu se admite modificarea valorii cheii primare pentru o linie din tabela-printe dac aceasta are asociat cel puin o linie n tabela-copil. De exemplu, nu se admite modificarea valorii cheii primare pentru linia corespunztoare departamentului "Resurse umane" (valoarea 1 pentru coloana CodDepart) n tabela DEPARTAMENT deoarece n tabela ANGAJAT, nu una ci chiar dou linii fac referire la aceast valoare. n mod asemntor, nu este permis tergerea unei linii din tabela-printe dac exist cel puin o linie n tabela-copil care face referire la ea. Cu att mai mult, linia corespunztoare departamentului "Resurse umane" din tabela DEPARTAMENT nu poate fi eliminat. Dac nu ar fi existat cele dou lini n tabela ANGAJAT, atunci operaia de tergere ar fi putut avea loc. Majoritatea SGBD-urilor prezint mecanisme de declarare i gestionare automat a restriciilor refereniale, prin actualizri n cascad i interzicerea valorilor care ar nclca aceste restricii. Vom relua acest subiect n capitolul urmtor, dedicat ACCESS-ului.

1.3.5. Restricii-utilizator
Restriciile utilizator mai sunt denumite i restricii de comportament sau restricii ale organizaiei (termenul n limba englez este business rules). De obicei, aceste restricii iau forma unor reguli de validare la nivel de atribut, la nivel de linie/tabel sau a unor reguli implementate prin declanatoare (triggere). Reguli la nivel de atribut O restricie la nivel de atribut poate preveni introducerea n baza de date a unor valori din alte intervale dect cele stabilite, n alte formate dect cele acceptate etc. Forma clasic a unei restricii la nivel de atribut este o expresie n care apar constante, funcii-sistem i, nu n ultimul rnd, atributul respectiv. La orice editare a atributului cu pricina (declanat n cazul inserrii unei linii n tabela din care face parte, sau la modificarea sa) expresia este evaluat i dac rezultatul evalurii este TRUE (adevrat), atunci inserarea/modificarea este permis, iar dac rezultatul este FALSE, atunci inserarea/modificarea este blocat i, eventual, este afiat un mesaj de eroare. Iat cteva exemple de astfel de reguli: numrul orelor suplimentare s fie mai mic de 30 (a se evita surmenarea angajailor!); numele i prenumele angajailor s nceap cu majuscul; marca angajailor s aib valori cuprinse ntre 1001 i 9999; salariul tarifar s fie mai mare dect salariul minim pe economie.

Reguli la nivel de nregistrare

10

Expresia care definete o restricie la nivel de nregistrare poate conine dou sau mai multe atribute i este evaluat la inserarea sau modificarea oricrei linii din tabel. Tabela PONTAJ conine, printre altele trei atribute numerice privind numrul orelor lucrate de un angajat ntr-o anumit lun, respectiv OreZi, OreSuplimentare i OreNoapte. Reinerea a trei cmpuri poate fi justificat de modul diferit de calcul al veniturilor lunare. Pentru a se evita greelile grave de editare a datelor din pontaje sau a asigura respectarea politicii firmei se poate impune regula ca numrul maxim de ore lucrate ntro lun de un angajat s fie mai mic de 250, adic OreZi + OreSuplimentare + OreNoapte < 250. Este lesne de observat c aceast regul implic trei atribute, deci trebuie instituit la nivel de nregistrare (linie). Alte tipuri de restricii utilizator Exist i alte tipuri de restricii a cror validare presupune citirea unor date aflate n tabele diferite. Acestea reclam ntrebuinarea unor proceduri speciale, numite declanatoare (triggere).

CAPITOLUL 2

SGBD-URI. MICROSOFT ACCESS

2.1 PREZENTARE GENERAL A MICROSOFT ACCESS

ACCESS este un sistem de gestiune a bazelor de date integrat n pachetul MS Office destinat pentru uzul personal, pentru munca n grup sau pentru mici afaceri. Fiind, probabil, cel mai utilizat instrument software dedicat bazelor de date, ACCESS ofer urmtoarele faciliti majore: dispune de o interfa uor de folosit pentru introducerea datelor; gsete rapid datele legate ntre ele; asigur afiarea pe ecran sau tiprirea la imprimant a datelor ntr-un format uor de neles; permite afiarea datelor sub form de grafice sau ca pagini Web; are incluse mecanisme pentru exportul datelor n Excel i /sau Word; asigur protejarea datelor de erori; automatizeaz operaiile comune pentru a reduce timpul de dactilografiere. ACCESS este conceput pentru scenarii multiutilizator, ceea ce nseamn c mai muli utilizatori pot accesa aceleai tipuri de date n acelai timp. Teoretic o baz de date ACCESS 2003 se poate adapta pentru 255 de utilizatori simultan. Deschiderea sesiunii de lucru ACCESS Ca i n cazul celorlalte componente MS Office, ACCESS se poate lansa n mai multe moduri:

meniul Start, selectnd din meniul Programs opiunea Microsoft Office ACCESS 2003,
Prelucrare dup Grama, A., Fotache, M., ugui, A., Dumitriu, F., Instrumente software pentru afaceri, Editura Universitii Alexandru Ioan Cuza, Iai, 2006

11

meniul rapid (apsarea butonului dreapta al maouse-ului pe Desktop, selectnd comanda New i apoi opiunea Microsoft Office ACCESS Application;

shortcut-ul de pe Desktop, accesnd pictograma de pe desktop, dac a fost creat o scurttur ACCESS 2003. Interfaa ACCESS Dialogul utilizator-sistem se realizeaz, prin intermediul interfeei ACCESS constituit, n principal, din bara de instrumente Database, bara meniu i panoul de activiti. Bara de instrumente Database, pe lng butoanele prezente n barele Standard ale altor produse MS Office, are n componen o serie de butoane specifice. Cel mai important este Relationships reprezint grafic relaiile existente i permite modificarea acestora sau crearea altora noi. La deschiderea sesiunii este activat, n dreapta ecranului, panoul de activiti Task Pane care ofer o serie de legturi, ce difer n funcie de operaia n curs de derulare (figura 2.1):

Connect to Microsoft Office online conectarea online la pagina Microsoft Office ; Search for... - cutarea n funcie de anumite criterii; Open deschiderea unuia dintre fiierele aflate n lista ultimelor fiiere cu care s-a lucrat, sau a unui alt fiier, cutat cu ajutorul butonului More...care deschide o fereastr Open; Create a new file... crearea unui nou fiier.

Afiarea sau ascunderea panoului de activiti se realizeaz din meniul View, prin comanda Task Pane.

Figura 2.1 Task Pane

Figura 2.2 Task Pane New File

Dac se opteaz pentru crearea unui nou fiier, Task Pane ofer mai multe variante (figura 2.2):

Blank database - crearea unei baze de date goale care nu conine nici o dat sau orice alte obiecte (opiunea cea mai des utilizat); From Existing File crearea unei baze de date noi folosind structura unei baze de date existente; On my computer construirea unei baze de date dintr-un fiier ablon;

Proiectele ACCESS permit dezvoltarea unor noi aplicaii client-server n urmtoarele situaii mai complexe: 12

datele sunt foarte importante; nu se accept nici un fel de pierderi da date i nici o indisponibilitate temporar a datelor; datele vor fi folosite simultan de mai multe persoane. ACCESS admite cel mult 255 de utilizatori, dar performanele pot fi mult diminuate dac utilizatorii sunt deosebit de activi; baza de date va avea dimensiuni foarte mari.

Configurarea sesiunii de lucru n ACCESS Ca i alte produse software, ACCESS permite stabilirea unor parametrii de lucru pentru sesiunea curent i, eventual, a sesiunilor urmtoare. n acest scop se activeaz din meniul Tools, comanda Options. Fereastra acestei comenzi este structurat pe numeroase cadre de pagin: View, General, Edit/Find, International etc. Vizm n continuare doar cadrul de pagin General care, printre altele, permite stabilirea unui director implicit n care vor fi salvate fiierele. Pentru exemplificare, din raiuni lesne de neles, n zona Default database folder:, s-a declarat ca director curent D:\feaa\isa_id\capitolul 4 (figura 2.3).

Declararea directorului curent

Figura 2.3 Declararea unui director implicit nchiderea sesiunii ACCESS O sesiune de lucru ACCESS se poate nchide folosind:

Butonul Close (X) al ferestrei ACCESS; Comanda Exit, din meniul File.

n ambele variante este asigurat i nchiderea i salvarea bazei de date deschis n acel moment. Tipuri de obiecte n proiectele (aplicaiile) ACCESS Un proiect ACCESS se organizeaz n jurul unei baze de date, i poate conine urmtoarele tipuri de obiecte:

Tabele (Tables) reprezint locul n care sunt stocate datele brute ale unei baze de date; Interogri (Queries) tabele care conin rspunsuri la anumite ntrebri despre date; Formulare (Forms) componente care ofer o interfa de introducere i afiare a datelor; Rapoarte (Reports) faciliti care ofer diferite modaliti de afiare /tiprire a datelor coninute n tabele;

13

Pagini (Pages) sunt asemntoare formularelor, n plus ele pot fi afiate ntr-un browser Web. Astfel, ACCESS este prima baz de date care permite transferul datelor pe un site Web; Module (Modules) sunt obiecte care conin coduri de programare, scrise n VBA. Modulele ofer utilizatorilor avansai posibilitatea de a personaliza bazele de date i coninutul acestora.

PROBLEM
Pasul 1 Definirea problemei
Se cere crearea unei aplicaii privind gestiunea personalului, care s acopere urmtoarele cerine funcionale: Evidena angajailor pe locuri de munc, funcii i nivelul studiilor; Evidena posturilor de munc; Evidena orelor lucrate pe tipuri de ore; Evidena deciziilor de transfer, promovare etc.

Aplicaia va fi realizat n mediul Microsoft Access i va conine baza de date, formulare, rapoarte i rspunsuri la ntrebri (interogri).

2.2 CREAREA I ACTUALIZAREA BAZELOR DE DATE ACCESS

Orice proiect de lucru cu o baz de date demareaz cu crearea tabelelor din baz i definirea restriciilor. Crearea tabelelor presupune declararea numelui, tipului, lungimii i altor proprieti pentru fiecare atribut.

2.2.1 Tipuri de date

n tabelele ACCESS pot fi organizate o palet diversificat de tipuri de date. Pentru fiecare cmp dintr-o tabel trebuie stabilit un tip de dat prin care se controleaz natura i cantitatea de date ce poate fi introdus. Sunt disponibile urmtoarele tipuri de date:

Text este folosit pentru stocarea irurilor de cel mult 255 de caractere alfanumerice (litere, numere, simboluri etc.); Memo este indicat pentru a stoca iruri care depesc 255 de caractere, nu sunt structurate i /sau au un anumit caracter de confidenialitate; coninutul cmpurilor memo nu este vizualizat atunci cnd se afieaz coninutul tabelelor; Number accept doar date numerice (ntregi sau cu zecimale), cu un numr suficient de poziii, pentru aproape toate datele economice. La rndul lor datele numerice pot fi reprezentate n diferite formate: Byte, Long Integer, Integer, Single, Double, Decimal; Date /Time General Date este tipul de date folosit pentru a stoca data calendaristic i/sau timpul i are mai multe formate: Long Date, Medium Date, Short Date, Long Time, Medium Time, Short Time;

14

Currency este asemntor datelor numerice, cu deosebirea c accept doar patru digii pentru partea zecimal. Este conceput pentru a evita erorile de rotunjire, astfel nct calculele cu bani s fie precise. i datele de acest tip pot avea mai multe formate: General number, Format Euro, Currency, Fexed, Standard, Percent, Scientific; AutoNumber este o variant special a datelor Number. Este recomandat n procedura de stabilire a cheii primare, atunci cnd din structura tabelei este dificil de ales un cmp reprezentativ. Formatele pentru AutoNumber sunt: Long Integer, Replication ID; Yes /No - este conceput pentru a pstra nregistrri simple On /off. Formatele pot fi: True /False, On/Off; Ole Object permite stocarea informaiilor ntr-un format accesibil altor programe (documente Word, foi de calcul Excel, imagini, fiiere cu muzic etc.) Hyperlink este un tip de date text special conceput pentru a stoca hyperlink-uri ctre site-uri Web sau alte resurse Internet; Lookup Wizard cmp special de cutare.

Remarcm disponibilitatea datelor de tip Lookup Wizard care folosite pentru a declara cmpuri de cutare. Majoritatea bazelor de date organizeaz dou tipuri de tabele: cele care includ date primare i cele care conin liste de valori folosite n tabele. Aceste tabele auxiliare se numesc tabele de cutare (lookup tables) i prezint dou avantaje: pun la dispoziia utilizatorului opiuni consecvente i simplu de utilizat i permit validarea datelor, acceptnd numai datele din tabel. Dac lista intrrilor posibile pentru un cmp este redus i are o perioad mare de valabilitate se poate crea un tabel de cutare bazat pe o lista de valori introduse, nu pe tabel (de exemplu, pentru cmpul stare civil, se poate introduce o list de valori Cstorit i Necstorit). Dac se opteaz pentru utilizarea unui cmp cu valori posibile, este necesar crearea unui tabel de cutare nainte de a putea folosi tabelul pentru a crea un cmp de cutare ntr-un alt tabel. Fiecare tip de date poate fi personalizat prin intermediul proprietilor. Aceste proprieti se stabilesc prin fereastra proiectantului de tabele Design View. Observaie n expresii, datele de tip text sunt incluse ntre ghilimele (de exemplu, Managementul Resurselor Umane), iar datele calendaristice sunt ncadrate de semnul # (de exemplu, #12/10/2008#).

2.2.2 Crearea /construirea tabelelor

Tabelele, fiind obiecte componente ale bazelor de date, presupun, ca prim etap, obinerea bazei de date din care vor face parte. Dac se opteaz pentru Blank database trebuie precizate locaia, numele i tipul unui astfel de fiier. Implicit, ACCESS atribuie numele md<n> i extensia .mdb (figura 1.4). Este recomandat ca numele fiierului s sugereze coninutul informaional sau apartenena de o aplicaie sau un utilizator. Exemplificrile din acest capitol au ca suport baza de date personal.mdb. Observaie Locaia n care va fi naintea efecturii acestei operaiuni creai folderul SIMRU pe discul D:. salvat BD

Numele BD Extensia implicit a BD

15

Figura 2.4 Fereastra File New Database Pentru crearea unui tabel ACCESS ofer trei posibiliti (figura 2.5):

Opiuni pentru crearea tabelelor BD

Obiectele unei BD

Figura 2.5 Opiuni pentru creare tabelelor unei Baze de date

Create table in Design view - folosind modul de proiectare a tabelului; este cea mai puternic i mai flexibil modalitate fiind specificate detaliile fiecrui cmp; Create table using wizard - apelnd asistentul Table Wizard care precizeaz paii care trebuie urmai pentru construirea unor tabele obinuite; Create table by entering date introducnd datele n cmpurile create de ACCESS; aceast metod este apropiat de modul de lucru n Excel.

Crearea tabelelor prin introducerea datelor Cea mai confortabil pentru nceptori este crearea tabelelor prin introducerea datelor. Dac se alege aceasta opiune (Create table by entering date), n etapa imediat urmtoare se deschide o fereastr n care coloanele, reprezentnd cmpurile, au nume predefinite de tipul Field<n>. Pe rndurile tabelului se introduc nregistrrile /articolele (figura 2.6).

Figura 2.6 Fereastra Create table by entering date pentru tabela LocMunca 16

n continuare, se face salvarea tabelului i, implicit, precizarea numelui acestuia ntr-o fereastr Save As, prin utilizarea butonului creeaz tabela LocMunca (figura 2.7). . Pentru exemplificare, n baza de date Personal se

Figura 2.7 Ferastra Save As pentru tabela LocMunca La final, se vor redenumi cmpurile/coloanele pentru a sugera coninutul acestora. Se folosete comanda Rename Column apelat fie din meniul rapid (activat de pe antetul /header-ul cmpului /coloanei), fie din meniul Format (figura 2.8). Intrarea n modul de editare este posibil i prin dublu click de mouse de pe antetul cmpului al crui nume urmeaz a fi schimbat.

Figura 2.8 Comanda Rename Column Crearea tabelelor folosind Table Wizard Table Wizard este un instrument care permite crearea tabelelor prin parcurgerea unor pai prestabilii. Pentru exemplificare s-a dorit crearea tabelei Angajat. ntr-un prim pas sunt stabilite cmpurile care vor constitui structura noii tabele. ACCESS ofer variate abloane att pentru domeniul afacerilor (Business) ct i cu caracter personal, dup uzanele americane. Folosind butonul Rename Field se pot personaliza machetele pentru articole, n sensul c structurile pot fi adaptate la specificul aplicaiei ce se proiecteaz (figura 2.9).

17

Tipuri abloane

de

Structuri articole

de

Redenumire a unuic mp

Figura 2.9 Stabilirea cmpurilor ntr-o tabel creat cu Table wizard Dup stabilirea cmpurilor, n pasul urmtor se precizeaz numele sub care va fi salvat tabela i modalitatea n care va fi stabilit cheia primar (vezi capitolul anterior), de ctre utilizator sau, implicit, de ctre ACCESS (figurile 2.10 i 2.11). Dup stabilirea cheii primare se va alege modul de atribuire a valorilor pentru aceasta (figura 2.11). n aceast prezentare s-a optat pentru atribuirea valorilor pentru cmpul Marca de ctre utilizator, n momentul adugrii unui angajat nou, ns se putea opta i pentru varianta atribuirii valorilor automat, n mod consecutiv, de ctre ACCESS.
Numele tabelei

Stabilirea cheii primarede ctre utilizator

Figura 2.10 Stabilirea numelui i a opiunii pentru cheii primare

18

Cheia primar stabilit de utilizator

Figura 2.11 Stabilirea cheii primare Dup precizarea cheii primare se pot stabili eventualele legturi cu alte tabele (acest pas nu este prezentat!) i apoi se alege modul n care se va continua dup crearea tabelei, fiind disponibile opiunile (figura 2.12):

modificarea n Table Design; introducerea datelor direct n tabel; aceasta este varianta pentru care am optat n exemplificarea de mai jos; introducerea datelor n tabel folosind un formular creat de un asistent /wizard ACCESS.
4

Figura 2.12 Opiunea de introducere a datelor direct n tabel Dup parcurgerea acestor pai are loc introducerea datelor n tabel (figura 2.13). 5

Figura 2.13 Introducerea datelor n tabel Crearea tabelelor folosind Design View

19

Cea mai complex modalitatea de obinere a tabelelor unei baze de date o ofer Design View n a crui fereastr pot fi stabilite: numele cmpurilor, tipul datelor i proprietile acestora, cheia primar etc. Exemplificm obinerea tabelei Decizie din baza de date Personal.mdb.

Stabilire p a cheii rimare

Figura 2.14 Stabilirea cheii primare Primul cmp, IdDecizie, este de tip numeric-auto (valorile sunt atribuite automat de ctre ACCES) i este reprezentat n formatul Long Integer. Acest format a fost ales ca proprietate din lista General. n plus, acest cmp a fost desemnat cheie primar. Stabilirea acestei chei se poate realiza fie activnd pictograma Primary Key din bara cu instrumente Database, fie selectnd comanda Primary Key din meniul rapid activat de pe numele cmpului (figura 2.14). Din lista General se stabilesc proprietile i pentru celelalte cmpuri (figura 2.15).

Stabilirea pentru data calendaristic

formatului

Figura 2.15 Stabilirea formatului pentru data calendaristic

20

Dup crearea celor trei tabele fereastra Database, pentru baza de date Personal este prezentat n figura 2.16. Pictogramele din bara cu instrumentele Database permit realizarea unor operaii specifice.

Figura 2.16 Fereastra Database pentru Personal.mbd Este posibil modificarea structurii unei tabele n sensul c pot fi adugate i /sau terse cmpuri sau pot fi modificate atributele acestora. Adugarea unui cmp se realizeaz fie din meniul Insert, fie din cel rapid, ambele selectate cnd prompterul este poziionat pe cmpul la stnga cruia se va insera unul nou (figura 2.17).

Figura 2.17. Comenzi pentru adugarea sau tergerea unui cmp tergerea unuia sau mai multor cmpuri presupune selectarea i apoi activarea comenzii Delete fie din meniul Edit, fie din cel rapid. Alte operaiuni de modifiare a structuri tabelelor pot fi realizate n fereastra Design View. n acest sens, dup deschiderea bazei de date, sunt suficiente trei click-uri mari i late pentru a (re)intra n proiectantul tabelei Angajat vezi figura 2.18. 21

3 1 2

Figura 2.18. Trei click uri pentru modificarea structurii tabelelor

PROBLEM
Pasul 2 Construirea tabelelor bazei de date
Se cere crearea tabelelor din schema bazei de date, conform datelor din tabelul de mai jos (cu excepia tabelelor create prin parcurgerea paragrafului curent, dac ele au fost create deja). Din coloana a treia se va lua n considerare numai cerinele privind cheia primar.

Tabelul 2.1 Schema bazei de date pentru aplicaia privind gestiunea personalului
Nume atribut Tip dat
Number, Long Integer Text, 50 Text, 50 Text, 13 Text, 1 Date/Time, Short Date Text, 50 Text, 10 Text, 50 Number, Double Number, Long Integer Number, Long Integer Number, Long Integer Autonumber Number, Integer Date/Time, Short Date Number, Long Integer Number, Long Integer Number, Long Integer Date/Time, Short Date Autonumber Text, 50

Alte observaii/Restricii
Cheie primar Nenul, prima liter s fie majuscul Nenul, prima liter s fie majuscul Cheie alternativ Se admit doar valorile M sau F S fie mai mic dect data curent

Tabela ANGAJAT
Marca Nume Prenume CNP Sex DataNastere Adresa TelefonAcasa Email SalarTarifar CodPostA CodLocMuncaA IdStudiiA

Cheie strin pentru tabela PostMunca Cheie strin pentru tabela LocMunca Cheie strin pentru tabela NivelStudii

Tabela DECIZIE
IdDecizie NrDecizie DataDecizie MarcaD CodPostNou CodPostVechi DataIntrVigoare Cheie primar Nenul Nenul, S fie mai mic sau egal cu data curent Cheie strin pentru tabela Angajat Cheie strin pentru tabela PostMunca Cheie strin pentru tabela PostMunca Nenul, S fie mai mare sau egal cu data curent Cheie primar Nenul

Tabela Functie
IdFunctie DenumireFunctie

22

IdStudiiCerut

Number, Long Integer Number, Long Integer Text, 50 Number, Long Integer Autonumber Text, 50 Autonumber Number, Integer Number, Integer Number, Long Integer Number, Long Integer Number, Long Integer Number, Long Integer Number, Long Integer Number, Long Integer Autonumber Text, 50 Number, Long Integer Number, Integer Number, Long Integer Number, Long Integer

Cheie strin pentru tabela NivelStudii Cheie primar Nenul, Cheie alternativ

Tabela LocMunca
CodLocMunca DenumireLocMunca NrPosturi

Tabela NivelStudii
IdStudii DenumireStudii Cheie primar Nenul, Cheie alternativ Cheie primar Nenul, Valori cuprinse ntre 1 i 12 Nenul, S fie mai mic sau egal cu anul curent Cheie strin pentru tabela Angajat Valori mai mici de 220 Valori mai mici de 30 Valori mai mici de 100 Valori mai mici de 16 Valori mai mici de 176 Cheie primar Nenul, cheie alternativ Cheie strin pentru tabela NivelStudii Cheie strin pentru tabela LocMunca Cheie strin pentru tabela Functie

Tabela Pontaj
IdPontaj Luna Anul MarcaP OreZi OreSuplimentare OreNoapte AbsenteMotiv AbsenteNemotiv

Tabela PostMunca
IdPost DenumirePost IdStudiiP Vechime CodLocMuncaP CodFunctieP

2.2.3 Declararea restriciilor

Un paragraf din capitolul 1 a fost consacrat problematicii restriciilor ntr-o baz de date relaional, restricii care cresc gradul de ncredere n baza de date prin prevenirea a o serie de erori ce pot interveni la inserarea, modificarea sau tergerea de date ntr-o tabel. Pentru reamintire, ntr-o tabel pot fi definite urmtoarele categorii de restricii: restricia de domeniu, de atomicitate, de nenulitate, de unicitate, referenial i restricii-utilizator, care la rndul lor pot fi la nivel de atribut (coloan) sau nregistrare (linie). n continuare vom prezenta modul de declarare a acestor restricii n ACCESS. IMPORTANT! Este recomandabil ca declararea resticiilor s fie fcut odat cu crearea tabelelor sau imediat dup, n orice caz, naintea de introducerea vreunei date n baz. Se asigur astfel preluarea corect a tuturor informaiilor n tabele. Ca i crearea tabelelor, declararea i modificarea ulterioar a restriciilor decurge ct se poate de natural n ACCESS. Dup deschiderea bazei de date, sunt suficiente cele trei click-uri din figura 2.18 pentru a (re)intra n proiectantul tabelei Angajat. Restricia de nenulitate Acest tip de restricie stabilete dac se admit valori nule pentru un cmp, altfel spus, dac este obligatorie introducerea de ctre utilizator a unei valori pentru acel cmp la adugarea unei nregistrri. n figura 2.19 este ilustrat modul n care, setnd opiunea Required a proiectantului de tabele pentru oricare atribut pe valoarea Yes, acelui atribut i se vor interzice valorile nule. n exemplul nostru, 23

atributului CNP din tabela Angajat i se interzic valorile nule, prin setarea opiunii Required pe valoarea Yes, n timp ce atributul Adresa din aceeai tabel poate avea valori NULL, Required fiind setat pe valoarea No. Nu uitai c pentru atributele importante, ce in de identificarea sau caracterizarea unei entiti, proces, fenomen, precum i cele implicitate n calculul unor informaii importante, nu trebuie acceptate valorile nule. Restricia de unicitate Dup cum deja tim din capitolul anterior, ntr-o tabel nu pot exista dou linii identice (dou linii care prezint aceleai valori pentru toate atributele). Cu alte cuvinte, fiecare tabel trebuie s aib o cheie primar. n ACCESS, cheia primar poate fi: natural - cnd valorile atributelor care o compune se introduc de utilizator - i artificial - cnd se folosete un cmp de tip AutoNumber, n acest din urm caz ACCESS introducnd automat o valoare consecutiv la inserarea unei nregistrri (1 pentru prima nregistrare, 2 pentru a doua nregistrare s.a.m.d.). De exemplu, tabela Angajat are o cheie natural Marca, iar tabela Pontaj prezint o cheie artificial IdPontaj. Declararea cheilor primare i alternative n ACCESS se realizeaz prin crearea indecilor, acesta fiind motivul pentru care la aceste tipuri de atribute proprietatea Indexed este setat pe Yes (No Duplicates). Dac o cheie primar este compus, pentru fiecare atribut component se alege simbolul cheii primare din bara de intrumente. Un atribut de tip cheie primar are n dreptul su o cheie (de yal), iar modalitatea de declarare a sa a fost prezentat n figura 4.14. Cheile alternative sunt declarate prin setarea opiunii Indexed pe valoarea Yes (NoDuplicates). n figura 4.19, atributul CNP a fost declarat drept cheie alternativ pentru tabela Angajat, n timp ce atributul Adresa are setat opiunea Indexed pe valoarea No, deci nu este nici cheie primar, nici alternativ.
Restricia de nenulitate

Restricia de unicitate

24

Figura 2.19.Declararea restriciilor de nenulitate i de unicitate Restricia de integritate referenial tim c o baz de date relaional este alctuit din tabele aflate n legtur. Stabilirea legturii se bazeaz pe mecanismul cheii strine i, implicit, a restriciei refereniale, discutate de noi n capitolul anterior. Atributele Marca i MarcaD joac rolurile de agent de legtur ntre tabelele Angajat i Decizie (cele dou atribute pot avea acelai nume). Pentru tabela Angajat, atributul Marca este cheie primar, n timp ce n tabela Decizie, MarcaD reprezint coloana de referin sau cheia strin, deoarece numai pe baza valorilor sale se poate face legtura cu tabela Angajat. Tabela n care atributul de legtur este primar se numete tabel-printe (n cazul nostru, Angajat), iar cealalt tabel-copil (Decizie). Pentru declararea restriciilor refereniale, mai nti, trebuie stabilite legturile ntre tabele, scop n care se apas butonul Relationship din bara de instrumente. Efectul acestei comenzi va consta n deschiderea ferestrei Relationships (vezi figura 2.20). Dup adugarea tabelelor Angajat i Decizie din fereastra Show Table se nchide aceast fereastr i se stabilete legtura ntre cele dou tabele. n acest sens, se va trage cu mouseul atributul Marca din tabela Angajat (adic, cheia primar din tabela printe) peste atributul MarcaD din tabela Decizie (adic, cheia strin din tabela copil). Urmarea acestei operaiuni va fi afiarea ferestrei Edit Relationships, prezentat n figura 2.21, n care pot fi definite restriciile refereniale.

Opiuni pentru integrita tea referenial

Figura 2.20 Stabilirea legturilor ntre tabele i definirea restriciilor refereniale Practic, restricia de integritate referenial se instituie abia la bifarea opiunii Enforce Referential Integrity, ACCESS-ul restricionnd adugarea, modificarea i /sau tergerea n tabelele printe i copil astfel: nu se permite modificarea valorii cheii primare din tabela printe dac exist n tabela copil mcar o nregistrare cu care este n legtur;

nu poate fi introdus nici o valoare a unei chei strine n tabela copil dac respectiva valoare nu exist deja ca i cheie primar n tabela printe. Dac se alege opiunea Cascade Update Related Fields orice modificarea a unei chei primare n tabela primare va atrage modificarea n cascad a tuturor cheilor strine n nregistrrile copil, iar bifnd opiunea Cascade Delete Related Records la tergerea unei nregistrri din tabela printe se vor elimina automat toate nregistrrile copil. Dup finalizarea operaiunii, prin apsarea butonului Create, n fereastra Relationships va fi afiat i legtura dintre cele dou tabele (vezi figura 2.21). Legtura evideniaz o relaie de tipul unu-la-multe ntre tabele. 25

Figura 2.21 Rezultatul stabilirii legturilor ntre tabele i a restriciilor refereniale Din fereastra Database pot fi realizate diverse operaii cu tabelele i nregistrrile ncrcate n acestea. Pentru a vizualiza coninutul unei tabele este suficient un dublu click de mouse de pe numele tabelei. La afiare, unele tabele au n stnga o coloan n care apare semnul plus (+) sau spaiu. Semnul plus n dreptul unei nregistrri semnific faptul c aceasta este legat prin chei strine de nregistrri aflate n alte tabele. Click pe semnul plus determin schimbarea n semnul minus (-) i afiarea nregistrrilor nrudite (copil) ntr-o subfoaie de date (figura 2.22).
Semnul - indic faptul c sunt afiate nregistrrile nrudite

Semnul + indic faptul c nregistrarea are cel puin o nregistrare nrudit ntr-o alt tabel

Figura 2.22 Afiarea nregistrrilor nrudite din tabela copil Pentru a vedea toate nregistrrile subordonate articolelor dintr-o tabel printe se poate lansa comanda Subdatasheet din meniul Format. Restricii utilizator n paragraful Restricii utilizator din capitolul anterior se spunea c , aceste restricii iau forma unor reguli de validare la nivel de atribut sau la nivel de linie/tabel. O restricie la nivel de atribut poate preveni introducerea n baza de date a unor valori din alte intervale dect cele stabilite, n alte formate dect cele acceptate etc. n partea stng a figurii 2.23 este ilustrat o regul de validare conform creia n tabela Angajat valorile atributului Marca trebuie s fie mai mari dect 1000. Rubrica Validation Rule este cea n care apare expresia-restricie [Marca]>1000 - (observai c numele atributului este scris ntre paranteze unghiulare), iar n rubrica Validation Text se indic mesajul care va aprea pe ecran atunci cnd se ncalc restricia - Cea mai mic valoare acceptat pentru MARCA este 1001 !.

26

Figura 2.23. Dou restricii la nivel de atribut n dreapta figurii apare o regul ceva mai impresionant, prin care prima liter din valorile atributului Nume este obligatoriu majuscul. Expresia este de-a dreptul impresionant StrComp(Left(UCase([Nume]);1);Left([Nume];1);0)=0. Exotismul expresiei ine nu att de folosirea funciei Ucase, care convertete literele unui ir de caractere (prima liter a atributului Nume, n cazul nostru) n majuscule, ct de funcia StrComp, prin care se compar dou iruri de caractere, dintre care unul (cel din dreapta) este prima liter din valoarea atributului, iar cellalt aceeai valoare, dar scris cu majuscule. Dac cele dou iruri difer ctui de puin, rezultatul evalurii expresiei este False (valoarea 1), iar modificarea atributului (sau inserarea liniei) este respins. Practic, regula accept numai valori n care prima liter este exclusiv majuscul (evaluarea expresiei este True valoarea 0). Funcia LEFT extrage primele n caractere de la stnga valorii argumentului. Expresia care definete o restricie la nivel de nregistrare poate conine dou sau mai multe atribute i este evaluat la inserarea sau modificarea oricrei linii din tabel. O astfel de regul se poate introduce n proiectantul de tabel apelnd butonul Properties din bara de instrumente. O regul de

validare la nivel de nregistrare pentru tabela Pontaj este ilustrat n figura 2.24. S-a stabilit ca numrul total al orelor lucrate (OreZi + OreSuplimentare + OreNoapte) s nu fie mai mare de 230.

27

Figura 2.24. O restricie la nivel de nregistrare

PROBLEM
Pasul 3 Declararea restriciilor de integritate
1. S se declare restriciile de integritate la nivel de atribut specificate n tabelul 2.1. 2. S se declare urmtoarele restricii la nivel de nregistrare: OreZi + OreSuplimentare + OreNoapte mai mic dect 230 (Tabela Pontaj); AbsenteMotiv + AbsenteNemotiv mai mic dect 176 (Tabela Pontaj); DataIntrVigoare mai mare dect DataDecizie (Tabela Decizie).

3. S se stabileasc legturile ntre tabelele bazei de date, conform specificaiilor pentru cheile strine din coloana a treia a tabelului 2.1, i s se stabileasc restriciile de integritate referenial.

2.2.4. Inserri, modificri i tergeri de nregistrri

ntr-o BD pot fi efectuate trei operaiuni de actualizare: adugri (inserri), modificri i tergeri de linii (nregistrri). Toate cele trei operaiuni pot fi realizate foarte simplu, asemntor cu modul de lucru n Excel, numai c mai nti este necesar afiarea nregistrrilor din tabela dorit. Afiarea nregistrrilor unei tabele existente n baza de date se face de manier similar modificrii structurii, numai c n loc de opiunea Design se alege Open (vezi figura 2.18). Pentru inserarea unei nregistrri din meniul Insert se alege chiar prima comand, New Record (vezi stnga jos a figurii), iar pentru tergere, n maniera din Excel se selecteaz linia sau liniile de ters (click pe antetul liniei), iar apoi din meniul Edit se alege Delete Record (figura 2.25). Modificarea valorilor se face direct, prin poziionarea n linia i coloana dorit i operarea modificrilor.

28

Figura 2.25 Adugarea i tergerea datelor dintr-o tabel Atunci cnd numrul de linii dintr-o tabel este imens, iar datele trebuie modificate dup criterii riguroase, este necesar recurgerea la interogri pe care le vom discuta n paragraful 2.4.

PROBLEM
Pasul 4 Popularea bazei de date
S se adauge nregistrri n tabelele bazei de date astfel: Angajat (minim 15), Decizie (minim 10), Funcie (minim 10), LocMunca (minim 5), NivelStudii (minim 5), Pontaj (minim 30) i PostMunca (minim 15).

2.3. FORMULARE (ECRANE) PENTRU EDITAREA DATELOR N ACCESS

Un formular reprezint un instrument pus la dispoziia utilizatorului n scopul uurrii operaiilor de accesare i actualizare a datelor stocate n tabelele unei bazei de date. Trebuie reinut faptul c un formular este legat la o structur de date de tip tabel sau cursor (query) obinut n urma unei interogri. Prin intermediul formularului se asigur o vedere organizat i formatat asupra unei pri sau asupra tuturor cmpurilor din una sau mai multe tabele. n cadrul unui formular deosebim cinci seciuni de lucru, i anume: 1. Antetul de formular (Form Header); 2. Antetul de pagin (Page Header); 3. Zona de detalii (Detail); 4. Subsolul de pagin (Page Footer); 5. Subsolul de formular (Form Footer). Din cele cinci seciuni este obligatorie doar zona de detalii, deoarece prin intermediul ei se atinge scopul pentru care a fost conceput un asemenea instrument. Antetele de formular i de pagin, precum i subsolurile aferente, pentru a fi aduse pe ecran trebuie s se apeleze la opiunea View din meniul principal. n ACCESS, formularele pot fi construite n trei moduri: Crearea rapid a unui formular prin utilizarea facilitii AutoForm (Columnar, Tabular, Datasheet, PivotTable sau PivotChart). De obicei se utilizeaz varianta organizrii 29

datelor sub forma unei coloane. Dac se alege Tabular, formularul va cuprinde un numr mai mare de nregistrri n zona de detaliu i va semna cu o tabel. Apelarea la asistent/vrjitor (Form Wizard). Utilizatorul va construi formularul, pas cu pas, sub ndrumarea asistentului, singura sarcin a acestuia fiind s rspund la ntrebri prin selecia unei variante din mai multe posibile; Utilizarea ferestrei de proiectare (Design View). n acest mod de lucru, fomularul este creat de ctre utilizatori avansai. n prima etap, pentru oricare variant am opta din cele trei, trebuie s selectm din proiectantul bazei de date, de sub Object opiunea Forms, dup care s activm butonul New, ca n figura 2.26.

2 1

Figura 2.26. Lansarea n execuie a generatorului de formulare Urmare a aciunii 2 din figura precedent se va activa fereastra New Form, n care va trebui s selectm varianta de lucru pentru organizarea cmpurilor (1) i tabela pentru care se va crea formularul (2) aa cum se prezint n figura 2.27.

Figura 2.27. Fereastr de selecie a modului de organizare a datelor i a tabelei Vom parcurge n cele ce urmeaz variantele de lucru AutoForm Columnar i cea cu asistentul/vrjitorul (Form Wizard). 1. Utilizarea facilitii AutoForm n generarea de formulare Ne propunem s generm un formular pentru tabela LocMunca. n acest sens, se vor urma paii prezentai n figurile 2.24 i 2.25, iar apoi se va selecta tabela LocMunca. Dup selecia tabelei se apas butonul Ok (nu se vede n figura 2.27), moment n care se va genera automat formularul corespunztor tabelei noastre (figura 2.28.). 30

2 3 1

Figura 2.28. Formularul generat cu opiunea AutoForm: Columnar pentru tabela LocMunca Din figura precedent observm: 1. Titlul ferestrei este LocMunca, ca i numele tabelei (ulterior l vom modifica); 2. Suntem poziionai pe prima nregistrare din tabela LocMunca; 3. Pe ultimul rnd dispunem de un set de butoane de navigare de la o nregistrare la alta (vezi sgeata 1); 4. cheia primar a tabelei este marcat prin sgeata n dreptul codului locului de munc (vezi sgeata 2); 5. Putem modifica foarte uor, chiar prea uor, valorile oricrui cmp cu respectarea restriciilor de integritate declarate deja; 6. Putem realiza operaii de sortare, filtrare, cutare, tergere ( ) i adugare ( ) din butoanele din linia de instrumente (vezi sgeata 3). Adugarea este posibil i din butoanele de navigare cu acelai buton . Dup crearea formularului de mai sus este necesar s-l salvm cu un nume, n cazul nostru i vom da numele frmLocMunca. Acest lucru se realizeaz prin activarea opiunii Save din meniul File sau direct click pe butonul . Rezultatul va fi apariia ferestrei de salvare a formularului cu un nume

recomandat de ACCESS, dar care va fi modificat n frmLocMunca. Nu ne rmne dect s dm click pe butonul Ok. 2. Utilizarea asistentului n generarea de formulare Continum crearea unui formular pentru tabela Angajat, dar vom apela la asistent/vrjitor n generarea de formulare. Lansarea asistentului/vrjitorului se realizeaz prin parcurgerea pailor parcuri anterior i prezentai n figurile 2.26 i 2.27, doar c de aceast dat vom selecta opiunea Form Wizard n loc de AutoForm: Columnar i vom alege tabela Angajat n loc de LocMunca. Dup apsarea butonului Ok vom intra n fereastra din figura 2.29, din care va trebui s selectm cmpurile care s fie trimise n formular. n cazul nostru vom trimite toate cmpurile, ceea ce nseamn c vom da click pe butonul >>. Dac se dorete trimiterea unui anumit cmp, se va da dublu click pe acel cmp.

31

Figura 2.29. Fereastra de selectare a cmpurilor din tabela Angajat (nainte i dup selectare) Dup activarea butonului Next vom intra n fereastra de organizare a datelor, din care vom selecta butonul radio Columnar i Next, ceea ce va face trecerea n fereastra de stabilire a stilului, din care vom selecta Standard i butonul Next (figura 2.30).

Figura 2.30 Selecia modului de organizare a datelor i a stilului Dup selectarea stilului se va solicita ataarea unui nume pentru formular. n cazul nostru i vom da numele frmAngajat i vom apsa butonul Finish, ce va avea ca efect afiarea formularului cu datele din prima nregistrare a tabelei Angajat (figura 2.31).

Figura 2.31 Salvarea i afiarea formularului pentru tabela Angajat

32

n cazul n care se dorete adugarea unei nregistrri se apas butonul din zona butoanelor de defilare sau din liniile de instrumente, ceea ce va determina golirea formularului, cu posibilitatea completrii datelor despre alt angajat. Modificarea datelor unui angajat cu ajutorul formularului frmAngajat se realizeaz n dou etape: a. cutarea nregistrrii de modificat, fie prin parcurgerea secvenial a nregistrrilor tabelei (se folosete butonul NEXT din linia de derulare a formularului), fie prin cutare

direct dup valorile unui cmp, de exemplu numele angajatului (se folosete butonul FIND din linia de instrumente);

b. efectuarea modificrii direct n formular. n mod similar modificrii se realizeaz i tergerea unei nregistrri cu ajutorul formularului, cu precizarea c dup cutarea nregistrrii de ters se d click pe butonul DELETE RECORD din linia de instrumente. Dup crearea celor dou formulare, fereastra FORMS, pentru baza de date Personal este prezentat n figura 2.32. Pictogramele din bara cu instrumente permit realizarea unor operaii specifice.

Figura 2.32 Fereastra Forms pentru Personal.mdb Din aceast fereastr orice formular poate fi utilizat (afiat) ulterior fie direct, prin dublu click pe numele acestuia, fie prin selectarea numelui formularului dorit (de exemplu, frmAngajat) i apsarea butonului Open.

PROBLEM
Pasul 5 Crearea formularelor pentru actualizarea bazei de date
S se creeze cte un formular pentru actualizarea tabelelor Pontaj, Decizie, Funcie i LocMunca.

2.4. OBINEREA DE INFORMAII (INTEROGAREA) BAZELOR DE DATE ACCESS

ACCESS-ul a fost, nc din tinereea sa, un reper n materie de faciliti de obinere a informaiilor dintr-o baz de date relaional, printr-un mecanism simplu de creare a interogrilor.

33

Vis-a-vis de terminologie, n englez, verbul care desemneaz explorarea bazei de date pentru a obine informaiile necesare este to query pe care-l traducem prin a interoga. ntr-un proiect ACCESS, la loc de cinste ntre obiecte, imediat dup tabele (Tables) apar interogrile (Queries). Selectarea acestora, click-ul de rigoare pe butonul New i apoi a opiunii Design View determin afiarea pe ecran a proiectantului de interogri, un cadru foarte versatil prin care putem formula o cerin informaional (figura 2.33).

1 2

Figura 2.33 Proiectantul de interogri Partea de sus a ecranului (n spatele ferestrei de alegere a tabelelor) servete la afiarea tabelelor implicate n interogare, precum i a legturilor (restriciilor refereniale) dintre ele. n cadrul propriu zis, fiecare coloan corespunde unei coloane din lista ce se dorete a fi obinut, informaiile specificate fiind: numele atributului (Field), tabela n care se afl acesta (Table), dac valorile atributului vor fi ordonate cresctor sau descresctor (Sort) n list, dac respectiva coloan va fi afiat n list sau servete doar la precizarea filtrului de selecie a nregistrrilor (Show) i condiiile pe care trebuie s le ndeplineasc nregistrrile (liniile) pentru a fi incluse n raport, altfel spus, condiia a filtrate a liniilor n rezultat (Criteria). Ar mai trebui spus c putem include n rezultat nu numai atribute din tabele, ci i expresii de atribute, dup cum vom vedea imediat.

2.4.1. Informaii obinute dintr-o singur tabel

Ne propunem s obinem din tabela Pontaj o list (situaie) a orelor lucrate din luna septembrie 2007, n care datele s fie ordonate cresctor dup valorile mrcii. 34

Pornind de la ceea ce dorim s obinem, s vedem cum se construiete macheta interogrii. Figura 2.34 ncearc s lmureasc lucrurile.

Coloana calculat

2 1 3

Expresiile filtrare

de

Figura 2.34 Macheta interogrii pentru obinerea listei orelor lucrate n partea de sus troneaz singura tabel necesar obinerii rezultatului Pontaj. Partea interesant este ns n partea de jos a figurii. Mai nti, sunt adugate n machet cmpurile care vor fi afiate n list, respectiv MarcaP, OreZi, OreSuplimentare, OreNoapte, TotalOre, Luna i Anul. Dou aspecte trebuie lmurite: primul dac primele patru cmpuri sunt selectate din tabel (se apas sgetua din prima linie a coloanei curente sau se trage cu mouseul atributul dorit ntr-o coloan a machetei), urmtorul cmp este calculat dup o expresie pe care o vom discuta cteva rnduri mai jos; ultimele dou coloane au fost adugate n macheta interogrii doar pentru specificarea criteriilor de filtrare, fr ca ele s fie afiate n list, motiv pentru care csuele din linia Show pentru cele dou coloane nu sunt activate. n linia Sort a coloanei MarcaP a fost aleas opiunea Ascending astfel nct datele din list s fie ordonate cresctor dup marca angajailor. n linia Criteria a coloanelor Luna i Anul este formulat criteriu de filtrare a liniilor din rezultat: = 9, respectiv = 2007. Este modalitate de a indica faptul c valorile de pe coloana Luna trebuie s fie egal cu 9 (adic luna spetembrie) i, cumulativ, coloana Anul s fie 2007. Dar cel mai captivant este ceea ce se petrece pe a cincea coloan a machetei. n prima faz pe linia Field se introduce expresia OreZI + OreSuplimentare + OreNoapte. Apoi se face un click discret pe butonul Properties (pasul 2) i se afieaz pe ecran fereastra Field Properties. Aici vom indica formatul de afiare fix (Format...Fixed) i numele coloanei calculate (Caption...TotalOre). Se salveaz macheta (celebra pictogram a dischetei din figura de mai sus) sub numele SituatieOreLucrate, iar rezultatul interogrii, prezentat n figura 2.35, se obine printr-un click pe butonul View din stnga-sus-ul ferestrei interogrii.

35

Figura 2.35 Rezultatul interogrii din figura 4.34

2.4.2. Informaii obinute din dou sau mai multe tabele

Prinznd un pic de curaj dup ncercarea din paragraful precedent, ne apropiem simitor de majoritatea situaiilor reale, n care informaiile necesare se gsesc nu ntr-o singur tabel, ci n dou sau chiar mai multe. Interogarea din figura 2.36 botezat SituatieVenituriLunare utilizeaz date din trei tabele. ntruct n primele paragrafe ale capitolului au fost declarate restriciile refereniale, pe msura adugrii tabelelor n interogare, ACCESS-ul indic i legturile dintre ele.

Figura 2.36. Interogare ce folosete trei tabele Spre deosebire de interogarea precedent, aceast interogare conine cteva coloane noi: DenumireLocMunca din tabela LocMunc; Marca, Nume, Prenume i SalarTarifar preluate din tabela Angajat; coloanele Anul i Luna din tabela Pontaj au rmas. De asemenea, a mai fost adugat un cmp calculat (n afar de TotalOre), VenitLunar, a crui expresie este ([OreZi] + [OreSuplimentare] + [OreNoapte]) * [SalarTarifar] / 168 (de dragul simplitii s-a optat pentru o formul simplist de calcul, n care s-a considerat numrul orelor lucrtoare din luna septembrie 2007 este 168). Condiiile de filtrare a liniilor din rezultat au rmas aceleai, ns acum avem trei criterii de ordonare a liniilor, respectiv valorile coloanelor DenumireLocMunca, Nume i Prenume, de fiecare dat alegndu-se modul cresctor (ASCENDING). Rezultatul interogrii este prezentat n figura 2.37.

36

Figura 2.37. Rezultatul interogrii din figura 4.36 Mai trebuie spus c pentru coloana VenitLunar, n fereastra Properties, s-a stabilit formatul Fixed i afiarea cu dou zecimale.

2.4.3. Prelucrri /grupri /sintetizri

Partea cea mai interesant a interogrilor, n ACCESS sau orice alt SGBD, ine de prelucrarea datelor numerice, n sensul agregrii lor. Astfel, managerii pot fi ct se poate de interesai s afle situaia veniturilor lunare pe departamente (n cazul nostru pe locuri de munc). n interogarea anterioar fiecare linie se refer la un angajat, aa nct, pentru onorarea solicitrii managerilor este necesar gruparea pe departamente a veniturilor lunare i nsumarea lor. Iat cum rezolvm problema vezi figura 2.38. Pentru declararea modalitii de grupare trebuie mai nti folosit simbolul de nsumare din bara de instrumente a interogrii. Ca urmare, n machet, ntre liniile Table i Sort apare linia Total. Pe aceast linie, pentru coloana VenitLunar (a doua coloan) este selectat opiunea Sum, ceea ce nseamn c veniturile lunare ale angajailor vor fi nsumate pe fiecare loc de munc (i fiecare an i lun, dar aceste criterii nu sunt relevante de vreme ce n interogarea propus sunt prelucrate doar datele aferente unei luni calendaristice). Un alt artificiu care face o impresie bun este noul criteriu prin care utilizatorul poate indica n momentul vizualizrii rezultatelor interogrii luna i anul. Din nefericire, cele dou interogri din paragrafele anterioare prelucreaz numai datele din luna septembrie 2007. La vizualizare (click pe simbolul View din stnga barei de instrumente a interogrii) pe ecran apare o fereastr minuscul, urmat de o alta, le fel de minuscul (figura 2.39), n care se solicit luna i anul i numai dup aceea se afieaz rezultatul (figura 2.40).

37

Buton ul de agregare

Figura 2.38.Filtru generalizat plus agregarea datelor

Figura 2.39. Cele dou ferestre pentru specificarea valorilor parametrilor Luna i Anul

Figura 2.40.Rezultatul interogrii din figura 2.38 Fiindc am ajuns deja la un nivel de performan destul de ridicat, ne vom opri aici cu problematica interogrii bazelor de date. Oricum, muli pai interesani mai pot fi efectuai pentru a merge mai departe. V urm succes! n continuare ne vom ocupa de punerea ntr-o form elegant a datelor extrase din baz.

PROBLEM
Pasul 6 construirea interogrilor asupra bazei de date
S se construiasc i s se execute urmtoarele interogri: 1. Obinei o situaie a orelor lucrate n luna septembrie 2007 (sau o alta, n funcie de datele din propria baz de date), care s conin marca angajatului, orele lucrate de zi, cele suplimentare i 38

cele de noapte, precum i totalul orelor lucrate, calculat prin nsumarea celor trei categorii de ore. Datele vor fi ordonate cresctor dup marca. 2. Obinei o list a angajailor care s conin marca, numele i prenumele, CNP, data naterii, adresa, telefonul i email-ul. Datele vor fi ordonate cresctor dup numele i prenumele angajailor. 3. Obinei o list a angajailor de sex feminin, care s conin marca, numele i prenumele, CNP, data naterii i telefonul. Datele vor fi ordonate descresctor dup data naterii. 4. Realizai o situaie a salariului tarifar care s conin marca, numele, prenumele i salariul tarifar, iar datele s fie ordonate descresctor dup salariul tarifar. 5. S se realizeze o situaie a veniturilor lunare pe luna septembrie 2007 (sau alta, n funcie de datele din propria baz de date), care s conin numele departamentului, marca, numele i prenumele angajatului, total ore lucrate, salariul tarifar i venitul lunar, calculat dupa expresia total ore lucrate * salar tarifar / 168. Date vor fi ordonate cresctor dup numele departamentului, numele i prenumele angajailor. 6. S se obin o list a posturilor de munc dintr-un anumit departament (denumirea locului de munc va fi parametru n interogare!), care s conin identificatorul i denumirea postului, denumirea funciei aferente, marca, numele i prenumele angajatului. 7. S se obin o situaie a deciziilor nregistrate ntr-o perioad anume (data iniial i data final vor fi parametri), n care s fie incluse numrul i data deciziei, marca, numele i prenumele angajatului, denumirile postului vechi i a celui nou, data intrrii n vigoare. Datele vor fi ordonate descresctor dup data deciziei. 8. S se obin o situaie centralizatoare pe departamente a veniturilor lunare aferente lunii septembrie 2007 (sau alta, n funcie de datele din propria baz de date), n care veniturile lunare ale angajailor s fie nsumate pe departamente. Situaia va conine numele departamentului i valoarea total a veniturilor lunare, iar datele rezultate vor fi ordonate descresctor dup totalul veniturilor. 9. S se afle valorile medii ale salariului tarifar pe sexe. Rezultatul va conine sexul, numrul angajailor i valoarea medie a salariului tarifar. 10. S se realizeze o situaie centralizatoare a absenelor pe departamente ntr-o perioad dat (data iniial i cea final a perioadei vor fi parametri), care s conin numele departamentului, numrul total al absenelor motivate pe departament, numrul total al absenelor nemotivate pe departament i numrul total al absenelor (calculat prin nsumarea celor motivate i a celor nemotivate). Datele vor fi ordonate alfabetic dup numele departamentului. 11. S se afle salariile maxime i cele minime pentru fiecare departament. Lista va conine numele departamentului, salariul tarifar minim i cel maxim pentru fiecare departament, iar datele vor fi ordonate alfabetic dup numele departamentului.

2.5 CONSTRUIREA I UTILIZAREA RAPOARTELOR

Informaiile din domeniul economic sunt prezentate, cel mai adesea, prin intermediul rapoartelor. Raportul reprezint un ansamblu de informaii conforme cu cerinele utilizatorilor, construit pe baza datelor din tabele. Rapoartele pot fi afiate pe ecran sau tiprite la imprimant, majoritatea lor avnd form tabelar. La proiectarea i construirea rapoartelor n format tabelar se vor lua n considerare cinci seciuni principale, la care mai pot fi adugate altele dou, dac se dorete gruparea datelor. Aceste seciuni,

39

sunt (redm i denumirea lor n limba englez, pentru o mai bun recunoatere a lor n generatoarele de rapoarte): Antetul i sfritul (subsolul) raportului (Report Header i Report Footer). Antetul raportului conine elementele care vor apare o singur dat, la nceputul raportului. Aici se includ, de obicei, titlul raportului, data obinerii i numele destinatarului. n seciunea de sfrit (subsol) se prevd elementele care vor apare o singur dat n raport, la sfritul acestuia. Aici se pot include totalurile generale pentru cmpurile numerice i numele persoanelor care au generat i certificat raportul respectiv. Antetul i sfritul paginii (Page Header i Page Footer). n aceste seciuni vor fi incluse acele elemente ale raportului care vor apare o singur dat pe fiecare pagin, la nceputul sau la sfritul ei. De regul, numele coloanelor sunt prevzute n antetul paginii astfel nct ele s fie afiate la nceputul fiecrei pagini. Totalurile la nivel de pagin, dac sunt necesare, trebuie incluse n seciunea de sfrit (subsol) a paginii. Numrul paginii poate apare n oricare din cele dou seciuni. Seciunea de detaliu (Detail). Este seciunea principal a oricrui raport i conine valorile cmpurilor din baza de date i a expresiilor calculate ce vor forma o linie cu date. Pentru fiecare nregistrare prelucrat din baza de date se va crea cte o linie n raport. Antetul i sfritul grupului (Group Header i Group Footer). Aceste dou seciuni apar n rapoarte numai atunci cnd se dorete gruparea datelor. n exemplul din figura 4.51, datele privind veniturile lunare sunt grupate pe departamente, iar denumirea acestuia reprezint cmpul de control, adic acela dup valorile cruia se va face gruparea. Elementele incluse n aceste seciuni vor apare o singur dat pentru fiecare grup de date, deasupra primei linii cu date din grup, respectiv sub ultima linie. n antetul grupului se includ, de regul, datele de identificare ale grupului adic, n exemplul nostru, numele departamentului. n seciunea de sfrit se pot afia totaluri sau rezultatele altor operaiuni de agregare la nivelul grupului, precum numrul elementelor, valoarea total, valoarea medie, valoarea minim i valoarea maxim pentru cmpurile numerice. n ACCESS, rapoartele pot fi construite n trei moduri:

Crearea rapid a unui raport pe baza unei singure tabele sau interogri, prin utilizarea facilitii AutoReport (Columnar sau Tabular). Utilizatorul trebuie doar s specifice tabela din care se vor extrage datele, iar raportul va fi generat i afiat pe ecran imediat. Dac se opteaz pentru Columnar, raportul obinut va fi de tip coloan, adic datele unei linii din tabel vor fi aranjate pe o singur coloan. Dac se alege Tabular, raportul generat va fi de tip tabel, rezervndu-se cte o coloan pentru fiecare cmp din tabel. Apelarea la vrjitor (Report Wizard). Utilizatorul va construi raportul, pas cu pas, sub ndrumarea vrjitorului, rolul su constnd n furnizarea de rspunsuri la anumite ntrebri, care privesc sursa datelor (tabelele i/sau interogrile), cmpurile de date care vor fi reinute n raport, modul de grupare i ordonare a datelor, formatul i titlul raportului. Spre deosebire de cazul anterior, acum pot fi create rapoarte pe baza mai multor tabele i/sau interogri. Utilizarea ferestrei de proiectare (Design View). n acest mod de lucru, utilizatorul va avea posibilitatea s creeze rapoarte mai complexe, pe care s le personalizeze conform cerinelor sale. Ca i n primul caz, raportul poate conine date dintr-o singur tabel sau interogare.

40

Pentru crearea unui raport, indiferent de modalitatea dorit, se selecteaz opiunea Reports din fereastra bazei de date i apoi butonul New din linia de instrumente, situat n partea superioar a ecranului. n urma acestei aciuni se afieaz fereastra de dialog din figura 2.41.

Figura 2.41 Fereastra de dialog pentru alegerea modalitii de realizare a unui raport n continuare vom descrie numai ultimele dou moduri de lucru, ntruct acestea ne permit realizarea de rapoarte complexe i personalizate, prima fiind mult mai simpl de urmat. Apelarea la vrjitor presupune activarea ferestrei New Report, prezentat n figura 2.41, alegerea opiunii Report Wizard i selectarea interogrii SituatieVenituriLunare, construit n paragraful anterior, n csua combinat din partea de jos a ferestrei. Dup selectarea butonului OK va fi afiat fereastra din figura 2.42.

Figura 4.42 Fereastra de selecie a coloanelor raportului n Report Wizard n csua din stnga sunt afiate toate coloanele interogrii, din care utilizatorul le va selecta pe cele care vor apare n raport, printr-un dublu click cu mouseul pe fiecare coloan dorit. Coloanele selectate apar n csua din dreapta ferestrei. Se continu cu apsarea butonului Next, ce va avea ca efect afiarea urmtoarei ferestre, prezentat n figura 2.43.

41

Figura 2.43 Fereastra de selecie a grupurilor de date n Report Wizard n noua fereastr, utilizatorul are posibilitatea s specifice dac datele din raport vor fi grupate dup valorile uneia sau a mai multor coloane. n cazul n care se dorete gruparea datelor se vor selecta coloanele dorite din csua situat n partea stng a ferestrei cu acelai dublu click. n exemplul nostru am optat pentru gruparea datelor n funcie de valorile atributului DenumireLocMunc, iar n partea dreapt a ferestrei este sugerat forma raportului. Se continu prin apsarea butonului Next. Urmtorul pas const n stabilirea criteriilor de ordonare a datelor din raport, prin intermediul ferestrei din partea stng a figurii 2.44. n exemplu nostru am ales ca ordonarea dateelor s sa fac cresctor dup valorile coloanei Marca. Tot n cadrul acestui pas se pot alege opiunile de agregare a datelor, dac se dorete acest lucru. n acest sens se va activa butonul Summary Options ce va avea ca efect afiarea ferestrei din partea dreapt a figurii 4.44. n aceast fereastr sunt afiate toate coloanele numerice din raport, precum i funciile de agregare disponibile (Sum, Avg, Min, Max). n exemplul nostru exist o singur coloan cu date numerice, Expr2, aferent calculului venitului lunar n interogarea SituatieVenituriLunare, i am ales totalizarea ei prin selectarea funciei Sum. Prin apsarea butoanelor OK i apoi Next se trece la pasul urmtor.

Figura 2.44 Ferestrele de alegere a criteriilor de ordonare a datelor i a opiunilor de agregare n Report Wizard n cadrul urmtorilor doi pai se vor alege formatul raportului i stilul pentru afiarea coninutului raportului. Cei doi pai sunt redai n cele dou ferestre din figura 2.45. Trecerea de la unul la altul, precum i la pasul urmtor se realizeaz prin intermediul aceluiai buton Next.

42

Figura 2.45 Ferestrele de alegere a formatului raportului i a stilului pentru text n Report Wizard Deja am ajuns la pasul final n construirea raportului. Nu ne mai rmne dect s dm un nume raportului (care este sugerat dup numele interogrii sau tabelei care st la baza construirii raportului) i s alegem modalitatea de finalizare, adic afiarea raportului sau modificarea lui n modul de lucru Design View. Aceste elemente se regsesc n fereastra din figura 2.46. Deoarece noi am optat pentru afiarea raportului (opiunea Preview the report), dup apsarea butonului Finish am obinut pe ecran raportul dorit, identic cu cel prezentat n figura 2.47. Remarcai c datele sunt grupate pe fiecare loc de munc, adic mai nti sunt afiai angajaii din departamentul Aprovizionare, apoi cei de la Contabilitate i Resurse umane, iar pentru fiecare departament se efectueaz i afieaz totalul veniturilor lunare. Un total general este afiat la sfritul raportului. De asemenea, remarcai c n cadrul grupului de date sunt ordonate dup valorile coloanei Marca.

Figura 2.46 Finalizarea construirii raportului n Report Wizard

43

Figura 2.47 Forma final a raportului privind situaia veniturilor lunare Dei raportul a fost obinut foarte uor i rapid, se pot observa unele neajunsuri n forma sa final: apariia numelor atributelor din tabele n locul unor denumiri mai explicite ale coloanelor, existena unor titluri nu tocmai clare, cum ar fi cele din liniile de total, etc. Astfel de situaii sunt evitate dac se apeleaz la cel de-al treilea mod de construire a rapoartelor, respectiv fereastra Design View. Activarea ei se face ntr-un mod asemntor cu cel prezentat anterior pentru utilizarea vrjitorului (Report Wizard), doar c, de data aceasta, n fereastra de dialog din figura 2.41 se va alege opiunea Design View i apoi aceeai interogare SituaieVenituriLunare. Rezultatul este prezentat n figura 2.48. Ne propunem s construim un raport asemntor cu cel construit anterior, doar c vom mai introduce dou coloane, pentru numrul orelor lucrate i salariul tarifar.

44

Figura 2.48 Fereastra Design View pentru construirea rapoartelor Pentru mai mult claritate, relum etapele recomandate de ctre noi pentru crearea raportului: 1. Crearea interogrii pentru extragerea datelor necesare raportului din tabele. Aa cum spuneam anterior, n fereastra de proiectare pot fi construite rapoarte pe baza unei singure tabele sau interogri. Dac raportul solicit date din dou sau mai multe tabele se va crea o interogare care s extrag datele necesare. n exemplul nostru vom utiliza interogarea SituaieVenituriLunare. 2. Deschiderea ferestrei pentru construirea raportului. n acest sens, se activeaz fereastra de dialog New Report, prezentat anterior n figura 2.41, se selecteaz opiunea Design View, dup care, din csua combinat situat mai jos se alege interogarea sau tabela dorit. Dup apsarea butonului OK, se deschide fereastra pentru construirea rapoartelor, prezentat n fig. 4.48. n cadrul ferestrei se poate observa pagina raportului care, pentru nceput este goal, bara de instrumente i o mic fereastr ce conine numele cmpurilor tabelei sau interogrii selectate anterior. Se observ c pagina conine numai trei din cele cinci seciuni ale unui raport. Pentru adugarea celorlalte dou, Report Header i Report Footer, se va accesa meniul View i se va selecta opiunea Report Header/Footer. 3. Adugarea obiectelor n cele cinci seciuni ale raportului. Pentru includerea obiectelor n raport se utilizeaz bara de instrumente specifice construirii rapoartelor. n acest sens, vor fi utilizate urmtoarele butoane: etichet ,pentru specificarea titlului raportului, denumirii coloanelor sau a altor texte

cu rol explicativ; csu de text , pentru adugarea cmpurilor de date i a expresiilor de calcul ale cror

valori vor fi afiate la vizualizarea /tiprirea raportului. linie i dreptunghi , pentru trasarea liniilor i chenarelor necesare pentru

nfrumusearea raportului; sgeat , atunci cnd dorim selectarea unui obiect din raport.

45

Pentru adugarea unui text, se selecteaz butonul etichet, se poziioneaz mouse-ul n poziia din care dorim s nceap textul i se d clic, dup care se introduce textul. Pentru a continua textul pe linia urmtoare, dar n aceeai csu, se folosete combinaia de taste CTRL+ENTER. Mai nti se completeaz antetul raportului (Report header), n care se include data afirii sau tipririi, i antetul paginii (Page header). Pentru includerea datei curente se adaug o csu de text care va avea ca expresie de calcul funcia DATE(). Specificarea expresiei de calcul se face astfel: se selecteaz csua i se apas butonul Properties din linia cu instrumente. Efectul acestei aciuni const n afiarea ferestrei cu proprieti, prezentat n figura 2.49.a). n aceast fereastr se alege proprietatea Control Source i se apas butonul trei puncte, din dreapta, pentru deschiderea ferestrei Expression Builder (construirea expresiilor de calcul). n figura 2.49.b) se poate vedea coninutul acestei ferestre i modul n care a fost introdus expresia DATE(). Expresia de calcul poate fi introdus i de la tastatur, direct n csua de editare. Se revine n pagina raportului prin apsarea butonului OK i nchiderea ferestrei cu proprieti.

a) Fereastra cu proprieti

b) Fereastra pentru introducerea expresiilor de calcul

Figura 2.49 Ferestrele pentru introducerea expresiilor de calcul Pasul urmtor vizeaz introducerea cmpurilor Marca, Nume, Prenume, TotalOreLucrate (Expr1), SalarTarifar i VenitLunar (Expr2) n seciunea de detaliu (Detail). n acest sens, din lista cmpurilor se trag, pe rnd, cele patru cmpuri n locul dorit. Eticheta adugat automat pentru fiecare cmp introdus n raport poate fi tears deoarece rolul explicativ l ndeplinete numele coloanei n care acesta este plasat. Dedesubtul celor patru cmpuri se traseaz o linie pentru a delimita rndurile cu date n momentul vizualizrii /tipririi raportului. n subsolul paginii (Page Footer) se vor introduce numrul paginii curente i numrul total de pagini din raport. Se va aduga o csu de text, urmndu-se paii descrii anterior pentru data curent, a crei expresie va avea forma: = Pagina & [Page] & din & [Pages]. Variabila [Page] livreaz numrul paginii curente, iar variabila [Pages] numrul total de pagini. Operatorul & este utilizat pentru adunarea (concatenarea) irurilor de caractere. n subsolul raportului (seciunea Report Footer) se adaug o linie pentru totalul general, n care va fi totalizat venitul lunar. Formula de calcul se introduce tot prin intermediul csuelor de text i va avea forma: = SUM ([VenitLunar]) 4. Gruparea i ordonarea datelor. Liniile din raport pot fi ordonate sau grupate n funcie de mai multe criterii, iar pentru fiecare grup de date se pot introduce n raport alte dou seciuni: antetul i 46

subsolul grupului. Cele dou operaiuni sunt realizate din fereastra Sorting and Grouping. Deschiderea ei se face prin selectarea opiunii Sorting and Grouping din meniul View sau prin apsarea butonului din linia cu instrumente, situat n partea superioar a ecranului.

Fereastra (prezentat n figura 2.50) conine un grid (tabel), format din dou coloane, Field /Expression i Sort Order, i un grup de proprieti pentru definirea grupurilor de date, n partea sa inferioar. Coloana Field /Expression este utilizat pentru specificarea cmpurilor sau expresiilor dup care se face gruparea i /sau ordonarea datelor n raport. n raportul nostru datele trebuie grupate dup denumirea locului de munc i ordonate dup marca angajatului. De aceea, vom selecta n prima linie cmpul DenumireLocMunca, iar n cea de-a doua Marca. Aceast coloan poate conine cel mult zece nume de cmpuri i /sau expresii, adic pot fi utilizate cel mult zece criterii de grupare i sortare.

Figura 2.50 Fereastra Sorting and Grouping Coloana Sort Order permite alegerea modalitii de ordonare cresctoare (Ascending) sau descresctoare (Descending) pentru cmpul sau expresia din linia respectiv. n momentul completrii coloanei Field/Expression, n coloana Sort Order va fi atribuit implicit valoarea Ascending. Dac se dorete modificarea ordinii de sortare pentru un anumit cmp sau expresie, atunci se selecteaz printr-un click elementul respectiv, dup care n coloana Sort Order se alege valoarea Descending. n cazul n care pentru un cmp sau o expresie se dorete nu doar sortarea datelor, ci i gruparea lor, atunci se vor configura proprietile din jumtatea inferioar a ferestrei Sorting and Grouping. Aceste proprieti au urmtoarele semnificaii: Group Header prezint dou valori posibile Yes /No. Dac se alege valoarea Yes, atunci pentru cmpul sau expresia selectat din coloana Field /Expression se adaug n raport o seciune nou pentru antetul grupului. Valoarea implicit este No, adic nu se creeaz automat o seciune pentru antetul grupului. Group Footer este asemntoare cu proprietatea anterioar, numai c se refer la seciunea de sfrit (subsol) a grupului respectiv. Pentru includerea ei n raport se va alege valoarea Yes. Group On stabilete modul de grupare a valorilor cmpului selectat. Valorile posibile depind de tipul cmpului sau expresiei de grupare (text, numeric sau dat calendaristic). De exemplu, dac s-ar fi ales data pontajului drept cmp de grupare, atunci prin aceast proprietate se va stabili dac datele vor fi grupate pe fiecare valoare distinct (se alege valoarea Each Value), pe fiecare an (Year), lun (Month), sptmn (Week) s.a.m.d. Group Interval specific un interval sau un numr de caractere pe care se bazeaz gruparea liniilor din raport. n cazul unui cmp de grupare de tip Date/Time, stabilirea valorii 12 semnific gruparea liniilor care aparin aceleiai jumti de zi, dac pentru proprietatea Group On a fost stabilit valoarea Hour. 47

Keep together se refer la modul de tiprire a liniilor raportului care fac parte din acelai grup. Pentru aceast proprietate exist trei valori posibile: No permite tiprirea liniilor dintr-un grup i pe pagina urmtoare, dac s-a ajuns la sfritul paginii; Whole group (Grupul ntreg) are ca efect tiprirea tuturor seciunilor grupului (antetul, detaliile i subsolul) pe o singur pagin, dac este posibil; With First Detail (Cu prima linie de detaliu) antetul grupului va fi tiprit pe aceeai pagin cu prima linie a seciunii de detaliu. Dup adugarea tuturor cmpurilor i expresiilor de ordonare i grupare i configurarea proprietilor de grupare, se nchide fereastra Sorting and Grouping i se trece la completarea seciunilor nou introduse n pagina raportului. Cerinele raportului ales de noi ca exemplu impun crearea unui grup de date, n funcie de denumirea locului de munc. n seciunea de antet se introduce denumirea locului de munc, iar n cea de subsol se adaug totalul calculat pentru venitul lunar, n maniera descris pentru seciunea Report Footer. Forma final a raportului privind veniturile lunare, cu toate obiectele incluse, este prezentat n figura 2.51.

Figura 2.51 Fereastra pentru construirea raportului exemplificat forma final Acum se salveaz raportul (este recomandabil s salvai mai des, fr a atepta s finalizai construirea raportului), dup care se face vizualizarea acestuia, prin selectarea opiunii Print Preview din meniul View sau prin apsarea butonului din partea stng a liniei cu instrumente. n

continuare se poate configura pagina (dimensiune, orientare, margini etc.), folosind opiunea Page Setup din meniul File. De asemenea, se poate tipri raportul prin comanda Print din acelai meniu File. La vizualizare raportul va arta ca n figura 2.52. Odat salvat, raportul poate fi ulterior modificat. n acest sens, se alege obiectul Report din fereastra bazei de date, apoi se alege raportul dorit din fereastra din dreapta, ce conine rapoartele create deja, i se apas butonul din linia cu instrumente. Efectul acestei comenzi va consta

n deschiderea ferestrei de construire a raportului (figura 2.51), n care vor fi regsite toate obiectele raportului i care pot fi modificate n conformitate cu noile cerine.

48

Figura 2.52 Forma i coninutul raportului exemplificat la vizualizare Dac ai reuit s parcurgei toate etapele descrise anterior, probabil v-ai convins c facilitile interesante i puternice oferite de modul Design View i meritai sincere felicitri. n schimb, este de asemenea probabil ca rata de abandon n rndul temerarilor s fie foarte mare. Motivele ar putea consta n dificultile ntmpinate uneori n realizarea diferiteelor operaiuni, precum i timpul ndelungat de construire a raportului. n concluzie, poate cea mai eficient cale de construire a rapoartelor const n realizarea lui cu ajutorul vrjitorului (Report Wizard) i apoi personalizarea i completarea lui n modul Design View. V felicitm dac ai ajuns la acest rnd din acest capitol i v dorim succes pentru aprofundarea facilitilor de lucru neprezentate de noi.

PROBLEM
Pasul 7 Crearea rapoartelor
S se construiasc urmtoarele rapoarte: 1. Situaia veniturilor lunare prezentat n figura 2.52. 2. Lista angajailor de sex feminin pornind de la interogarea cu numrul 3 de la pasul 6. 3. Raportul posturilor de munc pornind de la interogarea cu numrul 6 de la pasul 6.

Cerinele de realizare a proiectului la disciplina

49

Baze de date
Aplicaia informatic va fi dezvoltat n Microsoft Access. Aplicaia va conine obligatoriu urmtoarele componente: 1. Baza de date. Numrul minim de tabele este 4. Se vor utiliza urmtoarele faciliti de lucu: specificarea valorilor implicite (default), a regulilor de validare i a mesajelor de eroare asociate, definirea cheii primare, stabilirea legturilor dintre tabele, definirea restriciilor refereniale n fereastra Edit relationship. 2. Interogarea bazei de date. Se vor crea minim 7 interogri, din care cel puin 2 vor include faciliti de agregare a datelor. 3. Formulare (ecrane pentru actualizarea i vizualizarea datelor). Se vor crea minim 2 formulare utiliznd Form wizard. 4. Rapoarte. Se vor crea minim 2 rapoarte utiliznd Design view, din care cel puin un raport va conine grupuri de date. Temele de realizare a proiectului vor fi alese exclusiv din domeniul economic.

50