Elaborarea Si Implementarea Sistemului Informational

CUPRINS

Introducere 7

1. SQL Server – InterBase 9

1.1 SGBD InterBase 9

1.2 Funcționalitate relațională completă 9

1.3 Câteva caracteristici ale SGBD InterBase 12

1.4 Performantă InterBase 13

1.5 Arhitectură scalabil si flexibilă 14

2. Descrierea generală a instrumentarului CASE – ERwin 16

2.1 Datele generale 16

2.2 Structura procesului de modelare în ERwin 16

2.3 Crearea modelului logic al bazei de date 17

2.4 Crearea modelului fizic al bazei de date 17

2.5 Generarea schemei bazei de date 18

3. Mediul de dezvoltare rapidă a aplicațiilor – Borland Delphi 19

3.1 Dezvoltarea rapidă a aplicațiilor 19

3.1.1. Un model pentru alegere 19

3.1.2. Punerea în practică a noilor tehnologii 20

3.1.3. Un nou model de furnizare al aplicațiilor 20

3.1.4. Nevoia de RAD 21

3.1.5. Fundamentele 22

3.1.6. Anatomia unui instrument RAD 23

3.1.7. Controverse 25

3.2 Strategia Borland Delphi 27

3.3 Obiectivele Delphi 28

3.4 Arhitectura compilatorului de cod optimizat pe 32 biți 28

3.5 Suport complet pentru controale si automatizare OLE 29

3.6 Cei 32 biți de la Microsoft 30

3.7 Mai multã productivitate 31

3.8 Tratarea excepțiilor 32

3.9 Controale Windows 33

3.10 Suport extins pentru aplicațiile de baze de date 34

3.11 Mai multã putere în motorul de baze de date 35

4. Descrierea limbajului structurat de interpelare SQL 38

4.1 Noțiuni generale 38

4.2 Componența limbajului SQL 39

4.3 Operații relaționale. Comenzile limbajului de manipulare cu datele 40

4.4 Modalitatea realizării SQL în Delphi 44

4.4.1. Mecanismul de funcționare a cererilor în aplicațiile BD Delph 44

4.4.2. Componenta TQuery 45

5. Descrierea sistemului informațional "Registratorul" al Camerei Înregistrării de Stat 50

5.1 Descrierea structurii bazei de date a sistemului informațional 50

5.1.1. Descrierea câmpurilor tabelelor din baza de date. 54

5.2 Descrierea programului "Registru" al sistemului informațional 68

5.3 Descrierea programului "RegistruSet" al sistemului informațional 80

6. Partea economică a proiectului. 81

6.1 Planificarea rețea pentru elaborarea SI “Registratorul” 81

6.2 Evaluarea economică a sistemului informațional “Registratorul”. 92

6.3 Evaluarea eficacității de la implementarea SI “Registratorul” 97

7. Protecția muncii și sanitarie de producere 99

7.1 Zgomotul 100

7.2 Securitatea electrică 101

7.3 Microclimatul 101

7.4 Securitatea antiincendiară 102

7.5 Radiație 104

7.6 Parametrii vizuali a imaginii 105

7.7 Efecte psihofiziologice 107

7.8 Iluminatul 107

7.9 Calcularea iluminatului artificial a încăperii. 108

7.10 Ecologia 111

Concluzii 112

Bibliografia 113

ANEXE 114

Anexa 1 Secvențe ale programului "Registru" care controlează în care câmp a fost modificată informația întreprinderii. 114

Anexa 2 Secvențe a programului "Registru" pentru afișarea informației întreprinderii 119

Anexa 3 Secvențe a programului "RegistruSet"ale păstrării calei bazei de date 123

Anexa 4 Schema generală a structurii bazei de date "Registru de stat" 124

Anexa 5 Schema generală a tabelelor informaționale 125

Anexa 6 Structura detaliată a tabelelor ce conțin informația actuală 126

Anexa 7 Bloc-schema a procesului înregistrării de stat 127

Anexa 8 Forma de introducere/modificare a datelor întreprinderii 128

Anexa 9 Diagrama interacțiunii elementelor programului "Registru" 135

=== DIPL ===

CUPRINS

Introducere

În era pe care o trăim, era tehnologiilor informaționale, informația este o componentă esențială în desfășurarea oricărei activități. Prin informație se subînțelege – cunoștințe despre un obiect, proces sau fenomen. Deoarece influențează procesul de luare a deciziilor, informația trebuie să fie disponibilă în timp util, corectă, coerentă și neredundantă. Toate aceste cerințe trebuie satisfăcute în condițiile în care volumul datelor ce trebuie prelucrate este în continuă creștere. Evident, sânt necesare sisteme care să asigure culegerea, memorarea, organizarea, regăsirea și prelucrarea acestui volum enorm de date.

Alegerea sistemului de gestiune a bazei de date este un lucru foarte dificil, deoarece trebuie de ținut cont de posibilitățile diferitor SGBD, de necesitățile lor pentru lucru(partea tehnică) și costul lor. Pentru implementarea bazei de date a sistemului informațional am ales SGBD InterBase, care e destinat pentru păstrarea și prelucrarea unor volume mari de informație, în condițiile lucrului concomitent cu baza de date a mai multor aplicații client.

Organizațiile guvernamentale, economice și întreprinderile recunosc rolul central pe care aplicațiile software îl joacă în cadrul organizațiilor. Astăzi aplicațiile sânt folosite pentru reducerea costurilor, modernizarea operațiilor, îmbunătățirea serviciilor și asigurarea unui avantaj strategic față de competiție. Departamentele informatice sânt tot timpul sub presiune pentru a dezvolta repede aceste aplicații critice. Cum pot ei să satisfacă aceste cerințe în timp ce bugetele și echipele de dezvoltare sînt în diminuare? Răspunsul este în alegerea unui mediu de dezvoltare RAD(Rapid Application Development) – instrument de dezvoltare rapidă a aplicațiilor. RAD este o soluție propusă de industria de software pentru ieșirea dintr-o criză, provocată de creșterea exponențială a complexității aplicațiilor moderne. În general se vorbește despre RAD ca despre niște instrumente vizuale de dezvoltare. Cu ajutorul lor se pot desena ferestre de dialog, forme de intrare, machete de rapoarte. Oricât de departe ar merge însă facilitățile vizuale oferite, ele nu elimină nevoia folosirii unui limbaj de programare. În mediul integrat de dezvoltare Delphi, utilizat pentru implementarea sistemului informațional "Registratorul", limbajul de programare utilizat este Object Pascal.

Sistemul informațional "Registratorul" este un sistem unic integrat de evidență a întreprinderilor și organizațiilor înregistrate în Republica Moldova și este elaborat la comanda Camerei Înregistrării de Stat al Republicii Moldova. Scopul "Registratorului" este înregistrarea de stat a întreprinderilor și organizațiilor. Prin înregistrarea de stat se subînțelege – certificarea din partea organului înregistrării de stat a creării, reorganizării ori lichidării întreprinderii sau organizației, precum și a modificărilor și completărilor din documentele de constituire ale acestora. Toate datele necesare pentru înregistrarea de stat se păstrează în baza de date a sistemului informațional "Registratorul".

SQL Server – InterBase

SGBD InterBase

Atât în cadrul mediului de dezvoltare de aplicații (Delphi) cât si pentru exploatarea aplicațiilor, Borland oferă ca o componentă propriul sistem de gestiune baze de date relaționale: InterBase. Sistemul de gestiune de baze de date relaționale (SGBD) InterBase este baza de date aleasă de mulți utilizatori de aplicații dezvoltate în Borland Delphi. SGBD InterBase oferă înaltă performantă la un preț avantajos fiind o alternativă la alte SGBD-uri bine cunoscute.

SGBD InterBase:

este un sistem de gestiune baze de date relațional implementat pe majoritatea sistemelor de operare.

asigură o performantă mare aplicațiilor complexe cu volum mare de tranzacții.

este foarte ușor de instalat, configurat si administrat.

oferă un raport preț/performantă foarte bun.

SQL-server InterBase e destinat pentru prelucrarea și păstrarea unor volume mari de informație în condițiile lucrului concomitent cu baza de date a mai multor aplicații client.

Funcționalitate relațională completă

SGBD InterBase include toată funcționalitatea unui SGBD modern, inclusiv blocare la nivel de înregistrare, recuperare "roll-back" si "roll-forward", gestiunea tranzacțiilor pe baze de date distribuite prin "two phase commit", backup on-line (salvarea bazei de date fără a fi necesară oprirea aplicațiilor ce o utilizează), suport pentru standardul ANSI SQL.

mecanismul de recuperare "roll-back" – În cazul în care o tranzacție se termină anormal (din cauza unui defect în rețea sau a căderii sistemului), ea este automat anulată la repornirea sesiunii InterBase. Mecanismul “roll-back” se bazează pe fișierul “before-image” în care se salvează starea bazei de date înaintea începerii tranzacției.

mecanismul de recuperare "roll-forward" – În cazul în care o bază de date a devenit inutilizabilă (datorită unei defecțiuni pe disc, de exemplu), aceasta poate fi refăcută prin restaurarea ultimei salvări si reprocesarea tranzacțiilor efectuate de atunci până în momentul avariei (acestea sunt păstrate într-un fișier jurnal numit "after-image".

Pentru definirea relațiilor de integritate în baza de date se definesc:

relațiile de supunere între tabelele BD, prin stabilirea cheilor primare(PRIMARY) la tabele de tip părinte(PARENT) și cheilor externe(FOREIGN) la tabele de tip copil (CHILD)

constrângerile către valorile unor coloane(CONSTRAINT)

trighere(TRIGGER) – subrutine, rulate automat de către server până sau-și după evenimentul de modificare a înregistrării în tabelul BD

generatoarele (GENERATOR) pentru crearea și utilizarea valorilor unice a câmpurilor necesare.

Pentru accelerarea lucrului aplicațiilor client cu BD pot fi definite procedurile stocate, care prezintă subrutine ce au parametrii de intrare-ieșire și sunt capabile să execute o instrucțiune către BD. Procedurile stocate se scriu într-un limbaj algoritmic special. În ele se programează instrucțiunile des utilizate. Textul procedurilor se păstrează pe server.

Pentru asigurarea rapidității de executare a interpelărilor și excluderea acestor interpelări din aplicația client, în BD se poate de definit tabele virtuale (VIEW), în care se asamblează înregistrările din una sau mai multe tabele, respectându-se o cerință concretă. Lucrul cu un tabel virtual cu nimic nu se deosebește de lucrul cu un tabel obișnuit.

Sistemul de gestiune a bazei de date (SGBD) InterBase prezintă implementarea modernă a bazelor de date relaționale, bazate pe tranzacții. SGBD InterBase poate prelucra în paralel atât un volum mare de tranzacții mici cât și tranzacții cu prelucrarea de lungă durată datelor. InterBase are o tehnologie unică de delimitare a tranzacțiilor, care nu blochează comenzile de citire și înscriere, fiindcă tranzacțiile nu necesită blocarea tuplelor folosite. Și aceste tranzacții nu necesită programare adăugătoare.

Arhitectura sa SuperServer mărește performanța și optimizează resursele sistemului, în special pentru un număr mare de utilizatori, fiindcă este realizată pe prelucrare în procese paralele. Un concept de bază a arhitecturii SuperServer este colectarea centralizată a informației despre utilizatori, a statisticii despre Baza de Date și apelurile clienților. Aceasta permite păstrarea informației des utilizate în cache și îmbunătățește timpul de răspuns.

Instalarea serverului necesită doar 10 MB de memorie ceea ce ne permite să nu ne gândim la spațiu liber la instalare. Alt lucru la care nu trebuie de pierdut timpul este ajustarea parametrilor, fiindcă InterBase optimizează tranzacțiile pentru d-stă.

Să enumerăm unele din posibilitățile principale:

notificatorii de evenimente;

trighere;

proceduri stocate;

restricții de integritate a datelor.

Notificatorii de evenimente permit de a notifica pe cineva în cazul apariției unui eveniment concret, fără a apela Baza de Date în continuu. De exemplu, InterBase poate notifica un manager, prin e-mail, că în stoc se termină un produs oarecare.

Trigherele pot să asigure respectarea business regulilor pe server, astfel toate aplicațiile ce folosesc date corporative respectă aceste reguli automat. Cu atât mai mult că trigherele pot să automatizeze răspunsurile la evenimente pe server, de exemplu să ceară validarea datelor când un tuplu este schimbat.

Procedurile stocate permit mărirea vitezei de răspuns prin delegarea lucrărilor de rutină de la client la server. Totodată procedurile stocate încurajează proiectarea modulară și fac exploatarea și reutilizarea mai simplă și mai sigură prin limitarea operațiilor la cele definite în proceduri. Funcțiile definite de utilizatori extind capacitățile de calcul și posibilitățile de creare a operațiilor business dorite. InterBase are o bibliotecă de funcții standarde gata, astfel nu va trebui să începeți de la zero.

Restricțiile de integritate a datelor fac posibil menținerea relațiilor dintre tuplele păstrate în Baza de Date. InterBase asigură patru tipuri de restricții de integrității datelor:

Unique și Primary Key: asigură să nu existe două tuple cu același valori pentru o mulțime de coloane;

Integritatea referințelor în cascadă: validează relațiile părinte-copil între tabele pentru asigurarea sincronizării și modificările sau ștergerile în cascadă;

Check: condiția asociată va fi validată pentru orice tuplu al tabelului;

Domain: permite crearea tipurilor noi de date și specificării integrității la nivel de coloane. Domeniile pot fi utilizate pentru a specifica un segment de valori acceptabile sau o listă de valori valide și o valoare implicită. Aceasta înseamnă că după definirea domeniului, el poate fi utilizat în orice loc al aplicației ca o referință la un tip de date mai sofisticat.

În 1986, InterBase a elaborat primul SQL server cu suport a două tipuri de date avansate. BLOb (sunet, imagine, grafică sau informație binară) și masive multidimensionale (până la 16 dimensiuni într-un câmp). Aceasta a făcut ca InterBase să fie alegerea pentru aplicațiile științifice și multimedia cum atunci atât și acum. Azi, WWW și aplicațiile de telefonie utilizează BLOb foarte des pentru a oferi soluții multimedia. Și cu InterBase serverul este adoptat automat la utilizarea filtrelor, compresoarelor și convertoarelor de date, de exemplu să transforme o fotografie scanată într-un fișier jpeg.

Să admitem că doriți să mutați Baza de Date de pe un calculator pe o soluție Client/Server. Sau aveți nevoie să lărgiți aplicația în așa mod ca să fie utilizată de mai multe departamente. În orice caz, InterBase este o soluție ideală fiindcă el a fost proiectat în special pentru medii de Baze de Date distribuite.

InterBase poate prelucra tranzacțiile muli-server. Această posibilitate automat asigură ca modificările distribuite să fie acceptate (commited) fără vreo intervenție specială din partea aplicației. Când o tranzacție se extinde pe mai multe servere, InterBase automat apelează serverele pentru să se asigure că ele lucrează, apoi transmite instrucțiunea commit pentru a termina tranzacția. Pe lângă aceasta InterBase permite, dacă ceva sa întâmplat, de a anula tranzacția pe toate serverele implicate.

Câteva caracteristici ale SGBD InterBase

Scalabilitate si flexibilitate. Deoarece de obicei este dificil de determinat din faza de proiectare platforma pe care va fi implementată o aplicație anume, sistemul de gestiune a bazei de date pe care se bazează aplicația trebuie să fie disponibil si să ofere performantă ridicată pe o mare varietate de platforme hard si soft.

Baza de date InterBase este proiectată pentru a profita de avantajele diferitelor platforme hard si sistemelor de operare specifice. Din acest motiv baze de date InterBase au o performantă excelentă pe toate platformele suportate: de la sisteme mici cu un singur utilizator la sisteme mari, multiprocesor, cu sute de utilizatori ce procesează mai mult de 1000 de tranzacții pe secundă.

Portabilitate. Portabilitatea deosebită si suportul pentru protocoale multiple asigură ca o bază de date InterBase dezvoltată pe un tip de calculator să poată fi ușor mutată pe orice sistem si în orice configurație.

Arhitectura flexibilă a bazei de date InterBase are avantajul că profită de performantele specifice fiecărei platforme. Acesta permite ca SGBD InterBase să fie scalabil si portabil pe diferite arhitecturi hard si topologii de rețea. În plus, baza de date InterBase au o îmbunătățire de performanta predictibilă pe măsură ce noi resurse (memorie, procesoare) sunt adăugate în sistem.

InterBase este implementat utilizând ANSI SQL-92. Această interfață standard reduce considerabil timpul de adoptare la InterBase a elaboratorilor noi. El se utilizează la implementarea procedurilor stocate, trigherelor, restricțiilor și declarațiilor de integritate a datelor.

În InterBase se poate de folosit UNICODE la păstrarea datelor. Această posibilitate permite păstrarea informațiilor în mai multe limbi în același tabel.

InterBase este disponibil pe o listă mare de platforme UNIX și Windows.

Unele caracteristici tehnice ale SGBD InterBase

Pentru sistemul informațional implementat utilizăm InterBase Server v. 5.5. pentru platforma Windows NT. Pentru lucrul minim, acest server necesită 64 MB memorie operativă, de dorit însă să fie 128 MB.

Performantă InterBase

SGBD InterBase este un motor de baze de date performant pentru aplicații de gestiune utilizate în cele mai diverse domenii (comercial, guvernamental, industrial, servicii …). Performanta cerută de astfel de aplicații implică nu numai rată de procesare mare pentru tranzacții simple ci si procesarea rapidă si timp mic de răspuns pentru tranzacții mari, complexe, care caracterizează majoritatea aplicațiilor comerciale interactive.

Pentru a asigura o rată mare de procesare a tranzacțiilor si integritatea datelor SGBD InterBase include un număr de facilități proiectate pentru minimizarea utilizării de resurse si maximizarea ratei de procesare:

Blocare la nivel de înregistrare – La tranzacțiile de lungime si complexitate moderate punctul critic din punctul de vedere al performantei devine lupta pentru accesul la resursele comune partajate de utilizatori. Bazele de date cu blocare la nivel de pagină sau bloc au probleme în momentul în care o tranzacție atinge mai multe înregistrări: deoarece trebuie blocat pe durata tranzacției un întreg bloc pentru fiecare înregistrare aceasta înseamnă că este posibil să se blocheze si alte zeci sau sute de înregistrări ce nu sunt afectate de tranzacție. Când se execută mai multe tranzacții simultan, posibilitatea interblocării creste exponențial; ca rezultat apar tranzacții care așteaptă eliberarea înregistrărilor necesare cu consecințe asupra timpului de răspuns si a performantei.

Posibilitate de acces doar pentru citiri (Read-Only) – SGBD InterBase permite ca aplicațiile ce accesează datele doar pentru citiri (rapoarte) să citească înregistrările fără blocare. Aceste aplicații nu sunt niciodată blocate de alți utilizatori.

Gestiunea inteligentă a bufferelor – motorul InterBase utilizează în mod eficient si flexibil bufferele de memorie pentru a minimiza numărul de accese la disc. Într-o configurație client/server, serverul InterBase folosește tehnici de împachetare a înregistrărilor într-un singur pachet, care este transmis pe rețea către client. Aceasta împreună cu posibilitatea transmiterii numai a câmpurilor necesare dintr-o înregistrare cât si prin posibilitatea efectuării de către server a selecției înregistrărilor, reduce foarte mult traficul pe rețea generat de o aplicație ce necesită afișarea unei liste de înregistrări.

Operare non-stop – majoritatea aplicațiilor sunt exploatate o mare parte din zi sau toată ziua lăsând puțin timp pentru administrarea sistemului pentru operații precum salvările. InterBase asigură facilități de salvare fără întreruperea operațiilor bazei de date. Administratorul bazei de date poate lansa salvări totale sau parțiale ale bazei de date în timp ce aplicațiile sunt în exploatare.

Aceste facilități asigură aplicațiilor pe baza de date InterBase maximum de performantă în condițiile unui acces intens la datele comune.

Arhitectură scalabil si flexibilă

Utilizarea optimă a resurselor sistemului si a hardware-ului SGBD InterBase permite două configurații de bază:

Client/Server. În această configurație clientul si serverul sunt părți ale aceluiași proces eliminându-se încărcarea sistemului produsă de comunicarea între procese si schimbările de context. Aceste procese își coordonează singure accesul la baza de date prin memoria partajată si mecanisme de semafoare.

Client local (aplicații host/terminal). În această configurație aplicația client si serverul de date sunt procese separate (pe mașini diferite). Fiecare server poate avea un singur flux de control (server single-threaded), comunicând cu un singur client, sau mai multe fluxuri de control (server multi-threaded), ocupându-se de mai mulți clienți. Serverele „single-threaded" folosesc optim procesorul central al mașinilor uniprocesor, pe când serverele „multi-threaded" sunt eficiente pe sisteme multiprocesor.

Administratorul aplicației poate mixa aceste configurații pe același sistem.

Utilizarea corectă a tehnologiilor InterBase asigură descărcarea maximală al calculelor în aplicația client și garantează o securitate sporită și integritatea informației.

Descrierea generală a instrumentarului CASE – ERwin

Datele generale

ERwin – instrument CASE pentru proiectarea bazelor de date al firmei Platinum. ERwin cuprinde interfața grafică Windows, redactor pentru crearea descrierii atât logice cât și fizice a modelului de date și susținerea SGBD-urilor moderne.

ERwin nu e legat la o tehnologie concretă a unei firme ce propune SGBD-uri sau sisteme de dezvoltare. El susține diferite servere a bazelor de date și baze de date locale(desktop), și mai are posibilitatea de a se adresa către baza de date prin intermediului interfeței ODBC. Astfel în versiunea utilizată este implementată susținerea a 23 de SGDB, printre care: InterBase, Oracle, MSSQL Server, ș.a..

Forma de alegere a SGBD necesar pentru generarea structurii bazei de date.

Structura procesului de modelare în ERwin

În ERwin se utilizează două nivele de reprezentare a modelului de date: logic și fizic. În nivelul logic nu se specifică utilizarea unei SGBD concrete, nu se definesc tipuri de date(număr întreg sau real) și nu se definesc cheile tabelelor. Un SGBD ales, denumirile obiectelor și tipuri de date definite, cheile, corespund nivelului al doilea(fizic) al modelului ERwin.

Procesul realizării al modelului informațional constă din etapele următoare:

crearea modelului logic al datelor

definirea entităților

definirea relațiilor între entități

definirea cheilor primare și secundare

definirea atributelor ale entităților

trecerea la modelul fizic al datelor

denumirile entităților devin denumirile tabelelor

denumirile atributelor devin denumirile atributelor în tabele

generarea bazei de date

Crearea modelului logic al bazei de date

Din punct de vedere al utilizatorului ERwin, procesul creării modelului logic al datelor constă în redactarea vizuală a diagramei ERwin. Diagrama ERwin constă din 3 blocuri de bază: entități, atribute și relații.

Pe diagrama entitatea este prezentată ca un dreptunghi, și conține informație despre denumirea entității, descrierea ei, lista atributelor ș. a. Informația de baza, care descrie entitatea, constituie:

atributele, care constituie cheia primară

alte atribute

tipul entității(independentă, dependentă).

În ERwin, prin relație, se subînțelege dependența funcțională între două entități(în particular e posibilă relația a entității cu sine însuși). Relațiile se prezintă prin 5 elemente informaționale de bază:

tipul relației

entitate părinte(parent) sau copil(child)

puterea relației

admiterea valorilor nule

cerințe către integritatea de referință

Crearea modelului fizic al bazei de date

Pentru crearea modelului fizic al datelor, proiectantului îi este necesar să aleagă un SGBD concret și de a se comuta la nivelul fizic de vizualizare a diagramei.

La acest nivel fiecărei entități îi corespunde un tabel în SGBD real, atributului – un câmp al tabelului, relației – cheia externă, cheilor primare și secundare – indexare unică.

Pentru fiecare câmp este necesar de indicat tipul datelor, admiterea valorilor nule, valorile definite inițial, ș. a., în dependență de SGBD concret.

Ultimul pas la etapa de creare a modelului fizic al datelor constă în descrierea trigherilor și procedurilor stocate.

Generarea schemei bazei de date

La etapa de generare a schemei bazei de date ERwin automat creează următoarele elemente:

tabele

index unic pentru fiecare cheie primară și alternativă, și neunice pentru celelalte chei

procedurile stocate

alte obiecte, necesare pentru administrarea datelor.

Mediul de dezvoltare rapidă a aplicațiilor – Borland Delphi

Dezvoltarea rapidă a aplicațiilor

Instrumentele de dezvoltare rapidă a aplicațiilor reprezintă soluția propusă de industria de software pentru ieșirea dintr-o criză, provocată de creșterea exponențială a complexității aplicațiilor moderne.

Organizațiile guvernamentale, economice si întreprinderile recunosc rolul central pe care aplicațiile software îl joacă în cadrul organizațiilor. Astăzi aplicațiile sunt folosite pentru reducerea costurilor, modernizarea operațiilor, îmbunătățirea serviciilor si asigurarea unui avantaj strategic fată de competiție. Departamentele informatice sunt tot timpul sub presiune pentru a dezvolta repede aceste aplicații critice. Cum pot ei să satisfacă aceste cerințe în timp ce bugetele si echipele de dezvoltare sunt în diminuare?

Răspunsul constă în alegerea unui mediu de dezvoltare de aplicații RAD care să permită crearea rapidă de aplicații critice, robuste care să satisfacă necesitățile de gestiune a datelor de azi si de mâine. Cum se poate alege instrumentul optim pentru acest lucru?

Există un număr de factori ce trebuie luați în considerare la selecția unui instrument de dezvoltare de aplicații RAD. Alegerea trebuie făcută prin analiza atentă a cerințelor unei aplicații si selectarea unui instrument de dezvoltare suficient de robust care să trateze aceste cerințe si care să se încadreze în actuala structură hardware. Utilizatorii trebuie să decidă dacă o aplicație la cheie, cumpărată satisface cerințele domeniului de activitate sau dacă aceste cerințe justifică construirea aplicației unei aplicații proprii. În final, cum poate organizația să maximizeze cunoștințele si talentele personalului existent pentru a beneficia de noile tehnologii ce oferă adevărate beneficii în afaceri?

Trebuie ales un mediu de dezvoltare care exploatează noile tehnologii protejând totuși utilizatorii de complexitatea acestora.

Un model pentru alegere

Piața de produse RAD s-a dezvoltat deoarece organizațiile se grăbesc să beneficieze de flexibilitatea si puterea mediilor distribuite. Pentru acoperirea cererii, pe piață au apărut numeroase companii ce produc medii de dezvoltare de aplicații RAD. Toate afirmă că instrumentele de dezvoltare satisfac cerințele aplicațiilor de la nivelul grupelor de lucru la nivel de întreprindere. Identificarea diferențelor specifice se dovedește a fi o adevărată provocare.

Delphi folosește modelul icebergului pentru a explica diferența dintre uneltele de nivel grupă de lucru si nivel întreprindere. Utilizatorii trebuie să analizeze atent cerințele aplicației lor – interfața cu utilizatorul, logica aplicației si gestiunea datelor – înaintea alegerii mediului de dezvoltare. Multe instrumente de dezvoltare arată similar la nivelul interfeței cu utilizatorul. Doar atunci când se analizează mai adânc cerințele aplicației – se coboară sub nivelul apei – alegerea între instrumentele de nivel scăzut si cele de nivel înalt poate fi făcută în cunoștință de cauză.

Spre deosebire de aplicațiile de nivel scăzut, care tind să fie aplicații simple, orientate pe interfața grafică, cu număr mic de utilizatori, aplicațiile de nivel înalt suportă număr mare de utilizatori, procesare de tranzacții complexe si diferite tipuri de interfață cu utilizatorul (interfață grafică si mod caracter – o necesitate a majorității organizațiilor ce migrează spre configurații client/server). Din punctul de vedere al datelor aceste aplicații trebuie să efectueze tranzacții pe baze de date eterogene si distribuite. Complexitatea proceselor economice dintr-o companie implică proiectarea de aplicații cu logică complexă.

Dezvoltatorii sunt în căutarea unui instrument de dezvoltare care să combine ușurința utilizării mediilor de nivel scăzut cu puterea si robustețea unui instrument de nivel înalt. Acest instrument trebuie să permită dezvoltarea rapidă de aplicații de nivel înalt, cu logică si gestiune de date complexe si interfață prietenoasă.

Punerea în practică a noilor tehnologii

Orientarea obiect (OO) este o tehnologie avansată care furnizează beneficii deosebite dezvoltatorilor. Dar timpul de învățare a limbajelor de programare orientate obiect tradiționale ca SmallTalk sau C++ este lung, iar abordarea acestei paradigme de programare dă rezultate numai în mâinile programatorilor experți.

Majoritatea organizațiilor nu au resursele pentru reșcolarizarea dezvoltatorilor în limbajele orientate obiect, deci au fost puse în situația de a nu profita de beneficiile acestei tehnologii. Ele își doresc o abordare care să facă utilizarea orientării obiect simplă si accesibilă pentru toți dezvoltatorii putând profita astfel de beneficiile acesteia.

Un nou model de furnizare al aplicațiilor

Multe companii preferă construirea propriilor aplicații care să satisfacă particularitățile proprii de gestiune ale datelor. Construirea unei aplicații înseamnă menținerea de echipe de programatori si asigurarea productivității lor. În acest caz compania își asumă anumite riscuri: proiectul aplicației poate eșua; aplicația nu este livrată la timp; aplicația nu satisface în totalitate cerințele. Cerințele sunt în continuă modificare de unde apare necesitatea de noi aplicații sau de modificare a celor existente. Ciclul de dezvoltare al aplicației poate fi de doi sau trei ani.

Pentru a implementa aplicațiile mai repede, multe companii aleg pachete de aplicații „la cheie". Ele vor de asemenea să aibă posibilitatea de a adapta aceste aplicații pentru a putea să aibă avantajele unui produs dezvoltat în companie. Aplicațiile dezvoltate în limbaje de nivel înalt se potrivesc cel mai bine la adaptări.

Într-o nouă paradigmă de programare bazată pe componente, experții oficiilor de calcul vor selecta si integra cele mai bune componente de aplicații dintre ofertele de pe piață, vor asambla si adapta aceste componente pentru a crea aplicații specifice. Unele componente de aplicații, cu cerințe specifice organizației, vor fi dezvoltate în continuare intern, de către echipele de dezvoltare proprii. Acest model de dezvoltare bazat pe componente oferă beneficiile oferite de aplicațiile „la cheie" (cost si timp de implementare scăzute, eliminarea riscurilor) si satisfacerea cerințelor specifice oferite de aplicațiile proprii.

Nevoia de RAD

Ca orice activitate productivă si aducătoare de profit, producția de software a fost în permanentă preocupată de problema productivității. Cu toate acestea, termenul RAD a apărut abia în ultimii ani, ceea ce ne sugerează ideea că anumite schimbări recente de context au condus la nevoia de RAD. La modul cel mai general, putem enumera câteva mutații importante în informatica ultimului deceniu. În primul rând, democratizarea informaticii prin răspândirea extrem de rapidă a calculatoarelor personale. În al doilea rând, nașterea unei veritabile industrii de software, cu cifre de afaceri amețitoare. În al treilea rând, comunicațiile.

Coborând în sfera tehnologiei, aceste mutații se traduc în generalizarea interfețelor utilizator grafice, în impunerea arhitecturilor Client/Server, în orientarea tot mai pronunțată spre sisteme deschise si conectivitate la toate nivelele. Proiectanții de aplicații software s-au văzut astfel puși în fata unor cerințe cu totul noi, care i-au prins în mare parte descoperiți. Pur si simplu, profesiunea lor s-a schimbat peste noapte.

Dezvoltarea de aplicații care să utilizeze o interfață utilizator grafică (GUI) este radical diferită de dezvoltarea "tradițională". Nimic nu mai e la fel. Controlul fluxului de execuției este cedat utilizatorului, iar aplicația, până acum monolitică si atotstăpânitoare, se sparge în cioburi care trebuie să-si păstreze o relativă independentă, pentru că ar putea fi apelate în orice moment.

Mai mult chiar. Arhitectura Client/Server rupe total serviciile de procesare cele mai importante de serviciile de prezentare si interfață cu utilizatorul, distribuindu-le pe mașini diferite, de regulă funcționând pe platforme hard/soft eterogene. Aceasta afectează până si designul fundamental al aplicației.

Aceste schimbări de viziune au condus la creșterea explozivă a complexității aplicațiilor si primul lucru care a fost clar a fost inadecvarea vechilor unelte si metode la noile cerințe. Așadar, adio Cobol, adio top-down…

Proaspăt născuta industrie de software a sărit de îndată în ajutorul năpăstuiților proiectanți de aplicații. Dar, după ani si ani de Read, Write si Perform, contactul cu object-oriented, event-driven, middleware s.a.m.d. a fost un soc. Un soc cultural.

Chiar dacă costurile implicate de o reprofilare a proiectanților (timp si bani) nu ar fi fost prohibitive, lucrurile tot nu s-ar fi rezolvat. Pentru proiectanții de aplicații economice (cei la care ne referim cu precădere) a pierde 70-80% din timpul de proiectare pritocind interfețe simpatice era inacceptabil.

Soluția: amortizarea socului cultural prin instrumente de proiectare developers friendly si creșterea productivității prin posibilitatea utilizării unor componente prefabricate si a reutilizării unor componente proprii.

Fundamentele

Instrumentele RAD nu sînt o descoperire de ultimă oră, ci mai degrabă o soluție de ieșire din criză, având la bază câteva idei ceva mai vechi.

Una ar fi limbajele specializate pe domeniu, în special baze de date, cunoscute sub denumirea de 4GL – limbaje de generația a patra. Denumirea lor vrea să evidențieze nivelul lor mai înalt (deci mai îndepărtat de mașină si sistem de operare) decât al limbajelor de uz general cum ar fi C, Cobol, Pascal, etc. (3GL). Aceste limbaje permit proiectantului să se concentreze asupra problemei specifice aplicației, scutindu-l în mare măsură de chestiunile de "bucătărie" internă, rezolvate automat (mai grosier, dar mai repede).

O altă idee de la care s-a pornit a fost cea a instrumentelor CASE (Computer Aided Software Engineering). Mai precis, a două categorii mai speciale a acestora: pe de-o parte instrumente CASE care, pornind de la specificații precise dar exprimate într-un mod mai natural, generează cod într-un limbaj de programare si, pe de altă parte, instrumente CASE specializate pe realizarea de aplicații prototip.

Mai trebuia ceva, iar acest ceva a ieșit din pălăria Microsoft-ului sub numele de Visual Basic. Cei de la Microsoft au observat la timp nașterea unei categorii noi de utilizatori, denumită generic power users. E vorba despre acei utilizatori finali care, fără a fi profesioniști în informatică, din pasiune sau nevoie au acumulat suficiente cunoștințe pentru a-si putea rezolva singuri o bună parte din problemele curente. Vechiul BASIC, considerat de programatori infantil si simplist, a fost recondiționat si transpus într-o haină nouă, vizuală. Fiind acum nu doar ușor de învățat ci si ușor de folosit într-un mediu grafic, Visual Basic-ul s-a impus, aducând după el un val de "limbaje vizuale" si, desigur, un sac de bani în visteria Microsoft-ului.

Anatomia unui instrument RAD

Putem acum să schițăm în linii mari structura unui instrument RAD tipic, evidențiind si variațiile considerate uzuale.

IDE (Integrated Development Environment). În primul rând e nevoie de un mediu de lucru integrat, care să permită dezvoltarea aplicației de la început si până la sfârșit si care să permită accesul la toate componentele aplicației. Unele produse din această gamă (de exemplu CA-Visual Objects) dispun de un repository, care tine în mod automat evidenta tuturor componentelor aplicației. Unele dispun de suport pentru dezvoltarea în echipă, permițând controlul accesului la componente si controlul versiunilor (pentru această sarcină este adesea integrat programul PVCS al firmei Intersolv).

Instrumentele vizuale de descriere a interfeței sînt întotdeauna prezente. Cu ajutorul lor se pot desena ferestre de dialog, forme de intrare, machete de rapoarte. Plasarea controalelor se face de cele mai multe ori prin drag&drop, iar definirea atributelor (culoare, etichetă, evenimente, sursa de date, etc.) este de regulă posibilă printr-un "inspector de obiecte" (regăsit în mai toate produsele sub diverse nume). Modelul impus de Visual Basic este urmat de majoritatea produselor.

Unele produse merg mai departe pe calea vizualului, permițând descrierea de aceeași manieră a structurilor de date si a relațiilor între acestea. Mai mult, există produse (Novell Visual AppBuilder, IBM VisualAge) care permit chiar descrierea vizuală a fluxul de prelucrare.

Limbajul. Oricât de departe ar merge însă facilitățile vizuale oferite, ele nu elimină nevoia folosirii unui limbaj de programare (AppBuilder este o notabilă excepție). Aici opțiunile producătorilor sînt foarte diverse. Unii mizează pe accesibilitate, utilizând fie variațiuni de Basic (Sybase PowerBuilder, Oracle PowerObjects) fie variațiuni de Xbase (CA Visual Objects, MS Visual FoxPro). Alții utilizează versiuni de limbaje mai puternice (Pascal în Delphi, C++ în Enterprise Developer, SmallTalk în VisualAge) sau limbaje 4GL proprii (SQLWindows).

De regulă toate aceste limbaje sînt mai mult sau mai puțin orientate-obiect. Unele permit tipizarea strictă a variabilelor (Pascal-ul din Delphi, Clipper-ul din Visual Objects) si dispun de compilator adevărat, altele sînt mai libertine dar admit doar o pseudo-compilare, codul obținut (p-code) fiind apoi interpretat. În fine, o a treia opțiune o reprezintă generarea de cod într-un limbaj 3GL (de obicei C), care urmează apoi a fi compilat

Mai trebuie notat că multe instrumente RAD permit conectarea unor module scrise în limbaje tradiționale.

Conectivitate. Suportul pentru conectarea la surse diverse de date este extrem de important pentru instrumentele RAD. Vremurile când un mediu de dezvoltare era dedicat doar anumitor surse de date au apus, astfel că acum până si instrumentele RAD produse de liderii sistemelor de baze de date (Sybase, Gupta, Oracle) oferă conectivitate către principalele back-end-uri, chiar rivale pe piață. În plus, suportul pentru conectivitatea prin ODBC (Open Database Connctivity) este general, în cazul produselor Windows. Standardul rival de conectivitate, IDAPI, este încă mai puțin răspândit (Borland Delphi).

Pentru a permite proiectanților să dezvolte si mai ales să testeze aplicațiile client/server în mod off-line, multe dintre produse livrează si o versiune locală a unui server de baze de date: Watcom SQL pentru PowerBuilder si CA-Visual Objects, XDB pentru Enterprise Developer, InterBase pentru Delphi, Gupta SQLBase pentru SQLWindows, etc.

Componente. În fine, unul dintre obiectivele oricărui instrument RAD este să aducă un spor semnificativ de productivitate în dezvoltarea aplicațiilor. În această privință se detașează două abordări: utilizarea de componente prefabricate si reutilizarea codului (si chiar a design-ului) de la o aplicație la alta.

În prima abordare, modelul este dat de controalele VBX (Visual Basic custom controls) si de mai noile OCX-uri (OLE custom controls). Produse în general de terți producători, acestea oferă funcționalități diverse (de pildă administrarea proiectelor de dezvoltare software, calcul tabelar, etc.) ce pot fi înglobate în aplicațiile proprii. Bogăția ofertei de astfel de componente si preturile foarte atractive au determinat pe unii producători de instrumente RAD să ofere suport pentru utilizarea acestora în propriile produse (Delphi, PowerBuilder).

A doua abordare este legată în mod direct de tehnologia Object-Oriented si oferă explicația utilizării preponderente a unor limbaje orientate pe obiecte. Desigur, există posibilitatea de a crea biblioteci de rutine obișnuite, dar gradul lor de generalitate este în mod inerent redus, ceea ce împiedică reutilizarea efectivă a codului. Soluția cea mai elegantă si cea mai productivă o constituie realizarea unei biblioteci de clase, care să poată fi preluate într-o nouă aplicație si, dacă este cazul, specializate prin mecanismul de moștenire pentru specificul noii aplicații. Avantajul major îl constituie faptul că cea mai mare parte a codului (uneori integral) este refolosit si, foarte important, acest cod este deja testat. Majoritatea instrumentelor RAD dispun de mecanisme specializate în această privință (editoare de clase, browser-e) si de extensii corespunzătoare de limbaj pentru a controla elemente cum ar fi moștenirea (chiar multiplă în cazul lui SQLWindows), evenimente, mesaje, metode, protecția si vizibilitatea, etc.

Există si o cale de mijloc: distribuirea de clase predefinite, care pot fi folosite ca atare sau pot fi specializate prin moștenite. Un exemplu în acest sens îl reprezintă QuickObjects din SQLWindows. Există si soluții extreme, în care întreaga aplicație se construiește doar din elemente prefabricate (AppBuilder).

Distribuția. Odată dezvoltată o aplicație, ea trebuie distribuită clientului sau clienților. Aceasta implică în general compilarea modulelor componente si, eventual, realizarea unui set de dischete de instalare. Unele produse RAD controlează automat actualitatea modulelor componente (de exemplu Visual Objects), recompilînd selectiv elementele aplicației care au fost actualizate. De asemenea, există de regulă posibilitatea de a crea automat dischetele de instalare, incluzând codul (interpretabil sau direct executabil), modul run-time (dacă e cazul), bibliotecile DLL, documentația, etc.

Remarcabilă este si posibilitatea multor produse RAD de a genera, în locul aplicației, o bibliotecă de rutine (de regulă DLL – Dynamic Link Library) sau de clase.

Controverse

Desigur, prezentarea de mai sus nu este exhaustivă, intenția fiind doar de a surprinde "portretul robot" al unui instrument RAD. Deja se poate observa însă diversitatea opțiunilor producătorilor de astfel de instrumente. Direcția în care aceste produse vor evolua va depinde de mai mulți factori.

Unul dintre acești factori va fi cu siguranță produsul care se va impune cel mai repede si mai stabil pe piață. Valul RAD abia a început, dar se consideră că actualmente liderii sînt Visual Basic si PowerBuilder. Astfel ajungem deja la problemele controversate ale domeniului.

Cui se adresează de fapt instrumentele RAD? Utilizatorilor avansați (power users) sau proiectanților profesioniști? Microsoft, prin Visual Basic (dar si prin Access si noul VisualFoxPro) mizează pe prima categorie si face uz de toată forța sa comercială în această direcție. PowerBuilder se adresează în schimb profesioniștilor (ca si SQLWindows si Enterprise Developer). Ideal ar fi ca si unii si alții să aibă acces la aceste instrumente, dar simplitatea necesară primei categorii aduce inevitabil limitări care îndepărtează profesioniștii. În schimb forța instrumentelor destinate profesioniștilor implică o complexitate inaccesibilă utilizatorilor finali, chiar avansați.

O altă chestiune controversată este relația între RAD si metodologia proiectării aplicațiilor. Este interesant de remarcat că majoritatea instrumentelor RAD frotează oarecum proiectantul să înceapă dezvoltarea cu interfața, ceea ce contravine total metodologiei tradiționale. Explicația constă în faptul că o aplicație event-driven nu este structurată ierarhic, nu dispune de o "coloană vertebrală". Dimpotrivă, prelucrările se leagă în mod preponderent de elemente vizuale de interfață (dialoguri, forme, controale, etc.). Pe de altă parte, o nouă metodologie s-a născut (de fapt ea este cea care se cheamă RAD), sprijinind această orientare si asigurând ea însăși un spor de siguranță si productivitate. Pe de o parte aplicația poate fi dezvoltată concomitent pe două planuri, cel vizibil si cel invizibil, care pot fi in final asamblate. Pe de altă parte, interfața utilizator, dublată de o funcționalitate minimală (de regulă implicit oferită de instrumentele RAD), poate juca rolul de prototip, obținând astfel un valoros feed-back din partea utilizatorilor finali. Cu atât mai valoros cu cît poate fi obținut în primele etape ale proiectării, avantaj pe care orice proiectant cu experiență îl înțelege.

O mențiune în acest sens pentru Symantec Enterprise Developer, care permite ambele variante de dezvoltare. Si tot legat de Enterprise Developer, ar fi de menționat problema limitelor instrumentelor RAD. Că orice astfel de instrument trebuie să permită finalizarea în detaliu a unei aplicații este clar. Dar unde încep sarcinile destinate instrumentelor RAD? Enterprise Developer merge până în primele faze ale analizei, ba chiar oferă facilități de reverse engeneering pe aplicații existente ce trebuie refăcute. Majoritatea celorlalte produse se concentrează asupra dezvoltării de aplicații front-end, lăsând de exemplu partea de proiectarea a structurilor de date pe seama unor instrumente CASE specializate.

O altă problemă controversată este cea a relației între programarea vizuală si cea tradițională. Majoritatea programatorilor de simt frustrați dacă nu au acces la codul complet al aplicației, iar multe dintre mediile de dezvoltare la care ne referim nu oferă un corespondent la nivel de cod al elementelor dezvoltate vizual. O altă nemulțumire a programatorilor se referă la absenta unei viziuni globale asupra aplicației în ansamblul ei. Aceste probleme țin probabil si de adaptarea la noile unelte, dar ele determină în mare măsură acceptata unui astfel de produs. Remarcabilă este soluția aleasă de Gupta în SQLWindows. Corespondenta între vizual si cod este biunivocă, astfel încât în orice moment programatorul poate să aleagă între utilizarea unui instrument vizual sau să scrie cod. Editorul de cod, numit Outliner, oferă si mult dorita viziune de ansamblu, oferind totodată proiectantului șansa de a accede la fiecare linie de cod.

Pentru proiectanții de aplicații, vremea schimbărilor a venit. Aceștia trebuie să facă fată nu doar unei schimbări de instrumente, ci în primul rând unei schimbări de paradigmă, ce implică modul de a gândi o aplicație, modul de a o construi, de a o testa si de a o implementa. Pentru cei inadaptabili, viitorul este sumbru.

Pentru utilizatorii avansați vin iarăși vremuri noi. Aplicațiile pe care le vor utiliza vor fi mai prietenoase si mai apropiate de dorințele lor. Utilizatorii avansați vor avea șansa să se implice mai mult în proiectarea aplicațiilor, instrumentele de dezvoltare fiindu-le tot mai accesibile.

Cu toate că reclama comercială a instrumentelor RAD sugerează ideea programării fără programatori, nevoia de programatori profesioniști nu va scădea. Ba chiar dimpotrivă. În primul rând, prea puține sînt aplicațiile reale, serioase, care să poată fi duse la bun sfârșit de amatori, fie ei si power users. În al doilea rând, avântul comercial al instrumentelor RAD va face să se dezvolte o piață importantă pentru componente software.

Strategia Borland Delphi

Strategia Borland Delphi este de a folosi Orientarea obiect sub forma dezvoltării bazate pe componente. Familia de produse Borland Delphi se încadrează în viziunea tehnologică pe termen lung a companiei. Borland Delphi 5 este un mediu de dezvoltare de aplicații de nivel înalt, independent de tipul bazei de date, care permite dezvoltatorilor să construiască repede aplicații complexe folosind Visual Component Library(VCL).

Borland Delphi oferă o introducere rapidă în mediul dezvoltării bazat pe componente. VCL reprezintă o colecție de obiecte robuste (înglobează logică, acces la date si interfață) care lucrează împreună si pot fi asamblate pentru a crea o aplicație cu funcționalitate completă fără a scrie cod.

Folosind VCL, dezvoltatorii pot crea repede si ușor cod reutilizabil într-un mediu de programare vizual si folosind puternicul limbaj de programare Object Pascal, fără a fi necesară scrierea de cod în limbaje de nivel mai scăzut. Datorită faptului că VCL reprezintă extensii ale limbajului Object Pascal care este ușor de învățat si de stăpânit, programatorii pot deveni repede producători de componente. Atât componente furnizate cu Borland Delphi cât si cele proprii pot fi asamblate în aplicații folosind mouse-ul prin poziționare si acționare. Pe scurt, dezvoltatorii obțin productivitatea promisă de programarea orientată obiect într-un mediu de dezvoltare ușor de învățat si folosit.

Prin folosirea acestei tehnologii de către sutele de parteneri de aplicații ai Borland Delphi este de întrevăzut apariția unei piețe mondiale de componente de diferite complexități pentru diferite domenii de activitate. Aceasta va permite organizațiilor să-si înlocuiască aplicațiile monolitice cu aplicații proprii dezvoltate folosind cele mai bune componente de pe piață.

În ultimii ani activitatea Inprise Corporation a fost îndreptată pentru a satisface cerințele dezvoltării de aplicații de nivel înalt. Astăzi, prin aplicarea în practică a experienței si cunoștințelor în domeniul instrumentelor de dezvoltare client/server de nivel înalt, Borland Delphi continuă să furnizeze software de calitate si servicii care să maximizeze productivitatea dezvoltatorilor de aplicații profesioniști si să le permită livrarea de aplicații care să satisfacă cerințele organizațiilor lor aducându-le un avantaj competitiv în afaceri.

Obiectivele Delphi

Delphi a impus un nou standard în dezvoltarea rapidã de aplicatii si reprezintă primul mariaj fericit între un mediu de dezvoltare vizualã si un compilator veritabil. Noua versiune 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.

Încă din trecut Borland si-a precizat obiectivele ambițioase ale noului Delphi. Sã le trecem în revistã si sã inspectãm modul în care acestea 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;

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

suport complet pentru interfața Windows;

suport complet pentru aplicatii pe 32 biți atât pentru Windows 95 cît si Windows NT;

productivitate mărita în dezvoltarea de aplicatii;

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

Arhitectura compilatorului de cod optimizat pe 32 biți

Noul 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 moștenire directã este si suportul dual al lui Delphi pentru fișiere de tip unități Turbo Pascal (DCU) si fișiere în format standard OBJ. Ca urmare, partajarea de cod între Pascal si C++ a încetat sã mai fie o problemã.

Trecerea la cod pe 32 biți cu al sãu model plat de memorie marchează inevitabil si căderea barierei celor 64 KB. În fine, structurile de date de orice fel, vectorii si string-urile pot avea acum orice dimensiune – limitatã numai de sistemul de operare. S-a terminat cu împărțirea parcimonioasã a celor 64 KB între segmentul de date si cel de stivã, cu depășirile de stivã: segmentele de date si de stivã pot avea orice dimensiune iar cel de stivã poate creste dinamic.

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

Noul link-editor apelat la sfârșitul procesului de compilare este cu 20% până la 50% mai rapid decât versiunea precedentã. Câteva optimizări concurã la obținerea acestui rezultat. Astfel, utilizarea unei scheme de păstrare în memorie a unităților si formelor nemodificate mărește semnificativ viteza de link-editare prin comparație cu reîncărcarea modulelor de pe disc. Un nou format pentru unități (DCU) permite link-editorului sã utilizeze o tehnicã de verificare inteligentã a versiunilor care reduce drastic redundanta din recompilare. Astfel, dacã în trecut modificarea unei funcții dintr-o unitate determina recompilare automatã a tuturor unităților care foloseau vreun element din interfața unității modificate, acum numai unitățile care apelează explicit funcția modificatã sînt incluse în procesul de recompilare. Producătorii de biblioteci de obiecte si componente nu vor mai fi nevoiți sã distribuie o nouã versiune, recompilată, pentru fiecare nouã versiune de Delphi.

Suport complet pentru controale si automatizare OLE

Borland a renunțat la veleitățile de independentã din trecut, aderând 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 OLE merge până la a asigura compatibilitate completã cu viitorul Network OLE anunțat de Microsoft.

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

Întrucât compilatorul generează cod mașina 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 tip – variant – a fost creat special pentru facilitarea automatizărilor OLE. Acesta permite utilizatorilor sã declare variabile al căror tip este determinat în timpul rulării, adaptând astfel aplicația de tip controlor OLE la flexibilitatea automatizării OLE. În fapt, se poate utiliza o singurã variabilã pentru conectarea la diferite tipuri de servere OLE.

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

Programatorii care au remarcat cu neplăcere absenta de suport obiectual pentru server OLE în precedenta versiune vor fi mulțumiți sã constate cã Delphi este capabil sã creeze server-e OLE Automation atât conectate în proces cît si independente. Puteți exporta metodele server-ului OLE către oricare terț controller OLE, de la o aplicație creatã cu Delphi până la Microsoft Word sau Excel. O nouã perspectivã se deschide acum programatorilor Delphi – aceea de a putea separa funcțiile aplicației în module distincte construite pe o arhitecturã client-server, care pot rula local sau pe mașini diferite exploatând la maximum resursele procesorului prin multi-threading precum si cele ale rețelei prin împărțirea sarcinilor pe mașini distincte.

Scrierea unui server OLE se face la propriu, singurul suport vizual fiind asigurat doar în primii pași de Automation Object Expert. Funcționalitatea de server OLE se obține prin moștenire de la clasa TAutoObject, la care se adaugă proprietățile si metodele exportate într-o secțiune specialã, botezatã automated. Aplicația poate fi compilatã ca DLL, rezultând un server conectat în proces sau se poate obține un executabil ce se comportã ca server independent.

Cei 32 biți de la Microsoft

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

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

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

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

Mai multã productivitate

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

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

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

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

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

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

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

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

Tratarea excepțiilor

Importanta tratării excepțiilor este covârșitoare si numai cei ce s-au aventurat în dezvoltarea unui proiect de anvergură fără a se asigura astfel au gustat din amărăciunea loviturilor pe la spate, gen depășire de virgulă mobilă ce antrenează pierderea integrală a datelor… iar dacă au încercat să-si ia măsuri de protecție codul de validare a parametrilor si rezultatelor tindea să-l depășească pe cel propriu-zis si antrena noi bug-uri.

Posibilitățile deschise de Delphi fac ca arhitectura unei aplicatii să devină foarte complexă si probabilitatea survenirii de excepții să crească exponențial, mai ales în medii de baze de date.

Tratarea excepțiilor se face conform unui concept hibrid între sistemul clasic de tratare structurată a excepțiilor si recunoașterea excepțiilor ca tipuri de obiecte. Codul susceptibil să întâlnească o eroare se include într-un bloc de protecție la care se atașează un alt bloc cu cod de tratare a excepțiilor suspectate. Blocul de tratare poate fi completat cu unul de terminare, tipic cu cod de făcut curățenie, care primește controlul dar nu stinge excepția. Excepțiile sunt diferențiate ca obiecte distincte derivate din tipul Exception si moștenesc codul necesar afișării unui mesaj formatat si conectării cu un help topic. Blocurile de protecție pot fi imbricate si controlul execuției revine la nivelul la care blocul de tratare recunoaște si interceptează tipul respectiv de excepție.

Cea mai frecventă utilizare a blocurilor de protecție-tratare a excepțiilor se întâlnește când se dorește protejarea alocării de resurse. Adesea apariția unei excepții poate împiedica atingerea codului în care se efectuează eliberarea memoriei, închiderea de fișiere sau dealocarea de resurse Windows, cu consecințe imprevizibile pentru integritatea datelor sau stabilitatea sistemului. Includerea acestui cod – botezat cleanup code – într-un bloc de terminare garantează execuția lui indiferent de apariția excepției.

Invocarea unei excepții este cea mai bună metodă si adesea singura pentru a "scăpa" din ramura de execuție curentă. Spre exemplu, dacă în metoda ce tratează evenimentul BeforePost al unui obiect-tabelă se invocă o excepție, actualizarea înregistrării curente în tabelă este anulată.

Tratarea excepțiilor nu este numai pentru programatorii profesioniști. Chiar dacă este complet ignorată de dezvoltator, protecția la excepții încorporată în componentele din care s-a asamblat aplicația blochează orice excepție survenită fie din condiții externe, fie din erori de programare. Pur si simplu aplicația nu crapă. Își revine până si din erori serioase precum General Protection Fault !

Controale Windows

Între cele aproape 100 de componente din paleta lui Visual Component Library se regăsește si suita completã de controale specifice lui Windows si disponibile în Windows NT. Suita se compune din TabSet si PageControl pentru crearea de dialoguri cu mai multe pagini, TreeView destinat afișării unei ierarhii de obiecte, ListView pentru prezentarea pe coloane a unei liste de obiecte, ImageList care controlează o listã de imagini pentru afișare arborescentã sau pe coloane, HeaderControl pentru plasarea de bare de control pe spațiul de lucru, RichEdit – un editor de text cu facilități extinse de formatare, StatusBar – zonã plasatã în partea inferioarã a ferestrelor destinatã afișării situației curente a aplicației, TrackBar – o îmbunătățire sub formã de potențiometru a clasicului scrollbar, ProgressBar – similar cu TGauge si destinat afișării progresului unei proceduri, UpDown – butoane de incrementare / decrementare a unei valori, si în fine, HotKey – conceput pentru atașarea facilã a unor combinații de taste active pentru orice component.

Prin draparea lor în componente, programatorul este scutit de frecușul cu interfața noduroasã de nivel procedural. Când este necesar un nivel superior de funcționalitate, dezvoltatorii pot implementa propriile lor metode, proprietăți si componente prin moștenire. Toate controalele Win95 pot fi subclasate, ba chiar reprezintă un teren fertil pentru inovații si extensii. În pachetul Developer se livrează si sursele complete ale bibliotecii de componente, care se dovedesc foarte valoroase în înțelegerea comportamentului specific al obiectelor de interfața.

Suport extins pentru aplicațiile de baze de date

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

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

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

Paleta de acces la baze de date s-a îmbogățit cu o formã specialã de query – TUpdateSQL – care preia operațiunile de ștergere, inserare si actualizare de înregistrări spre deosebire de clasicul TQuery, care este rezervat acum doar pentru operațiuni 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.

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

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

Mai multã putere în motorul de baze de date

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

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

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

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

Nucleul de interogare SQL este complet rescris si separat acum de nucleul QBE. Performanta interogărilor SQL pe tabele desktop a crescut substanțial si au căzut o serie de restricții din subsetul Local SQL, care se apropie acum si chiar depășește standardul SQL 92. Sânt posibile includerea de subquery-uri în clauzele WHERE si HAVING, utilizarea de expresii în funcțiile de agregare (gen SUM( Cîmp1+Cîmp2) sau chiar SUM( MIN(Cîmp1))), ca si în clauzele GROUP BY si ORDER BY, precum si utilizarea operatorului UNION. În parantezã fie spus, bug-ul care împiedica un full outer join cu câmpuri multiple de legătura persistã încă si în noua versiune. Subseturile de înregistrări returnate de interogări asupra mai multor tabele pot fi editate cu reflectarea modificărilor în tabelele originale. Subseturile rezultate din query-uri pot fi suplimentar rafinate prin utilizarea de filtre.

O îmbunătățire care va îndepărta coșmarul multor dezvoltatori de baze de date desktop este suportul tranzacțional complet pentru tabele Paradox si dBASE. Modificările tabelelor pot fi grupate într-o tranzacție si efectuate (commit) sau anulate (rollback) integral, asigurând actualizarea bazei de date de o manierã consistentã si cu păstrarea integrității referențiale. Driver-ul pentru tabele Paradox > ver.6 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 operațiuni asupra bazei de date într-o perioadã mai lungã de timp fără a modifica imediat baza de date de pe server, reducând la minimum consumul de resurse pe server ca si traficul pe rețea.

Dezvoltatorii de aplicatii client-server SQL vor aprecia posibilitatea de a monitoriza frazele SQL care se transmit server-ului la fiecare execuție de funcție 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.

Decizia de a lucra cu Delphi se împletește strâns cu aceea de a accepta si exploata un nou mediu de lucru, pe 32 biți, multitasking, multithreading, cu noi concepte de realizare modularã a programelor prin OLE Automation si tehnici client-server. În ultimul an sistemele de operare pe 32 biți au atins masa criticã iar industria a început sã se schimbe din nou. Jucătorii de marcã mizează acum pe 32 biți iar Delphi a apărut la momentul oportun pentru a face tranziția rapid si eficient.

Descrierea limbajului structurat de interpelare SQL

Limbajul SQL (Structured Query Language) – limbajul cererilor structurizate, este un limbaj de descriere a operațiilor de apel la serverele bazelor de date. Acest limbaj a fost elaborat în anii 70 (prima versiune de lucru a fost lansată în anul 1970) de către compania IBM. Limbajul s-a dovedit a fi atât de comod și folositor, încât peste zece ani a devenit standard comercial. În anul 1986 acest fapt a fost documentat – Institutul Național American al Standardelor (ANSI) și Organizația Internațională de Standardizare (ISO), au publicat în comun primul standard al limbajului SQL 86. În anul 1992 apare standardul SQL 92 sau SQL 2 datorită progresului esențial care s-a produs anii 90 în domeniul elaborării și exploatării bazelor de date. În momentul de față merg lucrări pentru elaborarea standardului SQL 3.

Toți operatorii limbajului sunt divizați în trei categorii:

Operatorii de control a datelor (Data Control Statements) se folosesc pentru controlul statutului utilizatorului care face apel la baza de date. Aceștia sânt operatorii GRANT și REVOKE.

Limbajul de definire a datelor (Data Definition Language, DDL) include operatori de creare a obiectelor BD și definirii structurii lor. Din acest set fac parte operatorii CREATE SCHEMA, CREATE TABLE, CREATE VIEW, CREATE DOMAIN.

Limbajul de manipulare a datelor (Data Manipulation Language, DML) reunește operatorii de căutare, ștergere, modificare și memorizare a datelor. Aici intră operatorii SELECT, UPDATE, INSERT, DELETE. Cel mai important dintre ei (probabil cel mai important din tot limbajul SQL) este operatorul SELECT.

Operatorii primelor două categorii deseori se reunesc în DDL.

În afară cele evidențiate, mai există câteva grupe de operatori, care dirijează tranzacțiile, legăturile, sesiunile, etc. Însă aceste grupe nu sânt atât de importante.

Noțiuni generale

SQL prezintă din sine un limbaj structurat de interpelări. Acesta este un limbaj care face dă posibilitate de a crea și lucra cu baze de date relaționale, care este un set de informație legată, care se păstrează în tabel.

Spațiul informațional devine tot mai unificat. Asta a adus la necesitatea creării unui limbaj standard, care s-ar putea folosi în diferite tipuri a mediilor de calculatoare. Limbajul standard va da posibilitatea utilizatorilor, care cunosc un set de comenzi, să le folosească pentru crearea, găsirea, modificarea și transferarea informației – independent de faptul, că ei lucrează la calculator personal, la o stație lucrătoare de rețea, sau la calculator universal.

În lumea calculatoarelor, utilizatorul care are limbajul dat, are un mare avantaj în utilizarea și generalizarea informației dintr-un șir de surse cu ajutorul unui mare număr de metode.

Eleganța și independența de la specificul tehnologiilor informaționale, și susținerea lui de către liderii industriei în sfera tehnologiei bazelor de date relaționale, a făcut limbajul SQL limbaj standard de bază. Din această cauză oricine care dorește să lucreze cu bazele de date a anilor 90, trebuie să cunoască SQL.

Standardul SQL este determinat de ANSI (American National Standart Institute) și în momentul de față el este acceptat și de ISO (Organizația Internațională a Standardelor). Însă majoritatea programelor comerciale a bazelor de date îl lărgesc fără a pune la cunoștință ANSI, adăugând diverse particularități în acest limbaj, care, cum ei cred că ele vor fi forte folositoare. Câteodată ele ceva schimbă standardul limbajului, dar ideile bune au tendința de a se dezvolta și curând devin standarde a "pieței" de la sine ele în puterea folositoare a calităților sale.

Componența limbajului SQL

Limbajul SQL este destinat pentru manipularea datelor în baze de date relaționale , determinarea structurii bazei de date și dirijarea cu drepturile de acces la date într-un mediu cu mulți utilizatori.

Și de atâta, în limbajul SQL în calitate de părți componente întră:

limbaj de manipulare a datelor (Data Manipulation Language, DML)

limbaj de determinare a datelor (Data Definition Language, DDL)

limbaj de dirijare a datelor (Data Control Language, DCL).

O să subliniem, că acestea nu sânt limbaje aparte, ci sânt diverse comenzi a unui limbaj. Astfel de divizare sa făcut numai din punctul de vedere a diverselor valori funcționale a comenzilor date.

Limbajul de manipulare a datelor se utilizează, cum se vede din denumire, pentru manipularea datelor în tabelele bazei de date. El este format din 4 comenzi de bază.

Din punctul de vedere a interfeței aplicate există două tipuri de comenzi SQL:

SQL interactiv

SQL incorporat.

SQL interactiv se utilizează în utilize speciale (de tipul WISQL sau DBD), care dau posibilitatea în regim interactiv introducerea interpelărilor cu utilizarea comenzilor SQL, trimiterea lor pentru execuție la server și pentru a primi rezultate în fereastra care este destinată pentru aceasta. SQL incorporat se folosește în programele aplicate, și le permite să trimită interpelări la server și să prelucreze rezultatele primite, și cu tot mai mult combinând orientare – set și orientarea – record.

Operații relaționale. Comenzile limbajului de manipulare cu datele

Cea mai importantă comandă a limbajului de manipulare cu datele este comanda SELECT. După simplitatea sintaxei ei se ascunde o mare bogăție de posibilități.

Forma cea mai simplă a instrucțiunii SELECT este:

SELECT * FROM table_name;

Unde table_name este numele tabelului din care vom obține datele, iar asteriscul (*) înseamnă selectarea a tuturor câmpurilor din tabel.

Sintaxa instrucțiunii SELECT este următoarea:

SELECT [DISTINCT] columns

FROM tables

WHERE <search_conditions>

[GROUP BY column HAVING <search_condition>]

ORDER BY <sort_order>;

Descrierea clauzelor:

SELECT columns Lista câmpurilor ce vor fi selectate

DISTINCT Cuvânt-cheie opțional care elimină înscrierile duble

FROM tables Identifică tabelele care vor fi utilizate

WHERE <search_conditions> Specifică condiția de căutare care va fi utilizată pentru a limita numărul înscrierilor obținute la subset al numărului total de înscrieri valabile.

GROUP BY column Grupează înscrierile obținute în acord cu valoarea coloanei specificate.

HAVING <search_conditions> Specifică condiția de căutare care va fi utilizată împreună cu clauza GROUP BY.

ORDER BY <sort_order> Specifică ordinea de sortare a înscrierilor care vor fi întoarse de SELECT.

Ordinea clauzelor în instrucțiunea SELECT este importantă, însă numai SELECT și FROM sunt clauzele strict necesare.

SELECT poate, de asemenea, întoarce date din multiple tabele, setând lista numelor tabelelor în clauza FROM, separate prin virgulă.

WHERE

Clauza WHERE a instrucțiunii SELECT urmează după clauzele SELECT și FROM.

Dacă utilizăm clauza ORDER BY, atunci clauza WHERE trebuie folosită înaintea ei. Clauza WHERE testează datele după condiția dată, iar clauza SELECT întoarce numai înscrierile ce satisfac condiției respective. De exemplu, instrucțiunea:

SELECT NAME_S, NAME_L, KD_Jud

FROM S_NAM_PR

WHERE KD_Jud = "08";

întoarce numai înscrierile pentru care KD_jud este “08”.

WHERE condition;

column –câmp din tabel

operator – operator de comparare (descris în tabelul de mai jos)

value – este o valoare sau un set de valori cu care se compară câmpul respectiv. Value poate fi compusă din două sau mai multe valori ca operanzi ai operatorilor aritmetici. Condiția de căutare folosește următoarele tipuri de operatori:

Operațiile logice care se folosesc în clauza WHERE

Când înscrierea respectivă se compară la condiția de căutare, una din cele trei valori este întoarsă:

True: Înscrierea a satisfăcut condiției specificate în clauza WHERE.

False: Înscrierea nu a satisfăcut condiției specificate în clauza WHERE.

Unknown: Câmpul din clauza WHERE conține o valoare necunoscută care nu poate fi evaluată din cauza valorii NULL.

Operatorul LIKE

Operatorul LIKE ne dă posibilitatea de a folosi caractere speciale în text. Caracterele speciale sînt acele caractere care au o semnificație specială când sînt folosite în condiția de căutare. Caracterul (%) va semnifica – unul sau mai multe caractere, (_) – un singur caracter.

Operatorii Logici

Toate exemplele de până acum au inclus numai câte o condiție de căutare. Însă, în SQL avem posibilitatea de a include orice număr de condiții de căutare în clauza WHERE combinându-le cu ajutorul operatorilor AND sau OR.

Când AND apare între condițiile de căutare, ambele condiții trebuie să fie adevărate pentru ca înscrierea să fie întoarsă.

Când OR apare între condițiile de căutare, numai una din condiții trebuie să fie adevărată pentru ca înscrierea respectivă să fie întoarsă.

Când introducem condiții de căutare compuse, trebuie să ținem cont de ordinea de evaluare a condițiilor.

Funcțiile agregate

SQL pune la dispoziție funcții agregate care calculează o singură valoare dintr-un grup de valori. Grupul de valori sunt toate datele dintr-un câmp particular pentru setul dat de înscrieri. Funcțiile agregate pot fi folosite în cadrul clauzei SELECT, sau oriunde în cadrul instrucțiunii SELECT unde se folosește valoarea.

Clauza HAVING

La fel ca și clauza WHERE care reduce numărul înscrierilor întoarse de clauza SELECT, clauza HAVING poate fi folosită pentru a reduce numărul de înscrieri întoarse de clauza GROUP BY. La fel ca și clauza WHERE, clauza HAVING are condiție de căutare. În clauza HAVING condiția de căutare corespunde tipic unei funcții agregate folosite în clauza SELECT.

De obicei, cererea întoarce înscrieri în “ordinea naturală”, ordine în care înscrierile sînt găsite în tabel. Deoarece păstrarea datelor în tabele este de obicei neordonată (nesortată), rezultatul cererii va fi de asemenea nesortat. Clauza ORDER BY sortează rezultatul în acord cu câmpul specificat. Fiecare coloană din clauza ORDER BY trebuie de asemenea să apară și în clauza SELECT a instrucțiunii.

INSERT

Insert înscrie unul sau mai multe tuple de date într-un tabel sau view existent. Insert este una din privilegiile bazei de date controlate de către comenzile GRANT și REVOKE.

Valorile sunt înscrise în tuplu în ordinea coloanelor din tabelă, doar dacă nu este indicată o listă de coloane vizate. Dacă lista de coloane vizate prezintă un subset al coloanelor disponibile, valorile nule sau implicite automat sunt înscrise în toate coloanele nevizate.

Dacă lista opțională a coloanelor vizate este omisă, clauza VALUES trebuie să asigure valori pentru introducerea în toate coloanele tabelei.

Pentru a introduce un singur tuplu de date, clauza VALUES trebuie să asigure o listă specifică de valori pentru insertare.

Pentru a introduce mai multe tuple de date, trebuie să fie specificată o select expresie care extrage datele dintr-o tabelă pentru a le introduce în tabela aceasta. Coloanele selectate trebuie să corespundă cu coloanele vizate pentru introducere.

Este permis de a alege câmpuri de date din același tabel în care dorim să efectuăm introducerea, dar așa practică nu se recomandă deoarece poate cauza in introducerea infinită de tuple.

UPDATE

Modifică parțial sau în întregime tuplul existent de date dintr-un tabel sau view. Disponibil în SQL, DSQL și isql.

UPDATE modifică unul sau mai multe tuple dintr-un tabel sau view existent. UPDATE este una din privilegiile SGBD controlate de către GRANT și REVOKE

DELETE

Modifică parțial sau în întregime tuplul existent de date dintr-un tabel sau view. Disponibil în SQL, DSQL și isql.

DELETE specifică unul sau mai multe tuple pentru ștergere din tabel sau view care poate fi modificat. DELETE este una din privilegiile SGBD controlate de către GRANT și REVOKE.

Modalitatea realizării SQL în Delphi

Aplicațiile Delphi se adresează la date prin intermediul BDE (Borland Database Engine). Tipul de acces la bazele de date variază în funcție de tipul bazei de date. Bazele de date locale Paradox, dBASE, MS Access și FoxPro sunt apelate de BDE prin intermediul driver-ilor standarde. Datele din serverele SQL sânt primite datorită utilizării sistemului special de driver-e SQL Links. Un rol important în prelucrarea și trimiterea cererii îl joacă sistemul de prelucrare a cererilor – componentă a procesorului BD. Toate sistemele de gestionare a bazelor de date nu utilizează limbajul SQL ca mijloc principal în lucru cu datele. Cu toate acestea, BDE cu ajutorul driver-ului standard respectiv translează cererile ce vin de la aplicații într-o formă înțeleasă de sistemul de gestiune al bazei de date și primește răspuns. Deoarece cererea către orice BD locală se execută de un singur mecanism, există o sintaxă unică SQL pentru lucru a astfel de date. Această variantă poartă denumirea de SQL local și este o parte componentă din standardul SQL92.

Toate serverele BD care lucrează cu BDE prin SQL Links sunt niște sisteme industriale complicate și lucrează pe baza extensiilor proprii ale limbajului. În acest caz BDE pur și simplu transmite cererea la server, fără a o transla sau modifica. Este evident că, în acest caz elaboratorul aplicației trebuie să cunoască această variantă SQL.

Mecanismul de funcționare a cererilor în aplicațiile BD Delph

Rolul principal în pregătirea și dispecerizarea cererilor SQL îl joacă BDE. Însăși prelucrarea cererilor este efectuată de sistemul de prelucrare a cererilor – un element special al arhitecturii procesorului BD, care identifică setul de date al cererii, îndeplinește analiza sintaxei și, în dependență de parametrii BDE setați, transmite varianta locală a cererii driver-ului standard al BD respective sau adresează cererea serverului BD prin sistemul de driver-e SQL Links.

În calitate de inițiator al cererii este programul aplicație. Pentru crearea și executarea cererilor se folosește componenta TQuery, care conține textul cererii și încapsulează setul de date cu rezultatul executării cererii. Acest set de date poate fi utilizat la fel ca și orice alt set de date creat cu ajutorul componentei TTable.

Primind comanda de executare a cererii, componenta TQuery inițializează pregătirea cererii către executare, care include câteva etape.

Sarcina principală de pregătire a cererii – crearea legăturii dintre sistemul de gestiune al BD care va executa cererea, și setul de date al componentei TQuery respective. Dacă acest lucru a fost realizat, atunci se determină modalitatea de executare a cererii – accesul local prin intermediul driver-ului standard sau transmiterea textului cererii la server. După aceasta se setează valorile pentru variabilele parametrilor cererii.

Dacă cererea se execută local, atunci ea se transmite prin intermediul driver-ului standard la sistemului de gestiune al BD respectiv pentru a fi executată de acesta. Prin legătura creată la pregătirea cererii rezultatul se transmite în setul de date al aplicației.

Dacă cererea a fost adresată serverului SQL, atunci se presupune că ea are o sintaxă specifică, corespunzătoare serverului dat. În acest caz toată pregătirea specială a parametrilor cererii se execută de partea serverului. BDE asigură numai transmiterea cererii și întoarcerea rezultatului de execuție la setul de date al aplicației.

Încă o modalitate de executare a cererilor pentru serverul SQL – adresarea directă la funcțiile API a serverului respectiv. Aceasta însă, este metoda cea mai rapidă, dar și cea mai complicată pentru elaboratori.

Componenta TQuery

Componenta TQuery, la fel ca și componenta TTable se utilizează pentru crearea și gestionarea cu setul de date. Pentru componenta TTable este necesar de a seta proprietatea DatabaseName, care determină baza de date, și proprietatea TableName, care determină tabelul din baza de date – sursa nemijlocită a datelor. Pentru componenta TQuery se fixează de asemenea proprietatea DatabaseName, iar pentru setarea sursei datelor servește proprietatea SQL, care conține textul cererii. De fapt, acesta tot este denumire a tabelului (în cerere ea se conține întotdeauna), numai cu condiții adăugătoare de selectare a datelor.

De exemplu, cererea de mai jos:

Select * from Conducator

conține un set de date identic cu cel al tabelului Conducator și prezintă facilități similare de lucru cu aceste date.

Ierarhia părinților acestor două componente este de asemenea similară: TDataSet – TBDEDataSet – TDBDataSet. Aceasta ne dovedește încă odată, că menirea principală a componentei TQuery – crearea setului de date și asigurării accesului la el din aplicație.

Cu toate acestea componenta TQuery reprezintă un instrument puternic și flexibil de realizare și susținere a funcțiilor de bază și secundare a aplicației. Cu ajutorul acestei componente pot fi ușor soluționate astfel de probleme, care cu ajutorul componentei TTable se soluționează mult mai greu, sau nu se soluționează deloc.

Nu trebuie să uităm că aceste avantaje asigură nu însăți componenta TQuery, dar limbajul SQL.

La elaborarea aplicațiilor client pentru servere SQL această componentă trebuie să joace rolul principal. În cazul aplicațiilor locale de asemenea există un număr mare de probleme, care pot fi soluționate mai comod cu ajutorul componentei TQuery. Însă există multe situații, în care utilizarea componentei TTable este mai avantajoasă.

În afară de asta, componenta TQuery crează un set de date cu o structură numai din acele câmpuri, care sînt indicate în textul cererii. Structura setului de date a componentei TTable coincide cu structura tabelului BD (dacă obiectele câmpurilor sînt dinamice). Din această cauză în lucrul cu câteva câmpuri din setul de date foarte mare componenta TQuery permite de a economisi resurse.

Lucrul cu câmpurile din componenta TQuery este similar ca și cu TTable. Obiectele câmpurilor pot fi statice și dinamice. Câmpurile calculabile pot fi create cu ajutorul redactorului câmpurilor sau prin crearea expresiei calculabile în cadrul cererii.

Datorită moștenirii, componenta TQuery are posibilitatea de a aplica mecanismele de filtrare, căutare, etc. asupra înscrierilor din setul său de date. Aceasta îi asigură componentei TQuery o flexibilitate adăugătoare.

Reprezentarea datelor pentru componenta TQuery se efectuează prin intermediul componentei TDataSource.

Proprietățile și metodele componentei TQuery sînt prezentate în tabelul de mai jos.

Proprietățile și metodele componentei TQuery

(continuare) Tab. 3

Textul cererii este determinat de proprietatea SQL, la setarea căruia se utilizează redactorul simplu care se activează prin apăsarea butonului proprietății din Object Inspector.

Executarea cererii poate fi realizată prin trei metode.

Dacă cererea întoarce rezultatul în setul de date (de exemplu, folosește operatorii INSERT, DELETE, UPDATE), atunci se folosește metoda ExecSQL. După executarea cererii setul de date al componentei nu se deschide. Încercarea de a folosi metoda Open pentru astfel de cerere va duce la eroare.

Pentru a permite redactarea setului de date a cererii este necesar de a seta valoarea True proprietății RequestLive. Această proprietate nu va fi activată pentru cererea, rezultatul căreia nu se modifică din definire.

Pentru pregătirea de execuție a cererii se folosește metoda Prepare. Deși această operație se execută automat de către BDE, poate apărea totuși o situație în care elaboratorul va fi nevoit să folosească această metodă.

Metoda UnPrepare eliberează resursele alocate în procesul de pregătire a cererii.

Proprietatea Params permite elaboratorului de a modifica condițiile de selectare a cererii în dependență de situația curentă. Această proprietate reprezintă un set de parametri a cererii ce pot fi modificați.

Descrierea sistemului informațional "Registratorul" al Camerei Înregistrării de Stat

Sistemul informațional "Registratorul" este un sistem complex, destinat pentru gestiunea datelor ale întreprinderilor și organizațiilor înregistrate în Republica Moldova, elaborat la comanda Camerei Înregistrării de Stat al Republicii Moldova.

Scopul „Registratorului” este înregistrarea de stat a întreprinderilor și organizațiilor. Prin înregistrarea de stat se subînțelege – certificarea, din partea organului înregistrării de stat, a creării, reorganizării, ori lichidării întreprinderii sau organizației, precum și a modificărilor și completărilor din documentele de constituire ale acestora. Toate datele necesare pentru înregistrarea de stat se păstrează în baza de date a SI „Registratorul”, numită "Registrul de stat".

Cu ajutorul SI „Registratorul” se poate duce o evidențe minuțioasă a tuturor înregistrărilor de stat, cît și statistici de diferite feluri, datorită unui modul flexibil de creare a rapoartelor, integrat în interiorul sistemului. Sistemul este alcătuit din următoarele componente:

baza de date "Registrul de stat" a sistemului

programul "Registru"

programul "RegistruSet"

Descrierea structurii bazei de date a sistemului informațional

Baza de date a sistemului informațional "Registratorul" este implementată în sistemul de gestiune al bazelor de date (SGBD) InterBase versiunea 5.5.0.742 al firmei InterBase Software Corporation.

Pentru a optimiza lucrul proiectantului, în procesul elaborării structurii bazei de date, s-a folosit instrumentarul CASE de proiectare a bazelor de date – ERwin. Utilizarea acestui instrument ne dă posibilitatea în mod vizual să creăm tabele, să efectuăm unele modificări n structura bazei de date. Structura bazei de date este foarte ușor de transferat la alta SGBD relațională care suportă standardul ANSI SQL, utilizând ERwin.

Mai jos vom descrie mai amănunțit structura bazei de date.

Tabelele(T), utilizate în complexul programelor se divizează în 7 categorii:

Т ce păstrează informația actuală;

Т ce păstrează informația temporară la etapa inițială de înregistrare;

Т ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale;

Т ce păstrează istoria modificărilor;

Т ce sânt clasificatoare;

Т ce păstrează informația tehnică a elementelor complexului;

Т ce păstrează informația despre structura bazei de date a complexului.

La categoria tabelelor, ce păstrează informația actuală, se referă următoarele table, în continuare le vom denumi tabele informaționale:

S_NAM_PR – conține datele despre întreprindere;

CONDUCAT – conține datele despre managerul principal al întreprinderii;

FONDATOR – conține datele despre fondatorii întreprinderii;

S_RS_PR – conține datele despre conturile bancare ale întreprinderii;

FILIALE – conține datele despre filialele întreprinderii;

REORG – conține datele despre întreprinderile din care s-a reorganizat întreprinderea dată;

ADRES_ST – conține adresa managerului principal sau a fondatorilor întreprinderii daca ei locuiesc în afara Republicii Moldova;

LISTDOC – conține lista documentelor, prezentate pentru înregistrarea întreprinderii;

LISTDOCMOD – conține lista documentelor, prezentate pentru înregistrarea efectuării modificărilor;

La categoria tabelelor ce păstrează informația temporară la etapa inițială de înregistrare se referă următoarele tabele:

PREDINIT – conține datele despre întreprindere;

CONDINIT – conține datele despre managerul principal al întreprinderii;

FONDINIT – conține datele despre fondatorii întreprinderii;

RS_INIT – conține datele despre conturile bancare ale întreprinderii;

FIL_INIT – conține datele despre filialele întreprinderii;

REORGINIT – conține datele despre întreprinderile din care s-a reorganizat întreprinderea dată;

ADRSINIT – conține adresa managerului principal sau a fondatorilor întreprinderii daca ei locuiesc în afara Republicii Moldova;

LDOCINIT – conține lista documentelor, prezentate pentru înregistrarea întreprinderii;

La categoria tabelelor ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale se referă următoarele tabele:

PREDMOD – conține datele despre întreprindere;

CONDMOD – conține datele despre managerul principal al întreprinderii;

FONDMOD – conține datele despre fondatorii întreprinderii;

RS_MOD – conține datele despre conturile bancare ale întreprinderii;

FIL_MOD – conține datele despre filialele întreprinderii;

REORGINIT – conține datele despre întreprinderile din care s-a reorganizat întreprinderea dată;

ADRSMOD – conține adresa managerului principal sau a fondatorilor întreprinderii daca ei locuiesc în afara Republicii Moldova;

LDOCMOD – conține lista documentelor, prezentate pentru înregistrarea întreprinderii;

LDOCMODM – conține lista documentelor, prezentate pentru înregistrarea modificărilor;

La categoria tabelelor ce păstrează istoria modificărilor se referă următoarele tabele:

PREDHIST – conține datele despre întreprindere;

CONDHIST – conține datele despre managerul principal al întreprinderii;

FONDHIST – conține datele despre fondatorii întreprinderii;

RS_HIST – conține datele despre conturile bancare ale întreprinderii;

FIL_INIT – conține datele despre filialele întreprinderii;

ADRSHIST – conține adresa managerului principal sau a fondatorilor întreprinderii daca ei locuiesc în afara Republicii Moldova;

La categoria tabelelor clasificatoare se referă următoarele tabele:

S_JURID – clasificatorul formelor juridice de activitate;

S_PROPRM – clasificatorul formelor de proprietate pe teritoriul Republicii Moldova;

S_PROPRS – clasificatorul formelor de proprietate în afara hotarelor Republicii Moldova;

S_ ACTIV – clasificatorul genurilor de activitate;

TIPINTR – clasificatorul tipurilor de întreprinderi;

S_SUBORD – clasificatorul subordonărilor;

S_TARA – clasificatorul țărilor;

S_JUDETI – clasificatorul județelor;

S_CUATM – clasificatorul localităților;

S_ATE – clasificatorul raioanelor;

POSTA – clasificatorul oficiilor poștale;

STRAZI – clasificatorul denumirii străzilor;

S_BANK – clasificatorul băncilor;

S_IDENT – clasificatorul tipurilor actelor de identitate ce identifică managerul principal sau fondatorul;

S_DOCUM – clasificatorul tipurilor de documente necesare pentru înregistrarea întreprinderii ș înregistrarea modificărilor oficiale ale întreprinderii;

S_WORDS – clasificatorul cuvintelor (se utilizează cu S_DOCUM);

S_LICHIDAT – clasificatorul cauzelor radierii întreprinderii;

S_REG – clasificatorul tipurilor înregistrării întreprinderilor sau a modificărilor oficiale;

S_PREFIX – clasificatorul prefixelor în denumirea întreprinderilor;

La categoria tabelelor ce păstrează informația despre structura bazei de date a complexului se referă următoarele tabele:

PREDLFLD – conține informație despre câmpurile tabelei S_NAM_PR, a componentelor pe formă care servesc pentru prelucrarea informației câmpului corespunzător, și în unele cazuri informația despre clasificatorul cu care câmpul dat are referință;

CONDLFLD – conține informație despre câmpurile tabelei CONDUCAT, a componentelor pe formă care servesc pentru prelucrarea informației câmpului corespunzător, și în unele cazuri informația despre clasificatorul cu care câmpul dat are referință;

RSLFLD – conține informație despre câmpurile tabelei S_RS_PR, a componentelor pe formă care servesc pentru prelucrarea informației câmpului corespunzător, și în unele cazuri informația despre clasificatorul cu care câmpul dat are referință;

FONDLFLD – conține informație despre câmpurile tabelei FONDATOR, a componentelor pe formă care servesc pentru prelucrarea informației câmpului corespunzător, și în unele cazuri informația despre clasificatorul cu care câmpul dat are referință;

FILLFLD – conține informație despre câmpurile tabelei FILIALE;

REORGFLD – conține informație despre câmpurile tabelei REORG;

ADRSFLD – conține informație despre câmpurile tabelei ADRES_ST;

S_SPR – conține lista clasificatoarelor;

TABLES – conține lista tabelelor care păstrează informația actuală;

S_ANI – clasificatorul anilor;

S_LUNI – clasificatorul lunilor;

SQL – tabela, care se utilizează la construire a SQL-interpelărilor de către utilizator.

La categoria tabelelor ce păstrează informația tehnică a elementelor complexului se referă următoarele tabele:

LOCKS – conține lista utilizatorilor conectați în momentul dat la sistem;

USERS – conține informația despre utilizatorii înregistrați în sistem

RB_TABLE – conține informație despre tabelele sistemului, se utilizează pentru lucrul generatorului de rapoarte;

RB_FIELD – conține informație despre câmpurile tabelelor sistemului, se utilizează pentru lucrul generatorului de rapoarte;

RB_JOIN – conține informație despre joncțiunile câmpurilor ale tabelelor sistemului, se utilizează pentru lucrul generatorului de rapoarte;

LASTCOD – conține informația despre ultima întreprindere înregistrată în sistem.

Descrierea câmpurilor tabelelor din baza de date.

Tabela S_NAM_PR

NUMREG Char(9) numărul de înregistrare a întreprinderii;

D_REG Date data înregistrării;

TIP_REG Char(1) tipul înregistrării (S_REG.TIP_REG);

CODFISCAL Char(10) codul fiscal;

NR_CERERE Char(10) numărul cererii pentru înregistrare;

DATCER Date data cererii pentru înregistrare;

KD_JURID Char(3) forma juridică de activitate (S_JURID.KD_JURID);

KD_PROPR_M Char(2) forma de proprietate în Moldova

(S_PROPRM.KD_PROPR_M);

KD_PROPR_S Char(2) forma de proprietate străină (S_PROPRS.KD_PROPR_S);

PER_ACTIV Char(3) perioada activității;

COD_CUIIO Char(8) cod CUIIO;

TIPINTR Char(3) tipul întreprinderii;

KD_SUBORD Char(5) codul întreprinderii superioare

(S_SUBORD.KD_SUBORD);

IND_BUGET Char(1) “1” – Autofinanțare;

“2” – Bugetar;

“3” – Necomercial.

PERSJURID Char(1) “0” – Persoana fizica;

“1” – Persoana juridica;

“2” – Filiala.

NAME_S Char(50) denumirea abreviată;

NAME_L Char(150) denumirea lungă;

KD_CUATM Char(4) codul localității (S_CUATM.KD_CUATM);

KD_JUD Char(2) codul județului (S_JUD.KD_JUD);

KD_ATE Char(2) codul raionului (S_ATE.KD_ATE);

KD_POSTA Char(4) codul poștal (S_POSTA.KD_POSTA);

KD_STRAZI Char(4) codul străzii (STRAZI.KD_STRAZI);

CASA Char(5) numărul casei;

BLOC Char(3) numărul blocului;

APART Char(3) numărul apartamentului(oficiului);

TELEFON Char(20) numărul de telefon;

FAX Char(20) numărul fax;

KD_ACTIV Char(5) codul genului principal de activitate

(S_ACTIV.KD_ACTIV);

KD_ACTIV1 Char(5) codul genului de activitate №2 (S_ACTIV.KD_ACTIV);

KD_ACTIV2 Char(5) codul genului de activitate №3 (S_ACTIV.KD_ACTIV);

KD_ACTIV3 Char(5) codul genului de activitate №4 (S_ACTIV.KD_ACTIV);

KD_ACTIV4 Char(5) codul genului de activitate №5 (S_ACTIV.KD_ACTIV);

CAPSOC Numeric(16) capital social;

CAPSOCINCL Numeric(16) cota proprietății de stat/municipale în capitalul social;

APORTRM Numeric(16) aportul asociațiilor din RM la capitalul social;

APORTM_NAT Numeric(16) aportul asociațiilor din RM la capitalul social, în natură;

APORTS Numeric(16) aportul asociațiilor străini la capitalul social;

APORTS_NAT Numeric(16) aportul asociațiilor străini la capitalul social, în natură;

NUMCERT Char(10) numărul certificatului eliberat;

D_CERT Date data certificatului eliberat;

KD_STRUAUT Char(5) codul organizației care a eliberat permisul pentru fondarea

întreprinderii (S_SUBORD.KD_SUBORD);

NUMCONST Char(10) numărul permisului pentru fondare;

D_CONST Date data permisului pentru fondare;

KD_STRLIC Char(5) codul organizației care a eliberat permisul pentru primirea

licenței (S_SUBORD.KD_SUBORD);

NUMLIC Char(10) numărul permisului pentru primirea licenței;

D_LIC Date data permisului pentru primirea licenței;

SUPERREG Char(9) numărul de înregistrare a întreprinderii supreme;

KD_LICHID Char(2) codul tipului radierii întreprinderii

D_ANUL Date data radierii întreprinderii;

PRN_DECIZ Char(1) “1” – indice dacă Decizie a fost deacum imprimată;

DATMODIF Date data efectuării ultimelor modificări

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

KD_ANUL Char(4) anul înregistrării (S_ANI.KD_ANUL);

KD_LUNA Char(2) luna înregistrării (S_LUNI.KD_LUNA);

D_VVOD Date data de sistem a introducerii/modificări informației;

STARE Char(1) rezervat;

STATUT Char(3) rezervat.

Tabela CONDUCAT

NUMREG Char(9) numărul de înregistrare a întreprinderii;

KD_IDENT Char(2) codul documentului de identificare a persoanei

(S_IDENT.KD_IDENT);

IDNP Char(17) numărul, seria documentului de identificare;

NUMELE Char(25) numele;

PRENUM Char(30) prenumele;

PATRONIM Char(30) patronimicul;

D_NAST Date data nașterii;

KD_TARA_CET Char(3) codul țării cetățeniei (S_TARA.KD_TARA);

KD_TARA Char(3) codul țării domiciliului (S_TARA.KD_TARA);

KD_CUATM Char(4) codul localității (S_CUATM.KD_CUATM);

KD_JUD Char(2) codul județului (S_JUD.KD_JUD);

KD_ATE Char(2) codul raionului (S_ATE.KD_ATE);

KD_POSTA Char(4) codul poștal (S_POSTA.KD_POSTA);

KD_STRAZI Char(4) codul străzii;

CASA Char(5) numărul casei;

BLOC Char(3) numărul blocului;

APART Char(3) numărul apartamentului (oficiului);

TELEFON Char(20) numărul de telefon;

FAX Char(20) numărul faxului;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela FONDATOR

NUMREG Char(9) numărul de înregistrare a întreprinderii;

NR_FOND Numeric(3) numărul de ordine a fondatorului;

KD_IDENT Char(2) codul documentului de identificare a persoanei

(S_IDENT.KD_IDENT);

IDNP Char(17) numărul, seria documentului de identificare sau dacă

fondatorul este persoana juridică, atunci numărul lui de

înregistrare;

PERSJURID Char(1) “1” – fondatorul este persoană juridică,

“0” – fondatorul este persoană fizică;

NAME Char(150) N.P.P. sau denumirea întreprinderii;

D_NAST Date data nașterii sau data înregistrării;

KD_TARA_CET Char(3) codul țării cetățeniei (S_TARA.KD_TARA);

KD_TARA Char(3) codul țării domiciliului/ înregistrării

(S_TARA.KD_TARA);

KD_CUATM Char(4) codul localității (S_CUATM.KD_CUATM);

KD_JUD Char(2) codul județului (S_JUD.KD_JUD);

KD_ATE Char(2) codul raionului (S_ATE.KD_ATE);

KD_POSTA Char(4) codul poștal (S_POSTA.KD_POSTA);

KD_STRAZI Char(4) codul străzii;

CASA Char(5) numărul casei;

BLOC Char(3) numărul blocului;

APART Char(3) numărul apartamentului (oficiului);

TELEFON Char(20) numărul de telefon;

FAX Char(20) numărul faxului;

COTA Numeric(16) cota fondatorului în capitalul social, exprimată în bani;

COTA_PROC Numeric(3) cota fondatorului în capitalul social, exprimată în %;

KD_VALUT Char(1) codul valutei, “0” – Lei RМ,

“1” – dolari SUA;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela S_RS_PR

NUMREG Char(9) numărul de înregistrare a întreprinderii;

CODBANC Char(3) codul băncii cu contul de decontare în lei;

RS Char(15) numărul contului de decontare în lei;

CODBANC_US Char(3) codul băncii cu contul de decontare în dolari SUA;

RS Char(15) numărul contului de decontare în dolari SUA;

D_ACUMUL Date ultima dată de acumulare a capitalului social;

COTA Numeric(16) suma depunerii în cont;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela FILIALE

NUMREG Char(9) numărul de înregistrare a întreprinderii;

NR_FILIAL Numeric(3) numărul de ordine a filialei;

NUMREGFIL Char(9) numărul de înregistrare a filialei;

NAME Char(150) denumirea filialei;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela REORG

NUMREG Char(9) numărul de înregistrare a întreprinderii – creată în

rezultatul reorganizării

NR_REC Numeric(3) numărul de ordine al înregistrării;

D_REORG Date data efectuării reorganizației;

NUM_REORG Char(9) numărul de înregistrare a întreprinderii – din care s-a

reorganizat;

TIP_REG Char(1) tipul reorganizării (S_REG.TIP_REG) afară de valoarea 0;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela ADRES_ST

NUMREG Char(9) numărul de înregistrare a întreprinderii;

TIP_OBJ Char(1) tipul persoanei: “1” – managerul principal,

“2” – fondatorul;

NR_OBJ Numeric(3) numărul de ordine a persoanei;

ADRESA Char(100) adresa străină a persoanei;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela LISTDOC

NUMREG Char(9) numărul de înregistrare a întreprinderii;

KD_DOCUM Char(2) codul șablonului documentului

(S_DOCUM.KD_DOCUM);

NR_DOC Numeric(2) numărul de ordine al documentului;

NAME Char(250) conținutul documentului;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela LISTDOCMOD

NUMREG Char(9) numărul de înregistrare a întreprinderii;

KD_DOCUM Char(2) codul șablonului documentului

(S_DOCUM.KD_DOCUM);

D_MOD Date data oficială a înregistrării modificărilor;

NR_DOC Numeric(2) numărul de ordine al documentului;

NAME Char(250) conținutul documentului;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii, este

necesar deoarece Numărul de Înregistrare poate fi schimbat

în legătură cu unele modificări oficiale;

Tabela PREDINIT

Structura tabelei este identică cu structura tabelei S_NAM_PR

Tabela CONDINIT

Structura tabelei este identică cu structura tabelei CONDUCAT

Tabela FONDINIT

Structura tabelei este identică cu structura tabelei FONDATOR

Tabela RS_INIT

Structura tabelei este identică cu structura tabelei S_RS_PR

Tabela FIL_INIT

Structura tabelei este identică cu structura tabelei FILIALE

Tabela REORGINIT

Structura tabelei este identică cu structura tabelei REORG

Tabela ADRSINIT

Structura tabelei este identică cu structura tabelei ADRES_ST

Tabela LDOCINIT

Structura tabelei este identică cu structura tabelei LISTDOC

Tabela PREDMOD

Structura tabelei este identică cu structura tabelei S_NAM_PR

Tabela CONDMOD

Structura tabelei este identică cu structura tabelei CONDUCAT

Tabela FONDMOD

Structura tabelei este identică cu structura tabelei FONDATOR

Tabela RS_MOD

Structura tabelei este identică cu structura tabelei S_RS_PR

Tabela FIL_MOD

Structura tabelei este identică cu structura tabelei FILIALE

Tabela REORGMOD

Structura tabelei este identică cu structura tabelei REORG

Tabela ADRSMOD

Structura tabelei este identică cu structura tabelei ADRES_ST

Tabela LDOCMOD

Structura tabelei este identică cu structura tabelei LISTDOC

Tabela LDOCMODM

Structura tabelei este identică cu structura tabelei LISTDOCMOD

Tabela PREDHIST

Structura tabelei este identică cu structura tabelei S_NAM_PR cu unele excepții:

TYPE_HIST Char(1) tipul modificărilor:

“1” – înregistrarea modificărilor oficiale;

“0” – modificările legate nu necesitatea corectării

datelor în rezultatul comiterii erorilor în

procesul introducerii informației;

FIELDSMODIF Char(20) pentru păstrarea listei codurilor câmpurilor modificate.

DATMODIF Date data înregistrării modificărilor.

Tabela CONDHIST

Structura tabelei este identică cu structura tabelei CONDUCAT cu unele excepții:

TYPE_HIST Char(1) tipul modificărilor:

“1” – înregistrarea modificărilor oficiale;

“0” – modificările legate nu necesitatea corectării

datelor în rezultatul comiterii erorilor în

procesul introducerii informației;

FIELDSMODIF Char(20) pentru păstrarea listei codurilor câmpurilor modificate.

DATMODIF Date data înregistrării modificărilor.

Tabela FONDHIST

Structura tabelei este identică cu structura tabelei FONDATOR cu unele excepții:

TYPE_HIST Char(1) tipul modificărilor:

“1” – înregistrarea modificărilor oficiale;

“0” – modificările legate nu necesitatea corectării

datelor în rezultatul comiterii erorilor în

procesul introducerii informației;

FIELDSMODIF Char(20) pentru păstrarea listei codurilor câmpurilor modificate.

DATMODIF Date data înregistrării modificărilor.

Tabela RS_HIST

Structura tabelei este identică cu structura tabelei S_RS_PR cu unele excepții:

TYPE_HIST Char(1) tipul modificărilor:

“1” – înregistrarea modificărilor oficiale;

“0” – modificările legate nu necesitatea corectării

datelor în rezultatul comiterii erorilor în

procesul introducerii informației;

FIELDSMODIF Char(20) pentru păstrarea listei codurilor câmpurilor modificate.

DATMODIF Date data înregistrării modificărilor.

Tabela ADRSHIST

Structura tabelei este identică cu structura tabelei ADRES_ST cu unele excepții:

TYPE_HIST Char(1) tipul modificărilor:

“1” – înregistrarea modificărilor oficiale;

“0” – modificările legate nu necesitatea corectării

datelor în rezultatul comiterii erorilor în

procesul introducerii informației;

FIELDSMODIF Char(20) pentru păstrarea listei codurilor câmpurilor modificate.

DATMODIF Date data înregistrării modificărilor.

Tabelele PREDLFLD, CONDLFLD, RSLFLD, FILLFLD, FONDLFLD, REORGFLD, ADRSFLD

KD_FIELD Char(1) conține codurile câmpurilor tabelelor informaționale, la

înregistrarea modificărilor într-un câmp oarecare a acestor

tabele, în câmpul FIELDSMODIF a corespunzătoarei

tabele cu istoria modificărilor, se introduce codul dat;

NAME_FIELD Char(11) conține denumirea câmpurilor tabelelor informaționale;

VAR_NAME Char(20) conține denumirile componentelor pe forma de introducere,

a datelor în care se găsesc datele, care la momentul

înregistrării vor fi înscrise în baza de date, dacă câmpului îi

corespunde o componentă pe formă;

TIP_PROV Char(1) “1” – câmpul pe formă de introducere trebuie să fie

completat la momentul înregistrării “finale”,

“2” – câmpul pe formă de introducere trebuie să fie

completat atât la momentul înregistrării "inițiale"

cât și “finale”,

“0” – câmpul poate să rămână necompletat,

“ “ – câmpul tabelei nu are componentă pe forma;

NAME Char(60) conține denumirea de identificare a datelor, ce se păstrează

în câmpul tabelei informaționale corespunzătoare;

NAME_SPR Char(20) conține denumirea clasificatorului dacă câmpul dat se

referă la clasificator, în caz contrar – nul;

NAME_KDF Char(20) conține denumirea câmpului cu codul în clasificator dacă

câmpul dat al tabelei informaționale se referă la un

clasificator, altfel – nul;

NAME_NF Char(20) conține denumirea câmpului cu descifrarea dacă câmpul dat

tabelei informaționale se referă la un clasificator, altfel nul;

Tabela TABLES

NR Numeric(2) numărul de ordine al tabelei în listă;

TNAME Char(20) denumirea tabelei informaționale;

TFLNAME Char(20) denumirea tabelei ce conține informație tehnică despre

tabela informațională dată, structura e descrisă mai sus;

NAME Char(20) denumirea de identificare a tabelei informaționale.

Tabela S_SPR

NR Numeric(2) numărul de ordine al tabelei în listă;

SPR_NAME Char(20) denumirea tabelei clasificatoare;

FIELD_KD Char(20) denumirea câmpului cu codul în clasificator;

FIELD_NAME Char(20) denumirea câmpului cu descifrarea în clasificator;

NAME Char(30) denumirea de identificare a tabelei informaționale.

Tabela SQL

NR Numeric(3) numărul de ordine al SQL-interpelării în listă;

FV1NAME Char(80) conține denumirea de identificare a tabelei informaționale,

semnul “.” și denumirea de identificare a câmpului tabelei

informaționale, ce participă la construirea SQL- interpelării

de exemplu, “Intreprinderi.Numarul de înregistrare”;

OPER Char(20) operația în condiție a SQL-interpelării

între FV1NAME și FV2NAME;

FV2NAME Char(80) conține denumirea de identificare a tabelei informaționale,

semnul “.” și denumirea de identificare a câmpului tabelei

informaționale, ce participă la construirea SQL-

interpelării, de exemplu, “Intreprinderi.Numarul de

înregistrare”; Poate conține o valoare constantă, de

exemplu numărul de înregistrare concret;

LOP Char(7) operatorul logic de unificare a condiției a acestei

SQL-interpelării cu următoarea;

FV1KD Char(20) conține denumirea câmpului tabelei, care se utilizează în

SQL-interpelare, de exemplu “S_NAM_PR .NUMREG”;

FV2KD Char(20) conține denumirea câmpului tabelei, care se utilizează în

SQL-interpelare, de exemplu “S_NAM_PR .NUMREG”;

ERR Char(3) colectează informație despre erorile în SQL-interpelare;

SCOB1 Char(2) conține numărul de paranteze de deschidere "(" necesare

pentru SQL-interpelare;

SCOB2 Char(2) conține numărul de paranteze de închidere "(" necesare

pentru SQL-interpelare;

Tabela LOCKS

USERID Varchar(20) numele utilizatorului sub care el intră în sistem;

ID_RECORD Char(9) numărul pentru identificarea informației întreprinderii cu

care în momentul dat lucrează utilizatorul

PREDTYPE Char(1) indică tipul operației efectuate asupra întreprinderii:

"1" –înregistrarea;

"2" – modificarea;

"3" – corectarea datelor finale;

"4" – radierea întreprinderii;

LASTTIME Date ultimul moment de timp în care a fost verificat dacă

utilizatorul se află în sistem;

CONNECTID Date momentul de timp în care utilizatorul a intrat în sistem;

Tabela USERS

USERID Varchar(20) numele utilizatorului sub care el intră în sistem;

USERPASS Varchar(10) parola de acces a utilizatorului pentru autentificare;

NAME Varchar(50) numele complet a utilizatorului;

STATUS Char(1) indică dacă utilizatorul are dreptul de acces în sistem:

"N" – utilizatorului îi este oferit dreptul de acces normal;

"S" – utilizatorul este suspendat;

USERTYPE Varchar(22) tipul privilegiilor utilizatorului:

"ADMIN" – Administratorul sistemului;

"INTRODUCERE" – dreptul de modificare a informației;

"VIZUALIZARE" – dreptul de vizionare a informației.

Tabela RB_TABLE

TABLE_NAME Varchar(60) denumirea tabelelor sistemului;

TABLE_ALIAS Varchar(60) denumirea de identificare a tabelelor sistemului;

CONST_TABLE Char(1) indică dacă tabelul este clasificator sau nu;

COD_FIELD Varchar(60) indică codul cheie al tabelului, dacă el este un clasificator

Tabela RB_FIELD

TABLE_NAME Varchar(60) denumirea tabelelor sistemului;

FIELD_NAME Varchar(60) denumirea câmpurilor acestor tabelele;

FIELD_ALIAS Varchar(60) denumirea de identificare a câmpurilor tabelelor sistemului;

DATATYPE Varchar(60) tipul datelor păstrate în aceste câmpuri;

SELECTABLE Varchar(1) indică dacă câmpul dat poate fi utilizat la operație de

selectare a informației;

SERCHABLE Varchar(1) indică dacă câmpul dat poate fi utilizat la operație de

căutare a informației;

SORTABLE Varchar(1) indică dacă câmpul dat poate fi utilizat la operație de

sortare a informației;

AUTOSERCH Varchar(1) indică proprietatea de autocăutare a informației utilizând

câmpul dat;

MANDATORY Varchar(1) indică proprietatea de constrângere a câmpul dat în

procesul selectării informației;

Tabela RB_JOIN

TABLE_NAME1 Varchar(60) denumirea tabelului părinte;

TABLE_NAME1 Varchar(60) denumirea tabelului la care se face referire;

JOIN_TYPE Varchar(60) denumirea tipului joncțiunii tabelelor;

FIELD_NAMES1 Varchar(255) denumirea câmpului tabelului părinte care face joncțiunea;

OPERATORS Varchar(60) tipul operației logice aplicate asupra valorilor câmpurilor 1

și 2;

FIELD_NAMES1 Varchar(255) denumirea câmpului tabelului la care se face referire;

Tabela LASTCOD

LASTCOD Char(9) numărul de identificare a ultimii întreprinderi înregistrate în

sistem;

Descrierea programului "Registru" al sistemului informațional

Funcția de bază pe care o deține programul "Registru" este introducerea/modificarea informației despre întreprinderile înregistrate în Republica Moldova, imprimarea documentelor necesare, ducerea statisticii și crearea diferitor rapoarte.

Programul "Registru" este elaborat în mediul de dezvoltare rapidă a aplicațiilor Delphi 5 al firmei Inprise. Programul este efectuat pe diferite forme, care sânt activate cu ajutorul meniului de pe forma principală a programului. La fel pe forma principală sânt plasate butoanele pentru accesul rapid la majoritatea opțiunilor din meniul principal.

La prima lansare programul va cere de specificat calea spre baza de date a sistemului informațional. La oricare următoare lansare programul în primul rând va cere autentificarea utilizatorului programei(în urmare operatorul). Autentificarea se face prin introducerea numelui utilizatorului și a parolei de acces. După autentificarea corectă se permite lucrul cu programul.

Mecanismul de accesare a informației de către utilizatori este bazat pe privilegii. În sistemul informațional sânt specificate 3 tipuri de privilegii care pot fi conferite oricărui din utilizatori ai sistemului:

ADMIN – accesul nelimitat la resursele sistemului, precum și gestionarea datelor altor utilizatori, adică adăugarea utilizatorilor noi, eliminarea unor utilizatori, modificarea parolelor de acces a utilizatorilor în caz că utilizatorul și-a uitat parola;

INPUT – acest tip de utilizatori are dreptul de introducere-modificare a datelor întreprinderilor. Nu li se permite modificarea conținutului clasificatoarelor și administrarea informației privind amplasarea bazei de date.

VIEW – utilizatori cu cele mai mici privilegii. Au dreptul numai la vizionarea informației.

Forma de autentificare a utilizatorilor în sistem

La începutul lucrului, operatorului i se afișează forma principală a programului, care ne permite să alegem următoarele opțiuni din meniul principal:

înregistrarea unei întreprinderi noi;

modificarea și completarea datelor unei întreprinderi;

lichidarea întreprinderii;

imprimarea diferitor documente pentru înregistrarea de stat;

crearea diferitor rapoarte cu ajutorul generatorului de rapoarte implementat;

lucrul cu clasificatoarele auxiliare a sistemului;

deservirea tehnică a sistemului și căutarea întreprinderilor;

vizionarea informației despre sistemul dat.

Operațiile înregistrării de stat asupra întreprinderilor, în timp real durează câteva zile, există și cazuri când întreprinderea poate fi oficial înregistrată timp de o zi, dar în cazul dat toate documentele necesare trebuie să fie în stare ideală.

Mai jos vom descrie fiecare din aceste opțiuni.

Înregistrarea

În primul rând pentru începerea procedurii de înregistrare a întreprinderii, operatorul trebuie să aibă la dispoziție actele necesare pentru înregistrarea de stat, cu informația despre viitoarea întreprindere.

Deci pentru înregistrarea unei întreprinderi noi apelăm la meniul Înregistrarea –> Înregistrarea Inițială –> Introducere. În urma acestor operații se va afișa forma de introducere/modificare a datelor întreprinderii. Pentru a începe procedura de înregistrare, operatorul trebuie să introducă următoarele date:

datele generale ale întreprinderii(forma de proprietate, forma juridică de organizare, modul de finanțare, statutul juridic, perioada activității, etc.);

denumirea completă și abreviată a întreprinderii;

sediul întreprinderii;

datele despre managerul principal al întreprinderii;

genurile de activitate ale întreprinderii;

capitalul social (în unele cazuri și capitalul străin inclus)

rechizitele bancare ale întreprinderii;

datele despre fondatorii întreprinderii;

datele despre permise de activitate și licențe;

filialele întreprinderii;

informația despre reorganizarea întreprinderilor;

lista actelor prezentate pentru înregistrare;

La înregistrarea inițială toată informația introdusă se păstrează în blocul tabelelor ce păstrează informația inițială la etapa inițială de înregistrare.

Pentru unele întreprinderi nu este nevoie de introdus toată informația. Aceasta se precizează de către legislația în vigoare. De exemplu pentru întreprinderile la care forma juridică de organizare este întreprindere individuală, capitalul social constituie zero lei, deci nu este nevoie de introducerea rechizitelor bancare ale întreprinderii. La fel în acest caz fondatorului nu i se indică cota de participare. Datele despre permise pentru activitate și licențe se introduc numai pentru anumite genuri de activități, care necesită licențiere.

Dacă, până a înregistra oficial întreprinderea, apar unele completări sau e nevoie de efectuat unele corectări în informația inițială, apelăm la meniul Înregistrare –> Înregistrare Inițială –> Corectare. În urma acestor operații ne va apărea lista întreprinderilor, care sânt în procesul inițial de înregistrare, adică se păstrează în blocul tabelelor ce păstrează informația inițială de înregistrare. Utilizând săgeți, alegem întreprinderea necesară și efectuăm corectările, complectările necesare.

În cazul în care solicitantul se răzgândește sau înregistrarea oficială a întreprinderii este imposibilă din motive legislative, se apelează Înregistrare –> Înregistrare Inițială –> Lichidare pentru a șterge informația introdusă privind această întreprindere din blocul tabelelor ce păstrează informația temporară la etapa inițială de înregistrare.

Din momentul în care toată informația inițială este completă, operatorul imprimă "Cererea de înregistrare a întreprinderii" și apoi "Decizia privind înregistrarea întreprinderii(proiect)". Proiectul deciziei i se transmite registratorului de stat pentru examinare. Dacă registratorul are careva obiecții, atunci revenim la pasul Înregistrare –> Înregistrare Inițială –> Corectare pentru a corecta necesarul.

În caz contrar, dacă registratorul de stat după examinarea proiectului deciziei privind înregistrarea întreprinderii a dat acordul, se trece la pasul Înregistrare –> Înregistrare Finală –> Introducere.

După efectuarea acestui pas se va afișa lista cu întreprinderile care se află în procesul inițial de înregistrare. Utilizând săgeți alegem întreprinderea necesară din listă și tastăm Enter. Va apare forma de introducere/modificare a datelor, în care va trebui să specificăm datele finale de constituire a întreprinderii:

numărul de înregistrare;

data de înregistrare;

numărul cererii de înregistrare;

data cererii de înregistrare

numărul certificatului eliberat

data eliberării certificatului;

codul fiscal atribuit.

După apăsarea butonului "Înregistrarea finală" întreprinderea se înregistrează oficial în baza de date a sistemului.

În acest moment are loc transferarea informației privind întreprinderea specificată din blocul cu informație inițială de înregistrare în blocul cu informație actuală.

Ultimul pas al operației de înregistrare a întreprinderii este imprimarea "Deciziei de înregistrare a întreprinderii". Pentru aceasta apelăm Înregistrare –> Înregistrare Finală –> Tipărirea decizie p/u înregistrarea(finală), și nouă ni se va cere să introducem denumirea întreprinderii sau numărul ei de înregistrare. Apoi se afișează lista cu întreprinderile care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară și tastând Enter, se va imprima "Decizia de înregistrare a întreprinderii" în două exemplare, care au aceeași valoare juridică, dintre care un exemplar se păstrează la Camera Înregistrării de Stat în dosarul de arhivă al întreprinderii, iar celălalt se eliberează solicitantului.

Tot în blocul de înregistrare, mai sânt 2 opțiuni pentru gestionarea datelor ale întreprinderilor deja înregistrate:

Înregistrarea –> Înregistrarea Finală –> Corectarea

Servește pentru corectarea neoficială a datelor întreprinderii. Această opțiune este necesară în cazul în care s-au comis greșeli la înregistrarea oficială a întreprinderii(greșeala operatorului). Apelând această opțiune, programul va cere să indicăm denumirea întreprinderii solicitate sau numărul ei de înregistrare. Apoi se afișează lista cu întreprinderile care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară, va apare forma de introducere/modificare a datelor întreprinderii, unde vom face corectările necesare.

Înregistrarea –> Înregistrarea Finală –> Reinstalarea

Această opțiune se utilizează în cazul când o întreprindere a fost radiată, și apoi apelând la diferite instanțe de judecată a fost readusă la viață. Sau dacă a fost radiată din greșeala operatorului. Apelând această opțiune programul va cere să indicăm denumirea sau numărul de înregistrare a întreprinderii care dorim s-o reinstalăm.

Modificarea

În primul rând pentru începerea procedurii de înregistrare a modificărilor operate în documentele de constituire și în datele înscrise în Registrul de stat, operatorul trebuie să aibă la dispoziție actele necesare pentru înregistrarea modificărilor, cu informația necesară.

Pentru începerea procedurii de înregistrare a modificărilor unei întreprinderi, apelăm Modificarea –> Modificarea Inițială –> Introducerea modificărilor. După indicarea denumirii sau numărului de înregistrare a întreprinderii, se va afișa lista întreprinderilor care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară, se va afișa forma de introducere/modificare a datelor întreprinderii. În această formă operatorul modifică datele necesare și indică lista actelor prezentate pentru înregistrarea modificărilor.

La înregistrarea inițială a modificărilor, informația modificată se păstrează în blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale, pe lângă aceasta informația actuală se păstrează în blocul tabelelor cu informația actuală.

Ca exemplu de modificări pot servi: modificarea sediului întreprinderii, schimbarea managerului principal sau al unor date despre el(și-a schimbat domiciliul, s-a căsătorit), mărirea-micșorarea capitalului social în legătură cu intrarea-ieșirea fondatorilor din lista cu fondatori, schimbarea denumirii întreprinderii.

Dacă, până a înregistra oficial modificările operate în documentele de constituire și în datele înscrise în Registrul de stat, apar unele completări sau e nevoie de efectuat unele corectări în informația inițială de modificare, apelăm la Modificarea –> Modificarea Inițială –> Corectarea modificărilor. În urma acestor operații ne va apărea lista întreprinderilor care sânt în procesul inițial de înregistrare a modificărilor, adică se păstrează în blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale. Utilizând săgeți, alegem întreprinderea necesară și, în forma de introducere/modificare a datelor afișată, efectuăm corectările, completările necesare.

În cazul în care solicitantul se răzgândește sau din motive legislative înregistrarea oficială a modificărilor este imposibilă, se apelează Modificarea –> Modificarea Inițială –> Refuz la modificări, pentru a șterge informația introdusă, privind aceste modificări din blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale.

Din momentul în care toată informația este completă, operatorul, apelând Modificarea –> Modificarea Inițială –> Tipărirea cerere p/u modificarea și Modificarea –> Modificarea Inițială –> Tipărirea decizie p/u modificarea(proiect), imprimă respectiv, Cererea și Decizia(proiect) a modificărilor. Proiectul deciziei i se transmite registratorului de stat pentru examinare. Dacă registratorul are careva obiecții, atunci revenim la pasul Modificarea –> Modificarea Inițială –> Corectarea modificărilor, pentru a corecta necesarul.

În caz contrar, dacă registratorul nu are obiecții, se trece la pasul Modificarea –> Modificarea Inițială –> Înscrierea modificărilor. După apelarea acestui punct al meniului, se va afișa lista cu întreprinderile care sânt în procesul inițial de înregistrare a modificărilor. După ce alegem întreprinderea necesară, în forma de introducere/modificare a datelor va trebui să specificăm data petrecerii modificărilor oficiale. După apăsarea butonului "Modificarea finală" toate modificările se înregistrează în baza de date a sistemului.

În acest moment au loc 2 evenimente cu baza de date a sistemului:

transferarea informației privind întreprinderea specificată din blocul tabelelor ce păstrează informația actuală în blocul tabelelor ce păstrează istoria modificărilor;

transferarea informației privind întreprinderea specificată din blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării modificărilor oficiale în blocul tabelelor ce păstrează informația actuală.

Ultimul pas al operației de înregistrare a modificărilor oficiale este imprimarea "Deciziei privind înregistrarea modificărilor". Pentru aceasta apelăm Modificarea –> Modificarea finală –> Tipărirea decizie p/u modificare, și nouă ni se va cere să introducem denumirea întreprinderii sau numărul ei de înregistrare. Apoi se afișează lista cu întreprinderile care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară și tastând Enter, se va imprima "Decizia privind înregistrarea modificărilor" în două exemplare, care au aceeași valoare juridică, dintre care un exemplar se păstrează la Camera Înregistrării de Stat în dosarul de arhivă al întreprinderii, iar celălalt se eliberează solicitantului.

Radierea

În primul rând pentru începerea procedurii de radiere din Registrul de stat a întreprinderii, operatorul trebuie să aibă la dispoziție actele necesare pentru radierea întreprinderii, cu informația necesară.

Pentru începerea procedurii de radiere din Registrul de stat a întreprinderii, apelăm Radierea –> Radierea Inițială –> Introducerea. După indicarea denumirii sau numărului de înregistrare a întreprinderii, se va afișa lista întreprinderilor care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară, se va afișa forma de introducere/modificare a datelor întreprinderii. În această formă operatorul indică cauza radierii și lista actelor prezentate pentru radiere din Registrul de stat a întreprinderii.

La înregistrarea inițială a radierii, informația despre radiere se păstrează în blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării radierii, pe lângă aceasta informația actuală se păstrează în blocul tabelelor cu informația actuală.

Ca exemplu de cauze a radierii poate servi cazul când firma devine bancrot, este cumpărată de persoane particulare, a fost radiată în legătură cu reorganizarea, a fost radiată conform deciziei organului superior.

Dacă, până a înregistra oficial radierea din Registrul de stat a întreprinderii, apar unele completări sau e nevoie de efectuat unele corectări în informația inițială de radiere, apelăm la Radierea –> Radierea Inițială –> Corectare. În urma acestor operații ne va apărea lista întreprinderilor care sânt în procesul inițial de înregistrare a radierii, adică se păstrează în blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării radierii. Utilizând săgeți, alegem întreprinderea necesară și, în forma de introducere/modificare a datelor afișată, efectuăm corectările, completările necesare.

În cazul în care solicitantul se răzgândește sau din motive legislative înregistrarea oficială a radierii este imposibilă, se apelează Radierea –> Radierea Inițială –> Refuz la radiere, pentru a șterge informația introdusă, privind aceste modificări din blocul tabelelor ce păstrează informația temporară la etapa inițială a înregistrării radierii.

Din momentul în care toată informația este completă, operatorul, apelând Radierea –> Radierea Inițială –> Tipărirea cerere p/u radierea și Radierea –> Radierea Inițială –> Tipărirea decizie p/u radierea(proiect), imprimă respectiv, Cererea și Decizia(proiect) a radierii. Proiectul deciziei i se transmite registratorului de stat pentru examinare. Dacă registratorul are careva obiecții, atunci revenim la pasul Radierea –> Radierea Inițială –> Corectare, pentru a corecta necesarul.

În caz contrar, dacă registratorul nu are obiecții, se trece la pasul Radierea –> Radierea Inițială –> Înscrierea radierii. După apelarea acestui punct al meniului, se va afișa lista cu întreprinderile care sânt în procesul inițial de înregistrare a radierii. După ce alegem întreprinderea necesară, în forma de introducere/modificare a datelor va trebui să specificăm data radierii oficiale a întreprinderii. După apăsarea butonului "Radierea finală" datele despre radiere se înregistrează în baza de date a sistemului.

În acest moment în informația actuală a întreprinderii se specifică data radierii și cauza radierii întreprinderii, dar informația despre întreprindere nu se șterge din baza de date: Dacă operatorul în viitor va dori să efectueze careva operații asupra întreprinderilor radiate, sistemul va preîntâmpina operatorul că întreprinderea dată este deja radiată și îi va permite numai vizualizarea datelor acestei întreprinderi.

Ultimul pas al operației de înregistrare a radierii oficiale este imprimarea "Deciziei privind radierea întreprinderii din Registrul de stat". Pentru aceasta apelăm Radierea –> Radierea finală –> Tipărirea decizie p/u radierea, și nouă ni se va cere să introducem denumirea întreprinderii sau numărul ei de înregistrare. Apoi se afișează lista cu întreprinderile care satisfac condițiilor de căutare alese. Alegând întreprinderea necesară și tastând Enter, se va imprima "Decizia privind radierea întreprinderi din Registrul de stat" în două exemplare, care au aceeași valoare juridică, dintre care un exemplar se păstrează la Camera Înregistrării de Stat în dosarul de arhivă al întreprinderii, iar celălalt se eliberează solicitantului.

Imprimarea diferitor documente pentru înregistrarea de stat

Această opțiune ne permite să accesăm opțiunile de imprimare a documentelor de înregistrare de stat. Utilizând acest meniu operatorului i se dă posibilitatea de a imprima Cererile și Deciziile privind înregistrarea de stat a întreprinderilor.

Tot în acest meniu se află și opțiunea pentru imprimarea certificatului de înregistrare care se eliberează întreprinderilor înregistrate. Certificatul de înregistrare este un document care confirmă înregistrarea de stat a întreprinderii sau organizației și servește drept temei pentru luarea în evidență a lor de către inspectoratul fiscal teritorial. Modelul Certificatului de înregistrare a întreprinderii sau organizației se aprobă de către Guvern. Programul "Registratorul" umple golurile certificatului de înregistrare cu datele din baza de date "Registrul de stat"

Generarea rapoartelor

Această opțiune ne permite să accesăm un motor foarte puternic de creare a rapoartelor utilizând datele din baza de date a sistemului.

Generatorul de rapoarte este implementat ca un program de tip wizard – rapoartele se creează pas cu pas de către utilizator. Rezultatul lucrului programului va fi un raport, care va afișa informația din baza de date necesară utilizatorului și selectată strict după cerințele impuse de acesta. Raportul obținut poate fi tipărit sau salvat în fișier.

În cel mai simplu caz cu ajutorul acestui generator de rapoarte noi putem specifica textul unei interpelări SQL, indicând câmpurile care ne vor interesa. După aceasta pe forma de design a raportului plasăm componentele pentru afișarea în interiorul lor a datelor alese, și nu ne rămâne decât să accesăm forma de vizualizare a raportului pentru a vedea rezultatul lucrului.

Însă acest generator de rapoarte ne permite o gamă foarte largă de facilități pentru crearea rapoartelor.

Mai jos se vor descrie pașii care trebuie trecuți pentru selectarea informației pentru viitorul raport.

După deschiderea bazei de date, în lista tabelelor vor fi afișate toate tabelele din baza de date respectivă și va fi necesar să selectăm tabelele de care avem nevoie din această listă.

Apoi operatorul trebuie să facă selectarea câmpurilor a tabelelor alese din baza de date care vor fi prezente în raport, sau asupra cărora vor fi aplicate criterii de căutare. Pentru a crea raportul este obligator de a selecta cel puțin un câmp din baza de date.

Forma Calcs servește pentru crearea câmpurilor noi calculate. Aceste câmpuri calculabile ne permit să vizualizam anumite informații în forma diferită decât cea care este înscrisă în baza de date a sistemului.

Forma Group permite gruparea datelor după anumite condiții. În acest caz trebuie ca în lista tabelelor selectate să fie cel puțin două tabele, pentru ca să putem grupa câmpurile unei tabele cu cealaltă.

Următorul pas servește pentru crearea filtrelor, adică a condițiilor de selectare a înscrierilor din baza de date. Acest pas este foarte important, deoarece ne dă posibilitatea de a selecta din baza de date numai informația dorită. Cu toate acestea, utilizatorul poate continua lucrul cu generatorul de rapoarte fără a crea filtre. Pentru crearea unui filtru este necesar de a executa următorii pași:

Selectarea unui câmp din lista câmpurilor valabile;

Crearea condiției asupra câmpului ales de forma Câmp Operator logic – Valoarea;

După ce am terminat lucrul cu filtre putem trece la următorul pas.

Forma Sort servește pentru crearea ordinii de sortare după careva câmpuri a înregistrărilor alese din baza de date. Câmpurile după care se va face sortarea vor fi alese de utilizator prin adăugarea lor la lista de sortare. Ordinea de sortare va coincide cu ordinea câmpurilor din lista de sortare.

Ultima formă din program în care mai pot fi făcute modificări asupra SQL interpelării este forma SQL. Forma conține câmpul Query în care este afișat codul cererii scris în limbajul SQL. La executarea acestei cereri vor fi obținute înscrierile din baza de date, care vor corespunde cerințelor impuse de utilizator. Codul cererii afișat în câmpul Query poate fi modificat de către utilizator. Este necesar de menționat, că schimbările greșite din codului cererii vor duce la greșeli în timpul executării ei și ca urmare raportul nu va fi generat. Codul poate fi modificat corect numai de persoanele care cunosc limbajul SQL.

Până la acest moment noi numai am specificat criteriul de căutare a informației dorite.

Următoarea etapă este crearea propriu zisă a raportului pe baza informației găsite.

In fața operatorului va fi afișată masa de lucru cu trei benzi standarde: Titlul raportului, Conținutul raportului, Subsolul raportului. La fel pe masa de lucru sânt amplasate componente de vizualizare a imaginilor din baza de date și a informației textuale, componente de formatare a conținutului raportului, etc.

Dacă utilizatorul dorește, el poate să includă sau să excludă benzi în raport. Plasând pe suprafața raportului componentul necesar operatorul îi specifică din care câmp acest component să citească datele și să le afișeze. Exista posibilitatea formatării înfățișării raportului prin plasarea diferitor obiecte grafice.

În figura de mai jos este prezentat raportul, în care este afișată informația privind întreprinderile care sânt fondatori la firme deja radiate din Registrul de stat.

Exemplul raportului elaborat cu ajutorul generatorului de rapoarte

În acest raport este prezentată informația despre întreprinderea radiată(denumirea ei și data radierii) și informația despre fondatorul acestei întreprinderi. Un criteriu al acestui raport este că fondatorul trebuie să fie persoana juridică.

Clasificatoarele sistemului informațional

Acest punct al meniului permite lucrul cu tabelele clasificatoare ale sistemului. Apelând această opțiune se va afișa următoarea formă:

Forma de gestionare a informației clasificatoarelor

În această formă e posibilă manipularea cu conținutul clasificatoarelor, precum adăugarea unor câmpuri noi, modificarea conținutului unor câmpuri, imprimarea conținutului fiecărui clasificator, vizionarea lor. Însă e nevoie de remarcat faptul că, modificarea sau adăugarea conținutului clasificatoarelor au dreptul numai utilizatorii cu privilegii de Administrator, ceilalți au dreptul numai la vizualizarea și imprimarea informației. Pentru ceilalți utilizatori butoanele de adăugare și modificare a datelor vor fi inaccesibile.

Deservirea tehnică a sistemului și căutarea întreprinderilor

Utilizând acest meniu utilizatorul poate efectua căutarea întreprinderii utilizând o interfață prietenoasă. El va trebui să specifice condițiile de căutare într-un mod destul de clar chiar pentru un utilizator începător, să aleagă câmpurile care vor fi afișate, și să vizioneze rezultatul muncii sale. Condițiile de căutare pot fi specificate asupra tabelelor informaționale ale sistemului. Adică putem utiliza pentru căutarea întreprinderii informația referitoare la fondatori, managerul principal, conturile de decontare ale întreprinderii, precum și informația despre însăși întreprinderea.

La fel din acest meniu se poate lansa programul "RegistruSet" al sistemului, pentru a indica calea spre baza de date a sistemului. Aceasta opțiune, însă, este oferită numai utilizatorului cu privilegii de Administrator.

Descrierea programului "RegistruSet" al sistemului informațional

Programul "RegistruSet" este destinat gestiunii informației de ordin general privind baza de date a sistemului. În acest program se află opțiunea pentru a modifica calea spre baza de date a sistemului.

Acest program poate fi lansat în mod independent, dar poate fi lansat și din meniul programului "Registru". Dreptul de lansarea programului "RegistruSet" din meniul programului "Registru", îl au numai utilizatorii care au privilegii de Administrator.

Programul "RegistruSet" conține fereastra de dialog în care se modifică calea spre baza de date.

Forma pentru specificarea calei spre baza de date a programului "RegistruSet"

Informația introdusă se păstrează în registrul sistemului de operare Windows. Astfel dacă calea spre baza de date s-a modificat, atunci e nevoie ca Administratorul să corecteze informația dată.

Partea economică a proiectului.

Planificarea rețea pentru elaborarea SI “Registratorul”

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

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

accelerării vitezei de elaborare a proiectelor.

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

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

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

Metodele tradiționale de planificare presupun utilizarea celor mai simple modele de tipul construirea diagramelor de tip consecutive și ciclice.

Dar în asemenea diagrame nu este posibil de a prezenta legăturile dintre niște lucrări, de unde rezultă imposibilitatea de a afla cât de importantă este lucrarea dată pentru executarea scopului final. Pot apărea diferite întârzieri în timp, ce apar pe porțiuni de interconectare a lucrărilor, care sunt complicat de prezentat în diagrame. De obicei, în procesul dirijării se culege informația despre lucrările efectuate și aproape nu se culege și nu se prezintă informația referitor la prognoza finisării lucrărilor viitoare, de aceia este imposibil de a prognoza rezultatele diferitor variante de soluționare la modificările planului inițial de lucru. Este de asemenea complicat de a reflectași dinamica lucrărilor, de a corecta toată diagrama în legătură cu schimbarea termenilor de efectuare a unei lucrări, ce este necesar de a efectua ca să nu schimbăm termenul de efectuare a întregului complex de lucrări.

Aceasta este doar o parte mică din neajunsurile metodelor utilizate în prezent pentru planificare și prezentarea grafică a planurilor de pregătire a producerii. Aceste neajunsuri în mare pare sunt excluse de către sistemele de planificare și dirijare în rețea utilizate în prezent.

Sistemele de planificare și gestiune în rețea prezintă un complex de metode grafice și de calcul, metode de control și de organizare, care asigură modelarea, analiza și reconstruirea dinamică a planului de executare a proiectelor complexe.

Sistemele de planificare și gestiune în rețea este o metodă cibernetică creată pentru gestiunea cu sisteme dinamice complexe cu scopul asigurării condiției de optim pentru careva indicatori. Așa indicatori, în dependență de condițiile concrete, pot fi:

timpul minim pentru elaborarea întregului complex de lucrări;

costul minim al elaborării proiectului;

economia maximală a resurselor;

Particularitățile sistemului de planificare și gestiune în rețea în general sunt următoarele:

se realizează metoda proiectării de sistem la rezolvarea problemelor de organizare a gestiunii proceselor.

se utilizează modelul informațional-dinamic special (graful-rețea) pentru descrierea matematico-logică a procesului și calculul automat (conforma algoritmului) a parametrilor acestui proces (durata, costul, forțele de muncă, etc.)

se utilizează sisteme de calcul pentru prelucrarea datelor operative pentru calcului indicatorilor și primirea rapoartelor analitice și statistice necesare.

Documentul de bază în sistemul de planificare și gestiune în rețea este graful-rețea (modelul rețea), care prezintă modelul informațional-dinamic, în care sunt prezentate legăturile și rezultatele tuturor lucrărilor, necesare pentru atingerea scopului final.

Graful-rețea al proiectului

(continuare) Tab. 4

(continuare) Tab. 4

(continuare) Tab. 4

(continuare) Tab. 4

Graful-rețea pentru elaborarea SI “Registratorul"

Durata efectuării lucrărilor.

(continuare) Tab. 5

Calculele parametrilor grafului rețea.

(continuare) Tab. 6

(continuare) Tab. 6

Componența grupului de lucru

Evaluarea economică a sistemului informațional “Registratorul”.

Executarea lucrărilor de către lucrători.

(continuare) Tab. 8

(continuare) Tab. 8

Pentru salariu remunerat de bază sau cheltuit

Sb = 2580,00 + 2490,00 + 1770,00 + 1770,00 + 1740,00 = 10350,00 lei.

Salariu auxiliar (25%)

Sa = 10350,00 0,25 = 2587,50 lei.

Defalcări în Fondul Social (31%)

Cfs = (10350,00 + 2587,50) 0,31 = 4010,63 lei.

Cheltuielile totale pentru achitarea salariului

Ct = 12937,50 + 4010,63 = 16948,13 lei

Evenimentele care necesită timp de lucru cu calculatorul.

(continuare) Tab. 9

(continuare) Tab. 9

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

Suma cheltuielilor pentru ore-mașină va constitui

Smas = 332,00 * 15 = 4980,00 lei.

Cheltuielile pentru procurarea softului necesar.

De asemenea s-a procurat literatură tehnică în valoare de 340,50 lei și rechizite de birou în valoare de 85,5 lei.

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

Cheltuielile pentru amortizarea programelor Platinum ERwin v3.5.2.: Costul inițial 800USD, 2 licențe, amortizarea timp de 2 ani . Următorul Platinum ERwin produs va fi cumpărat cu 0.5 preț (la prezentarea licențelor actuale).

Durata lucrărilor asupra proiectului dat 3 luni

Sam_soft = (3*(800/2) * (2+3) )/(24) = 250USD = 3225,00 lei;

Cheltuielile prețului de cost și prețului de livrare a SI “Registratorul”.

Produsul final este procurat de către Camera Înregistrării de Stat. Camera Înregistrării de Stat capătă dreptul asupra acestui soft.

Evaluarea eficacității de la implementarea SI “Registratorul”

Evaluarea eficacității sociale de la implementarea SI “Registratorul”.

(continuare) Tab. 12

Camera Înregistrării de Stat, după procurarea produsului capătă profit de pe urma utilizării lui, cât în baza posibilităților de gestiune flexibile a produsului, cât și în prestarea contra plată a informației din baza de date a diferitor solicitanți.

Camera Înregistrării de Stat poate invita reprezentanții altor organizații de același profil din alte țări pentru a face schimb de experiență în domeniul înregistrării de stat și în domeniul utilizării calculatoarelor pentru aceasta.

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.

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ă. În 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 13:

Nivelurile admisibile a zgomotului.

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

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

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

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

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

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ăperi încă 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 magnetice ș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ăperi, totodată se efectuează măsurări la începutul, mijlocul și sfârșitul perioadelor calde și rece 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 14.

Normele microclimatului.

În acest tabel se aduc parametrii pentru categoriile de lucru 1a (mai puțin de 120 kkal/oră, lucrul șezând) și 1b (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ă.

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 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 fără participarea oxigenului.

Cauzele incendiilor și exploziilor pot fi electrice după caracter ș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.

În 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ăspundere î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 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 edificii 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 aruncate 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.

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

Radiație

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

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

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

Niveluri admisibile de tensiune.

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

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;

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

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

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.

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 disfuncț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ă. Tot odată 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 sprijin ș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.

Iluminatul

La lucrul cu CE o importanță mare are crearea mediului de iluminare optimal, adică organizarea rațională 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 locului de muncă trebuie să corespundă caracterului de lucru vizual, iluminarea încăperii să nu depindă de timpul de afară, fluxurile de lumină să aibă direcția optimală și utilajul trebuie să fie economic, inofensiv, durabil și simplu în exploatare.

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

iluminarea la locuri de muncă;

caracterul de strălucire a ecranului, mesei;

strălucirea petelor reflectate în ecran.

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

Punctele de control pentru măsurările iluminatului la locuri de muncă se amplasează:

în centrul ecranului;

pe tastatură;

pe document în planul amplasării lui;

pe masă în zona de lucru.

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

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 urmă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ă binefăcă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ă oscilaț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) fără 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 artificial 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

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

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

unde

A,B – dimensiunile încăperii

h – înălțimea suspensiei lămpilor de aspra suprafeței de lucru.

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

unde

H – înălțimea încăperii 4,00 m.

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

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

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.

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.

Concluzii

Implementarea sistemului informațional "Registratorul" în activitatea Camerei Înregistrării de Stat al Republicii Moldova, îi oferă celei din urmă posibilități extinse de gestiune a datelor privind întreprinderile înregistrate.

În primul rând trebuie de remarcat faptul că toată informația se păstrează pe un calculator special rezervat pentru păstrarea informației respective, numit Server. Operatorii lucrează în modalitatea client/server. Programul "Registru" joacă rolul programului client care se unește cu server pentru a accesa datele. În acest caz daca operatorul unui registrator are un flux mare de date pentru prelucrare și are limită de timp, atunci se poate de adăugat încă un calculator în sistem. Încă o soluție din situație este când un operator al altui registrator are un flux mic de cereri, atunci el își ajută colegul. În caz că la doi operatori numărul de cereri de înregistrare depuse este mic, va fi rațional ca acest volum să-l prelucreze un singur operator.

La fel, deoarece toată informația se păstrează pe Server, e foarte comod de dus evidența întreprinderilor înregistrate, radiate, etc. În orice moment de timp noi vom căpăta informația cea mai actuală la momentul corespunzător. Acesta este un plus foarte mare, deoarece informația trebuie să fie disponibilă în orice moment de timp, fie chiar și pentru organele de drept care examinează careva dosare penale, și cărora li este necesară informația actuală despre întreprinderile și organizațiile Republicii Moldova, datele despre activitatea lor, informația privind managerii principali sau fondatorii acestor întreprinderi.

Următoarea facilitate a sistemului este crearea rapoartelor. Pentru crearea rapoartelor utilizatorul fie în mod wizard, fie în modul design specifică ce fel de informație îl interesează, și indică criterii de căutare a ei. Acestea din urmă se unesc într-o SQL-interpelare către baza de date a sistemului. Utilizatorului nu îi rămâne decât să formeze forma de ieșire a raportului în care va putea plasa datele găsite.

Deoarece baza de date creată este implementată sub formă de SQL script, care corespunde ANSI standardelor, baza de date poate fi creată și exploatată sub un alt sistem de gestiune al bazelor de date moderne, la care Camera Înregistrării de Stat ar avea licență, fie și așa sisteme ca Oracle, Microsoft SQL Server, Informix, etc. Programele “Registru” și “RegistruSet” nu necesită modificări, trebuie doar create driver-e de legătură cu aceste SGBD utilizând fie ODBC sau BDE.

Bibliografia

Legea Republicii Moldova "Cu privire la înregistrarea de stat a întreprinderilor și organizațiilor" Nr.1265-XIV din 05.10.2000

InterBase 5 Server. Language Reference. Formă electronică

InterBase 5 Server. Data Definition Guide. Formă electronică

InterBase 5 Server. Operations Guide. Formă electronică

InterBase 5 Server. Programmer’s Guide. Formă electronică

InterBase 5 Server. API Reference Guide. Formă electronică

А.Я. Архангельский "Работа с локальными базами данных в DELPHI 5".

А.Я. Архангельский "100 компонентов общего назначения библиотеки DELPHI 5".

А.Я. Архангельский "Язык SQL в DELPHI 5".

Основы SQL. Formă electronică

В.В.Корнеев, А.Ф.Гарев, С.В.Васютин, В.В.Райх "Базы данных интелектуальная обработка информации".

V.Gofman "Lucrul cu baze de date în DELPHI ".

Н.Культин "Програмирование на Object Pascal в Delphi 5". Самоучитель.

Шумаков П.В. Фаронов В.В. "Руководство разработки баз данных в DELPHI 5 ".

Н. И. Баклашов "Охрана труда на предприятиях связи", Москва, Связь 1993

ANEXE

Secvențe ale programului "Registru" care controlează în care câmp a fost modificată informația întreprinderii.

function TfmInregIntr.DbCompare(DbName,FieldsDbName:string; nr: integer; var ListNotComplect: TStringList):string;

var nf,var_,md,rez,str1,TipObj,val_str,tname,fond_name :string;

Source: TComponent;

i: integer;

fl_intr,fl_cond,fl_cont,fl_fond: Boolean;

begin

fl_intr:=False;

fl_cond:=False;

fl_cont:=False;

fl_fond:=False;

rez:='';

DM.PrivateQ1.Close;

DM.PrivateQ1.SQL.Clear;

str1:='SELECT * FROM '+DbName+' WHERE ID_RECORD = :IdRec';

if DbName = 'FONDATOR' then str1:=str1+' AND NR_FOND = :nr';

if DbName = 'FILIALE' then str1:=str1+' AND NR_FILIAL = :nr';

DM.PrivateQ1.SQL.Add(str1);

DM.PrivateQ1.Params[0].Value:=IdRec;

if (DbName = 'FONDATOR') or (DbName = 'FILIALE') then

DM.PrivateQ1.Params[1].Value:=nr;

if not DM.PrivateQ1.Prepared then DM.PrivateQ1.Prepare;

DM.PrivateQ1.Open;

if DM.PrivateQ1.RecordCount > 0 then

begin

if DbName='FONDATOR' then

fond_name:=Trim(DM.PrivateQ1.FieldByName('NAME').Value)

else

fond_name:='';

DM.PrivateQ2.Close;

DM.PrivateQ2.SQL.Clear;

str1:='SELECT * FROM '+FieldsDbName;

DM.PrivateQ2.SQL.Add(str1);

if not DM.PrivateQ2.Prepared then DM.PrivateQ2.Prepare;

DM.PrivateQ2.Open;

if DM.PrivateQ2.RecordCount > 0 then

DM.PrivateQ2.First;

rez:='';

while not DM.PrivateQ2.Eof do

begin

if Trim(DM.PrivateQ2.FieldByName('KD_FIELD').Value) = '~' then

begin

DM.PrivateQ3.Close;

DM.PrivateQ3.SQL.Clear;

str1:='SELECT * FROM ADRES_ST WHERE ID_RECORD = :IdRec AND TIP_OBJ = :TipObj';

if (DbName = 'FONDATOR') or (DbName = 'FILIALE')

then str1:=str1+' AND NR_OBJ = :NrObj';

DM.PrivateQ3.SQL.Add(str1);

DM.PrivateQ3.Params[0].Value:=IdRec;

if DbName='CONDUCAT' then TipObj:='1';

if DbName='FONDATOR' then TipObj:='2';

if DbName='FILIALE' then TipObj:='3';

DM.PrivateQ3.Params[1].Value:=TipObj;

if (DbName = 'FONDATOR') or (DbName = 'FILIALE') then

DM.PrivateQ3.Params[2].Value:=nr;

if not DM.PrivateQ3.Prepared then DM.PrivateQ3.Prepare;

DM.PrivateQ3.Open;

if DM.PrivateQ3.RecordCount > 0 then

begin

nf:=Trim(DM.PrivateQ2.FieldByName('NAME_FIELD').Value);

var_:=Trim(DM.PrivateQ2.FieldByName('VAR_NAME').Value);

Source:=Self.FindComponent(var_);

if (Source is TEdit) and (TEdit(Source).Text <> DM.PrivateQ3.FieldByName(nf).Value) then

begin

if (DbName = 'S_NAM_PR') and (not fl_intr) then

begin

ListNotComplect.Add('Intreprinderea');

fl_intr:=True;

end;

if (DbName = 'CONDUCAT') and (not fl_cond) then

begin

ListNotComplect.Add('Conducatorul');

fl_cond:=True

end;

if (DbName = 'S_RS_PR') and (not fl_cont) then

begin

ListNotComplect.Add('Conturi');

fl_cont:=True;

end;

if (DbName = 'FONDATOR') and (not fl_fond) then

begin

ListNotComplect.Add('Fondator '+fond_name);

fl_fond:=True;

end;

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

ListNotComplect.Add(' Nou: '+TEdit(Source).Text);

ListNotComplect.Add(' Vechi: '+DM.PrivateQ3.FieldByName(nf).Value);

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

end;

DM.PrivateQ2.Next;

Continue;

end;

nf:=Trim(DM.PrivateQ2.FieldByName('NAME_FIELD').Value);

var_:=Trim(DM.PrivateQ2.FieldByName('VAR_NAME').Value);

Source:=Self.FindComponent(var_);

if (Source is TGroupBox) then

for i:=0 to TGroupBox(Source).ControlCount-1 do

if (TRadioButton(TGroupBox(Source).Controls[i]).Checked) and

(TRadioButton(TGroupBox(Source).Controls[i]).Hint <> DM.PrivateQ1.FieldByName(nf).Value) then

begin

if (DbName = 'S_NAM_PR') and (not fl_intr) then

begin

ListNotComplect.Add('Intreprinderea');

fl_intr:=True;

end;

if (DbName = 'CONDUCAT') and (not fl_cond) then

begin

ListNotComplect.Add('Conducatorul');

fl_cond:=True

end;

if (DbName = 'S_RS_PR') and (not fl_cont) then

begin

ListNotComplect.Add('Conturi');

fl_cont:=True;

end;

if (DbName = 'FONDATOR') and (not fl_fond) then

begin

ListNotComplect.Add('Fondator '+fond_name);

fl_fond:=True;

end;

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

ListNotComplect.Add(' Nou: '+TRadioButton(TGroupBox(Source).Controls[i]).Hint);

ListNotComplect.Add(' Vechi: '+DM.PrivateQ1.FieldByName(nf).Value);

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

if (Source is TPopup) and (TPopup(Source).Hint <> DM.PrivateQ1.FieldByName(nf).Value) then

begin

if (DbName = 'S_NAM_PR') and (not fl_intr) then

begin

ListNotComplect.Add('Intreprinderea');

fl_intr:=True;

end;

if (DbName = 'CONDUCAT') and (not fl_cond) then

begin

ListNotComplect.Add('Conducatorul');

fl_cond:=True

end;

if (DbName = 'S_RS_PR') and (not fl_cont) then

begin

ListNotComplect.Add('Conturi');

fl_cont:=True;

end;

if (DbName = 'FONDATOR') and (not fl_fond) then

begin

ListNotComplect.Add('Fondator '+fond_name);

fl_fond:=True;

end;

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

with TTable(TPopup(Source).DataSource.Owner.FindComponent(TPopup(Source).DataSource.DataSet.Name)) do

tname:=TableName;

val_str:=GetDbData(TPopup(Source).Hint,tname,

TPopup(Source).LabelField,TPopup(Source).DataField);

ListNotComplect.Add(' Nou: '+Trim(val_str));

val_str:=GetDbData(DM.PrivateQ1.FieldByName(nf).Value,

tname,TPopup(Source).LabelField,

TPopup(Source).DataField);

ListNotComplect.Add(' Vechi: '+Trim(val_str));

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

if (Source is TEdit) and (TEdit(Source).Text <> DM.PrivateQ1.FieldByName(nf).Value) then

begin

if (DbName = 'S_NAM_PR') and (not fl_intr) then

begin

ListNotComplect.Add('Intreprinderea');

fl_intr:=True;

end;

if (DbName = 'CONDUCAT') and (not fl_cond) then

begin

ListNotComplect.Add('Conducatorul');

fl_cond:=True

end;

if (DbName = 'S_RS_PR') and (not fl_cont) then

begin

ListNotComplect.Add('Conturi');

fl_cont:=True;

end;

if (DbName = 'FONDATOR') and (not fl_fond) then

begin

ListNotComplect.Add('Fondator '+fond_name);

fl_fond:=True;

end;

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

ListNotComplect.Add(' Nou: '+TEdit(Source).Text);

if DM.PrivateQ1.FieldByName(nf).IsNull then

ListNotComplect.Add(' Vechi: ')

else

ListNotComplect.Add(' Vechi: '+DM.PrivateQ1.FieldByName(nf).Value);

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

if (not(Source is TPopup) and (Source is TMaskEdit)) then

begin

if DM.PrivateQ1.FieldByName(nf).IsNull then md:=''

else

if (DM.PrivateQ1.FieldByName(nf).DataType = ftDate) or

(DM.PrivateQ1.FieldByName(nf).DataType = ftDateTime) then

md:=FormatDateTime('ddmmyyyy',DM.PrivateQ1.FieldByName(nf).Value)

else

md:=DM.PrivateQ1.FieldByName(nf).Value;

if Trim(TMaskEdit(Source).Text) <> md then

begin

if (DbName = 'S_NAM_PR') and (not fl_intr) then

begin

ListNotComplect.Add('Intreprinderea');

fl_intr:=True;

end;

if (DbName = 'CONDUCAT') and (not fl_cond) then

begin

ListNotComplect.Add('Conducatorul');

fl_cond:=True

end;

if (DbName = 'S_RS_PR') and (not fl_cont) then

begin

ListNotComplect.Add('Conturi');

fl_cont:=True;

end;

if (DbName = 'FONDATOR') and (not fl_fond) then

begin

ListNotComplect.Add('Fondator '+fond_name);

fl_fond:=True;

end;

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

ListNotComplect.Add(' Nou: '+TMaskEdit(Source).EditText);

ListNotComplect.Add(' Vechi: '+DM.PrivateQ1.FieldByName(nf).AsString);

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

end;

if (Source is TCheckBox) then begin

if (TCheckBox(Source).Checked and (Trim(DM.PrivateQ1.FieldByName(nf).AsString) = '0')) or

((not TCheckBox(Source).Checked) and (Trim(DM.PrivateQ1.FieldByName(nf).AsString) = '1')) then begin

ListNotComplect.Add(' '+DM.PrivateQ2.FieldByName('NAME').Value);

val_str:=GetDbData(TCheckBox(Source).Hint,'S_STATUT','KD_STATUT','NAME');

ListNotComplect.Add(' Nou: '+val_str);

val_str:=GetDbData(DM.PrivateQ1.FieldByName(nf).AsString,'S_STATUT','KD_STATUT','NAME');

ListNotComplect.Add(' Vechi: '+val_str);

rez:=rez+DM.PrivateQ2.FieldByName('KD_FIELD').Value;

end;

end;

DM.PrivateQ2.Next;

end;

end;

Result:=rez;

end;

Secvențe a programului "Registru" pentru afișarea informației întreprinderii

Pentru afișarea informației întreprinderii, informația mai întâi se culege din tabelele cu informația actuală, și se combină într-un singur raport. Culegerea informația se efectuează cu ajutorul procedurii GetDbInfo.

Pentru a afișa informația întreprinderii se apelează la Clasificatoare –> Întreprinderi ai meniului formei principale, și se indică denumirea sau numărul de înregistrare a întreprinderii căutate. După alegerea întreprinderii dorite din listă se tastează butonul "F3".

procedure TFFindPr.PrintDbInfo;

var i: integer;

FileStream: TFileStream;

rez: PChar;

s: string;

begin

DbInfoList:=TStringList.Create;

GetDbInfo(NumReg,'S_NAM_PR','PREDLFLD',2,DbInfoList);

DbInfolist.Add('');

GetDbInfo(NumReg,'CONDUCAT','CONDLFLD',2,DbInfoList);

DbInfolist.Add('');

GetDbInfo(NumReg,'S_RS_PR','RSLFLD',2,DbInfoList);

DbInfolist.Add('');

GetDbInfo(NumReg,'FONDATOR','FONDLFLD',2,DbInfoList);

DbInfolist.Add('');

GetDbInfo(NumReg,'FILIALE','FILLFLD',2,DbInfoList);

FileStream:=TFileStream.Create('InfoList.txt',fmCreate);

for i:=0 to DbInfolist.Count-1 do

begin

s:=WrapText(TrimRight(DbInfolist[i]), #13#10, ['.',',',';','!','?',' ',#9,'-',':'], 93);

rez:=PChar(s+chr(13)+chr(10));

FileStream.Write(rez[0],Length(rez));

end;

if DbInfoList.Count > 0 then DbInfoList.Clear;

DbInfoList.Free;

FileStream.Free;

DM.PrivateQ3.Close;

DM.PrivateQ3.SQL.Clear;

s:='SELECT NAME_L FROM S_NAM_PR WHERE NUMREG = :dForSearch';

DM.PrivateQ3.SQL.Add(s);

DM.PrivateQ3.Params[0].Value:=DM.tNamPr.FieldByName('NUMREG').Value;

if not DM.PrivateQ3.Prepared then DM.PrivateQ3.Prepare;

DM.PrivateQ3.Open;

Application.CreateForm(TfmPrintInfo, fmPrintInfo);

fmPrintInfo.ppLabel1.Caption:='Informatia despre intreprinderi.';

fmPrintInfo.ppLabel6.Caption:=Trim(DM.PrivateQ3.FieldByName('NAME_L').Value);

fmPrintInfo.ppLabel8.Caption:=DM.tNamPr.FieldByName('NUMREG').Value;

fmPrintInfo.ppReport1.Print;

fmPrintInfo.Release;

end;

Sursa procedurii GetDbInfo:

procedure GetDbInfo(NumReg,DbName,FieldsDbName: string; type_: integer; var DbInfoList: TStringList);

var i,nr,ff,ii: integer;

str1,TipObj,adrs_db,nf,val_,fm,d_modif: string;

begin

DM.PrivateQ1.Close;

DM.PrivateQ1.SQL.Clear;

if type_ = 2 then

str1:='SELECT * FROM '+DbName+' WHERE NUMREG = "'+NumReg+'"';

if type_ = 0 then

str1:='SELECT * FROM '+DbName+' WHERE ID_RECORD = "'+IdRec+'" AND TYPE_HIST = "0" ORDER BY DATMODIF DESCENDING';

if type_ = 1 then

str1:='SELECT * FROM '+DbName+' WHERE ID_RECORD = "'+IdRec+'" AND TYPE_HIST = "1" ORDER BY DATMODIF DESCENDING';

DM.PrivateQ1.SQL.Add(str1);

if not DM.PrivateQ1.Prepared then DM.PrivateQ1.Prepare;

DM.PrivateQ1.Open;

if DM.PrivateQ1.RecordCount > 0 then

DM.PrivateQ1.First;

ff:=1;

d_modif:='';

nr:=1;

while not DM.PrivateQ1.Eof do

begin

TipObj:='1';

if (DbName = 'PREDHIST') or (DbName = 'CONDHIST') or

(DbName = 'RS_HIST') or (DbName = 'FONDHIST') then

begin

if DM.PrivateQ1.FieldByName('DATMODIF').Value <> Null then

begin

if FormatDateTime('dd.mm.yyyy',DM.PrivateQ1.FieldByName('DATMODIF').Value) <> d_modif then

ff:=1;

d_modif:=FormatDateTime('dd.mm.yyyy',DM.PrivateQ1.FieldByName('DATMODIF').Value);

if (DbName <> 'FONDHIST') then

DbInfolist.Add(d_modif);

end;

end;

if (DbName = 'S_NAM_PR') then

DbInfolist.Add('Intreprinderea');

if (DbName = 'CONDUCAT') then

begin

DbInfolist.Add('Conducatorul');

nr:=1;

end;

if (DbName = 'S_RS_PR') then

DbInfolist.Add('Conturi');

if (DbName = 'FONDATOR') or (DbName = 'FONDHIST') then

begin

if DM.PrivateQ1.FieldByName('NR_FOND').Value <> nr then

ff:=1;

nr:=DM.PrivateQ1.FieldByName('NR_FOND').Value;

TipObj:='2';

DbInfolist.Add('');

if (DbName = 'FONDATOR') then

DbInfolist.Add('Fondator '+Trim(DM.PrivateQ1.FieldByName('NAME').Value)+' (nr.'+IntToStr(nr)+')')

else

begin

DbInfolist.Add('Modificare in datele despre fondator '+Trim(DM.PrivateQ1.FieldByName('NAME').Value));

DbInfolist.Add(d_modif);

end;

end;

if DbName = 'FILIALE' then

begin

nr:=DM.PrivateQ1.FieldByName('NR_FILIAL').Value;

TipObj:='3';

DbInfolist.Add('Filial '+Trim(DM.PrivateQ1.FieldByName('NAME').Value)+

' ('+DM.PrivateQ1.FieldByName('NUMREGFIL').Value+')');

end;

DM.PrivateQ2.Close;

DM.PrivateQ2.SQL.Clear;

str1:='SELECT * FROM '+FieldsDbName;

if (type_ = 0) or (type_ = 1) then

begin

str1:=str1+' WHERE KD_FIELD IN (';

fm:=Trim(DM.PrivateQ1.FieldByName('FIELDSMODIF').Value);

for i:=1 to Length(fm) do str1:=str1+'"'+fm[i]+'",';

str1:=str1+'"")';

end;

DM.PrivateQ2.SQL.Add(str1);

if not DM.PrivateQ2.Prepared then DM.PrivateQ2.Prepare;

DM.PrivateQ2.Open;

if DM.PrivateQ2.RecordCount > 0 then

DM.PrivateQ2.First;

while not DM.PrivateQ2.Eof do

begin

if Trim(DM.PrivateQ2.FieldByName('KD_FIELD').Value) = '~' then

begin

DM.PrivateQ3.Close;

DM.PrivateQ3.SQL.Clear;

if type_ = 0 then

begin

adrs_db:='ADRSHIST';

str1:='SELECT * FROM '+adrs_db+' WHERE ID_RECORD = "'+IdRec+'" AND TIP_OBJ = :TipObj'+

' AND NR_OBJ = :NrObj AND DATMODIF = "'+d_modif+'" AND TYPE_HIST = "0"';

end;

if type_ = 1 then

begin

adrs_db:='ADRSHIST';

str1:='SELECT * FROM '+adrs_db+' WHERE ID_RECORD = "'+IdRec+'" AND TIP_OBJ = :TipObj'+

' AND NR_OBJ = :NrObj AND DATMODIF = "'+d_modif+'" AND TYPE_HIST = "1"';

end;

if type_ = 2 then

begin

adrs_db:='ADRES_ST';

str1:='SELECT * FROM '+adrs_db+' WHERE NUMREG = "'+NumReg+'" AND TIP_OBJ = :TipObj'+

' AND NR_OBJ = :NrObj';

end;

DM.PrivateQ3.SQL.Add(str1);

DM.PrivateQ3.Params[0].Value:=TipObj;

DM.PrivateQ3.Params[1].Value:=nr;

if not DM.PrivateQ3.Prepared then DM.PrivateQ3.Prepare;

DM.PrivateQ3.Open;

ii:=0;

while not DM.PrivateQ3.Eof do

begin

ii:=ii+1;

if ii < ff then

begin

DM.PrivateQ3.Next;

Continue;

end;

nf:=Trim(DM.PrivateQ2.FieldByName('NAME_FIELD').Value);

val_:=DM.PrivateQ3.FieldByName(nf).Value;

DbInfolist.Add(' '+

Trim(DM.PrivateQ2.FieldByName('NAME').Value)+' '+

Trim(val_));

ff:=ff+1;

Break;

end;

DM.PrivateQ2.Next;

Continue;

end;

nf:=Trim(DM.PrivateQ2.FieldByName('NAME_FIELD').Value);

val_:=DM.PrivateQ1.FieldByName(nf).AsString;

if (DM.PrivateQ1.FieldByName(nf).DataType = ftDate) or

(DM.PrivateQ1.FieldByName(nf).DataType = ftDateTime) then

if not DM.PrivateQ1.FieldByName(nf).IsNull then

val_:=FormatDateTime('dd.mm.yyyy',DM.PrivateQ1.FieldByName(nf).Value);

if not Empty(DM.PrivateQ2.FieldByName('NAME_SPR').Value) then

val_:=GetDbData(DM.PrivateQ1.FieldByName(nf).Value,

Trim(DM.PrivateQ2.FieldByName('NAME_SPR').Value),

Trim(DM.PrivateQ2.FieldByName('NAME_KDF').Value),

Trim(DM.PrivateQ2.FieldByName('NAME_NF').Value));

if Trim(DM.PrivateQ2.FieldByName('KD_FIELD').Value) = '*' then

val_:='';

DbInfolist.Add(' '+

Trim(DM.PrivateQ2.FieldByName('NAME').Value)+' '+

Trim(val_));

if (DbName = 'FONDATOR') and

(Trim(DM.PrivateQ2.FieldByName('KD_FIELD').Value) = '*') then

DbInfolist.Delete(DbInfolist.Count-1);

if (DbName = 'FILIALE') and

(Trim(DM.PrivateQ2.FieldByName('KD_FIELD').Value) = '*') then

DbInfolist.Delete(DbInfolist.Count-1);

DM.PrivateQ2.Next;

end;

DM.PrivateQ1.Next;

end;

end;

Secvențe a programului "RegistruSet"ale păstrării calei bazei de date

procedure TfmSet.ShowSettingsAct;

var Reg : TRegistry;

ServerAddress : String;

begin

Reg := TRegistry.Create;

ServerAddress := '';

Valid := False;

try

Reg.RootKey := HKEY_LOCAL_MACHINE;

if Reg.OpenKey('\Software\Camera de Inregistrare\Registrator', True) then

ServerAddress := Reg.ReadString('ServerAddress');

finally

Reg.Free;

end;

Edit1.Text := ServerAddress;

ShowModal;

end;

procedure TfmSet.SpeedButton1Click(Sender: TObject);

begin

Close;

end;

procedure TfmSet.SpeedButton2Click(Sender: TObject);

var Reg : TRegistry;

begin

if Trim(Edit1.Text) = '' then begin

MessageDlg('Datele nu-s corecte!',mtError,[mbOK],0);

Exit;

end;

Reg := TRegistry.Create;

try

Reg.RootKey := HKEY_LOCAL_MACHINE;

if Reg.OpenKey('\Software\Camera de Inregistrare\Registrator', True) then begin

Reg.WriteString('ServerAddress', Trim(Edit1.Text));

Reg.CloseKey;

end;

Valid := True;

finally

Reg.Free;

end;

Close;

end;

Schema generală a structurii bazei de date "Registru de stat"

Schema generală a tabelelor informaționale

Structura detaliată a tabelelor ce conțin informația actuală

Bloc-schema a procesului înregistrării de stat

Forma de introducere/modificare a datelor întreprinderii

Această formă se utilizează la înregistrare, modificare sau radierea întreprinderii, și servește pentru introducerea informației despre întreprinderea.

Forma conține următoarele componente:

PageControl1 – componenta în care se conțin toate paginile cu date,

TabSheet1 – conține componentele subgrupei “Datele generale”,

TabSheet2 – conține componentele subgrupei “Denumirea”,

TabSheet3 – conține componentele subgrupei “Sediul”,

TabSheet4 – conține componentele subgrupei “Conducătorul”,

TabSheet5 – conține componentele subgrupei “Genuri de activități”,

TabSheet6 – conține componentele subgrupei “Capital social”,

TabSheet7 – conține componentele subgrupei “Rechizitele bancare”,

TabSheet8 – conține componentele subgrupei “Fondatori”,

TabSheet9 – conține componentele subgrupei “Filiale”,

TabSheet10 – conține componentele subgrupei “Lista documentelor p/u înregistrarea”,

TabSheet11 – conține componentele subgrupei “Permis p/u activitate”,

TabSheet12 – conține componentele subgrupei “Lista documentelor p/u modificarea”,

TabSheet13 – conține componentele subgrupei “Lista documentelor p/u radierea”,

TabSheet14 – conține componentele subgrupei “Informație despre reorganizare”.

Componentele subgrupei “Datele generale”

edNumReg – Numărul de înregistrare,

DataInreg – conține data de înregistrare,

gbIndice – conține obiecte “Indice”: “1 – Autofinanțare”;

“2 – Bugetar”;

“3 – Necomerciala”;

gbPersoana – conține obiecte “Persoana juridica”: “0 – Nu”,

“1 – Da”,

“2 – Filial”,

puProprRM – Forma de proprietate (RM),

puJurid – Forma juridica de organizare,

puProprS – Forma de proprietate (Străina),

puTipIntr – Tipul obiectului,

meCodObiect – Codul CUIIO,

mePerActiv – Perioada activității,

puSubord – Subordonarea obiectului,

edNumCerere – Numărul cererii,

meDateCerere – Data cererii,

edNumCert – Certificat: seria, număr,

meDateCert – data eliberării,

edCodFiscal – Codul fiscal,

puReg – Tipul înregistrării/modificării,

cbStatut – Statutul în redacția nouă.

Componentele subgrupei “Denumirea”

edScurta – Denumirea.Denumirea concreta,

edComplet1 – Denumirea.Denumirea completa,

puPrefix – Denumirea.Prefix,

puSufix – Denumirea.Sufix,

puCountry1 – Denumirea.Tara1,

puCountry2 – Denumirea.Tara2,

puCountry3 – Denumirea.Tara3,

puCountry4 – Denumirea.Tara4,

Componentele subgrupei “Sediul”

puJudetulF – Sediul.Judetul,

puLocalitF – Sediul.Localitatea,

puStradaF – Sediul.Strada,

edCasaF – Sediul.Casa,

edBlocF – Sediul.Bloc,

edApartamF – Sediul.Apartament,

puPostaF – Sediul.Posta,

edPhoneF – Sediul.Telefon,

edFaxF – Sediul.Fax,

Componentele subgrupei “Conducătorul”

edNumele – Conducatorul.Numele,

edPrenumele – Conducătorul. Prenumele,

edPatronim – Conducătorul. Patronimicul,

meDataNast – Conducătorul. Data nașterii,

puIdent – Conducătorul. Tipul actului de identitate,

edNrIdent – Conducătorul. Numărul actului de identitate,

puTaraC – Conducătorul. Tara cetățeniei,

puTaraCLoc – Conducătorul. Domiciliul: Tara,

puJudetulC – Conducătorul. Județul,

puLocalitC – Conducătorul. Localitatea,

puPostaC – Conducătorul. Posta,

puStradaC – Conducătorul. Strada,

edCasaC – Conducătorul. Casa,

edBlocC – Conducătorul. Bloc,

edApartamC – Conducătorul. Apartament,

edPhoneC – Conducătorul. Telefon,

edFaxC – Conducătorul. Fax,

edAdresaC – Conducătorul. Adresa (p/u conducătorii. străini).

Componentele subgrupei “Genuri de activități”

puActiv1 – Genuri de activitati.Genul1,

puActiv2 – Genuri de activitati.Genul2,

puActiv3 – Genuri de activitati.Genul3,

puActiv4 – Genuri de activitati.Genul4,

puActiv5 – Genuri de activitati.Genul5,

sbModifClasifActiv – butonul pentru efectuarea modificărilor în clasificatorul genurilor

de activitate S_ACTIV,

sbAlegereaActiv – butonul pentru alegerea genurilor de activitate direct din

clasificator;

Componentele subgrupei “Capital social”

meCapitalSoc – Capital social.Capital social (lei),

meCapitalSocIncl – Capital social. Inclusiv: proprietatea de stat/municipala (lei),

meAportRM – Capital social. Aporturi asociațiilor din RM la capitalul social (lei),

meAportRMn – Capital social. Inclusiv: aport in natura (lei),

meAportS – Capital social. Aporturi asociațiilor străini la capitalul social ($ US),

meAportSn – Capital social. Inclusiv: aport in natura ($ US).

Componentele subgrupei “Rechizitele bancare”

puBanc1 – Rechizitele bancare. Banca 1,

meNrContL – Rechizitele bancare. Nr. contului de decontare (in lei),

puBanc2 – Rechizitele bancare. Banca 2,

meNrContUS – Rechizitele bancare. Nr. contului de decontare (in $ US),

meSumPostL – Rechizitele bancare. Cota in (lei),

edSumPostProc – Rechizitele bancare. Cota in (%),

meDataPost – Rechizitele bancare. Ultima data de acumularea a capitalului social,

Componentele subgrupei “Permis p/u activitate”

puStruAuto – Structura care autorizat fondare,

meNumConst – Permis p/u activitate(Numărul),

meDateConst – Permis p/u activitate(Data),

puStruLicenta – Structura care a eliberat licența,

meNumLicenta – Licența(Numărul),

meDateLicenta – Licența(Data),

edSuperNr – Întreprinderi ierarhic superioare (p/u filiale, reprezentante).

Componentele subgrupei “Fondatori”

gbPersoanaFd – conține obiectele grupei “Persoana juridica”: “0 – Nu”,

“1 – Da”,

“2 – Colectiv”,

puIdentFd – Tipul actului de identitate,

edNumarFd – Nr. actului de identitate,

meDataFd – Data nașterii,

edDenumFd – Numele, prenumele patronimicul,

puTaraFd – Tara cetățeniei,

puTaraLocFd – Sediul: Tara,

puLocalitFd – Localitatea,

puJudetulFd – Județul,

puPostaFd – Posta,

puStradaFd – Strada,

edCasaFd – Casa,

edBlocFd – Bloc,

edApartFd – Apartament,

edPhoneFd – Telefon,

edFaxFd – Fax,

rgValuta – Valuta;

meSumaFd – Suma depunerii,

meCotaFd – Cota in %,

edAdresaFd – Adresa (p/u fondatori străini),

btSave – butonul pentru salvarea informației despre fondatorul curent,

btNew – butonul pentru introducerea informației a fondatorului nou,

btDelete – butonul pentru eliminarea fondatorului curent,

btForward – butonul trecerii la următorul fondator din lista,

btBackward – butonul trecerii la fondatorul precedent din listă.

Componentele subgrupei “Filiale”

DBGrid1 – tabela ce conține date despre filialele întreprinderii curente,

btInfoFl – butonul pentru vizionarea datelor a filialei alese,

btNewFl – butonul pentru introducerea informației a unei filiale noi,

btDeleteFl – butonul pentru eliminarea filialei curente.

Componentele subgrupei “Lista docum p/u înregistrarea”

lbDocListSel – conține lista documentelor prezentate pentru înregistrarea întreprinderii,

btNewDoc – butonul pentru introducerea unui document nou în listă,

btDeleteDoc – butonul pentru eliminarea documentului curent din listă,

btModifDoc – butonul pentru modificarea conținutului documentului curent,

sbModifClasifDocum – butonul pentru introducerea modificărilor în clasificatorul

documentelor S_DOCUM.

Componentele subgrupei “Lista docum p/u modificarea”

lbDocListSelMod – conține lista documentelor prezentate pentru înregistrarea

modificărilor în datele întreprinderii,

btNewDocMod – butonul pentru introducerea unui document nou în listă,

btDeleteDocMod – butonul pentru eliminarea documentului curent din listă,

btModifDocMod – butonul pentru modificarea conținutului documentului curent,

meDateMod – conține data înregistrării modificărilor întreprinderii

sbModifClasifDocum2 – butonul pentru introducerea modificărilor în clasificatorul

documentelor S_DOCUM.

Componentele subgrupei “Lista docum p/u radierea”

lbDocListSelLich – conține lista documentelor prezentate pentru radierea întreprinderii,

btNewDocLich – butonul pentru introducerea unui document nou în listă,

btDeleteDocLich – butonul pentru eliminarea documentului curent din listă,

btModifDocLich – butonul pentru modificarea conținutului documentului curent,

meDateRad – conține data radierii întreprinderii,

puCauzLich – conține cauza radierii întreprinderii.

Componentele ce aparțin formei

tbInreg – butonul pentru înregistrarea informației introduse/modificate, toate

datele se înscriu în tabelele corespunzătoare,

tbIesirea – butonul ieșirii din regim, și închiderea formei,

tbPrev – butonul trecerii rapide la subgrupa precedentă de date,

tbNext – butonul trecerii rapide la următoarea subgrupă de date,

pmMove – meniul care conține în calitate de Items denumirile subgrupelor de date,

pentru efectuarea trecerii rapidă la datele necesare,

bmToHistory – se utilizează pentru înregistrarea informației privind istoria modificărilor

a întreprinderii date, în tabela cu istoria modificărilor,

bmToReorg – se utilizează pentru înregistrarea informației privind reorganizarea

întreprinderii date în tabela cu reorganizarea,

dsFil – DataSource pentru legarea cu tabela FILIALE,

QFil – TQuery pentru lucru cu informația a filialelor întreprinderii date,

UpdateSQL1 – TUpdateSQL pentru lucru cu informația a filialelor întreprinderii date,

meDateModif – conține data înregistrării modificărilor.

Diagrama interacțiunii elementelor programului "Registru"

=== SCHEMA1 ===

Anexa 9 Diagrama interacțiunii elementelor programului "Registru"

Anexa 4 Schema generală a structurii bazei de date "Registru de stat"

Anexa 5 Schema generală a tabelelor informaționale

Anexa 8 Forma de introducere/modificare a datelor întreprinderii

Anexa 7 Bloc-schema a procesului înregistrării de stat

Anexa 6 Structura detaliată a tabelelor ce conțin informația actuală