Proiectarea Si Elaborarea
CUPRINS
Adnotare……………………………………………………………………………………………….7
Annotation…………………………………………………………………………………………….8
Introducere ………………………………………………………………………………………….10
1. Baze de date. Noțiuni generale. ………………………………………………….13
1.1. Noțiune de bază de date orientată pe obiecte…………………………………..13
1.2. Proiectarea bazelor de date orientate pe obiecte………………………………14
1.2.1. Modelul de date orientat pe obiecte…………………………………………….16
1.2.2. Operațiile modelului de date orientat pe obiecte…………………………..16
1.2.3. Reguli de integritate ale modelului de date orientat pe obiecte……….17
1.3. Limitele bazelor de date orientate obiect………………………………………..18
2. Concepte de bază ale programării orientate pe obiecte. …………………….19
2.1. Obiectul……………………………………………………………………………………..19
2.2. Metode……………………………………………………………………………………….20
2.3. Mesaje……………………………………………………………………………………….21
2.4. Încapsulare………………………………………………………………………………….21
2.5. Persistența…………………………………………………………………………………..22
2.6. Clase de obiecte…………………………………………………………………………..22
2.7. Moștenirea………………………………………………………………………………….24
2.8. Polimorfism ……………………………………………………………………………….24
2.9. Identitate…………………………………………………………………………………….25
3. Limbaje orientate pe obiecte. ……………………………………………………………25
3.1 Un reprezentant al limbajelor orientate pe obiecte – Delphi………………27
3.1.1. Arhitectura compilatorului de cod optimizat pe 32 biți………………….28
3.1.2. Compatibilitate cu codul pe 16 biți……………………………………………..29
3.1.3. Suport complet pentru controale și automatizare OLE…………………..30
3.1.4. Suport complet pentru aplicațiile și interfața Windows………………….31
3.1.5. Productivitatea………………………………………………………………………….32
3.1.6. Controale pentru Windows 95…………………………………………………….33
3.1.7. Suport extins pentru aplicațiile de baze de date…………………………….34
3.1.8. Performantele obținute de programele Delphi de baze de date………..36
4. Administrarea bazelor de date cu ajutorul mediului Delphi. ……………..39
4.1. Componentele necesare accesului la date ………………………………………40
4.2. Descrierea componentelor Delphi pentru accesul la date. ………………..40
4.2.1. TDataSource…………………………………………………………………………….40
4.2.2. Ttable……………………………………………………………………………………..41
4.2.3. Tquery…………………………………………………………………………………….41
4.2.4. TstoredProc……………………………………………………………………………..42
4.2.5. TDatabase………………………………………………………………………………..42
4.2.6. Tsession…………………………………………………………………………………..43
4.2.7. TbatchMove……………………………………………………………………………..43
4.2.8. TUpdateSQL……………………………………………………………………………44
4.2.9. Treport…………………………………………………………………………………….44
4.3. Componentele necesare pentru controlul datelor……………………………..46
4.4. Descrierea componentelor Delphi pentru controlul datelor. ……………..47
4.4.1. TDBGrid………………………………………………………………………………….47
4.4.2. TDBNavigator………………………………………………………………………….48
4.4.3. TDBText………………………………………………………………………………….48
4.4.4. TDBEdit………………………………………………………………………………….48
4.4.5. TDBMemo………………………………………………………………………………49
4.4.6. TDBImage……………………………………………………………………………….49
4.4.7. TDBListBox…………………………………………………………………………….50
4.4.8. TcomboBox……………………………………………………………………………..51
4.4.9. TDBCheckBox…………………………………………………………………………51
4.4.10. TDBRadioGroup…………………………………………………………………….52
4.4.11. TDBLookUpListBox……………………………………………………………….52
4.4.12. TDBLookUpComboBox………………………………………………………….53
4.4.13. TDBCtrlGrid………………………………………………………………………….53
4.5. Componentele QuickRpt………………………………………………………………54
4.6. Descrierea componentelor Delphi din pagina QuickRpt……………………55
4.6.1. TQuickReport…………………………………………………………………………..55
4.6.2. TQRBand…………………………………………………………………………………56
4.6.3. TQRGroup……………………………………………………………………………….56
4.6.4. TQRDetailLink…………………………………………………………………………57
4.6.5. TQRLabel………………………………………………………………………………..57
4.6.6. TQRMemo……………………………………………………………………………….57
4.6.7. TQRDBText…………………………………………………………………………….58
4.6.8. TQRDBCalc…………………………………………………………………………….58
4.6.9. TQRSysData…………………………………………………………………………….59
4.6.10. TQRShape……………………………………………………………………………..60
4.6.11. TQRPreview…………………………………………………………………………..60
5. Descrierea sistemului informațional – C.N.E.A.A.I.I. …………………………62
5.1. Evaluare Academică și Acreditare…………………………………………………62
5.1.1. Legea cu privire la evaluarea și acreditarea instituțiilor de
învățământ din Republica Moldova nr. 1257-XIII din 16 iulie 1997…………………62
5.1.2. Procedura de evaluare și acreditare……………………………………………..64
6. Protecția muncii și sanitarie de producere………………………………………….81
6.1. Zgomotul……………………………………………………………………………………82
6.2. Securitatea electrică……………………………………………………………………..83
6.3. Microclimatul……………………………………………………………………………..84
6.4. Securitatea antiincendiară……………………………………………………………..85
6.5. Radiație………………………………………………………………………………………88
6.6. Parametrii vizuali a imaginii…………………………………………………………89
6.7. Efecte psihofiziologice…………………………………………………………………91
6.8. Iluminatul…………………………………………………………………………………..91
6.9. Calcularea iluminatului artificial a încăperii. ………………………………….93
6.10. Ecologia. ………………………………………………………………………………….96
7. Partea economică a proiectului. ………………………………………………………97
7.1. Determinarea volumului de lucru necesar pentru îndeplinirea proiectului………………………………………………………………………………………..99
7.2. Evaluarea economică a sistemului informațional "C.N.E.A.A.I.I." …..99
7.2.1. Evaluarea prețului de cost al SI “C.N.E.A.A.I.I.” ……………………….102
7.3. Evaluarea eficacității de la implementarea SI “C.N.E.A.A.I.I.” ………104
Concluzie ……………………………………………………………………………………..106
Bibliografie……………………………………………………………………………………107
ANEXE…………………………………………………………………………………………108
Anexa 1…………………………………………………………………………………………108
Anexa 2…………………………………………………………………………………………112
=== DIPLOM ===
CUPRINS
Adnotare……………………………………………………………………………………………….7
Annotation…………………………………………………………………………………………….8
Introducere ………………………………………………………………………………………….10
1. Baze de date. Noțiuni generale. ………………………………………………….13
1.1. Noțiune de bază de date orientată pe obiecte…………………………………..13
1.2. Proiectarea bazelor de date orientate pe obiecte………………………………14
1.2.1. Modelul de date orientat pe obiecte…………………………………………….16
1.2.2. Operațiile modelului de date orientat pe obiecte…………………………..16
1.2.3. Reguli de integritate ale modelului de date orientat pe obiecte……….17
1.3. Limitele bazelor de date orientate obiect………………………………………..18
2. Concepte de bază ale programării orientate pe obiecte. …………………….19
2.1. Obiectul……………………………………………………………………………………..19
2.2. Metode……………………………………………………………………………………….20
2.3. Mesaje……………………………………………………………………………………….21
2.4. Încapsulare………………………………………………………………………………….21
2.5. Persistența…………………………………………………………………………………..22
2.6. Clase de obiecte…………………………………………………………………………..22
2.7. Moștenirea………………………………………………………………………………….24
2.8. Polimorfism ……………………………………………………………………………….24
2.9. Identitate…………………………………………………………………………………….25
3. Limbaje orientate pe obiecte. ……………………………………………………………25
3.1 Un reprezentant al limbajelor orientate pe obiecte – Delphi………………27
3.1.1. Arhitectura compilatorului de cod optimizat pe 32 biți………………….28
3.1.2. Compatibilitate cu codul pe 16 biți……………………………………………..29
3.1.3. Suport complet pentru controale și automatizare OLE…………………..30
3.1.4. Suport complet pentru aplicațiile și interfața Windows………………….31
3.1.5. Productivitatea………………………………………………………………………….32
3.1.6. Controale pentru Windows 95…………………………………………………….33
3.1.7. Suport extins pentru aplicațiile de baze de date…………………………….34
3.1.8. Performantele obținute de programele Delphi de baze de date………..36
4. Administrarea bazelor de date cu ajutorul mediului Delphi. ……………..39
4.1. Componentele necesare accesului la date ………………………………………40
4.2. Descrierea componentelor Delphi pentru accesul la date. ………………..40
4.2.1. TDataSource…………………………………………………………………………….40
4.2.2. Ttable……………………………………………………………………………………..41
4.2.3. Tquery…………………………………………………………………………………….41
4.2.4. TstoredProc……………………………………………………………………………..42
4.2.5. TDatabase………………………………………………………………………………..42
4.2.6. Tsession…………………………………………………………………………………..43
4.2.7. TbatchMove……………………………………………………………………………..43
4.2.8. TUpdateSQL……………………………………………………………………………44
4.2.9. Treport…………………………………………………………………………………….44
4.3. Componentele necesare pentru controlul datelor……………………………..46
4.4. Descrierea componentelor Delphi pentru controlul datelor. ……………..47
4.4.1. TDBGrid………………………………………………………………………………….47
4.4.2. TDBNavigator………………………………………………………………………….48
4.4.3. TDBText………………………………………………………………………………….48
4.4.4. TDBEdit………………………………………………………………………………….48
4.4.5. TDBMemo………………………………………………………………………………49
4.4.6. TDBImage……………………………………………………………………………….49
4.4.7. TDBListBox…………………………………………………………………………….50
4.4.8. TcomboBox……………………………………………………………………………..51
4.4.9. TDBCheckBox…………………………………………………………………………51
4.4.10. TDBRadioGroup…………………………………………………………………….52
4.4.11. TDBLookUpListBox……………………………………………………………….52
4.4.12. TDBLookUpComboBox………………………………………………………….53
4.4.13. TDBCtrlGrid………………………………………………………………………….53
4.5. Componentele QuickRpt………………………………………………………………54
4.6. Descrierea componentelor Delphi din pagina QuickRpt……………………55
4.6.1. TQuickReport…………………………………………………………………………..55
4.6.2. TQRBand…………………………………………………………………………………56
4.6.3. TQRGroup……………………………………………………………………………….56
4.6.4. TQRDetailLink…………………………………………………………………………57
4.6.5. TQRLabel………………………………………………………………………………..57
4.6.6. TQRMemo……………………………………………………………………………….57
4.6.7. TQRDBText…………………………………………………………………………….58
4.6.8. TQRDBCalc…………………………………………………………………………….58
4.6.9. TQRSysData…………………………………………………………………………….59
4.6.10. TQRShape……………………………………………………………………………..60
4.6.11. TQRPreview…………………………………………………………………………..60
5. Descrierea sistemului informațional – C.N.E.A.A.I.I. …………………………62
5.1. Evaluare Academică și Acreditare…………………………………………………62
5.1.1. Legea cu privire la evaluarea și acreditarea instituțiilor de
învățământ din Republica Moldova nr. 1257-XIII din 16 iulie 1997…………………62
5.1.2. Procedura de evaluare și acreditare……………………………………………..64
6. Protecția muncii și sanitarie de producere………………………………………….81
6.1. Zgomotul……………………………………………………………………………………82
6.2. Securitatea electrică……………………………………………………………………..83
6.3. Microclimatul……………………………………………………………………………..84
6.4. Securitatea antiincendiară……………………………………………………………..85
6.5. Radiație………………………………………………………………………………………88
6.6. Parametrii vizuali a imaginii…………………………………………………………89
6.7. Efecte psihofiziologice…………………………………………………………………91
6.8. Iluminatul…………………………………………………………………………………..91
6.9. Calcularea iluminatului artificial a încăperii. ………………………………….93
6.10. Ecologia. ………………………………………………………………………………….96
7. Partea economică a proiectului. ………………………………………………………97
7.1. Determinarea volumului de lucru necesar pentru îndeplinirea proiectului………………………………………………………………………………………..99
7.2. Evaluarea economică a sistemului informațional "C.N.E.A.A.I.I." …..99
7.2.1. Evaluarea prețului de cost al SI “C.N.E.A.A.I.I.” ……………………….102
7.3. Evaluarea eficacității de la implementarea SI “C.N.E.A.A.I.I.” ………104
Concluzie ……………………………………………………………………………………..106
Bibliografie……………………………………………………………………………………107
ANEXE…………………………………………………………………………………………108
Anexa 1…………………………………………………………………………………………108
Anexa 2…………………………………………………………………………………………112
ADNOTARE
Acest proiect de diplomă a fost implementat pentru proiectarea și realizarea unui Web-Server cu ajutorul limbajului de programare orientat pe obiecte Java, care mai apoi poate fi utilizat cu ușurință în cadrul unei rețele locale a unei comapanii, sau rețeaua globală Internet, pentru accesarea Informației necesare. El este destinat pentru lucrul cu sistemele informaționale din Internet, și anume pagini Web ce au un conținut vast.
Cuvintele cheie: WWW (World Wide Web), TCP (Transmission Control Protocol), IP (Internet Protocol), UDP (User Datagram Protocol), HTTP (HyperText Transfer Protocol), HTML (HyperText Marckup Language), DNS (Domain Naiming Service), host, port, URL (Uniform Resource Locator), MIME (Multipurpose Internet Mail Extensions), START, STOP, SGBD (Sistem de Gestiune a Bazelor de Date), MVJ (Mașina Virtuală Java).
Primul capitol al proiectului conține descrierea generală a tehnologiilor Web-Server și politicilor Internet. Aici sunt descrise toate mijloacele de interconectare care sunt utilizate și implementate în proiect.
În capitolul doi este descris la general lucrul în rețea a limbajului JAVA2 . Aici sunt desrise toate tehnologiile JAVA2 așa ca: classele principale , metodele și componentele de rețea , precum și definirea conceptului de socket.
Capitolul trei descrie structura Web-Serverului “SlavikWebServer1.0”. Sunt descrise toate classele folosite, metodele acestora, destinația fiecărei, și funcțiile îndeplinite în procesul serverului.
În capitolol patru se analizează problemele referitoare la protecția muncii și sanitaria de producere, unde se analizează acțiunea factorilor nocivi de la exploatarea calculatorului și standardele de lucru cu tehnica de calcul.
În capitolul cinci este efectuată proiectarea rețea a proiectului, sunt estimate cheltuielile proiectului și costul proiectului. Este prezentată analiza efectului social de la introducerea proiectului în exploatare.
Sunt anexate codurile sursă a fiecărei classe scrise în JSDK 1.3 JAVA2. De asemenea sunt anexate schemele generale de lucru, a Web-serverului și schemele rulării acestuia pe diferite platforme împreună cu sistemul de Securitate al proiectului.
ANNOTATION
This degree project was entered for designing and creation one Web-Server with the help of oriented-object language Java, which can with ease be applied in a local network of the company or worldnet Internet, for reception of the appropriate necessary information later. It is intended for work with information systems from Internet, namely pages Web, which have various contents.
Key words: WWW (World Wide Web), TCP (Transmission Control Protocol), IP (Internet Protocol), UDP (User Datagram Protocol), HTTP (HyperText Transfer Protocol), HTML (HyperText Marckup Language), DNS (Domain Naiming Service), host, port, URL (Uniform Resource Locator), MIME (Multipurpose Internet Mail Extensions), START, STOP, DBMC (database management sistem), JVM (Java Virtuale Mashine).
The first section of this project contains the general description of technology of Web-Servers and various politics of Internet. All means of work which here are described are introduced and are applied in the project.
In the second section in general the work in a network of language JAVA2. is described. All technologies JAVA2 such as here are described: the main classes, network methods and components, and also description concepts of socket.
In the third section the structure of Web-Server “SlavikWebServer1.0” is described. Their methods, purpose(assignment) everyone, and function executed by them are described all used classes, during the server.
Section number four contains the data about labour protection and industrial hygiene, where influence per capita of such harmful factors as noise, radiation and other, and also sanitary rules and norms of work of the person that uses computers is considered.
In the fifth section the basic principles of network planning are considered, network diagram is designed, the economic cost of the project is computed, and also the social effects of introducing this system are presented.
In this work I have listed initial codes of each class written in JSDK 1.3 JAVA2. And also listed the general(common) circuits of work Web-server.
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 cheltuielelor 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 idea 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, ca de exemplu MS Access sau Visual FoxPro. 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 ultimii 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 adte, funcționalitatea unui limbaj de programare și tehnologia de gestiune a bazelor de date.
1. Baze de date. Noțiuni generale.
1.1. Noțiune de baze de date orientate 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 implimentare 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 utelioară 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, definirele 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 implimentat î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ă nerezolvate 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 incapsulată în obiecte interogarea ad-hoc a bazei de date devine mai deficilă. 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.
2. Concepte de bază ale programării orientate pe obiecte.
2.1. Obiectul
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ă.
2.2. Metode
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.
2.3. Mesaje
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.
2.4. Încapsulare
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.
2.5. 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ă.
2.6. Clase de obiecte
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.
2.7. Moștenirea
Î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.
2.8. Polimorfism
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.
2.9. Identitate
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.
3. Limbaje orientate pe obiecte
Așa cum am spus în introducere, 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.
Un 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.
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ța Windows 95 si satisfacerea exigentelor logo Windows 95;
suport complet pentru aplicații pe 32 biți atît pentru Windows 95 cît si Windows NT;
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;
3.1.1. Arhitectura compilatorului de cod optimizat pe 32 biti
Acest compilator Pascal este construit pe o tehnologie comună cu C++ versiunea 4.5 si împrumută masiv de la acesta din urmă de la tehnici de optimizare a codului pînă la raportarea în stivă a erorilor de compilare. O mostenire directă este si suportul dual al lui Delphi pentru fisiere de tip unităti Turbo Pascal (DCU) si fisiere î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 reusit 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 registrilor, utilizarea registrilor pentru reducerea stivelor de apel de rutine, eliminarea subexpresiilor comune, inducerea variabilelor de buclă generează cod masină deosebit de rapid si compact care nu schimbă sensul codului original si poate fi depanat natural.
Noul link-editor apelat la sfîrsitul procesului de compilare este cu 20% pînă la 50% mai rapid decît versiunea precedentă. Cîteva optimizări concură la obtinerea acestui rezultat. Astfel, utilizarea unei scheme de păstrare în memorie a unitătilor si formelor nemodificate măreste semnificativ viteza de link-editare prin comparatie cu reînărcarea modulelor de pe disc. Un nou format pentru unităti (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 functii dintr-o unitate determina recompilarea automată a tuturor unitătilor care foloseau vreun element din interfața unitătii modificate, acum numai unitătile care apelează explicit functia modificată sînt incluse în procesul de recompilare. Producătorii de biblioteci de obiecte si componente nu vor mai fi nevoiti să distribuie o nouă versiune, recompilată, pentru fiecare nouă versiune de Delphi.
La aparitia noilor sisteme de operare pe 32 biți, numeroase voci sustineau 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.
3.1.2. Compatibilitate cu codul pe 16 biti
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.
3.1.3. Suport complet pentru controale și automatizare 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 usor chiar controalele OCX se includ facil în paleta de componente, iar Delphi creează automat o clasă care "îmbracă" controlul în component cu proprietăti, metode si evenimente, si permite chiar dezvoltatorilor derivarea de noi obiecte care să mostenească caracteristicile controlului original.
Întrucît compilatorul generează cod masină 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 aplicatia 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 ceilalti parametri.
3.1.4. Suport complet pentru aplicațiile și interfața Windows
În Delphi se regăseste suport pentru toate facilitătile oferite de Windows 9x si NT. De departe cea mai semnificativă este capacitatea de a crea cod executabil în fire paralele de executie (multi-threading). Complexitatea initierii si controlării firelor de executie 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 reactionează la încheierea executiei firului. Prioritatea executiei se stabileste prin simpla atribuire de valoare proprietătii Priority, iar lansarea thread -ului prin setarea proprietătii Suspended.
Încapsularea obiectuală a thread-urilor face ca executarea în paralel a mai multor sarcini identice să se reducă la instantierea mai multor obiecte din aceeasi clasă derivată din TThread. Diferitele instante pot partaja variabilele globale între ele sau crează copii proprii ale variabilelor prin utilizarea declaratiei threadvar. Exceptînd unele componente din Visual Component Library, nu există restrictii asupra includerii în codul thread-ului a obiectelor sau functiilor din interfața API Windows.
Biblioteca de sistem include tipuri si functii care asigură suport complet pentru Unicode. Tipul fundamental WideChar defineste 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 functionalităti oferite de sistemul de operare. Între acestea se numără si Winsockets, fisiere mapate în memorie, interfața de comunicatii TAPI. Totusi, cel putin pentru suportul groupware MAPI ar fi fost necesară o interfată obiectuală dedicată.
3.1.5. Productivitatea
Doar cerintele utilizatorilor de azi privind functionalitatea aplicațiilor cresc la fel de repede precum scad termenele de predare. Presiunea sporită asupra dezvoltatorilor de programe face ca acestia să nu se mai multumească doar cu un compilator foarte rapid; dezvoltarea este frînată de numerosi factori si solutiile însumate pot duce la salturi spectaculoase de productivitate.
Object Pascal dispune de avantajele traditionale 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 functii, bucle goale si nepotriviri de tipuri. Analizorul sintactic a devenit mai subtil, permitîndu-si sugestii utile mai ales programatorilor începători.
Tot acestia din urmă au tendinta de a comasa întregul cod într-o singură unitate greu de întretinut si depanat. Pentru a-l încuraja sa-si separe în mod logic munca în unităti distincte cu interfete strict delimitate, Delphi le oferă selectia vizuală a unitătilor care se includ în clauza uses.
Următorul pas logic pentru încurajarea programării modulare a fost referinta automată la componente continute în forme diferite. Desi proprietătile 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 si relatiile dintre acestea de modulele care implementează interfața cu utilizatorul.
În acelasi 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 interactiune 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 continute de acesta pot fi referite apoi din diverse alte forme.
Poate cea mai importantă obiectie a programării obiectuale fată de tehnica vizuală a precedentei versiuni a lui Delphi a fost imposibilitatea de a deriva noi forme prin mostenirea celor existente. Este natural într-un mediu complex de proiectare să creezi obiecte standard, din care urmează să fie derivate obiecte concrete care să mostenească 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 mostenirii vizuale se pot crea în faza de design noi forme care să preia proprietătile, evenimentele si metodele formei originale pe oricîte nivele de mostenire, fără a induce penalizări de performantă în aplicatia 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 retea locală. Tot aici pot fi stocate module de date, biblioteci DLL sau experti. Orice aplicatie poate mosteni, referi sau copia un obiect din Object Repository.
3.1.6. Controale pentru Windows
Între cele aproape 100 de componente din paleta lui Visual Component Library se regăseste 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 afisării unei ierarhii de obiecte, ListView pentru prezentarea pe coloane a unei liste de obiecte, ImageList care controlează o listă de imagini pentru afisare arborescentă sau pe coloane, HeaderControl pentru plasarea de bare de control pe spatiul de lucru, RichEdit – un editor de text cu facilităti extinse de formatare, StatusBar – zonă plasată în partea inferioară a ferestrelor destinată afisării situatiei curente a aplicatiei, TrackBar – o îmbunătătire sub formă de potentiometru a clasicului scrollbar, ProgressBar – similar cu TGauge si destinat afisării progresului unei proceduri, UpDown – butoane de incrementare / decrementare a unei valori, si în fine, HotKey – conceput pentru atasarea facilă a unor combinatii de taste active pentru orice component.
Prin draparea lor în componente, programatorul este scutit de frecusul cu interfața noduroasă de nivel procedural. Cînd este necesar un nivel superior de functionalitate, dezvoltatorii pot implementa propriile lor metode, proprietăți si componente prin mostenire. 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 întelegerea comportamentului specific al obiectelor de interfată.
3.1.7. Suport extins pentru aplicatiile de baze de date
Numeroase sînt extensiile de baze de date care pot fi regăsite în actuala versiune de Delphi si care usurează considerabil surmontarea problemelor specifice ridicate de proiectele de baze de date.
Dictionarul de date stochează si utilizează informatia despre continutul si comportamentul datelor din tabele. Aici se pot specifica atribute extinse de cîmpuri precum valorile minimă, maximă si implicită, optiunile de formatare în afisare 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ăti si evenimente de filtrare dinamică a datelor si oferă evenimente suplimentare pentru tratarea extinsă a erorilor. Există o proprietate care permite utilizarea facilitătii 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ă obtinerea 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ătit cu o formă specială de query – TUpdateSQL – care preia operatiunile de stergere, 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 atentie 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ătit cu facilităti 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 spatiu de afisare în care se pot plasa toate celelalte tipuri de controale de date pentru editarea cîmpurilor. Afisarea 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 resimtea puternic absenta unui set de componente pentru dezvoltarea vizuală de rapoarte. Greul Report Smith era în mod evident destinat aplicațiilor de corporatie bazate pe server-e SQL, fără a se potrivi cu necesitătile unei aplicații desktop. Din fericire industria shareware a produs rapid cîteva asemenea solutii, dintre care Borland a cumpărat-o pe cea mai reusită 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 initializate 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 fisierul executabil sub formă de resurse, rapoartele sînt complet inaccesibile utilizatorului final pentru modificări.
3.1.8. Performanțele obtinute de programele 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 obtinute de programele Delphi de baze de date, aceleasi de altfel cu cele obtinute cu Paradox sau Visual dBASE. BDE comportă o arhitectură obiectuală care permite un acces simplu si nativ din limbajele obiectuale la functiile î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 preemptiv: mai multe programe pot fi deservite simultan de BDE si pot accesa aceeasi bază de date în acelasi timp. În plus, în cadrul aceluiasi program se pot executa simultan mai multe operatiuni BDE separate în fire de executie diferite. Este posibilă astfel executia 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 conventiei UNC (conventia 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 substantial si au căzut o serie de restrictii 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 functiile de agregare, ca si în clauzele GROUP BY si ORDER BY, precum si utilizarea operatorului UNION. Subseturile de înregistrări returnate de înterogă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ătire care va îndepărta coșmarul multor dezvoltatori de baze de date desktop este suportul tranzactional complet pentru tabele Paradox si dBASE. Modificările tabelelor pot fi grupate într-o tranzactie si efectuate sau anulate integral, asigurînd actualizarea bazei de date de o manieră consistentă si cu păstrarea integritătii referentiale. Driver-ul pentru tabele Paradox este capabil de index secundar unic, index cu ordonare descrescătoare si 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 operatiuni 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 retea.
Dezvoltatorii de aplicații client-server SQL vor aprecia posibilitatea de a monitoriza frazele SQL care se transmit server-ului la fiecare executie 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.
4. Administrarea bazelor de date cu ajutorul mediului Delphi.
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 sis-temelor 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 modalitați de accesare a datelor de care avem nevoie.
4.1. Componentele necesare accesului 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.1 prezintă grupul de componente pentru acces la date furnizate de către mediul Delphi. Aceste componente sunt suficiente pentru a accesa.
Fig. 4.1. Componentele Delphi pentru acces la date sunt destul de puține la număr, si ușor defolosit.
4.2. Descrierea componentelor Delphi pentru accesul la date.
4.2.1. 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.
4.2.2. 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ă careia îi pun o întrebare, iar un tabel este subiectul întrebării.
4.2.3. 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..
4.2.4. 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.
4.2.5. 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.
4.2.6. 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.
4.2.7. 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.
4.2.8. 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.
4.2.9. 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 nici-odată că este necesară o conectare a componentelor DataControl si QuickRpt la o sursă de date.
Fig. 4.1 Componentele Delphi pentru acces la date conlucrează pentru a facilita aplicației dumneavoastră accesul la bazele de date și manipularea conținutului acestora, folosind componentele DataControl și QuickRpt
Figura 4.1 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.2. Transferurile de blocuri de date se pot efectua dintr-o varietate de surse, dar numai către un singur tip de destinație – componente de tip TTable.
4.3. Componentele necesare 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.3 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.3 Există versiuni ale componentelor Delphi de uz general, specializate în lucrul cu sisteme SGBD.
4.4. Descrierea componentelor Delphi pentru controlul datelor.
4.4.1. 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.
4.4.2. TDBNavigator
Configuratia 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, puteti folosi butonul Refresh pentru a actualiza continutul, unui component atașat componentului TDBNavigator.
4.4.3. 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 masură ce vă mutați de la o înregistrare la alta. Un component de tip TDBText necesită alocarea unei cantitaț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 l'olosiț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.
4.4.4. 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ă.
4.4.5. 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 coraponentului 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.
4.4.6. 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.
4.4.7. 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 singnră schimbare în baza de date fiecare element din listă are ca fundamentare baza de date, astfel că actualizarea se face imediat.
4.4.8. 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.
4.4.9. 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".
4.4.10. 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 probabl 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.
4.4.11. 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.
4.4.12. 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ă.
4.4.13. 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 defîniț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.5. Componentele 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 su-plimentare. 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.4 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 îndeplineas-că. 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 tidul 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 tnedii 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.4 Componentele QuickRpt reprezintâ noutatea adusă de versiunea Delphi 5.0.
4.6. Descrierea componentelor Delphi din pagina QuickRpt.
4.6.1. 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.
4.6.2. 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.
4.6.3. 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ă co-municaț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 infonnaț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.
4.6.4. 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.
4.6.5. 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 continutul 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.
4.6.6. 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 continută î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.
4.6.7. 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ă.
4.6.8. 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.
4.6.9. 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).
4.6.10. 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 revbluț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 defuii alt tip de informatii statistice. Nivelul de umbrire a fiecărui tip de informatii 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).
4.6.11. 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âmească 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 (com-ponente 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ățati 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 suprins 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 rapbrt 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. Descrierea sistemului informațional – C.N.E.A.A.I.I.
5.1. Evaluare Academică și Acreditare.
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.Termenii de evaluare vor fi determinați de graficul aprobat de către Guvernul Republicii Moldova. Pentru pregătirea Rapoartelor de autoevaluare vă expediem documentele de bază, executarea cărora este obligatorie.
5.1.1. Legea cu privire la evaluarea și acreditarea instituțiilor de învățământ din Republica Moldova nr. 1257-XIII
din 16 iulie 1997
Parlamentul adoptă prezenta lege.
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.
Dispoziții generale.
Articolul 1. Obiectul legii.
Prezenta lege reglementează procesul de evaluare și acreditare a instituțiilor de învățământ statale și particulare , de toate nivelurile, din Republica Moldova.
Articolul 2. Organul evaluării și acreditării.
(1) 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.
(2) 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.
(3) Componența nominală a Consiliului se stabilește de către Guvern.
(4) 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.
(5) Perioada de activitate a comisiilor specializate se – stabilește de către Guvern.
Criteriile evaluării și acreditării
Articolul 3. 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-fmanciară, 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.
Articolul 4. 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).
Articolul 5. 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.
Articolul 6. Baza tehnico-materială.
(1) Baza tehnico-materială a instituției de învățământ pasibile acreditării trebuie să corespundă standardelor de stat respective.
(2) 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.
5.1.2. Procedura de evaluare și acreditare
Articolul 7. Modul de acreditare și periodicitatea evaluării.
(1) 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.
(2) Procesul acreditării include două etape:
decizia definitivă privind neacreditarea , conducerea ei e în drept să se adreseze instanței judecătorești.
(3) 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.
Articolul 8. Definitivarea studiilor în cazul neacreditării instituțiilor de învățământ.
Elevii și studenții instituției de invăță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.
5.2 Descriirea structurii bazei de date pentru înregistrarea instituțiilor de învățămînt “Registrul Instituțiilor” a sistemului iformațional
“C.N.E.A.A.I.I.”
Baza de date a sistemului informațional “ C.N.E.A.A.I.I.” este împlementată cu ajutorul utilitarul BDE (Borland Database Engine) Configuration. Acest utilitar oferă informație de conectare pentru acces la o bază de date. Folosirea utilitarul Database Desktop ne permite vizualizarea toatelor surselor de date. Utilizînd aceste instrumente, sau creat 6 tabele, în care se păstrează informația referitoară 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 refiritore 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 s.a.m.d sa împlementat 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.
Institutia -instituția la care se referă administrația.
În tabelul SpecAll se păstrează specialitățile la care sunt acreditate instituțile 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ățpmî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 tebelului 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 tabelelor bezei de date poate fi reprezentată în felul următor.
5.3 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 5.3 este pezentată forma principală.
Fig. 5.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 fără meniul programului.
În meniul “Legistația” putem să întroducem sau să efectuem schimbări în nomenclatorul specialităților. Tot aici se aduce la cunoștințe lege despre acreditare instituților 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ților. 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.”.
Forma reacționează la evenimente efectuate de operator prin intermediul procedurilor. Modulul principal conține procedurile de chemare toatelor formelor folosite în program. Meniul principal folosește acestea proceduri cînd reacționează la evenimentele produse de operator. Operația de chemare a formei de înregestrare a instituților este prezentată în codul de mai jos:
procedure TCNEAAII.Editatrea1Click(Sender: TObject);
begin
ShowRegEdit
end;
Procedura TCNEAAII.Editatrea1Click este reacția la click cu mouse pe meniul “Institutia” ->”Registrare”. Scopul acestei proceduri este activizarea formei de înregistrare. Forma de înregistrare la rîndul său reacționează la evenimentele sale. Ea este prezentată în figura 5.4.
Restul procedurilor de chemare este asemănător cu procedura descrisă de mai sus. Aceste proceduri folosesc și butoanele acceleratoare, combinațiile de taste (acceleratoare) pentru activizarea formelor.
Datorită faptului că procedurile sunt asemănătoare nu este necesară descriirea lor detaliată. Pentru a examina codul mudulului principal apelați la anexa 1.0.
Fig. 5.4. Forma de înregistrare a instituției de învățămînt.
Această formă este compusă din componentele TEdit, TButton, TDateTimePicker grupate cu ajutorul componentelor TGroupBox. În afară de aceasta forma conține componentele invizibile TTable, TDataSource și TQuery. Ei controlează accesul la date, dirijarea datelor. Informația despre instituția de învățămînt se introduce cu ajutorul componentelor TEdit. Restul datelor referitori la o instituție se întoduce prin intermediul altor subformi, lansarea cărora permit butoanele de pe forma prezentată în fig. 5.4.
Pentru a înregistra o instituție de învățămînt e necesar de completat cîmpurile : “Denumirea instituției”, “Numărul facultăților”, “Numărul catedrelor”, “Numărul studenților” și “Data acreditării”. După completarea se apasă butonul “Ok”. Dacă cîmpul “Denumirea instituției” va fi lipsit de informație, atunci această instituție nu va fi înregistrată. Restul datelor poate fi introdus în orice moment.
Codul de mai jos prezintă procedura ce se activează la apăsarea butonului “Ok”.
procedure TRegistru.OkButtonClick(Sender: TObject);
begin
if Edit1.Text <> '' then
begin
Table1.Append;
Table1['Institutia']:=Edit1.Text;
Table1['NumarFacult']:=Edit2.Text;
Table1['NumarCatedre']:=Edit3.Text;
Table1['NumarStudent']:=Edit4.Text;
Table1.FieldByName('Data').AsDateTime:=DateTimePicker1.Date;
Table1.Post;
end
else ShowMessage('Introdu denumirea institutiei!');
end;
Algoritmul propus prezintă o procedură standartă de control a datelor. Se controlează conținutul cîmpului “Denumirea instituției”. Dacă este nul atunci programul insistă să introducem denumirea. În alt caz merge un set de atribuiri de date și înscriirea lor în tabela a bazei de date.
Codul deplin a modulului principal formei de înregistrare este prezentat în anexa 2.0.
Fig 5.5. Forma modificării informației despre o instituție de învățămînt.
Forma dată este asemănătoare cu forma de înregistrare instituțiilor descrisă mai de sus. Funcția acestei forme este de a modifica datele referitoare la o instituție de învățămînt deja întroduse. Această formă permite modificarea, adăugarea și ștergerea informației referitoare la o instituție și însuși instituția.
Destinația tastelor “A șterge”, ”A Modifica” este ștergerea și modificarea datelor referitoare la o instituție.
La apăsarea butonului “A șterge” se împlementează următoarea procedură:
procedure TChangeData.DeleteButtonClick(Sender: TObject);
begin
// Se cere confirmarea ștergerii
if Table1.State = dsBrowse then
if MessageDlg('Confirmati stergerea informatiei',
mtConfirmation, [mbYes, mbNo], 0) = mrYes then
begin
Table1.Delete; // Ștergerea datelor despre instituția
// Ștergerea profesorilor titulari referitori la instituția dată
with Query1 do begin
Open;
SQL.Clear;
SQL.Add('DELETE *');
SQL.Add('FROM ProfTitulari ');
SQL.Add('WHERE Institutia LIKE ''' + DBLookupComboBox1.Text +'%''');
ExecSQL
end;
Query1.Close;
// Ștergerea profesorilor prin cumul referitori la instituția dată
with Query1 do begin
Open;
SQL.Clear;
SQL.Add('DELETE *');
SQL.Add('FROM Cumul ');
SQL.Add('WHERE Institutia LIKE ''' + DBLookupComboBox1.Text +'%''');
ExecSQL
end;
Query1.Close;
end;
end;
Procedura cere de la operator confirmarea ștergerii datelor și după aceea se șterge înscriirea din tabelul Registru, pe care este poziționat cursorul:
Table1.Delete;
Următorul pas este ștergerea profesorilor titulari. Pentru aceasta din tabelul ProfTitulari se selectează înscriirile ce se refer la instituția dată. Prin intermediul operatorilor SQL se efectuează selectarea și ștergerea datelor:
SQL.Add('DELETE *');
SQL.Add('FROM ProfTitulari ');
SQL.Add('WHERE Institutia LIKE ''' + DBLookupComboBox1.Text +'%''');
Algoritmul ștergerii profesorilor prin cumul este același numai se în loc de tabelul ProfTitulari se folosește tabelul Cumul.
Procedura de modificare a datelor esti mult mai simplă. Se folosesc metodele standarte de editare și salvare a datelor Edit și Post componentului TTable:
procedure TChangeData.Button2Click(Sender: TObject);
begin
Table1.Edit;
Table1.Post;
end;
Codul deplin al modulului este prezentat în anexa 3.0
Formele de înregistrare și de schimbare a datelor (descrise mai sus) sunt asemănătoare între ele. Ele au forme comune. Adica, apăsînd butoanele din GroupBox “Profesorii” de pe forma de înregestrare sau de pe forma de schimbare a datelor, se activează aceeași formă la Titulari respectiv și la Prin Cumul. Aceste forme sunt descrise mai jos.
Fig. 5.6. Forma pentru manipulare cu date referitoare la profesorii titulari.
Funcția acestei forme este manipularea cu date referitoare la profesorii titulari. Ea este compusă din componentele TButton, TDBGrid, TDBEdit, TDBLookUpComboBox, TDBMemo, TTable, TdataSource, Tquerz, TopenDialog. Forma se completează destul de ușor și rapid. Destinația butoanelor este clară după denumirile lor. Ne oprim la butonul “Import”.
Orice instituție de învățămînt prezintă raportul într-un fel de revistă și o listă de profesori angajați la aceasta instituție. Pentru a ușura lucrul operatorului s-a propus că lista sa fie împlementată într-un tabel Excel. Butonul “Import” importeză datele dintr-un fișier de tip Excel. Adica operatorul apăsînd butonul “Import” indică calea fișierului, într-o formă de dialog standartă pentru deschiderea fișierilor. Prin aceasta operație operatorul nu pierde timp la introducerea datelor referitoare la profesori, așa dar este un cîștig de timp. Iar pentru cazăurile excepționale sunt prevăzute operațiile descrise de mai sus.
Codul procedurii de import este prezentat mai jos:
procedure TProfesorii.ImportButtonClick(Sender: TObject);
var
Sheet: Variant;
_Exit: boolean;
Col, Row: integer;
tmp:string;
begin
OpenDialog1.Execute;
_Exit:=FALSE;
Row:=6; Col:=2;
try
Excel := CreateOleObject('Excel.Application')
except
ShowMessage(“Componentul Excel nu este accesibil”);
Exit
end;
// Dialogul de deschidere a fișierilor
Excel.Workbooks.Add(OpenDialog1.FileName);
// Atribuirea variabelei Sheet poenterul pe prima foaie tebelei din fișierul Excel
Sheet:=Excel.Workbooks[1].Sheets[1];
while _Exit = FALSE do begin
tmp:= Sheet.Cells[Row,Col];
if tmp <> '' then
begin // Atribuirea datelor și salvarea lor
Query1.Append;
Query1['Numele']:=Sheet.Cells[Row,Col];
Query1['AnulNașterii']:=Sheet.Cells[Row,Col+1];
Query1['Stud']:=Sheet.Cells[Row,Col+2];
Query1['AnuAngajării']:=Sheet.Cells[Row,Col+3];
Query1['Funcția']:=Sheet.Cells[Row,Col+4];
Query1['Subdiviziunea']:=Sheet.Cells[Row,Col+5];
Query1['Sarcina']:=Sheet.Cells[Row,Col+6];
Query1['Titlu=tiințific']:=Sheet.Cells[Row,Col+9];
Query1['Specialitatea']:=Sheet.Cells[Row,Col+10];
Query1['Specializarea']:=Sheet.Cells[Row,Col+11];
Query1['TitlulDidactic']:=Sheet.Cells[Row,Col+12];
Query1['Institutia']:=Univer;
Query1.Post;
end
else _Exit:=TRUE;
Row:=Row+1;
end;
Excel.Quit;
end;
În liniile generale această procedură încearcă să creeze obiectul clasului specificat ca parametrul funcției CreateOleObject. Dacă aceasta operație se termină cu succes, programul continue, în caz contrar ne apelează de greșală și importarea datelor este întreruptă. Astfel de cazuri pot apărea cînd pe sistem nu este instalat Microsoft Office și anume programul Excel.
O altă formă asemănătoare cu aceasta este forma de manipularea cu date referitoare la profesorii angajați prin cumul. Ea este compusă din componentele care se folosesc la forma pentru profesorii titulari. Destinația ei este aceeași ca și la forma profesorilor titulari. Ambele forme puțin difera vizual între ele. Diferența constă în două cîmpuri care au destinația sa la formele respective. Aceste cîmpuri sunt evedențiate cu alte culori. Prezentarea acestei forme este arătată în fig. 5.7 de mai jos.
Fig. 5.7. Forma pentru manipulare cu date referitoare la profesorii prin cumul.
Funcția butoanelor “A adăuga”, “A șterge”, “A schimba” este clară după denumirele lor, adica: adăugare, ștergerea, schimbarea datelor. Textul codului de prelucrare la apăsarea acestor butoane este același ca și la forma de profesorii titulari. Procedura de import a datelor este asemănătoare cu cea descrisă de mai sus.
Forma se completează ușor și rapid. Sau elaborat aceste două forme pentru comoditatea introducerii personalului instituției și pentru a reduce volumul tabelelor referitori la ceste forme.
Grupul Acreditare de pe formele registrării și schimbării datelor conține un singur buton “Specialitățile”. La apăsarea acestui buton se activează forma de completare listei de specialități acreditate la instituția dată. În figura de mai jos este reprezentată forma de completare a specialităților.
Fig 5.8. Forma pentru introducera specialităților acreditate la instituția de învățămînt.
Această formă este compusă din componentele: TButton, TLabel, TDBGrid, TQuery și TDataSource. Forma dată conține două listinguri. Unul din ele (stîngul) reprezintă nomenclatorul specialităților adoptat de parlamentul Republicii Moldova, iar altul, lista specialităților acreditate la instituția de învățămînt. Butoanele “Adăugirea” și “Ștergerea” derijază datele referitoare la specialități.
Codul de mai jos descrie procedura de reacționarea la apăsarea butonului de adăugire.
procedure TNomencl.AddButtonClick(Sender: TObject);
begin
Query1.Append;
Query1['Cod']:= Table1['Cod'];
Query1['Naim']:= Table1['Profil'];
Query1['Institutia']:=Univer;
Query1.Post;
end;
Prin intermediul componentului TQuery se atribuie toate datele necesare și se sălvează în tabel. Reacția la apăsarea butonului de ștergere este descrisă mai jos.
procedure TNomencl.DelButtonClick(Sender: TObject);
begin
if Query1.State = dsBrowse then Query1.Delete;
end;
Acesta procedură este mai simplă decît precedentă. Aici iarăși prin intermediul componentului TQuery, folosind metoda standartă al acestuia, se șterg datele din tabelă, pe care se află cursorul.
Toate formele descrise mai de sus prezint lucrul principal al programului. Ele sunt punctele din meniul principal. În afara de meniu, programul conține și un panel de instrumente. Acest panel conține butoane acceleratoare la formele descrise de mai sus.
Mai jos se va descrie funcția unui buton din acest panel, care crează raportul despre instituția de învățămînt. În cadrul acestui raport intră informația generală despre instituția de învățămînt.
Fig. 5.9. Raportul despre o instituție de învățămînt.
Componentul principal al raportului TQuickRep. El însuși și este raportul adica 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 foaia. Acest component deobicei reprezintă titlul raportului.
TQRLabel este un text în raport sau el poate servi ca o denumire a unui cîmp, adica un text static.
TQRDBText afisează o înscriire din tabel pe care se află cursorul. În cazul nostru se afișează datele referitoare la profesori.
Acest raport este un component standart a mediului Delphi. Are funcțile 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ă standartă a sistemului operațional (Windows) a meniului imprimantei. Prin intermediul acestui meniu se configurează imprimanta, calitatea imaginei, foile care se vor tipări ș.a.
6. Protecția muncii și sanitarie de producere
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;
• insuficiența iluminatului natural;
• insuficiența iluminatului locurilor de muncă;
• temperatura ridicată a mediului ambiant;
• 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.
6.1. Zgomotul
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.
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 1:
Tab. 6.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 fîe depășit nivelului admisibil. Intrucâ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.
6.2. Securitatea electrică
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ă.
Legarea la nul este o măsură de protejare 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.
Scopul calculării este 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.
Curentul de scurtcircuit trebuie să fie mai mare de trei ori decât curentul nominal a siguranței Is.c. > 3In
6.3. 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 încăperiuncă 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 6.2.
Tabelul 6.2.
Normele microclimatului.
In 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ă.
6.4. Securitatea antiincendiară
Focul este o forță gigantică. Oamenii antici vedeau în el o sursă a vieții și în prezent el încălzește și hrănește doar cu acea diferență că pentru contemporanul nostru la nivelul actual de dezvoltare a condițiilor sociale că această întrebare a scăzut cu mult. însă acest fapt nu ne permite să neglijăm focul, doar o mică neatenție și marea lui forță poate aduce o nenorocire. Iată de ce e atât de important rolul securității antiincendiare în organizarea protecției muncii la întreprinderi și în încăperi administrative.
Incendiul se numește arderea necontrolată în afara unui focar special care aduce pierderi materiale. Dacă această ardere nu cauzează pierderi materiale, atunci ea se numește inflamare.
Explozia este o transformare chimică momentană, caracterizată prin degajarea de energie și crearea de gaze comprimate.
După gradul de ardere (oxidare însoțită de degajarea unei cantități mari de căldură) materialele de construcție se împart în următoarele tipuri: nearzătoare – sub acțiunea focului nu se inflamează, nu se corodează; greu inflamabile – sub acțiunea focului nu se inflamează, se carbonizează doar în prezența sursei de inflamare, iar după lichidarea ei arderea sau carbonizarea încetează (materialele se gips sau beton, materiale din argilă); inflamabile – sub acțiunea focului se inflamează și se carbonizează și continuă acest proces și după lichidarea sursei de inflamare (toate materialele organice, ce nu corespund cerințelor indicate anterior).
Materialele, ce posedă capacități ridicate de inflamabilitate se numesc periculoase din punct de vedere incendiar, iar capabile de explozii și detonare fară participarea oxigenului.
Cauzele incendiilor și exploziilor după caracter pot fi: electrice și neelectrice. La categoria electrice se referă: scânteia în aparatele electrice, descărcările electrostatice, fulgerele ș.a.
Cauzele incendiilor și exploziilor cu caracter neelectric pot fi: exploatarea incorectă a aparatului de sudură cu gaz, pistoalele de lipit, dereglarea dispozitivelor de încălzire, a echipamentului de producție, încălcarea procesului tehnologic ș.a.
In dependență de procesele tehnologice și proprietățile materialelor după gradul de pericol incendiar și exploziv încăperile și clădirile se împart în cinci categorii A, B, V, G, D în conformitate cu normele proiectării tehnologice.
Aceste categorii sînt stabilite și aprobate de către ministerele ramurilor corespunzătoare. Majoritatea clădirilor industriei radioelectronice se referă la categoria V.
Clădirile și edificiile se împart după gradul de stabilitate antiincendiară (SNIP 201.02-85), care se determină de limitele minimale de stabilitate incendiară ale construcțiilor de bază și limitele maximale de răspțndere în ele a focului. Aceste limite se determină în baza testării probelor în cuptoare speciale.
Protecția antiincendiară a obiectelor naționale este reglementată de STAS 12.11.033-81 "Cerințe generale", normelor și regulilor constructive, regulilor protecției antiincendiare a ramurii.
Factorii principali pentru viața omului ce apar în timpul incendiului sunt: focul deschis, temperatura ridicată a aerului și a obiectelor, produsele toxice ce ard, fumul, micșorarea concentrației de oxigen în aer, distrugerea încăperilor, echipamentului și explozia.
Pentru prevenirea incendiului trebuie luate următoarele măsuri: – excluderea apariției mediului arzător; – excluderea apariției în mediul arzător a surselor de inflamare;
– menținerea temperaturii și presiunii mediului arzător mai jos de nivelul maxim admisibil de ardere.
Pentru prevenirea incendiului sunt aplicate un șir de măsuri. Barajele antiincendiare din clădiri și edifîcii la care se referă pereții antiincendiari, barajele și acoperirile antiincendiare, ușile și altele trebuie să fie executate din materiale ne inflamabile și de asemenea să fie prevăzută autoînchiderea lor. Ferestrele antiincendiare nu trebuie să aibă posibilitate de deschidere.
Pentru anunțul incendiului se utilizează legăturile radio și telefonice, sirenele, traductoare de semnalizare a incendiului. Fiecare unitate economică trebuie să dispună de mijloace de legătură pentru chemarea urgentă a pompierilor. Toate mijloacele de legătură antiincendiare trebuie să aibă acces deschis în orice timp.
Cel mai răspândit și ieftin mijloc de stingere a incendiului este apa care permite consumarea efectivă a căldurii arancate de focarele de incendiu. Totodată apa nu poate fi folosită pentru stingerea lichidelor ușor inflamabile (benzină, gazul lampant, uleiuri minerale) și a materialelor care în contact cu ea elimină substanțe inflamabile (carbonatul de calciu).
în încăperile închise pentru lichidarea incendiului se recomandă utilizarea vaporilor de apă atât pentru stingerea materialelor solide cît și a substanțelor lichide.
In condițiile de laborator pentru stingerea incendiului poate fi folosit instinctorul cu volumul de șapte litri ce conține 97% etil bromic și 3% soluție de oxid carbonic. Componența aflată sub presiune în timpul utilizării se elimină sub formă de spumă. Durata funcționării este de circa 40s, distanța de aplicare -4-5 metri. El se utilizează la stingerea instalațiilor electrice aflate sub tensiune, deoarece brom etilul nu conduce curentul electric. Pentru protecția oamenilor de produsele toxice ale arderii și de fum se utilizează ventilatoarele și canalele de ventilare.
6.5. 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 tab 6.3.
Tab. 6.3.
Niveluri admisibile de tensiune.
Controlul radiației de toate tipurile se efectuează în confonnitate cu regulile ce sunt expuse în îndrumare speciale.
6.6. Parametrii vizuali a imaginii
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.
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 6.4.
Tabelul 6.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.
6.7. Efecte psihofiziologice
Lucrul operatorilor cere încordarea mintală și emoțională foarte mare, concentrarea atenției și responsabilitatea de lucrul efectuat. Operatorii foarte des suferă de diferite stări proaste a vederii, dureri de cap, dureri de mușchi în regiunea spatelui. în afară de asta, în mare măsură se exprimă senzația oboselii și încordarea mintală în timpul lucrului; ei nu se simt odihniți după somn de noapte.
Sarcina asupra vederii și caracterul încărcării lucrului provoacă la operatori disflmcția stării a analizatorului de vedere și sistemei nervoase centrale. în procesul de lucru la dânșii se micșorează rezistența vederii clare, sensibilitatea electrică și labilitatea analizatorului de vedere, și încă apar disfuncții a mușchilor ochilor.
Sunt interesante cercetările stării psihofiziologice a operatorilor de introducere a datelor, care efectuează lucrul monoton în timp de 2 ore în condiții favorabile de muncă. Totodată s-a arătat că din 80% de persoane supuse experienței capacitatea de lucru și activitatea mintală se micșorează peste 45 – 60 minute de lucrului neîntrerupt. în afară de aceasta la persoanele supuse experienței la sfârșitul zilei de lucru sa mărit timpul de reacție și cantitatea greșelilor la executarea problemelor. S-a micșorat frecvența de contractare a inimii de la 64 până la 40 batăi/min; la 74% persoane s-a tulburat bilanțul mușchilor ochiului.
Efectuarea multor operații la CC cer încărcarea îndelungată a mușchilor spatelui, gâtului, mâinilor și picioarelor ce aduce la apariția oboselii. Motive principale de apariția oboselii sunt înălțimea irațională a suprafeței de lucru, masei și scaunului, lipsa spatelui de prijin și brațelor, unghiuri incomode de îndoire în articulațiile umărului și cubitului, unghiul de înclinare a capului, repartizare incomodă a documentelor, monitoarelor și tastaturii, lipsa spațiului și suportului pentru picioare.
6.8. 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 iluminâtului 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 amplasarii 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.
6.9. Calcularea iluminatului artificial a încăperii.
Pentru organizarea activității normale a omului o mare însemnătate are crearea condițiilor normale de iluminare naturală și artificială la locul de muncă.
Iluminarea de producție, corect proiectată și îndeplinită, aduce la rezolvarea uirmătoarelor probleme:
– ea îmbunătățește condițiile de muncă, micșorează oboseala, contribuie la creșterea productivității muncii și a calității producției, acționează binefacător asupra mediului de producere, acționează pozitiv din punct de vedere psihologic asupra lucrătorului, ridică securitatea muncii și micșorează traumatismul în producție.
Analizatorul vizual percepe, ca lumină, pscilațiile electromagnetice cu lungimea de undă 380-770 nm.
Iluminarea optimă se alege în dependență de particularitățile (coeficientul de reflecție) suprafeței de lucru și detaliile ce sunt analizate pe ea (lungimea perioadei de lucru vizual, precizia, caracterul procesului de lucru).
O cerință importantă este menținerea regimului de iluminare. La iluminarea artificială devierile în rețea nu trebuie să depășească + 2.5 – 3 %.
Prin norme sunt introduse valorile minimale a iluminării care permit realizarea cu succes a lucrului vizual.
în dependență de sursa de lumină, iluminarea de producere poate fi de două tipuri: naturală (lumina de zi) și artificială, generată de lămpile electrice.
Iluminatul artificial poate fi de lucru, de pază, de serviciu, de evacuare, de avarii.
Iluminatul de lucru poate fi local, total și combinat.
Este interzis de a folosi la întreprinderile mari iluminatul local, deoarece el trebuie să constituie nu mai puțin de 10 % din iluminatul total.
Normarea iluminatului artificial se efectuează de SNiP-II-4-79.
La fel se normează iluminarea locurilor de muncă în funcție de :
1. categoria lucrului vizual
a) precizie înaltă E =5000 lx
b) fară precizie E =30 lx
2. în dependență de tipul de iluminat, adică total sau local.
3. în dependență de fon.
4. în dependență de contrast.
Raportul dintre fon și contrast indică subcategoria (a,b,c,d).
Iluminatul artificial există datorită becurilor incadiscente și fluoriscente.
Deci după cum știm, iluminatul natural este schimbător în timp sau chiar poate să nu existe, de aceia se folosește iluminatul artificial, iar pentru instalarea corectă a iluminatului artifîcial se fac careva calcule.
Calcularea iluminatului artificial se face conform metodei randamentului de flux de lumină.
După această metodă se găsește fluxul de lumină a becurilor care asigură iluminarea locurilor de muncă, normarea
F = ————————————
unde:
Sp – suprafața podelei En – iluminarea normată minimală, 500 lx (precizie mijlocie)
z – coeficientul iluminării neuniforme, Z= 1.1-1.2
Kr – coeficientul de rezervă, se ține cont de tipul de becuri și de tipul de încăpere.
N – numărul de instalații de iluminat
n – numărul de becuri într-o instalație
K uf – coeficientul utilizării de către lampele radiante a fluxului de lumina pe suprafața calculată.
Se determină în dependență de tipul becului, coeficientului de reflectare a podelei, pereților, tavanului, indicile încăperii:
AxB
l= hx(A + B)xHum
unde
A,B – dimensiunile încăperii
h – înălțimea suspensiei lămpilor de aspra suprafeței de lucru.
|I Kum – coeficientul de umbrire, se introduce pentru încăperile cu poziția fixă a lucrătorilor, și este egal cu 0.8-0.9.
înălțimea lampei asupra ariei de iluminare se calculează după formula:
Hc=H-Hi-Ht; unde
H – înălțimea încăperii 4,00 m.
hi- distanța de la pod până la partea de jos a lampei, 0,5 m
Ht- distanța de la podea până la suprafața iluminată, 0,75 m
Hc=4,00 – 0,10 – 0,75 = 3,15 m Calculăm i,
10.00×6.50 *~3.15x(lO.OO + 6.50)x0.85~
Având coeficientul de reflectare a tavanului și pereților egal cu 0.7 și după indicile calculat i, coeficientul de folosire a fluxului de lumină din tabel egal =0,30
Calculăm
F 300×1.5x65x1.2 F = —————————— = 5228 Im 10x2x0.373×0.9
Pentru iluminare utilizăm 10 instalații a câte 2 becuri fiecare. Alegem cea mai apropiată lampă de tipul EA-80 cu fluxul de lumină 5220 lm care asigură pe deplin iluminarea centrului de calcul.
6.10. Ecologia.
Elaborarea și exploatarea produselor soft este una din cele mai curate din punct de vedere ecologic activitatea de producere a oamenilor. Sunt utilizate numai surse de energie electrică. Hârtia nu se utilizează în cantități mari, și ea poate fi ușor reciclată după utilizare. Calculatoarele nu poluează mediul în tipul exploatării.
Bibliografie
В. В. Фаронов. Delphi 5. Руководство программиста. “Нолидж”, Москва 2000.
П. В. Шумаков В. В. Фаронов. Delphi 4. Руководство разработчика баз данных. “Нолидж”, Москва 1999.
ANEXE
Anexa 1
Sursa fișierului unit1.pas
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Menus, Unit2, Unit3, Unit4, Unit5, Unit6, Unit10, Unit11,
Unit12, Unit14, Unit16, Unit17, Buttons, jpeg, ExtCtrls, StdCtrls,
ToolWin, ComCtrls;
type
TCNEAAII = class(TForm)
MainMenu1: TMainMenu;
Tabele1: TMenuItem;
Specialitatea1: TMenuItem;
specialitatea2: TMenuItem;
Institutia1: TMenuItem;
Registrarea1: TMenuItem;
Info1: TMenuItem;
Editatrea1: TMenuItem;
Zapros1: TMenuItem;
Profesorii1: TMenuItem;
Reiting1: TMenuItem;
Cautarea1: TMenuItem;
Criterii1: TMenuItem;
Titulari1: TMenuItem;
Princumul1: TMenuItem;
Help1: TMenuItem;
Image1: TImage;
Contents1: TMenuItem;
N1: TMenuItem;
About1: TMenuItem;
Index1: TMenuItem;
Image2: TImage;
Image3: TImage;
Image4: TImage;
Image5: TImage;
Image6: TImage;
Label1: TLabel;
ToolBar1: TToolBar;
SpeedButton6: TSpeedButton;
SpeedButton7: TSpeedButton;
SpeedButton8: TSpeedButton;
SpeedButton9: TSpeedButton;
SpeedButton10: TSpeedButton;
procedure Specialitatea1Click(Sender: TObject);
procedure specialitatea2Click(Sender: TObject);
procedure Specializarea1Click(Sender: TObject);
procedure Info1Click(Sender: TObject);
procedure Registrarea1Click(Sender: TObject);
procedure Editatrea1Click(Sender: TObject);
procedure Profesorii1Click(Sender: TObject);
procedure Princumul1Click(Sender: TObject);
procedure Criterii1Click(Sender: TObject);
procedure SpeedButton2Click(Sender: TObject);
procedure SpeedButton3Click(Sender: TObject);
procedure SpeedButton4Click(Sender: TObject);
procedure SpeedButton1Click(Sender: TObject);
procedure SpeedButton5Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
CNEAAII: TCNEAAII;
implementation
{$R *.DFM}
procedure TCNEAAII.Specialitatea1Click(Sender: TObject);
begin
ShowProfil
end;
procedure TCNEAAII.specialitatea2Click(Sender: TObject);
begin
ShowSpecialitate
end;
procedure TCNEAAII.Specializarea1Click(Sender: TObject);
begin
ShowSpecializare
end;
procedure TCNEAAII.Info1Click(Sender: TObject);
begin
ShowInfo
end;
procedure TCNEAAII.Registrarea1Click(Sender: TObject);
begin
ShowReg
end;
procedure TCNEAAII.Editatrea1Click(Sender: TObject);
begin
ShowRegEdit
end;
procedure TCNEAAII.Profesorii1Click(Sender: TObject);
begin
ShowZapros
end;
procedure TCNEAAII.Princumul1Click(Sender: TObject);
begin
ShowZapros2
end;
procedure TCNEAAII.Criterii1Click(Sender: TObject);
begin
ShowSearch
end;
procedure TCNEAAII.SpeedButton2Click(Sender: TObject);
begin
ShowUniRap
end;
procedure TCNEAAII.SpeedButton3Click(Sender: TObject);
begin
ShowReg
end;
procedure TCNEAAII.SpeedButton4Click(Sender: TObject);
begin
ShowRegEdit
end;
procedure TCNEAAII.SpeedButton1Click(Sender: TObject);
begin
ShowProfForm
end;
procedure TCNEAAII.SpeedButton5Click(Sender: TObject);
begin
ShowSearch
end;
end.
Anexa 2
Sursa fișierului unit2.pas
unit Unit2;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Grids, DBGrids, Db, DBTables, StdCtrls, Mask, DBCtrls;
type
TProfil = class(TForm)
DataSource1: TDataSource;
Table1: TTable;
DBGrid1: TDBGrid;
OkButton: TButton;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
AddButton: TButton;
ChangeButton: TButton;
DelButton: TButton;
InsertButton: TButton;
procedure AddButtonClick(Sender: TObject);
procedure ChangeButtonClick(Sender: TObject);
procedure DelButtonClick(Sender: TObject);
procedure InsertButtonClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Profil: TProfil;
function ShowProfil: boolean;
implementation
{$R *.DFM}
function ShowProfil: boolean;
begin
with TProfil.Create(Application) do
try
Result := ShowModal = mrOk;
finally
Free;
end;
end;
procedure TProfil.AddButtonClick(Sender: TObject);
begin
//if Table1.State = dsBrowse then
DBEdit1.ReadOnly:=FALSE;
DBEdit2.ReadOnly:=FALSE;
Table1.Append;
end;
procedure TProfil.ChangeButtonClick(Sender: TObject);
begin
if Table1.State = dsBrowse then
begin
DBEdit1.ReadOnly:=FALSE;
DBEdit2.ReadOnly:=FALSE;
Table1.Edit;
end;
end;
procedure TProfil.DelButtonClick(Sender: TObject);
begin
if Table1.State = dsBrowse then
if MessageDlg('Confirmati stergerea informatiei',
mtConfirmation, [mbYes, mbNo], 0) = mrYes then
Table1.Delete;
end;
procedure TProfil.InsertButtonClick(Sender: TObject);
begin
DBEdit1.ReadOnly:=FALSE;
DBEdit2.ReadOnly:=FALSE;
Table1.Insert;
end;
end.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Proiectarea Si Elaborarea (ID: 148771)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.