Proiectatrea Bazei de Date a Centrului de Cercetari Stiintifice

CUPRINS

INTRODUCERE

Secolul care tocmai s-a încheiat a adus saltul cel mai spectaculos în progresul tehnico-științific. Deși realizările științei sunt foarte diverse și deosebit de importante, câteva descoperiri pot fi remarcate ca fiind excepționale. Printre acestea putem numi, fără rezerve, și inventarea calculatorului. Anume această descoperire fantastică a impulsionat radical dezvoltarea societății.

Astăzi, activitatea omului nici nu poate fi imaginată fără de utilizarea calculatorului, iar introducerea sistemelor informaționale în diferite domenii de activitate a oamenilor se examinează ca o direcție prioritară a progresului tehnic, cu scopul de a susține și de a intensifica procesul de activitate a oamenilor. Actual sistemele informaționale sunt parte componentă a instituțiilor de administrare, producere, realizare, cercetări științifice, etc.

Un sistem informațional este realizat cu ajutorul tehnologiilor informaționale (software), conține cunoștințele formalizate ale utilizatorilor și participă la rezolvarea sarcinilor de prelucrare a informației. Baza de date reprezintă elementul principal al tuturor sistemelor informaționale, care îndeplinește funcția de nucleu a sistemului. Structura bazei de date este determinată de genul de activitate și evidențele activității respective, deoarece ea este o totalitate de evidențe, care sunt unite într-un sistem unic integru, după o logică bine determinată, folosită de o multitudine de utilizatori. O bază de date care nu are, însă, asociat un sistem de gestiune al acesteia, nu are sens, ea nu-și atinge obiectivele pentru care a fost creată.

Deși SGBD-urile moderne se caracterizează printr-o flexibilitate sporită vis-a-vis de reproiectarea bazelor de date, se impune o analiză și o planificare minuțioasă a obiectivelor bazei de date proiectate, a structurilor de date și a relațiilor dintre ele. Orice modificare ale denumirilor, tipurilor și dimensiunilor câmpurilor tabelelor bazei de date necesită modificări în clasele de obiecte care utilizează câmpurile respective, lucru greu de realizat în cazul bazelor de date de proporții. De asemenea, proiectarea nereușită a tabelelor și a relațiilor dintre ele pot avea consecințe nedorite în cazul efectuării unor modificări în structura lor. Cu alte cuvinte, este mult mai rațional să depunem anumite eforturi în faza de proiectare, decât să redresăm ulterior o bază de date prost proiectată [3].

Deci, automatizarea procesului de evidență în sistemul Academiei de Poliție și formarea Sistemului Informațional al Academiei de Poliție necesită, în primul rând, o proiectare și planificare bine determinată.

Structura sistemului informațional este determinată, în mare parte, de structura bazelor de date, iar structura bazelor de date este determinat de genul de activitate a subdiviziunilor Academiei de Poliție și evidențele determinate de această activitate. Reieșind din acest fapt, structura Bazei Centrale de Date (BCD) v-a avea în componența sa mai multe baze de date.

În lucrarea de față este proiectată baza de date a Centrului de cercetări științifice, subdiviziune care dirijează activitatea științifică din cadrul Academiei de Poliție. De asemenea, este elaborat și un sistem informatic care va facilita realizarea operațiilor de actualizare și extragere a datelor din baza de date respectivă. Altfel spus, în lucrarea dată este elaborat sistemul informatic de evidență a activității științifice în Academia de Poliție.

Baza de date a sistemului științific va reflecta: evidența publicaților științifice ale colaboratorilor Academiei; evidența activităților științifice organizate de Academie sau la care a luat parte reprezentanți ai Academiei; titlurile științifico-didactice și gradele științifice ale colaboratorilor Academiei etc.

Astăzi teoria bazelor de date relaționale este un fundament real pentru construirea sistemelor informatice eficiente. Modelul relațional este caracterizat printr-un mare avantaj, și anume: „utilizatorii sunt protejați de cunoașterea reprezentării interne a datelor. Activitățile utilizatorilor la terminale și majoritatea aplicațiilor trebuie să rămână intacte, dacă reprezentarea internă este modificată…”[1]. Din această cauză, în lucrare, la proiectarea bazei de date s-a utilizat modelul relațional și baza de date proiectată este relațională.

Întreg sistemul informatic al Academiei se elaborează în limbajul Delphi. Din această cauză și subsistemul informatic din teză este în limbajul de programare Delphi 5. limbajul Delphi prezintă o combinație a câtorva tehnologii extrem de importante: un compilator cu o eficiență înaltă, modelul componentelor bazată pe tehnologia orientării pe obiecte, arhitectură vizuală a aplicațiilor din programele prototip.

Lucrarea conține șase capitole. În primul capitol sunt descrise aspectele generale ale sistemelor informaționale: noțiuni, caracteristici, obiective, funcții. Al doilea capitol descrie elementele de bază ale teoriei bazelor de date: structuri de date conceptuale, modele de date, modelul relațional, constrângeri de integritate asupra datelor. În al treilea capitol sunt descrise etapele de proiectare a bazelor de date, normalizarea bazelor de date. Descrierea sistemului informatic elaborat în lucrarea dată – datele despre activitatea științifică din Academie, proiectarea bazei de date, normalizarea (prin metoda de sinteză), descrierea funcționării programului – este făcută în capitolul patru. Capitolul cinci și șase descriu evaluarea economică a sistemului și protecția muncii a omului în timpul lucrului la calculator.

1. SISTEMUL INFORMATIC: GENERALITĂȚI

1.1. Noțiuni

Introducerea sistemelor informaționale (automatizate) în diferite domenii de activitate a oamenilor se examinează ca o direcție prioritară a progresului tehnic în direcția susținerii și intensificării procesului de activitate a oamenilor. Actual sistemele informaționale sunt parte componentă a instituțiilor de administrare, producere, realizare, cercetări științifice, etc.

La proiectarea și formarea sistemelor informaționale e necesar de a lua în considerație principiile de proiectare, ideile fundamentale, care stau la baza proiectării sistemelor respective, respectarea tehnologiilor principale a sistemelor intelectuale. E necesar de luat în considerație un factor foarte important – factorul uman, interesele și capacitățile oamenilor ce lucrează și dirijează cu sistemele respective. Destul de important este momentul de acumulare, prelucrare, analiză și păstrare a informației.

Dacă încercăm să dăm o definiție mai generală a sistemelor informaționale, atunci am putea spune că:

Orice sistemă aplicată, realizată cu ajutorul tehnologiilor informaționale, este un sistem informațional intelectual, ce conține cunoștințele formalizate ale utilizatorilor și, cu drept de partener, participă la rezolvarea sarcinilor de prelucrare a informației.

Arhitectura sistemului informatic evidențiază componentele acestuia. Ținând seama de faptul că există, totuși, diferite tipuri de sisteme informaționale, am putea spune că ele se diferențiază prin limbajele utilizate, prin anumite componente ce imprimă diferite facilități de exploatare a bazei de date, prin faptul că unele oferă posibilitatea lucrului în regim de teleprelucrare, altele numai în regim local, iar altele atât în regim local cât și în regim de teleprelucrare, nu poate fi dată o arhitectură unică, valabilă pentru toate sistemele, ci apar particularități de la un sistem la altul. Totuși o arhitectură generală ar cuprinde următoarele componente:

baza de date propriu-zisă în care se memorează colecția de date;

sistemul de gestiune al bazei de date, care este un ansamblu de programe (soft) care realizează gestiunea și prelucrarea complexă a datelor;

un set de proceduri manuale și automate, precum și reglementările administrative, destinate bunei funcționări a întregului sistem;

un dicționar al bazei de date, ce conține informații despre date, structura acestora, elemente

descriere a semanticii, statistici, documentație etc.;

mijloacele hard utilizate (comune, specializate etc.);

personalul implicat: categorii de utilizatori (finali, neinformaticieni), de specialitate (administrator), analiști-programatori, gestionari, operatori.

Deci, elementul principal al tuturor sistemelor informaționale este, baza de date, care îndeplinește funcția de nucleu a sistemului. Structura bazei de date este determinată de genul de activitate și evidențele activității respective. Reieșind din acest fapt putem spune că baza de date este o totalitate de evidențe, care sunt unite într-un sistem unic integru, după o logică bine determinată, folosită de o multitudine de utilizatori. O bază de date care nu are, însă, asociat un sistem de gestiune al acesteia, nu are sens, ea nu-și atinge obiectivele pentru care a fost creată.

Sistemul de gestiune al bazelor de date reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activități [3]:

definirea structurii bazei de date;

încărcarea datelor în baza de date;

accesul la date (interogare, actualizare);

întreținerea bazei de date (colectarea și refolosirea spațiilor goale, refacerea bazei de date în cazul unui incident);

reorganizarea bazei de date (restructurarea și modificarea strategiei de acces);

securitatea datelor.

Așa dar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigură interfața între o bază de date și utilizatorii acestuia.

În sens mai larg, sistemul de gestiune a bazelor de date este o componentă activă, ce interacționează cu toate celelalte componente, cu toate categoriile de personal implicat în funcționarea sistemului.

1.2. Caracteristici

Orice sistem informațional intelectual are unele caracteristici principale, care se bazează pe particularitățile de interacțiune comunicativă a omului cu sistemul, și anume:

Accesibilitatea – se determină în dependență de numărul de utilizatori de diferite tipuri; universalitatea sistemului, gradul de deservire concomitentă a sistemului.

Comoditatea utilizatorilor în activitatea cu sistemul informațional (interpelări, analiză, control) care se determină de gradul de îndestulare a necesităților în procesul de comunicare cu mijloacele tehnice, programice și alte tehnologii informaționale; minimizarea timpului de reacție a sistemului la comunicarea utilizatorului; reacția prietenoasă a sistemului la acțiunile nereușite ale utilizatorului.

Calitatea funcționării sistemului informațional se determină ca înțelegerea corectă și realizarea scopului utilizatorului în procesul activității.

Operativitatea sistemului informațional, care se determină în dependență de timpul sumar, consumat în procesul interacțiunii, pregătire și finisare a lui.

Adaptabilitatea sistemului informațional se determină de posibilitățile de a schimba structura internă a sistemului, adaptarea lui la posibilitățile omului-utilizator, precum și schimbarea caracteristicilor sistemului care sunt determinate de domeniul pentru care a fost preconizat.

Siguranța sistemului în urma interacțiunii cu utilizatorii este una din caracteristicile importante, care se apreciază ținând cont de dezvoltarea procesului informațional la diferite etape: pregătirea de interacțiune; transmiterea și sesizarea informației; interpretarea, realizarea diferitor acțiuni, înțelegerea și interpretarea de către utilizator a acțiunilor sistemului intelectual.

Securitatea sistemului informațional se caracterizează de gradul de apărare a sistemului de accesul nesancționat a utilizatorului la diferite categorii și niveluri de informații.

1.3. Obiective

După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea, transmiterea, stocarea și prelucrarea automată a datelor cu ajutorul mijloacelor electronice de calcul, în scopul satisfacerii diferitelor nivele de conducere cu informații necesare luării deciziilor, în condiții de eficiență economică sporită.

În aceste condiții, necesitatea acută de inută de informare trebuie satisfăcută ținând seama de o serie de cerințe prin care să se asigure: minimizarea costului procesului de prelucrare a datelor; creșterea vitezei de răspuns la întrebările solicitate de utilizatori; adaptarea facilă a sistemului informatic la evoluția în timp a sistemului informațional din care face parte; posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanții de sistem; posibilitatea folosirii sistemului de informare dispunând de un minim de cunoștințe despre modul de organizare a lui în general și informatică în special, integritatea și securitatea datelor etc. [3].

În acest context, nu poate fi proiectat și creat un sistem informațional fără a ține cont de obiectivele creării sistemului cum sunt:

Analiza datelor, presupune analiza domeniului în care va fi creată și utilizată baza de date; specificarea caracterului și volumului informației care se va conține în baza de date și modul ei de utilizare; care vor fi (în linii mai) datele de ieșire; posibilitatea reprezentării datelor sub diferite aspecte.

Asigurarea independenței datelor. O aplicație, în general, este dependentă de date în sensul că modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează și aplicația. Independența datelor față de aplicație este totuși necesară cel puțin din următoarele considerente: diferite aplicații au nevoie de viziuni diferite ale acelorași date; administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de acces, ca răspuns la cerințe (schimbări de standarde, prioritățile aplicațiilor, unitățile de memorare etc.), fără a modifica aplicațiile existente, baza de date existentă, precum și programele de exploatare a ei, care au fost folosite o perioadă de timp, reprezintă o investiție majoră la care nu trebuie să se renunțe prea ușor.

De aceea, se impune ca atunci când apar noi cerințe în cadrul sistemului informațional, sistemele informatice să poată funcționa cu programele și procedurile existente, iar datele existente să poată fi convertite. Deci, modificările care se fac la nivel de structură de date nu trebuie să modifice programele de aplicație.

Independența datelor trebuie privită din două puncte de vedere: independența fizică și independența logică a datelor. Independența fizică a datelor face ca memorarea datelor și tehnicile fizice de memorare să poată fi modificate fără a determina rescrierea programelor de aplicație. Independența logică a datelor se referă la posibilitatea adăugării de noi articole de date sau extinderea structurii conceptuale, fără ca aceasta să impună rescrierea programelor existente.

Asigurarea unei redundanțe minime și controlate a datelor. Spre deosebire de sistemele clasice de prelucrare automată a datelor, stocarea datelor în cazul bazelor de date se face astfel încât fiecare dată să apară o singură dată. Totuși, nu sunt excluse nici cazurile în care, pentru a realiza performanțe sporite, referitoare la timpul de acces la date și răspuns la solicitările utilizatorilor, să se accepte o anumită redundanță a datelor, însă în acest caz se va institui un control automat asupra ei în vederea asigurării coerenței datelor în bază.

Asigurarea unor facilități sporite de utilizare a datelor. Aceasta presupune: folosirea datelor de către mai mulți utilizatori în diferite scopuri (aplicații); accesul cât mai simplu al utilizatorilor la date, fără ca aceștia să fie nevoiți să cunoască structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei de date; existența unor limbaje performante de regăsire a datelor, care permit exprimarea sub forma unei conversații, a unor criterii de selecție a datelor și indicarea unor reguli cât mai generale pentru editarea informațiilor solicitate; spre deosebire de sistemul clasic de prelucrare pe fișiere, unde exista un singur criteriu de adresare, în cazul bazelor de date sistemul trebuie să ofere posibilitatea unui acces multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la fișierele clasice implică și reorganizarea lor; utilizarea unui limbaj cât mai aproape de limbajul natural, cu posibilitatea exploatării bazei de date în regim conversațional. Aceasta ar oferi posibilitatea exploatării în mod facil a bazei de date și de către utilizatorii neinformaticieni.

Asigurarea integrității informației împotriva unor ștergeri intenționate sau neintenționate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent și a unor proceduri de refacere a bazei de date după incidente.

Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. În condițiile bazelor de date, administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai prin canale corespunzătoare și poate, totodată, defini, verificări de autorizare realizate oricând se încearcă accesul la anumite date.

Asigurarea partajabilității datelor. Partajabilitatea datelor trebuie înțeleasă nu numai sub aspectul asigurării mai multor utilizatori la aceleași date, ci și acela al extinderii și modificării bazei de date cu eforturi minime, al posibilității dezvoltării unor aplicații fără a se modifica structura bazei de date.

Din obiectivele descrise mai sus, rezultă că un sistem informatic este un set de programe, care facilitează și supraveghează introducerea de informații în baza de date, actualizarea și extragerea datelor din bază, controlul și autorizarea accesului la date.

1.4. Funcții

Pentru realizarea obiectivelor enumerate mai sus, sistemele informatice dispun de o serie de componente ce permit efectuarea numeroaselor operații. În funcție de natura lor și scopul urmărit, operațiile pot fi gripate pe activități. Activitățile acceptă și ele o grupare pe funcții.

Ținând seama de multitudinea sarcinilor ce revin unui sistem și grupând aceste sarcini pe activități și apoi pe funcții, se deduc, în final, funcțiile sistemului informatic. Ținând seama de complexitatea sistemului, de facilitățile propuse a fi oferite de acesta, de limbajele utilizate și tipul bazei de date ce urmează a fi gestionată, gruparea activităților pe funcții are un caracter relativ, depinzând de sistemul informatic concret.

Funcțiile pe care un sistem informațional generalizat trebuie să fie capabil să le îndeplinească, sunt:

Funcția de descriere a datelor, care rezidă în definirea structurii datelor, a relațiilor dintre acestea și a condițiilor de acces la informațiile conținute în baza de date. La nivelul acestei funcții se descriu multitudinea atributelor (câmpurilor) din cadrul structurii bazei de date, legăturile dintre entitățile bazei de date sau dintre atributele aceleeași entități, se definesc eventualele criterii de validare a datelor, metodele de acces la date, aspectele referitoare la asigurarea integrității și confidențialității datelor etc. Rezultatul acestei funcții se va concretiza în schema bazei de date, memorarea în cod intern.

Funcția de manipulare a datelor este cea mai complexă funcție și realizează următoarele activități: crearea (încărcarea) bazei de date; actualizarea bazei de date, care presupune înserarea, adăugarea de noi înregistrări, tupluri, suprimarea unor înregistrări și redactarea informației, adică modificarea valorilor corespunzătoare unor câmpuri; interogarea bazei de date, care permite obținerea diferitor informații din baza de date conform unor criterii de căutare, sortarea și editarea parțială sau totală a unei înregistrări virtuale; obținerea datelor noi, care constă în prelucrarea informației inițiale în scopul obținerii unor totaluri, medii etc.

Funcția de utilizare asigură mulțimea interfețelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. În cadrul realizării acestei funcții, apar mai multe categorii de utilizatori: utilizatori liberi sau convenționali, care reprezintă categoria beneficiarilor de informații care utilizează limbajele de interogare a bazei de date într-o formă simplistă. Ei apar ca utilizatori neinformaticieni; utilizatori programatori, care utilizează limbajele de manipulare, realizând proceduri complexe de exploatare a bazei de date; administratorul bazei de date apare ca un utilizator special și are rolul hăotărâtor ăîn ceea ce privește funcționarea optimă a întregului ansamblu.

Funcția de întreținere, administrare a bazei de date, care constă în crearea copiilor de rezervă, compactarea bazei de date și repararea ei în cazul deteriorării. Este o funcție complexă și este de competența administratorului bazei de date.

De securitate a datelor, care rezidă în protejarea bazei de date împotriva accesului neautorizat și atribuirea drepturilor de acces pentru utilizatori în cazul utilizării bazei de date într-o rețea.

2. ELEMENTE ALE TEORIEI BAZELOR DE DATE

2.1. Scurt istoric

Evoluția metodelor și tehnicilor de organizare a datelor a fost determinată de necesitatea de a avea un acces cât mai rapid și ușor la un volum din ce în ce mai mare de informații precum și de perfecționarea echipamentelor de culegere, memorare, transmitere și prelucrare a datelor.

Conceptul de bază de date a apărut în 1969 cu ocazia prezentării primului raport CODASYL (în cadrul unei conferințe pe probleme de limbaje de gestiune a datelor). Ideea principală în organizarea datelor se baza pe existența unui fișier de descriere globală a datelor prin care realiza independența programelor față de date și a datelor față de programe. Accesul oricărui utilizator la baza de date se realiza prin intermediul unui fișier de descriere globală a datelor. Fișierul de date conținea colecții de date și legăturile dintre ele.

Ulterior, acest concept a fost dezvoltat luând forma de baze de date rețea, baze de date relaționale sau baze de date orientat pe obiecte.

În esență, conceptul de bază de date poate fi definit ca fiind una sau mai multe colecții de date (K1) aflate în interdependență, împreună cu descrierea datelor și a relațiilor dintre ele, B={K1, K2,…}.

Baza de date astfel definită trebuie să îndeplinească următoarele condiții: să asigure o interdependență sporită a datelor față de programe și invers; structura bazei de date trebuie astfel concepută încât să asigure informațiile necesare și suficiente pentru cerințele de informare și decizie; să se asigure o redundanță minimă și controlată a datelor; să permită accesul rapid la informațiile stocate în bază.

Pe plan internațional există mai multe grupuri specializate în standardizarea conceptelor ce apar în dezvoltarea bazelor de date, cele mai importante fiind DBTG, CODASYL, ANSI/X3/SPARC, grupul IBM.

Bazele de date sunt extrem de variate în funcție de criteriile luate în considerare:

după orientare: generalizate, specializate;

după modelul de date: ierarhice, rețele, relaționale, orientate obiect;

după amploarea geografică: locale, distribuite.

O bază de date poate fi structurate pe trei niveluri, în funcție de clasa utilizatorilor implicați:

nivelul logic. Este dat de viziunea programatorului de aplicații, care realizează programele de aplicații pentru manipularea datelor și structura logică corespunzătoare descrierii datelor aplicației;

nivelul conceptual (global). Este dat de viziunea administratorului bazei de date, care realizează structura conceptuală corespunzătoare descrierii bazei de date și administrează componentele bazei de date pentru manipularea datelor;

nivelul fizic. Este dat de viziunea inginerului de sistem care realizează structura fizică corespunzătoare descrierii datelor pe suportul fizic (periferic).

2.2. Structuri de date conceptuale

Înainte de a defini noțiunea de date, să ne închipuim următoarea situație abstractă: există un oarecare sistem, informația despre starea căruia prezintă interes și observatorul este capabil să perceapă starea sistemului și să o fixeze într-o formă anumită în memoria sa (nici un alt gen de acțiuni observatorul nu întreprinde). În calitate de astfel de “observator”, în general, se prezintă sistemele informaționale.

Astfel, datele pot fi definite ca informație fixată într-o formă bine determinată, utilă pentru prelucrarea, păstrarea și transmiterea ulterioară.

Organizarea datelor ocupă un loc important în proiectarea sistemelor informatice. De modul în care sunt organizate datele depinde eficiența sistemului informatic.

Organizarea datelor presupune:

definirea, structurarea, ordonarea și gruparea datelor în colecții de date omogene;

stabilirea legăturilor (relațiilor) între date, între elementele unei colecții, între colecțiile de date;

reprezentarea (stocarea) lor pe suport informațional, prelucrabil într-un sistem de calcul.

Scopul organizării datelor îl constituie regăsirea automată a datelor după diverse criterii și forme. Obiectivele urmărite în organizarea datelor sunt:

timpul de acces la datele organizate pe diferite suporturi de date să fie minim (acces rapid la date);

spațiul de memorie internă și externă ocupat de date să fie cât mai redus (economie de memorie internă și externă);

datele să apară o singură dată în sistem (unicitatea datelor), totuși se impune, uneori, acceptarea unei redundanțe minime a datelor;

în sistemul de organizare a datelor să se reflecte, pe cât posibil, toate legăturile dintre obiectele, fenomenele, procesele economice pe care aceste date le reprezintă;

să permită schimbarea structurii datelor și a relațiilor dintre ele fără a modifica programele ce le gestionează (flexibilitatea datelor).

Cele trei concepte de bază utilizate în organizarea datelor sunt: entitate, atribut, valoare. Aceste concepte sunt legate între ele: o entitate are mai multe atribute, iar atributelor li se asociază o mulțime de valori.

Prin entitate se înțelege un obiect concret sau abstract reprezentat prin proprietățile sale. Orice proprietate a unui obiect poate fi exprimată printr-o pereche (ATRIBUT, VALOARE), o entitate se poate exprima prin mai multe proprietăți, deci mai multe perechi de forma (ATRIBUT, VALOARE). De exemplu, o publicație științifică poate fi prezentată prin mulțimea de perechi: (TITLUL, ISTORIA POLIȚIEI REPUBLICII MOLDOVA), (FORMĂ, MONOGRAFIE), (ANUL EDIȚIEI, 2000), (TIPOGRAFIA, CENTRALĂ). În realitate mulțimea atributelor TITLUL, FORMĂ, ANUL EDIȚIEI, TIPOGRAFIA poate fi asociată mai multor publicații științifice. Rezultă că atributul nu caracterizează doar o entitate, ci poate caracteriza o clasă de entități numită entitate grup. În exemplul de mai sus, entitate grup s-ar putea numi PUBLICAȚII. Deoarece toate elementele unei entități grup se caracterizează prin aceeași mulțime de atribute, se poate spune că entitățile din cadrul unei entități grup sunt de același tip. În acest sens se utilizează termenul de tip de entități pentru o clasă de entități.

Pentru fiecare entitate trebuie de stabilit un identificator care va servi într-un singur sens pentru constatarea exemplarelor entității. În calitate de identificator poate servi un atribut sau o totalitate atributelor. În acest caz atributul de identificare este un atribut compus, completul de valori ale căruia se află într-o corespondență univocă cu exemplarele entității.

În sistemele de prelucrare a datelor atributul sau totalitatea atributelor, valorile cărora unic determină fiecare obiect din mulțimea de obiecte se numește cheie. În sistemele de prelucrare a datelor se folosește următoarea ipoteză: descrierea fiecărui obiect diferă de descrierea altor obiecte. În conformitate cu aceasta, fiecare set de obiecte posedă cheie.

Pentru descrierea setului de obiecte este aleasă o totalitate de atribute ce nu conțin cheie, atunci în componența atributelor se include un atribut special care joacă rolul de cheie. În majoritatea cazurilor această cheie este un număr succesiv.

Un și același set de obiecte poate avea câteva chei. Una din ele se stabilește ca cheie primară a setului de obiecte și servește în continuare drept cheie ce corespunde acestui set de obiecte, mai fiind numită și cheie a înregistrării sau cortegiului.

Alegerea cheii este un moment important în proiectarea modelului de date. Aceasta se datorează faptului, că pe de o parte, cheia trebuie să îndeplinească funcția sa principală — de identificare, iar pe de alta — să conțină un număr minim necesar de atribute pentru îndeplinirea funcției date.

Cheie compusă se numește cheia ce constă din două sau mai multe chei.

Noțiunea de atribut este cunoscută și sub denumirea de câmp. Fiecare atribut e caracterizat de natura valorilor pe care le poate lua. Astfel, un atribut este de tip numeric dacă valorile sale sunt numerice, alfanumeric dacă valorile sale sunt șiruri de caractere, etc. În general, un atribut are valori elementare, dar pot exista și situații de atribute compuse (formate prin concatinarea mai multor atribute). Pot exista atribute ce identifică în mod unic o entitate, ele numindu-se atribute cheie.

Deci, data este un model de reprezentare a informației, accesibil unui anumit procesor (om, program, calculator); cu acest model se operează pentru a obține noi informații despre fenomenele și procesele lumii reale.

Din punct de vedere logic, o dată se definește prin: identificator, atribut și valoare. Din punct de vedere fizic, unei date îi corespunde o zonă de memorie de o anumită mărime, situată la o adresă absolută.

2.3. Modele de date

Pentru cunoașterea realității înconjurătoare și prelucrarea datelor cu ajutorul calculatorului este necesară modelarea acestei realități. Definirea unui model de date presupune precizarea și identificarea structurii modelului, operatorii care acționează asupra structurilor de date, restricțiile pentru menținerea corectitudinii datelor, numite și reguli de integritate.

Descrierea structurii modelului presupune definirea entităților și a caracteristicilor asociate. Aceasta se realizează utilizând câmpul (ca fiind cel mai mic element al structurii care poate fi identificat în scopul prelucrării), grupul simplu sau compus (este un set format din mai multe câmpuri și/sau grupuri) și înregistrarea (este un ansamblu de câmpuri și grupuri, constituind totodată și elementul generic al structurii).

Operatorii care acționează asupra structurilor de date reprezintă cel de al doilea element al unui model de date. Acești operatori pot fi de citire, memorare, modificare, joncțiune etc.

Regulile de integritate, sunt restricții menite să asigure menținerea corectitudinii datelor. Exemple de astfel de restricții pot servi: să nu se accepte memorarea valorilor asociate caracteristicilor unei publicații dacă nu se cunoaște valoarea cheii ei (COD pentru entitatea PUBLICAȚIE și COD pentru entitatea AUTOR); să nu se permită ștergerea valorilor atributelor dacă nu au fot îndeplinite anumite condiții etc.[3].

În funcție de modul în care se definesc elementele amintite, modelele de date se împart în[3]:

Modele ierarhice sau arborescente – are ca structură de bază tipuri de înregistrări care grupează toate atributele unei entități. Pentru realizarea asocierilor (relațiilor, legăturilor) dintre tipuri de înregistrări, acest model introduce un nou tip de structură: ierarhia.

O ierarhie are un tip de înregistrare definit ca rădăcină și mai multe tipuri de înregistrări subordonate, legate sub formă de arbore. Fiecare nod din arbore care ne e rădăcină sau nod final are un singur nod superior și unul sau mai multe noduri inferioare. Modelul ierarhic pune la dispoziție două structuri: tipuri de înregistrare și ierarhia.

Modele rețea – în care datele sunt repartizate asemănător cu modelul ierarhic, cu deosebirea că fiecare inferior poate avea mai mulți superiori. Toate structurile de date, inclusiv legăturile sunt definite natural, fără a recurge la artificii. În cadrul acestui model, întâlnim două structuri: tipul de înregistrare (care asigură atributele unei entități) și tipul de set (care asigură legăturile între tipurile de înregistrare).

Modele relaționale – are la bază teoria matematică a relațiilor. Are o singură structură de date: relația (tabelul), o submulțime a produsului cartezian al unor domenii, mulțimi de valori ale entităților. Un astfel de model poate fi privit ca o mulțime de tabele obținute prin metoda normalizării. Normalizarea pleacă de la o mulțime de atribute (câmpuri de date) și o mulțime de dependențe funcționale dintre atribute și conduce la o schemă conceptuală a modelului relațional într-o formă normalizată în care se vor elimina anomaliile de actualizări.

Modele orientate obiect – sunt niște modele distribuite care se bazează pe primele trei modele, dar cu particularitățile legate de distribuirea geografică a datelor.

În ultimii ani se utilizează practic doar modelul relațional, datorită avantajelor față de celelalte modele.

2.4. Modelul relațional

Modelul relațional este în prezent cel mai răspândit model, care are la bază teoria matematică a relațiilor. Ca și orice alt model de date utilizat în proiectarea logică a bazelor de date eliberează utilizatorul de cunoașterea detaliilor despre structura fizică și metodele de acces la date.

Are o singură structură de date: relația (tabelul), o submulțime a produsului cartezian al unor domenii. Un astfel de model poate fi privit ca o mulțime de tabele obținute prin metoda normalizării. Normalizarea pleacă de la o mulțime de atribute (câmpuri de date) și o mulțime de dependențe funcționale dintre ele, și conduce la o schemă concepută a modelului relațional într-o formă normalizată în care se vor elimina anomaliile de date.

Modelul relațional al datelor a fost primit cu entuziasm și acceptat aproape fără rezerve atât de specialiști din domeniul bazelor de date, cât și de utilizatori, încă de la apariția primelor articole ale lui Codd E.F., în 1970, prin care erau puse bazele acestui model. Ideea unui model asamblist al datelor a fost lansată în 1968 de către Childs D.F. care a subliniat faptul că orice structură de date poate fi reprezentată printr-una sau mai multe tabele de date, în cadrul cărora este necesar să existe și informații de legătură, pentru asigurarea legăturilor între tabele. Codd are meritul de a fi articulat și dezvoltat ideile cu privire la utilizarea teoriei apartenenței la ansambluri sub forma unui model coerent de structurare a datelor – model relațional.

În prezent numărul sistemelor care apar sub eticheta de „relațional” sau care sunt prezentate cu ajutorul conceptelor relaționale este foarte mare. S-a constat că prin utilizarea sistemelor relaționale este posibilă atingerea unor obiecte importante ale organizării datelor de baze de date și anume: asigurarea unei mai mari independențe a programelor de aplicație față de organizarea datelor, utilizarea unor puternice limbaje de manipulare a datelor, a unor instrumente eficace de control a coerenței și redundanței datelor etc. [2]

Atribute și domenii.

Fie U o mulțime nevidă de elemente A1, A2,…An, numite atribute. Mulțimea U={ A1, A2,…An } se numește universul unei baze de date relaționale sau mulțime universală.

Domeniul unui atribut Ai din U, 1<i<n, notat cu dom(Ai), este o mulțime finită de valori de același tip care le poate primi atributul Ai.

În modelul relațional fiecare tabel se spune că reprezintă o relație. Atributele sunt niște identificatori pentru a diferenția și a marca colanele tabelului. Deci câmpul sau numele de coloană e și atribut. Toate atributele ce apar într-un tabel trebuie să fie incluse în universul U. Atributele au un caracter global în baza de date: dacă un nume denotă două colane în tabele distincte în aceeași bază de date, atunci el reprezintă același atribut.

Tupluri

Fie R o submulțime a universului U, RU, unde R≠Ø și fie dom (R) domeniul mulțimii R. Tuplu se numește o funcție, t:R→dom (R), din R în dom (R), adică t = {(Ai1, a1),…, (Aik, ak)}, unde orice Aij, 1≤j≤k, este un atribut în R și un argument al lui t, iar orice aj, 1≤j≤k, este o valoare în dom (Aij). t(Aij)=aj pentru aj Є dom (Aj).

Pentru comoditate notațională, un tuplu cu numele t și schema R e va nota ca t(R)=t(Ai1) t(Ai2)… t(Aik).

Relații și scheme

Fie R o submulțime a universului U. Relația r asupra R este o mulțime finită de tupluri cu schema R. Aritatea relației r este egală cu cardinalitatea mulțimii R (numărul de tupluri în ea).

Fie RU șirelația r asupra R. Mulțimea de atribute R se numește schema relației r.

Putem spune că relația se compune din două părți:

– antetul relației – mulțimea de atribute definite fiecare pe câte un domeniu de valori.;

– corpul relației – mulțimea de tupluri; fiecare tuplu este definit ca o mulțimi de valori ale atributelor definite în cadrul antetului.

Baza de date relațională este o mulțime finită de relații, db={r1, …, rm}, unde ri este o relație cu schema Ri, 1≤i≤m.

Fie baza de date db={r1, …, rm}. Schema bazei de date este mulțimea schemelor relațiilor ce formează baza de date, Db= {R1, …, Rm}.

Deci schema unei relații este o expresie a proprietăților comune și invariante ale tuplurilor ce compun relația. Din noțiunile date mai sus putem conchide următoarele:

Din definiția de mai sus a noțiunii de relație rezultă următoarele proprietăți:

Atributele nu sunt ordonate (ordinea lor nu este semnificativă). Această proprietate rezultă din faptul că antetul este definit ca o mulțime de atribute.

Atributele sunt distincte (chiar dacă pot exista două atribute definite pe același domeniu), deoarece elementele unei mulțimi sunt distincte;

În cadrul corpului relației tuplele nu sunt ordonate – corpul relației este definit ca o mulțime de tuple;

Orice atribut are doar valori atomice; Această proprietate poate fi enunțată și astfel:

La intersecția dintre o linie și o coloană se află întotdeauna o singură valoare, și niciodată o colecție de valori; rezultă că o relație nu conține grupuri repetitive; spunem în acest caz că relația se află în forma întâi normală;

Nu există tupluri duplicate, deoarece corpul unei relații este o mulțime de tupluri.

2.5. Constrângeri de integritate

Constrângerile de integritate, numite și restricții de integritate definesc cerințele pe care trebuie să le satisfacă datele din baza de date pentru a putea fi considerate corecte, coerente în raport cu lumea reală pe care o reflectă.

Constrângerile sunt principalul mod de integrare a semanticii datelor în cadrul modelului relațional. Mecanismele de definire și verificare a acestor restricții reprezintă instrumentele principale de control al semanticii datelor. În modelul relațional constrângerile sunt studiate mai ales sub aspectul puterii lor de modelare și al posibilității de verificare a respectării lor.

Constrângerile de integritate pot fi divizate în linii mari în două grupuri: constrângeri de comportament și dependențe între date.

Constrângerile de comportament specifică caracteristicile independente ale unui atribut (sau domeniu). Ele exprimă semantica elementelor domeniilor. De exemplu toate valorile atributului COLI DE TIPAR nu pot fi zero pentru o publicație concretă.

Al doilea tip de constrângere specifică legătura dintre atribute (sau domenii). Aici putem identifica așa-numita dependență de submulțime, când domeniul unui atribut este parte componentă a domeniului altui atribut.

Dependențe funcționale.

Unica posibilitate de determinare a dependențelor funcționale constă într-o analiză cu luare-aminte a semanticii atributelor. În aceste sens dependențele sunt, de fapt, aserțiuni despre lumea reală. Ele nu pot fi demonstrate, dar pot și trebuie să fie susținute de sistemul de gestiune a bazei de date.

Trebuie menționat că declararea dependențelor funcționale într-o bază de date este o decizie pe care o ia numai proiectantul bazei de date, iar sistemul de gestiune va susține aceste constrângeri. Grație dependențelor, există o structură mai eficientă de păstrare a datelor. Dependențele funcționale vor servi la proiectarea schemelor bazelor de date cu anumite proprietăți dezirabile[1].

Fie relația r cu schema R și X,Y R. Vom spune că dependența funcțională X→Y este validă în relația r (sau relația r satisface dependența funcțională X→Y), dacă pentru orice două tupluri din r, fie t1 și t2, din condiția că tuplurile au X-valori identice, urmează că au și Y-valori identice, adică t1[X]=t2[X] →t1[Y]=t2[Y].

Dacă X→Y e validă în r(R), vom spune că X determină funcțional Y sau, că Y e determinat funcțional de X.

Deci dependența funcțională X→Y reprezintă o restricție de integritate aplicată tuplurilor relației r(R), în sensul că oricare două tupluri din r care prezintă o aceeași valoare pentru X trebuie să prezinte o aceeași valoare pentru Y.

Partea stângă a dependenței poartă numele de determinant, iar partea dreaptă a dependenței poartă numele de determinat. Astfel, în cadrul dependenței X→Y, X este determinantul, iar Y determinatul.

Menționăm că nu ne interesează dependențele funcționale întâmplătoare, dar numai acele ce decurg din semantica atributelor. De exemplu, în relația publicații e validă și dependența funcțională AUTOR→PUBLICAȚIE. Dar ea nu reprezintă o constrângere ce reflectă lumea reală, fiindcă în realitate un autor, de regulă, scrie mai multe publicații (articole, teze științifice, monografii etc.).

Numai dependențele neîntâmplătoare, asigură integritatea semantică a bazei de date, unde operațiile de actualizare a bazei de date (adăugare, ștergere, modificare) se efectuează corect, fără pierderi sau repetări de date.

Să examinăm constrângerile legate de noțiunea de cheie a relației. Întrucât relația reprezintă o mulțime de tupluri, iar o mulțime nu poate conține elementele dublicate, relația nu poate prezenta tupluri identice. Deci tuplurile sunt unice și trebuie să existe posibilitatea identificării lor în cadrul unei relații. Identificarea unui tuplu fără a consulta toate componentele tuplului a dus la apariția noțiunii de cheie.

Fie U mulțimea univerală de atribute, RU, și R≠Ø. Mulțimea K de atribute, unde KR, se numește cheie pentru schema R (sau pentru relația cu schema R), dacă ea posedă următoarele proprietăți:

pentru orice două tupluri t1 și t2 din r avem t1[K] ≠ t2[K];

nici o submulțime K1 proprie a lui K nu posedă proprietatea (1).

Proprietatea (1), numită restricția de unicitate a cheii, permite K-valorilor să identifice în mod unic toate tuplurile dintr-o relație. Însă respectarea proprietății de unicitate poate fi complicată, dacă însăși K conține o cheie K1 și K≠K1. În acest caz, cu toate că atributele din K sunt suficiente de a atinge scopul, unele din ele nu sunt necesare, deci pot fi eliminate din cheie fără a se afecta unicitatea. Dacă, însă, K este o submulțime proprie a unei chei, atunci utilizarea a astfel de K-valori pentru căutarea datelor va descoperi tupluri ce coincid pe toate valorile atributelor din K.

Proprietatea (2) ne asigură că o cheie K constituie numai acele atribute ce sunt necesare și suficiente pentru a determina univoc pe celelalte. Cu alte cuvinte K-valorile întotdeauna asigură un grad exact de informație nici mai mult, nici mai puțin, pentru a găsi un tuplu unic într-o relație.

Mulțimea de atribute ce posedă proprietatea (1) se numește supercheie.

Deci cheia este o supercheie minimală. Orice cheie e și supercheie. Afirmația inversă nu e corectă.

Este evident că o mulțime vidă nu poate servi drept cheie a unei relații ce conține mai mult de un tuplu. Orice relație are cel puțin o cheie. La limită cheia este constituită fie dintr-un singur atribut, fie din totalitatea atributelor din schema relației respective.

Într-o relație por exista mai multe chei. Se spune în acest caz că relația posedă mai multe chei candidate. În această situație administratorul bazei de date va stabili una din cheile candidate să servească în mod efectiv la identificarea unică a tuplurilor. Ea va primi numele de cheie primară. Primare se vor numi și domeniile atributelor ce formează o cheie primară.

O cheie externă reprezintă un atribut (grup de atribute) dintr-o schemă Ri definit pe aceeași domeniu ca și cheia primară a altei scheme Rj. Relația ri se numește relație care referă, iar rj poartă numele de relație referită.

Unele atribute pot avea așa numitele valori nedefinite sau necunoscute notate cu null. Însă sunt bine cunoscute constrângerile formulate prin următoarele reguli numite reguli de actualizare (înserare, modificare și eliminare) a relațiilor:

Constrângerea entității – cheia primară a unei relații de bază nu poate conține valori null;

Constrângerea referirii – dacă atributul A al unei chei compuse a relației ri este definit pe un domeniu primar, atunci trebuie să existe o relație de bază rj cu o cheie primară B încât orice A-valoare din ri să apară în calitate de B-valoare în rj.

Constrângerea entității impune ca la înserarea unui tuplu, valoarea cheii să fie cunoscută, pentru a se putea verifica faptul că această valoare nu este deja încărcată (respectarea constrângerii de unicitate a cheii). C valori null cheia își pierde rolul de identificator de tuplu[1].

3. PROIECTAREA BAZELOR DE DATE

3.1. Noțiuni

Prin proiectarea bazei de date, se subînțelege proiectarea unei astfel de scheme care ar înlătura apariția unor anomalii în lucrul cu baza de date, asigurând totodată facilități și performanțe sporite la exploatarea ei. Anomaliile care apar în lucrul cu baza de date sunt cunoscute sun anomalii de actualizare a datelor. Ele sunt puse în legătură cu dependențele care se manifestă între atribute. O asemenea abordate a anomaliilor de actualizare permite caracterizarea riguroasă a gradului de perfecțiune a schemei bazei de date și face posibilă definirea unor tehnici formale de proiectare a unor astfel de scheme.

Prelucrarea datelor poate provoca o serie de probleme personalului responsabil de menținerea integrității datelor. Anomaliile în date cum ar fi datele dublicate sau pierderi de informații pot apărea, dacă datele nu sunt organizate într-un mod rezonabil. S-au elaborat tehnici de analiză a datelor și organizare a lor într-o structură flexibilă și stabilă.

Procesul de normalizare constă în aplicarea unui set de reguli predefinite asupra unei aranjări a datelor cu scopul reducerii structurii complexe și transformării lor în structuri mai mici și stabile ce vor facilita manipularea și menținerea datelor.

La fiecare pas o regulă este aplicată, datele pot fi restructurate și când regula este satisfăcută se spune că datele sunt într-o anumită formă normală.

Deci normalizarea este o abordare formală de analiză și grupare a datelor în structuri mai eficiente ce se pot acomoda viitoarelor actualizări. La fel, normalizarea minimizează impactul ce poate avea loc asupra aplicațiilor în procesul actualizării bazei de date.

Pentru a produce o bază de date bine proiectată de obicei se pornește de la relații nenormalizate și printr-o serie de pași se descompun structurile de date pentru a obține schema finală a bazei de date [1].

Astfel, proiectarea bazei de date presupune fixarea structurii bazei de date și a metodelor de prelucrare a datelor, spre deosebire de utilizarea doar a informațiilor stocate în baza de date la un moment dat. Dacă în mod obișnuit, baza de date își schimbă frecvent conținutul, structura ei rămâne nemodificată pe lungi perioade de timp.

3.2. Etapele de proiectare a bazei de date

Realizarea unei baze de date presupune parcurgerea următoarelor etape:

3.2.1 .Analiza domeniului

Se realizează baza de date și cerințele informaționale asociate, împărțirea domeniului în domenii funcționale; studierea structurii informaționale.

La această etapă obținem aspectul infologic, care se utilizează la precăutarea întrebărilor legate de conținutul semantic al datelor, indiferent de metodele de prezentare în memoria sistemului.

La etapa proiectării infologice a sistemului informațional trebuie soluționate următoarele întrebări:

despre care obiecte sau evenimente din lumea reală este necesar de a acumula și prelucra informații în sistem;

ce caracteristici de bază și legături dintre ele trebuie luate în considerație;

clarificarea faptului ce date despre obiect sau eveniment, caracteristici și legături vor fi introduse în sistem.

În așa mod, la etapa proiectării infologice se evidențiază acea parte a lumii reale, ce determină necesitățile informaționale ale sistemului, adică subiectele.

Datele corespund faptelor înregistrate despre obiect și evenimente din lumea reală. Pentru a utiliza în viitor datele este necesar conținutul semantic al acestor date. Pentru a utiliza în continuare aceste date e necesar să cunoaștem conținutul lor semantic — semantica datelor. Iată de ce în sistemele informaționale trebuie formulate regulile interpretării semantice a datelor.

3.2.2. Modelarea viziunilor particulare

Fiecare aplicație presupune utilizarea unei părți din baza de date, folosind informațiile într-un mod determinat. Această parte de informație se numește viziune. O bază de date poate să aibă una sau mai multe viziuni. Fiecărei viziuni îi corespunde un grup de utilizatori. Pentru un grup particular se definesc tipurile de cereri de informații și modul de determinare a datelor din baza de date care formează răspunsuri la aceste cereri.

Un pas important în proiectarea bazei de date corespunzătoare unui sistem este determinarea viziunilor și claselor de utilizatori asociate lor. Acestea se stabilesc, de obicei, prin colaborarea persoanelor cu responsabilități în sistem.

Utilizarea viziunilor permite independența logică a datelor, în sensul că informațiile și programele utilizatorilor nu sunt dependente de structura logică a bazei de date, ce se poate modifica în timp prin extindere sau restructurare.

Extinderea se poate face fie prin adăugarea de noi atribute la relațiile existente în baza de date, fie prin adăugarea unor relații noi. Restructurarea presupune rearanjarea diferitelor atribute în noi relații.

Viziunile permit ca aceleași date să fie privite în mod diferit de diferiți utilizatori. Ele determină simplificarea modului de percepere al utilizatorilor prin ignorarea informațiilor care nu sunt importante pentru aplicația respectivă. Importantă este și asigurarea automată a securității datelor la care utilizatorii nu au acces.

Se stabilesc persoanele de la care urmează să fie obținute informațiile privind viziunea respectivă, ordinea în care urmează să fie intervievați, subiectele ce urmează să fie discutate ți întrebările esențiale ce trebuie puse. Se urmărește obținerea unor informații relevante pentru sistemul respectiv, concise, corecte și actuale. Viziunile trebuie să fie adaptabile, în sensul de a putea fi schimbate în funcție de necesitățile utilizatorului. Astfel, trebuie să permită adăugarea de noi componente, eliminarea unor caracteristici, definirea altor metode de reprezentare externă etc.

Având o structură generală a aplicației, cunoscând persoanele ce utilizează acea parte de sistem și informațiile de care ele au nevoie, se poate construi un model de informații pentru viziunea respectivă. Plecând de la o schiță grafică având principalele elemente, pe baza discuțiilor avute și a observării sistemului existent, se precizează detaliile și se fac corecturile necesare. Se stabilesc, de asemenea, fluxurile de resurse, diferitele legături cu exteriorul (interfețe) și limitările existente.

Modelarea viziunilor de proiect particulare finisează cu construirea modelului viziunilor particulare. Alegerea viziunii particulare depinde de dimensiunile domeniului obiectual. Pentru oportunitatea proiectării a unei viziunii particulare e de dorit ca utilizarea a 6-7 tipuri de entități. Deseori viziunile particulare corespund unei aplicații externe separate. De exemplu, separat unei probleme funcționale sau individual unui utilizator. Însă poate corespunde și unei întregi baze de date independente care este utilizată de către mai mulți utilizatori.

La alegerea domeniului pentru viziunea particulară proiectantul caută o soluție de compromis, deoarece un domeniu îngust conduce la diminuarea nivelului de integrarea datelor și divizarea lor, pe când un domeniu extins — la ambiguități și complicații la proiectare.

Pentru fiecare viziune particulară a prezentării trebuie formulate entitățile necesare pentru descriere, adică trebuie de indicat tipul obiectelor (setul de astfel de obiecte) din domeniul obiectual, despre care trebuie colectată informația în sistem.

De multe ori se cere prelucrarea câtorva variante ale modelelor viziunilor particulare și de ales cel mai flexibil din punct de vedere al prezentării informației, permițând astfel prezentarea deplină a unei oarecare informații, cât și a unor fragmente ale sale. O astfel de abordare mărește posibilitățile utilizării în comun a datelor dintr-o bază de date de către diferiți utilizatori și pune baza pentru asigurarea flexibilității sistemului în scopul satisfacerii necesităților informaționale ale utilizatorilor.

Fiecărei entități alese i se atribuie un nume distinct ce reflectă conținutul semantic al ideii (conceptului) introdus. O denumire confuză, existența sinonimelor (unul și același concept are nume diferite) și omonimelor (diferite concepte au unul și același nume), conduc spre erori în proiectare și sunt neadmisibile.

De obicei, generalizarea categoriilor de entități la pasul dat nu se realizează. La modelarea viziunilor particulare trebuie de constatat categoriile date și de prezentat fiecare din ele ca entități independente. Constatarea se realizează utilizând noțiunile de tip și rol.

Numărul total al entităților formulate într-o viziune particulară separată trebuie să fie limitată. Un număr mare de tipuri de entități într-o viziune locală ne vorbește despre faptul că domeniul său este foarte mare și el trebuie revizuit, împărțindu-l în câteva domenii mai mici.

3.2.3. Integrarea viziunilor particulare (proiectarea schemei conceptuale)

O ultimă etapă în proiectarea conceptuală o reprezintă integrarea viziunilor utilizatorilor, prin care se obține modelul de date. Această fază cuprinde subfazele de combinare a viziunilor utilizatorilor, integrarea cu modelele existente de date și analizele privind stabilitatea și posibilitatea dezvoltării ulterioare.

Combinarea viziunilor utilizatorilor presupune punerea de acord a diferitelor funcții definite în viziuni și a diferitelor grupuri de utilizatori cu identificarea noțiunilor și relațiilor comune, eventual purtând nume diferite, a valorilor derivate, a constrângerilor de reprezentare, a regulilor de acces la date etc. Pentru părțile comune unor vederi trebuie rezolvate probleme legate de conflicte, de posibile inconsistențe și de stabilire a unor relații noi de legătură între vederi pentru a obține modelul logic de date compus.

Integrarea cu modelele existente de date presupune examinarea raportului dintre modelul logic rezultat în raport cu modelele dezvoltate în alte scopuri. Se pot detecta zone comune și unele inconsistențe în raport cu alte modele, care permit sau nu modificarea pentru a rezolva aceste probleme.

Analiza privind stabilitatea și posibilitățile de dezvoltare constă în considerarea schimbărilor viitoare care pot să afecteze baza de date. Pentru schimbările semnificative, inevitabile sau probabile se prevăd elemente incorporate în modelul logic sau, cel puțin, se face o documentare ce permite realizarea cu mai multă ușurință a unor schimbări ulterioare. Scopul este de a asigura o perioadă cât mai mare de stabilitate a modelului logic, perioada în care corectitudinea și utilitatea bazei de date se mențin la diferite schimbări în schemele conceptuale, dar fără să fie afectat modelul logic.

La integrarea modelelor viziunilor particulare proiectantul poate formula construcții ce sunt derivate față de cele realizate în viziunile particulare. Formarea unor astfel de construcții se realizează prin introducerea analiza noțiunilor de un nivel mai înalt în raport cu noțiunile utilizate în viziunile particulare la descrierea obiectelor inițiale. Scopul introducerii unor astfel de abstracții:

integrarea viziunilor fragmentare despre proprietățile diferite a unuia și aceluiași obiect într-o viziune componențială unică;

înlăturarea diferențelor neesențiale în viziunea despre astfel de obiect;

introducerea noțiunilor abstracte, convenabile pentru soluționarea problemelor puse în fața sistemului și stabilirea legăturilor dintre aceste noțiuni cu unele noțiuni concrete utilizate în model (de exemplu: escortă—limuzine, ”contract”—”întreprindere” etc.)

crearea claselor și subclaselor a astfel de obiecte și introducerea noțiunilor abstracte corespunzătoare (de exemplu: clasa „produsele întreprinderii” are ca subclasă tipul produselor fabricate), clasificarea obiectelor după anumite criterii (de exemplu, ”articolele fabricate” și ”articole produse”);

crearea tipurilor derivate de obiecte ce corespund reuniunii, intersecției sau diferenței obiectelor inițiale.

Construcțiile derivate trebuie să asigure noncontradicția datelor prezentate. Înainte de generalizare se hotărăște întrebarea despre ordinea integrării modelelor viziunilor particulare.

Un factor important este ordonarea pașilor procesului de integrare. Dacă înainte de proces se va realiza gruparea corespunzătoare a viziunilor particulare, poate fi mărit valoarea factorului X și se micșorează numărul operațiilor de comparare în timpul integrării.

La integrarea viziunilor se utilizează 3 concepte de bază:

identitatea;

agregarea;

generalizarea.

Două sau mai multe modele se consideră identice dacă au același conținut semantic.

Agregarea permite analiza relației dintre elementele modelului ca un nou element.

La integrarea viziunilor agregarea se întâlnește sub următoarele 3 forme:

Într-o viziune obiectul agregat este definit ca un tot întreg, în alta — se analizează componentele sale.

De exemplu, într-o viziune se definește doar un singur obiect A (un articol oarecare), în altă viziune – obiectele B1, B2, B3 (unele piese) ce sunt părți componente ale obiectului A (însăși obiectul

A nu este definit).

Dacă se va efectua o simplă reuniune, adică se vor analiza 4 obiecte distincte A, B1, B2, B3, aceasta va însemna că la integrarea viziunilor n-a fost inclusă informația despre faptul că obiectele B1, B2, B3 sunt părți componente ale obiectului A. Pentru a include această informație în modelul viziunii integrate, trebuie de efectuat reuniunea cu ajutorul agregării, fapt ce va majora posibilitățile utilizării în comun a datelor.

Un obiect agregat ca un tot întreg nu este determinat în nici una din viziuni, dar în ambele viziuni se analizează diferite părți constitutive ale sale.

De exemplu, într-o viziune sunt determinate obiectele B1, B2, iar în alta — B3, B4, B5, ce sunt componente ale obiectului A, care nu este definit în nici una din viziuni, dar despre existența căruia cunoaște proiectantul.

În fiecare din viziuni nu sunt condiții necesare pentru crearea obiectului agregat, pe când la integrare aceste viziuni se creează. De aceea pentru majorarea posibilității utilizării în comun a datelor proiectantul analizează obiectul agregat.

Unul și același obiect agregat se analizează în ambele viziuni, dar componentele diferă.

3.2.4. Proiectarea logică

Transformarea cerințelor față de date în structuri de date. La această etapă obținem aspectul datologic, care se utilizează în cazul soluționării întrebărilor despre prezentarea datelor în memoria sistemului informațional.

La proiectarea datologică a sistemului, reieșind din posibilitățile metodelor existente de percepere, păstrare și prelucrare a informației se elaborează formele corespunzătoare de prezentare a informației în sistem prin intermediul datelor și, de asemenea, sunt implicate și modelele de prezentare și transformare a datelor, se formulează regulile de interpretare semantică a datelor.

În rezultat obținem structură a bazei de date și specificarea programelor aplicative.

3.2.5. Proiectarea fizică

Etapa de transformare a schemei logice a bazei de date într-o schemă reală.

Dezvoltarea de aplicații de baze de date de mari dimensiuni este în același timp un fapt banal, dar și un fapt extraordinar. Banalitatea constã în faptul cã un procent semnificativ din efortul de dezvoltare de aplicații se îndreaptă spre acest domeniu. Extraordinarul se leagă de comp lexitatea deosebitã a acestor aplicații, care implicã echipe mari de proiectant, necesitã atât experiență în domeniu cât si adaptarea la condiții mereu noi. Și nu în ultimul rând, reprezintă o mare responsabilitate. Cu toate cã industria de software cunoaște o adevărată explozie, cu toate cã suntem literalmente bombardați cu sute si sute de aplicații din ce în ce mai complexe si mai specializate, încă nu a fost "inventat" un pachet software care sã satisfacă necesitățile generale ale unei întreprinderi. Chiar dacã ne restrângem pretențiile la partea numitã de obicei "de gestiune economicã", un astfel de software nu se întrezărește la orizont, cu toate cã în linii mari, toate întreprinderile funcționează pe aceleași principii. Existã pachete „de gata” care satisfac anumite nevoi specifice dar, la noi ca si în alte părți, elementele specifice primează si în consecință marea majoritate a întreprinderilor preferã sã-si construiască „la comandã” sistemul informatic.

3.3. Normalizarea bazei de date

3.3.1. Anomalii și redundanțe

De ce o schemă a bazei de date poate fi ,,rea”? Anomaliile, care apar în lucrul cu baza de date, se produc datorită dependențelor ,,nedorite” care se manifestă între atributele din cadrul schemelor relațiilor din baza de date. Aceste dependențe determină creșterea redundanței datelor și reducerea flexibilității structurii bazei de date, făcând extrem de dificil lucru cu ea.

Deci, în primul rând, o schemă poate fi ineficientă fiindcă conține o mulțime de date redundante.

În al doilea rând, ca o consecință a primei cauze, actualizarea unei baze redundante poate duce la situația când ea va conține fapte logic contradictorii. O parte de date pot rămâne nemodificate. Deci o bază de date ,,rea” duce la apariția unor inconsistențe la modificarea datelor.

În al treilea rând, o bază de date ,,rea” poate limita posibilitatea de inserare a datelor. Într-o relație nu pot fi introduse date despre o entitate până nu se cunosc alte date conform restricțiilor de integritate ale entității.

În al patrulea rând, pot apărea pierderi de date la ștergere. In mod normal, prin operația de ștergere trebuie să se poată elimina din baza de date numai datele pe care dorim să le ștergem. Atunci când, concomitent cu aceste date sunt șterse și altele, care nu mai pot fi reconstruite din baza de date, spunem că la operația de ștergere se produc pierderi de date.

3.3.2. Forma normală unu

Precum s-a menționat, domeniile atributelor sunt simple, adică ele sunt atomice (nu pot fi descompuse din punctul de vedere al sistemului de gestiune al bazei de date). Cu alte cuvinte, valorile ce le pot primi atributele nu sunt liste, mulțimi sau alte structuri complexe.

Definiția Schema relațională R se găsește în forma normală unu (FN1), dacă pentru orice atribut A din R valorile din dom(A) sunt atomice. Schema unei baze de date se găsește în forma normală unu, dacă orice schemă relațională din ea este în forma normală unu.

Forma normală unu este forma de bază a relațiilor, care figurează ca cerință minimală la majoritatea SGBD-urilor.

Definirea noțiunii de valoare atomică e destul de dificilă. Valoarea atomică dintr-o aplicație în altă aplicație poate fi considerată nonatomică. De aceea ne vom conduce de următoarea regulă: atributul nu este atomic, dacă în aplicații el se utilizează pe părți.

În general se cunosc două tipuri de atribute nonatomice. Unul din ele sunt listele sau mulțimile de valori.

Exemplul Relația publicații din tabelul 1 nu se află în forma normală unu, fiindcă atributul AUTORI nu e atomic.

Aducerea relației publicații în forma normală unu presupune eliminarea listelor de valori. Pentru orice valoare din listă pe care o poate primi atributul AUTORI se formează un tuplu aparte, conținând numele autorului și publicația lui. Relația publicații adusă în forma normală unu arată ca în tabelul 2.

Alt tip de atribute nonatomice sunt atributele compuse

Exemplul Relația atribute_publicații din tabelul .3 nu este în forma normală unu, dacă dorim să avem accesul la unele componente ale atributului AN_NR_EDIȚIEI.

Pentru a aduce relația atribute_publicații în forma normală unu atributul compus AN_NR_EDIȚIEI se divizează în două atribute AN și NUMAR. Noua relație atribute_publicații din tabelul 4 se găsește în forma normală unu.

Utilitatea formei normale unu este destul de evidentă. Listele de valori distrug structura naturală dreptunghiulară a unei relații. Este extrem de greu să te referi la un element din grupul de valori, fiindcă trebuie specificată cumva poziția valorii căutate. Și, bineînțeles, că operația de actualizare nu poate fi efectuată.

În afară de aceasta, diverse părți ale unui atribut partiționat pot să se comporte în mod diferit din punctul de vedere al dependențelor. Forma normală unu poate exprima dependențele la așa grad de detaliere, de care avem nevoie.

3.3.3. Forma normală doi

Apariția formei normale doi a fost motivată de reducerea redundanței și eliminarea unor anomalii ce apar la actualizarea schemelor în forma normală unu.

Să trecem la expunerea strictă a formei normale doi.

Definiția1. Fie relația r(R) și AR. Atributul A se numește primar, dacă el aparține unei chei a schemei R și nonprimar în caz contrar.

Definiția 2. Fie X→A o dependență funcțională netrivială. Atributul A este parțial dependent de X, dacă există o submulțime proprie Y a mulțimii X și Y→A. Dacă nu există o astfel de submulțime proprie, se spune că A depinde complet de X.

Definiția 3. Schema unei relații R se găsește în forma normală doi (FN2)în raport cu mulțimea de dependențe funcționale F, dacă ea se găsește în forma normală unu și orice atribut nonprimar nu depinde parțial de careva cheie a schemei R. Schema bazei de date se găsește în forma normală doi, dacă orice schemă relațională a ei se găsește în forma normală doi.

Problema determinării, dacă un atribut e primar e legată de problema găsirii cheilor unei relații. Prin urmare, determinarea dacă o schemă se găsește în forma normală doi e o problemă NP-completă.

3.3.4. Forma normală trei

Definiția 1. Fie relația r(R), X, Y R și A R. Vom spune că atributul A depinde tranzitiv de X prin Y, dacă sunt satisfăcute condițiile:

(1) X→Y,

(2) Y→X (adică X nu depinde funcțional de Y),

(3) Y→A,

(4) A XY.

În această definiție, condițiile (1) și (3) implică X→A conform regulii tranzitivității. Condiția (2) este esențială, de altfel X↔Y. Condiția (4), de asemenea, e esențială, în caz contrar X→A poate fi dedusă cu ajutorul reflexivității (dacă A X) sau cu ajutorul regulii proiectivității (dacă A Y).

Definiția 2. Schema R se găsește în forma normală trei (FN3) în raport cu o mulțime de dependențe funcționale F, dacă R se găsește în forma normală unu și orice atribut nonprimar nu depinde tranzitiv de careva cheie a schemei R. Schema bazei de date Db={R1, …,Rm} se găsește în forma normală trei, dacă orice schemă relațională Ri Db, 1≤ i ≤ m, se găsește în forma normală trei.

E firească întrebarea, care este corelația dintre forma normală trei și forma normală doi. Răspunsul îl dă următoarea teoremă.

Teorema 1. Schema unei relații ce se găsește în forma normală trei se găsește și în forma normală doi.

Demonstrație. Teorema poate fi reformulată în felul următor: dacă schema unei relații nu se găsește în forma normală doi, atunci ea nu se găsește nici în forma normală trei. Deci trebuie să arătăm că dependența parțială implică dependența tranzitivității.

Fie schema relațională S=(R,F) și presupunem că atributul nonprimar A e parțial dependent de o cheie, fie K. Adică K→AF+ și K1→AF+, unde K1K. Conform regulii reflexivității, K1K implică K→K1F+ și atunci condiția (1) a definiției 1 e satisfăcută. Condiția (2) tot e satisfăcută, adică K1→K, fiindcă în caz contrar K nu este cheie. Condiția (3) urmează din ipoteză, iar condiția (4) e satisfăcută din presupunerea că A este atribut nonprimar, adică nu aparține cheii K și deci nici lui K1 Prin urmare, atributul nonprimar A depinde tranzitiv de cheia K.

Definiția formei normale trei poate fi formulată și altfel.

Definiția 3. Schema unei relații se găsește în forma normală trei, dacă orice atribut ce depinde tranzitiv de cheie este primar.

Atunci putem formula următoarea teoremă.

Teorema 2. Schema R se găsește în forma normală trei în raport cu mulțimea de dependențe funcționale F, dacă pentru orice dependență netrivială X→A F+

(1) X este supercheie pentru R sau

(2) A este atribut primar.

Demonstrație. Fie X→A o dependență netrivială și fie K o cheie a schemei R. Din definiția de mai sus reiese că nu e necesară examinarea cazului, când A este atribut primar. Condiția (2) e evidentă. Să arătăm că pentru orice atribut nonprimar A, dependența K→ A nu este tranzitivă. Dacă presupunem că condiția (1) nu e satisfăcută, atunci K→X F+ (fiindcă K e cheie) și X→K. Dar aceasta este dependența tranzitivă a atributului nonprimar de cheie.

Aducerea schemelor în forma normală trei

Normalizarea este procesul de aducere a schemei într-o formă normală dată. Aducerea schemei într-o formă normală trei poate fi efectuată prin descompunere sau prin sinteză.

Normalizarea prin descompunere are mai multe dezavantaje descrise mai jos.

Dat fiind faptul că algoritmul de normalizare prin descompunere necesită calcularea cheilor schemei și determinarea atributelor nonprimare, examinarea dependențelor din F+ valide în schema curentă, complexitatea procesului de normalizare nu e polinomială. Acesta e primul dezavantaj.

Intr-al doilea rând, nu întotdeauna putem obține un număr minimal de scheme relaționale normalizate dintr-o schemă dată.

A treia problemă constă în apariția dependențelor parțiale în procesul descompunerii schemelor. Aceste dependențe generează scheme cu mai multe scheme relaționale decât e nevoie.

A patra problemă este că normalizarea prin descompunere nu întotdeauna conservă dependențele funcționle.

A cincea problemă constă în faptul că normalizarea prin descompunere poate produce scheme, în care dependențele ce pot fi utilizate mai departe în descompunere, sunt latente.

Normalizarea prin sinteză – o alta metodă de aducere a schemelor la forma normală trei, ce nu generează problemele descrise mai sus.

Metoda propusă este o procedură de sinteză, fiindcă pleacă de la mulțimea de dependențe funcționale F cu determinații dintr-un singur atribut și produce schema bazei de date Db={R1,…,Rm} asupra R= R1…Rm. Schema bazei de date trebuie să satisfacă următoarele patru condiții:

(1) Mulțimea de dependențe formate de cheile fiecărei scheme Ri trebuie să fie o acoperire a mulțimii inițiale F de dependențe funcționale, adică F = {K→Ri | RiDb, 1 i m, K – cheie}.

(2) Orice schemă relațională Ri din Db se află în forma normală trei.

(3) Nu există o schemă a bazei de date ce satisface condițiile (1) și (2) cu mai puține scheme relaționale.

(4) Orice relație r(R) ce satisface F se descompune fără pierderi asupra schemei Db, adică

r= ..

Să considerăm aceste condiții.

Condiția (1) garantează că descompunerea relației r asupra schemei Db conservă dependențele funcționale F. În afară de aceasta condiția (1) ne asigură cp unicele dependențe valide în Ri, 1≤i≤m, au în calitate de determinanți cheile schemei Ri. Satisfacerea condiției (1) este soluția problemei patru din secțiunea precedentă.

Condiția (2) este scopul principal al normalizării și necesitatea ei a fost detaliat studiată.

Condiția (3) ne ocrotește de scheme redundante, deci ea soluționează problemele doi și trei din secțiunea precedentă.

Condiția (4) de asemenea a fost considerată.

Problema cinci din secțiunea precedentă nu apare grație îndeplinirii concomitente a condițiilor (1) și (3). Iar problema unu nu se mai pune, fiindcă complexitatea algoritmului de sinteză descris mai jos este polinomială.

Algoritmul SYNT (F, Db)

Intrare: F – o mulțime de dependențe funcționale

Ieșire: Db schema bazei de date în forma normală trei.

Se găsește o acoperire nonredundantă Fn a mulțimii F

Se construiește o acoperire redusă în stânga Fr a mulțimii Fn

Mulțimea Fr se partiționează în clase de echivalențe

Se construiește o mulțime J în felul următor: fie J=Ǿ. Pentru orice două dependențe funcționale din Fr cu determinații X și Y, unde X↔Y, se modifică J, J:=J{X→Y, Y→X}. Pentru orice AY, dacă X→A se găsește în Fr, atunci Fr:= Fr \ {X→A}. Același lucru e valabil și pentru orice BX. Dacă Y→BFr, atunci Fr:=Fr\ {Y→B}.

5. Se elimină dependențele tranzitive. Se găsește o mulțime Fr1Fr, ce satisface (Fr1J)+ (FrJ)+ și nici o submulțime proprie a mulțimii Fr1 nu satisface condiția dată. Apoi se includ dependențele din J în clasele de echivalență a mulțimii Fr1 și fie că obținem mulțimea G de dependențe funcționale.

6. Se construiesc schemele R1,…,Rm. Fiecare schemă Ri include atributele dependențelor funcționale din clasa de echivalență i și în final obținem schema bazei de date Db:=(R1,…, Rm}.

Să ne oprim acum asupra corectitudinii algoritmului. Algoritmul expus formează un număr minimal de scheme relaționale în Db.

Teorema 3. Dacă Db este schema bazei de date sintetizate din mulțimea F, atunci Db conține cel puțin |EFn| scheme relaționale.

Demonstrație. Dependențele ce sunt incluse într-o schemă relațională Ri, 1≤ i ≤ m, au determinanți echivalenți. Deci Db conține atâtea scheme în câte clase de echivalență este partiționată mulțimea G. Urmează |EG|=|EFn| Dar e cunoscut faptul că |EF||EFn|, adică mulțimea nonredundantă constă dintr-un număr minimal de clase de echivalență.

Această teoremă ne garantează că algoritmul de sinteză satisface condiția (3).

Condiția (1) este asigurată, fiindcă F Fn Fr G.

Condiția (2) e satisfăcută de pasul. 5 al algoritmului ce elimină dependențele tranzitive.

Acum să vedem dacă e satisfăcută și condiția (4). Cu toate că algoritmul de sinteză soluționează toate problemele din normalizării prin descompunere, nu întotdeauna schema bazei de date posedă proprietatea joncțiunii fără pierderi. Adică nu întotdeauna e satisfăcută condiția (4). Acest lucru nu se petrecea în cazul normalizării prin descompunere.

Un alt dezavantaj al algoritmului de sinteză e legat de atributele ce nu sunt antrenate de mulțimea de dependențe funcționale F. Aceste două dezavantaje pot fi eliminate, introducând așa-numita cheie universală.

Definiția 4. Fie Db = {R1,…,Rm} o schemă a bazei de date asupra atributelor R = R1…Rm și F o mulțime de dependențe funcționale. Mulțimea XR se numește cheie universală, dacă F=X1→R și nu există X1, unde X1X, ce ar satisface F =X1→R.

Deci, ca schema bazei de date să posede proprietatea joncțiunii fără pierderi, ea trebuie să conțină o schemă relațională în care o cheie a ei e universală.

Vom modifica algoritmul de sinteză pentru a elimina cele două dezavantaje menționate mai sus.

La mulțimea inițială de dependențe funcționale F se adaugă o dependență funcțională R→C, unde R= R1…Rm, iar CR.

Este clar că la primul pas al algoritmului dependența R→C nu va fi eliminată, fiindcă ea nu e redundantă în F.

La al doilea pas ea va fi redusă în stânga, fie R1→C.

La etapa de partiție, dacă ea va intra într-o clasă de echivalență cu alte dependențe, atunci ea se elimină din Fr și algoritmul continuă mai departe. Dacă ea singură formează o clasă de echivalență, atunci R1→C generează schema Rm= R1C cu cheia R1.

La sfârșitul algoritmului se elimină atributul C din schema Rm, deci Rm = R1.

Un efect adițional al normalizării este creșterea numărului de structuri de date în baza de date. Aceasta însă afectează eficiența de căutare a datelor în sistemul informatic. Deși normalizarea reduce spațiul total necesar de păstrare a datelor, însă crește timpul în care poate fi căutată informația. Pentru procesarea interpelărilor și extragerii răspunsurilor apare necesitatea rejoncționării relațiilor. Prin aceasta și se explică faptul că primele baze de date relaționale au apărut pe calculatoare performante, iar mai târziu au apărut sisteme instalate pe microcomputere.

În ceea ce privește duplicatele de date trebuie de menționat că ele nu pot fi comparate cu redundanța de date ce este redusă în procesul de normalizare. Redundanța generează anomalii de actualizare a datelor. Pe când duplicatele apărute după normalizare, nu generează asemenea anomalii.

4. SISTEMUL informaTIC de evidență a activității științifice

4.1. Oportunitatea elaborării unui sistem informatic în cadrul Academiei de Poliție „Ștefan cel Mare”

Dezvoltarea științei a cunoscut mai ales în ultimele secolele o ascensiune uimitoare, atât sub aspectul calitativ, cât și sub aspectul cantitativ. Astăzi bunul mers al societății nici nu poate fi conceput în afara activității științifice.

Calculatorul cunoaște o utilizare deosebit de intensă și variată, în special, în activitatea științifică. Din păcate, implementarea tehnicii de calcul în activitatea științifică din țara noastră este deocamdată insuficientă. Același lucru se poate spune și despre Academia de Poliție „Ștefan cel Mare”. În Academia de Poliție „Ștefan cel Mare” nu există un sistem informațional integru care ar servi activitatea de dirijare a instituției. Mai mult decât atât, unele domenii de activitate nu dispun nici măcar de un minim de informatizare, fapt care reduce considerabil capacitatea de acțiune a instituției.

Pentru a remedia întrucâtva această stare de lucruri s-a decis informatizarea activității din Academia de Poliție „Ștefan cel Mare”, în general, și a activității științifice, în special.

Automatizarea procesului de evidență în sistemul Academiei de Poliție și formarea Sistemului Informațional al Academiei de Poliție cere, în primul rând, o proiectare și planificare bine determinată. Sistemul unic informațional deja subînțelege o administrare unică și centralizată al acestui sistem.

Structura sistemului informațional, conform standardelor, este determinat de structura bazelor de date, structura rețelei electronice și structura de stare a subdiviziunii de administrare a SIAP.

Structura bazelor de date este determinat de genul de activitate a subdiviziunilor Academiei de Poliție și evidențele determinate de această activitate. Reieșind din acest fapt putem spune că Baza centrală de Date a SIAP este o totalitate de evidențe, care după o logică bine determinată sunt unite într-un sistem unic integru.

Reieșind din acest fapt, structura BCD v-a avea în componența sa mai multe baze de date:

baza de date a sistemului cadre;

baza de date a sistemului învățământ;

baza de date a sistemului asigurare materială;

baza de date a sistemului cancelarie;

baza de date a sistemului contabilitate;

baza de date a sistemului științific;

baza de date a sistemului serviciului medical etc.

Toate bazele de date se unesc într-un sistem unic integru și structura fiecărei din ele este determinată de activitatea subdiviziunilor corespunzătoare (vezi anexa nr.1).

Drept suport tehnic în optimizarea procesului de studii și de cercetare științifică, în cadrul Academiei de Poliție au fost amenajate trei săli specializate, dotate cu calculatoare performante; de asemenea, toate subdiviziunile antrenate în procesul de studii și de cercetare științifică sunt dotate cu calculatoare, care sunt unite într-o rețea unică în cadrul Academiei de Poliție.

Structura rețelei de calculatoare în mare măsură depinde de dislocația subdiviziunilor Academiei de Poliție. Având în vedere că subdiviziunile Academiei sunt dislocate în trei locuri diferite ale orașului, și distanța dintre ele este foarte mare pentru a organiza o rețea locală prin cablu, ea este formată dintr-o rețea de calculatoare combinată, și anume: o rețea electronică locală unde va fi Baza centrală de Date, situată în corpusul principal al Academiei și două rețele locale auxiliare, în cele două subdiviziuni situate în cartierul Poșta Veche, care vor fi unite cu baza Centrală de Date prin intermediul rețelei telefonice, astfel toate subdiviziunile Academiei vor avea acces la informațiile din BCD.

Structura de stare a subdiviziunii de administrare a SIAP dispune de personal care efectuează deservirea tehnică, supravegherea matematică, întreținerea rețelei în stare de lucru, aplicarea noilor tehnologii informaționale, administrarea BCD, supravegherea informațională a BCD, proiectarea noilor blocuri informaționale etc. Acest personal face parte din subdiviziunea cu același nume Centrul Informații, care pe lângă funcția de administrare a sistemului informațional (grupul de administrare a SIAP), participă activ și în procesul de învățământ (grupul de asigurare informațională – laboratoarele).

În lucrarea dată este proiectată baza de date a sistemului științific, care trebuie să reflecteze: evidența publicaților științifice ale colaboratorilor Academiei; evidența activităților științifice organizate de Academie sau la care a luat parte reprezentanți ai Academiei; titlurile științifico-didactice și științifice ale colaboratorilor Academiei etc (vezi anexa nr.2).

Proiectând tipurile de date trebuie să ținem cont și de informația de ieșire: dări de seamă după diferiți parametri (publicațiile autorilor, publicațiile subdiviziunilor, activitățile după forma lor etc.).

4.2. Date despre activitatea științifică

Începând cu pași precauți, știința a pătruns, treptat, deja în faza actuală de dezvoltare a societății, practic, în fiecare colțișor al vieții noastre, devenind omniprezentă. Prezența ei s-a făcut simțită, în termeni esențiali, deopotrivă atât în sfera materială, cât și spirituală de existență umană. Știința reprezintă, de fapt, un veritabil fir al Ariadnei pentru om și societate în genunea nebuloasă a existenței ce-i învăluie.

În linii mari, putem remarca că în plan material știința a ajuns principalul factor de producție, iar în plan spiritual formează cadrul de referință pentru celelalte forme de conștiință socială și moduri de cunoaștere. În detaliu, în complexitate și în diversitate, prezența și contribuția științei este de-a dreptul copleșitoare. Până și credințele, indiferent de sorginte, nu se pot dispensa de invocații cu caracter științific, iar cele de dată recentă utilizează pe larg tezele științifice în doctrinele elaborate. În definitiv, putem enunța că știința se constituie într-un fundament solid și necesar acțiunilor edificatoare ale omului și bunului mers al societății"[7].

Activitatea științifică în Academia de Poliție „Ștefan cel Mare” este o direcție prioritară, iar suportul științific în procesul didactic reprezintă o verigă importantă, absolut necesară și este orientată spre obținerea cunoștințelor fundamentale în domeniile: jurisprudență, filozofie, sociologie, psihologie, politologie, precum și spre desfășurarea de cercetări concrete privind aplicarea cunoștințelor noi în vederea realizării obiectivelor practice și soluționarea problemelor concrete ce țin de asigurarea științifică a activității organelor de interne.

Însemnătatea activității științifice a Academiei de Poliție „Ștefan cel Mare” este determinată de faptul că ea constituie un suport pentru activitatea întregului Minister al Afacerilor Interne al Republicii Moldova. Totuși, această ramură deosebit de importantă a activității Academiei de Poliție „Ștefan cel Mare” nu a fost, până în prezent, informatizată. De aceea, informatizarea activității științifice în Academia de Poliție „Ștefan cel Mare” a devenit o necesitate stringentă. Sistemul informațional prezentat în lucrarea de față este destinat anume acestui scop. Importanța lui este cu atât mai mare, cu cât va cunoaște o implementare imediată în Academia de Poliție „Ștefan cel Mare”.

Activitatea științifică este desfășurată în cadrul Academiei de Poliție sub cele mai diverse forme. Una din principalele aspecte ale activității științifice o constituie elaborarea și publicarea literaturii științifice, adică a manualelor, monografiilor, materialelor didactice, articolelor, recomandărilor practice, elaborărilor metodice etc. Concomitent, în subdiviziunile Academiei sunt periodic analizate și avizate proiecte de legi, proiecte ale Programelor de Stat privind măsurile de prevenire și de contracarare a criminalității și menținerea ordinii și liniștii publice în Republica Moldova. Frecvent sunt organizate și desfășurate anchete sociologice și sondaje de opinie, atât în rândul populației civile, cât și în rândul funcționarilor de poliție. În fiecare an sunt chestionați și studenții Academiei de Poliție, în scopul perfecționării procesului de studii.

De menționat că în pofida existenței rețelei de calculatoare, colectarea și sistematizarea datelor ce țin de activitatea științifică continuă a fi un proces greoi, „manual” și care în ultimă instanță, consumă mult timp persoanelor responsabile de evidența și planificarea activității științifice. Acest inconvinient în activitate este complicat, în special, de cererile sistematice de informații privind activitatea științifică a Academiei de Poliție în general și a fiecărui funcționar în particular, acestea pentru a reprezenta diverse note informative privind activitatea științifică care des sunt solicitate de diverse subdiviziuni ale Ministerului Afacerilor Interne. De asemenea, pentru pregătirea dărilor de seamă; furnizarea informației despre activitatea științifică a fiecărui funcționar antrenat în procesul didactic și cel de cercetare științifică pentru întocmirea prezentărilor pentru atestarea acestora și pentru atribuirea gradelor speciale următoare.

În contextul acestei stricte necesități de a prelucra un volum mare de informații, care în prezent se păstrează doar în fișiere aparte (informațiile din fișiere fiind chiar incomplete), nefiind adunate într-un sistem unic integral; din cauza creșterii continue a acestei informații, s-a impus necesitatea realizării unui sistem informatic de evidență a activității științifice a Academiei de Poliție, care să poată realiza depozitarea informației în baza de date și prelucrarea acesteia; care printr-o interfață comodă și prietenoasă să ușureze munca utilizatorului la căutarea informațiilor necesare, care răspund subiectelor și reperelor mai des solicitate.

Sistemul informațional prezentat în lucrarea de față vine a răspunde tocmai necesității menționate. Sistemul informațional în discuție a fost conceput pentru a servi la optimizarea activității științifice din Academia de Poliție „Ștefan cel Mare”.

Dirijarea și planificarea activității științifice cade în sarcina Centrului de cercetări științifice, care include o subdiviziune specializată, iar sistemul informațional conceput va fi exploatat de subdiviziunea menționată, în special. Totuși, de informațiile stocate în acest sistem informațional va beneficia nu doar Academia de Poliție „Ștefan cel Mare”, ci și întreg Ministerul Afacerilor Interne, deoarece Academia de Poliție reprezintă principalul potențial științific al ministerului.

Sistemul informațional prezentat în lucrarea de față a fost conceput pornind de la necesitățile funcționale concrete ale Academiei de Poliție, răspunzând cerințelor punctuale ale solicitantului. Astfel, baza de date a sistemul informațional elaborat va stoca următoarele informații:

Compartimentul lucrări științifice și didactice publicate va oferi informații despre: autorul (autorii) lucrării, titlul lucrării, publicația în care a fost tipărit, editura, locul editării, anul editării, forma lucrării, volumul lucrării (în coli de tipar), indicii de clasificare, subdiviziunea în care își desfășoară activitatea autorul, .

În acest fel, informația despre autor permite: 1) a ține evidența volumului de lucru științific efectuat de funcționarii Academiei de Poliție, 2) a monitoriza caracterul realizărilor științifice ale funcționarilor concreți, 3) a fi la curent cu domeniul în care și-a aprofundat pregătirea profesională un funcționar anumit și poate deci acționa în calitate de expert în materie.

Informația despre titlul lucrării permite: 1) a ține evidența exactă a numărului de lucrări științifice și didactice elaborate de funcționarii Academiei de Poliție, 2) a monitoriza și a fi la curent cu materiile în care au fost desfășurate cercetări științifice, 3) a (re) orienta activitatea științifică în conformitate cu necesitățile survenite, 4) a avea acces rapid la informația științifică necesară, dar și disponibilă, 5) a întocmi rapid dările de seamă și notele informative solicitate de alte instituții.

Informația despre publicația în care a fost tipărită lucrarea științifică sau didactică respectivă permite a cunoaște și a găsi operativ lucrarea în care a fost tipărit un text științific sau didactic.

Informația despre editură și locul publicării permite: 1) a nota niște indici bibliografici obligatorii, 2) a cunoaște reușita funcționarilor Academiei de Poliție de a fi tipărit o lucrare în străinătate.

Informația despre anul editării unei lucrări permite: 1) a ține evidența lucrului științific realizat de funcționarii concreți într-o anumită perioadă, 2) a ține evidența lucrului științific realizat de Academia de Poliție (în calitate de instituție) într-o perioadă, 3) a întocmi cu exactitate dări de seamă și note informative pentru instituțiile solicitante, 4) a urmări progresele științifice înregistrate de Academia de Poliție.

Informația despre forma lucrării permite: 1) a clasifica lucrările, după un criteriu semnificativ, în – teze la conferințe științifice, articole, studii, monografii, materiale didactice, recomandări practice etc.; 2) a cunoaște caracterul realizărilor obținute.

Informația despre volumul lucrării permite: 1) a ține evidența volumului activității științifice efectuate de funcționarii concreți, 2) a ține evidența volumului activității științifice efectuate de Academia de Poliție (în calitate de instituție).

Informația despre indicii de clasificare ( CZU, I.S.B.N.) permite a verifica veridicitatea informației primite despre lucrările tipărite.

Informația despre subdiviziunea în care își desfășoară activitatea autorul permite: 1) a ține evidența activității științifice efectuate la catedre, 2) a monitoriza, în scop de dirijare, activitatea științifică desfășurată la catedre.

Informația despre titlul posedat de autor permite a cunoaște, sub un anumit aspect, gradul de pregătire științifică al autorului lucrării științifice consemnată, numărul de doctori la catedre etc.

Compartimentul activități științifice va oferi informații despre reuniunile științifice organizate de Academia de Poliție ,,Ștefan cel Mare” și anume: forma activității, genericul, data desfășurării, locul de desfășurare, nivelul reuniunii științifice, numărul participanților, tipărirea rezultatelor științifice prezentate în cadrul reuniunii științifice, date suplimentare.

Informația despre forma de activitate științifică permite a stabili: 1) forma în care s-a desfășurat reuniunea științifică: masă rotundă, conferință, congres etc.; 2) caracterul reuniunii: reuniune științifică sau științifico-practică; 3) contingentul participanților: cercetători, practicieni, cadre didactice etc.

Informația despre genericul reuniunii științifice permite a stabili 1) problematica pusă în discuție; 2) domeniul rezultatelor științifice prezentate la reuniune.

Informația despre data desfășurării reuniunii permite a localiza în timp producerea evenimentului științific.

Informația despre locul de desfășurare a reuniunii științifice permite a stabili localitate unde a avut loc evenimentul științific.

Informația despre nivelul reuniunii științifice permite a stabili importanța evenimentului care a avut loc și anume: la nivel de instituție, la nivel de minister, la nivel republican, la nivel internațional etc.

Informația despre numărul participanților permite: 1) a stabili amploarea reuniunii științifice desfășurate; 2) a aproxima volumul realizărilor științifice prezentate la reuniune.

Informația despre tipărirea realizărilor științifice prezentate în cadrul reuniunii științifice permite: 1) a stabili existența unor publicații incluzând materialele reuniunii științifice; 2) a găsi rapid materiale prezentate la reuniunea științifică.

Lipsa unui sistem informațional similar vizând activitatea științifică din Academia de Poliție ,,Ștefan cel Mare” face ca acest prim sistem să aibă un caracter oarecum de încercare, el urmând a fi dezvoltat și ajustat ulterior, în funcție de constatările oferite de experiență și noile cerințe înaintate.

4.3. Proiectarea sistemului

Pentru domeniul activității științifice din cadrul Academiei de Poliție „Ștefan cel Mare”, pot fi puse în evidență următoarele entități:

Pentru publicațiile științifice ale colaboratorilor Academiei:

Publicațiile științifice (denumirea, anul ediției, numărul paginilor, CZU, ISBN, etc.) –PUBLICAȚII;

Funcționarii Academiei, care desfășoară o activitate științifică, exprimată mai ales prin publicațiile lor științifice – AUTORI;

Pentru activitățile științifice din cadrul Academiei și la care participă Academia:

Activități științifice – activitate științifica (vezi anexa nr.2).

Tab.5

PUBLICAȚII

Tab.6

Autori

Tab.7

Activități științifice

În tabela PUBLICAȚII se observă numărul câmpurilor este destul de mare, dar aceasta este destul de convenabil, deoarece se vor evita includerea structurilor complexe în câmpuri. Această separare va avea consecințe benefice în utilizarea lor ulterioară.

Totuși se observă repetarea valorilor în câmpurile tabelului, și anume: Forma publicației, Editura, Tipografia. Aceasta se explică prin faptul că mai multe publicații sunt de aceeași formă, mai multe publicații sunt editate la una și aceeași editură, tiparul mai multor publicații poate fi executat la una și aceeași tipografie.

Din aceleași considerente în tabelul publicații nu au fost incluse nici datele despre autor. Includerea acestor date în tabel ar implica repetarea informației pentru fiecare din cărțile unui autor, în timp ce separarea lor într-un tabel aparte (AUTORI) necesită doar o singură descriere a datelor despre autori.

La fel s-a procedat și în cazul celorlalte câmpuri, valorile cărora se repetă, și s-au obținut tabele aparte: FORMA (teze la conferințe, articol științific, studiu, monografie, material didactic, îndrumar metodic, manuale, programe, elaborări practice etc.), EDITURA, TIPOGRAFIA, în care se descriu doar datele respective.

Raționamentul după care au fost separate tabelele atribute și Publicații este acela că multe publicații sunt scrise în coautorat, deci atributele lor vor fi identice, cu excepția autorului și a identificatorului publicației (diferit pentru fiecare publicație/autor). Astfel, cărțile care sunt scrise de mai mulți autori, sunt descrise o singură dată în tabelul atribute, iar identificatorul și autorul fiecărei publicații sunt descrise în tabelul publicații.

În tabelul autori se observă că valorile câmpului Subdiviziunea, Titlu științifico-didactic, Titlul științific, se repetă, de aceea, vom adăuga în baza de date încă tabelele: subdiviziuni (Catedre, Centrul de cercetări științifice, Secția studii, Secția personal), TITLURI ȘTIINȚIFICE (doctor, doctor habilitat), TITLURI ȘTIINȚIFICO-DIDACTICE (conferențiar universitar, profesor universitar, master) în care se vor descrie datele despre subdiviziuni, titlurile științifice, etc.

În tabelul Activități științifice se observă repetări de valori în câmpurile Forma de activitate, Organizatori, Nivelul activității și Localitatea (în care ar trebui de adăugat atributele Oraș și Țara), deci baza de date se va mări cu încă câteva tabele ca: FORMA DE ACTIVITATE (seminarii, mese rotunde, simpozioane, conferințe, congrese), ORGANIZATORI, NIVELUL ACTIVITĂȚII (republican, internațional, instituțional, ministerial, studențesc, profesoral).

După aceste realizări vom obține schema bazei de date în forma normală unu.

Apare, însă, o problemă. Mai multe lucrări sunt publicate în una și aceeași publicație. Lucrările la fel trebuie privite ca publicații științifice, și ele la fel pot fi scrise în coautorat. Din această cauză, se impune adăugarea în baza de date a două tabele, care vor reprezenta atributele publicațiilor, și anume ATRIBUTE GENERALE – atributele publicațiilor științifice și ATRIBUTE PARTICULARE – atributele lucrărilor din publicațiile științifice.

Aducerea bazei de date în forma normală trei și obținerea schemei bazei de date Db={R1,…,Rm} asupra R= R1…Rm se va obține cu ajutorul algoritmului de sintetizare, plecând de la mulțimea de dependențe funcționale F:

F={IdAP→IdFP, IdAP→DenP, IdAP→ColA, IdAP→IdAG, IdFPIdAG→IdAP,

IdAG→DenG, IdAG→AnE, IdAG→NrE, IdAG→IdEd, IdAG→IdTg, IdAG→IdOș

IdAG→Czu, IdAG→Isbn, IdAG→ColT, IdAG→NrPag, DenGAnENrE→IdAG,

CzuIsbn→IdAG,

IdP→IdAP, IdP→IdAut, IdAPIdAut→IdP,

IdEd→Editura, Editura→IdEd, IdTg→Tipografia, Tipografia→IdTg, IdOș→Oraș,

Oraș→IdOș, IdFP→FormaP, FormaP→IdFP,

IdAut→Nume, IdAut→IdTșd, IdAut→IdTș, IdAut→IdSb, Nume→IdAut,

IdTșd→TitluȘD, TitluȘD→IdTșd, IdTș→TitluȘ, TitluȘ→IdTș, IdSb→Subdiviz,

Subdiviz→IdSb,

IdAA→IdFA, IdAA→Generic, IdAA→DataÎ, IdAA→DataT, IdAA→NrPart,

IdAA→IdNiv, IdAA→IdOș, IdAA→IdAG, IdFAGenericDataÎdataT →IdAA,

IdAȘ→IdAA, IdAȘ→IdOrg, IdAAIdOrg→IdAȘ,

IdFA→FormaA, FormaA→IdFA, IdNiv→Nivel, Nivel→IdNiv, IdOrg→Organiz,

Organiz→IdOrg} (vezi anexa nr.3).

1. Construim acoperirea nonredundantă a mulțimii de dependențe F – Fn:

IdAP→IdFP: <IdAP, IdAPDenPColAIdAG, IdAPDenPColAIdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>;

IdAP→DenP: <IdAP, IdAPIdFPColAIdAG, IdAPIdFPColAIdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagFormaPEdituraTipografiaOraș>;

IdAP→ColA: < IdAP, IdAPIdFPDenPIdAG, IdAPIdFPDenPIdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagFormaPEdituraTipografiaOraș>;

IdAP→IdAG: < IdAP, IdAPIdFPDenPFormaP>;

IdFPIdAG→IdAP: < IdFPIdAG, IdFPIdAGFormaP, IdFPIdAGFormaPDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>;

IdAG→DenG: <IdAG, IdAGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>

IdAG→AnE: <IdAG, IdAGDenGNrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>

IdAG→NrE: <IdAG, IdAGDenGAnEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>

IdAG→IdEd: <IdAG, IdAGDenGAnENrEIdTgIdOșCzuIsbnColTNrPagTipografiaOraș>

IdAG→IdTg: <IdAG, IdAGDenGAnENrEIdEdIdOșCzuIsbnColTNrPagEdituraOraș>;

IdAG→IdOș: <IdAG, IdAGDenGAnENrEIdEdIdTgCzuIsbnColTNrPagEdituraTipografia>;

IdAG→Czu: <IdAG, IdAGDenGAnENrEIdEdIdTgIdOșIsbnColTNrPagEdituraTipografiaOraș>

IdAG→Isbn: <IdAG, IdAGDenGAnENrEIdEdIdTgIdOșCzuColTNrPagEdituraTipografiaOraș>

IdAG→ColT: <IdAG, IdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnNrPagEdituraTipografiaOraș>

IdAG→NrPag: <IdAG, IdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTEdituraTipografiaOraș>

DenGAnENrE→IdAG: <DenGAnENrE>;

CzuIsbn→IdAG: <CzuIsbn>;

IdP→IdAP: <IdP, IdPIdAut, IdPIdAutNumeIdTșdIdTșIdSbTitluȘDTitluȘSubdiviz>;

IdP→IdAut: <IdP, IdPIdAP, IdPIdAPIdFPDenPColAIdAG, IdPIdAPIdFPDenPColAIdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>;

IdAPIdAut→IdP: <IdAPIdAut, IdAPIdAutNumeIdTșdIdTșIdSbTitluȘDTitluȘSubdivizIdFPDenPColAIdAG… >;

IdEd→Editura: <IdEd>; Editura→IdEd: <Editura>;

IdTg→Tipografia: <IdTg>; Tipografia→IdTg: <Tipografia>;

IdOș→Oraș: <IdOș>; Oraș→IdOș: <Oraș>;

IdFP→FormaP: <IdFP>; FormaP→IdFP: <FormaP>;

IdAut→Nume: <IdAut, IdAutIdTșdIdTșIdSbTitluȘDTitluȘSubdiviz>;

IdAut→IdTșd: <IdAut, IdAutNumeIdTșIdSbTitluȘSubdiviz>;

IdAut→IdTș: <IdAut, IdAutNumeIdTșdIdSbTitluȘDSubdiviz>;

IdAut→IdSb: <IdAut, IdAutNumeIdTșdIdTșTitluȘDTitluȘ>;

Nume→IdAut: <Nume>;

IdTșd→TitluȘD: <IdTșd>; TitluȘD→IdTșd: <TitluȘD>;

IdTș→TitluȘ: <IdTș>; TitluȘ→IdTș: <TitluȘ>;

IdSb→Subdiviz: <IdSb>; Subdiviz→IdSb: <Subdiviz>;

IdAA→IdFA: <IdAA, IdAAGenericDataÎDataTNrPartIdNivIdOșIdAGNivelOrașDenG…>;

IdAA→Generic: <IdAA, IdAAIdFADataÎDataTNrPartIdNivIdOșIdAGFormaANivelOraș..>;

IdAA→DataÎ: <IdAA, IdAAGenericIdFADataTNrPartIdNivIdOșIdAGFormaANivelOraș..>;

IdAA→DataT: <IdAA, IdAAGenericIdFADataÎNrPartIdNivIdOșIdAGFormaANivelOraș..>;

IdAA→NrPart: <IdAA, IdAAGenericIdFADataÎDataTIdNivIdOșIdAGFormaANivelOraș..>;

IdAA→IdNiv: <IdAA, IdAAGenericIdFADataÎDataTNrPartIdOșIdAGFormaAOrașDenG..>;

IdAA→IdOș: <IdAA, IdAAGenericIdFADataÎDataTNrPartIdNivIdAGFormaANivelDenG.>;

IdAA→AG: <IdAA, IdAAGenericIdFADataÎDataTNrPartIdNivIdOșFormaANivelOraș>;

IdFAGenericDataÎDataT→IdAA: <IdFAGenericDataÎDataTFormaA>;

IdAȘ→IdAA: <IdAȘ, IdAȘIdOrgOrganiz>;

IdAȘ→IdOrg: <IdAȘ>; IdAȘIdAAGenericIdFADataÎDataTNrPartIdNivIdOșIdAGFormaANivelOrașDenGAnENrE…>;

IdAAIdOrg→IdAȘ: <IdAAIdOrg>; IdAAIdOrgOrganizGenericIdFADataÎDataTNrPartIdNivIdOșIdAGFormaANivelOrașDenG…>;

IdNiv→Nivel: <IdNiv>; Nivel→IdNiv: <Nivel>;

IdOrg→Organiz: <IdOrg>; Organiz→IdOrg: <Organiz>;

IdFA→FormaA: <IdFA>; FormaA→IdFA: <FormaA>;

După cum se observă, mulțimea de dependențe funcționale F nu conține dependențe funcționale redundante, deci Fn=F.

2. Construim acoperirea redusă în stânga Fr a mulțimii Fn:

IdFPIdAG→IdAP

FnIdFP→IdAP (IdFP)+=<IdFP, IdFPFormaP>

FnIdAG→IdAP (IdAG)+=<IdAG, IdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPag,

IdAGDenGAnENrEIdEdIdTgIdOșCzuIsbnColTNrPagEdituraTipografiaOraș>;

DenGAnENrE→IdAG

FnDenG→IdAG (DenG)+=<DenG >;

FnAnE→IdAG (AnE)+=<AnE >;

FnNrE→IdAG (NrE)+=<NrE>;

CzuIsbn→IdAG

FnCzu→IdAG (Czu)+=<Czu>;

FnIsbn→IdAG (Isbn)+=<Isbn>;

IdAPIdAut→IdP

FnIdAP→IdP (IdAP)+=<IdAP, IdAPIdFPDenPColAIdAGFormaPDenG…>

FnIdAut→IdP (IdAut)+=<IdAut, IdAutNumeIdTșdIdTșIdSbTitluȘDTitluȘSubdiviz>;

IdFAGenericDataÎDataT→IdAA

FnIdFA→IdAA (IdFA)+=<IdFA, IdFAFormaA>;

FnGeneric→IdAA (Generic)+=<Generic>;

FnDataÎ→IdAA (DataÎ)+=<DataÎ>;

FnDataT→IdAA (DataT)+=<DataT>;

IdAAIdOrg→IdAȘ

FnIdAA→IdAȘ (IdAA)+=<IdAA, IdAAIdFAGenericDataÎDataTNrPartIdNivIdOșIdAG..>

FnIdOrg→IdAȘ (IdOrg)+=<IdOrg, IdOrgOrganiz>;

Obținem că mulțimea de dependențe funcționale Fn este o mulțime redusă în stânga, adică Fr=Fn.

3. Împărțind mulțimea Fr în clase de echivalență, obținem:

EFr(IdAP)={IdAP→IdFP, IdAP→DenP, IdAP→ColA, IdAP→IdAG, IdFPIdAG→IdAP};

EFr(IdAG)={IdAG→DenG, IdAG→AnE, IdAG→NrE, IdAG→IdEd, IdAG→IdTg, IdAG→IdOș, IdAG→Czu, IdAG→Isbn, IdAG→ColT, IdAG→NrPag, DenGAnENrE→IdAG, CzuIsbn→IdAG };

EFr(IdP)={IdP→IdAP, IdP→IdAut, IdAPIdAut→IdP};

EFr(IdEd)={IdEd→Editura, Editura→IdEd};

EFr(IdTg)={IdTg→Tipografia, Tipografia→IdTg};

EFr(IdOș)={IdOș→Oraș, Oraș→IdOș};

EFr(IdFP)={IdFP→FormaP, FormaP→IdFP};

EFr(IdAu)={IdAut→Nume, IdAut→IdTșd, IdAut→IdTș, IdAut→IdSb, Nume→IdAut};

EFr(IdTșd)={IdTșd→TitluȘD, TitluȘD→IdTșd};

EFr(IdTș)={IdTș→TitluȘ, TitluȘ→IdTș};

EFr(IdSb)={IdSb→Subdiviz, Subdiviz→IdSb};

EFr(IdAA)={IdAA→IdFA, IdAA→Generic, IdAA→DataÎ, IdAA→DataT, IdAA→NrPart, IdAA→IdNiv, IdAA→IdOș, IdAA→IdAG, IdFAGenericDataÎdataT →IdAA};

EFr(IdAȘ)={IdAȘ→IdAA, IdAȘ→IdOrg, IdAAIdOrg→IdAȘ};

EFr(IdFA)={IdFA→FormaA, FormaA→IdFA};

EFr(IdNiv)={IdNiv→Nivel, Nivel→IdNiv};

EFr(IdOg)={IdOrg→Organiz, Organiz→IdOrg}.

S-au obținut 16 clase de echivalență.

4. Conform algoritmului, trebuie să construim mulțimea J de dependențe funcționale, dar mulțimea J=Ǿ, deoarece nu există în mulțimea Fr dependențe care ar satisface condițiile de formare a mulțimii J descrise în algoritm.

5. Obținem următoarea schemă a bazei de date Db={IdAP IDFP DenP ColA IdAG, IdAG DenG AnE NrE IdOș IdEd IdTg Czu Isbn ColT NrPag, IdP IdAP IdAut, IdOș Oraș, IdEd Editura, IdTg Tipografia, IdFP FormaP, IdAut Nume IdTșd IdTș IdSb, IdTșd TitluȘD, IdTș TitluȘ, IdSb Subdiviz, IdAA IdFA Generic DataÎ DataT NrPart IdNiv IdOș IdAG, IdAȘ IdAA IdOrg, IdFA FormaA, IdNiv Nivel, IdOrg Organiz} (vezi anexa nr.4).

Pentru a reprezenta informația de ieșire, vor fi elaborate diverse forme de reprezentare a informației după anumite criterii, și anume:

Publicațiile unui autor (se va indica perioada);

Publicațiile unei subdiviziuni (se va indica perioada);

Publicațiile dintr-o perioadă anumită;

Publicațiile de o anumită formă (se va indica perioada);

Numărul publicațiilor pe ani;

Activitățile științifice de o anumită formă (se va indica perioada);

Activitățile științifice organizate de Academia de Poliție (se va indica perioada);

Activitățile științifice la care a participat Academia de Poliție (se va indica perioada);

Numărul de persoane la catedre, după titlurile științifico-didactice și științifice…

4.4. Descrierea funcționării sistemului (programului)

Programul dispune de meniuri bine structurizate și un set butoane rapide asemănătoare ca la majoritatea programelor sistemului de operare Windows. Butoanele rapide ce sunt plasate în bara cu instrumente sunt destinate pentru accesarea rapidă a comenzilor din meniu, astfel, mărind eficacitatea de lucru (fig.1).

Bara de meniuri include meniurile: Introducere, Extragere și Ajutor. Folosind opțiunile acestor meniuri și casetele de dialog care se afișează la activarea lor, utilizatorul poate accesa toate facilitățile acestui program, lansând comenzile respective. Opțiunile unui meniu se vor afișa, ca de obicei, în rezultatul activării acestora, prin clic cu butonul stâng al șoricelului (fig.2).

La activarea submeniului Publicații științifice din meniul Introducere sau activând butonul respectiv din bara cu instrumente, se afișează o casetă de dialog (fig.3). În caseta respectivă pot fi introduse și vizualizate datele despre publicațiile științifice ale Academiei de Poliție, în dependență de forma publicației aleasă. Câmpurile din compartimentul Atribute particulare vor fi completate doar pentru aricole științifice, teze științifice de la conferințe etc. Autorul/autorii unei publicații științifice se aleg din compartimentul Autori (partea stângă) și se trec cu ajutorul butonașului pus la dispoziție în partea dreaptă.

Butonașul Nou este adăugat pentru un nou autor, care nu este inclus în baza de date, și deci, nu este prezent în lista din care noi putem alege autorii. La activarea lui se va afișa o casetă de dialog în care putem introduce numele și celelalte atribute pentru autor (vezi fig.4)

Datele despre activitățile științifice organizate de către Academie sau la care a participat reprezentanți ai Academiei pot fi introduse și vizualizate în caseta care se afișează la activarea opțiunii Activități științifice din meniu, sau prin activarea butonului respectiv din bara cu instrumente.

Butonul Nou are aceeași semnificație ca și în cazul publicațiilor științifice, numai că aici se va afișa caseta pentru introducerea organizatorilor, asemănătoare cu cea din fig.6. Astfel de casete se afișează și în cazurile când din lista de opțiuni afișate spre alegere (de exemplu Orașele unde s-au publicat publicațiile sau s-au organizat activitățile științifice) lipsește valoarea dorită. Această casetă ne va permite să adăugăm valoarea nouă (un oraș nou) în baza de date, apoi s-o alegem din lista respectivă.

Meniul Extragere ne permite, de asemenea, să alegem diferite opțiuni de extragere a datelor din baza de date. Prin alegerea opțiunilor respective, la ecran se cor afișa casete de dialog caracteristice, în care utilizatorii vor indica parametrii după care se va afișa datele în formă de raport.

Submeniul Publicații științifice dinmeniul Extragere ne va permite să afișăm publicațiile după autor, după formă, după subdiviziune, precum și combinația acestsor opțiuni. În casetă putem, de asemenea indica perioada de timp, după care se afișează datele. Asemănător se procedează și pentru cazurile când dorim să extragem date despre activitățile științifice (vezi fig.8).

Programul oferă posibilitatea extragerii autorilor din baza de date după titlul lor științifico-didactic și după gradul științific pe care îl posedă (fig.9).

Există multe cazuri, când o publicație constă dintro culegere de articole științifice sau teze științifice de la conferințe, la fel multe articole sunt publicate în diverse reviste periodice. În lucrarea dată s-a luat în considerație și acest lucru. Pentru a extrage din baza de date materialele unei publicații, se activează opțiunea Materialele unei publicații din meniul Extragere sau butonul respectiv din fereastra principală. Ca rezultat se afișează caseta de dialog din fig.10, în care utilizatorul alege din lista prezentată publicația dorită, anul și numărul publicației, revistei etc..

La elaborarea programului respectiv s-a ținut cont și de securitatea datelor din baza de date. Utilizatorii nu vor putea adăuga, șterge sau modifica datele fără a cunoaște parola, care le va permite efectuarea acestor operații.

5. Partea economică

5.1. Piața software

Este foarte important de înțeles faptul că, o piață cum este cea a software-ului, cea mai puternică piață la ora actuală, funcționează după niște reguli foarte simple. Nu se produce de dragul producției sau a produsului în sine, indiferent cât de frumos și perfect este, se produce numai și numai dacă există o necesitate ce impune produsul respectiv. Acest fapt se reflectă atât în industrie cât și în cercetare. Energia investită într-un produs software, implicând atât faza de proiectare, implementarea în sine cât și caracteristicile principale ale acestuia, este direct proporțională cu miza finală a proiectului. Acest lucru este deseori neglijat de designerul entuziast, puternic impulsionat de frumusețea potențială a produsului, «uitând» pe parcurs finalitatea reală a proiectului respectiv.

O altă caracteristică determinantă a unor importante segmente ale pieței software este în prezent procentul majoritar de consumatori neprofesioniști, fapt ce implică mai multe lucruri. În primul rând este vorba de creșterea importanței imaginii produsului, atât la nivel de prezentare în reclame și spoturi publicitare cât și la nivel de interfață cu utilizatorul. Înțelegerea rapidă a acestei reguli poate duce la un design orientat către utilizatorul final (end-user). Astfel s-au putut promova sisteme uriașe, mediocru proiectate, dar cu o interfață. Această abordare, la rândul ei, a impus noi linii de design tehnologic nu neapărat mai bune sau mai eficiente, ci mai degrabă punând accentul pe compatibilitate cu produse mai vechi. Un al doilea aspect al procentajului majoritar de consumatori neprofesioniști este apariția fenomenului de concurență neloială practicată de către unele companii extrem de mari.

Din această cauză voi încerca să pătrund foarte rapid în domeniul definit de noțiunea de software architecture prin prezentarea unor perspective modeme asupra procesului de analiza și proiectare a unui produs software având ca finalitate determinarea și maximizarea eficientei acestuia.

Pentru început vom defini noțiunea de arhitect. Arhitectul unui sistem software este privit ca fiind acea autoritate ce determină structura inițială a sistemului, acceptă ulterior de la o serie de părtași la proiect în ansamblu și elaborează o structură de bază a sistemului. Structura de bază include modularizarea sistemului, specificarea interfețelor inteme și exteme din cadrul acestuia, definirea comportamentelor modulelor componente la nivel funcțional, specificând eventual și unele detalii la nivel de implementare etc. Arhitectul este cel care răspunde de funcționalitatea sistemului în ansamblu precum și de orice probleme derivate ce își pot avea originea în designul global al sistemului.

Odată definite specificațiile generale, ajungem la etapa de implementare a proiectului, de către echipă, iar pe parcursul implementării se pot deseori redefini specificații interne sau chiar generale, caz în care arhitectul propune noi variante globale ale sistemului. În esență finalitatea acestei faze în design este concretizată într-un sistem urmând ca acesta să fie supus unor etape ulterioare de dezvoltare.

Un alt concept modem este cel reprezentat de noțiunea de acționar (stakeholder) care, în cadrul proiectării softului (software design) reprezintă o abstractizare pentru fiecare element ce participa direct sau indirect la elaborarea inițială a unui proiect software. Această noțiune este o generalizare a noțiunii de beneficiar utilizată în trecut. Astfel, acționari {stakeholder) la un proiect pot fi beneficiari, designeri, oameni de marketing, manageri etc.

În analiza tradițională a unei arhitecturi software se pornește de la construirea unor coeficienți ce vor defini arhitectura din mai multe puncte de vedere, urmând ca apoi, utilizând ponderarea cestor coeficienți să se construiască indici globali de eficiență și satisfacere a specificațiilor. Carențele acestei metode, elegantă de altfel, constau în imposibilitatea corelării intuitive a coeficienților cu comportări palpabile în cazul unei exploatări reale.

Acest neajuns trebuie de înlăturat și se pornește de la ideea că arhitectura unui sistem software nu poate fi judecată decât în cazul unei utilizări reale a sistemului, și că în acel caz sistemul își poate evidenția cu adevărat calitățile sau defectele corespunzătoare arhitecturii.

În acest sens, are loc definirea un set de scenarii virtuale ce reprezintă în esență posibile evoluții reale în utilizarea sistemului în sine. Scenariile sunt în principal propuse de către acționari (stakeholder), urmând apoi o ierarhizare a importanței acestora în funcție de relevanța reală. În urma ierarhizării, se preiau cele mai relevante scenarii și sunt supuse spre analiză arhitectului care va trebui să definească comportarea sistemului și modificările necesare pentru fiecare scenariu în parte. În urma unei analize ulterioare foarte simple, bazată pe numărul și tipul de modificări necesare în modulele componente ale sistemului, numărul și tipul de modificări necesare pentru fiecare componentă în parte, prioritățile globale definite inițial (de exemplu, portabilitate pe mai multe platforme predefinite), se poate defini un coeficient relevant pentru nivelul calitativ al arhitecturii sistemului respectiv.

Deseori acest pas al analizei arhitecturii unui sistem este neglijat de către firmele grăbite să își vadă proiectul dus la un «bun» sfârșit, fapt care de multe ori stă la baza unor dificultăți ulterioare extreme în ceea ce privește posibilitățile de modificare sau îmbunătățire ale sistemului în ansamblu. Să mai accentuăm doar că analiza este o etapă extrem de importantă în cadrul oricărui design de software modem.

Revenind la arhitect, în etapele inițiale ale designului, el trebuie să preia informații de la factori extrem de diverși (în principal de la acționari), să aibă calități deosebite în domeniul comunicării cu factorii umani implicați în proiect, să poată transpune o viziune într-un model funcțional coerent ce va putea fi la rândul său transpus într-o implementare reală. Datorită acestor calități deosebite, greu de găsit la un om, arhitectul este deseori înlocuit cu o echipă de arhitecți ce împreună fac față mai bine necesităților (de amintit, de asemenea, că arhitectul este cel mai bine plătit angajat al unei firme

care se respectă.)

O zicală în domeniu afirmă că dacă în cadrul unei firme nu se poate afirma cu certitudine cine este arhitectul principal atunci firma respectiva are mari șanse de a da faliment curând. Oricum ar fi, este evident faptul că în cadrul proiectelor mari și a celor foarte mari, cum sunt majoritatea aplicațiilor modeme de anvergura, elementul esențial îl constituie coeziunea și unitatea abordării designului, începând chiar cu etapele inițiale. O abordare greoaie care încearcă să se modeleze pe un vot majoritar s-a dovedit în timp, că duce spre o construcție greu de implementat, cu mari deficiente funcționale.

Un exemplu de acest tip este standardul CORBA. CORBA a pornit ca un proiect ce urma să fie definit împreună de către arhitecții firmelor ce compuneau suportul industrial pentru CORBA. Timp de mult timp CORBA a suferit «îmbunătățiri» și retușuri. Rezultatul final este în continuare un sistem greoi, cu redundanțe funcționale majore. Acest lucru nu înseamnă că sistemul nu oferă facilități deosebite și necesare totodată. Din punct de vedere al arhitecturii însă, acesta lasă de dorit.

5.2. Marketing

Una dintre ideile care trebuie să călăuzească în permanență designerul (proiectantul) modern de software este aceea că: «etichetele» asignate de-a lungul timpului unor concepte se modifică extrem de des însă ideile bune aflate în spatele acestora sunt puține și foarte simple în esență. Separarea elementelor de marketing de ceea ce aduce cu adevărat un produs nou poate duce la descoperiri deseori frustrante.

Vechea zicală «reclama este sufletul comerțului» își găsește locul mai mult ca oriunde într-o piață orientată pe IT {Information Technology) unde chiar obiectul major de tranzacționare îl reprezintă informația și uneltele de prelucrare ale acesteia. Advertising, în sensul modem al cuvântului nu este un corespondent simplu și direct al reclamei așa cum ne-o imaginăm cu toții

privind spoturile publicitare mai mult sau mai puțin puerile din mediile audio și TV. Procesul de advertising modem pornește cu, și se bazează pe, elemente definite încă înaintea conturării unui eventual produs final vandabil. Deseori piețele modeme vehiculează entități virtuale cu o valoare de potențial imens. Corespondentul real este deseori doar o idee sau o imagine bine pusă la punct a unui produs viitor sau prezent, dar mediocru.

Un exemplu ar fi firme ca Netscape Communications care au pornit prin a oferi un produs gratuit (deci doar imagine) și în foarte scurt timp au penetrat piața IT, segmentul browserelor Web, deținând și în prezent un important procent al acestuia.

Fără a intra în detalii, trebuie reținut faptul că, deseori, în piețele modeme imaginea creată a produsului este cea care-1 propulsează înainte incluzând chiar și designul acestuia. Acest fapt, aparent îngrijorător, creează un paradox greu de înțeles de mulți în prezent. Astfel inginerul software va asculta sfaturile oamenilor care se vor ocupa de imaginea produsului; iar aceștia vor asculta afirmațiile lui în ceea ce privește funcționalitățile produsului.

Concluzionând: nu scrieți linii de cod ci creați o imagine! Este un alt mod de a spune că perspectiva de ansamblu asupra unui produs în general este mult mai importantă decât implementarea produsului la un moment dat.

5.3. Designul la nivel de implementare

Vom intra aici în detalii ce condiționează designul la nivel de implementare pentru un sistem software.

Am menționa de la început faptul că traficul informațional între designer (developer/arhitect) și clienții/acționarii sistemului considerat se va efectua în majoritate utilizând tehnici electronice cum ar fi email, fax sau online chat. Acest fapt impune dintru început aplicarea unui șablon de proiectare (design pattem) de tip skeleton (top-down) prin construirea unui sistem ce își propune o funcționalitate implementată modular, susținută de un schelet inițial, dezvoltat foarte rapid.

Marea majoritate a proiectelor modeme sunt condiționate din mai multe puncte de vedere ce duc în final la constrângerea, aparent neimportantă, de a atinge un stadiu funcțional cât mai rapid. Condiționările sunt în primul rând mobilitatea extrem de crescută a pieței atât în ceea ce privește balanța cerere-ofertă cât și în ceea ce privește tehnologia în sine. Un designer modem nu își va permite luni de zile de studiu în ideea obținerii unei arhitecturi optime deoarece riscul ca sistemul său extrem de fiabil și optim să devină învechit chiar în acele luni de studiu, este foarte mare. O a doua condiționare provine de la potențialul concurenței care desigur cunoaște de asemenea nevoile curente ale pieței și va dezvolta produse similare ca-n în același timp. Ne vom rezuma la aceste două exemple de condiționări, care impun rapiditatea dezvoltării unui sistem funcțional chiar și în varianta skeleton.

Modularitatea este impusă și din multe alte puncte de vedere. Unul dintre ele ar fi posibilitatea reutilizării unor module dezvoltate anterior sau de către terți în cadrul sistemului, lucru ce ar optimiza

în ansamblu investiția umană în proiect. Un alt factor ar fi posibilitatea specificării unor interfețe inter-module ce vor putea fi apoi puse în corespondență cu diferite echipe (vezi mai jos) asigurând astfel și o coerență a procesului de dezvoltare propriu-zis.

Desigur sistemul nostru software își propune să ofere o cotă de portabilitate maximă și asta nu înseamnă nici pe departe numai posibilitatea rulării codului executabil pe mai multe plaftorme/arhitecturi hardware/software într-un mod identic. Sensul modem al noțiunii de portabilitate este dat de o serie de calități și restricții impuse produsului respectiv. Începând cu sistemul de documentare și help online, posibilitatea auto configurării în funcție de platforma curentă și optimizarea aplicației pentru a rula cât mai eficient în acel mediu și terminând cu banala afirmație că aplicația va trebui să ofere o comportare și o funcționalitate pseudo-identică pe toate platformele hardware/software în cauză, toate aceste elemente participă la definirea noțiunii de portabilitate.

O altă calitate a sistemului nostru, aparent în contradicție cu cea evocată anterior (portabilitatea) este capacitatea de automodelare și integrare într-un mediu format din aplicații ne portabile, vechi, monolitice, greoaie însă folosite de o mare majoritate de acționari ce își doresc utilizarea acestora în continuare chiar și după apariția sistemului nostru superb, modular, portabil și funcțional. Integrarea este poate una dintre cele mai controversate și greu de implementat calități însă și cea mai apreciată de către end-useri (utilizatorii finali sunt și ei acționari în cadrul sistemului). În acest sens tot mai multe din tehnologiile modeme utilizate în prezent se orientează către facilități portabile de integrare cu mediul gazdă al aplicației/sistemului dezvoltat.

Poate una dintre cele mai importante calități ce ne-o propunem în cadrul sistemului nostru este aceea care determină diferența dintre un simplu program scris în grabă pentru satisfacerea unui client și un sistem software dezvoltat cu o anume maturitate. Modularitatea și posibilitatea reutilizării modulelor în cadrul altor sisteme fac necesară o dezvoltare bazată pe o documentare completă a fiecărui pas de dezvoltare, a funcționalității fiecărui modul precum și a detaliilor și funcționalității fiecărei interfețe oferite de modulele din cadrul sistemului în ansamblu.

Etapa finală a dezvoltării sistemului nostru este desigur cea de implementare propriu-zisă. Aceasta este compusă din mai multe sub etape ce asigură în ansamblu și continuitatea produsului. Ne vom ocupa aici de elemente cum ar fi definirea specificațiilor, termene limită (deadlines) și stabilirea lor, sistemul de versiuni și subversiuni, construirea echipelor și interfațarea, uneltele utilizate, sistemul de documentație și în fine facilitatea de mentenanță (incluzând aici testarea, depanarea precum și întreținerea pe termen mediu și lung), o calitate necesară și extrem de vitală în

cadrul oricărui sistem software.

Definirea inițială a specificațiilor se poate deseori suprapune cu etapa de design arhitectural în cazul în care arhitectul va fi și cel ce va coordona dezvoltarea implementării în sine. Aici se stabilesc în principal elementele de detaliu mediu la nivelul modulelor precum și specificarea și înghețarea parțială a interfețelor funcționale din cadrul sistemului. În definirea specificațiilor vom trece de la modelul adoptat în analiza arhitecturii sistemului în sine, la un model intuitiv mai apropiat, considerând aici doar acei acționari ce pot fi cu adevărat caracterizați prin termenul de beneficiari ai sistemului. Aceștia vor stabili principalele funcționalități oferite de aplicație prezentând apoi arhitectului setul inițial al specificațiilor globale. Jobul arhitectului este de a integra aceste cerințe într-un model coerent având și opțiunea unor eventuale retușuri și eliminări a elementelor redundante sau imposibil de realizat.

Esențial este ca în această fază să fie definite, de comun acord între arhitect și beneficiari, cât mai multe aspecte legate de structură, dar mai ales de funcționalitatea aplicației. Specificațiile inițiale sunt un pas foarte important deoarece determină durata estimativă a proiectului precum și manopera necesară, deci în final costurile de dezvoltare. De aceea, este extrem de important ca această etapă să se desfășoare extrem de atent și păstrând un echilibru constant între posibilitățile reale și cererile beneficiarului.

Experiența arată că, în timp, pe măsură ce implementarea avansează, specificațiile inițiale și mai ales cerințele beneficiarului pot varia foarte mult și acest lucru nu este în beneficiul proiectului în ansamblu deoarece implică mai multă muncă, mai mult timp și în mod clar posibilitatea apariției incoerențelor în proiectul rezultat final. Recomandarea este de a definitiva specificațiile funcționale inițiale printr-un document ce va fi păstrat pentru referința ulterioară. Orice modificare va interveni la aceste specificații se va face, similar, printr-un document.

Imediat după definitivarea specificațiilor, arhitectul va construi rapid un draft al arhitecturii inițiale a sistemului, pe baza căruia, împreună cu șeful de proiect (șef al echipei de programatori), va estima niște cote de deviz pentru proiect incluzând aici termenele limită (deadlines), durata (duration) precum și factorul număr de ore / programator necesare, factor determinant în costurile de dezvoltare. Trebuie pus accentul pe atributul estimativ ce va trebui explicat în această faza și beneficiarilor, nefiind posibilă determinarea în avans a tuturor elementelor surpriză de care vom avea parte pe parcursul dezvoltării în sine.

Există o «glumă» ce recomandă unui dezvoltator de soft să comunice beneficiarului întotdeauna un timp estimativ dublu față de cât ar considera în realitate că durează dezvoltarea proiectului respectiv, prevăzând astfel un timp auxiliar pentru orice surprize neașteptate ar putea să apară. Din nefericire concurența acerbă face acest lucru aproape imposibil însă experiența arată că

este de preferat pierderea unui contract datorită unei estimări de timp mari (dar cu păstrarea unui renume bun) decât întârzierea la termen ce va aduce sigur o pierdere a renumelui și să nu uitam că principalul atu în această lume a IT este o imagine cât mai bună și atrăgătoare.

Odată stabilite niște termene de predare estimative, un alt element de considerat este cel al surprizelor ce ne vor aștepta cu siguranță pe parcursul dezvoltării proiectului. Nu există proiect software ce ar putea scăpa de aceste surprize. Ele pot lovi din direcții diferite și chiar simultan, începând cu probleme la nivelul unor dificultăți de programare, sănătatea unui programator important, hackerul ce pătrunde și șterge fișiere, expirarea licenței uneltelor de dezvoltare utilizate. Iată numai câteva dintre cele mai neașteptate întâmplări ce pot apare. Dar surprize vor apare și vor apare așa de regulat și sigur încât termenul de surpriză deseori nu își are rostul. Și cum una dintre regulile lui Murphy spune că dacă poți avea o surpriză plăcută și una neplăcută atunci în majoritatea cazurilor o vei avea pe cea neplăcută.

În cazul apariției unor elemente neprevăzute în dezvoltarea proiectului, elemente ce ar putea influența într-un mod sau altul bunul mers al proiectului și mai ales vor aveam impact și asupra beneficiarului într-un fel sau altul, de exemplu prin necesitatea prelungirii termenului contractului, sfatul nostru este de a comunica cât mai rapid cu beneficiarul împărtășindu-i problemele rapid și fără ocolișuri. Acest lucru va fi sigur apreciat. Nu lăsați lucrurile să dreneze sperând că veți găsi o soluție miraculoasă în ultimul sfert de oră înainte de termen. Asemenea soluții nu există și dacă apar sunt doar excepții de la regulă. Beneficiarul va aprecia mult mai mult faptul că își poate defini mai bine pașii următori cunoscând eventualele întârzieri. Comunicarea cu acesta este esențială și acest lucru nu trebuie uitat pe parcursul întregului proiect.

5.4. Sistemul de revizii

Un element esențial, mai ales în cazul lucrului în echipă asupra unor sisteme modulare, îl reprezintă definirea și impunerea unui sistem de revizii incluzând versiuni, revizii și modificări. Acest sistem va trebui gândit, odată cu arhitectura sistemului, în așa fel încât să se asigure un set minimal de calități: excluderea mutuală, paralelism, distribuire maximă posibilă. Sistemul fiind modular și distribuirea joburilor fiind deja făcută unor echipe specializate astfel încât fiecare dintre ele va modifica la un anumit moment unul sau mai multe module dar niciodată două echipe nu vor încerca modificarea aceluiași modul funcțional, sistemul de revizii utilizat va fi unul ierarhizat, pornind de la asigurarea unei versiuni incrementale fiecărui modul în parte, fiecărui subsistem format din mai multe module și în ansamblu sistemului global. De preferat este ca modificările necesare în cadrul unui anumit modul din cadrul sistemului să fie efectuate de echipa ce se ocupă în mod curent de

respectivul modul. De asemenea va trebui gândită o schemă prin care comunicația inter-echipe să fie cât mai eficientă făcând astfel posibil un timp de răspuns maximal din partea unei echipe solicitate pentru a modifica un anumit modul.

A nu se uita că, cel puțin în faza de dezvoltare, sistemul de revizii are un rol foarte important, mai ales în evitarea erorilor și a deadlock-ului precum și în menținerea coerenței sistemului în ansamblu. De aceea, impunerea sa nu trebuie să fie neconcordantă cu acest scop. Pe de altă parte sistemul fluxului informațional intern, incluzând și versiunile, va trebui gândit în așa fel încât să poată fi adoptat de toate echipele participante la procesul de dezvoltare. În acest sens recomandarea noastră este ca notațiile și numerotarea utilizată să fie uniformizată cel puțin la nivelul modular, fiind în prealabil stabilită de comun acord cu toate echipele participante.

Jurnalul modificărilor. Un element important este, de asemenea, menținerea a ceea ce se numește change-log. Acesta este un jurnal corespunzător fiecărui modul distinct în cadrul sistemului, care definește modificările aduse în timp modulului respectiv, corelate cu versiunea și data/ora curentă a fiecărei modificări. Acest jurnal se dovedește extrem de util în situația apariției unor noi erori datorate eventualei adăugări de facilități unor module. Se vor putea astfel determina rapid ce modificări au fost aduse modulelor în cauză în perioada considerată, și se va putea astfel localiza sursa erorilor.

Sistemul de versiuni. Voi spune aici puțin despre sistemul de versiuni la nivelul sistemului global, așa numita versiune a aplicației. În acest caz elementele deterministe nu mai sunt doar cele legate de menținerea coerenței interne etc. Din ce în ce mai mult, versiunile externe tind să constituie elemente legate de marketing și să eticheteze într-un anumit fel produsul respectiv. Un exemplu bun ar fi Microsoft care, din pură strategie de marketing, și-a botezat Windows versiunea internă 4.0.xxxx în Windows95 aplicând astfel o ștampilă de timp produsului impunând achiziționarea unui produs nou cât mai des (vezi Windows 98).

De aceea sistemul de versiuni externe rămâne mai mult la latitudinea departamentului de marketing decât a arhitectului. Singurul fapt evident este că versiunea asigurată acestuia va trebui în timp să evidențieze evoluția produsului (în bine!). Software-ul ca și alte domenii științifice, suferă de aceeași boală ce afectează orice om de știință încă din copilărie: de ce să spui ceva simplu când poți s-o spui mult mai complicat. Ei bine nici noi nu am scăpat de acest stigmat și în acest sens am inventat notațiile prealpha, alpha, beta testing, beta, stable etc. Toate aceste notații sunt referiri la stadiul de avansare al unui produs din punctul de vedere mai ales al fiabilității și stabilității în utilizare și mai puțin din punctul de vedere al funcționalității sale directe.

Astfel o aplicație versiunea 2.0 prealpha este un sistem care în principiu oferă o funcționalitate crescută față de versiunea 1.0, însă stabilitatea sa lasă foarte mult de dorit implicând chiar și implementarea unor facilități ce sunt prevăzute însă în mod sigur. Practic sistemul se mai află încă în faza de design-implementare. Ajungerea la stadiul 2.0 alpha arată ca sistemul respectiv a evoluat, implementează totalitatea facilităților expuse în specificații însă nu a fost testat. Beta testing se consideră a fi faza ce urmează unei testări interne, preliminare, a produsului implicând testări ulterioare mult mai complexe, implicând eventual și developeri externi ce se vor numi în acest caz beta testers. Fazei de beta testing îi urmează faza de reîntoarcere la testări interne (beta), utilizând informațiile colectate în urma beta testing-ului. Urmează apoi lansarea produsului în stadiul stable, din acest moment produsul fiind considerat apt pentru a fi lăudat pe piață. Noțiunea de final este deseori un sinonim pentru stable iar alteori marchează trecerea de la o versiune majoră la alta prin etichetarea produsului ca fiind ultimul produs aparținând clasei definite de versiunea majoră respectivă. Dar să nu uităm niciodată că toate acestea sunt simple denumiri și etichete.

Documentare. Etapa de dezvoltare fiind în curs de încheiere, specificațiile fiind într-o fază avansată de definitivare, produsul într-o stare funcțională (eventual prealpha) se impune demararea procesului de documentare a aplicației în sine. Nici un proiect modem nu va supraviețui fără un sistem de documentație și de help online, bine pus la punct și intuitiv. Cu cât piața țintă este mai largă cu atât rolul și importanța documentației sunt mai evidente. Făcând parte de asemenea din imaginea de ansamblu a produsului (nu uitați că imaginea se vinde în IT) acest task nu trebuie neglijat și nici lăsat pe mâna unor neprofesioniști.

De asemenea, un alt aspect este cel al integrării documentației on-line prin intermediul unui sit web împreună cu eventualul mecanism de distribuire a unor versiuni demonstrative ale produsului. Este o metodă deosebit de apreciată atât de potențialii beneficiari, de utilizatorii curenți dar și de hackerii dornici de software gratis sau ușor de spart. Compromisul trebuie făcut! Un lucru este sigur: fără sit web o firmă de software nu prea mai poate supraviețui.

Am discutat anterior despre importanța suportului și mentenanței oferite pentru un anumit produs atât pe termen scurt cât și pe termen mediu și lung. Un beneficiar își dorește o asigurare că produsul pe care îl comandă/cumpără astăzi îl va putea folosi și peste doi ani și în plus va putea avea acces și la noi tehnologii integrate în cadrul sistemului respectiv pe măsura trecerii timpului. În acest sens se poate face o analogie cu industria auto unde se observă existența unor ateliere specializate pentru anumite tipuri de mașini mult timp chiar și după ce tipurile respective au ieșit din liniile de producție.

Marile firme de software abordează această problemă, elegant, prin asignarea unei echipe specializate pentru un anumit produs, ce va avea ca sarcină principală mentenanța produsului respectiv, în perioada de până la dezvoltarea unor noi versiuni sau chiar și după oprirea dezvoltării produsului respectiv. Echipa ce se ocupă de această întreținere, în principiu, va corecta erori minore în software, documentație etc. și în plus va raporta erori importante și modificări necesare arhitectului principal sau șefului de proiect în cazul în care proiectul este încă în faze de dezvoltare.

În cazul unor proiecte mai mici, sau realizate cu buget mic, problema se poate de asemenea rezolva prin includerea în costurile inițiale și a specificării duratei și tipului de suport oferit pentru produsul respectiv.

5.5. Situația curentă

La momentul actual evidența activității științifice din cadrul Academiei de Poliție ,,Ștefan cel Mare” se realizează într-o mulțime de fișiere separate. Nu este asigurată integritatea datelor, datele din fișiere nefiind organizate într-un mod rezonabil, ceea ce duce la apariția anomalii de actualizare a datelor. Nu este asigurată siguranța păstrării și securitatea datelor.

Necesitatea proiectării implementării în practică a unui astfel de sistem reiese din răspunsurile date de cercetătorii științifici din cadrul Academiei la câteva întrebări.

Chestionar cu cercetătorii științifici din cadrul Academiei de Poliție ,,Ștefan cel Mare”

Întrebarea nr.1 Care ar fi menirea (rolul) unui sistem informatic de evidență a activității științifice?

Răspuns (Bejan Octavian, cercetător științific în Centrul de cercetări științifice al Academiei de Poliție): Un eventual sistem informatic ar trebui să servească la o organizare mai simplă și mai eficientă a activității științifice, răspunzând următoarelor cerințe majore:

să stocheze cât mai multă informație;

să faciliteze activitatea de dirijare a lucrului științific;

să permită obținerea rapidă de informații despre diverse aspecte ale activității științifice;

să faciliteze întocmirea dărilor de seamă, a notelor informative etc. privind activitatea științifică (ca proces, ca realizări etc.);

să ofere o imagine de ansamblu și totodată, amplă despre activitatea științifică în instituție, în subdiviziuni etc.;

să simplifice contactele cu alte subdiviziuni.

Întrebarea nr.2 Numiți cauzele implementării sistemului informatic de evidență a activității științifice în practică?

Răspuns (Valeriu Țurcan, cercetător științific în Centrul de cercetări științifice al Academiei de Poliție): Probabil, dacă putem vorbi aici de cauze, cea mai importantă ar fi inexistența unui astfel de sistem în cadrul Academiei de Poliție ,,Ștefan cel Mare” la etapa actuală. Această inexistență creează dificultăți majore în obținerea și circuitul informației atât în cadrul Academiei, cât și în afara ei. Astfel, putem vorbi mai mult despre utilitatea, necesitățile și facilitățile ce ni le potate oferi un astfel de sistem.

Întrebarea nr.3 Care ar fi avantajele unui sistem informatic de evidență a activității științifice?

Răspuns (Valeriu Negară, cercetător științific în Centrul de cercetări științifice al Academiei de Poliție): Avantajele ar fi următoarele:

sistematizarea datelor existente;

ar permite întocmirea rapidă a notelor informative, care sunt des solicitate de M.A.I.;

ar exclude implicarea unui personal numeros în analiza datelor existente;

ar permite întocmirea graficilor la notele informative elaborate, lucru ce nu se face până acum;

(Igor Ursan, cercetător științific în Centrul de cercetări științifice al Academiei de Poliție):

ar permite utilizarea în mod oportun, rapid, cu economisire de timp a informației privind activitatea științifică în pregătirea materialelor cu caracter informațional, științific, organizatoric etc.

ar facilita planificarea, dirijarea și controlul activității științifice, precum și primirea unor decizii, privind activitatea menționată, corecte, conform stării de fapt.

Întrebarea nr.4 Credeți că un sistem informatic de evidență a activității științifice vă va ajuta în dirijarea și planificarea ulterioară a activității respective?

Răspuns: (Tudor Tomozei, șeful Centrului de cercetări științifice al Academiei de Poliție): Desigur. Orice gen de activitate necesită evidență și analiză permanentă, fapt care permite direcționarea activității, adoptarea unor hotărâri care să contribuie la creșterea eficienței în activitate și la înlăturarea neajunsurilor depistate.

5.6. Planificarea elaborării sistemului informatic

Tehnologia proiectării unui sistem nou contemporan se bazează pe următoarele particularități:

• tehnica utilizată este construită utilizând ultimele elaborări științifice;

• accelerarea vitezei de elaborare a proiectelor;

• tehnica de calcul și softului sunt supuse uzurii morale foarte rapide;

Toate acestea au dus la necesitatea de creare a noi metode de planificare. Una din aceste metode prezintă modelarea procesului de elaborare, adică prezentarea 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, este necesar să nu schimbăm termenul de efectuare a întregului complex de lucrări.

La elaborarea sistemului informatic de evidență a activității științifice, se ține seama de asigurarea 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 maximă a resurselor.

Particularitățile sistemului informatic de evidență a activității științifice, în general, sunt următoarele:

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

se utilizează modelul pentru descrierea proceselor și calculul parametrilor acestor procese (durata, costul, forțele de muncă, etc.)

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

Documentul de bază în sistemul de evidență a activității științifice este modelul informațional în care sunt prezentate lucrările necesare pentru atingerea scopului final și durate de timp necesară (în zile).

Tab.8

Durata efectuării lucrărilor

5.7. Evaluarea economică a sistemului informatic

Din tabelul 8 vedem că proiectul durează 59 de zile. Adăugăm o zi de rezervă și obținem 60 de zile, 12 săptămâni cu 5 zile lucrătoare cu câte 8 ore lucrătoare. Salariul lunar al lucrătorilor este prezentat în tabelul 9.

Tab.9

Componența grupului de lucru

Salariul săptămânal alcătuiește, deci, 75 lei.

Pe durata proiectului salariul de bază alcătuiește: 12 x 75 = 900 lei;

Impozitul pe venit 10% din salariu de bază: 900 – 90 = 810 lei

Salariul auxiliar (10% din salariul de bază); 900 x 10% = 900 x 0,1 = 90 lei

Defalcări în Fondul Social (31%) (900 + 90) x 31% = 990 x 0,31 = 306,9 lei

Necesitățile în materiale, soft și hard sunt prezentate în tabelele 10 și 11.

Tab.10

Costul softului și hardului procurat

Tab.11

Costul materialelor utilizate

Să calculăm cheltuielile de energie electrică. Un calculator personal obișnuit are o putere de 200 W. Pe parcursul proiectului, timp de 60 de zile vor fi consumate:

200 x 60 x 8 = 96000 W = 96 kW

La momentul actual un kW costă 0,65 lei, deci cheltuielile vor fi: 96 x 0,65 = 62,4 lei

Deoarece procurarea softului și hardului în domeniul Tehnologiilor Informaționale este considerată investiție capitală, v-om amortiza aceste cheltuieli în timp de 1 an, fiindcă aceste produse sunt supuse uzurii morale rapide:

[S / (A x 365)] x Z unde: S – suma ce trebuie de amortizat;

A – perioada de amortizare în ani;

Z – perioada proiectului în zile.

[9050 / (1 x 365)] x 60 = 1487,67 lei

Pentru studierea domeniilor necesare la proiectarea sistemului a fost procurată literatură în sumă de 300 lei.

Tab.12

Calculul prețului de livrare a sistemului informatic de evidență a

activității științifice în Academia de Poliție ,,Ștefan cel Mare”

5.8. Evaluarea eficienței implementării sistemului informatic

Evaluarea comparativă a implementării sistemului informațional este prezentată în tabelul 13.

Tab.13

Evaluarea eficienței implementării sistemului informatic de evidență a

activității științifice în Academia de Poliție

Concluzie: Sistemul informatic de evidență a activității științifice din cadrul Academie de Poliție ,,Ștefan cel Mare” este un sistem care va facilita mult evidența și dirijarea activității științifice, care va economisi mult timp în lucru cu actualizarea datelor și extragerea datelor ce vor corespunde reperelor mai des solicitate sub formă de dări de seamă, note informative etc.

Acest sistem este benefic oricărei instituții care desfășoară o activitate științifică.

6. Protecția muncii și sanitarie în producție

Această teză de diplomă este dedicat elaborării unui pachet de programe de culegere și prelucrarea informației. Apare problema de protecția muncii programatorilor și utilizatorilor acestui pachet de programe. Deoarece lucrul cu acest sistem se efectuează cu ajutorul terminalelor video, noi avem nevoie de a examina cerințe de protecție muncii lucrând cu terminale video, în particularitate cu Calculatoare Electronice (CE) și diferite dispozitive periferice care se utilizează în Centrele de Calcul (CC) în procesul de lucru. Natural că introducerea și utilizarea largă a CE are în afară de părți pozitive și unele acțiuni negative asupra utilizatorilor.

Programatorii, operatorii CE și alți lucrători a CC sunt supuși acțiunilor factorilor de producere periculoși și dăunători, cum sunt nivelul zgomotului înalt, cantitatea insuficientă a luminii naturale, neajunsul luminării locului de muncă, temperatura ridicată a mediului exterior, diferite tipuri de radiație și altele.

Acțiunea factorilor nefavorabili, numiți mai sus, aduce la micșorarea capacității de muncă, ce este provocată de oboseală. Apariția și dezvoltarea oboselii este legată de schimbări care se petrec în creierul omului în timpul executării lucrului, cu reacții de frână în scoarța cerebrală. De exemplu zgomot mare provoacă greutăți în constatarea semnalelor de culori, micșorează rapiditatea de percepție a culorii, vederea, tulbură percepția informației vizuale, micșorează capacitate de a efectua mișcări rapid și fix, micșorează (productivitatea de lucru cu 5-12%, și încă aduce la înrăutățirea (agravarea) auzului.

Aflarea omului în zonele de influență combinată a diferitor factori dăunători mai mult timp poate aduce la îmbolnăvirea profesională.

Pentru crearea condițiilor de muncă favorabile în CC este necesar de luat în considerație particularitățile psihofiziologice a omului și condițiile de igienă generală. Un rol important joacă planificarea locului de muncă, care se petrece în conformitate cu cerințele de comoditate a executării lucrului, economisirea energiei și timpului operatorului, utilizarea rațională a spațiilor de producere, respectarea regulilor de protecție muncii.

6.1. Zgomotul

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

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

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

În conformitate cu STAS 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 m tabelul 14.

Tab.14

Nivelurile admisibile a zgomotului

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

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

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

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

6.2. 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 întră 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 m 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 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 STAS 12.1.005-91. Parametrii se normează după acest STAS și sunt prezentați în tabelul 15.

Tab.15

Normele microclimatului

În acest tabel se aduc parametrii pentru categoriile de lucru la (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ă.

6.3. 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 m 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 m 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ă m conformitate cu STAS 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.

6.4. Radiația

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ță :i fost utilizat monitorul cu tensiunea la cinescop mult mai mică de 15 kV, și de aceea acest factor ,mia 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ă le păș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 16.

Tab.16

Niveluri admisibile de tensiune

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

6.5. 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ă m 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 CE 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.

6.6. 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ă (STAS 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ă.

Calcularea protecției ,,legare la nul”

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

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

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

Se calculă rezistența circuitului „faza – nul“:

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

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

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

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

,

unde Lf , Sf , Ln,Sn – lungimea și secțiunea firului fazic și nul corespunzător;

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

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

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

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

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

unde Zt – rezistența transformatorului.

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

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

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

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

6.7. STAS 12.2.032-78. Locul de muncă la efectuarea lucrului șezând

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

6.7.1. Principii generale

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

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

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

Fig.1 Zona accesibilă a câmpului motor în plan vertical.

6.7.2. Caracteristicile de dimensiune a locului de muncă

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

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

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

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

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

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

Fig. 2. Nomograma înălțimii planului locului de muncă pentru diferite tipuri de lucru (1-4), spațiu pentru picioare(5) și înălțimea scaunului (6) independența de înălțimea omului,

Tab.17

Parametrii neregulați

Fig. 3. Spațiu pentru picioare (lățime nu mai puțin de 500 mm).

a – distanța dinte scaun și capătul de jos al planului de lucru nu mai puțin de 150 mm;

h – înălțimea spațiului pentru picioare nu mai puțin de 600 mm.

Tab.18

Parametrii scaunului

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

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

6.7.3. Cerințele de amplasare a organelor de conducere

3.1. La lucru cu două mâini organele de conducere se amplasează în așa mod ca să nu fie intersecția mâinilor.

3.2. Organele de conducere pe suprafața locului de muncă în plan orizontal trebuie de amplasat conform următoarelor cerințe:

organe de conducere foarte des utilizate trebuie să fie amplasate în zona 1 (fig. 4);

organe de conducere des utilizate și mai puțin importante se amplasează în zona 1 și 2 (fig. 4);

organe de conducere rar utilizate se amplasează nu mai departe de zona 3 (fig.4).

Fig. 4 Zone de observare vizuală în plan vertical.

3.3. Organele de conducere pot fi amplasate mai sus de 1100 mm în caz dacă amplasarea până la nivelul menționat nu este posibilă din motive tehnice. Așa organe de conducere trebuie să fie utilizate rar.

3.4. Organe de conducere de depanaj trebuie amplasate în zona accesibilă a câmpului motor, totodată trebuie de prevăzut mijloace speciale de notificare și preîntâmpinare a declanșării spontane sau intenționate în conformitate cu STAS 12.2.003-74.

6.7.4. Cerințele la amplasare a mijloacelor de reprezentare a informației

Mijloacele de reprezentare a informației foarte des utilizate, care necesită citirea rapidă și precisă, trebuie de amplasat în plan vertical sub unghi ±15° de la linia normală de privire și în plan orizontal sub unghi ±15° de la planul sagital (fig.4 și 5).

Fig. 5. Zone de observare vizuală în plan orizontal.

4.1. Mijloacele de reprezentare a informației des utilizate, care necesită citirea mai puțin precisă și rapidă, se poate de amplasat în plan vertical sub unghi ±30° de la linia normală de privire și în plan orizontal sub unghi ±30° de la planul sagital.

Mijloace de reprezentare a informației rar utilizate trebuie de amplasat în plan vertical sub unghi ±60° de la linia de normală privire, în plan orizontal sub unghi ±60° de la planul sagital (la mișcarea ochiului și învârtirea capului).

CONCLUZII

Sistemele informaționale cunosc o utilizare deosebit de intensă și variată în toate domeniile de activitate ale oamenilor, și în special, în activitatea științifică. Din păcate, în Academia de Poliție „Ștefan cel Mare” nu există un sistem informațional integru care ar servi activitatea de dirijare a instituției.

În scopul de a se remedia această stare de lucruri s-a decis informatizarea activității din Academia de Poliție „Ștefan cel Mare”.

După părerea mea sistemul informatic elaborat și prezentat în lucrarea de față va avea un loc foarte important în cadrul sistemului informațional general al Academiei de Poliție, deoarece alături de sistemele de evidență a Contabilității, Secției studii, Secției personal etc. s-a impus necesitatea creării și a unui sistem de evidență a activității științifice, sistem necesar mai ales Centrului de cercetări științifice, care dirijează toată activitatea științifică din Academiei.

Sistemul a fost conceput pornind de la necesitățile funcționale concrete ale Academiei de Poliție, și mai ales ale Centrului de cercetări științifice, răspunzând cerințelor punctuale ale solicitantului. Acest sistem nu va mai permite ca colectarea și sistematizarea datelor ce țin de activitatea științifică să fie un proces greoi, „manual” și care să consume mult timp persoanelor responsabile de evidența și planificarea activității științifice. Acest sistem va răspunde cererilor sistematice de informații privind activitatea științifică a Academiei de Poliție în general și a fiecărui funcționar în particular pentru a reprezenta diverse note informative privind activitatea științifică care des sunt solicitate de diverse subdiviziuni ale Ministerului Afacerilor Interne. De asemenea, pentru pregătirea dărilor de seamă; furnizarea informației despre activitatea științifică a fiecărui funcționar antrenat în procesul didactic și cel de cercetare științifică pentru întocmirea prezentărilor pentru atestarea acestora și pentru atribuirea gradelor speciale următoare. Volumul mare de informații în ce privește activitatea științifică se va păstra într-un sistem unic integral, dispărând astfel anomaliile de actualizare și prelucrare a datelor.

Sistemul informatic de evidență a activității științifice din cadrul Academie de Poliție ,,Ștefan cel Mare” este un sistem care va facilita mult evidența și dirijarea activității științifice, care va economisi mult timp în lucru cu actualizarea datelor și extragerea datelor ce vor corespunde reperelor mai des solicitate sub formă de dări de seamă, note informative etc. Acest sistem este benefic oricărei instituții care desfășoară o activitate științifică.

BIBLIOGRAFIE

Vitalie Cotelea, Baze de date proiectare logică, Chișinău, ASEM, 1997;

Ion Lungu, ș.a., Baze de date organizare, proiectare și implementare, București, ed. ALL EDUCATIONAL, 1995;

Ion Bolun, Ion Covalenco, Bazele informaticii aplicate, Chișinău, ASEM, 1999;

Protecția muncii și a mediului ambiant/Elaborat Marian O., Bajureanu A., Chișinău, UTM, 1993;

А.М.Епанешников, В.А. Епанешников, DELPHI 5 базы данных, Москва, Диалог-Мифи, 2000;

Владимир Гофман, Анатолий Хомоненко, DELPHI 5, БХВ – Петербург, Санкт-Петербург, 2001;

Octavian Bejan, De la savanți… la experți, în ,,Revista de filozofie și drept”, nr.2-3/1999.

Site-uri Web

www.borland.com;

www.delphi.com;

www.torry.ru;

www.citforum.ru.

ANEXE

ANEXA NR.1

STRUCTURA BAZEI CENTRALE DE DATE A SIAP

ANEXA NR.2

STRUCTURA BAZEI DE DATE activitatea științifică

ANEXA NR.3

TERMENI EXPLICATIVI

IdAP – Codul atributelor particulare;

IdFP – Codul formei publicației;

DenP – Denumirea particulară a lucrării;

ColA – Coli de autor;

IdAG – Codul atributelor generale;

DenG – Denumirea generală a publicației;

AnE – Anul ediției;

NrE – Numărul ediției;

IdEd – Codul editurii;

IdTg – Codul tipografiei;

IdOș – Codul orașului;

Czu – Indicele CZU;

Isbn – Indicele ISBN;

ColT – Colile de tipar;

NrPag – Numărul de pagini;

IdP – Codul publicației;

IdAut – Codul autorului;

Editura – Editura publicației;

Tipografia – Tipografia publicației;

Oraș – Orașul în care a fost publicată;

FormaP – Forma publicației;

IdTșd – Codul titlului științific-didactic;

IdTș – Codul titlului științific;

IdSb – Codul subdiviziunii;

TitluȘD – Titlul științific-didactic;

TitluȘ – Titlul științific;

Subdiviz – Subdiviziunea autorului;

IdAA – Codul atributelor activității științ.;

IdFA – Codul formei activității științifice;

Generic – Genericul activității științifice;

DataÎ – Data începerii activității științifice;

DataT – Data terminării activității;

NrPart – Numărul de participanți;

IdNiv – Codul nivelului;

IdAȘ – Codul activității științifice;

IdOrg – Codul organizatorului;

FormaA – Forma activității științifice;

Nivel – Nivelul activității științifice;

Organiz – Organizatorul activității științifice.

ANEXA NR.4

SCHEMA LOGICĂ A BAZEI DE DATE activitatea științifică

ANEXA NR.5

LISTINGUL PROGRAMULUI