Embed Size (px)
Citation preview
Baza de date pentru informatizarea si contabilizarea salariilor si a
altor drepturi de personal
„Din adevărata creaţie nu se obţine totul perfect, ci perfectibil.”
Capitolul 1
BAZĂ DE DATE PENTRU INFORMATIZAREA ŞI CONTABILIZAREA
SALARIILOR ŞI A ALTOR DREPTURI DE PERSONAL.
1.1. Prezentarea temei
În contextul societăţii actuale, caracterizată printr-o explozie informaţională fără
precedent în istoria omenirii, sistemele informatice reprezintă unul din elementele
fundamentale care generează şi controlează fluxurile informaţionale la nivel micro şi
macroeconomic. De mai bine de două decenii, bazele de date prin performanţele şi avantajele
acestora au reprezentat şi vor rămâne în continuare modalitatea principală de structurare şi
organizare a datelor în cadrul sistemelor informatice. În plus, producătorii de software au
creat Sisteme de Gestiune a Bazelor de Date din ce în ce mai performante şi în acelaşi timp
cât mai simplu de utilizat.
Lucrarea este structurată în două părţi:
Prima parte formată din capitolele 2 şi 3, constituie o prezentare succintă a
conceptului de bază de date şi a modului de operare cu acest concept, reprezentând în acelaşi
timp şi suportul teoretic al lucrării.
Partea a doua, formată din capitolele 4, 5 şi 6, este dedicată prezentării unui caz
concret de realizare a unei baze de date, în speţă, o bază de date pentru informatizarea şi
contabilizarea salariilor şi a altor drepturi de personal.
1.2. Scopul şi obiectivele temei
Înregistrarea şi calculul salariilor reprezintă, din punct de vedere organizatoric, o grea
încercare pentru cei care veghează la buna lor desfăşurare. Sunt necesare:
Pagina 3 din 46
introducerea, modificarea sau ştergerea din baza de date a informaţiilor referitoare la
salariaţi, cu înregistrarea concediilor şi întocmirea foii colective de prezenţă;
calcularea drepturilor şi reţinerilor salariale;
înregistrarea în contabilitate a drepturilor şi reţinerilor salariale;
afişarea rezultatelor.
Calculatorul poate veni în sprijinul acestei activităţi care în mod obişnuit se face
manual.
Lucrarea de faţă îşi propune evidenţierea utilităţii unei baze de date în uşurarea
muncii de înregistrare şi calculare a salariilor şi a altor drepturi salariale. Pentru aceasta este
necesară cunoaşterea şi înţelegerea conceptului de bază de date şi a modului în care
informaţiile din mediul extern pot fi stocate şi manevrate într-o bază de date.
Noua legislaţie vine cu o serie de modificări (faţă de anii trecuţi) de care trebuie să se
ţină cont în realizarea structurii bazei de date şi a modului de înregistrare a informaţiilor.
1.3. Argumentarea necesităţii temei.
Privită din exterior, organizarea contabilizării drepturilor şi obligaţiilor personalului
angajat la o entitate publică sau privată, necesită atât efort cât şi timp pentru completarea,
verificarea, calcularea şi afişarea unor rapoarte cum sunt foaia colectivă de prezenţă, statele
de plată, etc. De asemenea în unităţile publice sau private unde numărul de angajaţi este
foarte mare, unde există un volum foarte mare de date care trebuie prelucrate într-un timp
foarte scurt se cere automatizarea prelucrării datelor. Astfel se naşte ideea automatizării
acestei activităţi prin punerea la dispoziţia unităţilor publice şi private a unei baze de date şi a
unui program care să permită prelucrarea rapidă şi eficientă a datelor. Astfel se prelucrează
cu uşurinţă orice informaţie primită, se contabilizează şi orice modificare ulterioară de orice
fel să poată fi făcută uşor astfel încât cei care utilizează software-ul respectiv şi cei care
asigură service-ul programului informatic să fie mulţumiţi din toate punctele de vedere.
1.4. Analiza comparativă a abordărilor existente la ora actuală în ceea ce priveşte tematica de
licenţă.
Toată această muncă laborioasă necesita scrierea listelor manual sau cu o maşină de
scris, calculul salariilor şi altor drepturi de personal cu un calculator de buzunar, o alternativă
Pagina 4 din 46
recentă o constituie utilizarea unui program de calcul tabelar, Microsoft Excel, care
automatizează întru-câtva activitatea şi uşurează munca membrilor compartimentului
financiar-contabil. Mai există o serie de programe realizate în FoxPro, dar manevrarea lor
este greoaie, iar listarea la imprimantă nu este rezolvată pe deplin. De aceea consider
necesară folosirea unui SGDB performant pentru proiectarea unei aplicaţii capabile să devină
de un ajutor real celor care se „războiesc” cu organizarea contabilităţii salariilor şi altor
drepturi de personal.
Fără pretenţia deşartă că este o aplicaţie completă şi mergând pe ideea că orice
aplicaţie este perfectibilă, invit cititorii şi mai ales cunoscătorii să completeze această
aplicaţie astfel încât, în timp, să îi crească performanţele. Dar pentru aceasta este nevoie de
cunoaşterea noţiunilor teoretice şi dezvoltarea deprinderilor practice legate de baze de date şi
SGBD-uri în general şi a Microsoft Access în particular. Pentru aceasta recomand
aprofundarea noţiunilor teoretice prezentate în capitolele următoare.
Capitolul 2
NOŢIUNI INTRODUCTIVE
Prelucrarea automată a datelor nu se poate face la întâmplare, haotic ci numai în
cadrul unui sistem de organizare a acestora, după metode, tehnici şi procedee bine stabilite.
Organizarea şi prelucrarea datelor este parte integrantă din procesul de dezvoltare a
sistemelor informatice sau a aplicaţiilor care se subordonează.
Pentru ca multitudinea de date existente să poată fi prelucrată, aceasta trebuie să fie
organizată şi structurată pe diferite categorii. Aceste categorii de date, trebuie la rândul lor să
fie convertite într-o informaţie înţeleasă de către calculator şi care să poată fi depozitată pe
diferiţi suporţi de memorie.
În cadrul procesului de organizare, stabilirea structurilor fizice şi logice de date
reprezintă elemente fundamentale de care depinde eficienţa şi viteza prelucrării. Practic,
există o varietate foarte mare de situaţii, ceea ce face imposibilă formularea unei soluţii
universale. Din această cauză, fiecare aplicaţie practică trebuie foarte atent studiată pentru a
se putea stabili cele mai bune soluţii de înregistrare şi manipulare a datelor.
2.1. Noţiunea de dată. Data scalară, data, informaţia şi cunoştinţele.
Din punct de vedere informatic, prin dată se înţelege un model de reprezentare a
informaţiei accesibile unui anumit procesor (om, unitate centrală, aplicaţie de calcul etc.),
model cu care se poate opera pentru a obţine noi informaţii despre fenomenele, procesele şi
Pagina 5 din 46
obiectele lumii reale sau mai nou a lumii virtuale. O dată care este o entitate invizibilă în
raport cu informaţia care o poartă sau cu procesul la care participă este o dată scalară sau
elementară. O dată scalară, din punct de vedere a reprezentării informaţiei, poate fi privită
logic la nivel de procesor uman şi fizic la nivelul calculatorului sau procesorului fizic.
O dată scalară de defineşte, din punct de vedere logic, prin trei elemente: identificator,
atribute şi valori, iar din punct de vedere fizic corespunde unei anumite zone de memorie de o
anumită valoare. Identificatorul este un simbol sau nume care se asociază datei, pentru a o
distinge de alte date sau tip de dată. Valoarea datei se defineşte printr-o proprietate care poate
fi de tip întreg, real, boolean, text, etc. Atributele precizează proprietăţi ale datei şi ele
determină modul în care aceasta va fi tratată în procesul de prelucrare. Astfel, dacă o aplicaţie
tratează vechimea la un calcul al salariilor de personal, vechimea va fi identificatorul valoarea
va fi rezultatul efectiv al calculului procentului aplicat asupra salarului de încadrare, iar
atributul în acest caz va fi tratarea valorii ca un număr zecimal.
Din punct de vedere al bazelor de date putem defini data mai simplu, ca fiind o
înregistrare într-un cod convenit a unei observaţii, obiect, fenomen, cunoştinţe, imagini, sunet
sau text.
Informaţia este cunoaşterea în general, adică aflarea de elemente noi privind un
obiect, o dată sau o colecţie de date. Mai simplu, informaţiile se obţin în urma prelucrării
datelor sau cu alte cuvinte, datele sunt purtătoare de informaţie.
Cunoştinţele reprezintă informaţii simple sau agregate care se dobândesc de-a lungul
timpului prin observare şi acumulare în ceea ce priveşte obiectele, fenomenele şi procesele
din lumea reală.
2.2. Structuri de date
În majoritatea aplicaţiilor, datele se prezintă sub forma unor mulţimi sau grupe de
mulţimi. Folosirea datelor sub această formă este destul de dificilă, din care cauză de caută
organizarea datelor sub formă de structuri care să aibă diferite relaţii între ele. O structură de
date este o entitate individualizabilă prin nume, a cărei componente îşi menţin proprietăţile.
Organizarea datelor în structuri se poate face informatic pe două componente:
organizarea datelor în memoria internă a calculatorului sub formă de listă, coadă,
stivă.
organizarea datelor pe memoria externă sub formă de fişiere şi baze de date.
Pagina 6 din 46
Structurile interne de date au de obicei un caracter temporar pe perioada procesării
datelor, iar structurile externe au caracter permanent, de lungă durată. Asupra unei structuri
de date se pot efectua o multitudine de operaţii, cele mai frecvente fiind:
crearea este operaţie de memorare a structurii de date, în forma iniţială, pe un suport
de memorie;
consultarea este accesul la elementele structurii de date în vederea prelucrării sau
procesării valorilor acestora;
actualizarea presupune schimbarea stării structurii prin adăugarea sau inserarea unor
elemente noi sau ştergerea elementelor care nu mai sunt necesare şi modificarea valorilor
unor elemente;
sortarea care este aranjarea structurii de date după anumite criterii sau cerinţe
formulate din partea utilizatorilor;
interogarea prin care se cere selectarea şi sortarea datelor după anumite condiţii
impuse;
fuzionarea sau concatenarea este combinarea a două sau mai multe structuri de date
ordonate într-o singură structură;
ventilarea este operaţia de desfacere a unei structuri în mai multe structuri de sine
stătătoare.
Operaţiile aplicate asupra unei structuri de date pot să îi afecteze valorile şi/sau
structura. Dacă o structură de date îşi modifică forma, atunci această structură este
considerată dinamică. Opusul structurilor dinamice sunt structurile statice, care pe tot
parcursul existenţei lor au acelaşi număr de componente şi în aceeaşi ordine.
2.3. Noţiuni privind conceptul de bază de date
O bază de date este o colecţie unitară, organizată şi structurată de date elementare,
împreună cu descrierea şi modul de gestionare a acestora. Gestionarea unei baze de date se
face printr-un pachet de programe specializate, numit sistem de gestiune a bazelor de date, pe
scurt SGBD. Fizic, datele se stochează în fişiere de unde sunt apoi preluate şi prelucrate cu
ajutorul SGBD.
Un fişier este un ansamblu de înregistrări fizice, omogene din punct de vedere a
conţinutului şi posibilităţilor de prelucrare, aşa cum este prezentat în imaginea următoare.
Pagina 7 din 46
Înregistrarea fizică este unitatea de transfer între memoria internă (temporară) şi
memorie externă (permanentă) şi invers a calculatorului. O înregistrare fizică se compune din
una sau mai multe înregistrări logice.
Înregistrarea logică este unitatea de informaţie care se introduce la un anumit moment
dat în memoria calculatorului. De obicei, o înregistrare corespunde unui rând de informaţie
introdusă într-o bază de date sub forma unei tabele. La rândul ei, înregistrarea este formată
dintr-un ansamblu de câmpuri care descriu diferite structuri de date corespunzătoare anumitor
situaţii practice.
În afara bazelor de date există şi bănci de date. Banca de date este tot o bază de date,
dar mai puţin structurată. Rolul unei bănci de date este adunarea informaţiilor de larg interes
în vederea folosirii acestora de un public cât mai larg. De exemplu, băncile de date pot
conţine informaţii privind mersul trenurilor, avioanelor, cursul valutar, fondul documentar al
unei biblioteci, etc.
2.4. Obiectivele fundamentale ale unei baze de date
Pentru ca o bază de date să aibă o funcţionalitate maximă, datele trebuie grupate şi
prezentate sub diferite structuri intercorelate între ele. Dispunerea datelor într-o bază de date
nu este haotică ci se respectă anumite reguli prevăzute şi impuse de programatorul care a
creat baza de date şi de sistemul de gestionare a bazei de date. Plecând de la cerinţele impuse
unei baze de date, obiectivele fundamentale pe care trebuie să le îndeplinească sunt:
centralizarea datelor pentru a permite suprimarea redundanţei, asigurarea unicităţii
înregistrărilor şi controlul în orice moment asupra datelor introduse;
Pagina 8 din 46
independenţa dintre date şi prelucrarea acestora, deoarece baza de date este în
permanenţă actualizată şi prelucrarea datelor se poate face permanent şi de diverşi utilizatori;
partajarea datelor permite înlănţuirea prelucrărilor solicitate simultan pe aceeaşi
înregistrare în baza de date, prin blocarea cerinţelor în aşteptare şi deservirea ulterioară a
acestora;
integritatea datelor trebuie asigurată pentru coerenţa şi fiabilitatea bazei de date;
securitatea datelor împotriva unei distrugeri fizice sau logice datorate unei utilizări
necorespunzătoare a programului, erorilor de programare sau reavoinţei utilizatorului;
confidenţialitatea datelor împotriva unor accesări nedorite a bazei de date, lucru care
se realizează prin identificarea utilizatorului prin nume sau cod, autentificarea prin parole şi
autorizarea diverselor drepturi de accesare pe diferite nivele a bazei de date.
2.5. Sistemul de gestiune a bazelor de date.
Pentru ca datele care se introduc într-o bază de date să poată fi procesate, trebuie ca
acestea să fie gestionate de sistemul de gestiune a bazelor de date, imaginea următoare fiind
relevantă în acest sens.
Pagina 9 din 46
De asemenea SGBD serveşte şi ca interfaţă între utilizator şi baza de date pentru a
permite acestuia să creeze o bază de date, să o actualizeze şi să o consulte. SGBD poate fi
definit ca un instrument de introducere, aranjare, asamblare, codificare, protecţie, sortare şi
regăsire a datelor în baza de date. Principalele funcţii pe care trebuie să le îndeplinească un
SGBD sunt:
memorarea datelor pe suportul extern prin sistemul de gestiune a fişierelor;
gestiunea datelor şi a legăturilor dintre ele în vederea unei regăsiri rapide prin
intermediul SGBD intern;
introducerea şi extragerea datelor din şi spre exterior în forma cerută de utilizator prin
intermediul SGBD extern.
Capitolul 3.
MODELE DE REPREZENTARE A DATELOR ÎN BAZELE DE DATE
Descrierea unui obiect oarecare dintr-o mulţime se poate realiza prin folosirea unor
caracteristici sau atribute specifice obiectului respectiv. Caracterizarea sau atributul defineşte
un aspect sau o latură a unui obiect din mulţimea respectivă. Cu cât, un obiect este descris cu
mai multe caracteristici, cu atât avem o viziune mai largă asupra obiectului respectiv. Nu se
recomandă nici folosirea exagerată a caracteristicilor.
De exemplu, dacă considerăm o persoană, putem să îi asociem următoarele
caracteristici:
Persoana: {Nume, Prenume, Prenumele tatălui, Data naşterii, Locul naşterii, Adresa, Telefon,
e-mail}.
Fiecare element dintre acolade reprezintă o caracteristică ce contribuie la descrierea
unei „Persoane”. Descrierea completă a unui obiect se face printr-o familie de caracteristici.
Dacă caracteristicile grupate într-o anumită familie respectă o anumită proprietate, atunci
familia de caracteristici este o colecţie de date. La rândul ei o colecţie de date se poate
subdivide în colecţii numite entităţi. Astfel „persoana” poate fi privită ca entitate, dacă nu se
mai subdivide, sau ca o colecţie de date, având o singură entitate.
Pagina 10 din 46
În cazul exemplului de mai sus, Numele persoanei poate fi numele entităţii, iar
celelalte caracteristici scrise cu litere îngroşate formează o familie de caracteristici.
3.1. Tipuri de structuri fundamentale în baza de date
Datele în bazele de date sunt organizate în liste (tabele) interconectate. Structura de
tip listă poate fi:
liniară;
arborescentă;
în reţea;
relaţională.
Structura liniară este o listă liniară cu elemente nestructurate. Listele liniare pot fi
reprezentate dispersat sau liniar (legat). Aceste structuri permit următoarele tipuri de operaţii:
consultare, actualizare, ştergere, compunere sau ventilare (descompunere) colecţii de date.
Structura arborescentă se prezintă sub forma unui arbore şi se bazează pe coexistenţa
a mai multor colecţii de date (tabele) şi a unei mulţimi de relaţii ierarhice. Colecţiile de date
sunt ierarhizate pe nivele de relaţii de subordonare. Structurile arborescente permit operaţiile:
adăugare sau ştergere, consultarea colecţiilor de date.
Pagina 11 din 46
Structura de tip reţea se bazează tot pe existenţa unei mulţimi de colecţii de date, dar
spre deosebire de reţeaua arborescentă în acest caz avem o mulţime de relaţii în reţea.
În acest fel orice colecţie poate avea mai mulţi predecesori, ceea ce permite accesul la
diferite colecţii pe căi multiple. De asemenea, o structură de tip reţea se poate descompune în
mai multe structuri arborescente relaţionate ierarhic. O astfel de descompunere duce la
creşterea redundanţei.
Pagina 12 din 46
Structura relaţională are la bază relaţii între caracteristice entităţilor, a căror realizări
formează n legături. Este obligatoriu ca una dintre caracteristice entităţilor să fie o cheie
primară, ceea ce permite realizarea de legături între diverse tabele sau baze de date. Cheia
primară se caracterizează prin faptul că în cele mai multe situaţii are o valoare unică, diferită
pentru fiecare înregistrare în baza de date.
3.2. Nivele de reprezentare a datelor în baza de date.
Realizarea unei baze de date presupune organizarea acesteia pe trei niveluri de
percepţie corespunzătoare la trei categorii de activităţi distincte. Aceste nivele de percepţie şi
ierarhizare a unei baze de date sunt:
nivelul extern, corespunzător utilizatorilor, care îşi exprimă cerinţele informaţionale
prin scheme externe corespunzătoare diverselor tipuri de interogări;
nivelul conceptual care este aferent administratorului bazei de date;
nivelul logic care stabileşte relaţiile care se stabilesc între diferitele entităţi ale bazei
de date;
nivelul intern corespunzător programatorului bazei de date care realizează
reprezentarea datelor pe suportul fizic.
Urmărirea şi determinarea structurii unei baze de date se poate face ascendent,
plecând de la schema externă, urmată de elaborarea schemei conceptuale sau invers. Trecerea
de la schema conceptuală a unei baze de date la schema internă se face prin intermediul
Pagina 13 din 46
limbajelor de descriere a datelor care sunt incluse în SGBD. Un model de date presupune un
limbaj de descriere a unei anumite realităţi, în timp ce o schemă este o descriere a unei
realităţi momentane.
Schema conceptuală a unei baze de date se obţine pe baza schemelor externe prin
eliminarea redundanţelor.
3.2.1. Nivelul extern de prezentare a datelor
La nivel extern, fiecare grup de lucru sau utilizator care manipulează datele posedă a
anumită descriere a acestora. Această descriere corespunde felului în care utilizatorii văd
baza de date în programele lor de aplicaţie. În concluzie, la nivelul conceptual şi intern
schemele descriu baza de date, dar la nivel extern se prezintă doar mulţimea datelor care
prezintă interes pentru un anumit utilizator sau grup de utilizatori.
Astfel, schema externă de reprezentare a datelor pentru serviciul personal poate fi
următoarea:
Angajat
Marca
Nume
Prenume
Studii
Funcţia ocupată
Salarizare
Scheme externe pot fi multiple, în funcţia de aplicaţia preconizată şi de nivelul de
accesibilitate a diverşilor utilizatori cu toate că schema internă şi cea conceptuală sunt unice.
Plecând de la o schemă externă se pot construi diverse scheme externe pentru subgrupuri ale
grupului de utilizatori consideraţi. Fiecare schemă externă trebuie să se regăsească obligatoriu
în schema conceptuală a bazei de date.
3.2.2. Nivelul conceptual al unei baze de date
Nivelul conceptual este nivelul central al unei baze de date care reflectă modul de
structurare a datelor astfel încât acestea să poată fi prelucrate cu ajutorului unui SGBD.
Nivelul conceptual al unei baze de date stă la baza dezvoltării modelului conceptual care
permite definirea proprietăţilor elementare ale obiectelor care ne interesează în proiectarea
Pagina 14 din 46
unei baze de date. De exemplu: obiectele des manipulate de o baza de date sunt clienţii
(articole cerute, cantitatea, facturarea, plata, termene de livrare, etc.), furnizorii (articole
furnizate, cantitatea, facturarea, plata, etc.), articolele de fabricaţie (tip, culoare, mărime,
tipodimensiune), salariaţi (tip contract, calificare, vârstă, adresă).
În proiectarea bazelor de date la nivel conceptual, modelul cel mai frecvent utilizat
este modelul „Entitate – Atribut - Corespondenţă” sau prescurtat EAC.
O entitate, după cum a mai fost definit şi anterior este un model de obiect identificat
în lumea reală a aplicaţiilor cerute de crearea bazei de date. Entitatea poate fi un obiect
material (persoană, lucru, etc.), un obiect imaterial care corespunde unui eveniment abstract.
Obiectele sunt definite prin nume (rezultând numele entităţii) şi printr-o listă de proprietăţi
sau atribute (caracteristici).
Atributul se defineşte ca fiind proprietatea unei entităţi sau corespondenţe
caracterizată prin nume şi tip. Trebuie acordată o atenţie deosebită selecţionării atributelor
unei entităţi, deoarece acestea permit ulterior procesarea bazei de date şi obţinerea unor
rezultate la interogările formulate care pot fi bune sau nesatisfăcătoare. Mulţimea valorilor
unui atribut va forma un domeniu.
O baza de date bine proiectată presupune individualizarea fiecărei valori a entităţii cu
ajutorul unui atribut sau grup de atribute. Astfel, identificatorul unei entităţi caracterizează în
mod unic o realizare sau înregistrare a entităţii.
Între două atribute ale aceleaşi entităţi sau între două sau mai multe atribute ale două
sau mai multe entităţi există o dependenţă funcţională când unui atribut (proprietăţi) îi
corespunde o singură valoare a celuilalt atribut. Această caracteristică conceptuală a unei
baze de date permite structurarea datelor plecând de la entităţi la sub entităţi. Prin această
bază de date devine mai flexibilă şi mult mai uşor de consultat.
O corespondenţă sau asociere reprezintă legătura logică între două sau mai multe
realizări sau înregistrări ale entităţii. La realizarea unei corespondenţe trebuie respectate
următoarele reguli:
o corespondenţă sau asociere nu poate exista de cât o singură dată între aceleaşi
entităţi;
numele entităţilor, corespondenţelor, atributelor trebuie să fie unice în cadrul
modelului conceptual şi apoi în baza de date.
Pentru a se înţelege mai bine definiţiile enunţate anterior se prezintă următorul
exemplu. Produsele finite ale unei întreprinderi de automobile sunt livrate unor clienţi.
Livrarea acestor produse se face pe baza unor facturi care trebuie să conţină seria facturii,
Pagina 15 din 46
data livrării, tipurile de automobile facturate, cantitatea din fiecare, preţul unitar, cota de
T.V.A. corespunzătoare produsului respectiv. Aceste date servesc în final la calcularea valorii
totale a facturii. Schematic, situaţia prezentată se poate face prin schema entitate-
corespondenţă, astfel:
Plecând de la această reprezentare grafică se pot identifica următoarele:
Entităţi: (Tip automobil şi Factura livrare);
Atribute:
(cod, denumire, model, culoare, dotare) pentru entitatea Tip automobil;
(nr. factură, data facturării, cota TVA) pentru entitatea Factura livrare;
(cantitatea, preţ unitar) pentru corespondenţa Se facturează.
Identificatori: (cod pentru entitatea Tip automobil şi nr. factură pentru entitatea
Factura livrare).
Corespondenţă: (Se facturează) care nu are un identificator.
În exemplul de mai sus apare o regulă de gestiune prin corespondenţa Se facturează.
Pe baza regulilor de gestiune se stabilesc restricţiile modelului, ceea ce asigură integritatea,
securitatea şi coerenţa datelor. Regulile de gestiune stabilesc cardinalităţi şi conectivităţi între
înregistrările atributelor din entităţi şi cele ale proprietăţilor de corespondenţă sau asociere.
Cardinalităţile şi conectivităţile exprimă modul de participare a valorilor atributelor din
entităţi la fiecare apariţie de valori de asociere. Astfel putem avea o conectivitate minimă (0
sau 1) şi una maximă (1 sau n).
Plecând de la exemplul anterior, pentru stabilirea corectă a cardinalităţilor se va ţine
seama de următoarele reguli:
un tip de automobil, într-un anumit interval de timp, poate fi cuprins între minim sau
zero facturi sau se poate factura de mai multe ori, cu alte cuvinte se va regăsi în n facturi.
Pagina 16 din 46
Factura întocmită la o anumită dată poate conţine, în cantităţi şi la preţuri diferite,
minimum un tip de automobil şi maximum n produse.
Cardinalităţile stabilite pentru exemplul prezentat se regăsesc în imaginea următoare:
Între înregistrările aceleaşi entităţi pot exista şi corespondenţe reflexive. Pentru o bază
de date cu angajaţii unei firme, situaţia unui angajat pe scara ierarhică poate fi ca cea ilustrată
în figura următoare:
Pentru stabilirea cardinalităţilor s-au respectat următoarele reguli:
Un angajat nu poate să aibă în subordine nici un angajat (minimum 0), sau poate
conduce mai mulţi angajaţi (maximum n).
Pagina 17 din 46
Totdeauna un angajat poate fi condus de minim zero angajaţi (cazul directorului
firmei) şi de maxim un angajat-şef.
3.2.2.1. Restricţii de integritate a datelor
La realizarea modelului conceptual al unei baze de date trebuie să se ţină seama de
anumite reguli care trebuie să fie respectate permanent. Aceste reguli se numesc restricţii de
integritate (RI). Astfel de restricţii de integritate a datelor pot fi:
eliminarea redundanţelor sau repetărilor şi a omonimelor în denumirea entităţilor,
atributelor, corespondenţelor;
valorile atributelor cu rol de identificator trebuie să fie unice şi nenule;
cardinalităţile minime şi maxime se stabilesc pe baza regulilor de desfăşurare a
activităţilor în sectorul vizat în construcţia bazei de date;
în cazul asocierilor orice realizare a acestora impune existenţa înregistrărilor
entităţilor participante (integritate referenţială).
Pentru exemplificare se consideră facturarea produselor care se livrează unor clienţi
(reprezentată în imaginea de mai jos).
În cazul acestui exemplu, la facturare, cardinalitatea minimă şi maximă este 1,
deoarece întocmirea unei facturi trebuie să vizeze un client, iar la livrare acea factură este
trimisă numai acelui client pentru care s-a făcut facturarea. În cazul clientului cardinalitatea
minimă poate să fie nulă (nu i-a fost emisă nici o factură), iar cardinalitatea maximă ajunge la
n (numărul total de facturi primite de la furnizori).
De asemenea la realizarea facturării pot fi incluse şi anumite restricţii:
data facturării să nu fie anterioară datei curente;
capacitatea cilindrică a autovehiculelor facturate să fie cuprinsă doar în gama celor
fabricate (1000, 1300, 1600, 2000 cm³).
3.2.2.2. Rolurile unei entităţi
Pagina 18 din 46
O aceeaşi entitate, în cadrul unei baze de date, poate avea mai multe roluri în funcţie
de aplicaţia concretă la care participă.
Astfel între rolurile unei entităţi pot apărea următoarele situaţii:
Incluziunea de roluri, ceea ce presupune ca un rol al entităţii într-o asociere impune
un alt rol al său într-o altă asociere. Pentru exemplificare se consideră primirea unui
document de încasare generat de plata efectuată de un client pentru livrarea la domiciliu a
unor produse. Livrarea produselor are loc numai după ce în prealabil a fost emisă şi trimisă o
factură corespunzătoare. Incluziunea de roluri se reprezintă prin simbolul: .
Excluziune de roluri apare în situaţia în care roluri ale aceleiaşi entităţi se exclud
reciproc. Astfel, o firmă de vânzare şi închiriere automobile trebuie să ţină seama de faptul că
o maşină închiriată nu poate să fie şi vândută în acelaşi timp şi invers. Cele două roluri ale
entităţii automobil (închiriere şi vânzare) se exclud reciproc. Excluziunea de roluri se
simbolizează cu #:
Egalitatea de roluri înseamnă o restricţie de incluziune reciprocă între două roluri ale
aceleaşi entităţi. Ca exemplu se consideră cazul în care un salariat primeşte sporuri şi
primeşte sume care constituie reţineri din salariu. Există egalitate între rolurile pe care
entitatea Personal le are în cadrul celor două corespondenţe. Simbolizarea egalităţii de roluri
se face cu simbolul .
Pagina 19 din 46
3.2.3. Nivelul logic al unei baze de date (modelul relaţional).
Modelul relaţional are la bază noţiuni din teoria matematică a mulţimilor. Noţiunea de
bază folosită este cea de relaţie care se defineşte ca fiind o submulţime a produsului cartezian
a mai multor mulţimi. Astfel o relaţie R poate avea următoarea formă:
RM1 x M2 x ... x Mn
Relaţia poate fi definită şi cu ajutorul logicii matematice. Astfel, fie m = (m1, m2, ...,
mn)M1 x M2 x ... Mn şi un predicat P(m1, m2, ..., mn), atunci [M1, M2, ..., Mn]R = {(m1, m2, ...,
mn)/P(m1, m2, ..., mn) = adevărat}. Familia de mulţimi pe care este definită relaţia se numeşte
domeniu, iar dacă M1 = M2 = ...= Mn, relaţia este omogenă. Numărul n se numeşte gradul
relaţiei, iar un element al relaţiei t = (m1, m2, ..., mn) este numit tuplu, iar numărul de tupluri
indică cardinalul relaţiei.
Domeniul este o noţiune mai cuprinzătoare decât atributul, deoarece reprezintă
mulţimea tuturor valorilor posibile care definesc o anumită proprietate a unui obiect, spre
deosebire de atribut care reprezintă mulţimea valorilor existente la un moment dat în coloana
pe care o desemnează în cadrul relaţiei. Într-o relaţie pot exista mai multe atribute care iau
valori în aceleaşi domenii.
Practic, relaţiile se reprezintă simplu, prin tabele, supuse următoarelor restricţii:
în fiecare coloană toate valorile sunt de acelaşi fel;
fiecare valoare este un număr sau un şir de caractere;
ordinea liniilor în tabel nu este predefinită şi nu sunt admise duplicate;
coloanele sunt identificate prin nume distincte care reprezintă atributele relaţiei;
coloanele sunt identificate prin nume distincte care reprezintă atributele relaţiei.
Prelucrarea relaţiilor care se stabilesc în cadrul unei baze de date se face cu ajutorul
algebrei relaţionale sau a calcului relaţional de tuplu sau domeniu.
Pagina 20 din 46
3.2.3.1. Noţiuni de algebră relaţională
Operatorii relaţionali se pot grupa în:
operatori de bază, care pot genera toată clasa operatorilor relaţionale şi care la rândul
lor se împart în:
operatori de asamblare;
operatori unari.
operatori auxiliari.
Operatorii de asamblare sunt operatorii binari, care au două intrări şi o singură ieşire.
Aceşti operatori sunt: reuniunea, diferenţa şi produsul cartezian şi modul lor de operare este
identic cu cel din teoria mulţimilor.
Operatorii unari se aplică asupra unei relaţii şi generează o altă relaţie. Din această
clasă de operatori fac parte proiecţia şi selecţia. Prin intermediul proiecţiei, dintr-un tabel cu
un anumit număr de coloane se obţine un tabel cu un număr mai redus de coloane, prin
suprimarea dublurilor. Identic, cu ajutorul selecţiei se obţine un tabel cu un număr mai mic de
rânduri prin eliminarea înregistrărilor multiple.
Operatorii auxiliari se deduc din operatorii de bază, cei mai importanţi fiind:
compunerea (join), intersecţia, împărţirea sau diviziunea. Aceşti operatori se folosesc în
special la interogarea bazelor de date relaţionale. Modelarea numerică a produsului cartezian
este foarte dificilă şi consumă mult timp de calcul, din care cauză se preferă înlocuirea
acestuia prin operaţii de compunere (join).
Matematic, o compunere după un calificator multi-atribut Q poate fi definită astfel:
Q = Ai1BiAk2Bn... Ap3Bj.......
unde: A(A1, A2, ..., An) şi B(B1, B2, ..., Bn) sunt două relaţii, iar Q este un calificator
multi-atribut. Compunerea poate fi:
Compunere condiţionată când două relaţii R1 şi R2 se compun după calificatorul
multi-atribut Q şi când rezultă o relaţie E ale cărei tupluri sunt cele ale produsului cartezian
R1xR2 ce satisfac calificatorul Q. În funcţie de calificatorul Q se disting mai multe tipuri de
compuneri:
Echicompunere, dacă Q este de forma Ai = Bj;
(tetha) compunere, dacă Q este de forma Ai Bj, unde poate fi sub forma
următorilor operatori logici {, , , , };
Autocompunere, dacă Ai = Aj
Pagina 21 din 46
Compunere naturală sau echicompunere pe R1 şi R2 după toate atributele având
acelaşi nume în R1 şi R2, urmată de o proiecţie care permite conservarea unuia dintre aceste
atribute, egale ca nume.
Intersecţia se poate defini ca şi în teoria matematică a mulţimilor ca E = R 1 R2 sau
cu ajutorul operaţiilor de diferenţă:
E = R1 R2 = R1 – (R1 – R2) = R2 – (R2 – R1)
Diviziunea a două relaţii R1 şi R2 se poate simula cu operatori de diferenţă, produs
cartezian şi proiecţie, după cum urmează:
R1
R2
=X−Y ,
unde: X=R1{A1 , A2 , .. . , AP}
Y=(( X×R2 )−R1 {A1 , A2 , .. . , AP}
Prin prisma modelului relaţional, o bază de date este o colecţie de relaţii sau tabele
normalizate, în care fiecare coloană reprezintă un atribut distinct, iar fiecare rând un tuplu
distinct. Tuplurile unei relaţii se pot identifica în mod unic prin intermediul valorilor unuia
sau mai multor atribute, care joacă rol de cheie primară a relaţiei respective.
În cadrul unei baze de date, între diferite relaţii (tabele) pot apărea anomalii de
actualizare care sunt:
Anomalia de ştergere care constă în faptul că anumite date care urmează să fie şterse,
fac parte din tupluri în care se găsesc şi alte date care mai sunt necesare în continuare, ori
ştergerea făcându-se la nivelul întregului tuplu, acestea se pierd;
Anomalia de adăugare se datorează faptului că anumite date care urmează să fie
adăugate fac parte din tupluri incomplete ceea ce face ca acestea să nu poată fi adăugate;
Anomalia de modificare rezultă din faptul că este dificil de modificat o valoare a unui
atribut atunci când ea apare în mai multe tupluri ale relaţiei (cazul unor înregistrări multiple).
Pentru a se înlătura aceste anomalii, E. F. Codd a stabilit trei forme normale pentru
relaţii şi a introdus procesul de normalizare care se bazează pe noţiunea de dependenţă
funcţională ca relaţie între atributele unei entităţi care are un caracter invariant.
3.2.3.2 Normalizarea unei baze de date
Pagina 22 din 46
Procesul de normalizare a relaţiilor se realizează în mai mulţi paşi, începând cu forma
normală unu, ajungându-se la forma finală cinci. Pentru exemplificare se consideră o bază de
date prost concepută, care în forma normală unu nu ne permite operaţii de actualizare,
modificare sau ştergere fără a pierde informaţii nedorite.
O relaţie este în forma normală unu, dacă şi numai dacă toate atributele ei conţin
numai valori atomice (vezi tabelul).
CP UM PU Q CB LB ZIP TP
P1 buc 20 100 B1 Braşov 400 21
P1 buc 20 200 B2 Aiud 500 30
P1 buc 20 50 B3 Arad 300 59
P1 buc 20 10 B4 Braşov 400 21
P2 kg 10 250 B5 Arad 300 59
P2 kg 10 120 B1 Aiud 500 30
P2 kg 10 60 B3 Arad 300 59
P3 m 5 100 B1 Braşov 400 21
P3 m 5 50 B4 Braşov 400 21
P4 buc 25 6 B5 Arad 300 59
P4 buc 30 10 B2 Aiud 500 30
În acest tabel este reprezentată o relaţie R definită pe opt atribute: cod produs (CP),
unitatea de măsură (UM), preţul unitar (PU), cantitatea (Q), cod beneficiar (CB), localitatea
beneficiarului (LB), codul poştal (ZIP) şi prefixul telefonic al localităţii (TP).
Cheia primară a relaţiei R este compusă din CP şi CB, iar atributele UM, PU, LB, ZIP
şi TP nu sunt complet dependente funcţional de acestea. De asemenea perechile de atribute
(LB, ZIP) şi (LB, TP) sunt mutual dependente. Această relaţie R posedă anomalii de
actualizare, ca:
nu se poate adăuga un tuplu pentru care nu se cunoaşte beneficiarul (CB) şi localitatea
(LB), deoarece datorită respectării integrităţii entităţii, nici o componentă a cheii primare
(CP, CB) nu poate fi nulă;
dacă produsul P4 nu se mai fabrică temporar, trebuie şters tuplul P4 (buc 25 6 B5
Arad Arad 300), dar prin această ştergere se pierd şi informaţii referitoare la beneficiarul B5,
care mai sunt necesare în continuare;
dacă se modifică preţurile produselor, modificarea acestora se face greu deoarece
acelaşi preţ intervine în mai multe tupluri ceea ce face să avem o redundanţă mare a
înregistrărilor în baza de date.
Pagina 23 din 46
Pentru a elimina anomaliile de actualizare, se descompune relaţia R în mai multe
relaţii R1, R2 şi R3 prin folosirea operatorului de proiecţie. În felul acesta se obţine forma
normală doi a relaţiei R din tabelele următoare:
CP UM PU
P1 buc 20
P2 kg 10
P3 m 5
P4 buc 25
P5 buc 30
CP CB Q
P1 B1 100
P1 B2 200
P1 B3 50
P1 B4 10
P2 B5 250
P2 B2 120
P2 B3 60
P3 B1 100
P3 B4 50
P4 B5 6
P5 B2 10
CB LB ZIP TP
B1 Braşov 400 21
B2 Aiud 500 30
B3 Arad 300 59
B4 Braşov 400 21
B5 Arad 300 59
Diagrama dependenţei funcţionale este prezentată în imaginea următoare:
Din această diagramă se observă că relaţiei R3 îi sunt asociate dependenţele tranzitive
CB-LB, LB-ZIP şi CB-LB, LB-TP care generează şi ele anomalii de actualizare:
dacă se şterge tuplul referitor la beneficiarul B1 se pierd şi datele referitoare la
localitatea, codul poştal şi prefixul telefonic, care mai sunt necesare într-o viitoare etapă;
modificarea codului poştal ZIP se face greu, deoarece aceeaşi valoare apare în mai
multe tupluri rezultând redundanţă mare;
nu se poate adăuga o nouă localitate dacă nu există cel puţin un beneficiar din
localitatea respectivă, datorită lipsei cheii primare CB.
Pagina 24 din 46
Pentru a se înlătura anomaliile şi din această formă normală, se descompune relaţia
R3 în două relaţii R31 şi R32 care vor alcătui forma normală trei.
În concluzie, pentru a avea o redundanţă cât mai mică a bazei de date, forma optimă
în acest caz este forma normală trei care cuprinde relaţiile sau tabelele R1, R2, R31 şi R32.
Plecând de la aceste tabele se pot face interogări şi prelucrări ale datelor fără a se pierde din
conţinutul avut iniţial sub forma R. Se constată, că în acest fel, numărul datelor vehiculate
este mai mic, dar informaţia obţinută cu acestea este identică cu cea care s-ar obţine dacă am
avea datele în forma R. În plus, în acest caz se pot face adăugări, modificări şi ştergeri de date
fără a se atenta la integritatea bazei de date.
3.2.4. Nivelul intern (fizic)
Nivelul intern sau modelul fizic este cel care corespunde structurii în care sunt stocate
datele în interiorul maşinii de calcul. În modelul fizic se specifică tabelele sau fişierele care
compun baza de date, componentele fiecărui fişier (lungime, câmpuri, plasare a acestora,
localizare etc.), căile de acces la componentele tabelelor (indecşi, relaţii, legături între tabele).
La nivel intern se vor avea în vedere cerinţele privind protecţia datelor, atât din punct
de vedere al conţinutului câmpurilor din tabele (verificarea şi validarea valorilor câmpurilor
la introducere, evitarea ştergerilor cu sau fără rea voinţă a datelor importante prin conceperea
unei secvenţe de program specializat în acest scop), cât şi în ceea ce priveşte accesul
utilizatorilor la baza de date (stabilirea drepturilor de acces trebuie să se facă ţinând cont de
rolul, funcţia şi sarcina fiecărui utilizator).
Capitolul 4.
PROIECTAREA BAZEI DE DATE
4.1. Stabilirea nivelului extern al bazei de date
Pentru a se obţine o bază de date eficientă şi funcţională se recomandă a se da o
atenţie deosebită următoarelor aspecte:
studiul cu atenţie a structurării bazei de date şi a intercondiţionărilor dintre diferitele
entităţi;
stabilirea exactă a formatului datelor. Pentru datele numerice se foloseşte o
reprezentare adecvată, iar pentru cele de tip text se stabileşte dacă sunt mai lungi de sau nu de
Pagina 25 din 46
255 de caractere. De asemenea datele pot fi sub formă de dată calendaristică, obiecte
(imagini, fişiere multimedia, diferite tipuri de documente create cu diverse aplicaţii etc.);
tabelele trebuie proiectate cu existenţa unor câmpuri cheie şi trebuie să se stabilească
un sistem de relaţii între aceste chei. Pentru a se urmări pas cu pas funcţionarea bazei de date
în timpul proiectării acesteia se recomandă efectuarea de interogări, cu date introduse în
prealabil pentru testare, pentru a se vedea dacă se pot extrage uşor datele din tabelele
proiectate;
schema structurală a bazei de date trebuie să fie cât mai simplă, iar tabelele să fie de
dimensiuni mici care să fie în relaţii între ele. Acest lucru duce la scurtarea timpului de
prelucrare a unei cereri asupra bazei de date deoarece nu trebuie să se facă o căutare în toate
datele, ci numai în tabelele de dimensiuni mai mici în care se găsesc informaţiile necesare ca
răspuns la cererea efectuată;
consultarea colegilor, colaboratorilor şi a celor care vor utiliza efectiv baza de date
creată pentru a prezenta diferite sugestii şi necesităţi ale acestora.
Pentru a se înţelege paşii necesari proiectării unei baze de date se pleacă de la un
exemplu concret: Bază de date pentru informatizarea şi contabilizarea salariilor şi a altor
drepturi de personal la S.C. STIPO S.A. DOROHOI.
DESCRIEREA UNITĂŢII ANALIZATE
I. Înfiinţare, statut, obiective
I.1. Înfiinţare
Societatea comercială "STIPO" S.A. DOROHOI este înfiinţată conform Hotărârii
Guvernului României nr. 1200 din 12.11.1990 prin preluarea integrală a patrimoniului
întreprinderii de Sticlărie şi Porţelan Dorohoi înfiinţată în anul 1973.
Sediul societăţii este în municipiul Dorohoi, strada Livezilor, nr. 45, judeţul Botoşani.
Sediul societăţii poate fi schimbată pe baza hotărârii Adunării Generale a Acţionarilor,
potrivit reglementărilor legale.
Capitalul social este deţinut în procente de 70% de F.P.S. Moldova (Fondul Proprietă
ţii de Stat), persoană juridică înfiinţată prin H.G. nr. 254/1990, iar în procente de 30%
capitalul social este deţinut de F.P.P. nr. 4 Muntenia (Fondul Proprietăţii Particulare),
înmatriculat la Registrul de Comerţ al municipiului Bucureşti sub nr. 40/g/2342/1990 cu
sediul în Bucureşti.
I.2. Statut
Pagina 26 din 46
Societatea comercială "STIPO" S.A. DOROHOI este persoană juridică română, având
forma juridică de societate pe acţiuni. Este înzestrată cu fonduri fixe şi cu mijloace circulante
proprii, necesare desfăşurării activităţii acesteia. Se constituie pe baza principiului
autofinanţării în condiţiile legii.
Societatea are ca obiect de activitate producerea şi comercializarea articolelor de
sticlărie de menaj şi iluminat, porţelan menaj, vitrus, cristal, combinaţii sticlă - porţelan -
feronerie, piese de schimb pentru consum propriu şi terţi, ambalaje şi utilaje specifice
activităţii de bază. De asemenea tot în obiectul de activitate al firmei intră şi întreţinerea şi
repararea utilajelor.
Firma îşi desfăşoară activitatea pe bază de plan propriu, încheie bilanţ, are cont la
bancă, elaborează buget de venituri şi cheltuieli, planul costurilor de producţie, beneficiază de
credite bancare şi are relaţii economice cu alte unităţi.
Este obligată să acopere costurile de producţie şi cheltuielile de circulaţie, să obţină
beneficii, din care să restituie fondurile primite, să desfăşoare activitate rentabilă cu eficienţă
sporită, să asigure participarea salariaţilor la realizarea producţiei, a beneficiilor şi a împărţirii
beneficiilor.
Realizează relaţii bugetare directe efectuând vărsăminte, reprezentând prelevări din
valoare producţiei nete pentru societate, impozitul pe circulaţia mărfurilor, o parte din
beneficii, în condiţiile prevăzute de lege şi alte venituri cuvenite bugetului de stat.
I.3. Obiective
Firma are ca obiective principale îmbunatăţirea calităţii şi diversificarea produselor, o
mai bună adaptare la cerinţele pieţii, găsirea de noi pieţe de desfacere în ţară şi în străinătate.
Pe planul îmbunătăţirii calităţii produselor firma are următoarele obiective:
• diversificarea sortimentală prin crearea şi lansarea pe piaţă a unor noi produse;
• prezentarea de calitate a produselor şi îmbunatăţirea imaginii firmei;
• reducerea cheltuielilor cu materia primă prin reciclarea deşeurilor;
• utilizarea optimă a capacităţilor de producţie existente;
• reducerea cheltuielilor cu manopera prin creşterea productivităţii muncii;
• angajarea de personal tânăr, specializat.
• retehnologizarea secţiei producţie Sticlă Nr. 1.
• modernizarea oficiului de calcul.
O parte din utilajele achiziţionate pentru capacitatea nouă de producţie au fost
montate în cadrul filaturii care funcţionează, în locul unor utilaje de acelaşi tip care aveau
durata de funcţionare expirată.
Pagina 27 din 46
I.4. Structura organizatorică a unităţii (organigrama, descrierea unităţii)
Distribuirea autorităţii şi responsabilităţii în societate se realizează prin propria
structură organizatorică. Forma de organizare e folosită pentru divizarea scopului general,
care este maximizarea pe termen lung a profitului, în subscopuri. Structura organizatorică e
de tip mixt: funcţională şi structurată pe nivele ierarhice.
Structura organizatorică elaborată după principiul funcţional este specifică
întreprinderilor integrate vertical, dominant orientate spre producţie. O astfel de structură
duce la apariţia unor dificultăţi privind coordonarea strategică, trimite toată responsabilitatea
către conducerea strategică, favorizând centralizarea excesivă.
Modul de descompunere a delegării autorităţii este dată de organigrama pe structură a
unităţii, prezentată în continuare prin intermediul organigramei.
Conducerea societăţii este structurată pe următoarele nivele:
- nivelul 1 : Adunarea Generală a Acţionarilor;
- nivelul 2 : Consiliul de Administraţie;
- nivelul 3 : Conducerea Executivă a Societăţii;
- nivelul 4 : Conducător de Funcţiune;
- nivelul 5 : şef Secţie.
În cadrul societăţii funcţionează următoarele comisii pe activităţi:
- Comisia tehnico-aplicativă;
- Comisia de îmbunatăţire a calităţii produselor;
- Comisia tehnică de prevenire şi stingere a incendiilor;
- Comisia de casare;
- Comisia de recepţie a mărfurilor;
- Comisia de autorecepţie a produselor finite;
- Comisia de analiză a reclamaţiilor;
- Comisia tehnică de încadrare şi promovare a personalului;
- Comisia de cenzori.
Pentru buna desfăşurare a activităţii îşi propune realizarea unui sistem informatic care
să rezolve problemele privind evidenţa salariaţilor, a drepturilor şi obligaţiilor acestora.
Pentru fiecare salariat se cunosc: marca, nume, prenume, codul numeric personal, adresa şi
profesia.
Salariaţii lucrează în compartimentele societăţii care sunt identificate prin cod şi
denumire. Conform organigramei în fiecare compartiment există mai multe posturi. Pentru
Pagina 28 din 46
fiecare post se cunosc codul, denumirea, salariul minim şi salariul maxim. Angajaţii îşi
negociază salariul pentru postul ocupat.
Prezenţa angajaţilor la locul de muncă este evidenţiată în foaia colectivă de prezenţă
care se întocmeşte lunar pentru toţi angajaţii firmei şi conţine: marca, numele şi prenumele
salariatului, numărul de ore lucrate, numărul de ore absenţă, numărul de zile de concediu de
odihnă, numărul de zile de concediu medical, luna şi anul.
Salariaţii pot avea persoane în întreţinere. În momentul în care aceştia se angajează se
vor stabili: salariul, data angajării şi data de sfârşit dacă este pe perioadă determinată şi postul
pe care sunt încadraţi şi numărul de persoane aflate în întreţinere.
Plata salariilor se face prin card bancar. Pentru fiecare card se menţionează numele şi
prenumele salariatului, numărul cardului, banca emitentă, numărul contului, data emiterii şi
data până la care este valabil.
Pentru modelarea acestei activităţi se va folosi UML (Unified Modeling Language, iar
implementarea se va realiza cu ajutorul mediilor de programare Visual Basic 7.0 şi Access
2003.
Modelarea structurii sistemului utilizând UML 1. Diagrama cazurilor de utilizare
Diagrama cazurilor de utilizare este folosită, în general, pentru a indica sau caracteriza
funcţionalităţile şi comportamentul întregii aplicaţii. Ea conţine un set de cazuri de utilizare,
actori şi relaţiile dintre aceste componente.
Pentru proiectarea bazei de date se vor parcurge etapele prezentate în capitolul
anterior. Adică întâi se defineşte modelul conceptual (modelul entitate-atribut-
corespondenţă), după care acesta se transformă în model logic şi apoi în modelul fizic
corespunzător sistemului de gestiune a bazelor de date conferit de programul Microsoft
Access.
4.2. Determinarea entităţilor care compun baza de date.
Baza de date trebuie să conţină:
numele, prenumele angajatului;
codul numeric personal;
adresa;
profesia;
postul ocupat;
salariul de încadrare;
Pagina 29 din 46
sporurile care i se cuvin;
numărul de persoane aflate în întreţinere;
compartimentul în care lucrează;
pontajul salariatului pentru fiecare lună:
ore lucrate
ore absenţă
zile concediu medical
zile concediu de odihnă
reţinerile;
modalitatea de plată prin card.
Pornind de la aceste date sunt necesare o serie de operaţiuni la nivelul bazei de date:
înregistrarea datelor despre salariat;
înregistrarea datelor referitoare la angajarea salariatului;
completarea foii colective de prezenţă;
completarea reţinerilor din salarii;
calcularea salariilor şi contribuţiilor de personal;
listarea unor rapoarte: statele de plată, foaia colectivă de prezenţă;
interogarea bazei de date pentru obţinerea de informaţii în diferite momente, pentru
modificarea unor informaţii sau ştergerea lor din baza de date;
prezentarea unui raport cu contribuţiile lunare ale societăţii.
4.3. Stabilirea nivelului conceptual al bazei de date
Dacă privim un centralizator al datelor necesare, baza de date ar avea următoarea
structură:
Marca Identificatorul angajatului
Nume Numele angajatului
Prenume Prenumele angajatului
CNP Codul Numeric Personal
Adresa Adresa angajatului
Profesia Profesia angajatului
Salariu Salariul de încadrare
Data_început Data de început a activităţii
Data_sfârşit Data încheierii activităţii dacă e vorba de o perioadă
determinată sau dacă e vorba de perioadă
Pagina 30 din 46
nedeterminată vom insera o dată fictivă 01.01.9999
Nr_persoane_întreţinere Numărul de persoane în întreţinere
Cod_comp Cod compartiment
Den_comp Denumire compartiment
Cod_post Codul postului
Den_post Denumirea postului
Salar_minim Salarul minim de încadrare a postului respectiv
Salar_maxim Salarul maxim de încadrare a postului respectiv
ID_spor Identificatorul sporului
Tip_spor Tipul sporului
Coeficient Coeficientul de calcul
ID_FCP Identificator foaie colectivă de prezenţă
Luna Luna pentru care se face prezenţa
Anul Anul pentru care se face prezenţa
Nr_ore_efectiv_de_lucrat Numărul mediu de ore pentru luna respectivă pentru
care se plăteşte salariul de încadrare
Nr_zile_lucrătoare Numărul de zile lucrătoare din luna respectivă
Ore_lucrate Orele lucrate de salariat în luna respectivă
Ore_absenţă Orele absenţă ale salariatului în luna respectivă
Zile_concediu_medical Numărul de zile de concediu medical din luna
respectivă
Zile_concediu_odihnă Numărul de zile de concediu de odihnă din luna
respectivă
Nr_card Numărul cardului salariaului
Banca_emitentă Banca emitentă a cardului
Nr_cont Numărul contului în care se vor vira salariile lunar
Data_emitere Data emiterii cardului
Data_expirării Data expirării cardului
Pagina 31 din 46
4.4. Normalizarea bazei de date
Pentru uşurarea muncii operatorului au fost create următoarele tabele care respectă
toate formele normale, descompunerea la atribute atomice, restricţiile de integritate şi
tranzitive, validări pe câmpurile incluse în tabele:
Tabela Salariat: Marca, Nume, Prenume, CNP, Adresa, Profesia
Tabela Angajare: Marca, Cod_post, Salariu, Data_început, Data_sfârşit,
Nr_persoane_întreţinere
Tabela Compartiment: Cod_comp, Den_comp
Tabela Post: Cod_post, Den_post, Salar_minim, Salar_maxim, Cod_comp
Tabela Sporuri: ID_spor, Tip_spor, Coeficient
Tabele Sporuri_salariat: ID_spor, Marca
Tabela Foaie_colectivă_prezenţă: ID_FCP, Luna, Anul, Nr_ore_efectiv_de_lucrat,
Nr_zile_lucrătoare
Tabela Pontaj: ID_FCP, Marca, Ore_lucrate, Ore_absenţă, Zile_concediu_medical,
Zile_concediu_odihnă
Tabela Card: Nr_card, Banca_emitentă, Nr_cont, Data_emitere, Data_expirării, Marca
4.5. Relaţionarea bazei de date
Între tabele bazei de date au fost create următoarele relaţii:
Pagina 32 din 46
Atributele subliniate reprezintă chei primare pentru fiecare entitate, pe baza cărora se
va face regăsirea şi diferenţierea dintre fiecare tuplu sau înregistrare. Se recomandă, ca în
fiecare tabel, cheia primară să aibă o valoare unică pentru fiecare înregistrare. În cazul în care
avem aceeaşi cheie primară pentru mai multe înregistrări ale aceluiaşi tabel pot apărea
probleme la interogarea şi prelucrarea bazei de date.
Pentru a se realiza structura relaţională, între entităţi sau tabele trebuie să fie anumite
legături. Aceste legături se stabilesc cu ajutorul cheilor primare care trebuie să se regăsească
ca şi atribute în tabelele care se leagă între ele. Structura relaţională pentru baza de date
Salarii a fost prezentată în imaginea precedentă.
Capitolul 5
PROIECTAREA INTERFEŢEI GRAFICE DE COMUNICARE A
OPERATORULUI ŞI PROGRAMATORULUI CU SISTEMUL DE GESTIUNE AL BAZEI
DE DATE
Pagina 33 din 46
Utilizarea foilor de date (Data Sheets) pentru introducerea şi vizualizarea datelor este
de multe ori greoaie, mai ales pe măsura creşterii bazei de date sau a tabelelor cu foarte multe
câmpuri. Pentru a se realiza o interfaţă utilizator – bază de date cât mai atractivă şi intuitivă,
Access permite realizarea de formulare (Forms).
Formularele pot îndeplini mai multe funcţii, cele mai importante fiind:
Afişarea şi editarea datelor. Este una din cele mai des utilizate forme de folosire a
formularelor, deoarece datele se pot vizualiza şi introduce în forma dorită de proiectantul
aplicaţiei care ţine cont în general de dorinţa utilizatorului. Datele afişate în cadrul acestor
formulare pot fi modificate sau şterse;
Controlul operaţiilor realizate de aplicaţie. Cu ajutorul formularelor care înglobează
macrocomenzi şi proceduri Visual Basic se poate realiza afişarea automată a anumitor date
sau executarea unui şir de operaţii, ceea ce duce la creşterea productivităţii lucrului cu baza
de date.
Introducerea de date. Este scopul principal al folosirii formularelor;
Afişarea mesajelor. Formularele pot furniza informaţii privind modul în care aplicaţia
poate fi utilizată sau despre operaţiile care se execută sau s-ar putea executa;
Tipărirea rezultatelor. În cazul unor informaţii des utilizate, se poate executa un
formular cu ajutorul căruia să se tipărească direct anumite date sau rapoarte.
Proiectarea şi crearea formularelor şi a subformularelor
Un formular este compus din trei părţi. La proiectarea unui formular se pot folosi
toate ce le trei părţi sau numai unele dintre ele.
Cele trei părţi constitutive ale unui formular sunt:
antetul (Form Header);
zona de detaliu (Detail);
subsolul (Form Footer).
Pentru aplicaţia în discuţie în această lucrare s-au folosit doar formulare:
Form1, care reprezintă formularul principal, mai bine-zis meniul de comandă. De aici
avem acces la Preluare date/Inserare, Modificare/Ştergere date din tabelele bazei de date, la
Rapoarte, şi la butonul de acces la ieşirea din baza de date.
Form2, conţine exact interfaţa de acces la Preluare date/Inserare, Modificare/Ştergere
date din tabelele bazei de date pentru fiecare tabelă.
Alte formulare care prin design-ul lor te ajută să introduci manual sau automat datele
în cîmpurile tabelelor, să ştergi anumite informaţii sau să modifici nişte informaţii din tabele.
Pagina 34 din 46
Fiecare formular este realizat astfel încât să protejeze datele înscrise anterior în baza
de date şi să dirijeze (direcţioneze) cât mai precis încărcarea datelor necesare.
Form1, panoul principal va arăta astfel:
Form2, panoul principal va arăta astfel:
Pagina 35 din 46
Din Form2 se poate intra în oricare din secţiunile care ne interesează. Să presupunem
că vrem să intrăm să actualizăm Tabela Pontaj, facem click pe Pontaj şi se deschide un nou
panou de acces la toate acţiunile de modificare a tabelei:
Aici utilizatorul poate intra pe oricare din cele 3 formulare de actualizare a tabelei
Pontaj:
pe inserare date în tabela Pontaj făcând click pe Adăugare
pe modificare date în tabela Pontaj unde ni se cer nişte date după care să caute în
tabela Pontaj informaţiile cerute de noi, ni se cer Marca şi ID_FCP:
Pagina 36 din 46
pe ştergere date în tabela Pontaj unde ni se cer nişte date după care să caute în tabela
Pontaj informaţiile cerute de noi, ni se cer Marca şi ID_FCP, cu confirmările de rigoare la
ştergerea datelor.
Prezentăm ma jos şi conţinuul Tabelei Pontaj, cu datele care au fost introduse:
5.2. Actualizarea automată a datelor.
Pagina 37 din 46
Una din operaţiunile cele mai importante pe care le poate face aplicaţia este calculul
salariilor personalului angajat. Această operaţiune este realizată cu ajutorul unor Query –
Make Table Query sau de Update Query, de tip selecţie şi acţiune, care permit completarea
unor câmpuri pe baza altor query Actualizarea se realizează, conform unor query, strict în
ordinea următoare:
1. Calcul_venit_ore_efectiv_lucrate_plus_CO
2. Lansare_calcul_CM_salariati
3. Indemnizatii_finale_CM_salariati
4. Venit_brut_angajati
5. Calcul_contributii_angajati
6. Calcul_venit_net
7. Calcul_deduceri
8. Calcul_impozit_salarii
9. Calcul_salar_net
10. Extragere stat de salarii pe baza datelor de mai sus.
Prezentăm mai jos una din aceste interogări a bazei de date pentru
Calcul_contributii_angajati în forma Design şi SQL:
SELECT DISTINCTROW Indemnizatii_finale_CM.Marca,
Indemnizatii_finale_CM.Luna, Venit_brut.Venit_brut,
IIf([Indemnizatia_finala_CM]<>0,Round(6.5*([Venit_brut]-[Indemnizatia_finala_CM])/
100),Round(6.5*[Venit_brut]/100)) AS CASS, 9.5*[Venit_brut]/100 AS CAS,
IIf([Indemnizatia_finala_CM]<>0,Round(1*([Venit_brut]-[Indemnizatia_finala_CM])/
100),Round(1*[Venit_brut]/100)) AS Somaj INTO Contributii_angajati
Pagina 38 din 46
FROM Indemnizatii_finale_CM INNER JOIN Venit_brut ON
Indemnizatii_finale_CM.Marca = Venit_brut.Marca
WHERE (((Indemnizatii_finale_CM.Marca)=[Venit_brut].[Marca]) AND
((Indemnizatii_finale_CM.Luna)=[Venit_brut].[Luna]));
5.3. Interogarea bazei de date pentru obţinerea de informaţii
Toate informaţiile cuprinse în tabelele bazei de date pot fi supuse unor filtrări sau
sortări în funcţie de diferite criterii cu ajutorul interogărilor (queries). În cazul aplicaţiei
noastre s-au făcut interogări:
pentru selecţia datelor din mai multe tabele pentru calculul venitului brut şi net, a
impozitului pe venitul din salarii etc.
pentru selecţia salariaţilor în funcţie de marcă, nume, şi prezentarea rezultatului final
al drepturilor şi obligaţiilor salariale, etc.
Interogările se pot completa la momentul potrivit de către programator în funcţie de
cerinţele desfăşurării calculului salarial.
5.4. Redactarea rapoartelor finale
Esenţa unei baze de date este furnizarea de informaţii pe baza prelucrării datelor.
Vizualizarea acestor informaţii se poate face pe ecran sau pe hârtie prin intermediul foilor de
date, a formularelor şi a rapoartelor sau situaţiilor finale. Raportul final este o grupare a
datelor într-un anumit format şi după o anumită structurare a paginii în funcţie de necesităţile
utilizatorului. În cadrul rapoartelor se pot include şi informaţii suplimentare privind
necesităţile utilizatorului.
În majoritatea cazurilor, un raport foloseşte datele din mai multe tabele, dar comanda
de redactare a raportului se poate aplica numai asupra unui singur tabel sau interogări. Pentru
a se rezolva această situaţie, se face în prealabil o cerere care va reuni datele din tabele şi
interogările care ne interesează. Elementele de legătură dintre sursa de date şi situaţiile finale
sunt controalele, zonele de text, cadrele şi etichetele.
Aplicaţia a fost proiectată să aibă ca finalitate o serie de rapoarte cum ar fi:
o listă cu candidaţii prezenţa angajaţilor şi a orelor lucrate;
statele de salarii.
Pagina 39 din 46
Aceste rapoarte pot fi completate în funcţie de necesităţi cu alte rapoarte pe care
programatorul le poate realiza la cererea societăţii comerciale.
Exemple de rapoarte sunt prezentate în paginile următoare.
Pagina 40 din 46
Pagina 41 din 46
Capitolul 6.
INSTRUCŢIUNI FOLOSITE PENTRU PROGRAMAREA BAZEI DE DATE
6.1. Limbajul de interogare SQL.
Denumirea de SQL este un acronim de la „Structurated Query Language” (limbaj de
interogare structurat). Este unul dintre cele mai puternice limbaje structurate pentru
interogarea bazelor de date relaţionale şi are o răspândire foarte mare devenind chiar un
standard pentru mai multe SGBD-uri.
Limbajul SQL permite o comunicare uşoară şi rapidă a utilizatorului cu baza de date,
precum şi operaţii complexe privind actualizarea şi administrarea bazei de date. Acest limbaj
nu este un limbaj de programare propriu-zis, ci este un limbaj specializat pentru aplicaţii în
ceea ce priveşte bazele de date.
Există trei tipuri de utilizare a limbajului SQL:
Pagina 42 din 46
apelarea directă care constă în introducerea instrucţiunilor SQL direct de la prompter;
modulară prin folosirea anumitor proceduri apelate direct de diferitele module ale
aplicaţiei de baze de date;
încapsulat (Embedded SQL) când instrucţiunile SQL sunt introduse (încapsulate) în
codul de program al bazei de date.
Instrucţiunile SQL permit definirea, manipularea, selectarea datelor, procesarea
tranzacţiilor, controlul cursorului şi a accesului la baza de date. În funcţie de rolul pe care îl
îndeplinesc, instrucţiunile SQL se grupează astfel:
instrucţiuni de definire a tipurilor de date în vederea descrierii structurii bazei de date
şi a modului în care vor fi acceptate datele în baza de date;
instrucţiuni de manipulare a datelor în vederea adăugării, modificării şi ştergerii
diferitelor înregistrări sau părţi din acestea;
instrucţiuni de selecţie a datelor pentru realizarea sortărilor şi filtrărilor în vederea
consultării bazei de date;
instrucţiuni de procesare a tranzacţiilor care reprezintă operaţii multiple şi complexe
de manipulare a datelor;
instrucţiuni de control al cursorului necesar diferitelor aplicaţii sub formă compilată;
instrucţiuni privind controlul şi priorităţile de acces la date.
Limbajul SQL implementat în SGBD Microsoft Access foloseşte doar primele trei
tipuri de instrucţiuni. Pentru a se scrie corect aceste instrucţiuni SQL trebuie respectate strict
următoarele reguli:
orice instrucţiune SELECT se termină cu ”;”
în cazul interogărilor din mai multe tabele, pentru a se separa numele tabelului de
numele câmpului se va utiliza caracterul ”.”
parantezele drepte încadrează numele de câmpuri doar când acestea conţin caractere
neacceptate de SQL
parametrii dintr-o listă se delimitează cu ajutorul caracterului ”,”
valorile de tip şir se încadrează între ghilimele ” ” sau apostrofuri ‘ ‘
inegalităţile se specifică cu simbolurile < >
simbolurile ? şi * sunt folosite pentru a desemna unul sau mai multe caractere de
înlocuire (wildcard)
evidenţierea clară a valorilor de tip Data/Time se foloseşte simbolul #.
6.2. Instrucţiuni SQL pentru definirea datelor
Pagina 43 din 46
Instrucţiunile de definire a datelor permit crearea de baze de date, tabele, câmpuri şi
modificări ale acestora. Principalele instrucţiuni de definire a datelor folosite în SQL sunt:
crearea unei baze de date:
CREATE DATABASE nume_bază_de_date
Această instrucţiune se foloseşte într-o primă etapă la crearea bazei de date. Microsoft
nu acceptă această comandă deoarece crearea şi definirea bazei de date se face automat la
lansarea aplicaţiei.
crearea unui tabel:
CREATE TABLE nume_tabel
Plecând de la structura unei înregistrări şi de la tipurile de date asociate câmpurilor
utilizatorul poate să creeze un tabel. Numele tabelului trebuie să fie obligatoriu unic în cadrul
bazei de date, neputând fi un cuvânt rezervat de instrucţiunile SQL sau VBA sau numele unui
alt tabel.
Adăugarea unui câmp în cadrul unui tabel existent:
ALTER TABLE nume_tabel
Ştergerea completă a unui tabel dintr-o bază de date
DROP TABLE nume_tabel.
6.3. Instrucţiuni SQL pentru selecţia datelor
Prelucrarea datelor dintr-o bază de date se face prin filtrare sau cu ajutorul
instrucţiunilor de selecţie. Indiferent dacă interogările sunt simple sau complexe, cuvântul
cheie care defineşte această activitate este SELECT.
Cererile de interogare sunt:
simple
complexe:
de asociere de tip JOIN
de combinare de tip UNION
de tip PARAMETERS
6.4. Instrucţiuni SQL pentru manipularea datelor
Pagina 44 din 46
Instrucţiunile de manipulare a datelor trebuie folosite cu mare prudenţă deoarece pot
provoca modificări ireversibile asupra datelor din baza de date. Cele mai importante
instrucţiuni de acest tip sunt:
INTO care se materializează printr-o interogare care are drept acţiune crearea unei
tabele noi, plecând de la structura şi conţinutul unei tabele existente.
INSERT se foloseşte pentru adăugarea de înregistrări dintr-o tabelă în alta.
DELETE se materializează printr-o acţiune de ştergere parţială sau totală a
înregistrărilor din tabele.
UPDATE are scopul de a insera înregistrări noi, cât şi de a modifica valorile
câmpurilor din înregistrările existente.
6.5. Exemple de instrucţiuni SQL folosite în aplicaţie.
Modul în care funcţionează query-urile ale căror sintaxe sunt prezentate mai jos au
fost prezentate în capitolul 5.
Query-ul Calcul_venit_ore_efectiv_lucrate_plus_CO:
SELECT Angajare.Marca, Foaie_colectiva_prezenta.Luna,
Foaie_colectiva_prezenta.Anul, Round([Ore_lucrate]*[Salariu]/[Nr_ore_efectiv_de_lucrat]+
[Ore_lucrate]*[Salariu]/[Nr_ore_efectiv_de_lucrat]*[Coeficient]/100) AS Venit_ore_lucrate,
Round([Salariu]*[Zile_concediu_odihna]/[Nr_zile_lucratoare]) AS Venit_CO INTO
Calcul_venit_ore_lucrate_si_sau_CO
FROM Sporuri INNER JOIN ((Angajare INNER JOIN (Foaie_colectiva_prezenta
INNER JOIN Pontaj ON Foaie_colectiva_prezenta.ID_FCP = Pontaj.ID_FCP) ON
Angajare.Marca = Pontaj.Marca) INNER JOIN Sporuri_salariat ON Angajare.Marca =
Sporuri_salariat.Marca) ON Sporuri.ID_spor = Sporuri_salariat.ID_spor;
Query-ul Lansare_calcul_CM_salariati:
SELECT Angajare.Marca, Avg(Angajare.Salariu) AS Media_venituri,
75/100*[Media_venituri] AS Calcul_indemnizatie_CM INTO Lansare_calcul_CM
FROM Angajare INNER JOIN (Foaie_colectiva_prezenta INNER JOIN Pontaj ON
Foaie_colectiva_prezenta.ID_FCP = Pontaj.ID_FCP) ON Angajare.Marca = Pontaj.Marca
WHERE (((Foaie_colectiva_prezenta.Luna)=(Month(Date())-1) Or
(Foaie_colectiva_prezenta.Luna)=(Month(Date())-2)) Or
(Foaie_colectiva_prezenta.Luna)=(Month(Date())-3)) Or
(Foaie_colectiva_prezenta.Luna)=(Month(Date())-4)) Or
Pagina 45 din 46
(Foaie_colectiva_prezenta.Luna)=(Month(Date())-5)) Or
(Foaie_colectiva_prezenta.Luna)=(Month(Date())-6)))
GROUP BY Angajare.Marca;
Query-ul Indemnizatii_finale_CM_salariati:
SELECT Angajare.Marca, Foaie_colectiva_prezenta.Luna,
Pontaj.Zile_concediu_medical,
IIf([Zile_concediu_medical]<>0,Round([Calcul_indemnizatie_CM]*[Zile_concediu_medical
]/[Nr_zile_lucratoare]),0) AS Indemnizatia_finala_CM,
IIf([Zile_concediu_medical]<>0,9.5*[Indemnizatia_finala_CM]/100,0) AS CAS_CM INTO
Indemnizatii_finale_CM
FROM (Angajare INNER JOIN (Foaie_colectiva_prezenta INNER JOIN Pontaj ON
Foaie_colectiva_prezenta.ID_FCP = Pontaj.ID_FCP) ON Angajare.Marca = Pontaj.Marca)
INNER JOIN Lansare_calcul_CM ON Angajare.Marca = Lansare_calcul_CM.Marca;
Query-ul Venit_brut_angajati:
SELECT Calcul_venit_ore_lucrate_si_sau_CO.Marca,
Calcul_venit_ore_lucrate_si_sau_CO.Luna, [Venit_ore_lucrate]+[Venit_CO]+
[Indemnizatia_finala_CM] AS Venit_brut INTO Venit_brut
FROM Calcul_venit_ore_lucrate_si_sau_CO INNER JOIN Indemnizatii_finale_CM
ON Calcul_venit_ore_lucrate_si_sau_CO.Marca = Indemnizatii_finale_CM.Marca
WHERE (((Calcul_venit_ore_lucrate_si_sau_CO.Marca)=[Indemnizatii_finale_CM].
[Marca]) AND ((Calcul_venit_ore_lucrate_si_sau_CO.Luna)=[Indemnizatii_finale_CM].
[Luna]));
Query-ul Calcul_venit_net:
SELECT Contributii_angajati.Marca, Contributii_angajati.Luna,
Contributii_angajati.Venit_brut, [Venit_brut]-[CASS]-[CAS]-[Somaj] AS Venit_net INTO
Venit_net
FROM Contributii_angajati;
Query-ul Calcul_deduceri:
SELECT Angajare.Marca, Venit_net.Luna, Angajare.Nr_persoane_intretinere,
IIf([Venit_brut]<=1000,250+[Nr_persoane_intretinere]*100,IIf([Venit_brut]<=3000,(250+
[Nr_persoane_intretinere]*100)*(1-([Venit_brut]-1000)/2000),0)) AS Deducere INTO
Deduceri_personal
FROM Angajare INNER JOIN Venit_net ON Angajare.Marca = Venit_net.Marca;
Pagina 46 din 46
Query-ul Calcul_impozit_salarii:
SELECT Venit_net.Marca, Venit_net.Luna, Round(([Venit_net]-
[Deducere])*16/100) AS Impozit_salar INTO Impozit_salarii
FROM Venit_net INNER JOIN Deduceri_personal ON Venit_net.Marca =
Deduceri_personal.Marca
WHERE (((Deduceri_personal.Marca)=[Venit_net].[Marca]) AND
((Deduceri_personal.Luna)=[Venit_net].[Luna]));
Query-ul Calcul_salar_net:
SELECT Impozit_salarii.Marca, Impozit_salarii.Luna, [Venit_net]-[Impozit_salar]
AS Salariu_net INTO Salarii_nete_angajati
FROM Impozit_salarii INNER JOIN Venit_net ON Impozit_salarii.Marca =
Venit_net.Marca
WHERE (((Impozit_salarii.Marca)=[Venit_net].[Marca]) AND
((Impozit_salarii.Luna)=[Venit_net].[Luna]));
Capitolul 7.
CONCLUZII
Această încercare modestă de a prezenta un domeniu atât de vast nu poate face decât
să stârnească interesul asupra acestei ramuri a unei ştiinţe noi şi în continuă înnoire. În
informatică aplicaţiile au o „viaţă” scurtă deoarece apar mereu versiuni îmbunătăţite,
upgrade-uri, aplicaţii mult mai performante ce încearcă să vină în sprijinul utilizatorului.
Totuşi, chiar dacă se schimbă modul de punere în aplicare al unor idei, principiile de
bază persistă indiferent de complexitatea problemei, de aceea tot ce se învaţă într-un limbaj
de programare poate fi extrem de util în alte limbaje, nu prin memorarea unei sintaxe sau a
unui fragment de cod ci prin modul de abordare a problemei şi soluţiile ce se pot utiliza la
rezolvarea problemei. Aceste soluţii depind foarte puţin de mediul de programare şi ţin de
ingeniozitatea celui ce caută soluţia.
Aplicaţie prezentată în această lucrare este departe de a fi perfectă, dar este
perfectibilă şi conţine, cred, o serie de soluţii ingenioase descoperite nu doar prin studiul
aprofundat al suportului teoretic dar şi prin metode mai puţin ortodoxe de rezolvare găsite pe
măsură ce s-a lucrat.
Pagina 47 din 46
Crearea unei astfel de aplicaţii ar putea fi un foarte bun motiv de a începe un studiu
foarte serios al sistemelor de gestiune a bazelor de date în special pentru cei ce încearcă să
facă din aceasta o viitoare meserie.
Pagina 48 din 46
