. Sisteme DE Gestiune A Bazelor DE Date

Capitolul 1

BAZĂ DE DATE PENTRU SISTEMELE DE GESTIUNE

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;

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

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.

Î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 datelercorelate î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, 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;

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.

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.

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

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:

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.

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

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

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 .

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.

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

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

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

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

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:

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.

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

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

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

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

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:

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

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.

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:

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:

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.

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

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.

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.

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:

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

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

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

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.

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.

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.
C.N. Prague – Access 2003 Programare, Editura Teora, București, 2005.
Ion Lungu – Baze de date Oracle Limbajul SQL, Editura ASE, București, 2005.
K. Sandor – Access 2000, Editura Albastră, Cluj, 2003.
Carmen Răduț, Traian Surcel, ș.a. – Baze de date și sisteme de gestiune a bazelor de date visual foxpro, Editura Economică, București, 2003.
Ion Lungu, Traian Surcel, ș.a. – Informatică Economică, Editura Economică, București, 2006.
Traian Surcel, Radu Mârșanu, D. Avram – Medii de programare, Editura Tribuna Economică, București, 2004.

*** – Documentația Microsoft Access 2000.