Proiectarea Si Elaborarea Si C.n.e.a.a.i.i. 2

Cuprins

Introducere………………..………………..………………………..…………..8

1. Baze de date orientate pe obiect…………………………………….…..11

1.1. Noțiune de bază de date orientată pe obiect…………………………..11

1.2. Proiectarea bazelor de date orientate pe obiecte……….……………..12

1.2.1. Modelul de date orientat pe obiecte………………………………14

1.2.2. Operațiile modelului de date orientat pe obiecte. ………………..14

1.2.3. Reguli de integritate ale modelului de date orientat pe obiecte….15

1.3. Limitele bazelor de date orientate obiect………………………….…..16

1.4. Caracteristici fundamentale ale bazelor de date………………………17

2. Delphi – limbaj orientat pe obiecte…………………………..…………23

2.1. Limbaje orientate pe obiecte……………………………………..…….23

2.2. Reprezentant al limbajelor orientate pe obiecte – Delphi…………..24

2.2.1. Performanță – optimizarea compilatorului pe 32 biți…………27

2.2.2. Mediul Delphi și sistemul Windows……………………….…..29

2.2.3. Mediul Delphi și tehnologia OLE…………………….………..31

2.3. Avantajele mediului Delphi în raport cu bazele de date……………..31

2.4. Performanțele programelor Delphi de baze de date…………..……..33

3. Procedura de evaluare academică și acreditare…………..….……..36

3.1. Organul evaluării și acreditării……………………………………….36

3.2. Criteriile evaluării și acreditării………………………………..…….37

3.3. Modul de acreditare și periodicitatea evaluării………..…….…..…..38

4. Descrierea sistemului informațional – C.N.E.A.A.I.I. 2……………39

4.1. Descrierea generală a sistemului informațional “C.N.E.A.A.I.I.”…39

4.2. Descrierea programului “Registrul instituțiilor” al

sistemului informațional “C.N.E.A.A.I.I.” ……………..………..44

4.3. Componentele Delphi utilizate la elaborarea bazei de date……….53

4.3.1. Descrierea componentelor Delphi pentru accesul la date……54

4.3.2. Descrierea componentelor Delphi pentru controlul datelor….60

4.3.3. Descrierea componentelor Delphi din pagina QuickRpt…..…68

5. Protecția muncii și mediului ambiant…………………………………75

5.1. Analiza condițiilor de muncă………………………………………75

5.2. Factorii nocivi ce acționează asupra operatorului………………..79

5.3. Aprecierea pericolului lucrărilor lucrului la monitor lor de muncă în sala de calculatoare………………………………………………86

5.4. Securitatea electrică.protecția prin “legare la nul”………………89

5.5. Locul de muncă la efectuarea lucrului șezând………………….…92

5.5.1. Principii generale…………………………………………….92

5.5.2. Caracteristicile de dimensiune a locului de muncii………….93

6. Partea economică a proiectului……………………………………..…..96

6.1. Determinarea volumului de lucru necesar pentru îndeplinirea

proiectului…………………………………………………. ……………….96

6.2. Evaluarea economică a sistemului informațional "C.N.E.A.A.I.I."……..98

6.3. Evaluarea prețului de cost al SI “C.N.E.A.A.I.I.”……………………….101

6.4. Evaluarea eficacității de la implementarea SI “C.N.E.A.A.I.I.”………..103

Concluzie……………………………………..…..……………………..……105

Bibliografie……………………………………..…..………………………..107

=== DPLM2002 ===

Introducere

Esența oricărei baze de date este păstrarea informației. Informația păstrată în baza de date este foarte diversă – de la simple câmpuri textuale până la câmpurile ce păstrează imagini grafice. De asemenea, este important de menționat, că bazele de date moderne pot păstra volume enorme de informație.

Accesarea informației are loc prin intermediul sistemului de gestiune al bazei de date, care ne permite să modificăm, sau pur și simplu să vizionăm informația păstrată. Însă, timpul și posibilitățile omului de analiză a informației sânt limitate. În afară de aceasta, în majoritatea cazurilor, avem nevoie numai de unele câmpuri din baza de date, fără accesarea celorlalte.

Acest lucru, ne conduce la concluzia, că sânt necesare mijloace specializate de prezentare a informației din baza de date, care vor asigura accesul numai la informația strict necesară, ceea ce va duce la micșorarea cheltuielilor de timp în lucrul cu baza de date, ceea ce, la rândul său, este un factor foarte important în viața contemporană.

Astfel de mijloace specializate de prezentare a informației din baza de date sânt generatoarele de rapoarte. Însăși ideea de realizare a generatoarelor de rapoarte a apărut demult și este prezentă și în sistemele mai vechi sub diferite forme, însă posibilitățile lor erau reduse. Cel mai des generatoarele de rapoarte sânt încorporate în sistemul de gestiune al bazei de date. O altă modalitate sânt generatoarele de rapoarte specializate, care de obicei sânt create strict pentru baza de date respectivă.

Odată cu apariția mecanismelor de tipul ODBC (Open Database Conectivity) sau BDE (Borland Database Engine) a apărut posibilitatea de creare a generatoarelor de rapoarte universale, care pot crea rapoarte asupra diverselor baze cu condiția că acestea sânt menținute de sistemele sus numite. Ca exemplu de astfel de program poate servi MS Query, care lucrează cu orice bază de date, driver-ul căreia este prezent în ODBC.

În ltimii zece ani, tehnologia sistemelor informatice a avansat rapid și a obținut succese remarcabile. Calculatorul pătrunde în tot mai multe domenii de activitate iar pretențiile utilizatorilor cresc într-un ritm compatibil cu cel al progresului tehnologic. Structurile clasice de date bazate pe text și valori numerice fie se dovedesc insuficiente, fie complexitatea lor depășește posibilitățile de prelucrare oferite de tehnologiile clasice.

Aplicațiile asociate cu disciplinele tehnologice cum ar fi: proiectarea asistată la calculator, sisteme informatice geografice și sisteme bazate pe cunoștințe, presupun stocarea unor cantități mari de informații cu o structură complexă. Aceste aplicații necesită suport pentru tipurile de date care nu pot fi reprezentate în sistemele clasice. De exemplu, în bază de date care să susțină un puternic sistem de proiectare în domeniul ingineriei necesită stocarea unor cantități mari de date sub forma de diagrame și descrieri ale proiectului tehnic. De asemenea, aplicațiile de proiectare asistată de calculator pot solicita monitorizarea unor desene formate din grupuri de elemente complexe ce trebuie să fie combinate, separate, suprapuse și modificate astfel încât să permită rularea unor programe variate de proiectare.

Dacă eforturile de extindere a tehnologiilor actuale în domeniul achiziției, stocării și prelucrării noilor tipuri de informații ca elemente singulare sunt mai adesea finalizate cu succes, nu același lucru se poate spune despre administrarea corespunzătoare a unor colecții complexe de astfel de date.

Bazele de date "clasice" bazate pe modelul relațional (fie de tip SQL, fie de tip Xbase) oferă prea puțin suport pentru tipurile neconvenționale de date.

În ultima decadă s-a constatat prioritatea conceptelor de obiect și introducerea lor în tehnologia sistemelor informatice. Recent, conceptele de obiect au fost înglobate și în tehnologia SGBD-urilor, rezultând producția de sisteme de gestiune a bazelor de date orientate pe obiecte (SGBD-OO).

Baze de date orientate pe obiecte permit crearea de obiecte complexe, din componente mai simple, fiecare având propriile atribute și propriul comportament.

Obiectivele principale ale SG-OO sunt:

Puterea de modelare superioară a datelor. Aceasta se realizează prin:

Posibilități de deducție superioare (ierarhie de clase, moștenire);

Ameliorarea interfeței cu utilizatorul;

Luarea în considerare a aspectelor dinamice, integrarea descrierii structurale și comportamentale.

SGBD din a treia generație (sisteme de gestiune de baze de cunoștințe, sisteme de gestiune orientate pe obiecte) au fost concepute pentru gestionarea unor astfel de obiecte. Ele sunt deci complimentare sistemelor de gestiune a fișierelor și SGBD-lor din prima și a doua generație.

SGBD-OO combină noile concepte asociate limbajelor de programare orientate pe obiect cu capacitățile SGBD-urilor convenționale. SGBD-OO sunt acum în faza inițială de comercializare și au câteva caracteristici particulare față de cele convenționale. Modelul de dată-obiect permite reprezentarea unor structuri de date complexe și a unor ierarhii model asigurând posibilitatea de a defini tipuri de date care combină atît structura de date, cît și definirea procedurii. Aceasta duce la o flexibilitate crescută în reprezentarea structurii și comportamentului sistemelor reale.

SGBD-OO combină posibilitatea de definire și manipularea structurilor complexe de alte, funcționalitatea unui limbaj de programare și tehnologia de gestiune a bazelor de date.

1. Baze de date orientate pe obiect

Noțiune de bază de date orientată pe obiect

Baza de date orientată pe obiecte poate fi definită ca rezultatul aplicării tehnologiei orientate pe obiecte în domeniul stocării și regăsirii informațiilor.

O bază de date orientate pe obiecte integrează în general un limbaj de programare orientat pe obiecte și funcțiile SGBD-urilor tradiționale:

1.Persistenta: obiectele în memorie (structuri de date) sunt salvate pe disc pentru a putea fi partajate de mai mulți utilizatori și utilizate în timpul prelucrărilor ulterioare. Dacă nu s-ar proceda astfel, obiectele ar dispărea la sfârșitul execuției programului.

2.Independenta datelor: programele de aplicație posedă o interfață abstractă către date, ceea ce înseamnă că structura lor în interiorul bazei de date este ascunsă. Această caracteristică permite utilizatorului să modifice sau să reorganizeze baza de date fără a schimba codul aplicației, ceea ce creste enorm productivitatea.

3.Interogarea: O interogare este un mecanism de filtrare sau de triere: o serie de înregistrări sunt comparate cu cererea sau predicatul, iar cele care sunt compatibile sunt returnate în rezultat. Este un excelent mecanism pentru a găsi obiecte pe baza caracteristicilor comune.

4.Mecanismele tranzacționale: aceste mecanisme garantează că modificările sunt efectuate într-o manieră coerentă. Tranzacțiile permit formarea de grupuri de modificări care sunt înregistrate în bloc, fie în întregime, fie nu sunt înregistrate deloc. Aceasta garantează consistenta bazei de date cu ea însăși.

5.Controlul concurentei: aplicațiile trebuie să partajeze date, dar tranzacțiile tind să le izoleze unele de altele. Mecanismele de control al concurentei lucrează în concordanță cu modelul tranzacțional pentru sincronizarea accesului simultan la informația prezentă în baza de date.

Baza de date orientată pe obiecte oferă posibilitatea de a reprezenta structuri de date foarte complexe cu ajutorul obiectelor și claselor de obiecte.

Definirea clasei este macanizmul de specificare a schemei bazei de date. Schema bazei de date constă din toate clasele care au fost definite pentru o aplicație particulară. Definițiile de clasă include relațiile de înrudire (superclasa, subclasa) și relațiile structurale dintre clase (analog cu relațiile din modelul entitate-relație-atribut).

O schemă completă de baze de date poate consta din una sau mai multe ierarhii de clasă împreună cu relațiile structurale. Descrierile individuale ale schemei se referă la variabile de instanță ale claselor individuale. Schema bazei de date poate fi modificată dinamic, în funcție de necesitățile utilizatorului. Modificarea schemei presupune definirea unei taxonomii și a unui model al schimbării. Taxonomia definește un set de schimbări semnificative ale schemei, iar modelul furnizează o bază pentru specificarea semanticelor schimbărilor schemei și implimentarea schimbărilor schemei.

Pot fi identificate două tipuri de schimbare a schemei unei baze de date orientate pe obiecte.

Schimbări referitoare la modul de definire al unei clase care includ schimbările atributelor și metodelor definite pentru o clasă, cum ar fi schimbarea numelui sau domeniului unui atribut, adăugarea, ștergerea unui atribut sau metode. Și schimbări referitoare la structura ierarhiei de clase care include adăugarea sau ștergerea unei clase și schimbarea relațiilor superclasa/subclasa dintre o pereche de clase.

1.2. Proiectarea bazelor de date orientate pe obiecte

Cu toate că paradigma orientării pe obiecte pare extrem de naturală iar tehnicile specifice sunt simple, pentru proiectantul obișnuit cu metodele tradiționale de modelare, trecerea la noua metodologie este destul de dificilă. Aceasta se datorează faptului că proiectarea orientată pe obiecte este o metodologie cu totul nouă care contrazice în anumite privințe deprinderile proiectantului.

Modul clasic de proiectare se bazează pe tehnica top-down. Se identifică mai întâi componentele majore, se stabilesc corelațiile dintre ele, iar apoi se trece la rafinări succesive, "în cascadă", a componentelor.

Proiectarea orientată pe obiecte se bazează mai mult pe tehnica bottom-up. Se identifică mai întâi componentele funcționale pe baza cărora se va constitui apoi întregul edificiu. Se identifică în colecțiile existente obiectele care pot fi reutilizate pentru noul proiect. Acestea vor fi preluate ca atare sau, dacă este cazul, vor fi ajustate. Cele care nu există vor fi create, uneori din temelii, dar de cele mai multe ori ca subclase ale unor clase existente. Odată creată ierarhia de clase potrivită, se testează componentele specifice, se pune la punct documentația și se poate începe acțiunea de implimentarea sau comercializare.

Această metodologie modifică în mod substanțial planificarea lucrărilor și etapelor. Partea cea mai minuțioasă a proiectării se mută la începutul proiectului. Dacă există deja biblioteci de obiecte utilizate în alte aplicații, realizarea unui prototip se poate face în câteva zile. Pe baza lui se stabilesc aspectele funcționale și de interfață ale aplicației după care se trece la etapa de identificare a obiectelor, a claselor, a ierarhiei, a modului de comunicare între obiecte. Etapa finală a proiectului constă în asamblarea acestor elemente.

Refacerea unor aplicații "clasice" în noua tehnologie implică, de cele mai multe ori, refacerea aproape integrală a aplicațiilor.

Pe de altă parte, metodologia orientată pe obiecte poate fi aplicată cu succes în proiectare chiar dacă nu se urmărește utilizarea unor tehnici de realizare orientate pe obiecte. Avantajul constă în faptul că aceasta obligă la o analiza mai atentă a arhitecturii sistemului și mai departe, la design modular, exprimat prin componentele aflate în interacțiune. Adăugarea sau înlocuirea ulterioară a unor astfel de componente va fi cu siguranță mult mai ușoară.

1.2.1. Modelul de date orientat pe obiecte.

Un model de date orientat pe obiecte are la bază noțiunea de entitate conceptuală și definește un obiect ca o corecție de proprietăți care descriu entitatea.

Principalele concepte care stau la baza unui model orientat pe obiecte sunt: obiectul, încapsularea, persistența, clasa, tipul, moștenirea, poliformismul, identitatea, domeniul.

Nu există un “model orientat pe obiecte” propriu-zis, care să descrie în mod coerent structura și funcționarea unei baze de date orientate pe obiecte. Lipsa acestuia s-ar putea datora mai multor motive. Unul ar putea fi imaturitatea tehnologiei. Altul, mai plauzibil, îl constituie naturalețea dezarmantă a tehnologiei orientate pe obiecte.

Modelele obiectuale își au originea în rețelele semantice și în limbajele de programare orientate pe obiecte. Obiectivul principal este de a calcula mai bine realitatea și de a beneficia de reutilizarea obiectelor pentru a construi obiecte din ce în ce mai complexe.

În abordările tradiționale, modelele de reprezentare sunt foarte diferite de-a lungul etapelor ciclului de dezvoltare a sistemului informatic. La nivelul modelului logic, separarea datelor și a prelucrărilor se traduce printr-un model logic pentru date și dezvoltarea algoritmilor pentru prelucrări. În fine, la nivel fizic, instrumente foarte diferite sunt utilizate ca SGBD-uri pentru gestiunea datelor iar compilatoare sau interpretare pentru dezvoltarea programelor. În schimb, abordarea obiectuală ne permite o aceeași reprezentare la toate nivelele de dezvoltare. Un model obiectual este construit plecând de la un anumit număr de concepte pe care le vom descrie în paragraful următor.

1.2.2. Operațiile modelului de date orientat pe obiecte

Operațiile modelului de date orientat pe obiecte pot fi grupate astfel:

obiectele comunică între ele prin mesaje. Transmiterea și respectiv

primirea de mesaje stă la baza operațiilor modelului orientat pe obiecte;

un mesaj poate fi trimis instanțelor mai multor clase. Comportamentul polimorfic presupune selectarea metodei adecvate definită pentru clasa obiectului respectiv sau pentru o superclasă,

metodele pot fi definite, șterse sau modificate;

clasele pot fi definite și actualizate prin operații de creare, ștergere sau modificare;

instanța unei clase poate fi actualizată prin metode ce modifică valorile variabilelor propriei instanțe, aceasta modificând starea internă a obiectului;

Într-o serie de implimentări, definirile de clase sunt ele însele obiecte, numite obiecte clasă.

Obiectele clasă sunt instanțe ale unei clase generice sau ale unei metaclase. Deci, operațiile de creare, modificare și ștergere a definirilor de clasă pot fi implimentate ca mesaje.

1.2.3. Reguli de integritate ale modelului de date orientat pe obiecte.

În modelul de date orientat pe obiecte, regulile de integritate sunt o consecință a structurii modelului și a operațiilor. Următoarele reguli sunt important de reținut:

toate obiectele trebuie să respecte protocolul specificat de definirile lor de clasă. Astfel, un obiect poate răspunde doar la acele mesaje permise de clasa de care aparține;

obiectele sunt încapsulate. Acest lucru presupune accesul limitat la obiecte prin folosirea numai a protocolului de mesaje definit pentru clasa obiectului;

în principiu, identificatorul obiectului asigură integritatea referirii la un obiect. Astfel un obiect nu există fără să aibă asignat un identificator.

Dacă SGBD – OO comerciale nu susțin toate implicațiile integrității de

referire. Conceptul de ștergere în cascadă nu este implementat în majoritatea

SGBD – OO comerciale. Astfel, când un obiect este șters este dificil de specificat ștergerea automată a altor obiecte la care se referea obiectul șters.

1.3. Limitele bazelor de date orientate obiect

Cu toate că primele SGBD-uri orientate pe obiecte apărut pe piață în urmă cu șase ani, tehnologia bazelor de date orientate pe obiecte se găsește încă într-o etapă de pionierat. Imaturitatea tehnologiei bazelor de date orientate pe obiect s-ar traduce într-o serie de limitări care acum justifică reținele potențialilor utilizatori:

De oarece nu au fost acumulate suficientă experiență în domeniu, fiecare pas este unul de învățare și pionerat chiar și pentru producătorii de astfel de sisteme;

Măsura în care sistemele orientate pe obiecte sunt scalabile nu a fost încă suficient testată astfel încât comportarea acestora la volume foarte mari de date, în condițiile unei accesări concurente intense, este dificil de prevăzut. Tot aici ar putea intra și problemele încă ne rezolvate privind siguranța exploatării, restaurarea după incidente, controlul integrității, mecanismele tranzacționale;

Nu există încă o ofertă semnificativă de facilități de dezvoltare evaluate, cum ar fi generatoarele de aplicații și pachetele 4GL dedicate. De asemenea, lipsesc produse CASE care să faciliteze proiectarea corectă a ierarhiilor de clase;

Limbajele de interogare sunt deficiente. Tocmai datorită faptului că o mare parte din cod este încapsulată în obiecte interogarea ad-hoc a bazei de date devine mai dificilă. Altfel spus, cum pot căuta niște obiecte a căror structură îmi este ascunsă?;

Nu există încă standarde acceptate. Elaborarea și implimentarea acestora este dificilă tocmai datorită specificului "extensibil" al tehnologiei obiectuale.

1.4. Caracteristici fundamentale ale bazelor de date.

Conceptul de bază este obiectul, pe care îl putem defini ca fiind reprezentarea unei entități a lumii reale. În baza de date obiectul este identificat într-o manieră unică printr-un identificator, numit OID (Object IDentifier), atribuit de sistem. Două obiecte având OID diferite sunt considerate ca diferite, spre deosebire de SGBD-urile relaționale unde obiectele (tuple de valori corespunzând atributelor tabelei) nu sunt identificate decât prin valorile lor.

Un obiect este descris printr-un ansamblu de proprietăți constituind atribute și metode. Posibilitatea de a face private aceste proprietăți vis-a-vis de obiect se numește încapsulare. Altfel spus, nici un alt obiect nu cunoaște metodele unui obiect dat decât prin semnăturile lor (numele metodei, lista parametrilor și tipul rezultatului returnat) și nu are, în principiu, nici un mijloc de a accede la atributele acestuia, care sunt manipulate prin metodele proprii.

Obiectele sunt abstractizări ale entităților lumii reale și se caracterizează prin stare și comportament.

Starea unui obiect este exprimată prin valorile atributelor sale. Colecția de atribute aleasă pentru un obiect trebuie să fie suficientă pentru a descrie entitatea.

Comportamentul unui obiect reprezintă un set de metode sau operații care acționează asupra atributelor sale.

Fiecare obiect are asociat un nume care coincide, de obicei, cu numele entității reprezentate.

Structura unui obiect și operațiile (metodele) permise pentru acel obiect sunt definite împreună.

Obiectele din lumea reală, de aceeași natură sau prezentând similitudini, sunt grupate în cadrul unei clase în care sunt declarate toate atributele precum și metodele care le manipulează. O clasă constituie astfel un tipar pentru o mulțime de obiecte. Pe planul reprezentării interne, un obiect creat este o zonă de memorie conținând diferitele valori ale atributelor. Cât despre metode, ele sunt descrise o

singură dată și partajate de toate obiectele din clasă.

În contextul bazelor de date obiectuale, noțiunea de clasă de obiecte acoperă un aspect intensional (adică descrierea) și un aspect extensional (ansamblul de obiecte ale clasei). Orice obiect este construit apoi plecând de la o clasă (sau un tip) care regrupează structura datelor și metodele. O clasă joacă astfel rolul unui generator de obiecte.

Pot fi identificate trei tipuri de obiecte:

– obiecte elementare: întreg, boolean, șir de caractere;

– obiecte compuse: nume, adresă;

– obiecte complexe: avion, angajat.

Structura unui obiect și operațiile (metodele) permise pentru acel obiect sunt definite împreună.

O metodă reprezintă un program ce manipulează obiectul sau indică starea sa. Metoda este întotdeauna asociată unei clase. Specificarea metodei poartă numele de “semnătură” iar modul de implementare constituie “corpul” metodei. Secvența de program care implementează metoda poate fi compilată în orice moment al dezvoltării aplicației, fără ca nici o altă recompilare să fie necesară.

Metodele și atributele nu sunt vizibile din “exteriorul” obiectului. Astfel, un obiect are o implementare care este privată și o interfață care este publică și poate fi “văzută” de utilizatori și de alte obiecte. Implementarea poate fi modificată fără a modifica interfața.

Metodele de creare și de modificare sunt indispensabile tuturor claselor pentru a crea și a actualiza obiectele clasei. Încapsularea datelor asociate obiectului conduce la imposibilitatea de a fi văzute de către celelalte obiecte.

Un obiect răspunde la mesaje. Mesajele reprezintă cereri adresate obiectului pentru a returna o valoare sau pentru a-și schimba starea. Ele constituie interfața obiectului cu mediul.

Un mesaj indică unul sau mai multe obiecte și o metodă ce se aplică

acestora. Mesajele cuprind: numele mesajului, numele obiectului ținută pentru care au fost transmise și argumentele necesare, dacă există. Când un obiect primește un mesaj, una din procedurile sale este apelată. Procedura realizează apoi o operație care poate returna un rezultat. Mesajele sunt implementate prin intermediul metodelor. Codul pentru metode poate fi generic, capabil să opereze cu obiecte cu structuri diferite.

Structura obiectului și modul de acțiune al metodelor sale nu pot fi accesate și actualizate direct de către un agent extern, dar pot fi modificate indirect prin intermediul mesajelor. Această caracteristică ascunsă a stării obiectului este cunoscută sub numele de încapsulare. Un obiect este astfel divizat în două părți: o parte de interfață reprezentată de mesaje și o parte ascunsă, de implementare, reprezentată de starea internă și de metodele obiectului. Interfața permite deci unui agent din exterior să solicite obiectului executarea unei acțiuni trimițând-ui un mesaj corespunzător metodei (publice) asociate acțiunii.

Obiectele pot fi de asemenea considerate ca fiind date abstracte. Dată – abstractă este o tehnică folosită în multe limbaje de programare în care operațiile și reprezentarea internă a unei entități calculabile sunt parțial ascunse din punct de vedere extern. Abstracția permite rezultatelor entității calculabile să fie văzute, în timp ce ascunde modurile prin care s-a efectuat calculul.

Persistența este o proprietate a datelor sau a obiectelor care implică existența mai îndelungată a acestora față de procesul care l-a creat. Este proprietatea prin care starea bazei de date asigură execuția unui proces pentru a fi folosit ulterior în alt proces.

Codul aferent metodelor – făcând parte integrantă din obiect – este stocat, ca și starea obiectului, în baza de date. Aceasta înseamnă că, odată ce a fost descrisă, o metodă devine permanentă. O modificare adusă unei metode devine imediat operantă și persistă până la o nouă modificare.

Orice obiect sau valoare raportată printr-o instanță este de asemenea, persistentă.

Obiectele care au același fel de atribute și comportament pot fi categorisite

ca făcând parte din același tip sau clasă.

În raport cu această caracteristică, există două categorii de sisteme orientate pe obiecte:

cele care admit ca noțiune de bază clasa, cum sunt Smalltalk, Gemstone, Vision, Orion, G–Base;

cele care admit ca noțiune de bază tipul, cu reprezentanți de bază ca: C++, Simula, base, O2.

Într-un sistem orientat pe obiecte, tipul sintetizează elementele comune ale unui set de obiecte cu aceleași caracteristici. Corespunde noțiunii de tip abstract de date și are două componente:

interfața;

implementarea.

Pentru utilizator numai partea de interfață este vizibilă, cea de implementare făcând obiectul activității proiectantului.

Noțiunea de clasă deși are aceeași specificație cu cea de tip, este diferită de aceasta, fiind mai mult asociată de faza de execuție. Presupune două aspecte:

generarea de obiecte (prin operația “new” aplicată unei clase);

stocarea setului de obiecte care reprezintă instanțele clasei.

O clasă are o descriere ce constă dintr-un set de mesaje, la care instanțele clasei vor răspunde și un set de metode pentru implementarea de operații comune.

Clasele sunt de asemenea referite uneori ca tip de dată abstractă. Descrierea clasei servește ca șablon după care vor fi create noile obiecte. O clasă este deci un tip abstract de date care definește atât structura obiectelor din clasa respectivă, cît și mulțimea metodelor existente pentru aceste obiecte. Ca urmare, obiectele din aceeași clasă au aceleași atribute și aceleași metode și răspund la același mesaj.

Deoarece obiectele făcând parte din aceeași au aceleași metode, putem vorbi despre metode ca aparținând claselor și nu obiectelor în sine.

Utilizatorii obiectelor unei clase nu cunosc decât partea publică sau specificația clasei respective. Partea privată a clasei, care definește structura internă a obiectelor și modul de implementare a operațiilor, rămâne inaccesibilă utilizatorilor.

Clasele sunt organizate ierarhic. Există o metodă proprie (“built-in”) pentru definirea noilor clase. Fiecare clasă nou creată trebuie să fie o subclasă a unei clase existente. Dacă nu există nici o superclasă potrivită pentru definirea unei noi clase, aceasta va fi identificată ca o subclasă a clasei generale sistem (metaclasă). Orice subclasă moștenește structurile și metodele superclasei din care face parte.

O clasă poate crea noi instanțe ale obiectelor. Din punct de vedere al bazelor de date, o clasă poate fi considerată ca un tip înregistrare constând din metadata care asigură întreaga informație necesară pentru a construi și a folosi un anume obiect. Similar, e posibil de a considera instanțele unei clase ca fiind înregistrări stocate într-un fișier. Un dicționar de date pentru SGBD poate conține descrieri a multor tipuri diferite de înregistrări fiecare cu un set diferit de atribute.

Într-o bază de date orientată pe obiecte, clasele sunt aranjate într-o ierarhie în care fiecare clasă moștenește toate atributele și metodele superclasei din care face parte. Moștenirea este un concept puternic, care conduce la posibilitatea de reutilizarea a codului, și deci la creșterea semnificativă a productivității în proiectare.

Aplicații complexe care se folosesc de obiecte cum ar fi sistemele de desing asistat de calculator, solicită deseori definirea a numeroase și diferite clase. Este posibil să avem nevoie de o definire separată de clase. Este posibil să avem nevoie de o definire separată de clasă pentru fiecare obiect. Oricum, dacă unele obiecte sunt tipuri specifice, particulare, a altor obiecte, ar fi normal să folosim aceste avantaje ale relației dintre ele în definirea claselor. Aceasta se poate realiza având definiri de clasă în care o clasă specifică poate împărți sau împrumuta parte din descrierea unei clase mai generale.

Mecanismul de realizare a definirii unei clase în care derivă variabile de instanță și metode din altă definire de clasă se numește moștenire . Când o clasă moștenește variabile de instanță și metode din altă clasă, este considerată a fi o subclasă. Conceptele de subclasă și supraclasă sunt analoge conceptelor de generalizare și specializare familiare metodologiilor de modelare a datelor.

Polimorfismul se referă la faptul că, la primirea unui mesaj, stabilirea metodei care se aplică se face în mod dinamic, în funcție de clasa obiectului în cauză. Astfel, instanțe ale unor clase diferite pot fi adresate uniform, dar manifestă comportamente diferite. Acest fapt asigură manipularea simplă și coerentă a seturilor eterogene de obiecte.

Un alt tip de comportament polimorfic este asociat cu moștenirea. Răspunsul unui obiect la un mesaj poate fi determinat de metodele moștenite de la superclasă. Moștenirea multiplă permite definirea unor forme complexe de comportament polimorfic care pot antrena uneori combinarea metodelor de la două sau mai multe superclase.

Identitate este un mijloc de a distinge un obiect de altul. Prin identitate se asigură și persistența datelor.

Oricare din obiectele unei baze de date orientate pe obiecte are identitate care este independentă de valorile atributelor sale. Spre deosebire de modelul relațional, care utilizează unicitatea cheii primare pentru a identifica “obiectul” , tehnologia orientată pe obiecte permite modificarea valorilor oricărui atribut fără a-i afecta identitatea. Mai mult chiar, obiectele au “conștiința de sine”: pointerul Self, prin intermediul căruia obiectele se pot referi la ele însele.

Fiecare instanță sau realizare a obiectului are un identificator de obiect intern, repartizat lui și cunoscut ca un ID obiect sau pointer. Acesta este independent de valorile atributelor sale. Fiind generat de sistem, identificatorul este unic și nu este accesibil utilizatorului.

2. Delphi – limbaj orientat pe obiecte

2.1. Limbaje orientate pe obiecte

SGBD-urile orientate pe obiecte sunt rezultatul unirii între SGBD-urile tradiționale și limbajele de programare orientate pe obiecte (LOO), deoarece mulțumită acestora din urmă conceptele abordării obiectuale au putut să-și facă apariția în domeniul bazelor de date. Nevoile ivite din aplicațiile complexe conjugate cu puterea crescândă a calculatoarelor conduc la sisteme din ce în ce mai complexe care nu pot fi stăpânite decât cu o organizare eficientă a dezvoltărilor. În acest cadru, programarea orientată pe obiecte este nu numai o tehnică de programare ci constituie în mod esențial o tehnică de structurare a programelor care se sprijină pe entități manipulate de sistem și nu pe funcțiile sale.

Caracteristica principală a LOO este că permite o evoluție și o modularizate crescută programelor, precum și o mai mare putere declarativă.

Conceptul de programare orientată pe obiecte a apărut către 1970 și s-a răspândit încetul cu încetul în mediile inteligentei artificiale. El a inspirat numeroase limbaje, adesea experimentate și concepute pentru a răspunde unei nevoi specifice sau pentru a testa un concept dat. Dar această abundentă de programe pare astăzi să conveargă spre instrumente generale realizând sinteza cercetărilor din trecut.

Limbajele orientate pe obiecte, departe de a fi o chestiune de modă, propun o nouă abordare a programării care își datorează originalitatea fuziunii naturale dintre prelucrări și date. LOO constituie un pas suplimentar spre o modularizate sporită a programelor . Aceste limbaje sunt construite conform următoarelor 4 axiome:

Axioma 1: Orice este obiect. Un obiect se poate caracteriza prin:

– o structură de date, adică de variabile caracterizând starea sa și care sunt rezervate pentru a fi folosite în mod privit de către obiect;

– o structură de control a comportamentului, adică mesaje care sunt în general publice. Ele pot fi folosite de alte obiecte pentru a comunica cu obiectul în cauză. Atunci când sunt primite de obiect, ele activează metode asociate care induc un anume comportament obiectului.

Axioma 2: Orice obiect este creat plecând de la un model care este propriu acestui obiect: clasa. Se spune despre acel obiect cг este o instanță a clasei sale.

Unele obiecte au un statut dublu. Pot exista obiecte ale căror instanțe sunt ele însele clase. Clasele care le corespund se numesc metaclase.

Axioma 3: Orice obiect acceptă mesaje (cu sau fără parametri) la care răspunde.

Axioma 4: Orice clasă este o subclasă a cel puțin unei alte clase (superclasa), exceptând clasa "Obiect" care este rădăcina ierarhiei.

LOO permit dezvoltarea de aplicații într-o formă modulară ceea ce favorizează prototipizarea, testarea, reutilizarea codului și micșorarea sarcinilor dezvoltării. Un modul implementează o clasă de obiecte și fiecare nou modul poate fi obținut prin simplă specializare.

2.2. Reprezentant al limbajelor orientate pe obiecte – Delphi

Deși apărut la apusul epocii codului pe 16 biți, Delphi a impus un nou standard în dezvoltarea rapidă de aplicații si reprezintă primul mariaj fericit între un mediu de dezvoltare vizuală si un compilator veritabil. Versiunea pe 32 de biți readuce produsul pe creasta valului tehnologic si vizează o creștere dramatică atât a productivității dezvoltatorilor cît si a performantelor aplicațiilor acestora.

Cerințele utilizatorilor de azi privind funcționalitatea aplicațiilor cresc la fel de repede precum scad termenele de predare. Presiunea sporită asupra dezvoltatorilor de programe face ca aceștia să nu se mai mulțumească doar cu un compilator foarte rapid; dezvoltarea este frânată de numeroși factori și soluțiile însumate pot duce la salturi spectaculoase de productivitate.

Object Pascal dispune de avantajele tradiționale ale compilatorului care depistează erori logice provenite din cod incorect ori ambiguu, ca si de verificările stricte de tip. În noua versiune, compilatorul continuă să compileze codul chiar si după găsirea primei erori, oferind o imagine completă a corectitudinii programelor, utilă mai ales în depanarea proiectelor mari. Contrar compilatoarelor C++, rareori o primă eroare induce raportarea unei întregi serii de erori fără relevantă.

Compilatorul oferă acum un sistem de diagnosticare a erorilor mult mai complet incluzând detectarea utilizării de variabile sau pointeri neinitializati, variabile neutilizate, rezultate neutilizate returnate de funcții, bucle goale si nepotriviri de tipuri. Analizorul sintactic a devenit mai subtil, permitîndu-și sugestii utile mai ales programatorilor începători.

Tot aceștia din urmă au tendința de a comasa întregul cod într-o singură unitate greu de întreținut si depanat. Pentru a-l încuraja sa-si separe în mod logic munca în unități distincte cu interfețe strict delimitate, Delphi le oferă selecția vizuală a unităților care se includ în clauza uses.

Următorul pas logic pentru încurajarea programării modulare a fost referința automată la componente conținute în forme diferite. Deși proprietățile sau metodele componentelor din alte forme decât cea curentă erau accesibile programatic (prin scrierea de cod), în faza de design erau inaccesibile. Facilitatea de a referi componente din alte forme ale proiectului în timpul dezvoltării vizuale permite separarea modulelor care încapsulează structurile de date ca i relațiile dintre acestea de modulele care implementează interfața cu utilizatorul.

În același context se înscrie si obiectul vizual – DataModule – destinat stocării componentelor non-vizuale cum ar fi tabelele, query-urile si sursele de date pentru a încuraja separarea logicii de baze de date si de calcul de elementele de prezentare vizuală pentru interacțiune cu utilizatorul. Structura bazei de date poate fi definită în mod consistent într-un modul de date o singură dată pentru întregul proiect, iar obiectele conținute de acesta pot fi referite apoi din diverse alte forme.

Poate cea mai importantă obiecție a programării obiectuale fată de tehnica vizuală a precedentei versiuni a lui Delphi a fost imposibilitatea de a deriva noi forme prin moștenirea celor existente. Este natural într-un mediu complex de proiectare să creezi obiecte standard, din care urmează să fie derivate obiecte concrete care să moștenească imediat orice modificare s-ar efectua în obiectele de bază. Delphi preia această caracteristică fundamentală OOP si o extinde la mediul vizual de dezvoltare. Prin tehnica moștenirii vizuale se pot crea în faza de design noi forme care să preia proprietățile, evenimentele si metodele formei originale pe oricâte nivele de moștenire, fără a induce penalizări de performantă în aplicația finală.

Pentru formele cu caracter mare de generalitate – utilizabile în mai multe proiecte – Delphi oferă un mediu de stocare – Object Repository – partajabil chiar de membrii unei echipe într-o rețea locală. Tot aici pot fi stocate module de date, biblioteci DLL sau experți. Orice aplicație poate moșteni, referi sau copia un obiect din Object Repository.

Să trecem în revistă si să inspectăm modul în care unele obiective ale lui Delphi s-au regăsit în produsul final:

mărirea avansului în termeni de performantă prin introducerea unui nou compilator capabil de cod optimizat pe 32 biți;

compatibilitate completă cu programele Delphi existente pe 16 biți;

creșterea reutilizabilității obiectelor prin suport pentru controale OLE (OCX) si automatizare OLE;

suport complet pentru interfață și satisfacerea exigentelor logo Windows;

suport complet pentru aplicații pe 32 biți atât pentru Windows;

productivitate mărită în dezvoltarea de aplicații;

creșterea scalabilității aplicațiilor client-server de baze de date cu versiunea pe 32 biți a lui Borland Database Engine;

2.2.1. Performanță – optimizarea compilatorului pe 32 biți

Diferența dintre mediul Delphi și celelalte compilatoare constă în faptul că în Delphi produce cod nativ. Multe dintre complicații produc la compilare cod simbolic. Există două avantaje majore ale compilării în cod nativ: micșorarea dimensiunilor aplicațiilor și mărirea vitezei de execuție. Un alt avantaj constă și în suportul dual al lui Delphi pentru fișiere de tip unități Turbo Pascal (DCU) si fișiere în format standard OBJ. Ca urmare, partajarea de cod între Pascal si C++ a încetat să mai fie o problemă.

În fine, structurile de date de orice fel, vectorii si string-urile pot avea acum orice dimensiune – limitată numai de sistemul de operare. Segmentele de date si de stivă pot avea orice dimensiune iar cel de stivă poate creste dinamic.

Proiectantii au reușit să introducă tehnici remarcabile de optimizare a codului păstrând compilarea într-un singur pas precum si viteza de peste 350000 linii pe un procesor Pentium. Optimizarea regiștrilor, utilizarea regiștrilor pentru reducerea stivelor de apel de rutine, eliminarea subexpresiilor comune, inducerea variabilelor de buclă generează cod mașină deosebit de rapid si compact care nu schimbă sensul codului original si poate fi depanat natural.

Noul link-editor apelat la sfârșitul procesului de compilare este cu 20% până la 50% mai rapid decât versiunea precedentă. Câteva optimizări concură la obținerea acestui rezultat. Astfel, utilizarea unei scheme de păstrare în memorie a

unităților si formelor nemodificate măreste semnificativ viteza de link-editare prin comparație cu reînărcarea modulelor de pe disc. Un nou format pentru unități (DCU) permite link-editorului să utilizeze o tehnică de verificare inteligentă a versiunilor care reduce drastic redundanta din recompilare. Astfel, dacă în trecut modificarea unei funcții dintr-o unitate determina recompilarea automată a tuturor unităților care foloseau vreun element din interfața unității modificate, acum numai unitățile care apelează explicit funcția modificată sînt incluse în procesul de recompilare. Producătorii de biblioteci de obiecte si componente nu vor mai fi nevoiți să distribuie o nouă versiune, recompilată, pentru fiecare nouă versiune de Delphi.

La apariția noilor sisteme de operare pe 32 biți, numeroase voci susțineau că noul cod pe 32 biți ar fi mult mai obez decât echivalentul lui pe 16 biți. Cu certitudine acest fapt nu este valabil pentru Delphi: optimizările compilatorului si link-editorului reduc tipic cu 20-25% dimensiunea executabilului rezultat.

Fractura dintre sistemele de operare pe 16 si cele pe 32 biți s-a propagat până în mediile de dezvoltare de aplicații. Spre deosebire de Microsoft care asigură suport numai pentru ultimele tehnologii, Borland a făcut eforturi de protejare prin asigurarea unui nivel rezonabil de compatibilitate cu versiunile precedente ale compilatoarelor sale. La fel stau lucrurile și cu Delphi a cărui compatibilitate cu versiunile precedente este un veritabil pod între două lumi foarte diferite.

În cele mai multe cazuri, aplicațiile pe 16 biți pot fi pur si simplu recompilate și îmbogățite cu facilități specifice pe 32 biți. Portabilitatea este asigurată de așa numitul unit aliasing care permite redirecționarea referințelor la unități vechi către versiunile noi, de manipularea mesajelor prin tipuri similare de date, precum si de păstrarea în paletă a unor componente altfel depășite din versiunea anterioară.

Unele tipuri de date implicite și-au schimbat dimensiunea și au apărut tipuri noi de date care servesc mai bine scopuri vechi. Codul care presupune o anumită dimensiune fizică a structurilor de date devine inoperant. Optimizările în limbaj de asamblare sînt nu numai necompilabile dar si desuete în cele mai multe cazuri prin comparație cu cele efectuate nativ de compilator. Alocarea de memorie pe bază criteriului memoriei libere nu mai funcționează corect ca urmare a noii scheme de alocare a memoriei dintr-un spațiu de adrese virtual nelimitat.

Tehnicile clasice de comunicație inter-aplicații sînt total neutilizabile în noul mediu cu cerințe sporite de stabilitate în care aplicațiile rulează în spatii de adrese complet diferite si nu mai pot partaja un banal bloc de memorie. Bibliotecile DLL pe 16 biți care asigurau partajarea variabilelor globale între mai multe instanțe ale aceleiași aplicații sau între aplicații diferite dau cea mai mare bătaie de cap întrucât securitatea multitasking-ului preventiv impune alocarea unui segment de date separat pentru fiecare instanță. Soluțiile pentru aceste probleme sînt specifice si comportă fișiere mapate în memorie ori utilizarea unui mesaj special de copiere a datelor dintr-un spațiu de adrese în altul. Și nu în cele din urmă, codul pe 32 biți nu mai link-editează dinamic vechile DLL-uri pe 16 biți, care trebuie fie recompilate.

2.2.2. Mediul Delphi și sistemul Windows

În Delphi se regăsește suport pentru toate facilitățile oferite de Windows 9x si NT. De departe cea mai semnificativă este capacitatea de a crea cod executabil în fire paralele de execuție (multi-threading). Complexitatea inițierii si controlării firelor de execuție paralele este încapsulată acum într-o clasă specializată – TThread – care permite definirea unui thread prin introducerea codului specific în metoda Execute si atribuirea unei metode care reacționează la încheierea execuției firului. Prioritatea execuției se stabilește prin simpla atribuire de valoare proprietății Priority, iar lansarea thread – ului prin setarea proprietății Suspended.

Încapsularea obiectuală a thread-urilor face ca executarea în paralel a mai multor sarcini identice să se reducă la instanțierea mai multor obiecte din aceeași clasă derivată din TThread. Diferitele instanțe pot partaja variabilele globale între ele sau creează copii proprii ale variabilelor prin utilizarea declarației threadvar. Exceptând unele componente din Visual Component Library, nu există restricții asupra includerii în codul thread-ului a obiectelor sau funcțiilor din interfața API Windows.

Biblioteca de sistem include tipuri si funcții care asigură suport complet pentru Unicode. Tipul fundamental WideChar definește caracterul reprezentat pe 16 biți si ordonat conform Unicode, în timp ce PWideChar este pointer la string-ul de caractere Unicode. Tipul generic Char continuă însă să fie de tip ANSI, pe 8 biți.

Interfața procedurală cu Win API este completă (chiar dacă mizerabil documentată) si permite accesul aplicațiilor la diversele funcționalități oferite de sistemul de operare. Între acestea se numără si Winsockets, fișiere mapate în memorie, interfața de comunicații TAPI. Totusi, cel putin pentru suportul groupware MAPI ar fi fost necesară o interfață obiectuală dedicată.

Între cele aproape 100 de componente din paleta lui Visual Component Library se regăsește si suita completă de controale specifice lui Windows. Suita se compune din TabSet si PageControl pentru crearea de dialoguri cu mai multe pagini, TreeView destinat afișării unei ierarhii de obiecte, ListView pentru prezentarea pe coloane a unei liste de obiecte, ImageList care controlează o listă de imagini pentru afișare arborescentă sau pe coloane, HeaderControl pentru plasarea de bare de control pe spațiul de lucru, RichEdit – un editor de text cu facilități extinse de formatare, StatusBar – zonă plasată în partea inferioară a ferestrelor destinată afișării situatiei curente a aplicației, TrackBar – o îmbunătătire sub formă de potențiometru a clasicului scrollbar, ProgressBar – similar cu TGauge si destinat afișării progresului unei proceduri, UpDown – butoane de incrementare și decrementare a unei valori, si în fine, HotKey – conceput pentru atasarea facilă a unor combinații de taste active pentru orice component. Prin draparea lor în componente, programatorul este scutit de frecușul cu interfața noduroasă de nivel procedural. Când este necesar un nivel superior de funcționalitate, dezvoltatorii pot implementa propriile lor metode, proprietăți si componente prin moștenire. Toate controalele Win95 pot fi subclasate, ba chiar reprezintă un teren fertil pentru inovații si extensii. În pachetul Developer se livrează si sursele complete ale bibliotecii de componente, care se dovedesc foarte valoroase în înțelegerea comportamentului specific al obiectelor de interfață.

2.2.3. Mediul Delphi și tehnologia OLE

Borland aderă acum în întregime la tehnologia OLE. Formatul obiectelor din Delphi si BC++ au la bază modelul comun de obiect (COM), ambele limbaje oferind astfel suport obiectual nativ pentru OLE.

Integrarea controalelor OLE (OCX) într-un mediu de dezvoltare complet obiectual precum cel al lui Delphi nu prezintă nici o problemă. Mai ușor chiar controalele OCX se includ facil în paleta de componente, iar Delphi creează automat o clasă care "îmbracă" controlul în component cu proprietăți, metode si evenimente, si permite chiar dezvoltatorilor derivarea de noi obiecte care să moștenească caracteristicile controlului original.

Întrucât compilatorul generează cod mașină nativ, Delphi poate fi utilizat si pentru scrierea de noi controale OCX, cu toate că această sarcină este sensibil mai dificilă decât dezvoltarea de componente native.

Un nouă variantă a fost creată special pentru facilitarea automatizărilor OLE. Aceasta permite utilizatorilor să declare variabile al căror tip este determinat în timpul rulării, adaptând astfel aplicația de tip controlor OLE la flexibilitatea automatizării OLE. În fapt, se poate utiliza o singură variabilă pentru conectarea la diferite tipuri de servere OLE.

Parametrii cu nume permit utilizatorilor să specifice numai parametrii de interes în apelurile de servere OLE, păstrând valorile implicite ale server-ului pentru ceilalți parametri.

2.3. Avantajele mediului Delphi în raport cu bazele de date

Numeroase sînt extensiile de baze de date care pot fi regăsite în actuala versiune de Delphi si care ușurează considerabil surmontarea problemelor specifice ridicate de proiectele de baze de date.

Dicționarul de date stochează si utilizează informația despre conținutul si comportamentul datelor din tabele. Aici se pot specifica atribute extinse de câmpuri precum valorile minimă, maximă si implicită, opțiunile de formatare în afișare si editare. Este locul ideal pentru a stabili si asigura integritatea datelor. Formele în care urmează să fie utilizate vor prelua instantaneu caracteristicile si vor stabili conexiunile la selectarea câmpurilor de date.

Componentele de acces la bazele de date au fost rescrise în întregime păstrând însă interfața versiunilor precedente. Astfel, tabelele si query-urile sînt completate cu proprietăți si evenimente de filtrare dinamică a datelor si oferă evenimente suplimentare pentru tratarea extinsă a erorilor. Există o proprietate care permite utilizarea facilității de stocare în cache a modificărilor (detalii despre cache updates mai jos). Tabelele pot face uz de tehnica specială BDE de filtrare a datelor printr-o expresie de tip SQL care garantează obținerea unui set editabil de înregistrări (ceea ce nu întotdeauna este posibil printr-un query) cu minimum de consum de memorie.

Paleta de acces la baze de date s-a îmbogățit cu o formă specială de query – TUpdateSQL – care preia operațiunile de ștergere, inserare si actualizare de înregistrări spre deosebire de clasicul TQuery, care este rezervat acum doar pentru operatiuni de interogare. Remarcabil este editorul vizual de compunere rapidă a frazei SQL, inclus în toate versiunile pachetului spre deosebire de editorul lui TQuery rezervat în continuare pentru greu accesibilul pachet Delphi Client-Server.

O atenție deosebită o au componentele vizuale de prezentare și editare a datelor. Obiectele DBLookupCombo si DBLookupList sînt păstrate numai pentru compatibilitate; înlocuitoarele lor mai versatile si mai performante sînt acum DBLookupComboBox si DBLookupListBox. Omniprezentul DBGrid este semnificativ îmbogățit cu facilități de formatare la nivel de coloană si include tehnici de căutare si look-up în câmpul curent. Un nou component – DBCtrlGrid permite prezentarea mai multor înregistrări dintr-o tabelă, fiecare având rezervat propriul spațiu de afișare în care se pot plasa toate celelalte tipuri de controale de date pentru editarea câmpurilor. Afișarea unei liste de imagini dintr-o tabelă se poate face astfel fără a mai scrie vreo linie de cod.

În precedenta versiune a bibliotecii de componente se resimțea puternic absenta unui set de componente pentru dezvoltarea vizuală de rapoarte. Greul Report Smith era în mod evident destinat aplicațiilor de corporație bazate pe server-e SQL, fără a se potrivi cu necesitățile unei aplicații desktop. Din fericire industria shareware a produs rapid câteva asemenea soluții, dintre care Borland a cumpărat-o pe cea mai reușită si a inclus-o în toate pachetele de Delphi. QuickReport reprezintă un set de 11 componente care se integrează perfect cu componentele de acces la bazele de date (TTable, TQuery), dar pot prelua datele si din vectori, liste sau orice fel de variabile. Rapoartele se redactează sub forma clasică de benzi care pot include titluri, câmpuri calculate, de însumare si de sistem, dar si imagini bitmap sau metafile ori forme geometrice simple. Sânt posibile rapoarte master-detail pe mai multe nivele sau cu mai multe seturi detail si grupate pe criterii foarte diverse, inclusiv câmpuri calculate. Benzile pot reprezenta seturi detail, antete sau subsoluri de pagină, grup sau raport si pot fi organizate pe mai multe coloane sau în format de etichete multiple, iar calculele pot fi inițializate la nivel de bandă. Datele se pot previzualiza în faza de design iar un component special permite previzualizarea lor în timpul rulării. Pentru baze de date mici (de ordinul zecilor de mii de înregistrări) Quick Report este cu un ordin de mărime mai rapid decât Report Smith. Ca urmare însă a includerii lor în fișierul executabil sub formă de resurse, rapoartele sînt complet inaccesibile utilizatorului final pentru modificări.

2.4. Performanțele programelor Delphi de baze de date

Prezentarea lui Delphi nu poate omite versiunea pe 32 biți a lui Borland Database Engine, pe care se bazează performantele obținute de programele Delphi de baze de date, aceleași de altfel cu cele obținute cu Paradox sau Visual dBASE. BDE comportă o arhitectură obiectuală care permite un acces simplu si nativ din limbajele obiectuale la funcțiile încorporate de un nivel foarte înalt, de la operatiuni cu seturi de date prin interogări SQL sau QBE si filtre pînă la suport navigational complet prin relatii master-detail si lookup.

Concepția pe 32 biți se reflectă în suportul pentru multitasking preventiv: mai multe programe pot fi deservite simultan de BDE si pot accesa aceeași bază de date în același timp. În plus, în cadrul aceluiași program se pot executa simultan mai multe operațiuni BDE separate în fire de execuție diferite. Este posibilă astfel execuția de query-uri multiple în spate în timp ce în fată utilizatorul editează o tabelă.

BDE suportă acum nume lungi, descriptive (260 caractere incluzând si spatii) de tabele desktop, inclusiv în fraze SQL sau QBE. Numele de tabele SQL sînt în general limitate la 30 de caractere de server-le SQL corespunzătoare.

Accesul la bazele de date de pe server-e se poate efectua acum prin utilizarea convenției UNC (convenția numelui universal) preferată de Win95 si NT mapării discurilor logice.

Nucleul de interogare SQL este complet rescris si separat acum de nucleul QBE. Performanta interogărilor SQL pe tabele desktop a crescut substanțial si au căzut o serie de restricții din subsetul Local SQL, care se apropie acum si chiar depăseste standardul SQL 92. Sânt posibile includerea de subquery-uri în clauzele WHERE si HAVING, utilizarea de expresii în funcțiile de agregare, ca si în clauzele GROUP BY si ORDER BY, precum si utilizarea operatorului UNION. Subseturile de înregistrări returnate de interogări asupra mai multor tabele pot fi editate cu reflectarea modificărilor în tabelele originale. Subseturile rezultate din query-uri pot fi suplimentar rafinate prin utilizarea de filtre.

O îmbunătățire care va îndepărta coșmarul multor dezvoltatori de baze de date desktop este suportul tranzacțional complet pentru tabele Paradox si dBASE. Modificările tabelelor pot fi grupate într-o tranzacție si efectuate sau anulate integral, asigurând actualizarea bazei de date de o manieră consistentă si cu păstrarea integrității referențiale. Driver-ul pentru tabele Paradox este capabil de index secundar unic, index cu ordonare descrescătoare și câmpuri care se auto-incrementează, în timp ce driver-ul dBASE suportă acum încriptarea tabelelor si index în format Clipper.

Facilitatea de efectuare locală a modificărilor (cached updates) permite utilizatorilor să efectueze operațiuni asupra bazei de date într-o perioadă mai lungă de timp fără a modifica imediat baza de date de pe server, reducând la minimum consumul de resurse pe server ca si traficul pe rețea.

Dezvoltatorii de aplicații client-server SQL vor aprecia posibilitatea de a monitoriza frazele SQL care se transmit server-ului la fiecare execuție de functie BDE, ca si utilizarea de guvernatori care limitează numărul de înregistrări din seturile de date returnate de server în scopuri de accelerare a procesului de dezvoltare.

3. Procedura de evaluare academică și acreditare

Acreditarea instituțiilor din sistemul de învățământ, statale și particulare, din Republica Moldova , bazată pe evaluare , are drept scop determinarea capacităților acestora de a realiza calitativ obiectivele prevăzute de Legea învățământului.

Conform prevederilor Legii nr. 1257-XIH din 16 iulie 1997 în următorii cinci ani urmează să fie supuse evaluării academice și acreditării toate instituțiile de învățământ superior a Moldovei. Prezenta lege reglementează procesul de evaluare și acreditare a instituțiilor de învățământ statale și particulare , de toate nivelurile, din Republica Moldova. Termenii de evaluare vor fi determinați de graficul aprobat de către Guvernul Republicii Moldova. Pentru pregătirea Rapoartelor de auto-evaluare se expediază documentele de bază, executarea cărora este obligatorie.

3.1. Organul evaluării și acreditării

Acordarea autorizației de încredere (licenței) privind dreptul de înființare și funcționare provizorie a instituției de învățământ constituie prerogativa Ministerului Educație și Științei Evaluarea și acreditarea instituțiilor de învățământ primar, secundar, superior și postuniversitar constituie prerogativa Guvernului.

Pe lângă Guvern se creează Consiliul Național de Evaluare Academică și Acreditare a Instituțiilor (C.N.E.A.A.I.I.) de învățământ din Republica Moldova, denumită în continuare Consiliu.

Componența nominală a Consiliului se stabilește de către Guvern.

Consiliul constituie, de comun acord, cu alte ministere și departamente interesate, comisiile specializate de evaluare și acreditare și propune Guvernului, pentru confirmare, componența lor nominală. în componența comisiilor sînt incluși specialiști de înaltă calificare din domeniile respective, inclusiv din instituțiile Academiei de Științe a Moldovei, precum și beneficiarii viitorilor specialiști, desemnați de organele ierarhic superioare instituțiilor în cauză. In caz de necesitate, în componența comisiilor pot fi incluși și specialiști de peste hotarele Republicii Moldova.

Perioada de activitate a comisiilor specializate se – stabilește de către Guvern.

3.2. Criteriile evaluării și acreditării

Criterii generale.

Criteriile de evaluare academică și acreditare vizează toate domeniile ce țin de înființarea și funcționarea instituțiilor de învățământ: profesionalismul cadrelor didactice, conținutul și formele de organizare a învățământului, baza tehnico-materială, nomenclatorul specialiștilor, activitatea economico-financiară, activitatea științifică (în instituțiile de învățământ superior și postuniversitar), calitatea și eficiența procesului instructiv-educativ, corespunderea nivelului de pregătire a celor instruiți cu standardele educaționale de stat.

Personalul de conducere al instituției de învățământ.

Personalul de conducere al instituției de învățământ pasibile acreditării (rector, prorector, decan, prodecan, secretar științific, șef de catedră, director, director-adjunct) trebuie să fie constituit din cadre didactice cu norma de bază în instituția respectivă și cu titlu de profesor sau conferențiar universitar (în instituțiile de învățământ superior și postuniversitar) ori cu grade didactice (în instituțiile preuniversitare).

Planurile și programele de studii.

Planurile și programele de studii ale instituțiilor de învățământ pasibile evaluării și acreditării trebuie să corespundă cerințelor înaintate de Ministerul Educației și Științei și prevederilor documentelor organismelor internaționale de profil la care a aderat Republica Moldova.

Baza tehnico-materială.

Baza tehnico-materială a instituției de învățământ pasibile acreditării trebuie

să corespundă standardelor de stat respective.

Pentru obținerea acreditării, instituția de învățământ trebuie să prezinte dovada că, în conformitate cu Legea învățământului și standardele educaționale de stat, dispune de:

a) spații adecvate procesului de învățământ propriu sau arendate, inclusiv laboratoare, ateliere, săli specializate cu utilajul respectiv;

b) bibliotecă dotată cu săli de lectură și fond de carte, propriu sau arendat prin contract, corespunzător conținutului disciplinelor predate;

c) baza necesară pentru organizarea practicii prevăzute în planurile de studii.

3.3. Modul de acreditare și periodicitatea evaluării

Toate instituțiile de învățământ de stat și cele particulare se supun, în mod obligatoriu, evaluării și acreditării, în conformitate cu Legea învățământului.

Procesul acreditării include două etape:

decizia definitivă privind neacreditarea , conducerea ei e în drept să se adreseze instanței judecătorești.

Instituțiile de învățământ își pot desfășura (continua) activitatea de instruire doar în domeniile pentru care au obținut autorizația de funcționare provizorie sau acreditare.

Definitivarea studiilor în cazul neacreditării instituțiilor de învățământ.

Elevii și studenții instituției de învățământ, supuse evaluării, dar neacreditate, ce și-a încetat activitatea, își pot continua studiile, în conformitate cu specialitatea din nomenclator, în cadrul oricărei alte instituții de învățământ, acreditate sau autorizate provizoriu, cu respectarea criteriilor și condițiilor stabilite de către aceasta, conform Regulamentului cu privire la transferul elevilor și studenților, aprobat de Ministerul Educației și Științei.

4. Descrierea sistemului informațional – C.N.E.A.A.I.I. 2

4.1. Descrierea generală a sistemului informațional “C.N.E.A.A.I.I.”

Baza de date a sistemului informațional “ C.N.E.A.A.I.I.” este implementată cu ajutorul mecanismul BDE (Borland Database Engine) Configuration. Acest mecanism oferă informație de conectare pentru acces la o bază de date. Folosirea mecanismul Database Desktop ne permite vizualizarea tuturor surselor de date. Utilizând aceste instrumente, sau creat 6 tabele, în care se păstrează informația ce se referă la o instituție de învățământ.

Pentru păstrarea nomenclatorului specialităților a fost creat tabelul ProfilTable. Tabelul conține următoarele câmpuri:

ID – pentru păstrarea numărului unic al codului nomenclatorului specialităților.

Cod – pentru păstrarea codului (profilului, specialității, specializării).

Profil – pentru păstrarea numelui complet (profilului, specialității, specializării).

Tabelul pentru păstrarea informației referitor la instituțiile de învățământ se numește Registru și conține cîmpurile:

ID – numărul unic instituției de învățământ .

Institutia – denumirea instituției.

NumarFacult – numărul facultăților.

NumarCatedre – numărul catedrelor.

NumarStudent – numărul total al studenților.

Data – data acreditării instituției de învățământ .

Pentru păstrarea numerelor telefoanelor de contact, administraților e.t.c. s-a implementat tabelul Administratia. Acest tabel conține câmpuri:

ID – numărul unic înscrierii.

Nr.telefon – (număr de telefon, adresa, e-mail) administrației.

Denumirea – denumirea administrației.

Instituția – instituția la care se referă administrația.

În tabelul SpecAll se păstrează specialitățile la care sunt acreditate instituțiile de învățământ :

ID – numărul unic înscrierii.

Cod – pentru păstrarea codului (profilului, specialității, specializării).

Profil – pentru păstrarea numelui complet (profilului, specialității, specializării).

Institutia – denumirea instituției la care este acreditată specialitatea.

Informația despre profesorii titulari angajați la instituții de învățământ se păstrează în tabelul ProfTitulari:

ID – numărul unic al profesorului.

Numele – numele profesorului.

AnulNașterii – anul nașterii profesorului.

AnulAngajării – anul angajării.

Stud – denumirea instituției, facultății, anul absolvirii.

Fuctia – funcția profesorului.

Subdiviziunea – subdiviziunea profesorului.

Sarcina – sarcina didactică a profesorului.

TitluStiintific – titlul științific profesorului.

Specialitatea – specialitatea profesorului.

Specializarea – specializarea profesorului.

TitluDidactic – titlul didactic profesorului.

Institutia – denumirea instituției la care este angajat profesorului.

Următorul tabel al bazei este similar tabelului precedent, numai că destinația lui este păstrarea informației despre profesorii angajați prin cumul. Tabelul Cumul conține câmpuri:

ID – numărul unic al profesorului.

Numele – numele profesorului.

AnulNașterii – anul nașterii profesorului.

AnulAngajării – anul angajării.

Stud – denumirea instituției, facultății, anul absolvirii.

Fuctia – funcția profesorului.

Subdiviziunea – subdiviziunea profesorului.

Sarcina – sarcina cumulată a profesorului.

TitluStiintific – titlul științific profesorului.

Specialitatea – specialitatea profesorului.

Specializarea – specializarea profesorului.

TitluDidactic – titlul didactic profesorului.

Activ – activitatea de bază a profesorului.

Institutia – denumirea instituției la care este angajat profesorului.

Structura bazei de date este reprezentată în figura 4.1.

Forma principală a programului este reprezentată în figura 4.2.

4.2. Descrierea programului “Registrul instituțiilor” al sistemului informațional “C.N.E.A.A.I.I.”

Programul “Registrul instituțiilor” este destinat gestiunii informației în sistemul informațional. Operațiile principale ale programului sunt: introducerea, modificarea, ștergerea, căutarea, selectarea datelor. În afara de aceasta, programul acumulează cu timpul datele statisticii cu ajutorul cărora se formează reiting al instituției și diagramele grafice creșterii sau descreșterii prestigiului acesteia.

După instalarea programului în sistem, în mapa “Programs” apare grupul “CNEAAII” în care și se află programul.

Programul este efectuat în mediul vizual de programare pe obiect Delphi Profesional v.5.0 al firmei Borland Inprise. Programul conține mai multe forme care sunt activate cu ajutorul meniului principal, butoanelor și combinațiilor de taste de pe forma principală. În figura 4.3 este prezentată forma principală.

Fig. 4.3. Forma principală a programului.

Pe această formă sunt prezente: meniul principal a programului și un set de butoane acceleratoare. În afară de aceasta, forma reacționează la tastele apăsate, adica prin combinații din mai multe taste putem lucra cu meniul programului.

În meniul “Legistația” putem să introducem sau să efectuăm schimbări în nomenclatorul specialităților. Tot aici se aduce la cunoștințe lege despre acreditare instituțiilor de învățământ și legea privind aprobarea nomenclatorului specialităților. Meniul “Instituția” conține funcțiile de introducere, modificare și vizualizare a datelor referitoare la o instituție de învățământ. Prin meniul “Cercetări” primim informație referitoare la profesorii și reitingul instituțiilor. Meniul “Căutarea” efectuează selectarea profesorilor cu criteriu de selectare dat. Ultim punct din meniu principal “Help”, conține ghidul de utilizare și informația suplementar referitoară la sisitemul informațional “C.N.E.A.A.I.I.”.

Punctul “Nomenclator”din meniul“Legislația” are forma prezentată în figura

următoare:

Fig. 4.4. Forma de înregistrare a specializărilor.

Această formă este compusă din componentele TDBEdit, TDBGrid și TButton. Destinația acestei forme constă în introducerea corectă a nomenclatorului specializărilor. Butoanele “A adăuga” “A insera” “A schimba” “A șterge” implementesc următoarele funcții: adăugirea informației, inserarea inscrierelor, schimbarea inscrierelor și ștergerea.

Fig. 4.5. Forma de vizualizare a datelor referitoare la profesorilor titulari.

Această formă permite vizualizarea datelor care se refer la profesori titulari. În principiu ea este compusă din componentele TDBEdit și TDBLookupListBox. Prin forma dată nu se poate modifica informația. Scopul acestei forme este căutarea, selectarea datelor despre profesori și vizualizarea lor. Câmpul “Lista profesorilor” inițial conține toată lista numelor profesorilor ce sunt angajați în câmpul de muncă a instituțiilor de învățământ ce sunt supuse areditării. În câmpul Numele se introduce numele profesorului. Pe parcursul introducerii conținutul listei se schimbă. Dacă nu numele profesorului introdus nu este înregistrat în baza de date, atunci lista nu conține nici o înregistrare. În caz dacă există un nume asemănător cu cela introdus atunci lista se compune cu astfel de nume. Efectuăm un click pe numele dorit și se vizualizează celelalte datelor referitoare la acest profesor.

Fig. 4.6. Forma de vizualizare a datelor referitoare la profesori.

Această formă este asemănătoare cu forma precedentă. Ea permite vizualizarea datelor care se refer la profesori angajați prin cumul. Ea este compusă din componentele TDBEdit și TDBLookupListBox. Câmpul “Lista profesorilor” inițial conține toată lista numelor profesorilor ce sunt angajați prin cumul în câmpul de muncă a instituților de învățământ ce sunt supuse areditării. În câmpul Numele se introduce numele profesorului. Pe parcursul introducerii conținutul listei se schimbă. Dacă nu numele profesorului introdus nu este înregistrat în baza de date, atunci lista nu conține nici o înregistrare. În caz dacă există un nume asemănător cu cela introdus atunci lista se compune cu astfel de nume. Efectuăm un click pe numele dorit și se vizualizează restul datelor referitoare la acest profesor.

Fig. 4.7. Forma de selectare a profesorilor după specialitate.

Această formă este compusă din componentele TradioButton, TDBLookupComboBox și TDBLookupListBox. Această formă nu permite modificarea datelor ci numai vizualizarea lor. Destinația acestei forme este selectarea profesorilor (titulari sau prin cumul) din baza de date după specialitatea lor. Inițial lista conține toate numele de familie înregistrate în baza de date. Pe parcursul introducerii conținutul listei se schimbă. Dacă nu numele profesorului introdus nu este înregistrat în baza de date, atunci lista nu conține nici o înregistrare. Efectuăm un click dublu pe numele dorit și se vizualizează restul datelor referitoare la acest profesor.

procedure TPoisk.DBLookupComboBox1Click(Sender: TObject);

begin

if RadioButton1.Checked = TRUE then

begin

with Query1 do begin

Close;

SQL.Clear;

SQL.Add('SELECT *');

SQL.Add('FROM ProfTitulari ');

SQL.Add('WHERE Specialitate LIKE ''' + DBLookupComboBox1.Text +'%''');

ExecSQL

end;

Query1.Open;

end

else

begin

with Query1 do begin

Close;

SQL.Clear;

SQL.Add('SELECT *');

SQL.Add('FROM Cumul ');

SQL.Add('WHERE Specialitate LIKE ''' + DBLookupComboBox1.Text +'%''');

ExecSQL

end;

Query1.Open;

end;

În primul rând această procedură controlează pe care profesori să se selecteze programul, titulari sau angajați prin cumul. În cazul profesorilor titulari, selectarea efectuează următoare parte:

with Query1 do begin

Close;

SQL.Clear;

SQL.Add('SELECT *');

SQL.Add('FROM ProfTitulari ');

SQL.Add('WHERE Specialitate LIKE ''' + DBLookupComboBox1.Text +'%''');

ExecSQL

end;

În caz contrar selectarea efectuează partea a doua a procedurii. După aceasta se compune lista din selecțiile din baza de date. Toți profesorii (titulari sau prin cumul) vor fi afișați în listă.

Dacă efectuăm un click dublu pe un nume din listă, această formă va genera un raport referitor la profesorul selectat. Acest raport este prezentată în fig. 4.8.

Fig. 4.8. Raportul despre profesori.

Componentul principal al raportului TQuickRep. El însuși și este raportul adică foaia raportului. Restul componentelor așa ca TQRBand, TQRLabel, TQRDBText visual se depun pe componentul TQuickRep.

TQRBand este o bandă. Ea apare sau se tipărește numai o dată pe foaie. Acest component de obicei reprezintă titlul raportului.

TQRLabel este un text în raport sau el poate servi ca o denumire a unui câmp, adică un text static.

TQRDBText afișează o înscriere din tabel pe care se află cursorul. În cazul nostru se afișează datele referitoare la profesori.

Acest raport este un component standard a mediului Delphi. Are funcția de a scoate la tipar, de viziunea până la tipar în 3 variante. Pentru a scoate foaia la tipar această formă activează o formă standardă a sistemului operațional (Windows) a meniului imprimantei. Prin intermediul acestui meniu se configurează imprimanta, calitatea imaginei, foile care se vor tipări ș.a.

O altă formă, asemănătoare cu forma de selectare profesorilor prin specialitate, este o formă de selectare după instituția de învățământ. Ea este reprezentată în figura de mai jos.

Fig. 4.9. Forma de selectare a profesorilor după instituția de învățământ.

Această formă este compusă din componentele TradioButton, TDBLookupComboBox și TDBLookupListBox. Ea nu permite modificarea datelor

ci numai vizualizarea lor. Destinația acestei forme este selectarea profesorilor

(titulari sau prin cumul) din baza de date după locul lor de muncă, adică prin instituții de învățământ. Inițial lista conține toate numele de familie înregistrate în baza de date. Pe parcursul introducerii conținutul listei se schimbă. Dacă nu numele profesorului introdus nu este înregistrat în baza de date, atunci lista nu conține nici o înregistrare. Dacă se efectuează un click dublu pe numele de familie a profesorului atunci apare raportul descris de mai sus.

O altă formă de selectare este prezentată mai jos.

Fig. 4.10. Forma de selectare a profesorilor prin titlul lor științific.

Această formă este compusă din componentele TradioButton, TDBLookupComboBox și TDBLookupListBox. Această formă nu permite modificarea datelor ci numai vizualizarea lor. Destinația acestei forme este selectarea profesorilor (titulari sau prin cumul) din baza de date după titlul lor didactic. Această formă se folosește cînd este nevoia de a selecta profesorii prin

titlul lor didactic. Adică, dacă alegem în câmpul Tilul științific un grad, conținutul listei se va schimba. În lista va rămâne profesorii care au gradul științific indicat în câmpul de mai sus.

Inițial lista conține toate numele de familie înregistrate în baza de date. În câmpul Titlul didactic se află lista titlulelor științifice înregistrate în baza de date. Când se efectuează click dublu pe numele de familie se activează raportul descris de mai sus.

4.3. Componentele Delphi utilizate la elaborarea bazei de date

O bază de date este o colecție de date între care există anumite legături. Mediul Delphi folosește o definiție mult mai elaborată, care include anumite tipuri de date gestionate de către un server de baze de date și care se materializează într-un anumit tip de fișiere. Sistemele de administrare a bazelor de date (SGBD – Database Management System sau Sistemul de gestiune a Bazei de Date – SGBD) sunt ceva mai mult decât niște simple instrumente folosite în derularea afacerilor – ele au devenit chiar obiectul afacerilor.

Un sistem SGBD reprezintă o aplicație care gestionează toate datele unei companii, sau o bază de date adaptată uzului personal, care ține evidența corespondenței sau a altor categorii de informații. Acestea sunt percepții destul de înguste despre ceea ce este și ce poate face un sistem SGBD. Câteodată acestea sunt înglobate în cadrul altor aplicații. De exemplu, cele mai multe programe de calcul tabelar au funcții clare de administrare a bazelor de date. Mai există și alte domenii în care sistemele SGBD își găsesc locul.

Ceea ce ne interesează sunt sistemele SGBD care pun la dispoziție toate funcțiile ce intervin în manipularea bazelor de date: adăugarea, modificarea, ștergerea și vizualizarea tuturor datelor pe care ele le gestionează. Mediul Delphi furnizează capacități destul de complexe, specifice sistemelor SGBD, nu doar posibilitatea de a regăsi diverse informații într-un format simplu, ci și capacitatea de a manipula acele date și de a le vizualiza în diferite moduri. Se poate avea acces la orice – de la baze de date care se găsesc pe sisteme mainframe până la fișierul care conține nume și adrese, aflat pe hard-discul local, în măsura în care mediul Delphi pune la dispoziție driverul corespunzător, sau în măsura în care există un driver ODBC instalat undeva pe calculatorul. Am constatat că partea cea mai grea în crearea unei aplicații de baze de date în mediul Delphi este găsirea celei mai potrivite modalități de accesare a datelor de care avem nevoie.

4.3.1. Descrierea componentelor Delphi pentru accesul la date

Accesul la date este scopul fundamental pentru care se creează un sistem SGBD. Trebuie să avem la dispoziție o modalitate de acces la toate datele pe care vrem să le păstrăm. De asemenea, este importantă micșorarea volumului de date în scopul accesării lor mai facile. Pagina de componente pentru acces la date – Data Access – din cadrul paletei de componente este în majoritatea cazurilor suficientă. Baza de date trebuie să accepte metodele de conectivitate cu bazele de date deschise (ODBC), interfața de programare a aplicațiilor independente de tipul bazei de date (IDAPI) sau să asigure un tip de driver nativ al mediului Delphi.

Figura 4.11 prezintă grupul de componente pentru acces la date furnizate de către mediul Delphi. Aceste componente sunt suficiente pentru a accesa.

Fig. 4.11. Componentele Delphi pentru acces la date sunt destul de puține la număr, si ușor de folosit.

TDataSource

O sursă de date este locul în care se obține accesul la informațiile de care avem nevoie. În timp ce baza de date este locul unde sunt depozitate efectiv toate informațiile înrudite, iar un tabel conține un singur tip de informații, sursa de date ne pune efectiv la dispoziție. O sursă de date poate fi un tabel, o interogare, sau o procedură – tot ceea ce face parte dintr-o bază de date. Acesta este scopul existenței în mediul Delphi a componentului denumit sursă de date el este partea din mediul Delphi care vă permite să conversați cu sistemul SGBD.

TTable

Adeseori, noțiunea de tabel se confundă cu cea de bază de date. Un tabel este gruparea într-un anume fel a unor informații înrudite. Bazele de date conțin, de obicei, unul sau mai multe tabele – o bază de date este o colecție a tuturor informațiilor relative la un anumit set de date. în mod normal, tabelele conțin un set de date. De exemplu, puteți pune numele, adresele și numerele de telefon ale tuturor angajaților într-un singur tabel. Un alt tabel ar putea conține înregistrări individuale ale plăților către un anume angajat, adică suma de bani pe care a primit-o în fiecare zi de plată. Cele două tabele sunt puse în legătură prin numele angajatului, sau orice altă informație de identificare, dar nu conțin același tip de informație. Baza de date care conține aceste două tabele ar putea constitui statul de plată al companiei. Cu alte cuvinte, baza de date conține toate tabelele care au legătură cu statul de plată al companiei. întotdeauna mi-a plăcut să consider că o bază de date este o persoană căreia îi pun o întrebare, iar un tabel este subiectul întrebării.

TQuery

Dacă o bază de date reprezintă sursa de răspunsuri, iar tabelul conține răspunsul la o anumită întrebare, acest component este întrebarea însăși. Un component TQuery ne permite să interogăm baza de date sau orice altă sursă de date sub formularul unei întrebări precise și să primiți ca răspuns numai informațiile de care aveți nevoie. în trecut, lumea obișnuia să ia un tabel întreg sau chiar baza de date cu totul, atunci când avea nevoie numai de o anumită informație. Rețelele de calculatoare nu sunt concepute să funcționeze în condițiile unui asemenea trafic de date, în special atunci când câteva sute de utilizatori interoghează bazele de date. Utilizarea unei interogări reduce timpul necesar formulării răspunsului la întrebare și reduce traficul în rețea în același timp. Interogările în mediul Delphi apelează la SQL (Structured Query Language – limbaj de interogare structurat). SQL este o modalitate standard de conversație cu o sursă de date.

TStoredProc

DDE este o metodă de control de la distanță al executării anumitor sarcini – o metodă destul de primitivă de control, sub forma unui program macro. O bază de date poate fi rezidentă pe un sistem mainframe sau pe o altă sursă dificil de accesat. Procedurile stocate sunt programe macro de surse de date. Ele sunt stocate pe serverul de date – care poate fi un server de fișier, un sistem mainframe sau chiar propriul PC local – și folosesc limbajul nativ al aplicației server. Cele mai multe sisteme SGBD folosesc limbajul SQL pentru implementarea acestor proceduri. Așadar, la ce este bună o procedură stocată? Gândiți-vă la ea ca la o metodă perfecționată de interogare. Ele permit reducerea volumului de date, sau efectuarea anumitor calcule, înainte de a intra în posesia datelor. Unele dintre cele mai mari avantaje în folosirea procedurilor stocate sunt asemănătoare cu cele care derivă din folosirea procedurilor obișnuite în scrierea codului. De exemplu, ele vă ajută să eliminați posibilitatea de a scrie de două ori același cod și să impuneți anumite standarde de lucru în cadrul companiei. Ele reduc, de asemenea, volumul de muncă pe care trebuie să o depuneți, deoarece nu trebuie să faceți modificări decât într-un singur loc atunci când apare nevoia de a modifica o anumită interogare.

TDatabase

Database este componentul pe care Delphi îl folosește pentru a avea controlul asupra accesului la informații – el furnizează legătura funcțională dintre aplicația dumneavoastră și serverul de date cu care aceasta conversează. De exemplu, componentul TDatabase este responsabil de inițierea tranzacțiilor cum sunt expedierea sau recepționarea unor informații. De asemenea, el răspunde de probleme cum ar fi deschiderea unei sesiuni de lucru cu baza de date pentm acele sisteme SGBD care au și facilitatea de asigurare a securității accesului la date – lucru pe care majoritatea lor o fac. Nu este necesar să adăugați aplicației dumneavoastră un component TDatabase pentru a avea acces la date: mediul Delphi va crea un component virtual de acest tip dacă va avea nevoie. Cu toate acestea, adăugarea unui astfel de component va fumiza un nivel superior de flexibilitate aplicației.

TSession

Acest component supervizează tot ceea ce face aplicația în legătură cu bazele de date, și veți fi pe calea cea bună. Nu se poate crea în mod dinamic un component TSession – ea trebuie să existe încă din faza de proiectare a aplicației. Mediul Delphi creează în schimb în mod automat un component TSession, numit Session, pe care îl puteți accesa fără să fie nevoie să îl adăugați la aplicația dumneavoastră. Acest component furnizează accesul la proprietățile și metodele sesiunii de lucru cu bazele de date. De exemplu, proprietatea Databases a acestui component vă va furniza numele tuturor bazelor de date deschise de către aplicația curentă. Una din metodele pe care le veți găsi printre cele mai utile este cea denumită GetStoredProcNames, ea returnând o listă cu procedurile stocate, puse la dispoziție de serverul de baze de date. în general, veți constata că veți folosi componentul TSession ca pe un mijloc de control al percepției generale asupra sistemului SGBD și nu în legătură cu anumite baze de date, surse de date sau tabele. Destinația principală a componentului TSession este aceea de a gestiona mai multe sesiuni de lucru ale unei aplicații cu bazele de date. Cu alte cuvinte, teoretic puteți deschide sesiuni de lucru cu bazele de date folosind mai multe nume de cont sau puteți deschide mai multe sesiuni cu același nume de cont.

TBatchMove

Componentul TBatchMove își dovedește utilitatea în legătură cu mai multe sarcini. Ori de câte ori va trebui să mutați un bloc de date dintr-o locație într-alta, va trebui să vă gândiți la folosirea acestui component. El reduce semnificativ volumul de muncă pe care trebuie să-1 depuneți atunci când trebuie să actualizați baza de date principală a companiei, cu date provenind de la o filială, sau să luați inventarul echipamentelor din anul precedent pentru a verifica ce modificări s-au produs din acest punct de vedere în anul îh curs. Personal, consider că acest component este util și în calitate de rutină pentru un pseudo-import al datelor. Puteți astfel să vehiculați blocuri de date între două produse de baze de date diferite, pe care mediul Delphi le acceptă – și, totusi, Delphi acceptă destule prin intermediul ODBC și al driverelor sale native. Pe scurt, este vorba de exportul unor blocuri de date într-un anumit format și scrierea lor în alt format.

TUpdateSQL

Există situații când nu trebuie să faceți altceva decât să cititi anumite date într-un tabel, nepunându-se problema modificării lor. In mod normal, vom folosi o structură de date de tip read-only (protejată la scriere) pentru a reduce traficul prin rețea. Unei asemenea structuri de date i se rezervă o zonă tampon de memorie (buffer) pe mașina dumneavoastră locală. Totuși, dacă folosiți acest tabel în scopul regăsirii unor informații, n-ar fi bine să aveți la dispoziție cele mai recente date? Acesta este rolul componentului TUpdateSQL. El ne permite accesul la zona de memorie tampon pentru a actualiza structura de date read-only, precum și informațiile pe care le vedeți ca rezultat al acestei interogări actualizate.

TReport

El permite crearea unui raport tip ReportSmith din interiorul mediului Delphi pe baza fișierelor deschise în momentul rulării aplicației.

Toate componentele pot lucra cu baza de date fără ca acest lucru să fie mediat de un component de tip TDataSource. Componentele pentru accesul la date pot avea acces la date în mod direct. Componentele de tip Data Control sau QuickRpt trebuie întotdeauna conectate la o sursă de date.

Figura de mai jos vă înfățișează o perspectivă mai apropiată de realitate despre modul în care com-ponentele pentru acces la date conlucrează pentru crearea unei conexiuni între aplicația dum-neavoastră și serverul de baze de date. De asemenea, figura va arăta și modul în care această co-nexiune vă dă posibilitatea de a folosi componentele DataControl și QuickRpt, pe care le voi des-crie în următoarele două secțiuni ale acestui capitol. Atunci când scrieți aplicații, să nu uitați niciodată că este necesară o conectare a componentelor DataControl si QuickRpt la o sursă de date.

Fig. 4.12. Componentele Delphi ce conlucrează pentru a facilita aplicației accesul la bazele de date.

Figura 4.12 arată legătura dintre componentul TBatchMove și celelalte componente necesare pentru accesul la date. Pentru realizarea transferului (batch move) al unui bloc de date va trebui întotdeauna să aveți un component de tip TTable pe post de destinatar al acestui transfer. Cu toate acestea, pe post de sursă a transferului se pot folosi componente de tip TTable, TQuery sau TStoredProc. Validitatea acestor surse de date vă permite o flexibilitate deosebită în realizarea procedurilor de import sau export al blocurilor de date.

Fig. 4.13. Transferurile de blocuri de date se pot efectua din mai multe surse, dar numai către un singur tip de destinație – componente de tip TTable.

4.3.2. Descrierea componentelor Delphi pentru controlul datelor

Înainte de a începe munca de creare a unei aplicații, trebuie să știți care sunt tipurile de componente pe care mediul Delphi vi le pune la dispoziție. în acest caz, un component va pune la dispoziție o metodă pentru vizualizarea datelor, în alte cazuri metode pentru manipularea datelor continute într-un tabel. Toate aceste componente sunt elemente de control vizibile pe ecran. în secțiunea următoare vom studia componentele de tip QuickRpt folosite pentru tipărirea la imprimantă a datelor.

În figura 4.14 sunt prezentate componentele necesare controlului datelor din cadrul paletei de componente. Cred că veți constata că ele se comportă ca și corespondentele lor de uz general, având doar elemente specifice funcționalității sistemelor SGBD. De exemplu, componentul TDBEdit este un component standard de editare care este conectat la o bază de date. Vom folosi acest component pentru a crea formulare ajustate, conform anumitor necesități. Componentul TDBGrid vă permite să creați o metodă de afișare de tip Browse
într-o bază de date.

Figura 4.14 Există versiuni ale componentelor Delphi de uz general, specializate în lucrul cu sisteme SGBD.

TDBGrid

Acest component afișează pe ecran o grilă asemănătoare unei foi de calcul tabelar. îl puteți folosi pentru crearea unor metode de afișare asemănătoare unui browser într-o bază de date. Există două tipuri obișnuite de browsere. Primul este folosit pentru lucrul cu un singur tabel. în mod normal, vom folosi acest tip de afișare pentru căutarea datelor, apoi veți afișa un formular detaliat pentru a permite utilizatorului să vizualizeze toate datele simultan. Cel de-al doilea tip este folosit în contextul unor baze de date relaționale, de tipul „una la mai multe". Vom folosi componentul TDBGrid pentru a afișa înregistrările din bazele de date descendent, care sunt în relație cu înregistrarea curentă din cadrul bazei de date părinte.

TDBNavigator

Configurația standard conține 10 butoane, al căror număr îl puteți modifica pe baza diferitelor proprietăți ale obiectului. Destinația principală a acestui component este aceea de a vă permite mutarea de pe o anumită înregistrare pe următoarea. Trei dintre butoane – edit (editare), delete (ștergere) și insert (inserare) – vă permit modificarea înregistrărilor din tabel. Butonul Post face ca modificările operate astfel să devină permanente – cele mai multe sisteme SGBD folosesc termenul „commit" pentru a denumi acest tip de acțiune. în mod asemănător, butonul Cancel reface starea anterioară a unei înregistrări – cele mai multe sisteme SGBD folosesc noțiunea „roll-back" pentru a denumi acest tip de acțiune. În sfârșit, puteți folosi butonul Refresh pentru a actualiza conținutul, unui component atașat componentului TDBNavigator.

TDBText

Ori de câte ori doriți să creați un formular ajustat pentru a putea afișa o singură înregistrare la un moment dat, veți avea nevoie de unul sau mai multe astfel de componente. Pe scurt, ele realizează afișarea tuturor datelor de tip text pe care le conține un tabel. Utilizatorul nu poate edita (modifica) informațiile conținute de acest component. Avantajul utilizării acestui component este faptul că el își actualizează automat conținutul pe măsură ce vă mutați de la o înregistrare la alta. Un component de tip TDBText necesită alocarea unei cantități mai mari de memorie decât pentru un component TLabel. Dacă aveți nevoie să afișați zone simple de text care nu se modifică, atunci folosiți întotdeauna componente de tip TLabel. De exemplu, anteturile și etichetele datelor se vor implementa cu ajutorul componentelor TLabel și nu cu componente de tip TDBText.

TDBEdit

Componentele de tip TDBEdit vă permit afișarea informațiilor sub formă de text dintr-un tabel, dintr-o interogare sau o procedură stocată. Marea diferență este faptul că acest component este, de asemenea, „data-aware", adică își actualizează automat conținutul pe măsură ce vă mutați de la o înregistrare la alta în tabel.

Există situații în care va trebui să puneți la dispoziție un component de editare pentru date care nu se modifică, și care totuși să fie inserate în tabel. De exemplu, poate veți dori să introduceți data curentă într-unul dintre câmpurile tabelului. Această necesitate poate apărea în legătură cu o înregistrare dintr-un stat de plată, sau în legătură cu vreun alt câmp aflat într-o relație de tip „una-la-mai-multe". Utilizarea unui component de tip TEdit într-o asemenea situație va economisi memorie, în condițiile în care, în cele mai multe cazuri, integritatea bazei de date nu va fi compromisă.

TDBMemo

Ca și celelalte componente de editare prezentate până acum, și componentul TDBMemo este dependent de date (data-aware). în aproape toate privințele, componentul TDBMemo se comportă la fel ca și componentul TMemo. Iată însă o facilitate interesantă, care îi este specifică. Această facilitate pune la dispoziție proprietatea AutoDisplay care – prin valoarea sa – hotărăște dacă mediul Delphi va afișa automat toate obiectele binare pe care componentul TDBMemo le-ar putea conține. Puteți atribui acestei proprietăți valoarea False pentru a reduce valoarea traficului prin rețea, și valoarea frecvenței de actualizare a imaginii de pe monitor, pentru utilizatorii aplicației dumneavoastră. Metoda LoadMemo vă permite să actualizați manual conținutul componentului TDBMemo. Tot ceea ce aveți de făcut este să asociați această metodă cu acțiunea unui buton Update din cadrul formularului.

Componentul TDBMemo pune la dispoziție unele facilități, altele decât facilitatea dependență de date (data-aware), care îl pot face interesant în unele situații. Cu toate acestea, el consumă mai multă memorie atât față de componentul TMemo cât și față de componentul TRichEdit. Cel mai eficient din punctul de vedere al economiei de memorie este componentul TMemo, urmat de TDBMemo componentul TRichEdit. Singura situație care ar trebui să vă determine să folosiți componente de tip TDBMemo este aceea în care aveți nevoie de facilitatea data-aware sau de facilitatea de manipulare a obiectelor binare.

TDBImage

Pentru ca să afișați o imagine dintr-un tabel, folosiți acest component. Capacitățile de manipulare a obiectelor binare de către componentul TDBImage face posibilă manipularea ceva mai mult decât a unor simple imagini grafice. De exemplu, mediul Delphi va manipula obiecte OLE grafice înglobate într-un câmp de tip BLOB al unei baze de date.

Deși un component TDBImage nu consumă prea multe resurse sistem în plus față de un component TImage, el consumă totuși destule. Având acest lucru în vedere, probabil că veți opta pentru folosirea componentelor de tip TImage ori de câte ori este posibil. De exemplu, puteți folosi componentul TImage pentru a afișa sigla companiei. Îl puteți folosi, de asemenea, pe timpul introducerii datelor în combinație cu o listă. Utilizatorul va selecta imaginea dorită alegând-o dintr-o listă. în acest caz, componentul TImage va arăta imaginea pe măsură ce utilizatorul parcurge elementele listei.

TDBListBox

Folosesc deseori acest component pentru a afișa informații semi-statice pentru utilizatori. De exemplu, îl voi folosi pentru a afișa o listă a instituților,
dintr-o evidență a corespondenței gestionată de un sistem SGBD. Avantajele stocării corespondenței sub forma unor intrări în cadrul unui tabel reduce în raod real cerințele de resurse necesare pentru stocarea anumitor tipuri de date. De exemplu, puteți stoca informația despre statul în care se află destinatarul într-un singur octet, în loc de două. Dacă aveți nevoie să adăugați la listă un alt stat, o altă țară sau vreun alt tip de informație semi-statică, nu trebuie decât să modificați, o singură dată, tabelul care conține datele. Utilizatorul va remarca imediat noua înregistrare, la următoarea rulare a aplicației.

Un alt exemplu, dacă ați stocat o listă cu date în cadrul aplicației dumneavoastră și ați folosit un component standard TListBox pentru a-1 afișa, va trebui să actualizați aplicația ori de câte ori va trebui să adăugați un nou element la lista respectivă. Folosirea fișierelor de configurare pentru rezolvarea acestei probleme nu este o metodă prea elegantă. Mai mult, utilizând fișierele de configurare lăsați conținutul listei la bunul plac al utilizatorului, iar probabilitatea că el să șteargă din greșeală fișierele de configurare este destul de mare.

Un alt motiv care vine în sprijinul alegerii acestei soluții este viteza de actualizare. Ce s-ar întâmpla dacă ați fi afișat deja un anumit tip de informație semi-statică într-un anumit fel, iar șeful dumneavoastră v-ar fi spus să-1 schimbați? în mod normal, ar trebui să verificați dacă ați modificat modul de afișare a fiecărui element din listă, pe lângă modificările necesare pentru a actualiza procedurile și aplicația, în așa fel încât schimbările să se reflecte în realitate. Folosind o combinație formată dintr-un tabel și un component TDBListBox veți putea să faceți o singură schimbare în baza de date fiecare element din listă are ca fundamentare baza de date, astfel că actualizarea se face imediat.

TComboBox

Acest component lucrează la fel ca și corespondentul său, componentul TComboBox. El permite utilizatorului fie să selecteze o valoare dintre cele conținute într-o listă predefinită, fie să scrie o nouă valoare într-o casetă de editare. Diferența principală dintre aceste două componente este aceea că TDBComboBox are proprietatea „data-aware".

Dacă doriți să limitați gama de valori din care utilizatorul poate face o selecție, veți folosi un component TDBListBox. Pe de altă parte, dacă doriți să permiteți utilizatorilor să adauge noi valori, atunci un component de tip TComboBox este mult mai eficient din punctul de vedere al economiei de memorie. Vă recomand să folosiți acest component numai dacă doriți să permiteți utilizatorului modificarea conținutului unui tabel de căutare în baza de date. Desigur că acest lucru va fi limitat la stadiul unui formular cu rol de administrator, în cele mai multe cazuri.

TDBCheckBox

Folosim această metodă în relație cu valorile de tip boolean, pe care aveți nevoie să le stocați în baza de date. în situația în care caseta de validare este marcată, câmpul respectiv capătă valoarea True. Acest component oferă aceleași capacități ca și componentul TCheckBox. Marea diferență este aceea că posedă facilitatea „data-aware".

TDBRadioGroup

Acest component reprezintă o altă modalitate de implementare a unei liste scurte de elemente, cum ar fi lista de categorii de informații, despre care am vorbit mai devreme. Desigur că va trebui să limitați destul de mult numărul de valori dintre care să se poată face alegerea – ceea ce limitează destul de mult utilitatea acestui component.

În mod normal, bazele de date stochează cantități mari de informații – nu doar cinci sau șase valori. Este adevărat că ați putea folosi un tabel pentru a stoca ceva de genul unei liste scurte de categorii, cel puțin pentru motivul unei actualizări ulterioare foarte facile. Cu toate acestea, dacă lista este într-adevăr scurtă și conținutul său este foarte stabil, în așa fel încât soluția reprezentată de un grup de butoane radio să fie viabilă, atunci probabil că va trebui să optați pentru componentul TRadioGroup standard și veți stoca astfel lista local. Desigur că există un număr mare de excepții de la această regulă și multe dintre acestea au fost menționate deja atunci când am făcut referire la componentul TDBListBox, în cadrul acestui tabel.

TDBLookUpListBox

Utilizarea unei tabele de căutare în cadrul aplicației dumneavoastră necesita mai demult scrierea unui anumit volum de cod. Nu mai este cazul, acum. Acest component vă permite adăugarea unui tabel de căutare la aplicația dumneavoastră, fără să faceți nimic altceva în plus decât să definiți câteva proprietăți simple. Conținutul listei este definit de către proprietățile ListField și ListSource. Câmpul bazei principale de date care este afectat este definit de către proprietățile DataSource și DataField. Tabela principală și tabela de căutare sunt menținute permanent în concordanță folosind proprietatea KeyField.

TDBLookUpComboBox

Componentul TDBLookUpComboBox lucrează exact în același fel ca și corespondentul său, componentul TDBLookUpListBox. Vom folosi aceleași câmpuri pentru a crea o legătură între un tabel principal și un tabel de căutare. Singura diferență este aceea că acest component la care ne referim pune la dispoziție o listă derulantă.

TDBCtrlGrid

Componentul TDBCtrlGrid vă va permite să faceți acest lucru. El afișează o combinație între un formular personalizat și o vizualizare de tip browse, în același timp. Noi definim un mod de afișare, apoi Delphi face o replică a acestei afișări, după cum este nevoie. Componentul are chiar și două proprietăți — rând și coloană astfel încât puteți afișa etichetele în același format în care apar pe hârtie. Desigur, nu este singura modalitate de utilizare a acestui component (îl puteți folosi pentru a realiza un browser personalizat, sau orice alte aplicații), dar ceea ce v-am spus a fost primul lucru care mi-a venit în minte atunci când am văzut acest component, pentru prima dată.

Toate aceste componente necesită precizarea de valori pentru două proprietăți, înainte de a putea afișa orice fel de informații numele sursei și numele câmpului. Sursa este reprezentată de numele componentului DataSource, despre care am discutat în secțiunea precedentă, iar câmpul este cel din tabelul selectat, care conține date.

Unele dintre componentele descrise în tabelul de mai sus, ca și cele care vor fi prezentate în secțiunea următoare (QuickRpt) pot folosi mai multe tipuri de câmpuri. Versiunea pe 32 de biți a mediului Delphi pune la dispoziție trei asemenea tipuri Data, Calculated și Lookup. Câmpul de tip Data este un câmp care există în mod normal în tabel. Un astfel de câmp nu trebuie decât să fie citit. Un câmp de tipul Calculated are o valoare derivată din valoarea unui câmp existent. El necesită din partea dumneavoastră fumizarea unei definiții de ecuație sau de funcție.

Câmpul de tip Lookup este unul din elementele de finețe adăugate mediului Delphi. Până acum obișnuiați să scrieți un cod oarecare pentru a crea o legătură între un tabel de căutare și tabelul cu date. De exemplu, trebuia să creați un fel de relație între un tabel care conținea numele statelor, și tabelul care conținea în mod real acele state sub formă de date. Mediul Delphi schimbă situația permițându-vă să definiți un câmp de căutare în interiorul unor anumite tipuri de componente, câmp pentru care nu este nevoie de scrierea nici unui fel de cod.

Orice component care folosește editorul de câmpuri poate folosi, de asemenea, aceste trei tipuri de câmpuri, deoarece ele reprezintă o problemă de standardizare. Borland pune la dispoziție, de asemenea, multe alte extensii în legătură cu editorul de câmpuri, pe care le vom studia în cadrul numeroaselor exemple din acest capitol.

4.3.3. Descrierea componentelor Delphi din pagina QuickRpt

Componentele din pagina QuickRpt sunt elemente de noutate aduse încă de versiunea Delphi 2.0. Acest set de componente reprezintă punctul care marchează jumătatea drumului ce începe cu scrierea manuală a unui cod necesar pentru implementarea unei rutine de tipărire la imprimantă și se termină cu folosirea unei aplicații externe mediului Delphi, cum este ReportSmith, pentru rezolvarea acestei sarcini. Desigur că aplicația ReportSmith va pune la dispoziție mai multe instrumente decât cele pe care le găsiți pe lista de componente QuickRpt, însă pentru a le folosi trebuie să duceți după dumneavoastră o mulțime de alte elemente suplimentare. Pe de altă parte, din perspectiva utilizatorului, apelarea unei rutine externe pentru realizarea unei sarcini de tipărire nu este o metodă prea elegantă, dar care până la urmă rezolvă problema.

Înainte de a trece mai departe, haideți să aruncăm o privire asupra componentelor din pagina QuickRpt și să vedem ce pot face ele pentru dumneavoastră. Figura 4.15 vă arată aceste componente din pagina QuickRpt a paletei de componente. Ca și componentele din pagina Data Control veți constata că și acestea funcționează în mod similar cu corespondentele lor de uz general, cu particularitatea dată însă de sarcina specială de tipărire, pe care trebuie să o îndeplinească. De exemplu, componentul TQRLabel este o etichetă standard folosită pentru redirecționarea datelor către imprimantă. Veți folosi acest component pentru afișarea în cadrul unui raport a informației text care nu se modifică, cum ar fi informația referitoare la data calendaristică sau la tipul raportului. Unele dintre aceste componente sunt chiar niște extensii ale componentelor din pagina Data Control. De exemplu, varianta tipărită la imprimantă a componentului TDBText este un component TQRDBText. Ele fac același lucru, dar în medii diferite. Pe de altă parte, componentul TQRPreview este conceput strict în relație cu sarcina de tipărire la imprimantă – nu îl veți folosi în cadrul unui formular pentru nimic altceva.

Fig. 4.15 Componentele QuickRpt reprezintă noutatea adusă de versiunea Delphi 5.0.

TQuickReport

Acesta este componentul esențial pentru generarea rapidă a unui raport. El îndeplinește sarcinile privind datele și tipărirea la imprimantă. Pentru a folosi acest component, includeți-1 într-un formular și atribuiți proprietății sale DataSource valoarea reprezentată de numele componentului TTable sau TQuery, care conține datele pe care doriți să le tipăriți la imprimantă. Pentru a formata într-un anumit fel documentul tipărit, adăugați formularului componente cum sunt TQRBand și TQRDBText. Cele două metode principale pe care le veți folosi cu acest component sunt Preview și Print. Pentru a-1 folosi pe primul va trebui să adăugați formularului dumneavoastră un component TQRPreview. Modul de afișare Preview pune la dispoziție și posibilitatea de a declanșa operațiunea de tipărire, îndată ce utilizatorul a văzut cum va arăta documentul.

TQRBand

În esență, o „bandă" este un tip de date singular în cadrul unui raport. Corel Draw folosește această abordare atunci când tipărește la imprimantă diferite niveluri sau zone care țin de fișierul în format grafic curent. Prin schimbarea valorii asociate proprietății BandType, aveți posibilitatea de a modifica tipul benzii. Există o diversitate de tipuri de benzi, care conțin titlul, conținutul propriu-zis, grupuri, note de subsol și anteturi. Ceea ce face, de fapt, componentul TQRBand nu este altceva decât separarea datelor cuprinse în documentul de tipărit, în diferite porțiuni utilizabile.

TQRGroup

TQRGroup este un tip special de component de afișare. El nu afișează direct datele așa cum face un component de editare, ci pune datele la dispoziția raportului ori de câte ori sunt solicitate informații specifice grupului. Pentru a utiliza acest component trebuie să definiți o sursă de date și un câmp de date, la fel cum procedați și în cazul altor componente al căror rol este de a afișa datele. O modificare a valorii câmpului de date semnalează sfârșitul grupului. îndată ce ați definit aceste două proprietăți, va trebui să comunicați mediului Delphi unde să plaseze informația de grup. Aici este locul în care intră în scenă proprietățile HeaderBand și FooterBand acestea precizează mediului Delphi unde să plaseze informația pe care ați furnizat-o. în mod normal, pentru a produce un raport master detaliat, veți cupla un component TQRGroup cu un component TQuery. Rațiunea principală de folosire a componentului TQRGroup este justificată atunci când aveți nevoie să creați rapoarte care conțin mai mult de două niveluri de informații grupate. Dacă aveți nevoie de detalii organizate pe mai multe niveluri de informație, atunci componentul cel mai indicat spre a fi folosit este TQRDetailLink.

TQRDetailLink

Vom folosi acest component pentru a crea rapoarte master/detail pe baza mai multor tabele cu date situate pe același nivel. Aceasta este cea de-a doua metodă prin care se pot realiza rapoarte master/detail (prima metodă este cea reprezentată de componentul TQRGroup). Acest component funcționează prin cuplarea unui component TQRDetailLink cu o bandă a unui grup care conține informații de detaliu. Veți specifica numele tabelului principal pe post de sursă de date pentru componentul TQRDetailLink. Raportul va tipări la imprimantă un grup de informații pentru fiecare înregistrare conținută în tabelul principal.

TQRLabel

Acest component este un component standard de tip Label, dar care este proiectat pentru direcționarea informațiilor către imprimantă, și nu către ecran (cu toate acestea, în faza de proiectare a aplicației puteți vedea conținutul componentului). El vă permite să afișați capetele de coloane și alte date care nu se modifică. Dacă doriți să afișați datele dintr-un tabel, atunci va trebui să folosiți componentul TQRText.

TQRMemo

Acesta este un component standard de tip Memo, dar care este proiectat pentru direcționarea informațiilor către imprimantă. în legătură cu folosirea lui trebuie spus că, spre deosebire de afișarea informației pe monitor, informația destinată a fi tipărită la imprimantă nu poate folosi componentele de tip bară de derulare. înseamnă că un text care poate fi afișat integral pe ecran de către componentul TQRMemo nu va putea apărea și în raportul tipărit. Deoarece acest component ia întotdeauna în calcul același necesar de spațiu de memorie – chiar dacă informația text conținută în câmpul Memo nu este suficientă pentru a-l ocupa – atunci va trebui să determinați mărimea componentului însuși, în conformitate cu cantitatea de date pe care doriți să o tipăriți la imprimantă. Desigur, această metodă nu este cea mai potrivită pentru afișarea unui text, dar are meritul că funcționează. Spre deosebire de alte componente care funcționează în relație cu bazele de date, nu veți completa cu date conținutul unui component Memo prin specificarea unei surse de date și a unui câmp de date. Acest component folosește proprietatea TStrings pentru a determina tipul datelor pe care le va afișa. Desigur, acest component nu este unul de tip „data-aware", astfel că va trebui să aveți grijă atunci când îl utilizați.

TQRDBText

Componentul TQRDBText este probabil componentul pe care îl veți folosi cel mai des pentru afișarea datelor. Modul său de funcționare este similar cu cel al componentului TDBText, cu deosebirea că trimite datele către imprimantă și nu către ecran. Folosind proprietățile DataSource și DataField puteți specifica datele pe care componentul le va tipări la imprimantă.

TQRDBCalc

În majoritatea cazurilor, veți întâlni acest component în cadrul grupurilor și notelor de subsol. El vă permite fie să afișați suma valorilor existente într-un anumit câmp, fie să numărați câte înregistrări snnt într-o zonă care conține detalii. De exemplu, să presupunem situația în care doriți să tipăriți la imprimantă un raport care să cuprindă cheltuielile de deplasare ale personalului companiei, pe regiuni. Ați putea să tipăriți cheltuielile de deplasare pentru fiecare angajat în parte și apoi să adăugați acest component (TQRDBCalc) la fiecare grup, pentru a afișa totalul cheltuielilor fiecărui grup. Ca și în cazul altor componente de tip „data-aware", proprietățile DataSource și DataField spun componentului TQRDBCalc ce să calculeze. Proprietatea ResetGroup spune componentului când să-și reinițializeze contorul.

TQRSysData

Consider că acest component este foarte util prin faptul că folosind un singur component am posibilitatea de a afișa data sau ora curentă, titlul raportului sau numărul paginii, sau mulți alți parametri ai sistemului. Pentru mine, un interes special 1-a prezentat proprietatea prin care se pot contoriza detaliile. Am putut folosi această proprietate pentru a plasa un număr în dreapta sau în stânga fiecărei linii care conține detalii. Singura proprietate căreia trebuie să-i acordați atenție atunci când folosiți acest component este proprietatea Data, care definește tipul datelor pe care doriți să le vedeți (tipăriți).

TQRShape

În trecut, rapoartele de afaceri nu făceau apel la vreun fel de grafice, pentru a spori claritatea textului. Acum, situația s-a schimbat. Prezentările au încetat să mai fie prelegeri plictisitoare, pline de tabele care nu se mai termină, conținând informații statistice, în prezent, o persoană care se pricepe la prezentări folosește grafice (uneori și elemente multimedia, dacă este necesar) pentru a da prezentării sale o înfățișare cât mai atrăgătoare. Componentele Delphi din categoria QuickRpt nu vă oferă posibilitatea de a face schimbări revoluționare în ceea ce privește aspectul raportului dumneavoastră, din acest punct de vedere, dar componentul TQRShape – folosit cu pricepere – vă va da posibilitatea de a adăuga „sare și piper" la prezentarea dumneavoastră. Acest component plasează o figură geometrică – un pătrat sau un cerc – în interiorul raportului. Puteți folosi aceste figuri geometrice pentru a defini anumite tipuri de date. De exemplu, puteți folosi cercuri evidențiate printr-un efect de umbră pentru a defini anumite informații statistice, și patrulatere evidențiate la fel, pentru a defini alt tip de informații statistice. Nivelul de umbrire a fiecărui tip de informații poate fi sugestiv pentru importanța datelor respective. De exemplu, ați putea, de asemenea, să folosiți un patrulater de culoare închisă pentru a evidenția în cadrul raportului o linie care dă o informație despre o creștere foarte mare a vânzărilor, și un patrulater gol pentru a pune în evidență ceva care se situează în zona de inferioritate. Puteți folosi, de asemenea, aceste primitive grafice pentru a crea grafice simple reprezentate prin bare sau prin sectoare de cerc. Păstrați constantă lățimea unor patrulatere, dar modificați-le înălțimea și astfel veți obține un grafic reprezentat prin bare. Parametrul Brush vă permite să selectați și stilul de umplere (hașură diagonală, în cruce, orizontală și așa mai departe).

TQRPreview

Personal, consider că acest component este poate partea cea mai elaborată a unui raport. El vă permite afișarea pe ecran a raportului curent. Utilizatorul se poate deplasa pagină cu pagină în cadrul raportului, sau îl poate direcționa spre tipărire la imprimantă. Există chiar și un factor de scalare astfel că se poate face o mărire a unei anumite porțiuni selectate dintr-un raport. Vom vedea imediat cum lucrează acest component.

Acum, după ce ați avut ocazia de a trece în revistă componentele QuickRpt, v-ați putea întreba ce vă poate determina vreodată să le folosiți. Unele dintre acestea, cum ar fi TQRShape, nu par a fi în măsură să stârnească interesul cuiva. Pe de altă parte, componentul TQRPreview cred că este bine gândit, bine realizat și foarte util, chiar și fără un cod suplementar atașat lui. (Chiar mă întreb dacă nu cumva programatorii se vor plânge de faptul că tipul Quick Reports de componente face o parte prea mare din munca pe care ar trebui să o facă ei.) Iată un motiv important care poate justifica opțiunea pentru crearea rapoartelor cu ajutorul componentelor interne Delphi (componente de tip QuickRpt) și nu opțiunea reprezentată de apelul la serviciile unei aplicații externe (de exemplu ReportSmith). Motivul îl constituie faptul că atunci când terminați lucrul la aplicație, obțineți un pachet integrat. Nu este necesar să aveți în execuție vreo versiune a unei alte aplicații pe care ar trebui să o distribuiți clientului dumneavoastră. Toate lucrurile de care are nevoie clientul există în aplicația dumneavoastră.

Există și un al doilea motiv interesant pentru dumneavoastră ca programator. Pentru a crea rapoarte personalizate este nevoie de prea mult timp, iar pentru a putea face cât de cât ceva util folosind aplicația ReportSmith este necesar să învățați limbajul BASIC. Este clar că veți economisi timp folosind rapoartele rapide (care se obțin folosind elementele QuickRpt), în ciuda limitărilor pe care le au în prezent, pentru aproape orice fel de rapoarte, mai puțin pentru realizarea celor complexe.

Nu aș fi deloc surprins dacă, în următoarea versiune a mediului Delphi, Borland va face din QuickRpt categoria principală de componente pentru crearea rapoartelor. Această categorie pune la dispoziție facilitatea pe care aș fi dorit să o conțină prima versiune o cale rapidă de creare a unui raport fără să fie nevoie să înveți un noul limbaj de programare. Se economisește mult timp prin folosirea componentelor QuickRpt în locul aplicației externe ReportSmith.

5. Protecția muncii și mediului ambiant

Proiectul de diplomă prezintă elaborarea unui set de programe pentru culegerea și prelucrarea informației. Rezultă problema protecției muncii atât a persoanelor care elaborează programele, cât și a utilizatorilor ei. Lucrările în sistemul menționat vor fi efectuate utilizând calculatoare personale, adică prezintă lucrul programatorilor și a operatorilor tehnicii de calcul, e necesar de a precauta cerințele pentru protecția muncii la lucrul cu tehnica de calcul, în special a calculatoarelor personale cu diferite sisteme periferice.

Sub noțiunea de protecție a muncii înțelegem un sistem de acte legislative, social-economice, tehnice, igienice și măsuri curativo-profilactice, care asigură securitatea, sănătatea oamenilor în procesul de producție. Asigurarea protecției muncii se realizează cât la proiectarea proceselor de producție, atât și la procesul de realizare a lor. Direcția tranșantă de îmbunătățire a condițiilor de muncă este trecerea la noi tehnologii avansate cu un înalt grad de protecție a muncii. Este necesară crearea unei sisteme „om – mediu de protecție” echilibrată în care caracteristicile cantitative a factorilor de protecție să nu se abată de la nivelul normat și să corespundă caracteristicilor omului.

5.1. Analiza condițiilor de muncă în sala de calculatoare

Sălile de calculatoare, și dimensiunile lor ( aria, volumul ) trebuie în primul rând să corespundă numărului și plasării în ele a mijloacelor de calcul (calculatoare). În ele se disting parametrii corespunzători ai temperaturii, iluminării, aerului curat, se asigură izolarea de zgomote industriale etc.

Pentru asigurarea condițiilor de muncă normale normele sanitare СН 245- 71 se atribuie unui lucrător, volumul sălii de calculatoare nu mai mic de 15 m3 aria încăperii îngrădită cu pereți și despărțituri izolate trebuie să fie nu mai mic de 4,5 m2. De asemenea sălile de calculatoare se asigură cu ventilație de schimb comun și iluminare artificială.

Aria sălii de calculatoare trebuie să corespundă ariei, necesare după condițiile tehnice a tipului de calculator dat. Înălțimea sălii de-asupra podelei tehnologice până la podul suspendat trebuie să fie 3 – 3,5 m. Distanța dintre podul de bază și cel suspendat trebuie să fie de 0,5 – 0,8 m. Spațiul dintre aceste poduri în sala de calculatoare se folosește în calitate de canal de ventilație pentru includerea eliminatoarelor, rețelei antiincendiare și dispozitivelor de iluminare. Gabaritele ușii a sălii de calculatoare se admit nu mai mici de 1,81,1 m, din calculele posibilității transportării dispozitivelor (calculatoarelor). Sălilor de calculatoare mari li se asigură și spații pentru păstrarea purtătorilor de informație magnetice. În așa caz aceste spații (săli) se admit de a fi nu mai mici de 16 m2. Podeaua, podul și pereții acestor spații de păstrare se acoperă cu un material antiincendiar, ușile acestor spații de păstrare trebuie să fie metalice sau din lemn, dar acoperite cu tablă de fier. Rama suspendării ușii de-asemenea trebuie să fie îmbrăcată cu tablă de fier. Sălile de păstrare a purtătorilor de informație trebuie situate la distanță față de câmpurile magnetice și electrice mari și ecranate de influența lor. De-asemenea sălile adăugătoare prevăzute pentru sălile de calculatoare se situează de obicei la etajele inferioare și înălțimea lor trebuie să fie de 3,3 m. Sala de calculatoare trebuie să conțină iluminare naturală. În celelalte săli adăugătoare se admite iluminare artificială.

O formare coloristică rațională a sălilor este îndreptată la îmbunătățirea condițiilor igieno-sanitare, majorarea productivității și securității. Coloritul sălilor de calculatoare influențează asupra sistemului nervos al omului dispoziției și în ultimul rând la productivitatea munci. De aceea este atât de necesar alegerea coloritului sălilor de calculatoare. Sălile de calculatoare astfel este comod de colorat în colori în corespundere cu coloarea mijloacelor tehnice (calculatoarelor). Alegerea culorii se determină de un șir de factori în același rând și de construcția clădirii, caracterului lucrului îndeplinit, iluminare, numărului de lucrători. Este necesar de luat în considerație, că culoarea este un stimulator psihologic înalt: culoarea roșie – mărește tensiunea musculară; portocaliu – stimulează activitatea; galben – stimulează sistema nervoasă și vederea; verde – calmează; albastru – micșorează tensiunea musculară; violet – creează o percepere de calmare. Perceperea culorii în mare măsură depinde de iluminare. Sub influența diferitor sursei de lumină culoarea de suprafață își schimbă tonul.

Coeficientul de reflexie a luminii față de materiale și instalații în interiorul sălii de calculatoare are o mare însemnătate pentru iluminare: cît mai multă lumină se reflectă de la suprafață cu atât este mai mare iluminarea sălilor de calculatoare trebuie să fie moale, fără luciu, coloritul interiorului sălilor de calculatoare trebuie să fie calmantă pentru perceperea vizuală.

Este necesar de avut în vedere, că culorile oranj și galben mai ales în combinare cu negru se folosește pentru avertizarea de pericol. În coloarea roșie se colorează mijloacele antiincendiare, în verde – mijloacele și locurile de securitate și odihnă. Aceste culori și combinările lor nu se recomandă de a folosi în scopuri decorative.

O mare importanță o are colorarea corectă a sălilor adăugătoare, lipsite de iluminarea naturală și legăturii vizuale cu mediul exterior. Alegerea corectă a culorii compensează acest neajuns. Colorarea aprinsă înviorează spațiul și îmbunătățește starea psihologică a lucrătorilor.

Proiectul de diplomă prezintă elaborarea unui set de programe pentru culegerea și prelucrarea informației. Rezultă problema protecției muncii atât a persoanelor care elaborează programele, cât și a utilizatorilor ei. Lucrările în sistemul menționat vor fi efectuate utilizând calculatoare personale, adică prezintă lucrul programatorilor și a operatorilor tehnicii de calcul, e necesar de a precauta cerințele pentru protecția muncii la lucrul cu tehnica de calcul, în special a calculatoarelor personale cu diferite sisteme periferice, utilizate de către personalul centrului de calcul (CC) în procesul activității vitale. Evident, integrarea și utilizarea pe larg a calculatoarelor electronice pe lângă factorii pozitivi mai are și nuanțe negative asupra persoanelor care le exploatează.

Lucrul operatorilor tehnicii de calcul necesită o atenție mare, posibilitatea de a rezolva în timp limitat probleme complexe, responsabilitatea față de acțiunile întreprinse ce duce la o tensionare emoțională și stres.

Operatorii tehnicii de calcul, programatorii, și alți colaboratori ai CC sunt supuși unor factori nocivi și periculoși cum ar fi:

• nivelul ridicat de zgomot;

• temperatura ridicată a mediului ambiant;

• insuficiența iluminatului locurilor de muncă;

• insuficiența iluminatului natural;

• diferite forme de iradieri, etc.

Acțiunea factorilor indicați duce la micșorarea capacității de muncă, ca rezultat al obosirii. Apariția și dezvoltarea obosirii este legată de schimbările, ce apar în procesul muncii în sistemul nervos central, cu procese de încetinire în creier. De exemplu, zgomotul mare conduce la dificultăți în perceperea semnalelor colore, micșorează viteza de percepție a culorilor, adaptarea vizuală, micșorează capacitatea de a acționa rapid și efectiv, micșorează cu 5-12% capacitatea de muncă și duce la deteriorarea auzului.

Aflarea îndelungată a persoanei într-un mediu în care acționează mai mulți factori nocivi poate duce la o îmbolnăvire profesională.

Pentru crearea condițiilor de lucru prielnice e necesar de a lua în considerare particularitățile psiho-fiziologice ale oamenilor, plus starea igienică generală. Un rol important îl are amplasarea postului de lucru, economia energiei electrice și timpului operatorului, utilizarea rațională a suprafețelor utilizate, comodității utilizării tehnicii de calcul, respectarea regulilor de protecție a muncii.

5.2. Factorii nocivi ce acționează asupra operatorului

Zgomotul este unul din factori care influențează omul când el lucrează cu CE, aceasta este condiționat de funcționarea dispozitivelor ce sunt necesare în CC.

Zgomotul la locurile de muncă în sala de calculatoare se creează de sursele interioare: mijloacele tehnice (calculatorul),dispozitivele de condiționare a aerului, compresoare, pompe, convertoarele de tensiune și alte dispozitive și de-asemenea de zgomotele ce pătrund din afara sălii de calculatoare. Pentru micșorarea zgomotului creat sursele interioare și de-asemenea de zgomotul ce pătrunde din afară este necesar:

de a slăbi zgomotul surselor, adică de a folosi în construcția lor a ecranelor acustice și conservatorilor de izolare a sunetului;

de a micșora efectul influențării sumare asupra locurilor de muncă a undelor electromagnetice de frecvență joasă;

de a poziționa rațional mijloacele tehnice (calculatoarele);

de a folosi rezolvări tehnologice și arhitectoriale îndreptate pentru izolarea surselor de zgomot.

Sursele principale de zgomot în încăperi amenajate cu tehnica de calcul sunt imprimantele, tastatura, instalații pentru condiționarea aerului, dar în CE – ventilatoarele sistemelor de refrigerare și transformatoare.

La influența zgomotului pe un timp îndelungat la colaboratorii CC se observă micșorarea atenției, dureri de cap, se micșorează capacitatea de muncă. In documente de însoțire a utilajului ce produc zgomot se aduc normele timpului de lucru la acest utilaj.

În conformitate cu GOST 12.1.003-91 "Zgomot. Cerințele generale de protecție" caracteristica de normă a zgomotului locurilor de muncă sunt nivelurile presiunii de sonor (zgomot). Nivelurile accesibile a zgomotului, lucrând cu CE, sunt prezentate în tabelul 5.1:

Tab. 5.1.

Nivelurile admisibile a zgomotului

Pentru micșorarea zgomotului la locurile de muncă se efectuează următoarele acțiuni:

Arhitectural-planificative. Clădirile se proiectează și se construiesc în așa mod, ca la locurile de muncă să nu fie depășit nivelului admisibil. Întrucât sistemul va fi utilizat la CC existent aici se poate de obținut micșorarea zgomotului amplasând în încăperi vecine utilajului cu zgomot ridicat.

Tehnico-organizatorice. Pentru micșorarea zgomotului la CC se efectuează reparația și ungerea utilajului (imprimantelor). Se poate de aranjat utilajul în așa fel ca el să facă mai puțin zgomot.

Acustice. În CC se instalează podele tehnologice și poduri fixate în balamale. Distanța între podul de bază și podul fixat în balamale 0,5 – 0,8 m, iar înălțimea podelei tehnologice 0,2 – 0,6 m.

Microclimatul. Deoarece CE sunt surse de eliminare a căldurii, ce poate ajunge la mărirea temperaturii și micșorarea umidității aerului. în încăperi se atrage atenție la controlul parametrilor microclimatului în Săli de Calcul (SC). în SC mărimea medie a eliminărilor de căldură constituie 310 W/m2. Eliminările de căldură de la instalații de iluminare tot sunt mari, mărimea specifică a lor este 35-60 W/m2. În afară de aceasta la microclimatul mai influențează surse exterioare de eliminare a căldurii, cum sunt căldura de la radiația solară ce intră prin fereastră, și afluența căldurii prin construcții de barieră ce nu sunt transparente.

Asupra corpului omului și lucrului utilajului a CC influențează foarte mult umiditatea aerului relativă. La umiditatea aerului egală cu 40% lenta magnetică devine mai fragilă, se mărește uzura capilor magnetici și apare câmpul magnetic static la mișcarea purtătorilor de informației în CE.

La efectuarea controlului locurilor de muncă se măsoară temperatura, umiditatea relativă și viteza de mișcare a aerului în încăpere, totodată se efectuează măsurări la începutul, mijlocul și sfârșitul perioadelor calde și reci a anului.

Se măsoară temperatura și umiditatea aerului cu psihometre aspiratoare, iar viteza de mișcarea a aerului – cu electro-anemometre, catatermometre. Ordinea de măsurare a indicilor microclimatului se stabilește în conformitate cu GOST 12.1.005-91. Parametrii se normează după acest GOST și sunt prezentați în tabelul următor.

Tab. 5.2.

Normele microclimatului.

În acest tabel se aduc parametrii pentru categoriile de lucru la (mai puțin de 120 kkal/oră, lucrul șezând) și Ib (de la 120 până la 150 kkal/oră, lucrul șezând), deoarece lucrul programatorului sau operatorului se poate atribui la una din aceste categorii.

Pentru crearea la locuri de muncă a condițiilor meteorologice bune se efectuează condiționarea și ventilarea aerului, utilizarea ventilatoarelor înăuntru CE pentru a reduce eliminările de căldură. Utilajul se aranjează în așa fel ca influența căldurii asupra corpul omului va fi cea mai mică.

Iluminatul. La lucrul cu CE o importanță mare are crearea mediului optimal de iluminare, adică organizarea rațională a iluminatului natural și artificial în încăperi și la locuri de muncă, deoarece lucrând la CE încărcarea în general cade pe organe de vedere. Dacă omul lucrează mai mult de o jumătate a zilei de lucru la CE la el se observă înrăutățirea vederii, ce constituie 62-94%. Asta în primul rând este oboseala ochilor, dureri foarte mari și simțul de nisip în ochi, mâncărime și senzație de usturare în ochi. Totodată senzațiile dureroase în ochi apar în general la sfârșitul zilei de lucru. Din această cauză toate locurile de muncă cu CE se amplasează în locuri ce sunt protejate de căderea luminii difuzate pe ecranul terminalului. Pentru asta se utilizează încăperi cu iluminarea unilaterală (într-o singură direcție), totodată ferestrele trebuie să fie cu storuri sau jaluzele pentru excluderea efectului de orbire și strălucirea ecranului terminalului.

Iluminarea artificială a locului de muncă se efectuează în felul următor, nivelul iluminării trebuie să corespundă caracterului de lucru vizual, iluminarea încăperii să nu depindă de timpul de afară, fluxurile de lumină să aibă direcția optimală și utilajul trebuie să fie economic, inofensiv, durabil și simplu în exploatare.

La instalarea iluminatului artificial se fac următoarele măsurări:

• iluminarea la locuri de muncă;

• caracterul de strălucire a ecranului, mesei;

• strălucirea petelor reflectate în ecran.

Se efectuează măsurări de control a iluminării și strălucirii la locuri de muncă cu diferite terminale, care sunt în încăperi și care se află în diferite condiții de iluminare, acolo unde sunt plângeri ale personalului. Măsurarea iluminatului se efectuează în timpul întuneric a zilei.

Punctele de control pentru măsurările iluminatului la locuri de muncă se amplasează: în centrul ecranului, pe tastatură, pe document în planul amplasării lui, pe masă în zona de lucru.

Efectuarea măsurărilor se efectuează în conformitate cu GOST 2.4.940-91. Măsurarea caracterului de strălucire a ecranului se efectuează la strălucirea ecranului nu mai puțin de 35 c/m2. Iluminarea locului de muncă se normează după SNiP 11-4-91 și depinde de caracterul lucrului vizual, contrastul obiectului, fonului și tipul fonului.

Securitatea incendiară. Securitatea împotriva incendiilor a obiectivelor trebuie să se asigure:

printr-un sistem de preîntâmpinare a incendiului;

printr-un sistem de protecție împotriva incendiilor;

prin măsuri tehnico-organizatorice.

Sistemele de preîntâmpinare și protecție împotriva incendiilor trebuie să excludă în ansamblu influența factorilor periculoși ai incendiului, ce depășesc valorile admisibile, asupra oamenilor. Probabilitatea influenței acestor factori nu trebuie să o depășească pe cea normativă, egală cu 10-6 pentru o persoană pe an.

Sistemele de preîntâmpinare a incendiului și protecție împotriva incendiilor, care asigură păstrarea bunurilor materiale, vor fi folosite doar prin confirmarea unui efect economic de la aplicarea lor sau de o deosebită însemnătate socială a obiectivului dat, determinată de organele directive în modul stabilit.

Securitatea împotriva incendiilor a obiectivului și părților sale componente trebuie să fie asigurată atât în timpul exploatării, cât și în cazurile reconstrucției, reparației sau situaților de avarie.

Factorii periculoși ai incendiului care influențează asupra oamenilor sunt următorii: focul deschis și scânteile, temperatura înaltă a mediului înconjurător, produsele toxice ale arderii, fumul, concentrația scăzută a oxigenului, prăbușirea părților clădirilor, agregatelor, instalațiilor etc.

Protecția împotriva incendiilor trebuie să se asigure printr-un șir de măsuri ca folosirea mijloacelor de stingere a incendiilor și tipurilor de tehnică împotriva incendiilor respectivă, folosirea instalațiilor automate de semnalizare și stingere a incendiilor, folosirea construcțiilor de bază ale obiectivelor cu grad de rezistență la foc și propagare a focului bine determinat, îmbibarea construcțiilor cu substanțe antipireme și aplicarea pe suprafața lor a vopselelor și compozițiilor protectoare de foc, instalații și dispozitive ce asigură limitarea propagării incendiului, organizarea evacuării la timp a oamenilor, folosirea mijloacelor colective și individuale de protecție împotriva factorilor periculoși ai incendiului, folosirea sistemelor de protecție antifum.

Rezistența la foc a clădirilor și instalațiilor trebuie stabilită astfel ca elementele de construcție să-și păstreze capacitatea portantă și funcțiile de barare a focului o perioadă de timp care este necesară pentru asigurarea securității oamenilor și stingerii incendiului de către subdiviziunile de pompieri.

Limitarea propagării incendiului conform limitelor focarului de aprindere trebuie să se asigure prin:

instalarea barierelor antifoc;

stabilirea suprafețelor maximal admise ale despărțiturilor și secțiilor antifoc, limitarea numărului de nivele;

instalarea dispozitivelor de deconectare sau comutare în caz de avarie a instalațiilor și comunicațiilor;

folosirea mijloacelor ce previn sau limitează scurgerea și revărsarea lichidelor în timpul incendiului;

folosirea dispozitivelor de barare a focului în utilaje.

Fiecare obiectiv va fi planificat și executat, astfel ca evacuarea oamenilor din el să se termine înainte ca factorii periculoși ai incendiului să atingă valori limită, pentru ce se vor stabili numărul de deșeuri și dimensiunile căilor de evacuare, posibilitatea mișcării nestingherite pe aceste căi, organizarea la necesitate a dirijării cu torentul de oameni ce deplasează pe căile de evacuare.

Mijloacele colective și individuale de protecție trebuie să asigure securitatea oamenilor pe durata întreagă de acțiune a factorilor periculoși ai incendiului.

Sistemul de protecție antifum trebuie să asigure protecția căilor de evacuare de fum, temperaturile înalte și produsele toxice ale arderii atâta timp cât este necesar pentru evacuarea sau protecția colectivă a oamenilor. La orice obiectiv al economiei naționale trebuie să fi asigurată anunțarea la timp sau semnalizarea despre incendiu la faza inițială cu mijloace tehnice sau organizatorice.

Radiație. Intensitatea radiației Roentgen de energie joasă se controlează la locuri de muncă cu monitoare, care lucrează sub tensiunea la cinescop 15 kV și mai mult. Norma nivelului de radiație roentgen este 100 mcP/oră, dar în timpul de azi se utilizează mai mult monitoare cu nivelul radiație mai mică, ce aduce la micșorarea influenței factorilor dăunători asupra programatorului sau operatorului. La efectuarea tezei de licență a fost utilizat monitorul cu tensiunea la cinescop mult mai mică de 15 kV, și de aceea acest factor nu a fost înregistrat de dispozitiv, adică a fost mai puțin de normă.

Încă se măsoară și se normează intensitatea radiației ultraviolete (la lungimea de undă 336 nm) și infraroșie (la lungimea de undă 700 – 1050 nm) ce influențează asupra omului, nu trebuie să depășească 10 W/m2.

Radiația electromagnetică se normează după componente electrice (50 V/m) și magnetice (50 A/m) de aflare în această zonă de radiere în timp de 8 ore. Tensiunea înaltă a câmpului electric între monitorul și operatorul aduce la efecte neplăcute. La distanța de 5 – 30 cm de la monitor tensiunea nu trebuie să depășească nivelul admisibil după norme, ce sunt stabilite în dependența de timpul aflării la locul de muncă. Niveluri admisibile de tensiune sunt prezentate în tabelul următor.

Tab. 5.3.

Niveluri admisibile de tensiune.

Controlul radiației de toate tipurile se efectuează în conformitate cu regulile ce sunt expuse în îndrumare speciale.

5.3. Aprecierea pericolului lucrărilor lucrului la monitor

Calculatoarele ocupă practic toate domeniile de lucru în timpul de față. Calculatoarele sunt utilizate atât în laboratoarele științifice cît și în instituțiile de învățământ, școli, etc. Mereu crește numărul de specialiști ce folosesc calculatorul. Dar lucrul îndelungat la calculator influențează negativ asupra sănătății operatorului. În primul rând se dereglează vederea. Principalii factori ce influențează asupra operatorului sunt:

câmpurile electromagnetice

iradiația de la monitor.

În fiecare zi operatorii se găsesc în fața monitoarelor. Acest factor poate aduce la dezvoltarea bolilor profesionale. Asupra sănătății operatorului pot influența următorii factori:

nemișcarea îndelungată a corpului, ce aduce la dereglarea scheletului și a mușchilor

încordarea îndelungată a ochilor

influența radiației de la monitor

influența câmpurilor electrostatici și electromagnetici, ce aduce la îmbolnăvirea pielei, dureri de cap și dereglarea funcționării unor organe.

La efectuarea cercetărilor asupra iradiației monitoarelor în diapazonul 20 Hz – 2 MHz, au arătat că intensitate câmpului static electromagnetic este 400 B/m, iar a câmpului magnetic 8 A/m.

Efectuând controlul asupra condițiilor de lucru la locuri de muncă cu monitoare trebuie să fie măsurate și evaluate următorii parametri a imaginii:

• deformarea imaginii;

• contrastul de strălucire a imaginii;

• variația strălucirii elementelor simbolului;

• lungimea, lățimea, raportul lățimii la lungimea;

• lățimea liniei de contur a simbolului;

• modulație de strălucire a rasterului;

• distanța între cuvinte, rânduri;

• vibrația și fugă (licărire) imaginilor.

Prezența sau lipsa licăririi imaginii se stabilește după metode experimentale sau de calcul. Metoda experimentală permite de evaluat și vibrarea imaginii. Prezența vibrării se determină prim metodă măsurărilor directe. Celelalte caracteristici a ecranului se stabilesc după rezultatele măsurărilor directe și indirecte. După control, parametrii se compară cu recomandațiile prezentate în tabelul 5.4.

Tab. 5.4.

Parametrii monitorului

Totodată o importanță mare are rezoluția ecranului, care se determină de tipul adaptorului grafic (CGA, EGA, VGA, SVGA), adică cât mai mare este rezoluția ecranului atât mai bună este imaginea.

Încordarea ochilor se poate de lămurit prin următorii factori negativ:

contrastul mărit dintre iluminarea monitorului și iluminarea încăperii.

iluminarea nedeplină câmpului de lucru (iluminarea optimă 600 – 400 lux ).

Distanța optimă de urmărire a informației la monitor 50–80 cm. Monitoarele pe baza tuburilor electroluminescente, sînt surse potențiale de radiație Roentgen, ultraviolet, infraroșu, frecvență radio și câmpurile electromagnetice.

Operatorul actual, citește informația de pe monitor cît și de pe foi. Privirea lui trece de pe foi pe monitor și invers de mii de ori pe zi. Deci operatorul trece de la o metodă de citire la alta care se deosebește esențial prin parametrii ce le caracterizează. De aceea apariția bolii ochilor este una din problemele actuale, ce sunt discutate la adunări, conferințe referitor la protecția ochilor.

Pe de o parte, informația de pe monitor, este statică, dar pe de altă parte, imaginea pe monitor mereu se schimbă. De aceea imaginea trebuie să apară rapid și să fie clară.

Lucrul la monitor deseori se petrece în încăperi cu iluminare artificială, de aceea sunt necesare condiții optime de lucru pentru îndeplinirea cerințelor necesare.

Monitoarele trebuie să se afle la distanța mâinii întinse, iar monitoarele vecine trebuie să se afle la distanța de 2m22cm față de operator.

După posibilitate monitorul trebuie să se afle puțin mai sus de nivelul ochilor. Aceasta ar aduce la relaxarea perechilor de mușchi împrejurul ochilor, care sunt încordați când ne uităm în jos sau înainte.

Încăperile în care se află calculatoarele și monitoarele, trebuie să fie voluminoase, cu schimbarea a aerului. Suprafața minimă pentru un monitor este de 9 –10 m2.

Nu se admite contactul vizual cu alte monitoare sau ecrane a televizoarelor. Este necesar de înlăturat iluminarea puternică a ecranului.

Este interzis lucrul la calculator în încăperi semiîntunecoase sau întunecoase.

O înlocuire tehnologică a monitoarelor pe baza tuburilor electroluminescente, au obținut-o monitoarele pe baza cristalelor lichide. Dar din cauza costului major, aceste monitoare sunt puțin folosite în practică.

În corespundere cu factorii negativi analizați anterior se recomandă de utilizat monitoarele ce corespund standardului internațional de iradiație TCO – 99.

5.4. Securitatea electrică. Protecția prin „legare la nul”

Utilajul CE este foarte periculos pentru operatori, deoarece lucrând la acest utilaj operatorul poate să atingă unele părți care sunt sub tensiune. Trecând prin om curentul electric efectuează influența optică, biologică termică, ce poate aduce la traumă electrică (GOST 12.1.009-91).

O importanță mare pentru emiterea cazurilor neplăcute și periculoase are organizarea corectă a exploatării utilajului electric, efectuarea lucrărilor de montare și profilactică.

În instalațiile cu tensiunea joasă se folosesc des rețele cu patru fire cu firul nul de protecție, unde se efectuează protecția „legarea la nul”.

Legarea la nul este o măsură de protejare a omului de electrocutare prin deconectarea strictă și în viteză a rețelei în caz de apariție a tensiunii pe carcasă, sau în cazul străpungerii izolării. Deconectarea strictă se efectuează, dacă curentul de scurt circuit format prin faza și firul nul este destul de mare ca declanșatorul să lucreze corect.

Protecția prin „legarea la nul” se numește unirea în mod voit a părților ne conductoare ale instalației electrice (carcasei), care în regim normal nu se găsesc sub tensiune (numai în regim de avarie pe ele poate apărea tensiune), cu firul de protecție – nul, care la rândul său este unit cu punctul neutru legat la pământ al sursei de alimentare.

Dacă pe carcasa utilajului din figura 5.1 apare tensiune în caz de defectare a izolării unui fir, se creează un circuit prin firul nul, punctul neutru, sursa de alimentare și firul de fază. Componentele acestui circuit au o rezistența electrică foarte joasă (deoarece sunt executate din materiale, ce conduc bine curentul) și circuitul se numește scurtcircuit, iar curentul care se scurge prin acest circuit se numește curent de scurtcircuit (). Curentul de scurcircuit este foarte mare și provoacă arderea siguranței fuzibile sau deconectarea declanșatorului automat A în cazul apariției tensiunii pe carcasa utilajului.

Protecția „legarea la nul” transformă curentul de scurgere în curent de scurtcircuit este important ca firul nul să nu fie întrerupt, din această cauză în el nu se montează siguranțe fuzibile sau întrerupătoare aparte. Pentru prevenirea ruperii avariate a firului nul el se unește cu diferite „prize de pământ” naturale (baze metalice, construcții îngropate în pământ) și repetat la „priza de pământ” artificială în cel puțin două puncte.

Scopul calculării instalației "legarea la nul" – determinarea secțiunii firului nul, care satisface condiția funcționării protecției maximale de curent. Valoarea protecției se determină după puterea instalației electrice proiectate (exploatate).

Curentul de scurtcircuit trebuie să depășească valoarea protecției conform cerințelor (pentru siguranțe , unde – curentul nominal al siguranței). Modul de calculare este următorul:

Se calculă rezistența circuitului "faza – nul":

unde: – rezistența activă a firului fazic, Ohm;

– rezistența activă a firului nul, Ohm;

– rezistența inductivă a rețelei "faza – nul" și pentru rețelele cu tensiune joasă (până la 1000V) și firele din cupru și aluminiu, deci Xc este foarte mică (Xc = 0).

2) Înainte de aceasta trebuie de calculat rezistențele active se calculă după formula:

unde – lungimea și secțiunea firului fazic și nul corespunzător;

– rezistența electrică specifică: pentru cupru, Cu= 0.018 Ohm(mm2 / m);

pentru aluminiu Al = 0.028 Ohm(mm2 / m);

Deoarece materialul din care s-a confecționat cablul (firul) este cupru, lungimea firului de fază =300 m, iar secțiunea firului = 12 mm2 vom obține următoarele calcule:

Rf = 0,018 Ohm(mm2/m) = 0,45 Ohm;

Pentru lungimea firului nul Ln= 300 m și secțiunea firului = 8 mm vom obține:

Rn = 0,018 Ohm(mm2/m) = 0,45 Ohm;

3) Acum putem calcula rezistența circuitului "faza-nul":

4) Curentul de scurt-circuit calculat în A:

unde Zt – rezistența transformatorului.

Pentru tensiunea U= 380 V și Zt / 3 = 0,0354 Ohm (din tabel) obținem următoarele calcule:

5) Se compară Is.c. cu In : dacă Is.c. =3 In pentru siguranță atunci se aleg conductoare de o secțiune mai mare și calculul se repetă.

Deoarece In este egal cu 63 A obținem: 327A 189A.

Rezultă că, curentul de scurtcircuit depășește valoarea cerințelor obiectului protecția muncii (pentru siguranțe) sunt respectate.

5.5. Locul de muncă la efectuarea lucrului șezând

Standardul STAS 12.2.032 – 78 stabilește cerințele ergonomice generale la locuri de muncă la efectuarea lucrului șezând la proiectarea utilajului nou sau modernizarea proceselor de producție și utilajului existent.

5.5.1. Principii generale

Locul de muncă la efectuarea lucrului șezând se organizează la lucrul simplu, care nu cere mișcarea liberă a lucrătorului și la lucrul de greutate medie în cazuri cauzate de particularitățile de proceselor tehnologice.

Construcția locului de muncă și amplasarea concomitentă a elementelor (scaun, organe de conducere, mijloace de primire a informației) trebuie să corespundă cerințelor tehnologice și caracterului de lucru.

Locul de muncă trebuie să fie organizat m conformitate cu cerințele standardelor, condițiilor tehnice și (sau) indicațiilor metodice de securitatea muncii.

5.5.2. Caracteristicile de dimensiune a locului de muncii

Construcția locului de muncă trebuie să asigure efectuarea operațiilor accesibile a câmpului motor. Câmpul motor m plan vertical și orizontal pe medie sunt prezentate pe fig. 5.2 și 5.3.

Efectuarea operațiilor, "des" și "foarte des", trebuie să fie asigurată' și zonei optimale a câmpului de motor.

Observație. Frecvența îndeplinirii operațiilor se consideră: foarte des – două sau m puțin de două operații pe minut, dar mai mult de două operații pe oră; rar – nu mai mult de două operații pe oră.

La proiectarea utilajului de muncă trebuie să fie luați în considerație indicatorii antroponometrici a femeii (dacă lucrează numai femei) și al bărbatului (dacă lucrează numai bărbați); dacă utilajul este deservit și de femei și de bărbați – indicatori medii generale a femeilor și bărbaților.

La construcția utilajului de producere și la locul de muncă se asigură poziția optimală a lucrătorului care se atinge reglând:

– înălțimea planului de lucru, scaunului și spațiului pentru picioare. Parametrii reglați se aleg după nomogramă;

– înălțimea scaunului și suportului pentru picioare (la înălțimea neregulată a planului de lucru). în acest caz înălțimea planului de lucru se stabilește după nomograma pentru lucrător cu înălțimea 1800 mm. Poziția optimală de lucru pentru lucrători cu înălțime mai mică se atinge mărind înălțimea scaunului și suportului pentru picioare cu mărimea egală cu diferența între înălțimea planului de lucru pentru lucrător cu înălțimea 1800 mm și înălțimea planului de lucru optimal pentru înălțimea lucrătorului dat.

Construcția scaunului reglabil a operatorului trebuie să corespundă cerințelor STAS 21889-76.

În cazurile când nu se poate de reglat înălțimea planului locului de muncă și suportului pentru picioare, se permite proiectarea și fabrica utilajului cu parametri neregulați a locului de muncă. în acest caz valorile parametrilor se definesc după tabelele 5.5, 5.6.

Tab. 5.5

Parametrii neregulați

Tab. 5.6

Parametrii scaunului

Forma planului de lucru a utilajului trebuie de instalat m dependență de caracterul lucrului îndeplinit. Ea poate fi pătrată, poate să aibă o tăietură pentru lucrător sau adâncitură pentru mașini de birou.

Suportul pentru picioare trebuie să fie reglabil după înălțime. Lățimea trebuie să fie nu mai mică de 300 mm, lungimea – nu mai mică de 400 mm. Suprafața suportului trebuie să fie zimțată. La marginea din față trebuie să fie o bordură.

6. Partea economică a proiectului.

6.1. Determinarea volumului de lucru necesar pentru îndeplinirea proiectului.

Proiectele tehnologice contemporane sunt caracterizate de următoarele particularități:

• tehnica nouă utilizată este foarte complexă și este construită utilizând ultimele elaborări științifice.

• accelerării vitezei de elaborare a proiectelor.

• proiectele referitoare la complexele tehnicii de calcul și softului sunt supuse uzurii morale foarte rapide.

• necesitatea proiectării de sistemă la elaborarea softului și sistemelor tehnice.

Toate acestea au dus la necesitatea de creare a noi metode de planificare. Una din aceste metode prezintă modelarea procesului de elaborare, adică prezentarea legăturilor și caracteristicilor lucrărilor în procesul elaborării proiectului.

Tab. 6.1.

Durata efectuării lucrărilor.

Programul va fi scris la calculatoare arendate cu 10 lei pe oră.

Suma cheltuielilor pentru ore-mașină va constitui

Smas = 493 * 10 = 4930,00 lei.

6.2. Evaluarea economică a sistemului informațional "C.N.E.A.A.I.I.".

Această etapă constă în determinarea componentei grupei de executanții și împărțirea lor pe lucrări. Grupul se formează luând în considerație următorii factori: termenii de îndeplinire a proiectului, resursele financiare alocate, complexitatea temei, experiența și nivelul profesionist a executanților, pentru a fi în stare sa îndeplinească toate lucrările la proiectarea și elaborarea sistemului multiprocesor.

În tab. 6.2 sunt arătați executanții care vor îndeplini lucrarea, codul fiecăruia și salariu.

Tab. 6.2

Componența grupului de lucru.

Această etapă constă în împărțirea executanților după lucrări:

În tabelul de mai jos (tab. 6.3) sunt indicate toate lucrările, executant, care vor îndeplini lucrarea dată, durata îndeplinirii lucrării și ocuparea fiecărui executant pe lucrarea dată, luând în considerație ca ziua de lucru durează 8 ore.

Tab. 6.3

Executarea lucrărilor de către lucrători

Pentru salariu remunerat de bază sau cheltuit

Sb = 720,00 +1687,50 +3605,00 + 3570,00 = 9582,50 lei.

Salariu auxiliar (25%)

Sa = 9582,50 x 0,25 =2595,63 lei.

Defalcări în Fondul Social (31 %)

Cfs = (9582,50 + 2595,63) x 0,31 =3713,22 lei.

Cheltuielile totale pentru achitarea salariului

Ct = 9582,50 + 3713,22 + 2595,63 = 15891,35 lei

6.3. Evaluarea prețului de cost al SI “C.N.E.A.A.I.I.”

Aprecierea economică a proiectului include determinarea eficacității folosirii articolului (obiectului) proiectat. Pentru aceasta trebuie de determinat cheltuielile pentru petrecerea însăși a proiectului, în care intra cheltuielile pentru confecționarea modelelor experimentale, controlul și reglarea lor, cheltuielile consumatorilor noii tehnici, cheltuielile dictate de necesitatea creării condițiilor necesare de exploatare.

La elaborarea sistemului participă o grupă de executanții, care îndeplinesc anumite lucrări. Cheltuielile pentru petrecerea proiectării și elaborării se determină pe calea alcătuirii planului de cheltuieli. Mai întâi efectuăm calculul prețurilor materialelor și semifabricatelor, pe care le includem in tabelul de mai jos.

Tab. 6.4

Costul materialelor utilizate

Deorece softul BDE Administrator v.5.01 al companiei Inprise se distribuie gratuit, folosindu-ne de el reducem cheltuielile pentru procurarea softului.

De asemenea s-a procurat literatură tehnică în valoare de 500 lei și rechizite de birou în valoare de 113 lei.

Cheltuielile pentru amortizarea programelor Inprise Delphi v.5.0 Professional: Costul inițial 800USD, 3 licențe, amortizarea timp de 2 ani. Următorul produs Inprise Delphi va fi cumpărat cu 0.5 preț (la prezentarea licențelor actuale).

Durata lucrărilor asupra proiectului dat 6 luni

Sam_soft = (6*(800/2) * 3/24 =300 USD = 2840 lei ;

Tab. 6.5

Costul total al proiectului

Produsul final este efectuat la comanda Consiliului Național de Evaluare Academică și Acreditare a Instituțiilor de Învățământ.

6.4. Evaluarea eficacității de la implementarea SI “C.N.E.A.A.I.I.”

Este clar că crearea unui astfel de sistem informațional necesită cheltuieli mari și eforturi serioase din partea programatorilor, de aceea acest sistem informațional nu va fi chiar atât de ieftin și accesibil pentru toți. Dacă luăm în considerație faptul că cu ajutorul acestui sistem informațional se lucrează mai repede, mai efectiv, mai comod, atunci acele cheltuieli pentru acest sistem se recuperează destul de repede. În acest caz avem nevoie de puțină forță de muncă, dar rezultatele muncii sunt foarte avantajoase, luând în considerație organizarea eficientă a forțelor de muncă.

În tabelul următor este evaluată eficiența implementării proiectului dat, adică se arată diferența dintre un mod vechi de lucru și unul nou, având în vedere perfecționarea și dezvoltarea modului vechi în unul mai performant și comod în utilizare.

Tab. 6.6

Evaluarea eficacității sociale de la implementarea SI "C.N.E.A.A.I.I."

Concluzie

În ultima decadă s-a constatat prioritatea conceptelor de obiect și introducerea lor în tehnologia sistemelor informatice. Recent, conceptele de obiect au fost înglobate în tehnologia sistemelor de gestiune a bazelor de date, rezultând producția de sisteme de gestiune a bazelor de date orientate pe obiecte.

Bazele de date “clasice”, bazate pe modelul relațional oferă prea puțin suport pentru tipurile neconvenționale de date.

Bazele de date orientate pe obiecte permit crearea de obiecte complexe, din componente mai simple, fiecare având propriile atribute și propriul comportament.

Sistemele de gestiune a bazelor de date orientate pe obiecte combină posibilitatea de definire și manipulare a structurilor complexe de date, funcționalitatea unui limbaj de programare și tehnologia de gestiune a bazelor de date. Sistemele de gestiune a bazelor de date orientate pe obiecte, ori sistemele de gestiune de baze de cunoștințe reprezintă sistemele de gestiune a bazelor de date din a treia generație.

Ele sunt deci complementare sistemelor de gestiune a bazelor de date din prima și a doua generație.

Sistemele de gestiune a bazelor de date orientate pe obiecte combină noile concepte asociate limbajelor de programare orientate pe obiecte cu capacitățile sistemelor de gestiune a bazelor de date convenționale. Sistemele de gestiune a bazelor de date orientate pe obiecte sunt acum în faza de comercializare și au câteva caracteristici particulare față de sistemele de gestiune a bazelor de date convenționale. Baza de date-obiect permite reprezentarea unor structuri de date complexe și a unor ierarhii model asigurând posibilitatea de a defini tipuri de date care combină atât structura de date, cît și definirea procedurii. Acesta duce la o flexibilitate crescută în reprezentarea structurii și comportamentului sistemelor reale.

Sistemul C.N.E.A.A.I.I o fost implementat ca sistem de gestiune a bazelor de date orientate pe obiecte pentru a oferi posibilitatea de gestiune cît mai flexibilă.

Formarea sistemului informațional C.N.E.A.A.I.I pentru consiliul este benefică și oportună, având în vedere demararea procesului de acreditare, eveniment unic pentru sistemul de învățământ din republica Moldova. Utilizarea sistemului informațional permite rezolvarea unor dificultăți întâmpinate de Consiliului Național de Evaluare Academică și Acreditare în cadrul procesul de evaluare și acreditare. Totodată utilizarea sistemului informațional urgentează procesul de evaluare și acreditare a celor mai buni specialiști din diferite domenii ale științei, a celor mai buni profesori din cadrul centrelor științifice și universitare.

Sistemul elaborat contribuie la optimizarea procesului de acreditare. Esența sistemului constă la reducerea la minim a timpului și simplificarea soluționării problemei în cauză. La fel cu ajutorul sistemului elaborat se duce evidența tuturor instituțiilor de învățământ acreditate și crearea diferitor rapoarte pe baza datelor instituțiilor de învățământ acreditate.

Bibliografie

Salomie I. Tehnici orientate pe obiecte, Cluj Napoca, Editura Albastră, 1995.

Lungu I., Bodea C. Baze de date. Organizare, proiectare și implementare, București, Editura All Educational, București 1995.

Khoshafian S., Abnous R. Object Orientation. Concepts, Databases, User Interfaces, John Wiley & Sons Inc., 1990.

Wegner P. Dimension of Object Oriented Modeling, IEEE Computer, October 1992.

Cotelea V. Baze de date relaționale: proiectare logică, Chișinău, Editura ASEM, 1997.

Балабанов И.Т. Основы финансового менеджмента. М.: Финансы и статистика, 1995.

Технико-экономическое обоснование дипломных проектов. / Под ред. В.К. Беклешева. М.: Высшая школа, 1991.

Павлов С.П., Губонина З.И. Охрана труда в приборостроении. М.: Высшая школа, 1986.

Охрана труда в машиностроении. / Под ред. Е.Я. Юдина. М.: Высшая школа, 1993.