Elaborarea Sistemului Informarional Activitatea Si Prognozarea Situatiei Financiare a Unei Firme Private
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.
Produsul Inprise Delphi, utilizat pentru implementarea sistemului informațional “Activitatea și prognozarea situației financiare a unei firme private” se referă la mediile de programare de tip RAD – Rapid Application Development (Construirea rapidă a aplicațiilor). Acest produs prezintă limbaj de programare de nivel înalt, orientat pe obiect, cu componente vizuale și biblioteci de clase gata pentru utilizare. Aceste biblioteci de componente sunt destinate pentru crearea cât mai rapidă a interfețelor pentru program, fie pentru crearea interfețelor de gestiune a programului de către utilizator sau a interfețelor de comunicare a programului cu alte programe. Pe lângă asigurarea creării rapide a interfețe aceste medii de programare acordă și o colecție de componente care sunt utilizate forte des de către programatori, de exemplu diferite metode de sortare deja implementate, arbori, liste, etc.
Sistemul informațional implementat se bazează pe baza de date și pe programele scrise care interacționează cu ea. Alegerea sistemului de gestiune al bazei de date este un lucru foarte important, deoarece trebuie de ținut cont de posibilitățile diferitor SGBD, de necesitățile lor pentru lucru (sistemul tehnic) și costul lor.
Revoluția informațională care a avut loc în ultimii ani în lume, în o foarte mare măsură este datorată apariției și dezvoltării bazelor de date relaționale. Standardizarea a permis ca datele de la un SGBD să fie transferate în alt SGBD fără măcar mici dificultăți. SGBD relaționale moderne permit manipularea foarte comodă cu datele, inclusiv toate sistemele bancare sunt realizate în asemenea SGBD.
Pentru implementarea bazei de date a sistemului informațional am ales SGBD Paradox care posedă caracteristicile unui SGBD de dimensiuni medii, care optimal corespunde cerințelor impuse de către sarcina de lucru, adică să poată prelucra și păstra informațiai.
Scopul proiectului dat este automatizarea procesului de creare a rapoartelor grafice și tabelare, pentru analiza activității întreprinderii și prognozarea situației financiare în scopul obținerii unui profit mai mare. Asigurarea accesului rapid la informația necesară și prezentarea ei într-o formă comodă pentru analiză. Aceste rapoarte sunt create reieșind din informația bazei de date “Raport FINACIAR”.
Până la crearea acestui proiect, era programul 1C, din care se luau datele necesare, care erau posibile de luat din acest program, apoi datele se prelucrau în mod manual pentru a obține rezultatele finale. După ce erau primite rezultatele finale se crea rapostele necesare. Pentru prezentarea rapoartelor se folosea programul Microsoft Excel. Însă acest proces dura foarte mult timp, fiindcă procesul dat nu era automatizat.
Din această cauză, s-a hotărât de a crea un program, care ar automatiza procesul de calcul și crearea a unor rapoarte standarde ce dețin de activitatea și prognozarea financiară.
În prezent produsele soft se implementează foarte rapid, din cauza dezvoltării enorme a tehnologiilor informaționale, acumulării cunoștințelor și bibliotecilor de date, creării rețelelor pentru comunicare și schimb de informații.
1 INIȚIERE ÎN LIMBAJUL DE PROGRAMARE DELPHI
1.1 INTRODUCERE
„Clasele și obiectele sunt noțiuni strâns legate una de alta. În particular fiecare obiect este un exemplu a unei careva clase, iar clasa poate crea orice număr de obiecte. În majoritatea cazurilor clasele sunt statice, adică toate particularitățile și conținutul lor sunt determinate în procesul de compilare. De aici rezultă că orice obiect creat se referă la o clasă strict determinată. Obiectele, invers, în procesul de execuție a programului se crează și se distrug foarte des” – noțiune dată de Gadi Buci.
Metodele claselor permit adresarea la informația internă despre clasă, fără crearea exemplarelor clasei – obiectelor.
Orice obiect are proprietăți și evenimente. Proprietățile sunt caracteristicile obiectului dat, iar evenimentele sunt acțiunile ce se efectuează în momente necesare. Făcând o analogie cu un obiect real, cum ar fi de exemplu un avion, o proprietate de-a lui este lungimea, iar un eveniment este luarea stratului după începerea lucrului motorului.
Proprietățile și evenimentele obiectelor se stabilesc in Object Inspector, în paginile respective. Trebuie de menționat că deoarece unele componente provin de la acelaș tip, ele au și unele proprietăți, evenimente asemănătoare.
1.1.1 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ânată 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 neinițializați, 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ștenească imediat orice modificare s-ar efectua în obiectele de bază. Delphi 2 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 aplicatia 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.
1.1.2 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 facilității de stocare în cache a modificărilor (detalii despre cache updates mai jos). Tabelele pot face uz de tehnica specială BDE de filtrare a datelor printr-o expresie de tip SQL care garantează obținerea unui set editabil de înregistrări (ceea ce nu întotdeauna este posibil printr-un query) cu minimum de consum de memorie.
Paleta de acces la baze de date s-a îmbogățit cu o formă specială de query – TUpdateSQL – care preia operațiunile de ștergere, inserare si actualizare de înregistrări spre deosebire de clasicul TQuery, care este rezervat acum doar pentru 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 aplicații desktop. Din fericire industria shareware a produs rapid câteva asemenea soluții, dintre care Borland a cumpărat-o pe cea mai reușită si a inclus-o în toate pachetele de Delphi. QuickReport reprezintă un set de 11 componente care se integreapreia proprietățile, evenimentele si metodele formei originale pe oricâte nivele de moștenire, fără a induce penalizări de performantă în aplicatia 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.
1.1.2 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 facilității de stocare în cache a modificărilor (detalii despre cache updates mai jos). Tabelele pot face uz de tehnica specială BDE de filtrare a datelor printr-o expresie de tip SQL care garantează obținerea unui set editabil de înregistrări (ceea ce nu întotdeauna este posibil printr-un query) cu minimum de consum de memorie.
Paleta de acces la baze de date s-a îmbogățit cu o formă specială de query – TUpdateSQL – care preia operațiunile de ștergere, inserare si actualizare de înregistrări spre deosebire de clasicul TQuery, care este rezervat acum doar pentru 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 aplicații desktop. Din fericire industria shareware a produs rapid câteva asemenea soluții, dintre care Borland a cumpărat-o pe cea mai reușită si a inclus-o în toate pachetele de Delphi. QuickReport reprezintă un set de 11 componente care se integrează perfect cu componentele de acces la bazele de date (TTable, TQuery), dar pot prelua datele si din vectori, liste sau orice fel de variabile. Rapoartele se redactează sub forma clasică de benzi care pot include titluri, câmpuri calculate, de însumare si de sistem, dar si imagini bitmap sau metafile ori forme geometrice simple. Sânt posibile rapoarte master-detail pe mai multe nivele sau cu mai multe seturi detail si grupate pe criterii foarte diverse, inclusiv câmpuri calculate. Benzile pot reprezenta seturi detail, antete sau subsoluri de pagină, grup sau raport si pot fi organizate pe mai multe coloane sau în format de etichete multiple, iar calculele pot fi inițializate la nivel de bandă. Datele se pot previzualiza în faza de design iar un component special permite previzualizarea lor în timpul rulării. Pentru baze de date mici (de ordinul zecilor de mii de înregistrări) Quick Report este cu un ordin de mărime mai rapid decât Report Smith. Ca urmare însă a includerii lor în fișierul executabil sub formă de resurse, rapoartele sînt complet inaccesibile utilizatorului final pentru modificări.
1.1.3 Mai multă putere în motorul de baze de date
Prezentarea lui Delphi 2 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 navigational complet prin relații master-detail si lookup.
Noua concepție 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 operatiuni 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ătură 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 aplicații 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.
1.2 SPECIFICUL 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.
1.2.1 Mecanismul de funcționare a cererilor în aplicațiile BD Delphi
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.
1.2.2 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 RFinanciar
conține un set de date identic cu cel al tabelului RFinanciar ș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 efectuiază prin intermediul componentei TDataSource.
Proprietățile și metodele componentei TQuery sînt prezentate în tabelul de mai jos.
Proprietățile și metodele componentei TQuery Tab. 1
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.
1.3 DELPHI ȘI PARADOX
Paradoxul asocierii unui compilator cu un sistem de gestiune a bazelor de date este numai aparent. Desi un mediu RAD nu este obligatoriu si un mediu de dezvoltare de aplicatii de baze de date, nealinierea la cererea principală a pietii poate scoate din competitie cel mai performant sistem. Borland dispunea nu numai de atuul unui compilator remarcabil ci si de o tehnologie avansată de baze de date, completată în ultima vreme cu dezvoltarea Interbase SQL si achizitionarea lui ReportSmith. Iar cum produsul în care a investit cel mai mult se numeste Paradox, cu ce altceva decât Paradox putea să semene cel mai mult suportul de baze de date al lui Delphi!?
Delphi, intrinsec, nu are încorporat nici un fel de suport de baze de date. Totusi, componentele specializate în acces la baze de date livrate în standard sunt atât de complete încât transformă efectiv dezvoltarea unei forme într-o familiară editare de machetă cu tabele si query-uri în cele mai variate relatii de one-to-many, many-to-many, one-to-many-to-many-to…etc., cu controale din cele mai diverse, de la câmpuri de editare cu validare la câmpuri calculate, de la tabele cu editare in-place la câmpuri lookup combo box sau list box. Nu lipseste nici clasicul navigator cu butoane de înainte-înapoi, stergere, inserare, actualizare, etc.
Dezvoltatorul detine un control total asupra interactiunilor dintre utilizator si baza de date prin intermediul unui set complet de evenimente generate de obiecte dataset (tabele si query-uri) si datasource (interfată între dataset si câmpurile de editare). Există astfel posibilitatea de a efectua validări înainte de actualizarea modificărilor în tabelă, de a primi controlul înaintea inserării sau stergerii unei noi înregistrări sau la prima tentativă de modificare a înregistrării curente. Iar lista de posibilităti rămâne deschisă.
Cel mai bine se vor simti programatorii de Paradox care vor regăsi aceeasi filozofie în manipularea tabelelor prin operatiuni familiare precum Insert, Edit, Cancel, Post (Do_It), Next, First, Last, etc. Câmpurile unei înregistrări sunt accesibile ca obiecte componente distincte prin intermediul editorului de câmpuri al tabelei, existând tipuri distincte pentru fiecare format, inclusiv imagine, memo sau cîmp binar (BLOB). Adesea, singura operatiune cu câmpuri efectuată prin program este atribuirea sau citirea valorii unui câmp. Accesul se face prin intermediul proprietătii Value si mentinerea sincronizării câmpului cu controlul de editare asociat sau cu tabela se face automat prin metodele mostenite.
În spatele scenei se găseste o implementare deosebit de puternică a accesului la baze de date. Obiectul tabelă tratează în mod unitar atât o tabelă Paradox sau dBase cât si una SQL. Nu este necesară nici un fel de modificare în cod sau în proprietătile tabelei pentru a muta o aplicatie de pe o bază de date locală pe o bază de date echivalentă de pe un server SQL! Nu există de asemenea nici o limitare în lucrul simultan cu tabele provenind din surse diferite. Pe aceeasi formă pot coexista tabele SQL si un spreadsheet Excel provenind dintr-o sursă ODBC. Remarcabilă este si aducerea la un numitor comun a diverselor specii de index, programatorul utilizând transparent un index secundar Paradox, un index DBase sau unul SQL.
Întrucât editoarele de componente nu dispun de facilităti de creare, editare sau interogare de baze de date în scopuri de testare a aplicatiilor, Delphi este însotit de Database Desktop – un Paradox miniatural capabil să creeze si restructureze tabele Paradox si DBase dar si SQL, fără capabilităti de forme si rapoarte – evident.
1.4 SQL – CUVÂNTUL LA MODĂ
Doar utilizarea tabelelor, chiar cu filtre si legate în relatii complexe, nu mai satisface adesea nici măcar în scopuri de editare. Iar a interoga navigând prin tabele si testând relatii a devenit nu numai desuet si neproductiv dar chiar generator de bug-uri.
Utilizarea obiectele tip TQuery deschide perspective remarcabile către cele mai diverse scheme de prelucrare sau editare a datelor. Query-urile sunt în esentă obiecte de executie a unei comenzi SQL asupra unor tabele putând proveni din surse eterogene, Paradox, DBase, ODBC sau servere SQL diferite. Fiind un descendent al tipului TDataset, query-ul are numeroase trăsături comune cu tabela, putând fi integrat în relatii, navigat, chiar editat în anumite conditii când se comportă ca un dynaset si actualizează tabelele de provenientă a datelor. Evident, comenzile SQL admit variabile care permit schimbarea dinamică a rezultatelor query-ului si chiar legarea query-ului de valori din înregistrarea curentă a altei tabele sau query.
Un obiect specializat în copierea si adăugarea de dataset-uri, TBatchMove, permite înlăntuirea query-urilor atunci când nu se poate ajunge la rezultatul dorit printr-o singură interogare SQL.
Dezvoltatorii nefamiliari cu SQL pot folosi Database Desktop pentru a construi vizual un query-by-example pe care îl pot traduce apoi în comandă SQL si integra în obiectul query, dacă nu sunt cumva fericitii posesori ai versiunii client-server care include un editor vizual de query-uri. Nu orice QBE se poate traduce în SQL si invers.
Utilizarea de query-uri reduce dramatic timpul de dezvoltare a unei baze de date si crează premize spre migrarea acesteia spre suport SQL. Folosirea lui pe baze de date locale simplifică dezvoltarea dar abuzul se plăteste scump. Astfel, crearea un obiect query necesită cam 100 KBytes de memorie, în timp ce un obiect tabelă se multumeste cu câtiva KBytes.
Cine este responsabil de interpretarea si executia query-ului, ca si de acces la baze de date în general? Borland si-a bazat toate produsele, de la Paradox la Delphi pe al său Borland Database Engine (o implementare a standardului IDAPI – alternativă viabilă la ODBC-ul lui Microsoft). Prin BDE este posibil accesul atât la surse native cum sunt Paradox si dBase precum si la conexiuni ODBC, pentru care interpretează si execută comenzile SQL, cât si la servere SQL, cărora le transmite cererile SQL si optimizează modul de acces la rezultate. Din punct de vedere al performantei pe baze de date locale, driver-ele native Paradox si DBase sunt net mai rapide decât cele similare disponibile prin ODBC, astfel încât acesta din urmă rămâne doar ca alternativă de conectare la formate mai ciudate de tabele.
Dornic să apelez direct functii BDE am descoperit – nedocumentată bineînteles – interfata de programare BDE (fisierele dbiprocs.int, dbierrs.int, dbitypes.int). Desi căutam numai o functie de actualizare a cache-ului pe disc am descoperit stupefiat functii de un nivel foarte înalt de operare cu query-uri, seturi de date, tranzactii, operatiuni de tip batch, stabilire de relatii, sortare, s.a.m.d. Se explică astfel capabilitătile remarcabile ale obiectelor tabelă si query din Delphi, care nu sunt decât simple împachetări obiectuale ale functionalitătii unui motor de baze de date foarte avansat. Aplicatiile Delphi au în spate performanta nativă a Paradox-ului si DBase-ului for Windows.
Desi oferta este covârsitoare, Borland plusează din nou integrând si Local Interbase Server – o versiune locală de server SQL, mono-utilizator si multi-instantă, în scopul declarat de testare locală de aplicatii Delphi pe baze de date SQL înaintea scalării acestora pe servere reale Interbase, Oracle, Sybase sau Informix.
M-am întrebat desigur cam ce monstruozitate va trebui distribuită clientului si pe cîte CD-uri? Ei bine, o aplicatie tipică de baze de date cuprinde un executabil selfconsistent de 500-700 KBytes si motorul de baze de date BDE, care ocupă 3 MBytes cu totul din care vreo 800 KBytes utili. În rulare, o aplicatie complexă MDI cu sase-opt forme de date deschise simultan nu consumă mai mult de un megabyte din memoria disponibilă, incluzând si cache-ul BDE, si galopează pe un 386SX cu 4 MBytes de RAM.
2 DESCRIEREA INSTRUCȚIUNILOR ANSI SQL
2.1 CREATE DOMAIN
Creează un tip de date pentru coloane global în toată baza de date.
Sintaxa:
CREATE DOMAIN domain [AS] <datatype>
[DEFAULT { literal | NULL | USER}]
[NOT NULL] [CHECK ( <dom_search_condition>)]
[COLLATE collation];
< datatype> = {
{SMALLINT | INTEGER | FLOAT | DOUBLE PRECISION} [ <array_dim>]
| {DECIMAL | NUMERIC} [( precision [, scale])] [ <array_dim>]
| DATE [ <array_dim>]
| {CHAR | CHARACTER | CHARACTER VARYING | VARCHAR}
[(1…32767)] [ <array_dim>] [CHARACTER SET charname]
| {NCHAR | NATIONAL CHARACTER | NATIONAL CHAR}
[VARYING] [(1…32767)] [ <array_dim>]
| BLOB [SUB_TYPE { int | subtype_name}] [SEGMENT SIZE int]
[CHARACTER SET charname]
| BLOB [( seglen [, subtype])]
}
<array_dim> = [[x:]y [, [x:]y …]]
<dom_search_condition> = {
VALUE <operator> <val>
| VALUE [NOT] BETWEEN <val> AND <val>
| VALUE [NOT] LIKE <val> [ESCAPE <val>]
| VALUE [NOT] IN ( <val> [ , <val> …])
| VALUE IS [NOT] NULL
| VALUE [NOT] CONTAINING <val>
| VALUE [NOT] STARTING [WITH] <val>
| ( <dom_search_condition>)
| NOT <dom_search_condition>
| <dom_search_condition> OR <dom_search_condition>
| <dom_search_condition> AND <dom_search_condition>
}
< operator> = {= | < | > | <= | >= | !< | !> | <> | !=}
Note referitor la sintaxa structurii CREATE DOMAIN:
Nu este posibil de a specifica clauza COLLATE pentru coloanele de tip Blob.
Pentru declararea masivelor trebuie utilizate parantezele pătrate. De exemplu următoarea segvență creează un masiv 5×5 de elemente tip string cu lungime maximă de 6 caractere:
my_array = varchar(6)[5,5]
Utilizați : pentru definirea masivelor numerotarea la care se începe diferit de 1. Următorul exemplu creează un masiv de numere întregi care se începe la 10 și se sfârșește la 20:
my_array = integer[20:30]
În structurile SQL transmise către DSQL omiteți simbolul ; după declararea tipului, în aplicații cu SQL inclus ca exemplu C, C++ și în isql se utilizează simbolul ; ca semn de sfârșit al instrucțiunii.
Descrierea operatorilor utilizați. Tab. 2
CREATE DOMAIN creează un tip de date pentru coloanele definite cu CREATE TABLE sau ALER TABLE. Definirea tipului de date (domeniului) conține un set de caractere, care includ:
Tipul de date;
Opțional: valoarea vidă;
Opțional: interzicerea valorilor vide;
Opțional: restricții la date;
Opțional: o clauză collation.
Notă: Aveți grijă la crearea domeniilor cu restricții contradictorii, așa ca declararea domeniului NOT NULL și atribuirea valorii implicite DEFAULT NULL.
Coloanele care sunt create în baza domeniilor moștenesc toate caracteristicile domeniului. Valoarea implicită a domeniului, clauza collation, și NOT NULL pot fi rescrise când definim o coloană în baza unui domeniu. O coloană bazată pe un domeniu poate adăuga restricții suplimentare la clauza CHECK.
Exemple:
Următorul isql exemplu creează un domeniu numeric care trebuie să posede o valoare pozitivă mai mare decât 1000 cu valoarea implicită de 9999. Cuvântul cheie VALUE substituie numele coloanei care se va baza pe acest domeniu.
CREATE DOMAIN CUSTNO
AS INTEGER
DEFAULT 9999
CHECK (VALUE > 1000);
În următorul isql exemplu valorile introduse în domeniu la 4 valori specifice:
CREATE DOMAIN PRODTYPE
AS VARCHAR(12)
CHECK (VALUE IN (’software’, ’hardware’, ’other’, ’N/A’));
În următorul isql exemplu, prima instrucțiune creează un domeniu utilizând USER pentru valoarea implicită. Următoarele instrucțiuni creează un tabel care include o coloană, ENTERED_BY, creată în baza domeniului USERNAME.
CREATE DOMAIN USERNAME AS VARCHAR(20)
DEFAULT USER;
CREATE TABLE ORDERS (ORDER_DATE DATE, ENTERED_BY USERNAME, ORDER_AMT
DECIMAL(8,2));
INSERT INTO ORDERS (ORDER_DATE, ORDER_AMT)
VALUES (’1-MAY-93’, 512.36);
Instrucțiunea INSERT nu include o valoare pentru coloana ENTERED_BY, de aceia InterBase automat va introduce denumirea utilizatorului a utilizatorului curent, JSMITH:
SELECT * FROM ORDERS;
1-MAY-93 JSMITH 512.36
2.2 CREATE TABLE
Se utilizează pentru a crea un tabel nou într-o bază de date existentă.
Sintaxa:
CREATE TABLE table [EXTERNAL [FILE] ’ <filespec>’]
( <col_def> [, <col_def> | <tconstraint> …]);
<col_def> = col {< datatype> | COMPUTED [BY] (< expr>) | domain}
[DEFAULT { literal | NULL | USER}]
[NOT NULL]
[ <col_constraint>]
[COLLATE collation]
< datatype> = {
{SMALLINT | INTEGER | FLOAT | DOUBLE PRECISION} [ <array_dim>]
| {DECIMAL | NUMERIC} [( precision [, scale])] [ <array_dim>]
| DATE [ <array_dim>]
| {CHAR | CHARACTER | CHARACTER VARYING | VARCHAR}
[( int)] [ <array_dim>] [CHARACTER SET charname]
| {NCHAR | NATIONAL CHARACTER | NATIONAL CHAR}
[VARYING] [( int)] [ <array_dim>]
| BLOB [SUB_TYPE { int | subtype_name}] [SEGMENT SIZE int]
[CHARACTER SET charname]
| BLOB [( seglen [, subtype])]
}
<array_dim> = [[x:]y [, [x:]y …]]
< expr> = O expresie SQL care întoarce o valoare.
<col_constraint> = [CONSTRAINT constraint] <constraint_def>
<constraint_def> = {UNIQUE | PRIMARY KEY
| CHECK ( <search_condition>)
| REFERENCES other_table [( other_col [, other_col …])]}
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
<tconstraint> = CONSTRAINT constraint <tconstraint_def>
<tconstraint_def> = {{PRIMARY KEY | UNIQUE} ( col [, col …])
| FOREIGN KEY ( col [, col …]) REFERENCES other_table
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
| CHECK ( <search_condition>)}
<search_condition> =
{ <val> <operator> { <val> | ( <select_one>)}
| <val> [NOT] BETWEEN <val> AND <val>
| <val> [NOT] LIKE <val> [ESCAPE <val>]
| <val> [NOT] IN ( <val> [ , <val> …] | <select_list>)
| <val> IS [NOT] NULL
| <val> {[NOT] {= | < | >} | >= | <=}
{ALL | SOME | ANY} ( <select_list>)
| EXISTS ( <select_expr>)| SINGULAR ( <select_expr>)
| <val> [NOT] CONTAINING <val>| <val> [NOT] STARTING [WITH] <val>
| ( <search_condition>)| NOT <search_condition>
| <search_condition> OR <search_condition>
| <search_condition> AND <search_condition>}
<val> = {
col [ <array_dim>] | : variable| <constant> | <expr> | <function>
| udf ([ <val> [, <val> …]])| NULL | USER | RDB$DB_KEY | ?
} [COLLATE collation]
<constant> = num | ' string' | charsetname ' string'
<function> = {
COUNT (* | [ALL] <val> | DISTINCT <val>)| SUM ([ALL] <val> | DISTINCT <val>)
| AVG ([ALL] <val> | DISTINCT <val>)| MAX ([ALL] <val> | DISTINCT <val>)
| MIN ([ALL] <val> | DISTINCT <val>)| CAST ( <val> AS <datatype>)
| UPPER ( <val>)| GEN_ID ( generator, <val>)
}
<operator> = {= | < | > | <= | >= | !< | !> | <> | !=}
<select_one> = SELECT numai la o coloană, întoarce exact o valoare.
<select_list> = SELECT numai la o coloană, întoarce zero sau mai multe valori.
<select_expr> = SELECT numai la o coloană, întoarce zero sau mai multe valori.
Descrierea operatorilor utilizați. Tab. 3.
CREATE TABLE implementează în o bază de date existentă un nou tabel, coloanele lui și restricțiile pentru integritate. Utilizatorul care creează tabelul este proprietarul tabelului și posedă toate privilegiile pentru el, incluzând posibilitatea de a extinde aceste privilegii și pentru alți utilizatori, trighere, proceduri ai BD utilizând clauza GRANT.
CREATE TABLE posedă următoarele opțiuni pentru definirea coloanelor:
Coloanele locale specifică numele și tipul de date pentru informația ce va fi introdusă în coloană.
Coloanele calculate (Computed by) sunt bazate pe o expresie. Valorile coloanei sunt calculate de fiecare dată când tabelul este accesat. Dacă tipul de date nu este specificat InterBase evaluează unul corespunzător. Coloanele la care există referințe în expresii trebuie să existe înainte ca coloanele să fie definite.
Coloanele în baza domeniilor moștenesc toate proprietățile domeniului, cu posibilitatea de a introduce unele modificări (vezi descriere pentru CREATE DOMAIN).
Tipurile de date CHAR, VARCHAR, sau Blob pentru coloanele textuale pot include clauza CHARACTER SET pentru specificarea unui set particular pentru o singură coloană. Dacă nu specificăm setul de caractere coloane va utiliza setul implicit de caractere. Dacă setul de caractere al bazei de date este schimbat, toate coloanele create apoi vor utiliza acest set ca setul implicit, însă coloanele deja create vor păstra setul de caractere la momentul creării.
NOT NULL este un atribut care previne introducerea valorilor vide sau necunoscute în coloană. NOT NULL afectează operațiunile INSERT și UPDATE.
Instrucțiunea DECLARE TABLE trebuie să preceadă CREATE TABLE în aplicațiile SQL incluse dacă același program creează tabelul și introduce date în el.
Opțiunea EXTERNAL FILE creează un tabel datele căruia se află într-un fișier extern, diferit de baza de date InterBase. Utilizați această opțiune pentru:
A defini un tabel InterBase compus din datele unei surse externe, așa ca datele în fișiere gestionate de către alte sisteme de operare ori de către aplicații non-SGBD.
Transferarea datelor într-un tabel existent al InterBase dintr-un fișier extern.
Restricțiile de integritate a datelor.
Se pot defini restricții de integritate la momentul creării tabelului. Aceste restricții sunt reguli pentru validarea datelor prin introducerea relațiilor coloană – tabel și tabel – tabel. Ele verifică toate tranzacțiile care accesează baza de date și sunt automat susținute de către sistem. CREATE TABLE permite crearea următoarelor restricții de integritate:
PRIMARY KEY (cheia principală) prezintă una sau mai multe coloane, conținutul cărora colectiv este garantat că va fi unic. Coloanele care aparțin la PRIMARY KEY trebuie să nu fie vide, adică să posede atributul NOTT NULL. Un tabel poate avea doar o cheie primară PRIMARY KEY.
Cheia UNIQUE (unică) asigură că într-o coloană sau un set de coloane nu vor exista 2 tuple cu valori egale. O coloană unică de asemenea trebuie să specifice atributul NOT NULL. Un tabel poate avea una sau mai multe chei unice. O cheie unică poate fi referită de către FOREIGN KEY în alt tabel.
Restricțiile de referință (REFERENCES) asigură că valorile în coloanele specificate (cunoscute ca FOREIGN KEY (cheie străină)) sunt aceleași valori în cheia pe care se fac referințe (fie PRIMARY sau UNIQUE) în alt tabel. Cheile PRIMARY sau UNIQUE trebuie să fie definite înainte ca să fie definită restricția REFERENCES la alt tabel. Opțiunile ON DELETE și ON UPDATE la REFERENSES descriu acțiunea asupra cheii străine când cheia primară este ștearsă sau modificată. Valorile posibile pentru ON DELETE și ON UPDATE sunt următoarele:
Descrierea operatorilor utilizați. Tab. 4.
Este posibil de a crea referințe FOREIGN KEY pentru tabele create de către alți utilizatori, dacă ei au creat acces de tip REFERENCES la tabelele corespunzătoare. Orice utilizator care modifică cheia străină trebuie să posede privilegiile REFERENCES sau SELECT asupra cheii primare a tabelului.
Condiția CHECK asigură o verificare pentru date la introducere și modificare la tabelul specificat. Search_condition poate necesita o combinație de valori ori poate compara valoarea introdusă cu datele din alte coloane.
Specificația USER ca valoare pentru Search_condition specifică numele login al utilizatorului care încearcă să scrie în tabelul dat.
Crearea cheilor PRIMARY KEY și FOREIGN KEY necesită acces exclusiv la baza de date.
Pentru restricții care nu posedă nume, sistemul generează un nume unic pe care îl păstrează în tabelul de sistem RDB$RELATION_CONSTRAINTS.
Exemple:
Următoarea isql structură creează un tabel simplu cu o cheie primară:
CREATE TABLE COUNTRY
(
COUNTRY COUNTRYNAME NOT NULL PRIMARY KEY,
CURRENCY VARCHAR(10) NOT NULL
);
Următorul set de instrucțiuni creează restricții UNIQUE la nivel de coloană și la nivel de tabel.
CREATE TABLE STOCK
(MODEL SMALLINT NOT NULL UNIQUE,
MODELNAME CHAR(10) NOT NULL,
ITEMID INTEGER NOT NULL,
CONSTRAINT MOD_UNIQUE UNIQUE (MODELNAME, ITEMID));
Următorul exemplu în isql reflectă instrucțiunile PRIMARY KEY, FOREIGN KEY de nivel de tabel și restricția CHECK. Restricția PRIMARY KEY se bazează pe trei coloane, de asemenea acest exemplu ilustrează crearea unui masiv de VARCHAR (string de lungime variabilă).
CREATE TABLE JOB
(
JOB_CODE JOBCODE NOT NULL,
JOB_GRADE JOBGRADE NOT NULL,
JOB_COUNTRY COUNTRYNAME NOT NULL,
JOB_TITLE VARCHAR(25) NOT NULL,
MIN_SALARY SALARY NOT NULL,
MAX_SALARY SALARY NOT NULL,
JOB_REQUIREMENT BLOB(400,1),
LANGUAGE_REQ VARCHAR(15) [5],
PRIMARY KEY (JOB_CODE, JOB_GRADE, JOB_COUNTRY),
FOREIGN KEY (JOB_COUNTRY) REFERENCES COUNTRY (COUNTRY),
CHECK (MIN_SALARY < MAX_SALARY)
);
În următorul exemplu coloana F2 este o cheie străină care posedă referință la cheia primară P1 a tabelului T1. Când se modifică un tuplu în T1 schimbările automat se propagă la toate tuplele afectate în T2. Dacă un tuplu în T1 este șters, toate tuplele afectate în F2 a tabelei T2 vor fi setate la NULL.
CREATE TABLE T1 (P1 INTEGER NOT NULL PRIMARY KEY);
CREATE TABLE T2 (F2 INTEGER FOREIGN KEY REFERENCES T1.P1
ON UPDATE CASCADE
ON DELETE SET NULL);
Următorul exemplu prezintă un tabel în care valoarea unei coloane este calculată:
CREATE TABLE SALARY_HISTORY
( EMP_NO EMPNO NOT NULL,
CHANGE_DATE DATE DEFAULT ’NOW’ NOT NULL,
UPDATER_ID VARCHAR(20) NOT NULL,
OLD_SALARY SALARY NOT NULL,
PERCENT_CHANGE DOUBLE PRECISION
DEFAULT 0
NOT NULL
CHECK (PERCENT_CHANGE BETWEEN -50 AND 50),
NEW_SALARY COMPUTED BY
(OLD_SALARY + OLD_SALARY * PERCENT_CHANGE / 100),
PRIMARY KEY (EMP_NO, CHANGE_DATE, UPDATER_ID),
FOREIGN KEY (EMP_NO) REFERENCES EMPLOYEE (EMP_NO)
);
În următorul isql exemplu prima coloană menține ordinea collate implicită pentru setul de caractere implicit al bazei de date. A doua coloană posedă a ordine diferită collate și a treia coloană include un alt set de caractere și o alt ordine collate:
CREATE TABLE BOOKADVANCE (BOOKNO CHAR(6),
TITLE CHAR(50) COLLATE ISO8859_1,
EUROPUB CHAR(50) CHARACTER SET ISO8859_1 COLLATE FR_FR);
2.3 CREATE TRIGGER
Această instrucțiunea creează un trigher, incluzând definirea mecanismului de activare, și a acțiunilor efectuate de către el. Disponibil în DSQL și isql.
Sintaxa:
CREATE TRIGGER name FOR table
[ACTIVE | INACTIVE]
{BEFORE | AFTER}
{DELETE | INSERT | UPDATE}
[POSITION number]
AS <trigger_body> terminator
<trigger_body> = [ <variable_declaration_list>] < block>
<variable_declaration_list> =
DECLARE VARIABLE variable <datatype>;
[DECLARE VARIABLE variable <datatype>; …]
< block> =
BEGIN
<compound_statement>
[ <compound_statement> …]
END
<compound_statement> = { <block> | statement;}
<datatype> = {
{SMALLINT | INTEGER | FLOAT | DOUBLE PRECISION}
| {DECIMAL | NUMERIC} [( precision [, scale])]
| DATE | {CHAR | CHARACTER | CHARACTER VARYING | VARCHAR}
[( int)] [CHARACTER SET charname]
| {NCHAR | NATIONAL CHARACTER | NATIONAL CHAR}
[VARYING] [( int)]}
Descrierea operatorilor utilizați. Tab. 5.
CREATE TRIGGER definește un trigher nou pentru baza de date. Trigher se numește un program asociat cu o tabelă sau view care se execută automat când un tuplu în tabel sau view este modificat, șters sau introdus.
Un trigher nu se apelează niciodată direct. Când a aplicație sau utilizatorul încearcă se efectueze una din operațiile INSERT, UPDATE, sau DELETE asupra unui tuplu din tabel, trigherele asociate cu acest tabel și cu această operație sunt executate imediat. Trigherele definite pentru UPDATE în view fără posibilități de modificare se execută chiar când nu se execută modificări.
Trigherele sunt compuse din cap (header) și corp (body).
Capul trigherului conține:
Numele trigherului, unic în baza de date, care distinge acest trigher de la alte trighere.
Numele tabelului, care identifică tabelul cu care va fi asociat acest trigher.
Instrucțiunile care determină când trigherul va fi activat.
Corpul trigherului conține:
O listă opțională de variabile locale și tipul lor de date.
Un bloc de instrucțiuni implementate in limbajul de proceduri și trighere al InterBase, cuprinse de către BEGIN și END. Aceste instrucțiuni vor fi executate la activarea trigherului. Un bloc de instrucțiuni poate la rândul lui include alte blocuri, asigurând în așa mod mai multe nivele logice pentru programare (nesting).
Deoarece fiecare instrucțiune din corpul trigherului trebuie să se sfârșească ci simbolul ; trebuie de a defini un alt simbol pentru a specifica sfârșitul corpului trigherului. În isql, includeți instrucțiunea SET TERM înainte CREATE TRIGGER pentru a specifica un terminator altul decât ;. După corpul trigherului, includeți alt SET TERM pentru a schimba terminatorul înapoi la simbolul ;.
Trigherul este asociat cu un tabel. Proprietarul tabelului și utilizatorii la care li sau acordat privilegii referitor la tabel automat primesc drepturile de a acționa trigherele asociate.
Trigherilor li se pot acorda privilegii asupra tabelelor la fel ca și la alte proceduri. Utilizați instrucțiunea GRAND, dar în loc de a utiliză TO username folosiți, TO TRIGGER trigger_name. Privilegiile trigherilor pot fi extrase similar utilizând instrucțiunea REVOKE.
Când utilizatorul efectuează acțiunea care lansează trigherul spre executare, trigherul va avea privilegiile în caz când măcar una din următoarele condiții este adevărată:
Trigherul are privilegiile pentru acționare;
Utilizatorul are privilegiile pentru a acționa.
Limbajul pentru proceduri și trighere al InterBase este un limbaj de programare complet pentru proceduri (stored procedures) și trighere (trigger). El include:
SQL instrucțiuni de manipulare cu datele (SQL DML) : INSERT, UPDATE, DELETE și instrucțiunea SELECT.
SQL operatorii și expresiile, incluzând UDF legate cu executarea aplicațiilor și generatorilor.
Extensii puternice pentru SQL, incluzând instrucțiuni de atribuire, de control a fluxelor, variabile de context, instrucțiuni de generare a evenimentelor, excepții și structuri de prelucrare a erorilor. Următorul tabel sumează extensiile limbajului pentru trighere.
Descrierea operatorilor utilizați. Tab. 6.
Următorul trigher, SAVE_SALARY_CHANGE, face modificări corespunzătoare la tabelul SALARY_HISTORY când este efectuată modificarea salariului lucrătorului în tabelul lucrătorilor EMPLOYEE:
SET TERM !! ;
CREATE TRIGGER SAVE_SALARY_CHANGE FOR EMPLOYEE
AFTER UPDATE AS
BEGIN
IF (OLD.SALARY <> NEW.SALARY) THEN
INSERT INTO SALARY_HISTORY
(EMP_NO, CHANGE_DATE, UPDATER_ID, OLD_SALARY, PERCENT_CHANGE)
VALUES (OLD.EMP_NO, ’now’, USER,OLD.SALARY,
(NEW.SALARY – OLD.SALARY) * 100 / OLD.SALARY);
END !!
SET TERM ; !!
Următorul trigher, SET_CUST_NO, utilizează un generator pentru a crea numere unice pentru clienți când un nou client este introdus în tabela pentru clienți CUSTOMER:
SET TERM !! ;
CREATE TRIGGER SET_CUST_NO FOR CUSTOMER
BEFORE INSERT AS
BEGIN
NEW.CUST_NO = GEN_ID(CUST_NO_GEN, 1);
END !!
SET TERM ; !!
Următorul trigher, POST_NEW_ORDER, generează un eveniment “new_order” de fiecare dată când un nou tuplu este introdus în tabelul SALES:
SET TERM !! ;
CREATE TRIGGER POST_NEW_ORDER FOR SALES
AFTER INSERT AS
BEGIN
POST_EVENT ’new_order’;
END !!
SET TERM ; !!
Următoarele patru fragmente demonstrează de cap de trighere demonstrează cum opțiunea POSITION determină ordinea de lansare a trigherilor.
CREATE TRIGGER A FOR accounts
BEFORE UPDATE
POSITION 5 … /* Corpul trigherului urmează */
CREATE TRIGGER B FOR accounts
BEFORE UPDATE
POSITION 0 … /* Corpul trigherului urmează */
CREATE TRIGGER C FOR accounts
AFTER UPDATE
POSITION 5 … /* Corpul trigherului urmează */
CREATE TRIGGER D FOR accounts
AFTER UPDATE
POSITION 3 … /*Corpul trigherului urmează*/
Când această modificare are loc:
UPDATE accounts SET account_status = 'on_hold'
WHERE account_balance <0;
Ordinea de lansare a trigherilor este:
Trigherul B este lansat.
Trigherul A este lansat.
Este efectuată operația de UPDATE.
Trigherul D este lansat.
Trigherul C este lansat.
2.4 GRANT
Specifică privilegiile pentru utilizatori pentru obiectele bazei de date. Disponibil în SQL, DSQL, și isql.
Sintaxa:
GRANT{
< privileges> ON [TABLE] { tablename | viewname}
TO { <object> | <userlist> | GROUP UNIX_group}
| EXECUTE ON PROCEDURE procname TO { <object> | <userlist>}
| < role_granted> TO {PUBLIC | < role_grantee_list>}};
< privileges> = {ALL [PRIVILEGES] | < privilege_list>}
< privilege_list> = {
SELECT| DELETE| INSERT| UPDATE [( col [, col …])]
| REFERENCES [( col [, col …])]
[, < privilege_list> …]}}
<object> = {
PROCEDURE procname| TRIGGER trigname| VIEW viewname| PUBLIC
[, <object> …]}
<userlist> = {
[USER] username| rolename| Unix_user}[, <userlist> …]
[WITH GRANT OPTION]
< role_granted> = rolename [, rolename …]
< role_grantee_list> = [USER] username [, [USER] username …]
[WITH ADMIN OPTION]
Descrierea operatorilor utilizați. Tab. 7.
GRANT oferă privilegii și roluri pentru obiectele bazei de date utilizatorilor, rolurilor și altor obiect a bazei de date. Când un obiect este creat, doar utilizatorul ce la creat posedă toate privilegiile asupra obiectului și doar creatorul poare oferi aceste privilegii altor utilizatori sau obiecte a bazei de date.
Pentru a accesa un tabel sau view, utilizatorul sau obiectul trebuie să posede privilegiile asupra instrucțiunilor apropriate SELECT, INSERT, UPDATE, DELETE sau REFERENCES pentru acest tabel sau view. Privilegiile SELECT, INSERT, UPDATE, DELETE sau REFERENCES pot fi atribuite împreună utilizând clauza ALL.
Pentru a lansa la executare o procedură într-o aplicație, utilizatorul sau obiectul trebuie să posede privilegiul EXECUTE.
Pentru a oferi privilegii unui grup de utilizatori, creați un rol utilizând instrucțiunea CREATE ROLE. Apoi utilizați instrucțiunea GRANT privilege TO rolename pentru a oferi privilegiile dorite acestui rol și utilizați GRANT rolename TO user pentru a înscrie un utilizator la acest rol. Utilizatorii pot fi adăugași sau extrași din rol (grup) unul după altul utilizând instrucțiunile GRANT și REVOKE. Utilizatorul trebuie să specifice rolul la momentul conectării pentru a primi privilegiile de la rol.
Pentru sisteme de operare UNIX, privilegiile pot fi oferite unei grupe de utilizatori definite în /etc/groups, la orice UNIX utilizator definit în /etc/passwd, atât la server cât și la client, așa ca și la utilizatori individuali și roluri.
Pentru a permite altui utilizator să efectueze referințe la o coloană printr-o cheie străină, acordați dreptul REFERENCES la cheia primară a tabelei, ori la coloanele cheii primare, proprietarului cheii străine. De asemenea e necesar de a acorda REFERENCES și SELECT privilegii asupra cheii primare pentru orice utilizator care dorește să înscrie în tabelul ce conține cheia străină.
Dacă acordați privilegiul REFERENCES, el trebuie să fie oferit minim pe toate coloanele cheii primare. Dacă REFERENCES este oferit pentru tabelul întreg, coloanele care nu fac parte din cheia primară nu sunt afectate deloc.
Când utilizatorul definește cheia străină pentru un tabel creat de alt utilizator, InterBase verifică dacă sunt oferite privilegiile REFERENCES la tabelul la care se vor efectua referințele.
Privilegiile sunt utilizate în momentul executării pentru verificarea dacă valoarea introdusă în cheia străină se conține în cheia primară a tabelului.
Este posibil de a oferi privilegii REFERENCES la roluri.
Pentru a permite utilizatorilor de a oferi privilegii la alți utilizatori, folosiți <userlist> care include clauza WITH GRANT OPTION. Utilizatorii pot transmite altor utilizatori numai privilegiile pe care ei le posedă.
Pentru a oferi privilegiile la toți utilizatorii specificați PUBLIC în locul listei cu denumirile utilizatorilor. Specificația PUBLIC oferă privilegiile numai la utilizatori, nu și la obiectele bazei de date.
Următorul tabel sumează privilegiile posibile:
Descrierea privilegiilor. Tab. 8.
Privilegiile pot fi extrase numai de către utilizatorul care le-a transmis, utilizând instrucțiunea REVOKE. Dacă privilegiul ALL a fost oferit, atunci privilegiul ALL trebuie extras. Dacă privilegiile sunt oferite la PUBLIC, atunci ele trebuie extrase de la PUBLIC.
Exemple:
Următorul exemplu în isql oferă privilegiile SELECT și DELETE unui utilizator. Clauza WITH GRANT OPTION transferă utilizatorului dreptul GRANT asupra acestor privilegii:
GRANT SELECT, DELETE ON COUNTRY TO CHLOE WITH GRANT OPTION;
Următorul exemplu de SQL inclus oferă privilegiile SELECT și UPDATE la o procedură pentru un tabel:
EXEC SQL
GRANT SELECT, UPDATE ON JOB TO PROCEDURE GET_EMP_PROJ;
Următorul SQL inclus oferă EXECUTE privilegii pentru o procedură, altei proceduri și altui utilizator:
EXEC SQL
GRANT EXECUTE ON PROCEDURE GET_EMP_PROJ
TO PROCEDURE ADD_EMP_PROJ, LUIS;
Următorul exemplu creează un rol denumit “administrator”, oferă privilegiile UPDATE pentru tabelul1 acestui rol, și apoi oferă rolul la user1, user2 și user3. Acestor utilizatori apoi li se oferă UPDATE și REFERNCES privilegii pentru tabelul 1.
CREATE ROLE administrator;
GRANT UPDATE ON table1 TO administrator;
GRANT administrator TO user1, user2, user3;
2.5 REVOKE
Retrage privilegiile de la utilizatori pentru obiectele bazei de date specificate. Disponibil în SQL, DSQL și isql.
Sintaxa:
REVOKE [GRANT OPTION FOR]
< privileges> ON [TABLE] { tablename | viewname}
FROM { <object> | <userlist> | < rolelist> | GROUP UNIX_group}
| EXECUTE ON PROCEDURE procname
FROM { <object> | <userlist>}
| < role_granted> FROM {PUBLIC | < role_grantee_list>}};
< privileges> = {ALL [PRIVILEGES] | < privilege_list>}
< privilege_list> = {
SELECT| DELETE| INSERT| UPDATE [( col [, col …])]
| REFERENCES [( col [, col …])]
[, < privilege_list> …]}}
<object> ={
PROCEDURE procname| TRIGGER trigname| VIEW viewname| PUBLIC
[, <object>]}
<userlist> = [USER] username [, [USER] username …]
< rolelist> = rolename [, rolename]
< role_granted> = rolename [, rolename …]
< role_grantee_list> = [USER] username [, [USER] username …]
Descrierea operatorilor utilizați. Tab. 9.
REVOKE retrage privilegiile de la utilizatori ori alte obiecte a bazei de date. Privilegii sunt operațiile pentru care utilizatorul posedă autoritate de efectuare.
GRANT OPTION FOR retrage drepturile utilizatorilor de a transmite privilegiile altor utilizatori.
Următoarele limitări trebuie să fie evidențiate pentru REVOKE.
Numai utilizatorul care oferă privilegiile le poate retrage.
Unui singur utilizator i se pot atribui aceleași privilegii pentru un obiect al bazei de date de către mai mulți utilizatori. Instrucțiunea REVOKE efectuată de către unul din acești utilizatori va retrage numai privilegiile oferite anterior de către acest utilizator particular.
Când un rol este retras de la un utilizator, toate privilegiile care au fost oferite de către acest utilizator altor utilizatori din cauza autorității oferite de rol, de asemenea vor fi extrase.
Exemple:
Următorul isql select retrage privilegiul SELECT de la un utilizator:
REVOKE SELECT ON COUNTRY FROM MIREILLE;
Următoarea instrucțiune în isql retrage privilegiul EXECUTE pentru o procedură de la altă procedură:
REVOKE EXECUTE ON PROCEDURE GET_EMP_PROJ
FROM PROCEDURE ADD_EMP_PROJ, LUIS;
2.6 CREATE GENERATOR
Declară un generator pentru baza de date. Disponibil în SQL, DSQL și isql.
Sintaxa
CREATE GENERATOR name;
unde name – numele generatorului.
CREATE GENERATOR declară un generator în baza de date setează valoarea inițială la zero. Generator numim un număr în serie (segvență) care poate fi automat introdus în o coloană utilizând funcția GEN_ID(). Generatoarele des sunt utilizate pentru asigurarea unei valori unice în cheile primare.
O bază de date poate conține orice număr de generatoare. Generatoarele sunt globale pentru baza de date și pot fi utilizate și modificate în orice tranzacție. InterBase nu atribuie valori duble pentru tranzactele paralele.
Utilizați SET GENERATOR pentru a seta sau modifica valorile generatorului existent. Generatorul poate fi utilizat în interiorul unei proceduri, trigher, ori instrucțiunii SQL care apelează GEN_ID().
Nu există instrucțiune “drop generator”. Pentru a șterge un generator, el trebuie șters din tabelul de sistem în următorul mod:
DELETE FROM RDB$GENERATORS WHERE RDB$GENERATOR_NAME = EMPNO_GEN’;
Exemple: Următorul exemplu în isql() creează un generator EMPNO_GEN, și trigherul CREATE_EMPNO. Trigherul utilizează generatorul pentru a produce chei numerice, incrementate cu 1, pentru coloane NEW.EMPNO:
CREATE GENERATOR EMPNO_GEN;
COMMIT;
SET TERM !! ;
CREATE TRIGGER CREATE_EMPNO FOR EMPLOYEES
BEFORE INSERT
POSITION 0
AS BEGIN
NEW.EMPNO = GEN_ID(EMPNO_GEN, 1);
END
SET TERM ; !!
2.7 CREATE INDEX
Creează un index în una sau mai multe coloane a bazei de date. Disponibil în SQL, DSQL și isql.
Sintaxa:
CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]]
INDEX index ON table ( col [, col …]);
Descrierea operatorilor utilizați. Tab. 10.
Se implementează un index în una sau mai multe coloane a tabelului. Utilizați CREATE INDEX pentru a mări viteza de acces la date. Utilizând un index pentru coloane care apar în WHERE clauze poate îmbunătăți performanțele căutării.
Nu este posibil crearea indexurilor pentru coloanele de tip Blob sau masive.
Un index UNIQUE nu poate fi creat în o coloană, sau un set de coloane dacă ele deja conțin valori duble, ori valori vide (NULL).
ASC și DESC specifică ordinea în care sunt sortate indexurile. Pentru răspunsuri mai rapide în cereri care necesită valori sortate, creați ordinea în indexuri ca ele să coincidă cu cererea ORDER BY. Pot fi create două indexuri cu ASC și DESC pe aceleași coloane pentru a accesa datele în diferite cereri cu diferite sortări.
Pentru a îmbunătăți performanțele indexurilor, utilizați SET STATISTICS pentru a recalcula selectivitatea indexurilor, ori reconstruiți indexul prin deactivarea lui și apoi activarea lui, utilizând instrucțiunea ALTER INDEX [1].
Exemple
Următoarea isql instrucțiune creează un index unic:
CREATE UNIQUE INDEX PRODTYPEX ON PROJECT (PRODUCT, PROJ_NAME);
Următoarea isql instrucțiune creează un index descrescător:
CREATE DESCENDING INDEX CHANGEX ON SALARY_HISTORY (CHANGE_DATE);
Următoarea isql instrucțiune creează un index bazat pe două coloane:
CREATE INDEX NAMEX ON EMPLOYEE (LAST_NAME, FIRST_NAME);
2.8 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.
Clauza TRANSACTION poate fi utilizată în SQL aplicații cu tranzacte multiple pentru specificarea care tranzact dirijează operația de INSERT. Clauza TRANSACTION nu este disponibilă în DSQL sau isql.
Sintaxa:
INSERT [TRANSACTION transaction] INTO <object> [( col [, col …])
{VALUES ( <val> [, <val> …]) | <select_expr>};
unde:
<object> = tablename | viewname
<val> = {
: variable | <constant> | <expr>
| <function> | udf ([ <val> [, <val> …]])| NULL | USER | RDB$DB_KEY | ?
} [COLLATE collation]
<constant> = num | ' string' | charsetname ' string'
<expr> = O SQL expresie care întoarce o valoare validă pentru insertare.
<function> = {
CAST ( <val> AS <datatype>)| UPPER ( <val>)| GEN_ID ( generator, <val>)
}
<select_expr> = O structură SELECT care întoarce 0 sau mai multe tuple și unde numărul de coloane în fiecare tuplu este egal cu numărul de obiecte care trebuie să fie introduse.
Exemple.
Următoarea segvență de SQL inclus într-o aplicație adaugă un tuplu la un tabel, atribuind valori de la variabile la două coloane:
EXEC SQL
INSERT INTO EMPLOYEE_PROJECT (EMP_NO, PROJ_ID) VALUES (:emp_no ,
:proj_id );
următoarea structură în isql specifică valorile de insertare într-un tabel prin clauza select:
INSERT INTO PROJECTS
SELECT * FROM NEW_PROJECTS
WHERE NEW_PROJECTS.START_DATE > ’6-JUN-1994’;
2.9 UPDATE
Modifică parțial sau în întregime tuplul existent de date dintr-un tabel sau view. Disponibil în SQL, DSQL și isql.
Sintaxa:
în SQL:
UPDATE [TRANSACTION transaction] { table | view}
SET col = < val> [, col = <val> …]
[WHERE <search_condition> | WHERE CURRENT OF cursor];
în DSQL și isql:
UPDATE { table | view}
SET col = < val> [, col = <val> …]
[WHERE <search_condition>
<val> = {
col [ <array_dim>] | : variable| <constant> | <expr> | <function>
| udf ([ <val> [, <val> …]])| NULL | USER | ?}
[COLLATE collation]
<array_dim> = [[x:]y [, [x:]y …]]
<constant> = num | ' string' | charsetname ' string'
<expr> = O expresie SQL corectă care întoarce o valoare.
<function> = {
CAST ( <val> AS <datatype>)| UPPER ( <val>)| GEN_ID ( generator, <val>)}
<search_condition> = Vezi CREATE TABLE pentru o descriere detailată.
Descrierea operatorilor utilizați. Tab. 11.
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.
Clauza WHERE este utilizată pentru a restrânge tuplele din tabelă la un subset care va fi modificat. Fără clauza WHERE vor fi modificate toate tuplele din tabel.
Exemple:
Următoarea isql structură modifică toate tuplele din tabel:
UPDATE CITIES
SET POPULATION = POPULATION * 1.03;
Următorul exemplu de SQL inclus folosește o clauză WHERE pentru a reduce modificare tuplelor la un subset:
EXEC SQL
UPDATE PROJECT
SET PROJ_DESC = :blob_id
WHERE PROJ_ID = :proj_id;
2.10 DELETE
Modifică parțial sau în întregime tuplul existent de date dintr-un tabel sau view. Disponibil în SQL, DSQL și isql.
Sintaxa în DSQL și SQL:
DELETE [TRANSACTION transaction] FROM table
{[WHERE <search_condition>] | WHERE CURRENT OF cursor};
pentru isql utilizăm:
DELETE FROM TABLE [WHERE <search_condition>];
Descrierea operatorilor utilizați. Tab. 12.
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.
Clauza TRANSACTION specifică tranzacția care dirijează cu operația DELETE și este utilizată pentru aplicațiile cu mai multe SLQ tranzacții. Clauza TRANSACTION nu este disponibilă în DSQL și isql.
Clauza WHERE este utilizată pentru a restrânge tuplele din tabelă la un subset care va fi șters. Fără această clauză vor fi șterse toate tuplele din tabel.
Exemple:
Următoarea isql structură șterge toate tuplele din tabel:
DELETE FROM EMPLOYEE_PROJECT;
Următorul exemplu de SQL inclus folosește un cursor și clauza WHERE CURRENT OF pentru a șterge tuple din tabelul CITIES cu o populație mai mică de variabila gazdă min_pop. Este declarat și deschis un cursor care găsește orașele ce corespund condiției, atribuie tuplele la cursor și apoi șterg tuplul curent indicat de către cursor.
EXEC SQL
DECLARE SMALL_CITIES CURSOR FOR
SELECT CITY, STATE
FROM CITIES
WHERE POPULATION < :min_pop;
EXEC SQL
OPEN SMALL_CITIES;
EXEC SQL
FETCH SMALL_CITIES INTO :cityname, :statecode;
WHILE (!SQLCODE)
{
EXEC SQL
DELETE FROM CITIES
WHERE CURRENT OF SMALL_CITIES;
EXEC SQL
FETCH SMALL_CITIES INTO :cityname, :statecode;
}
EXEC SQL
CLOSE SMALL_CITIES;
2.11 COMMIT
Face ca modificările efectuare de către tranzacții în baza de date să fie permanente, și încheie tranzacția. Disponibil în SQL, DSQL și isql.
Sintaxa:
COMMIT [WORK] [TRANSACTION name] [RELEASE] [RETAIN [SNAPSHOT]];
Descrierea operatorilor utilizați. Tab. 13.
COMMIT este utilizat pentru a încheia tranzacția și:
A înscrie toate modificările în baza de date;
A efectua modificările tranzacției vizibile la următoarele SNAPSHOT tranzacții ori pentru a citi tranzacțiile înscrise (READ COMMITED).
A închide cursoarele deschise, nu în cazul dacă folosim argumentul RETAIN.
Un tranzact care s-a încheiat cu COMMIT se consideră încheiat cu succes. Întotdeauna trebuie de utilizat COMMIT sau ROLLBACK pentru a încheia tranzactele implicite.
După utilizarea tranzactelor numai pentru citire utilizați COMMIT în loc de ROLLBACK. Efectul este același, dar performanțele tranzacțiilor ce urmează sunt mai ridicate și resursele de sistem utilizate de ele sunt reduse.
Argumentul RELEASE este prezent numai pentru compatibilitate cu versiunile precedent ala InterBase. Pentru a efectua deconectarea de la baza de date utilizați DISCONNECT.
Exemple:
Următorul exemplu în isql face permanente toate modificările la baza de date efectuate de către tranzacția implicită.
COMMIT;
Următoarele SQL instrucțiuni incluse confirmă modificările unui tranzact numit:
EXEC SQL
COMMIT TR1;
Următorul exemplu de SQL instrucțiuni incluse utilizează COMMIT RETAIN pentru a păstra modificările, însă menținând contextul tranzactului curent.
EXEC SQL
COMMIT RETAIN;
2.12 ROLLBACK
Restabilește baza de date la starea precedentă începutului tranzacției. Disponibil în SQL, DSQL, și isql.
Sintaxa:
ROLLBACK [TRANSACTION name] [WORK] [RELEASE];
Descrierea operatorilor utilizați. Tab. 14.
ROLLBACK “întoarce” modificările efectuate în baza de date de către tranzactul curent, apoi încheie tranzactul. Rupe legătura programului cu baza de date și eliberează resursele de sistem. Utilizați RELEASE în ultimul ROLLBACK pentru a închide toate bazele de date deschise. Așteptați până când programul nu mai are nevoie de baza de date pentru a elibera resursele de sistem.
Clauza TRANSACTION este utilizată pentru a specifica tranzactul “întors” într-o aplicație cu mai multe tranzacte deschise. Dacă este omis, tranzactul implicit este “întors”. Clauza TRANSACTION nu este disponibilă în DSQL.
Exemplu:
Următorul isql exemplu “întoarce” tranzactul implicit:
ROLLBACK;
2.13 SELECT
Pentru vizionarea informației din baze de date relaționale care susțin limbajul SQL trebuie de utilizat instrucțiunea SELECT. SELECT are o sintaxă foarte complicată, ceea ce ne dă, în schimb, posibilități enorme de obținere a datelor din tabele. 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ă.
Ca exemplu, să culegem următoarea instrucțiune SQL:
SELECT DEPARTMENT, DEPT_NO, FULL_NAME, EMP_NO
FROM DEPARTMENT, EMPLOYEE
WHERE DEPARTMENT = "Engineering" AND MNGR_NO = EMP_NO;
Această instrucțiune întoarce câmpurile specificate pentru salariatul care este managerul departamentului Engineering. Deseori numele câmpului se întâlnește în mai multe tabele din cadrul aceleiași cereri (query). În acest caz câmpurile trebuie să fie diferențiate, precedând fiecare nume a câmpului cu numele tabelului și punct (.).
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 LAST_NAME, FIRST_NAME, PHONE_EXT
FROM EMPLOYEE
WHERE LAST_NAME = "Green";
întoarce numai înscrierile pentru care LAST_NAME este “Green”.
WHERE condition;
În această clauză:
condition = column operator value [log_operator condition]
value = value arith_operator value
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:
Operator Descrierea
Operatori de comparare Se folosește pentru a compara data din câmpul respectiv cu valoarea din condiția de căutare. Exemple <, >, <=, >=, =, and <>. Alți operatori includ BETWEEN, CONTAINING, IN, IS NULL, LIKE, și STARTING WITH.
Operatori aritmetici Se folosesc pentru a calcula și evalua valorile condițiilor de căutare. Operatorii sunt +, -, *, și /.
Operatorii logici Se folosesc pentru a combina condițiile de căutare sau nega condiția. Operatorii logici: NOT, AND, și OR.
Condițiile de căutare pot folosi următoarele tipuri de valori:
Tipurile de valori Descrierea
Valori literale Numere și șiruri de caractere a căror valoare dorim să testăm (de exemplu, numărul 1138 sau the string-ul "Smith").
Valori derivate Funcții și expresii aritmetice, de exemplu: SALARY * 2 sau LAST_NAME || FIRST_NAME.
Subcereri O instrucțiune SELECT care întoarce una sau mai multe valori. Valorile întoarse se folosesc la testarea condiției de căutare.
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.
De exemplu:
SELECT LAST_NAME, FIRST_NAME, EMP_NO FROM EMPLOYEE
WHERE LAST_NAME LIKE "%an";
Ca rezultat vom obține:
LAST_NAME FIRST_NAME EMP_NO
Ramanathan Ashok 45
Steadman Walter 46
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ă. De exemplu:
SELECT DEPT_NO, LAST_NAME, FIRST_NAME, HIRE_DATE
FROM EMPLOYEE
WHERE DEPT_NO = 623 AND HIRE_DATE > "01-Jan-1992";
Această cerere întoarce informație despre salariații departamentului 623 care au fost angajați la lucru după 1 Ianuarie 1992.
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ă.
Ca exemplu de utilizare a operatorului OR vom folosi cererea de mai jos:
SELECT CUSTOMER, COUNTRY
FROM CUSTOMER
WHERE COUNTRY = "USA" OR COUNTRY = "Canada";
Această cerere întoarce înscrierile ce se referă la cumpărătorii din USA și Canada.
Când introducem condiții de căutare compuse, trebuie să ținem cont de ordinea de evaluare a condițiilor. Să presupunem că dorim să obținem salariații din departamentul 623 sau 600 care au fost angajați la serviciu mai târziu de 1 Ianuarie 1992.
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.
Tabelul de mai jos prezintă funcțiile agregate valabile în InterBase:
Funcția Ce face această funcție
AVG(value) Întoarce valoarea medie pentru un grup de înscrieri.
COUNT(value) Calculează numărul înscrierilor care satisfac clauzei WHERE.
MIN(value) Întoarce valoarea minimă dintr-un grup de înscrieri.
MAX(value) Întoarce valoarea maximă dintr-un grup de înscrieri.
SUM(value) Adună valorile numerice într-un grup de înscrieri.
De exemplu, să presupunem că dorim să știm câte coduri de lucru diferite există în tabelul JOB.
Vom introduce următoarea instrucțiune
SELECT COUNT(JOB_CODE) FROM JOB;
Rezultatul este:
COUNT
31
Însă, acesta nu este rezultatul dorit, deoarece cererea include coduri de lucru dublate în cadrul contorului. Pentru a calcula numai coduri de lucru unice, vom folosi cuvântul cheie DISTINCT:
SELECT COUNT(DISTINCT JOB_CODE) FROM JOB;
Rezultatul corect va fi:
COUNT
14
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.
Ca exemplu vom introduce o cerere care va afișa numai departamentele principale a căror bugete totale sînt mai mari de 2,000,000:
SELECT HEAD_DEPT, SUM(BUDGET)
FROM DEPARTMENT
GROUP BY HEAD_DEPT
HAVING SUM(BUDGET) > 2000000;
Această cerere va genera următorul rezultat:
HEAD_DEPT SUM
000 3500000.00
100 3800000.00
600 2350000.00
Clauza ORDER BY
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.
De exemplu, vom culege instrucțiunea:
SELECT LAST_NAME, FIRST_NAME, PHONE_EXT
FROM EMPLOYEE
ORDER BY LAST_NAME;
Această cerere sortează rezultatul după numele de familie a salariaților.
Joncțiunea tabelelor
JOIN permite instrucțiunii SELECT să primească date din două sau mai multe tabele din baza de date. Tabelele sînt listate în clauza FROM. Clauza opțională ON poate reduce numărul de înscrieri întoarse, iar clauza WHERE va reduce ulterior numărul de înscrieri întoarse.
Din informația din SELECT care descrie joncțiunea, InterBase creează un tabel care conține rezultatele operației de joncțiune, tabelul rezultat, numit deseori tabel dinamic sau virtual.
InterBase suportă două tipuri de bază de joncțiune: joncțiune internă și joncțiune externă.
Joncțiunile interne leagă înscrierile din tabele bazându-se pe condiții de joncțiune specificate și întorc numai acele înscrieri care satisfac condiției de joncțiune. Dacă câmpul care va fi joncționat conține valoarea NULL pentru înscrierea dată, această înscriere nu va fi inclusă în tabelul rezultat. Joncțiunele interne sunt mai larg utilizate deoarece ele restricționează datele întoarse și prezintă relația clară dintre două sau mai multe tabele.
Joncțiunile externe leagă înscrierile din tabele bazându-se pe condiții de joncțiune specificate dar întoarce înscrieri indiferent dacă acestea satisfac condițiilor de joncțiune sau nu.
Joncțiunea internă
Există trei tipuri de joncțiuni interne:
Joncțiunea de egalitate (equi-joins) – leagă înscrierile bazându-se pe valoarea comună sau egalitatea relațională în câmpurile de legătură.
Joncțiunea care leagă înscrierile bazându-se pe compararea diferită de egalitate în câmpurile de legătură. Nu există o denumire oficial recunoscută pentru astfel de joncțiuni, dar pentru simplicitate ele pot fi numite joncțiuni comparative (comparative joins) sau (non-equi-joins).
Joncțiuni reflexive (reflexive sau self-joins), compară valorile in cadrul câmpului a unui singur tabel.
Pentru a specifica instrucțiunea SELECT ca o joncțiune internă, trebuie să listăm tabelele care vor fi joncționate în clauza FROM, și să listăm câmpurile care vor fi comparate în clauza WHERE. Sintaxa simplificată este:
SELECT <columns>
FROM <left_table> [INNER] JOIN <right_table>
[ON <searchcondition>]
[WHERE <searchcondition>];
Condiția de căutare bazată pe câmpul din tabelul din dreapta poate fi specificată în clauza opțională ON urmând referința tabelului din dreapta.
De exemplu, să considerăm următoarea cerere acre include joncțiune internă:
SELECT D.DEPARTMENT, D.MNGR_NO, E.SALARY
FROM DEPARTMENT D JOIN EMPLOYEE E
ON D.MNGR_NO = E.EMP_NO
AND E.SALARY*2 > (SELECT SUM(S.SALARY) FROM EMPLOYEE S
WHERE D.DEPT_NO = S.DEPT_NO)
ORDER BY D.DEPARTMENT;
Clauza SELECT de mai sus folosește nume corelaționale D pentru DEPARTMENT și E pentru EMPLOYEE (cum este specificat în clauza FROM) pentru a selecta numele departamentului și numărul managerului din tabelul DEPARTMENT și salariul managerului din tabelul EMPLOYEE.
Clauza ON conține o condiție de joncțiune compusă:
Câmpul MNGR_NO din tabelul DEPARTMENT trebuie să coincidă cu câmpul EMP_NO din EMPLOYEE.
Salariul managerului dublat (E.SALARY*2) trebuie să fie mai mare decât suma tuturor salariaților din departament. Cu alte cuvinte, salariul managerului trebuie să fie mai mare decât jumătate din suma salariilor tuturor salariaților din departament.
Joncțiunea externă
Joncțiunea externă produce tabelul rezultat care conține câmpuri din orice înscriere dintr-un tabel și un subset de înscrieri din alt tabel. Sintaxa joncțiunii externe este foarte asemănătoare cu cea a joncțiunii interne:
SELECT col [, col …] | *
FROM <left_table> {LEFT | RIGHT | FULL} [OUTER] JOIN
<right_table> [ON <searchcondition>]
[WHERE <searchcondition>];
Însă, în cazul joncțiunii externe este necesar de a specifica tipul joncțiunii. Există trei posibilități:
Joncțiunea externă de stânga obține toate înscrierile din tabelul din stânga a joncțiunii, și fiecare înscriere din tabelul din dreapta care satisfac condiției de căutare specificate în clauza ON.
Joncțiunea externă de dreapta obține toate înscrierile din tabelul din dreapta a joncțiunii, și fiecare înscriere din tabelul din stânga care satisfac condiției de căutare specificate în clauza ON.
Joncțiunea externă totală obține toate câmpurile din ambele tabele din joncțiune neluând în considerație condiția de căutare specificată în clauza ON
Joncțiunea externă este utilă în așa cazuri când dorim, de exemplu, când afișăm salariații care sînt încadrați în proiect, poate fi interesant de a vedea salariații ce nu sînt încadrați în acest proiect.
Joncțiunea externă de mai jos întoarce numele salariaților din tabelul EMPLOYEE și ID-urile proiectelor din tabelul EMPLOYEE_PROJECT, pentru salariații ce sînt încadrați în proiect.
SELECT PROJ_ID, FULL_NAME
FROM EMPLOYEE LEFT OUTER JOIN EMPLOYEE_PROJECT
ON EMPLOYEE.EMP_NO = EMPLOYEE_PROJECT.EMP_NO;
În exemplul de mai sus sunt specificați toți salariații din tabelul EMPLOYEE, cu excepția celor care sînt incluși în proiect, deoarece EMPLOYEE este tabelul din stânga joncțiunii.
3 DESCRIEREA BAZEI DE DATE “RAPROT FINANCIAR”, ÎN CADRUL SI “ACTIVITATEA ȘI PROGNOZAREA SITUAȚIEI FINANCIARE A UNEI FIRME PRIVATE”
3.1 DESCRIEREA STRUCTURII BAZEI DE DATE “RAPORT FINANCIAR”A SISTEMULUI INFORMAȚIONAL “ACTIVITATEA ȘI PROGNOZAREA SITUAȚIEI FINANCIARE A UNEI FIRME PRIVATE”
Baza de date a sistemului informațional “Activitatea și prognozarea situației financiare a unei firme private” este implementată în sistemul de gestiune al bazelor de date (SGBD) Paradox. Deoarece va fi necesar ca de fiecare dată la crearea raportului să fie creată baza de date am implementat un SQL script care creează obiectele bazei de date necesare pentru funcționarea sistemului informațional. Aceste obiecte sunt: domeniile de date definite, tabelele, trigherele, generatoarele, indexurile, cheile primare și străine (referințe), etc. După lansarea acestui SQL script noi obținem baza de date gata pentru exploatare de către programele pentru introducerea datelor referitoare la firme, produselor, indicatorilor și vânzărilor, cu evaluarea statisticilor și rapoartelor atât pe parcursul exploatării cât și după finisarea culegerii informațiilor. De asemenea utilizarea unui SQL script este mai comodă și din punct de vedere a flexibilității bazei de date, noi putem modifica baza de date înainte de a o crea. De asemenea SQL scriptul este foarte ușor de transferat la altă SGBD relațională care suportă standardul ANSI SQL.
Pentru asigurarea clarității structurii bazei de date și pentru simplificare au fost create domenii de date. În baza acestor domenii au fost create opt tabele ce vor asigura păstrarea informației referitoare la raport financiar. Pentru a micșora volumul de informație necesară pentru păstrarea datelor, au fost construite tabelele: firma, produs, rfirma, at_inv, vinzări, rap_an. Tabelul pentru păstrarea informației referitoare la firme conține următoarele câmpuri:
cod_frm – pentru păstrarea numărului unic a firmei,
denum_firm – pentru păstrarea denumirii a firmei,
data_inr – pentru păstrarea datei de înregistrare a firmei,
vin_firm – pentru păstrarea tipului de vânzare angro sau detail a firmei.
ofl – pentru păstrarea codului băncii al firmei,
cod_fisc – pentru păstrarea codului fiscal al firmei,
cod_tva – pentru păstrarea codului tva al firmei,
banca – pentru păstrarea denumirii băncii,
cod_dec – pentru păstrarea codului de decontare a firmei,
adresa – pentru păstrarea adresei juridice a firmei,
telefon – pentru păstrarea telefonului de contact al firmei.
Tabelul pentru păstrarea informației referitoare la datele ce țin cont de activitatea operațională, cheltuieli, activitatea financiară, rezultat excepțional conține următoarele câmpuri:
id – pentru păstrarea numărului unic al indicatorilor,
indicatori – pentru păstrarea denumirii indicatorilor financiari,
an_gest – pentru păstrarea trimestrului de gestiune,
val_an_gest – pentru păstrarea valorii trimestrului de gestiune,
an_prec – pentru păstrarea trimestrului precedent,
val_an_prec – pentru păstrarea valorii trimestrului precedent,
id_firm – numărul unic al firmei.
Tabelul pentru păstrarea datelor referitoare la datele privind activitatea de investiții conține următoarele câmpuri:
id – pentru păstrarea numărul unic al indicatorilor.
indicatori – pentru păstrarea denumirii indicatorilor.
an_gest – pentru păstrarea trimestrului de gestiune.
val_an_gest_s – pentru păstrarea valorii în străinătate a anului de gestiune.
val_an_gest_t – pentru păstrarea valorii totale a trimestrului de gestiune.
an_prec – pentru păstrarea trimestrului precedent.
val_an_prec_s– pentru păstrarea valorii în străinătate a trimestrului precedent.
val_an_prec_t– pentru păstrarea valorii totale a trimestrului precedent.
id_firm – numărul unic al firmei.
Tabelul pentru păstrarea informației referitoare la produsele de care dispune firma conține următoarele câmpuri:
id_prod – pentru păstrarea numărului unic al produsului,
den_prod – pentru păstrarea denumirii produsului,
cd_prod – pentru păstrarea codului produsului,
pret_vin_prod – pentru păstrarea prețului de vânzare a produsului,
sin_prod – pentru păstrarea sinieostului produsului,
ad_com – pentru păstrarea adausului comercial,
id_firm – numărul unic al firmei.
Tabelul pentru păstrarea informației referitoare vânzări, conține următoarele câmpuri:
id_v – pentru păstrarea numărului unic al înregistrării,
vin_can – pentru păstrarea vânzărilor cantitative,
vin_val – pentru păstrarea vânzărilor valorice,
p_gest – pentru păstrarea perioadei de gestiune,
p_prec – pentru păstrarea perioadei precedente,
id_prod – numărul unic al produsului,
id_firm – numărul unic al firnei.
Tabelul pentru păstrarea informației referitoare la prognozare, conține următoarele câmpuri:
ch_f – pentru păstrarea cheltuielilor fixe,
ch_v – pentru păstrarea cheltuielelor variabile,
vl_vin – pentru păstrarea valorii vânzărilor valorice,
prof_brut – pentru păstrarea profitului brut,
pon_ch_f – pentru păstrarea ponderei cheltuielelor fixe,
id_firm – numărul uni al firmei.
Pentru păstrarea informației referitoare la raport anual conține aceleași câmpuri ca și tabelul pentru păstrarea darelor trimestrial.
Pentru asigurarea numerelor unice id_firm, id_prod, id_v sunt folosite generatoare și trighere.
Pentru tabelul firma este creat generatorul id_firm_gen care este utilizat în trigherul before insert set_id_firm care generează o valoare id_firm nouă, de fiecare dată când este introdusă o valoare nouă.
Pentru tabelul produs este creat generatorul id_prod_gen care e utilizat în trigherul set_id_prod pentru generarea numerelor unice ale produselor id_prod, de fiecare dată cum este introdusă o specialitate nouă.
Analog este creat trigherul set_id_v pentru tabelul vinzări care utilizează generatorul id_v_gen pentru generarea numărului unic al vânzărilor speciale id_v.
Există trigherul del_prodt pentru ștergere before delete la tabelul produs pentru introducerea acestui produs în tabelul celor șterși cu scopul de a urmări circulația produselor cu care dispune firma.
3.2 DESCRIEREA PROGRAMULUI “CLIENT” AL SISTEMULUI INFORMAȚIONAL “ACTIVITATEA ȘI PROGNOZAREA SITUAȚIEI FINANCIARE A UNEI FIRME PRIVATE”
3.2.1 Descrierea generală a programului “client”
Destinația programului “client” este de a înregistrarea datele , în tabele corespunzătoare și crearea rapoartelor standarte pentru analiza activității și prognozarea situației financiare.
Pentru lansarea programului “client” e necesar de a efectua următoarea operație, utilizând programele BDE Administrator de creat un driver pentru legătura dintre program și baza de date.
După lansarea programului pe ecran apare o formă în care trebuie de întrodus parola de aces, în baza căreia se activează domeniul de acces al operatorului la informația din baza de date. După acesta operatorul pote să lucreze cu informația dată. Pentru a lucra cu informația necesară, este necesar de întrodus perioada de gestiune (anii corespunzători) unde se activiează accesul la informația datelor la această perioadă, dacă pentru această perioadă nu există atuni se poate înregistra informația. Dacă această perioadă există operatorul poate vizualiza, imprima și modifica informația necesară, și prognozarea situației financiare după anumite criterii.
Schema structurală a programului conți următoarele etape:
înregistrarea, modificarea, și prelucrarea datelordepre firme.
afișarea și imprimarea datelor despre firme.
înregistrarea și modificarea produselor de care dispune firma.
înregistrarea datelor privind vânzările firmei date.
statistica evaluării vânzărilor.
înregistrarea și modifcarea datelor privin indicatorilor financiari din activitatea financiară.
crearea, afișarea și imprimarea rapoartelor grafice și tabelare privind activitatea financiară a firmei date.
înregistrarea și prelucrarea datelor prind prognozarea situației financiare a firmei date.
crearea, afișarea și imprimarea rapoartelor privind prognozarea situației financiare a firmei date.
Prin statistic evaluării vânzărilor se are în vedere:
urmărirea volumului de vânzări față de targhetul propus evaluat în procente,
creșterea ofertei pe piață a produselor, adică care produse se vând mai bine,
crearea unor condiții specialela produsele care se vând foarte rău sau chiar de loc nu se vând.
La etapa de prognozare a situației financiare a unei firme date are loc mai întâi înregistrarea cheltuielilor fixe – valoarea, care sunt constatante, cheltuielile variabile și ponderea creșterii a valorii vânzărilor procentual față de cele la sfârșitul anului de gestiune apoi conform formulelor de calcul se calculează simestria cheltuielile variabile volumel de vânzări, profitul brut și ponderea cheltuielilor fixe față de vânzări. Însă pentru a putea exprima volumul de vânzări în procente se întroduce targhetul de vânzări pe perioada dată care poate să fie constant sau să crească (scadă) după un anumit procent dat.
De exemplu prognozarea mai poate fi făcută presupunând un volum oarecare de vânzări și valoarea cheltuielilor fixe de observat ce profit brut va putea fi obținut având vânzările și cheltuielile variaile date la aceleași condiții de lucru. De aici poți săți faci un program de lucru, adică crearea unor oferte speciale pe piață pentru diferiți cumpărători, pentru a atrage interesul clieienților la aceste produse pentru obținerea profitului stabilit.
Forma pentru prognozarea situației financiare a unei firme este prezentată în figura 1.
DBGrid de pe această formă ne arată volorile câmpurilor respective. După cum se oservă este creat un grafic care reflectă coerența între câmpurile care conțin datele despre vânzări nete, profitul brut și ponderea cheltuielilor fixe. Din acest grafic putem face concluzia că în caz de adaus comercial stabil, odată cu creșterea volumului de vânzări scade ponderea cheltuielilor fixe și crește venitul. Aici nu se observă această scădere deorece rezultatul este rotungit la valoare întreagă. La o optimizare a procesului de distribuție pot fi scăzue unele cheltuieli variabile.
Butonul YES permite calcularea datelor necesare și înregistrarea datelor în tabel. Butonul Retry permite modificarea datelor datelor și înnoirea datelor calculate în DBGrid. Odată cu modificarea datelor automat se schimbă și datele din grafic. Butonul ac_al permite activarea Edit-lor pentru întroducerea valorilor pentru cheltuielile fixe, volumul de vânzări și cheltuielile variabile aleatoare. În colțul stânga sus a formei este Edit-ul pentru întroducerea targhetului a volumului de vânzări pe aceste perioade. Când acest buton nu este activat cu ajutorul Edit-lor se întroduce ponderea de creștere a cheltuielilor variabile și a volumului de vânzări, restul datelor luânduse din tabele.
Fig. 1. Forma pentru prognozarea situației financiare a unei firme private.
Descrierea în linii generale a blocurilor din schema-bloc a programului:
X1 – introducerea parolei de acces,
X2 – înregistrarea datelor despre forme,
X3 – modificarea datelor despre firme,
X4 – afișarea și imprimarea datelor despre firme,
X5 – înregistrarea perioadei de gestiune a firmei,
X6 – înregistrarea indicatorilor financiari privind activitatea firmei,
X7 – prelucrarea datelor, se are în vedere calcularea și completarea câmpurilor necasare.
X8 – crearea rapoartelor grafice și tabelare,
X9 – afișarea și imprimarea datelor privind activitatea firmei,
X10 – înregistrarea datelor pentru prognozare,
X11 – prelucrarea datelor pentru prognozare,
X12 – crearea rapoartelor grafice pentru prognozarea financiară a firmei,
X13 – afișarea și imprimarea datelor privind prognozarea financiară a firmei,
X14 – modificarea datelor necesare,
X15 – prelucrarea datelor modificate,
X16 – afișarea datelor modificate.
Y1 – verificarea veridicității parolei de acces,
Y2 – verificarea înregistrării firmei,
Y3 – verificarea perioadei de gestiune.
Forma principală a programului “client” permite alegerea următoarelor funcții:
activarea formei pentru introducerea datelor despre firme în baza de date;
activarea formei pentru introducerea parolei de acces a operatorului;
activarea formei pentru introducerea perioadei de gestiune;
activarea formei de modificare a informației referitoare la firme;
activarea formei pentru vizionarea informației datelor despre firme;
activarea formei pentru înregistrarea produselor de care dispune firma;
activarea formei pentru înregistrarea informației privind activitatea financiară;
activarea formei pentru înregistrarea vânzărilor;
activarea formelor pentru vizionarea rapoartelor în forma tabelară sau grafică;
activarea formei pentru vizualizarea datelor privind prognoza.
Formele de înregistrare a datelor permit activarea formelor de vizionare parțială a datelor, ștergerea și modificarea datelor corespunzătoare.
3.2.2 Introducerea datelor
Metoda cu care este efectuată interacțiunea programului “client” este că într-o variabilă locală se pregătește SQL instrucțiunea necesară pentru transmitere la SGBD, apoi este deschis un tranzact în baza de date, în obiectul pregătit de tip TQuery (cerere) se înscrie conținutul aceste variabile, se execută cererea, și dacă cererea a fost executată cu succes se păstrează modificările efectuate în baza de date. În caz că la executarea cererii de către sistemul de gestiune al bazei de date, apar erori, programul afișează erorile și apoi efectuează comanda RollBack pentru a restabili baza la condiția inițială începutului tranzactului. Dacă cererea efectuată cu succes întoarce un răspuns de la SGBD atunci programul prelucrează și afișează rezultatele.
Forma pentru introducerea parolei de activare păstrează parola în o variabilă globală. La introducerea parolei apare un mesaj care indică tipul de aces la informație. În caz că parola nu coincide, apare un mesaj care indică acest fapt. În caz că această parolă este aflată de către persoane inautorizate, ea poate fi schimbată de către administratorul programului.
După introducerea parolei de activare operatorul are opțiunea de a înregistra datele. Forma de introducere a datelor despre firmă este prezentată în figura 2.
Fig. 2. Forma pentru introducerea datelor despre firma.
Pe această formă sunt prezente 8 obiecte de tip TDBEdit care permite salvarea datelor in tabel, corespunzător câmpurilor date și 3 obiecte de tip TBitBtn și un obiect de tip TRadioButon. Obiectul de tip TRadioButon servește pentru alegerea categoriei de vânzări din cel doua de care dispune firma, adică poate fi aleasă numai una din cele două. Obiectul de tip TbitBtn cu denumirea de Afișare permite afișarea listei a datelor despre firme din tabelul dat. Obiectul de tip TbitBtn cu denumirea Confirmare, activind-ul permite salvarea datelor în tabel și deschide forma de întroducere produselor de care dispune firma, iar cel cu denumirea Anulare, anulează înregistrarea datelor și închide forma dată.
Forma de introducere a produselor de care dispune firma este prezentată în figura 3.
Pe această formă sunt prezente 5 obiecte de tip TDBEdit care permite salvarea datelor in tabel, corespunzător câmpurilor date și 3 obiecte de tip TBitBtn și un obiect de tip TComoBos. Obiectul de tip TComoBox servește pentru alegerea firmei din lista firmelor care au fost înregistrate și nu poaate fi culeasă de la tastaură, dacă firma dată nu există în listă atunci ia trebuie inregistrată. Obiectul de tip TbitBtn cu denumirea de Preview permite afișarea listei a produselor de care dispune firma dată. Obiectul de tip TbitBtn cu denumirea Ok, activind-ul permite salvarea datelor în tabel, iar cel cu denumirea Cancel, anulează înregistrarea datelor și închide forma dată. Prin vînzări cantitative se are în vedere un volum stabilit de vânzări, cu alte cuvinte targhetul la produsul dat, adică ce volum de vinzări ar trebui de obținut. În baza aceste date se face evaluarea vânzărilor a produselor, care influiențează la propgnozarea situației financiare.
Fig. 3. Forma pentru introducerea produselor.
Forma de introducere a perioadei de gestiune este prezentată în figura 4.
Pe această formă sunt prezente un obiect de tip TcomoBox, două obiecte de tip Tedit și un obiect de tip TbitBtn. Obiectul de tip TComoBox servește pentru alegerea firmei din lista firmelor care au fost înregistrate și nu poaate fi culeasă de la tastaură, dacă firma dată nu există în listă atunci ia trebuie inregistrată. Obiectele de tip Tedit servesc pentru întroducerea perioadei de gestiune, dacă diferența dintre aceste două date este mai mare ca unu la confirmare dă o eroare că nu a fost întrodusă corect perioada de gestiune. După ce afost introdusă perioada de gestiune corect noi putem întroduce datele ce țin cont de activitatea financiară.
Formele de întroducere a datelor ce se referă la indicatorii , conțin obicte de tip Tlabel, TDBEdit și TBitBtn. În obiectele de tip TLabel sunt întroduse denumirile exacte a indicatorilor financiari.
Fig. 4. Forma pentru introducerea perioadei de gestiune.
Cu ajutorul obiectelor de tip TDBEdit se folosesc pentru întroducerea datelor în tabel. Întroducerea acestor date se face trimestrial, pentru a vedea mai eficient volumul de vânzări a firmei pe perioadele respective a anului de gestiune. Obiectele de tip TBitBtn se foloses pentru confirmarea înregistrării, anulării și pentru vizualizarea datelor întroduse. Pentru a nu întroduce de fiecare dată denumirile indicatorilor sa hotărât de a crea câte o formă pentru fiecare tip de activitate, unde obiectele de tip TLabel vor afișa aceste denumiri, și la confirmarea înregistrării ele se vor înregistra în tabel.
3.2.3 Modificarea datelor
Din forma principală, operatorul poate efectua modoficarea datelor activând butonul respectiv pentru modoficarea informației necesare. În acest caz se deschide o formă asemănătoare celei de inregistrare a datelor respective, însă obiectele de pe formă vor reflecta datele care trebuiesc modificate. După efectuarea modificării se confirma această modificare și datele din tabel sunt înlocuite cu datele noi, în caz că am hotărât că nu trebuiesc modificate atunci se anulează modificarea datelor acționând butonul specificat pentru anularea modificărilor.
Modificarea datelor mai poate fi efectuată și din formele de înregistrare a datelor, adică pe aceate forme există un buton care deschide o forma de afișare a datelor în formă de tabel, apoi în DBGrid care se conține pe această formă care reflectă datele selectate pot fi modificate acționând mai întâi butonul pentru moificarea datelor în DBGriddin bara cu instrucțiuni. După ce a fost creată modificarea se acționează butonul salvare, care înnpiește datele modificate în tabel.
3.2.4 Ștergerea datelor
Pentru ștergerea datelor operatorul mai întâi trebuie să activeze forma de afizare a datelor, apoi inserând înregistrarea darită pentru ștergere și apasă butonul pentru ștergere. Înainte de a șterge inregistrarea apare un mesaj care întreabă confirmarea ștergerii, după aceea înregistrarea se șterge din tabel. Dacă tabelul este pustiu, acționân butonul pentru ștergerea înregistrărilor apre un mesaj care confirmă că tabelul dat este pustiu și nu poate fi executată ștergerea informației din acest tabel. Ștergerea produselor de care dispun firma din tabel de produse se salvează întrun tabel Deleted care apo permite de observat cu ce fel de tip a lucrat firma dată și gama lor. Aceasta ne dă posibilitatea de observat că cu cât gama de produse cu care a lucrat este mare, că firma nu obținea prifitul dorit la aceste produse și căuta modalitatea de lucru a restabili activitatea financiară.
3.2.5 Afișarea datelor
Pentru a viziona date introduse operatorul activează butonul Raport din forma principală, apoi selectează informația care dorește pentru afișare. Afișarea porțială a datelor este posibila pe parcursul înregistrării datelor, adică permite vizionarea datelor întroduse până a crea rapoartele date. Cel mai principal punct din afișarea datelor este prezentarea datelor în formă grafică pentru a vedea clar nivelul de funcționare și de apreciere mai rapidă a concluziilor necesare.
Afișarea raportelor și denumirea indicatorilor privind activitatea financiară sunt create conform standardelor financiare.
4 PARTEA ECONOMICĂ A PROIECTULUI
4.1 PLANIFICAREA REȚEA PENTRU ELABORAREA SI “ACTIVITATEA ȘI PROGNOZAREA SITUAȚIEI FINANCIARE A UNEI FIRME PRIVATE”
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. Tab. 15.
(continuare) Tab. 15.
(continuare) Tab. 15.
Graful-rețea pentru elaborarea SI “Activitatea și prognozarea situației financiare a unei firme private” vezi anexa.7.
Durata efectuării lucrărilor. Tab. 16.
Pentru calculul parametrilor grafului-rețea am elaborat un sistem care după transferarea datelor de intrare în baza de date (SQL) permite lansarea unui set de proceduri care calculează parametrii grafului-rețea.
Calculele parametrilor grafului rețea. Tab. 17.
Componența grupului de lucru. Tab. 18.
4.2 EVALUAREA ECONOMICĂ A SISTEMULUI INFORMAȚIONAL “ACTIVITATEA ȘI PROGNOZAREA SITUAȚIEI FINANCIARE A UNEI FIRME PRIVATE”
Executarea lucrărilor de către lucrători. Tab. 19.
Pentru salariu remunerat de bază sau cheltuit
Sb = 1720,00 + 1660,00 + 1990,00 = 5360,00 lei.
Salariu auxiliar (25%)
Sa = 5360,00 0,25 = 1340,00 lei.
Defalcări în Fondul Social (31%)
Cfs = (5360,00 + 1340,00) 0,31 = 2077,00 lei.
Cheltuielile totale pentru achitarea salariului
Ct = 6700,00 + 2077,00 = 8777,00 lei
Evenimentele care necesită timp de lucru cu calculatorul. Tab. 20.
Programul va fi scris la calculatoare arendate cu 15 lei pe oră.
Suma cheltuielilor pentru ore-mașină va constitui
Smas = 270,00 * 15 = 4050,00 lei.
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.4.3 Professional: Costul inițial 600USD, 2 licențe, amortizarea timp de 2 ani. Următorul produs Inprise Delphi va fi cumpărat cu 0.5 preț (la prezentarea licențelor actuale).
Durata lucrărilor asupra proiectului dat 3 luni (1USD=12,85)
Sam_soft = (3*(600/2) * 2 )/(24) = 75USD = 963,75 lei;
Cheltuielile prețului de cost și prețului de livrare a SI “Admiterea UTM”. Tab. 21.
Produsul final este procurat de către „M.A.G” SRL. Firma capătă dreptul asupra acestui soft incluzând dreptul de a vinde acest soft.
5 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.
5.1 ZGOMOTUL
Zgomotul este unul din factori care influențează omul când el lucrează cu CE, aceasta este condiționat de funcționarea dispozitivelor ce sunt necesare în CC.
Sursele principale de zgomot în încăperi amenajate cu tehnica de calcul sunt imprimantele, tastatura, instalații pentru condiționarea aerului, dar în CE – ventilatoarele sistemelor de refrigerare și transformatoare.
La influența zgomotului pe un timp îndelungat la colaboratorii CC se observă micșorarea atenției, dureri de cap, se micșorează capacitatea de muncă. Î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 22:
Nivelurile admisibile a zgomotului. Tab. 22.
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.
5.2 SECURITATEA ELECTRICĂ
Utilajul CE este foarte periculos pentru operatori, deoarece lucrând la acest utilaj operatorul poate să atingă unele părți care sunt sub tensiune. Trecând prin om curentul electric efectuează influența optică, biologică termică, ce poate aduce la traumă electrică (GOST 12.1.009-91).
O importanță mare pentru emiterea cazurilor neplăcute și periculoase are organizarea corectă a exploatării utilajului electric, efectuarea lucrărilor de montare și profilactică.
Legarea la nul este o măsură de protejare de electrocutare prin deconectarea strictă și în viteză a rețelei în caz de apariție a tensiunii pe carcasă sau în cazul stră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
5.3 MICROCLIMATUL
Deoarece CE sunt surse de eliminare a căldurii, ce poate ajunge la mărirea temperaturii și micșorarea umidității aerului. În încăperi se atrage atenție la controlul parametrilor microclimatului în Săli de Calcul (SC). În SC mărimea medie a eliminărilor de căldură constituie 310 W/m2. Eliminările de căldură de la instalații de iluminare tot sunt mari, mărimea specifică a lor este 35-60 W/m2. În afară de aceasta la microclimatul încă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 23.
Normele microclimatului. Tab. 23.
Î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ă.
5.4 SECURITATEA ANTIINCENDIARĂ
Focul este o forță gigantică. Oamenii antici vedeau în el o sursă a vieții și în prezent el încălzește și hrănește doar cu acea diferență că pentru contemporanul nostru la nivelul actual de dezvoltare a condițiilor sociale că această întrebare a scăzut cu mult. Însă acest fapt nu ne permite să neglijăm focul, doar o mică neatenție și marea lui forță poate aduce o nenorocire. Iată de ce e atât de important rolul securității antiincendiare în organizarea protecției muncii la întreprinderi și în încăperi administrative.
Incendiul se numește arderea necontrolată în afara unui focar special care aduce pierderi materiale. Dacă această ardere nu cauzează pierderi materiale, atunci ea se numește inflamare. Explozia este o transformare chimică momentană, caracterizată prin degajarea de energie și crearea de gaze comprimate.
După gradul de ardere (oxidare însoțită de degajarea unei cantități mari de căldură) materialele de construcție se împart în următoarele tipuri: nearzătoare – sub acțiunea focului nu se inflamează, nu se corodează; greu inflamabile – sub acțiunea focului 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.
5.5 RADIAȚIE
Intensitatea radiației Roentgen de energie joasă se controlează la locuri de muncă cu monitoare, care lucrează sub tensiunea la cinescop 15 kV și mai mult. Norma nivelului de radiație roentgen este 100 mcP/oră, dar în timpul de azi se utilizează mai mult monitoare cu nivelul radiație mai mică, ce aduce la micșorarea influenței factorilor dăunători asupra programatorului sau operatorului. La efectuarea tezei de licență a fost utilizat monitorul cu tensiunea la cinescop mult mai mică de 15 kV, și de aceea acest factor nu a fost înregistrat de dispozitiv, adică a fost mai puțin de normă.
Încă se măsoară și se normează intensitatea radiației ultraviolete (la lungimea de undă 336 nm) și infraroșie (la lungimea de undă 700 – 1050 nm) ce influențează asupra omului, nu trebuie să depășească 10 W/m2.
Radiația electromagnetică se normează după componente electrice (50 V/m) și magnetice (50 A/m) de aflare în această zonă de radiere în timp de 8 ore. Tensiunea înaltă a câmpului electric între monitorul și operatorul aduce la efecte neplăcute. La distanța de 5 – 30 cm de la monitor tensiunea nu trebuie să depășească nivelul admisibil după norme, ce sunt stabilite în dependența de timpul aflării la locul de muncă. Niveluri admisibile de tensiune sunt prezentate în tabelul 24.
Niveluri admisibile de tensiune. Tab. 24.
Controlul radiației de toate tipurile se efectuează în conformitate cu regulile ce sunt expuse în îndrumare speciale.
5.6 PARAMETRII VIZUALI A IMAGINII
Efectuând controlul asupra condițiilor de lucru la locuri de muncă cu monitoare trebuie să fie măsurate și evaluate următorii parametri a imaginii:
deformarea imaginii;
contrastul de strălucire a imaginii;
variația strălucirii elementelor simbolului;
lungimea, lățimea, raportul lățimii la lungimea;
lățimea liniei de contur a simbolului;
modulație de strălucire a rasterului;
distanța între cuvinte, rânduri;
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 25.
Parametrii monitorului. Tab. 25.
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.
5.7 EFECTE PSIHOFIZIOLOGICE
Lucrul operatorilor cere încordarea mintală și emoțională foarte mare, concentrarea atenției și responsabilitatea de lucrul efectuat. Operatorii foarte des suferă de diferite stări proaste a vederii, dureri de cap, dureri de mușchi în regiunea spatelui. În afară de asta, în mare măsură se exprimă senzația oboselii și încordarea mintală în timpul lucrului; ei nu se simt odihniți după somn de noapte.
Sarcina asupra vederii și caracterul încărcării lucrului provoacă la operatori 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.
5.8 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.
5.9 CALCULAREA ILUMINATULUI ARTIFICIAL A ÎNCĂPERII
Pentru organizarea activității normale a omului o mare însemnătate are crearea condițiilor normale de iluminare naturală și artificială la locul de muncă.
Iluminarea de producție, corect proiectată și îndeplinită, aduce la rezolvarea 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,2 m
Ht- distanța de la podea până la suprafața iluminată, 0,75 m
Hc=4,00 – 0,4 – 0,75 = 2,85 m
Calculăm i,
Având coeficientul de reflectare a tavanului și pereților egal cu 0.7 și după indicele calculat i, coeficientul de folosire a fluxului de lumină din tabel egal =0,30
Calculăm
Pentru iluminare utilizăm 3 instalații a câte 2 becuri fiecare. Alegem cea mai apropiată lampă de luminiscență cu fluxul de lumină 4290 lm care asigură pe deplin iluminarea încăperii de lucru.
5.10 ECOLOGIA
Elaborarea și exploatarea produselor soft este una din cele mai curate din punct de vedere ecologic activitatea de producere a oamenilor. Sunt utilizate numai surse de energie electrică. Hârtia nu se utilizează în cantități mari, și ea poate fi ușor reciclată după utilizare. Calculatoarele nu poluează mediul în tipul exploatării.
CONCLUZII
Elaborarea sistemului informațional „Activitatea și prognozarea situației financiare a unei firme private” oferă posibilitatea de afișare a rezultatelor în formă grafică, care au o valoare esențială în proiectul dat și care permite de a face o analiză mai suficientă asupra datelor și accesul rapid la informația necesară.
Acest program permite crearea rapoartelor pentru evaluarea și rpognozarea situației financiare, care într-o modalitate sau alta refelectă activitatea financiară a unei firme private, pe baza cărora pot fi create condiții noi de lucru și oferte speciale pentru a atrage cumpărătorii la gama de produse care se mișcă foarte greu pe piață și tot odată de a le face cunoștință cu gama dată. Un rol mare care joacă la volumul de vânzări este reclama, însă ea are o legătură cu volumul de vânzări.
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, fie și așa sisteme ca Oracle, DB2, Informix, etc. Programele “server” și “client” nu necesită modificări, trebuie doar create driver-e de legătură cu aceste SGBD utilizând fie ODBC sau BDE.
În caz că la exploatarea pe viitor vor apărea necesități de modificare a formelor de intrare, ele trebuie efectuate atât în baza de date, cât și în programele respective. Modificările bazei de date pot fi efectuate la crearea bazei de date, introducând schimbări în SQL scripturi, sau în timpul exploatării sistemului, utilizând instrucțiunile ALTER. Modificările programelor pot fi ușor efectuate, deoarece toate formele de lucru cu baza de date sunt implementate utilizând aceiași tehnologie de interacțiune cu SGBD. Se schimbă componentele necesare pe formă, iar apoi se introduc modificări în SQL instrucțiunea care efectuează cererea la SGBD.
BIBLIOGRAFIE
А.Я. Архангельский "Работа с локальными базами данных в DELPHI 5".
А.Я. Архангельский "100 компонентов общего назначения библиотеки DELPHI 5".
А.Я. Архангельский "Язык SQL в DELPHI 5".
Crearea tabelelor cu ajutorul DataBaseDesktop. Formă electronică
Основы SQL. Formă electronică
В.В.Корнеев, А.Ф.Гарев, С.В.Васютин, В.В.Райх "Базы данных интелектуальная обработка информации".
V.Gofman "Lucrul cu baze de date în DELPHI ".
Н.Культин "Програмирование на Object Pascal в Delphi 5". Самоучитель.
Шумаков П.В. Фаронов В.В. "Руководство разработки баз данных в DELPHI 5 ".
10. Шумаков П. В. Delphi 3 и разработка приложений баз данных.-М.: «Нолидж»1999.-704с.
11. Грофф Дж. SQL полное руководство. -Kieв.:BHV –608c.
12. Энсор Д. Oracle 8: Рекомендации разработчикам. -Kieв.:BHV –128c.
13. Стивенс Р. SQL за 24 часа. Освой самостоятельно. -:Бином – 400c.
14. Грабер М. SQL: справочное руководство -:ЛОРИ – 287c.
15. Грабер М. Введение в SQL. -:ЛОРИ.
16. Йордан Э. Структурные модели в объектно-ориентированном анализе и проектировании. -:ЛОРИ.
17. Сергей Термин «Бугалтерские и налоговые консултации» №1-2/98 Представление финансовых отчетов ст. 91-111.
18. Баклашов И. Охрана труда на предприятия связи. Москва 1983.
ANEXE
Anexa 1
Structura bazei da date „Raport FINANCIAR”
Anexa 2
SQL scriptul pentru crearea bazei de date “Raport Financiar” al SI “Activitatea și prognozarea situației financiare a unei firme private”.
CREATE DATABASE "d:\diploma\pro.gdb" USER "SYSDBA" PASSWORD "mag"
PAGE_SIZE = 4096;
CONNECT "d:\diploma\pro.gdb"
USER "SYSDBA" PASSWORD "mag";
/*–––––––––––––––––––––-*/
create domain name_string as varchar(25);
CREATE DOMAIN name_short_string AS VARCHAR(10);
CREATE DOMAIN name_long_string AS VARCHAR(50);
CREATE DOMAIN name_vl_string AS VARCHAR(80);
CREATE DOMAIN categoria
AS VARCHAR(1)
DEFAULT 'B' NOT NULL
CHECK (VALUE IN ('B', 'K'));
COMMIT;
/*Tabelul pentru firme*/
CREATE TABLE facultate (
id_firm INTEGER NOT NULL PRIMARY KEY,
den_firm name_vl_string NOT NULL,
data_inr date NOT NULL,
vin_firm boollean NOT NULL,
ofl integer,
cod_fisc integer,
cod_tva integer,
bamca name_ string,
cod_dec integer,
adresa name_long_string,
telefon name_short_string.
);
COMMIT;
CREATE UNIQUE ASCENDING INDEX fr_idx ON facultate (cod_firm, den_firm, data_inr, vin_firm, ofl, cod_fisc, cod_tva, banca, adresa, telefon);
CREATE UNIQUE ASCENDING INDEX fr_name_key ON firme (fr_name);
CREATE UNIQUE ASCENDING INDEX fr_name_key_sh ON firme (fr_name_sh);
COMMIT;
/*Tabelul pentru produse*/
CREATE TABLE produse (
id_prod INTEGER NOT NULL PRIMARY KEY,
den_prod name_vl_string NOT NULL,
cod_prod name_short_string NOT NULL,
pret_vin_prod money NOT NULL,
sin_prod money NOT NULL,
ad_com integer NOT NULL,
id_firm integer NOT NULL,
FOREIGN KEY (id_firm) REFERENCES firme(id_firm)
);
COMMIT;
CREATE UNIQUE ASCENDING INDEX prod_idx ON specialitate (id_prod, den_prod, cod_prod, pret_vin_prod, sin_prod, ad_com, id_firm);
CREATE UNIQUE ASCENDING INDEX prod_name_key ON produse (prod_name);
CREATE UNIQUE ASCENDING INDEX prod_name_key_sh ON produse (prod_name_sh);
COMMIT;
/*Tabelul pentru activitatea operationala*/
CREATE TABLE act_op (
id_op integer NOT NULL PRIMARY KEY,
indic name_vl_string NOT NULL,
an_gest integer NOT NULL,
val_an_gest integer NOT NULL,
an_prec integer NOT NULL,
val_an_prec integer NOT NULL,
id_firm integer NOT NULL,
FOREIGN KEY (id_firm) REFERENCES firme (id_firm)
);
/*Tabelul pentru produsele sterse din tabelul principal*/
CREATE TABLE deleted(
id_in integer NOT NULL,
data date NOT NULL,
id_prod integer NOT NULL,
den_prod name_string NOT NULL,
id_firm integer NOT NULL.
PRIMARY KEY (id_firm, id_prod)
);
COMMIT;
/*Tabelul pentru activitatea de investitii*/
CREATE TABLE ac_inv (
id_inv integer NOT NULL PRIMARY KEY,
indic name_vl_string NOT NULL,
an_gest integer NOT NULL,
val_an_ges_s integer NOT NULL,
val_an_ges_t integer NOT NULL,
an_prec integer NOT NULL,
val_an_prec_s integer NOT NULL,
val_an_prec_t integer NOT NULL,
id_firm integer NOT NULL,
);
COMMIT;
CREATE ASCENDING INDEX id_inv ON ac_inv (id_inv);
COMMIT;
/*Tabelul pentru inregistrarea vinyarilor*/
CREATE TABLE vinzari (
id_v INTEGER NOT NULL,
vin_can integer NOT NULL,
vin_val integer NOT NULL,
p_gest integer NOT NULL,
p_prec integer NOT NULL,
id_prod integer NOT NULL,
id_firm integer NOT NULL.
);
COMMIT;
/*Tabelul pentru inregistrarea raportului anual*/
CREATE TABLE note (
id_ind INTEGER NOT NULL PRIMARY KEY,
an_prec integer NOT NULL,
val_an_prec integer NOT NULL,
an_gest integer NOT NULL,
val_an_gest integer NOT NULL,
id_firm integer NOT NULL,
);
COMMIT;
/*Trighere de intrare*/
/*Trigher pentru tabelul firme*/
create generator id_firm_gen;
set generator id_firm_gen to 0;
set term !! ;
create trigger set_id_firm FOR firme
before insert as
begin
new.id_firm = gen_id(id_firm_gen, 1);
end !!
set term ; !!
commit;
/*Trigher pentru tabelul produse*/
create generator id_prod_gen;
set generator id_prod_gen to 0;
set term !! ;
create trigger set_id_prod FOR produse
before insert as
begin
new.id_prod = gen_id(id_prod_gen, 1);
end !!
set term ; !!
commit;
/*Trigher pentru tabelul ac_op*/
create generator id_op_gen;
set generator id_op_gen to 0;
set term !! ;
create trigger set_id_op FOR ac_op
before insert as
begin
new.id_op = gen_id(id_op_gen, 1);
end !!
set term ; !!
commit;
/*Trigher pentru tabelul ac_inv*/
create generator id_ai_gen;
set generator id_ai_gen to 0;
set term !! ;
create trigger set_id_ai FOR ac_inv
before insert as
begin
new.id_ai = gen_id(id_ai_gen, 1);
end !!
set term ; !!
commit;
/*Trighere pentru stergere*/
set term !! ;
create trigger del_vin FOR vinzari
before delete as
begin
insert into deleted values(old.id_v, old.vin_can, old.vin_val, old.p_gest, old.p_prec);
/* delete from studii where (id_v = old.id_v); */
end !!
set term ; !!
/*Trighere pentru modificare*/
set term !! ;
create trigger mod_abit FOR vinzari
before update as
declare variable nr_max integer;
declare variable nr_max_d integer;
begin
if (old.id_prod <> new.id_prod) then begin
insert into deleted values(old.id_v, old.vin_can, old.vin_val, old.p_gest, old.p_prec);
select max(id_v_prod) from abiturient where (id_prod = new.id_prod) into :nr_max;
select max(id_d_prod) from deleted where (id_prod = new.id_prod) into :nr_max_d;
if (:nr_max IS NULL) then nr_max = 0;
if (:nr_max_d IS NULL) then nr_max_d = 0;
if (:nr_max > :nr_max_d) then begin
new.id_v_prod = :nr_max + 1;
end else
new.id_v_prod = :nr_max_d +1;
end
end !!
set term ; !!
COMMIT;
EXIT;
Anexa 3
Secvențe din codul sursă ale programului “client”
Pentru programul client vom prezent secvențele de program pentru verificarea parolei de acces și a formei principale.
unit Unit_init; {secvență a programului din forma principală}
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
Menus, ComCtrls, ToolWin;
type
TForm_init = class(TForm)
MainMenu: TMainMenu;
File2: TMenuItem;
Exit2: TMenuItem;
N6: TMenuItem;
PrintSetup2: TMenuItem;
Print2: TMenuItem;
N7: TMenuItem;
SaveAs2: TMenuItem;
Save2: TMenuItem;
N8: TMenuItem;
Open2: TMenuItem;
New2: TMenuItem;
Help1: TMenuItem;
About1: TMenuItem;
HowtoUseHelp1: TMenuItem;
SearchforHelpOn1: TMenuItem;
Contents1: TMenuItem;
StatusBar1: TStatusBar;
ToolBar1: TToolBar;
ToolButton1: TToolButton;
ToolButton2: TToolButton;
Registru1: TMenuItem;
ActivitateaOperationala1: TMenuItem;
VinzariNete1: TMenuItem;
CostulVinzarilor1: TMenuItem;
Alteveniturioperationale1: TMenuItem;
Cheltuielicomerciale1: TMenuItem;
Cheltuieligeneralesiadministrative1: TMenuItem;
Altecheltuielioperationale1: TMenuItem;
Activitateadeinvestitii1: TMenuItem;
Venituridinactivitateadeinvestitii1: TMenuItem;
Cheltuielidinactivitateadeinvestitii1: TMenuItem;
Activitateafinanciara1: TMenuItem;
Venituridinactivitateafinanciara1: TMenuItem;
Cheltuielidinactivitateafinanciara1: TMenuItem;
Rezultztexceptional1: TMenuItem;
Cheltuielieconomiiprivindimpozitulpevenit1: TMenuItem;
Perioadadegestiune1: TMenuItem;
Raport1: TMenuItem;
Grafice1: TMenuItem;
Tabelar1: TMenuItem;
Anexa1: TMenuItem;
Pro1: TMenuItem;
procedure Exit1Click(Sender: TObject);
procedure Exit2Click(Sender: TObject);
procedure New2Click(Sender: TObject);
procedure ToolButton1Click(Sender: TObject);
procedure ToolButton2Click(Sender: TObject);
procedure Perioadadegestiune1Click(Sender: TObject);
procedure VinzariNete1Click(Sender: TObject);
procedure CostulVinzarilor1Click(Sender: TObject);
procedure Alteveniturioperationale1Click(Sender: TObject);
procedure Cheltuieligeneralesiadministrative1Click(Sender: TObject);
procedure Cheltuielicomerciale1Click(Sender: TObject);
procedure Altecheltuielioperationale1Click(Sender: TObject);
procedure Venituridinactivitateadeinvestitii1Click(Sender: TObject);
procedure Cheltuielidinactivitateadeinvestitii1Click(Sender: TObject);
procedure Venituridinactivitateafinanciara1Click(Sender: TObject);
procedure Cheltuielidinactivitateafinanciara1Click(Sender: TObject);
procedure Rezultztexceptional1Click(Sender: TObject);
procedure Cheltuielieconomiiprivindimpozitulpevenit1Click(
Sender: TObject);
procedure Grafice1Click(Sender: TObject);
procedure Tabelar1Click(Sender: TObject);
procedure Anexa1Click(Sender: TObject);
procedure Pro1Click(Sender: TObject);
procedure FormShow(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form_init: TForm_init;
_indicatori,sim:string;
k:integer;
implementation
uses Unit_datamod, Unit_inreg_f, Unit_inr_prod, Unit_per_gest,
Unit_vin_nete, Unit_af_vin_nete, Unit_cost_vin, Unit_alte_ven_op,
Unit_chelt_gen_ad, Unit_chlet_com, Unit_alte_chelt_op, Unit_ven_act_inv,
Unit_chelt_act_inv, Unit_ven_act_fin, Unit_chelt_act_fin, Unit_rez_exc,
Unit_chelt_imp_ven, Unit_rap_fin, Unit_rf, {Unit1,} Unit_anexa,
Unit_af_ac_op, Unit_prog_1, Unit_par_aces, Unit_par_f;
{$R *.DFM}
procedure TForm_init.Exit1Click(Sender: TObject);
begin
Form_init.Close;
end;
procedure TForm_init.Exit2Click(Sender: TObject);
begin
Form_init.Close;
end;
procedure TForm_init.Cheltuielieconomiiprivindimpozitulpevenit1Click(
Sender: TObject);
begin
if (_an_prec_l=0) or (_an_gest_l=0)
then begin
ShowMessage('Nu ati introdus perioada de gestiune.');
Exit;
end;
Form_chelt_imp_ven.Show;
Form_chelt_imp_ven.E_cc_an_prec.text:='0';
Form_chelt_imp_ven.E_cc_an_gest.text:='0';
Form_chelt_imp_ven.E_ca_an_prec.text:='0';
Form_chelt_imp_ven.E_ca_an_gest.text:='0';
DM_table.T_an_rfirm.Append;
end;
procedure TForm_init.Grafice1Click(Sender: TObject);
begin
Form_rap_fin.Show;
end;
procedure TForm_init.Tabelar1Click(Sender: TObject);
begin
Form_rf.QRL_an_prec.Caption:=_an_prec;
Form_rf.QRL_an_gest.Caption:=_an_gest;
Form_rf.QR_rf.preview;
end;
….
end.
{––––-secvența programului Parolii de acces––––––}
unit Unit_par_aces;
interface
uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,
Buttons, Messages, Dialogs;
type
TPasswordDlg_ac = class(TForm)
Label1: TLabel;
Password_ac: TEdit;
OKBtn: TButton;
CancelBtn: TButton;
procedure OKBtnClick(Sender: TObject);
procedure CancelBtnClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
PasswordDlg_ac: TPasswordDlg_ac;
implementation
uses Unit_par_f, Unit_init;
{$R *.DFM}
procedure TPasswordDlg_ac.OKBtnClick(Sender: TObject);
begin
if Password_ac.text='costano' Then
// begin
PasswordDlg_f.Show
// PasswordDlg_ac.Close;
// end;
else begin
ShowMessage('Nu ati introdus corect parola de acces. Incercati din nou' );
Exit;
end;
end;
procedure TPasswordDlg_ac.CancelBtnClick(Sender: TObject);
begin
PasswordDlg_ac.Visible:=false;
Form_init.Close;
end;
end.
unit Unit_par_f;
interface
uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,
Buttons;
type
TPasswordDlg_f = class(TForm)
Label1: TLabel;
Password_f: TEdit;
OKBtn: TButton;
CancelBtn: TButton;
procedure OKBtnClick(Sender: TObject);
procedure CancelBtnClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
PasswordDlg_f: TPasswordDlg_f;
implementation
uses Unit_datamod, Unit_init;
{$R *.DFM}
procedure TPasswordDlg_f.OKBtnClick(Sender: TObject);
begin
if Password_f.text=DM_table.T_firma.Lookup('Denum_firm',Password_f.text,'Denum_firm')
then begin
Form_init.File2.Visible:=false;
Form_init.Perioadadegestiune1.Visible:=true;
Form_init.Registru1.Visible:=true;
Form_init.Raport1.Visible:=true;
Form_init.Pro1.Visible:=true;
PasswordDlg_f.Visible:=false;
end
else begin
Form_init.File2.Visible:=true;
Form_init.Perioadadegestiune1.Visible:=true;
Form_init.Registru1.Visible:=true;
Form_init.Raport1.Visible:=true;
Form_init.Pro1.Visible:=true;
PasswordDLG_f.Visible:=false;
end;
end;
procedure TPasswordDlg_f.CancelBtnClick(Sender: TObject);
begin
PasswordDlg_f.Visible:=false;
Form_init.Close;
end;
end.
Anexa 4
Schema structurală a programului „client”
Anexa 5
Schema-bloc a programului „client”
Anexa 6
Diagrama interacțiunii formelor programului “client”
Anexa 7
Graful-rețea pentru elaborarea SI „Activitatea și prognozarea situației financiare a unei firme private”
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Elaborarea Sistemului Informarional Activitatea Si Prognozarea Situatiei Financiare a Unei Firme Private (ID: 148809)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.