Nicolae Morariu Sorin Vlad

PROIECTAREA SISTEMELOR INFORMATICE

Metode, modele, tehnici şi instrumente utilizate

2008

1

Referent ştiinţific:

Prof. univ. dr. ing. Doru E. Tiliuţe Universitatea “Ştefan cel Mare” Suceava

Copyright © 2008. Editura InfoData.

2

Descrierea CIP a Bibliotecii Naţionale a României

MORARIU, NICOLAE

Proiectarea sistemelor informatice Metode, modele, tehnici şi

instrumente utilizate/ Nicolae Morariu, Sorin Vlad - Bucureşti:

Editura InfoData, 2008

Bibliogr.

ISBN 973-30-1042-1

004.65

CUPRINS

Introducere........................................................................................................................................3Capitolul 1. Sisteme Informatice...................................................................................................3

1.1. Sistem, Sistem informaţional, Sistem informatic...................................................................31.1.1. Componentele sistemului informatic...............................................................................31.1.2. Clasificarea sistemelor informatice.................................................................................31.1.3. Ciclul de viaţă a unui sistem informatic.........................................................................31.1.4. Conţinutul bazei informaţionale a unei întreprinderi.......................................................31.1.5. Ciclul prelucrării datelor pentru sistemul informatic.......................................................31.1.6. Sisteme informatice de gestiune......................................................................................3

1.2. Metodologii de realizare a sistemelor informatice.................................................................31.2.1. Conţinutul metodologiilor de realizare a sistemelor informatice....................................31.2.2. Metode şi tehnici de realizare a sistemelor informatice..................................................3

Teste rezolvate..............................................................................................................................3Întrebări.........................................................................................................................................3

Capitolul 2. Iniţierea şi planificarea realizării unui sistem informatic.....................................32.1. Identificarea, selecţia, iniţierea şi planificarea proiectelor.....................................................32.2. Studii de fezabilitate...............................................................................................................32.3. Tehnici de reprezentare a planurilor şi programarea calendaristică.......................................3Teste rezolvate..............................................................................................................................3

Capitolul 3. Analiza sistemului existent şi definirea cerinţelor noului sistem..........................33.1. Studiul sistemului informaţional existent...............................................................................33.2. Determinarea cerinţelor sistemului........................................................................................3

3.2.1. Metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemului.............33.2.2. Metode moderne de analiză şi determinare a cerinţelor sistemului.................................3

3.3. Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor....................33.3.1. Diagramele fluxurilor de date (DFD)..............................................................................33.3.2. Descompunerea funcţională şi rafinarea DFD.................................................................33.3.3. Modelarea sistemului curent............................................................................................33.3.4. Modelarea logicii proceselor...........................................................................................3

3.4. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER).................................33.4.1. Modelul Entitate/Relaţie (E/R)........................................................................................3

Teste rezolvate..............................................................................................................................3Întrebări.........................................................................................................................................3

Capitolul 4. Proiectarea logică a sistemelor informatice............................................................34.1. Proiectarea formularelor/formatelor şi a rapoartelor..............................................................3

4.1.1. Proiectarea situaţiilor cu rezultate finale (rapoartelor)....................................................34.1.2. Proiectarea codurilor........................................................................................................34.1.3. Proiectarea intrărilor în sistemul informatic....................................................................3

4.2. Proiectarea interfeţelor şi a dialogurilor.................................................................................34.3. Proiectarea logică a bazelor de date.......................................................................................3

4.3.1. Normalizarea relaţiilor - Forme normale.........................................................................34.3.2. Simplificarea structurii datelor prin normalizare.............................................................3

3

4.3.3. Transformarea diagramelor entitate-relaţie în relaţii.......................................................3Teste rezolvate..............................................................................................................................3

Capitolul 5. Proiectarea fizică a sistemelor informatice.............................................................35.1. Proiectarea fizică a bazelor de date şi a fişierelor..................................................................3

5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:............................................35.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)............................................................35.1.3. Administratorul bazei de date..........................................................................................35.1.4. Proiectarea securităţii bazelor de date şi a fişierelor........................................................35.1.5. Limbajul SQL - Crearea, Administrarea şi Interogarea bazelor de date relaţionale........3

5.2. Proiectarea programelor şi a procedurilor..............................................................................35.2.1. Atributele modulelor........................................................................................................35.2.2. Structurile de control ale programelor.............................................................................35.2.3. Proiectarea şi realizarea programelor..............................................................................3

5.3. Proiectarea sistemelor distribuite...........................................................................................3Teste rezolvate..............................................................................................................................3Întrebări şi răspunsuri....................................................................................................................3

Capitolul 6. Instrumente CASE....................................................................................................36.1. Funcţiile CASE......................................................................................................................36.2. Trăsături definitorii ale CASE-ului........................................................................................36.3. Tipuri de instrumente CASE [72]..........................................................................................36.4. Exemple de instrumente CASE..............................................................................................3

6.4.1. Erwin Data Modeler.........................................................................................................36.4.2. Microsoft Visio 2007.......................................................................................................36.4.3. Toad data modeler...........................................................................................................36.4.4. Embarcadero ER/Studio [70]...........................................................................................36.4.5. Oracle Designer...............................................................................................................3

Teste rezolvate..............................................................................................................................3Întrebări şi răspunsuri....................................................................................................................3

Capitolul 7. Tendinţe actuale şi de perspectivă în evoluţia sistemelor informatice.................37.1. Concepţia sistemică în economie...........................................................................................37.2. Categorii de sisteme inteligente.............................................................................................3

7.2.1. Sisteme expert bazate pe reguli.......................................................................................37.2.2. Sisteme bazate pe reţele neuronale (sisteme conexioniste).............................................37.2.3. Sisteme multi-agent. Definiţie, clasificare, arhitecturi....................................................37.2.4. Sisteme inteligente hibride...............................................................................................3

Capitolul 8. Studii de caz - Arhitecturi de sisteme informatice.................................................38.1. Model de date georelaţional în cadrul unui sistem informatic geografic distribuit cu aplicaţii în domeniul cadastrului...................................................................................................38.2. Sistem informatic geografic distribuit pentru reprezentarea digitală şi monitorizarea zonelor expuse inundaţiilor...........................................................................................................38.3. Sistem bazat pe cunoştinţe destinat documentării şi cercetării asistate în genetica vegetală3

8.3.1. Organizarea datelor în cadrul sistemului informatic........................................................38.3.2. Arhitectura unui sistem bazat pe cunoştinţe în genetica vegetală...................................38.3.3. Probleme specifice cercetării...........................................................................................3

8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorită depozitării necontrolate a deşeurilor.............................................................................................3

8.4.1. Introducere.......................................................................................................................3

4

8.4.2. Definirea arhitecturii generale a sistemului.....................................................................38.4.3. Proiectarea bazei de date a sistemului.............................................................................38.4.4. Dezvoltarea unei aplicaţii specifice pentru reprezentarea şi monitorizarea unor zone intravilane din judeţul Suceava supuse degradării datorită depozitării necontrolate a deşeurilor...................................................................................................................................3

Concluzii.......................................................................................................................................3BIBLIOGRAFIE............................................................................................................................3

5

Introducere

Scopul lucrării este de a familiariza studenţii facultăţilor cu profil economic cu principalele concepte, metode tehnici şi instrumente utilizate în proiectarea sistemelor informatice. Sunt prezentate şi exemplificate principalele etape şi activităţi de parcurs pentru întreg ciclul de viaţă a unui sistem informatic. În ultima parte a lucrării sunt prezentate tendinţe actuale şi de perspectivă în evoluţia sistemelor informatice precum şi arhitecturi de sisteme informatice realizate pentru diverse domenii de activitate.

Pentru a asigura parcurgerea şi însuşirea problematicii propuse, lucrarea de faţă cuprinde opt capitole şi anume: 1 – Sisteme informatice, 2 – Iniţierea şi planificarea realizării unui sistem informatic, 3 – Analiza sistemului existent şi definirea cerinţelor noului sistem, 4 – Proiectarea logică a sistemelor informatice, 5 – Proiectarea fizică a sistemelor informatice, 6 – Instrumente CASE, 7 – Tendinţe actuale şi de perspectivă în evoluţia sistemelor informatice, 8 – Studii de caz - Arhitecturi de sisteme informatice.

În capitolul 1 sunt prezentate conceptele sistem, sistem informaţional, sistem informatic, sunt definite componentele sistemului informatic, sunt redate clasificări ale sistemelor informatice după diverse criterii, este definit ciclul de viaţă a unui sistem informatic şi sunt prezentate etapele ciclului de viaţă în cadrul modelului cascadă. Este prezentat conţinutul bazei informaţionale a unei intreprinderi şi este definit sistemul informatic de gestiune şi ciclul prelucrării datelor pentru sistemul informatic. Este definit conceptul de metodologie de realizare a unui sistem informatic şi sunt prezentate sumar principalele metode utilizate.

În capitolul 2 sunt prezentate o serie de aspecte privind primele activităţi desfăşurate în vederea realizării sistemelor informatice, activităţi definite în literatura de specialitate sub numele de microanaliza sistemelor, componentă preluată din managementul proiectelor şi care are în vedere modalităţile de identificare a proiectelor de dezvoltare a sistemelor informaţionale, precum şi modul în care au loc iniţierea şi planificarea realizării acestora, în strânsă legătură cu planul strategic organizaţional. Este definit studiul de fezabilitate, iar ca tehnică de reprezentare grafică a planurilor de programare calendaristică este definită şi exemplificată diagrama Gantt.

În cadrul capitolului 3 este prezentată prima etapă a ciclului de viaţă al sistemelor informatice, etapă prin care se determină modul în care funcţionează sistemul informaţional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul sistem. Astfel, sunt prezentate o serie de aspecte privind:

– studiul sistemului existent;– determinarea cerinţelor noului sistem;– metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemulu

(interviul şi chestionarul);– metode moderne de analiză şi determinare a cerinţelor sistemului (JAD,

prototipizarea);– structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor

(diagramele fluxurilor de date DFD);– modelarea conceptuală a datelor (diagramele entitate – relaţie, DER).

6

În capitolul 4 al lucrării este tratată etapa de proiectare logică a sistemului informatic cunoscută şi sub denumirea proiectare generală sau proiectare de ansamblu. Proiectarea de ansamblu a sistemului are în vedere prezentarea noului sistem prin prezentarea tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurilor. Având în vedere intrările şi ieşirile sisemului, este prezentată proiectarea logică a bazei de date, activitate prin care se urmăreşte transformarea diagramelor entitate-relaţie în relaţii. Aceste elemente definitorii ale noului sistem se construiesc pe baza a ceea ce s-a identificat în etapele anterioare, dar ţinându-se cont şi de cerinţele identificate în timpul desfăşurării activităţilor din etapa de proiectare logică. Documentaţia realizată în cadrul acestei etape constituie proiectul tehnic de ansamblu al sistemului.

Capitolul 5 tratează proiectarea fizică a sistemului informatic, cunoscută şi sub numele de proiectare de detaliu, care urmează proiectării logice şi care înseamnă o abordare detaliată a sistemului. Dacă în etapa de proiectare logică se acumulează informaţiile ce sintetizează cerinţele utilizatorilor noului sistem, operaţiune prestată de analiştii de sistem, în cadrul proiectării fizice se prezintă punctele de vedere ale specialiştilor, cum ar fi cei din domeniul bazelor de date, securităţii sistemelor, reţelelor de calculatoare, programării, etc. Proiectarea fizică a sistemului informatic cuprinde:

Proiectarea fizică a bazelor de date şi a fişierelor. O astfel de activitate înseamnă descrierea modului în care vor fi stocate datele şi cum se va asigura controlul lor pentru a se oferi o securitate maximă;

Proiectarea structurii sistemului şi a programelor. Se descriu programele sau modulele acestora care să fie în strânsă concordanţă cu diagramele fluxurilor de date şi cu celelalte piese ale documentaţiei realizate în etapele anterioare;

Proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalităţile în care utilizatorul poate să dispună de date şi facilităţile de prelucrare oferite de reţele de calculatoare.

În capitolul 6 sunt definite instrumentele CASE şi sunt prezentate tipuri de instrumente CASE având în vedere cele două metodologii de proiectare: metodologia structurată şi metodologia orientată obiect. În finalul capitolului sunt prezentate facilităţile oferite şi modul de utilizare a următoarelor produse CASE: Erwin Data Modeler, Microsoft Visio 2007, Toad Data Modeler, Embarcadero ER/Studio, Oracle Designer.

Capitolul 7 tratează o serie de aspecte privind noua concepţie sistemică în economie, dezvoltarea şi utilizarea sistemelor inteligente în cadrul unei organizaţii, reprezentarea şi procesarea datelor şi cunoaşterii în cadrul conceptului de sistem informaţional inteligent. Sunt prezentate sumar principalele categorii de sisteme inteligente: sisteme expert, sisteme conexioniste, sisteme multiagent, sisteme inteligente hibride.

În capitolul 8 sunt prezentate exemple de sisteme informatice pentru diverse domenii de activitate, realizate cu participarea autorilor în cadrul unor proiecte de cercetare.

7

Capitolul 1. Sisteme Informatice

1.1. Sistem, Sistem informaţional, Sistem informaticUn sistem reprezintă un ansamblu de elemente (componente) interdependente între

care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv [60]. Conform teoriei sistemelor orice organism economic este un sistem.

În cadrul acestei lucrări prin organizaţie se va referi o intreprindere, instituţie, societate comercială.

În orice organizaţie se disting 3 componente: sistemul de conducere sau de decizie; sistemul informaţional; sistemul operaţional.Sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe utilizate

în cadrul organizaţiei precum şi datele care au stat la baza obţinerii lor, procedurile şi tehnicile de obţinere a informaţiilor (plecând de la datele primare) şi de difuzare a informaţiilor, precum şi personalul implicat în culegerea, transmiterea, stocarea şi prelucrarea datelor.

Sistemul informaţional are două componente: componenta pentru stocarea (memorarea informaţiilor); componenta pentru prelucrarea informaţiilor.Orice organizaţie interacţionează cu alte organizaţii externe ei primind informaţii

din exterior şi furnizând informaţii către lumea exterioară.Funcţiile unui sistem informaţional sunt: să colecteze informaţii din sistemele operaţional şi decizional precum şi

informaţiile ce provin din mediul extern; să memoreze aceste informaţii precum şi informaţii rezultate din prelucrarea

lor; să asigure accesul la memorie în vederea comunicării informaţiilor stocate; să prelucreze informaţiile la cererea sistemului operaţional şi a sistemului de

conducere.Noţiunea de sistem informatic este legată de informatizarea activităţii organizaţiei,

deci folosirea echipamentelor hardware şi a produselor software pentru organizarea şi administrarea informaţiilor. Utilizarea calculatoarelor în cadrul sistemului informaţional (SI) al unei organizaţii conduce la definirea componentei Sistem Informaţional Automatizat (SIA) – care cuprinde numai lucrările realizate cu ajutorul calculatoarelor. Relaţia SI – SIA este reprezentată în figura 1.1.

8

Fig. 1.1. Relaţia SI – SIA (Sursa: [10])

Definiţie. Un sistem informatic este un sistem utilizator-calculator integrat, care furnizează

informaţii pentru a sprijini activităţile de la nivel operaţional şi activităţile de management într-o organizaţie, utilizând echipamente hardware şi produse software, proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare, control şi luarea deciziilor [8].

Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie asigurarea conducerii cu informaţii reale şi în timp util, necesare fundamentării şi elaborării operative a deciziilor [11].

Elaborarea sistemelor informatice impune modelarea sistemului informaţional al organizaţiei cu ajutorul unui formalism prin care să poată fi reprezentată cât mai sugestiv şi fidel realitatea din cadrul sistemului informaţional.

Sistemele informatice complexe pot fi descompuse în subsisteme, care la rândul lor pot fi descompuse în aplicaţii destinate unor categorii de utilizatori, aplicaţii care la rândul lor pot fi constituite din unul sau mai multe programe scrise în diverse limbaje de programare după cum este ilustrat în figura 1.2.

Fig.1.2. Sistem informatic, subsisteme, aplicaţii, programe

9

Pentru organizaţii de complexitate mică, informatizarea poate însemna realizarea unei singure aplicaţii informatice referită de asemenea ca sistem informatic.

Sistemele, subsistemele şi aplicaţiile informatice sunt produse informatice numite şi produse software. Un produs informatic este constituit din programe care accesează baza de date şi din documentaţia necesară pentru utilizarea şi întreţinerea programelor. Acestea se realizează în baza unor metodologii şi necesită parcurgerea unor etape începând cu specificarea cerinţelor şi terminând cu implementarea, exploatarea şi întreţinerea lor.

Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor. Sistemul informatic este inclus în sfera sistemului informaţional atâta vreme cât în cadrul sistemului informaţional vor exista o serie de activităţi care nu vor putea fi automatizate [11].

1.1.1. Componentele sistemului informaticUn sistem informatic este compus din [11]: baza informaţională; baza tehnică; sistemul de programe; baza ştiinţifică şi metodologică; factorul uman (resursele umane); cadrul organizatoric.Baza informaţională cuprinde: datele supuse prelucrării; fluxurile informaţionale; sistemele şi nomenclatoarele de coduri.Baza tehnică este constituită din totalitatea mijloacelor tehnice de culegere,

transmitere, stocare şi prelucrare a datelor, locul central revenind calculatoarelor electronice.

Sistemul de programe cuprinde totalitatea programelor utilizate pentru funcţionarea sistemului informatic în concordanţă cu funcţiunile şi obiectivele stabilite. Sunt avute în vedere atât programele de bază (software de bază) cât şi programele aplicative (software de aplicaţie).

Baza ştiinţifică şi metodologică este constituită din: algoritmi; formule; modele; tehnici de realizare a sistemelor informatice.Resursele umane constau din: personalul de specialitate: analişti, programatori, ingineri de sistem, analişti-

programatori ajutori, operatori, etc.;

10

beneficiarii sistemului.Cadrul organizatoric este cel specificat în regulamentul de organizare şi

funcţionare (ROF) al unităţii în care va fi utilizat sistemul informatic.La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere

următoarele componente hard şi soft: reţele, echipamente, produse software de bază, produse software de aplicaţie.Reţele

clasificare după aria de întindere geografică: Locale =LAN (Local Area Network) – la nivelul unei organizaţii; Metropolitane –MAN (Metropolitan Area Network) – la nivel de oraş,

localitate; De mare întindere -WAN (World Area Network) (ex. Judeţ, Ţară).

clasificare după accesibilitate: Internet (reţeaua Web) – o colecţie mondială de reţele interconectate; Intranet – un sit Web sau un grup de sit-uri care aparţin unei organizaţii,

accesibil numai pentru membrii acesteia; Extranet – o reţea intranet care este parţial accesibilă utilizatorilor externi

autorizaţi.Echipamente

Echipamente de calcul : calculatoare, staţii grafice, pentru servere de reţea, servere de baze de date, staţii de lucru (clienţi, utilizatori), UPS-uri;

Echipamente de comunicaţie : router-e, hub-uri, modem-uri, switch-uri.Produse software

Produse software de bază: Sisteme de operare pentru serverul de reţea (UNIX, Windows NT server,

Windows Server 2003, Novell) şi pentru staţiile de lucru sau clienţi (Windows 98, Windows NT work station, Windows XP, Windows Vista);

Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL, ACCESS, FoxPro etc.);

Sisteme GIS (Geographical Information System) – utilizate pentru realizarea aplicaţiilor pentru stocarea şi prelucrarea datelor spaţiale;

Limbaje (medii) de programare – utilizate pentru realizare software de aplicaţie.

Produse software de aplicaţie – produse program ce constituie aplicaţiile şi subsistemele sistemului informatic.1.1.2. Clasificarea sistemelor informatice

Sistemele informatice se clasifică după mai multe criterii [46].

1. În funcţie de domeniul de utilizare, sistemele informatice pot fi pentru : conducerea activităţilor economico-sociale conducerea proceselor tehnologice cercetare ştiinţifică şi proiectare tehnologică activităţi speciale.

11

2. În funcţie de elementul supus analizei: sisteme informatice orientate spre funcţii; sisteme informatice orientate spre proces; sisteme informatice orientate spre date; sisteme informatice orientate spre obiecte; sisteme informatice orientate spre cunoştinţe.

3. După modul de organizare a datelor: sisteme bazate pe fişiere; sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţionale, orientate-

obiect; sisteme mixte.

4. După metoda folosită în analiza şi proiectarea sistemelor: sisteme dezvoltate după metoda sistemelor; sisteme dezvoltate după metoda clasică a ciclului de viaţă; sisteme dezvoltate după metoda structurată; sisteme dezvoltate după metoda orientată-obiect; sisteme dezvoltate după metoda rapidă(RAD); sisteme dezvoltate după metoda echipelor mixte(JAD); sisteme dezvoltate după metoda prototipurilor.

5. După gradul de centralizare: sisteme centralizate; sisteme descentralizate;

6. După gradul de dispersie a resurselor sistemului informatic: sisteme informatice locale (bazate pe reţea locală, staţii de lucru): sisteme informatice distribuite (date distribuite).

7. După gradul de automatizare a activităţilor de analiză şi proiectare a sistemelor informatice:

sisteme informatice dezvoltate pe baza analizei şi proiectării clasice; sisteme informatice analizate cu instrumente automate şi proiectate clasic; sisteme informatice bazate pe instrumente diverse de automatizare a analizei şi

proiectării; sisteme informatice dezvoltate cu instrumente de tip CASE.

În funcţie de nivelul ierarhic ocupat de sistemul economic în structura organizatorică a societăţii, există sisteme informatice [11]:

pentru conducerea activităţii la nivelul unităţilor economice; pentru conducerea activităţii la nivelul organizaţiilor economico-sociale cu

structură de grup; sisteme informatice teritoriale; pentru conducerea ramurilor, subramurilor şi activităţilor la nivelul economiei

naţionale; sisteme informatice funcţionale generale.

12

1.1.3. Ciclul de viaţă a unui sistem informaticSistemele informatice (SI) se caracterizează printr-un ciclu de viaţă care începe cu

decizia realizării unui nou SI care să corespundă mai bine noilor cerinţe ale utilizatorilor şi se încheie cu decizia de înlocuire a SI existent cu unul nou, mai performant. Ciclul de viaţă se desfăşoară pe etape în cadrul fiecăreia fiind definite faze şi activităţi specifice.

Încă de la început facem menţiunea că, indiferent de etapa istorică sau metodologică, sistemele sunt abordate prin prisma ciclului lor de viaţă. Ele apar se dezvoltă, descresc şi pier, sau printr-un nou ciclu, se perfecţionează, dând naştere unei alte versiuni sau chiar unui nou sistem. Mutaţiile din domeniul tehnologiei informaţionale şi al metodelor de abordare a sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de parcurgere a lor. Spre exemplu, odată cu abordarea orientată-obiect a sistemelor, s-au lansat şi noi modele ale ciclului de viaţă [60].

Prin parcurgerea materialelor de specialitate, se poate constata că numărul fazelor/etapelor variază de la trei (de exemplu analiza, proiectarea, implementarea) la peste douăzeci. Există mai multe modele ale ciclului de viaţă, multe dintre ele cunoscând o evoluţie în timp. Spre exemplu, modelul cascadă (figura 1.3) prevede parcurgerea mai multor etape ale ciclului de viaţă care se derulează secvenţial fiind însă permisă la nevoie revenirea la etapa parcursă anterior în vederea îndepărtării neajunsurilor identificate în etapele superioare ale ciclului de viaţă.Etapele ciclului de viaţă a unui sistem informatic în modelul cascadă ([8]) sunt:1. Analiza şi definirea cerinţelor – sunt definite scopurile, serviciile şi restricţiile pe care trebuie să le îndeplinească sistemul informatic, prezentate într-o manieră încât să poată fi înţelese atât de către utilizatorii sistemului cât şi de personalul de proiectare.2. Proiectarea sistemului şi a software-ului – satabilirea cerinţelor pentru hardware şi software şi elaborarea arhitecturii generale a sistemului. Funcţiile sistemului informaţional vor fi reprezentate astfel încât să poată fi tranformate în unul sau mai multe programe executabile.3. Implementarea şi testarea unităţilor de program – proiectarea software-ului din etapa anterioară este transpusă într-o mulţime de programe sau module program şi verificarea faptului că fiecare program sau modul satisface specificaţia sa.4. Integrarea şi testarea sistemului – integrarea şi testarea programelor şi modulelor program ca un sistem complet pentru a ne asigura că cerinţele informaţionale sunt satisfăcute. După testare sistemul este livrat beneficiarului.5. Exploatarea şi întreţinerea sistemului – este faza în care sistemul informatic este efectiv utilizat de către beneficiar şi în care sunt descoperite şi rezolvate eventuale erori de proiectare şi programare şi omisiuni în cerinţele informaţionale iniţiale.

13

Fig. 1.3. Etapele ciclului de viaţă a unui sistem informatic în modelul cascadă ([8])

1.1.4. Conţinutul bazei informaţionale a unei întreprinderiPentru o întreprindere entităţile bazei informaţionale pot fi grupate după cum

urmează:

pentru activitatea de aprovizionare: stocuri de materiale, intrări materiale, consumuri de materiale, contracte cu furnizorii, programe de aprovizionare;

pentru activitatea de producţie: tehnologii şi reţete de fabricaţie, program de lucru, norme de muncă şi consumuri de manoperă;

pentru activitatea de desfacere: stocuri de produse, contracte cu clienţii, realizări contracte;

pentru activitatea de marketing: evoluţia cererii şi a ofertei, dinamica preţurilor, elasticitatea cererii şi a producţiei;

pentru activitatea financiar-contabilă: solduri şi rulaje contabile, calculaţia costurilor, bugete de venituri şi cheltuieli, contabilitatea analitică şi sintetică;

pentru activitatea de personal: evidenţa personalului, salarizări, dotări social-culturale şi gestiunea lor;

pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte tehnice, investiţii, etc.

1.1.5. Ciclul prelucrării datelor pentru sistemul informaticOperaţiunile care se execută asupra datelor, din momentul apariţiei lor, pentru a

genera informaţii semnificative şi relevante sunt referite la un loc prin noţiunea de ciclul prelucrării datelor, care cuprinde cinci faze [46]: culegerea datelor, pregătirea datelor, prelucrarea datelor, întreţinerea fişierelor şi obţinerea informaţiilor de ieşire.

Faza de culegere a datelor cuprinde două activităţi fundamentale :

14

observarea mediului care generează datele, fie printr-un observator uman, fie prin diverse echipamente;

înregistrarea datelor, fie prin scrierea lor în documentele sursă, fie prin captarea lor sub diferite forme cu ajutorul unor echipamente speciale.

Faza de pregătire a datelor constă într-un număr de operaţii executate asupra datelor pentru a facilita prelucrarea lor ulterioară şi anume:

clasificarea datelor, care implică atribuirea de coduri de identificare (simbol cont, cod secţie, etc.), astfel încât datele să fie incluse în submulţimile corespunzătoare;

gruparea datelor, adică acumularea intrărilor similare, pentru a fi prelucrate în grup;

verificarea datelor cuprinde o mare varietate de proceduri pentru controlul corectitudinii datelor, înainte ca ele să fie prelucrate;

sortarea datelor, prin care grupurile de date sunt aranjate în loturi de înregistrări, după criterii de ordonare numerică, alfabetică, alfanumerică sau de timp;

cuplarea a două sau mai multe loturi de înregistrări într-unul singur; transmiterea datelor de la un punct la altul; transcrierea datelor dintr-o formă în alta, astfel încât să se efectueze trecerea de

la scrierea de mână la cea tipizată sau de la documentele scrise la mediile specifice.

Faza de prelucrare a datelor, poate să includă activităţi, cum sunt: calculaţiile cuprind unele forme de tratare matematică a datelor; compararea supune unei examinări simultane două sau mai multe tipuri de date

între care există o legătură logică (ex. soldul final şi cel final); sintetizarea este o activitate importantă prin care se comasează informaţiile; filtrarea este o altă operaţiune prin care se extrag datele ce vor fi supuse

prelucrărilor următoare; restaurarea, prin care sunt aduse datele din memorie într-o formă accesibilă

omului, pentru prelucrarea umană în continuare, sau într-o formă prelucrabilă tot pe calculator.

În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim: memorarea (stocarea) datelor în vederea utilizării lor viitoare; actualizarea datelor memorate astfel încât să surprindă cele mai recente

evenimente; indexarea datelor pentru a înlesni o uşoară regăsire a lor; protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi

tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.Ultima fază a ciclului de prelucrare a datelor este obţinerea informaţiilor de ieşire.

Informaţiile de ieşire pot fi regăsite în una din următoarele trei forme: documente, rapoarte, răspunsuri la întrebări. De cele mai multe ori, datele nu parcurg toate activităţile, iar unele dintre ele pot să nu treacă prin toate cele cinci faze.

15

Fazele ciclului prelucrării datelor sunt ilustrate în figura 1.4.

Fig. 1.4 Ciclul prelucrării datelor

1.1.6. Sisteme informatice de gestiuneSistemele informatice de gestiune sunt sisteme integrate care crează şi actualizează

o bază de date unică din documentele primare, care va fi ulterior prelucrată pentru obţinerea situaţiilor specifice fiecărui utilizator .

Sistemul informatic de gestiune implică următoarele patru componente interdependente [60]: domeniile de gestiune, datele, modelele, regulile de gestiune.

Domeniile de gestiune corespund activităţilor desfăşurate în cadrul firmei: activitatea de personal, activitatea de producţie, activitatea comercială, activitatea financiar-contabilă, activitatea de cercetare-dezvoltare.

Datele reprezintă „materia primă” ce urmează a fi prelucrată în cadrul sistemului informatic pentru obţinerea informaţiilor necesare luării deciziilor la toate nivelurile manageriale:operaţional, tactic, strategic.

Modelele de gestiune grupează procedurile specifice unui domeniu, iar regulile de gestiune definesc prelucrările ce se efectuează asupra datelor şi modul de utilizare a informaţiilor conform obiectivelor sistemului.

Sistemul informatic de gestiune reuneşte subsisteme informatice specializate pe domenii între care se manifestă interacţiuni specifice. Fiecare subsistem definit grupează procese informaţionale omogene, specifice unui anumit domeniu.

La nivelul fiecărui subsistem vor fi definite aplicaţii distincte corespunzătoare acestor activităţi. La rândul lor aplicaţiile sunt formate din proceduri descompunându-se

16

în module reprezentând secvenţe de cod prin care se realizează o funcţie independentă din cadrul procedurii.Exemplu. O procedură pentru operaţia de actualizare se va descompune în următoarele module:

1. modulul coordonator al funcţiei de actualizare;2. modulul pentru realizarea funcţiei de adăugare de înregistrări;3. modulul pentru funcţia de ştergere înregistrări;4. modulul pentru funcţia de modificare a înregistrărilor din baza de date.

În figura 1.5. este reprezentată schema de principiu pentru sistemul integrat al contabilităţii incluzând contabilitatea de gestiune şi contabilitatea financiară.

Fig.1.5. Sistem informatic de gestiune integrat al contabilităţii (adaptare după [60])

1.2. Metodologii de realizare a sistemelor informaticeRealizarea sistemelor informatice reprezintă o acţiune complexă, care îmbină un

număr mare de activităţi: analiză, proiectare, implementare, exploatare [11]. În plus, reclamă resurse umane, materiale şi financiare însemnate, pe o perioadă considerabilă de timp. Folosirea eficientă a acestor resurse, în scopul obţinerii unui sistem informatic performant a impus ordonarea acestui proces complex, într-o succesiune bine stabilită de etape şi subetape şi utilizarea unor metode şi tehnici adecvate. Aceste observaţii au condus la conturarea unor metodologii de realizare a sistemelor informatice.

Între diversele etape de realizare a sistemelor informatice există o legătură indestructibilă, legătură reflectată şi de faptul că în mod logic şi practic calitatea realizării unor activităţi din etapele şi fazele precedente influenţează în mod decisiv calitatea activităţilor din etapa care urmează.

17

1.2.1. Conţinutul metodologiilor de realizare a sistemelor informaticeMetodologiile de realizare a sistemelor informatice cuprind [11]: modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre

variaţiile sistemului şi dinamismul său; regulile de formalizare a datelor şi proceselor de prelucrare; instrumentele pentru concepţia, realizarea şi elaborarea documentaţiei; modalitatea de derulare a proiectului şi acţiunile specifice fiecărei etape (ciclul

de viată); definirea modului de lucru, rolului analiştilor şi proiectanţilor şi a raportului

dintre ei; modalităţile de administrare a proiectului (planificare, programare, urmărire). Totodată, metodologiile au rolul de a indica modul de desfăşurare a acestui proces,

stabilind [11]: componentele procesului de realizare a sistemului informatic (etape, subetape,

activităţi, operaţii) şi conţinutul lor; fluxul parcurgerii (executării) componentelor; metodele, tehnicile, procedeele,

instrumentele, normele si standardele utilizate. În funcţie de modul de abordare şi domeniul de aplicabilitate, metodologiile

utilizate sunt: metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE

(Ministerul industriei-Franta), IE (James Martin), SSADM (Marea Britanie); metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael

Jackson); metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S,

METHOD/ 1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin).

1.2.2. Metode şi tehnici de realizare a sistemelor informaticeLa realizarea sistemelor informatice se utilizează : metode, tehnici, instrumente,

procedee de lucru [11]. Metodele utilizate în proiectarea sistemelor informatice reprezintă modul unitar

sau maniera comună în care analiştii de sisteme, programatorii şi alte categorii de persoane implicate, realizează procesul de analiză a sistemului informaţional-decizional existent, proiectarea şi introducerea sistemului informatic. Deci, metoda are un caracter general, în cadrul ei aplicându-se anumite tehnici de lucru.

Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă felul în care se acţionează eficient şi rapid, în cadrul unei metode, pentru soluţionarea diferitelor probleme ce apar în procesul de proiectare. Prin aceste tehnici se îmbină armonios cunoştinţele despre metode cu măiestria personală a celor chemaţi să aplice metodele si să utilizeze instrumentele adecvate [11].

Utilizarea acestor metode, tehnici, instrumente, procedee de lucru în proiectarea sistemelor informatice se face în conformitate cu o serie de principii şi în limita unor metodologii de lucru care se adoptă în funcţie de situaţia reală la care se referă.

18

În abordările incipiente se lucra cu probleme izolate şi ulterior s-a efectuat trecerea la abordarea sistemică (modulară), odată cu abordarea funcţională sau, mai bine zis, cu analiza şi descompunerea funcţională (în fiecare modul există câte o funcţie) şi ulterior abordarea orientată-obiect [11]. Pe parcurs s-au impus două strategii de abordare şi anume:

strategia top down (de sus în jos); strategia bottom – up evolutivă (de jos în sus).În strategia top – down abordarea generală este divizată în unităţi componente prin

rafinări repetate, metoda de proiectare putând fi descrisă sub forma unei diagrame ierarhice cu module de control pe nivele superioare şi cu module detaliate pe nivelele inferioare. Structura organizatorică a unei unităţi economico-sociale numită organigrama unităţii poate fi reprezentată printr-o astfel de diagramă ierarhică. Pentru unităţi economice productive în organigramă se disting următoarele patru nivele de reprezentare [8]:

nivelul conducerii strategice, reprezentat de directorul general şi consiliul de administraţie;

nivelul conducerii tactice (directori pe funcţiuni); nivelul compartimentelor funcţionale (servicii şi posturi de lucru) şi de

proiectare, cercetare (laboratoare) care asigură conducerea operativă a sistemului prin şefii lor;

nivelul compartimentelor de producţie (secţii, ateliere) care realizează funcţia de producţie a sistemului economic.

În strategia bottom – up evolutivă, se porneşte de la o tratare minimală care se extinde treptat pe măsura înaintării în realizarea sistemului.

În practică, de cele mai multe ori se utilizează o combinare a celor două strategii.Metodele de abordare a sistemelor informatice ar putea fi grupate prin prisma celor

mai mulţi autori astfel [46]: metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale; metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece

diagramele fluxurilor de date se întrebuinţează pentru descrierea proceselor; metode orientate spre informaţie sau date, orientate-informaţii, apărute ca

urmare a popularizării puternice a ingineriei informaţiei a lui JAMES MARTIN, dar şi a diagramelor entitate-relaţie ale lui CHEN [12];

metode orientate-obiect.Caracteristici esenţiale ale principalelor metode

Informaţia este văzută de DeMarco în 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor informaţionale sau prin trei dimensiuni: date, funcţii, comportament [46].

Datele sunt reprezentate sub formă de atribute (având în vedere structura lor), înseamnă ceea ce este stocat şi reflectă structura statică a sistemului.

Funcţiile scot în evidenţă în mod limitat ceea ce face sistemul. El poate fi văzut şi ca un proces, întrucât elementele sistemului despre care se păstrează datele de rigoare sunt supuse unor transformării funcţionale, prin intermediul proceselor.

19

Comportamentul este invocat pentru a reda o altă modalitate de percepţie a sistemului, influenţa evenimentele şi proprietăţilor sistemului, şi sugerează dinamica lui.Metoda descompunerii funcţionale (orientate funcţii)

Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm pe câţiva cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco&Gowan. Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi analizei structurate. Fiecare funcţie este descompusă în subfuncţii, până se obţin structuri uşor de transpus în instrucţiunile limbajelor de programare.Metodele fluxurilor de date (orientate-proces)

Prin această metodă analiştii efectuează reprezentarea lumii reale prin simboluri care reprezintă fluxul datelor, transformările datelor, stocarea datelor, entităţi externe, etc. Metoda orientată spre procese are încă un mare grad de asemănare cu descompunerea funcţională.Metode orientate spre informaţii (orientate-date)

Două realizări importante în domeniu au dat tonul unei orientări în abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen (1976) şi ingineria informaţiei, în viziunea lui James Martin.Metoda orientată-obiect

Metodele OO constituie o categorie particulară a metodelor de dezvoltare software, care privesc construirea sistemelor pentru care clasa reprezintă unitatea arhitecturală fundamentală. Clasa este o grupare logică a obiectelor care au aceeaşi structură şi un comportament similar. O clasă poate fi divizată în subclase cu proprietatea că subclasele moştenesc proprietăţile clasei şi în plus pot avea proprietăţi suplimentare. Un sistem informatic este gândit ca un ansamblu de obiecte autonome astfel încât datele şi prelucrările (metodele) sunt definite în cadrul aceleiaşi structuri şi anume obiectul.

Teste rezolvate1. Care definiţie este corectă:

20

a) Un sistem reprezintă un ansamblu de elemente (componente) interdependente, între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv;

b) Un sistem este un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor..

Răspuns: a,b2. Sistemul informaţional cuprinde:

a) Ansamblul informaţiilor interne şi externe, formale sau informale utilizate în cadrul firmei precum şi datele care au stat la baza obţinerii lor;

b) Procedurile şi tehnicile de obţinere(pe baza datelor primare) şi de difuzare a informaţiilor;

c) Platforma necesară prelucrării şi disipării informaţiilor;d) Personalul specializat în culegerea, transmiterea, stocarea şi prelucrarea datelor.

Răspuns: a,b,c,d3. Un sistem informatic este:

a) un sistem destinat conducerii unei organizaţii,b) un sistem utilizator-calculator integrat, care furnizează informaţii pentru a sprijini

activităţile de la nivel operaţional şi activităţile de management într-o organizaţie, utilizând echipamente hardware şi produse software, proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare, control şi luarea deciziilor,

c) un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor.

Răspuns: b,c4. Identificaţi afirmaţia falsă:

a) Sistemul informaţional este subordonat sistemului de conducere. b) Sistemul informaţional face legătura între sistemul condus şi sistemul de

conducere. c) Sistemul informatic este inclus în sistemul informaţional.d) Sistemul condus este subordonat sistemului informaţional.

Răspuns: d5. Sunt componente principale ale unui sistem informatic:

a) Baza informaţională;b) Manager general;c) Baza tehnică;d) Baza ştiinţifică metodologică;e) Sistemul de programe.

Răspuns: a,c,d,e6. Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie:

a) asigurarea conducerii cu informaţii reale şi în timp util necesare fundamentării şi elaborării operative a deciziilor;

b) asigurarea funcţionării normale si optime a activităţilor;c) creşterea productivităţii muncii;

21

d) creşterea profitului;e) îmbunătăţirea imaginii unităţii economice.

Răspuns: a7. După domeniul de utilizare, sistemele informatice se clasifică în:

a) Sisteme informatice pentru conducerea activităţilor economico-sociale;b) Sisteme informatice pentru conducerea proceselor tehnice;c) Sisteme informatice şi expert;d) Sisteme informatice pentru activităţi speciale.

Răspuns: a,b,d8. După modul de organizare a datelor, Sistemele informatice economice pot fi împărţite

în:a) sisteme imagine;b) sisteme bazate pe tehnica bazelor de date (ierarhice, reţea, relaţionale, orienatate-

obiect);c) sisteme bazate pe algoritmi fundamentali;d) sisteme bazate pe fişiere.

Răspuns: b,d9. Ciclul prelucrării datelor pentru sistemul informatic cuprinde următoarele faze:

a) culegerea datelor; b) pregătirea datelor;c) prelucrarea datelor;d) ştergerea datelor.

Răspuns: a,b,c10. În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim:

a) memorarea(stocarea) datelor în vederea utilizării lor viitoare;b) actualizarea datelor memorate astfel încât să surprindă cele mai recente

evenimente;c) crearea datelor;d) indexarea datelor pentru a înlesni o uşoară regăsire a lor;e) protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi

tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.Răspuns: a,b,d,e

11. Metodologiile de realizare a sistemelor informatice cuprind: a) reguli de formalizare a datelor;b) instrumente pentru concepţia, realizarea şi elaborarea documentaţiei;c) modalităţile de administrare a proiectului;d) instrucţiuni pentru luarea deciziilor;e) modalitatea de abordare a sistemelor.

Răspuns: a,b,c,e

12. Reprezintă modul unitar sau maniera comună în care analiştii de sisteme, programatorii şi alte categorii de persoane implicate realizează procesul de analiză a sistemului informaţional-decizional existent, proiectarea şi introducerea sistemului informatic:

22

a) metodele utilizate în proiectarea sistemelor informatice;b) procedurile utilizate în proiectarea sistemelor informatice;c) tehnicile de lucru utilizate în proiectarea sistemelor informatice;d) instrumentele utilizate în proiectarea sistemelor informatice.

Răspuns: a

13. Care din afirmaţiile următoare sunt corecte:a) Metoda top-down are ca obiectiv principal realizarea modularizării sistemului de

sus în jos.b) Metoda top-down constă în agregarea modulelor de jos în sus.c) Metoda top-down nu are la bază principiul abordării sistemice.

Răspuns: a14. Nu sunt faze ale ciclului de viaţă al dezvoltării sistemelor:

a) microanaliza;b) analiza;c) colectarea;d) proiectarea logică;e) proiectarea fizică;f) implementarea;g) întreţinerea.

Răspuns: c

Întrebări1. Enumeraţi principalele activităţi din cadrul unei intreprinderi în vederea

identificării entităţilor bazei informaţionale.2. Definiţi tipurile de reţele de calculatoare după aria de întindere geografică.3. Definiţi tipurile de reţele de calculatoare după accesibilitate.4. Prezentaţi tipurile de echipamente care pot fi utilizate în cadrul unui sistem

informatic.5. Enumeraţi produsele software de bază care pot fi utilizate pentru realizarea unui

sistem informatic.6. Definiţi ciclul de viaţă a unui sistem informatic.7. Enumeraţi etapele ciclului de viaţă a unui sistem informatic în modelul cascadă.8. Enumeraţi metodologiile utilizate în funcţie de modul de abordare şi domeniul de

aplicabilitate9. Enumeraţi cele 4 nivele care pot fi identificate în organigrama unei unităţi

economice Productive.

23

Capitolul 2. Iniţierea şi planificarea realizării unui sistem informatic

2.1. Identificarea, selecţia, iniţierea şi planificarea proiectelorIdentificarea şi selecţia proiectelor de dezvoltare a sistemelor informatice

reprezintă prima etapă din ciclul de viaţă a dezvoltării sistemelor care, împreună cu iniţierea şi planificarea proiectelor, constituie microanaliza, componentă preluată din managementul proiectelor. Evidenţierea acestor activităţi în cadrul modelului cascadă de derulare a fazelor sau etapelor ciclului de viaţă a sistemului este reprezentată în figura 4.1 [46].

Figura 2.1 Ciclul de viaţă al dezvoltării sistemelor [46]\

Fiecare etapă sau fază de realizare a unui sistem informatic se descompune în activităţi. Astfel pentru identificarea şi selecţia proiectelor se parcurg activităţile:

identificarea potenţialelor proiecte de dezvoltare; clasificarea şi ierarhizarea lor; selecţia proiectului.

Identificarea potenţialelor proiecte de dezvoltareProblema esenţială a activităţii de identificare a potenţialelor proiecte de dezvoltare

a sistemului constă în nominalizarea celor ce pot fi abilitaţi să facă propuneri pertinente. Aceştia pot fi: top-managerii, comitetul de iniţiativă, departamentul utilizatorilor, grupul de dezvoltare. Caracteristicile esenţiale ale variantelor de proiecte propuse în cele patru situaţii sunt prezentate tabelul 2.1.Tabel 2.1 Variante de proiecte [46]

Propuneri Metoda de selecţie Caracteristicile proiectului

24

a proiectului

De sus în jos

Top-managerii orientare puternică spre strategie; cele mai mari dimensiuni ale proiectului; cele mai de durată proiecte.

Comitetul de iniţiativă

orientare mixtă (a diferiţilor reprezentanţi); vizează schimbările organizaţionale cele mai

mari; analiză formală a costurilor şi avantajelor

proiectelor; proiecte mai mari şi mai riscante.

De jos în sus

Departamentulutilizatorilor

limitat, neorientat strategic; realizare mai rapidă; câţiva utilizatori reprezintă niveluri ale

conducerii, precum şi funcţiile întreprinderii.Grupul de dezvoltare

integrare în sistemul existent; puţine întârzieri în realizarea proiectului; mai puţin interesat de analizele cost – avantaje.

Selecţia proiectelor de dezvoltare a sistemelor informaţionaleDatorită efectelor diferite şi a amplitudinii lor, se recomandă evidenţierea distinctă

a proiectelor pe termen lung şi a celor pe termen scurt. Dintre ele se selectează cele ce ating obiectivele organizaţiei. De asemenea, se va urmări modul în care proiectele se aliniază dinamicii unităţii. Iniţierea şi planificarea proiectelor

Pentru realizarea acestei faze este nevoie de comunicarea efectivă dintre părţile implicate( analişti, clienţi - manageri, utilizator).

Iniţierea proiectuluiDin momentul selecţiei lui, proiectul trece în faza de iniţiere, ceea ce presupune

desfăşurarea unei activităţi laborioase, prestată de un responsabil, cunoscut în practică sub numele de manager de proiect, care răspunde de [46]:

Elaborarea unor studii de fezabilitate generală; Elaborarea planurilor detaliate ale proiectelor; Găsirea celor mai buni membri ai echipei proiectului.Managerul de proiect trebuie să dea dovadă de multe calităţi pentru a putea jongla

cu elemente cum sunt: Schimbările tehnologice; Ciclul de viaţă al sistemelor; Contractori şi furnizori; Managementul resurselor umane; Metodologie şi instrumente de lucru diferite; Restricţii de timp şi resurse; Documentare şi comunicare;

25

Aşteptările managerilor şi clienţilor.Activităţile efectuate în faza iniţierii proiectului sunt:

1. stabilirea echipei de iniţiere a proiectului;2. stabilirea bunelor relaţii cu beneficiarii;3. stabilirea planului iniţierii proiectului;4. stabilirea procedurilor manageriale;5. stabilirea cadrului de desfăşurare a proiectului.

Planificarea proiectuluiPlanificarea proiectului va cuprinde o evaluare a cerinţelor informaţionale ale

sistemului la nivelul întregii organizaţii.Planificarea proiectului este procesul prin care are loc definirea clară a activităţilor

şi a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.Tipurile activităţilor executate în cadrul planificării proiectului cuprind [46]:

1. Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului;2. Descompunerea proiectului în activităţi uşor executabile şi controlabile;3. Estimarea resurselor şi crearea unui plan al resurselor;4. Realizarea unei prime planificări calendaristice;5. Realizarea unui plan al comunicărilor;6. Determinarea standardelor şi procedurilor proiectului;7. Identificarea şi evaluarea riscului;8. Crearea unui buget preliminar;9. Întocmirea rapoartelor de activitate;10. Definitivarea planului de bază al proiectului.

2.2. Studii de fezabilitate

Elaborarea unui sistem informatic poate costa milioane de dolari şi se poate realiza pe parcursul a trei până la şase ani pentru a fi complet. Din aceste motive, este normal ca factorii de conducere să demareze proiectarea unui nou sistem după ce se efectuează studii de fezabilitate.

Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja început mai poate fi continuat. Proporţiile şi durata studiilor de fezabilitate variază, în funcţie de mărimea şi natura sistemului implementat. În cazul sistemelor bazate pe calculatoare mari, studiul are cu totul alte dimensiuni faţă de varianta utilizării microcalculatoarelor [46].

Fezabilitatea proiectului poate fi studiată în orice fază a elaborării lui, dar studiile, de regulă, se efectuează în momente certe. Când este propus un proiect, se efectuează un studiu preliminar de fezabilitate pentru a se stabili dacă proiectul atinge obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de subiectivă, întrucât proiectul nu este reprezentat cu lux de amănunte. Însă, îndată ce se obţine o situaţie mai clară despre sistem, despre natura problemei de rezolvat, precum şi despre doleanţele

26

utilizatorilor, măsurarea preliminară a fezabilităţii poate fi determinată odată cu faza de analiză a sistemului. Când proiectanţii oferă două sau trei variante de elaborare a sistemului, numai studiile de fezabilitate determina varianta optimă.

După ce a avut loc proiectarea primară a sistemului, pot fi determinate în detaliu elementele de cost ale proiectării, implementării şi exploatării. Este ultima posibilitate de a renunţa la sistem, înaintea implementării lui.

Pe parcurs, odată cu progresul înregistrat în dezvoltarea sistemului informatic, se obţin informaţii din ce în ce mai certe, oferindu-se posibilitatea unor analize de fezabilitate mult mai concludente, ceea ce atrage studierea fezabilităţii în diverse faze ale ciclului de viaţă al sistemelor. De fiecare dată, studiile de fezabilitate trebuie să aibă la bază o foarte bună documentaţie. Aceasta va conţine [46]:

Definirea problemei (o scurtă descriere a proiectului şi explicarea a ceea ce-şi propune el să realizeze);

Descrierea cerinţelor sistemului; Descrierea soluţiilor sistemului propus; Explicaţia critică a motivării studiului întreprins; Cuantificarea tuturor costurilor materiale şi beneficiilor aferente; O listă a costurilor şi beneficiilor necuantificabile.

2.3. Tehnici de reprezentare a planurilor şi programarea calendaristică

Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea şi descrierea planurilor proiectelor. Documentaţia planificării poate fi alcătuită din:

rapoarte grafice - cele mai folosite (fig. 2.2 )rapoarte sub formă de text.

O diagrama Gantt este o modalitate de reprezentare grafică a proiectului. Cu ajutorul barelor orizontale sunt prezentate activităţile planificate. Lungimea barelor este proporţională cu timpul alocat activităţilor reprezentate. Se pot folosi diferite culori, umbre sau forme pentru a scoate în relief anumite activităţi. Ceea ce s-a planificat şi realizat, de asemenea, pot fi evidenţiate prin bare paralele de culori, forme sau umbre diferite. Diagramele Gantt nu indică ordinea activităţilor (precedenţa lor), ci indică data începerii şi pe cea a finalizării. Se recomandă pentru descrierea proiectelor simple sau a unor componente ale proiectelor mari, sau a activităţilor prestate doar de o singură persoană, precum şi pentru monitorizarea modului în care se efectuează activităţile în comparaţie cu cele planificate (ca dată).

Evidenţa promovării vânzărilor (EPV)

Nr.Crt.

Nume activitate

Aprilie 2005

Mai 2005

Iunie 2005

Iulie 2005

August 2005

Septembrie 2005

1. Colectarea cerinţelor

27

2. Proiectare ecrane

3. Proiectare rapoarte

4. Proiectare baze de date

5. Documentaţie utilizator

6. Programare7. Testare8. Instalare9. Şedinţa de

analiză

Proiect: EPVData:Analist:

Critic: În lucru: Sinteză:

Necritic: Punct de reper: Derulat:

Figura 2.2. Diagrama Gantt pentru descrierea planului proiectului [46]

Teste rezolvate1. Propunerile pentru identificarea proiectelor de dezvoltare sunt făcute de:

a) top-manageri; b) personalul auxiliar;c) muncitori; d) departamentul utilizatorilor.

Răspuns: a, d2. Selecţia proiectelor de dezvoltare a sistemelor informaţionale, urmăreşte:

a) atingerea obiectivelor organizaţiei;b) bunul mers a informaţiei;c) creşterea duratei de implementare.

Răspuns: a3. Care nu sunt activităţile efectuate în faza iniţierii proiectului:

a) stabilirea echipei de iniţiere a proiectului;b) stabilirea bunelor relaţii cu beneficiarii;c) stabilirea planului iniţierii proiectului;d) stabilirea procedurilor manageriale;

28

e) stabilirea cerinţelor sistemului.Răspuns: e

4. Tipurile activităţilor executate în cadrul planificării proiectului cuprind:a) Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului;b) Descompunerea proiectului în activităţi uşor executabile şi controlabile;c) Crearea bazei de date;d) Crearea unui buget preliminar;e) Implementarea proiectului.

Răspuns: a, b, d5. Următoarele afirmaţii sunt corecte:

a) Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja început mai poate fi continuat;

b) Studiul de fezabilitate face parte din etapa de întreţinere a sistemelor;c) Diagrama Gantt este o modalitate de reprezentare grafică a proiectului.

Răspuns: a, c6. Studiile de fezabilitate trebuie să conţină:

a) Definirea problemei (o scurtă descriere a proiectului şi explicarea a ceea ce-şi propune el să realizeze);

b) Descrierea cerinţelor sistemului;c) Explicaţia critică a motivării studiului întreprins;d) Cuantificarea tuturor costurilor materiale şi beneficiilor aferente.

Răspuns: a, b, c, d7. Diagramele Gantt se utilizează pentru:

a) reprezentarea ordinii activităţilor desfăşurate pentru realizarea proiectului;b) reprezentarea grafică a proiectului;c) descrierea proiectelor simple sau a unor componente ale proiectelor mari;d) monitorizarea stadiului realizării activităţilor planificate.

Răspuns: b, c, d

29

Capitolul 3. Analiza sistemului existent şi definirea cerinţelor noului sistem

3.1. Studiul sistemului informaţional existentPrin sistem existent se înţelege realitatea obiectivă din organizaţia pentru care

urmează a se realiza sistemul informatic solicitat printr-o comandă numită cererea beneficiarului.

Analiza sistemului existent şi definirea cerinţelor noului sistem este prima etapă din ciclul de viaţă al dezvoltării sistemelor informatice, etapă prin care se determină modul în care funcţionează sistemul informaţional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul sistem. Studiul şi analiza sistemului existent are ca obiectiv principal stabilirea cerinţelor informaţionale ale conducerii în vederea realizării unui sistem informatic.

Studiul sistemului existent cuprinde un grup de activităţi care urmăresc cunoaşterea performantelor tehnico-funcţionale ale sistemului informaţional, atât în ansamblul său, cât şi pentru elementele de structură ale acestuia, a cerinţelor informaţionale ale conducerii, cunoaşterea lipsurilor şi restricţiilor pe care le prezintă sistemul existent faţă de aceste cerinţe. De modul de realizare a acestor activităţi depinde întregul proces de realizare a sistemului informatic.

Studiul sistemului existent constă în [11]: definirea caracteristicilor generale ale sistemului economic;studiul activităţilor de bază desfăşurate în sistem;studiul sistemului de conducere;studiul sistemului informaţional;identificarea metodelor şi mijloacelor tehnice.

Definirea caracteristicilor generale ale sistemului economic implică : cunoaşterea profilului, obiectivelor agentului economic; cunoaşterea locului în sfera serviciilor si sfera producţiei; cunoaşterea relaţiilor de cooperare cu alţi agenţi economici; cunoaşterea specificului activităţii de bază ( producţie, servicii); cunoaşterea nivelului tehnic; cunoaşterea principalilor indicatori economici şi evoluţia lor; dezvoltarea, modernizarea etc.

Studiul activităţilor desfăşurate în sistemul economic, modul de realizare a funcţiunilor unităţii economice se face prin:

1. Pe baza statutului de funcţionare a societăţii se studiază:- activităţile şi sarcinile din cadrul acestor funcţiuni;- atribuţiile ce revin compartimentelor;- modul de realizare a activităţilor funcţionale din cadrul unităţii economice.

2. În cazul activităţii de producţie se prezintă:fluxul de producţie, amplasarea locurilor de muncă, depozitelor etc.;tipurile de produse, structura lor, ciclurile de realizare;

30

modul de organizare a producţiei, stocarea producţiei, transporturile interne, controlul de calitate;resursele existente:

capacităţi;asigurarea tehnică / proiectarea de produse noi;norme tehnice;

asigurarea cu materiale necesare;sistemul existent de programare a producţiei.

Studiul sistemului de conducere se referă la: identificarea caracteristicilor sistemului de conducere existent;sistemul de indicatori cantitativi şi valorici; organizarea conducerii; caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de decizii, modul de lucru a deciziilor.

Studiul sistemului informaţional presupune: elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea); estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de culegere şi prelucrare; identificarea principalilor algoritmi, regulilor de calcul şi a punctelor si regulilor de control; cunoaşterea principalelor restricţii ale sistemului informaţional; situaţia raţionalizării fluxurilor şi a documentelor din unitatea economica, studii elaborate, stadiul lor de implementare; sistemul de codificare utilizat, restricţii; performanţele şi limitele sistemului informaţional existent.

Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea datelor în cadrul sistemului informaţional existent se face evidenţiind: mijloacele tehnice existente în dotarea unităţii economice ( modul de utilizare, cheltuielile de exploatare, personalul implicat, performante); existenţa unor aplicaţii proiectate şi/sau implementate.

3.2. Determinarea cerinţelor sistemuluiDeterminarea cerinţelor sistemului este activitate esenţială în aflarea situaţiei

existente şi a ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor sistemului se concretizează în diferite forme ale informaţiilor colectate, cum sunt copii ale interviurilor, însemnări efectuate în timpul observării şi analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru ş.a., precum şi rezultate ale prelucrărilor efectuate de calculator, cum ar fi prototipurile [46].

Rezultatele prezentate după această activitate pot fi rezumate astfel:1. Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea

activităţilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la

31

chestionare sau interpretări ale acestora, însemnări şi rezultate din observarea activităţilor, procese verbale ale şedinţelor ce au avut loc în acest scop;

2. Informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare ale formularelor, rapoartelor şi machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme şi documentaţia sistemului existent, rapoartele consultanţilor;

3. Informaţii obţinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fişierelor sesiunilor grupului de sprijinire a sistemului, conţinutul depozitelor şi rapoartele existente în CASE, ecrane şi rapoarte rezultate din prototipurile sistemului, ş.a.

3.2.1. Metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemuluiMetodele utilizate frecvent în analiza sistemului existent sunt: Interviul; Chestionarul.

Interviul este o metodă foarte răspândită pentru culegerea informaţiilor din sistemul informaţional. Utilizatorii acestei metode sunt în general analiştii care nu sunt familiarizaţi cu unitatea studiată şi cu problemele ei. Prezintă avantajul că lasă foarte multă libertate creativă analistului în construirea şi desfăşurarea lui. În alegerea persoanelor de intervievat trebuie avute în vedere următoarele constatări [8]:

persoanele care ocupă poziţii medii în ierarhia structurii organizatorice furnizează informaţiile cele mai apropiate de realitate;

colectarea de informaţii corecte necesită intervievarea atât a personalului de conducere, cât şi a celui de execuţie;

în prealabil trebuie verificată competenţa subiecţilor intervievaţi; lipsa unei atitudini critice poate să denote reţineri în exprimarea ideilor.Se vor efectua interviuri la nivelul conducerii şi interviuri la nivelul posturilor de

lucru.Rezultatul interviului este consemnat în raportul de interviu care trebuie semnat de

către persoanele intervievate.

Chestionarul poate fi utilizat atât de către analiştii începători, cât şi de către cei avansaţi, familiarizaţi sau nu cu problemele informaţionale-decizionale ale unităţii. Prin utilizarea lui dispare “filtrul de informaţii” care este analistul iar cel care furnizează informaţii are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând această metodă, participă un număr mare de “furnizori de informaţii”. Limitele chestionarului constau în faptul că este o metodă de verificare a unor cunoştinţe prealabile, fapt ce implică cunoaşterea prealabilă a domeniului.

Această metodă necesită timp relativ îndelungat pentru întocmirea chestionarului precum şi de culegere şi prelucrare a răspunsurilor. Chestionarul nu are o arie largă de utilizare.

32

3.2.2. Metode moderne de analiză şi determinare a cerinţelor sistemuluiCa efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în

ultimii ani, s-a efectuat trecerea spre analiza mai puţin pronunţată a sistemelor ce urmează a se realiza. Tehnicile moderne, JAD şi prototipizarea, preiau tot mai puţine elemente din sistemele existente, ca urmare a analizei efectuate. Altele mai radicale renunţă aproape total la analiza sistemului existent, este cazul proceselor controlate prin RAD, care apelează la JAD, prototipizare şi alte instrumente de tip CASE [46].

Joint Application Design(JAD)Spre sfârşitul anilor 1970, specialiştii în realizarea de sisteme de la IBM au

elaborat un nou proces de culegere a cerinţelor informaţionale ale sistemelor şi de revizuire a proiectelor sistemelor, numindu-se JAD.

Ideea principală a proiectării JAD o constituie punerea laolaltă a tuturor forţelor interesate în dezvoltarea sistemelor: utilizatori-cheie, managerii şi analiştii de sistem implicaţi în analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totuşi în sesiunea JAD se urmăreşte o anumită secvenţă de derulare a activităţilor, pe baza unor roluri bine stabilite.

Prototipizarea şi determinarea cerinţelor sistemelorPrototipizarea este un proces interactiv prin care analiştii şi utilizatorii pun în

discuţie o versiune rudimentară a unui sistem informaţional, care va fi într-o continuă schimbare, în funcţie de reacţia utilizatorilor. Prototipizarea renunţă la ciclul de viaţă al dezvoltării sistemelor sau la creşterea rolului său [46].

Pentru culegerea informaţiilor despre cerinţele utilizatorilor încă se apelează la interviuri, dar prin prototipizare, operaţiunea va fi mai simplă şi va solicita un timp mai scurt. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze ce ar mai dori, dar şi să-şi genereze această formă nouă, cu ajutorul specialiştilor.

Prototipizarea este facilitată de câteva limbaje sau produse program, inclusiv instrumentele de tip CASE.

Prototipizarea este foarte utilă în determinarea cerinţelor sistemului atunci când [46]:

cerinţele utilizatorului nu sunt prea clar formulate sau bine înţelese; unul sau mai mulţi utilizatori sau susţinători sunt implicaţi în sistem; se utilizează anumite mijloace de lucru (formulare şi rapoarte predefinite).Prototipizarea generează şi deficienţe, cum ar fi: tendinţa de evitare a unui cadru formal de elaborare a documentaţiei privind

cerinţele sistemului, ceea ce va îngreuna în viitor orice control; fiind conceput de un număr mic de utilizatori va fi probabil respins de viitorii

utilizatori; fiind conceput izolat este puţin probabil ca el să fie integrat în sistemul existent;

33

nerespectându-se etapele ciclului de viaţă al dezvoltării sistemelor pot fi omise aspecte esenţiale, cum ar fi securitatea, controlul datelor introduse şi standardizarea la nivel de sistem.

Paşii prototipizării sunt [46]: Identificarea cerinţelor principale ale sistemului; Realizarea prototipului iniţial; Proces iterativ de adaptare a sistemului la cerinţele utilizatorului; Folosirea sistemului aprobat de utilizatori.După determinarea cerinţelor sistemului urmează structurarea acestora prin

utilizarea unor instrumente specifice de modelare logică.

3.3. Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilorIndiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate

apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de date fizice şi diagrame ale fluxului de date logice. Altele apelează la combinaţii de diagrame, tabele şi forme descriptive [46].

Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat, prin specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de entităţi externe sistemului analizat.

3.3.1. Diagramele fluxurilor de date (DFD)Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,

reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent.

Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor şi cerinţele funcţionale ale noului sistem.

Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau depozitele CASE (repository) [46].

Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor.

DFD reprezintă doar una din tehnicile de analiză structurată.Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor

fluxurilor de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu ajutorul calculatorului, adică în instrumente CASE.

Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD

În analiza sistemelor se folosesc frecvent reprezentările grafice, de exemplu diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului informaţional. Proiectarea fluxului informaţional reprezintă circulaţia informaţiei în

34

sistem, transformările suferite, stocarea informaţiei precum şi scurgerile de informaţie în afara sistemului. Scopul diagramelor de date DFD pentru o anumită componentă organizatorică sau funcţională la care se referă (secţie, birou, compartiment, întreaga unitate, o anumită activitate – vânzări, cumpărări, încasări, plăţi, ş.a) este de a scoate în relief, într-o manieră cât mai sugestivă, următoarele aspecte [46]:

sursa datelor de prelucrare;operaţiunile de prelucrare prin care trec datele;destinaţia datelor prelucrate;legătura existentă între prelucrări şi activitatea de stocare a datelor.

Întocmirea diagramelor de flux de date (DFD) DFD este o reprezentare grafică a transformării datelor de intrare în date de ieşire

folosind un set de simboluri de reprezentare şi un set de reguli de completare şi validare. Simboluri folosite în diagramele realizate cu SSADM

proces (transformare): Procesele sunt etichetate cu text ce sugerează modul de transformare a datelor şi sunt identificate printr-un număr(descriere a funcţiei procesului de prelucrare, începând cu un verb, urmat de o descriere a obiectului funcţiei de prelucrare). În DFD fizică pentru sistemul existent, se va preciza şi locaţia (compartiment / persoană) procesului.

flux de date: este constituit din datele transmise între două procese. Fluxul de date este etichetat printr-un substantiv ce sugerează informaţia sau pachetul de informaţii transmise.

entitate externă (terminator): sursă / receptor de date. Poate fi un alt sistem (organizaţie, compartiment).

stoc de date: un depozit temporar sau permanent de date. Poate fi:

manual: registre, dosare, arhivă de documente pe suport magnetic: fişiere.

Convenţii folosite în diagramele de reprezentare a fluxurilor de date DFD: procesele şi stocurile de date sunt numerotate secvenţial, pentru a putea fi

identificate. Numerele asociate proceselor nu semnifică ordinea de execuţie a acestora;

pentru a evita fluxurile de date întretăiate şi aspectul de “păienjeniş” al diagramei, entităţile externe şi stocurile de date pot fi duplicate. O entitate

35

externă duplicată se reprezintă prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentară verticală în partea stângă a cutiei;

pentru a face diagramele mai lizibile, entităţile externe sunt plasate, pe cât posibil, în jurul diagramei iar stocurile de date, în partea centrală a diagramei;

fluxurile de date de la - către stocurile de date sunt unidirecţionale (fie de adăugare, fie de consultare) şi nu sunt etichetate.

3.3.2. Descompunerea funcţională şi rafinarea DFD Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să

realizăm de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o descompunere funcţională a sistemului, care este realizată prin rafinarea succesivă a proceselor.

Primul nivel (nivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care defineşte graniţele între sistemul analizat si mediu.

Nivelele următoare se obţin prin rafinarea proceselor complexe într-o diagramă de nivel inferior.

Pentru aplicaţia DECONTĂRI au rezultat următoarele diagrame [46]:

Figura 3.1. Diagrama contextuală pentru aplicaţia Decontări

36

Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicaţia Decontări

37

Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaţia Decontări

Definirea direcţiilor de perfecţionare a actualului sistemPe baza activităţilor de evaluare şi analiză critică se identifică neajunsurile

actualului sistem şi se propun soluţii de înlăturare a acestora se formulează variante de soluţii, iar în cadrul acestora se definesc cerinţele şi restricţiile de realizare a sistemului informatic.

Definirea direcţiilor de perfecţionare presupune: 1. specificarea obiectivelor şi a performantelor sistemului informatic; 2. stabilirea domeniilor de probleme şi a principalelor funcţiuni ale sistemului

informatic; 3. definirea cerinţelor si restricţiilor informaţionale pe domenii de probleme şi funcţiuni

care constă în: definirea principalelor intrări/ ieşiri; definirea soluţiei de organizare a datelor; definirea variantelor tehnologice de prelucrare; definirea restricţiilor informaţionale şi de control.

38

4. formularea condiţiilor pentru realizarea sistemului informatic, care constă în: specificarea termenelor şi duratelor solicitate; precizarea priorităţilor în realizarea obiectivelor sistemului informatic; specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu alte

sisteme, gradul de generalizare al sistemului. Pentru fiecare variantă de soluţie informatică se procedează la: evaluarea resurselor necesare (costurile de sistem); evaluarea efectelor economice directe si indirecte; calculul indicatorilor de eficientă economică.

3.3.3. Modelarea sistemului curentIndiferent de tipul sistemului analizat, manual sau informatizat, acesta va fi înlocuit

de un nou sistem. Oricât de ineficient, vechiul sistem trebuie să transfere celui nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic actual efectuează în parte sau în întregime ceea ce-şi propune să facă noul sistem fizic, dar la alt nivel de performanţă. Necesitatea trecerii de la vechiul la noul sistem ne obligă să decidem asupra celor două elemente specificate anterior, date şi proceduri, ceea ce conduce la obligativitatea constituirii unui model logic al sistemului propus, care să conţină una sau mai multe DFD, un model de date şi logica procesului de prelucrare. O modalitate de abordare constă în prezentarea detaliată a sistemului fizic curent, după care să se realizeze construirea modelului logic curent, prin abstractizarea celui fizic existent. Se va continua cu scoaterea în relief a ceea ce trebuie neapărat schimbat din sistemul curent şi ceea ce trebuie să se realizeze în cel nou. Pornind de la modelul fizic, se derivă modelul logic în cadrul căruia se realizează:

pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul cum funcţionează sistemul în implementarea actuală;

pune în evidenţă funcţiunile de bază ale sistemului; permite identificarea şi eliminarea problemelor legate de redundanţa datelor şi

duplicarea proceselor de prelucrare; permite stabilirea cu o mai mare precizie a graniţelor sistemului prin eliminarea

proceselor manuale care nu pot fi automatizate complet. Derivarea modelului logic al sistemului existent

Construirea modelului logic presupune transformarea diagramei de flux a datelor fizice în diagrama de flux a datelor logice.

Procesul de derivare a diagramei logice va începe de la ultimul nivel de descompunere alcătuit de la procesele “frunză” şi va continua prin agregarea proceselor către nivelurile superioare. Se parcurg următorii paşi [46]:1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea într-un stoc logic de date a entităţilor înrudite sau utilizate frecvent.

După identificarea stocurilor logice de date se construiesc: diagrama de corespondenţă între stocuri logice şi entităţile din modelul logic; diagrama de corespondenţă între stocuri fizice şi stocuri logice de date.

39

2. Înlăturarea dependenţelor fizice şi temporale din denumirea proceselor şi a fluxurilor de date: din DFD la nivel fizic (se observă că nu există referinţe fizice şi temporale în aplicaţia decontări). 3. Derivarea proceselor logice:

scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi automatizate (deciziile);

înlocuirea proceselor care nu realizează nici o transformare asupra fluxurilor de date cu fluxurile propriu-zise;

combinarea proceselor care realizează prelucrări asemănătoare sau multiple care se execută împreună sau în secvenţă;

înlăturarea proceselor care ţin de implementarea actuală şi a proceselor redundante.

În cazul aplicaţiei prezente: se combină procesele “Înregistrare încasări în numerar” şi “Înregistrare încasări

prin virament” deoarece realizează prelucrări asemănătoare; se înlătură procesele redundante “Înregistrare încasări în jurnal” si “Înregistrare

plăti în jurnal”. 4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu fluxul de informaţii utilizate efectiv de proces. 5. Gruparea proceselor elementare şi transformarea diagramei fizice în diagramă

logică, aplicând cei 5 paşi.

Relaţia existentă între DFD şi modelul datelorDupă cum reiese din prezentările anterioare, fiecare săgeată din DFD reprezintă un

flux al datelor, în sensul unui traseu pe care structurile datelor elementare sau grupate se vor deplasa în sistem. De exemplu, Facturi desfacere este o dată grupată. Când numele ei se plasează pe un flux de prelucrare trebuie să vedem şi obligativitatea ca acel flux să fie descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile documentului. Similar va fi abordat şi simbolul pentru stocare. La prima vedere, el reprezintă locul unde se realizează operaţiunea, dar foarte important este să prezentăm structura datelor păstrate. Firesc, şi în cazul fluxului de date, şi în cel al stocării lor nu trebuie uitată descrierea semnificaţiei economice. Structura datelor trebuie să fie redusă la a treia formă normalizată, iar conţinutul locurilor de stocare a datelor să fie prezentat prin reduceri la unul sau mai multe tabele relaţionale în forma a treia normalizată [46].

În cazul aplicaţiei DECONTĂRI, se obţine nivelul elementar al DFD a sistemului logic pentru Decontări cu beneficiarii reprezentată în figura 3.4. Nivelele superioare ale DFD a sistemului logic sunt identice.

Tabel 3.1 aplicaţia DecontăriSursa Destinaţia Nume flux Continutul fluxului1.1. Înregistrare facturi

D2 FACTURI DESFACERE

desfaceri CODCLIENT, DENCLIENT, ADRESAC, CONTC,

40

desfacere BANCA_C, DATAFACTD, NRFACTD, TOTALFACTD

D2 FACTURI

DESFACERE

1.3. Analiza situaţie client

desfaceri CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, NRFACTD, TOTALFACTD

Figura 3.4. Diagrama fluxului de date

3.3.4. Modelarea logicii proceselorDupă ce au fost descrise procesele de conversie a datelor în informaţii, prin

intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează şi logica internă a proceselor, oricât ar fi de detaliate, chiar şi la nivelul proceselor primare, se impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de programare.

41

În faza de analiză, modelarea logicii proceselor se va derula cât mai detaliat şi complet posibil, dar operaţiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza într-o etapă ulterioară şi anume proiectarea. Modelarea logicii proceselor ca şi diagramele fluxurilor de date fac parte din etapa de analiză a sistemului.

În analiza structurată, rezultatele obţinute în urma modelării proceselor sunt descrieri şi diagrame structurate care vor prezenta logica fiecărui proces, precum şi diagrame care vor evidenţia dimensiunea temporală a sistemelor, când apar procesele sau evenimentele şi modul în care aceste evenimente schimbă starea sistemului.

Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în următoarele elemente ale documentaţiei [46]:

reprezentarea în engleza structurată; reprezentarea logicii proceselor prin tabele de decizie; reprezentarea logicii proceselor prin arbori de decizie; tabelul sau diagrama stărilor de tranziţie.

Reprezentarea logicii proceselor prin engleza structuratăEngleza structurată este o formă mult simplificată şi modificată a limbii engleze,

folosită pentru descrierea conţinutului casetelor care marchează procesele (prelucrările) din diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită în conceperea procedurilor componente ale sistemelor informatice [46]. Se folosesc verbe pentru cuvintele cheie şi substantive pentru descrierea structurii datelor.

Nu există o formă standard de engleză structurată, fiecare analist ar putea apela la o formă proprie, dar scopul este de a înlesni accesul mai multor persoane la rezultatele analizei înglobate în documentaţie. Utilizarea englezei structurate pentru procesul “Analiza situaţie client” din decontări cu beneficiarii este reprezentată mai jos.

Analiza situaţie client WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI READ (FACTURI_DESF) cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; while (not eof (FACTURI_DESF)) { if (cod!=FACTURI_DESF.codclient) { CLIENTI.codclient = cod; CLIENTI.denclient = den; CLIENTI.adresac = adr; CLIENTI.contc = cont;

42

CLIENTI.banca_c = banca; CLIENTI.sold = sold; cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; } else { READ(ÎNCASĂRI); vb=0; vb1=0; while (not eof (ÎNCASĂRI) AND vb=0) { if (cod=ÎNCASĂRI.client AND FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd AND FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd) { if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata) { sold = sold+ FACTURI_DESF.totalfactd - ÎNCASĂRI.sumaincasata} vb1=1; } else if (vb1=1) vb=1 READ (ÎNCASĂRI) } MOVE FIRST LINE ÎNCASĂRI READ (FACTURI_DESF) } CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)

3.4. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)În cadrul modelării conceptuale a datelor se va renunţa la abordarea proceselor şi

se va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul modelării proceselor şi modelării logicii proceselor elementele esenţiale vor fi diagramele.

James Martin şi Carma McClure, atunci când reliefează importanţa tehnicilor structurate prin obiectivele ce şi le propun, consideră că o parte a acestora au legătură şi cu datele, şi anume [46]:

Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se referă la structurarea corectă a datelor, la uniformitatea modalităţilor de definire şi proiectare a datelor la nivel de întreprindere şi nu a sistemului. Corect efectuate, acestea accelerează procesele de analiză şi proiectare şi permit să se utilizeze în comun componentele esenţiale ale sistemelor: resursele.

43

Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică problemele de structurare a lor şi conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizării sistemelor. Dacă baza de date a unităţii este deosebit de importantă, atunci pe analiza datelor trebuie să se pună un accent aparte, ea fiind întotdeauna realizată înaintea proiectării programelor. Firesc, dacă ştim care sunt cerinţele unui sistem (ieşirile), imediat ne vom pune întrebarea din ce se obţin acestea (intrările) şi apoi vom urmări cum se pot obţine ieşirile (procesele).

Obiectivul principal al ingineriei informaţiei este crearea unui set de metodologii care să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască modele ale datelor la nivel de întreprindere, iar sistemele proiectate izolat să se integreze în aceste modele.

Datele trebuie să fie unice. Asupra lor, la nivel de întreprindere, pot fi văzute două categorii mari de operaţiuni:

asigurarea datelor (creare, actualizare); utilizarea datelor (obţinere de documente, de diverse rapoarte, analize „What-

If”, sprijin decizional, diferite căutări de informaţii, control şi auditare întreprindere).

Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi legăturile existente între date.

Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea orietată-obiect.

Modelarea datelor prin DER prezintă caracteristicile şi structura datelor independent de modul în care acestea sunt memorate în calculator. Modelul se creează iterativ. De cele mai multe ori, operaţiunea are loc la nivel de întreprindere, prin apelarea la o categorie foarte largă de date neglijându-se detaliile exagerate. Doar în etapele următoare, în speţă când se trece la definirea proiectului, are loc construirea unui model anume entitate-relaţie prin care să fie scoasă în evidenţă aria de întindere a proiectului. În timpul structurării cerinţelor, un model entiatate-relaţie reprezintă cerinţele conceptuale de date pentru sistemul luat în discuţie. După ce sunt descrise complet intrările şi ieşirile sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relaţie, este rafinat înainte de a fi trecut într-un format logic (de regulă, un model relaţional al datelor) din care se definesc bazele de date şi are loc proiectarea fizică a acestora.

Se consideră că, în timpul modelării conceptuale a datelor, se produc şi se analizează cel puţin patru diagrame entitate-relaţie [46]:1. DER care să acopere datele necesare aplicaţiei proiectului. Ea va permite stabilirea

necesarului de date ale aplicaţiei proiectului, fără să se ţină seama de constrângerile sau confuziile generate de detaliile care nu sunt încă necesare.

44

2. DER pentru aplicaţia ce va fi înlocuită. Diferenţele dintre aceste diagrame arată ce schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicaţie. Nu se aplică în cazul sistemelor complet noi.

3. DER care să scoată în relief întreaga bază de date din care noua aplicaţie îşi va extrage datele. Cât timp mai multe aplicaţii pot folosi aceeaşi bază de date, această diagramă şi prima evidenţiază modul în care noua aplicaţie apelează la conţinutul unor baze de date mult mai extinse.

4. DER pentru întreaga bază de date din care aplicaţia curentă îşi extrage datele necesare. Ea este discutată doar pentru sistemele care există şi pentru care se urmăreşte îmbunătăţirea.

Metodele de determinare a cerinţelor trebuie să fie orientate, prin întrebările puse, prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor. La început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul în care va afla cât mai multe informaţii despre datele necesare viitorului sistem pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel formulate încât să se realizeze o bună înţelegere a regulilor după care vor fi folosite datele în noul sistem, ce politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii de genul: când şi cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor.

Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere [46].Un prim punct de vedere, formulat în literatură sub numele de metoda top-down,

va scoate în evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte clară a naturii afacerii, şi nu se va opri asupra detaliilor privind modul în care ecranele, rapoartele sau documentele sunt folosite în organizaţie.

În afara metodei top-down, informaţiile necesare construirii modelului datelor se pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub numele de metoda bottom-up.

Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi evidenţiate datele prelucrate în sistem şi de aici va rezulta necesarul de date menţinute în baza de date a sistemului.

3.4.1. Modelul Entitate/Relaţie (E/R)Cercetările efectuate pentru definirea unui model de date care să permită

reprezentarea cât mai fidelă a realităţii au condus la definirea conceptului de model semantic încă din 1976 când Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astăzi o tehnică larg acceptată pentru proiectarea bazelor de date.

Modelul E/R permite proiectantului bazei de date să elaboreze un model conceptual de nivel înalt, fără a ţine seama de anumite constrângeri impuse de utilizarea unui anumit SGBD, de o anumită platformă hardware, sau de anumite considerente de eficienţă privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidelă a realităţii avute în vedere, constituind astfel o etapă intermediară în proiectarea unei baze de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în activitatea de programare.

45

Modelul Entitate/Relaţie (E/R) permite reprezentarea schematică a realităţii avute în vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază: tip de entitate, tip de relaţie (legătură, corelaţie), atribut.

Tipuri de entităţi, entităţiTipul de entitate reprezintă o clasă de obiecte sau un concept cu o existenţă de sine

stătătoare, este identificat printr-un nume şi este definit de un set de proprietăţi numite atribute. O entitate este un obiect particular al clasei de obiecte, reprezintă o instanţă a tipului de entitate şi este definit de valori corespunzătoare ale atributelor ce definesc tipul de entitate. Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în cazul nostru). Obiectele se caracterizează printr-o existenţă de-a lungul timpului, iar evenimentele îşi fac simţită prezenţa la un moment dat. La rândul lor, obiectelor li se pot asocia cel puţin două evenimente: apariţia şi dispariţia lor. Exemple: încheierea şi încetarea contractului de muncă; predarea produselor la secţia expediţie şi desfacerea lor la beneficiari ş.a. Evenimentelor le corespund asocieri între două sau mai multe obiecte. Exemplu: CLIENT COMANDĂ PRODUS. Raportat la o anumită organizaţie, o entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care organizaţia doreşte să păstreze anumite date. Se cuvine precizată diferenţa dintre tipurile entităţilor (entity types) şi cazurile/instanţele entităţii (entity instances) [46]. Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi care au proprietăţi sau caracteristici comune. Referirea generală la elementele ce pot fi catalogate ca entităţi se va realiza printr-un substantiv denumit cu litere majuscule, plasate în interiorul dreptunghiului corespunzător entităţii.

O instanţiere a entităţii sau instanţă, denumită în continuare, caz al entităţii sau caz, este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate prin datele stocate în bazele de date. De exemplu, există o singură entitate CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe ale acestei entităţi stocate în baza de date.Atribute

Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă interes pentru organizaţie. La rândul lor, şi relaţiile pot avea propriile lor atribute.

Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele posibile:

CLIENT : CodClient, DenClient, AdresaClientCa şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu

majuscule (eventual + minuscule), plasate în interiorul elipselor, legate de entitatea căreia i se asociază. De multe ori însă, chiar şi în cazul folosirii produselor CASE, pentru a nu se încărca o diagramă entitate-relaţie, se evită prezentarea atributelor. Operaţiunea se face, în schimb, în repository, depozitul de informaţii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.

46

Cheie candidat şi cheie primarăFiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se

efectueze diferenţierea fiecărui caz de acelaşi tip.Un set de atribute ale căror valori identifică în mod unic instanţele unui tip de

entitate, constituie o cheie candidat pentru acel tip de entitate. Având în vedere faptul că pentru un tip de entitate pot exista mai multe chei candidat, una dintre chei se va desemna drept cheie primară.

O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca identificator de cazuri în cadrul unui tip de entitate [46].

În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce formează cheia primară, numele respective se subliniază (vezi CodClient din entitatea CLIENT ).

Un tip de relaţie reprezintă o asociere între două sau mai multe tipuri de entităţi şi defineşte legătura care există între tipurile respective de entităţi. Fiecare tip de relaţie este identificat printr-un nume care descrie funcţia sa şi poate conţine atribute. O relaţie sau o instanţă a unui tip de relaţie este o legătură între instanţe ale tipurilor de entităţi asociate în cadrul tipului de relaţie corespunzător. Dacă R este un tip de relaţie definit pe tipurile de entităţi E1, E2,…,En, atunci R este funcţional faţă de Ei (1 £ i £ n) dacă orice instanţă a tipului de entitate Ei este determinată univoc de instanţe ale tipurilor de entităţi E1,…,Ei-

1,Ei+1,…,En prin relaţia R. Un tip de relaţie R definit pe tipurile de entităţi E1, E2,…,En, poate fi funcţional sau nu faţă de fiecare din tipurile de entităţi Ei (1 £ i £ n).

Un atribut defineşte o proprietate a unui tip de entitate sau a unui tip de relaţie şi poate fi: atribut simplu sau elementar, atribut compus (format din mai multe componente, fiecare având o existenţă independentă), atribut derivat (valorile sale se obţin plecând de la valorile altor atribute).

Pentru reprezentarea unor probleme complexe de tip bază de date, apărute începând din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultând astfel modelul entitate relaţie extins EER. În acest sens la conceptele de bază au fost adăugate conceptele suplimentare de superclasă, subclasă şi moştenire.

O superclasă reprezintă un tip de entitate care conţine subclase distincte care trebuie să fie reprezentate în cadrul modelului, iar o subclasă este un membru al unei superclase. O subclasă, fiind un tip de entitate distinct, poate avea la rândul său subclase, astfel încât se pot construi ierarhii de clase. O subclasă moşteneşte toate atributele superclasei, putând avea în plus şi alte atribute. În diagrama EER, pentru subclase se vor reprezenta numai atributele specifice subclasei.

Pentru elaborarea unei diagrame EER, se utilizează [14], [20] o serie de simboluri reprezentate în figura 3.5.

47

48

Reprezentare tip entitate cu numele <nume tip entitate>

Reprezentare atribut cheie cu numele <nume atribut>

<nume tip entitate>

<nume atribut> Reprezentare atribut cu numele <nume atribut>

<nume atribut>

<nume tip relaţie> Reprezentare tip de relaţie cu numele <nume tip relaţie>

Relaţia R funcţională faţă de tipul de entitate E

Relaţia R nefuncţională faţă de tipul de entitate E

E R

E R

Superclasa

Subclasa

Apartenenţa subclasei la superclasă

<nume tip entitate>

<nume atribut>

Apartenenţa atributului <nume atribut> la tipul de entitate <nume tip entitate>

<nume atribut> Reprezentare atribut derivat cu numele <nume atribut>

Reprezentare atribut compus <nume atribut>format din componentele <atribut1>, <atribut2>

<nume atribut>

<atribut1> <atribut2>

Fig. 3.5. Simboluri utilizate în reprezentarea unei diagrame EER

Un exemplu de reprezentare a unui tip de entitate prin diagramă este ilustrat în figura 3.6.

Relaţiile entităţilorO relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de

entităţi care prezintă interes pentru organizaţie. Ele se reprezintă printr-un romb ca în exemplul din figura 3.7.

Cardinalitatea relaţiilorPresupunem că există două tipuri de entităţi, A şi B, între care există o linie de

legătură pentru a marca relaţia. Cardinalitatea unei relaţii este dată de un număr al cazurilor/instanţelor entităţii B care pot sau care ar putea să fie asociate cu fiecare caz al entităţii A. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”), cu menţiunea că ele pot avea prezenţă obligatorie sau opţională. Cardinalitatea se poate reprezenta în moduri diferite, în funcţie de notaţia folosită. De exemplu, ea poate fi notată cu semne (0, 1, M, N) sau prin simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de săgeată pentru M. Alteori, 1 se reprezintă prin linie simplă şi M prin vârf de săgeată). În multe materiale, inclusiv produse CASE, se foloseşte notaţia model-date, cunoscută mai mult sub numele laba-gâştei, conform căreia cardinalitatea se reprezintă prin următoarele simboluri [46]:

Entităţi compuse sau asociative (gerundive)

49

obligatoriu 1

opţional 0 sau 1

nobligatoriu multe (n, unde n ia valori de la 1 la M)

nopţional 1 sau multe (n, unde n ia valori de la 1 la M)

PRODUSEFURNIZORI

Figura 3.7. Reprezentare relaţie Oferte între entităţile FURNIZORI, PRODUSE

Oferte

CLIENT

DenClient

AdresaClientCodClient

Figura 3.6. Model de reprezentare a atributelor prin DER

Atributele pot fi asociate cu o relaţie multe-la-multe sau cu o entitate. Un exemplu, din lumea cursurilor-credit, transferabile în cadrul unei perioade. Un student poate urma mai multe cursuri dintr-o listă, dar finalizarea cu notă se poate efectua în momente (la date) diferite. Prezentăm, mai jos, câteva dintre datele concrete [46]:

MATRICOLA STUDENT

NUME CURS DATA PROMOVĂRII

1111 Informatică Iulie 19991177 Informatică Septembrie 19991155 Informatică Septembrie 19991111 Drept comercial Ianuarie 2000

Din analiza cazurilor rezultă că atributul DATA_PROMOVĂRII nu este o proprietate a entităţii STUDENT, cât timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entităţii CURS, cât timp acelaşi curs poate fi susţinut la date diferite. În schimb, DATA_PROMOVĂRII este o proprietate a relaţiei dintre STUDENT şi CURS. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în fig. 3.8.

De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau asociativă care, de fapt, este o relaţie folosită de analist în model ca un tip de entitate. În astfel de cazuri, se foloseşte un simbol special: dreptunghi cu romb în interior, în care se scrie numele entităţii (fig. 3.9) [46].

50

STUDENT CURS

Data promovării

Promovare

Figura 3.8. Asocierea unui atribut la o relaţie [46]

STUDENT Promovare CURS

Data promovării

Figura 3.9. Redarea unei entităţi gerundive (asociative) [46]

Scopul diagramelor entitate-relaţie este de a surprinde cele mai complete sensuri posibile ale datelor necesare sistemului informaţional din organizaţie.

Tipuri de relaţiiDin cele prezentate mai sus, rezultă că între entităţile descrise, luate două câte

două, se pot identifica trei tipuri de relaţii (legături): unu-la-unu, unu-la-multe, multe-la-multe. În diagrame, descrierea relaţiilor se face de-a lungul liniilor care leagă cele două entităţi. Simbolul vârf-de-săgeată este cunoscut ca indicator al cardinalităţii (cardinality indicator). În cele ce urmează sunt prezentate exemple de tipuri de relaţii [46].

1. Relaţia unu-la-unu (1:1)

Figura 3.10. Descrierea relaţiei 1:1

„Fiecare BIROU este condus de un, şi numai un, MANAGER”„Fiecare MANAGER conduce un, şi numai un, BIROU”.

2. Relaţia unu-la-multe (1:M)

Figura 3.11. Descrierea relaţiei 1:M

„Fiecare VÂNZARE implică unul sau mai multe ATRICOL(e)_VÂNDUT(e) “„Fiecare ATRICOL_VÂNDUT face parte din numai o VÂNZARE”

3. Relaţia multe-la-multe

Figura 3.12. Descrierea relaţiei M:N

“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”“Fiecare PRODUS este livrat de unul sau mai mulţi FURNIZOR(i)”

În anumite cazuri, între două entităţi pot exista mai multe relaţii.De exemplu, s-ar putea spune că “FURNIZOR oferă PRODUS”, dar şi “PRODUS

este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. 3.13.

51

BIROU MANAGEReste condus deconduce

implicăVÂNZARE ARTICOL VÂNDUT

face parte din

livreazăFURNIZOR PRODUS

este livrat de

PRODUS FURNIZOR

oferă

este cumpărat de la

Figura 3.13. Descrierea relaţiilor multiple între două entităţi

4. Relaţii opţionale şi obligatoriiEste posibil ca relaţiile dintre entităţi să nu fie prezente în toate situaţiile. Spre

exemplu în cazul proiectelor la care lucrează diverse persoane, o persoană poate să lucreze la un singur proiect sau la câteva, sau la niciunul şi, invers, un proiect poate fi realizat de o persoană, de mai multe sau de nici una. În astfel de situaţii, se apelează la următoarea formă de reprezentare (fig. 3.14).

Cercul suprapus pe latura entităţii indică poziţia 0 (valoarea minimă poate fi şi zero), conferind relaţiei caracterul opţional.

Un alt aspect se referă la caracterul obligatoriu al relaţiilor. Să luăm exemplul vânzărilor. În relaţia 1:M, dintre VÂNZARE şi ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o vânzare fără cel puţin un articol vândut şi, invers, un articol nu poate fi vândut fără o vânzare. Simbolul folosit pt a marca relaţiile obligatorii este un cerc haşurat (Figura 3.15).

5. Relaţia unei entităţi cu ea însăşiÎn practică, apar şi situaţii în care o entitate se află în relaţie cu ea însăşi.Spre exemplul în cadrul entităţii ANGAJAT, unii dintre ei sunt coordonatori ai

activităţii celorlalţi, situaţii situaţii care pot fi reprezentate printr-o diagramă de forma celei din fig.3.16.

Reprezentarea anterioară se citeşte astfel:“Un angajat poate fi coordonatorul unuia sau mai multor angajaţi”“Oricare angajat întotdeauna raportează altui angajat”

52

PERSOANA PROIECTeste realizat de

lucrează la

Figura 3.14. Exemplu de relaţie opţională

VÂNZARE ARTICOL VÂNDUT

Figura 3.15. Exemplu de relaţie obligatorie

coordonator alANGAJAT

raportează la

Figura 3.16. Redarea relaţiei unei entităţi cu ea însăşi

6. Relaţii alternative (sau/sau)Uneori se ivesc situaţii când relaţiile posibile se redau alternativ: fie o variantă este

de urmat, fie cealaltă. De exemplu, o marfă destinată vânzării poate fi realizată de unitatea care o vinde sau poate fi procurată din afară. În ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pusă în legătură cu cele două surse posibile, PRODUCŢIA_ALTORA şi PRODUCŢIA_PROPRIE, printr-un punct comun, aşa cum este prezentat în figura 3.17.

Semnificaţia diagramei este următoarea: “O marfă se poate asocia sau cu un producător din afară, sau cu producţia unităţii”“Un producător din afară poate livra mai multe mărfuri”“O linie proprie de producţie poate livra mai multe mărfuri”.

Deşi diagramele entitate-relaţie sunt bine cunoscute şi utilizate în domeniul bazelor de date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării structurate.

Scopul acestor diagrame este de a evidenţia entităţile de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile ce există între ele.

De remarcat diferenţa dintre diagrama fluxului de date şi diagrama entitate-relaţie. În timp ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât şi entităţile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează doar entităţile de date. Din această cauză, DER poate fi considerată şi ca diagrama modelului datelor sau diagrama conceptuală a datelor.

În sistemul analizat pentru descrierea DER se apelează la simbolul dreptunghi, pentru fiecare entitate. Se recomandă ca numele entităţii să fie redat printr-un substantiv cât mai sugestiv (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, ÎNCASĂRI). După ce se identifică entităţile se continuă cu împerecherea lor, fiecare cu fiecare, pentru a descrie relaţiile dintre ele. Pentru aplicaţia Decontări se obţine astfel diagrama din figura 3.18

53

MARFA

PRODUCŢIA PROPRIE

PRODUCŢIA ALTORA

Figura 3.17. Exemplu de diagramă pentru relaţiile alternative

Figura 3.18. DER pentru aplicaţia Decontări [46]

Aplicaţie practicăFolosind modelul entitate - relaţie să se reprezinte diagrama E/R de ansamblu

pentru un sistem informatic simplificat al unei firme care desfăşoară activitate de comerţ fiind avute în vedere subsistemele:

aprovizionare (evidenţa furnizorilor);desfacere (situaţia vânzărilor);urmărirea stocurilor.

54

FURNIZORI Oferte PRODUSEm n

Cod furnizor Cod produs

Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaţiei de tip m-n Oferte

PRODUSE Vânzări VANZARI

CLIENTIm n

Cod produs Cod client

Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaţiei de tip m-n Vânzări

55

Desfacere

PRODUSE STOCURI

Intrări

Ieşiri

1 n

1 n

AprovizionareCod produs Cod Produs+Depozit+Preţ

Fig. 3.21. Subsistemul Urmărirea stocurilor.Reprezentarea relaţiilor de tip 1-n Intrări, Ieşiri, pentru actualizarea stocurilor

PRODUSE

Cod produs Denumire produs Descriere produs

Fig. 3.22. Reprezentarea entităţii PRODUSE

Oferte

Cod produs Unitate de măsură produs

Preţ unitar produs

Fig. 3.23. Reprezentarea relaţiei Oferte

Cod furnizor

Teste rezolvate

1. Studiul sistemului existent constă în: a) studiul activităţilor de bază desfăşurate de sistem;b) identificarea metodelor si mijloacelor tehnice;c) definirea caracteristicilor generale ale sistemului;d) definirea direcţiilor de perfecţionare ale actualului sistem;e) studiul sistemului de conducere.

Răspuns: a, b, c, e

2. Activitatea de determinare a cerinţelor sistemului se concretizează în diferite forme ale informaţiilor colectate, cum sunt:a) copii ale interviurilor;b) realizarea programului;c) implementarea sistemului;

56

FURNIZORI

Cod furnizor Denumire furnizor Adresa furnizor

Fig. 3.23. Reprezentarea entităţii FURNIZORI

Localitate Stradă Număr

Oferta

d) interpretări ale răspunsurilor la chestionare.Răspuns: a, d

3. Definirea caracteristicilor generale ale sistemului economic implică: a) cunoaşterea profilului, obiectivelor agentului economic; b) cunoaşterea locului în sfera serviciilor şi sfera producţiei; c) cunoaşterea relaţiilor de cooperare cu alţi agenţi economici; d) cunoaşterea specificului activităţii de bază ( producţie, servicii).

Răspuns: a, b, c, d4. Studiul sistemului de conducere se referă la identificarea:

a) caracteristicilor rezultate din statutul de funcţionare a societăţii, tipuri de decizii, modul de luare a deciziilor;

b) principalilor algoritmi, reguli de calcul şi de control;c) mijloacelor tehnice existente în dotarea unităţii economice;d) modului de organizare a producţiei.

Răspuns: a5. Metodele tradiţionale de determinare a cerinţelor sistemelor sunt:

a) interviul;b) prototipizarea;c) Joint Application Design (JAD);d) chestionarul.

Răspuns: a, d

6. Paşii prototipizării sunt:a) Identificarea cerinţelor principale ale sistemului;b) Realizarea prototipului iniţial;c) Proces iterativ de adaptare a sistemului la cerinţele utilizatorului;d) Folosirea sistemului aprobat de utilizatori.

Răspuns: a, b, c, d

7. Scopul diagramelor de date DFD este de a scoate în relief, într-o manieră cât mai sugestivă, următoarele aspecte:a) sursa datelor de prelucrare;b) macheta datelor de prelucrare;c) destinaţia datelor prelucrate;d) legătura existentă între prelucrări şi activitatea de stocare a datelor.

Răspuns: a, c, d

8. Identificaţi afirmaţia falsă: a) Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat;b) Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,

reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional curent;

57

c) Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor şi cerinţele funcţionale ale noului sistem;

d) Diagrama fluxului de date prezintă modelarea conceptuală a datelor.Răspuns: d

9. Simbolul folosit în diagramele DFD realizate cu SSADM (Structured Systems Analysis and Design Methodology), pentru reprezentarea fluxului de date sunt:a) săgeată; a) elipsă; b) cerc.

Răspuns: a

10. Câte entităţi externe conţine diagrama de context pentru aplicaţia Decontări:

a) patru entităţi; b) cinci entităţi; c) nici o entitate.Răspuns: b

11 Raportul detaliat al cerinţelor sistemului conţine următoarele elemente:a) refacerea analizelor pentru întregul sistem;b) descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv

numele fiecărei intrări, sursa, cine îl completează, ce date va conţine şi cum vor fi culese datele;

c) o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte, documente).

Răspuns: b, c

12. Principalele elemente ale documentaţiei elaborate pentru modelarea logicii proceselor sunt:

a) reprezentarea în engleza structurată;b) reprezentarea logicii proceselor prin tabele de decizie;

58

c) reprezentarea prin diagrame entitate-relaţie;d) reprezentarea logicii proceselor prin arbori de decizie;e) tabelul sau diagrama stărilor de tranziţie.

Răspuns: a, b, d, e

13. Cea mai cunoscută formă utilizată pentru modelarea conceptuală a datelor este:a) diagrama entitate-relaţie (DER);b) diagrama fluxului de date (DFD);c) diagrama stărilor de tranziţie.

Răspuns: a14. În DER pentru fiecare entitate reprezentată se apelează la simbolul:

a) cerc;b) săgeată;c) romb;d) dreptunghi.

Răspuns: d15. Nu sunt tipuri de relaţii:

a) relaţia unu-la-unu; b) relaţia unu-la-multe;c) relaţia absolută; d) relaţia unei entităţi cu ea însăşi.

Răspuns: c16. Care din afirmaţiile următoare sunt adevărate:

a) O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca identificator de cazuri în cadrul unui tip de entitate.

b) Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în cazul nostru).

c) Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă interes pentru organizaţie.

Răspuns: a, b, c

Întrebări

1. Enumeraţi metode moderne de analiză şi determinarea cerinţelor sistemului.2. Descrieţi tipurile de legături care pot exista între două mulţimi de entităţi.3. Definiţi cheia unei relaţii.

59

Capitolul 4. Proiectarea logică a sistemelor informatice

Dacă în primele etape, au fost identificate şi structurate cerinţele sistemului, în faza de proiectare logică se efectuează deplasarea atenţiei de la prezentarea a ceea ce există şi ce se intenţionează la descrierea a ceea ce va însemna noul sistem şi cum va funcţiona. Prezentarea noului sistem constă în prezentarea tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurilor.

4.1. Proiectarea formularelor/formatelor şi a rapoartelorÎn cadrul etapei de analiză a sistemului informatic, intrările şi ieşirile au fost

identificate şi prezentate, exprimând cerinţele informaţionale la nivelul fiecărui subsistem/ aplicaţie informatică. În acel moment nu s-au prezentat toate detaliile privind formularele/formatele, rapoartele şi procesul de modelare a datelor, insistându-se mai mult pe identificarea şi descrierea lor.

Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare într-un proces al DFD, iar rapoartele se pot regăsi într-un flux al datelor generate de un proces al DFD.

Un formular/format poate fi un document primar sau o machetă de ecran care conţine unele date predefinite, cărora li se adaugă altele ce urmează a fi completate în rubrici speciale.

Un raport este un document economic în care sunt incluse doar date predefinite, ceea ce înseamnă că poate fi numit şi document pasiv, folosit pentru a citi şi vizualiza informaţia.

În faza de proiectatre logică se reprezintă doar o ciornă a formularelor/formatelor, rapoartelor sau ecranelor, ele fiind privite doar ca structură şi machetă, pot fi realizate cu ajutorul unui editor de texte sau un produs program orientat spre grafică sub forma unui prototip.

4.1.1. Proiectarea situaţiilor cu rezultate finale (rapoartelor)Obiectivul prezentării detaliate a ieşirilor este şi acela de a determina formatul şi

conţinutul tuturor rapoartelor imprimate şi ale documentelor şi ecranelor furnizate de sistem.

Proiectarea ieşirilor se va face astfel încât să servească pentru [11]: transmiterea rezultatelor prelucrării pe calculator utilizatorului, într-o formă pe

care acesta să o înţeleagă şi în care să-şi regăsească cerinţele sale; transmiterea proiectului situaţiilor finale programatorului, fără ambiguităţi,

pentru a-i permite acestuia trecerea la întocmirea programelor necesare editării sau vizualizării.

În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al raportului sau ecranului şi să întrebe utilizatorul dacă informaţiile din raport şi formatul acestuia sunt accesibile. Dacă ieşirile nu corespund cerinţelor utilizatorului, analistul

60

trebuie să le modifice. Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator îl constituie macheta imprimantei.

Macheta imprimantei este reprezentarea de detaliu a situaţiei de ieşire, cuprinzând: antet; titlu; date de identificare; cap de tabel; date elementare ce se imprima rând de rând; totalurile. detalii şi indicaţii tehnice de realizare care se referă la:

volumul datelor de ieşire; frecvenţă; număr de copii şi destinaţia fiecăreia; grad de precizie al calculelor; condiţii speciale de editare; criterii de control, validare şi interpretare a datelor de ieşire.

Specificaţiile de ieşire vor cuprinde, pentru utilizator, macheta situaţiei iar pentru programator macheta situaţiei şi o serie de indicaţii tehnice de realizare.

Pe baza specificaţiilor de ieşire se trece la proiectarea fizică prin care se alege suportul informaţiilor de ieşire, se realizează definitivarea formei şi formatului de editare a situaţiilor (aşezarea în pagina / ecran, spaţierea între coloane şi rânduri, etc.) şi se definitivează procedurile de utilizare şi interpretare a ieşirilor.

Alegerea tipului de suport fizic de ieşire (imprimanta, display, disc fix, floppy disc, banda magnetică etc.) se face în funcţie de: timpul de răspuns solicitat, amplasarea utilizatorului faţă de calculator, hard-ul şi soft-ul existent, costul suportului, măsura în care răspunde necesitaţilor de redare a conţinutului informaţional al situaţiei finale.

Când se pregătesc ieşirile, este bine să se ia în calcul ce se urmăreşte prin ele, astfel încât apelarea la categoriile de date de mai sus să se efectueze în cunoştinţă de cauză.

În definitivarea formei şi formatului de prezentare a situaţiilor finale trebuie să ţinem seama de o serie de considerente practice cum ar fi [11]:

Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei finale;

Restricţii tehnice; Elemente de eficienţă; Lizibilitate – spaţiere; Utilizarea formularelor pretipărite; Utilizarea monitoarelor sau terminalelor video; Utilizarea generatoarelor de rapoarte.

Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei finale O serie de cerinţe ale conducerii privind macheta situaţiei finale obligă proiectantul

la o anumită structurare şi machetare a situaţiilor finale. Informaţiile se pot împărţii în două grupe prin prisma sistemelor informatice interne şi externe. Informaţiile interne reprezintă acele informaţii culese, generate sau folosite în interiorul organizaţiei.

61

Informaţiile externe se referă la cele colectate sau create de la sau pentru parteneri străini (facturi, rapoarte anuale, etc).

În funcţie de informaţiile care pot fi văzute din punct de vedere al echipei manageriale distingem: informaţii curente, de atenţionare, indicatori de bază, etc.Restricţii tehnice

În proiectarea situaţiilor finale intervin o serie de restricţii datorate caracteristicilor şi performanţelor tehnice ale echipamentelor periferice şi anume: numărul maxim de caractere pe linie; numărul maxim de linii pe pagina / ecran; facilităţile de imprimare etc. Pe piaţă se afla o gamă variată de echipamente de redare a rezultatelor. Există mai multe tipuri de imprimante, console şi terminale video, ceea ce creează posibilitatea unei alegeri adecvate a perifericelor destinate obţinerii diverselor tipuri de situaţii finale.Elemente de eficienţă

În proiectarea situaţiilor finale nu trebuie sa scape atenţiei şi aspectele de eficientă economică privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situaţiilor; economie de hârtie de imprimantă. Abilitatea şi experienţa proprie a programatorilor joacă în acest sens un rol important.

În vederea optimizării obţinerii situaţiilor finale pe imprimantă se pot folosi de la caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeaşi pagină de imprimantă; editarea unei situaţii imprimând faţă/verso pe aceeaşi coală;

Pentru a nu irosi timp cu editarea unor situaţii finale voluminoase se recomandă mai întâi rularea unor programe scurte care să verifice cheile de control aplicate. Numai dacă aceste chei sunt corecte, eventual verificate şi de utilizator, se poate lansa editarea analitica a situaţiilor finale. Programele care editează situaţii finale voluminoase trebuie prevăzute cu posibilitatea de întrerupere (respectiv de reluare a editării în cazul unor incidente ivite în timpul rulării) sau editarea lor sub forma unui fişier ASCII sau text pe hard disc sau floppy disc, urmând imprimarea ulterioara a acestui fişier, total sau parţial.

Lizibilitate – spaţiere Parcurgerea unei situaţii finale trebuie să fie cât mai uşoara, “citirea” unei situaţii

nu trebuie să dea naştere la ambiguităţi. Este necesar ca situaţia sa fie autoexplicativă. Pentru aceasta, antetul va conţine informaţii şi coduri ce vor indica sursa de emitere a raportului, exprimând clar, sintetic, conţinutul raportului şi perioada la care se referă.

Capul de tabel, împreuna cu titlul şi antetul, se afişează pe următoarele pagini numai dacă au intervenit schimbări în cadrul caracteristicilor de grupare faţă de prima pagină, altfel se imprimă doar numerotarea coloanelor de tabel.

Informaţiile importante pot fi subliniate. Totalurile se separă de informaţiile analitice. Informaţiile care se repetă pe linii succesive se imprimă o singură dată. Utilizarea formularelor pretipărite

Aceasta implica utilizarea unei hârtii de imprimanta ce cuprinde elemente fixe ale situaţiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta conduce la o creştere a vitezei de editare şi o diminuare a uzurii imprimantelor, riboanelor etc. Totodată situaţiile obţinute sunt mai estetice şi sunt uşor de parcurs de utilizatori.

62

Utilizarea monitoarelor sau terminalelor video Prin intermediul unui soft adecvat, monitoarele sau terminalele video oferă

posibilitatea afişării situaţiilor finale, atât în regim alfanumeric, cât şi în regim grafic, alegerea modului de lucru făcându-se prin intermediul unor comenzi sau comutatori.

Ecranul unui terminal video în regim alfanumeric este alcătuit din linii şi coloane iar în regim grafic ecranul este privit ca o matrice de puncte denumite “pixeli”.

Reprezentarea informaţiilor de ieşire sub forma grafică reprezintă un pas înainte faţă de editarea sub forma de text a rapoartelor. Această formă de afişare se recomandă factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare a informaţiilor de ieşire şi volumul redus al rapoartelor.

Pe lângă problemele legate de aşezarea informaţiilor pe ecran, la proiectarea ecranelor de ieşire se iau în considerare şi facilităţile oferite de monitoare sau terminalele video şi anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afişare (normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonoră (normal, semnal sonor după afişarea unui câmp etc.). Utilizarea generatoarelor de rapoarte ( REPORT WRITER )

Multe limbaje de programare, pachete de programe şi sisteme de gestiune a bazelor de date dispun de module specializate în editarea de rapoarte, ceea ce conduce la reducerea considerabila a eforturilor programatorilor. De obicei, aceste generatoare solicită precizarea titlului, antetului de coloană, conţinutul unui rând de date (de detaliu), gradele de total şi maniera lor de afişare, la începutul sau la sfârşitul grupului de date, al paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane, pagini, spaţierea dintre linii, coloane, afişarea datelor privind momentul listării, statistici etc. Astfel de module specializate există în pachete de programe pentru gestionarea bazelor de date cum ar fi: ACCESS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.

4.1.2. Proiectarea codurilorÎn proiectarea sistemului de coduri trebuie să avem în vedere două aspecte

importante şi anume [11]: influenţa tipului şi structurii codului asupra performanţelor sistemului

informatic; implicaţiile utilizării codurilor în operaţiile de culegere a datelor şi interpretarea

rezultatelor finale de către utilizatorii neinformaticieni. Primul aspect ridică probleme de ordin tehnic în realizarea nomenclatorului de

coduri şi are în vedere facilitarea operaţiilor de prelucrare, ocuparea unui spaţiu de memorie internă şi externă cât mai mic etc.

Celui de-al doilea aspect trebuie să i se acorde o atenţie mai mare în vederea uşurării activităţilor de culegere, verificare a datelor şi interpretarea rezultatelor din situaţiile finale. Având în vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri să se respecte o serie de cerinţe.

Activităţile parcurse în realizarea unui sistem de coduri sunt: analiza elementelor ce urmează a fi codificate; precizarea şi uniformizarea tehnologiei, a denumirilor;

63

stabilirea caracteristicilor şi a relaţiilor dintre elementele de codificat; alegerea tipurilor de coduri; estimarea capacităţii, lungimii şi formatului

codurilor; atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de

coduri); întreţinerea nomenclatoarelor de coduri. Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la

nivelul economiei naţionale (CAEN, SIRUES, SIRUTA, CNP, etc).

4.1.3. Proiectarea intrărilor în sistemul informaticDatele de intrare parcurg o succesiune de etape până la utilizarea efectivă în

cadrul sistemului informatic. Aceste etape intermediare sunt: înregistrarea datelor pe documentul de intrare; conversia datelor într-o formă acceptata de sistemul de calcul / transpunere pe suportul tehnic; verificarea sintactică şi semantică a datelor de intrare; corecţia datelor eronate etc.

La proiectarea intrărilor este necesar să se realizeze, în principal următoarele activităţi:

alegerea suportului tehnic pentru culegerea datelor;proiectarea machetelor documentelor de intrare, stabilirea instrucţiunilor de culegere;stabilirea regulilor de control şi validare a datelor;proiectarea formularelor (videoformatului) de intrare.

Alegerea suportului tehnic al datelor de intrare se face în funcţie de cerinţele aplicaţiei informatice. Datele introduse de la terminalul video, fie intră imediat în circuitul de prelucrare-actualizare a unei baze de date, fie sunt stocate pe un suport magnetic sau sunt stocate în vederea prelucrării ulterioare.

La proiectarea machetei documentelor de intrare (indiferent de metodele de prelucrare a datelor folosite ulterior) sunt respectate câteva reguli care să înlesnească completarea şi apoi utilizarea documentului atât pentru prelucrarea automată a datelor cât mai ales pentru necesităţile curente ale salariaţilor societăţii economice. Nu este recomandabil să dublăm documentele primare, prin proiectarea unor documente destinate exclusiv preluării datelor pentru necesităţile prelucrării automate.

Macheta documentului primar trebuie să conţină: antetul–ce reprezintă denumirea unităţii şi/sau a serviciului care-l emite; denumirea documentului; coduri de identificare, data documentului; rubrici /casete/ rânduri pentru denumirea informaţiilor cantitativ-valorice şi

coduri; rubrici /casete /spaţii pentru semnături şi ştampile; text explicativ, eventual indicaţii de completare şi verificare. În ordonarea informaţiilor pe document, deci în rubricarea documentului se va ţine

seama de câteva reguli: antetul se plasează în stânga sus; codurile şi alte informaţii de

64

identificare se plasează în dreapta sus; sensul natural de parcurgere este de sus în jos şi de la stânga la dreapta; zonele de document ce se completează de compartimente/ persoane diferite se marchează / grupează distinct; mărimea şi spaţierea documentului, distanţa dintre rânduri, dimensiunea rubricilor, depind de locul şi modalitatea de completare (manual, dactilo, automat) precum şi de nivelul de calificare a personalului ce completează documentul.

Aşezarea rubricilor pe document trebuie să respecte ordinea firească de folosire a documentului şi nu ordinea de utilizare a datelor în programe. Ordinea de culegere a datelor este suficient a fi precizată prin numerotarea rubricilor sau simpla lor încadrare în chenar sau utilizarea de litere îngroşate în denumirea rubricilor implicate în dialogul operator-calculator.

Atunci când documentul există într-o formă pe hârtie, în varianta pe calculator se va urmări păstrarea în mare măsură a structurii existente, dar cu adaptări specifice noului mediu.

Regulile de control şi procedurile de validare a datelor de intrare trebuie să cuprindă [11]:

reguli de verificare a volumului, secvenţei documentelor şi a cifrelor de control (dacă este cazul) pe pachetele de documente primare;

reguli pentru controlul sintactic şi semantic a datelor din documentele primare. Aceste reguli se referă la: încadrarea indicatorilor numerici (în limitele de verosimilitate), corelaţii logice (între indicatorii înscrişi în acelaşi document, sau cu alţi indicatori din baza de date), prezenţa unor informaţii obligatorii (apartenenţa codurilor la nomenclatoarele de coduri specifice aplicaţiei informatice) etc. Aceste reguli sunt necesare pentru scrierea programelor de verificare logică a datelor de intrare.

Proiectarea formularelor(videoformatelor) de intrare pentru introducerea datelor de intrare se face în funcţie de modul concret de desfăşurare a dialogului operator-calculator. Acest dialog se poate desfăşura sub următoarele forme:

întrebare-răspuns cu defilarea liniilor ecranului; afişare pe ecran a machetei de introducere a datelor de intrare. În prima variantă, mai uşor de realizat practic, operatorul introduce succesiv, ca

răspuns la întrebările afişate pe ecran, date de intrare. La proiectarea formelor de intrare este necesar ca proiectantul să aibă în vedere o serie de aspecte cum ar fi:

afişarea la un moment dat a unui volum redus de informaţii; afişarea la un moment dat a unei cereri de răspuns ce se referă la o singură

informaţie; scurtarea răspunsului operatorului prin folosirea mnemonicelor şi codificărilor; utilizarea unor formate clare şi precise pentru afişare; evitarea cuvintelor şi caracterelor dificil de citit sau înţeles; existenta unor rutine speciale de tipul HELP; preluarea asistată a unor coduri (ex. utilizare tehnici de tip Lookup wizard în

ACCESS)

65

În varianta a doua cursorul marchează de fiecare dată câmpul curent care se introduce. Ecranul display-ului trebuie să reproducă integral sau simplificat macheta documentului, respectând aceeaşi ordine a rubricilor. Mesajele de eroare se pot afişa într-o zona prestabilita a ecranului, însoţită de avertizare sonora sau luminoasa.

Dacă este cazul, pentru unele câmpuri (rubrici) de date se pot prelua valori implicite, atunci când nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fişierele bazei de date sau tabele special memorate pentru valorile asumate prin lipsa sau prin aplicarea unui algoritm. Pentru o mai uşoară operare este necesar să folosim toate facilităţile de afişare şi de combinare a culorilor oferite de terminalul video (figura 4.1).

În proiectarea formularelor de intrare pot fi utilizate componente specializate în acest sens din sistemele de gestiune a bazelor de date cum ar fi ACCESS, dBASE, ORACLE, PARADOX precum şi programe scrise în diverse limbaje de programare.

4.2. Proiectarea interfeţelor şi a dialogurilorInterfaţa cu utilizatorul reprezintă o parte a aplicaţiei software care permite

utilizatorilor să-si exprime intenţiile de operare asupra calculatorului şi să interpreteze rezultatele acţiunilor efectuate de maşină. Prin proiectarea dialogurilor şi a interfeţelor se definesc modalităţile prin care oamenii şi calculatoarele schimbă informaţii [46].

Metode şi echipamente folosite în dialogul om-maşinăInterfaţa om – maşină defineşte modalitatea prin care utilizatorul interacţionează

cu un sistem informatic. Interfeţele sunt destul de variate, conform descrierilor, însă toate trebuie să dispună de un stil sau de o metodă prin care să se folosească anumite echipamente în măsură să faciliteze o astfel de interacţiune.

Metode de interacţiune

66

Figura 4.1. Formularul(macheta) de intrare pentru facturi

Metodele cele mai utilizate sunt:ˉ interacţiunea prin limbaj-comandă (în acest tip de interacţiune utilizatorul

transmite calculatorului comenzile sub forma unui şir de caractere);ˉ interacţiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului

prin intermediul unui sistem de meniuri şi opţiuni de meniu sau folosind scurtături sub formă de combinaţii de taste);

ˉ interacţiunea bazată pe obiecte icons(comunicarea se face prin intermediul desenelor. Imaginile folosite funcţionează ca butoanele, la apăsarea lor se activează o anumită funcţie sau comandă);

ˉ interacţiunea prin limbaj natural(comenzile se transmit folosind vocea şi sintetizatoarele de voce pentru redarea rezultatelor).

Echipamentelor necesare interacţiunii cu sistemulCele mai folosite echipamente sunt:ˉ keyboard – tastatura este formată dintr-un set de butoane (taste) Prin

intermediul ei se introduc date, comenzi;ˉ mouse;ˉ joystick;ˉ touch screen – atingerea ecranului constituie modalitatea prin care are loc

selecţia;light pen – stiloul optic, efectuează selecţia prin apăsarea pe ecran;voice – vocea constituie modalitatea de transmitere a textelor şi comenzilor către calculator.

Proiectarea dialogurilorProiectarea dialogurilor este procesul prin care sunt proiectate toate secvenţele

folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este de a selecta cele mai potrivite metode şi echipamente, precum şi de a prezenta condiţiile în care se pot afişa informaţiile sau se pot obţine de la utilizator.

Pentru a obţine rezultate bune trebuie să se ţină seama de regulile de bază la conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uşurinţa în lucru, controlul, operaţiunea inversă (refacerea unui element şters), rezolvarea erorilor, etc.

O modalitate de prezentare a secvenţei dialogurilor este cea care apelează la tehnica diagramelor prin care se reprezintă meniurile componente ale aplicaţiei.

67

Figura 4.2. Exemplu de diagramă de apelare a meniurilorPentru proiectarea interfeţelor şi dialogurilor se poate apela la ajutorul oferit de

produsele CASE sau la mediile de dezvoltare grafică ACCESS, Visual Basic, etc. Pentru a se putea proiecta în condiţii optime mediile GUI (Graphical User Interface) trebuie să se cunoască aceste medii. În mediile grafice informaţiile se plasează în ferestre. Acestea au trăsături specifice ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu sistem, etc.

4.3. Proiectarea logică a bazelor de dateProiectarea logică a bazelor de date este în strânsă legătură cu modelarea

conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date. Procesul de modelare logică a datelor se derulează în paralel cu celelalte activităţi ale proiectării logice: proiectarea formularelor şi a rapoartelor şi proiectarea dialogurilor şi interfeţelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-relaţie, ci şi pe baza machetelor formularelor şi a rapoartelor. Se efectuează analiza datelor elementare din intrările şi ieşirile sistemului pentru a se desprinde legăturile dintre ele.

Prin modelarea logică a datelor se urmăreşte: structurarea performantă a datelor prin procesul de normalizare; obţinerea unui model logic al datelor din care să se poată realiza proiectul bazei

de date fizice funcţie de tipul de SGBD utilizat: relaţional – cel mai utilizat în prezent, reţea, ierarhic, sau orientate-obiect;

realizarea unui model al datelor care să răspundă cerinţelor actuale de date regăsite în formulare şi rapoarte. Modelarea logică este un proces ascendent (bottom-up, de jos în sus) de obţinere a relaţiilor din formulare şi rapoarte prin transformarea modelului entitate-relaţie într-o formă relaţională.

Modelarea logică a datelor descrie datele cu ajutorul unei notaţii speciale, care corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de

68

date. Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viaţă se regăseşte câte o activitate specifică datelor după cum urmează [46]:

Analiza – Modelele conceptuale ale datelor, prezentarea DER; Proiectarea logică – Modelul logic al datelor (relaţional); Proiectarea fizică – Proiectarea fizică a bazelor de date şi a fişierelor

(organizarea fişierelor); Implementarea – Descrierea fişierelor şi a bazelor de date.După cum prezintă profesorul Oprea D. În “Analiza şi proiectarea sistemelor

informaţionale economice” în procesul de modelare logică există patru paşi esenţiali:1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare şi

rapoarte) privind aplicaţia, folosindu-se principiile normalizării;2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor într-un model logic

consolidat (centralizat) al datelor, numit şi integrarea perspectivelor;3. Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să se ţină

cont de perspectiva utilizatorului, într-un set de relaţii normalizate;4. Compararea modelului logic consolidat al datelor cu modelul transformat al entităţii-

relaţie şi realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicaţiei.

Rezultatele obţinute prin parcurgerea celor patru paşi pot fi ilustrate prin intermediul unor exemple oferite în literatura de specialitate de McFadden şi Hoffer.

Primul pas al modelării logice se poate explica prin două rapoarte solicitate de utilizatori, reprezentând perspectiva utilităţii sistemului din punctul lor de vedere:

cel mai bun client al produsului X(ecran);situaţia comenzilor în curs.

Ecranul “Cel mai bun client al produsului X”, prin percepţia utilizatorului, are următorul format:

Din analiza ecranului se pot desprinde relaţiile:CLIENT(COD_CLIENT, NUME)COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)PRODUS(COD_PRODUS)LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA)

69

Cel mai bun client al produsuluiIntroduceţi codul produsului: P1122Data de început: 10/10/99Data de sfârşit: 31/12/99- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - COD CLIENT: 1111NUME CLIENT: S.C. ALPHA S.R.L.VOLUM: 1000

Figura 4.3 Model de ecran solicitat de utilizatori [46]

Raportul “Situaţia comenzilor în curs” are următorul format:

Realizarea raportului este posibilă prin folosirea următoarelor entităţi:

PRODUS(COD_PRODUS)COMANDA(NR_COMANDA, DATA_COMANDA)LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)FACTURA(NR_FACTURA, DATA_FACTURA)

Pasul al doilea presupune comasarea perspectivelor utilizatorilor şi crearea unui set integrat al relaţiilor, rezultând următoarele relaţii:

CLIENT(COD_CLIENT, NUME)PRODUS(COD_PRODUS)FACTURA(NR_FACTURA, DATA_FACTURA)COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)

Pasul al treilea constă în transformarea modelului conceptual al datelor (diagrama-entitate-relaţie) din aplicaţie fără să se ţină cont de punctul de vedere al utilizatorului, într-un set de relaţii normalizate. Din analiza diagramei din figura 4.5 se desprind următoarele relaţii:CLIENT(COD_CLIENT, NUME, ADRESA)PRODUS(COD_PRODUS, DENUMIRE)FACTURA(NR_FACTURA, NR_COMANDA)COMANDA(NR_COMANDA, COD_CLIENT)

70

Pagina 1Situaţia comenzilor în curs31/03/1998

COD PRODUS CANTITĂŢI_DE_LIVRATA1111 0A2222 0B1111 150Y9999 100

Figura 4.4. Model de raport solicitat de utilizatori [46]

LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)

Pasul al patrulea compară modelul obţinut din pasul doi cu cel din pasul trei şi integrează perspectivele utilizatorilor în vederea obţinerii unui model logic final, după cum urmează:

CLIENT(COD_CLIENT, NUME, ADRESA)PRODUS(COD_PRODUS, DENUMIRE)FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA)COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)

Rezultatul modelării logice a datelor îl constituie relaţiile normalizate rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza în actualizarea depozitului (repository) sau a dicţionarului proiectului. Diferenţa majoră între modelarea conceptuală şi cea logică este că după modelarea logică a datelor cerinţele structurate de date se concretizează în relaţii, şi nu în entităţi. Din cauza normalizării nu este necesară o corespondenţă unu-la-unu între entităţi şi relaţii [46].

71

NUME_CLIENTCOD_CLIENT ADRESA NR_FACTURA

CLIENT FACTURA

FacturareLansează

COMANDA

Linie_comandă

PRODUS

CANTITATE_COMANDATA

COD_PRODUS DENUMIRE

NR_COMANDA

CANTITATE_LIV

Livrare

Figura 4.5. Diagrama entitate-relaţie pentru gestiunea clienţilor [46]

4.3.1. Normalizarea relaţiilor - Forme normaleÎntre atributele unei relaţii sau între atribute din relaţii diferite pot exista anumite

legături logice (dependenţe), care influenţează proprietăţile schemelor de relaţie în raport cu operaţiile curente care intervin în timpul exploatării bazei de date: adăugare, ştergere, actualizare. Aceste legături logice, cunoscute în literatura de specialitate sub denumirile de dependenţele funcţionale, dependenţele multivalorice şi dependenţe de cuplare, au implicaţii majore asupra criteriilor de proiectare a schemelor relaţionale. Alegerea unui model conceptual convenabil pentru o bază de date relaţională poate necesita realizarea unor descompuneri pentru anumite scheme de relaţie date, descompuneri care să izoleze

72

dependenţele existente şi prin aceasta să elimine anomaliile care se datorează acestor dependenţe.Dependenţe funcţionale

Penru definirea acestui tip de dependenţe se consideră schema de relaţiePrestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)

definită pentru urmărirea serviciilor prestate de o firmă pentru diverşi clienţi.Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare

client are o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină în mod unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relaţie de mai sus, se constată o redundanţă relativ la atributul Adresa a cărei valoare este repetată pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariţia următoarelor anomalii:

Anomalia la adăugare:adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puţin un serviciu.

Anomalia la ştergere:dacă se şterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.

Anomalia la actualizare:datorită redundanţei relativ la atributul Adresa, dacă se schimbă adresa unui client este necesară parcurgerea întregii relaţii pentru a identifica şi actualiza toate apariţiile acestui client, în caz contrar baza de date devine inconsistentă (acelaşi client poate apare la adrese diferite).

Aceste anomalii pot fi eliminate, dacă schema de relaţie Prestari_Servicii se înlocuieşte prin următoarele două scheme de relaţie:

Clienti(Cod, Nume_client, Adresa)Servicii(Cod, Serviciu_prestat, Valoare).

Relaţia Clienti conţine codul, numele şi adresa fiecărui client, fără nici un fel de redundanţă, iar relaţia Servicii conţine serviciile prestate pentru fiecare client şi valorile acestor servicii. Un dezavantaj al descompunerii relaţiei iniţiale în cele două relaţii este acela că pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesară efectuarea unei operaţii de cuplare a relaţiilor Clienti şi Servicii.

Se consideră o schemă de relaţie R şi A,B două atribute simple sau compuse ale schemei de relaţie R. Atributul A determină funcţional atributul B sau B depinde funcţional de A, dacă şi numai dacă oricărei valori a atributului A îi corespunde o singură valoare a atributului B (se notează A->B).

Dependenţa funcţională A->B este totală dacă nu există nici un subset C al atributului A (CcA) astfel încât C->B şi este parţială în caz contrar.

În relaţia Prestari_Servicii, una din dependenţele funcţionale care poate fi pusă în evidenţă este Nume_client->Adresa.

Deoarece într-o relaţie orice cheie identifică în mod unic fiecare tuplă a relaţiei, deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relaţie atributele sunt dependente funcţional faţă de cheile acesteia.

Se pot face, până în acest moment, următoarele precizări:

73

Eliminarea dependenţelor funcţionale din schemele de relaţie şi a consecinţelor negative (redundanţa datelor; anomaliile de adăugare, ştergere, actualizare) se realizează prin descompunerea schemei date într-o colecţie de scheme mai simple în care sunt evitate neajunsurile mai sus menţionate. Reconstituirea relaţiei iniţiale se poate face prin operaţia de cuplare (uniune). Pentru ca descompunerea schemei de relaţie să fie echivalentă cu relaţia iniţială, trebuie să fie îndeplinite condiţiile:

cuplare fără pierdere de informaţie; conservarea dependenţelor (dependenţele funcţionale din relaţia iniţială trebuie

să se regăsească în relaţiile rezultate prin descompunere).Formele normale sunt scheme de relaţie echivalente obţinute prin descompunerea

unor scheme de relaţie în vederea eliminării redundanţei datelor şi anomaliilor la adăugare, actualizare, ştergere înregistrări în baza de date. Descompunerile schemelor de relaţii în scheme de relaţii echivalente având în vedere dependenţele funcţionale conduc la definirea primelor 4 nivele de forme normale şi anume: prima formă normală (FN1), a doua formă normală (FN2), a treia formă normală (FN3) şi forma normală Boyce-Codd (FNBC).

A patra formă normală (FN4) este definită având în vedere dependenţele multivalorice, iar a cincea formă normală (FN5) este definită având în vedere dependenţele de cuplare. Începând de la prima formă normală şi până la forma normală FN5 se impun condiţii din ce în ce mai restrictive asupra relaţiilor. Astfel o relaţie aflată pe un anumit nivel de normalizare (FN5) satisface toate restricţiile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definiţiile formelor normale având în vedere dependenţele funcţionale.

O relaţie R este în prima formă normală (FN1) dacă şi numai dacă toate atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul Adresa ar putea fi considerat un atribut neatomic dacă în cadrul adresei ne-ar interesa localitatea, strada etc., caz în care trebuie descompus în atribute atomice.

O relaţie R este în a doua formă normală (FN2) dacă este în FN1 şi orice atribut neprim este total dependent faţă de orice cheie a relaţiei (atributele prime sunt atribute care fac parte dintr-o cheie a relaţiei şi cele neprime sunt atributele care nu aparţin nici unei chei a relaţiei).

O relaţie R este în a treia formă normală (FN3) dacă este în FN2 şi nici un atribut neprim nu este funcţional dependent faţă de un alt atribut neprim al relaţiei.

O relaţie R se află în forma normală Boyce-Codd (FNBC) dacă singurele dependenţe funcţionale admise sunt cele în care o cheie determină un alt atribut (nici un atribut prim sau neprim nu poate fi dependent funcţional faţă de un alt atribut dacă acesta nu este sau nu conţine o cheie).Dependenţe multivalorice

Pentru ilustrarea acestui tip de dependenţe se ia în considerare următoarea schemă de relaţie:

Clase(Clasa, Discipline, Elevi)ce conţine clasele dintr-o instituţie de învăţământ, iar pentru fiecare clasă sunt înregistrate disciplinele ce se predau şi elevii înmatriculaţi în clasa respectivă. Se poate constata că

74

relaţia Clase poate rezulta prin operaţia de cuplare după atributul Clasa a următoarelor două relaţii:

CD(Clasa, Discipline)CE(Clasa, Elevi)

În relaţia Clase, presupunând că pentru o clasă dată, fiecare elev frecventează toate disciplinele înregistrate pentru acea clasă, există dependenţele multivalorice:

Clasa ->> DisciplineClasa ->> Elevi.

Ca şi în cazul dependenţelor funcţionale, existenţa dependenţelor multivalorice prezintă aceleaşi neajunsuri privind redundanţa datelor şi anomalii la efectuarea operaţiilor de adăugare, actualizare şi ştergere înregistrări în baza de date.

O relaţie R este în a patra formă normală dacă singurele dependenţe multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care conţine o cheie a relaţiei.

Întrucât orice dependenţă funcţională este un caz particular de dependenţă multivalorică, rezultă că orice relaţie care se află în forma normală FN4, se află şi în forma normală FNBC. Transformarea unei relaţii într-o colecţie de relaţii care să se afle în FN4 este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea dependenţelor funcţionale cât şi a dependenţelor multivalorice.

În concluzie, putem afirma că în cazul formelor normale de la FN1 la FN4, trecerea de la o formă normală la alta s-a făcut prin descompunerea unei relaţii în altele două, urmărindu-se eliminarea dependenţelor funcţionale şi multivalorice. O relaţie aflată în forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode. Există situaţii când relaţii aflate în FN4 conţin redundanţe şi prezintă anomalii la operaţiile de adăugare, ştergere şi actualizare. Aceste anomalii sunt cauzate de existenţa dependenţelor de cuplare şi pot fi eliminate prin descompunerea relaţiei în 3 sau mai multe relaţii a căror cuplare are ca rezultat relaţia iniţială.Dependenţe de cuplare

Se consideră schema de relaţie:SDS (Specializari, Discipline, Studenti)

care conţine disciplinele care se predau la diverse specializări şi studenţii care le frecventează, cu precizarea că pot exista discipline opţionale care nu sunt frecventate de toţi studenţii de la specializarea respectivă. În aceste condiţii în cadrul schemei de relaţie SDS nu au loc dependenţele multivalorice:

Specializari ->> DisciplineSpecializari->> Studenti

ceea ce înseamnă că relaţia SDS este în FN4. Deşi este în FN4, relaţia SDS conţine mai multe redundanţe care pot conduce la anomalii de actualizare. Pe de altă parte, relaţia SDS nu poate fi descompusă în două componente din a căror cuplare să rezulte relaţia iniţială cu conservarea informaţiei. Se constată însă că relaţia SDS poate fi descompusă în următoarele 3 relaţii:

SD(Specializari, Discipline)SS(Specializari, Studenti)

75

DS(Discipline, Studenti)şi relaţia SDS este rezultatul cuplării relaţiilor: SD, SS şi DS fără pierdere de informaţie.

SDS = SD►◄SS►◄DS.În acest caz spunem că în relaţia SDS există o dependenţă de cuplare.

Dependenţele multivalorice sunt cazuri particulare de dependenţe de cuplare.A cincea formă normală este o generalizare a formei normale patru, trecerea unei

relaţii în FN5 presupunând eliminarea dependenţelor de cuplare existente în cadrul relaţiei, împreună cu anomaliile pe care acestea le creează. În cadrul unei relaţii pot exista dependenţe de cuplare care nu conduc la redundanţă în memorarea datelor şi nu produc anomalii la operaţiile efectuate asupra înregistrărilor bazei de date (acestea sunt dependenţele de cuplare implicate de o cheie a relaţiei).

O relaţie este în forma normală cinci (FN5) dacă şi numai dacă toate dependenţele de cuplare existente în relaţie sunt implicate de o cheie a acesteia. Relaţia SDS se poate descompune, cu conservarea conţinutului de informaţie, în cele 3 componente ale sale: SD, SS şi DS care sunt în FN5.

Având în vedere similaritatea ce există între definiţiile pentru FNBC, FN4 şi FN5, acestea pot fi unificate în următoarea definiţie [20]:

O relaţie R este în FNBC, FN4, FN5 dacă şi numai dacă singurele dependenţe funcţionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaţiei R.

În concluzie, prin procesul de normalizare se realizează eliminarea din schemele de relaţie a dependenţelor (funcţionale, multivalorice şi de cuplare) cu scopul de a obţine o schemă relaţională mai bună din punctul de vedere al redundanţei datelor şi al anomaliilor ce pot apare la operaţiile de adăugare, ştergere şi actualizare înregistrări în baza de date. Normalizarea unei scheme de relaţie R înseamnă înlocuirea acesteia cu o mulţime de proiecţii R1,...,Rn astfel încât R să fie echivalentă cu uniunea proiecţiilor R1,...,Rn. Deşi normalizarea este o operaţie utilă în proiectarea bazelor de date, aceasta nu oferă întotdeauna reţete pentru obţinerea celor mai bune modele şi de aceea este la latitudinea proiectantului decizia de a aplica sau nu o anumită etapă de normalizare după o analiză temeinică a avantajelor şi dezavantajelor modelului obţinut. În unele cazuri normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere constatările de mai sus se poate afirma că deşi normalizarea nu reprezintă o soluţie general valabilă în orice situaţie, totuşi dacă pentru proiectarea bazei de date se aplică corect o metodologie de proiectare descendentă, modelul rezultat va fi de la sine normalizat. Cercetările în acest domeniu continuă, fiind definite şi alte forme normale printre care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente, conţine şi date istorice, iar factorul (atributul) timp are un rol esenţial (exemple concludente de astfel de baze de date sunt depozitele de date). Astfel, în proiectarea unei baze de date temporale trebuie avute în vedere şi alte operaţii de descompunere a schemelor de relaţie şi anume:

descompunerea orizontală – pentru separarea datelor curente de datele istorice; descompunerea verticală – pentru separarea atributelor aceleiaşi entităţi având în

vedere valorile lor raportate la atributul temporal.

76

În proiectarea unei baze de date nu este exclusă nici operaţia inversă normalizării numită denormalizare [16], prin care se urmăreşte înlocuirea unei colecţii de scheme de relaţie cu o schemă de relaţie echivalentă în vederea eliminării necesităţii efectuării unor operaţii de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendinţa este de a ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând fi avute în vedere doar aspecte legate de performanţele anumitor aplicaţii.

Un alt principiu care se urmăreşte în proiectarea unei baze de date este principiul proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relaţie reale (variabile de relaţie de bază) nu trebuie să aibă semnificaţii suprapuse. În timp ce prin normalizare se urmăreşte reducerea redundanţei din cadrul unei scheme de relaţie, prin proiectarea ortogonală se urmăreşte reducerea redundanţei dintre schemele de relaţie.

4.3.2. Simplificarea structurii datelor prin normalizareProblema de bază a proiectării logice a bazelor de date este cum ar trebui

combinate datele elementare pentru a forma relaţii(sau tipuri de înregistrări) care să descrie entităţile şi relaţiile dintre entităţi. În limbajul bazelor de date, cuvântul relaţie înseamnă un tabel de date, ceea ce duce la concluzia că bazele de date relaţionale (modelul relaţional) sunt clădite pe un grup de tabele legate între ele [46].

Modelul relaţional a fost dezvoltat de către Codd. Este un model conceptual de organizare a datelor, destinat reprezentării legăturilor dintre date. El este bazat pe teoria matematică a relaţiilor şi este definit cu o deosebită rigoare matematică [Popescu I., 1996].

În cadrul modelului relaţional datele sunt structurate sub forma de relaţii (de aici şi denumirea). Cea mai directa şi intuitiva modalitate de reprezentare a datelor în cadrul acestui model este sub forma de tabele. Fiecărei relaţii i se poate asocia un tabel care are atâtea coloane câte mulţimi leagă relaţia şi are atâtea linii câte tuple conţine relaţia.

Prezentarea structurii relaţionale a datelor impune definirea noţiunilor de: domeniu, relaţie, atribut şi schemă a unei relaţii. Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de bază ale organizării datelor sunt prezentate în tabelul următor:

Tabel 4.1. Concepte utilizate în bazele de date relaţionaleFormal Uzual FizicRelaţie Tablou Fişier(tabel)Tuplu Linie ÎnregistrareAtribut Coloană CâmpDomeniu Tip de dată Tip de dată

Definirea domeniuluiUn domeniu este o mulţime de valori caracterizată printr-un nume. Un domeniu se

poate defini explicit prin enumerarea tuturor valorilor aparţinând acestuia sau definind o proprietate distinctivă a domeniului valorilor, de cele mai multe ori limita superioară şi limita inferioară [54]. De exemplu:

77

D1: {“F”,”M”} -definire explicităD2: {x| xN, x [0,100]} -definire implicităD3: {s|s=şir de caractere} -definire implicită

Pentru un ansamblu de domenii D1,D2,…,Dn produsul cartezian al acestora reprezintă ansamblul tuplurilor (elemente ale unei relaţii) <v1,v2,…,vk> unde vi este un element care aparţine domeniului Di. De exemplu, tuplurile <“Maria”,”F”,”50” >,< “Vasile”,”M”,”60”> aparţin produsului cartezian D3xD1xD2.

Definirea relaţiei O relaţie R pe mulţimile D1,D2,…,Dn este o submulţime a produsului cartezian

D1xD2x…xDn, deci o mulţime de tupluri [54].Considerând că nu se cunosc decât două persoane, relaţia R se defineşte prin

tuplurile care descriu aceste persoane, şi anume:R: {<“Maria”,”F”,”50”>,<“Vasile”,”M”,”60”>}

O relaţie poate fi reprezentată printr-un tabel bidimensional în care fiecare linie corespunde unui tuplu şi fiecare coloană corespunde unui domeniu.

R: D3 D1 D2

“Maria” “F” 50“Vasile” “M” 60

Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor, deoarece este uşor de înţeles şi de utilizat.

În prezentarea conceptului de relaţie se poate recurge la analogii cu alte concepte cum ar fi cel de fişier. Relaţia poate avea semnificaţia unui fişier, tuplul poate fi considerat o înregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înregistrare.

Definirea atributuluiÎn timp ce tuplurile dintr-o relaţie trebuie să fie unice, un domeniu poate apare de

mai multe ori în produsul cartezian pe baza căruia este definită relaţia [Popescu I, 1996].PERS D3 D1 D2 D3

“Maria” “F” 50 “Vasile”“Vasile” “M” 60 “Maria”

Relaţia PERS reprezintă un subansamblu al produsului cartezian D3xD1xD2xD3. Atributul reprezintă coloana unei tabele de date, caracterizată printr-un nume. Numele coloanei (atributului) exprimă, de obicei, semnificaţia valorilor din cadrul coloanei respective.

Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza domeniului de care aparţin valorile ci şi funcţie de poziţia ocupată în cadrul tuplului. Dependenţa faţă de ordinea datelor înseamnă o reducere a flexibilităţii organizării datelor. Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor nu trebuie să prezinte nici o importanţă. Pentru a diferenţia coloanele care conţin valori ale aceluiaşi domeniu, şi

78

a elimina astfel dependenţa de poziţie în cadrul tabelei se introduce tocmai conceptul de atribut. Fiecare relaţie are asociat un nume sau un identificator propriu.

Schema unei relaţii este formată din ansamblul elementelor definitorii sau din nivelul relaţiei urmat de lista atributelor specifice.

În mulţimile matematice nu este permis ca un obiect să apară de mai multe ori. Cât timp o relaţie este o mulţime de tupluri, teoretic nici o linie a unei relaţii nu poate fi duplicatul altei linii. După cum reiese din prezentările anterioare, dacă o coloană sau o combinaţie de coloane nu poate să identifice în mod unic o linie, atunci trebuie inventată o coloană-cheie specială.

O tehnica de proiectare a modelului conceptual al bazei de date într-o abordare bottom-up este tehnica celor cinci forme normale.

Conform acestei tehnici, atributele entităţilor definite se organizează într-o singură tabelă sau în mai multe şi se urmăreşte descompunerea acestor tabele în altele, fără pierdere de informaţii în scopul eliminării anomaliilor de ordin logic şi fizic. Acest lucru se realizează prin parcurgerea a o serie de etape, de normalizare, prin care se trece de la o forma normală la alta. Se apreciază posibilitatea existentei a cinci forme normale (FN). Prin parcurgerea acestor etape, se ajunge în mod succesiv să se amelioreze structura bazei de date, înlăturându-se treptat o serie de neajunsuri şi asigurând facilităţi sporite în privinţa încărcării, actualizării şi exploatării bazei de date. O relaţie nenormalizată conţine unul sau mai multe grupuri care se repetă.

Necesitatea normalizării progresive este dată de faptul că anumite relaţii pot genera o serie de situaţii nedorite, aşa-numitele “anomalii de actualizare”, cum sunt: anomalia de ştergere, anomalia de adăugare, anomalia de modificare [11].

4.3.3. Transformarea diagramelor entitate-relaţie în relaţiiPentru a se putea compara rezultatele obţinute în etapa de proiectare logică a

datelor, adică a relaţiilor normalizate, cu diagrama entitate-relaţie, rezultat al proiectării conceptuale, aceasta din urmă trebuie să fie convertită în relaţii, de asemenea, normalizate.

Întregul proces se desfăşoară în patru paşi, astfel: [46]Reprezentarea entităţilor. Fiecare tip de entitate din diagrama entitate-relaţie este reprezentată ca o relaţie în modulul relaţional al datelor. Identificatorul tipului de entitate devine cheie primară a relaţiei, iar celelalte atribute ale tipului entităţii devin atribute non-cheie ale relaţiei.Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relaţie trebuie să fie reprezentată în modelul relaţional al datelor. Reprezentarea legăturii se efectuează în funcţie de natura ei. De exemplu, uneori se poate constitui o relaţie prin includerea cheii primare a unei relaţii ca o cheie străină în altă relaţie. Astfel, se poate crea o relaţie separată pentru reprezentarea legăturii.Normalizarea relaţiilor. Relaţiile create în paşii 1 şi 2 pot conţine redundanţe nedorite şi vor constitui surse de înregistrare a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a relaţiilor.

79

Fuziunea relaţiilor. În timpul modelării logice a datelor s-au creat diferite relaţii, atât pe baza normalizării ascendente a perspectivelor utilizatorilor, cât şi a transformării uneia sau a mai multor diagrame entitate-relaţie în seturi de relaţii. În structura acestor seturi de relaţii pot exista unele relaţii redundante, cum ar fi existenţa a două sau mai multe relaţii care descriu acelaşi tip de entitate, ce ar trebui să fuzioneze şi să se renormalizeze pentru extragerea eventualelor redundanţe.

Teste rezolvate

1. Afirmaţiile următoare nu sunt corecte:a) Fiecare Format/formular de intrare va fi asociat unui flux al datelor de intrare

într-un proces al DFD;b) Un proces al DFD va fi asociat cu o macheta de ecran;c) Rapoartele se pot regăsi într-un flux al datelor generate de un proces al DFD.

Răspuns: b2. Prezentarea informaţiile din formulare/formate şi rapoarte pot fi oferite:

a) sub formă de text;b) sub formă de sfaturi;c) sub formă de grafice;d) sub formă de tabele.

Răspuns: a, c, d3. Macheta imprimantei cuprinde:

a) antet;b) titlu;c) date elementare ce se imprima rând de rând;d) totalurile.

Răspuns: a, b, c, d4. Detaliile şi indicaţiile tehnice de realizare a machetei imprimantei se referă la:

a) volumul datelor de ieşire;b) intensitatea datelor;c) contrast.

Răspuns: a5. Alegerea tipului de suport fizic de ieşire (imprimanta, display, etc.) se face în funcţie

de:a) sursa de energie; b) calitatea datelor; c) costul suportului.

Răspuns: c6. În definitivarea formei şi formatului de prezentare a situaţiilor finale trebuie să ţinem

seama de o serie de considerente practice cum ar fi: a) Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei

finale;b) Restricţii tehnice;c) Utilizarea formularelor pretipărite;d) Utilizarea generatoarelor de rapoarte.

80

Răspuns: a, b, c, d7. Activităţile parcurse la realizarea unui sistem de coduri sunt:

a) analiza elementelor care urmează a fi codificate; b) analiza sistemului decizional;c) uniformizarea datelor de intrare;d) alegerea tipurilor de coduri.

Răspuns: a, d8. La proiectarea intrărilor este necesar să se realizeze, în principal următoarele activităţi:

a) alegerea colecţiilor de date;b) proiectarea machetelor documentelor de intrare;c) alegerea regulilor de control şi validare a datelor;d) proiectarea formularelor (videoformatului) de intrare.

Răspuns: b, c, d9. Macheta documentului de intrare conţine:

a) antetul documentului;b) diagrama fluxului de date;c) denumirea documentului.

Răspuns: a, c10. Nu sunt metode de interacţiune om – maşină:

a) interacţiunea permanentă,b) interacţiunea prin meniuri,c) interacţiunea bazată pe obiecte icons,d) interacţiunea prin limbaj natural.

Răspuns: a11. Echipamentele necesare interacţiunii cu sistemul sunt:

a) eyescreen; b) keyboard; c) mouse.Răspuns: b, c

12. Construirea prototipului secvenţei de derulare a dialogurilor se poate face cu ajutorul:a) instrucţiunilor repetitive; b) produselor CASE; c) mediile de dezvoltare grafică.

Răspuns: b, c

13. În procesul de modelare logică a datelor sunt paşi esenţiali:a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare şi

rapoarte) privind aplicaţia, folosindu-se principiile normalizări;b) Implementarea modelului logic al datelor.c) Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să

se ţină cont de perspectiva utilizatorului, într-un set de relaţii normalizate;Răspuns: a, c

14. Nu sunt elemente de bază ale structurii relaţionale a datelor:a) Relaţia;b) Atributul;c) Fişierul;

81

d) Domeniul;e) Tuplul.

Răspuns: c15. Paşii parcurşi în procesul de transformare a diagramelor entitate-relaţie în relaţii sunt:

a) Reprezentarea entităţilor;b) Reprezentarea legăturilor;c) Normalizarea relaţiilor.

Răspuns: a, b, c16. Modelul conceptual pune în evidenţă:

a) modul de stocare a datelor pe suportul de memorare;b) reprezentarea logică, detaliată a entităţilor, asocierilor (legăturilor) şi datelor elementare ale unei organizaţii;c) structura globală de organizare a datelor.

Răspuns: b), c)17. Normalizarea unei relaţii constă în:

a) Descrierea relaţiei în limbajul de descriere a datelor;b) Identificarea dependenţelor între atributele relaţiei;c) Descompunerea relaţiei în relaţii echivalente urmărind eliminarea redundanţei datelor şi anomaliilor la efectuarea operaţiilor de adaugare, actualizare şi ştergere în baza de date.

Răspuns: c)

82

Capitolul 5. Proiectarea fizică a sistemelor informatice

Proiectarea fizică cunoscută şi sub numele de proiectare de detaliu, urmează proiectării logice întâlnită şi sub numele de proiectare generală sau proiectare de ansamblu. În timpul proiectării logice se prezintă o imagine de ansamblu (generală) a sistemului, în timp ce proiectarea fizică înseamnă o abordare detaliată a sistemului. Cu alte cuvinte, în etapa de proiectare logică se acumulează informaţiile de natură să sintetizeze cerinţele utilizatorilor noului sistem, operaţiune prestată de analiştii de sistem, iar în timpul proiectării fizice se prezintă punctele de vedere ale specialiştilor, cum ar fi cei din domeniul bazelor de date, securităţii sistemelor, reţelelor de calculatoare, programării, etc.

Proiectarea fizică implică parcurgerea următorilor paşi [46]:1. Proiectarea fizică a bazelor de date şi a fişierelor. O astfel de activitate înseamnă

descrierea modului în care vor fi stocate datele şi cum se va asigura controlul lor pentru a se oferi o securitate maximă;

2. Proiectarea structurii sistemului şi a programelor. Se descriu programele sau modulele acestora care să fie în strânsă concordanţă cu diagramele fluxurilor de date şi cu celelalte piese ale documentaţiei realizate în etapele anterioare;

3. Proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalităţile în care utilizatorul poate să dispună de date şi facilităţile de prelucrare oferite de reţele de calculatoare.

5.1. Proiectarea fizică a bazelor de date şi a fişierelorModelul conceptual surprinde structura globală de organizare a datelor,

asigurându-se independenţa totală faţă de orice sistem de gestiune a bazelor de date. Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaţie(DER), motiv pentru care este cunoscut şi sub numele de modelul entitate-relaţie al datelor. El scoate în evidenţă reprezentarea logică, detaliată a entităţilor, asocierilor (legăturilor) şi datelor elementare ale unei organizaţii sau ale unei părţi din ea. Modelul se realizează în faza de analiză.

Modelul logic al datelor înseamnă descrierea datelor în concordanţă cu modelul de organizare a acestora de către sistemele de gestiune a bazelor de date. În acest material s-a ales modelul relaţional. Conform cu acest model datele sunt reprezentate în baza de date sub forma tabelelor sau relaţiilor create din diagrama entitate-relaţie obţinută în etapa anterioară.

O bază de date poate fi definită ca un ansamblu de date elementare sau structurate, accesibile unei comunităţi de utilizatori. Mai concret, la nivel fizic, o bază de date este un ansamblu de fişiere intercorelate, care conţine nucleul de date necesare unui sistem informatic (aplicaţie informatică). Un fişier este un ansamblu de înregistrări fizice, omogene din punct de vedere al conţinutului şi al prelucrării. O înregistrare fizică este unitatea de transfer între memoria internă şi cea externă a calculatorului. Înregistrarea fizică este formată din una sau mai multe înregistrări logice. O înregistrare logică este

83

unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este formată dintr-un ansamblu de câmpuri, care descriu o anumită entitate.

Modul de stocare a datelor pe suportul fizic de memorare este funcţie de sistemul de gestiune a bazelor de date utilizat.

Proiectarea fizică a bazelor de date şi a fişierelor îşi propune să asigure trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor. O problemă de importanţă majoră în cadrul acestei etape o constituie alegerea Sistemului de Gestiune a Bazelor de Date adecvat soluţionării optime a problemelor formulate în etapele anterioare ale realizării sistemului informatic.

5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:Centralizarea datelor permite: suprimarea redundanţei, asigurarea unicităţii

înregistrării şi controlul centralizat (asupra datelor). În prelucrarea clasică în care fişierele sunt dedicate aplicaţiilor, aceleaşi date apar înregistrate în mai multe fişiere şi în formate diferite. Acest lucru implică o utilizare ineficientă a spaţiului de memorie externă, actualizarea dificilă a acestor date şi lizibilitate redusă ca urmare a formatelor diferite.

Independenţa între date şi prelucrări. Baza de date, ca imagine a unei anumite realităţi, trebuie actualizată permanent. Acest lucru nu trebuie să afecteze programele de prelucrare. Pentru aceasta trebuie ca fiecare program să aibă o viziune proprie asupra BD

Realizarea de legături între entităţile de date, care sunt indispensabile pentru exploatarea eficientă a sistemului informatic. Spre exemplu, în cadrul gestiunii aprovizionării, trebuie asociat un furnizor la lista de produse pe care le vinde şi invers, un produs la lista de furnizori, precizând condiţiile de vânzare pentru un furnizor şi un produs.

Integritatea datelor asigură fiabilitatea şi coerenţa bazei de date (BD). Pentru aceasta trebuie definite restricţii de integritate cum ar fi:

apartenenţa la o listă de valori sau interval; apartenenţa la un anumit format; reguli de coerenţă cu alte date. Securitatea datelor. Baza de date trebuie să fie protejată împotriva unei distrugeri

logice (anomalie de actualizare) sau fizice. Pentru aceasta există instrumente care permit: crearea unor puncte de repriză; altfel spus, salvarea din timp în timp a unor

copii coerente ale bazei de date; gestiunea unui jurnal de tranzacţii; lista operaţiilor realizate asupra bazei de

date după ultimul punct de repriză. Confidenţialitatea datelor este asigurată prin proceduri de: identificare a utilizatorilor prin nume sau cod; autentificarea prin parole; autorizarea accesului diferenţiat prin drepturi de creare, consultare modificare

sau ştergere pentru anumite segmente de date. Partajarea datelor permite înlănţuirea tranzacţiilor solicitate simultan pe aceeaşi

înregistrare din baza de date, prin blocarea cererilor în aşteptare şi deservirea ulterioară a acestora.

84

5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)Sistemul de gestiune a bazelor de date referit prescurtat SGBD sau DBMS (Data

Base Management System) este un sistem de programe care permite definirea, crearea şi întreţinerea bazei de date, precum şi accesul controlat la baza de date. Un SGBD oferă următoarele facilităţi pentru crearea şi exploatarea bazelor de date:

facilităţi de descriere a datelor, prin intermediul unui limbaj de descriere a datelor DDL (Data Description Language) care permite utilizatorului să descrie structurile de date ce vor fi memorate în baza de date;

facilităţi de manipulare a datelor, prin intermediul unui limbaj de manipulare a datelor DML (Data Manipulation Language) care permite utilizatorului să insereze, actualizeze, şteargă, să prelucreze şi să extragă date din baza de date;

controlul accesului la baza de date prin intermediul unui limbaj de control DCL (Data Control Language) care asigură:

- sistem de securitate, previne accesarea bazei de date de către utilizatori neautorizaţi;

- sistem de integritate, menţine concordanţa datelor stocate în baza de date;

- sistem de control al concurenţei, permite accesul partajat la baza de date;- sistem de control al refacerii, permite recuperarea bazei de date în urma

unor defecţiuni hard sau soft; mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei

de date care îl interesează.În majoritatea produselor comerciale de baze de date , cele trei limbaje se regăsesc

reunite în cadrul unui singur limbaj (spre exemplu limbajul SQL).

5.1.3. Administratorul bazei de dateAdministratorul bazei de date referit prescurtat DBA (Data Base Administrator),

este o persoană sau un grup de persoane care coordonează şi răspunde de ansamblul activităţilor privind baza de date, începând din faza de proiectare şi continuând cu celelalte etape pe întreaga perioadă de viaţă a bazei de date. Astfel, în faza de proiectare a bazei de date, administratorul stabileşte SGBD-ul ce va fi utilizat, echipamentele necesare, structurile de date plecând de la necesităţile de informaţie ale tuturor utilizatorilor bazei de date, drepturile de acces la date ale fiecărui utilizator. Rezultatul fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema generală a bazei de date), modelului extern (subschema proprie fiecărui utilizator) şi stabilirea modalităţilor de reprezentare a structurilor de date la nivel fizic pe suporturile de memorare externe utilizate. Drepturile de acces la baza de date pot fi definite [ORA92] fie pentru fiecare utilizator în parte, fie pentru grupuri de utilizatori (denumite Role), fiecare utilizator fiind apoi asignat unui grup. După proiectarea bazei de date, administratorul va menţine permanent legătura cu utilizatorii acesteia pentru rezolvarea cerinţelor utilizatorilor şi impunerea unei discipline în vederea alinierii la standardele existente. Administratorul va realiza, ori de câte ori se impune, reorganizarea structurii fizice a datelor în vederea optimizării parametrilor de funcţionare a întregului sistem şi va stabili

85

proceduri de arhivare a datelor şi proceduri de recuperare a bazei de date la avarii şi defecte. Pentru a preveni accesul neautorizat la date, în cadrul sistemului de securitate pot fi prevăzute [16] şi alte mecanisme şi anume: evidenţa de auditare, criptarea datelor.

Evidenţa de auditare constă dintr-un fişier în care sistemul înregistrează automat toate operaţiile efectuate asupra datelor, fişier ce va putea fi consultat de către persoane autorizate pentru a verifica efectuarea unor operaţii neautorizate. O înregistrare din evidenţa de auditare va conţine următoarele informaţii: textul sursă al operaţiei executate, terminalul de la care a fost lansată operaţia, utilizatorul care a lansat operaţia, data şi ora operării, obiectele bazei de date afectate, imaginile datelor afectate înainte de efectuarea operaţiei, imaginile datelor afectate după efectuarea operaţiei.

Pentru a preveni accesul unor intruşi la baza de date, care încearcă să ocolească sistemul, se utilizează criptarea datelor, mecanism ce constă în stocarea şi transmiterea datelor pe căile de comunicaţie sub formă cifrată. Criptarea se realizează cu ajutorul unor algoritmi de criptare printre care cel mai recent este standardul american de criptare avansat AES (Advanced Encryption Standard).

5.1.4. Proiectarea securităţii bazelor de date şi a fişierelorSecuritatea este abordată din mai multe puncte de vedere, dar cea referitoare la

baze de date şi la fişiere presupune luarea unor măsuri pentru reconstituirea datelor pierdute sau preluate eronat, precum şi pentru accesul neautorizat sau incomodarea până la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal. Aşadar două aspecte vor fi relevante: reconstituirea datelor şi criptarea lor [46].

Reconstituirea datelor este des asociată cu existenţa fişierelor de tip back-up, însă în practică este posibilă şi reconstituirea fără apelarea la acest tip de fişiere. În vederea controlării corectitudinii datelor tranzacţionate se apelează la fişiere cu rol special, care conţin un istoric, în ordine cronologică, al schimbărilor şi accesărilor efectuate asupra fişierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fişierele distruse, dar şi la verificarea corectitudinii operaţiunilor de actualizare.

Securitatea prin criptografiere se referă la asigurarea transformării datelor de comunicat într-o formă neinteligibilă pentru toţi ceilalţi receptori, exceptându-l pe cel autorizat. Criptarea a devenit una dintre cele mai puternice modalităţi de asigurare a securităţii datelor. Ea poate fi realizată prin sistemul de operare sau prin SGBD, dar şi prin rutine create de către specialişti.

În cele ce urmează sunt prezentate criteriile avute în vedere în alegerea tipului de SGBD [11].

a) Portabilitatea SGBD-ului. Prin aceasta înţelegem posibilitatea de a utiliza un SGBD de pe un sistem de calcul pe un altul. Portabilitatea cuprinde două aspecte şi anume: portabilitatea programelor propriu-zise şi portabilitatea datelor. Pentru realizarea unor programe portabile este necesar ca: programele să conţină cât mai puţine elemente legate de echipament. Portabilitatea sistemului de gestiune privit prin prisma portabilitaţii datelor se referă la posibilitatea de a folosi o serie de date utilizate în cadrul unui sistem informatic de către un alt sistem informatic, deci posibilitatea integrării fişierelor deja existente în cadrul unui alt sistem.

86

b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a unităţii centrale; costului de întreţinere şi dezvoltare; resurselor hard imobilizate; costului de adaptare şi trecere pe un nou sistem de calcul; costul documentaţiei etc.

c) Facilităţile de implementare, întreţinere şi exploatare a bazei de date. Acestea sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare şi regăsire a datelor, care să permită un acces cât mai rapid la orice informaţie; timpul cât mai redus pentru actualizare, căutare şi răspuns la cererile de informare; editarea operativă a celor mai variate tipuri de situaţii solicitate de către utilizator; posibilitatea de inserţie a unor programe de aplicaţie, programe de validare de date, de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafică a ieşirilor etc.

d) Posibilitatea gestionarii structurilor complexe de date.e) Multitudinea metodelor de acces. In funcţie de cerinţele proprii aplicaţiei, sistemul

va trebui să suporte interogări sau actualizări în timp real având proceduri de tip conversaţional.

f) Protecţia şi securitatea datelor din bază. g) Specificul aplicaţiei. Este cunoscut faptul că programele sunt orientate pe aplicaţii,

cum ar fi: programarea producţiei, aprovizionare-desfacere, optimizări, prognoze etc. Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari

cum ar fi: mentenanţa sistemului, facilităţile ce le oferă administratorului bazei de date, calitatea documentaţiei oferite de furnizori, asistenţă în implementarea sistemului şi în pregătirea utilizatorilor etc. Toţi aceşti factori alături de criteriile enunţate pot să influenţeze succesul în implementarea SGBD-ului şi eficienţa economică pe ansamblul sistemului informatic.

În cele ce urmează se vor prezenta o serie de aspecte privind utilizarea limbajului SQL pentru crearea bazei de date, definirea utilizatorilor şi acordarea drepturilor de acces, definirea interogărilor bazei de date, precum şi exemple practice sub SGBD ORACLE.

5.1.5. Limbajul SQL - Crearea, Administrarea şi Interogarea bazelor de date relaţionale

Limbajul SQL (Structured Query Language)– a fost realizat în cadrul firmei IBM ca limbaj de interogare al SGBD System R şi ulterior a devenit unul din cele mai răspândite limbaje pentru SGBD-urile relaţionale. Limbajul SQL, ca limbaj de interogare a bazelor de date relaţionale, este construit pe baza a două formalisme abstracte enunţate în cele ce urmează.

1. Algebra relaţională – prin care interogările sunt exprimate prin aplicarea unor operatori unari sau binari care constituie primitive ce acţionează asupra relaţiilor, rezultatul interogărilor fiind tot relaţii, ceea ce permite asocierea şi imbricarea acestor operatori pentru a forma interogări complexe. Operatorii algebrei relaţionale se împart în două grupe şi anume:- operaţii pe mulţimi (Reuniunea, Intersecţia, Diferenţa, Produsul cartezian);- operatori relaţionali speciali (Selecţia, Proiecţia, Cuplarea (JOIN), Diviziunea).

87

2. Calculul relaţional – prin care interogările descriu mulţimea tuplelor rezultat prin specificarea unui predicat (condiţie) care trebuie satisfăcut de aceste tuple.Începând din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de

interogare ale bazelor de date relaţionale fiind utilizat atât în cadrul unor SGBD-uri complexe cum ar fi SGBD ORACLE (liderul mondial în domeniul bazelor de date), cât şi în cadrul unor SGBD-uri de complexitate redusă cum ar fi cele din familia xBase (Dbase IV, FoxPro).

Standardul SQL utilizat pînă la începutul anului 2000 este cel realizat în 1992 şi cunoscut sub numele de SQL’92 sau SQL2.

Noul standard SQL3 lansat în 1999 are în vedere o serie de extensii faţă de SQL2 după cum urmează:

facilităţi orientate obiect – posibilitatea de definire de către utilizator a tipurilor abstracte de date care să permită descrierea de metode, identitatea obiectelor, subtipuri şi moştenire, polimorfism etc.;

structuri de control – pentru a conferi limbajului completitudine de calcul (IF, FOR, WHILE, etc.) pentru a deveni un limbaj de sine stătător a cărui putere de expresie să nu mai fie limitată la nivelul limbajelor relaţionale;

facilităţi pentru exprimarea prelucrărilor recursive; facilităţi de comunicare în reţea; facilităţi de prelucrare distribuită (mecanisme pentru crearea, memorarea şi

execuţia procedurilor la nivelul serverelor de date –stored procedures); facilităţi multimedia; facilităţi pentru tratarea timpului în bazele de date.

Comenzi pentru crearea/actualizarea schemei bazei de date Crearea unui utilizator se realizează cu comanda

CREATE USER <nume utilizator> IDENTIFIED BY <parola>Adăugarea relaţiilor într-o bază de date –comanda CREATE TABLE are sintaxa:

CREATE TABLE <nume relaţie>[(<nume atribut> <tip dată>,…)]Exemplu -crearea tabelei Persoane în SQL Oracle se realizează cu comanda:

CREATE TABLE Persoane (Nrcrt NUMBER UNIQUE NOT NULL,Nume CHAR(15),Prenume CHAR(15),Datan DATE,Sexul CHAR,Adresa VARCHAR2(50));

O nouă relaţie poate fi creată şi ca rezultat al unei operaţii de interogare astfel:CREATE TABLE <nume relaţie> (<nume atribut> <tip dată>,…) AS <subinterogare>

Adăugarea/modificarea de atribute pentru o relaţie existentă se realizează cu comanda:

ALTER TABLE <nume relaţie> ADD|MODIFY (< nume atribut> <tip dată>,…)Ştergerea unei relaţii se realizează cu comanda:

DROP TABLE <nume relaţie>Comenzi pentru optimizarea interogărilor

Una din principalele căi de optimizare a timpilor de interogare a unei baze de date este indexarea. Un index poate fi privit ca o relaţie cu două atribute şi anume:

88

primul atribut conţine valorile atributelor relaţiei după care se crează indexul; al doilea atribut conţine un pointer (adresa) la locaţia tuplelor corespunzătoare.Crearea unui index se realizează cu comanda:

CREATE [UNIQUE] INDEX <nume index>ON <nume relaţie>(<nume atribut>[ASC|DESC],…)

Dacă pentru atributele utilizate în clauza WHERE a unor instrucţiuni SQL au fost creaţi indecşi, atunci aceştia vor fi utilizaţi în vederea optimizării timpului de prelucrare. Decizia de utilizare sau nu a unui index este luată de limbajul SQL şi nu de utilizator. Pentru aceasta fiecare model de limbaj SQL dispune de o componentă numită optimizator, care examinează interogarea şi decide care este modul optim de obţinere a rezultatului.

O altă tehnică de optimizare a interogărilor este tehnica “clustering” disponibilă în ORACLE şi care constă în gruparea tuplelor din mai multe relaţii şi stocarea lor în aceeaşi zonă pe disc.Controlul datelor (comenzi DCL)Vederi

O vedere este o relaţie virtuală, definită plecând de la alte relaţii din baza de date şi care nu conţine date şi deci nu ocupă spaţiu fizic pe disc. Vederile se definesc în două scopuri şi anume:

pentru a simplifica accesul utilizatorilor la date; pentru a asigura protecţia şi securitatea datelor –fiecărui utilizator fiindu-i

permis acces la o porţiune a bazei de date şi putând efectua doar anumite operaţii (conform drepturilor de acces specificate cu comenzile GRANT/REVOKE).

Asupra unei vederi se pot efectua aceleaşi operaţii ca şi asupra unei relaţii cu deosebirea că vederile nu conţin date şi că orice modificări efectuate asupra datelor sunt reflectate şi în vederi. Astfel, asupra unei vederi se pot realiza operaţiile:

creare vedere (CREATE VIEW); creare sinonim pentru vedere (CREATE SYNONIM); ştergere vedere (DROP VIEW); interogare vedere (SELECT); actualizare date din vedere (UPDATE); ştergere date din vedere (DELETE); adăugare date (INSERT).Crearea unei vederi – se realizează cu comanda CREATE VIEW care are sintaxa:

CREATE VIEW <nume vedere> [<lista atribute>]AS <fraza SELECT> [WITH CHECK OPTION]

Exemplu:CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare)

AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM Produse,StocuriWHERE Produse.codp=Stocuri.Codp AND CodDep = ”D1”Interogarea vederii se va realiza cu comanda

SELECT * FROM StocuriD1

89

Utilizarea opţiunii WITH CHECK OPTION asigură faptul că nici o tuplă nu va fi adaugată sau actualizată cu instrucţiunile INSERT, UPDATE, dacă nu sunt respectate condiţiile specificate în clauza WHERE a instrucţiunii SELECT din definiţia vederii.

Pentru acordarea sau retragerea drepturilor de acces la baza de date prin intermediul vizualizărilor se vor folosi comenzi de forma:

GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>TO <nume utilizator>

sauREVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>

FROM <nume utilizator>Asigurarea securităţii datelor presupune definirea drepturilor de acces ale

utilizatorilor şi protecţia sistemului la accesul neautorizat. În acest sens asigurarea securităţii se realizează pe două niveluri şi anume:

– nivelul 1 – acordarea dreptului de acces la sistem;– nivelul 2 – acordarea dreptului de acces la nivel de relaţii.Pentru conectarea utilizatorilor la sistem în majoritatea versiunilor de SQL se

utilizează un nume de utilizator şi o parolă.Referitor la drepturile de acces la nivel de relaţie în sistemele multi-user trebuie

precizat utilizatorul care a creat relaţia (proprietarul relaţiei). Fiecare utilizator are drepturi doar asupra propriilor relaţii, iar drepturi asupra unor relaţii create de alţi utilizatori pot fi acordate prin comanda GRANT şi pot fi retrase prin comanda REVOKE.

Datele privind definirea bazei de date, utilizatorii şi drepturile de acces sunt stocate în dicţionarul de date şi sunt gestionate de către sistemul de gestiune a bazei de date (SGBDR).

În cele ce urmează se va prezenta modul de realizare a celor două nivele de securitate în cadrul sistemului ORACLE.Nivelul 1 de securitate a datelor se realizează cu comanda:

GRANT <autorizare,…> TO <nume utilizator> [IDENTIFIED BY <parola>]unde <autorizare> poate fi:

DBA – conferă utilizatorului dreptul de efectuare a oricărei operaţii asupra oricărei relaţii din baza de date;

CONNECT – conferă utilizatorului dreptul de a a face interogări (SELECT) şi actualizări (INSERT, UPDATE, DELETE) asupra relaţiilor create de alţi utilizatori, însă nu permite utilizatorului să creeze relaţii (CREATE) sau să şteargă relaţii create de alţi utilizatori (DROP);

RESOURCE – conferă utilizatorului drepturile ce rezultă din autorizarea CONNECT şi în plus dreptul de a crea relaţii (CREATE) şi de a şterge relaţii ce îi aparţin (DROP).

Unui utilizator îi pot fi acordate mai multe tipuri de autorizări în cadrul unei singure comenzi GRANT.

Parola stabilită pentru un utilizator poate fi modificată printr-o comandă GRANT ulterioară spre exemplu astfel:

GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parolă>

90

Unui utilizator căruia i s-a acordat un tip de autorizare îi pot fi acordate şi alte tipuri de autorizare prin comenzi GRANT ulterioare.

Retragerea autorizărilor acordate unui utilizator se realizează cu comanda:REVOKE <autorizare,…> FROM <nume utilizator>

Nivelul 2 de securitate a datelorPentru acordarea respectiv retragerea drepturilor de acces la relaţii se utilizează

comenzile GRANT respectiv REVOKE cu următoarea sintaxă:GRANT ALL|<drept de acces>,… ON <nume relaţie> TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]

respectivREVOKE ALL|<drept de acces>,… ON <nume relaţie>

FROM <nume utilizator>|PUBLICPrivilegiile (drepturile de acces) pot fi acordate sau retrase de următoarele categorii

de utilizatori: utilizatorii cu nivel de autorizare DBA; proprietarii relaţiilor; utilizatorii autorizaţi cu opţiunea WITH GRANT OPTION.Prin specificarea PUBLIC acordarea respectiv retragerea drepturilor de acces se

aplică tuturor utilizatorilor.Prin specificarea WITH GRANT OPTION, utilizatorul respectiv poate la rândul său

să acorde aceleaşi drepturi sau mai puţine altor utilizatori.În ORACLE pot fi acordate următoarele drepturi de access asupra relaţiilor:

SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele şi indecşi.Drepturile de acces pot fi acordate asupra întregii relaţii, sau doar asupra anumitor

atribute ale relaţiei.Exemple:

Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra relaţiei Persoane care aparţine utilizatorului Vasilescu se realizează prin comanda:

GRANT ALL ON Vasilescu.Persoane TO Ionescu,PopescuAcordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra

relaţiei Produse aparţinând utilizatorului Ionescu se realizează cu comanda:GRANT SELECT,INSERT,UPDATE ON Ionescu.Produse TO PUBLIC

Acordarea privilegiilor SELECT,UPDATE numai asupra atributelor CodP, Denp din relaţia Produse aparţinând utilizatorului Ionescu, utilizatorului Popescu cu condiţia ca acesta la rândul său să poată acorda oricărui alt utilizator aceleaşi drepturi sau mai puţine, se realizează cu comanda:

GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire)TO Popescu WITH GRANT OPTION

Retragerea drepturilor de acces INSERT,DELETE asupra relaţiei Persoane aparţinând utilizatorului Vasilescu, utilizatorului Ionescu se realizează cu comanda:

REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM IonescuInstrucţiuni pentru inserarea şi actualizarea datelor în tabele

Inserarea datelor – comanda INSERT are următoarea sintaxă:

91

INSERT INTO <nume relatie>|<nume vedere> [(<nume atribut>…)][VALUES] <lista valori>|<subinterogare>

Exemple:Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)

INSERT INTO Persoane VALUES (1,’Ionescu’,’Ion’,05/23/82,’M’,’Suceava’)(adaugă o înregistrare în tabela Persoane completând toate atributele)

INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,’Ionescu’,’Ana’)(adaugă o înregistrare în Persoane completând numai atributele Nrcrt,Nume, Prenume)

Pentru a insera în tabela PersF(Nrcrt,Nume,Prenume) toate înregistrările din tabela Persoane pentru care Sexul=’F’ se scrie comanda:

INSERT INTO PersF(Nrcrt,Nume,Prenume) SELECT Nrcrt,Nume,PrenumeFROM Persoane WHERE Sexul = ‘F’

Actualizarea datelor – comanda UPDATE are sintaxa:UPDATE <nume relaţie>|<nume vedere> SET <nume atribut> = <expresie>,…[WHERE <condiţie>]

Condiţia din clauza WHERE defineşte tuplele care vor face obiectul actualizării. Clauza WHERE poate conţine şi o subinterogare.Exemple:

UPDATE Persoane SET Nume = ‘Popescu’, Prenume = ‘Ana Maria’WHERE Nume = ‘Ionescu’ AND Prenume = ‘Ana’

(actualizează numele şi prenumele persoanei Ionescu Ana cu valorile Popescu respectiv Ana Maria).

UPDATE Vanzari SET Pret = Pret*1.2 WHERE CodP IN(SELECT CodP FROM Facturi WHERE Numar = 120

AND Vanzari.Codc=Facturi.Codc )(realizează majorarea preţului cu 20% pentru produsele vândute cu factura 120).

Dacă în comanda UPDATE clauza WHERE este omisă, actualizarea se va efectua asupra tuturor tuplelor relaţiei.

Ştergerea datelor – comanda DELETE are sintaxa:DELETE FROM <nume relaţie>|<nume vedere> [WHERE <condiţie>]

unde <condiţie> poate fi o condiţie simplă, o expresie sau o subinterogare.Exemple:

DELETE FROM Stocuri WHERE Cant = 0(şterge toate înregistrările din tabela Stocuri pentru care câmpul Cant are valoarea 0).

DELETE Oferte(şterge toate înregistrările din tabela Oferte).

Comenzi pentru gestiunea tranzacţiilorTranzacţia este o succesiune de instrucţiuni SQL grupate într-un bloc de

instrucţiuni utilizate pentru actualizarea şi/sau interogarea datelor din baza de date. O tranzacţie se consideră încheiată după realizarea tuturor operaţiilor pe care le conţine. Operaţiile conţinute într-o tranzacţie pot fi realizate efectiv în baza de date sau nu, fie automat de către sistem după fiecare operaţie, fie printr-o comandă explicită dată după o

92

succesiune de operaţii. Astfel salvarea automată de către sistem a modificărilor este realizată prin comanda

SET AUTOCOMMIT ONDacă iniţial a fost specificată comanda SET AUTOCOMMIT OFF, salvarea

modificărilor efectuate asupra datelor se realizează prin comanda COMMIT, iar abandonarea modificărilor se realizează prin comanda ROLLBACK.

Blocul de operaţii ce definesc o tranzacţie poate fi delimitat de instrucţiunile :BEGIN TRANSACTIONEND TRANSACTION

Problemă rezolvatăSe lansează în execuţie SQL Plus Oracle sub utilizatorul system (figura 5.1).În baza de date ORCL sub S.G.B.D. Oracle se crează utilizatorul U1 identificat

prin parola PW1 şi i se acordă privilegiile CONNECT, RESOURCE (figura 5.2).Se închide sesiunea de lucru SQL Plus a utilizatorului system (cu instrucţiunea

EXIT) şi se deschide o nouă sesiune de lucru SQL Plus pentru utilizatorul U1 (figura 5.3).Se crează tabela Produse şi se inserează două înregistrări (figura 5.4).

93

Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system

ORCL

94

Figura 5.2. Creare utilizator U1 şi acordare privilegii CONNECT, RESOURCE

Figura 5.3. Lansare SQL Plus ORACLE pentru utilizatorul U1

ORCL

Figura 5.4. Creare tabelă Produse şi inserare două înregistrări

Limbajul SQL - Interogarea bazelor de date - Fraza SELECTInterogarea bazelor de date în limbajul SQL se realizează cu ajutorul unei singure

instrucţiuni şi anume instrucţiunea SELECT având următoarea sintaxă:SELECT [DISTINCT] <lista atribute>|*FROM <lista relaţii> [WHERE <condiţie>][GROUP BY <lista atribute de grupare>][HAVING <condiţie>][ORDER BY <atribut1 de ordonare> [ASC]|DESC,…][UNION <frază SELECT>]

<lista atribute> este o listă ce conţine nume de atribute (câmpuri) sau expresii construite utilizând atribute, separate prin caracterul “,” şi care fac parte din relaţiile (tabele, vederi) enumerate în <lista relaţii> din clauza FROM. Numele fiecărui atribut sau expresii din <lista atribute> va fi afişat în capul de tabel ce reprezintă rezultatul interogării, fiecare atribut sau expresie putând primi un alias folosind specificarea AS <alias>.

Caracterul ‘*’ specifică faptul că se extrag toate atributele tabelei precizate în clauza FROM.

Clauza DISTINCT precizează faptul că în relaţia rezultat nu pot apărea duplicate (tuple identice).

Clauza WHERE precizează condiţiile de interogare (condiţii care trebuie să fie satisfăcute de tuplele interogate, condiţii de cuplare relaţii (JOIN, relaţii între tabele). În clauza WHERE pot fi utilizaţi operatori logici (AND, NOT, OR), predicate (IN, LIKE, BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a operaţiilor, operatorilor, funcţii şi alte subinterogări SELECT, pentru construirea de expresii pe care trebuie să le îndeplinească tuplele ce constituie rezultatul interogării. Predicatul IN permite specificarea unei liste pentru domeniul de căutare pentru un atribut, iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de căutare a valorilor unui atribut, fiind echivalent cu o condiţie de forma:

<atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>

Exemple:Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)Selectarea tuturor înregistrărilor din tabela Persoane pentru care primele 7

caractere din câmpul Adresa sunt ‘Suceava’ sau ‘Rădăuţi’ se realizează cu comanda:SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (‘Suceava’,‘Rădăuţi’)

Interogarea de mai sus este echivalentă cu interogarea:SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = ‘Suceava’

OR SUBSTR(Adresa,1,7) = ‘Rădăuţi’

95

Selectarea tuturor înregistrărilor din tabela Persoane pentru care data naşterii este cuprinsă între 01/01/72 şi 01/01/82 se realizează astfel:SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND {01/01/82}

Interogarea de mai sus este echivalentă cu interogarea:SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <= {01/01/82}

Predicatul LIKE permite selecţia şirurilor de caractere care conţin anumite caractere specificate prin intermediul unei măşti definite cu ajutorul unor caractere speciale (%, _ în dBASE IV, FoxPro, ORACLE, sau *, ? în INFORMIX) Exemple:

SELECT * FROM Persoane WHERE Nume LIKE ‘%a’(selectează toate înregistrările din tabela Persoane pentru care valorile atributului Nume se termină cu litera ‘a’).

SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE ‘A%u’(selectează valorile atributelor Nume, Prenume, Datan pentru toate înregistrările din tabela Persoane pentru care prima literă din Nume este ‘A’ iar ultima literă este ‘u’).

SELECT Nume FROM Persoane WHERE Nume LIKE ‘_o%’(selectează valorile atributului Nume pentru toate înregistrările din tabela Persoane pentru care prima literă din Nume este orice literă, a doua literă din Nume este litera ‘o’ şi începând din poziţia a treia numele poate conţine orice litere.)

Predicatele ALL, ANY, EXISTS se utilizează pentru interogări ce conţin subinterogări, în vederea verificării anumitor condiţii ce trebuie îndeplinite între rezultatele interogării şi rezultatele subinterogării.

Clauza GROUP BY – realizează gruparea tuplelor unei relaţii pe baza valorilor unui atribut sau grup de atribute şi generează o singură tuplă pentru fiecare grup de tuple având aceeaşi valoare pentru atributele care definesc grupul. Atributele care definesc grupul trebuie obligatoriu să se regăsească în lista atributelor interogate <lista atribute>.

De asemenea asupra unor atribute pot fi aplicate funcţii agregat:

AVG(<atribut>) – media valorilor atributului specificat ca parametru, pe grup; SUM(<atribut>) – suma valorilor atributului specificat ca parametru, pe grup; MAX(<atribut>) – maximum valorilor atributului specificat ca parametru, pe

grup; MIN(<atribut>) – minimum valorilor atributului specificat ca parametru, pe

grup; COUNT(<atribut>) – numărul înregistrărilor pe grupare după <atribut>.Observaţie. <atribut> poate fi fie un atribut, fie o expresie definită utilizând

atribute ale tabelei.Clauza HAVING, opţiune a clauzei GROUP BY, este o formă specială a clauzei

WHERE întrucât se aplică unor grupuri de tuple (şi nu unor tuple) definite de clauza GROUP BY.Exemple:

Fie tabela Stocuri(CodDep,CodP,UmP,Cant,Pret)SELECT CodDep,SUM(Cant*Pret) AS Valoare,COUNT(CodDep) AS Contor FROM

Stocuri GROUP BY CodDep

96

(Calculează suma produselor Cant*Pret pentru toate tuplele având aceeaşi valoare în câmpul CodDep şi numărul înregistrărilor din fiecare grup definit de câmpul CodDep şi afisează rezultatele sub formă de tabel având coloanele CodDep, Valoare, Contor)

SELECT CodDep,CodP,MAX(Pret) FROM StocuriGROUP BY CodP HAVING MAX(Pret) < 150000

(selectează pentru fiecare grupă de înregistrări având aceeaşi valoare în câmpul CodP, înregistrarea cu preţul maxim mai mic decât 150000)

Clauza ORDER BY – permite precizarea ordinii de afişare a datelor astfel:ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC,…

Exemplu:SELECT * FROM Persoane ORDER BY Datan DESC,Nume

(afişează toate înregistrările din tabela Persoane în ordine descrescătoare după data naşterii şi în cadrul aceleiaşi date a naşterii crescător după Nume)

Clauza UNION – permite obţinerea rezultatului a două sau mai multe interogări printr-o singură instrucţiune SELECT.Exemplu:

SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE CodDep = ‘Dep01’UNION

SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE Cant >= 100(selectează tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate înregistrările pentru care CodDep = ‘Dep01’, la care adaugă tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate înregistrările pentru care Cant >= 100).

Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL.Pentru a schimba ordinea de afişare a tuplelor extrase se poate utiliza clauza

ORDER BY aplicată doar relaţiei finale şi nu asupra fiecărei fraze SELECT.Regăsirea datelor din două sau mai multe relaţii

Interogarea datelor din două sau mai multe tabele (relaţii) presupune existenţa unor câmpuri comune pentru realizarea operaţiei de cuplare (operatorul JOIN). În fraza SELECT operaţia de cuplare este definită în clauza WHERE sub forma:

<nume tabela1>.<cheie1> = <nume tabela2>.<cheie2>(unde <cheie1>, <cheie2> reprezintă câmpurile ce identifică înregistrările corespondente în cele două tabele).

Pentru exemplificare pe lângă tabela Stocuri mai considerăm tabela Produse(CodP, DenP, DesP).

SELECT Produse.CodP,DenP,UmP,Cant,Pret FROM Produse,StocuriWHERE Produse.CodP = Stocuri.CodP

(extrage toate tuplele (CodP,DenP,UmP,Cant,Pret) pentru care valoarea atributului CodP din tabela Produse este egală cu valoarea atributului CodP din tabela Stocuri ).

În lipsa clauzei WHERE se vor extrage toate combinaţiile posibile între tuplele celor două tabele (produsul cartezian).

Fiecărei tabele i se poate atribui un alias astfel încât fraza de mai sus este echivalentă cu fraza:

97

SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP = B.CodP

În anumite situaţii poate fi necesară corelarea (cuplarea) unei relaţii (tabele) cu ea însăşi. Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm următoarea interogare:

SELECT A.CodP,A.Cant,A.Pret FROM Stocuri AWHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP)

Pentru rezolvarea unor astfel de probleme s-au utilizat instrucţiuni SELECT imbricate care vor fi prezentate în detaliu în cele ce urmează.Instrucţiuni SELECT imbricate

Limbajul SQL oferă posibilitatea construirii unor interogări complexe prin includerea în clauza WHERE a unei instrucţiuni SELECT, a altei instrucţiuni SELECT (numită sub-interogare sau ‘inner’) astfel:

SELECT <lista atribute> FROM <lista relaţii> WHERE <condiţie> (<sub-interogare>)

La rândul ei sub-interogarea poate conţine în clauza WHERE o altă instrucţiune SELECT obţinând astfel o interogare complexă constituită din instrucţiuni SELECT imbricate pe un număr oarecare de nivele. Instrucţiunea SELECT interioară generează valori pentru condiţia de căutare a instrucţiunii SELECT exterioare care o conţine (numită şi „outer”). O sub-interogare poate returna o singură valoare, sau poate returna mai multe valori.

În ce priveşte ordinea de evaluare a interogărilor pot exista : sub-interogări simple - în care interogarea interioară este evaluată prima,

independent de interogarea exterioară, iar rezultatul interogării interioare este utilizat de interogarea exterioară;

sub-interogări corelate - în care interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară, care în baza valorii primite, parcurge tuplele relaţiei şi transmite interogării exterioare rezultatul obţinut. Astfel de interogări realizează corelarea unei relaţii cu ea însăşi şi sunt cele mai performante.

Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm următoarea interogare:

SELECT A.CodP,A.Cant,A.Pret FROM Stocuri AWHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP)

Sub-interogări simple care returnează o singură valoare - pot fi utilizate în interogări imbricate având sintaxa:

SELECT <lista atribute> FROM <lista relaţii>WHERE <atribut> = <

> <=

98

>= !=

(<sub-interogare>)[ORDER BY <atribut[ASC]|DESC,…]

Exemplu:SELECT CodDep,CodP,Cant FROM Stocuri

WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep(afişează produsele pentru care există stocuri peste medie, ordonate pe depozite).

Sub-interogari simple care returneaza mai multe valori pot fi utilizate în interogări imbricate care utilizează în clauza WHERE condiţii care generează o mulţime de valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.Exemplu:

SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM FacturiWHERE Numar IN (SELECT Numar FROM Beneficiari,Comenzi

WHERE Beneficiari.Nume=’Ionescu’ AND Beneficiari.Cod_B=Comenzi.Cod_B))Predicatul ANY poate fi utilizat în combinaţie cu oricare din operatorii <, >, =, <=,

>=, != şi permite verificarea dacă valoarea unui atribut satisface condiţia precizată pentru orice valoare din lista rezultată din subinterogare.

SELECT CodP FROM Stocuri WHERE Cant > ANY(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)

Predicatul ALL returnează toate tuplele pentru care valorile atributului din clauza WHERE sunt <, >, <=, >= decât toate valorile generate de interogarea interioară (acest predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal în care toate interogările din listă sunt egale).Exemplu:

SELECT * FROM Stocuri WHERE Cant < ALL(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)

Predicatul EXISTS verifică dacă pentru fiecare tuplă a relaţiei există tuple care satisfac condiţia din interogarea interioară (deci EXISTS permite specificarea mai multor atribute în interogarea interioară). Astfel spre exemplu instrucţiunea:

SELECT * FROM Produse A WHERE NOT EXISTS(SELECT * FROM Stocuri B WHERE B.CodP=A.CodP)

va returna o listă de produse care nu au nici o înregistrare în Stocuri.Aplicaţie practică

Se consideră baza de date Furnizori_Clienţi_Stocuri care conţine următoarele tabele (în ACCESS):PRODUSE (catalog de produse)

Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodp Cod produs Number, Integer 4 Cheie primarăDenp Denumire produs Text 20Desp Descriere produs Hyperlink Referă document

corespunzător

99

STOCURI (stocurile de produse pe depozite)Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodp Cod produs Number, Integer

Lookup Wizard4 Lookup Wizard cu

tabela PRODUSECodDep Cod depozit Text 2Ump Unitate de

măsură produsLookup Wizard 8 Creare şi utilizare

listă de valoriCant Cantitate Number, Integer 4Pret Preţ unitar Number,

LongInteger8

FURNIZORI (catalog de furnizori)

Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodf Cod furnizor Number, Integer 4 Cheie primarăDenf Denumire

furnizorText 30

Adresaf Adresa furnizor Text 25

CLIENTI (catalog de clienţi)

Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodc Cod client Number, Integer 4 Cheie primarăDenc Denumire client Text 30Adresac Adresa client Text 25

OFERTE (oferte de produse de la furnizori)

Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodf Cod furnizor Number, Integer

Lookup Wizard4 Lookup Wizard cu

tabela FURNIZORICodp Cod produs Number, Integer

Lookup Wizard4 Lookup Wizard cu

tabela PRODUSEUmp Unitate de

măsură produsLookup Wizard 8 Creare şi utilizare

listă de valoriPret Preţ unitar Number,

LongInteger8

Datao Data ofertei Date 8Oferta Oferta furnizor Hyperlink Referă document

corespunzător

VANZARI (vânzările de produse pe clienţi)

Câmp Semnificaţie Tip dată Dimensiune ObservaţiiCodc Cod furnizor Number, Integer 4 Lookup Wizard cu

100

Lookup Wizard tabela CLIENTICodp Cod produs Number, Integer

Lookup Wizard4 Lookup Wizard cu

tabela PRODU,03SE

Ump Unitate de măsură produs

Lookup Wizard 8 Creare şi utilizare listă de valori

Cant Cantitate Number, Integer 4Pret Preţ unitar Number,

LongInteger8

Să se scrie comenzile SQL pentru realizarea interogărilor de mai jos:

a) Situaţia stocurilorb)

Situaţia ofertelor

Câmp Codf Denf Adresaf Codp Denp Ump Pret DataoTabela Furnizori Furnizori Furnizori Produse Produse Oferte Oferte Oferte

c) Situaţia vânzărilorCâmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare DatavTabela Clienti Clienti Clienti Produse Produse Vanzar

iVanzari

Vanzari

Cant*Pret Vanzari

d) Lista produselor pentru care nu există oferte

Câmp Codp DenpTabela Produse Produse

Câmp CodDep Codp Denp Ump Cant Pret ValoareTabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret

101

Lista produselor pentru care nu s-au făcut vânzări în perioada [Data1,Data2]

Răspuns:a)

SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS ValoareFROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp

b)SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao

FROM Oferte, Produse,FurnizoriWHERE Oferte.Codp = Produse.Codp AND Oferte.Codf = Furizori.Codf

c)SELECT Vanzari.Codc, Denc, Adresac, Vanzari.Codp, Denp, Ump,Cant, Pret,

Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,ClientiWHERE Vanzari.Codp = Produse.Codp AND Vanzari.Codc = Clienti.Codc

d)SELECT * FROM Produse WHERE NOT EXISTS

(SELECT * FROM Oferte WHERE Produse.Codp=Oferte.Codp)e)

SELECT * FROM Produse WHERE NOT EXISTS(SELECT * FROM Vanzari WHERE Produse.Codp=Vanzari.Codp

AND Datav BETWEEN Data1 AND Data2)

5.2. Proiectarea programelor şi a procedurilorProiectantul de soft are ca principală misiune definirea şi structurarea

componentelor care vor forma un tot unitar, astfel încât prin acestea să se obţină un proiect soft operaţional. Proiectantul va grupa funcţiile ce trebuie să fie interconectate şi va descrie modalităţile de realizare a legăturilor. După proiectanţii de soft vor interveni programatorii, pentru transpunerea în realitate a proiectului. Ei vor controla intrările, prelucrările şi ieşirile din sistem prin intermediul programelor.

Softul are două componente de bază instrucţiunile şi modulele. Instrucţiunile sunt operaţiuni elementare executate de calculator prin gruparea şi selecţia controlată a acestora pentru atingerea obiectivelor funcţiilor de prelucrare orientate pe probleme. Instrucţiunile constituie cel mai jos nivel al operaţiunilor ce pot fi executate de către un limbaj de programare. Blocurile de instrucţiuni sunt astfel grupate încât să constituie anumite structuri executabile de calculator. De modul în care sunt grupate instrucţiunile pentru a da naştere unor structuri standard ale programelor, de relaţiile dintre instrucţiuni, de aranjamentul acestora depinde calitatea softului proiectat.

Modulul – este o colecţie sau o formă grupată de instrucţiuni de programe sursă. Modulele se pot grupa pentru a forma programele.

Câmp Codp DenpTabela Produse Produse

102

Programul, în concepţia diverşilor autori, are semnificaţii diferite. El este definit ca:

un set de instrucţiuni cu ajutorul cărora se efectuează prelucrări specifice; o entitate ce poate fi executată pe calculator; un mijloc de comunicare cu calculatorul pentru rezolvarea unor probleme; o descriere a unui algoritm şi a datelor asociate în vederea execuţiei pe

calculator, deci o reprezentare a acestora (algoritmi şi date) ţinând cont de restricţiile impuse de calculator;

o realizare a unei funcţii f care, dată fiind o mulţime de date x, specifică valoarea y=f(x);

Prin algoritm se înţelege o metodă de soluţionare a unei clase de probleme, reprezentată de o succesiune finită de operaţii bine definite, numite instrucţiuni.

Prin prisma complexităţii lor programele se pot clasifica în [46]: programe simple (1000 de linii) programe de complexitate medie(10 000 de linii) programe complexe (peste 100 000 de linii) au numeroase module cu legături

complexe.Pentru ca programele să fie caracterizate prin eficienţă, fiabilitate, flexibilitate,

inteligibilitate, în procesul elaborării lor trebuie să se respecte anumite principii [46]: principiul conformării, potrivit căruia programele trebuie să fie elaborate în

conformitate cu cerinţele utilizatorului; principiul completitudinii constă în realizarea descrierilor complete ale

obiectivelor programului pe toate nivelurile ierarhice de descompunere; principiul abstractizării se referă la elaborarea funcţiei programului, ţinând cont

de elementele esenţiale, făcându-se abstracţie de detaliile nesemnificative; principiul modularizării constă în descompunerea programelor în subdiviziuni

logice (module), care vor fi analizate în procesul de concepere şi elaborare a programelor.

În timp s-au conturat mai multe metode sau tehnici de programare prezentate sumar în cele ce urmează..

Metoda programării clasice are la bază construirea monolitică a logicii programului, fără intenţii de structurare. Programul este privit în totalitatea lui şi analizat direct la nivelul operaţiilor elementare pe care le implică executarea lucrării care se elaborează .

Programarea modulară constă în descompunerea programului, chiar din faza de proiectare, în module uşor de întrebuinţat. Fiecare modul este apoi analizat ca un program distinct şi rezolvat ca atare [46].

Metoda programării structurate constă în faptul că oferă o rezolvare standardizată şi structurată, în mod unitar, a programelor, reprezentând o ridicare a activităţii de programare la nivelul activităţii industriale, fundamentată pe o metodologie ştiinţifică. Programarea structurată este caracteristică dezvoltării sistemelor pe baza diagramelor fluxului de date şi utilizează limbaje structurate. Ea presupune o separare între structurile de date şi codul funcţiilor care le prelucrează.

103

Metoda programării orientate-obiect - constă în abordarea naturală a lumii reale, folosind componente modularizate şi eliminând restricţiile impuse de mediul de programare. Se definesc concepte noi de tip, clasă, moştenire, etc [Udrică M., 2000].

5.2.1. Atributele modulelorLa nivelul softului proiectat, componenta de bază este modulul. El este o colecţie

sau o formă grupată de instrucţiuni ale programului sursă. La rândul lor, modulele se pot grupa pentru a forma programe.

Modulele programelor au următoarele caracteristici [46]:Un modul este format dintr-un grup de instrucţiuni care sunt contigue din punct de vedere fizic şi sunt executate ca o unitate distinctă;Grupurile de instrucţiuni care formează un modul au începuturi şi sfârşituri bine definite;În majoritatea cazurilor, grupul de instrucţiuni are doar un punct de intrare şi unul de ieşire;Un modul poate fi un program sau un subprogram distinct compilat sau o procedură internă a unui program.

Un modul are trei componente de bază: funcţia, logica şi interfeţele.Funcţia unui modul constă în transformarea datelor prin procesul de execuţie a

acestuia. Funcţia este tratată în regimul cutiilor negre, ea fiind văzută la nivel de modul doar prin ceea ce se percepe în exteriorul lui, nu privindu-i componentele interne sau, altfel spus, rolul acestora. Interes prezintă doar intrările şi ieşirile modulului respectiv [46].

La nivelul softului, referirea la un modul este în acelaşi timp o referire la funcţia lui. La nivelul cel mai de sus, modulele au funcţii orientate spre problema de rezolvat, în timp ce modulele aflate pe nivelurile mai de jos au funcţii orientate spre prelucrările pe care le realizează.

În diagrama de structură, folosită pentru reprezentarea grafică a proiectelor soft, un modul este reprezentat printr-o casetă (dreptunghi) ce poartă denumirea funcţiei îndeplinite.

La atribuirea numelui unui modul trebuie să se ţină cont de faptul că acesta trebuie să surprindă atât funcţia proprie, cât şi pe cele ale subcomponentelor de ordin inferior. Se recomandă [46] evitarea conjuncţiilor din structura numelor, deoarece ele ar sugera necesitatea folosirii mai multor module.

Logica modulului descrie prelucrările care au loc în interiorul acestuia [46].La nivelul programării, preocuparea este, în esenţă, legată de logica modulului,

algoritmii de prelucrare, redaţi sub diverse forme – scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinaţii ale acestora – sunt concepuţi pentru prezentarea modului de transformare a intrărilor în ieşiri. Paşii algoritmilor se vor transforma în instrucţiuni ale limbajelor de programare.

Interfeţele sunt conexiuni sau cuplaje între module. Interfeţele modulelor sunt utilizate pentru stabilirea căilor prin care să se transfere controlul de la un modul la altul [46].

104

Conexiunile dintre module se înregistrează pe două planuri: al transferării controlului de la un modul la altul; al transmiterii datelor de la un modul la altul.În concluzie, se poate spune că eficienţa proiectelor – soft depinde în mare măsură

de eficienţa cu care se transferă controlul între module, precum şi de metoda folosită pentru transmiterea datelor între module.

5.2.2. Structurile de control ale programelorProiectul soft trebuie să fie văzut [46] din două puncte de vedere: logic şi fizic.Din punct de vedere logic, modalitatea în care intră în funcţiune modulele este

redată prin structura ierarhică a lor.Din punct de vedere fizic, după ce s-a stabilit structura logică, se va pune problema

adaptării prelucrării lor pe calculator, moment în care se va avea în vedere structura execuţiei instrucţiunilor, adică a secvenţelor după care se declanşează operaţiunile din interiorul modulelor.

Structurile de control al logicii cunoscute şi sub numele de structuri de control fundamentale, reprezintă un set minim, dar şi necesar, de reguli prin care să se controleze procesul de activare a componentelor de prelucrare dintr-un program sau între modulele acestuia. Structurile sunt: secvenţa, selecţia, iteraţia sau repetiţia. Ele mai sunt cunoscute şi sub numele de structură secvenţială, structură alternativă (simplă şi generalizată şi structură repetitivă (condiţionată anterior sau la început şi condiţionată posterior sau la sfârşit ).

Secvenţa asigură parcurgerea instrucţiunilor în ordinea în care apar. Selecţia defineşte alegerea unui grup de instrucţiuni din două sau mai multe posibile. Iteraţia oferă posibilitatea execuţiei repetate a unui grup de instrucţiuni.

În elaborarea programelor structurate este necesar să se respecte o serie de restricţii, şi anume [46]:

fiecare element (secvenţa, selecţia, iteraţia) are un punct de intrare;fiecare element are un punct de ieşire unic;elementul de iteraţie permite şi o execuţie cu factor de repetiţie zero, adică excluderea elementului respectiv din execuţie.

Fiecare element din cele enunţate (secvenţa, selecţia, iteraţia) care respectă restricţiile de mai sus defineşte un bloc standard şi sunt reprezentate în continuare [46].Structura secvenţială (liniară) se prezintă astfel:

Figura 5.5. Structura secvenţială

105

Selecţia (structura de tip IF-THEN-ELSE) sau structura alternativă are următoarea formă de prezentare:

Figura 5.6. Structura alternativăDacă se îndeplineşte condiţia C, se execută operaţiile din Bloc-1, altfel se execută

operaţiile din Bloc-2. După execuţia blocului, se continuă cu instrucţiunea următoare.Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecţiei.

Ea permite alegerea unei variante din mai multe posibile (figura 5.7).

Figura 5.7. Structura alternativă generalizată

Iteraţia sau structura repetitivă defineşte execuţia repetată a unei operaţii sau grup de operaţii, funcţie de rezultatul evaluării unei condiţii. Evaluarea condiţiei se face fie înainte, fie după executarea operaţiilor.

Structura repetitivă condiţionată anterior (de tip WHILE-DO) este reprezentată în figura 5.8

106

C

Bloc - nBloc - 2Bloc - 1

C

Bloc - 1

DA

NU

Figura 5.8. Structura repetitivă condiţionată anterior

Structura repetitivă condiţionată posterior (de tip DO UNTIL) are forma din figura 5.9.

O formă particulară de structură repetitivă condiţionată posterior este structura repetitivă cu număr definit de paşi (de tip DO FOR). Numărul de repetiţii este controlat de o variabilă, numită variabilă de control. În reprezentarea grafică următoare, V este variabila de control, Vi este valoarea iniţială a variabilei de control, iar R este raţia (incrementul). O astfel de structură este redată în figura 5.10.

107

C

Bloc - 1

DA

NU

Figura 5.9. Structura condiţionată posterior

V>Vf

V=Vi+R

DA

NU

Bloc - 1

V=Vi

Figura 5.10. Structura repetitivă cu număr definit de paşi

În literatura de specialitate, se consideră că structura secvenţială, structura alternativă de tip IF-THEN-ELSE şi structura repetitivă condiţionată anterior sunt suficiente pentru a defini structura de control a oricărui program. Din acest motiv, cele trei structuri de control, enumerate mai sus, sunt numite structuri de control fundamentale sau structuri de bază.

5.2.3. Proiectarea şi realizarea programelor Ideea de bază în proiectarea programelor constă în faptul că acesta trebuie să

respecte întocmai structurile diagramelor fluxurilor de date, prin nivelurile arhitecturale de tip program.

Pentru proiectarea programelor, programatorii vor respecta sistemul de cerinţe şi restricţii impus de etapele parcurse anterior pentru realizarea sistemului informatic. Urmând principiile programării structurate, realizarea programelor se face în următoarele faze [11]: definirea problemei de programat; descompunerea problemei de programat; realizarea modulară a produselor program; testarea “top-down” a produselor program; definirea programului testat şi a documentaţiei aferente; dezvoltarea versiunii calitative a produsului program.

Specificaţiile elaborate în etapele precedente permit definirea problemei de programat prin care se formulează elementele specifice şi se analizează relaţiile dintre aceste elemente, din punct de vedere dinamic sau static.

Descompunerea aplicaţiei se poate face după criteriul funcţionalităţii, motiv pentru care elementele rezultate se mai numesc şi module funcţionale. Din punct de vedere al fluxului datelor pot fi [11]:

– module de intrare, care manipulează datele de intrare; – modulele de ieşire, care furnizează rezultate ale prelucrărilor; – module de prelucrare, care efectuează diverse operaţii asupra datelor. Pe baza unor funcţiuni identificate sau a altor raţiuni de programare, modulele pot

fi divizate în continuare. Scopul acestei structurări funcţionale până la nivel elementar este de a identifica funcţiunile sistemului şi de a le separa, eventual, în funcţiuni generale şi cu caracter specific aplicaţiei.

Modulele funcţionale pot fi descompuse apoi după criteriul omogenităţii, rezultând modulele operaţionale.

Realizarea modulară a produselor program presupune următoarele acţiuni [11]:

108

Examinarea modulelor şi specificarea succesiunii operaţiilor de prelucrare descrise în acestea.

Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere întreaga cazuistică a sistemului informaţional şi să testeze toate ramurile programului.

Precizarea elementelor de comunicaţie între module, respectiv stabilirea parametrilor de intrare/iesire în/din fiecare modul.

elaborarea algoritmii de prelucrare specifici fiecărui modul şi structura programelor.

transcrierea algoritmilor într-un limbaj de programare. scrierea codului sursă şi obţinerea fişierelor executabile.Prin compararea rezultatelor propuse a fi obţinute cu cele efectiv furnizate de

aplicaţia informatică, sunt verificate sintactic şi funcţional module din program. Dacă se realizează identitatea între cele doua categorii de rezultate, operaţia de testare se consideră încheiată.

O atenţie deosebită trebuie acordată întocmirii documentaţiei programului cu observaţia că în acest sens este recomandată autodocumentarea la nivel de modul.

5.3. Proiectarea sistemelor distribuiteUn sistem de prelucrare distribuită a datelor presupune existenţa a două sau mai

multor sisteme independente de prelucrare a datelor, numire noduri, interconectate într-o configuraţie de reţea. Ele folosesc facilităţi de comunicare pentru schimbul de informaţii şi îşi coordonează activităţile pentru realizarea unui anumit scop. Un sistem de prelucrare distribuită a datelor permite realizarea activităţii de prelucrare automată a datelor în cadrul unei reţele de calculatoare. Într-un astfel de mediu, cooperează trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor şi reţeaua de calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel încât să se realizeze obiectivele comune ale organizaţiei [46].

Sistemele de prelucrare distribuită a datelor trebuie să permită: posibilitatea de prelucrare independentă; o configuraţie de reţea; o posibilitate de transfer a datelor folosind facilităţi de partajare a datelor; un obiectiv comun de realizat.La proiectarea unui sistem nou trebuie să se definească clar obiectivele pe care

trebuie să le îndeplinească noul sistem. Aceste obiective pot fi clasificate în financiare şi funcţionale. Din punct de vedere financiar se urmăreşte maxim de profit cu minimum de

109

NOD NODLegătură/canal

Figura 5.11. Model de bază al unui sistem de prelucrare distribuită a datelor.

cheltuieli, iar din punct de vedere funcţional se urmăreşte realizarea unui sistem performant.

Costul sistemului se regăseşte în costurile iniţiale pe procesoare, periferice (imprimantă, scanner, etc), cablări, soft-uri, şi costuri funcţionale (operaţionale) cu distribuirea datelor, cu personalul, întreţinerea sistemului, etc.

Performanţa sistemului este apreciată prin prisma productivităţii şi a eficienţei lui. Ea se determină în funcţie de cerinţele operaţionale ale unui sistem de calcul. Se consideră că performanţa este o funcţie a [46]:

timpului de răspuns(intervalul de timp dintre momentul formulării unei cereri de la un terminal de comunicaţie-date şi obţinerea răspunsului în acelaşi loc);

randamentului(cantitatea de date ce poate fi prelucrată de către un sistem de calcul într-o perioadă de timp);

calităţii serviciilor oferite utilizatorilor(siguranţă, fidelitate, integrare, control şi acceptabilitate);

nivelul serviciilor.Sistemul propus trebuie să fie fezabil, din punct de vedere tehnic, şi eficient, prin

prisma costurilor prelucrării automate a datelor şi a comunicaţiilor din sistem. Performanţele sistemului sunt influenţate de mai mulţi factori, cum ar fi timpul de răspuns, randamentul, disponibilitatea, siguranţa(securitatea sistemului).

La proiectarea sistemelor distribuite trebuie avute în vedere două componente majore:

Proiectarea nodurilor; Proiectarea reţelei de comunicaţii.Ordinea de proiectare nu este strictă rămânând la latitudinea echipei de proiectare.

Figura 5.12. Principalele module de proiectare a sistemelor de prelucrare distribuită a datelor

Modele de sisteme distribuite

110

Calculatoarele personale şi staţiile de lucru pot fi utilizate fie ca sisteme de-sine-stătătoare pentru execuţia diferitelor aplicaţii informatice, fie într-o configuraţie de reţea. O reţea locală se bazează pe un set de calculatoare personale, fiecare cu propria memorie, astfel încât să poată folosi în comun toate echipamentele şi software-ul din reţea. Dintre toate calculatoarele, există unul sau unele mai puternice pe care se vor afla aplicaţii folosite în comun de celelalte calculatoare ale reţelei. Cea mai utilizată arhitectură este arhitectura client/server.

Arhitectura client/serverModelul Client /Server oferă date distribuite, portabilitate între platforme şi un

acces standardizat la resurse. Termenul de Client /Server provine de la metoda tradiţională de accesare a unui computer central numit server de către computere aflate la distanţă sau clienţi într-o infrastructură de reţea.

Modelul Client /Server implică o entitate software (clientul) care efectuează cereri, acestea fiind îndeplinite de o altă entitate software(serverul) . Clientul este cel care transmite o cerere severului, acesta o interpretează şi apoi o efectuează. Pentru a putea îndeplini cererea, serverul poate referi o sursă de informaţie (baze de date), să efectueze procesări asupra datelor, să controleze periferice sau să efectueze cereri adiţionale altor servere. Un client poate face cereri la multiple servere şi un server poate deservi mai mulţi clienţi.

Sursă de informaţie (Bază de date)Cerere Procesare (Logică şi Aritmetică)

Client Server Dispozitive (Imprimantă, periferice partajate)

Rezultatul Servicii(Cereri adiţionale altor servere)

îndeplinirii cererii

Figura 5.13. O tranzacţie Client /Server.

Se poate afirma că tehnologia client / server împarte o aplicaţie în trei componente de bază: un client, un server şi o reţea care conectează clientul la server. Atât clientul cât şi serverul sunt calculatoare cu grade variate de putere de calcul, ce colaborează la îndeplinirea sarcinilor.

Calculatorul server este responsabil cu administrarea accesului la baza de date, precum şi cu alte sarcini care-i revin direct serverului. Când se alege un server pentru mediul de lucru client / server trebuie avute în vedere: scalabilitatea – posibilitatea de creştere a capacităţii serverului, în limite rezonabile; toleranţa la erori – posibilitatea de recuperare a contextului calculatorului server după producerea unei disfuncţionalităţi hardware; service şi asistenţă tehnică. Calculatoarele server au utilizări variate în sistemele client / server (există servere de fişiere care asigură spaţiul de disc centralizat care poate fi folosit conform necesităţilor calculatoarelor client din reţea; servere de

111

tipărire – care colectează informaţiile ce urmează a fi trimise către imprimantă de către calculatoarele client şi le asigură tipărirea într-o anumită ordine; servere de baze de date – calculatoare care rulează un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL; serverele de aplicaţii – calculatoare server care rulează programe de aplicaţii).

Sistemele client-server au apărut ca urmare a descentralizării activităţii din diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două nivele: client, server. De obicei clienţii reprezintă utilizatorii finali care vor comunica cu serverul bazei de date în cadrul unei reţele de calculatoare. După rolul pe care îl are fiecare din componentele client, server, se pot distinge trei arhitecturi de bază pentru un sistem client-server (Loomis 1992) şi anume:

arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele două componente (server, client). Serverul este responsabil de administrarea memoriei şi zăvoarelor, efectuarea operaţiilor în memoria secundară, securitatea, integritatea şi recuperarea bazei de date, executarea procedurilor stocate şi optimizarea interogărilor. Clientul este responsabil de administrarea tranzacţiilor şi realizarea interfeţei cu limbajul de programare;

arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este realizată de către client. Serverul este responsabil de memoria secundară şi furnizează paginile corespunzător cererilor formulate de client;

arhitectura de tip server de bază de date – cea mai mare parte din prelucrările bazei de date este efectuată de către server. Clientul transmite cererea serverului, primeşte rezultatele şi le transmite aplicaţiei. Este modul utilizat frecvent de către sistemele relaţionale.

În fiecare dintre cele trei cazuri serverul se găseşte pe aceeaşi maşină ca şi baza de date fizică. Clientul se poate afla pe aceeaşi maşină sau pe una diferită. În cazul bazelor de date distribuite pe mai multe maşini, clientul va comunica cu câte un server de pe fiecare maşină. De asemenea mai mulţi clienţi pot comunica concomitent cu acelaşi server (accesul concurent).

Arhitectura tradiţională a sistemelor client-server este o arhitectură pe două nivele (etaje), în care la primul nivel (clientul) se realizează interfaţa cu utilizatorul şi logica principală a aplicaţiei, iar la al doilea nivel (serverul) se realizează validarea datelor şi accesul la baza de date. Necesitatea rezolvării unor probleme complexe care presupun accesul la baza de date a unui număr mare de utilizatori, utilizarea unor platforme hard-soft diferite, precum şi integrarea bazelor de date în mediul Web, au impus definirea unei noi arhitecturi client-server în care sunt definite trei nivele şi anume:

nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei; nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării

datelor; nivelul server de baze de date, la care se realizează validarea datelor şi accesul

la baza de date.Un server de aplicaţie poate servi mai mulţi clienţi, fiind conectat fizic atât la

nivelul client cât şi la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate fi un browser Web, iar serverul de aplicaţie poate fi un server Web.

112

Teste rezolvate

1. Proiectarea fizică a sistemelor informatice înseamnă:a) o abordare detaliată a sistemului;b) o abordare de ansamblu a sistemului;c) o abordare generală a sistemului;

Răspuns : a2. Proiectarea fizică a sistemelor informatice implică:

a) proiectarea fizică a bazelor de date şi a fişierelor.b) proiectarea structurii sistemului şi a programelor.c) proiectarea documentaţiei sistemului analizat.d) proiectarea strategiilor de prelucrare distribuită.

Răspuns : a, b, d3. Proiectarea fizică a bazelor de date şi a fişierelor îşi propune să asigure:

a) trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor;b) structura globală de organizare a datelor;c) descrierea logică a datelor.

Răspuns : a4. Sunt structuri de control fundamentale în realizarea programelor:

a) structura secvenţială;b) structură funcţională;c) structura alternativă;d) structura organizaţională:e) structura repetitivă.

Răspuns : a, c, e5. Structura repetitivă de bază condiţionată anterior este:

a) de tip WHILE-DO;b) de tip DO UNTIL;c) de tip DO FOR.

Răspuns : a6. Nu sunt metode de programare:

a) metoda programării clasice;b) metoda programării structurate;c) metoda programării orientate-obiect;d) metoda programării iterative.

Răspuns : d7. Un modul are componente de bază:

a) funcţia;b) schema;c) logica;d) interfeţele.

Răspuns : a, c, d

113

8. Funcţia unui modul constă în:a) transformarea datelor prin procesul de execuţie a acestuia.b) descrierea prelucrărilor care au loc în interiorul acestuia.c) legătura cu alte module.

Răspuns : a9. Realizarea modulară a programelor corespunde principiilor:

a) programării clasice;b) programării structurate;c) bazelor de cunoştinţe;

Răspuns : b10. Principalele module de proiectare a sistemelor de prelucrare distribuită a datelor sunt:

a) proiectarea nodurilor;b) proiectarea diagramelor;c) proiectarea reţelei de comunicaţii.

Răspuns : a, c11. Nu sunt componente de bază ale tehnologiei client/server:

a) clientul; b) administratorul de sistem;c) serverul; d) reţeaua care conectează clientul la server.

Răspuns : b12. Care dintre următoarele instrucţiuni nu sunt decizionale ?

a) WHILE ... WEND ;b) IF...END IF;c) IF...ELSE...END IF;d) IF...THEN...ELSE IF... ... ...END IF ;e) SELECT CASE...CASE... ... ...END SELECT.

Răspuns : a13. Care dintre următoarele instrucţiuni repetitive sunt condiţionate posterior ?

a) FOR...NEXT ;b) WHILE...WEND ;c) DO WHILE...LOOP;d) DO UNTIL...LOOP;e) DO...LOOP WHILE.

Răspuns : e14. Proiectarea fizică a bazei de date are în vedere:

a) modul de stocare a datelor pe suportul de memorare;b) trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor;c) structura globală de organizare a datelor.

Răspuns: a), b)15. Sistemul de Gestiune a Bazelor de Date este:

a) un sistem de programe care permite definirea, crearea şi întreţinerea bazei de date precum şi accesul controlat la baza de date;

b) un sistem de programe pentru interogarea bazei de date.Răspuns: a)

114

Întrebări şi răspunsuri

1. Enumeraţi arhitecturile de bază pentru un sistem client-server după rolul pecare îl au componentele client şi server;

Răspuns: arhitectura de tip server de obiecte; arhitectura de tip server de pagini; arhitectura de tip server de bază de date.

2. Enumeraţi cele 3 nivele ale noii arhitecturi client-server definite ca urmare a utilizării a unor platforme hard-soft diferite, precum şi integrării bazelor de date în mediul Web:

Răspuns: nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei; nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării

datelor; nivelul server de baze de date, la care se realizează validarea datelor şi accesul

la baza de date.

115

Capitolul 6. Instrumente CASE

În general, un instrument CASE (Computer Aided Systems/Software Engineering) este un pachet software care oferă suport în proiectarea şi implementarea sistemelor informatice. Prin integrarea numeroaselor tehnici utilizate în pregătirea proiectării unui sistem, incluzând aici dicţionarul datelor, fluxul de date, relaţiile între entităţi, un software de tip CASE poate determina o creştere a gradului de corectitudine cu care se realizează proiectarea unei baze de date.

Altfel spus, termenul CASE se referă la totalitatea instrumentelor şi metodelor destinate ingineriei software asistată de calculator. Aceste produse software asigură suport în etapa de analiză şi de proiectare facilitând reprezentarea grafică în cadrul acestor etape.

Deşi instrumentele CASE sunt numite uneori generic „instrumente de modelare ER” ceea ce ar însemna că pot doar să creeze modelul logic, în realitate un instrument de tip CASE are mult mai multe facilităţi. Un instrument CASE realizează în primul rând legătura între modelul utilizator şi modelul logic ce formalizează modelul utilizator folosind un mod de reprezentare comun atât acestuia cât şi proiectantului bazei de date.

Un instrument de tip CASE nu elimină însă posibilitatea ca modelul final obţinut să fie proiectat greşit. În scopul evitării acestei situaţii este necesară o pregătire de durată a utilizatorului. Dacă acesta are experienţă în lucrul cu instrumente CASE, utilizarea unui produs nou este facilă deoarece toate instrumentele de modelare se bazează pe aceleaşi principii şi au relativ aceleaşi facilităţi. Dacă însă utilizatorul este „nou” în domeniu, trebuie luat în considerare timpul necesar realizării unui model şi timpul necesar verificării acestuia de către o persoană cu experienţă.

Problema CASE-ului (Proiectarea Sistemelor/Programelor asistată de calculator sau cu Ajutorul Calculatorului – Computer Aided Systems/Software Engineering) a devenit foarte importantă la mijlocul anilor 1980, când hardul sa extins prin seria PC-urilor, iar reţelele au devenit mai puternice, constituindu-se sistemele distribuite. Obiectivul principal al CASE-ului îl constituie punerea în practică a produselor-program de proiectare şi realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinţelor până la întreţinerea fizică a produsului informatic. Totuşi, analiza şi proiectarea, bazate pe conceptele şi metodele structurate, reprezintă elementele forte ale instrumentelor CASE, iar în ultimii ani CASE a acordat atenţia cuvenită analizei, proiectării şi programării orientate pe obiecte [46].

Majoritatea produselor soft au fost construite în mod artizanal, fără posibilitatea testării complete a lor, fiind însoţite de o documentaţie destul de slabă. Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susţinere a activităţilor de planificare, definire, proiectare şi realizare a softului. Ele se bazează pe logica structurală, pe descompunerea funcţională şi reprezentarea prin diagrame a fluxurilor de date ale aplicaţiilor.

Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a încuraja abordarea logicii structurate şi pentru folosirea calculatorului ca un mod de tezaurizare a lucrărilor şi ca o planşetă de desen, pe care pot fi plasate reprezentările structurate ale

116

sistemelor sau aplicaţiilor. Pe măsura evoluţiei lor, sistemele CASE au devenit mult mai complexe, permiţând ca procesele de proiectare şi realizare a aplicaţiilor să se desfăşoare într-un mediu informatic interactiv, oferind utilizatorilor un întreg arsenal de instrumente şi proceduri, prin care pot proiecta, realiza, testa, documenta, întreţine/actualiza şi exploata sistemul.

Utilizarea produselor de tip CASE a fost determinată de [46]: calitatea îndoielnică a aplicaţiilor realizate în mod tradiţional; frustrarea utilizatorilor în încercarea lor de a participa la procesul de proiectare

şi realizare a aplicaţiilor, datorită nivelului ridicat de cunoştinţe informatice solicitate de metodele tradiţionale;

costuri deosebit de mari pe care le presupun întreţinerea şi actualizarea softului funcţional;

imposibilitatea rezolvării tuturor cerinţelor utilizatorilor; limitarea posibilităţii de reprezentare grafică a schemelor de realizare a noilor

proiecte.Folosirea sistemelor CASE este motivată şi de următoarele avantaje: reducerea complexităţii logicii de descriere a sistemului; posibilitatea de a alege dintre mai multe variante de proiectare; creşterea vitezei de realizare a sistemelor; realizarea succesivă a componentelor unui sistem; creşterea integrării; consolidarea disciplinei de proiectare; oferirea unei interfeţe de proiectare; folosirea depozitelor modularizate; salvarea şi refolosirea unor componente din diagramele realizate; simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de

date, care fac posibilă realizarea unui model al derulării proceselor sistemului/aplicaţiei care se proiectează. A urmat folosirea dicţionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaţia. Au apărut ecranele predefinite pentru a prezenta ce poate să obţină utilizatorul prin exploatarea sistemului. S-a apelat la facilităţile grafice, care pot folosi simbolurile logicii structurate şi care permit proiectantului să realizeze o diagramă coerentă a fluxurilor de date.

6.1. Funcţiile CASEPrimele sisteme CASE erau un set de aplicaţii neintegrate, cu funcţii distincte, fără

a fi interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generaţiile actuale, care încearcă să realizeze o integrare completă şi uşoară a tuturor elementelor, integrarea reprezentând, de fapt, factorul cel mai important al metodologiei CASE.

CASE se bazează pe două funcţii fundamentale [46].Prima funcţie constă în posibilitatea descompunerii de sus în jos (top-down) a

sistemului informatic în procese şi module distincte, fiecare având definite responsabilităţile funcţionale şi/sau operaţionale.

117

Cea de-a doua funcţie se referă la faptul că sistemele informaţionale pot fi reprezentate într-o formă grafică concisă, folosind câteva simboluri de bază. Importanţa acestor două funcţii rezidă în posibilitatea utilizării modularităţii aplicaţiilor, a diagramelor, obţinerea unei documentaţii privind realizarea, evaluarea arhitecturii şi utilizarea sistemului.

Pentru definirea şi construirea sistemelor, produsele CASE presupun stabilirea şi respectarea unei anumite discipline. Metodologia oferă o interfaţă între crearea şi verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentaţii, care include şi integrează caracteristicile proceselor şi paşii de parcurs, pentru descrierea modului de lucru; oferă un model al produsului final, ce poate fi folosit în realizarea operaţiilor de exploatare şi întreţinere a sistemului/aplicaţiei, şi oferă o interfaţă pentru păstrarea evoluţiei proiectului.

Folosirea reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii aplicaţiei în mai multe componente logice. Prin ataşarea unei baze de date la elementele grafice, se va obţine un depozit ce va conţine paşii şi funcţiile reprezentate în diagramele construite. Dacă aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare ale sistemului/aplicaţiei. Modelarea grafică în sistemele CASE prezintă o interactivitate ridicată, permiţând construirea diagramelor, deplasarea de la o diagramă la alta, modificarea, extinderea, copierea, evaluarea şi descrierea elementelor unei aplicaţii.

Modelele grafice permit conectarea fluxurilor logice între activităţile şi funcţiile specifice aplicaţiei, relaţii care pot fi testate şi validate în mod automat.

6.2. Trăsături definitorii ale CASE-uluiEvoluţia instrumentelor CASE a determinat apariţia I-CASE (Integrated CASE)

care se referă la toate aspectele integrării, chiar dacă sistemele sunt deschise sau nu.Caracteristicile mediilor moderne de tip CASE [46]: un set de instrumente specifice pentru realizarea sistemelor; diversitatea modurilor de interacţiune; semnificaţia reprezentărilor grafice; elemente de tip verificare şi validare (V&V); natura bidirecţională, deplasări pe verticală în structura sistemului; deschidere pentru interconectarea instrumentelor CASE; sprijin pentru lucrul cu utilizatori multipli; descompunerea; performanţe de deplasare, pe orizontală, de la un instrument la altul; grade diferite de automatizare; integrarea.CASE-ul nu este un proces independent. El constituie un set integrat de

metodologii, care urmăresc realizarea ciclului de viaţă al unui sistem. La sfârşitul fiecărei faze a ciclului de viaţă, rezultatele obţinute trebuie supuse unei analize şi verificări, iar utilizatorii trebuie informaţi asupra modului de gestionare a procedurilor de lucru. Ei sunt cei care trebuie să dea avizul de continuare a parcurgerii fazelor următoare, pe baza a ceea

118

ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite în proiectarea sistemului şi a modelului proiectat pe măsura desfăşurării operaţiunilor, din faza de proiectare până la predarea produsului final. CASE poate sprijini aceste proceduri prin punerea la dispoziţie a unei documentaţii a modelului proiectat. Pe acest fond, pot fi făcute evaluări, critici sau modificări asupra elementelor din modelul proiectat. Rezultatele obţinute în urma proiectării unui anumit model de sistem constau în documentaţia oferită, care acoperă întregul ciclul de viaţă al sistemului, cu toate operaţiile şi procedurile pe care le presupune. În plus, CASE oferă posibilitatea de a analiza ieşirile obţinute şi de a le modifica pentru a reflecta schimbările intervenite în sistem, modulele definite şi depozitul de date.

6.3. Tipuri de instrumente CASE [72]În literatura de specialitate, instrumentele CASE sunt clasificate şi după un alt

criteriu decât cel al activităţilor din ciclul de viaţă al sistemelor pe care le sprijină. Acest criteriu se referă la metodologia pe care o încorporează pentru realizarea sistemelor. Astfel, se întâlnesc următoarele trei categorii:

instrumente CASE bazate pe metodologia structurată; instrumente hibride, ce conţin elemente specifice orientării-obiect, dar care nu

permit realizarea sistemelor orientate-obiect; instrumente pur orientate-obiect.În cele ce urmează se vor prezenta câteva exemple de CASE folosite de cele mai

utilizate metodologii de analiză şi proiectare, respectiv metodologia structurată şi cea orientată pe obiecte.A) Metodologia structurată

Westmount I-CASE Yourdon oferă suport complet pentru realizarea sistemelor informatice. Având la baza metoda structurată propusă de Yourdon, acest instrument CASE integrat oferă posibilitatea lucrului în echipă, posibilitatea de generare şi reutilizare a codului şi generarea automată a documentaţiei de realizare a sistemului informatic.

Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaţional: Informix, Ingres sau Oracle.

Analyst, este componenta ce oferă suport pentru analiza structurată. Metoda este implementată de Yourdon şi De Marco. Westmount I-CASE Yourdon oferă suport pentru un set extins de instrumente şi anume editoare pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structură a datelor editoarele matriciale pentru matricea listei de evenimente.

Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de ansamblu).

Designer este componenta ce oferă suport pentru proiectarea de detaliu a sistemului informatic.

Proiectarea de detaliu a aplicaţiei este strâns legată de proiectarea bazei de date. Pentru modelarea datelor se utilizează diagrama entitate asociere.

119

Programmer este mediul de programare care oferă suport pentru generarea codului sursă, compilare, lansare în execuţie şi testarea aplicaţiei. Generatorul de cod translatează specificaţiile de proiectare în cod sursă. Astfel, pe baza diagramei entitate asociere se generează codul DDL (în SQL) ce defineşte structura fizică a bazei de date. Codul poate fi completat pentru a defini restricţiile de integritate şi modul fizic de stocare a bazei de date. Este prezentată şi facilitatea de inginerie inversată care translatează definirile asociate bazei de date existente într-o diagramă entitate asociere. Codului aplicaţiei este generat în limbajul C îmbogăţit cu instrucţiuni SQL pornind de la specificaţiile din schemele de structură.

Docwriter este componenta care permite generarea documentaţiei pentru fiecare etapă de realizare a sistemului.

Utilizarea produsului Westmount I-CASEY Yourdon îmbunătăţeşte productivitatea realizării sistemelor informatice şi oferă garanţii pentru calitatea sistemelor obţinute.

B) Metodologia orientată-obiectExpresia „pur orientate-obiect" se referă la faptul că pe de o parte, instrumentele

CASE conţin numai elemente specifice abordării orientate-obiect a sistemelor, iar pe de altă parte la faptul că se bazează pe metodele şi tehnicile de analiză şi proiectare orientate-obiect. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de viaţă al sistemelor, pot fi grupate ca şi cele convenţionale, astfel:

- Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor;- Lower CASE orientat-obiect pentru generarea codului-sursă al aplicaţiilor;- I-CASE orientat-obiect care acoperă întregul ciclu de viaţă.Tendinţa de utilizare mai accentuată a tehnologiilor informaţionale orientate-obiect

a condus la apariţia a numeroase produse CASE orientate-obiect sau la reorientarea firmelor producătoare de instrumente convenţionale spre înglobarea în produsele lor a elementelor specifice abordării obiectuale.

6.4. Exemple de instrumente CASEUn posibil dezavantaj al utilizării instrumentelor CASE îl reprezintă costul

acestora. O licenţă pentru All Fusion ERwin Data Modeler costă în jur de 3000$. La momentul actual nu se poate indica exact un anumit produs software ca fiind cel mai bun de pe piaţă. În final nu contează ce produs a fost utilizat atât timp cât modelul obţinut este correct şi poate fi întreţinut cu uşurinţă. Se consideră că un instrument CASE este performant dacă permite forward engineering (capacitatea de a crea baza de date din modelul proiectat), ingineria inversă (crearea modelului având la dispoziţie modelul) şi capturarea metadatelor (posibilitatea de definire a datelor). Se va demonstra această afirmaţie exemplificând cu ajutorul mai multor instrumente, dintre care cel mai performant, conform opiniei generale, este AllFusion Erwin Data Modeler.6.4.1. Erwin Data Modeler

Unul dintre programele intens utilizate în proiectarea CASE a bazelor de date este Erwin care este un instrument de modelare vizuală care permite atât modelarea logică cât şi modelarea fizică. Câteva dintre avantajele utilizării acestui program [17]:

120

- mediu de modelare simplu de utilizat;- este posibilă partajarea şi reutilizarea modelelor odată create;- utilizarea Erwin reduce timpul de proiectare datorită creării automate a

modelului fizic;- îmbunătăţeşte exactitatea modelului datorită posibilităţii de sincronizare a

modelului cu baza de date fizică;- ERwin pune la dispoziţia utilizatorului o facilitate importantă numită forward

engineering care permite conversia diagramei ER în cod SQL corespunzător bazei de date modelate;

- reverse engineering – facilitate care permite crearea unui model pe baza schemei unei baze de date existente în prealabil.

Erwin Data Modeler permite utilizarea modelelor complexe prin împărţirea lor în submodele mai uşor de gestionat. Modelele realizate pot fi vizualizate, modificate şi tipărite la imprimantă în multiple moduri. RPTwin este o componentă înglobată în Erwin care permite realizarea de rapoarte şi conţine un set de rapoarte predefinite şi de asemenea oferă posibilitatea realizării unor rapoarte personalizate.

Fereastra principală Erwin Data Modeler este prezentată în figura 6.1.

Figura 6.1. Fereastra ERwin Data Modeler.În partea superioară a interfeţei utilizator ERwin sunt plasate bara de meniuri şi

bara de instrumente (toolbar) care permit selectarea unor opţiuni din meniuri, respectiv

121

accesarea mai rapidă a unora dintre aceste opţiuni prin apăsarea butoanelor corespunzătoare.

Fereastra de explorare a modelului (Model Explorer Pane) permite, prin intermediul unor elemente grafice, construirea modelului prin inserarea de entităţi, domenii, relaţii, reguli de validare, etc.

AllFusion Erwin Data Modeler suportă trei tipuri de modele pentru proiectarea bazelor de date:

Logic: Model conceptual (global) care include entităţi, relaţii şi atribute, esenţiale obţinerii unui model Entitate –Relaţie.

Fizic: Model detaliat care implică specificarea tabelelor, atributelor şi a tipului de date asociat.

Logic/Fizic: Un model care înglobează atât modelul fizic cât şi modelul logic.

Pentru a crea un model, se alege opţiunea New din meniul File. Fereastra Create Model este prezentată în figura 6.2.

Figura 6.2. Fereastra de creare a unui nou modelAceastă fereastră de dialog permite alegerea tipului modelului (butoanele radio din

partea superioară) şi formatul bazei de date în care va fi exportat modelul creat în Erwin. Se poate alege de asemenea şi un eventual şablon (Template) pentru crearea unui anumit tip de model prin apăsarea butonului Browse File System şi alegerea fişierului respectiv. Formatul bazei de date se alege din secţiunea Target Database. În figura de mai sus s-a ales formatul Acces. Noul model va fi denumit implicit Model_n. Pentru a-l redenumi se

122

execută click dreapta pe numele modelului din fereastra Model Explorer şi se alege opţiunea Properties. Redenumirea se realizează prin introducerea noului nume în câmpul Name, figura 6.3.

Figura 6.3. Redenumirea modeluluiCrearea modelului continuă cu inserarea atributelor. Din fereastra Diagram

Windows se execută dublu click pe entitatea care se va popula cu atribute şi se alege opţiunea New. Se va afişa fereastra din figura 6.4. Se apasă butonul New, apoi se introduce numele atributului şi se selectează tipul acestuia.

Figura 6.4. Fereastra introducere a atributelor.ERwin suportă trei tipuri de relaţii: cu identificare, fără identificare şi many to

many. ERwin clasifică entitatea copil într-o relaţie cu identificare slabă (weak). Pentru adăugarea unei relaţii se execută click dreapta pe elementul Relationship din Model Explorer şi se alege opţiunea New. Se va afişa fereastra din figura 6.5.

123

Figura 6.5. Adăugarea unei relaţii noiO relaţie cu identificare semnifică faptul că una dintre entităţile relaţiei este entitate

dependentă, adică una dintre entităţi este, pentru a se identifica, cel puţin parţial dependentă de cealaltă entitate. Entitatea copil nu se poate identifica fără a se utiliza cel puţin cheia primară a entităţii părinte. Într-o relaţie fără identificare, entitatea copil nu are nevoie pentru identificare de cheia primară a entităţii părinte. Entitatea copil trebuie să conţină însă obligatoriu cheia primară a entităţii părinte. O relaţie de tip fără identificare este simbolizată prin linie punctată.

După alegerea celor două entităţi aflate în relaţie şi apăsarea butonului OK, noua relaţie este adăugată şi este figurată grafic printr-o linie (punctată sau continuă, corespunzătoare tipului relaţiei) ce uneşte cele două entităţi. O relaţiei many to many este simbolizată printr-o linie continuă cu două puncte negre la ambele capete. După crearea relaţiei, utilizatorul poate adăuga o descriere a acesteia prin executarea unui click dreapta pe relaţie şi accesarea opţiunii Properties. În final, după realizarea tuturor operaţiilor se obţine un model fizic ce poate fi ulterior folosit pentru forward engineering, figura 6.6.

Erwin permite, prin intermediul opţiunii Forward Engineering, convertirea diagramei entitate – relaţie în cod SQL, generându-se astfel schema bazei de date. Scriptul SQL din figura 6.7 este obţinut pentru modelul StocProd de gestionare a depozitării şi vânzării produselor în cazul unui hipermarket.

124

Figura 6.6. Model fizic al unei baze de date.

Figura 6.7. Script SQL generat prin forward engineering

6.4.2. Microsoft Visio 2007Microsoft Visio permite crearea unui mare număr de tipuri de diagrame bazate pe

şabloane predefinite, dar oferă şi instrumente CASE pentru proiectarea bazelor de date. Este disponibil în două variante, Standard şi Professional, varianta profesională având

125

capacităţi avansate de Inginerie inversă şi un mai mare număr de şabloane predefinite. De asemenea, varianta Professional permite elaborarea de diagrame specifice limbajului de programare vizuală UML şi transformarea bazelor de date în format UML (Universal Modeling Language) [71].

Fereastra Microsoft Visio Professional este prezentată în figura 6.8.

Figura 6.8. Interfaţa Microsoft Visio 2007.Şabloanele sunt grupate pe categorii şi afişate în banda din partea stângă a ferestrei

aplicaţiei. Procesul de creare a modelului unei baze de date poate începe prin selectarea şablonului corespunzător din categoria Database Model Diagram sau cu importarea unui model deja creat în Erwin Data Modeler, figura 6.9.

Opţiunea Reverse Engineering din meniul Database permite importul bazelor de date Oracle, DB2, SQL, Access şi generarea modelului Visio corespunzător. Un program automatizat (wizard) ghidează utilizatorul pentru o preluare mai facilă a bazelor de date deja existente în alte formate şi pentru conectarea la diverse surse de baze de date.

Proiectarea unei baze de date cu ajutorul Visio presupune parcurgerea următoarelor etape:

a) Crearea modelului ORM (Object Role Model) care permite crearea unui model intuitiv al bazei de date (stabilirea entităţilor, a atributelor acestora, evidenţierea relaţiilor dintre entităţi).

b) Generarea automată a modelului logic pe baza modelului ORMc) Generarea modelului fizic pe baza modelului logic obţinut anterior

Interfaţa de creare a tabelelor (entităţilor) este similară cu aceeaşi interfaţă din programul Microsoft Access cu deosebirea că, în cazul Visio, tabelele pot fi portabile independent de sistemul de gestionare a bazelor de date.

126

.Figura 6.9. Opţiunile meniului Database.

Este posibil importul modelelor realizate cu alte instrumente CASE. Ca etapă intermediară între generarea modelului logic şi generarea modelului fizic este necesară validarea modelului (Database->Model-> Error Check). În acest caz este posibilă apariţia unor erori care vor fi afişate în fereastra de afişare a rezultatelor. Cele mai comune tipuri de erori pot apărea în următoarele două situaţii:

- două sau mai multe relaţii au acelaşi nume;- coloanele cu aceeaşi denumire din tabele diferite sunt diferite din punct de

vedere al tipului datelor.Pentru a genera baza de date se selectează din meniul Database opţiunea Generate.

Se va lansa automat validarea modelului şi se poate opta pentru generarea unui script DDL ce conţine comenzile SQL corespunzătoare generării fiecărei tabele şi relaţii din baza de date. Este utilă selectarea opţiunii Store current database image in model pentru ca modificările ulterioare aduse bazei de date să determine doar o adăugare a acestora şi nu crearea de la zero a bazei de date modificate. În final Visio va genera entităţile, indecşii şi relaţiile bazei de date. Rezultatul acestei cod va fi afişat în fereastra de afişare a rezultatelor. Ca ultimă etapă, se recomandă o verificare a codului respectiv, întrucât pot apărea erori. Visio 2007 permite salvarea sub formă de pagină Web a modelelor realizate. Diagramele ER se pot salva în diverse formate grafice cu scopul utilizării ulterioare în documentaţiile diverselor proiecte.6.4.3. Toad data modeler

Toad Data Modeler exportă diagramele ER în format HTML, RTF sau în format imagine (.jpg sau .bmp). Atuurile acestui program sunt următoarele [69]:

127

– posibilitatea de a creea diagrame ER pentru diverse sisteme de gestionare a bazelor de date;

– ingineria inversă;

– adăugarea de date suplimentare în diagramele ER pentru a îmbunătăţi descrierea bazei de date;

– posibilitatea de a verifica modelul şi de a genera erorile într-o formă explicită;

– generarea automată de cod SQL pentru baza de date creată;

– monitorizarea modificărilor cu ajutorul Version Manager-ului;

– posibilitatea de creare a unei liste de sarcini privind modelul generat (To Do list).

Pentru a creea un nou model în Toad Data Modeler se alege din meniul File opţiunea New. În continuare se alege formatul bazei de date ţintă, pentru care va fi generat scriptul SQL. Pentru Access 2000 nu se generează script SQL, însă se generează cod VBA (Visual Basic for Applications). Codul sursă poate fi executat ca şi Modul în fereastra editorului Visual Basic din Access 2000. Mai întâi va trebui creată o bază de date vidă şi inserat un modul Visual Basic. În modulul respectiv se copie codul generat de programul Toad. În continuare, din fereastra editorului Visual Basic se alege opţiunea Reference din meniul Tools şi se selectează DAO 3.6 libraries for MS Access 2000 şi se lansează în execuţie modulul din opţiunea Run. Din meniul Model, opţiunea Insert se inserează toate elementele grafice ale modelului: entităţi, atribute şi diverse tipuri de relaţii. Dacă se doreşte modificarea tipului unei relaţii create în prealabil, se execută click dreapta pe relaţia respectivă şi se alege opţiunea Edit Relationship. Se va afişa fereastra din figura 6.10.

128

Figura 6.10. Modificarea unei relaţii.Este posibilă astfel redenumirea relaţiei, modificarea tipului acesteia, inserarea

unei scurte descrieri, etc. Pentru a obţine o imagine de ansamblu asupra bazei de date, se va accesa opţiunea Project Explorer din meniul Model. Se va afişa structurat lista cu entităţile existente, atributele, relaţiile şi indecşii utilizaţi, figura 6.10. În final se validează modelul şi se remediază eventualele erori selectând opţiunea Model Verification.Procesul de inginerie inversă va extrage toate elementele bazei de date din formatul original şi va genera modelul Toad al bazei de date respective. Pentru a asigura comunicarea cu diversele formate de baze de date, Toad foloseşte diverse metode de comunicaţie printre care, atunci când este posibilă şi comunicaţia nativă.

Opţiunea Reverse Engineering din meniul File va demara procesul. Utilizatorul va trebui să specifice formatul original al bazei de date, tipul acesteia şi numele utilizator şi parola de conectare dacă este cazul, figura 6.11.

129

Figura 6.11. Afişarea structurată a modelului. Fereastra Model Explorer

130

Figura 6.11. Opţiunea Reverse Engineering.6.4.4. Embarcadero ER/Studio [70]

Programul suportă diverse tipuri de baze de date: Oracle, MS SQL Server, IBM DB2 şi Sybase ASE. Programul poate fi rulat în două moduri: client independent (standalone) sau ca şi client conectat la un depozit central. Depozitul permite crearea unei baze de date centralizate care va memora modelele create şi permite de asemenea aplicarea unor restricţii de securitate referitoare la accesul la modelul respectiv. Nu este permis accesul la un submodel fără ca, în prealabil, accesul la modelul principal să fie permis. Opţiunea New din meniul File determină activarea ferestrei din figura 6.12.

131

Figura 6.12. Opţiunile disponibile pentru crearea unui nou model în ER/StudioDupă cum se constată din figura 6.12, sunt posibile trei variante de creare a

modelului: crearea unui model nou, posibilitatea de a importa un model din fişiere SQL, ERX sau dintr-un format extern de descriere a datelor.

Facilitatea inginerie inversă utilizează conexiunea directă cu o mare varietate de tipuri de baze de date. Odată cu accesarea acestei opţiuni se lansează un wizard care va afişa o listă cu tipurile de baze de date compatibile şi care vor fi ulterior transformate în modele logice sau fizice. Obiectele asupra cărora se poate aplica procesul inginerie inversă sunt: tabelele şi vederile, tabelele definite de utilizator, procedurile şi funcţiile memorate. Se detectează de asemenea automat integritatea în cazul în care nu este declarată explicit în baza de date. ER/Studio va împărţi elementele capturate dintr-o bază de date în două categorii, corespunzătoare modelului logic şi modelului fizic. Prin vizualizarea modelului logic, utilizatorul poate vizualiza proprietăţile asociate unei tabele, cum ar fi atributele, relaţiile şi eventualele restricţii. Programul nu elimină restricţiile legate de cheia străină declarate explicit ci va semnala o cheie străină prin afişarea simbolului FK lângă aceasta.

ER/Studio permite crearea diagramelor entitate – relaţie în totalitate pornind de la zero sau obţinerea acestora cu ajutorul facilităţii inginerie inversă. Produsul scanează bazele de date şi ajută utilizatorii în eliminarea redundanţelor prin extragerea metadatelor.

132

Figura 6.13. Interfaţa utilizator ER/Studio6.4.5. Oracle Designer

Setul de instrumente Designer/2000 este parte integrantă din portofoliul de instrumente de dezvoltare oferit de Oracle şi reprezintă o soluţie integrată pentru dezvoltarea de sisteme client/server din generaţia a doua sau de sisteme Intranet bazate pe Web. Designer/2000 acoperă toate fazele ciclului de dezvoltare a aplicaţiilor software, pornind de la modelarea sistemului informatic (business modelling) până la exploatare. Abordarea Designer/2000 bazată pe un Repository permite ca anumite componente sau toate componentele să fie folosite pentru dezvoltarea rapidă de aplicaţii scalabile, multi-platformă, distribuite [72].

Oracle Designer oferă instrumente de modelare şi de dezvoltare care permit utilizatorilor să urmărească anumite metode de proiectare. Astfel, Oracle Designer permite utilizatorilor să utilizeze metodologia SLDC (System Development Life Cycle) sau metode iterative gen SSADM (Structured System Analysis and Design Methodology).

133

Figura 6.14. Oracle Designer 2000.În cele ce urmează se vor prezenta caracteristicile generale ale acestui produs

software.Produsele software oferă instrumente de modelare pentru crearea diagramei de flux

de date, a diagramelor entitate – relaţie, a diagramelor ierarhiei funcţionale şi a modelelor de proces. Oracle Designer poate transforma un model logic în model fizic ce poate fi apoi transformat în bază de date. Oracle Designer conţine instrumente de transformare a procedurilor în cod şi poate de asemenea genera o interfaţă grafică utilizator (GUI) prin utilizarea Oracle Form şi Report.

Oracle Designer oferă un depozit centralizat în care se stochează toate informaţiile ce pot fi accesate de către alţi utilizatori. Acest fapt permite proiectanţilor să lucreze simultan la aceeaşi aplicaţie şi toate modelele sunt imediat disponibile celorlaltor utilizatori. Un alt avantaj al acestei centralizări este cel generat de faptul că toată informaţia este memorată unitar, micşorându-se riscul pierderii sau alterării acesteia.

Depozitul care stochează toată informaţia pentru instrumentul CASE furnizează un volum mare de documentaţie formată din detalii referitoare la model (Diagrama ER, de flux de date) şi de comentarii memorate în aplicaţii sub diverse forme (tabele, vederi sau module SQL).

Oracle Designer permite generarea unor rapoarte utile din depozitul de date.Codul PL/SQL este stocat într-o formă modulară, grupată pe funcţii, proceduri sau

triggere. Modulele sunt incluse în alte module PL/SQL ca unităţi de subprogram. Când aceste module sunt generate pe baza depozitului, toate subprogramele sunt incluse pentru a forma codul sursă al modulului.

134

Un alt avantaj al instrumentelor CASE este faptul că scurtează timpul necesar obţinerii unui model valid. Instrumentele CASE permit proiectarea sistemului şi prin utilizarea unor instrumente de modelare este posibilă transformarea acestuia în elemente palpabile (tabele, chei străine).

Deoarece informaţia utilizată de instrumentul CASE este memorată centralizat întreţinerea sistemului este mai facilă.

Din punct de vedere al mentenabilităţii, apar următoarele avantaje: - modelele proiectate pot fi actualizate imediat;- modificările aplicate asupra modelului pot fi implementate în aplicaţie cu

ajutorul instrumentelor specifice ceea ce reduce posibilitatea apariţiei unor erori;

- codul generat poate reflecta doar eventualele modificări aduse asupra tabelelor;- codul generat este stocat modular astfel încât este posibilă modificarea doar a

unui modul şi regenerarea modulului modificat.

Teste rezolvate

1. Obiectivul principal al instrumentelor CASE este:

a) Punerea în practică a produselor-program de proiectare şi realizare a softului cu ajutorul calculatorului.

b) Simplificarea activităţilor de proiectare şi realizare a sistemelor/ aplicaţiilor.c) Folosirea depozitelor modularizate.

Răspuns: a2. Avantajele sistemelor CASE sunt:

a) exploatarea sistemului;b) creşterea vitezei de realizare a sistemelor;c) realizarea succesivă a componentelor unui sistem;d) simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.

Răspuns: b, c, d3. Instrumentele CASE se bazează pe:

a) o funcţie fundamentală;b) două funcţii fundamentale;c) mai multe funcţii fundamentale.

Răspuns: b4. Caracteristicile mediilor moderne de tip CASE sunt:

a) integrarea;

135

b) aranjarea;c) descompunerea;d) exploatarea.

Răspuns: a, c5. Domeniile către care se orientează Upper CASE-ul, sunt:

a) analiza cerinţelor sistemului;b) proiectarea şi modelarea funcţională şi procedurală;c) modelarea datelor şi proiectarea bazei de date;d) generarea codurilor.

Răspuns: a, b, c, d6. Nu sunt corecte următoarele afirmaţii:

a) CASE reprezintă Proiectarea Sistemelor Asistată de Calculator;b) Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susţinere a

activităţilor de planificare, definire, proiectare şi realizare a softului.c) CASE reprezintă Proiectarea Sistemelor cu Ajutorul Calculatorului;d) CASE reprezintă Componente Asamblate ale Sistemelor Economice.

Răspuns: d

Întrebări şi răspunsuri

1. Enumeraţi tipurile de instrumente CASE după metodologia pe care o încorporează pentru realizarea sistemelor.

Răspuns:instrumente CASE bazate pe metodologia structurată;instrumente hibride, ce conţin elemente specifice orientării-obiect, dar care nu permit realizarea sistemelor orientate-obiect;instrumente pur orientate-obiect.

2. Enumeraţi componentele produsului Westmount I-CASE Yourdon.Răspuns:

Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaţional: Informix, Ingres sau Oracle.Analyst, este componenta ce oferă suport pentru analiza structurată şi anume: editoare pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structură a datelor editoarele matriciale pentru matricea listei de evenimente.Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de ansamblu). Designer este componenta ce oferă suport pentru proiectarea de detaliu a sistemului informatic.Proiectarea de detaliu a aplicaţiei este strâns legată de proiectarea bazei de date. Pentru modelarea datelor se utilizează diagrama entitate asociere.Programmer este mediul de programare care oferă suport pentru generarea codului sursă, compilare, lansare în execuţie şi testarea aplicaţiei. Generatorul de cod generează codul

136

DDL (în SQL) ce defineşte structura fizică a bazei de date şi codul aplicaţiei în limbajul C îmbogăţit cu instrucţiuni SQL pornind de la specificaţiile din schemele de structură.Docwriter este componenta care permite generarea documentaţiei pentru fiecare etapă de realizare a sistemului.

3. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de viaţă al sistemelor, pot fi grupate în instrumente:

Răspuns: Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor; Lower CASE orientat-obiect pentru generarea codului-sursă al aplicaţiilor; I-CASE orientat-obiect care acoperă întregul ciclu de viaţă.

137

Capitolul 7. Tendinţe actuale şi de perspectivă în evoluţia sistemelor informatice

7.1. Concepţia sistemică în economieÎncepând din anii ’80, în teoria generală a sistemelor apare şi se dezvoltă o nouă

concepţie şi anume concepţia holonică asupra sistemelor. Aproximativ în aceeaşi perioadă se dezvoltă sistemele inteligente, ca structură de bază în domeniul inteligenţei artificiale.

Un sistem holonic este [61], [BURA99] un sistem de referinţă deschis în cadrul căruia funcţionează alte sisteme autonome, fiind posibilă “desprinderea” şi “ataşarea” de sisteme autonome atât în plan abstract cât şi în plan real, iar optimizarea vizează atât sistemele componente cât şi sistemul de referinţă. În acest context, două sau mai multe sisteme autonome pot fi integrate în baza unor criterii şi pentru atingerea unor obiective, formând astfel un nou sistem de referinţă, respectiv sistemul holonic care are rolul de integrator şi care optimizează funcţionarea şi rezultatele obţinute de sistemele încorporate.

Arhitectura generală a unui sistem holonic este reprezentată în figura 7.1 [61], [BURA99].

Sistemul activităţii umane este un tip particular de holon la care se raportează optimizarea tuturor celorlalte sisteme holonice. Realizarea şi funcţionarea unui sistem integrator este de neconceput fără utilizarea masivă a tehnologiei informatice.

Concepţia holonică asupra sistemelor oferă noi perspective în cercetarea ştiinţifică şi în procesul cunoaşterii cu aplicabilitate în diverse domenii, inclusiv în economie, însă rezultate spectaculoase sunt aşteptate în domeniul inteligenţei artificiale [61], [BURA99]. Având în vedere această concepţie precum şi impactul utilizării tehnologiilor informatice (mai recent a inteligenţei artificiale) în management, în domeniul economic este definită firma holonică [61], [BURA99] şi întreprinderea inteligentă [1].

138

SI

S1

S2

Sn

.

.

.

INPUTS OUTPUTS

FEEDBACK

Fig 7.1. Arhitectura generală a unui sistem holonic

O firmă holonică se obţine prin integrarea a două sau mai multor companii autonome într-o reţea, având în vedere cerinţele prezente şi viitoare impuse de clienţii comuni şi standardul produselor/serviciilor realizate de fiecare firmă autonomă. Concepţia holonică asupra sistemelor poate fi avută în vedere şi în cadrul altor organizaţii, un exemplu în acest sens fiind organizaţiile administraţiei publice locale la nivel teritorial (consiliul judeţean, prefectura, primăriile din cadrul judeţului).

Schimbările tehnologice care au avut loc în ultimii ani au condus la o nouă gândire privind întreprinderea şi activitatea sa, cu implicaţii majore la nivel organizaţional şi în ceea ce priveşte managementul. Dezvoltarea şi utilizarea sistemelor inteligente în cadrul unei organizaţii permite managerilor să folosească cunoaşterea depozitată pentru rezolvarea problemelor complexe din cadrul organizaţiei şi pentru luarea deciziilor strategice.

Existenţa reţelelor Internet, Intranet, Extranet şi a altor reţele de telecomunicaţii permite interconectivitatea globală şi deci manifestarea organizaţiilor la nivel planetar. În condiţiile globalizării, întreprinderea modernă trebuie să satisfacă necesităţile globale de afaceri într-o societate informaţională globală astfel încât aplicaţii din orice punct de pe glob să poată accesa şi prelucra datele şi cunoştinţele necesare desfăşurării activităţii muncitorului cunoaşterii.

Utilizarea sistemelor inteligente care sunt permanente, nu fac grevă, nu solicită concediu, pot memora, consulta şi prelucra volume considerabile de date şi cunoştinţe şi pot funcţiona 24 de ore din 24, asigură o independenţă a managementului de salariaţi şi pune la dispoziţia managerilor toate cunoştinţele acumulate asistându-i în soluţionarea problemelor complexe şi luarea deciziilor. Sistemele inteligente oferă posibilitatea exploatării cunoaşterii prin combinarea potenţialului tehnologiei bazelor de date cu tehnologia bazelor de cunoştinţe şi a sistemelor expert, remarcându-se în acest sens tehnologia bazelor de date inteligente [3].

Având în vedere aceste aspecte s-a definit întreprinderea inteligentă, întreprinderea expert, întreprinderea bazată pe cunoştinţe [1], ca fiind acea organizaţie în care se utilizează în mod curent sistemele inteligente pentru soluţionarea tuturor problemelor dificile, “organizaţia care lucrează inteligent este organizaţia care captează cunoaşterea de la experţii umani, o depozitează într-o formă acceptată de către calculator şi o foloseşte cu ajutorul unor programe specializate la soluţionarea problemelor”.

Întreprinderile viitorului denumite de McHugh & all [61] firme virtuale, vor fi propulsate spre succes de o viziune comună, iar managementul se va realiza atât prin procese şi tehnici intuitive cât şi prin metodele logice şi raţionale utilizate la ora actuală.

Societatea modernă este caracterizată de schimbări rapide şi inovare permanentă în toate domeniile cunoaşterii. Încă din anii ’70, în lucrarea “Şocul Viitorului”, Alvin Toffler atrăgea atenţia asupra accelerării schimbării în toate domeniile cunoaşterii, schimbare determinată în principal de revoluţia informatică.

Perioada 1950-1990 defineşte “Al Treilea Val” al progresului şi este perioada în care are loc revoluţia informatică prin utilizarea maşinilor “inteligente” şi în care accentul este pus pe resursa “individ”, iar relaţiile interorganizaţionale au la bază deviza “cooperăm”. După 1990 are loc naşterea şi răspândirea celui de-Al Patru-lea Val

139

determinat de revoluţia cunoaşterii cu accent pe cunoaşterea inconştientă deci cunoaşterea bazată pe intuiţie, imaginaţie şi capacitatea creativă a individului. Este perioada ce va fi caracterizată de realizarea şi utilizarea de maşini care “gândesc” destinate pe domenii (ex. Economia), în care managementul este privit ca instituţie centrală cu difuzarea sa fără frontiere într-o societate informaţională globală şi în care cunoaşterea este exploatată ca resursă economică sub deviza “creăm împreună”.

Datorită facilităţilor de comunicare dincolo de graniţe, spaţiu şi timp oferite de reţeaua Internet, economia noului mileniu poate fi privită [73] ca o “scenă digitală” în care noile afaceri devin e-bussines (afaceri electronice), comerţul devine e-commerce (comerţ electronic), apar noi servicii electronice (e-services) şi se nasc noi comunităţi de tip virtual (e-communities). În noua scenă cu calculatoare interconectate în reţele Internet, Intranet şi Extranet suntem “inundaţi de informaţie, dar flămânzi după cunoştinţe” [73] (John Naisbitt „Megatrends. Ten New Directions Transforming Our Lives”), viziunea lui Alvin Toffler în „Şocul viitorului” fiind mult mai sumbră, el avertizând asupra iminenţei unui nou „potop”, de această dată nu de apă, ci de informaţii. Apare deci şi se dezvoltă, în cadrul economiei digitale, o nouă piaţă şi anume piaţa digitală sau piaţa electronică în care trebuie acordată o importanţă tot mai mare noii resurse strategice care este informaţia, cunoştinţa. Principalii actori (componente) ai economiei digitale, în viziunea anumitor specialisti (Turban, s.a., 1999) [73] sunt:

cumpărătorii/consumatorii - milioane de internauţi care navighează pe Web -potenţiali cumpărători ai bunurilor ăi serviciilor oferite sau promovate pe Internet;

vânzătorii - sute de mii de magazine digitale care îşi prezintă milioane de produse pe

Net; produsele şi serviciile digitale - digitalizarea software-ului, a muzicii, a cărţilor,

ziarelor şi revistelor, a filmelor ş.a., digitalizarea a nenumărate alte produse şi servicii;

companiile creatoare ale infrastructurii digitale - mii de firme implicate în asigurarea hardware-ului şi software-ului necesar realizării infrastructurii specifice economiei digitale, care să permită dezvoltarea comerţului electronic;

intermediarii (agenţii)- un nou tip de actori care îşi oferă serviciile pe Web, rolul lor diferind de cel al intermediarilor obişnuiţi prin aceea că sunt implicaţi în crearea şi susţinerea pieţei „on-line”, ei ajutând consumatorii şi/sau vânzătorii în derularea tranzacţiilor electronice;

serviciile de suport - sute de astfel de servicii sunt disponibile, pornind de la cele care asigură securitatea până la cele care furnizează cunoştinţe;

creatorii de conţinut - sute de companii de tip multimedia orientate pe crearea şi actualizarea continuă a propriilor pagini Web, precum şi a unor site-uri pentru diverse alte firme.

Fiecare din componentele economiei digitale prezentate mai sus are un rol bine definit în cadrul pieţei digitale / spaţiului electronic (marketspace) în care au loc tranzacţiile.

140

Din prezentarea de mai sus se constată apariţia unui nou tip de actor pe scena digitală şi anume intermediarul sau agentul. Se impune astfel distribuirea inteligenţei artificiale în vederea realizării sistemelor de agenţi inteligenţi sau sistemelor multiagent care pot lua decizii într-o societate populată de agenţi inteligenţi artificiali sau umani care au propriile lor scopuri.

Distribuirea inteligenţei artificiale este justificată din următoarele motive: în mod natural activităţile şi cunoştinţele sunt distribuite spaţial; extinderea cooperării om-maşină prin rezolvarea distribuită a problemelor; descompunerea sistemelor complexe şi a bazelor de cunoştinţe aferente în

subsisteme cooperative asigurând astfel modularitate şi flexibilitate sistemului precum şi timp de răspuns optim;

necesitatea integrării aplicaţiilor de inteligenţă artificială deja existente, atât între ele cît şi cu componente de prelucrare clasică şi sisteme de gestiune a bazelor de date distribuite;

în modelarea comportamentului uman în cadrul aplicaţiilor de inteligenţă artificială trebuie avut în vedere faptul că comportamentul uman este un comportament social.

Astfel, apare şi se dezvoltă o nouă tehnologie în realizarea programelor şi anume programarea orientată agent AOP (Agent-Oriented Programming), care constituie o modalitate de abordare în construcţia sistemelor multi-agent. Programarea orientată pe agenţi introdusă de Yoav Shoham odată cu definirea limbajului AGENT0, reprezintă o specializare a programării orientate pe obiecte şi în care colecţiei de obiecte definite de stări şi care comunică între ele prin transmitere de mesaje îi corespunde o mulţime de agenţi caracterizaţi de stări mentale compuse din noţiuni mentale (convingeri, intenţii, obligaţii, angajamente, decizii, etc.).

Comunicarea între agenţi se realizează prin intermediul unui limbaj specializat cum ar fi de exemplu limbajul KQML (Knowledge Querry and Manipulation Language) propus de ARPA (Advanced Research Projects Agency) în 1992, cu ultima versiune standardizată apărută la începutul anului 1997 (ARPA a realizat şi standardul MIF -Module Interconnect Framework ce conţine metodele standard de construire a megaprogramelor multimodul). KQML foloseşte limbajul KIF (Knowledge Interchange Format) pentru a descrie conţinutul informaţional al mesajului şi este o reprezentare ASCII a logicii cu predicate de ordinul întâi, într-o sintaxă apropriată de cea a limbajului LISP. Limbajul KQML şi KIF (cu succesorul lui SIF - Simple Knowledge Interchange Format) tind să devină la ora actuală un standard al comunicării în Sistemele Multi Agent cognitive.

Pentru realizarea activităţilor dintr-un domeniu într-o manieră inteligentă, în cadrul procesului decizional, decidentul este pus permanent în situaţia de a evalua şi alege între două sau mai multe alternative în cadrul unor activităţi inteligente. Materia primă de bază prelucrată în cadrul activităţilor inteligente este cunoaşterea, care reprezintă conceptul fundamental pentru dezvoltarea sistemelor inteligente. Reprezentarea şi procesarea datelor şi cunoaşterii reprezintă obiectul apariţiei şi dezvoltării a două tehnologii de importanţă majoră în informatică [1]:

141

Tehnologia bazelor de date; Tehnologia sistemelor inteligente.

În timp ce tehnologia bazelor de date are în vedere memorarea, întreţinerea şi accesarea unor volume mari de date, tehnologia sistemelor inteligente este axată pe rezolvarea unor probleme complexe în diverse domenii care necesită expertiză umană, fiind însă restricţionată de domenii bine delimitate şi ineficientă pentru procesări numerice şi gestiunea unor volume mari de date. Cele două tehnologii la ora actuală distincte, tind să evolueze convergent în cadrul conceptului de sistem informaţional inteligent care presupune elaborarea unui model unificat date-cunoştinţe. În acest sens, sistemele de baze de date au în vedere exprimarea semanticii în schemele lor conceptuale şi capacitatea de inferenţiere (baze de date deductive), iar sistemele bazate pe cunoştinţe tind să rezolve probleme care reclamă baze de cunoştinţe (fapte şi reguli) din ce în ce mai mari. Pentru exploatarea maximă a celor două resurse informaţionale, bazele de date şi bazele de cunoştinţe, nu este suficientă doar cuplarea sistemelor de gestiune a bazelor de date cu sistemele expert prin intermediul unor interfeţe în cadrul aplicaţiilor, fiind necesară proiectarea fiecăreia din cele două componente ca o extensie naturală a celeilalte astfel încât împreună să conducă la realizarea unui sistem integrat. În acest sens cercetările sunt îndreptate în următoarele direcţii:

dotarea SGBD cu instrumente suplimentare de structurare şi manipulare având în vedere semantica datelor (un pas important în această direcţie îl constituie bazele de date deductive);

dotarea sistemelor expert cu instrumente care să permită accesarea şi manipularea eficientă a informaţiei stocate în bazele de date;

valorificarea informaţiei din bazele şi depozitele de date prin tehnici de analiză multidimensională şi data mining.

7.2. Categorii de sisteme inteligenteÎn realizarea sistemelor inteligente s-au conturat următoarele abordări principale:

sisteme expert bazate pe reguli, în care cunoştinţele sunt reprezentate prin reguli de producţie;

sisteme bazate pe reţele neuronale, în care baza de cunoştinţe este creată automat de un algoritm de învăţare plecând de la o mulţime de exemple de învăţare, baza de cunoştinţe este implicit reprezentată de ponderile conexiunilor dintre neuroni şi nu există o bază de cunoştinţe explicită ca în abordarea bazată pe reguli;

sisteme multiagent care sunt sisteme distribuite formate dintr-o colecţie de agenţi autonomi care interacţionează într-un mediu comun.Avantajele şi dezavantajele fiecăreia dintre abordări sunt complementare şi de

aceea s-au definit modele mixte (hibride) care combină avantajele celor trei tipuri de sisteme.

7.2.1. Sisteme expert bazate pe reguliSistemele expert sunt sisteme informatice care stochează cunoştinţele dintr-un

domeniu bine precizat şi au capacitatea de a realiza expertize de o calitate apropiată de a

142

celor realizate de experţii umani. Într-un sistem expert bazat pe reguli pot fi evidenţiate următoarele componente:

o bază de cunoştinţe explicită constituită din o bază de fapte şi o bază de reguli; motorul de inferenţe; interfaţa utilizator.O categorie aparte de sisteme expert bazate pe reguli o reprezintă sistemele expert

generalizabile sau generatoarele de sisteme expert care sunt acele sisteme expert care conţin motorul de inferenţe, sistemul de gestiune al bazei de cunoştinţe, interfaţa de comunicaţie cu utilizatorul, dar a căror bază de cunoştinţe este vidă. Generatoarele de sisteme expert [53], [27], [22] sunt sisteme bazate pe reguli de producţie, capabile de a stoca diverse cunoştinţe reprezentate prin reguli şi de a deduce cu ajutorul acestora şi a valorilor unor fapte precizate de utilizator, noi cunoştinţe.7.2.2. Sisteme bazate pe reţele neuronale (sisteme conexioniste)

Un sistem conexionist constă dintr-o reţea de elemente de tip neuron interconectate, care realizează anumite funcţii logice simple. Într-un astfel de sistem informaţia este memorată difuz în toată reţeaua, fiind reprezentată de ponderile conexiunilor sinaptice dintre neuronii reţelei. O caracteristică importantă a reţelelor neuronale este capacitatea de a învăţa din exemple şi de a construi algoritmul de rezolvare a unei probleme pornind de la mulţimea de exemple de instruire şi regula de modificare a ponderilor interneuronale. Prelucrarea informaţiei în sistemele neuronale constă în efectuarea unor calcule numerice (calcul matriceal) prin care în faza de învăţare se urmăreşte descoperirea relaţiilor existente între intrările şi ieşirile unui set de exemple de instruire, relaţii ce vor fi ulterior utilizate pentru prelucrarea unor seturi noi de date de intrare în vederea clasificării lor. Pot fi astfel analizate seturi mari de date, din care unele pot fi incerte sau incomplete, pentru a identifica caracteristicile şi gruparea lor în clase fără a cunoaşte apriori regulile de aplicat, reguli ce vor fi deduse de sistem în faza de instruire prin procesarea numerică a datelor. Instruirea reţelei poate fi reactualizată prin utilizarea unor noi seturi de date de instruire. Un inconvenient al acestor sisteme este faptul că procesul de raţionament nu poate fi explicat iar cunoştinţele nu sunt reprezentate explicit. Pentru soluţionarea unor probleme complexe , reţelele neuronale pot fi combinate, în cadrul unui sistem integrat, cu alte tehnologii printre care: baze de date, sisteme expert, data mining, etc. În cadrul aplicaţiilor de tip data mining, reţelele neuronale pot fi utilizate pentru identificarea corelaţiilor din bazele de date în vederea descoperirii unor "şabloane" (patterns) semnificative în structura datelor şi extragerea informaţiilor predictive ascunse din bazele mari de date. În ultimii ani, reţelele neuronale artificiale sunt utilizate cu succes pentru rezolvarea unor probleme complexe printre care: procesarea limbajului natural, robotica, vederea artificială şi procesarea semnalelor, recunoaşterea scrisului de mână, sisteme de sprijinire a deciziei.7.2.3. Sisteme multi-agent. Definiţie, clasificare, arhitecturi.

Un sistem multi-agent (SMA) este [SIMA98] un sistem distribuit format dintr-o colecţie de agenţi autonomi care interacţionează într-un mediu comun, fiecare agent având cunoştinţe, capacităţi de acţiune şi scopuri proprii. Funcţie de tipurile de agenţi utilizaţi se pot identifica două categorii de sisteme multi-agent inteligente şi anume:

143

SMA cu agenţi cognitivi, numite şi sisteme multi-agent cognitive; SMA cu agenţi reactivi, numite şi sisteme multi-agent reactive.Sistemele multi-agent cognitive urmăresc să simuleze aspecte ale

comportamentului uman prin tratarea noţiunilor de scop, cooperare, competiţie, organizare în structuri sociale şi stabilirea relaţiilor de dependenţă în aceste structuri, capacitate de învăţare şi auto-perfecţionare. Un sistem multi-agent cognitiv reprezintă un sistem particular bazat pe cunoştinţe ce conţine o reprezentare simbolică a cunoştinţelor despre lumea în care evoluează fiind capabil să ia decizii prin intermediul unui proces inferenţial de raţionament. Însă, spre deosebire de un sistem bazat pe cunoştinţe clasic, în cadrul unui sistem multi-agent, un agent reprezintă simbolic lumea atât prin convingeri, care sunt păreri despre lume, eventual incomplete sau eronate, cât şi prin cunoştinţe care reprezintă fapte adevărate despre acea lume. De asemenea, un agent trebuie să fie capabil să raţioneze atât despre propriile lui convingeri şi cunoştinţe cât şi despre cele ale celorlalţi agenţi cu care interacţionează într-un anumit mediu. Abordarea cognitivă a agenţilor, ridică o serie de probleme critice în special referitor la complexitatea de calcul şi dificultatea algoritmilor necesari prelucrărilor simbolice.

Un sistem multi-agent reactiv este un sistem în care agenţii sunt unităţi simple de prelucrare, capabile să reacţioneze la schimbările de mediu şi să execute acţiuni simple corespunzător acestor schimbări. Un astfel de sistem este inspirat din organizarea şi activitatea comunităţilor biologice de insecte. Astfel, o albină nu poate fi considerată inteligentă însă comportamentul stupului în ansamblu şi modul de organizare a albinelor, executând acţiuni comune şi coordonate în vederea realizării scopului, prezintă elemente de inteligenţă. Adepţii sistemelor multi-agent reactive, criticând abordarea cognitivă, consideră că inteligenţa este situată în lumea exterioară şi nu la nivelul componentelor de prelucrare individuale, respectiv agenţii, comportarea inteligentă fiind un rezultat al interacţiunii dintre agenţi şi mediu, iar inteligenţa este o proprietate a sistemului ca întreg. În acest sens, au fost propuse sisteme cu arhitecturi care modelează structura şi comportamentul colectivităţilor de insecte, sisteme care ar putea fi realizate într-o abordare subsimbolică utilizând reţele neuronale sau algoritmi genetici.

O altă direcţie de cercetare o constituie abordarea mixtă cognitiv-reactivă având în vedere avantajele şi dezavantajele fiecăreia dintre cele două categorii de sisteme multi-agent.Arhitecturi pentru sisteme multi-agent

Arhitectura BDI (Belief, Desire, Intention) este arhitectura unui sistem multi-agent care conţine o reprezentare explicită a convingerilor, dorinţelor şi intenţiilor agentului. Convingerile reprezintă informaţiile pe care un agent le are despre mediul în care evoluează sau despre ceilalţi agenţi din sistem şi acestea pot fi adevărate sau false. Dorinţele sunt lucrurile pe care agentul ar dori să le realizeze, însă nu trebuie neapărat să acţioneze pentru îndeplinirea tuturor dorinţelor sale. Intenţiile sunt lucrurile pe care agentul le are în vedere spre realizare sau s-a angajat să le realizeze.

O arhitectură a unui sistem multi-agent se numeşte deliberativă dacă se bazează pe reprezentarea explicită a unui model simbolic şi pe manipularea de simboluri. Astfel de arhitecturi corespund de obicei sistemelor multi-agent cognitive.

144

O arhitectură reactivă este arhitectura unui sistem multi-agent în care nu se foloseşte un model simbolic pentru reprezentarea cunoştinţelor şi nu există raţionament simbolic. Într-o astfel de arhitectură, agenţii sunt reprezentaţi prin unităţi de prelucrare simple iar inteligenţa sistemului este emergentă din interacţiunea unităţilor de prelucrare cu mediul.7.2.4. Sisteme inteligente hibride

Pentru definirea conceptului de sistem inteligent hibrid, reamintim pentru început că în domeniul inteligenţei artificiale au apărut şi se dezvoltă o serie de tehnologii de vârf enumerate în cele ce urmează:

sisteme expert bazate pe reprezentarea simbolică a cunoştinţelor (sisteme expert bazate pe reguli);

reţele neuronale artificiale (sisteme conexioniste); sisteme fuzzy; algoritmi genetici; strategii de evoluţie şi programarea evolutivă (algoritmi evolutivi); agenţi inteligenţi; sisteme multiagent (inteligenţa artificială distribuită).Sistemele inteligente în care sunt integrate cel puţin două din tehnologiile

menţionate mai sus sunt cunoscute sub denumirea de sisteme inteligente hibride, iar tehnologia utilizată în vederea integrării este denumită tehnologia fuziunii. Fiecare din tehnologiile dezvoltate în domeniul inteligenţei artificiale prezintă avantaje şi dezavantaje şi nu pot fi utilizate singular pentru rezolvarea unor probleme complexe care se pun astăzi în ştiinţă, tehnică, economie şi societate. Această afirmaţie este susţinută şi de faptul că în procesarea umană a informaţiei şi cunoaşterii sunt implicate diverse reprezentări arhitecturale, creierul având pe de o parte o structură neuronală, iar pe de altă parte capacitatea de a opera cu simboluri şi de a efectua raţionamente simbolice, de a prelucra date imprecise sau incomplete.

Un domeniu de mare interes în care agenţii se vor impune spectaculos este Internet-ul, care permite astăzi accesul direct a milioane de oameni pe autostrada informaţională ( “Internet Society” estimează că există peste 30 de milioane de utilizatori care accesează zilnic reţeaua Internet), care pot fi atât consumatori cât şi potenţiali furnizori de informaţie. Căutarea informaţiei despre un anumit subiect necesită identificarea şi investigarea unui număr mare de documente de pe Web, operaţii mari consumatoare de timp şi care pot fi realizate de agenţi competenţi numiţi agenţi Internet. Pentru a asigura accesul tuturor categoriilor de utilizatori, indiferent de calificare şi cunoştinţele de care dispun, la resursele informaţionale imense de pe Internet, viitoarea generaţie de agenţi Internet va fi o combinaţie de modele cognitive şi reactive, având ca scop atât satisfacerea necesităţii de informare a utilizatorului cît şi transparenţa totală a autostrăzii informaţionale.

Deşi reţeaua Internet reprezintă un mare succes în unificarea resurselor informaţionale, structura sa actuală în care pot fi identificate două straturi şi anume: utilizatorii (consumatorii) de informaţie şi producătorii (furnizorii) de informaţie, nu este adecvată pentru activitatea de informare care presupune prelucrarea complexă a

145

informaţiilor din multiple documente de pe Web independentă de utilizator. Pentru rezolvarea acestei probleme, una din cele mai promiţătoare propuneri este modelul în care activităţile desfăşurate pe Internet sunt împărţite pe trei straturi, denumit [73] modelul celor 3 straturi şi anume:1. un strat pentru utilizatorii de informaţie (clienţii informaţionali) – defineşte cererea de

informaţie;2. un strat pentru furnizorii (producătorii) de informaţie – defineşte oferta de informaţie;3. un nou strat aflat între primele două, denumit stratul de mijloc sau stratul

intermediarilor, care să permită conectarea primelor două straturi prin cele mai bune căi sau modalităţi.

În cadrul acestui model, agenţii au un rol important diferenţiat pe straturi după cum urmează:

sarcinile agenţilor în cadrul primului strat sunt de a afla ce informaţii caută utilizatorii, dacă au anumite preferinţe în legătură cu informaţia de care au nevoie, etc.;

în cadrul celui de-al doilea strat sarcinile agenţilor sunt de a face un inventar al serviciilor şi informaţiilor oferite de către furnizori, de a ţine evidenţa noilor informaţii adăugate în reţea, etc.;

agenţii din stratul de mijloc au rolul de intermediari informaţionali între utilizatorii informaţionali (umani sau electronici) şi furnizorii de informaţii, sarcina lor fiind de mediere între agenţii celorlalte două straturi.

Agenţii utilizaţi într-un astfel de model vor trebui concepuţi în baza unor standarde general acceptate, astfel încât să răspundă şi să reacţioneze în acelaşi mod prin utilizarea unui set standardizat de coduri suficient de flexibil pentru a permite construirea unor agenţi pentru sarcini neaşteptate sau imprevizibile în prezent.

Referitor la domeniile de utilizare a tehnologiei agenţilor în viitor, cercetători în domeniu cred [73] că agenţii autonomi vor deveni în următorii 10 ani parte integrantă a celor mai multe sisteme de afaceri. Astfel, cei de la IBM prevăd o vastă utilizare a agenţilor software în e-commerce: “Creăm o nouă categorie economică (a new economic species), parţial asemănătoare nouă ca imagine, dar semnificativ diferită de oameni”, “Agenţii software vor deveni actori în economie”, afirmă Jeff Kephart, managerul grupului care se ocupă de fenomenul agenţilor.

146

Capitolul 8. Studii de caz - Arhitecturi de sisteme informatice

8.1. Model de date georelaţional în cadrul unui sistem informatic geografic distribuit cu aplicaţii în domeniul cadastruluiModele de date utilizate în sistemele informatice geografice (GIS)

Dacă până nu demult, tehnologiile GIS s-au dezvoltat independent de tehnologia bazelor de date, structurile de date fiind tratate exclusiv prin instrumente proprii fiecărui produs GIS, în ultimii ani se impune integrarea celor două tehnologii astfel încât un sistem GIS să poată beneficia de rezultatele obţinute în domeniul bazelor de date. În acest sens, în prezent pe piaţa sistemelor GIS sunt utilizate [78] următoarele modele de date: modelul hibrid, modelul integrat, modelul orientat obiect.

Modelul hibrid (model georelaţional) utilizează un set de fişiere pentru stocarea coordonatelor şi a informaţiei topologice şi un sistem SGBD (Oracle, Informix, Ingres, Sybase, Access) pentru stocarea datelor descriptive în tabele. Schema unui astfel de model este reprezentată în figura 8.1.

Sisteme care se bazează pe acest model printre care: ARC/INFO al firmei ESRI, IDGS şi GEOMEDIA ale firmei INTERGRAPH, MGE al firmei Bentley MicroStation, sunt reprezentative în domeniu, impunându-se pe piaţa utilizatorilor de sisteme GIS. Sistemul prezentat în acest capitol al lucrării este realizat pe baza acestui model.

Modelul de date integrat este bazat pe reprezentarea şi procesarea datelor grafice şi descriptive în cadrul unui SGBD relaţional. Acest mod de tratare prezintă limitări privind tipurile de date, însă are în vedere posibilitatea extinderii SGBD-ului cu noi tipuri de date şi cu noi facilităţi de interogare SQL. În acest sens, firme importante în domeniul bazelor de date, printre care Oracle, au dezvoltat în cadrul produselor lor SGBD componente

specializate pentru reprezentarea şi accesarea datelor spaţiale. Schema modelului de date integrat este reprezentată în figura 8.2.

147

Fişiere de date spaţiale:coordonate punctedescriere topologie

Baza de date relaţională:- tabele de date descriptive

Identificator de legătură

Figura 8.1. Model de date georelaţional

BAZA DE DATE RELAŢIONALĂ

Concatenare relaţională

Tabele de date grafice Tabele de date descriptive

Figura 8.2. Model de date integrat

Într-un astfel de model apar probleme de normalizare la asocierea perechilor de coordonate cu elementele grafice corespunzătoare.

odelul de date orientat obiect se bazează pe tehnologia orientată obiect, însă prezintă dezavantaje întrucât nu există un limbaj de interogare standard iar sistemele orientate obiect sunt încă în stadiu incipient.

Model de date georelaţional în domeniul cadastruluiRegistrul cadastrului conţine 3 categorii de informaţii: informaţii tehnice,

informaţii juridice, informaţii economice. Raportat la modul de prelucrare, informaţiile se grupează în: date descriptive (textuale) şi date grafice (spaţiale). Organizarea, descrierea şi prelucrarea datelor cadastrale necesită utilizarea unui produs de tip GIS (Geographical Information System) care să ofere: un nucleu grafic pentru reprezentarea şi prelucrarea datelor grafice, un sistem de gestiune a bazelor de date, comunicarea între cele două componente ale sistemului. Potrivit legii cadastrului general şi publicităţii imobiliare, cadastrul general se organizează la nivelul fiecărui teritoriu administrativ comunal, orăşenesc, municipal, judeţean şi la nivel naţional. Documentele tehnice principale ale cadastrului general, ce se vor întocmi la nivelul comunelor, oraşelor şi municipiilor sunt:

registre cadastrale (parcele, proprietari, corpuri de proprietate) planuri cadastrale şi hărţi topografice.

Datele din registrele cadastrale privind terenurile şi construcţiile vor fi reprezentate grafic în planuri cadastrale şi hărţi topografice.

La nivel de judeţ se vor organiza şi vor funcţiona bazele de date ale cadastrului general interconectate, iar la nivel naţional banca de date a cadastrului general. În cadrul modelului sunt avute în vedere entităţile de bază, nivelele de abordare, categoriile de date, după cum este ilustrat în figura 8.3.

În cele ce urmează sunt descrise structurile de date definite în cadrul modelului

148

Figura 8.3. Schema generală a modelului georelaţional

georelaţional.

Date descriptive

PARCELE (descriere parcele): CODJ cod judeţ, CODL cod localitate, CODP cod parcelă (perimetru, parcela), DENP denumire parcelă, ADRESA adresa parcelei (strada, nr.), CATF cod categorie de folosinţă, TIPP tip proprietate, PCADP partida cadastrală a parcelei, SUPP suprafaţa parcelei, DOTARI dotarea edilitară a parcelei (A-apă, C-canal, G-gaze, E-electricitate), VALE valoare economică.

CATFOL (definire dicţionar categorii de folosinţă): CATF cod categorie de folosinţă, DENCF denumire categorie de folosinţă.

TIPPROP (definire dicţionar tipuri de proprietate): TIPP cod tip proprietate, DENTP denumire tip proprietate.SUBPARC (descriere subparcele): CODJ cod judeţ, CODL cod localitate, CODP cod parcelă, CODSP , cod (număr) subparcelă, CATF cod subcategorie de folosinţă, SUPSP suprafaţa subparcelei.ISTORIAP (istoric parcele): CODJ cod judeţ, CODL cod localitate, CODP cod parcelă (perimetru, parcela), DENP denumire parcelă, ADRESA adresa parcelei (strada, nr.), CATF cod categorie de folosinţă, TIPP tip proprietate, PCADP partida cadastrală a parcelei, SUPP suprafaţa parcelei.

PART_CADP (relaţia PARCELE-PROPRIETARI): PCADP partida cadastrală a parcelei, CODPROP cod proprietar, CODDET cod deţinător, COTA cota indiviză (%).

CONSTRUCTII (descriere corpuri clădire): CODJ cod judeţ, CODL cod localitate, CODP cod parcelă de amplasare a construcţiei, IDCORP identificator corp clădire, DENCORP denumire corp clădire, PCADC partida cadastrală a construcţiei, TIPP tip proprietate, DEST destinaţia clădirii, FOL folosinţa clădirii, SUPS suprafaţa la sol, NRNIV număr nivele, SUPD suprafaţa desfăşurată, DOTARI dotarea edilitare (A-apă, C-canal, G-gaze, T-telefon, E-electricitate), FUNDAT fundaţie, PERETI pereţi, ANCON anul construirii, SEISM grad de rezistenţă la seisme.

PART_CADC (relaţia CONSTRUCTII-PROPRIETARI): PCADC partida cadastrală, CODPROP cod proprietar, CODDET cod deţinător, COTA cota indiviză (%).

JUDETE (lista judeţe): CODJ cod judeţ, DENJ denumire judeţ.

LOCALITATI (lista localităţi): CODJ cod judeţ, CODL cod localitate, DENL denumire localitate.

ARTERE (artere, străzi): CODJ cod judeţ, CODL cod localitate, CODA cod arteră

149

(stradă), DENA denumire arteră (stradă).

POSESORI (PERSOANE, AGENTI - persoane sau agenţi economici şi sociali, proprietari sau deţinători de terenuri şi construcţii): CODPOS cod posesor, DENPOS nume posesor, Adresa de domiciliu (CODJ cod judeţ, CODL cod localitate, CODA cod stradă, NR număr poştal, BLOC blocul, SCARA scara, ETAJ etajul, AP apartamentul ).

Date grafice (spaţiale)COORDONATE (fişier .xyz pentru descriere puncte măsurate în teren): CODP cod parcelă de amplasare a construcţiei, IDCORP identificator corp clădire sau spaţii pentru parcele, NRP număr punct, X abscisa punctului, Y ordonata punctului, Z cota punctului.

CONTUR (fişier .con pentru descriere entităţi grafice): CODP cod parcelă de amplasare a construcţiei, IDCORP identificator corp clădire sau spaţii pentru parcele, TIPC tip contur (0-deschis, 1-închis), LAYER strat sau cod culoare umplere contur, NRP1 NRP2 … NRP10 identificare puncte consecutive pe contur.

O altă categorie de date este constituită din imagini raster reprezentând fişiere imagine obţinute prin scanare planuri cadastrale şi hărţi topografice, care pot constitui surse de date grafice obţinute prin operaţia de vectorizare.

Date de sinteză

Pentru realizarea unor situaţii de sinteză în baza de date se definesc vederi ca spre exemplu:TSPCF – total suprafeţe pe categorii de folosinţă

CREATE VIEW TSPCF(CATF,TSUP) AS SELECT CATF, SUM(SUPP)FROM PARCELE GROUP BY CATF

TSPLCF – total suprafeţe pe localităţi defalcat pe categorii de folosinţăCREATE VIEW TSPLCF(CODL,CATF,TSUP) AS SELECT CODL, CATF, SUM(SUPP)

FROM PARCELE GROUP BY CODL, CATF

TSPJ – total suprafeţe pe judeţeCREATE VIEW TSPJ(CODJ,TSUP) AS SELECT CODJ, SUM(SUPP)

FROM PARCELE GROUP BY CODJ

TSPJL – total suprafeţe pe judeţe defalcat pe localităţiCREATE VIEW TSPJL(CODJ,CODL,TSUP) AS SELECT CODJ, CODL, SUM(SUPP)

FROM PARCELE GROUP BY CODJ,CODL

TSPTP – total suprafeţe pe tipuri de proprietateCREATE VIEW TSPTP(TIPP,TSUP) AS SELECT TIPP, SUM(SUPP)

150

FROM PARCELE GROUP BY TIPP

TSPJCON – total suprafaţă construcţii pe judeţeCREATE VIEW TSPJCON(CODJ,SUPS,SUPD)

AS SELECT CODJ,SUM(SUPS),SUM(SUPD) FROM CONSTRUCTII GROUP BY CODJ

Interconectarea bazelor de date

În baza de date a cadastrului sunt utilizate o serie de informaţii proprii altor sisteme de evidenţă şi anume: sistemul de evidenţă a populaţiei, sistemul de evidenţă a unităţilor teritorial administrative, sistemul de evidenţă a agenţilor economici şi sociali. Comunicarea între aceste sisteme informaţionale este reprezentată în schema din figura 8.4.

Distribuirea datelor este o caracteristică comună fiecăruia din cele patru sisteme de evidenţă. Datele proprii altor sisteme şi utilizate în sistemul cadastrului vor trebui, fie reproduse, fie utilizată o altă metodă de accesare a acestora. În cele ce urmează este prezentată o astfel de metodă de accesare a unor date stocate în baze de date diferite, proprie sistemului de gestiune a bazelor de date ORACLE şi anume crearea şi utilizarea referinţelor dblink [ORA92]. În figura 8.5 este reprezentată schema de comunicare între bazele de date aferente sistemelor de evidenţă utilizate.

151

Figura 8.4. Schema de comunicare între sistemele de evidenţă

POPULAŢIE

AGENŢI

ECONOMICI

ŞI SOCIALI

UNITĂŢI TERITORIAL

ADMINISTRATIVE- judeţe

- localităţi - străzi (artere)

CADASTRU

- Parcele

- Construcţii

- Proprietari/deţinători

proprietate localizare

B.D.POPULATIE

B.D.AGENTI

B.D.COMUNITATI

B.D.CADASTRU

LEGCP LEGCA LEGCC

Figura 8.5. Schema de comunicare între bazele de date ale sistemelor de evidenţă

Referirea, în baza de date CADASTRU, a unor date din bazele de date POPULATIE, AGENTI, COMUNITATI aflate pe servere diferite eventual la distanţă faţă de baza de date solicitantă (CADASTRU), se poate reliza prin elementele dblink denumite LEGCP, LEGCA, LEGCC care se crează cu comenzi având sintaxa:

CREATE DATABASE LINK <nume dblink> CONNECT TO <nume utilizator>IDENTIFIED BY <parola utilizator> USING ‘<server B.D. Oracle>’

unde <nume utilizator>, <parola utilizator>, <server B.D. Oracle> sunt date de identificare pentru bazele de date referite (POPULATIE, AGENTI, COMUNITATI).

Accesul la date din bazele de date referite se realizează prin instrucţiuni SELECT astfel:SELECT <lista câmpuri> FROM <nume tabelă>@<nume dblink> WHERE <condiţie>.

Astfel, dacă se presupune că din structurile de date definite mai sus, tabela PERSOANE este definită în baza de date POPULATIE, tabela AGENTI este definită în baza de date AGENTI, tabelele JUDETE, LOCALITATI, ARTERE sunt definite în baza de date COMUNITATI, iar celelalte tabele sunt definite în baza de date CADASTRU, pentru a obţine lista tuturor proprietarilor (persoane fizice) de terenuri pe suprafeţe şi categorii de folosinţă din localitatea SUCEAVA (CODJ = 33, CODL = 5800) şi adresele de domiciliu ale acestora plecând de la baza de date CADASTRU şi interconectarea acesteia cu bazele de date POPULATIE şi COMUNITATI, se va utiliza schema de interogare reprezentată în figura 8.6.

Comanda SQL pentru realizarea interogării reprezentată în schemă este:

SELECTA.Codp,A.Catf,A.Supp,C.Denpos,D.Denj,E.Denl,F.Dena,C.Nr,C.Bloc, C.Scara,C.Etaj,C.Ap FROM PARCELE A, PART_CADP B, PERSOANE@LEGCP C, JUDETE@LEGCC D, LOCALITATI@LEGCC E, ARTERE@LEGCC F WHERE A.Codj = ”33” AND A.Codl = ”5800” AND A.Pcadp = B.Pcadp AND B.Codpos = C.Codprop AND C.Codj = D.Codj AND C.Codl = E.Codl AND C.Coda = F.Coda ORDER BY C.Denpos

152

PARCELEPcadpCodjCodl

PART_CADPPcadpCodprop

PERSOANECodposCodjCodlCoda

JUDETE- Codj

LOCALITATI- Codl

ARTERE- Coda

Codprop = Codpos

Codj = 33Codl = 5800

=

=

=

=

=

Figura 8.6. Schemă de interogare a bazelor de date interconectate

8.2. Sistem informatic geografic distribuit pentru reprezentarea digitală şi monitorizarea zonelor expuse inundaţiilor

Introducere

Lucrarea prezintă un sistem GIS, pentru reprezentarea digitală, monitorizarea şi evaluarea computerizată a efectelor asupra zonelor expuse inundaţiilor datorate revărsării apelor curgătoare sau accidentelor la construcţiile hidrotehnice.Lucrarea este destinată protecţiei civile la nivelul unui judeţ (Inspectoratul pentru Situaţii de Urgenţă) sau a unui bazin hidrografic şi dispeceratului S.G.A. corespunzător (judeţean sau bazinal), pentru monitorizarea zonelor expuse, elaborarea planurilor de apărare şi a variantelor de acţiune în lupta împotriva inundaţiilor, fenomenelor meteorologice periculoase şi a accidentelor la construcţiile hidrotehnice.

Zonele expuse inundaţiilor vor putea fi descrise prin reprezentări sub formă de rapoarte (tabele, situaţii) şi prin reprezentări grafice constând din planuri, hărţi, schiţe, hidrografe, imagini, la diverse nivele: apă curgătoare, amenajare hidrotehnică, localitate, bazin hidrografic, judeţ. Pentru realizarea reprezentării digitale sunt preluate şi prelucrate date descriptive (alfanumerice) şi date grafice.

Datele sistemului

Datele descriptive sunt organizate într-o bază de date relaţională ce poate fi creată şi administrată utilizând, la alegere, un SGBD relaţional, ca de exemplu FoxPro sau Oracle, funcţie de performanţele sistemului de calcul şi a sistemului de operare utilizat.Structura bazei de date se defineşte prin încărcarea tabelelor dicţionar ceea ce conferă flexibilitate referitor la datele utilizate în sistem.

Baza de date alfanumerice este un ansamblu de tabele ce conţin date privind: apele curgătoare; bazinele hidrografice; localităţile expuse inundaţiilor; staţiile hidrologice şi staţiile hidrometrice; cote zonale de apărare; staţiile meteorologice şi posturile pluviometrice; amenajările (construcţiile) hidrotehnice; obiectivele periclitate; comisiile

153

de apărare împotriva inundaţiilor; stocurile de materiale şi mijloace de apărare existente; suprafeţele de teren, pe categorii de folosinţă, din cadrul localităţilor; niveluri, debite, temperaturi, precipitaţii măsurate şi arhivate în istoric.

La structura definită pot fi adăugate noi tabele şi câmpuri în tabelele deja existente prin simpla redefinire a tabelelor dicţionar.Datele grafice sunt organizate astfel:

fişiere imagine pentru reprezentare imagini, reprezentări raster rezultate prin scanare;

fişiere de contur şi fişiere de coordonate asociate pentru reprezentări de tip vector.

O reprezentare grafică (desen) este constituită în acest caz dintr-un ansamblu de entităţi grafice şi este conţinută într-un fişier .con şi fişierul de coordonate .xyz asociat. Entităţile grafice sunt grupate pe straturi (layere) care pot fi redate în ansamblu sau selectiv.

Corespondenţa între fişierele de date grafice şi reprezentările aferente este definită în catalogul reprezentărilor care conţine şi denumirea explicită a acestora. Dacă la preluarea datelor se stabilesc legături între informaţia grafică şi informaţia alfanumerică, modulul de reprezentare grafică permite accesarea informaţiei corespunzătoare din baza de date alfanumerice la selectarea fiecărui obiect grafic din desen.

Reprezentări

Sistemul realizat este orientat pe documente (reprezentări), fiecare dintre ele având asociată câte o înregistrare din catalogul de reprezentări aferent aplicaţiei. Într-o intrare din acest catalog sunt memorate informaţii caracteristice respectivei reprezentări, şi anume: nume, listă de produse cu care se poate prelucra/vizualiza şi fişierul/fişierele specifice ei (cu precizarea căii de acces la fişier(e)).

Pentru fiecare dintre produsele folosite pentru a prelucra/vizualiza diversele reprezentări aferente sistemului, există câte o intrare asociată într-un catalog de produse, ce conţine informaţii specifice produsului, şi anume: numele şi comanda de lansare în execuţie (eventual cu parametri).

Acest mod de tratare deschisă a reprezentărilor, orientat pe documente şi nu pe produse, asigură o mare flexibilitate şi permite o extindere uşoară, prin posibilitatea introducerii de reprezentări recunoscute de produse ce nu fac parte din sistem.

În cele ce urmează sunt formulate exemple de reprezentări ce pot fi realizate: Reprezentarea hărţii sistemului informaţional hidro-meteorologic şi operativ la

nivelul unui bazin hidrografic sau a unui judeţ (fig. 8.7). Reprezentarea reţelei hidrografice prin planuri şi hărţi la scara precizată de

utilizator cu posibilitatea de redare pe ecran, la imprimantă, la plotter; Elaborare reprezentări la nivel de bazin hidrografic având în vedere râul

principal şi afluenţii, localităţile şi categoriile de teren traversate, delimitarea zonelor inundabile, amenajările şi construcţiile hidrotehnice, posturile hidro-meteorologice, comisiile de apărare împotriva inundaţiilor etc (fig. 8.8);

154

Realizarea planurilor de situaţie a luncilor inundabile; Reprezentarea planşei conţinând comandamentele, comisiile locale şi staţiile

hidrometrice aferente, pentru apărarea împotriva inundaţiilor, la nivelul unui bazin hidrografic sau a unui judeţ;

Reprezentarea, la nivelul unui bazin hidrografic sau a unui judeţ, a zonelor în care se ating sau se depăşesc pragurile critice de apărare împotriva inundaţiilor;

Reprezentarea 3D a zonelor expuse calamităţilor, la nivelul unui bazin hidrografic sau a unui judeţ, cu evidenţierea reţelei hidrografice, formelor de relief, căilor de acces, zonelor inundate funcţie de cotele apelor;

Reprezentări grafice prin planuri, hărţi, schiţe, imagini pentru fiecare construcţie hidrotehnică;

Reprezentare profile transversale în planuri de situaţie; Reprezentarea hidrografelor undelor de viitură; Realizare planuri tematice la nivel de apă curgătoare, bazin hidrografic, judeţ; Realizare planuri la scară precizată cu localizarea obiectivelor, delimitarea

zonelor inundabile, dispozitivele hidro-meteorologice folosite pentru stabilirea valorilor caracteristice locale de apărare şi indicarea zonelor de evacuare.

Dintre reprezentările formulate anterior, harta sistemului informaţional hidro-meteorologic şi operativ este documentul grafic care defineşte sistemul informaţional hidro-meteorologic, la scara unui întreg bazin hidrografic sau judeţ.

În cadrul sistemului anumite informaţii sunt constante în timp sau în flux lent (reţeaua hidrografică, staţiile hidro-meteorologice, amenajările hidrotehnice etc.), iar altele sunt variabile sau în flux rapid (niveluri, debite, temperaturi etc.), acestea din urmă neputând fi reprezentate în cadrul hărţii. Spre deosebire de harta clasică, reprezentarea digitală oferă posibilitatea reprezentării în timp real a sistemului hidro-meteorologic, evidenţiind modificările ce au loc privind datele în flux rapid, date a căror cunoaştere, prelucrare şi interpretare în timp util prezintă o importanţă hotărâtoare în lupta împotriva inundaţiilor, fenomenelor meteorologice periculoase şi accidentelor la construcţiile hidrotehnice.

Având în vedere volumul şi diversitatea informaţiilor necesare pentru reprezentarea digitală, entităţile grafice sunt grupate pe straturi, ce vor putea fi reprezentate independent sau combinat, la scară precizată, raportate la suprafaţa unui întreg judeţ sau bazin hidrografic, sau parţial, pe zone selectate. Un exemplu de astfel de grupare în reprezentarea sistemului informaţional hidro-meteorologic şi operativ este prezentat în cele ce urmează:

reţeaua hidrografică ce traversează suprafaţa bazinului sau judeţului; amenajările hidrotehnice (baraje, lacuri de acumulare, amenajări piscicole,

aducţiuni, consolidări maluri, regularizări şi îndiguiri); localităţi; bazine hidrografice; căi de comunicaţie (drumuri, străzi, căi ferate, poduri); reţele tehnico edilitare (reţele electrice, reţele de alimentare cu apă, reţele de

canalizare, reţele telefonice, reţele de gaze etc.);

155

terenuri pe categorii de folosinţă; curbe de nivel; staţii hidro-meteorologice; comisii locale de apărare; lunci inundabile.

156

Fig. 8.7. Reprezentarea hărţii sistemului informaţional hidro-meteorologic şi operativ

Fig. 8.8. Reprezentare localităţi, staţii hidrometrice, cote, debite

157

Structura produsului software

Produsul software realizat pentru reprezentarea digitală şi monitorizarea zonelor expuse inundaţiilor este constituit din două componente realizate în tehnologie GIS şi anume:

componenta GEO-MAP; componenta HIDRO-MAP.

Componenta GEO-MAP

Componenta GEO-MAP tratează reprezentarea informaţiei grafice vectoriale ataşată informaţiei alfanumerice şi interogarea acesteia prin planuri şi hărţi şi a informaţiei raster rezultată prin scanare precum şi reprezentarea de informaţie vector suprapusă peste informaţie raster. Din punct de vedere structural această componentă este constituită din următoarele module:

Modulul de administrare a bazei de date, dezvoltare proiecte; Modulul CAD; Modulul de interogare a bazei de date; Modulul de interfaţare cu tipul de SGBD utilizat.Modulul de administrare a bazei de date şi de dezvoltare proiecte creează

suportul pentru funcţionarea întregului sistem, toate celelalte module ale componentei GEO-MAP utilizând informaţiile conţinute în fişierele create în cadrul acestui modul.În cadrul acestui modul este definit proiectul, sunt completate cataloagele cu informaţii despre tabelele utilizate, este definită structura tabelelor, relaţiile dintre tabele, cheile de acces, view-urile, regulile pentru legătura cu obiectele grafice corespondente.

Modulul CAD realizează următoarele funcţii: afişarea grafică a desenului; încadrarea obiectelor grafice în fereastra utilizator; umplerea cu culoare a obiectelor grafice; afişarea desenului conform setării straturilor; reprezentare simboluri; asigurare interfeţe I/O.În cadrul modulului CAD utilizatorul îşi stabileşte fereastra activă, scara, straturile,

poziţia şi dimensiunile ferestrei în care va fi reprezentată informaţia grafică. Modulul CAD realizează reprezentarea simbolisticii în cadrul planurilor sau hărţilor precum şi interfeţele cu plottere, imprimante, fişiere .DXF, digitizoare etc.

Modulul de interogare a bazei de date preia şi trimite comenzi de interogare de tip SQL către modulul de interfaţare cu tipul de SGBD utilizând structurile definite în cadrul modulului de administrare a bazei de date (cataloage, tabele, relaţii, reguli) şi către modulul CAD pentru accesarea informaţiei grafice. Legătura dintre obiectele grafice şi înregistrările asociate din baza de date se realizează utilizând textul ce reprezintă numele obiectului grafic şi asigură comunicarea între modulul de interogare a bazei de date şi modulul CAD. Textele reprezentând numele obiectelor grafice pot fi constituite din valori

158

ale unuia sau mai multor câmpuri din tabele corespunzătoare în baza de date şi sunt compuse sau descompuse automat în baza regulilor definite de utilizator în tabelele dicţionar ce descriu baza de date. Astfel la o interogare dinspre modulul de interogare a bazei de date. regula corespunzătoare va permite concatenarea informaţiei dispersate în mai multe câmpuri, creând un şir de caractere ce va fi utilizat în modulul CAD pentru identificarea obiectului grafic corespunzător.

La o interogare dinspre modulul CAD o astfel de regulă permite împărţirea şirului de caractere, reprezentând numele obiectului grafic, în câmpuri pentru a completa cheia de acces la înregistrarea bazei de date. În cazul interogării pe criterii se aplică aceeaşi regulă, însă vor fi baleiate toate înregistrările a bazei de date şi toate obiectele grafice pentru a fi evidenţiate prin colorare acele obiecte grafice care au îndeplinit criteriile precizate în cererea SQL de interogare formulată de utilizator.

Produsul pune la dispoziţia utilizatorului un mediu asistat pentru formularea cererilor de interogare facilitând astfel comunicarea între modulul de interogare a bazei de date şi modulul de interfaţare cu tipul de SGBD.

În abordarea acestei problematici s-au avut în vedere două variante de SGBD-uri: xBase şi client/server. Abordările au fost diferenţiate datorită inexistenţei pseudo-tabelelor de tip vedere (view) în cadrul bazei de date xBase. Componenta de tip vedere este o componentă practic indispensabilă în cadrul sistemelor GIS şi din acest motiv a trebuit creată prin software şi simulată, luând în considerare elementele ce definesc tabela de acest tip.

Modulul de interfaţare cu tipul de SGBD face independentă aplicaţia GIS de SGBD-ul utilizat. Utilizarea unui anumit SGBD presupune existenţa unui modul program specific pentru citirea şi interpretarea dicţionarelor definite în cadrul modulului de administrare a bazei de date.

În acest sens sunt realizate module program pentru SGBD-uri de tip xBase (dBASE, FoxPro etc.). Prin realizarea unor proceduri similare pentru alte tipuri de SGBD-uri ca de exemplu Oracle, SQL Server etc. produsul devine independent de SGBD-ul utilizat.

S-a adoptat această soluţie pentru a putea beneficia de tehnici oferite de diverse SGBD-uri privind:

optimizarea accesului; tehnologii client / server; administrarea distribuită; metode de protecţie a datelor.Fiecare modul comunică cu celelalte module prin comenzi şi mesaje de răspuns

sau coduri de eroare, având ca referinţă fişierele ASCII create prin modulul de administrare a bazei de date. şi dezvoltare de proiecte.

Valorile de câmpuri pentru relaţii, şirurile de caractere pentru identificare obiecte precum şi secvenţa SQL de interogare sunt generate automat prin selecţie din meniuri popup şi selecţie de obiecte grafice cu mouse-ul.

159

Componenta HIDRO –MAP

Componenta HIDRO-MAP realizează: monitorizarea zonelor expuse inundaţiilor la nivel de: judeţ, bazin hidrografic,

zonă; determinarea şi reprezentarea zonei inundate funcţie de cotele apelor măsurate

în două staţii consecutive: simularea zonelor inundate la formarea şi propagarea viiturilor; elaborarea de planuri de protejare, recuperare şi evaluare.Monitorizarea zonelor expuse inundaţiilor constă din: reprezentarea hărţii vectoriale a sistemului informaţional hidro-meteorologic; reprezentarea informaţiei în flux rapid prin evidenţierea zonelor în care se ating

sau depăşesc pragurile critice (cote de avertizare, cote de inundare, cote de pericol etc. );

reprezentare hidrografe pentru cote sau debite la un punct de măsurare (staţie) selectat.

Componenta foloseşte ca instrument de lucru harta sistemului informaţional hidro-meteorologic şi operativ, scanată şi digitizată în cadrul componentei GEO-MAP, asupra căreia se pot realiza operaţii de scalare, deplasare, interogare punctuală, utilizând principiile şi funcţiile definite în cadrul componentei GEO-MAP.

Reprezentarea variaţiei anumitor parametri (cote, debite, precipitaţii etc.) este realizată în cadrul hărţii sistemului, asigurând astfel localizarea zonelor monitorizate.Semnalizarea punctelor în care se ating sau se depăşesc pragurile critice se realizează sonor şi prin colorarea elementului grafic corespunzător.

Achiziţia datelor hidro-meteorologice în flux rapid, de la posturile şi staţiile de observaţie şi măsurare, răspândite pe teritoriul judeţului sau a bazinului hidrografic, este realizată în cadrul unui modul ce funcţionează independent de celelalte module din cadrul componentei HIDRO-MAP.

Pentru achiziţia datelor în flux rapid (cote, debite, temperaturi, precipitaţii etc.) sunt avute în vedere următoarele abordări:

transmiterea datelor de la punctele (staţiile) de măsurare la dispeceratul judeţean sau bazinal (SGA), prin reţeaua de comunicaţie (T, RT), unde sunt preluate în baza de date prin tastare;

transmiterea datelor on-line pe interfaţa serială, prin microcontrolere amplasate în punctele de transmisie (staţii hidrologice, staţii hidrometrice, staţii meteorologice şi posturi pluviometrice);

utilizarea unor staţii automate pentru achiziţia şi transmiterea datelor.În versiunea actuală sunt tratate primele două modalităţi de achiziţie şi transmitere

a datelor, urmând ca în perspectivă, în măsura dotării cu echipamente specializate, să fie tratată şi cea de-a treia modalitate.

160

Pentru fiecare staţie selectată, se poate solicita reprezentarea hidrografului, care evidenţiază variaţia unui anumit parametru (cotă, debit etc.) pe o perioadă de timp precizată sau pentru un număr de măsurători, putându-se totodată vizualiza ultimele valori achiziţionate pentru parametrul reprezentat.

Sistemul hidro-meteorologic şi operativ este reprezentat la nivelul hărţii digitale încărcate la startarea componentei HIDRO-MAP. Faţă de harta obişnuită (instrumentul de lucru al SGA-urilor), această reprezentare conţine şi o componentă dinamică, prin faptul că asigură o imagine în timp real a situaţiei hidro-meteorologice pentru zona aflată sub observaţie.

În cadrul fiecărei reprezentări, obiectele grafice sunt grupate pe straturi (layere) putând fi redate în totalitate sau parţial (cele activate) pentru întreaga reprezentare sau pentru o zonă selectată cu posibilitatea de mărire, micşorare şi redactare la scară precizată.

Determinarea şi reprezentarea zonei inundate funcţie de cotele apei măsurate în două staţii hidrometrice consecutive

Modelul elaborat în acest sens se bazează pe utilizarea de profile transversale realizate prin măsurători sau generate asistat în diverse puncte de pe traseul cursului de apă. Implementarea modelului propune parcurgerea a două faze şi anume:

generarea asistată de profile transversale; determinarea şi reprezentarea zonei inundate.Generarea asistată de profile transversale pe traseul cursului de apă se realizează

prin modelarea digitală a terenului utilizând curbele de nivel şi (eventual) puncte intermediare de cotă cunoscută reprezentate în planul utilizat ca document de intrare, plan care a fost în prealabil digitizat prin componenta GEO-MAP.

Există posibilitatea trasării de noi curbe de nivel prin interpolare numerică.Generarea unui profil transversal printr-un punct P prin modelarea digitală a

terenului este ilustrată în figura 8.9.

161

Fig. 8.9. Generarea unui profil transversalÎn exemplul ilustrat se constată că numărul punctelor PDi, PSi determinate pentru

profilul transversal prin P este mult superior în cazul existentei unor puncte de cote cunoscute (marcate cu x în exemplul dat) faţă de cazul când s-ar utiliza doar curbe de nivel. Cotele punctelor P pe cursul apei se determină prin interpolare numerică. Punctele ce definesc profilele transversale generate asistat şi cele realizate prin măsurători se vor memora urmând a fi utilizate ori de câte ori se cere determinarea şi trasarea zonei inundate.

Pentru determinarea zonei inundate cunoscând cotele apei în două staţii succesive din amonte spre aval se determină cotele apei în punctele de generare profile transversale prin metoda interpolării numerice presupunând panta uniformă între cele două puncte de măsurare. Pentru fiecare punct P se determină punctul din stânga şi cel din dreapta de cotă egală cu cota punctului P.

Zona inundată este definită de banda rezultată prin unirea punctelor stânga între ele şi unirea punctelor dreapta determinate. Peste zona astfel determinată şi reprezentată ca obiect grafic (culoare albastru) se vor suprapune şi alte straturi reprezentând obiective inundate, căi de acces etc. (vezi figura 8.10).

Cele trei zone aferente cotei de atenţie, inundare, evacuare pot fi marcate distinct în cadrul aceleaşi reprezentări.

162

Fig. 8.10. Determinarea zonei inundate utilizând profile transversale şi cotele apei măsurate în staţia amonte şi staţia aval

Elaborarea de planuri de protejare, recuperare şi evaluare

Aplicaţia de elaborare de planuri de protejare, recuperare şi reabilitare a zonelor afectate de calamităţi este lansată în momentul când se recepţionează un semnal de pericol de inundaţii de la calculatorul ce monitorizează staţiile de culegere automată a datelor meteorologice şi hidrologice.

Odată lansată, aplicaţia afişează pe ecran şi/sau tipăreşte la imprimantă: listă cu persoanele cu putere de decizie în coordonarea acţiunilor de salvare şi

modul cum pot fi contactate; numărul de persoane ce trebuie evacuate; reprezentarea zonelor de evacuare şi a traseelor de evacuare; listele cu unităţile şi formaţiunile de protecţie civilă ce trebuie să intervină şi

modul cum pot fi contactaţi membrii acestora; depozitele de materiale şi locul de parcare a mijloacelor de transport cu care se

va interveni în operaţiunile de salvare, tipul şi capacităţile acestora.După ce comisiile abilitate în evaluarea pagubelor au cules date suficiente pentru a

putea întocmi rapoarte statistice se pot afişa şi/sau tipări rapoarte privind: numărul familiilor şi persoanelor fără adăpost; numărul familiilor şi persoanelor cu locuinţe avariate; suprafaţa inundată; suprafaţa de cultură distrusă şi/sau compromisă; distrugerile în obiective industriale; kilometri de drumuri şi căi ferate avariate; reţelele distruse, valoarea pagubelor totală şi pe secţiuni.Produsul software realizat poate fi un instrument util pentru protecţia civilă (ISU) la

nivelul unui judeţ sau a unui bazin hidrografic şi a dispeceratului S.G.A. corespunzător, pentru monitorizarea zonelor expuse inundaţiilor, elaborarea planurilor de apărare şi a

163

variantelor de acţiune în lupta împotriva inundaţiilor, fenomenelor meteorologice periculoase şi a accidentelor la construcţiile hidrotehnice.

În perspectivă, pe măsura dotării cu echipamente adecvate, vor putea fi avute în vedere:

utilizarea unor staţii automate pentru achiziţia şi transmiterea datelor; transmiterea şi recepţia datelor în cadrul unor reţele de calculatoare; utilizarea unor instrumente de prognoză şi simulare asistată elaborate de

institutele de profil din ţară; elaborarea asistată a variantelor de acţiune pentru protecţia civilă.

8.3. Sistem bazat pe cunoştinţe destinat documentării şi cercetării asistate în genetica vegetală

Resursele genetice vegetale reprezintă toate formele de viaţă din domeniul vegetal: plantele sălbatice, formele vechi cultivate, soiurile şi populaţiile locale, buruienile, formele ameliorate, etc. Asigurarea securităţii alimentare în condiţiile exploziei demografice impune păstrarea resurselor genetice vegetale, în mod deosebit a celor ameninţate cu dispariţia şi identificarea de noi specii dintre cele sălbatice, susceptibile să devină noi plante de cultură. Se impune astfel colectarea, evaluarea şi conservarea resurselor genetice vegetale, în acest scop fiind create o serie de instituţii şi organisme naţionale şi internaţionale: Bănci de gene, Institutul Internaţional de Resurse Genetice Vegetale (IPGRI) cu sediul la Roma, Comitetul Naţional de Resurse Genetice Vegetale etc.

Conservarea resurselor genetice vegetale se face pe de o parte prin păstrarea lor în habitatele în care s-au format şi au evoluat (conservare “in situ”), iar pe de altă parte prin păstrarea în instituţii special create în acest sens şi anume: bănci de gene şi grădini botanice (conservare “ex situ”). Cea mai evoluată formă de conservare a resurselor genetice vegetale se realizează în băncile de gene care sunt instituţii dotate cu instalaţii ce asigură temperatura de conservare şi cu laboratoare, echipamente şi aparatură necesare caracterizării şi evaluării materialului genetic conservat. În acest sens în 1990 a fost înfiinţată Banca de Resurse Genetice Vegetale Suceava care are în componenţă o clădire ce ocupă o suprafaţă de 3550 metri pătraţi pentru laboratoare, birouri, oficiul de calcul, un compartiment pentru uscarea seminţelor, o cameră de creştere a culturilor “in vitro”, staţia frigorifică şi depozitul pentru conservarea probelor. Câmpul experimental al băncii are o suprafaţă de 1,250 ha din care 1 ha teren arabil şi 0,250 ha ocupate de 7 sere neâncălzite. Activitatea de colectare a resurselor genetice vegetale şi în special a populaţiilor de porumb la Suceava datează încă din anii 50, însă adevărata activitate ştiinţifică a început din 1987 odată cu fondarea Băncii de Gene Suceava. Principalele obiective ale Băncii de gene Suceava sunt explorarea şi colectarea, evaluarea şi conservarea resurselor genetice vegetale.8.3.1. Organizarea datelor în cadrul sistemului informatic

Datele privind materialul genetic conservat în Banca de Resurse Genetice Vegetale Suceava sunt stocate într-o bază de date care descrie intrările, reprezentând soiuri, populaţii, linii, hibrizi, obţinute din culturi, flora spontană, donaţii, schimb etc. Intrările

164

(probele) stocate în banca de gene aparţin unor specii de plante, fiecare specie fiind descrisă de un număr de atribute (descriptori). Datele descriptive pot fi însoţite de imagini reprezentând planta, sămânţa, frunza, etc., sau alte imagini obţinute prin analize microscopice. Corespunzător activităţilor de colectare, evaluare şi depozitare (conservare) probe (intrări) în banca de gene se vor obţine date de paşaport, date de evaluare şi date de conservare. Datele de paşaport şi datele de conservare (fişa de depozit) sunt comune tuturor speciilor, iar caracterizarea şi evaluarea diferă de la o specie la alta şi rezultă din prelucrări statistice efectuate asupra datelor obţinute din măsurători experimentale şi analize de laborator efectuate asupra unui număr de probe. Cu alte cuvinte activităţile de colectare şi depozitare probe sunt descrise de aceleaşi atribute pentru toate speciile, iar caracterizarea şi evaluarea sunt descrise de atribute diferite de la o specie la alta.

Pentru fiecare din cele trei tipuri de date sunt prezentate, în cele ce urmează, câteva exemple cu menţiunea că în definirea structurii datelor trebuie avută în vedere posibilitatea adăugării de noi descrieri (structură evolutivă).

Date de paşaport: Nr.intrare, Denumire intrare, Clasificare taxonomică (Genul, Specia, Subspecia, Varietatea), Originea (Localitatea, Judeţul (zona), Ţara), Data colectării, Sursa colectării, Date geografice (Altitudine, Latitudine, Longitudine)…

Date de de conservare: Cod depozit, Număr probă, Germinaţia, Stoc de seminţe, Umiditatea, Masa a 1000 boabe …

Date de evaluare (ex. pentru specia zea mays): Locul evaluării (Ţara, Instituţia de cercetare, Persoana care a făcut evaluarea), Date despre plantă (Înălţimea totală a plantei, Diametrul mediu al tulpinii, Numărul total de frunze), Măsurători la ştiulete (Lungimea, Diametrul la bază, Diametrul la vârf, Numărul de rânduri de boabe, Greutatea ştiuletelui,…).

Fiecare soi din cadrul unei specii va fi definit de valori corespunzătoare ale atributelor ce definesc specia respectivă. Din exemplele prezentate se poate constata că descrierea materialului genetic conservat în banca de gene reprezintă preponderent cunoştinţe a căror prelucrare se poate realiza în cadrul unui sistem bazat pe cunoştinţe, care să conţină componente de interfaţă cu limbaje de programare de nivel înalt, sisteme de gestiune a bazelor de date, şi anumite aplicaţii de inteligenţă artificială.

În modelul de date relaţional o structură extensibilă a bazei de date este definită de următoarele scheme de relaţie (tabele):SPECII (Cod_s, Denumire_s) -catalogul speciilor de planteDESCRIPTORI (Cod_d, Denumire_d, Tip_d) –lista atrib unde: Tip_d = 1 – colectare, 2 – evaluare, 3 - conservareD_SPECII (Cod_s, Cod_d) –definire speciiINTRARI (Cod_s, Cod_i, Denumire_i) –lista intrărilor (soiurilor) pe speciiD_INTRARI (Cod_i, Cod_d, Val_d) – definire intrări A_GEN (Cod_fiu, Cod_parinte) – genealogii intrări (arbori genealogici)

În această reprezentare, definirea entităţilor în baza de date se realizează prin încărcarea tabelelor de mai sus, deci structura bazei de date este o structură evolutivă cu un grad ridicat de generalitate, care se extinde dinamic prin simpla încărcare a tabelelor bazei de date.

165

În figura 8.12. sunt ilustrate activităţile de colectare, evaluare şi depozitare intrări în Banca de gene şi înregistrarea datelor rezultate în registre şi în baza de date .

166

SPECII

SOIURI DESCRIPTORI

VALORI

GENEALOGIE

SPEC_SOI SPEC_DES

SOI_GEN

GEN_SOI

SOI_VAL DES_VAL

Fig. 8.11. Diagrama structurii datelor

167

SPECII INTRĂRI (probe) din:

Culturi

Flora spontană

Donaţii

Schimb………Grâu

Linii

Populaţii

Soiuri

Hibrizi………

Porumb

FasoleOrz…….

Colectareprobe

LaboratoareEvaluare

probe

Date de paşaport

Date experimentale

Prelucrări statistice

Date de evaluare

Înregistrare date

Date de conservare

DepozitConservare

probe

Baza de date

Registre

Culturi in vitro

Ierbar

Fig. 8.12. Activităţi desfăşurate în Banca de Resurse Genetice Vegetale Suceava

Colectare, evaluare şi depozitare probe Înregistrare date

Pentru documentare privind materialul genetic conservat în banca de gene se pot formula următoarele cereri de interogare a bazei de date: catalogul speciilor de plante, descriere specie precizată, lista intrărilor aparţinând unei specii, raport documentar intrare (descriere intrare) precizată, genealogie intrare (arborele genealogic), lista intrărilor ce satisfac condiţii precizate în momentul interogării.

Arborele genealogic poate fi reprezentat, fie printr-o descriere de forma:

Intrarea “i” provine din:

- “i1”- “i2”

“i2” provine din:

- “i21”- “i22”

“i21” provine din:

- “i211”- “i212”

…………………

, fie grafic printr-o structură arborescentă ilustrată în figura 8.13.

Astfel de descrieri pot fi realizate prin interogări ale bazei de date cu ajutorul unor proceduri de tip recursiv.

Descriptorii utilizaţi pentru datele de conservare sunt specifici Băncii de gene Suceava şi definesc următoarele date: numărul de intrare, codul de depozit, genul, specia, subtaxa, ţara de origine, luna depozitării, anul depozitării, anul ultimei reânmulţiri, anul ultimei germinaţii, stocul, umiditatea, masa a 1000 seminţe, numărul de reânmulţiri;

Descriptorii ce definesc datele de paşaport sunt cei recomandaţi de Institutul Internaţional de Resurse Genetice Vegetale IPGRI cu sediul la Roma, sunt preluaţi în

168

Intrare i

i1 i2

i22 i21

i211 i212

…………Fig. 8.13. Reprezentare grafică arbore genealogic (genealogie intrare)

baza de date în limba engleză şi există posibilitatea accesării datelor de paşaport privind materialul genetic conservat în banca de gene, prin reţeaua Internet [74].

8.3.2. Arhitectura unui sistem bazat pe cunoştinţe în genetica vegetalăMediile de dezvoltare ale sistemelor bazate pe cunoştinţe existente la ora actuală

au componente de interfaţă cu limbaje de programare de nivel înalt, orientate pe obiecte, sisteme de gestiune a bazelor de date, etc., iar anumite aplicaţii de inteligenţă artificială sunt dezvoltate în limbaje cum ar fi C, Prolog, ADA, etc. În acest context, componentele principale ale unui sistem bazat pe cunoştinţe în genetica vegetală sunt: Crearea şi administrarea bazei de date, Interogarea bazei de date, Prelucrarea statistică a datelor, Aplicaţii de inteligenţă artificială.

Datele şi cunoştinţele ce urmează a fi memorate şi prelucrate în cadrul unui sistem în domeniul geneticii vegetale referă soiuri aparţinând unor specii de plante de cultură şi din flora spontană care sunt supuse fenomenului de eroziune genetică şi agresiunii factorilor patogeni (fitopatologia) şi factorilor de mediu. Descrierea plantelor şi experimentele efectuate în domeniul vegetal generează două categorii de date şi anume: 1. date descriptive, 2. date experimentale. Datele ce descriu materialul genetic (datele descriptive) sunt preponderent cunoştinţe care vor fi reprezentate în baza de date în cadrul unei structuri evolutive de date de tip universal. Aceste date pot fi însoţite de imagini (plantă, frunză, rădăcină, sămânţă, etc.).

În studiul organismelor vii se impune a se face deosebire între caracteristicile observabile (ceea ce se vede) şi ceea ce determină (cauzează) aceste caracteristici deoarece s-a constatat că două organisme ce rezultă din acelaşi părinte, deci care au aceeaşi ereditate, pot avea aspecte morfofiziologice diferite dacă condiţiile de viaţă sunt diferite. În acest sens, pentru a defini deosebirile existente între organisme cu aceeaşi origine şi cu aceeaşi ereditate dar deosebite în ceea ce priveşte aspectul corpului, în 1909 genetistul danez W.Johannsen a definit conceptele de genotip şi fenotip astfel [15]:

genotipul reprezintă totalitatea genelor şi plasmagenelor (suma totală a informaţiei genetice) dintr-un organism;

fenotipul reprezintă totalitatea caracteristicilor (proprietăţilor) unui organism la un moment dat (dimensiuni, comportare, formă, culoare, funcţii fiziologice, compoziţie chimică, structură internă sau externă, microscopică sau macroscopică, etc.) rezultate prin interacţiunea dintre genotip şi mediul în care se dezvoltă organismul respectiv.

Fiecare caracteristică a unui organism este determinată de anumite gene şi în timp ce fenotipul se modifică pe parcursul vieţii organismului respectiv, genotipul este relativ constant (un organism are aceleaşi gene pe tot parcursul vieţii). Corespunzător celor două concepte, în structura bazei de date a sistemului bazat pe cunoştinţe în genetica vegetală, se va descrie genotipologia respectiv fenotipologia. Având în vedere faptul că fiecare specie este caracterizată de un anumit număr de cromozomi, genele sunt particule materiale ce ocupă poziţii stabile în cromozomi fiind aranjate în ordine liniară de-a lungul cromozomului ca mărgelele într-un şirag, s-a reuşit să se întocmească hărţi ale cromozomilor la diverse specii. Un exemplu de reprezentare a unei hărţi genetice este

169

ilustrat în figura 8.14 care redă harta genetică pentru specia Orz, realizată în cadrul modelului virtual al orzului, de H.Buck-Sorlin (1999-2002) utilizând vlab (laborator virtual în botanică) care a fost realizat de Przemyslaw Prusinkiewicz bazat pe L-systems (o parte a unui limbaj de rescriere propusă de biologul olandez Aristid Lindenmayer în1968). Tabelul T.8.3.1. conţine toate genele care afectează lungimea tulpinii şi alte aspecte ale morfologiei plantei. Pentru fiecare genă este prezentat simbolul, descrierea şi încadrarea sa în una din cele şapte grupe de cromozomi (7H, 2H, 3H, 4H, 1H, 6H, 5H) [76].

T8.3.1. Identificare gene [76]

Symbol Description Chr

brh1 Brachytic 1 7H

brh2 Brachytic 2 4H

clh Curled leaf dwarf (s.a. leaf mutants and curly mutants) 1H

cud 2 Curly dwarf 2 (s.a. leaf mutants and curly mutants) 1H

cud1 Curly dwarf 1 (s.a. leaf mutants and curly mutants) 5H

hcm Short culm 2H

lzd Lazy dwarf 3H

min Semi-minute dwarf 1 4H

nld Narrow leafed dwarf (s.a. leaf mutants) 5H

sdw1 Semidwarf 1 3H

sdw2 Semidwarf 2 3H

170

a) b) Fig. 8.14. Reprezentare hartă genetică pentru specia Orz [EVAM99] a) reprezentare grupe de cromozomi; b) reprezentare gene

sid Single internode dwarf 4H

sld slender dwarf 1 3H

sld 2 Slender dwarf 2 2H

uzu Uzu or semi brachytic 3H

wnd Winding dwarf (s.a. curly mutants) 7H

Zeo1 Zeocriton 1 2H

171

O altă categorie de informaţii care poate fi prevăzută în baza de date şi cunoştinţe a sistemului o reprezintă descrierea codului genetic având în vedere compoziţia fiecărei gene. În cele ce urmează este definită o reprezentare simbolică a codului genetic conform [15].

După cum afirma E. Schrödinger încă din 1956 “Filamentul cromozomic cuprinde, cifrată într-un fel de cod miniatural, întreaga devenire a organismului, întreaga sa dezvoltare şi funcţionare … Structurile cromozomice deţin, de asemenea, mijloacele de a executa acest program.”. În segmentul de ADN şi ARN viral corespunzător fiecărei gene, mesajul este înregistrat prin combinarea unor simboluri asemănător alfabetului Morse, fiind utilizate în acest sens următoarele 4 simboluri chimice corespunzătoare celor 4 baze azotate: A(adenina), G(guanina), C(citozina) si T(timina) sau U(uracilul) la ribovirusuri, care intră în constituţia macromoleculei de ADN (A,G,C,T) sau a macromoleculei de ARN (A,G,C,U). Cele patru simboluri formează alfabetul. Din combinarea simbolurilor aşa cum în sistemul Morse se obţin cuvintele, în sistemul genetic se formează codonii, iar din asocierea cuvintelor aşa cum în sistemul Morse rezultă frazele, în sistemul genetic din asocierea codonilor rezultă genele.

Codul genetic reprezintă corespondenţa dintre grupele de nucleotizi din moleculele de acizi nucleici din gene şi aminoacizii incluşi în proteinele sintetizate de către acestea. Toată informaţia genetică a unui organism este conţinută într-un grup linkage (un cromozom la bacterii şi viruşi) sau în două sau mai multe grupe linkage (doi sau mai mulţi cromozomi) la celelalte organisme.

Având în vedere faptul că există 20 aminoacizi care intră în compoziţia proteinelor, rezultă că o secvenţă de 3 simboluri (din cele patru) poate realiza codificarea celor 20 de aminoacizi (un simbol poate codifica doar 4 aminoacizi, o secvenţă de două simboluri poate codifica 42=16 aminoacizi, iar numărul total de secvenţe de 3 simboluri este 43=64 combinaţii posibile). Din cei 64 codoni, 61 reprezintă codoni cu sens (semnifică un anumit aminoacid) iar trei reprezintă codoni nonsens. Din cei 61 codoni cu sens, 2 se numesc codoni de iniţiere (AUG, GUG) şi se află la începutul fiecărui mesaj genetic. Codonii nonsens sunt UAA, UAG, UGA şi au rolul de a indica separarea genelor, fiind numiţi din acest motiv şi codoni stop.

Cercetările complexe efectuate de F. H. C. Crick şi colaboratorii săi încă din anii 60 au condus la următoarea concluzie: codul genetic este reprezentat prin codoni (triplete formate plecând de la cele 4 simboluri) cu menţiunea că doi codoni succesivi nu se suprapun (nu au nici un nucleotid comun), între codoni nu există semne speciale care să marcheze începutul sau sfârşitul codonului (nu există „virgule biochimice”), iar o genă este o secvenţă de codoni care începe şi se sfârşeşte cu semne speciale, citirea genei făcându-se liniar de la începutul spre sfârşitul ei.

După cum afirma J. D. Watson (1974), o genă de dimensiune medie conţine 900 perechi de nucleotizi (obişnuit între 600 şi 1800) împărţită în 300 de codoni (tripleţi de baze, fiecare triplet codificând un aminoacid), deci mărimea medie a unei proteine este de 300 aminoacizi.(obişnuit între 200 şi 600).

Având în vedere aspectele prezentate mai sus, precum şi rezultate obţinute la nivel mondial se poate concluziona că o reprezentare cât mai completă a informaţiilor privind

172

genomul la nivel de specie poate fi realizată în cadrul unui SGBD cu facilităţi de orientare spre obiecte.

În contextul problemelor prezentate, arhitectura generală a unui sistem bazat pe cunoştinţe pentru documentare şi cercetare asistată în genetica vegetală este reprezentată în schemele din figurile 8.15, 8.16.

173

Fig 8.15. Schema generală a unui sistem bazat pe cunoştinţe în genetica vegetală

175

176

Fig 8.16. Schema bazei de date

177

8.3.3. Probleme specifice cercetăriiProbleme specifice cercetării, tratate în cele ce urmează, în cadrul sistemului bazat

pe cunoştinţe în genetica vegetală sunt: recunoaşterea populaţiilor şi clasificarea lor; diagnosticarea rezistenţei plantelor la boli.

Recunoaşterea populaţiilor şi clasificarea lor În activitatea de conservare a resurselor genetice vegetale în banca de gene, o

atenţie deosebită este acordată populaţiilor locale deoarece acestea constituie un important material iniţial de ameliorare. În acest sens, cercetările în domeniu vizează:

recunoaşterea populaţiilor şi clasificarea lor; determinarea relaţiei dintre mărimea populaţiei de reproducere şi

particularităţile genetice ale descendenţilor la anumite specii (exemplu porumb);

determinarea corelaţiilor dintre caracteristici şi valorile optime ale unor parametri pentru obţinerea unor soiuri cu anumite caracteristici prestabilite.

Problemele de clasificare şi recunoaştere pot fi soluţionate prin metode specifice domeniului inteligenţei artificiale (recunoaştere forme, baze de cunoştinţe şi sisteme expert, reţele neuronale), iar problemele de optimizare, prin definirea şi utilizarea unor modele regresionale.

Clasificarea şi recunoaşterea populaţiilor de porumbAvând în vedere diversitatea porumbului şi lipsa unor criterii clare de demarcare

între formele existente în cadrul genului Zea mays pentru care polenizarea este încrucişată şi deci există un schimb genic continuu între populaţii, au existat numeroase încercări de clasificare încă din perioada introducerii porumbului în Europa. Sistemele de clasificare cele mai răspândite aparţin lui Sturtevant (1899) – reprezentant de frunte al clasificării artificiale şi lui Anderson şi Cutler (1942) – reprezentanţi ai sistemului natural de clasificare. Deoarece clasificarea artificială a lui Sturtevant se bazează pe puţine informaţii, nefiind oglindite relaţiile filogenetice, există posibilitatea ca unele forme diferite filogenetic să fie incluse în aceeaşi grupă sau forme asemănătoare filogenetic să fie incluse în grupe diferite.

Clasificarea naturală a lui Anderson şi Cutler se bazează pe întreaga constituţie genetică, pe studii genetice, citologice, fiziologice, agronomice şi arheologice, fiind mult mai elastică şi mai complexă, oferind posibilitatea includerii întregii varietăţi a porumbului, însă mult mai greu de abordat având în vedere volumul mare de informaţii ce trebuie luat în considerare. În clasificarea naturală a porumbului se utilizează noţiunea de rasă ca unitate taxonomică de bază. Din punct de vedere genetic, rasa poate fi considerată ca un grup de indivizi care au un număr semnificativ de gene în comun. Rasele majore au un număr mai mare de gene în comun decât subrasele. La nivel superior rasei se situează complexul rasial care poate fi definit ca un grup de rase cu caracteristici distinctive comune: morfologice, biologice şi de areal. La nivel inferior rasei se află populaţiile locale care sunt grupuri de indivizi, care se deosebesc de indivizii celorlalte populaţii ce

compun rasa, prin una sau mai multe însuşiri de detaliu. Folosirea conceptului de rasă în clasificarea naturală a porumbului trebuie să pornească de la faptul că rasele trebuie considerate ca grupuri mari şi orice analiză a elementelor rasiale trebuie să fie în primul rând o analiză a grupurilor şi nu a unor indivizi izolaţi.

Având în vedere faptul că la porumb faţă de alte plante de cultură, polenizarea este încrucişată şi deci procesul de eroziune genetică este mai accentuat, în perioada 1975-1985 la Staţiunea de Cercetări Agricole Suceava s-au efectuat experimente şi evaluări pentru soiurile de porumb Hângănesc, Cincantin, Suceava 1, din care a rezultat un important fond de date reprezentând valorile măsurate pentru 30 de descriptori (date de evaluare) pentru fiecare variantă de înmulţire. În cadrul experimentelor efectuate s-au utilizat 20 de variante de înmulţire, fiecare variantă fiind particularizată de numărul de mame şi numărul de taţi folosiţi la înmulţire. Dintre caracteristicile ce definesc soiurile de porumb, s-au luat în considerare acele caracteristici (descriptori) care diferă de la o variantă la alta (30 parametri) şi anume:

Măsurători la plantă:

Înălţimea totală a plantei Numărul total de frunze

………………………….. Măsurători la ştiulete: Lungimea ştiuletelui Greutatea ştiuletelui Diametrul ştiuletelui la bază

………………………….. Măsurători la bob Lungime bob Lăţime bob Grosime bob

…………………………..

Prelucrarea acestor date viza soluţionarea următoarelor probleme:1. determinarea variantei de înmulţire cea mai apropiată de soiul martor;2. determinarea variantei optime de înmulţire pentru păstrarea caracterelor soiului

martor.Întrucât prin prelucrări statistice nu s-au obţinut răspunsuri satisfăcătoare la

întrebările puse, s-a optat pentru utilizarea unor instrumente ale inteligenţei artificiale. Problemele de clasificare şi recunoaştere sunt rezolvate prin tehnici specifice recunoaşterii formelor.

În cadrul Subsistemului de Recunoaşterea formelor, fiecare intrare în banca de gene reprezintă o formă iar mulţimea descriptorilor ce descriu specia respectivă, sau o submulţime a lor (datele de evaluare) prin valorile ce definesc intrarea respectivă reprezintă mulţimea caracteristicilor formei. De asemenea fiecare din variantele de înmulţire utilizate în cadrul experimentelor efectuate reprezintă o formă. Pentru

179

clasificarea şi recunoaşterea formelor se utilizează programul REFORME realizat de autori. Prin utilizarea tehnicilor de recunoaşterea formelor se obţin ieşiri în diverse reprezentări printre care: liste, grafice, ce descriu apartenenţa la o clasă, gruparea în clase. În cele ce urmează sunt prezentate rezultate obţinute prin utilizarea subsistemului de Recunoaşterea formelor pentru experimentele cu soiul Hângănesc.

Fiecare formă este reprezentată pe un rând în foaia de calcul Excel după cum este ilustrat în figura 8.17. Descrierea soiului martor este redată în figura 8.18. Datele de intrare sunt normalizate prin metoda ajustării domeniului (figura 8.19). După efectuarea unei clasificări nesupervizate utilizând algoritmul de prag cu distanţa euclidiană, pentru valoare prag = 1.5, se obţine rezultatul ilustrat în figura 8.20. Se poate constata că cele 100 forme au fost grupate în 4 clase, 85% din forme fiind repartizate în clasa 0.1. La determinarea clasei cele mai apropiate de soiul martor prin regula celui mai apropiat vecin se obţine clasa 0.1. şi varianta la distanţa minimă faţă de soiul martor prezentată descriptiv în figura 8.21. În figura 8.22 sunt reprezentate soiul martor şi varianta la distanţa minimă de martor raportat la valorile celor 30 de descriptori.

Fig. 8.17. Date iniţiale (1 martor, 100 variante de înmulţire)

180

Fig. 8.19. Date iniţiale normalizate

Fig. 8.18. Valorile caracteristicilor pentru soiul martor

181

Fig. 8.20. Clasificare nesupervizată prin algoritmul de prag cu distanţă euclidiană

Fig. 8.21. Varianta la distanţa minimă de martor

Fig. 8.22. Reprezentarea soiului martor şi a variantei cele mai apropiate de soiul martor

182

183

8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorită depozitării necontrolate a deşeurilor

8.4.1. IntroducereLucrarea prezintă realizări în cadrul proiectului de cercetare CEEX „Sistem

telematic pentru managementul on-line al zonelor intravilane degradate – ZoneMAP” în cadrul programului INFOSOC în perioada 15.09.2006 – 30.08.2008. Obiectivul general al proiectului ZoneMAP constă în realizarea unui sistem telematic pentru managementul şi monitorizarea on-line a zonelor intravilane degradate datorită depozitării necontrolate a deşeurilor, prin elaborarea unui sistem electronic de poziţionare geografică GPS/GIS.

Autorii lucrării au participat la realizarea următoarelor componente ale sistemului: definirea arhitecturii generale a sistemului; proiectarea bazei de date a sistemului.Lucrarea se înscrie în aria tematică „Tehnologii informaţionale şi de comunicaţii”,

care reprezintă una din temele prioritare în cadrul programului de cercetare şi dezvoltare tehnologică PC 7 pentru anii 2007-2013. Programul de localizare geografică a zonelor afectate din punct de vedere ecologic, utilizând tehnologiile GPS / GIS stă la baza sistemului integrat de asistare electronică a deciziilor în domeniul protecţiei zonelor intravilane. Drept criteriu de selecţie a metadatelor s-a ales riscul antropic asupra spaţiului intravilan, risc generat de depozitarea necontrolată a deşeurilor urbane. Lucrarea de faţă oferă suportul pentru controlul localizării şi monitorizării depozitelor ilegale de deşeuri şi poate fi utilizată ca tehnologie multimedia pentru furnizarea de informaţii referitoare la zonele afectate de poluarea antropică. Lucrarea prezintă soluţiile tehnice, metodologice şi tehnologice pentru implementarea modelelor de producţii economic eficiente şi sănătoase pentru mediu, promovate prin managementul integrat al deşeurilor. Se vizează dezvoltarea nivelului de educaţie şi conştientizare a cetăţenilor în domeniul conservării resurselor şi managementului deşeurilor pentru protecţia mediului intravilan prin generarea de alternative civic atractive în spiritul dezvoltării durabile şi accesarea unor module de informare.

Obiectivul principal al lucrării constă în monitorizarea zonelor afectate de depozitarea necontrolată a deşeurilor prin utilizarea celor mai noi tehnologii informaţionale şi de comunicaţii prin elaborarea unui sistem electronic de poziţionare geografică GPS/GIS.

Gestionarea deşeurilor, componentă importantă a oricărei strategii de mediu, se referă la activităţile de colectare, transport, tratare, valorificare şi eliminare a acestora. Datele privind gestionarea deşeurilor în România fac distincţie între două categorii importante de deşeuri:

deşeuri municipale şi asimilabile din comerţ, industrie şi instituţii, deşeuri din construcţii şi demolări şi nămoluri de la staţiile de epurare orăşeneşti;

deşeuri de producţiePrin culegerea automată a datelor de mediu, meteorologice şi ecologice, se

urmăreşte realizarea unui sistem de monitoring, dotat cu senzori şi/sau traductori, capabili să măsoare şi să traducă (în semnale electrice) mărimi cu caracter meteorologic (cum

184

sunt: intensitatea radiaţiei solare, temperatura, umiditatea, ş.a.), dar şi mărimi de stare ale sistemului ecologic (ex. concentraţii de nutrienţi în apă şi sol, poluanţi în aer, apă si sol, pH, biomase). Mărimile astfel achiziţionate sunt convertite în valori numerice ce vor fi stocate în baza de date a sistemului. Având în vedere faptul că datele de mediu sunt achiziţionate periodic (la diverse intervale de timp), baza de date a sistemului este o bază de date temporală, ceea ce înseamnă că pe lângă datele curente, baza de date conţine şi date istorice, iar factorul (atributul) timp are un rol esenţial.

În cadrul sistemului telematic pentru managementul on-line al zonelor intravilane degradate sunt definite următoarele categorii de date:

date privind gestionarea deşeurilor (zone intravilane monitorizate, deşeuri, surse de poluare, depozite deşeuri, staţii de prelucrare deşeuri ;

date privind protecţia mediului (parametri calitate mediu: apă, aer, sol); date spaţiale (hărţi tematice).Baza de date a sistemului este o bază de date distribuită pe următoarele nivele: serverul central de baze de date (SQL server Microsoft); serverele locale de baze de date (Microsoft ACCESS).Organizarea, descrierea şi prelucrarea datelor spaţiale necesită utilizarea unui

produs de tip GIS. Sunt disponibile pe piaţă mai multe soluţii printre care: ArcINFO de la ESRI, AutoCAD Map de la Autodesk, GEOMEDIA de la INTERGRAPH, care sunt produse realizate în S.U.A. şi au un preţ relativ ridicat. Există însă şi soluţii realizate în România (de exemplu, NetSET de la Data Invest şi MapSys de la Geotop) al căror preţ este mai accesibil. Este avut în vedere pachetul NetSET, care oferă un foarte bun raport între preţ, performanţe şi facilităţi oferite, acoperind practic toate aspectele dezvoltării aplicaţiilor GIS. În plus, lucrează cu hărţi vectoriale în format shape, compatibil la nivel internaţional cu alte pachete de programe similare.

8.4.2. Definirea arhitecturii generale a sistemuluiSistemul este compus din mai multe (sub)sisteme telematice, denumite „staţii

locale”, legate atât între ele cât şi cu „staţia centrală”. Sistemul automat de monitorizare a depozitului central de deşeuri al municipiului Suceava se compune din două subsisteme:1. Subsistem LOCAL,2. Subsistem DISPECER.

Subsistemul local se compune din: a) Traductoare, sensori, detectoare etc., b) Echipament local.

Subsistemul DISPECER se compune din: Echipament dispecer , Calculator tip PC, Imprimanta, UPS. Dispecerul este prevazut în exterior cu o antenă tip GSM/GPRS. Echipamentul dispecer se compune dintr-o cutie Automatica tip CA13 în interiorul căreia se află staţia de recepţie GSM / GPRS tip Metrilog T707.Arhitectura generală a sistemului este reprezentată în figura 8.23.

Metrilog T707 este o staţie de transmitere date bazată pe standardele de protocoale deschise. Sistemul de comunicaţii foloseşte reţelele GSM, transmisia de date făcându-se folosind standardul GSM/GPRS (General Packet Radio Service). În cazul folosirii strict a

185

protocolului GPRS se menţionează faptul că nu mai este necesară şi staţia de recepţie de la dispecerat deoarece recepţionarea datelor din teren se poate face prin reţeaua Internet (staţia GPRS de pe teren transmite datele către un server al operatorului local de telefonie mobilă care oferă serviciul de GPRS, iar preluarea datelor de pe acest server se va face cu ajutorul unui program de achiziţie realizat în cadrul activităţilor de implementare a proiectului ZoneMAP de către IPA SA, partener în echipa proiectului).

Staţia T707 foloseşte conceptul de BUS, astfel încât se acceptă cuplarea simultană a unui număr mare de traductoare: actuala staţie poate eşantiona un numar de max. 50 de traductoare.

Staţii de achiziţie dateÎn funcţie de complexitatea şi numărul de parametrii achiziţionaţi din fiecare punct

de măsură, în cadrul sistemului se definesc următoarele tipuri de staţii: staţii de achiziţie hidrometrice (achiziţionează nivelul în apele de suprafaţă,

temperatura atmosferică, calitatea apelor de suprafaţă şi din pânza freatică); staţii pluviometrice (achiziţionează parametrii în funcţie de configuraţia staţiei: nivel,

temperatură şi precipitaţii);

Puncte pluviometrice şi staţii achiziţie din puţuri de foraj

Sistemul Central de prelucrare a informaţiilor

(Server Baze de Date)+

Imprimantă

Sistem de comunicaţie

GSM

Senzori + Traductori

Dispecer central

nivel comunicaţie(datalogger, radio/GSM modem)

nivel local (traductoare) Aria

monitorizată

Figura 8.23. Arhitectura generală a sistemului

186

staţii de achiziţie din puţurile de foraj (achiziţionează date referitoare la variaţia nivelului pânzei freatice în forajele de urmărire şi de exploatare, precum şi calitatea apelor);

staţii portabile pentru achiziţia datelor de la puţurile de foraj şi transferul lor în baza de date la dispecerul zonal.

8.4.3. Proiectarea bazei de date a sistemuluiBaza de date a sistemului este o bază de date distribuită pe următoarele nivele:

serverul central de baze de date (SQL server Microsoft); serverele locale de baze de date (Microsoft ACCESS).Arhitectura generală a bazei de date este reprezentată în figura 8.24.

Schema conceptuală a bazei de dateDatele privind gestionarea deşeurilor sunt grupate în următoarele două categorii:

date privind deşeurile municipale şi asimilabile din comerţ, industrie şi instituţii, deşeuri din construcţii şi demolări şi nămoluri de la staţiile de epurare orăşeneşti;

date privind deşeurile de producţieÎn cadrul sistemului telematic pentru managementul on-line al zonelor intravilane

degradate sunt definite următoarele categorii de date: date privind gestionarea deşeurilor (zone intravilane monitorizate, deşeuri,

surse de poluare, depozite deşeuri, staţii de prelucrare deşeuri ; date privind protecţia mediului (parametri calitate mediu: apă, aer, sol);

Internet GSM

Central Server

user 1

user p

.

.

.

.

.

.

..

user p+1

user p+t

.

.

.

.

.

.

.

.

.

LocalServer 1

Local Server n

Local Server

n+1

LocalServer

n+m

Figura 8.24. Arhitectura bazei de date a sistemului

187

date spaţiale (hărţi tematice).Pentru modelarea logică a datelor se pleacă de la diagrama entitate-relaţie de

ansamblu a sistemului reprezentată în figura 8.26. În diagrama entitate-relaţie sunt reprezentate tipurile de entităţi: zone intravilane

monitorizate, deşeuri, surse de poluare, depozite deşeuri, parametri calitate mediu, hărţi tematice.Date privind gestionarea deşeurilor

Având în vedere entităţile reprezentate în schema conceptuală a bazei de date, se definesc, în cele ce urmează, schemele de relaţie (tabelele) bazei de date pentru sistemul de monitorizare, precum şi exemple de completare.Tabelul 8.4.1.Tipuri deşeuri

Grupa Tipuri principale de deşeuri Cod deşeu Unitate de măsură

1 Deşeuri municipale şi asimilabile din comert, industrie, institutii, din care:

20 15 01 Tone

1.1 Deşeuri menajere colectate in amestec de la populatie

20 03 01 Tone

1.2. Deşeuri asimilabile colectate in amestec din comert, industrie, institutii

20 03 01 Tone

1.3. Deşeuri municipale şi asimilabile colectate separat (exclusiv deşeuri din constructii şi demolari), din care: *

20 01 15 01 Tone

1.4. Deşeuri voluminoase 20 03 07 Tone1.5. Deşeuri din gradini şi parcuri 20 02 Tone1.6. Deşeuri din piete 20 03 02 Tone

1.7. Deşeuri stradale 20 03 03 Tone

1.8. Deşeuri generate şi necolectate ** 20 01 15 01 Tone2 Nămoluri de la statii de epurare orăşeneşti, din

care: 19 08 05 Tone

2.1 Cantitate valorificată (s.u.) 19 08 05 Tone2.2 Cantitate depozitată (s.u.) 19 08 05 Tone3 Deşeuri din constructii şi demolări, din care: 17 Tone3.1 Deşeuri inerte 17.05.03 Tone

3.2 Deşeuri în amestec 17.05.02 Tone

Tabelul 8.4.2.Zone monitorizateCod zonă

Denumire zonă / localitate Populaţia totală Reprezentări GIS

30 Judeţul Suceava 705555 Hyperlink30.1 Municipiul Suceava 108076 Hyperlink30.2 Municipiul Fălticeni 30800 Hyperlink30.3 Municipiul Rădăuţi 29417 Hyperlink30.4 Municipiul Câmpulung Moldovenesc 20572 Hyperlink

188

Tabelul 8.4.3.Deşeuri generateGrupa Cod deşeu Anul Cantitate Cod zona

1 20 15 01 2002 183363 301.1 20 03 01 2002 103485 301 20 15 01 2003 149448 301.1 20 03 01 2003 75956 30

Tabelul 8.4.4.Staţii prelucrare deşeuriCod staţie Denumire staţie / localitate

30.1 SC DIASIL SERVICE SRL Suceava, str. Grigore Al Ghica, nr.1830.2 SC AMBRO SA Suceava, Calea Unirii, nr.2430.3 SC OMT METAL SRL Gura Humorului, str. Gării Păltinoasa, fn30.4 SC COREMAT IS SRL Fălticeni, str. Topitoriei, fn30.5 SC COM REMAT SRL Iaşi, punct de lucru Suceava, Calea Unirii, nr.1430.6 SC COMREMAT SRL Vatra Dornei, str. Bistriţei, nr.2A30.7 SC SIMOTAB SRL Suceava, Gara Suceava Vest30.8 SC NICOTEX SRL Suceava, str. Mirăuţi, nr.19

Tabelul 8.4.5. Deşeuri prelucrateGrupa Cod deşeu Anul Cantitate Cod staţie

prelucrare1 20 15 01 2002 52 30.11.1 20 03 01 2002 80 30.21 20 15 01 2003 113 30.11.1 20 03 01 2003 164 30.2

Tabelul 8.4.6.Depozite deşeuriCod depozit Denumire depozit / localitate Capacitate disponibilă (mc)

30.1 Suceava / Suceava 9000030.2 Rădăuţi / Rădăuţi 5030030.3 Antileşti / Fălticeni 7940030.4 Buliceni / Vatra Dornei 300030.5 Hurghiş / Câmpulung 3430030.6 Gura Humorului / Gura Humorului 1000030.7 Siret / Siret 67500

Tabelul 8.4.7. Deşeuri depozitateCod depozit Anul Cantitate (mc)

30.1 2002 8852930.2 2002 19047

189

30.3 2002 952830.4 2002 752330.5 2002 768630.6 2002 375530.7 2002 596430.1 2003 6679530.2 2003 1545730.3 2003 840030.4 2003 407030.5 2003 697530.6 2003 337030.7 2003 5606

Date privind protecţia mediuluiDatele de mediu sunt reprezentate în diagrama E-R prin entitatea PARAMETRI

CALITATE MEDIU care este descrisă în figura 8.25 ca o structură ierarhică de date, având în vedere principiile proiectării bazelor de date temporale.

Cele două categorii de date (date privind gestionarea deşeurilor, date privind protecţia mediului) sunt astfel descrise în cadrul unei structuri flexibile şi extensibile de date.

Date spaţialeRaportat la modul de prelucrare, datele spaţiale se grupează în: date descriptive

(textuale) şi date grafice. Datele descriptive sunt organizate în tabele, iar datele grafice

Parametri calitate mediu

2. Parametri meteorologici1. Parametri ecologici

1.2. Apa 1.3. Aer1.1. Sol

Cod Denumire

1.1.1.

1.1.2 ...........................

Cod Denumire

1.2.1.

1.2.2 ...........................

Cod Denumire

1.3.1.

1.3.2 ...........................

Cod Denumire

2.1.

2.2 ..............................

Cod parametruValoare parametruData măsurării1.1.1………………1.2.1………………1.3.1………………2.1………………

DATE ISTORICE

Figura 8.25. Date privind protecţia mediului

190

definesc imagini vector prin puncte definite de coordonate şi descrieri de contururi. Datelele spaţiale sunt reprezentate şi pot fi redate pe straturi. O altă categorie de date este constituită din imagini raster reprezentând fişiere imagine obţinute prin scanare planuri cadastrale şi hărţi topografice, care pot constitui surse de date grafice obţinute prin operaţia de vectorizare.

Organizarea, descrierea şi prelucrarea datelor cadastrale necesită utilizarea unui produs de tip GIS (Geographical Information System) care să ofere: un nucleu grafic pentru reprezentarea şi prelucrarea datelor grafice, un sistem de gestiune a bazelor de date, comunicarea între cele două componente ale sistemului. Este avut în vedere pachetul NetSET, care oferă un foarte bun raport între preţ, performanţe şi facilităţi oferite, acoperind practic toate aspectele dezvoltării aplicaţiilor GIS. În plus, lucrează cu hărţi vectoriale în format shape, compatibil la nivel internaţional cu alte pachete de programe similare.

Fig.8. 26. Schema conceptuală a bazei de date8.4.4. Dezvoltarea unei aplicaţii specifice pentru reprezentarea şi monitorizarea unor zone intravilane din judeţul Suceava supuse degradării datorită depozitării necontrolate a deşeurilor.

191

În cadrul acestei secţiuni sunt prezentate: proiectarea şi realizarea modelului de poziţionare geografică în sistem GPS /

GIS a zonelor intravilane degradate; realizarea modelului experimental al sistemului telematic pentru managementul

on-line al zonelor intravilane degradate prin depozitarea necontrolată a deşeurilor.

Componentele software dezvoltate pentru realizarea aplicaţiei sunt: Componenta care asigură importul hărţii vectoriale a municipiului Suceava,

indiferent de sursa acesteia şi împreună cu informaţiile de georeferenţiere. Componenta care asigură navigarea, funcţiunile de mărire-micşorare, de afişare

sau nu a straturilor, de suprapunere a straturilor într-o anumită ordine etc. Componenta care asigură gestiunea bazelor de date ataşate fiecărui strat şi

legătura dintre aceste baze şi obiectele grafice de pe straturi. Componenta care asigură citirea perimetrelor ridicate cu ajutorul dispozitivelor

mobile GPS şi creare de noi straturi cu aceste informaţii. Componenta software care asigură citirea locaţiilor dispozitivelor automate de

măsurarea a parametrilor de mediu amplasaţi în zonele degradate ale zonei intravilan a Municipiului Suceava.

Componenta care asigură recepţionarea informaţiilor despre parametrii de mediu transmise prin GPRS/GPS/TCP/IP de către dispozitivele automate de măsurare plasate în punctele cheie ale zonei intravilane a Municipiului Suceava.

Pentru realizarea sistemului s-a colaborat cu instituţii pe plan local (Primăria Municipiului Suceava, Agenţia pentru Protecţie a Mediului Suceava, Garda de Mediu Suceava) pentru a realiza ridicări de coordonate geografice pentru zonele propuse pentru monitorizare, care au furnizat studii tehnice şi valori istorice pentru analize chimice, în vederea determinării punctelor critice din punctul de vedere al poluării datorate depozitării necontrolate a deşeurilor urbane, precum şi în vederea identificării necesităţilor de monitorizare.

Au fost realizate activităţi de urmărire periodică a evoluţiei perimetrale a depozitelor, prin poziţionare geografică a limitelor amplasamentelor obiectivelor identificate în cazul fazei anterioare, şi anume: depozitul de deşeuri municipale Suceava, depozitele neamenajate de pe malurile pâraielor Vătafu şi Şcheia şi din cartierul Obcine. Aceste obiective au fost monitorizate prin inspecţii periodice şi ridicări de coordonate ale limitelor perimetrale la data inspecţiei. În obiectivele monitorizate, s-au ridicat probe de sol / apă, pentru evaluarea nivelului de poluare indus şi definirea stării de calitate ca nivel de referinţă. Pentru identificarea efectelor induse asupra apelor de suprafaţă s-au continuat investigaţiile asupra râului Suceava, pâraielor Vătafu şi Şcheia, prin recoltarea de probe amonte şi aval de amplasamentul depozitelor de deşeuri şi determinarea indicatorilor de calitate pentru probele prelevate din levigatul deversat.

S-a realizat harta vectorială georeferenţiată a municipiului Suceava şi s-au introdus punctele care constituie perimetrele zonelor degradate identificate până în prezent, măsurate ca poziţie geografică cu ajutorul dispozitivelor GPS. Pentru pozitionarea

192

geografică a amplasamentelor Depozitului central de deseuri al municipiului Suceava, a depozitelor neamenajate de deseuri de pe malul paraurilor afluente raului Suceava si a depozitelor neamenajate din zonele rezidentiale monitorizate în cadrul fazelor anterioare ale implementării proiectului, s-a recurs la utilizarea tehnicii de pozitionare prin intermediul satelitilor GPS (Global Positioning System). A fost utilizat un receptor GPS performant, portabil, care oferă posibilitatea masurării perimetrelor depozitelor de deşeuri, calculării suprafeţelor acestora, precum şi poziţionării cu o precizie mare pe hartă, a punctelor de prelevare probe de apă si sol. Receptorul GPS utilizat este model GPSMAP 60CSx produs de firma GARMIN, receptor care are încorporată harta digitală a Romaniei (ROAD 2006, cu licenţa nr.931). Acest receptor GPS foloseşte un sistem de poziţionare geografică de tip WAAS (Wide Area Augmentation System) cu o precizie mare de localizare, şi anume de ±3 m. Receptorul GPS are port de comunicare, astfel încât se poate conecta prin port USB cu un calculator şi, cu ajutorul aplicaţiei software MapSource, livrată împreună cu receptorul, datele ridicate în teren (puncte de poziţionare şi masurările de perimetre) stocate în memoria receptorului GPS pot fi transferate, vizualizate pe hartă şi apoi listate la un printer.

În continuare sunt prezentate imagini care reprezintă zonele monitorizate precum şi alte rezultate obţinute în cadrul aplicaţiei de monitorizare.

Figura 8.27. Incadrarea in zonă a depozitului central de deşeuri al municipiului Suceava

Depozitul SuceavaPerimetru: 1,3 km;Suprafata: 78667 mp

193

Rezultatele masurătorilor cu GPS efectuate în luna septembrie 2007 pentru Depozitul de deseuri al municipiului Suceava sunt urmatoarele: lungimea perimetrului depozitului 1.3 km, suprafata: 78 667 mp.

Comparativ cu masurările efectuate in luna aprilie 2007 se constată că suprafata depozitului a crescut cu aproximativ 10 % (de la 71 559 mp la 78 667 mp).

Trebuie evidenţiat faptul că pe o portiune de aproximativ 150 m lungime depozitul de deseuri se găseste la mai putin de 2 m de albia raului Suceava (latura de N), iar eroziunea laterală a raului Suceava este foarte activă in această zonă existând posibilitatea ca o parte din deseurile depozitate să ajungă în râu (detaliu in Figura 8.28).

Procesele de şiroire sunt active in această zonă, apele meteorice care percolează depozitul se scurg in râul Suceava (detalii in Figura 8.29) antrenând prin solubilizare si nu numai materiale din masa depozitului.

SIROIRE

Scurgeri ape de siroirespre raul Suceava

Figura 8.29. Procese de şiroire şi scurgeri ape de şiroire în râul Suceava- detalii

Raul SuceavaDepozitulSuceava

Figura 8.28. Amplasamentul depozitului faţă de albia râului Suceava

194

S-a constatat faptul ca extinderea depozitului s-a realizat pe laturile de E si NE cu mentiunea că deseurile se găsesc la o distantă mică de raul Suceava (detaliu in Figura 8.30.).

Starea parametrilor de calitate a mediului în zonele selectateComponenta de mediu SOL

Investigaţiile realizate, pentru componenta de mediu SOL, in zona depozitelor de deşeuri urbane monitorizate în cadrul Fazelor 2 şi 3 de implementare a proiectului, au urmărit evaluarea nivelului de poluare indus de depozitarea neamenajata a deseurilor în zona de amplasament o obiectivelor analizate, la limita perimetrelor acestora.

Pentru evaluarea gradului de poluare a solului au fost recoltate de către reprezentantii INCD ECOIND, în luna septembrie 2007, 7 probe de sol după cum urmează:

4 probe pentru Depozitul de deşeuri central al municipiului Suceava; 1 proba de sol pentru depozitul neamenajat de pe paraul Vatafu;

Figura 8.30. Depunere deseuri pe latura de Est – detaliu

Bascularea deseurilor din remorca

195

1 proba de sol pentru depozitul neamenajat de pe raul Scheia; 1 proba de sol martor din zona Scheia.Pentru prelevarea probelor de sol s-a utilizat sonda de prelevare pedologică, marca

Buerkle, pungi de plastic şi etichete autoadezive, iar poziţionarea punctelor de prelevare s-a făcut cu ajutorul GPS Garmin din dotare. Probele au fost recoltate la adâncimile 0-10 cm şi 30-40 cm. Amplasarea probelor de sol pentru depozitul Suceava este prezentată în Tabelul 8.4.8 şi este detaliată pe hartă în figura 8.31.Tabelul 8.4.8 Amplasarea probelor de sol prelevate la Depozitul central Suceava

Nr.crt

Simbol probă

AdâncimeCoordonate geografice

ridicate cu GPSAmplasare

1 S01

0-10 cmN 470 39,052’E 0260 17,229’

- in vecinatea albiei minore a raului Suceava, latura de NV a

depoziului30-40 cm

2 S02

0-10 cmN 470 39,033’E 0260 17,375’

- in vecinatea albiei minore a raului Suceava, latura de NE a

depoziului30-40 cm

3 S030-10 cm N 470 38,895’

E 0260 17,422’

- latura de SE a depozitului, padure de foioase30-40 cm

4 S030-10 cm

N 470 38,936’E 0260 17,259’

- latura de SV a depozitului, padure de foioase

30-40 cm

Descrierea morfologică a probelor de sol prelevate de la Depozitul central Suceava este prezentata în Tabelul 8.4.9.

Tabelul 8.4.9. Descrierea morfologică a probelor de sol, Depozitul Suceava

Nr.crt

Simbolprobă

Adâncime Structură Textură Observaţii

1 S010-10 cm astructurat nisipoasă lipsa radacini30-40 cm astructurat nisipoasă -

2 S020-10 cm astructurat nisipos radacini ierboase30-40 cm astructurat lutonisipoasa -

3 S030-10 cm poliedrica lutonisipoasa

urme de radacini fine ierboase

30-40 cm astructurat nisipoasa -4 S04 0-10 cm grauntoasa lutoargiloasa radacini lignificate

196

30-40 cm grauntoasa lutoargiloasa -

Analiza morfologică a probelor de sol de la Depozitul central de deşeuri al municipiului Suceava relevă predominarea texturii nisipoase care conferă apelor meteorice posibilităţi de infiltrare rapidă în sol, dar, în acelaşi timp o capacitate redusă de reţinere a apei în sol.

Componenta de mediu APA DE SUPRAFAŢĂ Depozitele de deşeuri neamenajate amplasate în vecinătatea apelor de suprafaţă

sunt surse potenţial generatoare de afectare a calităţii acestora.Scurgerile de levigat de pe versanţii depozitelor contribuie la poluarea cu substanţe

organice şi suspensii a apelor de suprafaţă efectul putând fi resimţit pe distanţe mari. Împrăştierea deşeurilor pe malurile apelor de suprafaţă conduce la apariţia riscului de blocare a cursurilor în condiţii de precipitaţii extreme.

În general prin levigarea de către apele meteorice a deşeurilor depozitate neamenajat se induce o contaminare cu încarcare organică, compuşi ai azotului şi în funcţie de compoziţia deşeului şi alte substanţe toxice (metale grele).

Pentru identificarea efectelor induse asupra calităţii apelor de suprafaţă s-au efectuat investigaţii asupra calităţii apelor: râului Suceava, pârâului Vătafu, pârâului Şcheia. S-au recoltat probe de apă amonte şi aval de amplasarea depozitelor de deşeuri şi s-au efectuat determinări ale indicatorilor de calitate.

Metodele de încercare utilizate pentru determinarea indicatorilor de calitate sunt prezentate în Tabelul nr. 8.4.10.Tabel nr. 8.4.10 Indicatori de calitate ape de suprafaţă şi metode de încercare

Nr.crt.

Indicator de calitate Metode de incecare

1 pH SR ISO 10523/972 Conductivitate SR EN 27888/973 Turbiditate SR EN ISO 7027-014 Cloruri SR ISO 9297/015 CCOCr SR ISO 6060/96

Proba Sol Vatafu

S01S02

S03S04

Figura 8.31. Amplasarea probelor de sol în zona Depozitului Suceava pârâului Vatafu

197

6 CBO5 SR EN 1899/2-027 Amoniu

SR ISO 7150/2-018 Azot amoniacal(N-NH4)9 Azot total SR ISO 10048/0110 Azotati SR ISO 7890/2-0011 Sulfati STAS 8601/70

12Substante extractibile cu solventi organici

SR 7587/96

Probele prelevate au fost supuse determinărilor analitice şi analizând valorile indicatorilor de calitate determinate pentru proba de apă prelevată din levigat, comparativ cu valorile limită admise prin NTPA-001/2005 s-a constatat că indicatorii de calitate „CBO5”, „CCOCr” şi „Azot total” depăşesc valorile admise inducând o poluare semnificativă.

Monitorizarea on-line a calităţii apelor de suprafaţă în zonele imediat învecinate depozitelor neamenajate de deşeuri va reflecta efectele induse de aceste depozite. Numai o parte din indicatorii de calitate determinaţi vor putea fi monitorizaţi on-line, ceilalţi vor fi determinaţi în continuare prin încercări de laborator asupra probelor de apă prelevate din râu şi pâraie.

Monitorizarea zonelor degradate din municipiul Suceava utilizând platforma GIS NetSET

Ca model pentru harta municipiului Suceava a fost aleasă o hartă simplificată (vezi Figura 8.32.), care oferă avantajul că este foarte cunoscută de locuitorii oraşului, această hartă fiind utilizată pentru orientare în municipiu (în mijloacele de transport în comun, în cadrul afişajului stradal etc.).

Figura 8.32. Harta model pentru harta vectorială georeferenţiată a municipiului Suceava198

Pachetul de programe NetSET dispune de un modul de georeferenţiere care permite, pe baza punctelor de control de coordonate cunoscute, transformarea imaginii unei hărţi într-o imagine georeferenţiată, pregătită pentru a fi referinţa unei hărţi vectoriale georeferenţiate ( stă la baza desenării straturilor vectoriale).

În continuare sunt reprezentate imagini ce ilustrează reprezentarea unor straturi vectoriale pe harta georeferenţiată pentru a evidenţia în final evoluţia extinderii zonelor degradate.

Figura 8.33. Strat vectorial limită intravilan realizat pe platforma GIS NetSET

Figura 8.34. Strat vectorial limite administrative cartiere realizat pe platforma GIS NetSET

Figura 8.35. Harta vectorială completă a zonei intravilan a municipiului Suceava realizată pe platforma GIS NetSET

199

Din Figura nr. 8.36. se poate observa că perimetrul zonei degradate luat în considerare a evoluat în timp, fapt mai bine pus în evidenţă în figura 8.37.

Figura 8.36. Reprezentare zonă degradată măsurată în aprilie 2007(stânga) şi septembrie 2007 (dreapta) pentru zona degradată „Depozitul central Suceava”

Figura 8.37. Evoluţia extinderii zonei degradate „Depozitul central Suceava” din aprilie până în septembrie 2007

200

201

ConcluziiAceastă tehnologie poate oferi suportul pentru controlul localizării şi monitorizării

depozitelor ilegale de deşeuri şi poate fi utilizată ca tehnologie multimedia pentru informarea autorităţilor şi populaţiei asupra zonelor afectate de poluare antropică. Realizarea unui sistem de asemenea complexitate, impune captarea informaţiei strict instanţiate, în timp real, dar şi a datelor rezultate în urma unor analize de laborator, care se introduc de către operatorul uman. În mod concret, soluţia adoptată este realizarea unui sistem integrat de management şi monitorizare, bazat pe senzori, ce poate fi uşor „up-gradat” la nivel de sistem de management funcţional şi arhitectural, pentru a se putea realiza o monitorizare centralizată pe baza unor programe şi aplicaţii specializate. Rolul sistemului implementat este de preîntâmpinare şi de prealarmare asupra stabilităţii, supravegherea încadrării în limite şi evidenţierea necesităţii reducerii depozitării necontrolate a deşeurilor, informarea factorilor de decizie.

202

BIBLIOGRAFIE

[1] Ioan I.Andone, Robert J.Mockler, Dorothy G.Dologite, Alexandru Al.Ţugui, Dezvoltarea sistemelor inteligente în economie. Metodologie şi studii de caz., Editura Economică, Bucureşti, 2001.

[2] Ioan Andone, Sisteme inteligente hibride. Teorie. Studii de caz pentru aplicaţii economice. Ghidul dezvoltatorului, Editura Economică, Bucureşti, 2002.

[3] Andone I., Ţugui Al., Baze de date inteligente în managementul firmei, Ed, Dosoftei, Iaşi, 1997.

[4] Balan D., Balan G. – Sistemul informaţional în gestionarea întreprinderilor, Ed. Junimea, Iaşi, 1998

[5] Balteanu D. et al., Sistem informational geografic (GIS) pentru studiul dezastrelor naturale, Academia Româna, Institutul de Geografie, Bucuresti

[6] Tudorel Baicu, Tatiana Eugenia Şesan, Fitopatologie Agricolă, Ed.Ceres, Bucureşti, 1996.

[7] .“Banca de Resurse Genetice Vegetale” Suceava, editată la Banca de gene Suceava, 1997.

[8] Brânzei R. – Sisteme informatice, Ed. Universităţii “Al. I. Cuza”, Iaşi, 1995[9] .Octavian Bâscă,.Baze de date, Ed. ALL, 1997.[10] Ion Capanu, Constantin Anghelache, INDICATORI ECONOMICI pentru

managementul micro şi macroeconomic. Calcul. Prezentare. Analiză., Editura Economică, Bucureşti, 2000.

[11] Chindea M. E. – Proiectarea sistemelor informatice economice, Bucureşti, 1999[12] Chen, P.P. – Entity-Relationship Approach to Systems Analysis and Design,

Amsterdam, North Holland, 1980[13] Thomas M. Connoly, Carolyn E. Begg, Database Solutions – A step – by- step

approach to building databases, Second Edition, Pearson Education Limited, 2004[14] Thomas Connolly, Carolyn Begg, Anne Strachan – Database Systems – A

Practical Approach to Design, Implementation and Management Second Edition (trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Bucureşti 2001).

[15] T. Crăciun, I. Tomozei, N. Coleş, Galia Butnaru, GENETICĂ VEGETALĂ Ed. Didactică şi Pedagogică, Bucureşti, 1991.

[16] C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson Education, Inc. Adison Wesley Higher Education, 2004.

[17] Carla M. DeAngelis, Modeling Data with Erwin, SAMS, 2000[18] Delahaye, J.P. – Systemes experte: organisation et programmation des bases de

connaissances en calcul propositionnel, Laboratoire d'Informatique Fondamentale de Lille, Université des Sciences et Technologies de Lille, 1986.

[19] Dimitriu G., Sisteme informatice geografice GIS, Editura Albastra, Cluj-Napoca, 1998

[20] Robert Dollinger-Baze de date şi gestiunea tranzacţiilor, Cluj Napoca, 1998.

203

[21] Doina Fusaru, Arhitectura bazelor de date – Mediul SQL, Univ.Spiru Haret, Ed.Fundatiei România de mâine, Buc.2002.

[22] GURU Tutor – On-line System Documentation, Micro Data Base Systems Inc., Lafayette Indiana, 1987.

[23] Jan R. Harrington, Relational Database Design Clearly Explained, Academic Press, 2002

[24] John E. Harmon and Steven J. Anderson, The Design and Implementation of Geographic Information Systems, John Wiley & Sons, 2003

[25] Michael J. Hernandez, Proiectarea Bazelor de date, trad. Ed. Teora, Bucureşti, 2003.

[26] W. Daniel Hillis, Maşina care gândeşte. Cum funcţionează calculatoarele. (trad. Mihai Cipu, Ed. Humanitas, Bucureşti, 2001).

[27] Mathieu, Ph. – La réalisation d'un générateur de Systemes expertes, Course imprimé, Laboratoire d'Informatique Fondamentale de Lille, Université des Sciences et Technologies de Lille, 1992.

[28] Ion Sainiuc, Carmen Antonovici, Radu Ungureanu, Nicolae Morariu, ”GEO-GRAPH – Sistem Informatic Geografic utilizat în realizarea cadastrului general finanţat de Banca Mondială”, Analele ştiinţifice ale Universităţii ”Alexandru Ioan Cuza” din Iaşi Tom XLII-XLIII, 1996-1997, pag. 51-54.

[29] Nicolae Morariu, Sorin Vlad , “Consideraţii privind dezvoltarea sistemelor inteligente în economie”, Economia românească prezent şi perspective. Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.566-577.

[30] Nicolae Morariu, Dumitru Ostafe, Sorin Vlad , “Consideraţii privind utilizarea unor instrumente ale inteligenţei artificiale în cercetarea aplicativă”, “Economia românească prezent şi perspective”, Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.615-622.

[31] Şt.Gh.Pentiuc, Nicolae Morariu, ş.a., Intelligent System for Prognosis and Estimation of Economic Decisions at Districtual Level, Advances in Electrical and Computer Engineering, Faculty of Electrical Engineering “Stefan cel Mare” University of Suceava, vol.1(8), nb.1(15), 2001, pp. 44-47.

[32] mat.Nicolae Morariu, prof.dr.ing.Nicolae Popovici, ing.Radu Ungureanu, ing.Ion Sainiuc, ing.Traian Teodorescu, fiz.Cătălin Zamfirescu; ”Sistem informaţional geografic (SIG) pentru monitorizarea zonelor expuse inundaţiilor”, Produse software pentru reprezentarea digitală şi monitorizare, Revista Hidrotehnica vol. 42 Nr. 10-12 1997, pag. 43-46.

[33] N. Morariu, N. Popovici, R. Ungureanu, T. Teodorescu, I. Sainiuc, C. Zamfirescu; ”Sistem de reprezentare digitală a zonelor expuse inundaţiilor”, Simpozion ştiinţific jubiliar “65 ani ai Universităţii Agrare de Stat din Moldova”, vol. 2, 7-9 octombrie 1998 Chişinău, pag. 186-188.

[34] Nicolae Morariu,Şt.Gh.Pentiuc,Gh.Sandu,B.Tanasiciuc ş.a., “Sistem expert destinat monitorizării impactului măsurilor economice asupra zonelor defavorizate –referinţă Judeţul Suceava”, Sesiunea ştiinţifică naţională cu participare

204

internaţională “Economia românească prezent şi perspective”, Univ. “Ştefan cel Mare” Suceava, iunie 2002, pag.586-598.

[35] . Nicolae Morariu, “Aspecte privind distribuirea datelor în cadrul unui sistem informatic pentru integrarea registrelor permanente”, Tehnologii informaţionale, Editura Universităţii Suceava, ISBN 973-666-059-1, 2003 , pag.60-69.

[36] Nicolae Morariu, “Integrarea tehnologiei bazelor de date cu tehnologia sistemelor inteligente”, Economia românească prezent şi perspective. Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Universităţii Suceava, ISBN 973-666-035-4, 2003, pag.553-565.

[37] Nicolae Morariu, “Utilizarea unor instrumente ale inteligenţei artificiale pentru diagnosticare şi predicţie în economie”, Simpozionul Internaţional al Tinerilor Cercetători Ediţia II - a, Academia de Studii Economice din Moldova, 29 – 30 aprilie 2004, Departamentul Editorial-Poligrafic al A.S.E.M. Chişinău, ISBN 9975-75-239-x, Vol.I pag.14-16.

[38] Nicolae Morariu, “REFORME – A software product for pattern clasification and recognition by joint use of pattern recognition techniques and multi-layer perceptron”, “The Proceedings of the Central and East European Conference in Business Information Systems”, Cluj-Napoca, may 2004, Ed. Risoprint, ISBN 973-656-648-X, pag.100-105.

[39] Nicolae Morariu, “Artificial Inteligence Techniques in an Evaluation and Decision System for Economic Activity”, SACI 2004, Budapest Polytechnic Nepszinhaz, Budapest, Hungary, Timişoara, 2004.

[40] [MOR404]. Nicolae Morariu, Sorin Vlad, ”Online documentation and assisted research knowledge based system for vegetal genetics resources”, Proceedings of the Forth International Conference ”Internet Education Science IES-2004”, Baku State University Azerbaijan,Vinnytsia National Technical University Ukraine, St. Cyril and St. Methodius University of Veliko Turnovo Bulgaria, oct. 2004 Vinnytsia Ukraine, ISBN 966-641-104-0, Tom 2, pag. 513-516.

[41] Nicolae Morariu, ”Baze de date. Îndrumar de laborator”, ISBN 973-666-159-8, Editura Univ. “Ştefan cel Mare” Suceava, 88 p, Suceava, 2005.

[42] Andrew J. Oppel, Databases Demystified, McGraw-Hill, 2004[43] Dumitru Oprea, Gabriela Meşniţă, Florin Dumitriu, Analiza sistemelor

informaţionale, Editura Universităţii „Alexandru Ioan Cuza” Iaşi, 2005[44] Dumitru Oprea, Florin Dumitriu, Gabriela Meşniţă, Proiectarea sistemelor

informaţionale, Editura Universităţii „Alexandru Ioan Cuza” Iaşi, 2006[45] Dumitru Oprea, Dinu Airinei, Marin Fotache, Sisteme informaţionale pentru

afaceri, Editura POLIROM Iaşi, 2002[46] Oprea D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed.

POLIROM, Iaşi, 1999[47] Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn

Maslen, Published by Oracle Corporation UK Ltd. 1992.[48] Totul despre SQL Interogarea bazelor de date, Corina Pascu, Adrian Pascu, Ed.

Tehnică Buc. 1994.

205

[49] Pigford D. V., Baur G., Expert Systems for Business. Concepts and Applications. Featuring VP-Expert, Boyd & Fraser Pub, Boston, 1990.

[50] Elemente de teoria şi proiectarea bazelor de date. Note de curs, Stefan Gh. Pentiuc, Jean Michel Duthilleul, Univ. “Ştefan cel Mare” Suceava 1995.

[51] Pentiuc, Şt. Gh. – An Algorithm for the Generation of Symbolic Classifiers for Pattern Recognition Systems. Analele Universităţii "Ştefan cel Mare" Suceava, nr.1, 1994.

[52] Ştefan-Gheorghe Pentiuc, Aplicaţii ale recunoaşterii formelor în diagnosticul automat, 158 p. ISBN 973-31-1096-5, Editura Tehnică, Bucureşti, 1997.

[53] [PENT00]. Şt. Gh. PENTIUC, Generatoare de sisteme expert - Editura Hipparion, Cluj-Napoca, 2000, ISBN 973-9448-48-8, 112 pagini.

[54] Popescu I. – Baze de date relaţionale: proiectare şi implementare, Ed. Universităţii din Bucureşti, Bucureşti, 1996

[55] Rojanschi, V., Bran Florina, Diaconu Gheorghiţa, Protecţia şi ingineria mediului, Ed. Economică, Bucureşti, 2002

[56] Roger J. - Utilizare ACCESS 95, Ed. Teora, Bucureşti, 1995[57] Rusu A, Boş N., Kiss A., Topografie-Geodezie EDP Bucureşti, 1982. [58] Khoshafian Setrag “Object Oriented Databasses”, pub. John Whiley 1994, UK.[59] Prof. dr. Victoria Stanciu, ş.a. Proiectarea sistemelor informatice, Ed. Dual Tech,

2004.[60] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureşti

2000[61] Alecsandru Puiu Tacu, Romul Vancea, Ştefan Holban, Aurel Burciu, Inteligenţa

Artificială. Teorie şi aplicaţii în economie., Editura Economică, Bucureşti, 1998.[62] Udrică M. – Modelarea orientată obiect, Ed. Cison, Bucureşti, 2000[63] Vasilescu P., Dunca V. – Proiectarea sistemelor informatice, Ed. Tehnică,

Bucureşti, 1979[64] Marian Zaharia, Claudia Cârstea, Liana Sălăgean, Inteligenţa artificială şi

sistemele expert în asistarea deciziilor economice, ISBN 973-590-870-0, Ed. Economică, Bucureşti, 2003.

[65] Mark Whitherhorn, Bill Marklyn, Insisde Relational Databases with Examples in Access, Springer 2007

[66] *** Anuar privind calitatea mediului în judeţul Suceava, (1991-2003), Agenţia de Protecţia Mediului, Suceava

[67] *** Sistem telematic pentru managementul on-line al zonelor intravilane degradate, acronim ZoneMAP, cod 509, contract nr.123CEEX/15.09.2006, programul CEEX - competitia ianuarie 2006, Raport tehnic faza 2, faza 3.

[68] ***http://www.ca.com/us/products/product.aspx?id=260[69] ***http://www.quest.com/Toad-Data-Modeler/[70] ***http://www.embarcadero.com/products/erstudio/[71] ***http://office.microsoft.com/en-us/visio/default.aspx[72] ***http://www.oracle.com/technology/software/products/designer/htdocs/

winsoft.html

206

[73] *** www.feea.uaic.ro. [74] Suceava Genebank – Romania, Databases, http://www.svgenebank.ro[75] *** Inteligent Database Systems,

www.cms.dmu.ac.uk/~jennyc/Intell_db_notes.htm[76] Evaluation and Conservation of Barley Genetic Resource to Improve Their

Accessibility to Breeders in Europe. Evaluation methods 1999, EU Project GENRES CT98-104, Genbank, IPK, Gatersleben, Germany, http//barley.ipk-gatersleben.de

[77] UMBC KQML Web. KQML Papers and presentations, http:www.cs.umbc.edu/kqml/papers/

[78] Ing. Laurentiu-Virgil RUSAN, Consideratii privind structurile de date specifice sistemelor informationale geografice,www.revistaie.ase.ro/content/13/rusan.pdf

[79] Data mining, o nouã erã în informaticã Ştefan I.Nitchi şi Rodica Avram-Nitchi, http:www.byte.ro/byte97-02/18tend.html.

[80] Dicţionar modern de informatică, “Sisteme multiagenţi”, Universitatea “Politehnica Bucureşti”, www.cs.pub.ro/~dict/sisteme_multiagenti/ sisteme_multiagenti.html

207