Studii de Caz Access 2007

Baze de date Access 2007
- Studii de caz
Editura 2009
2009 Editura InfoMega

Toate drepturile rezervate. Reproducerea materialelor din aceast lucrare se poate face doar cu acordul scris al editurii. Autorii i asum rspunderea asupra materialelor publicate.
Editur acreditat de C.N.C.S.I.S.
e-mail: office@infomega.ro http://www.infomega.ro
CIP Nr. 6275/27.03.2009
Descrierea CIP a Bibliotecii Naionale Baze de date Access 2007 : studii de caz / Stanciu Andrei (coord.), Mihai Florin, Mangiuc Drago, - Bucureti : InfoMega, 2009 Bibliogr. ISBN 978-973-7853-41-7 I. Stanciu, Andrei (coord.) II. Mihai, Florin III. Mangiuc, Drago 004.65
Microsoft Excel, Microsoft Word i Microsoft Access 2007 sunt mrci nregistrate ale Microsoft Corporation
Cuvnt nainte
Rod al colaborrii unui grup de tineri autori, cadre didactice universitare n Academia de Studii Economice Bucureti, cartea se adreseaz tuturor celor pasionai de informatica de gestiune n general i de dezvoltarea aplicaiilor informatice cu baze de date n particular. Obiectivul principal al lucrrii este acela de a oferi studenilor un sprijin n realizarea proiectelor proprii, de a le oferi idei i soluii pentru dezvoltarea aplicaiilor i de a le deschide interesul spre domeniul bazelor de date. Cartea conine 11 studii de caz ce trateaz operaii de gestiune n cadrul diferitor entiti organizaionale. Urmrind scopul didactic al lucrrii, autorii au ncercat s reflecte ntr-o msur ct mai mare realitatea economic dar, n unele situaii, din considerente didactice, studiile de caz au fost simplificate n sensul formulrii regulilor de gestiune i a limitrii numrului de atribute, pentru a face modelele ct mai accesibile. Proiectarea modelelor relaionale pentru bazele de date este realizat pe baza teoriei normalizrii i, pentru fiecare studiu de caz, sunt exemplificate cereri de interogare a datelor i propuneri privind proiectarea elementelor de interfa i a situaiilor de raportare prin facilitile existente n Microsoft Access 2007. n sperana c cititorii vor gsi utile exemplele prezentate i vor avea curiozitatea s testeze i, de ce nu, s mbunteasc aceste soluii, fiecare studiu de caz ofer cteva propuneri de extindere a modelelor i idei de exerciii a cror rezolvare este lsat la latitudinea cititorilor. ncheiem aceast scurt introducere mulumind pentru sprijinul acordat pe tot parcursul colaborrii n cadrul colectivului de baze de date din catedra de Informatic de Gestiune, profesorilor Pavel Nstase, Vasile Florescu i doamnei profesoare Florentina Berbec.
Autorii
Cuprins
I.
Baz de date pentru evidena mprumuturilor de cri n cadrul unei biblioteci.. 7
Autor: Asistent univ. drd. Rdulescu Cristina

II. Baz de date pentru evidena contractelor ncheiate de o agenie de turism..... 28
Autor: Confereniar univ. dr. Oancea Mirela

III. Baz de date pentru evidena testrilor la un centru de certificare a aptitudinilor de operare pe calculator 45
Autor: Asistent univ. drd. Geambau Cristina

IV. Baz de date pentru gestiunea aprovizionrilor cu materiale la o firm 70
Autor: Lector univ. dr. Stanciu Andrei

V. Baz de date pentru evidena polielor de asigurare, la o societate de profil 89
Autor: Asistent univ. drd. Rdulescu Cristina

VI. Baz de date pentru evidena operaiunilor efectuate prin casierie... 111
Autor: Lector univ. drd. Aleca Ofelia

VII. Baz de date pentru gestiunea costurilor proiectelor 128
Autor: Lector univ. drd. Aleca Ofelia

VIII. Baz de date pentru evidena personalului. 146
Autor: Confereniar univ. dr. Mihai Florin

IX. Baz de date pentru evidena contractelor cu clienii la o firm de consultan 162
Autor: Lector univ. dr. Stanciu Andrei
X. Baz de date pentru evidena activitii unei clinici medicale 176
Autor: Lector univ. dr. Mangiuc Drago

XI. Baz de date pentru evidena comenzilor primite de ctre un studio foto 192
Autor: Lector univ. dr. Mangiuc Drago
Baz de date pentru evidena mprumuturilor de cri n cadrul unei biblioteci
O bibliotec urmeaz s implementeze o baz de date pentru evidena informatizat a mprumuturilor de cri. Pentru fiecare titlu ce poate constitui obiectul mprumuturilor, alturi de numele propriu-zis (titlul crii) sunt ntregistrate urmtoarelor informaii: autorii, editura i anul publicrii, genul cruia i aparine, precum i numrul exemplarelor pe care biblioteca le deine; fiecrui titlu i se atribuie un cod unic, cunoscut sub numele de cot. Pentru evidena autorilor se consemneaz: codul, numele, prenumele i opional, ara de provenien. Abonaii bibliotecii sunt nregistrai n sistem pe baza urmtoarelor date: cod abonat, nume, prenume, dat natere, seria i numrul actului de identitate, adres, telefon. Acetia pot opta pentru diverse tipuri de abonamente, fiecare tip fiind caracterizat de un cod unic, denumire, durata de valabilitate a abonamentelor (exprimat n numr de luni), limit cri (numrul maxim de cri ce pot fi mprumutate la un moment dat), limit timp (durata maxim, ca numr de zile, a mprumuturilor) i tarif. Pentru fiecare abonament se atribuie un cod unic i se indic tipul de abonament, perioada de valabilitate (data de debut i cea de expirare) i titularul (abonatul). mprumuturile pot fi efectuate doar n baza unor abonamente valabile i sunt nregistrate prin intermediul bonurilor de mprumut. Alturi de abonamentul n baza cruia a fost ntocmit, un astfel de bon trebuie s specifice data mprumutului, crile mprumutate i data limit la care acestea trebuie returnate (n funcie de tipul abonamentului); la nregistrarea n sistem, fiecare bon primete un numr unic. Crile mprumutate prin intermediul aceluiai bon pot fi restituite la date diferite, pentru fiecare carte indicndu-se data returnrii. Fiecare abonament valabil este caracterizat de o limit efectiv de mprumut, iniial egal cu limita specific tipului de abonament (limit cri), dar care se diminueaz odat cu fiecare carte mprumutat (-1), urmnd s se refac (+1) la momentul restituirii ei. Reguli de gestiune: Un titlu poate fi publicat de un autor sau, n colaborare, de un colectiv de autori. Un abonament are un singur titular. Un bon de mprumut are la baz un abonament unic. Un bon de mprumut poate viza mai multe titluri, cu condiia ca numrul acestora s se ncadreze n limita specific tipului de abonament. I. Realizai modelul relaional al bazei de date i implementai n MS Access Pe baza informaiilor care descriu activitatea bibliotecii, se poate constitui dicionarul atributelor i se pot deduce relaiile dintre acestea. Ambele aspecte sunt redate sintetic prin intermediul matricei dependenelor funcionale, prezentat n continuare:
Studii de caz
Observaii: Anterior realizrii matricei au fost eliminate atributele derivate: DataExpirareAbonament (se determin n funcie de DataDebut i DurataValabilitate), DataLimitaRestituireImprumut (depinde de DataBon i LimitaDurata), LimitaEfectivaImprumut (se calculeaz deducnd numrul crilor mprumutate i nerestituite din LimitaNrCarti). Pentru simplificare, pe primul rnd al matricei au fost dispuse doar atributele sau perechile de atribute cu rol de determinant, n raport cu alte atribute. Dependenele funcionale au fost marcate cu simbolul 1, iar cele tranzitive cu 1t.
Din analiza matricei dependenelor funcionale, se deduce urmtorul model relaional al bazei de date:
TipAbonament (CodTipAbonament, DenumireTipAbonament, DurataValabilitate, LimitaNrCarti, LimitaDurata, TarifAbonament) Abonat (CodAbonat, NumeAbonat, PrenumeAbonat, DataNastere, SerieCI, NrCI, Adresa, Telefon) Autor (CodAutor, NumeAutor, PrenumeAutor, Tara) Carte (Cota, Titlu, Editura, AnPublicare, Gen, NrExemplare) Abonament (CodAbonament, DataDebut, CodTipAbonament, CodAbonat) BonImprumut (NrBon, DataBon, CodAbonament) CarteImprumutata (NrBon, Cota, DataRestituire) AutorCarte (Cota, CodAutor)
Observaii: ntruct printr-un bon de mprumut pot fi mprumutate mai multe cri, care pot fi restituite pe rnd, la date diferite (i n plus, n mod firesc, aceeai carte poate face, n timp, obiectul mai multor mprumuturi), atributul DataRestituire necesit un determinant compus (NrBon+Cota), ce va constitui cheia primar a unei tabele distincte (CarteImprumutata). Totodat, la nivelul acestui tabel, atributele NrBon i Cota sunt, n mod individual, chei externe n raport cu cheile primare din tabelele BonImprumut, respectiv Carte. Tabela AutorCarte este consecina dependenelor multiple reciproce dintre atributele Cota i CodAutor. n aceast situaie se impune constituirea unei noi tabele, cu o cheie primar compus din ambele atribute, care sunt totodat, n mod individual, chei externe n raport cu cheile primare Cota i CodAutor, din tabelele asociate. n vederea realizrii modelului relaional au fost eliminate dependenele tranzitive, astfel nct tabelele rezultate se afl deja n forma normal 3 (FN3) i pot face obiectul implementrii. Rezultatul implementrii modelului relaional n Microsoft Access 2007 este urmtorul:
10
Studii de caz
Studiu individual: ntruct biblioteca este implicat n schimburi culturale cu alte instituii de profil, se impune evidena crilor primite n custodie de la alte biblioteci, respectiv a crilor date n custodie. n acest scop, trebuie preluate n sistem att datele aferente crilor vizate (ntr-o manier identic celei descrise n prezentarea aplicaiei), ct i cele privitoare la bibliotecile partenere (codul, denumirea, adresa, localitatea i telefonul). Pentru fiecare titlu ce face obiectul transferului se va consemna numrul exemplarelor transferate, data de nceput, respectiv de sfrit a perioadei n care opereaz transferul, precum i biblioteca partener. Crile primite n custodie vor fi evideniate separat de cele date n custodie. Adugai modelului relaional tabelul, sau tabelele, ce permit memorarea datelor privind schimburile descrise.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) n cazul oricrui bon de mprumut, data ntocmirii trebuie nregistrat n mod obligatoriu. Aceasta nu poate fi ulterioar datei curente i nici anterioar datei la care biblioteca a fost nfiinat (5 februarie 1999); de asemenea, data curent va fi utilizat ca valoare implicit pentru data mprumutului. La nivelul cmpului NrBon, din tabela BonImprumut, vor fi specificate urmtoarele proprieti: - Default Value: DATE() - Required: Yes - Validation Rule: BETWEEN #5/2/1999# AND DATE() - Validation Text: Data mprumutului nu poate fi ulterioar datei curente, sau anterioar datei de nfiinare a bibliotecii! II.b) Presupunnd c biblioteca ofer spre mprumut doar titluri publicate de un numr limitat de edituri, se cere ca denumirile acestora s fie afiate n cadrul unei liste derulante, introducerea editurii care a publicat un anumit titlu putnd fi realizat prin selectarea unui articol din list. n acest scop, este necesar ca n tabela Carte, la nivelul cmpului Editura s se seteze urmtoarele proprieti: - Display Control: Combo Box - Row Source Type: Value List - Row Source: Astra; Guliver; Atlas (sunt enumerate denumirile editurilor) - Limit To List: Yes
11
II.c) La nivelul oricrui tip de abonament, limita de durat a mprumuturilor (exprimat n numr de zile) nu poate depi durata de valabilitate a abonamentelor de tipul respectiv (exprimat n numr de luni); de asemenea, nu se pot ncheia abonamente pe perioade mai scurte de o lun. n tabela TipAbonament, la nivelul cmpului DurataValabilitate vor fi specificate urmtoarele proprieti : - Validation Rule: >=1 - Validation Text: Nu se pot ncheia abonamente pe perioade mai scurte de o lun! Restricia privind relaia dintre limita de durat a mprumuturilor i durata de valabilitate a abonamentelor implic dou atribute ale tabelului TipAbonament, prin urmare trebuie implementat prin intermediul unei reguli de validare definit la nivel de tabel: - Table Properties / Validation Rule: ([DurataValabilitate] * 30) >= [LimitaDurata] - Table Properties / Validation Text: Limita de durat a mprumuturilor nu poate depi durata de valabilitate a abonamentului! Observaie: Pentru a se putea face distincia ntre valori (constante) de tip text i atribute, numele atributelor trebuie delimitate prin paranteze drepte ([DurataValabilitate], [LimitaDurata]).
Studiu individual: Definii proprietile care permit implementarea urmtoarelor restricii la nivelul bazei de date: a) Durata de valabilitate a unui abonament, indiferent de tipul su, nu poate depi 3 ani. b) Abonaii bibliotecii trebuie s aib cel puin 18 ani. c) Pentru toate abonamentele cu durata mai mic de un an, durata maxim a mprumuturilor va fi limitat la 30 de zile, iar numrul de maxim al crilor ce pot fi mprumutate la un moment dat va fi limitat la 5.
12
Studii de caz
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze n ordine alfabetic toate titlurile ce aparin genurilor Art i Beletristic, publicate n ultimii 5 ani, de o anumit editur, indicat la execuie.
III.b) S se identifice tipurile de abonamente cu durata de valabilitate mai mare de un an, ce au fost solicitate n anul precedent de abonai care nu provin din Bucureti.
Observaie: Avnd n vedere natura relaiei dintre tabelele TipAbonament i Abonament un tip de abonament poate fi asociat cu mai multe abonamente), dar i faptul c se urmrete obinerea unei liste cu tipurile de abonamente care se conformeaz restriciilor din cerin, nu i a datelor privitoare la abonamentele propriu-zise, este posibil ca la nivelul cmpurilor afiabile, anumite combinaii CodTipAbonament + DenumireTipAbonament s apar n mod repetat. Din acest motiv, se va solicita ca din setul de rezultate returnat de interogare, s fie eliminte duplicatele (Query Properties / Unique Values: Yes).
13
III.c) n cazul fiecrui abonament valabil la data curent, s se determine numrul total al crilor mprumutate.
Observaie: Data expirrii unui abonament se calculeaz cumulnd durata de valabilitate (exprimat n luni, conform enunului) la data de la care abonamentul este valabil (DataDebut) i deducnd apoi o zi; spre exemplu, un abonament cu durata de 1 an i cu data de debut 7 mai 2009 expir la 6 mai 2010 (aceasta este ultima zi de valabilitate). n cazul de fa, pentru a determina data expirrii, s-a utilizat funcia calendaristic DATEADD (tip_unitate_timp, nr_uniti_timp, debut_interval), care permite aflarea datei de sfrit a unui interval pentru care se specific data de nceput i durata, exprimat prin numrul unitilor de timp de un anumit tip, indicat sub forma unor constante text, predefinite (d- zile, m - luni, yyyy - ani etc.).
III.d) S se reduc cu 20% tariful abonamentelor cu durata de 2 ani, care nu au fost solicitate de clienii bibliotecii.
Observaii: Cererea este rezolvat prin intermediul unei introgri de aciune, de actualizare (Update Query). Pentru a identifica tipurile de abonamente pentru care nu exist solicitri, trebuie cutate nregistrile tabelei TipAbonament, fr corespondent n tabela Abonament. n acest scop, cele dou tabele au fost relaionate prin intermediul unei jonciuni externe (Left Join, n cazul de fa), impunndu-se condiia ca
14
Studii de caz
n setul de rezultate obinut, atributele ce provin din tabela Abonament, inclusiv cmpul-cheie primar, CodAbonament, s aib valori nule. IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se identifice editurile care au publicat titluri din genurile Beletristic i Timp liber, ce au fost mprumutate n perioada 10 octombrie 2008 10 octombrie 2009.
SELECT DISTINCT Editura FROM Carte INNER JOIN (CarteImprumutata INNER JOIN BonImprumut ON CarteImprumutata.NrBon = BonImprumut.NrBon) ON Carte.Cota = CarteImprumutata.Cota WHERE Gen IN ("Beletristica", "Timp liber") AND DataBon BETWEEN #10/10/2008# AND #10/10/2009#;
Observaie: Datorit faptului c aceleai titluri pot figura n mai multe bonuri de mprumut, editurile care le-au publicat pot aprea n mod repetat la nivelul setului de nregistri returnat de interogare. n cazul de fa, unicul cmp afiabil este cel care conine denumirile editurilor, astfel nct se impune eliminarea duplicatelor prin intermediul specificatorului DISTINCT. IV.b) S se obin lista abonailor cu vrsta de peste 70 ani (ordonai dup vrst, n sens descresctor), care au ncheiat abonamente n luna curent; numele i prenumele vor fi afiate ntr-o coloan unic.
SELECT DISTINCT NumeAbonat & " " & PrenumeAbonat AS [Nume si Prenume], DATEDIFF("yyyy", DataNastere, DATE()) AS Varsta FROM Abonat INNER JOIN Abonament ON Abonat.CodAbonat = Abonament.CodAbonat WHERE DATEDIFF("yyyy", DataNastere, DATE()) >70 AND MONTH(DataDebut) = MONTH(DATE()) AND YEAR(DataDebut) = YEAR(DATE()) ORDER BY 2 DESC;
Observaie: ntruct este reprezentat de un cmp afiabil (Varsta), criteriul de sortare poate fi specificat att prin intermediul expresiei ce st la baza sa (DATEDIFF("yyyy", DataNastere, DATE())), ct i prin indicarea poziiei pe care o ocup n cadrul listei cmpurilor afiabile (ORDER BY 2). Funcia DATEDIFF(tip_unitate_timp, data1, data2) returneaz diferena dintre dou date, exprimat n numrul unitilor de timp de un anumit tip (specificat prin intermediul acelorai constante text predefinite, ca i n cazul funciei DATEADD). IV.c) S se identifice crile mprumutate i nerestituite, dei perioada de mprumut a expirat, precum i bonurile de mprumut asociate. Rezultatele vor fi sortate dup numrul zilelelor de ntrziere, n ordine descresctoare i dup titlurile crilor, n ordine alfabetic.
Baze de date Access 2007 SELECT Carte.Cota, Titlu, BonImprumut.NrBon, (DATE() - (DataBon + LimitaDurata-1)) AS Intarziere FROM TipAbonament INNER JOIN (Abonament INNER JOIN (BonImprumut INNER JOIN (CarteImprumutata INNER JOIN Carte ON CarteImprumutata.Cota = Carte.Cota) ON BonImprumut.NrBon = CarteImprumutata.NrBon) ON Abonament.CodAbonament = BonImprumut.CodAbonament) ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament WHERE DataRestituire IS NULL AND (DataBon + LimitaDurata - 1) < DATE() ORDER BY (DATE() - (DataBon + LimitaDurata - 1)) DESC, Titlu;
15
Observaie: innd cont de faptul c limita de durat a unui mprumut este exprimat n numr de zile, rezult ca trebuie determinate urmtoarele: Data limit a unui mprumut: (DataBon + LimitaDurata -1), sau, expresia echivalent (DATEADD(d, LimitaDurata, DataBon)-1) Numrul zilelor de ntrziere: (DATE() - (DataBon + LimitaDurata-1)) .
IV.d) S se determine numrul i valoarea total a abonamentelor cu durata de un an, care au fost achiziionate n fiecare lun a anului anterior; sortare dup numrul abonamentelor, n ordine descresctoare.
SELECT MONTH(DataDebut) AS Luna, COUNT(*) AS NrAbonamente, SUM(TarifAbonament) AS ValoareTotala FROM Abonament INNER JOIN TipAbonament ON Abonament.CodTipAbonament = TipAbonament.CodTipAbonament WHERE YEAR(DataDebut) = YEAR(DATE())-1 AND DurataValabilitate = 12 GROUP BY MONTH(DataDebut) ORDER BY COUNT(*) DESC;
IV.e) Pe baza numrului de cri mprumutate, s se realizeze un clasament al primelor 3 genuri solicitate de cititori, la nivelul unei perioade ce va fi specificat la execuie.
PARAMETERS [Inceput interval] Date, [Sfarsit interval] Date; SELECT TOP 3 Gen, COUNT(*) AS NrCarti FROM BonImprumut INNER JOIN (CarteImprumutata INNER JOIN Carte ON CarteImprumutata.Cota = Carte.Cota) ON BonImprumut.NrBon = CarteImprumutata.NrBon WHERE DataBon BETWEEN [Inceput interval] AND [Sfarsit interval] GROUP BY Gen ORDER BY COUNT(*) DESC;
IV.f ) S se obin lista titlurilor (sortate alfabetic) pentru care, temporar, nu exist nici un exemplar disponibil (toate exemplarele sunt mprumutate i nereturnate).
16
Studii de caz SELECT Carte.Cota, Titlu, NrExemplare FROM CarteImprumutata INNER JOIN Carte ON CarteImprumutata.Cota = Carte.Cota WHERE DataRestituire IS NULL GROUP BY Carte.Cota, Titlu, NrExemplare HAVING COUNT(*) = NrExemplare ORDER BY Titlu;
IV.g) S se obin o list a tipurilor de abonamente cu cel puin 100 solicitri, respectiv a celor fr nici o solicitare, la nivelul unui an indicat la execuie.
PARAMETERS [Introduceti anul vizat] Integer; SELECT TipAbonament.CodTipAbonament, DenumireTipAbonament, COUNT(*) AS NrSolicitari FROM TipAbonament INNER JOIN Abonament ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament WHERE YEAR(DataDebut) = [Introduceti anul vizat] GROUP BY TipAbonament.CodTipAbonament, DenumireTipAbonament HAVING COUNT(*) >=100 UNION SELECT TipAbonament.CodTipAbonament, DenumireTipAbonament, 0 AS NrSolicitari FROM TipAbonament LEFT JOIN Abonament ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament WHERE Abonament.CodTipAbonament IS NULL AND YEAR(DataDebut) = [Introduceti anul vizat];
Observaii: Pentru a identifica tipurile de abonamente pentru care nu exist solicitri, la nivelul tabelului TipAbonament trebuie cutate nregistrrile fr corespondent n tabelul Abonament, recurgndu-se la o jociune extern - a se revedea explicaiile de la punctul III.d) ntruct operatorul UNION permite reunirea ntr-un set de nregistrri unic, a rezultatelor produse de cereri de selecie distincte, dar cu o structur identic sub aspectul cmpurilor afiabile, pentru a uniformiza structura seturilor de nregistrri, n cazul cererii care vizeaz tipurile de abonamente fr solicitri, a fost introdus un cmp ce conine o valoare constant, 0, indicnd absena abonamentelor. IV.h) S se identifice titlurile din genul IT, pentru care durata medie de mprumut este superioar duratei medii a mprumuturilor, calculat la nivelul genului de care aparin; rezultatele vor fi salvate ntr-un nou tabel (Statistica-IT). Ulterior, n tabelul nou creat, vor fi adugate crile din acelai gen, fr nici un mprumut. - Creare tabel:
SELECT Carte.Cota, Titlu, AVG(DataRestituire - DataBon) AS [Durata medie mprumut] INTO [Statistica-IT] FROM Carte INNER JOIN (CarteImprumutata INNER JOIN BonImprumut ON CarteImprumutata.NrBon = BonImprumut.NrBon) ON Carte.Cota = CarteImprumutata.Cota
17
WHERE DataRestituire IS NOT NULL AND Gen LIKE "IT" GROUP BY Carte.Cota,Titlu HAVING AVG(DataRestituire - DataBon) > (SELECT AVG(DataRestituire - DataBon) FROM Carte INNER JOIN (CarteImprumutata INNER JOIN BonImprumut ON CarteImprumutata.NrBon = BonImprumut.NrBon) ON Carte.Cota = CarteImprumutata.Cota WHERE DataRestituire IS NOT NULL AND Gen LIKE "IT");
- Adugare nregistrri:
INSERT INTO [Statistica-IT] ( Cota, Titlu, [Durata medie mprumut] ) SELECT Carte.Cota, Carte.Titlu, 0 FROM Carte WHERE Cota Not In (SELECT Cota FROM CarteImprumutata);
IV.i) S se elimine din baza de date crile publicate de editurile Coral i Astoria, cu peste 10 ani n urm, care nu au fcut obiectul nici unui mprumut.
DELETE * FROM Carte WHERE Editura IN ("Coral", "Astoria") AND AnPublicare < (YEAR(DATE()) - 10) AND Cota <> ALL (SELECT Cota FROM CarteImprumutata);
IV.j) Biblioteca decide s achiziioneze cte 50 de exemplare din titlurile cu cel puin 100 de solicitri n ultimile 6 luni; s se opereze aceast modificare la nivelul bazei de date.
UPDATE Carte SET NrExemplare = (NrExemplare + 50) WHERE Cota = ANY (SELECT Cota FROM CarteImprumutata INNER JOIN BonImprumut ON CarteImprumutata.NrBon = BonImprumut.NrBon WHERE DATEDIFF("m", DataBon, DATE()) <= 6 GROUP BY Cota HAVING COUNT(*) >= 100);
Studiu individual: a) S se identifice editurile care n anul curent au publicat lucrri din genul Politic, scrise de autori britanici sau americani. b) S se calculeze valoarea total a ncasrilor aferente abonamentelor achiziionate n ultimile 2 sptmni, de clieni din Braov i Sibiu. c) S se determine vrsta medie a clienilor care dein abonamente valabile. d) S se identifice editurile de la care provin cele mai multe, respectiv cele mai puine titluri. e) S se reduc cu 10% tariful i s se extind cu 3 luni durata de valabilitate, n cazul tipurilor de abonamente pentru care nu au mai existat solicitri ulterioare datei de 1 noiembrie 2008.
18
Studii de caz
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular pentru consultarea i actualizarea datelor privind fondul de carte aflat n gestiunea bibliotecii. Avnd n verere c o carte poate avea mai muli autori, pentru rezolvarea acestei cerine s-a creat un formular bazat pe tabela Carte, n cadrul cruia a fost plasat un subformular (numit AutoriCarti) ce permite evidena autorilor. Rezultatul este urmtorul:
Observaii: Sursa de date (proprietatea Record Source) a formularului este reprezentat de tabela Carte, n timp ce subformularul are la baz urmtoarea cerere SQL:
SELECT AutorCarte.CodAutor, NumeAutor, PrenumeAutor, Cota FROM Autor INNER JOIN AutorCarte ON Autor.CodAutor = AutorCarte.CodAutor;
Sincronizarea dintre cele sursele de date ale celor dou formulare este realizat pe baza atributului comun Cota. Drept urmare, n cadrul formularului principal, vor fi setate urmtoarele proprieti ale obiectului subformular AutoriCarti: - Link Master Fields: Cota - Link Child Fields: Cota Butoanele de comand care permit deplasarea de la o nregistrare la alta, adugarea sau tergerea de nregistrri, precum i anularea modificrilor efectuate asupra nregistrrii curente, au fost realizate prin utilizarea asistentului (wizard) specializat, disponibil n MS Access 2007. Butonul de comand pentru editarea nregistrii curente (cmdEditeaza) determin, prin procedura ataat evenimentului Click (pe care, din motive de spaiu, nu o redm aici), comutarea formularului din modul consultare n modul editare, inhibnd sau activnd, n mod alternativ, anumite controale, n funcie de valoarea proprietaii Enabled (True sau False): n modul editare, cmpurile formularului, ca i butoanele pentru salvarea sau anularea modificrilor sunt active (Enabled = True), n timp ce butoanele pentru navigare, adugare,
19
tergere, ca i cmdEditeaza, sunt inactive (Enabled = False); desigur, situaia se inverseaz n modul consultare, proprietatea Enabled a fiecrui control fiind setat la valoarea opus celei din modul editare. Caseta combinat cboCota permite regsirea rapid a datelor privitoare la titlul a crui cot a fost selectat. Proprieti: - Control Source: (Unbound) - Row Source Type: Table/Query; - Row Source:
SELECT Cota, Titlu FROM Carte;
- Procedura asociat evenimentului AfterUpdate: Private Sub cboCota_AfterUpdate()

'Este creata o copie a setului de inregistrari din tabelul-sursa al formularului
Dim rsCarti As Recordset Set rsCarti = Me.RecordsetClone

'Se avanseaza la inregistrarea care contine cota selectata
rsCarti.FindFirst "[Cota]='" & Me.cboCota.Value & "'" Me.Bookmark = rsCarti.Bookmark End Sub
Butonul de comand cmdSalveaza permite salvarea modificrilor aduse titlului vizat de nregistrarea curent, innd-se seama de faptul c trebuie specificat cel puin un autor. Procedura asociat evenimentului Click:
Private Sub cmdSalveaza_Click() On Error Resume Next
'Se verifica existenta inregistrarilor la nivelul subformularului AutoriCarti
If Me.AutoriCarti.Form.Recordset.RecordCount = 0 Then MsgBox "Nu au fost specificati autorii! " & vbCrLf & "Inregistrarea nu a fost salvata!", vbCritical Else DoCmd.RunCommand acCmdSaveRecord
' In caseta combinata cboCota sunt actualizate datele privitoare la titlurile disponibile
Me.cboCota.Requery MsgBox "Inregistrarea a fost salvata!", vbInformation End If End Sub
20
Studii de caz
V.b) Realizai un formular pentru consultarea i actualizarea datelor privitoare la mprumuturi. ntruct datele privind mprumuturile trebuie corelate cu cele aferente abonamentelor (valabilitate, numrul maxim de cri ce pot fi mprumutate etc.) i cele legate de crile care fac obiectul mprumuturilor, s-a optat pentru realizarea unui formular cu urmtoarea structur:
Dup cum se poate observa, formularul include un subformular (CartiImprumutate), care permite evidena crilor mprumutate i eventual, restituite. Iat cteva precizri privind soluia prezentat: - Sursa de date (proprietatea Record Source) a formularului este reprezentat de urmtoarea cerere SQL:
SELECT BonImprumut.NrBon, BonImprumut.DataBon, BonImprumut.CodAbonament, DataDebut, Abonament.CodTipAbonament, Abonament.CodAbonat, DenumireTipAbonament, DurataValabilitate, LimitaNrCarti, LimitaDurata, TarifAbonament, NumeAbonat, PrenumeAbonat, DATEADD("m", DurataValabilitate,DataDebut) -1 AS DataExpirare, IIF((LimitaDurata + DataBon)<=DataExpirare, LimitaDurata+DataBon, DataExpirare) AS LimitaRestituire FROM TipAbonament INNER JOIN (Abonat INNER JOIN (Abonament INNER JOIN BonImprumut ON Abonament.CodAbonament = BonImprumut.CodAbonament) ON Abonat.CodAbonat = Abonament.CodAbonat) ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament;
Observaie: Data limit pentru restiturea crilor se determin lund n calcul numrul zilelor de mprumut la care d dreptul tipul de abonament, sau, dac n acest interval abonamentul expir, data limit coincide cu ultima zi de valabilitate a abonamentului.
21
n cazul subformularului, valoarea proprietii Record Source este reprezentat de interogarea urmtoare:
SELECT CarteImprumutata.NrBon, CarteImprumutata.Cota, Titlu, DataRestituire, DataBon + LimitaDurata AS LimitaRestituire, IIF(IIF(ISNULL(DataRestituire), DATE(), DataRestituire) < LimitaRestituire, 0, IIF(ISNULL(DataRestituire), DATE(), DataRestituire) - LimitaRestituire) AS Intarziere FROM TipAbonament INNER JOIN (Carte INNER JOIN ((Abonament INNER JOIN BonImprumut ON Abonament.CodAbonament = BonImprumut.CodAbonament) INNER JOIN CarteImprumutata ON BonImprumut.NrBon = CarteImprumutata.NrBon) ON Carte.Cota = CarteImprumutata.Cota) ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament;
Observaie: Numrul zilelor de ntrziere se calculeaz comparnd data limit la care crile trebuie napoiate bibliotecii cu data restituirii efective, n cazul crilor returnate, sau cu data curent, n cazul celor nerestituite. Sincronizarea dintre sursele de date ale celor dou formulare este realizat pe baza atributului comun NrBon. Drept urmare, n cadrul formularului principal, vor fi setate urmtoarele proprieti ale obiectului subformular CartiImprumutate: - Link Master Fields: NrBon - Link Child Fields: NrBon Dup cum se poate observa, codul abonamentului n baza cruia se efectueaz mprumutul este selectat din lista de valori a unui control ComboBox, cu urmtoarele proprieti: - Control Source: CodAbonament - Row Source Type: Table/Query - Row Source:
SELECT Abonament.CodAbonament, NumeAbonat & " " & PrenumeAbonat AS Titular, LimitaNrCarti - NrCartiNerestituite AS LimitaEfectivaNrCarti FROM Abonat, Abonament, TipAbonament, (SELECT Abonament.CodAbonament, COUNT(CarteImprumutata.Cota) - COUNT(DataRestituire) AS NrCartiNerestituite FROM (Abonament LEFT JOIN BonImprumut ON Abonament.CodAbonament = BonImprumut.CodAbonament) LEFT JOIN CarteImprumutata ON BonImprumut.NrBon = CarteImprumutata.NrBon GROUP BY Abonament.CodAbonament) AS Tmp WHERE Abonat.CodAbonat = Abonament.CodAbonat
22
Studii de caz AND Abonament.CodTipAbonament = TipAbonament.CodTipAbonament AND Tmp.CodAbonament = Abonament.CodAbonament;
Observaie: Interogarea determin numrul crilor ce pot fi mprumutate de abonaii bibliotecii ca diferen ntre numrul maxim de cri asociat abonamentelor pe care le dein i cel al crilor mprumutate i nerestituite. - Procedura asociat evenimentului AfterUpdate: Private Sub CodAbonament_AfterUpdate() txtLimitaEfectivaCarti.Value = _ IIf(CodAbonament.ListIndex > -1, CodAbonament.Column(2, CodAbonament.ListIndex), "") End Sub Observaie: Procedura permite ca n caseta text txtLimitaEfectivaCarti s fie afiat numrul maxim de cri ce pot fi mprumutate. Dup cum s-a artat mai sus, acesat informaie este disponibil la nivelul casetei combinate CodAbonament n coloana LimitaEfectivaNrCarti. Drept urmare, n condiiile n care a codul abonamentului a fost selectat (CodAbonament.ListIndex > -1), din sursa de date a controlului CodAbonament va fi preluat valoarea cu coordonatele reprezentate de rndul corespunztor seleciei curente i coloana cu indexul 2 (LimitaEfectivaNrCarti are numrul de ordine 3, ns indexarea ncepe de la 0). n plus, datorit faptului c formularul are ca surs o interogare, odat cu selectarea codului aferent abonamentului, se actualizeaz n mod automat coninutul tuturor cmpurilor care depind de acesta: DataDebut, CodTipAbonament (i implicit, DenumireTipAbonament, DurataValabilitate, LimitaNrCarti, LimitaDurata i TarifAbonament), CodAbonat (i implicit, NumeAbonat i PrenumeAbonat), DataExpirare, LimitaRestituire. Din acest motiv, toate controalele ce au ca surs cmpurile amintite (proprietatea Control Source) au fost dezactivate, servind doar la afiarea datelor, nu i la editarea acestora (proprietatea Enabled = False). Butoanele de comand au fost realizate prin utilizarea asistentului (wizard) specializat disponibil n MS Access 2007 i, exceptnd butonul cmdSalveaza, au funcii similare celor descrise n cazul cerinei precedente. - Butonul de comand cmdSalveaza permite salvarea modificrilor aduse unui bon de mprumut, lund n calcul resticiile legate de numrul de cri ce pot fi mprumutate i perioada n care poate fi efectuat mprumutul. Procedura asociat evenimentului Click este urmtoarea: Private Sub cmdSalveaza_Click() On Error Resume Next Dim msg_eroare As String
'Se verifica existenta inregistrarilor la nivelul subformularului CartiImprumutate
Dim nr_carti As Byte
23
nr_carti = Me.CartiImprumutate.Form.Recordset.RecordCount If nr_carti = 0 Then msg_eroare = "Nu exista carti imprumutate!" & vbCrLf ElseIf nr_carti > Me.txtLimitaEfectivaCarti Then msg_eroare = "Numarul de carti ce pot fi imprumutate a fost depasit!" & vbCrLf End If If Me.DataBon > Me.DataExpirare Or Me.DataBon < Me.DataDebut Or _ Me.LimitaRestituire > Me.DataExpirare Then _ msg_eroare = msg_eroare & "Perioada de valabilitate abonament depasita!" & vbCrLf If msg_eroare <> "" Then MsgBox msg_eroare & "Inregistrarea nu a fost salvata!", vbCritical Else DoCmd.RunCommand acCmdSaveRecord
'Se actualizeaza numarul max. de carti ce pot fi imprumutate
Me.CodAbonament.Requery MsgBox "Inregistrarea a fost salvata!" End If End Sub La nivelul subformularului, cotele aferente titlurilor ce fac obiectul unui mprumut sunt selectate din lista de valori a unui control ComboBox, cu urmtoarele proprieti: - Control Source: Cota - Row Source Type: Table/Query - Row Source:
SELECT Carte.Cota, Titlu, NrExemplare AS NrTotalExemplare, NrExemplare - COUNT(CarteImprumutata.Cota) AS ExemplareDisponibile FROM Carte LEFT JOIN CarteImprumutata ON Carte.Cota = CarteImprumutata.Cota WHERE DataRestituire IS NULL GROUP BY Carte.Cota, Titlu, NrExemplare HAVING (NrExemplare - COUNT(CarteImprumutata.Cota)) > 0;
Observaie: Interogarea identific titlurile pentru care exist exemplare disponibile pentru mprumut, determinnd totodat i numrul acestora, ca diferen ntre numrul total al exemplarelor aflate n gestiunea bibliotecii i cel al exemplarelor mprumutate i nerestituite.
Studiu individual: S se realizeze formularele (i eventualele subformulare asociate acestora) care ndeplinesc urmtoarele funcii: a) Consultarea i actualizarea tabelei TipAbonament; b) Gestiunea clienilor i a abonamentelor aferente acestora.
24
Studii de caz
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se afieze abonamentele ncheiate ntr-o anumit perioad, ce urmeaz a fi precizat la deschiderea raportului. Datele vor fi prezentate grupat, pe ani, luni, respectiv tipuri de abonamente, determinndu-se totalul ncasrilor i numrul abonamentelor pentru fiecare din nivelurile indicate. ntruct datele necesare rezolvrii acestei cerine se afl nu doar n tabelul Abonament, ci i n tabelele asociate (spre exemplu, numele titularului n tabela Abonat, durata de valabilitate i tariful n tabela TipAbonament etc.), sursa raportului (proprietatea Record Source) este n mod necesar, o interogare, al crei cod SQL este urmtorul:
SELECT TipAbonament.CodTipAbonament, DenumireTipAbonament, DurataValabilitate, TarifAbonament, CodAbonament, [NumeAbonat] & " " & [PrenumeAbonat] AS Titular, DataDebut, DATEADD("m", DurataValabilitate, DataDebut) -1 AS DataExpirare FROM TipAbonament INNER JOIN (Abonat INNER JOIN Abonament ON Abonat.CodAbonat = Abonament.CodAbonat) ON TipAbonament.CodTipAbonament = Abonament.CodTipAbonament WHERE DataDebut BETWEEN [Data Inceput] AND [Data Sfarsit];
Structura raportului, n modul Design, este urmtoarea:
Observaii: Informaiile de detaliu, privitoare la abonamentele propriu-zise, au fost plasate n seciunea Detail, gruparea acestora n vederea prezentrii i centralizrii fiind realizat dup criteriile menionate n cerin: anul, luna i tipul abonamentului. Cele dou expresii centralizatoare, care returneaz returneaz numrul de
25
abonamente i valoarea acestora, sunt incluse n antetul fiecrui grup i n cel al raportului, valorile returnate avnd semnificaii diferite, n funcie de nivelul pe care ne plasm: 1.total lunar pentru un anumit tip de abonament, 2.total lunar general (pentru toate tipurile de abonamente), 3. total anual (pentru toate tipurile de abonamente), 4. total general multianual, aferent perioadei vizate (presupunnd c aceasta acoper mai muli ani), la nivel de raport. Pentru a ataa fiecrui abonament un numr curent, la nivelul grupului de nregistri din care face parte (n funcie de combinaia an + lun + tip de abonament, care i este caracteristic) pentru contolul TextBox ce afieaz acest numr, au fost setate proprietile Control Source (=1) i Running Sum (Over Group). Drept urmare, la nivelul grupului, se calculeaz o sum care, pentru fiecare nregistrare, este incrementat cu 1, astfel c pentru orice abonament, valoarea rezultat va corespunde numrului curent al nregistrrii n cadrul grupului de care aparine. La trecerea la un nou grup de nregistrri (alt tip de abonament, i/sau o alt luna, i/sau un alt an) valoarea aferent numrului curent este resetat i numrtoarea rencepe de la 1. Prin intermediul unor casete text plasate n seciunile de subsol, asociate raportului (Report Footer) i paginii (Page Footer) sunt afiate data la care raportul este consultat, respectiv numrul paginii curente - [Page] - din numrul total de pagini - [Pages]. Dup cum se poate observa, n seciunea Report Header, n expresia ce reprezint sursa de date a controlului TextBox aferent perioadei, au fost utilizai parametrii din interogarea ce st la baza raportului, astfel nct perioada afiat s coincid cu cea la care se refer datele din coninutul raportului. La deschiderea raportului, se solicit specificarea intervalul vizat, prin furnizarea valorilor aferente celor 2 parametrii. Spre exemplu, figura urmtoare prezint coninutul raportului, n cazul n care intereseaz abonamentele emise n perioada 2 februarie 2 mai 2009 (a fost redat partea superioar a primei pagini din raport).
26
Studii de caz
VI.b) S se prezinte situaia fondului de carte de care dispune biblioteca, prin furnizarea datelor de detaliu privind fiecare titlu (cot, titlu, autori, numr exemplare) i determinarea numrului titlurilor i exemplarelor aferente fiecrui gen, edituri, respectiv an de editare. Dei datele necesare rezolvrii cerinei provin din mai multe tabele (Autor, Carte, AutorCarte), sursa raportului (proprietatea Record Source) nu poate fi reprezentat de o interogare ce implic tabelele amintite. Aceasta deoarece, datorit relaiilor dintre tabele (ntre atributul CodAutor i atributul Cota exist o relaie de dependen multipl reciproc), n cazul unei cri cu mai muli autori, aplicarea operatorului INNER JOIN determin rezultate eronate ale centralizrii numrului de titluri, respectiv de exemplare. Din acest considerent, s-a optat pentru o soluie care include un raport principal, a crui surs de date o reprezint tabelul Carte i un subraport, ce are la baz urmtoarea interogare:
SELECT Autor.CodAutor, NumeAutor & " " & PrenumeAutor AS Autor, Cota FROM Autor INNER JOIN AutorCarte ON Autor.CodAutor = AutorCarte.CodAutor;
Utilizarea acestei interogri ca surs a subraportului permite nu doar obinerea datelor necesare, cele despre autori (dac se urmrea exclusiv acest lucru, era suficient s se indice drept surs tabelul Autor), dar i corelarea nregistrrilor din raport cu cele din subraport, cmpul de legtur fiind reprezentat de Cota. Drept urmare, n cadrul raportului principal, vor fi setate urmtoarele proprieti ale obiectului subraport: - Link Master Fields: Cota - Link Child Fields: Cota Figura urmtoare, red structura celor dou rapoarte, n modul Design, precum i relaia dintre acestea.
Observaii: Informaiile de detaliu, privitoare la titlurile disponibile i autorii acestora au fost plasate n seciunea Detail, gruparea acestora n vederea prezentrii i centralizrii fiind realizat dup criteriile menionate n cerin: genul, editura i
27
anul publicrii. Cele dou expresii centralizatoare, care returneaz numrul titlurilor i al exemplarelor, sunt incluse n antetul fiecrui grup i n subsolul raportului, valorile returnate avnd semnificaii diferite, n funcie de nivelul pe care ne plasm: 1.total anual pentru o anumit editur i un anumit gen, 2. total multianual pentru o anumit editur i un anumit gen, 3. total aferent unui anumit gen (fcnd abstracie de editur i an), 4. total general, la nivel de raport. n cadrul subraportului a fost inclus o caset-text ce permite afiarea numrului nregistrrii curente la nivelul sursei de date a subraportului ([CurrentRecord]), astfel c numele autorilor fiecrei cri vor fi precedate de cte un numr de ordine (1,2,3...) Figura urmtoare prezint maniera n care este afiat raportul, atunci cnd este deschis n vederea consultrii sau listrii (a fost redat partea superioar a primei pagini din raport).
Studiu individual: S se realizeze rapoartele (cu eventualele subrapoarte asociate) care permit afiarea urmtoarelor informaii: a) mprumuturile efectuate n baza unui anumit abonament, specificat la deschiderea raportului. b) Crile mprumutate i nerestituite, aferente abonamentelor exprirate; datele vor fi organizate pe abonamente i categorii de abonamente, calculndu-se durata efectiv a ntrzierii (pentru fiecare carte n parte), respectiv durata medie a ntrzierii (la nivel abonament, tip de abonament i pe ansamblu).
28
Studii de caz
O agenie de turism dorete s-i informatizeze activitatea de gestionare a contractelor ncheiate pentru pachetele de servicii pe care le ofer. Turitii sunt persoane fizice care se identific printr-un cod unic, nume prenume, CNP, serie i numr CI, data naterii, telefon, numr paaport. Agenia ofer mai multe categorii de servicii (excursii, cazare, bilete avion); fiecare categorie de servicii include tipuri de servicii (excursii circuit sau sejur; cazare all-inclusive sau demipensiune; bilete avion dus, ntors, dusntors) pentru care se memoreaz un cod unic i denumirea serviciului. Indiferent de natura serviciului, se impune specificarea rii destinaie identificat prin cod i denumire; pentru ara destinaie se precizeaz localitatea destinaie, pentru care se reine codul i numele. Pentru ca oferta s fie ct mai atractiv, agenia acord anumite reduceri n funcie de vrsta turitilor; asfel, pentru turitii care care au vrsta mai mic sau egal cu 12 ani, se acord o reducere de 40% din tariful standard aferent fiecrui serviciu, iar copii care nu au mplinit nc 2 ani beneficiaz de gratuitate. Fiecare prestator de servicii se identific printr-un un cod unic, denumire, numrul de telefon, categoria n care se ncadreaz (companie aerian, firm de transport terestru, unitate cazare). Pentru serviciile prestate, agenia ncheie un contract de care pot beneficia mai multi turiti (de exemplu, o familie). n cadrul contractului, pe lng numrul i data ncheierii acestuia, se precizeaz turistul/turitii beneficiar(i), clauzele contractuale (drepturile/obligaiile prilor contractante), avans-ul, data pn la care se poate achita valoarea integral a contractului, tariful standard aferent serviciului respectiv, data plecrii i data de sosire. Dac turistul renun din vina sa la serviciile care face obiectul respectivului contract, el datoreaz ageniei despgubiri difereniate n funcie de momentul renunrii (mai exact, numrul de zile nainte de data plecrii). Reguli de gestiune: un contract poate avea unul sau mai muli beneficiari (turiti), un turist poate ncheia unul sau mai multe contracte. oricare dintre beneficiarii contractului poate renuna la serviciile contractate la o anumit dat (situaii critice: accidente, boli sau alte motive ntemeiate). un contract conine un singur tip de servicii. o categorie de servicii include mai multe servicii. fiecare serviciu poate fi realizat de mai muli prestatori de servicii. fiecare categorie de prestatori servicii include mai muli prestatori, dar un prestator nu poate s fac parte dect dintr-o singur categorie. fiecare ar destinaie are mai multe localiti.
II
Baz de date pentru evidena contractelor ncheiate de o agenie de turism
29
n cadrul unei localiti se pot presta mai multe servicii, un serviciu poate fi contractat n mai multe localiti.
I. Realizai modelul realizai al bazei de date i implemenai n MS Access Pentru obinerea modelului relaional se parcurg urmtoarele etape: I.a) Inventarierea atributelor Pe baza informaiilor referitoare la activitatea de gestionare a contractelor ncheiate de agenia de turism, se poate ntocmi dicionarul de atribute:
CodTurist, CNPTurist, NumePrenume, SerieNrCI, DataNaterii, TelefonTurist, NrPasaport, CodCategorieServicii, DenumireCategorie, CodServiciu, DenumireServiciu, CodPrestatorServicii, DenumirePrestatorServicii, CodCategoriePrestator, DenumireCategoriePrestator, Codar, Denumirear, CodLocalitate, NumeLocalitate, CodPartener, NrContract, DataIncheiereContract, ClauzeContractuale, Avans, DataLimitaPlataContract, DataAnulareContract, DataPlecare, DataSosire, Tarif, Vrsta, Reducere, Despgubiri, TarifRecalculat, ValoareaTotalContracte.
I.b) Specificarea regulilor de gestiune (sunt prezentate anterior) i precizarea algoritmilor de calcul pentru atributele care pot fi determinate prin calcul: Vrsta (ani) AnulCurent AnulNasterii Reducere: pentru turitii cu vrsta <= 2 ani, reducerea este de 100% (aplicat la tariful standard); pentru turitii cu vrsta > 2 ani <= 12 ani, reducerea este de 40%; pentru turitii cu vrsta > 12 ani, nu se acord reducere. Tarif Recalculat TarifStandard Reducere Despgubiri: 30% din tariful standard, dac renunarea se face cu mai mult de 30 de zile calendaristice nainte de data plecrii; 50% din tariful standard, dac renunarea se face n intervalul 16-30 de zile nainte de data plecrii; 95% din tariful standard, dac renunarea se face ntrun interval mai mic de 16 zile nainte de data plecrii. ValoareaTotalaContracte Suma valoric a fiecrui contract I.c) ntocmirea diionarului de date pe baza urmtoarelor reguli: fiecare atribut este nscris o singur dat
30
Studii de caz
sunt eliminate atributele sinonime (n exemplul prezentat, CodPrestatorServicii i CodPartener sunt sinonime, deci se va reine doar unul dintre acestea CodPrestatorServicii). nu sunt preluate atribute calculate (Vrsta, Reducere, TarifRecalculat, Despagubiri, ValoareaTotalContracte). Dicionar de date (DD)
CodTurist, CNPTurist, NumePrenume, SerieNrCI, DataNaterii, TelefonTurist, NrPasaport, CodCategorieServicii, DenumireCategorie, CodServiciu, DenumireServiciu, CodPrestatorServicii, DenumirePrestatorServicii, CodCategoriePrestator, DenumireCategoriePrestator, Codar, Denumirear, CodLocalitate, NumeLocalitate, NrContract, DataIncheiereContract, ClauzeContractuale, Avans, DataLimitaPlataContract, DataPlecare, DataSosire, Tarif, DataAnulareContract.
I.d) Stabilirea dependenelor funcionale dintre atribute acestea sunt prezentate n mod sintetic prin matricea dependenelor funcionale (forma simplificat dependenele funcionale sunt marcate cu 1, iar cele tranzitive cu 1T). Matricea este prezentat n figura din pagina urmtoare. Observaii: pentru fiecare cheie primar i atributele determinate netranzitiv de aceasta se formeaz o tabel. deoarece un contract poate fi ncheiat pentru mai muli turiti, iar un turist poate s ncheie cu agenia mai multe contracte se apeleaz la un determinant compus format din NrContract i CodTurist care va deveni cheia primar a tabelei ContracteTuriti (obinut datorit dependenelor multiple reciproce dintre cele dou atribute specificate); ntruct oricare dintre beneficiarii contractului poate s renune la serviciul contractat la o anumit dat, pentru atributul izolat DataAnulareContract se asociaz ca determinant cheia compus NrContract i CodTurist. agenia ofer servicii n localiti diferite, iar un serviciu poate fi contractat n mai multe localiti; datorit dependenelor multiple reciproce dintre cele dou atribute se impune crearea unei tabele intermediare care va avea drept cheie primar grupul CodLocalitate i CodServiciu.
31
Matricea dependenelor funcionale
32
Studii de caz
Modelul relaional obinut cu ajutorul matricei dependenelor funcionale este urmtorul:

CategorieServicii(CodCategorieServicii, DenumireCategorie) OfertaServicii(CodServiciu, DenumireServiciu, CodCategorieServicii) CategoriePrestatorServicii(CodCategoriePrestator, DenumireCategoriePrestator) PrestatoriServicii(CodPrestatorServicii, DenumirePrestatorServicii, CodCategoriePrestator,CodServiciu) ara(Codar, Denumirear) Localitate(CodLocalitate, NumeLocalitate, Codar) OferteLocalitati(CodServiciu, CodLocalitate) Contracte(NrContract, DataIncheiereContract, ClauzeContractuale, Avans, DataLimitaPlataContract, DataPlecare, DataSosire, Tarif) Turisti(CodTurist, CNPTurist, NumePrenume, SerieNrCI, DataNaterii, TelefonTurist) ContracteTuristi(NrContract, CodTurist, DataAnulareContract)
Implementarea modeluluiu in Access este prezentat n figura urmtoare:
Studiu individual: Pentru fiecare contract ncheiat, agenia emite o factur pe care se precizeaz numrul acesteia, data emiterii, valoarea, TVA i alte detalii; achitarea facturii se realizeaz printr-un document de plat pe care se regsesc numrul documentului de plat, data, tipul documentului de plat, suma pltit.
Cu un document de plat se poate achita o singur factur, dar o factur poate fi pltit n mod ealonat. Pot exista mai multe documente de plat cu acelai numr, dar de tipuri diferite. Adugai modelului relaional tabelul sau tabelele necesare pentru a permite memorarea datelor aferente achitrii facturilor emise pentru serviciile contractate.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) n cadrul tabelei CategorieServicii, cmpul DenumireCategorie poate lua valorile excursii, bilete avion, cazare. Rezolvarea acestei cerine se poate realiza: fie prin specificarea unei reguli de validare la rubrica Validation Rule din zona de proprieti asociat cmpului respectiv, fia de lucru General:
fie prin definirea unei liste derulante cu valorile respective i selectarea opiunilor corespunztoare n fia Lookup din caseta Field Properties aferent cmpului DenumireCategorie.
II.b) La nivelul tabelei Contracte, data la care se ncheie contractul se consider ca fiind implicit data curent; de asemenea, data limit pn la care se poate realiza achitarea integral a contractului trebuie s fie ulterioar (sau cel mult aceeai) momentului n care s-a ncheiat contractul. n acelai timp, data limit pentru plata contractului trebuie s fie anterioar datei plecrii, fapt care impune definirea unei reguli de validare n caseta de proprieti asociat tabelei Contracte:
34
Studii de caz
: II.c) n tabela Turiti se impun urmtoarele restricii: Cmpul CNPTurist va fi de tip text i va admite obligatoriu 13 caractere numerice (pentru definirea unui ablon de afiare, la rubrica Input Mask se folosete caracterul 0, care impune introducerea unei valori numerice).
Dac turistul nu are nc vrsta de 14 ani, cmpul SerieNrCI va rmne necompletat; n acest context, se verific relaia dintre dou atribute ale tabelei Turiti prin definirea unei reguli de validare la nivel de tabel:
Studiu individual: a) Tipul documentelor de plat pentru achitarea facturilor aferente contractelor ncheiate poate lua valorile: ordin de plat, chitan, foaie de vrsmnt. Data facturii va fi implicit data curent. b) Data plecrii trebuie s fie anterioar datei de sosire; avansul achitat nu poate depi valoarea tarifului standard. c) Suma pltit prin documentul de plat trebuie s fie permanent pozitiv.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze lista prestatorilor de servicii pe care agenia i are parteneri n Spania; fiecare prestator va fi afiat o singur dat, nregistrrile fiind afiate n ordine alfabetic n funcie de numele prestatorilor.
Observaie: fiecare prestator poate s apar n mod repetat n list: agenia poate avea unul sau mai muli parteneri pentru acelai tip de serviciu, dar poate s ncheie mai multe contracte cu acelai prestator n acest caz, prestatorul respectiv de servicii ar fi afiat de mai multe ori n rezultatul interogrii. Pentru eliminarea duplicatelor se impune setarea opiunii Unique Values: Yes n caseta Query Properties. III.b) S se calculeze tariful mediu pe fiecare tip de serviciu pentru care data de plecare a fost o zi de week-end.
36
Studii de caz
Observaie: pentru identificarea zilelor de week-end s-a folosit funcia WEEKDAY(data, paramentru) care returneaz numrul corespunztor fiecrei zile a sptmnii. Argumentul paramentru este o constant a crei valoare difer n raport cu formatul de afiare al datei calendaristice; valorile folosite cel mai frecvent sunt: 1- formatul american, caz n care funcia WEEKDAY returneaz 1 pentru duminc i 7 pentru smbt; 2- formatul european (utilizat i n exemplul curent), variant n care funcia WEEKDAY returneaz 1 pentru luni i 7 pentru duminic. III.c) S se calculeze valoarea total a contractelor pe fiecare tip de serviciu i pe fiecare trimestru al anului 2008; nregistrrile vor fi sortate alfabetic n funcie de numele serviciului prestat.
III.d) S se mreasc cu 10 % tariful serviciilor contractate n anul curent; majorarea opereaz numai pentru serviciile al cror cod va fi specificat de ctre utilizator.
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze categoriile de servicii contractate de agenie n anul 2008; fiecare categorie de servicii va fi afiat o singur dat, nregistrrile fiind ordonate alfabetic n funcie de categoria de servicii.
SELECT DISTINCT CategorieServicii.CodCategorieSevicii, CategorieServicii.DenumireCategorie FROM (CategorieServicii INNER JOIN OfertaSevicii ON CategorieServicii.CodCategorieSevicii = OfertaSevicii.CodCategorieServicii) INNER JOIN Contracte ON OfertaSevicii.CodServiciu = Contracte.CodServiciu WHERE YEAR([DataIncheiereContract]))=2008 ORDER BY CategorieServicii.DenumireCategorie;
Observaie: existena specificatorului DISTINCT n cadrul frazei SELECT se justific prin faptul c pe aceeai categorie de servicii (de exemplu - excursii) se pot afia mai multe nregistrri care se repet n combinaia CodCategorie DenumireCategorie; scopul interogrii este de a afia doar tipurile de categorii de servicii (excursii, bilete avion, cazare). IV.b) S se calculeze i afieze despgubirile percepute de agenie n cazul n care turistul renun din vina sa la serviciile contractate. Agenia aplic penalizri difereniate n funcie de momentul la care care se reziliaz contractul (raportat la data plecrii); astfel: *) 30% din tariful serviciului dac renunarea se face cu mai mult de 30 de zile nainte de data plecrii; *) 50% din tariful serviciului dac renunarea se face n intervalul 16-30 de zile nainte de data plecrii; *) 95% din tariful serviciului dac renunarea se face ntr-un intervalul mai mic de 16 zile nainte de data plecrii.
SELECT ContracteTuristi.CodTurist, Contracte.NrContract, ContracteTuristi.DataAnulareContract, Contracte.DataPlecare, IIF([DataAnulareContract] IS NULL,0, DATEDIFF("d",[DataAnulareContract],[DataPlecare])) AS NrZile, Contracte.Tarif, IIF(NrZile=0,0,IIF(NrZile<=16,Tarif*95/100,IIF(NrZile<=30,Tarif*50/100,Tarif*30/100))) AS Despagubiri FROM Contracte INNER JOIN ContracteTuristi ON Contracte.NrContract = ContracteTuristi.NrContract;
Observaie: funcia DATEDIFF (tip_interval, DataDebut, DataSfrit) returneaz diferena dintre dou date calendaristice, exprimat n intervale de timp prin intermediul unor formate predefinite ( d- zile, m - luni, y - ani). IV.c) S se determine numrul de parteneri (prestatori servicii) pe care i are agenia n fiecare ar; rezultatele vor fi ordonate alfabetic n funcie de ara destinaie.
SELECT Tara.CodTara, Tara.DenumireTara, COUNT(PrestatorServicii.CodPrestatorservicii) AS NrParteneri
38
Studii de caz FROM (OfertaServicii INNER JOIN ((Tara INNER JOIN Localitate ON Tara.CodTara = Localitate.CodTara) INNER JOIN OferteLocalitati ON Localitate.CodLocalitate = OferteLocalitati.CodLocalitate) ON OfertaServicii.CodServiciu = OferteLocalitati.CodServiciu) INNER JOIN PrestatorServicii ON OfertaServicii.CodServiciu = PrestatorServicii.CodServiciu GROUP BY Tara.CodTara, Tara.DenumireTara ORDER BY Tara.DenumireTara;
IV.d) S se calculeze i afieze numrul de turiti de de gen masculin i feminin care au anulat contractele n ultimul an.
SELECT IIF(VAL(LEFT([CNPTurist],1))=1,"M","F") AS Gen, COUNT(ContracteTuristi.CodTurist) AS NrTotalTuristi FROM Turisti INNER JOIN ContracteTuristi ON Turisti.CodTurist=ContracteTuristi.CodTurist WHERE YEAR([DataAnulareContract])>=YEAR(Date())-1 GROUP BY VAL(LEFT([CNPTurist],1));
Observaie: pentru a determina genul turitilor (masculin sau feminin) se aplic funcia LEFT(argument, n) unde n reprezint numrul de caractere care urmeaz a fi extrase ncepnd din partea stng a argumentului specificat (pe exemplul anterior, funcia LEFT se aplic pe cmpul CNPTurist i care are drept efect extragerea primei cifre aferent acestuia). n mod implicit, funciile LEFT, RIGHT, MID returneaz rezultatele sub form de text; pentru convertirea acestora n valori numerice se recomand utilizarea funciei VALUE IV.e) S se afieze primele 3 servicii pentru care tariful standard este mai mare dect media valoric a tarifelor aferente tuturor serviciilor oferite de agenie.
SELECT TOP 3 OfertaSevicii.CodServiciu, OfertaSevicii.DenumireServiciu, Contracte.Tarif FROM OfertaSevicii INNER JOIN Contracte ON OfertaSevicii.CodServiciu=Contracte.CodServiciu WHERE Contracte.Tarif >(Select AVG(Tarif) FROM Contracte) ORDER BY Tarif DESC;
Observaie: afiarea primelor 3 servicii cu tarifele mai mari dect media presupune utilizarea atributului TOP n cadrul frazei SELECT pentru specificaea numrului de elemente i sortarea descresctoare n funcie de Tarif prin ORDER BY. IV.f ) S se afieze lunile din anul 2008 n care agenia a ncheiat mai mult de 3 contracte; rezultatele vor fi ordonate n funcie de luna n care s-a ncheiat contractul.
SELECT MONTH([DataIncheiereContract]) AS Luna, COUNT(NrContract) AS NrTotalContracte FROM Contracte WHERE YEAR([DataIncheiereContract])=2008
GROUP BY MONTH([DataIncheiereContract]) HAVING COUNT(Contracte.NrContract)>3 ORDER BY MONTH([DataIncheiereContract]);
IV.g) S se determine numrul de prestatori care au efectuat servicii pe fiecare categorie de servicii pentru contractele ncheiate n trimestrele 1 i 2 ale anului precedent.
TRANSFORM COUNT(PrestatorServicii.CodPrestatorServicii) AS NrPrestatori SELECT OfertaSevicii.DenumireServiciu FROM ((CategorieServicii INNER JOIN OfertaSevicii ON CategorieServicii.CodCategorieSevicii = OfertaSevicii.CodCategorieServicii) INNER JOIN Contracte ON OfertaSevicii.CodServiciu = Contracte.CodServiciu) INNER JOIN PrestatorServicii ON OfertaSevicii.CodServiciu = PrestatorServicii.CodServiciu WHERE DATEPART("q",[DataIncheiereContract]) IN (1,2) AND YEAR([DataIncheiereContract]) =YEAR(Date())-1 GROUP BY OfertaSevicii.DenumireServiciu PIVOT CategorieServicii.DenumireCategorie;
Observaie: funcia DATEPART(interval, Data_referin) permite extragerea unor intervale de timp dintr-o dat calendaristic prin intermediul unor constante de tip text cu valoare predefinit (d zile, m luni, q trimestre, y ani). IV.h) S se afieze tipurile de servicii care au fost contractate de cele mai multe ori.
SELECT OfertaServicii.CodServiciu, OfertaServicii.DenumireServiciu FROM OfertaServicii INNER JOIN Contracte ON OfertaServicii.CodServiciu = Contracte.CodServiciu GROUP BY OfertaServicii.CodServiciu, OfertaServicii.DenumireServiciu HAVING COUNT(*) = (SELECT TOP 1 COUNT(*) FROM Contracte GROUP BY CodServiciu ORDER BY 1 DESC);
Observaie: Prin intermediul subinterogrii se determin numrul maxim de contracte ncheiate pe diferite tipuri de servicii (cmpul n funcie de care se realizeaz ordonarea nregistrrilor se precizeaz prin poziia pe care o ocup n cadrul frazei SELECT (1) sau prin expresia COUNT(*)), iar la nivelul interogrii principale se identific serviciile care ndeplinesc condiia specificat. IV.i) S se micoreze cu 10% tariful standard aferent contractelor anulate anul trecut.
UPDATE Contracte SET Tarif = Tarif*90/100 WHERE NrContract IN (SELECT NrContract FROM Contracte INNER JOIN ContracteTuristi ON Contracte.NrContract=ContracteTuristi.NrContract WHERE YEAR([ContracteTuristi.DataAnulareContract]) = YEAR(Date())-1);
40
Studii de caz
IV.j) S se tearg din baza de date serviciile care anul trecut au fost contractate de un numr de ori mai mic dect o valoare care va fi precizat de utilizator.
DELETE * FROM OfertaServicii WHERE CodServiciu IN (SELECT CodServiciu FROM OfertaServicii INNER JOIN Contrate ON OfertaServicii.CodServiciu= Contrate.CodServiciu WHERE YEAR([Contract.DataIncheiereContract]) = YEAR(Date())-1 GROUP BY OfertaServicii.CodServiciu HAVING COUNT(Contract.NrContract)<[Introduceti numrul minim]);
Studiu individual: a) S se afieze numele turitilor care au contractat servicii de tip circuit n ultimii 2 ani; datele vor fi ordonate alfabetic n funcie de numele turitilor. b) S se calculeze vrsta fiecrui turist i reducerea acordat de agenie pentru serviciile oferite, tiind c aceasta se determin n mod difereniat, pe categorii de vrst (vezi restriciile specificate n textul problemei). c) S se afieze tariful mediu pe fiecare categorie de servicii contractate n Italia sau Grecia pe fiecare lun a anului precedent. d) S se tearg din baza de date numele unui prestator de servicii pe care agenia l-a avut ca partener n semestrul al II-lea al anului 2008 i al crui cod va fi specificat de utilizator. e) S se mreasc cu 15% tariful aferent serviciului care a fost contractat de cele mai multe ori.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) S se realizeze un formular obinut pe baza tabelei Turisti:
Observaie: Formularul Turisti a fost generat cu ajutorul comenzii Form Wizard, din meniul Create-Forms-More forms, i completat apoi n modul design cu butoane de nchidere a formularului , , butoane butoane de de parcurgere salvare i secvenial . a
nregistrrilor
adugare
nregistrri
i combo box-ul de cutare a turitilor
V.b) Realizai un formular cu subformular pentru gestionarea contractelor ncheiate de agenie:
Observaii: a). Formularul Contracte este un formular complex alctuit dintr-un formular principal i un subformular, sincronizate prin intermediul cmpului NrContract (verificarea se va realiza n proprietile subformularului Link Child Fields i Link Master Fields NrContract). Formularul principal a fost generat pe tabela Contracte, iar subformularul pe baza unei interogri prin intermediul controlului subform n modul design al formularului principal.
42
Studii de caz
Interogarea surs a subformularului s-a realizat pe baza tabelelor Contracte, ContracteTuristi i Turisti cu scopul de a asocia pentru fiecare turist, tariful serviciului n raport cu vrsta acestuia. n acest sens, la nivelul interogrii s-a calculat vrsta fiecrui turist pe baza cmpului Data Nasterii i apoi s-a asociat un tarif recalculat pe baza algoritmului de mai jos (specificat n enunul problemei):
Varsta: Year([DataIncheiereContract])-Year([DataNasterii]) Tarif serviciu recalculat: [Tarif]-IIf([Varsta]<=2; [Tarif]*100/100; IIf([Varsta]<=12; [Tarif]*40/100;0))
b). Formularul Contracte a fost completat cu o linie de Total pentru calculul valorii totale a serviciilor incluse pentru fiecare contract. n acest scop, n subformularul Subformular s-a creat o caset text, creia i s-a atribuit numele TotalTarif, iar pentru proprietatea Control Source s-a specificat formula =Sum([TarifRecalculat]). Ulterior, se revine n formularul principal Contract, unde s-a creat o alt caset text i n caseta de proprieti, la rubrica Control Source se introduce formula:
=[subformular subform].[Form]![TotalTarif].
c). Pentru a preciza semnatarul contractului, pe formularul principal s-a prevzut un combo-box care are ca surs interogarea urmtoare:
Aceast interogare permite alegerea ca semnatar doar a unui turist, dintre toi beneficiarii nscrii pe acel contract. Pentru ca aceast list s fie reactualizat cu turitii afiai pe contractul respectiv s-a prevzut:
Private Sub Form_Current() Me.semnatar.Requery End Sub
Studiu individual: a) S se realizeze un formular pe baza tabelei DocumentPlat. b) S se realizeze un formular cu subformular pentru obinerea unei Facturi.
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: S se realizeze un obiect de tip raport pentru a obine una dintre situaiile de ieire frecvent solicitate la nivelul ageniei: Situaia contractelor ncheiate pe fiecare categorie de servicii n perioada... Sursa raportului este interogarea urmtoare proiectat pentru a cumula toate caracteristicile situaiei de obinut.
Selecia perioadei se face prin intermediul formularului Listare:
44
Studii de caz
Raportul a fost proiectat pentru a furniza informaii detaliate pentru fiecare categorie de servicii oferite de agenie, cu specificarea contractelor ncheiate, a datei de ncheiere pentru fiecare contract i a serviciului prevzut. n acest sens, se impune gruparea informaiilor pe fiecare categorie de servicii, calculndu-se numrul total de contracte ncheiate.
Pentru a se realiza filtrarea informaiilor la nivelul perioadei specificate n formularul Listare, n cadrul raportului s-au setat proprietile:
Filter: DataIncheiereContract between forms!Listare!DataInceput and forms!Listare!DataSfarsit Filter on: yes.
Studiu individual: a) S se realizeze un obiect de tip raport pentru a obine Situaia facturilor ncasate pe luna... b) S se realizeze un obiect de tip raport pentru a obine Situaia contractelor anulate n perioada...
III
Baz de date pentru evidena testrilor la un centru de certificare a aptitudinilor de operare pe calculator
Un centru de certificare a aptitudinilor de operare pe calculator, dorete s i mbunteasc activitatea de gestiune a testrii candidailor. n acest sens, se dorete implementarea unui sistem informatic prin care s se in evidena testrilor programate pentru diferite module, a examinatorilor responsabili pentru fiecare testare, a slilor n care se desfoar testrile, a candidailor nscrii, precum i a rezultatelor obinute de ctre acetia. Modulele vor avea n cadrul sistemului un identificator unic, o denumire i vor fi ncadrate ntr-un anumit nivel de certificare. Programarea testrilor presupune alocarea unui identificator unic al testrii, stabilirea modulului pentru care se face testarea, a datei testrii, a orei de ncepere a testrii, a duratei testrii, a orei de terminare a testrii, a slii n care se va desfura, a tarifului perceput, precum i a examinatorului responsabil pentru testarea respectiv. Centrul dispune de mai multe sli, fiecare avnd un numr unic i un anumit numr de locuri disponibile. Examinatorii au un identificator unic alocat de ctre centru, ce va fi memorat n sistem alturi de numele i prenumele acestora. Pentru fiecare candidat vor fi stocate n sistem date privind: codul numeric personal (CNP), numele i prenumele, seria i numrul crii de identitate, adresa i localitatea. nscrierea la o testare presupune stocarea n baza de date a informaiilor referitoare la testarea pentru care se face nscrierea, data la care se face nscrierea i candidatul nscris. De asemenea, sistemul trebuie s aloce un identificator unic pentru fiecare nscriere. Dup susinerea fiecrei testri i corectarea testelor, se vor stoca n cadrul sistemului rezultatele aferente testrii respective, precizndu-se punctajul obinut de ctre fiecare candidat. Reguli de gestiune: O testare se refer la un singur modul, are repartizat un singur examinator responsabil cu aceasta i este programat ntr-o sal disponibil la data testrii i n intervalul de timp n care se desfoar testarea; Un examinator poate fi responsabil la mai multe testri; O nscriere a unui candidat se refer la o singur testare programat la o dat ulterioar datei de nscriere; Un candidat se poate nscrie la mai multe testri; Pentru o testare nu poate fi nscris un numr de candidai mai mare dect numrul de locuri disponibile n sala n care se desfoar testarea. I. Realizai modelul bazei de date i implementai n MS Access Proiectarea unei baze de date poate fi realizat prin mai multe metode, una dintre acestea fiind obinerea modelului relaional prin normalizare. Pentru ca ntr-o baz de date s nu existe redundan i anomalii (anomalii la adugare, anomalii la modificare
46
Studii de caz
i anomalii la tergere) aceasta trebuie s respecte o serie de reguli, denumite forme normale (FN1, FN2, FN3, FNBC, FN4 i FN5). Pentru obinerea modelului relaional se poate utiliza matricea dependenelor. ntocmirea acesteia presupune parcurgerea urmtoarelor etape: Etapa 1: Stabilirea dicionarului de atribute Din enunul problemei rezult urmtorul dicionar preliminar al atributelor: identificator modul, denumire modul, nivel modul, identificator testare, modul testat, dat testare, or ncepere testare, durat testare, or terminare testare, sal testare, tarif testare, examinator responsabil, numr sal, numr locuri disponibile sal, identificator examinator, nume i prenume examinator, CNP candidat, nume i prenume candidat, serie carte identitate candidat, numr carte identitate candidat, adres candidat, localitate candidat, identificator nscriere, testarea pentru care se face nscrierea, dat nscriere, candidat nscris, punctaj obinut. Pentru obinerea dicionarului atributelor n forma final, din list se vor elimina: Atributele sinonime: modul testat, sal testare, examinator responsabil, testarea pentru care se face nscrierea, candidat nscris. Atributele calculate: or terminare testare. Astfel, se obine urmtorul dicionar final al atributelor: identificator modul, denumire modul, nivel modul, identificator testare, dat testare, or ncepere testare, durat testare, tarif testare, numr sal, numr locuri disponibile sal, identificator examinator, nume i prenume examinator, CNP candidat, nume i prenume candidat, serie carte identitate candidat, numr carte identitate candidat, adres candidat, localitate candidat, identificator nscriere, dat nscriere, punctaj obinut. Etapa 2: Stabilirea cheilor candidate Cheile candidate sunt acele atribute din dicionarul atributelor care au valori unice i nenule. Pentru problema dat, cheile candidate sunt: identificator modul, identificator testare, numr sal, identificator examinator, CNP candidat, identificator nscriere. Etapa 3: Stabilirea cheilor primare Dintre cheile candidate se vor alege cheile primare. n cazul acestui exemplu, toate cheile candidate vor deveni chei primare. Etapa 4: Stabilirea dependenelor La completarea matricei se vor avea n vedere urmtoarele tipuri de dependene ntre cheile primare i celelalte atribute: dependene funcionale (simple) (1) dependene funcionale (simple) tranzitive (1T) dependene multiple (M) Not: Pentru simplificarea modelului nu se vor lua n considerare dependenele pariale i dependene multiple tranzitive.
Etapa 5: Identificarea atributelor izolate i gsirea determinanilor acestora Se identific atributul izolat punctaj obinut. Pentru determinarea acestuia se va forma cheia primara compusa din atributele CNP candidat i identificator testare, deoarece se refer la punctajul obinut de un anumit candidat la o anumit testare. n urma parcurgerii celor 5 etape se obine urmtoarea matrice a dependenelor:
Pe baza matricei dependenelor se vor forma relaiile (tabelele), avnd n vedere urmtoarele reguli: Fiecare cheie primara mpreun cu atributele determinate simplu de ctre aceasta vor forma o relaie. n cazul n care printre aceste atribute se regsete o alt cheie primar, aceasta va fi considerat cheie extern pentru relaia creat. Dependenele multiple reciproce stabilite ntre dou atribute ce reprezint chei primare vor determina formarea unei noi relaii, care va fi identificat printr-o cheie primar compus din cele dou atribute, ce vor fi n acelai timp i chei externe. Modelul relaional al bazei de date este urmtorul:
Candidati (CNP, NumePrenume, SerieCI, NumarCI, Adresa, Localitate) Inscrieri (IDInscriere, DataInscriere, CNP, IDTestare) Rezultate (CNP, IDTestare, PunctajObtinut) Testari (IDTestare, DataTestare, OraIncepereTestare, TarifTestare, IDModul, IDExaminator, NumarSala) Module (IDModul, DenumireModul, NivelModul) Examinatori (IDExaminator, NumePrenumeExaminator) Sali (NumarSala, NumarLocuri) DurataTestare,
48
Studii de caz
Relaiile stabilite ]ntre tabelele din baza de date Access sunt prezentate n figura urmtoare:
Studiu individual: Pentru ca un candidat sa poat fi nscris la o testare, acesta trebuie s achite n prealabil tariful corespunztor testrii respective. Achitarea tarifului se face pe baza unei chitane ce are un numr unic, o dat i o sum. Printr-o chitan se achit tariful corespunztor unei singure nscrieri, pentru un singur candidat. Completai modelul relaional prin adugarea tabelului necesar achitrii taxei de nscriere i stabilii legturile dintre acesta i celelalte tabele ale modelului.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Durata testrii se va selecta dintr-o list cu elementele: 2 ore i 3 ore. Rezolvare: Pentru cmpul DurataTestare se va alege tipul de date Number. Pentru stabilirea formatului de afiare n ore i crearea listei se vor modifica urmtoarele proprieti ale cmpului: Categoria General: Format: # ore Categoria Lookup: Display control: Combo Box Row source type: Value List Row source: 2;3 Limit to list: Yes
II.b) Definii un ablon de introducere a seriei crii de identitate a candidatului astfel nct s fie acceptat doar introducerea a dou litere obligatorii, ce vor fi formatate n vederea afirii sub form de majuscule. Completarea acestui cmp este obligatorie la introducerea datelor n tabelul Candidati. Rezolvare: Cmpului SerieCI i va corespunde tipul de date Text i se vor stabili urmtoarele proprietile: Categoria General: Format: > Input Mask: LL Required: Yes Semnul > utilizat la proprietatea Format convertete caracterele introduse n majuscule, iar caracterul L nlocuiete o liter obligatorie. II.c) Pentru data de nscriere a candidailor se va utiliza data curent drept valoare implicit. Rezolvare: Datei de nscriere i corespunde tipul de date Date/Time. Pentru atribuirea datei curente ca valoare implicit se modific urmtoarea proprietate a cmpului: Categoria General: Default value: Date() II.d) Cheia extern IDModul din cadrul tabelului Testri trebuie s aib ca surs nregistrrile corespunztoare din tabelul Module (n care acest cmp este cheie primar). Rezolvare: Pentru cmpul IDModul, din tabelul Testri, se alege tipul de date Number i se stabilesc urmtoarele proprieti: Categoria Lookup: Display control: Combo Box Row source type: Table/Query Row source: SELECT IDModul, DenumireModul, NivelModul FROM Module ORDER BY IDModul; Column count: 3 Column widths: 0cm;2,54cm;2,54cm Limit to list: Yes Dimensiunea primei coloane este de 0 cm, deoarece se dorete afiarea n list doar a celorlalte dou coloane (DenumireModul i NivelModul).
50
Studii de caz
Studiu individual: a) S se defineasc un ablon de introducere a CNP-ului candidailor, care s permit doar introducerea a 13 cifre obligatorii. b) Punctajul obinut de candidai este cuprins ntre 0 i 100 puncte. c) Nivelul modului se selecteaz dintr-o list cu elementele: nceptori, avansai.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze, n ordinea punctajelor obinute, o list a candidailor promovai i nepromovai la o anumit testare. Un candidat este considerat promovat dac a obinut un punctaj de minim 80 puncte.
III.b) S se creeze o interogare care s afieze o list a cursanilor care au promovat testele susinute la un anumit modul, ntr-un anumit trimestru al anului curent. Denumirea modulului i numrul trimestrului se vor introduce la rularea interogrii. Un test se consider promovat dac s-a obinut un punctaj de minim 80 puncte.
III.c) S se mreasc cu 20% tariful de testare perceput pentru toate testrile programate dup data curent, la modulele Excel 2 i Access 2, n zile de week-end.
Aceast cerere este o interogare de actualizare. La crearea sa, se apas butonul Update , care afieaz rndul Update to, in cadrul grilei QBE. Pentru aflarea zilei din sptmn corespunztoare datei testrii se folosete funcia Weekday. S-a utilizat, drept al doilea argument al funciei, tipul 2- conform cruia ziua 1 este considerat ziua de luni i ziua 7 cea de duminic. III.d) S se afieze modulele pentru care sunt programate testri pentru urmtoarea lun, pe sli, pe date i pe ore.
IIf(Month(Date())=12;1;Month(Date())+1) IIf(Month(Date())=12;Year(Date())+1;Year(Date()))
52
Studii de caz
Pentru rezolvarea acestei cerine se poate crea o interogare de tip tabel ncruciat, cu urmtoarea structur: Antet de rnd data i ora de ncepere a testrii Antet de coloan numrul slii Coninut tabel denumirea modului. Crearea unei astfel de interogri presupune apsarea butonului , care afieaz dou noi rnduri n grila QBE: Total i Crosstab. Pentru afiarea rezultatelor doar pentru luna urmtoare se adaug urmtoarele condiii: Luna testrii trebuie s fie egal cu luna curent + 1. n cazul n care luna curent este decembrie (12), luna urmtoare este considerat luna ianuarie (1). Anul testrii trebuie s fie egal cu anul curent, cu excepia cazului n care luna curent este decembrie (12), cnd anul testrii va fi egal cu anul curent + 1.
Studiu individual: a) S se afieze testrile programate pentru module de nivel avansai, n zile de weekend, n lunile martie, iunie i septembrie ale anului curent. b) S se afieze pentru un examinator (al crui identificator este introdus la rularea interogrii) numrul fiecrei sli la care are programate testri n urmtoarea lun. Rezultatul va fi afiat sub form de tabel ncruciat (crosstab), lund n considerare data testrii, ora de nceput a testrii i denumirea modulului pentru care este organizat testarea. c) S se afieze punctajul minim, punctajul maxim i media punctajelor obinute de ctre cursani pentru fiecare testare organizat n ultima jumtate a anului precedent.
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze pentru un candidat (al crui CNP se introduce la rularea interogrii) o list a modulelor pentru care a obinut punctaj de promovare la testrile susinute. Promovarea unui test presupune obinerea a minim 80 puncte.
SELECT Module.DenumireModul, Rezultate.PunctajObtinut FROM ([Module] INNER JOIN Testari ON Module.IDModul = Testari.IDModul) INNER JOIN (Candidati INNER JOIN Rezultate ON Candidati.CNP = Rezultate.CNP) ON Testari.IDTestare = Rezultate.IDTestare WHERE Candidati.CNP=[Introduceti CNP-ul candidatului] AND Rezultate.PunctajObtinut>=80;
IV.b) S se afieze modulele pentru care nu s-a organizat nici o testare.

SELECT Module.IDModul, Module.DenumireModul, Module.NivelModul FROM [Module] LEFT JOIN Testari ON Module.IDModul=Testari.IDModul WHERE Testari.IDModul IS NULL;
IV.c) S se afieze toate modulele de nivel avansai, pentru care au fost organizate mai mult de 30 de testri, n anii 2007 i 2008.
SELECT Module.DenumireModul, Count([IDTestare]) AS NumarTestari FROM [Module] LEFT JOIN Testari ON Module.IDModul=Testari.IDModul WHERE Module.NivelModul="avansati" AND Year([DataTestare]) In (2007,2008) GROUP BY Module.DenumireModul HAVING Count([IDTestare])>30;
IV.d) S se tearg testrile programate la date anterioare datei curente, dar care nu au avut loc efectiv deoarece nu s-a nscris nici un cursant.
DELETE * FROM Testari WHERE [DataTestare]<Date() AND IDTestare NOT IN (SELECT Inscrieri.IDTestare FROM Testari INNER JOIN Inscrieri ON Testari.IDTestare = Inscrieri.IDTestare);
IV.e) S se afieze primii 10 candidai nscrii la testri n prima lun a anului curent. n cazul n care un candidat s-a nscris la mai multe module, numele acestuia va aprea o singur dat pe list.
SELECT DISTINCT TOP 10 Candidati.CNP, Candidati.NumePrenume FROM Candidati INNER JOIN Inscrieri ON Candidati.CNP=Inscrieri.CNP WHERE (((Month([DataInscriere]))=1) AND ((Year([DataInscriere]))=Year(Date())));
IV.f ) S se afieze numrul de candidai nscrii pe module, n fiecare an, din anul 2005 pn n prezent. Modulele vor fi grupate pe nivele, afindu-se mai nti cele corespunztoare nivelului nceptori.
TRANSFORM Count(Candidati.CNP) AS NumarCandidati SELECT Module.NivelModul, Module.DenumireModul FROM ([Module] INNER JOIN Testari ON Module.IDModul = Testari.IDModul) INNER JOIN (Candidati INNER JOIN Inscrieri ON Candidati.CNP = Inscrieri.CNP) ON Testari.IDTestare = Inscrieri.IDTestare WHERE Year([DataTestare]) Between 2005 And Year(Date()) GROUP BY Module.NivelModul, Module.DenumireModul ORDER BY Module.NivelModul DESC PIVOT Year([DataTestare]);
IV.g) S se creez un tabel numit ArhivaTestari, care s cuprind detalii privind testrile care au fost organizate pn n anul precedent.
SELECT Testari.IDTestare, Testari.DataTestare, Testari.OraIncepereTestare, Testari.DurataTestare, Testari.TarifTestare, Testari.IDModul, Module.DenumireModul, Module.NivelModul, Testari.IDExaminator, Examinatori.NumePrenumeExaminator, Testari.NumarSala, Sali.NumarLocuri INTO ArhivaTestari
54
Studii de caz FROM Sali INNER JOIN ([Module] INNER JOIN (Examinatori INNER JOIN Testari ON Examinatori.IDExaminator = Testari.IDExaminator) ON Module.IDModul = Testari.IDModul) ON Sali.NumarSala = Testari.NumarSala WHERE Year([DataTestare])<=Year(Date())-1;
IV.h) S se adauge n tabelul ArhivaTestari (creat la punctul anterior) toate testrile organizate n primul trimestru al anului curent.
INSERT INTO ArhivaTestari ( IDTestare, DataTestare, OraIncepereTestare, DurataTestare, TarifTestare, IDModul, DenumireModul, NivelModul, IDExaminator, NumePrenumeExaminator, NumarSala, NumarLocuri ) SELECT Testari.IDTestare, Testari.DataTestare, Testari.OraIncepereTestare, Testari.DurataTestare, Testari.TarifTestare, Testari.IDModul, Module.DenumireModul, Module.NivelModul, Testari.IDExaminator, Examinatori.NumePrenumeExaminator, Testari.NumarSala, Sali.NumarLocuri FROM Sali INNER JOIN ([Module] INNER JOIN (Examinatori INNER JOIN Testari ON Examinatori.IDExaminator = Testari.IDExaminator) ON Module.IDModul = Testari.IDModul) ON Sali.NumarSala = Testari.NumarSala WHERE Year([DataTestare])=Year(Date()) AND DatePart("q",[DataTestare])=1;
IV.i) S se afieze denumirea modulului la care s-au nscris cei mai muli candidai.
SELECT Module.DenumireModul, Count(Candidati.CNP) AS NrCandidatiInscrisi FROM Candidati INNER JOIN (([Module] INNER JOIN Testari ON Module.IDModul=Testari.IDModul) INNER JOIN Inscrieri ON Testari.IDTestare=Inscrieri.IDTestare) ON Candidati.CNP=Inscrieri.CNP GROUP BY Module.DenumireModul HAVING Count(Candidati.CNP)>=ALL (SELECT Count(Candidati.CNP) FROM Candidati INNER JOIN (([Module] INNER JOIN Testari ON Module.IDModul = Testari.IDModul) INNER JOIN Inscrieri ON Testari.IDTestare = Inscrieri.IDTestare) ON Candidati.CNP = Inscrieri.CNP GROUP BY Module.DenumireModul);
IV.j) S se micoreze cu 15% tariful perceput pentru testrile programate n urmtoarea perioad, la care s-a nscris un numr de candidai mai mic dect jumtate din numrul de locuri disponibile n slile n care acestea sunt organizate.
UPDATE Testari SET TarifTestare = [TarifTestare]*85/100 WHERE [DataTestare]>Date() AND IDTestare IN (SELECT Testari.IDTestare FROM Testari LEFT JOIN Inscrieri ON Testari.IDTestare = Inscrieri.IDTestare GROUP BY Testari.IDTestare HAVING Count(Inscrieri.IdInscriere)<=ALL (SELECT [NumarLocuri]/2 As JumatateLocuriSala FROM Sali INNER JOIN (Testari LEFT JOIN Inscrieri ON Testari.IDTestare = Inscrieri.IDTestare) ON Sali.NumarSala = Testari.NumarSala));
Studiu individual: a) S se afieze numrul de testri la care a fost responsabil fiecare examinator al centrului, n ultimul trimestru al anului precedent. b) S se afieze o list a slilor n care nu a fost organizat nici o testare. c) S se afieze detalii privind candidatul care s-a nscris la cele mai multe testri. d) S se tearg testrile programate n urmtoarea lun, la care s-a nscris un numr de candidai mai mic de 5. e) S se creeze un nou tabel, numit DetaliiCandidati, care s cuprind suplimentar fa de datele preluate din tabelul Candidati, informaii privind data naterii i vrsta fiecrui candidat.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular care s permit nscrierea candidailor la testrile programate pentru diferite module. n cadrul formularului creat pentru rezolvarea acestei cerine se selecteaz din lista Denumirea modului pentru care se face nscrierea i se apas butonul Afiare testri programate, care afieaz ntro list toate testrile programate pentru urmtoarea perioad, pentru modulul selectat anterior, la care mai sunt locuri disponibile (numrul de candidai nscrii la o testare nu trebuie s depeasc numrul de locuri din sala n care se desfoar). Se selecteaz din list testarea la care dorete candidatul s se nscrie i se apas butonul Fi nscriere, ceea ce va conduce la afiarea cmpurilor ce trebuie completate pentru nregistrarea propriu-zis a nscrierii n baza de date.
56
Studii de caz
n cadrul fiei de nscriere este necesar doar completarea CNP-ului candidatului, celelalte cmpuri fiind completate automat astfel: data nscrierii va fi considerat data curent, numele candidatului va fi preluat din tabelul Candidai n funcie de CNP, iar ID testare va fi preluat de la testarea selectat n lista testrilor programate. n cazul n care candidatul nu se afl n baza de date a centrului de testare, acesta poate fi nregistrat prin apsarea butonului Adaug candidat, ce deschide un formular (prezentat la punctul V.b.) ce permite introducerea datelor acestuia. Dup completarea fiei de nscriere se apas butonul Salvare nscriere, pentru salvarea acesteia n baza de date. Formularul de nscriere va fi nchis prin apsarea butonului nchidere formular. Pentru realizarea acestui formular din meniul Create se alege opiunea Form Design, dup care se salveaz noul formular sub denumirea frmInscriere. Din categoria Form Design Tools, se utilizeaz urmtoarele butoane pentru adugarea controalelor pe formular: - Caset text (Text Box) - Buton de comand (Button) - Caset combinat (Combo Box) - List derulant (List Box) Utiliznd butonul Property Sheet se afieaz lista de proprieti. Pentru controalele adugate pe formularul de nscriere a candidailor se stabilesc proprietile prezentate n tabelul de mai jos. Pentru formular se vor modifica proprietile: Caption: Formular inscriere candidati Record Selectors: No Navigation Buttons: No Close Button: No On Load: Cod VBA 1 Not: Codurile VBA i interogrile utilizate drept surs pentru formular i pentru unele controale, vor fi prezentate dup tabelul de proprieti.
Control
Proprieti Name: cboDenumireModul Row source: SELECT IDModul, DenumireModul, NivelModul FROM Module ORDER BY DenumireModul Row source type: Table/Query Limit to list: Yes Column count: 3 Column widths: 0cm;2,544cm;2,501cm Controlul are drept surs cmpurile din tabelul Module. Name: cmdAfisareTestariProgramate Caption: Afisare testari programate On click: Event procedure -> Cod VBA 2 Name: lstTestariProgramate Row source: TestariProgramate Row source type: Table/Query Limit to list: Yes Column count: 5 Column Heads: yes Column widths: 2cm;2,507cm;3,501cm;2,507cm;2cm Lista derulanta are drept surs interogarea TestariProgramate. Name: cmdFisaInscriere Caption: Fisa inscriere On click: Event procedure -> Cod VBA 3 Name: txtDataInscriere DefaultValue: Date() Enabled: No La aceast rubric va fi afiata n mod implicit data curent, utilizatorul neputnd edita acest cmp. Name: cboCNP Row source: SELECT [Candidati].[CNP] FROM Candidati; Row source type: Table/Query Limit to list: Yes Column count: 1
Tip control: Combo Box
Tip control: Button
Tip control: List Box
Tip control: Button
Tip control: Text Box
Tip control: Combo Box
58
Studii de caz
Tip control: Button
Tip control: Button
Column widths: 2,54cm On change: Event procedure -> Cod VBA 4 On got focus: Event procedure -> Cod VBA 5 Controlul utilizeaz ca surs cmpul CNP din tabelul Candidai. La modificarea cmpului (evenimentul Change) este definit o procedur care s actualizeze numele candidatului n formular, n funcie de noul CNP selectat. La accesarea cmpului (evenimentul Got focus) este definit o procedur care actualizeaz elementele din list, n cazul n care a fost adugat un nou candidat n baza de date, utiliznd butonul Adaugare candidat. Name: cmdAdaugareCandidat Caption: Adaugare candidat On click: Event procedure -> Cod VBA 6 Name: txtDataInscriere Control source: =DLookUp("[NumePrenume]";"Candidati";"[CNP] =" & "[Forms]![frmInscriere]![cboCNP]") Enabled: No Funcia DlookUp preia numele i prenumele candidatului din tabelul Candidati, n funcie de CNP-ul selectat n formular la rubrica CNP candidat. Utilizatorul nu poate modifica coninutul acestui cmp. Name: txtIDTestare Enabled: No Valoarea acestui cmp este atribuit n mod automat la apsarea butonului Fisa Inscrirere, fiind preluat identificatorul testrii selectate n lista testrilor programate. Utilizatorul nu poate modifica coninutul acestui cmp. Name: cmdSalvareInscriere Caption: Salvare inscriere On click: Event procedure -> Cod VBA 7
Tip control: Button
Name: cmdInchidereFormular Caption: Inchidere formular On click: Macro pentru nchidere formular Pentru ataarea macrocomenzii pentru nchiderea formularului se executa click mouse dreapta pe buton, se alege Build Event -> Macro Builder: Action: Close Arguments: Form; frmInscriere; Yes
Cod VBA 1: La ncrcarea formularului frmInscrieri (evenimentul On Load), controalele aferente fiei de nscriere nu trebuie s fie vizibile, deoarece nainte de completarea acestora este necesar selectarea testrii pentru care se face nscrierea. Astfel, este necesar definirea urmtoarei proceduri VBA:
Private Sub Form_Load() txtDataInscirere.Visible = False cbocnp.Visible = False txtNumePrenume.Visible = False txtIDTestare.Visible = False cmdSalvareInscriere.Visible = False cmdAdaugareCandidat.Visible = False End Sub
Cod VBA 2: La apsarea butonului Afiare testri programate (evenimentul On Click) se vor afia testrile programate pentru modulul selectat la rubrica Denumire modul. n cazul n care nu a fost selectat nici un modul, se va afia mesajul "Selectai denumirea modulului!". Procedura aferent acestui eveniment este urmtoarea: Private Sub cmdAfisareTestariProgramate_Click() If cboDenumireModul.listindex = -1 Then MsgBox "Selectati denumirea modulului!" Else lstTestariProgramate.Requery End If End Sub Pentru afiarea testrilor programate n cadrul listei lstTestariProgramate, se utilizeaz drept surs a acesteia interogarea TestariProgramate. Aceast interogare returneaz detalii privind testrile programate la o dat ulterioar datei curente, pentru modulul selectat la rubrica Denumire modul, la care mai exist locuri disponibile (numrul cursanilor nscrii pn la momentul respectiv este mai mic dect numrul locurilor din sala n care se desfoar testarea).
60
Studii de caz
Interogarea TestariProgramate are urmtorul coninut:

SELECT Testari.IDTestare, Testari.DataTestare, Testari.OraIncepereTestare, Testari.DurataTestare, Testari.TarifTestare, Testari.IDModul, [Numar locuri disponibile la fiecare testare].NumarLocuriDisponibile FROM Testari INNER JOIN [Numar locuri disponibile la fiecare testare] ON Testari.IDTestare = [Numar locuri disponibile la fiecare testare].IDTestare WHERE (((Testari.DataTestare)>Date()) AND ((Testari.IDModul)=[Forms]![frmInscriere]![cboDenumireModul].[value]) AND (([Numar locuri disponibile la fiecare testare].NumarLocuriDisponibile)>0));
n cadrul acestei interogri au fost utilizate rezultatele unei alte interogri - Numar locuri disponibile la fiecare testare, care calculeaz numrul de locuri care au rmas disponibile pentru fiecare testare programat:
SELECT Testari.IDTestare, Count(Inscrieri.IDInscriere) AS NumarCandidatiInscrisi, Sali.NumarLocuri, [NumarLocuri]-[NumarCandidatiInscrisi] AS NumarLocuriDisponibile FROM (Sali INNER JOIN Testari ON Sali.NumarSala = Testari.IDSala) LEFT JOIN Inscrieri ON Testari.IDTestare = Inscrieri.IDTestare GROUP BY Testari.IDTestare, Sali.NumarLocuri;
Cod VBA 3: Butonul Fisa Inscriere va afia la executarea evenimentului Click controalele aferente fiei de nscriere, prelund la rubrica ID Testare identificatorul testrii selectate anterior din lista testrilor programate. n cazul n care nu a fost selectat nici o testare din list se afieaz mesajul "Selectai o testare din lista!".
Private Sub cmdFisaInscriere_Click()
se verific dac a fost selectat o testare din lista lstTestariProgramate
If lstTestariProgramate.ItemsSelected.Count = 0 Then MsgBox "Selectati o testare din lista!" Else

se atribuie casetei text txtIDTestare, id-ul testarii selectate in lista lstTestariProgramate
Dim Item As Variant Set Item = lstTestariProgramate.ItemsSelected txtIDTestare = lstTestariProgramate.Column(0, Item)

se afieaz controalele aferente fiei de nscriere
txtDataInscirere.Visible = True cbocnp.Visible = True txtNumePrenume.Visible = True txtIDTestare.Visible = True cmdSalvareInscriere.Visible = True cmdAdaugareCandidat.Visible = True End If End Sub
Cod VBA 4: La completarea fiei de nscriere, n situaia n care candidatul exist n baza de date, CNP-ul acestuia se va selecta din list la rubrica CNP candidat. n caz contrar, se va utiliza butonul Adaugare candidat, pentru adaugarea acestuia n baza de date i apoi se va selecta CNP-ul din list. n funcie de CNP-ul selectat se vor afia numele i prenumele candidatului la rubrica Nume candidat. La modificarea CNPului, trebuie s se realizeze i modificarea numelui i prenumelui aferente candidatului respectiv. Din acest motiv este necesar definirea urmtoarei proceduri la evenimentul On Change aferent controlului cboCNP:
Private Sub cboCNP_Change() txtNumePrenume.Requery End Sub
Cod VBA 5: n cazul n care s-a utilizat butonul Adaugare candidat pentru adugarea unui nou candidat n baza de date, la revenirea n formularul de nscriere este necesar actualizarea listei CNP-urilor cnd aceasta este accesat. Astfel, va fi definit urmtoarea procedur pentru evenimentul On Got focus aferent controlului cboCNP:
Private Sub cboCNP_GotFocus() cbocnp.Requery End Sub
Cod VBA 6: Butonul Adaugare candidat are ataat codul VBA pentru deschiderea formularului frmCandidati, utilizat pentru introducerea unui candidat n baza de date. Formularul va fi deschis n modul acFormAdd, care permite doar introducerea unui nou candidat n baza de date, nu i modificarea celor existeni.
Private Sub cmdAdaugareCandidat_Click() DoCmd.OpenForm "frmAdaugareCandidat", acNormal, , , acFormAdd End Sub
Cod VBA 7: Salvarea nscrierii n baza de date se face prin apsarea butonului Salvare nscriere. n cazul n care nu a fost completat CNP-ul candidatului, sistemul afieaz un mesaj de atenionare.
Private Sub cmdSalvareInscriere_Click()
se verific dac a fost completat CNP-ul
If cbocnp.listindex = -1 Then MsgBox "Completati CNP-ul candidatului!" Else Dim setul As Recordset declarare recordset Set setul = CurrentDb().OpenRecordset("Inscrieri", dbOpenTable)
se adaug coninutul controalelor de pe formular n cmpurile tabelei Inscrieri
setul.AddNew setul!CNP = cbocnp.Value setul!idtestare = txtIDTestare.Value setul.Update
62 MsgBox "Inscriere efectuata" End If End Sub
Studii de caz
V.b) Realizai un formular care s permit adugarea unui nou candidat n baza de date. Acest formular se va deschide la apsarea butonului Adugare client din cadrul formularului de nscriere a candidailor pentru susinerea unei testri (prezentat la punctul anterior). Afiai n acest formular, suplimentar fa de datele candidatului, data naterii i vrsta acestuia, n funcie de codul numeric personal. Pentru rezolvarea acestei cerine poate fi creat un formular ale crui cmpuri s fie legate la cmpurile din tabelul Candidati. Crearea formularului poate fi realizat fie n modul Form Design, fie utiliznd instrumentul Wizard. Astfel, formularul va cuprinde casete text pentru introducerea urmtoarelor date ale candidatului: CNP, nume i prenume, serie carte identitate, numr carte identitate, adres i localitate. Suplimentar se vor adaug dou casete text n care vor fi afiate data naterii i vrsta candidatului, precum si un buton Revenire, ce nchide acest formular, permind revenirea la formularul de nscriere a candidatului pentru susinerea unei testri.
Data naterii se obine extrgnd din CNP: Ziua naterii Luna naterii Anul naterii
Vrsta se calculeaz ca diferen ntre data curent i data naterii.
nchide formularul
Control Proprieti Name: txtDataNasterii Control Source: Tip control: Text Box
=IIf(IsNull([cnp]);"";DateValue(Mid([cnp];4;2) & "." & Mid([cnp];6;2) & "." & (Switch(Mid([cnp];1;1)=1;19;Mid([cnp];1;1)=2;19;Mi d([cnp];1;1)=5;20;Mid([cnp];1;1)=6;20) & Mid([cnp];2;2))))
Enable: No
Name: txtVarsta Control Source: Tip control: Text Box
=IIf(IsNull([cnp]);"";Int((Now()[txtDataNasterii])/365,25) & " ani")
Tip control: Button
Enable: No Name: cmdRevenire Caption: Revenire On click: Macro pentru nchidere formular Pentru ataarea macrocomenzii pentru nchiderea formularului se executa click mouse dreapta pe buton, se alege Build Event -> Macro Builder: Action: Close Arguments: Form; frmAdaugareCandidat; Yes
La obinerea datei de natere din CNP s-au folosit urmtoarele funcii: DateValue convertete un ir de caractere reprezentnd luna, ziua i anul, pentru obinerea unei date calendaristice. Aceste iruri de caractere trebuie s fie separate de un simbol valid pentru formatul de dat. Mid extrage o anumit parte dintr-un ir de caractere. Argumentele funciei sunt: irul de caractere din care se face extragerea valoarea poziional a caracterului de la care se ncepe extragerea numrul de caractere de extras Switch evalueaz o lis de expresii i returneaz o valoare sau o expresie asociat cu prima expresie din list care este adevrat. Argumentele funciei sunt perechi formate din expresii i valori. Expresiile sunt evaluate de la stnga la dreapta. Funcia va returna valoarea asociat cu prima expresie care este evaluat ca fiind adevrat. La obinerea anului naterii se ia n considerare prima cifr a CNP-ului, dup cum urmeaz:

1 / 2 data naterii cuprins ntre 1 ianuarie 1900 i 31 decembrie 1999 3 / 4 - data naterii cuprins ntre 1 ianuarie 1800 i 31 decembrie 1899 5 / 6 - data naterii cuprins ntre 1 ianuarie 2000 i 31 decembrie 2099
Pentru a evita afiarea unei erori n casetele text aferente datei naterii i vrstei, n cazul n care CNP-ul nu este nc completat, se utilizeaz funciile IIf i IsNull. Studiu individual: a) Realizai un formular care s permit adugarea unei noi testri n baza de date. La planificarea slii se va avea n vedere faptul c aceasta trebuie s fie disponibil la data i n intervalul de timp pentru care este programat testarea. b) Realizai un formular destinat introducerii punctajelor obinute de ctre fiecare candidat la o anumit testare.
64
Studii de caz
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se creeze un raport care s afieze detalii privind testrile programate, pe fiecare modul, ntr-o anumit perioad (ce se va introduce intr-un formular nainte de deschiderea raportului).
Rezolvare: Pentru crearea raportului din meniul Create se alege opiunea Report Wizard. Sursa raportului este constituit din cmpuri aparinnd mai multor tabele, dup cum urmeaz:
Tabelul Module: DenumireModul, NivelModul Tabelul Testari: DataTestare, OraIncepereTestare, DurataTestare, TarifTestare, NumarSala Se va alege opiunea de vizualizare a datelor n funcie de Module (by Module) i se va face o sortare a acestora dup cmpul DataTestare, ascendent.
Dup creare, raportul se deschide n modul Design View i se efectueaz urmtoarele modificri ale acestuia:
n antetul raportului (Report Header) se adaug dou controale de tip Text Box pentru afiarea perioadei pentru care se ntocmete: Proprieti Name: txtInceputPerioada Control Source:
=[Forms]![frmPerioada]![txtDataInceput]
Element afiat Data nceput perioada
Enable: No Data sfrit perioada Name: txtSfarsitPerioada Control Source: =[Forms]![frmPerioada]![txtDataSfarsit]
Sursa controalelor o reprezint datele calendaristice introduse n formularul frmPerioada, n casetele text txtDataInceput i txtDataSfarsit, nainte de deschiderea raportului. Pentru ca raportul creat s afieze doar informaii privind testrile programate n perioada introdus n formularul frmPerioada, nainte de deschiderea raportului, este necesar adugarea urmtorului filtru:
66
Studii de caz
Pentru calcularea orei de terminare a testrii, n seciunea Detail a raportului, se adaug un control de tip Text Box, cu urmtoarea surs (proprietatea Control Source): =Format([OraIncepereTestare]-[DurataTestare];"Short Time") Afiarea numrului de testri programate pentru fiecare modul, se face adugnd n subsolul gruprii IDModul (seciunea IDModul Footer) a unui control de tip Text Box. Sursa pentru acest control este urmtoarea: ="Numar testari programate pentru modulul " & [DenumireModul] & ", " & "nivel " & [NivelModul] & ": " & Count([DenumireModul]) i selectnd Afiarea subsolului gruprii IDModul se face apsnd butonul oiunea with a footer section, din cadrul fereastrei Group, Sort, and Total.
La sfritul raportului va fi afiat numrul total de testri programate. Pentru realizarea acestei cerine, se creeaz un control de tip Text Box n subsolul raportului (seciunea Report Footer), cu urmtoarea surs:
="Numar total testari programate in perioada " & [txtInceputPerioada] & " - " & [txtSfarsitPerioada] & ": " & Count([DenumireModul])
VI.b) S se creeze un raport pentru afiarea rezultatelor obinute de ctre candidai la o anumit testare, ce se va selecta dintr-o list nainte de deschiderea raportului. n funcie de punctajul obinut se va afia calificativul corespunztor astfel: punctaj < 80 puncte: calificativul nepromovat punctaj >= 80 puncte: calificativul promovat Rezultatele vor fi afiate n ordine descresctoare a punctajelor, iar calificativele vor fi formatate cu culori diferite: rou pentru nepromovat i albastru pentru promovat. La finalul raportului se vor calcula: numrul total de candidai, numrul de candidai promovai i numrul de candidai respini.
Rezolvare: Pentru crearea raportului din meniul Create se alege opiunea Report Wizard. Sursa raportului este constituit din cmpuri aparinnd mai multor tabele, dup cum urmeaz: Tabelul Rezultate: CNP, PunctajObtinut Tabelul Candidati: NumePrenume Tabelul Testari: IDTestare, DataTestare Tabelul Module: DenumireModul, NivelModul Se va alege opiunea de vizualizare a datelor n funcie de Testari (by Testari) i se va face o sortare a acestora dup cmpul PunctajObtinut, descendent. Dup creare, raportul se deschide n modul Design View i se efectueaz urmtoarele modificri ale acestuia:
68
Studii de caz
Se muta n antetul raportului controalele ce cuprind informaii privind: IDTestare, DataTestare, DenumireModul i NivelModul. Se adaug un control de tip Text Box, pentru afiarea calificativului corespunztor fiecrui candidat. Pentru acest control se modific urmtoarele proprieti: o Name: txtCalificativ o Control Source:
=IIf([PunctajObtinut]<80;"nepromovat";"promovat")
n subsolul raportului (Report Footer) se adaug trei controale de tip Text Box, pentru calcularea numrului total de candidai, a numrului de candidai promovai i a numrului de candidai respini. Proprietatea Control Source
=Count([CNP]) =Sum(IIf([PunctajObtinut]>=80;1;0)) =Sum(IIf([PunctajObtinut]<80;1;0))
Element calculat Numr total candidai Numr candidai promovai Numr candidai nepromovai
Pentru ca raportul creat s afieze doar informaii privind testarea care a fost selectat din list (cboTestare), n formularul frmSelectareTestare, nainte de deschiderea raportului, este necesar adugarea urmtorului filtru:
Formatarea condiional a calificativelor, n vederea aplicrii unui font rou pentru calificativul nepromovat i a unui font albastru pentru cel promovat, se face selectnd controlul txtCalificativ i apsnd butonul . n cadrul ferestrei deschise pe ecran ca urmare a acestei aciuni se adaug urmtoarele condiii, cu formatrile aferente:
Studiu individual: a) S se creeze un raport care s afieze lista candidailor nscrii pentru fiecare testare programat ntr-o anumit perioad (perioada se va introduce ntr-un formular nainte de deschiderea raportului). n cadrul raportului se va calcula numrul de candidai nscrii pentru fiecare testare i pe total. b) S se creeze un raport cu toate testrile programate la o dat ulterioar datei curente, cu precizarea pentru fiecare testare a: numrului de candidai nscrii, a numrului total de locuri disponibile, precum i a numrului de locuri neocupate. Se vor evidenia, prin aplicarea unui font rou, testrile la care nu s-a nscris nici un candidat.
70
Studii de caz
IV
Baz de date pentru gestiunea aprovizionrilor cu materiale la o firm
Se dorete realizarea unei baze de date pentru gestiunea aprovizionrilor cu materiala la o firm ce dispune de mai multe depozite situate n locaii diferite din ar. Depozitele firmei sunt numerotate i, pentru fiecare dintre acestea sunt cunoscute localitatea i adresa exact. Firma se aprovizioneaz cu materiale de la mai muli furnizori, identificai prin CUI furnizor, denumire firm i pentru care se cunosc ara, localitatea i adresa. Toate materialele achiziionate de firm sunt cuprinse ntr-un nomenclator de materiale n care sunt specificate: codul material, denumire material, unitate de msur (UM) i clasa de calitate. n momentul realizrii unei aprovizionri la un depozit se ntocmete o not de recepie pe care sunt consemnate: numrul recepiei, data recepie i denumirile materialele aprovizionate cu cantitile i preurile aferente pentru fiecare material. n final se calculeaz valoarea total a materialelor recepionate. Notele de recepie sunt semnate de o comisie de recepie alcatuit din gestionarii depozitului. La un depozit sunt angajai unul sau mai muli gestionari pentru care se cunosc: cod numeric personal (CNP), Serie i numr carte de identitate, nume gestionar, data angajare, data nastere i numr telefon. Reguli de gestiune: O not de recepie se ntocmete la un singur depozit pentru materiale care provin de la un singur furnizor. Pe o not de recepie pot fi consemnate unul sau mai multe materiale. Numerele bonurilor de recepie sunt atribuite n mod unic la nivelul firmei. Preurile de aprovizionare ale materialelor sunt variabile n timp i pot diferi de la un furnizor la altul. Un gestionar al firmei este angajat la un singur depozit (dar, aa cum s-a precizat n enun, la un depozit sunt angajai mai muli gestionari). O comisie de recepie e format din unul sau mai muli gestionari ai depozitului. I. Realizai modelul relaional al bazei de date i implementai n MS Access Pe baza informaiilor din enunul problemei i a regulilor de gestiune, se poate constitui dicionarul atributelor i se pot contura dependenele funcionale dintre acestea. Aceste aspecte sunt redate sintetic prin intermediul matricei dependenelor funcionale. Observaie: Numele atributelor au fost prescurtate (de exemplu nume furnizor NumeFz, cod material CodM).
1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 NrDepozit LocalitateD AdresaD CUIFz NumeFz TaraFz LocalitateFz AdresaFz CodM NumeM UM Clasa NrReceptie DataReceptie PretUnitar Cantitate CNP NrCI SerieCI NumeGest DataAngajare TelefonGest CodM+NrReceptie
2 1
3 1
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1t
1t
1t
1t
1t
1t
1t
1t
72
Studii de caz
Observaii: Nu au fost luate n considerare atributele calculate. n cazul de fa, atribut calculat este valoarea total a materialelor recepionate. Nu au fost luate n considerare dect o singur dat atributele sinonime (de exemplu numele materialului din nomenclatorul de materiale i denumire material de pe fiecare not de recepie) Potenialele chei primare (atributele determinante) au fost subliniate n prima coloan. Dependenele funcionale au fost marcate cu simbolul 1, iar cele tranzitive cu 1t. S-a constata c atributul CNP i atributul compus din Serie i Numr CI (carte de identitate) reprezint poteniale chei candidate pentru c determin aceleai atribute (cele care descriu gestionarul). n plus, ntre cele dou exist dependene funcionale reciproce (la o realizare a CNP corespunde o singur combinaie Serie i Numr CI i invers). A fost preferat ca determinant atributul CNP, alegerea avnd la baz criteriul stabilitii n timp (CNP nu se modific pe parcursul existenei unei persoane) Dup marcarea dependenelor funcionale s-a constat c atributele PretUnitar i Cantitate nu sunt determinate funcional de ctre nici una din potenialele chei primare. n acest scop s-a cutat un determinant compus i a fost identificat combinaia format din CodM i NrReceptie pe baza creia se poate specifica un singur pre i o singur cantitate aprovizionat (dintr-un anumit material, la o anumit recepie) . ncercnd s conturm modelul relaional al bazei de date plecnd de la matricea dependenelor funcionale i de la observaiile anterioare se pot defini urmtoarele tabele:
Depozit (NrDepozit, LocalitateD, AdresaD) Furnizor (CUIFz, NumeFz, TaraFz, LocalitateFz, AdresaFz) Material (CodM, NumeM, UM, Clasa ) Receptie (NrReceptie, DataReceptie, NrDepozit, CUIFz) Gestionar (CNP, NrDepozit, SerieCI, NrCI, NumeGest, DataAngajare, TelefonGest) ContinutReceptie (CodM, NrReceptie, Cantitate, PretUnitar)
Studiind legturile existente ntre tabele i revenind la enunul problemei se constat c nu exist suficiente legturi cheie primar cheie extern pentru a determina care sunt gestionarii care au semnat notele de recepie. ntruct ntre cheile primare ale tabelelor Gestionar i Recepie exist dependene multivaloare reciproce (un gestionar poate asista la mai multe recepii i o recepie e realizat de o comisie format din mai muli gestionari, se impune adugarea unui tabel intemediar care s asigure legtura. Acest tabel va descrie, de fapt, componena comisiilor de recepie.
ComisieRecepie (CNP, NrRecepie)
73
Rezultatul implementrii modelului relaional n Microsoft Access 2007 este urmtorul:
Studiu individual: 1. Pentru a utiliza ct mai eficient spaiul de depozitare, dup recepionarea materialelor exist posibilitatea ca acestea s fie mutate dintr-un depozit n altul. Pentru mutarea materialelor ntre depozite se ntocmesc bonuri de transfer pe care se precizeaz: numr bon, data transfer, materialul transferat i cantitatea aferent. Un bon de transfer este ntocmit pentru un singur material, la un singur depozit expeditor, ctre un singur depozit destinaie. Fiecare bon de transfer este semnat de un gestionar la depozitul de unde pleac materialul i de ctre un gestionar la depozitul unde materialul ajunge. Adugai modelului relaional tabelul, sau tabelele, ce permit memorarea datelor privind transferurile de materiale.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Pentru fiecare gestionar se va verifica DataAngajare s nu fie anterioar datei de 2 februarie 2000 (cnd s-a nfiinat firma). Regula de validare este urmtoarea:
74
Studii de caz
II.b) Pentru a facilita introducerea datelor n tabelul ComisieReceptie, CNP gestionar se va selecta prin intermediul unei liste ce va afia valorile pentru cmpurile CNP i NumeGest din tabelul gestionari (gestionari vor fi afiai alfabetic). n acest sens se va deschide tabelul ComisieReceptie in modul Design i se va selecta cmpul CNP, dup care se va alege seciunea Lookup aferent casetei de proprieti. Se vor stabili urmtoarele proprieti: Display Control ComboBox RowSource SELECT CNP, NumeGest FROM GESTIONAR
ORDER BY NumeGest;
Column Count 2 (pentru a afia ambele cmpuri din instruciunea SELECT precizat ca surs a listei)
Rezultatul este prezentat n figura urmtoare:
II.c) In tabelul Furnizori se va impune o regul de validare, astfel nct, dac se adaug un furnizor din Spania, localitatea furnizorului nu se va putea completa dect cu valorile Madrid Sau Toledo. ntruct acest validare se realizeaz prin compararea unor valori din cmpuri diferite,
75
regula va fi implementat la nivelul validrilor tabelului. n acest scop se va deschide tabelul n modul Design i se va apsa butonul Properties din bara de instrumente. Expresia pentru regula de validare este prezentat n figura urmtoare:
IIf([TaraFZ]="Spania";[LocalitateFZ] In ("Madrid";"Toledo"))
Validare la nivel de tabel
Studiu individual: Modificai proprietile la nivel de cmp sau tabel care s permit: a) Completarea automat a datelor de recepie cu data curent. b) Preturile i cantitile materialelor recepionate s fie obligatoriu pozitive. c) Codurile unice (CUI) ale furnizorilor din tabelul Recepie s poat fi selectate prin intermediul unei liste n care s figureze codurile i numele furnizorilor din tabelul furnizori.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se calculeze vechimea n ani pentru gestionarii care lucreaz n depozitele firmei din Ploieti i, n funcie de vechime, o prim de 1000 lei pentru cei cu vechime peste 5 ani i 750 lei pentru ceilali.
76
Studii de caz
III.b) S se calculeze Total cantitate recepionat pe fiecare material n intervalul 1 ianuarie 2007 16 martie 2007.
Observaie: Pentru cmpul DataRecepie, n rndul Total al interogrii s-a specificat opiunea Where, ntruct acest cmp este necesar doar pentru impunerea condiiilor, nu i pentru gruparea. III.c) Calculai valoarea totala a recepiilor pe fiecare furnizor extern (din afara Romniei) i convertii aceast valoare n euro la un curs tastat ca parametru al interogrii.
Observaie: Pentru valoarea calculat n euro, n rndul total al interogrii s-a selectat opiunea Expression ntruct acest cmp este calculat pe baza cmpului Valoare, care este rezultatul unei agregri. Cmpurile PretUnitar i Cantitate nu au fost incluse separat n grila interogrii ntruct ar fi afectat gruparea datelor (unui furnizor i corespund mai multe preuri, etc.)
77
III.d) S se realizeze o interogare de tip CrossTab pentru a evidenia preul maxim al fiecrui material n fiecare lun a anului 2008 .
Interogare de tip CrossTab
Observaie: Dup apsarea butonul CrossTab din bara de instrumente, n grila interogrii devine vizibil rndul Crosstab n care se va preciza ce cmp de grupare va fi afiat pe coloanele tabelului (Column heading), care sunt cmpurile ce vor fi afiate pe rnduri (Row Heading) i care sunt valorile de afiat la intersecie (Value) Rezultatul interogrii e prezentat n figura urmtoare:
Not: n lunile anului care nu sunt afiate pe coloane nu exist recepii. Studiu individual: Realizai urmtoarele interogri : a) Calculai ci salariai a angajat firma n anul 2009 n fiecare ora. b) Calculai diferena ntre preul maxim i preul minim de recepie pe fiecare material.
78
Studii de caz
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) Care sunt cei mai noi 10 angajati din firm ?
SELECT TOP 10 NumeGest FROM Gestionar ORDER BY DataAngajare DESC
IV.b) S se extrag ntr-un tabel numit Concedieri toi angajaii de la depozitele 1,2 i 5. n tabelul Concedieri vor figura doar codurile numerice personale, numele gestionarilor i, ntr-un cmp numit Motiv, se va afia textul inchidere depozit pentru cei din depozitul 1 i absene nemotivate pentru ceilali.
SELECT CNP, NumeGest, IiF(NrDepozit=1, "inchidere depozit", "absente") AS Motiv INTO Concedieri FROM Gestionar WHERE NrDepozit IN (1,2,5)
Observaie: Interogarea de selecie a fost transformat ntr-o interogare ce permite crearea unui nou tabel prin precizarea clauzei INTO, dup instruciunea SELECT. IV.c) S se afieze lista ordonat alfabetic cu numele furnizorilor de la care firma a realizat recepii n ultimele 7 zile.
SELECT DISTINCT NumeFz FROM Furnizor, Receptie WHERE Furnizor.CUIFz=Receptie.CUIFz AND DataReceptie>Date()-7 ORDER BY NumeFz
Aceast interogare poate fi rezolvat prin exprimarea legturii ntre tabelele surs direct n clauza FROM astfel:
SELECT DISTINCT NumeFz FROM Furnizor INNER JOIN Receptie ON Furnizor.CUIFz=Receptie.CUIFz WHERE DataReceptie>Date()-7 ORDER BY NumeFz
Observaie: Clauza DISTINCT a fost utilizat, imediat dup instruciunea SELECT pentru a prentmpina apariia n lista de rezultate a unui furnizor de mai multe ori (pentru fiecare recepie de la acel furnizor). IV.d) S se afieze numele i adresele furnizorilor de la care firma a aprovizionat benzin.
SELECT DISTINCT NumeFz, TaraFz, LocalitateFz, AdresaFz FROM Furnizor AS F, Receptie AS R, ContinutReceptie AS CR, Material AS M WHERE F.CUIFz=R.CUIFz AND R.NrReceptie=CR.NrReceptie AND CR.CodM=M.CodM AND NumeM="benzina"
Observaie: ntruct, pentru a exprima legtura dintre furnizor i material, este necesar preluarea n clauza FROM a tabelelor Receptie i ConinutRecepie, pentru a
79
scrie mai uor interogarea s-au atribuit alias-uri numelor de tabele (de ex. Receptie AS R) . IV.e) S se afiseze numele gestionarilor de la depozitul 1 care nu au participat la nicio recepie (CNP-ul acestor gestionari nu se regsete n tabelul ComisieRecepie)
SELECT NumeGest FROM Gestionar LEFT JOIN ComisieReceptie ON Gestionar.CNP=ComisieReceptie.CNP WHERE ComisieReceptie.CNP IS NULL AND NrDepozit=1
Observaie: Utilizarea LEFT JOIN n loc de INNER JOIN permite preluarea tuturor gestionarilor din depozitul 1, indiferent dac acetia apar n tabelul ComisieRecepie sau nu. Filtrarea celor ca nu figureaz n tabelul de comisii se realizeaz prin condiia ComisieReceptie.CNP Is Null.
O alt variant de rezolvare este urmtoarea:
SELECT NumeGest FROM Gestionar WHERE NrDepozit=1 AND CNP NOT IN (SELECT CNP from ComisieReceptie)
IV.f ) Calculai cantitatea medie aprovizionat la o recepie din fiecare material. Se va ordona lista descresctor, dup cantiatatea medie determinat.
SELECT Material.CodM, NumeM, AVG(Cantitate) AS [Cantitate medie receptionata] FROM Material INNER JOIN ContinutReceptie ON Material.CodM=ContinutReceptie.CodM GROUP BY Material.CodM, NumeM ORDER BY AVG(Cantitate) DESC
IV.g) S se afieze lista furnizorilor de la care s-au realizat cel puin de 10 recepii dup data de 10 martie 2009.
SELECT Furnizor.CUIFz, NumeFz, COUNT(NrReceptie) AS [Total receptii] FROM Furnizor INNER JOIN Receptie ON Furnizor.CUIFz=Receptie.CUIFz WHERE DataReceptie>#10/3/2009# GROUP BY Furnizor.CUIFz, NumeFz HAVING COUNT(NrReceptie)>=10
Observaii: Condiia ce implic utilizarea funciei agregat COUNT a condus la necesitatea utilizrii clauzei HAVING. Cmpul DataRecepie nu apare n instruciunea SELECT, ci doar n clauza WHERE ntruct nu este un cmp de grupare.
80
Studii de caz
IV.h) S se diminueze cu 2% preurile de recepie aferente recepiilor din ziua curent pentru materialele din clasa de calitate 2.
UPDATE ContinutReceptie SET PretUnitar=PretUnitar*0.98 WHERE NrReceptie IN (SELECT NrReceptie FROM Receptie WHERE DataReceptie=Date() ) AND CodM IN (SELECT CodM FROM Material WHERE Clasa=2)
IV.i) S se tearg din baza de date toi gestionarii din depozitul 1 i ceilali de la alte depozite dac nu figureaz n nicio comisie de recepie.
DELETE * FROM Gestionar WHERE NrDepoziit=1 OR CNP NOT IN (SELECT CNP FROM ComisieReceptie)
IV.j) Care este cel mai ieftin material recepionat n anul 2009 ? (materialul recepionat la cel mai mic pre).
SELECT NumeM FROM Material INNER JOIN ContinutReceptie ON Material.CodM=ContinutReceptie.CodM WHERE PretUnitar <= ALL(SELECT PretUnitar FROM ContinutReceptie INNER JOIN Receptie ON ContinutReceptie.NrReceptie=Receptie.NrReceptie WHERE YEAR(DataReceptie)=2009)
Studiu individual: a) S se calculeze valoarea fiecrei recepii i valoarea TVA aferent (aplicnd o cot de 19%) b) S se calculeze ci gestionari au participat la fiecare recepie. c) S se tearg recepiile ce provin de la furnizorul ABC SRL. d) S se identifice care sunt gestionarii din depozitul 2 care au participat la mai mult de 100 recepii n ultimul an. e) S se calculeze cantitatea total recepionat din fiecare material, n fiecare an.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular cu subformular pentru a vizualiza la fiecare recepie care sunt gestionarii ce fac parte din comisie. Pe formularul bazat pe tabelul Recepie, codul furnizorului se va alege prin intermediul unui control de tip ComboBox, iar pe subformularul ce va avea ca surs tabelul ComisieReceptie, gestionarii se vor alege de asemenea dintr-o list. Aceast list va fi conine doar gestionarii din depozitul n care a avut loc recepia. Practic, subformularul nu va conine dect un control de tip ComboBox n care se vor afia CNP i nume gestionar pentru a fi alctuit comisia de recepie.
81
Formularul i subformularul n mod Design sunt prezentate n figura urmtoare.
Formular
Subformular
Cea mai simpl metod pentru transformarea casetei CUIFz de pe formular n list de tip ComboBox este s se efectueze click cu butonul drept al mouseului pe suprafaa casetei i, din meniul contextual, s se selecteze opiunea Change To (figura urmtoare).
Apoi, prin intermediul casetei Properties se vor modifica urmtoarele proprieti ale listei de tip Combo: Row Source: SELECT CUIFz, NumeFz FROM Furnizor ORDER BY NumeFz Column Count: 2 (pentru a afia ambele cmpuri din comanda SELECT) Colum Widths: 0cm;5cm (dac se dorete ascunderea primei coloane i doar afiarea numelui furnizorului) Pentru crearea listei de gestionari din subformular nu este ns suficient s se modifice tipul de control i proprietile enumerate mai sus ntruct lista trebuie restrns la gestionarii de la depozitul unde are loc recepia. Acest depozit este precizat n caseta NrDepozit pe formularul principal care i poate modifica valoarea de cte ori se trece la o alt recepie. n acest sens, vom stabili n mod dinamic sursa de date (row source) pentru lista ce permite selecia gestionarilor n subformular. Acest lucru este necesar atunci cnd pe formular se trece la o alt not de recepie sau cnd utilizatorul modific manual numrul depozitului unde are loc recepia.
82
Studii de caz
Evenimentul ce survine la nivelul formularului n momentul n care se trece de la o not de recepie la alta i este necesar reconfigurarea listei de gestionari este On Current, iar evenimentul care survine la nivelul casetei NrDepozit, atunci cnd utilizatorul modific numrul depozitului pentru nota de recepie curent este Before Update . Pentru a nu scrie de mai multe ori aceeai instruciune care modific sursa de date a listei CNP din subformular, vom crea o procedur ce va prelua ca argument numrul depozitului de pe formular:
Sub ActualizezListaGestionari(depozit) ComisieReceptie.Controls("cnp").RowSource = _ "SELECT CNP, NumeGest FROM Gestionar WHERE NrDepozit=" & depozit End Sub
Aceast procedur este apelat ori de cte ori survin evenimentele amintite anterior:
deplasarea de la o nregistrare la alta n formularul principal Private Sub Form_Current() Call ActualizezListaGestionari(NrDepozit.Value) End Sub modificarea de ctre utilizator a numrului depozitului Private Sub NrDepozit_BeforeUpdate(Cancel As Integer) Call ActualizezListaGestionari(NrDepozit.Value) End Sub
Formularul, n mod de vizualizare este prezentat n figura urmtoare:
V.b) Realizai un formular numit Catalog Materiale care s permit vizualizarea materialelor n format tabelar. Se va aduga pentru fiecare material un buton numit VizualizareFurnizori care va permite afiarea listei furnizorilor de la care s-a aprovizionat materialul respectiv.
83
Pentru a afia lista furnizorilor afereni unuia dintre materialele de pe formular, se va proiecta mai nti o interogare n care se va specifica, n rndul de criterii, codul materialului prin referirea casetei CodM de pe formularul Catalog Materiale. Sintaxa utilizat este Forms!NumeFormular!NumeControl iar interogarea numit FurnizoriMateriale este prezentat n figura urmtoare:
Codul VBA ataat butonul de comand de pe formular are rolul s deschid aceast interogare:
Private Sub AfisezFurnizori_Click() DoCmd.OpenQuery ("FurnizoriMaterial") End Sub
Observaie: Dac pe baza interogrii FurnizoriMateriale s-ar fi realizat un raport sau un formular, se puteau utiliza pentru butonul de comand una dintre metodele OpenForm sau OpenReport ale obiectului DoCmd.
84
Studii de caz
Studiu individual: a) S se realizeze un formualar cu subformular pentru actualizarea recepiilor (formularul va avea ca surs tabelul Receptie, iar subformularul, tabelul ContinutReceptie. b) S se realizeze un formular cu subformular pentru a vizualiza pentru fiecare depozit lista recepiilor n ordine cronologic.
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se afieze o list a recepiilor dintr-un anumit an, grupate pe trimestre i pe luni. Se vor afia doar numr recepie, data recepie, numr depozit i nume furnizor, calculndu-se total recepii la nivel de an. Pe fiecare trimestru se vor ordona recepiile pe depozite i, n cadrul fiecrui depozit se vor ordona invers cronologic. Pentru realizarea raportului se va selecta meniul Create i apoi se va apsa butonul Report Wizzard. Etapele ce urmeaz a fi parcurse sunt prezentate n continuare: 1. n prima etap se va configura sursa de date specificnd cmpurile necesare din tabelele Recepie i respectiv Furnizor.
2. n a doua etap, programul wizzard solicit gruparea dup una dintre cele dou surse de date specificate. ntruct niciuna dintre alternativele propuse nu realizeaz gruparea pe trimestre se opteaz pentru alternativa by Receptie i se apas butonul Next.
85
3. Se va aduga DataReceptie de dou ori n lista cmpurilor de grupare (o dat pentru gruparea la nivel de trimestru i o dat pentru gruparea la nivel de lun). ntruct datele calendaristice sunt grupate n mod implicit pe luni, va fi necesar s se apese ulterior butonul Grouping Options i se va stabili gruparea pe trimestre n caseta Grouping Intervals (figura alturat).
4. Se stabilete ordinea de sortare a datelor pe raport (dup numr depozit i descresctor dup dat n cadrul fiecrui depozit)
5. Se precizeaz modul de dispunere a datelor n pagin.
86
Studii de caz
6. Se alege un stil pentru raport (acesta se refer la tipurile de fonturi, culoarea acestora, etc.) Proprietile pot fi modificate ulterior n modul Design.
7. Se stabilete un nume pentru raport. Acesta va figura i ca titlu al raportului, afiat pe prima pagin (n seciunea Report Header)
Structura raportului, n modul Design, este urmtoarea:
Aa cum s-a specificat n enun, se dorete ca aceast situaie trimestrial s fie tiprit doar pentru un anumit an. Acest lucru se poate realiza parametriznd comanda SQL ce constituie sursa raportului (sursa raportului poate fi modificat n proprietatea Report Source figura urmtoare)
87
O alt soluie pentru a restrnge recepiile afiate pe raport la un anumit an calendaristic este utilizarea proprietilor Filter i Filter On Load ale raportului:
Raportul n modul de vizualizare Print Preview este prezentat n figura urmtoare:
88
Studii de caz
Presupunnd c se dorete calcularea unui total general al numrului de recepii pe anul specificat n momentul deschiderii raportului, se va aduga o nou caset de tip TextBox n subsolul raportului (seciunea Report Footer) i se va completa proprietatea Control Source a casetei cu formula =Count(*)
Observaie: n cazul n care se doresc subtotaluri pe luni sau pe trimestre, aceast caset poate fi copiat n seciunile de subsol ale gruprilor pe lun, respectiv trimestru.
Studiu individual: S se realizeze urmtoarele rapoarte: a) Lista recepiilor pentru fiecare material pentru un interval de timp precizat prin specificarea a dou date calendaristice de ctre utilizator. Se vor afia pentru fiecare material i cantitatea recepionat la fiecare recepie, calculndu-se total recepionat pe fiecare material. b) Situaia angajrilor n firm pe fiecare an, la fiecare depozit. Se va calcula vechimea fiecrui gestionar, exprimat n ani. c) Lista recepiilor din luna curent pe furnizori. Se va calcula total recepii de la fiecare furnizor.
89
Baz de date pentru evidena polielor de asigurare, la o societate de profil
O societate de asigurri intenioneaz s implementeze o baz de date pentru evidena polielor de asigurare. Clienii societii pot fi persoane fizice sau juridice caracterizate de nume, prenume, dat natere i CNP, n cazul persoanelor fizice, respectiv denumire i CUI, n cazul persoanelor juridice. Pentru fiecare client, indiferent de statutul su juridic, se atribuie un cod unic i se rein adresa, localitatea i telefonul. Oferta firmei const n mai multe tipuri de asigurri, pentru care se nregistreaz codul, denumirea, riscurile acoperite, durata minim i cea maxim, valoarea minim i cea maxim, precum i alte caracteristici. Pentru a evidenia fiecare risc ce poate fi acoperit prin diverse tipuri de asigurari, se memoreaz codul riscului, denumirea i o descriere asociat. Poliele de asiguare ncheiate de clienii societii sunt nregistrate pe baza urmtoarelor elemente: numr poli, dat ncheiere, dat nceput valabilitate, durat valabilitate (ca numr de luni), dat expirare, obiectul asigurrii, tipul asigurrii, valoarea asigurat i titularul poliei. La ncheierea poliei se ntocmete un grafic al primelor de asigurare ce trebuie pltite n contul poliei, consemnndu-se: valoarea i scadena fiecrei prime, polia aferent, precum i numrul primei, la nivelul poliei asociate (cu alte cuvinte, pentru fiecare poli, vor exista primele 1, 2, 3 etc). Pentru evidena documentelor pe baza crora societatea de asigurri realizeaz ncasarea primelor, se rein urmtoarele informaii: numrul documentului (unic), tipul acestuia, data emiterii, primele ncasate i valoarea documentului. Reguli de gestiune: Un tip de asigurare poate permite acoperirea mai multor tipuri de riscuri. De asemenea, acelai tip de risc poate face obiectul mai multor tipuri de asigurri. O poli are un singur titular i vizeaz un singur tip de asigurare. O prim de asigurare corespunde unei singure polie, dar unei polie i pot fi asociate mai multe prime. Pe baza aceluiai document pot fi ncasate mai multe prime, ns nu se admit pli pariale, fiecare prim fiind ncasat integral, prin intermediul unui document unic. Fiecare document de ncasare are un singur titular, clientul care efectuez plata primelor. I. Realizai modelul relaional al bazei de date i implementai n MS Access Pe baza informaiilor referitoare la activitatea societii de asigurri se poate constitui dicionarul atributelor i se pot deduce relaiile dintre acestea. Ambele aspecte sunt redate sintetic prin intermediul matricei dependenelor funcionale, prezentat n continuare:
90
Studii de caz
Observaii: Anterior realizrii matricei au fost eliminate atributele derivate: DataExpirarePolita (se determin n funcie de DataInceputValabilitate i DurataValabilitate), ValoareDocumentIncasare (se calculeaz ca sum a valorii primelor - ValoarePrima - ncasate pe baza documentului). Pentru simplificare, pe primul rnd al matricei au fost dispuse doar atributele sau perechile de atribute cu rol de determinant, n raport cu alte atribute. Dependenele funcionale au fost marcate cu simbolul 1, iar cele tranzitive cu 1t.
91
Analiza matricei dependenelor funcionale conduce la urmtorul model relaional al bazei de date:
TipAsigurare (CodAsigurare, DenumireAsigurare, DurataMinima, DurataMaxima, ValoareMinima, ValoareMaxima, AlteCaracteristici) Risc (CodRisc, DenumireRisc, Descriere) Client (CodClient, TipClient, Nume, Prenume, DataNastere, Cnp, Denumire, Cui, Adresa, Telefon) PolitaAsigurare (NrPolita, DataPolita, CodAsigurare, CodClient, DataInceputValabilitate, ValoareAsigurata, ObiectAsigurare) DocumentIncasare (NrDocumentIncasare, TipDocument, DataDocument, CodClient) PrimaAsigurare (NrPolita, CodPrima, ValoarePrima, Scadenta, NrDocumentIncasare) AsigurareRisc (CodAsigurare, CodRisc)
Observaii: ntruct codificarea primelor se realizeaz similar (1, 2, 3 etc.) n contextul fiecrei polie, rezult c un astfel de cod nu poate juca rol de determinant n raport cu celelalte atributele asociate polielor. Deoarece fiecare cod este unic la nivelul unei polie date, se va apela la un determinant compus, constituit din atributele CodPrima i NrPolita, care va deveni cheia primar a tabelei PolitaAsigurare. Totodat, n aceeai tabel, NrPolita ndeplinete i rolul de cheie extern n raport cu cheia primar a tabelei PolitaAsigurare. Tabela AsigurareRisc este consecina dependenelor multiple reciproce dintre atributele CodAsigurare i CodRisc. n aceste condiii, se impune constituirea unei tabele distincte, cu cheia primar compus din ambele atribute, care, n mod individual, sunt chei externe n raport cu cheile primare din tabelele TipAsigurare i Risc. n vederea realizrii modelului relaional au fost eliminate dependenele tranzitive, astfel nct tabelele rezultate se afl deja n forma normal 3 (FN3) i pot face obiectul implementrii. Rezultatul implementrii modelului relaional n Microsoft Access 2007 este prezentat n figura urmtoare:
92
Studii de caz
Studiu individual: La producerea unui risc acoperit de o poli valabil, titularul poliei sesizeaz societatea de asigurri, care urmeaz s evalueaze pagubele i s decid despgubirile ce se impun. n acest scop, se ntocmete un proces verbal care conine urmtoarele elemente: numrul procesului verbal, data completrii, numele expertului care l-a ntocmit, polia (neexpirat) care st la baza sa, concluziile i procentul de despgubire decis. Achitarea despgubirilor se realizeaz prin intermediul unor documente de plat n care se consemneaz: numrul (unic) i tipul documentului, valoarea i eventualele explicaii. Nu se admit pli fracionate, iar un document de plat vizeaz despgubirile decise printr-un singur proces verbal. Adugai modelului relaional tabelul sau tabelele necesare pentru memorarea datelor privind despgubirile acordate asigurailor.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Valorile atributului TipClient trebuie limitate la PF (implicit) i PJ; de asemenea nu se accept valoarea NULL. Sunt vizate urmtoarele proprieti ale cmpului TipClient, din tabela Client: - Default Value: PF - Required: Yes - Validation Rule: PF OR PJ - Validation Text: Valorile admise sunt PF (pentru persoanele fizice) i PJ pentru persoanele juridice)! O alternativ la regula de validare impus prin proprietatea Validation Rule o constituie limitarea valorilor atributului TipClient prin intermediul unei liste derulante, care va oferi spre selecie doar valorile admise. n acest caz, la introducerea
93
datelor (n Datasheet View), zona aferent cmpului TipClient, nu va mai fi afiat sub forma uzual, a unei casete-text (TextBox), ci sub form de caset combinat (ComboBox). Pentru aceasta, este necesar ca la nivelul atributului TipClient s se seteze urmtoarele proprieti: - Display Control: Combo Box - Row Source Type: Value List - Row Source: PF; PJ - Limit To List: Yes II.b) Data de debut a valabilitii unei polie nu poate fi anterioar datei de ncheiere a poliei. De asemenea, data ncheierii unei polie nu poate fi ulterioar datei curente. Data curent va fi utilizat ca valoare implicit pentru data de debut a perioadei de valabilitate a unei polie. n tabela PolitaAsigurare, la nivelul atributului DataPolita, vor fi specificate urmtoarele proprieti : - Default Value: DATE() - Validation Rule: <= DATE() - Validation Text: Data ncheierii a unei polie nu poate fi ulterioar datei curente. Restricia privind anterioritatea datei de nceput a valabilitii unei polie fa de data la care polia a fost ncheiat, implic relaia dintre valorile a dou atribute ale tabelului PolitaAsigurare, prin urmare trebuie implementat prin intermediul unei reguli de validare definit la nivel de tabel: - Table Properties / Validation Rule: [DataPolita] <= [DataInceputValabilitate] - Table Properties / Validation Text: Perioada de valabilitate a unei polie debuteaz dup data nregistrrii poliei! II.c) n funcie de tipul clienilor (persoane fizice sau juridice), se vor completa alternativ fie atributele Nume, Prenume, DataNastere i Cnp (13 caractere numerice), fie Denumire i Cui. i n cazul acestei restricii sunt implicate mai multe cmpuri ale aceleiai tabele (Client), impunndu-se o soluie similar celei prezentate anterior: - Table Properties / Validation Rule:
([TipClient]="PJ" IMP (([Nume] IS NULL) AND ([Prenume] IS NULL) AND ([DataNastere] IS NULL) AND ([Cnp] IS NULL) AND ([Denumire] IS NOT NULL) AND ([Cui] IS NOT NULL))) AND ([TipClient]="PF" IMP (([Nume] IS NOT NULL) AND ([Prenume] IS NOT NULL) AND ([DataNastere] Is NOT NULL) AND ([Cnp] IS NOT NULL) AND ([Denumire] IS NULL) AND ([Cui] IS NULL)))
94
Studii de caz
Table Properties / Validation Text: La introducerea datelor, se va tine cont de tipul clientilor! Observaie: Pentru a se putea face distincia ntre valori (constante) text i atribute, numele atributelor trebuie ncadrate de paranteze drepte ([Nume], [Prenume] etc.), iar constantele de ghilimele (PF, PJ). n plus, n cazul atributului Cnp (care trebuie s admit doar texte, compuse din 13 caractere numerice) se stabilesc urmtoarele proprieti: - Data Type: Text - Input Mask: 0000000000000 (0 indic un caracter numeric, obligatoriu)
Studiu individual: a) Tipurile de documente care atest ncasarea contravalorii primelor de asiguare trebuie restricionate la urmtoarele: chitan, ordin de plat, cec. Data emiterii unui document de plat nu poate fi ulterioar datei curente. b) Pentru fiecare tip de asigurare, durata minim trebuie s fie inferioar duratei maxime, iar valoarea minim nu o poate depi pe cea maxim. c) Durata maxim acoperit de fiecare tip de asigurare este de cel mult 4 ani.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se identifice categoriile de riscuri acoperite prin tipuri de asigurri pentru care durata i valoarea sunt fixe (predeterminate).
Observaie: Avnd n vedere natura relaiei dintre tabelele Risc i AsigurareRisc o categorie de riscuri poate fi asociat cu mai multe tipuri de asigurri), dar i faptul c se urmrete obinerea unei liste a riscurilor, nu i a datelor privitoare la asigurri, este posibil ca la nivelul cmpurilor afiabile, anumite combinaii CodRisc + DenumireRisc s apar n mod repetat. Din acest motiv, se va solicita ca din setul de rezultate returnat de interogare, s fie eliminte duplicatele (Query Properties / Unique Values: Yes).
95
III.b) S se obin lista clienilor persoane juridice, din Bucureti i Braov, care dein polie ce urmeaz s expire n urmtoarele 10 zile; va fi afiat i numrul poliei.
Observaie: Data expirrii unei polie poate fi deteminat cumulnd durata de valabilitate (exprimat ca numr de luni, conform enunului) la data care marcheza nceputul perioadei de valabilitate i deducnd apoi o zi; spre exemplu, o poli cu valabilitatea de 1 an i cu data de debut 5 mai 2009 expir la 4 mai 2010 (aceasta este ultima zi de valabilitate). n cazul de fa, pentru a determina data expirrii, s-a utilizat funcia calendaristic DATEADD (tip_unitate_timp, nr_uniti_timp, debut_interval), care permite aflarea datei de sfrit a unui interval pentru care se specific data de nceput i durata, exprimat prin numrul unitilor de timp de un anumit tip, indicat sub forma unor constante text, predefinite (d- zile, m - luni, yyyy - ani etc.). III.c) S se determine valoarea total a primelor ncasate n numerar, la nivelul anului n curs, pe tipuri de asigurri.
96
Studii de caz
III.d) S se decaleze cu 5 zile (n plus), scadenele tuturor primelor neachitate, asociate polielor cu numerele 100, 101 i 107.
Observaie : Cererea este rezolvat prin intermediul unei introgri de aciune, de actualizare (Update Query). IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze tipurile de asigurri solicitate de clienii persoane juridice, n intevalul 15 ianuarie 15 februarie 2009.
SELECT DISTINCT TipAsigurare.CodAsigurare, DenumireAsigurare FROM TipAsigurare INNER JOIN (PolitaAsigurare INNER JOIN Client ON PolitaAsigurare.CodClient = Client.CodClient) ON TipAsigurare.CodAsigurare = PolitaAsigurare.CodAsigurare WHERE TipClient ="PJ" AND DataPolita BETWEEN #15/01/2009# AND #15/02/2009#;
Observaie: Datorit faptului c pentru acelai tip de asigurare pot exista mai multe polie, anumite combinaii CodAsigurare + DenumireAsigurare pot aprea n mod repetat la nivelul setului de nregistrri returnat de interogare; pentru eliminarea duplicatelor la nivelul cmpurilor afiabile, s-a recurs la specificatorul DISTINCT. IV.b) n cazul polielor cu durata de valabilitate mai mare de un an, s se afieze primele restante i s se calculeze valoarea penalitilor aferente, prin aplicarea unui procent predefinit la valoarea primei: 2% pe zi, dac ntrzierea nu depete 30 zile i 7% pe zi, n caz contrar. nregistrrile vor fi sortate descresctor, dup numrul zilelor de ntrziere.
SELECT PrimaAsigurare.*, ValoarePrima * IIF((DATE() - Scadenta) <= 30, 0.02, 0.07) * (DATE() - Scadenta) AS Penalitati FROM PolitaAsigurare INNER JOIN PrimaAsigurare ON PolitaAsigurare.NrPolita = PrimaAsigurare.CodPrima WHERE DurataValabilitate > 12 AND NrDocumentIncasare IS NULL AND DATE() > Scadenta ORDER BY Scadenta;
97
Observaie: Sortarea ascendent, dup scaden, produce un rezultat similar cu sortarea descendent, dup numrul zilelor de ntrziere (cu ct scadena, depit deja, este mai ndeprtat n timp, cu att numrul zilelor de ntrziere este mai mare).
IV.c) S se identifice tipurile de asigurri ncheiate de clienii persoane fizice, cu vrsta mai mic de 35 ani (la data ncheierii poliei).
SELECT DISTINCT TipAsigurare.* FROM Client INNER JOIN (PolitaAsigurare INNER JOIN TipAsigurare ON PolitaAsigurare.CodAsigurare = TipAsigurare.CodAsigurare) ON Client.CodClient = PolitaAsigurare.CodClient WHERE TipClient = "PF" AND DATEDIFF("yyyy", DataNastere, DataPolita) < 35;
Observaie: Funcia DATEDIFF(tip_unitate_timp, data1, data2) returneaz diferena dintre dou date, exprimat n numrul unitilor de timp de un anumit tip (specificat prin intermediul acelorai constante text predefinite, ca i n cazul funciei DATEADD). IV.d) S se determine numrul i valoarea total a polielor ncheiate n semestrul 2 al anului anterior, pe tipuri de asigurri i tipuri de clieni. nregistrrile vor fi sortate n ordine descresctoare, dup valoarea polielor.
SELECT TipAsigurare.CodAsigurare, DenumireAsigurare, TipClient, SUM (ValoareAsigurata) AS [Valoare polite], COUNT(*) AS [Numar polite] FROM TipAsigurare INNER JOIN (PolitaAsigurare INNER JOIN Client ON PolitaAsigurare.CodClient = Client.CodClient) ON TipAsigurare.CodAsigurare = PolitaAsigurare.CodAsigurare WHERE YEAR(DataPolita) = YEAR(DATE()) -1 AND MONTH(DataPolita) > 6 GROUP BY TipAsigurare.CodAsigurare, DenumireAsigurare, TipClient ORDER BY SUM (ValoareAsigurata) DESC;
IV.e) S se calculeze valoarea total a primelor ncasate n avans (nainte de scaden), la nivelul lunilor ianuarie, mai i octombrie, n ultimii 3 ani; fiecare dintre lunile precizate vor fi afiate distinct, n ordine cronologic.
SELECT YEAR(DataDocument) AS An, MONTH(DataDocument) AS Luna, SUM(ValoarePrima) AS [Total incasari] FROM DocumentIncasare INNER JOIN PrimaAsigurare ON DocumentIncasare.NrDocumentIncasare = PrimaAsigurare.NrDocumentIncasare WHERE DataDocument < Scadenta AND YEAR(DataDocument) >= (YEAR(DATE())-3) AND MONTH(DataDocument) IN (1,5,10) GROUP BY YEAR(DataDocument), MONTH(DataDocument) ORDER BY 1, 2;
98
Studii de caz
Observaie: ntruct sunt reprezentate de cmpuri afiabile (an, lun), criteriile de sortare pot fi specificate att prin intermediul expresiilor ce stau la baza lor (ORDER BY YEAR(DataDocument),MONTH(DataDocument)), ct i prin indicarea poziiilor pe care le ocup n cadrul listei cmpurilor afiabile (ORDER BY 1, 2). IV.f ) S se realizeze un clasament al tipurilor de asigurri pentru care, n ultimile 3 sptmni, au fost ncheiate cel puin 10 polie cu durata mai mare de 1 an; rezultatele vor fi sortate dup numrul polielor, n ordine descresctoare.
SELECT TipAsigurare.CodAsigurare, DenumireAsigurare, COUNT(*) AS [Numar polite] FROM TipAsigurare INNER JOIN PolitaAsigurare ON TipAsigurare.CodAsigurare = PolitaAsigurare.CodAsigurare WHERE DATEDIFF ("d", DataPolita, DATE()) <= 21 AND DurataValabilitate > 12 GROUP BY TipAsigurare.CodAsigurare, DenumireAsigurare HAVING COUNT(*) >= 10 ORDER BY COUNT(*) DESC;
IV.g) S se identifice tipurile de asigurri care permit acoperirea celor mai multe riscuri.
SELECT TOP 1 TipAsigurare.CodAsigurare, DenumireAsigurare, COUNT(*) As [Nr Riscuri] FROM TipAsigurare INNER JOIN AsigurareRisc ON TipAsigurare.CodAsigurare = AsigurareRisc.CodAsigurare GROUP BY TipAsigurare.CodAsigurare, DenumireAsigurare ORDER BY 3 DESC;
Observaie: Pentru ca specificatorul TOP 1 s returneze asigurrile care acoper numrul maxim de riscuri se impune sortarea descendent, dup valorile returnate de funcia COUNT: ORDER BY COUNT(*) DESC, sau, ORDER BY 3 DESC. IV.h) S se identifice clienii din Bucureti, care nu mai dein polie valabile, dar au acumulat debite din prime neachitate. Rezultatele obinute n urma interogrii vor fi stocate ntr-un nou tabel, numit Debite - Prime, cu urmtoarea structur: CodClient, Identitate client (numele i prenumele, sau, dup caz, denumirea), Total prime restante. Ulterior, n tabelul nou creat, vor fi adaugai i debitorii din Braov, care nu mai dein polie valabile. - Creare tabel:
SELECT Client.CodClient, IIF(TipClient = "PF", Nume & " " & Prenume, Denumire) AS [Identitate client], SUM(ValoarePrima) AS [Total prime restante] INTO [Debite Prime] FROM Client INNER JOIN (PolitaAsigurare INNER JOIN PrimaAsigurare ON PolitaAsigurare.NrPolita = PrimaAsigurare.NrPolita)
Baze de date Access 2007 ON Client.CodClient = PolitaAsigurare.CodClient WHERE DATEADD("m", DurataValabilitate, DataInceputValabilitate) >= DATE() AND NrDocumentIncasare IS NULL AND Adresa LIKE "*Bucuresti*" GROUP BY Client.CodClient, IIF(TipClient="PF", Nume & " " & Prenume, Denumire);
99
- Adugare nregistrri:
INSERT INTO [Debite Prime] (CodClient, [Identitate client], [Total prime restante]) SELECT Client.CodClient, IIF(TipClient = "PF", Nume & " " & Prenume, Denumire), SUM(ValoarePrima) FROM Client INNER JOIN (PolitaAsigurare INNER JOIN PrimaAsigurare ON PolitaAsigurare.NrPolita = PrimaAsigurare.NrPolita) ON Client.CodClient = PolitaAsigurare.CodClient WHERE DATEADD("m", DurataValabilitate, DataInceputValabilitate) >= DATE() AND NrDocumentIncasare IS NULL AND Adresa LIKE "*Braov*" GROUP BY Client.CodClient,IIF(TipClient="PF", Nume & " " & Prenume, Denumire);
IV.i) Pentru toate tipurile de asigurri care acoper un numr minim de riscuri, precizat la execuie, s se realizeze modificrile urmtoare: dublarea duratei maxime a asigurrii, reducerea cu 3% a valorii minime, respectiv majorarea cu 13% a valorii maxime.
Parameters [Introduceti numarul minim de riscuri] Integer; UPDATE TipAsigurare SET DurataMaxima = DurataMaxima * 2, ValoareMinima = ValoareMinima * 0.97, ValoareMaxima = ValoareMaxima * 1.13 WHERE CodAsigurare IN (SELECT CodAsigurare FROM AsigurareRisc GROUP BY CodAsigurare HAVING COUNT(CodAsigurare) > [Introduceti numarul minim de riscuri]);
IV.j) S se renune la tipurile de asigurri cu valoarea, sau durata minim, superioare mediei i care nu au fost solicitate de nici un client.
DELETE * FROM TipAsigurare WHERE (ValoareMinima > (SELECT AVG(ValoareMinima) FROM TipAsigurare) OR DurataMinima > (SELECT AVG(DurataMinima) FROM TipAsigurare)) AND CodAsigurare <> ALL (SELECT CodAsigurare FROM PolitaAsigurare);
100
Studii de caz
Studiu individual: a) Pentru un tip de asigurare indicat ca parametru, s se obin situaia primelor neachitate, scadente n urmtoarele 3 zile. b) S se calculeze, pe tipuri de asigurri, valoarea total a ncasrilor din prime, la nivelul lunii curente. c) S se determine durata medie de valabilitate i valoarea medie a asigurrilor ncheiate de clienii persoane juridice din Braov, Timioara i Constana, n anul precedent. d) S se identifice riscurile care fac obiectul a cel puin 5 tipuri de asigurri. e) n cazul polielor cu numerele 735 i 773, s se modifice suma i durata de valabilitate la valorile maxime posibile, conform tipului de asigurare aferent.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular pentru consultarea i actualizarea datelor privitoare la tipurile de asigurri. Avnd n verere c fiecare tip de asigurare este asociat cu una sau mai multe categorii de riscuri, pentru rezolvarea acestei cerine a fost creat un formular principal ce permite gestionarea tipurilor de asigurri, n cadrul cruia a fost plasat un subformular, pentru evidena riscurilor. Rezultatul este urmtorul:
Observaii: Sursa de date (proprietatea Record Source) a formularului este reprezentat de tabela TipAsigurare, n timp ce subformularul are la baz urmtoarea cerere SQL:
SELECT AsigurareRisc.CodRisc, DenumireRisc, Descriere, CodAsigurare FROM Risc INNER JOIN AsigurareRisc ON Risc.CodRisc = AsigurareRisc.CodRisc;
101
Sincronizarea dintre sursele de date ale celor dou formulare este realizat pe baza atributului comun CodAsigurare. Drept urmare, n cadrul formularului principal, vor fi setate urmtoarele proprieti ale obiectului subformular RiscuriAcoperite: - Link Master Fields: CodAsigurare - Link Child Fields: CodAsigurare Butoanele de comand care permit deplasarea de la o nregistrare la alta, adugarea sau tergerea de nregistrri, precum i anularea modificrilor efectuate asupra nregistrrii curente, au fost realizate prin utilizarea asistentului (wizard) specializat, disponibil n MS Access 2007. Butonul de comand pentru editarea nregistrii curente (cmdEditeaza) determin, prin procedura ataat evenimentului Click (pe care, din motive de spaiu, nu o redm aici), comutarea formularului din modul consultare n modul editare, inhibnd sau activnd, n mod alternativ, anumite controale, n funcie de valoarea proprietaii Enabled (True sau False): n modul editare, cmpurile formularului, ca i butoanele pentru salvarea sau anularea modificrilor sunt active (Enabled = True), n timp ce butoanele pentru navigare, adugare, tergere, ca i cmdEditeaza, sunt inactive (Enabled = False); desigur, situaia se inverseaz n modul consultare, proprietatea Enabled a fiecrui control fiind setat la valoarea opus celei din modul editare. Caseta combinat cboCodAsigurare permite regsirea rapid a datelor privitoare la tipul de asigurare al crui cod a fost selectat. Proprieti: - Control Source: (Unbound) - Row Source Type: Table/Query; - Row Source:
SELECT CodAsigurare, DenumireAsigurare FROM TipAsigurare;
- Procedura asociat evenimentului AfterUpdate: Private Sub cboCodAsigurare_AfterUpdate()

'Este creata o copie a setului de inregistrari din tabelul-sursa al formularului
Dim rsAsigurari As Recordset Set rsAsigurari = Me.RecordsetClone

'Se avanseaza la inregistrarea ce contine codul asigurarii selectate
rsAsigurari.FindFirst ("[CodAsigurare]=" & Me.cboCodAsigurare.Value) Me.Bookmark = rsAsigurari.Bookmark End Sub
Butonul de comand cmdSalveaza permite salvarea modificrilor aduse tipului de asigurare vizat de nregistrarea curent, innd-se seama de faptul c acesta trebuie s acopere cel puin o categorie de riscuri i c limitele de durat i valoare trebuie s fie valide. Procedura asociat evenimentului Click este urmtoarea:
102
Studii de caz
Private Sub cmdSalveaza_Click() On Error Resume Next Dim msg_eroare As String If Me.DurataMaxima < Me.DurataMinima Then _ msg_eroare = "Durata Max. trebuie sa fie cel putin egala cu Min.!" & vbCrLf If Me.ValoareMaxima < Me.ValoareMinima Then _ msg_eroare = msg_eroare & "Val. Max. trebuie sa fie macar egala cu Min.!" & vbCrLf
'Se verifica existenta inregistrarilor la nivelul subformularului RiscuriAcoperite
Dim rsRiscuri As Recordset Set rsRiscuri = Me.RiscuriAcoperite.Form.Recordset If rsRiscuri.RecordCount = 0 Then _ msg_eroare = msg_eroare & "Nu ati mentionat nici o categorie de riscuri!" & vbCrLf If msg_eroare <> "" Then MsgBox msg_eroare & "Inregistrarea nu a fost salvata!", vbCritical Else DoCmd.RunCommand acCmdSaveRecord
' In caseta combinata cboCodAsigurare sunt actualizate datele privitoare la asigurari
Me.cboCodAsigurare.Requery MsgBox "Inregistrarea a fost salvata!", vbInformation End If End Sub
V.b) Realizai un formular pentru consultarea i actualizarea datelor privind poliele de asigurare. Deoarece poliele de asigurare trebuie corelate, din punctul de vedere al duratei i sumei, cu valorile specifice categoriei de asigurri de care aparin i pentru c gestiunea polielor implic i gestiunea primelor aferente, s-a optat pentru realizarea unui formular cu urmtoarea structur:
103
Dup cum se poate observa, formularul include un subformular (numit Prime) care permite evidena primelor de asigurare i a documentelor de plat utilizate pentru achitarea acestora. Cteva precizri privind soluia prezentat: - Sursa de date (proprietatea Record Source) a formularului principal este reprezentat de urmtoarea cerere SQL:
SELECT NrPolita, DataPolita, PolitaAsigurare.CodAsigurare, PolitaAsigurare.CodClient, DataInceputValabilitate, DurataValabilitate, ValoareAsigurata, ObiectAsigurare, DenumireAsigurare, DurataMinima, DurataMaxima, ValoareMinima, ValoareMaxima, TipClient, DATEADD("m", DurataValabilitate, DataInceputValabilitate) -1 AS DataExpirare, IIF(TipClient = "PF", Nume & " " & Prenume, Denumire) AS NumeClient FROM TipAsigurare INNER JOIN (Client INNER JOIN PolitaAsigurare ON Client.CodClient = PolitaAsigurare.CodClient) ON TipAsigurare.CodAsigurare = PolitaAsigurare.CodAsigurare;
n cazul subformularului, valoarea proprietii Record Source este reprezentat de tabela PrimaAsigurare. Sincronizarea dintre cele sursele de date ale celor dou formulare este realizat pe baza atributului comun NrPolita. Drept urmare, n cadrul formularului principal, vor fi setate urmtoarele proprieti ale obiectului subformular Prime: - Link Master Fields: NrPolita - Link Child Fields: NrPolita Dup cum se poate observa, codul tipului de asigurare aferent poliei este selectat din lista de valori a unui control ComboBox, cu urmtoarele proprieti: - Control Source: CodAsigurare - Row Source Type: Table/Query - Row Source:
SELECT CodAsigurare, DenumireAsigurare FROM TipAsigurare;
De asemenea, codul clientului titular al poliei este selectat din lista de valori a unui alt control ComboBox, cu urmtoarele proprieti: - Control Source: CodClient - Row Source Type: Table/Query - Row Source:
SELECT CodClient, TipClient, Nume, Prenume, Denumire FROM Client;
Datorit faptului c formularul are ca surs o interogare, odat cu selectarea unui cod de client, se actualizeaz n mod automat coninutul cmpurilor TipClient i NumeClient. De asemenea, la selectarea codului aferent unui tip de asigurare, se actualizeaz coninutul tuturor cmpurilor care depind de acesta (DenumireAsigurare, DurataMinima, DurataMaxima, ValoareMinima, ValoareMaxima). Din acest motiv, toate controalele ce au ca surs cmpurile amintite (proprietatea Control Source) au fost dezactivate, servind doar la afiarea
104
Studii de caz
datelor, nu i la editarea acestora (proprietatea Enabled = False). Un tratament similar a fost aplicat i controlului ce are ca surs cmpul DataExpirare, valoarea sa fiind calculat n mod automat, n funcie de DurataValabilitate i DataInceputValabilitate. n plus, atunci cnd asigurarea selectat are valoarea i/sau durata predeterminate, cmpurile ValoareAsigurata i DurataValabilitate sunt dezactivate i completate n mod automat, dup cum se poate observa din procedura asociat evenimentului AfterUpdate al controlului ComboBox ce ofer lista tipurilor de asigurri:
Private Sub CodAsigurare_AfterUpdate() If Me.DurataMaxima = Me.DurataMinima Then Me.DurataValabilitate = Me.DurataMaxima Me.DurataValabilitate.Enabled = False Else Me.DurataValabilitate.Enabled = True End If If Me.ValoareMaxima = Me.ValoareMinima Then Me.ValoareAsigurata = Me.ValoareMaxima Me.ValoareAsigurata.Enabled = False Else Me.ValoareAsigurata.Enabled = True End If End Sub
Butoanele de comand au fost realizate prin utilizarea asistentului (wizard) specializat disponibil n MS Access 2007 i, exceptnd butonul cmdSalveaza, au funcii similare celor descrise n cazul cerinei precedente. Butonul de comand cmdSalveaza permite salvarea modificrilor aduse poliei curente, lund n calcul corelaia dintre durata de valabiliate i valoarea poliei, pe de-o parte, i limitele de durat i valoare, determinate de tipul asigurrii, pe de alt parte. De asemenea, pentru a fi valid, o poli trebuie asociat cu primele de asigurare ce trebuie achitate n contul su. n continuare este redat procedura asociat evenimentului Click:
Private Sub cmdSalveaza_Click() On Error Resume Next Dim msg_eroare As String If Me.DataInceputValabilitate < Me.DataPolita Then _ msg_eroare = "Data debut valabil. trebuie sa fie ulterioara datei politei!" & vbCrLf If (Me.ValoareAsigurata < Me.ValoareMinima) Or _ (Me.ValoareAsigurata > Me.ValoareMaxima) Then _ msg_eroare = msg_eroare & "Valoarea politei depaseste limitele admise!" & vbCrLf If (Me.DurataValabilitate < Me.DurataMinima) Or _
105
(Me.DurataValabilitate > Me.DurataMaxima) Then _ msg_eroare = msg_eroare & "Durata valabil.depaseste limitele admise!" & vbCrLf
'Se verifica existenta inregistrarilor la nivelul subformularului Prime
If Me.Prime.Form.Recordset.RecordCount = 0 Then _ msg_eroare = msg_eroare & "Nu au fost inregistrate prime de asigurare!" & vbCrLf If msg_eroare <> "" Then MsgBox msg_eroare & "Inregistrarea nu a fost salvata!", vbCritical Else DoCmd.RunCommand acCmdSaveRecord MsgBox "Inregistrarea a fost salvata!", vbInformation End If End Sub La nivelul subformularului, la adugarea unei noi prime pentru polia afiat la nivelul formularului principal, codul primei este atribuit n mod automat, pe baza numrului nregistrrii curente. Astfel, n cazul fiecrei polie, primele vor fi codificate n mod automat sub forma: 1, 2, 3 etc: Private Sub Form_Current() If Me.NewRecord Then Me.CodPrima = Me.CurrentRecord End Sub
De asemenea, tot la nivelul subformularului, la adugarea sau modificarea primelor de asigurare, se verific dac acestea sunt introduse n ordine cronologic i dac scadenele lor se ncadreaz n intervalul de valabilitate al poliei de care aparin: Private Sub Form_BeforeUpdate(Cancel As Integer) Dim msg_eroare As String If (Me.Scadenta < Me.Parent.Form!DataInceputValabilitate) Or _ (Me.Scadenta > CDate(Me.Parent.Form!DataExpirare.Value)) Then _ msg_eroare = "Data excede perioada de valabilitate a politei!" & vbCrLf
Daca nu ne aflam la prima inregistrare, se cauta scadenta primei anterioare
Dim sir_scadenta As String sir_scadenta = "CodPrima=" & Me.CurrentRecord - 1 & " And NrPolita=" & Me.NrPolita If Me.CurrentRecord > 1 Then If DLookup("[Scadenta]", "PrimaAsigurare", sir_scadenta) >= Me.Scadenta Then _ msg_eroare = msg_eroare & "Primele se introduc in ordine cronologica!" End If If msg_eroare <> "" Then MsgBox msg_eroare, vbCritical
Se anuleaza operatia de salvare a inregistrarii curente
Cancel = True End If End Sub
106
Studii de caz
Studiu individual: S se realizeze formularele (i eventualele subformulare asociate acestora) care ndeplinesc urmtoarele funcii: a) Consultarea i actualizarea tabelei Client; b) nregistarea documentelor de ncasare aferente primelor de asigurare.
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se obin situaia ncasrilor din prime de asigurare la nivelul unui an, respectiv al unei categorii de clieni, care urmeaz s fie precizate la deschiderea raportului. Datele vor fi prezentate grupat, la nivelul de polielor individuale, precum i al categoriilor de asigurri de care acestea aparin, determinndu-se totalul ncasrilor pentru fiecare din nivelurile indicate. ntruct datele necesare obinerii unei astfel de situaii trebuie extrase din mai multe tabele, sursa raportului (proprietatea Record Source) este reprezentat de o interogare, al crei cod SQL este urmtorul:
SELECT TipAsigurare.CodAsigurare, DenumireAsigurare, PolitaAsigurare.NrPolita, PrimaAsigurare.CodPrima, PolitaAsigurare.CodClient, TipClient, IIF(TipClient = "PF", Nume & " " & Prenume, Denumire) AS TitularPolita, PrimaAsigurare.NrDocumentIncasare, TipDocument, DataDocument, IIF(Scadenta < DataDocument, ValoarePrima, 0) AS PrimeRestante, ValoarePrima, Scadenta FROM TipAsigurare INNER JOIN ((Client INNER JOIN PolitaAsigurare ON Client.CodClient = PolitaAsigurare.CodClient) INNER JOIN (DocumentIncasare INNER JOIN PrimaAsigurare ON DocumentIncasare.NrDocumentIncasare = PrimaAsigurare.NrDocumentIncasare) ON PolitaAsigurare.NrPolita = PrimaAsigurare.NrPolita) ON TipAsigurare.CodAsigurare = PolitaAsigurare.CodAsigurare WHERE YEAR(DataDocument)= IIF(ISNULL([Specificati anul]), YEAR (DataDocument),[Specificati anul]) AND TipClient= IIF(ISNULL([Specificati tipul clientilor]),TipClient,[Specificati tipul clientilor]);
Structura raportului, dup cum se prezint n modul Design, este prezentat n figura de pe pagina urmtoare.
107
Observaii: Informaiile de detaliu, privitoare la documentele de ncasare i primele pe care aceste le achit, sunt plasate n seciunea Detail, gruparea acestora n vederea prezentrii i centralizrii fiind realizat dup criteriile menionate n cerin: numrul poliei de care aparin, i codul tipului de asigurare asociat poliei. Expresiile care returneaz valoarea total a ncasrilor sunt incluse n subsolul fiecrui grup i n cel al raportului, valorile returnate avnd semnificaii diferite, n funcie de nivelul pe care ne plasm: 1.total aferent unei anumite polie, 2. total calculat pentru toate poliele de un anumit tip, 3. total general, pentru toate tipurile de asigurri, la nivel de raport. n seciunea Report Header, n expresiile ce reprezint sursele de date ale casetelor text aferente anului (txtAn) i categoriei de clieni (txtTipClient), au fost utilizai parametrii din interogarea ce st la baza raportului, astfel nct, dac au fost specificate, criteriile de filtrare a nregistrrilor vor fi afiate n antetul raportului. Astfel, n cazul celor dou controale, valorile proprietii Control Source au fost setate dup cum urmeaz: - pentru txtAn:
= IIF(ISNULL([Specificati anul]), "" , "Anul: " & [Specificati anul])
- pentru txtTipClient:
= IIF(ISNULL([Specificati tipul clientilor]), "" , IIF([Specificati tipul clientilor] = "PF", "Tip clienti: Persoane fizice", IIF([Specificati tipul clientilor]="PJ", "Tip clienti: Persoane juridice","")))
La deschiderea raportului, dup cum sunt, sau nu, furnizate valori pentru cei doi parametrii, anul i/sau tipul clienilor vor fi, sau nu, folosite drept criterii de filtrare a nregistrrilor ce constituie sursa de date a raportului. Spre exemplu, figura urmtoare prezint coninutul raportului n cazul n care se solicit situaia ncasrilor aferente persoanelor juridice, n 2009.
108
Studii de caz
VI.b) S se afieze poliele de asigurare ncheiate n anul curent, determinnd, la nivelul fiecrui tip de asigurare, valoarea total i cea medie a polielor, respectiv durata medie a perioadei de asigurare. Pentru rezolvarea acestei cerine se poate realiza un raport unic, bazat pe o interogare ce extrage toate datele necesare din tabelele n care acestea se afl, sau se poate recurge la o soluie ce implic utilizarea subrapoartelor, dup cum reiese din figura urmtoare:
Observaii: Sursa de date (proprietatea Record Source) a raportului principal este reprezentat de tabelul TipAsigurare, iar cea a subraportului Polie1, de urmtoarea cerere SQL:
Baze de date Access 2007 SELECT PolitaAsigurare.*, IIF(TipClient="PF", Nume & " " & Prenume, Denumire) AS Titular FROM Client INNER JOIN PolitaAsigurare ON Client.CodClient = PolitaAsigurare.CodClient WHERE YEAR(DataPolita) = YEAR(DATE());
109
Sincronizarea dintre sursa de date a raportului principal i cea subraportului Polite1 este realizat pe baza atributului comun CodAsigurare. Drept urmare, n cadrul raportului principal, vor fi setate urmtoarele proprieti ale obiectului subraport: - Link Master Fields: CodAsigurare - Link Child Fields: CodAsigurare n cadrul subraportului a fost inclus o caset-text ce permite afiarea numrului nregistrrii curente la nivelul sursei de date a subraportului, astfel c fiecrei polie i se va ataa un numr de ordine (1,2,3...). n seciunea Detail a raportului principal au fost plasate informaiile referitoare la tipurile de asigurri, precum i subraportul Polie1, ce conine datele de detaliu i totalurile aferente polielor propriu-zise. ntruct datele subraportului sunt corelate cu cele din raportul principal, reiese c poliele vor fi prezentate n mod grupat, iar valorile agregate calculate la nivelul subraportului vor corespunde unui anumit tip de asigurare, de la nivelul raportului. Agregarea la nivel general, de raport, a datelor privind poliele, nu este posibil ntruct atributele ale cror valori fac obiectul centralizrii nu sunt disponibile la nivelul raportului principal, ci doar al subraportului Polie1. n plus, funciile de grup, precum SUM, COUNT, AVG, MIN etc. nu admit ca argumente nume de controale, pentru a fi posibil agregarea valorilor disponibile n subraportul Polite1. Pentru a putea totui afia totalurile la nivelul raportului principal, n subsolul acestuia a fost plasat un al doilea subraport, Polite2, a crui unic menire este s furnizeze totalurile pentru ansamblul polielor. Sursa de date (proprietatea Record Source) a acestui subraport este reprezentat de urmtoarea interogare, ce returneaz poliele ncheiate la nivelul anului curent (conform cerinei):
SELECT PolitaAsigurare.* FROM PolitaAsigurare WHERE YEAR(DataPolita)=YEAR(DATE());
ntruct nu intereseaz datele de detaliu, aferente polielor individuale, ci doar valorile centralizate, singura seciune afiabil a subraportului Polie2 este Report Footer; aici au fost plasate casetele-text asociate, prin proprietarea Control Source, cu expresiile ce permit centralizri la nivelul sursei de date, n ansamblul su. n plus, avnd n vedere rolul i amplasarea subraportului Polie2 n cadrul raportului principal (seciunea Report Footer), ntre cele dou rapoarte nu trebuie i nici nu poate fi stabilit nici o corelaie; cu alte cuvinte, n cazul acestui subraport nu vor fi setate proprietile Link Master Field i Link Child Field.
110
Studii de caz
Figura urmtoare red modul n care este afiat raportul atunci cnd este deschis n vederea consultrii.
Studiu individual: S se realizeze rapoartele (i eventualele subrapoarte asociate acestora) care permit afiarea urmtoarelor informaii: a) Poliele aferente unui anumit tip de asigurare, specificat la deschiderea raportului; datele vor fi organizate pe ani i pe categorii de titulari (persoane fizice i juridice). b) Primele restante aferente polielor expirate, cu determinarea duratei efective a ntrzierii (pentru fiecare prim n parte), respectiv a duratei medii a ntrzierii (la nivel de poli, tip de asigurare i pe ansamblu).
111
Firma Specialistul SRL are ca obiect de activitate realizarea de cursuri de pregtire i perfecionare n domeniul limbilor strine. Se dorete realizarea unei baze de date pentru evidena operaiilor realizate n lei n cadrul casieriei. Zilnic se va realiza registrul de cas ce va conine data realizrii operaiei, explicaia operaiei, suma operaiei i tipul operaiei (ncasare sau plat) precum i numrul i tipul documentului (cec de numerar, chitana, foaie de vrsmnt, dispoziie de plata sau ncasare, state de salarii, etc.). Registrul de cas va conine soldul iniial al zilei, totalul sumelor ncasate, totalul sumelor pltite precum i soldul final al zilei. Fiecare operaie nregistrat n baza de date va primi un numr unic folosit la identificare. ncasrile pot s provin din vnzarea de serviciilor proprii (taxele cursanilor ce particip la cursurile de limbi strine) sau ridicri de numerar de la banc, aport de capital. Plile se pot face pentru achitarea drepturilor salariale, avansuri spre decontare, cumprri de bunuri, depuneri de numerar la banc. Operaiile sunt grupate pe categorii n funcie de sursa acestora, reinndu-se pentru fiecare operaie codul categoriei, denumirea acesteia i tipul. Principalele categoriile de operaii sunt taxa curani, ridicare numerar banca, aport capital, achitare drepturi salariale, avans spre decontare, cumprare bunuri, depunere de numerar la banc la care pot fi adugate ulterior (in timpul exploatrii bazei de date) i alte pli sau ncasri. O categorie special de operaii o reprezint avansurile spre decontare. Acestea trebuie sa fie justificate prin intermediul unor documente n cadrul deconturilor de cheltuieli. Pentru fiecare decont de cheltuieli este necesar reinerea numrului i datei acestuia, a documentelor (numr, data, suma, tip) ce justific cheltuirea avansului precum i a datelor titularului avansului. Pot s beneficieze de avansuri spre decontare salariaii firmei. Datele fiecrui salariat (nume, data natere, adres) vor fi nregistrate n cadrul bazei de date o singur dat, acesta fiind identificat cu ajutorul mrcii. Avansul neutilizat este restituit la casierie pe baza documentului de ncasare. Documentele justificate pentru avansuri se vor scana i se vor arhiva. Reguli de gestiune: O operaie este ncadrat ntr-o singur categorie, dintr-o categorie putnd face parte mai multe operaii. Un decont poate presupune mai multe operaii prin casierie (ridicare avans i posibile diferene), o operaie ce poate presupune ridicarea unui avans sau restituirea diferenelor este nregistrat pe un singur decont. Un decont de cheltuieli poate s conin mai multe documente justificativ, un document poate justifica cheltuielile de pe un singur decont. Un salariat poate avea mai multe deconturi, un decont aparinnd unui singur angajat.
VI
Baz de date pentru evidena operaiunilor efectuate prin casierie
112
Studii de caz
I. Realizai modelul realizai al bazei de date i implementai n MS Access Realizarea modelului relaional al bazei de date presupune parcurgerea mai multor etape. Plecnd de la informaiile de baz respectiv atributele, pe baza relaiilor stabilite ntre acestea (dependene funcionale) se realizeaz succesiv formele normalizate ale bazei de date (FN1, FN2, FN3). Trebuie stabilite n primul rnd atributele elementare i nerepetitive ce vor constitui baza procesului de normalizare. Deoarece baza de date va fi realizat cu ajutorul ACCESS 2007 se vor folosi noile funcionaliti ale acestuia i se va defini un cmp denumit FisierDocument n care se va reine fiierul ce conine copia documentului justificativ. Pe baza analizei cerinelor funcionale ale bazei de date se identific urmtorul dicionar preliminar al datelor:
NrOperatie, DataOperatiei, ExplicatieOperatie, SumaOperatie, TipOperatie, NrDocument, TipDocument, CodCategorie, DenCategorie, TipCategorie, NrDecont, DataDecont, NrDocJustificativAvans, DataDocJustificativAvans, SumaDocJustificativAvans, TipDocJustificativAvans, NumeSalariat, MarcaSalariat, DataNastereSalariat, AdresaSalariat, FisierDocument, TotalIncasariZilnice, TotalPlatiZilnice, SoldFinalZilnic, SoldIinitialZilnic.
Prin respectarea cerinelor impuse de ctre FN1, din dicionarul atributelor se vor elimina atributele calculate: TotalIncasariZilnice deoarece se calculeaz prin nsumarea sumelor ncasate zilnic TotalPlatiZilnice obinut prin nsumarea sumelor plilor zilnice SoldFinalZilnic obinut prin diferena ncasrilor i a plailor zilnice la care se adug soldul iniial. SoldInitialZilnic fiind de fapt soldul final al zilei precedente. TipOperatie are aceleai valori ca i TipCategorie respectiv ncasare sau plat. S-a optat pentru eliminarea atributului TipOperatie deoarece operaia este inclus ntr-o categorie, tipul ei fiind acelai cu cel al categoriei din care face parte. Respectnd cerinele impuse cheilor primare (unicitate, ireductibilitate) se identific n cadrul dicionarul atributelor urmtoarele atribute candidat: Atribut Candidat NrOperatie NrDecont CodCategorie NrDocJustificativ, TipDocJustificativ MarcaSalariat Descriere Acest atribut are valori unice, identificnd n mod unic o operaie. Fiecare decont este numerotat n mod unic. Acest atribut are valori unice, identificnd n mod unic o categorie de operaii. Pot exista mai multe tipuri de documente justificative, numerele fiind unice n cadrul acestor tipuri. Reprezint atributul pe baza cruia este identificat un salariat
113
Urmtoarea etap n cadrul normalizrii o reprezint identificarea dependenelor funcionale. Este recomandat ca din mulimea dependenelor funcionale s se rein doar cele n care determinatul este cheie primar. La nregistrarea unei operaii i se atribuie un numr unic existnd dependene funcionale ntre atributul NrOperatie i atributele ExplicatieOperatie, SumaOperatie, NrDocument, TipDocument. Deoarece o operaie este ncadrat ntr-o singur categorie, exist dependene funcionale ntre atributul NrOperatie i atributele CodCategorie, DenCategorie, TipCategorie. O operaie este nregistrat doar pe un singur decont, existnd dependene funcionale ntre atributul NrOperatie i atributele NrDecont, DataDecont. O operaie de tipul acordare avans sau restituire diferene se realizeaz pentru singur salariat existnd o dependen funcional ntre atributul NrOperatie i atributul MarcaSalariat i dependene funcionale tranzitive ntre atributul NrOperatie i atributele NumeSalariat, DataNastereSalariat, AdresaSalariat. Fiecare decont este numerotat n mod unic, atributul NrDecont implicnd funcional atributul DataDecont . Pentru c un decont aparine unui singur angajat exist dependene funcionale ntre atributul NrDecont i atributele NumeSalariat, MarcaSalariat, NumeSalariat, DataNastereSalariat, AdresaSalariat. Un document poate justifica cheltuielile de pe un singur decont, acest lucru genernd dependene funcionale totale ntre grupul de atribute NrDocJustificativ, TipDocJustificativ i atributele NrDecont, DataDecont. Pentru fiecare document trebuie memorate data, suma i fiierul ce conine arhiva electronic existnd dependene funcionale totale ntre grupul de atribute NrDocJustificativ, TipDocJustificativ i atributele DataDocJustificativ, SumaDocJustificativ, FisierDocument. Figura urmtoare ilustreaz dependenele funcionale:
114
Studii de caz
Pentru simplificare n scop didactic s-au reprezentat n cadrul matricei dependenelor funcionale doar dependenele funcionale totale i dependenele funcionale tranzitive n care determinatul este cheie primar, nereprezentndu-se dependenele funcionale multivaloare sau cele pariale.
Analiznd dependenele funcionale se observ existena dependenelor funcionale tranzitive. Prin eliminarea acestora se obin tabelele ce respect forma normal trei.
Categorie (CodCategorie, DenCategorie, TipCategorie) Salariat (MarcaSalariat, NumeSalariat, AdresaSalariat, DataNastereSalariat) Decont (NrDecont, DataDecont, MarcaSalariat) Operatie (NrOperatie, DataOperatiei, SumaOperatie, ExplicatieOperatie, NrDocument, TipDocument, NrDecont, CodCategorie) DosumentJustificativ (NrDocJustificativ, TipDocJustificativ, DataDocJustificativ, SumaDocJustificativ, NrDecont, FisierDocument)
Implementarea n ACCESS 2007 a tabelelor i a relaiilor dintre acestea este prezentat n figura urmtoare:
115
Studiu individual: Se dorete extinderea activitii firmei, operaie ce necesit realizarea operaiunilor prin casierie i n valut. Evidena operativ a numerarului n devize se ine cu ajutorul Registrul de cas care va avea coloane att pentru ncasri, pli, sold n lei, ct i pentru asemenea operaii n devize. Pentru fiecare fel de valut se realizeaz cte un registru de cas. Este important s se rein n baza de date codul, denumirea valutei i cursul de schimb pentru fiecare operaie. O operaie se face ntr-o singur valut la un singur curs de schimb, ntr-o anumit valut putnd s se realizeze mai multe operaii. Adugai modelului relaional tabelul sau tabelele necesare pentru a permite memorarea datelor privind valuta i cursul de schimb aferent operaiilor din casierie.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Tipul categoriei va putea s aib doar dou valori ncasare sau plat, valori ce se vor alege dintr-o list derulant. Pentru realizarea listei derulante ce va conine valorile ncasare i plata se va folosi proprietatea Lookup Wizard a cmpului TipCategorie din tabelul Categorie. n cadrul ferestrei Lookup Wizard se va alege opiunea I will type in the values that I want, iar n cadrul etapelor ulterioare se introduc valorile ncasare i Plat.
II.b) Suma operaiei va avea valori cuprinse ntre 0 i 1000. Pentru a restriciona valorile cmpului suma operaie se va folosi proprietatea Validation Rule asociat acestui cmp din tabelul Operatie. Realizarea acestei restriciei referitoare la domeniul de valori acceptate de atributul SumaOperatie
116
Studii de caz
presupune atribuirea valorii between 0 and 1000 proprietii Validation Rule. Proprietatea Validation Text va conine mesajul personalizat de eroare afiat n cazul nerespectrii condiiei impus prin Validation Rule. II.c) Angajaii vor fi codificai n funcie de departamentul unde lucreaz. Marca angajatului va fi alctuit din 5 caractere primele 2 fiind codul compartimentului, iar ultimele trei reprezint numrul angajatului n cadrul departamentului. De exemplu angajatul cu marca CO005 lucreaz n departamentul contabilitate. S se realizeze un ablon de introducere a mrcii angajatului n acest format. Realizarea unui ablon de introducere a mrcii angajatului formatul dorit (dou caractere obligatorii alfabetice urmate de trei caractere obligatoriu numerice) se realizeaz cu ajutorul proprietii Input Mask. Pentru caractere obligatorii alfabetice se folosete simbolul L, iar pentru cele numerice obligatorii se folosete caracterul 0.
Valorile cmpului SumaOperatie trebuie s fie cuprinse ntre 0 i 1000.
Realizarea formatului de introducere a mrcii angajatului.
Studiu individual: a) Tipul documentului va putea s ia valorile DP, DI, C, FV, StatSalarii ce se vor alege dintr-o list derulant. b) Valoarea implicit pentru data operaiei s fie data curent.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze n coloane distincte sumele ncasate i cele restituite pentru fiecare din operaiile din categoriile "Avansuri spre decontare" i "Retur avans spre decontare". Se va folosi funcia IIF pentru a afia sumele ncasate (acelea pentru care tipul operaiei este ncasare) i sumele pltite (acelea pentru care tipul operaiei este plat). n cadrul seciunii Criteria pentru cmpul DenumireCategorie se vor introduce cele
117
dou condiii "Avansuri spre decontare", "Retur avans spre decontare" folosind operatorul OR.
III.b) S se afieze angajaii care n lunile ianuarie, februarie i martie ale anului 2007 au justificat sume totale mai mari de 200 Ron pe mai puin de 2 deconturi. Pentru condiia impus datei decontului s-a folosit operatorul BETWEEN. Datele calendaristice sunt marcate cu ajutorul caracterului #.
III.c) S se afieze sumele totale aferente operaiilor desfurate n anul 2007 grupate pe luni i categorii. Se va folosi o interogare de tipul analiz ncruciat (Crosstab Query). Pentru afiarea n rezultatul cererii a tuturor lunilor anului 2007 numerotate de la 1 la 12 se va folosi proprietatea Column Headings asociat obiectului de tip interogare ( Query). Funcia MONTH se folosete pentru extragerea lunii din data operaiei. Prin concatenarea tipului i denumirii categoriei folosind operatorul &se obin valorile unui nou cmp ce va avea eticheta Operaie.
118
Studii de caz
III.d) S se afieze soldurile iniiale pentru o anumita zi introdus ca parametru. Soldul iniial al unei zile se calculeaz prin nsumarea ncasrilor din care se scad totalul plailor pentru perioada precedent zilei introduse ca parametru. Totalul sumelor ncasate se calculeaz folosind funcia agregat SUM i funcia IIF astfel SUM(IIF([TipCategorie]="Incasare";[SumaOperatie];0)). n mod asemntor se calculeaz i totalul sumelor pltite.
Studiu individual: a) S se afieze numele i vrsta n ani a salariailor care au realizat deconturi de cheltuieli. b) S se afieze denumirile categoriilor pentru care n anul 2007 s-au realizat mai mult de 20 operaii. c) S se afieze numrul deconturilor de cheltuieli pe angajai i pe luni. Se va folosi o interogare de tipul analiz ncruciat (Crosstab Query).
119
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze tipurile de categorii de operaii. Un tip se va afia o singur dat.
SELECT DISTINCT TipCategorie FROM Categorie ORDER BY TipCategorie;
IV.b) S se afieze primele trei documente justificative cu cele mai mari sume. Pentru a afia doar primele trei documente se ordoneaz descresctor nregistrrile n funcie de sum i se folosete cuvntul cheie TOP urmat de numrul de nregistrri dorite.
SELECT TOP 3 * FROM DocumentJustificativ ORDER BY SumaDocJustificativ DESC
IV.c) S se afieze alfabetic categoriile de operaii ce fac parte din cadrul unui anumit tip introdus ca parametru. Valoarea parametrului este introdus prin intermediul unui control de tip list derulant denumit CmbTip din formularul Operatie. Referina la valoarea unui ctre un control al unui formular se realizeaz astfel [Forms]![NumeFormular]![NumeControl].
SELECT CodCategorie, DenumireCategorie FROM Categorie WHERE TipCategorie=[Forms]![Operatie]![CmbTip] ORDER BY TipCategorie;
IV.d) S se afieze lista operaiilor realizate ntre anumite date introduse ca parametru, evideniindu-se n coloane distincte sumele pltite i cele ncasate
SELECT NrOperatie, DataOperatie, ExplicatieOperatie, [TipDocument] & [NrDocument] AS Document, IIF([TipCategorie]="Incasare",[SumaOperatie],0) AS Incasare, IIF([TipCategorie]="Plata",[SumaOperatie],0) AS Plata FROM Categorie INNER JOIN Operatie ON Categorie.CodCategorie = Operatie.CodCategorie WHERE Operatie.DataOperatie Between [Datainceput] And [DataSfarsit] ORDER BY Operatie.DataOperatie;
IV.e) S se afieze numrul de salariai pe fiecare categorie de vrst.

SELECT COUNT(MarcaSalariat) AS Nr, YEAR(Date())-YEAR([DataNastereSalariat]) AS Varsta FROM Salariat GROUP BY YEAR(Date())-YEAR([DataNastereSalariat]);
IV.f) S se afieze categoriile de operaii pentru care suma total pentru anul 2007 a depit 500 RON. nregistrrile se vor ordona n funcie de valoarea total.
SELECT Categorie.CodCategorie, FIRST(DenumireCategorie) AS Denumire, SUM(Operatie.SumaOperatie) as SumaTotala FROM Categorie INNER JOIN Operatie ON Categorie.CodCategorie = Operatie.CodCategorie
120
Studii de caz
WHERE YEAR([DataOperatie])=2007 GROUP BY Categorie.CodCategorie HAVING SUM(SumaOperatie)>500 ORDER BY SUM(SumaOperatie) DESC;
IV.g ) S se afieze totalul sumelor justificate precum i operaiile efectuate prin casierie pentru fiecare decont. Se vor afia numrul decontului, data acestuia, total sume justificate sau suma operaiei (coloana denumita Suma), tipul categoriei operaiei (pentru sumele totale justificate se va afia Justificare), denumirea categoriei din care face parte operaia (pentru sumele totale justificate se va afia Justificare avans), pentru sumele totale justificate i pentru operaiile de tip ncasare se va afia n coloana separata semnul +1, iar pentru operaiile de tip plat semnul -1. n ultima coloana denumit Total se va afia produsul dintre suma total justificat sau suma operaiei i semnul +1 sau -1. Deoarece trebuie reunite informaii ce se pot obine folosind cereri distincte se folosete operatorul UNION. Numrul de coloane din fiecare cerere ce participa la reuniune cu ajutorul operatorului UNION trebuie s fie acelai. Prima cerere va returna suma total justificata pe fiecare decont afind numrul i data decontului, suma total calculat cu ajutorul funciei SUM, tipul operaiei fiind Justificatoare, coloana Descriere afind mesajul Justificare avans, semnul este +1, iar coloana Total se obine prin preluarea valorii sumei totale. Ce de a doua cerere afieaz lista operaiilor participante la decont.
SELECT Decont.NrDecont, FIRST(DataDecont) AS Data,SUM(SumaDocJustificativ) AS Suma, "Justificatore" AS Tip, "Justificare avans" AS Descriere, "+1" AS Semn, SUM(SumaDocJustificativ) AS Total FROM Decont INNER JOIN DocumentJustificativ ON Decont.NrDecont = DocumentJustificativ.NrDecont GROUP BY Decont.NrDecont UNION SELECT Decont.NrDecont, DataOperatie AS Data, SumaOperatie AS Suma, TipCategorie, DenumireCategorie, IIf(TipCategorie="Incasare","+1","-1") AS Semn,Suma*Semn AS Total FROM Decont, Categorie, Operatie WHERE Decont.NrDecont=[Operatie].[NrDecont] AND Categorie.CodCategorie=[Operatie].[CodCategorie] ORDER BY Data;
IV.h) S se modifice explicaia operaiei generat de chitana numrul 45 din 12-072007, noua explicaie fiind Plata C 45
UPDATE Operatie SET ExplicatieOperatie = "Plata C 45" WHERE Operatie.NrDocument=45 AND Operatie.TipDocument="C" AND Operatie.DataOperatie=#7/12/2007#;
121
IV.i) S se afieze categoriile pentru care nu s-au realizat operaii n anul 2005.
SELECT * FROM Categorie WHERE CodCategorie NOT IN (SELECT Categorie .CodCategorie FROM Categorie INNER JOIN Operatie ON Categorie.CodCategorie = Operatie.CodCategorie WHERE YEAR([DataOperatie])=2005);
IV.j) S se afieze categoriile pentru care sunt efectuate cele mai multe operaii.
SELECT Operatie.CodCategorie, FIRST(DenumireCategorie) AS Denumire, COUNT(NrOperatie) AS Numar FROM Categorie INNER JOIN Operatie ON Categorie.CodCategorie = Operatie.CodCategorie GROUP BY Operatie.CodCategorie HAVING COUNT(NrOperatie) >=ALL (SELECT COUNT(Operatie.NrOperatie) FROM Categorie INNER JOIN Operatie ON Categorie.CodCategorie = Operatie.CodCategorie GROUP BY Operatie.CodCategorie);
Studiu individual: a) S se afieze cronologic toate operaiile pentru care documentul este de tip factur vnzare codificat FV b) S se afieze numrul de categorii de operaii pe fiecare tip de categorie. c) Afiai lunile din anul 2007 n care s-au justificat sume totale mai mari de 500 RON. d) S se afieze salariaii care n anul 2007 nu au beneficiat de deconturi de cheltuieli. e) S se afieze categoria de operaii pentru care n anul 2007 s-au efectuat tranzacii cu cea mai mare valoare total.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular cu subforumular pentru actualizarea deconturilor de cheltuieli, a avansurilor spre decontare i a documentelor justificative. Formularul principal va avea ca surs tabelul Decont, subformularul AvansuriDecontare va avea ca surs interogarea Avansuri_decontare rezolvat n cadrul cerinei III.a, iar subformularul DocumentJustificativ va avea ca surs tabelul cu acelai nume. Legtura dintre formular i cele doua subformulare se va realiza prin intermediul cheii primare respectiv externe NrDecont.
122
Studii de caz
Formular pentru actualizarea deconturilor de cheltuieli
n cadrul formularului principal se va realiza o list derulant ce permite selecia salariatului la care se refer decontul de cheltuieli. n cadrul subformularelor se vor afia totalurile avansurilor fr restituiri i respectiv totalul sumelor justificate. Calculul avansului total fr sumele restituite se realizeaz n cadrul seciunii Form Footer a subformularului AvansuriDecontare cu ajutorul unei casete text (control TextBox) pentru care valoarea Control Source va fi egal cu .Pentru acest control proprietatea Name va avea valoarea txtSuma Pentru calculul totalului sumelor justificate se va folosi un control de tip caset text( TextBox) pentru care valoarea Control Source va fi egal cu , iar valoarea proprietii Name va fi txtSumaJustificata. n cadrul formularului principal se vor prelua valorile celor dou controale txtSuma i txtSumaJustificata fcndu-se referire la numele subformularelor din care provin. Controalele formularului principal care vor prelua sumele totale date ca avans i cele justificate vor avea proprietatea Name egal cu txtSAvans, respectiv txtSJustificata. Afiarea mesajului diferen de ncasat sau diferen de pltit se realizeaz cu ajutorul funciei IIF astfel valoarea proprietii Control Source a controlului caset text ce va afia acest mesaj va fi egal cu
Pentru calculul sumelor ce trebuiesc restituite sau ncasate se va folosi funcia IIF. Controlul de tip caset text va avea proprietatea Control Source egal cu
Formularul pentru actualizarea deconturilor de cheltuieli n modul Design View este prezentat n figura urmtoare:
123
V.b) Realizai un formular pe baza tabelei operaie ce va permite actualizarea nregistrrilor din aceast tabel. Se va realiza un control de tip list derulant ce va permite alegerea tipului de operaie (ncasare sau plat). Proprietatea Name a acestui control va avea valoarea CmbTip. n funcie de tipul operaiei se va alege o categorie. Pentru ncasare se pot alege vnzarea de serviciilor proprii, ridicri de numerar de la banc, aport de capital sau alte ncasri, iar pentru pli se poate alege achitarea drepturilor salariale, avansuri spre decontare, cumprri de bunuri, depuneri de numerar la banc sau alte pli. Pentru selecia categoriei se va realiza o list derulant ce va avea ca surs interogarea rezolvat n cadrul cerinei IV.c. Proprietatea Name a acestui control va avea valoarea CmbCategorie.
124
Studii de caz
Pentru actualizarea valorilor controlului CmbCategorie .dup actualizarea valorilor controlului CmbTip se va folosi procedura urmtoare n cadrul evenimentului After Update asociat controlului CmbTip.
Private Sub CmbTip_AfterUpdate() Me.CmbCategorie.Requery End Sub
Studiu individual: a) S se realizeze un formular Startup ce va permite deschiderea formularelor realizate n cadrul aplicaiei.
b) S se realizeze un formular pe baza tabelului salariat ce permite actualizarea nregistrrilor. Se va realiza o list derulant ce va permite cutarea salariailor. Se vor aduga butoane de navigare, de tergere a unui angajat i de adugare a unei noi nregistrri precum i nchiderea formularului.
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se afieze registrul de cas ce va prezenta situaia zilnic a operaiilor realizate prin casierie ntre anumite date introduse ca parametru. Se vor afia pentru fiecare dat calendaristic soldul iniial (soldul final al zilei precedente), operaiile efectuate n acea zi (numr i tip document) sumele ncasate respectiv pltite precum i soldul final al zilei. Sursa acestui raport o constituie interogarea rezolvat la cerina IV.d. n cadrul raportului se vor grupa nregistrrile pe zile (data operaiei fiind cmpul de grupare).
125
Totalul ncasrilor zilnice se va calcula n cadrul seciunii DataOperatie Footer cu ajutorul unui control de tip caseta text pentru care proprietatea Control Source va avea valoarea =Sum([Incasare]). n acelai fel se va proceda i pentru calculul totalului plailor. Soldul final al zile se calculeaz astfel =Sum([Incasare][Plata])+[txtSI], unde txtSI este numele controlului caseta text n care s-a afiat valoarea soldului iniial al zilei Raportul Registru cas vizualizat n mod Design View este prezentat n figura urmtoare:
Pentru aflarea soldului iniial al unei anumite zile se realizeaz o funcie n cadrul unui modul VBA. Funcia va avea ca argument data pentru care se dorete calcularea soldului iniial. n cadrul acestei funcii se va defini o variabil de tip QueryDef care va corespunde interogrii SolduriInitiale rezolvat n cadrul cerinei III.d. O variabil de tip Recordset se va defini pentru a se face referire la obiectul Recordset ataat obiectului QueryDef "SolduriInitiale". n formular soldul iniial al unei zile este afiat cu ajutorul unei casete text amplasate n cadrul seciunii DataOperatie Header pentru care valoarea Control Source are valoarea =SoldInitial([DataOperatie]).
Public Function SoldInitial(data As Date) As Double
se declara o variabila de tip QueryDef
Dim q As QueryDef
se iniializeaz variabila de tip QueryDef cu obiectul de tip interogare SolduriInitiale
Set q = CurrentDb.QueryDefs("SolduriInitiale")
se atribuie valorile pentru parametrii interogrii
126 q.Parameters(0) = data

se declara o variabila de tip Recordset
Studii de caz
Dim rs As Recordset
se iniializeaz obiectul de tip recordset asociat interogrii
Set rs = q.OpenRecordset If Not rs.EOF Then

dac exist nregistrri ce corespund cerinelor, funcia va returna valoarea atributului SoldIZi
SoldInitial = Nz(rs("SoldZi")) Else

dac nu exist nregistrri ce corespund cerinelor, funcia va returna valoarea 0
SoldInitial = 0 End If End Function
VI.b) S se afieze situaia decontrilor pe salariai. Se vor afia pentru fiecare decont avansurile, retururile precum i sumele justificate i diferenele de ncasat sau restituit.
Raport ce prezint situaia decontrilor pe salariai
Sursa acestui raport o constituie interogarea rezolvat n cadrul cerinei IV.g. nregistrrile se vor grupa n funcie de numrul decontului. n cadrul seciunii NrDecont Header se va afia diferena de pltit sau ncasat prin nsumarea (figura urmtoare) valorilor cmpului Total din interogarea surs a raportului. Cmpul total nu se va afia n cadrul raportului, valoarea proprietii Visible fiind False.
127
Raport ce prezint situaia decontrilor pe salariai vizualizat n modul mod Design View
Studiu individual: a) S se realizeze un raport ce prezint cronologic lista operaiilor realizate ntre doua date introduse ca parametrii. Se va afia numrul curent al fiecrei operaii, numrul i tipul documentului, data operaiei, suma ncasat respectiv pltit. Se vor calcula totalurile ncasate, pltite i diferena dintre ncasri i pli.
b) S se realizeze un raport ce prezint situaia tuturor documentelor justificative. Se vor calcula totalul sumelor i numrul de documente.
128
Studii de caz
VII
Baz de date pentru gestiunea costurilor proiectelor
Avnd ca principal obiectiv consultan n domeniul economic, firma Consult SRL dorete realizarea unei baze de date pentru gestionarea costurilor proiectelor pe care le dezvolt. Atunci cnd se iniiaz un proiect este necesar reinerea titlului i a descrierii acestuia, precum i a datelor de nceput i de finalizare precum i a codului unic la nivelul firmei atribuit de sistem. Descrierea proiectului este completat cu ajutorul unei documentaii sub forma unei resurse electronice (fiier Word, document scanat, etc.). Resursele implicate n derularea proiectelor pot s fie ncadrate n doua categorii: umane, materiale. Pentru fiecare resursa implicat n desfurarea proiectului se va retine n sistem codul i denumire. Din fiecare resurs se va consuma n cadrul unui proiect un anumit numr de uniti de msura (ore lucrate pentru resursa uman, respectiv cantitatea de materiale folosite). Resursele materiale folosite n cadrul proiectelor pot s fie ncadrate n mai multe categorii (materiale, electronice, etc.). Costul unitar precum i tariful orar al resurselor consumate difer n funcie de proiect. De exemplu la proiectul intitulat Modaliti de perfecionare prin e-learning pentru personalul departamentului contabilitate vor colabora un expert contabil, un expert resurse umane, un analist IT i un manager de proiect ce lucreaz fiecare cte 20 ore, fiind pltii cu un tarif orar de 7 RON, 10 RON, 15 RON, respectiv 20 RON. n acelai proiect se vor consuma 2 topuri de hrtie al crui cost este de 8,63 RON i 1 toner imprimant ce cost 328,6 RON, n timp ce valoarea cheltuielile de regie (indirecte) este 1000 RON, iar alte cheltuieli n valoare de 44,3 RON. n funcie de complexitatea proiectului i resursele folosite, costul total al acestuia este obinut prin nsumarea costurilor totale pentru fiecare categorie de cheltuieli: cheltuielile directe (cu manopera, cu materialele) i cheltuielile indirecte. Cheltuielile indirecte codificate n mod unic la nivelul firmei particip la calculul costului a mai multor proiecte, pentru fiecare n parte avnd o anumite valoare. Reguli de gestiune: n cadrul unui proiect se consum mai multe resurse, o resurs poate s fie alocat mai multor proiecte, cantitatea (numrul de ore) i costul unitar (tariful) variind n funcie de proiect. Costul total al unui proiect se obine prin nsumarea costurilor categoriilor de cheltuieli participante (cu manopera, cu materialele, cheltuielile indirecte), cheltuielile indirecte particip la calculul costului a mai multor proiecte, pentru fiecare n parte avnd o anumit valoare.
129
I. Realizai modelul relaional al bazei de date i implementai n MS Access Realizarea modelului relaional al bazei de date presupune parcurgerea mai multor etape. Plecnd de la informaiile de baz respectiv atributele pe baza relaiilor stabilite ntre acestea (dependente funcionale) se realizeaz succesiv formele normalizate ale bazei de date (FN1, FN2, FN3). Trebuie stabilite n primul rnd atributele elementare i nerepetitive ce vor constitui baza procesului de normalizare. Deoarece baza de date va fi realizat cu ajutorul ACCESS 2007 se vor folosi noile funcionaliti ale acestuia i se va defini un cmp denumit Documentaie n care se vor retine fiierul ce conine descrierea proiectului. Pe baza analizei cerinelor funcionale ale bazei de date se identific urmtorul dicionar preliminar al datelor: Cod Proiect, Denumire Proiect, Descriere, Data nceput, Data Sfrit, Cod Resursa Umana, Denumire Resursa Umana, Cod Resursa Materiala, Denumire Resursa Materiala, Unitate Msur, Cod Cheltuiala indirecta, Denumire Cheltuiala indirecta, Cantitate, Numr Ore Lucrate, Tarif Orar, Cost Unitar, Cost Total Resursa Materiala Consumata, Cost Total Proiect, Valoare cheltuieli indirecte pe proiect, Valoare totala cheltuieli indirecte, Categorie Resursa Materiala, Documentaie. Prin respectarea cerinelor impuse de ctre FN1, din dicionarul atributelor se vor elimina atributele calculate Cost Total Resursa Materiala Consumata deoarece se calculeaz prin nmulirea cantitii cu costul unitar Cost Total Proiect obinut prin nsumarea valorilor tuturor cheltuielilor implicate n proiect Valoare totala cheltuieli indirecte calculat prin nsumarea valorilor tuturor cheltuielilor indirecte implicate n proiect Respectnd cerinele impuse cheilor primare (unicitate, ireductibilitate) se identific n cadrul dicionarul atributelor urmtoarele atribute candidat:
Atribut Candidat Cod Proiect Cod Resursa Umana Descriere Acest atribut are valori unice, identificnd n mod unic un proiect. Fiecare resurs uman implicat n desfurarea proiectelor va fi codificat n mod unic. Aceasta codificare se va folosi pentru fiecare implicare a acestei resurse n orice proiect. Fiecare resursa material implicat n desfurarea proiectelor va fi codificat n mod unic. Aceasta codificare se va folosi pentru fiecare utilizare a acestei resurse n orice proiect. Pentru fiecare proiect se pot folosi mai multe categorii de cheltuieli indirecte. Pentru identificarea uoar i clasificarea acestora se codific fiecare categorie.
Cod Resursa Materiala Cod Cheltuiala indirecta
130
Studii de caz
Urmtoarea etap n cadrul normalizrii o reprezint identificarea dependenelor funcionale. Este recomandat ca din mulimea dependenelor funcionale s se rein doar cele n care determinatul este cheie primar. Deoarece la iniierea unui proiect i se atribuie un cod unic ce l va identific n mod unic, exist dependente funcionale ntre atributul Cod Proiect i atributele Denumire Proiect, Descriere, Data nceput, Data Sfrit i Documentaie. Fiecare resurs uman implicat n desfurarea proiectelor va fi codificat n mod unic, acest lucru determinnd dependen funcional ntre atributele Cod Resursa Umana i Denumire Resursa Umana. Atributul Cod Resursa Materiala va determina funcional atributele Denumire Resursa Materiala, Unitate Msur i Categorie Resursa Materiala. Fiecare categorie de cheltuieli indirecte( n afara de cele generate de resursele umane sau materiale) va fi identificat cu ajutorul atributului Cod Cheltuiala indirecta ce va determina funcional atributul Denumire Cheltuiala Indirecta. Cantitatea dintr-o resurs (numrul de ore) i costul unitar (tariful) variaz n funcie de proiect determinnd dependena funcional total ntre grupul de atribute Cod Proiect, Cod Resursa Umana i atributele Numr Ore Lucrate, Tarif Orar precum i ntre grupul de atribute Cod Proiect, Cod Resursa Materiala i atributele Cantitate i Cost Unitar. Pentru fiecare proiect se pot folosi mai multe categorii de cheltuieli indirecte, fiecare n parte avnd o anumite valoare. Dependene funcionale funcionale sunt evideniate n figura urmtoare:
Pentru simplificare n scop didactic s-au reprezentat n cadrul matricei dependenelor funcionale doar dependenele funcionale totale n care determinatul este cheie primar, nereprezentndu-se dependenele funcionale multivaloare, dependenele funcionale tranzitive sau cele pariale. Matricea dependenelor funcionale este prezentat pe pagina urmtoare:
131
Analiznd dependenele funcionale se observa ca nu exist dependene funcionale tranzitive obinndu-se astfel tabelele ce respect forma normal trei.
Proiecte (CodProiect, DenumireProiect, Descriere, DataInceput, DataSfarsit, Documentatie) CheltuieliIndirecte (CodCheltuialaIndirecta, DenumireCheltuialaIndirecta) CheltuieliIndirecteProiect (CodProiect, CodCheltuialaIndirecta, ValoareCheltuialaIndirecta) ResurseUmane (CodResursaUmana, DenumireResursaUmana) ResurseUmaneProiect (CodProiect, CodResursaUmana, NumarOreLucrate, TarifOrar) ResurseMateriale (CodResursaMateriala, DenumireResursaMateriala, UnitateMasura, CategorieResursaMateriala) ResurseMaterialeProiect (CodProiect, CodResursaMateriala, Cantitate, Cost Unitar)
Implementarea modelului n Microsoft Access este prezentat n figura din pagina urmtoare.
132
Studii de caz
Studiu individual: Beneficiarii proiectelor pot s fie persoane fizice sau juridice pentru care trebuie reinut n sistem denumirea i tipul. Fiecare beneficiar va fi codificat, codul ajutnd la identificarea ulterioar a acestuia. Un beneficiar poate avea mai multe proiecte, un proiect este realizat pentru un singur beneficiar. Adugai modelului relaional tabelul sau tabelele necesare pentru a permite memorarea datelor aferente beneficiarilor proiectelor.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Data nceput trebuie s fie anterioar datei de finalizare a proiectului. II.b) Valoarea cheltuielilor indirecte trebuie s fie pozitiv. II.c) Data de nceput a unui proiect s aib valoare implicit data curent. Restriciile ce presupun implicarea mai multor cmpuri din cadrul aceluiai tabel se vor implementa n cadrul proprietilor tabelului la Validation Rule.
Implementarea restriciei data nceput anterioar datei de finalizare la nivelul tabelului Proiect
133
Pentru ca data de nceput a proiectului s fie implicit data curent se va folosi funcia Date() n cadrul proprietii Default Value. Restricia asupra valorilor unui singur atribut din cadrul unui tabel se implementeaz la proprietatea Validation Rule a acelui atribut .
Implementarea restriciei Valoare Cheltuieli Indirecte pozitiv
Valoare implicita pentru atributul Data nceput
Studiu individual: a) Valorile pentru unitatea de msur s se poat selecta dintr-o list derulant ce conine cele mai utilizate valori (bucat, kg, litru), lsnd posibilitatea adugrii ulterioare i a altor valori. b) Cantitatea, numrul de ore lucrate precum i costul materialelor trebuie s admit doar valori pozitive c) Tariful orar trebuie sa se ncadreze ntre 10 i 150.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze sptmnile n care sunt programate s nceap proiectele
134
Studii de caz
III.b) S se afieze suma total a cheltuielilor indirecte pentru proiectele ncepute n lunile ianuarie sau februarie 2005 n care sunt implicate mai mult de dou tipuri de cheltuieli indirecte. Modalitatea de referire la o dat calendaristic difer n funcie de setrile regionale ale fiecrui calculator.
III.c) S se afieze situaia costurilor resurselor materiale pe categorii i proiecte. Se va folosi o cerere de tip analiz ncruciat (Crosstab Query).
III.d) S se creeze un tabel ce conine denumirea i codul proiectele n cadrul crora nu sunt implicate cheltuieli materiale. Aceasta interogare este o interogare de aciune Make Table. Pentru realizarea acesteia se apas butonul
aflat n cadrul grupului Query
Specificarea numelui tabelului ce se va crea prin
135
Type din meniul Design.
intermediul interogrii de tip Make Table
Pentru a afia toate proiectele cele ce au precum i cele ce nu au cheltuieli materiale trebuie schimbat tipul legturii dintre tabelele Proiect i ResurseMaterialeProiect..
Proprietile relaiei dintre tabele Proiect i ResurseMaterialeProiect
Studiu individual: a) S se afieze numrul de proiecte pe ani de ncepere i de finalizare. Se va folosi o cerere de tip analiz ncruciat. b) S se afieze proiectele n care sunt implicate mai mult de 3 resurse materiale ce nu sunt din categoria echipamente. c) Sa se creeze un tabel ce conine denumirea i codul cheltuielilor indirecte neutilizate n cadrul proiectelor.
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze categoriile resurselor materiale. O categorie se va afia doar o singur dat
SELECT DISTINCT ResurseMateriale.CategorieResursaMateriala FROM ResurseMateriale;
IV.b) S se afieze durata proiectului n luni i zile. n funcie de perioada de desfurare se va afia categoria proiectului astfel: proiect pe termen scurt dac perioada este mai mica de 2 luni, altfel fiind ncadrat n categoria proiectelor pe termen lung) Funcia DateAdd permite adugarea unei valori numerice la o anumita dat calendaristic obinndu-se tot o dat. Funcia DateDiff permite calcularea diferenei ntre dou date calendaristice, aceast diferen fiind afiat n zile (caz n care se folosete valoarea d pentru parametrul funciei) sau luni (ceea ce implic folosirea parametrului m).
136
Studii de caz
SELECT CodProiect, DATEDIFF("m",[DataInceput],[DataSfarsit]) AS NrLuni, [DataSfarsit]-DateAdd("m",[NrLuni],[DataInceput]) AS NrZile, IIF([Nrluni]<=2,"termen scurt","termen lung") AS Tip FROM Proiecte
IV.c) S se afieze proiectele n care s-au folosit resurse materiale din categoria echipamente
SELECT Proiecte.CodProiect, DenumireProiect FROM ResurseMateriale, Proiecte, ResurseMaterialeProiect WHERE CategorieResursaMateriala="Echipamente" AND Proiecte.CodProiect = ResurseMaterialeProiect.CodProiect AND ResurseMateriale.CodResursaMateriala = ResurseMaterialeProiect.CodResursaMateriala
IV.d) S se calculeze totalul cheltuielilor indirecte pentru fiecare proiect

SELECT CodProiect, SUM(ValoareCheltuieliIndirecte) AS CostChInd FROM CheltuieliIndirecteProiect GROUP BY CodProiect;
IV.e) S se afieze denumirea primelor cinci resurse umane ce au cel mai mare cost total. Costul total se obine prin nsumarea valorilor costurilor pentru fiecare proiect la care a participat. Costul unei resurse este obinut pe baza tarifului orar i a numrului de ore lucrate. Pentru a afia doar primele cinci resurse se ordoneaz descresctor nregistrrile n funcie de costul total pe resurs i cu ajutorul cuvntului cheie TOP urmat de numrul de nregistrri dorite.
SELECT TOP 5 ResurseUmane.CodResursaUmana, FIRST(DenumireResursaUmana) as ResursaUmana, SUM([NumarOreLucrate]*[TarifOrar]) AS CostResursaUmana FROM ResurseUmane INNER JOIN ResurseUmaneProiect ON ResurseUmane.CodResursaUmana = ResurseUmaneProiect.CodResursaUmana GROUP BY ResurseUmane.CodResursaUmana ORDER BY SUM([NumarOreLucrate]*[TarifOrar]) DESC;
IV.f) S se afieze toate resursele implicate (resurse umane, materiale) i cheltuielile indirecte implicate n cadrul proiectelor. Se va afia codul proiectului, denumirea resursei, costul resursei i tipul resursei (uman, material, cheltuial indirect). nregistrrile ce vor fi afiate ca rezultat al acestei cereri provin din trei tabele diferite folosindu-se pentru a rezolva aceasta cerin operatorul UNION. Ordonarea s-a fcut global pentru ntregul set de nregistrri n funcie de codul proiectului i tipul resurselor.
SELECT CodProiect, DenumireResursaMateriala, [Cantitate]*[CostUnitar] AS CostResursa, "Resursa materiala" as Tip FROM ResurseMateriale INNER JOIN ResurseMaterialeProiect ON ResurseMateriale.CodResursaMateriala = ResurseMaterialeProiect.CodResursaMateriala UNION SELECT CodProiect, DenumireResursaUmana, [NumarOreLucrate]*[TarifOrar] AS CostResursa, "Resursa umana" as Tip
137
FROM ResurseUmane INNER JOIN ResurseUmaneProiect ON ResurseUmane.CodResursaUmana = ResurseUmaneProiect.CodResursaUmana UNION SELECT CodProiect, DenumireCheltuialaIndirecta, ValoareCheltuieliIndirecte AS CostResursa, "Cheltuiala indirecta" as Tip FROM CheltuieliIndirecte INNER JOIN CheltuieliIndirecteProiect ON CheltuieliIndirecte.CodCheltuialaIndirecta = CheltuieliIndirecteProiect.CodCheltuialaIndirecta ORDER BY CodProiect ,Tip
IV.g) S se adauge proiectul avnd codul CJ5698 denumit Modaliti de perfecionare a managementului proiectelor pentru care data de ncepere este 1-122007 i data de finalizare este 25-6-2008. Pentru a aduga date n cadrul unui tabel pe lng numele tabelului se vor preciza numele cmpurilor i valorile acestora. Pentru valorile de tip text se vor folosi ghilimelele () iar pentru date calendaristice se vor folosi caracterele diez (#) pentru a delimita valoarea acesteia.
INSERT INTO Proiecte ( CodProiect, DenumireProiect, DataInceput, DataSfarsit ) VALUES ("CJ5698", "Modaliti de perfecionare a managementului proiectelor", #1/12/2007#, #6/25/2008#)
IV.h) S se mreasc cu 10% tariful orar pentru resursele umane implicate n proiectele ce au nceput n martie 2005 i au o durat mai mic de 30 zile . Am folosit pentru a rezolva aceasta cerin o interogare de tip aciune combinat cu o subinterogare ce are drept scop selecia proiectelor ncepute n martie 2005 cu o durat mai mic de 30 zile. Funciile Month i Year extrag luna, respectiv anul dintr-o dat calendaristic.
UPDATE ResurseUmaneProiect SET TarifOrar = TarifOrar*1.1 WHERE CodProiect IN (SELECT Proiecte.CodProiect FROM Proiecte INNER JOIN ResurseUmaneProiect ON Proiecte.CodProiect = ResurseUmaneProiect.CodProiect WHERE MONTH(DataInceput)=3 AND YEAR(DataInceput)=2005 AND DataSfarsitDataInceput=30 )
IV.i) S se tearg resursele umane neimplicate n nici un proiect. Resursele umane care nu participa la nici un proiect sunt acelea al cror cod se regsete n tabela ResurseUmane i nu apare n tabela ResurseUmaneProiect.
DELETE * FROM ResurseUmane Where CodResursaUmana NOT IN (SELECT CodResursaUmana FROM ResurseUmaneProiect)
IV.j) S se afieze codurile i denumirile proiectelor derulate n anul 2007 avnd valoarea total a cheltuielilor materiale mai mare dect o valoare introdus ca parametru. n cadrul unui proiect sunt consumate mai mute resurse materiale. Pentru a calcula totalul costurilor materiale pe proiect se va folosi funcia agregat SUM.
138
Studii de caz
SELECT Proiecte.CodProiect, FIRST(DenumireProiect) AS Denumire, SUM([Cantitate]*[CostUnitar]) AS [Cost Resurse Materiale] FROM Proiecte, ResurseMateriale ,ResurseMaterialeProiect WHERE Proiecte.DataInceput>=#1/1/2007# AND Proiecte.DataSfarsit<=#12/31/2007# AND ResurseMateriale.CodResursaMateriala = ResurseMaterialeProiect.CodResursaMateriala AND Proiecte.CodProiect = ResurseMaterialeProiect.CodProiect GROUP BY Proiecte.CodProiect HAVING SUM([Cantitate]*[CostUnitar])>=[Introduceti valoarea]
Studiu individual: a) S se afieze proiectele ncepute ntre anumite date introduse ca parametrii. b) S se afieze pentru fiecare proiect stadiul desfurrii (n desfurare, finalizat sau nenceput). Observaie se va folosi funcia IIF. c) S se afieze numrul de resurse materiale pe categorii. d) S se afieze codurile i denumirile proiectelor ncepute n anul 2007 avnd valoarea total a cheltuielilor resurselor umane mai mare dect 200. e) S se tearg proiectele finalizate care nu implic nici un fel de resurse.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular cu subformular pentru a introduce detaliile unui proiect precum i costurile principalelor resurse implicate n dezvoltarea acestuia. Formularul principal va actualiza tabelul Proiect i va avea trei subformulare pentru actualizarea resurselor materiale (tabel ResurseMaterialeProiect), a celor umane (tabel ResurseUmaneProiect) i a cheltuielilor indirecte (tabel CheltuieliIndirecteProiect) implicate n proiect. Se va realiza o list derulant ce permite cutarea rapid a unui anumit proiect. Fiind necesar afiarea mai multor categorii de informaii precum i sintetizarea acestora (afiarea costurilor totale din fiecare categorie) se va folosi un control de tip Tab (figura urmtoare). Controale disponibile n cadrul Microsoft ACCESS 2007 se regsesc uor n meniul Design n categoria Controls.
139
Formularul ce permite gestionarea costurilor proiectelor
Realizarea subformularelor se face cu ajutorului controlului Subform/ Subreport din cadrul grupului de butoane Controls din meniul Design. Proprietatea Default View a subformularelor va avea valoarea Datasheet.
Controlul Subform/ Subreport
Realizarea subformularului ResurseUmaneProiect
Legtura dintre formularul principal (Proiect) i subformularul ResurseUmaneProiect se face prin intermediul cmpului CodProdus. Deoarece valoarea codului de proiect se va afia n cadrul formularului principal nu mai este necesar afiarea acestei valori i n cadrul subformularului. n subformulare se vor realiza liste derulante pentru cheile externe. n cazul subformularului ResurseUmaneProiect afiarea costul fiecrei resursei umane implicate n proiect se realizeaz cu ajutorul unui control caseta text (TextBox )a crui proprietate ControlSource este . Numrul total al orelor lucrate se calculeaz n cadrul subsolului formularului (seciunea Form Footer) cu ajutorul unei casete text (TextBox) pentru care proprietatea ControlSource este .
140
Studii de caz
Pentru a se putea prelua valoarea numrului total de ore n cadrul formularului principal, controlul caset text se va redenumi txtTotalOre.
Subformular ResurseUmaneProiect afiat n modul Design View
Costul total al resurselor umane se calculeaz n cadrul subsolului formularului ResurseUmaneProiect (seciunea Form Footer) cu ajutorul unei casete text( TextBox) pentru care proprietatea ControlSource este . Pentru a se putea prelua aceasta valoare n cadrul formularului principal controlul caseta text se va redenumi txtTotalCostRU. In formularul principal, ce permite editarea proiectelor, pentru afiarea numelui i codului proiectului se folosete un control de tip Text Box pentru care proprietatea . Control Source va avea valoarea Pentru afiarea n cadrul formularului principal a valorilor totale ale costurilor resurselor umane, materiale i cheltuielilor indirecte se vor folosi casete text (Text Box) pentru care proprietatea Control Source va avea valoarea =[NumeSubformular].[Form]![NumeControlSubformular] . n cazul n care un proiect nu are cheltuieli dintr-o anumita categorie (uman, material sau indirecte) n cadrul costului total acestea au pondere 0. Pentru a converti valoare NULL la valoarea 0 se folosete funcia NZ.
141
Calculul costului total al resurselor materiale n cadrul subformularului ResurseUmaneProiect i preluarea acestuia n cadrul formularului principal Proiecte( vizualizare n modul Design View).
Realizarea listei derulante ce permite cutarea rapid a unui contract se realizeaz cu ajutorul controlului ComboBox (figura precedent). n cadrul ferestrei Combo Box Wizard se alege opiunea Find a record on my form based on the value I selected in my combo box (figura urmtoare). Se aleg cmpurile CodProeict i DenumireProiect pentru a fi afiate n list i se adaug eticheta vizibil pe formular.
Fereastra Combo Box Wizard
Selecia cmpurilor pentru lista derulant ce permite cutarea unui proiect
142
Studii de caz
V.b) Realizai un formular ce va permite selectarea unui proiect dintr-o list derulant i exportul bugetului acestuia n MS Excel.
Formularul AfisareBugetRaport ce permite exportul bugetului unui proiect n MS Excel
Formularul (denumit AfisareBugetRaport) conine o list derulant (control de tip ComoBox a crui nume este CmbProiecte) ce afieaz codul i denumirea proiectelor. Evenimentului On Click aferent butonului Btnexport i se va ataa obiectul MacroExport. Acest obiect realizeaz urmtoarea succesiune de activiti: Deschidere interogare (Query) BugetProiect (cerina IV.f ) Selecteaz doar nregistrrile al cror cod de proiect este egal cu cel selectat n lista derulant. Executa comanda de export n MS EXCEL. nchide interogarea BugetProiect.
Studiu individual: a) S se realizeze un formular ce permite actualizarea cheltuielilor materiale. b) S se realizeze un formular de tip PivotChart ce va prezenta grafic structura cheltuielilor n cadrul proiectelor. (Observaie Sursa formularului este interogarea din cadrul cerinei IV.f )
143
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) Afiarea bugetului pentru un anumit proiect ales dintr-o list derulant.
Sursa raportului o constituie interogare (Query) BugetProiect (cerina IV.f ). n cadrul raportului vor fi afiate toate cmpurile sursei de date. Datelor vor fi afiate grupat n funcie de codul proiectului i de tipul cheltuielilor.
Fereastra Report Wizard n care se selecteaz sursa raportului i cmpurile acestuia
Nivelurile de grupare n cadrul raportului
Pentru calculul totalului cheltuielilor pe fiecare tip n cadrul seciunii Tip Header se folosete o caseta text( control de tip TextBox) pentru care valoarea proprietii ControlSource este . Aceiasi proprietate va avea i controlul caseta text folosit n cadrul sectiunii CodProiect Header dar efectul va fi calculul valorii costului total pe proiect (figura urmtoare).
144
Studii de caz
Numerotarea tipurilor de cheltuielilor n cadrul unui proiect se va face cu ajutorul unul control de tip TextBox pentru care proprietatea ControlSource are valoarea =1, iar proprietatea Running Sum are selectat valoarea OverGroup.
Raportul Buget Proiecte vizualizat n modul Design View
Deschiderea raportului se realizeaz la declanarea evenimentului On Click al butonului btnAfisRaport de pe formularul AfisareBugetRaport( realizat n cadrul cerinei V b). Pentru a se afia doar datele referitoare la proiectul selectat n lista derulant de pe formular, proprietatea Filter a raportului va avea valoarea . n cazul n care nu exista informaii despre bugetul unui proiect se va afia un mesaj de eroare, raportul numai fiind afiat. Se va folosi n acest scop evenimentul NoData al raportului pentru care se va aduga urmtorul cod VBA.
Private Sub Report_NoData(Cancel As Integer)
afisare mesaj de eroare
MsgBox "Nu exista informatiile cerute!"

anulare afiare raport
Cancel = 1 End Sub
145
VI.b) Afiarea listei resurselor umane implicate n proiecte. Sursa raportului o constituie tabelul ResurseUmane. n seciunea Report Footer se va calcula numrul de nregistrri afiate n raport cu ajutorul unei casete text (control TextBox) pentru care proprietatea ControlSource are valoarea
Raportul ce afieaz lista resurselor deschis n modul Design View
Studiu individual: a) S se realizeze un raport ce va afia calendarul nceperii proiectelor
b) S se realizeze un raport ce va afia lista resurselor materiale pe categorii
146
Studii de caz
Baz de date pentru evidena personalului

Se dorete realizarea unei baze de date pentru evidena salariailor. Angajaii vor fi nregistrai o singur dat n cadrul bazei de date. Pentru identificare fiecare angajat va primi un cod unic denumit marca angajat. n baza de date se vor memora numele, data natere, telefonul, vrsta. Salariu de ncadrare poate varia lunar, reinndu-se data modificrii i noul cuantum al salariului. Venitul lunar net este obinut prin diminuarea salariului de ncadrare cu eventuale reineri aferente acelei luni. O categorie de reineri poate s se aplice mai multor salariai. Reinerile sunt un procent din salariul de ncadrare i sunt specifice fiecrui salariat. Se vor retine n baza de date denumirea reinerii, procentul reinerii precum i perioada pentru care se aplic (data nceput, data de sfrit). Fiecare categorie de reinere memorat n baza de date se va codifica. Angajai sunt organizai n departamente. Departamentele vor avea un cod unic folosit pentru identificare. Angajaii pot s lucreze n decursul timpului n cadrul unui singur departament sau a mai multora. Trebuie reinut n baza de date data nceperii activitii pentru fiecare departament n care i-a desfurat sau i desfoar activitatea. Alocarea sarcinilor se va face innd cont de vechimea angajatului n cadrul departamentului i de pregtirea profesional a fiecruia. Pentru fiecare angajat se vor reine n baza de date detalii legate de pregtirea profesional, adic denumirile studiilor i stagiilor la care a participat, datele de finalizare i tipul acestora. Fiecare etap a pregtirii profesionale a unui angajat va fi identificat cu ajutorul unui cod. Reguli de gestiune: Salariul de ncadrare al unui salariat se poate modifica n timp. Fiecare salariat poate s nu aib reineri sau s aib mai multe reineri, o reinere putndu-se aplica mai multor salariai ( unei categorii de salariai). Procentele de reinere sunt specifice fiecrui salariat i se aplic salariului de ncadrare. Angajaii pot s lucreze n decursul timpului n cadrul unui singur departament sau a mai multora. n cadrul unui departament pot s lucreze mai muli angajai Un angajat poate avea mai multe studii sau stagii de pregtire. I. Realizai modelul realizai al bazei de date i implementai n MS Access Realizarea modelului relaional al bazei de date presupune parcurgerea mai multor etape. Plecnd de la informaiile de baz respectiv atributele, pe baza relaiilor stabilite ntre acestea (dependene funcionale) se realizeaz succesiv formele normalizate ale bazei de date (FN1, FN2, FN3). Trebuie stabilite n primul rnd atributele elementare i nerepetitive ce vor constitui baza procesului de normalizare. Deoarece baza de date va fi realizat cu ajutorul ACCESS 2007 se vor folosi noile funcionaliti ale acestuia i se va defini un cmp denumit Fotografie n care se va
VIII
147
reine fiierul ce conine fotografia salariatului. Pe baza analizei cerinelor funcionale ale bazei de date se identific urmtorul dicionar preliminar al datelor:
Marca, Nume, Telefon, DataNastere, Varsta, Fotografie, SalariuIncadrare, DataModificareSalariuIncadrare, CodRetinere, DenumireRetinere, ProcentRetinere, DataInceputReinere, DataSfritRetinere, SalariuNet, CodDepartament, DenumireDepartament, DataIncepereActivitate, VechimeAngajare, CodPregatireProfesionala, DenumirePregatireProfesionala, DataFinalizare, TipPregatire.
Prin respectarea cerinelor impuse de ctre FN1, din dicionarul atributelor se vor elimina atributele calculate Varsta se calculeaz pentru fiecare persoana n funcie de data curenta i data naterii SalariuNet se obine prin diminuarea salariului de ncadrare cu procentele aferente reinerilor VechimeAngajare se calculeaz pentru fiecare angajat n funcie de data curent i data de ncepere a activitii Respectnd cerinele impuse cheilor primare (unicitate, ireductibilitate) se identific n cadrul dicionarul atributelor urmtoarele atribute candidat din care se vor alege cheile primare: Atribut Candidat Marca CodRetinere Cod Departament CodPregatire Profesionala Descriere Acest atribut are valori unice, identificnd n mod unic un angajat Fiecare reinere este codificat n mod unic. La nivelul bazei de date fiecare departament are un cod unic. Reprezint atributul pe baza cruia este identificat un stagiu de pregtire profesional.
n etapa urmtoare se vor identifica dependenele funcionale n care determinatul este cheie primar. La nregistrarea unui angajat i se atribuie un cod unic existnd dependene funcionale ntre atributul Marca i atributele Nume, Telefon, DataNastere, Fotografie. Salariul de ncadrare al unui salariat se poate modifica la anumite date existnd dependene funcionale totale ntre grupul de atribute Marca, DataModificareSalariuIncadrare i atributul SalariuIncadrare. Pentru reinerea istoricului etapelor de pregtire profesional fiecare dintre acestea este codificat genernd astfel dependene funcional ntre atributul CodPregatireProfesionala i atributele DenumirePregatireProfesionala, DataFinalizare, TipPregatire. O etap de pregtire profesional corespunde unui singur angajat genernd dependena funcional ntre atributul CodPregatireProfesionala i atributele Marca, Nume, Telefon, DataNastere,
148
Studii de caz
Fotografie. Dependena dintre atributul CodPregatireProfesionala i atributele Nume, Telefon, DataNastere, Fotografie este tranzitiv. Istoricul reinerilor fiecrui angajat se va memora cu ajutorul unui tabel pentru care se va alege o cheie surogat IdRetinereSalariat. Exist o dependenta funcional ntre atributul IdRetinereSalariat i atributele Marca, CodRetinere, ProcentRetinere, DataInceputReinere, DataSfritRetinere. Angajaii pot s lucreze n decursul timpului n cadrul unui singur departament sau a mai multora, un angajat putnd reveni la unul din departamentele anterioare. Istoricul angajrii salariailor n cadrul departamentelor se va memora n cadrul unui tabel ce va avea drept cheie primar o cheie surogat IdAngajare, existnd o dependen funcional ntre atributul IdAngajare i Marca, CodDepartament i DataIncepereActivitate. Pentru simplificare n scop didactic s-au reprezentat n cadrul matricei dependenelor funcionale doar dependenele funcionale totale i dependenele funcionale tranzitive n care determinatul este cheie primar, nereprezentndu-se dependenele funcionale multivaloare sau cele pariale.
Matricea dependenelor funcionale
149
Graful dependenelor funcionale simple (nu s-au reprezentat dependentele tranzitive)
Analiznd dependenele funcionale se observ existena dependenelor funcionale tranzitive. Prin eliminarea acestora se obin tabelele ce respect forma normal trei.
Angajat (Marca, Nume, Telefon, DataNastere, Fotografie) IstoricSalariu (DataModSal, Marca, SalariuIncadrare) Retinere (CodRetinere, DenumireRetinere) RetineriSalariat (IdRetinereSalariat, Marca, CodRetinere, ProcentRetinere, DataInceputRetinere, DataSfarsitRetinere) Departament (CodDepartament, DenumireDepartament) AngajareSalariat (IdAngajare, CodDepartament, Marca, DataIncepereActivitate) Pregatire (CodPregatireProfesionala, DenumirePregatireProfesionala, DataFinalizare, TipPregatire, Marca)
Implementarea n ACCESS 2007 a tabelelor i a relaiilor dintre acestea
150
Studii de caz
Studiu individual: Fiecare salariat poate s beneficieze ntre anumite date de nceput i de sfrit de anumite sporuri sau prime, un spor putndu-se aplica unuia sau mai multor salariai. Procentele sporurilor sunt specifice fiecrui salariat i se aplic la salariu de ncadrare. La introducerea n baza de date fiecare categorie de sporuri sau prime (ce va avea o denumire) se va codifica. Adugai modelului relaional tabelul sau tabelele necesare pentru a permite memorarea datelor privind sporurile acordate salariailor i calcului sumelor totale datorate sporurilor.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Data sfrit reinere s fie mai mare dect data nceput reinere cu cel puin 30 zile Data de nceput i de sfrit sunt atribute ale tabelului RetineriSalariat. Restriciile ce implic mai mule cmpuri din cadrul aceluiai tabel se vor implementa n cadrul proprietilor tabelului la Validation Rule (figura urmtoare).
II.b) Procentul reinerii s fie cuprins ntre 0 i 15 % Realizarea restriciei referitoare la domeniul de valori acceptate de atributul ProcentRetinere presupune atribuirea valorii between 0 and 0,15 proprietii Validation Rule). Proprietatea Validation Text va conine mesajul personalizat de eroare afiat n cazul nerespectrii condiiei impus prin Validation Rule (rezolvarea pe pagina urmtoare). II.c) Codul departamentelor trebuie s conin maxim 5 caractere. Deoarece codul departamentului este limitat doar la 5 caractere proprietatea Field Size a acestui atribut va lua valoarea 5 (rezolvarea pe pagina urmtoare).
151
Proprietile atributului ProcentRetinere
Proprietile atributului CodDepartament
Studiu individual: a) Salariul ncadrare trebuie s aib valori ntre 300 i 3000. b) Tipul pregtirii s se poate selecta dintr-o list derulant ce conine valorile facultate, liceu, masterat, doctorat, stagiu pregtire, putndu-se aduga ulterior i alte valori.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se clasifice salariaii n funcie de vrsta n dou categorii: persoane pn n 35 ani i persoane peste 35 ani. Se va folosi funcia IIF pentru a afia tipul categoriei. Vrsta s-a calculat ca diferen ntre anul curent i anul naterii.
III.b) S se afieze procentul total al reinerilor pentru un salariat a crui marc se introduce ca parametru i pentru o anumit dat introdus tot ca parametru. O reinere poate s fie pe o perioad fix i n acest caz se cunosc datele de nceput sau finalizare sau poate s fie o perioada neterminat, cunoscndu-se doar data de nceput, data sfrit avnd valoarea NULL.
152
Studii de caz
III.c) S se afieze numrul angajailor pe tipuri de pregtire i ani de finalizare. Se va folosi o cerere de tip analiz ncruciat (Crosstab Query). Pe linie (Row Heading) se vor afia categoriile de pregtire profesional, iar pe coloana (Column Heading) se vor afia anii de absolvire obinui cu ajutorul funciei YEAR(). Numrul de angajai se va calcula cu ajutorul funciei agregate COUNT.
III.d) S se afieze reinerile care nu aparin nici unui salariat. Fiind necesar afiarea tuturor reinerilor trebuie schimbat tipul legturii dintre tabelele Retinere i RetineriSalariat. Din totalul nregistrrilor se vor selecta doar acelea pentru care valoarea atributului Marca este NULL.
Fereastra Join Proprieties
153
Studiu individual: a) S se afieze numele i vrsta n ani a angajailor care au lucrat sau lucreaz n cadrul departamentului contabilitate. b) S se afieze salariaii care n prima lun a lui 2006 au nregistrat procente totale ale reinerilor mai mari dect 20%. c) S se afieze angajaii care nu au avut i nu au nregistrate reineri.
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze tipurile de pregtire a angajailor. Fiecare tip se va afia doar o singur dat.
SELECT DISTINCT TipPregatire FROM Pregatire
IV.b) S se afieze prima liter cu care ncepe numele fiecrui angajat. Se va folosi funcia MID ce va permite extragerea caracterului de pe prima poziie a irului de caractere coninut de atributul Nume.
SELECT Marca, Angajat.Nume, Telefon, DataNastere, MID ([Nume],1,1) AS Litera FROM Angajat;
IV.c) S se afieze salariul de ncadrare la o dat introdus ca parametru pentru un angajat a crui marc se va introduce ca parametru.
PARAMETERS Data DateTime, MarcaAng Text ( 255 ); SELECT TOP 1 DataModSal, SalariuIncadrare, Marca FROM IstoricSalariu WHERE DataModSal<=[Data] AND Marca=[MarcaAng] ORDER BY IstoricSalariu.DataModSal DESC;
IV.d) S se afieze cronologic pregtirea profesional a fiecrui angajat finalizat dup data angajrii.
SELECT DISTINCT TipPregatire & " - " & DenumirePregatireProfesionala AS Pregatire, AngajareSalariat.Marca, DataFinalizare FROM Angajat , AngajareSalariat, Pregatire WHERE Angajat.Marca = AngajareSalariat.Marca AND Angajat.Marca = Pregatire.Marca AND DataIncepereActivitate<= DataFinalizare ORDER BY AngajareSalariat.Marca, DataFinalizare;
IV.e) S se afieze numrul angajailor pentru fiecare tip de pregtire profesional.

SELECT TipPregatire, COUNT(Angajat.Marca) AS NumarAngajati FROM Angajat INNER JOIN Pregatire ON Angajat.Marca = Pregatire.Marca GROUP BY TipPregatire;
IV.f) S se afieze marca salariailor care din anul 2005 au fost angajai la mai mult de dou departamente.
154
Studii de caz
SELECT Marca, COUNT(CodDepartament) AS NrDepartamente FROM AngajareSalariat WHERE YEAR([DataIncepereActivitate])>=2005 GROUP BY Marca HAVING COUNT(CodDepartament)>=2
IV.g ) Pentru salariatul cu marca 3258 s se nregistreze o majorare salarial, noul salariu fiind 1200, ncepnd 1-11-2007
INSERT INTO IstoricSalariu ( DataModSal, Marca, SalariuIncadrare ) VALUES (#1/11/2007#,"3258",1200)
IV.h) S se afieze salariaii care nu au reineri n anul 2007.

SELECT Angajat.Marca, Nume FROM Angajat WHERE Marca NOT IN (SELECT Marca FROM RetineriSalariat WHERE YEAR([DataInceputReinere])=2007 AND (YEAR([DataSfritRetinere])=2007 OR YEAR([DataSfritRetinere]) IS NULL))
IV.i) S se afieze printr-o singur interogare istoricul departamentelor n care au lucrat precum i modificrile de salariu pentru fiecare angajat. Evenimentele se vor afia cronologic.
SELECT IstoricSalariu.Marca, Nume, DataModSal AS Data, SalariuIncadrare, "Modificare Salariu" AS Tip FROM Angajat INNER JOIN IstoricSalariu ON Angajat.Marca = IstoricSalariu.Marca UNION SELECT Angajat.Marca, Nume, DataIncepereActivitate AS Data, "-" AS Sal, "Angajare departament " & DenumireDepartament FROM Departament ,Angajat,AngajareSalariat WHERE Angajat.Marca = AngajareSalariat.Marca AND Departament.CodDepartament = AngajareSalariat.CodDepartament ORDER BY Marca, Data
IV.j) S se afieze numele angajailor i salariile de ncadrare pentru o anumit dat introdus ca parametru. Valoarea parametrului se va prelua din controlul txtData al formularul denumit FrmSelectieData. Salariul ce trebuie afiat este cel care corespunde celei mai mari date de modificare ce nu depete valoarea parametrului
SELECT A.Marca, Nume AS Numele, SalariuIncadrare AS Salariu, DataModSal AS DataModificareSalariu FROM Angajat AS A, IstoricSalariu AS IstoricS WHERE A.Marca=IstoricS.Marca and DataModSal<=[Forms]![FrmSelectieData]![txtData] AND DataModSal>= ALL (SELECT DataModSal FROM IstoricSalariu WHERE IstoricSalariu.Marca=A.Marca)
155
Studiu individual: a) S se afieze angajaii al cror numr de telefon ncepe cu 0723 b) S se afieze departamentul unde lucreaz angajatul Popescu Marian n luna curent precum i vechimea n cadrul acestui departament. c) S se afieze reinerile care se aplic la mai mult de 5 angajai la o anumit dat introdus ca parametru. d) S se afieze cu ajutorul unei singure interogri istoricul salariilor obinute i a pregtirii profesionale. Se vor afia marca, numele, data schimbrii salariului sau a finalizrii pregtirii i descrierea activitii (modificare salariu sau tipul pregtirii). e) S se tearg departamentele unde nu lucreaz nici un angajat.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular cu subformular pentru actualizarea tabelei angajat i actualizarea reinerilor salariatului. Pentru o anumit dat (valoare implicita fiind data curent) se va calcula procentul total al reinerilor.
Formularul ce permite actualizarea angajailor i a reinerilor acestora
Pentru cmpul CodRetinere de pe subformularul RetineriSalariat se va realiza o list derulant din care se va putea selecta reinerea, afindu-se n formular numele acesteia. Legtura dintre formular i subformular se va realiza prin intermediul cmpului Marca.
Apelare funcie TotalRetineri txtData
Subformular
Formularul Angajat prezentat n modul Design View
156
Studii de caz
Controlul ce va permite introducerea datei este o caseta text (TextBox) pentru care proprietatea Name este txtData, proprietatea Default Value este DATE(), iar proprietatea Format are valoarea ShortDate. Pentru calculul procentului total al reinerilor se va realiza funcia TotalRetineri n cadrul unui obiect modul. Aceast funcie va avea ca argumente marca angajatului i data pentru care se dorete calcului procentului total al reinerilor. n cadrul funciei se vor declara doua variabile, una de tip Recordset i cealalt de tip QueryDef ce va permite deschiderea interogrii ProcentTotalRetineriAngajat, obiect ce este descris n cadrul cerinei III.b. Function TotalRetineri(marca As String, data As Date) As Double
se declara o variabila de tip QueryDef i una de tip Recordset
Dim qRetineri As QueryDef Dim rs As Recordset

se iniializeaz variabila qRetineri cu obiectul de tip interogare ProcentTotalRetineriAngajat
Set qRetineri = CurrentDb.QueryDefs("ProcentTotalRetineriAngajat")

se atribuie valorile pentru parametrii interogrii
qRetineri.Parameters("data") = data qRetineri.Parameters("MarcaAngajat") = marca

se iniializeaz obiectul de tip recordset asociat interogrii
Set rs = qRetineri.OpenRecordset If Not rs.EOF Then

dac exist nregistrri ce corespund cerinelor, funcia va returna valoarea atributului PTotal
TotalRetineri = rs("PTotal") Else

dac nu exist nregistrri ce corespund cerinelor, funcia va returna valoarea 0
TotalRetineri = 0 End If End Function
Pe formular se va apela funcia n cadrul proprietii ControlSource a unui control caseta text, avnd drept argumente Marca i txtData (figura de mai sus). V.b) Realizai un formular pentru actualizarea tabelei reineri. Pentru realizarea acestui formular se va accesa opiunea Form Wizard din cadrul grupului de butoane Forms din meniul Create. Sursa formularului o constituie tabelul Retinere, iar aezarea nregistrrilor n formular va fi tabelar.
157
Alegerea tabelului surs pentru formular
Alegerea modului de afiare a nregistrrilor n cadrul formularului
Formularul obinut permite adugarea, modificarea i tergerea nregistrrilor din tabelul Retinere.
Formular ce permite actualizarea reinerilor
Studiu individual: a) Realizai un formular cu subformular pentru actualizarea tabelei pregtire profesional.
b) Realizai un formular pentru actualizarea tabelei departamente.
158
Studii de caz
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) S se realizeze un raport ce afieaz situaia reinerilor pentru o lun selectat n cadrul unei liste derulante (figura urmtoare). Pentru realizarea formularul FrmSelectieData se va crea un obiect de tip formular cu ajutorul opiunii Create Design Form din grupul Forms al meniului Create. Pe acest formular se va aduga un control de tip caseta text pentru care proprietatea Format va avea valoarea mm/yyyy, proprietatea Name va fi txtData. Pentru a afia n mod implicit data curent proprietatea Default Value a casetei text va fi egala cu DATE(). Urmtorul pas l constituie realizarea raportului avnd ca surs interogarea descris la cerina (IV.j).
Raportul ce afieaz situaia reinerilor salariailor pentru luna selectat n list
Preluarea datei din formular se va face folosind numele formularului i al controlului coninut de acesta ce conine valoarea datei n urmtorul format [Forms]![NumeFormular]![NumeControl]. n cazul nostru referirea se va face n felul urmtor [Forms]![FrmSelectieData]![txtData]). Pentru afiarea datei n format luna/an se va folosi funcia FORMAT avnd ca parametru mm/yyyy. Pentru calculul reinerilor fiecrui salariat se va aduga n seciunea Detail a raportului un control de tip caseta text (TextBox) pentru care proprietatea Control Source se va apela funcia TotalRetineri descris la cerina (V.a) avnd ca argumente marca angajatului i valoarea datei preluat din formular astfel: =TotalRetineri([Marca];[Forms]![FrmSelectieData]![txtData]). Pentru proprietatea Name a acestui control se va stabili valoarea ProcentRetinere. Afiarea valorii sumei reinerii pentru fiecare salariat se va realiza cu ajutorul unui control de tip caseta text avnd proprietatea Control Source egal cu
159
=[ProcentRetinere]*[Salariu]. Salariul net se va afia n cadrul unei casete text avnd proprietatea Control Source egal cu =(1-[ProcentRetinere])*[Salariu].
Raportul ce afieaz situaia reinerilor deschis n modul Design View
Pentru a realiza legtura dintre formular i raport se va realiza un obiect de tip Macro denumit MacroParametru. Structura acestuia este prezentat n figura urmtoare. Afiarea coloanei Macro Name n modul Design al obiectului macro denumit MacroParametru, se va apsa butonul Macro Names din categoria Show/Hide a meniului Design.
Structura obiectului de tip macro denumit MacroParametru
Prima categorie Macro Name din structura obiectului Macro va realiza deschiderea formularului i va fi ataat evenimentului On Open al raportului. A doua categorie Macro Name va realiza nchiderea formularului ce permite preluarea parametrului fiind ataat evenimentului On Close a Fereastra de proprieti a raportului raportului. Ataarea acestor obiecte de tip macro evenimentelor On Open i On Close ale raportului au ca efect deschiderea formularului la deschiderea raportului i respectiv nchiderea formularului o dat cu nchiderea raportului. Urmtoarele dou categorii Macro Name se vor ataa evenimentelor On Click butoanelor Afieaz respectiv Anuleaz din formularul FrmSelectieData. Apsarea butonului Afieaz din cadrul formularului FrmSelectieData are ca efect ascunderea acestuia ca urmare a setrii valorii proprietarii Visible a formularului la valoarea No prin intermediul obiectului macro MacroParametru.
160
Studii de caz
VI.b) S se realizeze un raport ce afieaz numele i telefonul tuturor angajailor grupai alfabetic . Situaia va afia marca, numele i telefonul angajailor grupai n funcie de prima liter a numelui.
Raportul are ca surs interogarea descris n cadrul cerinei (IV.b). Se va realiza gruparea n funcie de atributul Litera. Datele se vor afia pe dou coloane. n cadrul figurii urmtoare sunt prezentate proprietile modificate ferestrei Page Setup pentru afiarea pe dou colane a nregistrrilor din raport.
Prezentarea raportului n modul Design View Fereastra Page Setup ce permite afiarea nregistrrilor pe dou coloane
Studiu individual: a) S se realizeze un raport ce afieaz istoricul salariilor pentru fiecare salariat.
161
b) S se realizeze un raport cu subraport ce afieaz toate etapele pregtirii profesionale pentru fiecare angajat. Se va afia numrul de stagii de pregtire pentru fiecare angajat.
162
Studii de caz
IX
Baz de date pentru evidena contractelor cu clienii la o firm de consultan
Se dorete realizarea unei baze de date pentru o firm ce are ca obiect de activitate acordarea de consultan n domeniul IT. La firm lucreaz mai muli angajai pentru care se cunosc: codul numeric personal (CNP), numele, data naterii, data angajrii, adresa de e-mail i competenele n domeniul IT ale angajatului Competenele se refer la abilitile angajatului n diverese ramuri ale domeniului IT (de exemplu programare, administrare reele, baze de date, etc.) i sunt codificate ntrun nomenclator la nivelul firmei. Fiecrui angajat i se memoreaz o fotografie scanat, precum i CV-ul redactat ca document Microsoft Word. Clienii crora le sunt oferite servicii de consultan sunt persoane juridice pentru care se cunosc: cod unic de identificare (CUI), denumire firm, localitate, adresa, i telefon contact. Cu clienii se ntocmesc contracte care sunt numerotate, datate i n care se specific valoarea contractului i termenul de finalizare. Pe perioada de desfurare a unui contract angajaii firmei se deplaseaz la sediul clientului i ntocmesc fie zilnice de pontaj pe care consemneaz numrul de ore lucrate la client i contractul pentru care s-a lucrat. Fiele de pontaj sunt datate i codificate n mod unic la nivelul firmei. Un contract se ncheie cu un singur client, dar exist clieni cu care s-au ncheiat mai multe contracte. La un contract pot lucra mai mui angajai, iar un angajat poate lucra la mai multe contracte. O fi de pontaj se ntocmete pentru orele lucrate ntr-o singur zi, la un singur client, pentru un anumit contract (angajaii care, n decursul aceleiai zile lucreaz pentru dou contracte diferite, vor ntocmi fie de pontaj diferite. Un angajat poate avea mai multe competene n domeniul IT.
I. Realizai modelul relaional al bazei de date i implementai n MS Access Pe baza informaiilor din enunul problemei i a regulilor de gestiune, se poate constitui dicionarul atributelor i se pot analiza dependenele funcionale dintre atribute. Aceste aspecte sunt redate sintetic prin intermediul matricei dependenelor funcionale.
Observaie: Numele unora dintre atribute au fost prescurtate (de exemplu denumire firm client DenClient, codificare competenta CodComp, etc.).
1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Observaii:
CNP Nume DataNastere DataAngajare MailAngajat Competenta CodComp Foto CV CUI DenClient OrasClient AdresaClient TelefonClient NrContract DataContract ValoareContract TermenFinalizare CodFisaPontaj DataPontaj OreLucrate
2 1
3 1
4 1
5 1
8 1
9 1
10 11 12 13 14 15 16 17 18 19 20 21
1t
1t
1t
1t
1t 1t 1t 1t
1t 1t
1t
1t
1t
1t
1t
1t
1t
Potenialele chei primare (atributele determinante) sunt evideniate n prima coloan a matricei. Dependenele funcionale au fost marcate cu simbolul 1, iar cele tranzitive cu 1t. Cmpurile n care urmeaz s fie memorate fiiere n baza de date (fotografiile i CV-urile angajailor) nu pot fi luate n calcul ca poteniale chei primare (vor fi cmpuri de tip Attachment n baza de date).
164
Studii de caz
Dup marcarea dependenelor funcionale se poate contura urmtorul model relaional al bazei de date (cheile primare sunt subliniate cu linie continu, iar cheile externe cu linie punctat)1:
ANGAJATI (CNP, Nume, DataNastere, DataAngajare, MailAngajat, CV, Foto) COMPETENTE (CodComp, Competenta) CLIENTI (CUI, DenClient, OrasClient, AdresaClient, TelefonClient ) CONTRACTE (NrContract, CUI, DataContract, ValoareContract, TermenFinalizare) PONTAJE (CodFisaPontaj, CNP, CUI, NrContract, DataPontaj, OreLucrate)
Studiind legturile existente ntre tabele i revenind la enunul problemei, se constat c nu exist suficiente legturi cheie primar cheie extern pentru a determina care sunt competenele fiecrui angajat. ntruct ntre cheile primare ale tabelelor Angajati i Competente exist dependene multivaloare reciproce (un angajat poate avea competene multiple, iar o competen poate fi deinut de mai muli dintre angajai) se va aduga modelului un tabel intermediar care s asigure legtura. Am numit acest tabel Angajati_Competente
Angajati_Competente (CNP, CodComp)
Rezultatul implementrii modelului relaional n Microsoft Access 2007 este prezentat n figura urmtoare:
Conform metodologiei, se creaz un tabel pentru fiecare atribut determinant marcat n matricea dependenelor funcionale i atributele determinate netranzitiv de ctre acesta.
165
Studiu individual: 1. Se dorete extinderea modelului bazei de date pentru a face posibil evidena ncasrilor pe care firma le realizeaz n contul contractelor cu clienii. Clienii pltesc contravaloarea contractelor prin ordine de plat. Pe fiecare ordin de plat se consemneaz numrul ordinului de plat, data efecturii plii i suma achitat de client. n cele mai multe cazuri, contravaloarea unui contract este achitat n trane, firma primind mai multe ordine de plat pentru acelai contract. Adugai modelului relaional tabelul, sau tabelele, ce permit memorarea datelor privind sumele pe care firma le primete pentru activitatea desfurat.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Se dorete ca, n loc de acronimul CNP, la introducerea datelor n tabelul Angajati s se afieze pentru acest cmp titlul Cod numeric personal. n acest sens se va modifica proprietatea Caption:
II.b) Pentru codurile fielor de pontaj s-a stabilit un standard la nivelul firmei, astfel nct orice cod va fi alctuit din: 3 caractere alfanumerice, urmate simbolul ., apoi de 6 cifre urmate de simbolul . i, n final, doua litere. Pentru a preveni nerespectarea acestui format impus, se va modifica la nivelul cmpului CodFisaPontaj proprietatea Input Mask astfel:
166
Studii de caz
II.c) Pentru fiecare angajat se va verifica dac a mplinit vrsta de 18 ani n momentul angajrii. ntruct acest validare se realizeaz prin compararea unor valori din cmpuri diferite (data natere i data angajare), regula va fi implementat la nivelul validrilor tabelului. n acest scop se va deschide tabelul n modul Design i se va apsa butonul Properties din bara de instrumente.
Validare la nivel de tabel
Studiu individual: Impunei urmtoarele reguli de validare la nivel de cmp sau tabel: a) Numrul de ore completat de un angajat pe o fi de pontaj nu poate depi 10. b)Termenul de finalizare a contractelor nu poate fi anterior datei semnrii contractului c) Valoarea contractelor se va ncadra ntre 1.000 lei i 900.000 lei. d) Valorile posibile pentru cmpul OrasClient se vor limita la lista Bucuresti, Ploiesti, Brasov, Constanta. e) Datele de pe fiele de pontaj nu pot fi ulterioare datei curente (data sistemului).
167
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze lista angajailor care nu au realizat pn n prezent nici un pontaj la contractele ncheiate de firm n anul 2009. ntr-o prim etap se va realiza o interogare pe baza tabelelor Pontaje i Contracte pentru a obine o list cu CNP-urile angajailor care au lucrat la contractele din anul 2009. Aceast interogare va fi salvata cu numele Pontaje la contracte din 2009.
Ulterior se va realiza o a doua interogare ce va avea ca surs tabelul Angajai i interogarea precedent.
Observaie: Pentru a evidenia care sunt angajaii care figureaz n tabelul Angajati i nu apar pe fiele de pontaj obinute prin interogarea Pontaje la contracte din 2009 se va specifica, mai nti, preluarea n setul de rezultate a tuturor angajailor din tabel, prin modificarea proprietilor legturii (Join Properties). Ulterior, se va completa n cmpul de criterii condiia Is Null pentru cmpul CodFisaPontaj.
168
Studii de caz
III.b) S se calculeze total ore pontate de fiecare angajat n decembrie 2008 la clientul ABC SA.
Observaie: Pentru cmpul DataPontaj, n rndul Total al interogrii, s-a specificat opiunea Where, ntruct acest cmp este necesar doar pentru impunerea condiiilor, nu i pentru gruparea datelor. III.c) S se calculeze pentru fiecare salariat vechimea n munc i totalul orelor pontate. Pentru cei cu vechime peste 1 an i mai mult de 100 de ore pontate se va afia ntr-un cmp calculat numit Observatii textul Propus pentru prima.
Observatii: IIf([TotalOre]>100 And [Vechime]>1; "Propus pentru prima" ; )
Observaie:Pentru cmpul Observatii, n rndul Total al interogrii, s-a utilizat opiunea Expression deoarece este un cmp calculat pe baza altor cmpuri rezultate din agregarea datelor.
169
III.d) S se afieze numrul total de ore pontate pentru angajaii care au mai mult de 5 competene. Observaie: Aceast cerin, pentru a conduce la rezultate corecte, este necesar s fie rezolvat prin dou interogri succesive. ntr-o prim etap se va determina care sunt angajaii care au mai mult de 5 competene (se va salva interogarea cu numele Angajati Selectati)
A doua interogare va avea ca surs tabelul de Pontaje i interogarea precedent:
Observaie:Dac interogarea s-ar fi rezolvat printr-un singur Query, rezultatele nu ar fi fost cele corecte ntruct, datorit legturilor de tip 1-n ntre tabelul Angajati i tabelele Pontaje, respectiv Angajati_Competente, numrul de competene calculat nu ar fi fost cel real (competenele s-ar fi multiplicat n funcie de numrul de pontaje).
170
Studii de caz
Studiu individual: Realizai urmtoarele interogri : a) Calculai totalul de ore pontate pe fiecare contract n ultima lun . b) Calculai numrul mediu de ore pontate de fiecare angajat n fiecare lun a anului 2008. Interogarea va fi de tip CrossTab Query. c) Printr-o interogare de tip Make Table
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) Care sunt clienii firmei din oraele Iai sau Braov care nu au telefonul memorat n baza de date ?
SELECT DenClient FROM CLIENTI WHERE (OrasClient="Iasi" OR OrasClient="Brasov") AND TelefonClient Is NULL
Observaie: A fost necesar utilizarea parantezelor rotunde pentru a ncadra cele dou condiii legate prin operatorul OR pentru a indica prioritatea criteriilor din clauza WHERE. O soluie alternativ ar fi fost utilizarea operatorului IN (Iasi, Brasov) IV.b) Se dorete atribuirea unui cod la nivelul firmei pentru fiecare contract. Acest cod va fi unul alfanumeric i va conine: primele 3 litere din numele oraului din care provine clientul, caracterele de pe pozitia a doua si a treia din denumirea clientului, numrul de cifre care alctuiesc valoarea contractului i, n final, ultimele dou cifre din anul n care s-a ncheiat contractul .
SELECT CONTRACTE.NrContract, Left(OrasClient,2) & Mid(DenClient,2,2) & Len(ValoareContract) & Right(Year(DataContract),2) AS CodContract FROM CLIENTI INNER JOIN CONTRACTE ON CLIENTI.CUI = CONTRACTE.CUI;
Observaie: Pentru informaii suplimentare privind funciile LEFT, RIGHT, MID i LEN se recomand consultarea sistemului de asisten (Help) oferit de Microsoft Access. IV.c) Care sunt angajaii care au nregistrat pontaje la contractul cu numerele 101 sau 102. Lista se va ordona alfabetic.
SELECT DISTINCT Nume FROM ANGAJATI INNER JOIN PONTAJE ON ANGAJATI.CNP=PONTAJE.CNP WHERE NrContract in (3,4) ORDER BY NUME ASC
Observaie: Clauza DISTINCT a fost utilizat, imediat dup instruciunea SELECT pentru a prentmpina apariia n lista de rezultate a unui angajat de mai multe ori (pentru fiecarre pontaj realizat).
171
IV.d) S se afieze numele i adresele cleinilor la care a realizat pontaje angajatul Ion Vasile.
SELECT DISTINCT DenClient, OrasClient, AdresaClient FROM (ANGAJATI INNER JOIN PONTAJE ON ANGAJATI.CNP=PONTAJE.CNP) INNER JOIN CLIENTI ON PONTAJE.CUI=CLIENTI.CUI WHERE Nume="Ion Vasile""
IV.e) S se afieze numele angajailor care nu figureaz cu nicio competen n baza de date.
SELECT Nume FROM ANGAJATI LEFT JOIN ANGAJATI_COMPETENTE ON ANGAJATI.CNP=ANGAJATI_COMPETENTE.CNP WHERE ANGAJATI_COMPETENTE.CNP IS NULL
Observaie: Utilizarea LEFT JOIN n loc de INNER JOIN permite preluarea tuturor angajailor, indiferent dac CNP-ul acestora figureaz n tabelul ce conine cheia extern. O alt variant de rezolvare este urmtoarea:
SELECT Nume FROM ANGAJATI WHERE CNP NOT IN (SELECT CNP FROM ANGAJATI_COMPETENTE)
IV.f ) Calculai numrul total de ore pontate pentru fiecare client, la fiecare contract.
SELECT CLIENTI.CUI, DenClient, NrContract, SUM(OreLucrate) As [Total ore] FROM CLIENTI INNER JOIN PONTAJE ON CLIENTI.CUI=PONTAJE.CUI GROUP BY CLIENTI.CUI, DenClient, NrContract
IV.g) S se afieze lista angajailor i numrul de fie de pontaj ntocmite de fiecare pentru cei care nu au cumulat 50 de ore pontate.
SELECT ANGAJATI.CNP, Nume, COUNT(Fisa) AS [Total fise intocmite] FROM ANGAJATI INNER JOIN PONTAJE ON ANGAJATI.CNP=PONTAJE.CNP GROUP BY ANGAJATI.CNP, Nume HAVING SUM(OreLucrate)<50
Observaie: Condiia ce implic utilizarea funciei agregat SUM a condus la necesitatea utilizrii clauzei HAVING. IV.h) S se modifice interogarea precedent pentru a elimina din lista de rezultate angajaii care au intocmit fie de pontaj n ultimele dou zile. La interogare se va aduga clauza WHERE care va conine urmtoarea subinterogare:
SELECT ANGAJATI.CNP, Nume, COUNT(Fisa) AS [Total fise intocmite] FROM ANGAJATI INNER JOIN PONTAJE ON ANGAJATI.CNP=PONTAJE.CNP WHERE ANGAJAT.CNP NOT IN (SELECT CNP FROM PONTAJ WHERE DataPontaj>Date()-10 ) GROUP BY ANGAJATI.CNP, Nume HAVING SUM(OreLucrate)<50
172
Studii de caz
IV.i) S se tearg din baza de date clienii cu care nu exist nregistrate contracte dup data de 1 ianuarie 2000.
DELETE * FROM CLIENTI WHERE CUI NOT IN (SELECT CUI FROM CONTRACTE WHERE DataContract>#1/1/2000#)
IV.j) Care sunt angajatii care au nregistrat pontaje pentru contractul cu cea mai mare valoare ?
SELECT Nume FROM ANGAJATI INNER JOIN PONTAJE ON ANGAJATI.CNP = PONTAJE.CNP WHERE PONTAJE.NRcontract IN (SELECT NrContract FROM CONTRACTE WHERE ValoareContract>=ALL(SELECT ValoareContract FROM Contracte))
Studiu individual: a) S se calculeze un discount la valoarea fiecrui contract astfel: pentru contractele mai vechi de 90 de zile 1% din valoare, pentru cele cu vechime ntre 30 i 90 de zile 2% din valoare, iar pentru celelalte 5%. b) S se obin lista angajailor care au realizat pontaje la contractele clientului START SRL n ultima lun. c) S se tearg pontajele aferente contractului cu numrul 100. d) S se tearg pontajele aferente contractelor cu clientul ABC SRL. d) S se identifice care sunt angajaii care au totalizat mai mult de 100 de ore lucrate. e) S se calculeze valoarea total a contractelor pe fiecare client.
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular cu subformular pentru a vizualiza pentru fiecare client lista contractelor. Se va aduga pe formular o list de cutare a clienilor i se va calcula valoarea total a contractelor pe subformular. Tot pe subformular, pentru fiecare contract se va calcula durata n zile a fiecrui contract (diferena ntre termenul finalizrii contractului i data semnrii contractului). Contractele cu o durata mai mare de 90 de zile se vor afia pe fundal verde. Se va realiza un buton de comand pe subformular prin intermediul cruia s se poat vizualiza lista pontajelor la contractul respectiv, sub forma unui raport..
173
Formularul realizat pe baza tabelului Clieni, cu subformular avnd ca surs tabelul Contracte, este prezentat n figura urmtoare n modul Design.
Name:TxtDurata
Name: NrContract
Name:TxtSuma Name: btnPontaj
Name: comboCauta
Dup cum se poate observa, pe subformular a fost adugat n seciunea Detail o caset de tip TextBox (txtDurata), iar proprietatea Control Source pentru aceast caset conine formula de calcul pentru durata contractului exprimat n zile (=[TermenFinalizare]-[DataContract]). Pentru aceast caset s-a stabilit formatare condiional solicitat n enunul problemei (contractele cu durat peste 90 de zile se vor afia pe fundal verde). n acest sens se va selecta caseta txtDurata i, din bara de instrumente, se va apsa butonul
O alt caset de tip TextBox (txtSuma) a fost plasat n subsolul subformularului. Pentru aceast caset, proprietatea Control Source conine expresia necesar calculrii valorii totale a contractelor: =Sum(ValoareContract). Lista de cutare pe formular dup numele clientului (comboCauta) a fost realizat cu ajutorul programului wizzard. Figurile urmtoare ilsustreaz succint paii de ce trebuie parcuri pentru realizarea unui ComboBox de cutare:
174
Studii de caz
1. Se specific faptul c se dorete ca viitoare caset tip ComboBox s aib rol de cutare (se va genera automat codul VBA pentru cutarea nregistrrilor dup elementul selecta n list)
2. Se selecteaz cmpurile ce vor constitui sursa listei (se va genera automat o instruciune SQL de tip SELECT).
3. Se pot ajusta coloanele casetei de tip ComboBox.
4. Se precizeaz textul ce va fi afiat prin intermediul unui control de tip Label poziionat pe formular n dreapta casetei de tip Combo Box.
nainte de a realiza butonul btnPontaj n seciunea Detail de pe subformular, cu rolul de a afia o list a pontajelor pentru contractul selectat, se va realiza lista pontajelor
175
sub forma unui raport avnd drept surs tabelele Pontaje i Angajati. Raportul este prezentat n figura urmtoare n modul Design:
Dup cum s-a precizat, raportul va afia toate fiele de pontaj, de pe toate contractele, nsoite de numele angajailor care le-au ntocmit. Filtrarea pontajelor dup numrul contractului selectat pe subformular (caseta TextBox se numete NrContract) se va realiza prin instruciunea VBA ce se declaneaz n momentul apsrii butonului.
Private Sub btnPontaj_Click() DoCmd.OpenReport "Raport Pontaje", acViewPreview , , "NrContract = " & NrContract End Sub
Observaie: Argumente instruciunii OpenReport sunt urmtoarele

OpenReport <nume raport>, <mod de vizualizare>, [numele unui filtru], [condiie de filtrare a datelor de pe raport]
ntrct instruciunea utilizat n exemplu nu utilizeaz cel de-al treilea argument, ci precizeaz direct condiia, n exemplu apar dou virgule succesive dup modul de vizualizare a raportului.
Studiu individual: S se realizeze urmtoarele formulare: a) Formular pentru tabelul Angajati cu subformular avnd ca surs tabelul Pontaje. Se va calcula total ore pontate de ctre fiecare angajat n subsolul subformularului i se va aduga o list de cutare a angajailor pe formularul principal b) Formular pentru tabelul Contracte cu subformular avnd ca surs tabelul Pontaje. Se va cacula pentru fiecare contract numrul total de ore pontate, iar pe formularul principal codurile clienilor (CUI) se vor selecta prin intermediul unei casete de tip Combo Box ce va conine att codurile ct i numele clienilor
176
Studii de caz
Baz de date pentru evidena activitii unei clinici medicale
Se dorete realizarea unei baze de date pentru gestiunea activitii unei clinici medicale (din cadrul unui spital). Clinica este format din mai multe secii, fiecare secie dispunnd de un anumit numr de sli (pentru internarea i tratamentul pacienilor). Fiecare secie din cadrul clinicii este identificat printr-un cod i are o denumire. Unele secii au posibilitatea de a accepta urgene, altele nu. O sal aparine unei secii, are un numr, este situat la un anumit etaj (din cele cinci ale cldirii) i este dotat cu un anumit numr de paturi. Personalul care deservete clinica este format din dou categorii principale de angajai: medici i asisteni. Pentru fiecare medic se cunosc: valoarea identificatorului unic (codul), numele, prenumele, gradul (stagiar, rezident, primar, specialist etc.), precum i specialitatea (domeniul su de competen). Fiecare medic deservete o singur secie, rspunznd de pacienii aflai n toate slile respectivei secii. Medicii sunt singurii angajai care au dreptul de a stabili diagnostice pentru pacieni. Asistenii care deservesc clinica sunt, de asemenea, identificai printr-un cod, nregistrai cu nume, prenume i calificare. Unii asisteni pot avea gradul de asistent ef. Un asistent deservete anumite sli, existnd situaia n care mai muli asisteni deservesc aceleai sli. Evidena pacienilor clinicii se realizeaz prin deschiderea unei fie pentru fiecare pacient. Fia pacientului are un numr unic i conine datele de identificare ale pacientului: nume, prenume, data naterii, naionalitate. Din motive legate de decontarea serviciilor medicale, se face distincie ntre pacienii de naionalitate romn i cei de alte naionaliti. n cazul fiecrei fie medicale se reine i data deschiderii, reprezentnd momentul primei prezentri a unui pacient la clinic. n funcie de simptomele anunate, fiecare pacient care se prezint la clinic este ndrumat ctre un medic, care realizeaz o consultaie i i stabilete un diagnostic. n scopul urmririi istoricului medical al unui pacient, diagnosticele stabilite de ctre medici sunt nregistrate n fia medical a acestuia. Fiecare diagnostic stabilit are un identificator, nregistrndu-se de asemenea data stabilirii, coninutul diagnosticului (explicaia acestuia) i tipul diagnosticului, care descrie condiiile n care diagnosticul a fost stabilit (de urgen, preliminar, interimar, definitiv). n situaia n care condiia pacientului implic spitalizarea acestuia, se va proceda la realizarea unui document (bilet) de internare. Fiecare asemenea document este identificat printr-un cod, specificndu-se data internrii, data externrii, pacientul care beneficiaz de internare i sala unde acesta va sta pe perioada spitalizrii. De asemenea, pentru fiecare internare se va stabili (n funcie de tipul asigurrii medicale a pacientului) procentul n care costul internrii va fi subvenionat de ctre stat (0, 25, 50, 75 sau 100% pentru cazul tratamentelor complet gratuite).
177
Reguli de gestiune: Activitatea unei secii a clinicii se desfoar n mai multe sli Fiecare sal din cadrul clinicii aparine unei singure secii O secie a clinicii este deservit de mai muli medici Fiecare medic deservete o singur secie n cadrul clinicii Fiecare asistent din personalul clinicii deservete mai multe sli Fiecare sal din cadrul clinicii este deservit de mai muli asisteni Fiecare internare nregistrat se refer la un singur pacient (o singur fi) Un pacient poate beneficia de mai multe internri succesive Fiecare internare se realizeaz ntr-o singur sal n aceeai sal se pot realiza mai multe internri (pentru pacieni diferii) Fiecare diagnostic nregistrat se refer la un singur pacient (o singur fi) Unui pacient i se pot stabili (n timp) mai multe diagnostice Un diagnostic este stabilit de ctre un singur medic Fiecare medic (indiferent de grad) poate stabili mai multe diagnostice I. Realizai modelul relaional al bazei de date i implementai n MS Access Realizarea modelului relaional presupune identificarea prealabil a atributelor care vor intra n componena acestui model, precum i centralizarea lor n forma dicionarului de atribute. Pentru problema enunat, dicionarul de atribute are urmtorul coninut (ordonat alfabetic):
DICIONAR DE ATRIBUTE Asistentef Calificare CodAsistent CodInternare CodMedic CodSectie DataDeschidere DataDiagnostic DataExternare DataInternare DataNatere DenumireSecie EtajSal Explicaie Grad IDDiagnostic Naionalitate NumrFi NumrPaturi NumrSal NumeAsistent NumeMedic NumePacient PrenumeAsistent PrenumeMedic PrenumePacient ProcentSubvenie Specialitate TipDiagnostic Urgene
n vederea obinerii modelului relaional aferent acestui dicionar de atribute se va construi matricea dependenelor funcionale. Din cauza limitrilor de spaiu, se va prezenta forma restrns a acestei matrice (pe una dintre dimensiuni vor fi specificate doar atributele cu rol de cheie primar, nu ntregul coninut al dicionarului). n acest scop, se vor marca n list acele atribute care au rol de identificare n cadrul modelului. Casetele de culoare neagr din cadrul matricei marcheaz dependenele funcionale triviale (faptul c fiecare atribut depinde funcional de el nsui). Casetele
178
Studii de caz
de culoare gri marcheaz dependenele multivaloare, pe baza crora nu se pot trage concluzii cu privire la forma final a modelului relaional. Marcajul 1T indic existena unei dependene funcionale tranzitive ntre cheia primar de pe coloan i atributul corespunztor liniei, iar marcajul 1 indic existena unei dependene funcionale directe ntre cele dou elemente menionate.
Nr. 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 ATRIBUTE Denumire Asistentef Calificare CodAsistent CodInternare CodMedic CodSectie DataDeschidere DataDiagnostic DataExternare DataInternare DataNatere DenumireSecie EtajSal Explicaie Grad IDDiagnostic Naionalitate NumrFi NumrPaturi NumrSal NumeAsistent NumeMedic NumePacient PrenumeAsistent PrenumeMedic PrenumePacient ProcentSubvenie Specialitate TipDiagnostic Urgene 03 1 1 04 CHEI PRIMARE 05 06 16 18 20
1T 1T 1 1 1T 1T 1T
1 1T 1 1
1 1T 1 1T 1 1T 1 1 1 1T 1
1 1T 1 1T 1 1 1 1 1 1 1 1
T T
1T 1 1T 1
1 1T 1T 1
1T 1 1T
1T
179
Modelul relaional al bazei de date este urmtorul:

Asistent (CodAsistent, NumeAsistent, PrenumeAsistent, Calificare, AsistentSef) Internare (CodInternare, DataInternare, DataExternare, NumarFisa, NumarSala, ProcentSubventie) Medic (CodMedic, NumeMedic, PrenumeMedic, Grad, Specialitate, CodSectie) Sectie (CodSectie, DenumireSectie, Urgente) Diagnostic (IDDiagnostic, CodMedic, NumarFisa, DataDiagnostic, Explicatie, TipDiagnostic) FisaPacient (NumarFisa, DataDeschidere, NumePacient, PrenumePacient, DataNastere, Nationalitate) Sala (NumarSala, EtajSala, NumrPaturi, CodSectie) Deserveste (CodAsistent,NumrSala)
n scopul implementrii n SGBD Microsoft Access 2007 a modelului relaional obinut, este necesar stabilirea tipului de date ce va fi atribuit fiecrui atribut. Opinia autorului cu privire la tipurile de date cele mai potrivite pentru cazul n discuie este prezentat n tabelul urmtor: ATRIBUTE DE TIP NUMERIC (Tipurile NUMBER i AUTONUMBER)
DENUMIRE ATRIBUT CodAsistent CodInternare CodMedic CodSecie EtajSal IDDiagnostic NumrFi NumrPaturi NumrSal ProcentSubvenie TIP DE DATE Number, Long Integer AutoNumber, Long Integer, Random Number, Long Integer AutoNumber, Long Integer, Increment Number, Byte AutoNumber, Long Integer, Random AutoNumber, Long Integer, Random Number, Byte Number, Integer Number, Byte
ATRIBUTE DE TIP ALFANUMERIC (Tipul de date TEXT) DENUMIRE ATRIBUT LUNGIME (CARACTERE)
Calificare DenumireSecie Explicaie Grad Naionalitate NumeAsistent NumeMedic NumePacient PrenumeAsistent PrenumeMedic PrenumePacient Specialitate TipDiagnostic Urgene 30 40 255 20 20 30 30 30 30 30 30 20 20 2
180
Studii de caz
ATRIBUTE DE TIP DAT (Tipul de date DATE/TIME) DENUMIRE ATRIBUT TIP DE DATE
DatDeschidere DatDiagnostic DatExternare DatInternare DatNatere Date/Time Date/Time Date/Time Date/Time Date/Time TIP DE DATE Yes/No
ATRIBUTE DE TIP LOGIC (Tipul de date YES/NO)

DENUMIRE ATRIBUT Asistentef
Not: Implementarea modelului relaional n SGBD Access se va realiza fr a utiliza caracterele diacritice specifice limbii romne. n opinia autorului, procesul de definire a atributelor i alegere a tipurilor de date trebuie completat cu o serie de constrngeri suplimentare, pentru a asigura integritatea i consistena datelor, dar i pentru a facilita utilizarea bazei de date i popularea acesteia. n acest sens se va propune i exemplifica realizarea urmtoarelor tipuri de restricii de integritate (constrngeri): Atributele Calificare (din tabela Asistent), TipDiagnostic (din tabela Diagnostic), Naionalitate (din tabela FiPacient), ProcentSubvenie (din tabela Internare), Grad i Specialitate (din tabela Medic), EtajSal (din tabela Sal) i Urgene (din tabela Secie) au un domeniu de valori bine definit i, ca urmare, posibilitile de introducere a datelor ar trebui limitate la lista de valori corespunztoare fiecrui atribut. Cele dou figuri care urmeaz exemplific utilizarea instrumentului LOOKUP oferit de SGBD Access 2007 pentru realizarea unei liste de valori numerice (n primul caz), respectiv pentru realizarea unei liste de valori alfanumerice (n cel de-al doilea caz). n ambele cazuri, limitarea posibilitilor de introducere de date la variantele prestabilite s-a realizat cu ajutorul proprietii Limit To List, care a primit valoarea Yes. Stabilirea valorilor predefinite pentru un atribut cu valori numerice (EtajSal):
181
Stabilirea valorilor predefinite pentru un atribut cu valori alfanumerice (Urgene)
Pentru atributele DataDiagnostic (din tabela Diagnostic), DataDeschidere (din tabela FiPacient), DataInternare i DataExternare (din tabela Internare), se intenioneaz furnizarea unei valori implicite (considerat ca potrivit pentru o mare parte din situaii), urmnd ca aceasta s fie modificat liber de ctre utilizator n situaiile n care nu este aplicabil. n cazul primelor trei atribute, aceast valoare ar fi data curent a sistemului, iar n cazul celui de-al patrulea (DataExternare), o dat ulterioar datei curente (cu trei zile), stabilit pe baza duratei medii a unei internri. Cea mai simpl metod de a obine acest tip de comportament este apelul la funcia Date, care returneaz data curent a sistemului i plasarea acestui apel n seciunea Default Value a listei de proprieti pentru cmpul vizat (figura urmtoare):
182
Studii de caz
n scopul de a facilita stabilirea valorilor pentru cmpurile cu rol de cheie extern, instrumentul LOOKUP oferit de SGBD Access 2007 poate fi utilizat pentru a afia n cadrul cmpului-cheie extern toate valorile cheii primare corespunztoare (toate valorile care respect integritatea referenial). n funcie de situaie, o asemenea afiare poate include i alte cmpuri suplimentare, care nu fac parte din cheie dar faciliteaz nelegerea valorilor cheii. Afiarea unor cmpuri suplimentare sau ascunderea cmpului cu rol de cheie extern nu afecteaz n nici un fel relaiile dintre cele dou tabele implicate, fiind doar o metod de mbuntire a ergonomiei interfeei. De exemplu, adugarea numelui i prenumelui unui medic la codul acestuia poate elimina ambiguitile n selectarea medicului care a stabilit un diagnostic (cheia extern CodMedic din tabela Diagnostic). n acest caz, proprietatea Bound Column stabilete care dintre coloanele afiate conine cheia extern propriu-zis, proprietatea Column Count stabilete numrul de coloane afiate, iar proprietatea Column Widths poate fi utilizat pentru a preciza explicit limea fiecrei coloane (sau pentru a ascunde una dintre coloane). n figura urmtoare este exemplificat. Stabilirea detaliat a numrului i dimensiunilor coloanelor pentru un cmp cu rol de cheie extern.
Varianta final a bazei de date, coninnd att tabelele, ct i relaiile dintre acestea, este prezentat n figura urmtoare:
183
Studiu individual: Completai modelul anterior, astfel nct s rspund i urmtoarei cerine: Baza de date trebuie s asigure evidena situaiilor n care un pacient este transferat dintr-o camer n alta pe parcursul internrii. Adugai modelului relaional tabelul sau tabelele necesare pentru a permite memorarea datelor aferente transferurilor suferite de un pacient pe durata unei internri.
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Deoarece durata medie a unei internri este de trei zile, se dorete ca valoarea implicit a cmpului DataExternare (din tabela Internare) s fie cu trei zile mai mare dect data curent a sistemului. n acest scop se va modifica proprietatea Default Value a cmpului DataExternare, cu ajutorul funciei Date(). Stabilirea valorii implicite a datei de externare este prezentat n figura urmtoare:
184
Studii de caz
II.b) Deoarece clinica a nceput s funcioneze la 1 ianuarie 2003, pentru fiele pacienilor nu se vor accepta date de deschidere anterioare acestei valori. Condiia ca valorile cmpului DataDeschidere s fie ulterioare datei de 1.1.2003 se va implementa n cadrul proprietii Validation Rule a acestui cmp. De asemenea, se recomand utilizarea proprietii Validation Text pentru stabilirea unui mesaj de avertizare n cazul n care o valoare introdus nu respect regula menionat anterior.
II.c) n scopul pstrrii consistenei datelor din baza de date, este necesar implementarea unei restricii la nivel de tabel care s verifice dac data externrii pentru un pacient este ulterioar datei de internare. Modul de stabilire a restriciei este prezentat n figura urmtoare.
185
Studiu individual: a) Deoarece clinica nu dispune de echipamentul necesar tratamentului copiilor sub doi ani, se cere implementarea unei restricii care s nu permit deschiderea de fie pentru pacieni a cror dat de natere nu este anterioar cu cel puin doi ani datei curente. b) Se cere modificarea condiiei de la punctul II.c) pentru situaia n care nu se accept internri pe perioade mai scurte de 3 zile.
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze medicii a cror specialitate este ORL
186
Studii de caz
III.b) S se afieze numrul de internri nregistrate dup 1 ianuarie 2007
III.c) S se afieze n ordine alfabetic numele, prenumele i numrul de diagnostice stabilite, pentru medicii care au stabilit cel puin trei diagnostice dup 1 ianuarie 2007
187
III.d) S se afieze numrul de asisteni cu calificarea Ortopedie care deservesc fiecare sal
Studiu individual: a) S se afieze numrul de asisteni cu calificarea ORL care deservesc fiecare etaj b) S se afieze secia deservit de cei mai muli medici
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze seciile care primesc urgene
SELECT Sectie.CodSectie, Sectie.DenumireSectie FROM Sectie WHERE (Sectie.Urgente="DA");
IV.b) S se afieze cei mai tineri trei pacieni

SELECT TOP 3 FisaPacient.NumePacient, FisaPacient.PrenumePacient FROM FisaPacient ORDER BY FisaPacient.DataNastere DESC;
IV.c) S se afieze numrul de asisteni cu funcie de asistent ef care deservesc fiecare sal
SELECT Deserveste.NumarSala, Count(Deserveste.CodAsistent) AS NumrAsisteni FROM Asistent INNER JOIN Deserveste ON Asistent.CodAsistent = Deserveste.CodAsistent WHERE Asistent.AsistentSef=Yes GROUP BY Deserveste.NumarSala;
IV.d) S se afieze numrul de pacieni nscui dup 2000

SELECT Count(FisaPacient.NumarFisa) AS CountOfNumarFisa FROM FisaPacient WHERE FisaPacient.DataNastere >= #1/1/2000#;
188
Studii de caz
IV.e) S se afieze numrul de diagnostice stabilite n 2007 de ctre fiecare medic specialist
SELECT Medic.NumeMedic, Medic.PrenumeMedic, Count(Diagnostic.IDDiagnostic) AS NumrDiagnostice, Year([DataDiagnostic]) AS Anul FROM Medic INNER JOIN Diagnostic ON Medic.CodMedic = Diagnostic.CodMedic WHERE Medic.Grad="Specialist" GROUP BY Medic.NumeMedic, Medic.PrenumeMedic, Year([DataDiagnostic]) HAVING Year([DataDiagnostic])=2007;
IV.f ) S se afieze numrul de pacieni nscui n fiecare an

SELECT Year([DataNastere]) AS AnNastere, Count(FisaPacient.NumarFisa) AS NumrPacieni FROM FisaPacient GROUP BY Year([DataNastere]);
IV.g) S se afieze numele tuturor asistenilor care deservesc sli deservite de medicul Srdaru Liviu
SELECT Asistent.NumeAsistent, Asistent.PrenumeAsistent FROM Asistent INNER JOIN (((Sectie INNER JOIN Medic ON Sectie.CodSectie = Medic.CodSectie) INNER JOIN Sala ON Sectie.CodSectie = Sala.CodSectie) INNER JOIN Deserveste ON Sala.NumarSala = Deserveste.NumarSala) ON Asistent.CodAsistent = Deserveste.CodAsistent WHERE Medic.NumeMedic="Sardaru" AND Medic.PrenumeMedic="Liviu";
IV.h) S se afieze medicii primari, n ordinea descresctoare a numrului de diagnostice stabilite

SELECT Medic.NumeMedic, Medic.PrenumeMedic, Count(Diagnostic.IDDiagnostic) AS NumrDiagnostice FROM Medic INNER JOIN Diagnostic ON Medic.CodMedic = Diagnostic.CodMedic WHERE Medic.Grad="Primar" GROUP BY Medic.NumeMedic, Medic.PrenumeMedic ORDER BY Count(Diagnostic.IDDiagnostic) DESC;
IV.i) S se creeze tabela PacieniStrini care s conin datele personale i numrul de internri ale fiecrui pacient care nu este de naionalitate romn
SELECT FisaPacient.NumarFisa, FisaPacient.NumePacient, FisaPacient.PrenumePacient, FisaPacient.DataNastere, Count(Internare.CodInternare) AS NrInternri INTO PacientiStraini FROM FisaPacient INNER JOIN Internare ON FisaPacient.NumarFisa = Internare.NumarFisa WHERE FisaPacient.Nationalitate="Straina" GROUP BY FisaPacient.NumarFisa, FisaPacient.NumePacient, FisaPacient.PrenumePacient, FisaPacient.DataNastere;
IV.j) S se tearg din tabela creat anterior datele pacienilor nscui dup 1960
DELETE Year([DataNastere]) AS AnulNastere FROM PacientiStraini WHERE Year([DataNastere]) > 1960;
189
Studiu individual: a) S se afieze numele pacienilor de naionalitate romn nscui dup 1990 b) S se afieze numrul de medici afereni fiecrui grad c) S se afieze datele celui mai tnr pacient internat ntr-o sal a seciei Chirurgie d) S se afieze numrul maxim de diagnostice stabilite de ctre un medic n 1990 e) S se tearg datele pacienilor care nu au avut nici o internare
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular pe baza tabelei Internare, prevzut cu un buton de validare care s nu permit salvarea unei nregistrri atta timp ct ntre data externrii i data internrii nu este o diferen de cel puin trei zile (data externrii fiind, evident, ulterioar celei de internare). Deoarece formularul va conine toate cmpurile din tabela Internare, acesta va fi creat prin selectarea tabelei din lista de obiecte Access, urmat de alegerea butonului Form din seciunea Create a barei cu butoane. Formularul astfel obinut se salveaz cu numele frmInternare, apoi se deschide n modul Design View pentru a se aduga un buton de comand (numit cmdVerific). Aspectul final al formularului este prezentat n imaginea urmtoare.
Codul VBA aferent butonului cmdVerific va realiza un test al condiiei enunate i va salva nregistrarea numai n cazul n care condiia este respectat. n continuare este prezentat procedura eveniment aferent butonului:
Private Sub cmdVerifica_Click() If DataExternare - DataInternare < 3 Then MsgBox "Internarea se face pentru o perioada de minim 3 zile!" Else DoCmd.Save End If End Sub
190
Studii de caz
V.b) Realizai un formular cu subformular pentru afiarea istoricului medical al unui pacient (toate diagnosticele stabilite pacientului de la momentul deschiderii fiei, n ordine invers cronologic) Formularul principal se va realiza pe baza tabelei FiPacient, iar subformularul va fi realizat pe baza tabelei Diagnostic. Pentru o prezentare optim, subformularul va fi afiat n modul Multiple forms. Aspectul final al formularului este prezentat n imaginea urmtoare.
Pentru obinerea listei de diagnostice n ordine invers cronologic, este necesar precizarea acestei condiii n cadrul proprietii Order By a subformularului, ca n figura alturat.
Studiu individual: a) S se realizeze un formular cu subformular pentru afiarea asistenilor care deservesc fiecare secie a clinicii. b) S se realizeze un formular cu subformular pentru afiarea tuturor internrilor precedente ale unui pacient.
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) Afiarea asistenilor care deservesc slile din fiecare secie a clinicii. Coninutul unui asemenea raport presupune centralizarea datelor din cel puin trei tabele: Secie, Sal i Asistent. Din acest motiv, s-a optat pentru o structur pe mai multe nivele, aa cum este prezentat n figura urmtoare:
191
Structura pe mai multe nivele presupune definirea de seciuni Header multiple n cadrul raportului, astfel: O seciune destinat gruprii la nivel de secie (CodSecie Header) O seciune destinat gruprii la nivel de sal (NumrSal Header) O seciune destinat prezentrii nregistrrilor de detaliu privind codul, numele, prenumele i specializarea fiecrui asistent (Detail) Pentru exemplificare se va prezenta i un fragment din raport, n forma n care poate fi consultat pe ecran sau tiprit de ctre utilizatorul final.
Studiu individual: a) S se realizeze un raport pentru afiarea medicilor care deservesc fiecare secie a clinicii. b) S se realizeze un raport pentru afiarea istoricului medical al fiecrui pacient (fia pacientului).
192
Studii de caz
Se dorete realizarea unei baze de date pentru gestiunea comenzilor primite de ctre un studio foto. Oferta de servicii a studioului este organizat sub forma unui catalog n cadrul cruia fiecare serviciu oferit este identificat printr-un cod, specificndu-se, de asemenea, denumirea i preul unitar al serviciului. Pentru fiecare comand primit de ctre studioul foto se atribuie un numr unic (cu rol de identificare), nregistrndu-se i data la care a fost nregistrat. De asemenea, se impune existena unui atribut pentru stabilirea tipului de livrare a comenzii (la studio sau prin curier, la domiciliul clientului). nregistrarea coninutului fiecrei comenzi (necesar pentru calculul valorii acesteia i apoi pentru ncasare) presupune cunoaterea cantitii comandate din fiecare serviciu oferit (pe baza catalogului de servicii). n vederea obinerii unei evidene a clienilor studioului, precum i pentru a rspunde cerinelor legate de livrarea la domiciliu, este necesar nregistrarea unor date personale ale acestora. Ca urmare, n momentul plasrii primei comenzi, fiecrui client i se atribuie un cod de identificare, pe care l va utiliza pentru toate comenzile ulterioare. n plus, va fi necesar cunoaterea numelui, adresei i oraului de domiciliu, pentru situaia n care o comand nu va fi ridicat de la studio, ci va fi livrat prin curier direct la domiciliul clientului. Reguli de gestiune: Un client al studioului poate plasa mai multe comenzi; O comand aparine unui singur client (este plasat de ctre un singur client); O comand poate conine mai multe servicii (n cantiti diferite); Acelai serviciu (din catalog) se poate afla pe mai multe comenzi (n cantiti diferite); Pe fiecare comand, fiecare serviciu se nregistreaz o singur dat; Preurile serviciilor sunt fixe. I. Realizai modelul relaional al bazei de date i implementai n MS Access Realizarea modelului relaional presupune identificarea prealabil a atributelor care vor intra n componena acestui model, precum i centralizarea lor n forma dicionarului de atribute. Pentru problema enunat, dicionarul de atribute are urmtorul coninut (ordonat alfabetic):
XI
Baz de date pentru evidena comenzilor primite de ctre un studio foto
193
DICIONAR DE ATRIBUTE
Adres Cantitate CodClient CodServiciu Data Denumire NrComand Nume Ora Pre TipLivrare
n vederea obinerii modelului relaional aferent acestui dicionar de atribute se va construi matricea dependenelor funcionale. Din cauza limitrilor de spaiu, se va prezenta forma restrns a acestei matrice (pe una dintre dimensiuni vor fi specificate doar atributele cu rol de cheie primar, nu ntregul coninut al dicionarului). n acest scop, se vor marca n list acele atribute care au rol de identificare n cadrul modelului. Casetele de culoare neagr din cadrul matricei marcheaz dependenele funcionale triviale (faptul c fiecare atribut depinde funcional de el nsui). Casetele de culoare gri marcheaz dependenele multivaloare, pe baza crora nu se pot trage concluzii cu privire la forma final a modelului relaional. Marcajul 1T indic existena unei dependene funcionale tranzitive ntre cheia primar de pe coloan i atributul corespunztor liniei, iar marcajul 1 indic existena unei dependene funcionale directe ntre cele dou elemente menionate. ATRIBUTE Denumire Adres Cantitate CodClient CodServiciu Data Denumire NrComand Nume Ora Pre TipLivrare CHEI PRIMARE 04 07 1T 1T 1 1 1 1 1 1 1T 1T
Nr. 01 02 03 04 05 06 07 08 09 10 11
03 1
04+07 1T 1 1T 1T 1T 1T 1T 1T 1T
Modelul relaional al bazei de date este urmtorul: Client (CodClient, Nume, Adresa, Oras) Comanda (NrComanda, Data, TipLivrare, CodClient) Continut (NrComanda, CodServiciu, Cantitate) Serviciu (CodServiciu, Denumire, Pret)
194
Studii de caz
n scopul implementrii n SGBD Microsoft Access 2007 a modelului relaional obinut, este necesar stabilirea tipului de date ce va fi atribuit fiecrui atribut. Opinia autorului cu privire la tipurile de date cele mai potrivite pentru cazul n discuie este prezentat n tabelul urmtor:
ATRIBUTE DE TIP NUMERIC (Tipurile NUMBER i AUTONUMBER)
DENUMIRE ATRIBUT Cantitate CodClient CodServiciu NrComand Pre DENUMIRE ATRIBUT Adres Denumire Nume Ora TipLivrare TIP DE DATE Number, Long Integer AutoNumber, Long Integer, Random AutoNumber, Long Integer, Increment AutoNumber, Long Integer, Random Number, Single LUNGIME (CARACTERE) 255 200 50 30 20 TIP DE DATE Date/Time
ATRIBUTE DE TIP ALFANUMERIC (Tipul de date TEXT)
ATRIBUTE DE TIP DAT (Tipul de date DATE/TIME)

DENUMIRE ATRIBUT Dat
Observaii: 1. Implementarea modelului relaional n SGBD Access se va realiza fr a utiliza caracterele diacritice specifice limbii romne. 2. n scopul pstrrii compatibilitii tipului de date dintre cheia primar a unei tabele i cheile externe corespunztoare, fiecrei chei primare de tip AutoNumber i vor corespunde chei externe de tip Long Integer. n opinia autorului, procesul de definire a atributelor i alegere a tipurilor de date trebuie completat cu o serie de constrngeri suplimentare, pentru a asigura integritatea i consistena datelor, dar i pentru a facilita utilizarea bazei de date i popularea acesteia. n acest sens se va propune i exemplifica realizarea urmtoarelor tipuri de restricii de integritate (constrngeri): Atributul TipLivrare (din tabela Comand) are un domeniu de valori bine definit i, ca urmare, posibilitile de introducere a datelor ar trebui limitate la lista de valori corespunztoare acestui domeniu. Figura urmtoare exemplific utilizarea instrumentului LOOKUP oferit de SGBD Access 2007 pentru realizarea unei liste de valori alfanumerice (tipul de date Text). n plus,
195
limitarea posibilitilor de introducere de date la variantele prestabilite s-a realizat cu ajutorul proprietii Limit To List, care a primit valoarea Yes.
Figura de mai sus exemplific stabilirea valorilor predefinite ale unui atribut de tip Text (TipLivrare). Pentru atributul Dat (din tabela Comand) se intenioneaz furnizarea unei valori implicite (considerat ca potrivit pentru o mare parte din situaii), urmnd ca aceasta s fie modificat liber de ctre utilizator n situaiile n care nu este aplicabil. n cazul acestui atribut, valoarea ar putea fi data curent a sistemului. Cea mai simpl metod de a obine acest tip de comportament este apelul la funcia Date, care returneaz data curent a sistemului i plasarea acestui apel n seciunea Default Value a listei de proprieti pentru cmpul vizat (figura urmtoare):
n scopul de a facilita stabilirea valorilor pentru cmpurile cu rol de cheie extern, instrumentul LOOKUP oferit de SGBD Access 2007 poate fi utilizat pentru a afia n cadrul cmpului-cheie extern toate valorile cheii primare
196
Studii de caz
corespunztoare (toate valorile care respect integritatea referenial). n funcie de situaie, o asemenea afiare poate include i alte cmpuri suplimentare, care nu fac parte din cheie dar faciliteaz nelegerea valorilor cheii. Afiarea unor cmpuri suplimentare sau ascunderea cmpului cu rol de cheie extern nu afecteaz n nici un fel relaiile dintre cele dou tabele implicate, fiind doar o metod de mbuntire a ergonomiei interfeei. De exemplu, adugarea numelui i prenumelui unui client la codul acestuia poate elimina ambiguitile n selectarea clientului care a plasat o anumit comand (cheia extern CodClient din tabela Comand). n acest caz, proprietatea Bound Column stabilete care dintre coloanele afiate conine cheia extern propriu-zis, proprietatea Column Count stabilete numrul de coloane afiate, iar proprietatea Column Widths poate fi utilizat pentru a preciza explicit limea fiecrei coloane (sau pentru a ascunde una dintre coloane). Tehnica descris este exemplificat n figurile urmtoare:
Efectele procedurii descrise anterior sunt prezentate n figura urmtoare:
Tabelele i relaiile obinute n urma implementrii n Microsoft Access, sunt prezentate n figura din pagina urmtoare.
197
Studiu individual: Completai modelul anterior, astfel nct s rspund i urmtoarelor cerine: Baza de date trebuie s asigure evidena facturrii i ncasrii comenzilor primite de la clieni. n acest sens, se vor implementa o serie de tabele adiionale, conform cu urmtoarele reguli de gestiune: * O comand (de facturat) apare pe o singur factur; * O factur poate centraliza mai multe comenzi ale aceluiai client; * O factur poate fi pltit prin intermediul a mai multe documente de plat; * Un document de plat poate achita mai multe facturi;
II. n tabelele modelului realizat la cerina anterioar se vor stabili urmtoarele proprieti: II.a) Deoarece studioul foto i-a nceput activitatea la 1 ianuarie 2003, pentru comenzile primite de la clieni nu se vor accepta date de plasare anterioare acestei valori. Condiia ca valorile cmpului Dat (din tabela Comand) s fie ulterioare datei de 1.1.2003 se va implementa n cadrul proprietii Validation Rule a acestui cmp. De asemenea, se recomand utilizarea proprietii Validation Text pentru stabilirea unui mesaj de avertizare n cazul n care o valoare introdus nu respect regula menionat anterior. Exemplul din figura alturat ilustreaz limitarea domeniului de valori pentru cmpul Dat
198
Studii de caz
II.b) n scopul pstrrii consistenei datelor din baza de date, este necesar implementarea unei restricii la nivelul cmpului Cantitate (din tabela Coninut) care s limiteze domeniul de valori la cele strict pozitive (cantitatea nu trebuie s ia valori negative sau s fie zero). De asemenea, lipsa unei valori (Null) pentru atributul Cantitate poate conduce la imposibilitatea de a calcula suma total a unei comenzi i, ca urmare de a nregistra ncasarea acestei sume. Pentru a evita aceste situaii, vor fi stabilite valorile corespunztoare aferente proprietilor Validation Rule, Validation Text i Required. Modul de stabilire a restriciilor este prezentat n figura urmtoare. Exemplul ilustreaz Implementarea unor restricii la nivelul cmpului Cantitate.
Studiu individual: a) Se cere completarea tabelei Comand cu un atribut de tip dat, numit DataLivrare, precum i stabilirea unor restricii la nivel de tabel, astfel: pentru comenzile care se preiau direct de la studio, data livrrii este ulterioar cu cel puin dou zile datei comenzii, iar pentru comenzile care se livreaz la domiciliu, data livrrii este ulterioar cu cel puin patru zile datei comenzii b) Se cere modificarea condiiei de la punctul II.b) pentru situaia n care se accept i valori negative ale atributului Cantitate (n scop rectificativ).
199
III. Realizai interogri (Queries) pentru urmtoarele cerine: III.a) S se afieze clienii din Bucureti
III.b) S se afieze numrul de comenzi nregistrate dup 1 ianuarie 2007
III.c) S se afieze n ordine alfabetic numele, adresa i numrul de comenzi plasate, pentru clienii care au transmis cel puin trei comenzi dup 1 ianuarie 2007
200
Studii de caz
III.d) S se afieze numrul de comenzi cu livrare la domiciliu aferente fiecrui client
Studiu individual: a) S se afieze serviciile din catalog n ordinea descresctoare a cantitii totale comandate b) S se afieze serviciul solicitat de cei mai muli clieni
201
IV. Realizai interogri SQL pentru urmtoarele cerine: IV.a) S se afieze datele clienilor care nu sunt din Bucureti
SELECT Client.CodClient, Client.Nume, Client.Adresa, Client.Oras FROM Client WHERE Client.Oras < > "Bucuresti";
IV.b) S se afieze cele mai noi trei comenzi

SELECT TOP 3 Comanda.NrComanda, Comanda.Data FROM Comanda ORDER BY Comanda.Data DESC;
IV.c) S se afieze numrul de servicii de pe fiecare comand

SELECT Comanda.NrComanda, Count(Continut.CodServiciu) AS NrServicii FROM Comanda INNER JOIN Continut ON Comanda.NrComanda = Continut.NrComanda GROUP BY Comanda.NrComanda;
IV.d) S se afieze numrul de comenzi primite dup 2005

SELECT Count(Comanda.NrComanda) AS NrComenzi FROM Comanda WHERE Comanda.Data >= #1/1/2006#;
IV.e) S se afieze numrul de comenzi plasate n 2007 pentru fiecare serviciu din catalog
SELECT Serviciu.Denumire, Count(Continut.NrComanda) AS NrComenzi FROM Comanda INNER JOIN (Serviciu INNER JOIN Continut ON Serviciu.CodServiciu = Continut.CodServiciu) ON Comanda.NrComanda = Continut.NrComanda WHERE Year([Data])=2007 GROUP BY Serviciu.Denumire;
IV.f ) S se afieze numrul de comenzi primite n fiecare an

SELECT Year([Data]) AS An, Count(Comanda.NrComanda) AS NrComenzi FROM Comanda GROUP BY Year([Data]);
IV.g) S se afieze anul n care s-au primit cele mai multe comenzi
SELECT TOP 1 Year([Data]) AS An, Count(Comanda.NrComanda) AS NrComenzi FROM Comanda GROUP BY Year([Data]) ORDER BY Count(Comanda.NrComanda) DESC;
202
Studii de caz
IV.h) S se afieze clienii, n ordinea descresctoare a numrului de comenzi plasate

SELECT Client.CodClient, Client.Nume, Client.Adresa, Client.Oras, Count(Comanda.NrComanda) AS NrComenzi FROM Client INNER JOIN Comanda ON Client.CodClient = Comanda.CodClient GROUP BY Client.CodClient, Client.Nume, Client.Adresa, Client.Oras ORDER BY Count(Comanda.NrComanda) DESC;
IV.i) S se creeze tabela ClientiProvincie care s conin datele personale i numrul de comenzi ale fiecrui client din afara Bucuretiului
SELECT Client.CodClient, Client.Nume, Client.Adresa, Client.Oras, Count(Comanda.NrComanda) AS NrComenzi INTO ClientiProvincie FROM Client INNER JOIN Comanda ON Client.CodClient = Comanda.CodClient GROUP BY Client.CodClient, Client.Nume, Client.Adresa, Client.Oras HAVING Client.Oras < > "Bucuresti";
IV.j) S se tearg din tabela creat anterior datele clienilor al cror nume ncepe cu litera M
DELETE ClientiProvincie.* FROM ClientiProvincie WHERE ClientiProvincie.Nume Like "M*";
Studiu individual: a) S se afieze numele clienilor din Bucureti care au transmis comenzi nainte de 1 ianuarie 2006 b) S se afieze numrul de clieni din fiecare ora c) S se afieze datele celei mai noi comenzi care solicit serviciul Retuare d) S se afieze numrul maxim de comenzi plasate din acelai ora n 2008 e) S se reduc cu 10% preul tuturor serviciilor pentru care s-au nregistrat mai puin de trei comenzi f) S se tearg datele pacienilor care nu au plasat nici o comand
V. Se vor realiza obiecte de tip formular pentru urmtoarele cerine: V.a) Realizai un formular pe baza tabelei Comand, care s permit preluarea sau afiarea complet a unei comenzi. n acest scop, formularul va trebui s conin un subformular pentru afiarea datelor clientului (pe baza codului de client selectat din formularul principal), precum i un subformular pentru selectarea i afiarea coninutului comenzii (datele cu privire la serviciile comandate). n plus, se impune prezentarea unor cmpuri suplimentare, cu valori calculate, pentru suma net, taxa pe valoare adugat i suma brut aferent fiecrui serviciu. Valoarea net a serviciului se calculeaz prin nmulirea cantitii comandate (preluat din tabela Coninut) cu preul unitar al serviciului (preluat din
203
tabela Serviciu). Pentru calculul TVA aferent unui serviciu comandat, valoarea net a serviciului se a nmuli cu cota de TVA, iar pentru obinerea valorii brute, valoarea net a serviciului se va nsuma cu valoarea TVA aferent. n scopul facilitrii obinerii acestor valori la nivelul formularului, se recomand calculul lor prealabil, n cadrul unei interogri (numit Sursa), al crui coninut este prezentat n figura urmtoare:
Interogarea prezentat anterior se va utiliza ca surs de date pentru un formular de tip Multiple items, care va afia i va permite actualizarea coninutului comenzii. n subsolul acestui formular (seciunea Form Footer) se vor aduga trei casete text (controlul TextBox) cu scopul de a afia valoarea total (suma) aferent fiecrei coloane totalizabile. Structura i modul de prezentare ale acestui formular, precum i formulele de calcul aferente casetelor de total sunt descrise n figura de mai sus. Pentru afiarea datelor clientului se va realiza un formular avnd ca surs de date tabela Client, formular a crui structur este prezentat n figura urmtoare.
204
Studii de caz
n final, se va crea un formular avnd ca baz tabela Comand, n cadrul cruia vor fi integrate cele dou subformulare descrise anterior. n acest scop se vor utiliza dou controale Subform/Subreport, fiecare avnd rol de container pentru cte unul din cele dou subformulare. Deoarece toate cele trei formulare implicate au sursele de date legate prin chei externe, SGBD Access va deduce relaiile logice dintre ele, actualiznd automat datele clientului i coninutul comenzii n momentul afirii acesteia. Formatul final al formularului este prezentat n figura alturat.
Studiu individual: a) S se realizeze un formular pentru afiarea tuturor serviciilor oferite i a tarifelor aferente). b) S se realizeze un formular cu subformular pentru afiarea datelor i valorilor comenzilor aferente unui client (fr a afia i coninutul acestor comenzi).
VI. Se vor realiza obiecte de tip raport pentru urmtoarele cerine: VI.a) Afiarea coninutului unei comenzi i a datelor clientului care a transmis-o. Coninutul unui asemenea raport presupune centralizarea datelor din cel puin trei tabele: Comand, Client i Coninut. Din acest motiv, s-a optat pentru o structur pe mai multe nivele, aa cum este prezentat n figura urmtoare:
205
Structura pe mai multe nivele presupune definirea de seciuni Header multiple n cadrul raportului. De asemenea, pentru o prezentare mai compact a antetului comenzii, datele clientului au fost comasate n cadrul acestui antet. n scopul unei utilizri ct mai flexibile, se recomand specificarea numrului comenzii printr-un parametru, astfel nct raportul s poat fi folosit pentru tiprirea unei singure comenzi. Pentru exemplificare se va prezenta i un fragment din raport, n forma n care poate fi consultat pe ecran sau tiprit de ctre utilizatorul final.
Studiu individual: a) S se realizeze un raport pentru afiarea serviciilor solicitate n timp de ctre fiecare client. b) S se realizeze un raport pentru afiarea serviciilor din catalog, n ordinea descresctoare a popularitii (dat de ordinea descresctoare a numrului de comenzi).
206
Studii de caz
Bibliografie
Microsoft Access 2007 Step By Step, Steve Lambert, Microsoft Press, 2007 Baze de date, Florescu Vasile (coordonator), Ionescu Bogdan (coordonator) ; Cozgarea Gabriel, Vrincianu Marinela, Tudor Catalin, Aleca Ofelia, Rdulescu Cristina, Editura Infomega, 2009 Baze de date Fundamente teoretice i practice, Grupul BDASEIG, Editura Infomega, 2002 Tehnologia bazelor de date Access 2000, Pavel Nstase, Florin Mihai, Andrei Stanciu, Liana Covrig Editura Economic, 2001 http://databases.about.com http://office.microsoft.com http://www.ms-access2007.com

Studii de Caz Access 2007

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Studii de Caz Access 2007

Uploaded by

Copyright:

Available Formats

Baze de date Access 2007

2009 Editura InfoMega

Editur acreditat de C.N.C.S.I.S.

e-mail: office@infomega.ro http://www.infomega.ro

CIP Nr. 6275/27.03.2009

Autor: Asistent univ. drd. Rdulescu Cristina

Autor: Confereniar univ. dr. Oancea Mirela

Autor: Asistent univ. drd. Geambau Cristina

Autor: Lector univ. dr. Stanciu Andrei

Autor: Asistent univ. drd. Rdulescu Cristina

Autor: Lector univ. drd. Aleca Ofelia

Autor: Lector univ. drd. Aleca Ofelia

Autor: Confereniar univ. dr. Mihai Florin

Autor: Lector univ. dr. Stanciu Andrei

X. Baz de date pentru evidena activitii unei clinici medicale 176

Autor: Lector univ. dr. Mangiuc Drago

Autor: Lector univ. dr. Mangiuc Drago

Baze de date Access 2007

Baz de date pentru evidena mprumuturilor de cri n cadrul unei biblioteci

Baze de date Access 2007

Baze de date Access 2007

Baze de date Access 2007

Baze de date Access 2007

Baze de date Access 2007

- Procedura asociat evenimentului AfterUpdate: Private Sub cboCota_AfterUpdate()

Dim rsCarti As Recordset Set rsCarti = Me.RecordsetClone

Me.cboCota.Requery MsgBox "Inregistrarea a fost salvata!", vbInformation End If End Sub

Baze de date Access 2007

Studii de caz AND Abonament.CodTipAbonament = TipAbonament.CodTipAbonament AND Tmp.CodAbonament = Abonament.CodAbonament;

Dim nr_carti As Byte

Baze de date Access 2007

Structura raportului, n modul Design, este urmtoarea:

Baze de date Access 2007

Baze de date Access 2007

Baz de date pentru evidena contractelor ncheiate de o agenie de turism

Baze de date Access 2007

Matricea dependenelor funcionale

Modelul relaional obinut cu ajutorul matricei dependenelor funcionale este urmtorul:

Implementarea modeluluiu in Access este prezentat n figura urmtoare:

GROUP BY MONTH([DataIncheiereContract]) HAVING COUNT(Contracte.NrContract)>3 ORDER BY MONTH([DataIncheiereContract]);

i combo box-ul de cutare a turitilor

V.b) Realizai un formular cu subformular pentru gestionarea contractelor ncheiate de agenie:

Private Sub Form_Current() Me.semnatar.Requery End Sub

Selecia perioadei se face prin intermediul formularului Listare:

IV.b) S se afieze modulele pentru care nu s-a organizat nici o testare.

Tip control: Combo Box

Tip control: Button

Tip control: List Box

Tip control: Button

Tip control: Text Box

Tip control: Combo Box

Tip control: Button

Tip control: Text Box

Tip control: Text Box

Tip control: Button

Tip control: Button

Interogarea TestariProgramate are urmtorul coninut:

If lstTestariProgramate.ItemsSelected.Count = 0 Then MsgBox "Selectati o testare din lista!" Else

Dim Item As Variant Set Item = lstTestariProgramate.ItemsSelected txtIDTestare = lstTestariProgramate.Column(0, Item)

setul.AddNew setul!CNP = cbocnp.Value setul!idtestare = txtIDTestare.Value setul.Update

62 MsgBox "Inscriere efectuata" End If End Sub

Vrsta se calculeaz ca diferen ntre data curent i data naterii.

Name: txtVarsta Control Source: Tip control: Text Box

=IIf(IsNull([cnp]);"";Int((Now()[txtDataNasterii])/365,25) & " ani")