bazĂ de date pentru informatizarea Şi contabilizarea salariilor Şi a altor drepturi de personal

Bază de date pentru informatizarea şi contabilizarea salariilor şi a altor drepturi de personal

Capitolul 1BAZĂ DE DATE PENTRU INFORMATIZAREA ŞI CONTABILIZAREA SALARIILOR ŞI A ALTOR DREPTURI DE PERSONAL. - 4 -

1.1. Prezentarea temei - 4 -1.2. Scopul şi obiectivele temei - 4 -1.3. Argumentarea necesităţii temei. - 5 -1.4. Analiza comparativă a abordărilor existente la ora actuală în ceea ce priveşte tematica de licenţă. - 6 -

Capitolul 2NOŢIUNI INTRODUCTIVE - 6 -

2.1. Noţiunea de dată. Data scalară, data, informaţia şi cunoştinţele. - 7 -2.2. Structuri de date - 8 -2.3. Noţiuni privind conceptul de bază de date - 9 -2.4. Obiectivele fundamentale ale unei baze de date - 10 -2.5. Sistemul de gestiune a bazelor de date. - 11 -

Capitolul 3.MODELE DE REPREZENTARE A DATELOR ÎN BAZELE DE DATE - 12 -

3.1. Tipuri de structuri fundamentale în baza de date - 13 -3.2. Nivele de reprezentare a datelor în baza de date. - 15 -

3.2.1. Nivelul extern de prezentare a datelor - 16 -3.2.2. Nivelul conceptual al unei baze de date - 17 -3.2.3. Nivelul logic al unei baze de date (modelul relaţional). - 23 -3.2.4. Nivelul intern (fizic) - 29 -

Capitolul 4.PROIECTAREA BAZEI DE DATE - 30 -

4.1. Stabilirea nivelului extern al bazei de date - 30 -4.2. Determinarea entităţilor care compun baza de date. - 31 -4.3. Stabilirea nivelului conceptual al bazei de date - 32 -4.4. Normalizarea bazei de date - 33 -4.5. Relaţionarea bazei de date - 34 -

Capitolul 5PROIECTAREA INTERFEŢEI GRAFICE DE COMUNICARE A OPERATORULUI ŞI PROGRAMATORULUI CU SISTEMUL DE GESTIUNE AL BAZEI DE DATE - 35 -

5.1. Proiectarea şi crearea formularelor şi a subformularelor - 36 -5.2. Actualizarea automată a datelor. - 41 -5.3. Interogarea bazei de date pentru obţinerea de informaţii - 44 -5.4. Redactarea rapoartelor finale - 44 -

Capitolul 6.INSTRUCŢIUNI FOLOSITE PENTRU PROGRAMAREA BAZEI DE DATE - 45 -

6.1. Limbajul de interogare SQL. - 45 -6.2. Instrucţiuni SQL pentru definirea datelor - 47 -6.3. Instrucţiuni SQL pentru selecţia datelor - 47 -6.4. Instrucţiuni SQL pentru manipularea datelor - 48 -6.5. Exemple de instrucţiuni SQL folosite în aplicaţie. - 48 -

Capitolul 7.CONCLUZII - 50 -BIBILOGRAFIE: - 51 -

3


„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:

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;

4


î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

5


alternativă 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.

6


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 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ă.

7


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:

1. organizarea datelor în memoria internă a calculatorului sub formă de listă,

coadă, stivă.

2. organizarea datelor pe memoria externă sub formă de fişiere şi baze de date.

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.

8


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.

Î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

9


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;

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,

10


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.

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;

11


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.

Î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.

12


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.

13


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.

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

14


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 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

15


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 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.

16


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,

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:

17


Plecând de la această reprezentare grafică se pot identifica următoarele:

Entităţi: (Tip automobil şi Factura livrare);

Atribute:

o (cod, denumire, model, culoare, dotare) pentru entitatea

Tip automobil;

o (nr. factură, data facturării, cota TVA) pentru entitatea

Factura livrare;

o (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:

18


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.

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:

19


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).

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;

20


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

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 #:

21


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 .

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ă

22


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:

o în fiecare coloană toate valorile sunt de acelaşi fel;

o fiecare valoare este un număr sau un şir de caractere;

o ordinea liniilor în tabel nu este predefinită şi nu sunt admise

duplicate;

o coloanele sunt identificate prin nume distincte care reprezintă

atributele relaţiei;

o 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.

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:

o operatori de asamblare;

o 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.

23


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:

o Echicompunere, dacă Q este de forma Ai = Bj;

o (tetha) compunere, dacă Q este de forma Ai Bj, unde poate fi

sub forma următorilor operatori logici {, , , , };

o Autocompunere, dacă Ai = Aj

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 = R1 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ă:

24


unde:

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

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ă

25


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;

26


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.

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:

27


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.

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

28


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 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.

29


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

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.

30


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ă.

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ă

31


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 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.

32


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;

sporurile care i se cuvin;

numărul de persoane aflate în întreţinere;

compartimentul în care lucrează;

33


pontajul salariatului pentru fiecare lună:

o ore lucrate

o ore absenţă

o zile concediu medical

o 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

34


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ă 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

35


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

36


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

37


4.5. Relaţionarea bazei de dateÎntre tabele bazei de date au fost create următoarele relaţii:

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

38


PROIECTAREA INTERFEŢEI GRAFICE DE COMUNICARE A OPERATORULUI ŞI PROGRAMATORULUI CU SISTEMUL DE GESTIUNE AL BAZEI DE DATE

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);

39


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.

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:

40


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

41


- 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:

- 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:

42


5.2. Actualizarea automată a datelor.

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

43


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

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.

44


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.

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.

45


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.

47


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:

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:

1. 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;

2. instrucţiuni de manipulare a datelor în vederea adăugării, modificării şi ştergerii

diferitelor înregistrări sau părţi din acestea;

3. instrucţiuni de selecţie a datelor pentru realizarea sortărilor şi filtrărilor în

vederea consultării bazei de date;

4. instrucţiuni de procesare a tranzacţiilor care reprezintă operaţii multiple şi

complexe de manipulare a datelor;

5. instrucţiuni de control al cursorului necesar diferitelor aplicaţii sub formă

compilată;

6. 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 ”;”

48


î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

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:

o 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:

o 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:

o ALTER TABLE nume_tabel

Ştergerea completă a unui tabel dintr-o bază de date

49


o 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:

o de asociere de tip JOIN

o de combinare de tip UNION

de tip PARAMETERS

6.4. Instrucţiuni SQL pentru manipularea datelor

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.

50


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())-6)))

GROUP BY Angajare.Marca;

Query-ul Indemnizatii_finale_CM_salariati:

51


SELECT Angajare.Marca, Foaie_colectiva_prezenta.Luna,

Pontaj.Zile_concediu_medical,

IIf([Zile_concediu_medical]<>0,Round([Calcul_indemnizatie_CM]*[Zile_co

ncediu_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+

52


[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;

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]));

53


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.

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.

54


BIBILOGRAFIE:

Carol Schnakovszky – Baze de date, 2000, suport de curs - Universitatea Bacău.

Pavel Năstase, Florin Mihai, ş.a. – Baze de date Microsoft Access 2000, Editura

Teora, Bucureşti, 1999.

Roger Jennings – Utilizare Access 2003, Editura Teora, Bucureşti, 2004.

E. Koller, M. Roşculeţ – Programarea în Access 97, Editura Teora, Bucureşti, 1997.

*** - Documentaţia Microsoft Access 2000.

55

bazĂ de date pentru informatizarea Şi contabilizarea salariilor Şi a altor drepturi de personal

Documents