1

C u p r i n s
Introducere.. 3

Capitolul 1

Sisteme informatice.

4
1.1. Sistem, Sistem informaional, Sistem informatic. 4
1.1.1. Componentele sistemului informatic 5
1.1.2. Clasificarea sistemelor informatice. 6
1.1.3. Ciclul de via a unui sistem informatic....... 8
1.1.4. Coninutul bazei informaionale a unei ntreprinderi ... 9
1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic.... 9
1.1.6. Sistemele informatice de gestiune ... 10
1.2. Metodologii de realizare a sistemelor informatice....... 11
1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice..... 11
1.2.2. Metode i tehnici de realizare a sistemelor informatice ...... 11
1.3. Instrumente CASE........................................................................................................ 13
1.3.1. Funciile CASE .................................................... 14
1.3.2. Trsturi definitorii ale CASE-ului....................................................................... 14
1.3.3. Exemple de instrumente CASE ........................... 15
Teste rezolvate..................................................................................................................... 17
ntrebri i rspunsuri......................................................................................................... 20
ntrebri.............................................................................................................................. 20

Capitolul 2
Iniierea i planificarea realizrii unui sistem informatic.... 21

2.1. Identificarea, selecia, iniierea i planificarea proiectelor... 21
2.2. Studii de fezabilitate.......... .. 23
2.3. Tehnici de reprezentare a planurilor i programarea calendaristic............................. 24
Teste rezolvate......................................................................................................................... 24

Capitolul 3
Analiza sistemului existent i definirea cerinelor noului sistem........................ 26

3.1. Studiul sistemului informaional existent..... 26
3.2. Determinarea cerinelor sistemului .................. 27
3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului.. 27
3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului.. 28
3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor... 29
3.3.1. Diagramele fluxurilor de date (DFD).. 29
3.3.2. Descompunerea funcional i rafinarea DFD.. 31
3.3.3. Modelarea sistemului current.... 32
3.3.4. Modelarea logicii proceselor.... 35
3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)........................ 36
3.4.1. Modelul Entitate/Relaie (E/R)............................................................................. 43
3.5. Selectarea celei mai bune variante strategice de proiectare .... 46
Teste rezolvate..................................................................................................................... 47
ntrebri.............................................................................................................................. 49

Capitolul 4
2
Proiectarea logic a sistemelor informatice.......................................................................................... 50

4.1. Proiectarea formularelor/formatelor i a rapoartelor................................................................ 50
4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor)............................. 50
4.1.2. Proiectarea codurilor .... 53
4.1.3. Proiectarea intrrilor n sistemul informatic......................................... 53
4.2. Proiectarea interfeelor i a dialogurilor ......... 55
4.3. Proiectarea logic a bazelor de date. 56
4.3.1. Normalizarea relaiilor - Forme normale.............................................................. 60
4.3.2. Simplificarea structurii datelor prin normalizare.. 63
4.3.3. Transformarea diagramelor entitate-relaie n relaii 65
Teste rezolvate. 65

Capitolul 5
Proiectarea fizic a sistemelor informatice........................................................... 68

5.1. Proiectarea fizic a bazelor de date i a fiierelor..................................................................... 68
5.1.1. Obiectivele fundamentale ale unei baze de date................................................... 68
5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD).... 69
5.1.3. Administratorul bazei de date... 70
5.1.4. Proiectarea securitii bazelor de date i a fiierelor.... 70
5.1.5. Limbajul SQL crearea, administrarea, interogarea bazelor de date relaionale. 71
5.2. Proiectarea programelor i a procedurilor................. 81
5.2.1. Atributele
modulelor..........................................................................................................
82
5.2.2. Structurile de control ale
programelor...............................................................................
83
5.2.3. Proiectarea i realizarea
programelor.................................................................................
86
5.3. Proiectarea sistemelor
distribuite..............................................................................................
87
Problem
rezolvat...........................................................................................................................
89
Teste
rezolvate..................................................................................................................................
91
ntrebri i
rspunsuri.......................................................................................................................
93

ADENDA................................................................................................................................. 94

BIBLIOGRAFIE......................................................................................................................

96








3

Introducere .......................................................................................................................................5
Capitolul 1........................................................................................................................................8
Sisteme Informatice..........................................................................................................................8
1.1. Sistem, Sistem informaional, Sistem informatic................................................................................................ 8
1.1.1. Componentele sistemului informatic.......................................................................................................... 11
1.1.2. Clasificarea sistemelor informatice............................................................................................................ 13
1.1.3. Ciclul de via a unui sistem informatic.................................................................................................... 15
1.1.4. Coninutul bazei informaionale a unei ntreprinderi ................................................................................. 16
1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic ................................................................................. 17
1.1.6. Sisteme informatice de gestiune................................................................................................................. 19
1.2. Metodologii de realizare a sistemelor informatice ............................................................................................ 21
1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice ............................................................... 21
1.2.2. Metode i tehnici de realizare a sistemelor informatice ............................................................................. 22
Capitolul 2. Iniierea i planificarea realizrii unui sistem informatic...........................................31
2.1. Identificarea, selecia, iniierea i planificarea proiectelor ................................................................................ 31
Identificarea potenialelor proiecte de dezvoltare ................................................................................................ 32
Selecia proiectelor de dezvoltare a sistemelor informaionale ............................................................................ 32
Iniierea i planificarea proiectelor........................................................................................................................... 32
Iniierea proiectului .............................................................................................................................................. 33
Planificarea proiectului ........................................................................................................................................ 33
2.2. Studii de fezabilitate.......................................................................................................................................... 34
2.3. Tehnici de reprezentare a planurilor i programarea calendaristic .................................................................. 35
Capitolul 3......................................................................................................................................39
Analiza sistemului existent i definirea cerinelor noului sistem...................................................39
3.1. Studiul sistemului informaional existent.......................................................................................................... 39
3.2. Determinarea cerinelor sistemului ................................................................................................................... 41
3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului......................................... 42
3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului............................................................ 43
3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor................................................ 45
3.3.1. Diagramele fluxurilor de date (DFD)......................................................................................................... 45
Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD................. 46
3.3.2. Descompunerea funcional i rafinarea DFD ........................................................................................... 47
3.3.3. Modelarea sistemului curent ...................................................................................................................... 50
3.3.4. Modelarea logicii proceselor.......................................................................................................................... 53
Reprezentarea logicii proceselor prin engleza structurat.................................................................................... 54
3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER) ............................................................. 56
3.4.1. Modelul Entitate/Relaie (E/R)................................................................................................................... 59
Capitolul 4......................................................................................................................................77
Proiectarea logic a sistemelor informatice ...................................................................................77
4.1. Proiectarea formularelor/formatelor i a rapoartelor ......................................................................................... 77
4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor) ............................................................................... 78
4.1.2. Proiectarea codurilor .................................................................................................................................. 82
4.1.3. Proiectarea intrrilor n sistemul informatic............................................................................................... 83
4.2. Proiectarea interfeelor i a dialogurilor............................................................................................................ 86
4.3. Proiectarea logic a bazelor de date .................................................................................................................. 89
4.3.1. Normalizarea relaiilor - Forme normale.................................................................................................... 94
4.3.2. Simplificarea structurii datelor prin normalizare ..................................................................................... 100
4.3.3. Transformarea diagramelor entitate-relaie n relaii................................................................................ 104
Capitolul 5....................................................................................................................................108
Proiectarea fizic a sistemelor informatice ..................................................................................108
5.1. Proiectarea fizic a bazelor de date i a fiierelor ........................................................................................... 108
5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:..................................................................... 109
5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD) .................................................................................... 111
4
5.1.3. Administratorul bazei de date .................................................................................................................. 111
5.1.4. Proiectarea securitii bazelor de date i a fiierelor ................................................................................ 113
5.1.5. Limbajul SQL - Crearea, Administrarea i Interogarea bazelor de date relaionale................................. 115
5.2. Proiectarea programelor i a procedurilor ....................................................................................................... 135
5.2.1. Atributele modulelor ................................................................................................................................ 138
5.2.2. Structurile de control ale programelor...................................................................................................... 139
5.2.3. Proiectarea i realizarea programelor ....................................................................................................... 143
5.3. Proiectarea sistemelor distribuite ................................................................................................................... 144
Capitolul 6....................................................................................................................................153
Instrumente CASE........................................................................................................................153
6.1. Funciile CASE............................................................................................................................................... 155
6.2. Trsturi definitorii ale CASE-ului ................................................................................................................. 156
Capitolul 7....................................................................................................................................179
Tendine actuale i de perspectiv n evoluia sistemelor informatice.........................................179
7.2.1. Sisteme expert bazate pe reguli ................................................................................................................ 186
7.2.2. Sisteme bazate pe reele neuronale (sisteme conexioniste) ...................................................................... 186
7.2.3. Sisteme multi-agent. Definiie, clasificare, arhitecturi. ............................................................................ 187
7.2.4. Sisteme inteligente hibride....................................................................................................................... 189
Capitolul 8....................................................................................................................................193
Studii de caz - Arhitecturi de sisteme informatice .......................................................................193
8.1. Model de date georelaional n cadrul unui sistem informatic geografic distribuit cu aplicaii n domeniul
cadastrului .............................................................................................................................................................. 193
Model de date georelaional n domeniul cadastrului............................................................................................. 194
8.3. Sistem bazat pe cunotine destinat documentrii i cercetrii asistate n genetica vegetal ......................... 214
8.3.1. Organizarea datelor n cadrul sistemului informatic ................................................................................ 215
8.3.2. Arhitectura unui sistem bazat pe cunotine n genetica vegetal ............................................................ 220
8.3.3. Probleme specifice cercetrii ................................................................................................................... 227
8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorit depozitrii
necontrolate a deeurilor ........................................................................................................................................ 234
8.4.1. Introducere ............................................................................................................................................... 234
8.4.3. Proiectarea bazei de date a sistemului ...................................................................................................... 238
8.4.4. Dezvoltarea unei aplicaii specifice pentru reprezentarea i monitorizarea unor zone intravilane din
judeul Suceava supuse degradrii datorit depozitrii necontrolate a deeurilor. ............................................. 244
[19] Dumitru Oprea, Gabriela Meni, Florin Dumitriu, Analiza sistemelor informaionale, Editura Universitii
Alexandru Ioan Cuza Iai, 2005 ......................................................................................................................... 264
[20] Dumitru Oprea, Florin Dumitriu, Gabriela Meni, Proiectarea sistemelor informaionale, Editura
Universitii Alexandru Ioan Cuza Iai, 2006 .................................................................................................... 264
[21] Dumitru Oprea, Dinu Airinei, Marin Fotache, Sisteme informaionale pentru afaceri, Editura POLIROM Iai,
2002 ....................................................................................................................................................................... 264




8
Capitolul 1. Sisteme Informatice

1.1. Sistem, Sistem informaional, Sistem informatic
Un sistem reprezint un ansamblu de elemente (componente) interdependente ntre
care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv [4]. Conform teoriei sistemelor orice organism economic
este un sistem.
n cadrul acestei lucrri prin organizaie se va referi o intreprindere, instituie,
societate comercial.
n orice organizaie se disting 3 componente:
sistemul de conducere sau de decizie;
sistemul informaional;
sistemul operaional.
Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate
n cadrul organizaiei precum i datele care au stat la baza obinerii lor, procedurile i
tehnicile de obinere a informaiilor (plecnd de la datele primare) i de difuzare a
informaiilor, precum i personalul implicat n culegerea, transmiterea, stocarea i
prelucrarea datelor.
Sistemul informaional are dou componente:
componenta pentru stocarea (memorarea informaiilor);
componenta pentru prelucrarea informaiilor.
Orice organizaie interacioneaz cu alte organizaii externe ei primind informaii
din exterior i furniznd informaii ctre lumea exterioar.
Funciile unui sistem informaional sunt:
s colecteze informaii din sistemele operaional i decizional precum i
informaiile ce provin din mediul extern;
s memoreze aceste informaii precum i informaii rezultate din prelucrarea
lor;
s asigure accesul la memorie n vederea comunicrii informaiilor stocate;
9
s prelucreze informaiile la cererea sistemului operaional i a sistemului de
conducere.
Noiunea de sistem informatic este legat de informatizarea activitii organizaiei,
deci folosirea echipamentelor hardware i a produselor software pentru organizarea i
administrarea informaiilor. Utilizarea calculatoarelor n cadrul sistemului informaional
(SI) al unei organizaii conduce la definirea componentei Sistem Informaional
Automatizat (SIA) care cuprinde numai lucrrile realizate cu ajutorul calculatoarelor.
Relaia SI SIA este reprezentat n figura 1.1.
Sistem informatizat Procesor de informaii Informaie Reguli









Fig. 1.1. Relaia SI SIA (Sursa: [10])

Definiie.
Un sistem informatic este un sistem utilizator-calculator integrat, care furnizeaz
informaii pentru a sprijini activitile de la nivel operaional i activitile de management
ntr-o organizaie, utiliznd echipamente hardware i produse software, proceduri
manuale, o baz de date i modele matematice pentru analiz, planificare, control i luarea
deciziilor [10].
Obiectivul principal urmrit prin introducerea unui sistem informatic l constituie
asigurarea conducerii cu informaii reale i n timp util, necesare fundamentrii i
elaborrii operative a deciziilor [2].
Elaborarea sistemelor informatice impune modelarea sistemului informaional al
organizaiei cu ajutorul unui formalism prin care s poat fi reprezentat ct mai sugestiv
i fidel realitatea din cadrul sistemului informaional.
Sistem
manua
Sistem

Om
Calculato
Fiiere
manual
Fiiere
informatice
Reguli i
proceduri
scrise
Programe i
Structuri de
10
Sistemele informatice complexe pot fi descompuse n subsisteme, care la rndul lor
pot fi descompuse n aplicaii destinate unor categorii de utilizatori, aplicaii care la rndul
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, aplicaii, programe

Pentru organizaii de complexitate mic, informatizarea poate nsemna realizarea
unei singure aplicaii informatice referit de asemenea ca sistem informatic.
Sistemele, subsistemele i aplicaiile informatice sunt produse informatice numite
i produse software. Un produs informatic este constituit din programe care acceseaz
baza de date i din documentaia necesar pentru utilizarea i ntreinerea programelor.
Acestea se realizeaz n baza unor metodologii i necesit parcurgerea unor etape
ncepnd cu specificarea cerinelor i terminnd cu implementarea, exploatarea i
ntreinerea lor.
Sistemul informatic economic este un ansamblu structurat de elemente
intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i
pentru fundamentarea deciziilor. Sistemul informatic este inclus n sfera sistemului
informaional atta vreme ct n cadrul sistemului informaional vor exista o serie de
activiti care nu vor putea fi automatizate [2].


Sistem Informatic
Subsistem 1 Subsistem 2 Subsistem n
Aplicatia 2.1 Aplicatia 2.k
Program 2.k.1 Program 2.k.s
11
1.1.1. Componentele sistemului informatic
Un sistem informatic este compus din [2]:
baza informaional;
baza tehnic;
sistemul de programe;
baza tiinific i metodologic;
factorul uman (resursele umane);
cadrul organizatoric.
Baza informaional cuprinde:
datele supuse prelucrrii;
fluxurile informaionale;
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
funcionarea sistemului informatic n concordan cu funciunile i obiectivele stabilite.
Sunt avute n vedere att programele de baz (software de baz) ct i programele
aplicative (software de aplicaie).
Baza tiinific i metodologic este constituit din:
algoritmi;
formule;
modele;
tehnici de realizare a sistemelor informatice.
Resursele umane constau din:
personalul de specialitate: analiti, programatori, ingineri de sistem, analiti-
programatori ajutori, operatori, etc.;
beneficiarii sistemului.
12
Cadrul organizatoric este cel specificat n regulamentul de organizare i
funcionare (ROF) al unitii n care va fi utilizat sistemul informatic.
La realizarea i utilizarea unui sistem informatic trebuie avute n vedere
urmtoarele componente hard i soft: reele, echipamente, produse software de baz,
produse software de aplicaie.
Reele
- clasificare dup aria de ntindere geografic:
Locale =LAN (Local Area Network) la nivelul unei organizaii;
Metropolitane MAN (Metropolitan Area Network) la nivel de ora,
localitate;
De mare ntindere -WAN (World Area Network) (ex. Jude, ar).
- clasificare dup accesibilitate:
Internet (reeaua Web) o colecie mondial de reele interconectate;
Intranet un sit Web sau un grup de sit-uri care aparin unei organizaii,
accesibil numai pentru membrii acesteia;
Extranet o reea intranet care este parial accesibil utilizatorilor externi
autorizai.
Echipamente
Echipamente de calcul : calculatoare, staii grafice, pentru servere de reea,
servere de baze de date, staii de lucru (clieni, utilizatori), UPS-uri;
Echipamente de comunicaie : router-e, hub-uri, modem-uri, switch-uri.
Produse software
Produse software de baz:
Sisteme de operare pentru serverul de reea (UNIX, Windows NT server,
Windows 2000, Novell) i pentru staiile de lucru sau clieni (Windows 95,
Windows 98, Windows NT work station, Windows 2000);
Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft,
MySQL, ACCESS, FoxPro etc.);
13
Sisteme GIS (Geographical Information System) utilizate pentru realizarea
aplicaiilor pentru stocarea i prelucrarea datelor spaiale;
Limbaje (medii) de programare utilizate pentru realizare software de
aplicaie.
Produse software de aplicaie produse program ce constituie aplicaiile i
subsistemele sistemului informatic.
1.1.2. Clasificarea sistemelor informatice
Sistemele informatice se clasific dup mai multe criterii [1].
1. n funcie de domeniul de utilizare, sistemele informatice pot fi pentru :
conducerea activitilor economico-sociale
conducerea proceselor tehnologice
cercetare tiinific i proiectare tehnologic
activiti speciale.
2. n funcie de elementul supus analizei:
sisteme informatice orientate spre funcii;
sisteme informatice orientate spre proces;
sisteme informatice orientate spre date;
sisteme informatice orientate spre obiecte;
sisteme informatice orientate spre cunotine.
3. Dup modul de organizare a datelor:
sisteme bazate pe fiiere;
sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, 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;
14
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 reea local, staii de lucru):
sisteme informatice distribuite (date distribuite).
7. Dup gradul de automatizare a activitilor de analiz i proiectare a sistemelor
informatice:
sisteme informatice dezvoltate pe baza analizei i proiectrii clasice;
sisteme informatice analizate cu instrumente automate i proiectate clasic;
sisteme informatice bazate pe instrumente diverse de automatizare a analizei i
proiectrii;
sisteme informatice dezvoltate cu instrumente de tip CASE.
n funcie de nivelul ierarhic ocupat de sistemul economic n structura
organizatoric a societii, exist sisteme informatice [2]:
pentru conducerea activitii la nivelul unitilor economice;
pentru conducerea activitii la nivelul organizaiilor economico-sociale cu
structur de grup;
sisteme informatice teritoriale;
pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei
naionale;
sisteme informatice funcionale generale.
15
1.1.3. Ciclul de via a unui sistem informatic
Sistemele informatice (SI) se caracterizeaz printr-un ciclu de via care ncepe cu
decizia realizrii unui nou SI care s corespund mai bine noilor cerine ale utilizatorilor
i se ncheie cu decizia de nlocuire a SI existent cu unul nou, mai performant. Ciclul de
via se desfoar pe etape n cadrul fiecreia fiind definite faze i activiti specifice.
nc de la nceput facem meniunea 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 perfecioneaz, dnd natere unei
alte versiuni sau chiar unui nou sistem. Mutaiile din domeniul tehnologiei informaionale
i al metodelor de abordare a sistemelor s-au reflectat i n ciclul de via al dezvoltrii
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 [4].
Prin parcurgerea materialelor de specialitate, se poate constata c numrul
fazelor/etapelor variaz de la trei (de exemplu analiza, proiectarea, implementarea) la
peste douzeci. Exist mai multe modele ale ciclului de via, multe dintre ele cunoscnd
o evoluie n timp. Spre exemplu, modelul cascad (figura 1.3) prevede parcurgerea mai
multor etape ale ciclului de via care se deruleaz secvenial fiind ns permis la nevoie
revenirea la etapa parcurs anterior n vederea ndeprtrii neajunsurilor identificate n
etapele superioare ale ciclului de via.
Etapele ciclului de via a unui sistem informatic n modelul cascad ([10]) sunt:
1. Analiza i definirea cerinelor sunt definite scopurile, serviciile i restriciile
pe care trebuie s le ndeplineasc sistemul informatic, prezentate ntr-o manier nct s
poat fi nelese att de ctre utilizatorii sistemului ct i de personalul de proiectare.
2. Proiectarea sistemului i a software-ului satabilirea cerinelor pentru
hardware i software i elaborarea arhitecturii generale a sistemului. Funciile sistemului
informaional vor fi reprezentate astfel nct s poat fi tranformate n unul sau mai multe
programe executabile.
16
3. Implementarea i testarea unitilor de program proiectarea software-ului
din etapa anterioar este transpus ntr-o mulime de programe sau module program i
verificarea faptului c fiecare program sau modul satisface specificaia sa.
4. Integrarea i testarea sistemului integrarea i testarea programelor i
modulelor program ca un sistem complet pentru a ne asigura c cerinele informaionale
sunt satisfcute. Dup testare sistemul este livrat beneficiarului.
5. Exploatarea i ntreinerea sistemului este faza n care sistemul informatic
este efectiv utilizat de ctre beneficiar i n care sunt descoperite i rezolvate eventuale
erori de proiectare i programare i omisiuni n cerinele informaionale iniiale.



















1.1.4. Coninutul bazei informaionale a unei ntreprinderi
Pentru o ntreprindere entitile bazei informaionale pot fi grupate dup cum
urmeaz:
- pentru activitatea de aprovizionare: stocuri de materiale, intrri materiale,
consumuri de materiale, contracte cu furnizorii, programe de aprovizionare;
Proiectarea sistemului
i a software-ului
Analiza i definirea
cerinelor
Implementarea i testarea
unitilor de program
Integrarea i testarea
sistemului
Exploatarea i ntreinerea
sistemului
Fig. 1.3. Etapele ciclului de via a unui sistem informatic n modelul cascad ([10])
17
- pentru activitatea de producie: tehnologii i reete de fabricaie, program de
lucru, norme de munc i consumuri de manoper;
- pentru activitatea de desfacere: stocuri de produse, contracte cu clienii,
realizri contracte;
- pentru activitatea de marketing: evoluia cererii i a ofertei, dinamica preurilor,
elasticitatea cererii i a produciei;
- pentru activitatea financiar-contabil: solduri i rulaje contabile, calculaia
costurilor, bugete de venituri i cheltuieli, contabilitatea analitic i sintetic;
- pentru activitatea de personal: evidena personalului, salarizri, dotri social-
culturale i gestiunea lor;
- pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte
tehnice, investiii, etc.
1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic
Operaiunile care se execut asupra datelor, din momentul apariiei lor, pentru a
genera informaii semnificative i relevante sunt referite la un loc prin noiunea de ciclul
prelucrrii datelor, care cuprinde cinci faze [1]: culegerea datelor, pregtirea datelor,
prelucrarea datelor, ntreinerea fiierelor i obinerea informaiilor de ieire.
Faza de culegere a datelor cuprinde dou activiti fundamentale :
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 pregtire a datelor const ntr-un numr de operaii executate asupra
datelor pentru a facilita prelucrarea lor ulterioar i anume:
clasificarea datelor, care implic atribuirea de coduri de identificare (simbol
cont, cod secie, etc.), astfel nct datele s fie incluse n submulimile
corespunztoare;
18
gruparea datelor, adic acumularea intrrilor 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
nregistrri, dup criterii de ordonare numeric, alfabetic, alfanumeric sau de
timp;
cuplarea a dou sau mai multe loturi de nregistrri ntr-unul singur;
transmiterea datelor de la un punct la altul;
transcrierea datelor dintr-o form n alta, astfel nct s se efectueze trecerea de
la scrierea de mn la cea tipizat sau de la documentele scrise la mediile
specifice.
Faza de prelucrare a datelor, poate s includ activiti, cum sunt:
calculaiile cuprind unele forme de tratare matematic a datelor;
compararea supune unei examinri simultane dou sau mai multe tipuri de date
ntre care exist o legtur logic (ex. soldul final i cel final);
sintetizarea este o activitate important prin care se comaseaz informaiile;
filtrarea este o alt operaiune prin care se extrag datele ce vor fi supuse
prelucrrilor urmtoare;
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 ntreinere a fiierelor exist mai multe activiti, dintre care amintim:
memorarea (stocarea) datelor n vederea utilizrii lor viitoare;
actualizarea datelor memorate astfel nct s surprind cele mai recente
evenimente;
indexarea datelor pentru a nlesni o uoar regsire a lor;
19
protecia 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 obinerea informaiilor de ieire.
Informaiile de ieire pot fi regsite n una din urmtoarele trei forme: documente,
rapoarte, rspunsuri la ntrebri. De cele mai multe ori, datele nu parcurg toate activitile,
iar unele dintre ele pot s nu treac prin toate cele cinci faze.
Fazele ciclului prelucrrii datelor sunt ilustrate n figura 1.4.




























1.1.6. Sisteme informatice de gestiune
Sistemele informatice de gestiune sunt sisteme integrate care creaz i actualizeaz
o baz de date unic din documentele primare, care va fi ulterior prelucrat pentru
obinerea situaiilor specifice fiecrui utilizator .
Sistemul informatic de gestiune implic urmtoarele patru componente
interdependente [4]: domeniile de gestiune, datele, modelele, regulile de gestiune.
Pregtirea datelor
ntreinere fiiere Informaii de ieire
Prelucrarea datelor
Culegerea
datelor
Fig. 1.4 Ciclul prelucrrii datelor
20
Domeniile de gestiune corespund activitilor desfurate n cadrul firmei:
activitatea de personal, activitatea de producie, activitatea comercial, activitatea
financiar-contabil, activitatea de cercetare-dezvoltare.
Datele reprezint materia prim ce urmeaz a fi prelucrat n cadrul sistemului
informatic pentru obinerea informaiilor necesare lurii deciziilor la toate nivelurile
manageriale:operaional, tactic, strategic.
Modelele de gestiune grupeaz procedurile specifice unui domeniu, iar regulile de
gestiune definesc prelucrrile ce se efectueaz asupra datelor i modul de utilizare a
informaiilor conform obiectivelor sistemului.
Sistemul informatic de gestiune reunete subsisteme informatice specializate pe
domenii ntre care se manifest interaciuni specifice. Fiecare subsistem definit grupeaz
procese informaionale omogene, specifice unui anumit domeniu.
La nivelul fiecrui subsistem vor fi definite aplicaii distincte corespunztoare
acestor activiti. La rndul lor aplicaiile sunt formate din proceduri descompunndu-se
n module reprezentnd secvene de cod prin care se realizeaz o funcie independent din
cadrul procedurii.
Exemplu. O procedur pentru operaia de actualizare se va descompune n urmtoarele
module:
1. modulul coordonator al funciei de actualizare;
2. modulul pentru realizarea funciei de adugare de nregistrri;
3. modulul pentru funcia de tergere nregistrri;
4. modulul pentru funcia de modificare a nregistrrilor din baza de date.






21
n figura 1.5. este reprezentat schema de principiu pentru sistemul integrat al
contabilitii incluznd contabilitatea de gestiune i contabilitatea financiar.









Fig.1.5. Sistem informatic de gestiune integrat al contabilitii (adaptare dup [4])



1.2. Metodologii de realizare a sistemelor informatice
Realizarea sistemelor informatice reprezint o aciune complex, care mbin un
numr mare de activiti: analiz, proiectare, implementare, exploatare [2]. n plus,
reclam resurse umane, materiale i financiare nsemnate, pe o perioad considerabil de
timp. Folosirea eficient a acestor resurse, n scopul obinerii 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 observaii au
condus la conturarea unor metodologii de realizare a sistemelor informatice.
ntre diversele etape de realizare a sistemelor informatice exist o legtur
indestructibil, legtur reflectat i de faptul c n mod logic i practic calitatea realizrii
unor activiti din etapele i fazele precedente influeneaz n mod decisiv calitatea
activitilor din etapa care urmeaz.

1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice
Metodologiile de realizare a sistemelor informatice cuprind [2]:
modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre
variaiile sistemului i dinamismul su;
regulile de formalizare a datelor i proceselor de prelucrare;
Creare
Actualizare
BD
Consultare 1
Consultare 2
Balana de
verificare
Registrul jurnal
Cartea mare

Situaia
costurilor pe
comenzi

Documente:
Comand,
Facturi,
ordin de
plat,
bon de
consum,
chitane
fiscale,
NIR,
..
22
instrumentele pentru concepia, realizarea i elaborarea documentaiei;
modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul
de viat);
definirea modului de lucru, rolului analitilor i proiectanilor i a raportului
dintre ei;
modalitile de administrare a proiectului (planificare, programare, urmrire).
Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces,
stabilind [2]:
componentele procesului de realizare a sistemului informatic (etape, subetape,
activiti, operaii) i coninutul lor;
fluxul parcurgerii (executrii) componentelor; metodele, tehnicile, procedeele,
instrumentele, normele si standardele utilizate.
n funcie 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 informatice
La realizarea sistemelor informatice se utilizeaz : metode, tehnici, instrumente,
procedee de lucru [2].
Metodele utilizate n proiectarea sistemelor informatice reprezint modul unitar
sau maniera comun n care analitii de sisteme, programatorii i alte categorii de
persoane implicate, realizeaz procesul de analiz a sistemului informaional-decizional
23
existent, proiectarea i introducerea sistemului informatic. Deci, metoda are un caracter
general, n cadrul ei aplicndu-se anumite tehnici de lucru.
Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint
felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea
diferitelor probleme ce apar n procesul de proiectare. Prin aceste tehnici se mbin
armonios cunotinele despre metode cu miestria personal a celor chemai s aplice
metodele si s utilizeze instrumentele adecvate [2].
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 funcie de situaia real la care se refer.
n abordrile incipiente se lucra cu probleme izolate i ulterior s-a efectuat trecerea
la abordarea sistemic (modular), odat cu abordarea funcional sau, mai bine zis, cu
analiza i descompunerea funcional (n fiecare modul exist cte o funcie) i ulterior
abordarea orientat-obiect [2]. 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 uniti componente prin
rafinri repetate, metoda de proiectare putnd 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 uniti economico-sociale numit organigrama
unitii poate fi reprezentat printr-o astfel de diagram ierarhic. Pentru uniti
economice productive n organigram se disting urmtoarele patru nivele de reprezentare
[10]:
nivelul conducerii strategice, reprezentat de directorul general i consiliul de
administraie;
nivelul conducerii tactice (directori pe funciuni);
nivelul compartimentelor funcionale (servicii i posturi de lucru) i de
proiectare, cercetare (laboratoare) care asigur conducerea operativ a
sistemului prin efii lor;
24
nivelul compartimentelor de producie (secii, ateliere) care realizeaz funcia
de producie a sistemului economic.
n strategia bottom up evolutiv, se pornete de la o tratare minimal care se
extinde treptat pe msura naintrii 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 muli autori astfel [1]:
metode orientate spre funcii, numite i metode ale descompunerii funcionale;
metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece
diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor;
metode orientate spre informaie sau date, orientate-informaii, aprute ca
urmare a popularizrii puternice a ingineriei informaiei a lui JAMES
MARTIN, dar i a diagramelor entitate-relaie ale lui CHEN [3];
metode orientate-obiect.
Caracteristici eseniale ale principalelor metode
Informaia este vzut de DeMarco n 1982, ca fiind posibil de abordat prin trei
perspective specifice sistemelor informaionale sau prin trei dimensiuni: date, funcii,
comportament [1].
Datele sunt reprezentate sub form de atribute (avnd n vedere structura lor),
nseamn ceea ce este stocat i reflect structura static a sistemului.
Funciile scot n eviden n mod limitat ceea ce face sistemul. El poate fi vzut i
ca un proces, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt
supuse unor transformrii funcionale, prin intermediul proceselor.
Comportamentul este invocat pentru a reda o alt modalitate de percepie a
sistemului, influena evenimentele i proprietilor sistemului, i sugereaz dinamica lui.
Metoda descompunerii funcionale (orientate funcii)
Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm
pe civa cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Warnier-Orr,
Dahl, Marco&Gowan. Descompunerea funcional este cea care anun apariia
25
proiectrii structurate i analizei structurate. Fiecare funcie este descompus n
subfuncii, pn se obin structuri uor de transpus n instruciunile limbajelor de
programare.
Metodele fluxurilor de date (orientate-proces)
Prin aceast metod analitii efectueaz reprezentarea lumii reale prin simboluri
care reprezint fluxul datelor, transformrile datelor, stocarea datelor, entiti externe, etc.
Metoda orientat spre procese are nc un mare grad de asemnare cu descompunerea
funcional.
Metode orientate spre informaii (orientate-date)
Dou realizri importante n domeniu au dat tonul unei orientri n abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P.
Chen (1976) i ingineria informaiei, 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 aceeai structur i un
comportament similar. O clas poate fi divizat n subclase cu proprietatea c subclasele
motenesc proprietile clasei i n plus pot avea proprieti suplimentare. Un sistem
informatic este gndit ca un ansamblu de obiecte autonome astfel nct datele i
prelucrrile (metodele) sunt definite n cadrul aceleiai structuri i anume obiectul.















26
Teste rezolvate
1. Care definiie este corect:
a) Un sistem reprezint un ansamblu de elemente (componente) interdependente,
ntre care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite,
cu scopul atingerii unui anumit obiectiv;
b) Un sistem este un ansamblu structurat de elemente intercorelate funcional
pentru automatizarea procesului de obinere a informaiilor i pentru
fundamentarea deciziilor..
Rspuns: a,b
2. Sistemul informaional cuprinde:
a) Ansamblul informaiilor interne i externe, formale sau informale utilizate n
cadrul firmei precum i datele care au stat la baza obinerii lor;
b) Procedurile i tehnicile de obinere(pe baza datelor primare) i de difuzare a
informaiilor;
c) Platforma necesar prelucrrii i disiprii informaiilor;
d) Personalul specializat n culegerea, transmiterea, stocarea i prelucrarea datelor.
Rspuns: a,b,c,d
3. Un sistem informatic este:
a) un sistem destinat conducerii unei organizaii,
b) un sistem utilizator-calculator integrat, care furnizeaz informaii pentru a sprijini
activitile de la nivel operaional i activitile de management ntr-o organizaie,
utiliznd 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 funcional pentru automatizarea
procesului de obinere a informaiilor i pentru fundamentarea deciziilor.
Rspuns: b,c
4. Identificai afirmaia fals:
a) Sistemul informaional este subordonat sistemului de conducere.
27
b) Sistemul informaional face legtura ntre sistemul condus i sistemul de
conducere.
c) Sistemul informatic este inclus n sistemul informaional.
d) Sistemul condus este subordonat sistemului informaional.
Rspuns: d
5. Sunt componente principale ale unui sistem informatic:
a) Baza informaional;
b) Manager general;
c) Baza tehnic;
d) Baza tiinific metodologic;
e) Sistemul de programe.
Rspuns: a,c,d,e
6. Obiectivul principal urmrit prin introducerea unui sistem informatic l constituie:
a) asigurarea conducerii cu informaii reale i n timp util necesare fundamentrii i
elaborrii operative a deciziilor;
b) asigurarea funcionrii normale si optime a activitilor;
c) creterea productivitii muncii;
d) creterea profitului;
e) mbuntirea imaginii unitii economice.
Rspuns: a
7. Dup domeniul de utilizare, sistemele informatice se clasific n:
a) Sisteme informatice pentru conducerea activitilor economico-sociale;
b) Sisteme informatice pentru conducerea proceselor tehnice;
c) Sisteme informatice i expert;
d) Sisteme informatice pentru activiti speciale.
Rspuns: a,b,d
8. Dup modul de organizare a datelor, Sistemele informatice economice pot fi mprite
n:
a) sisteme imagine;
28
b) sisteme bazate pe tehnica bazelor de date (ierarhice, reea, relaionale, orienatate-
obiect);
c) sisteme bazate pe algoritmi fundamentali;
d) sisteme bazate pe fiiere.
Rspuns: b,d
9. Ciclul prelucrrii datelor pentru sistemul informatic cuprinde urmtoarele faze:
a) culegerea datelor;
b) pregtirea datelor;
c) prelucrarea datelor;
d) tergerea datelor.
Rspuns: a,b,c
10. n faza de ntreinere a fiierelor exist mai multe activiti, dintre care amintim:
a) memorarea(stocarea) datelor n vederea utilizrii lor viitoare;
b) actualizarea datelor memorate astfel nct s surprind cele mai recente
evenimente;
c) crearea datelor;
d) indexarea datelor pentru a nlesni o uoar regsire a lor;
e) protecia datelor memorate, care cuprinde o mare varietate de proceduri i
tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.
Rspuns: a,b,d,e
11. Metodologiile de realizare a sistemelor informatice cuprind:
a) reguli de formalizare a datelor;
b) instrumente pentru concepia, realizarea i elaborarea documentaiei;
c) modalitile de administrare a proiectului;
d) instruciuni pentru luarea deciziilor;
e) modalitatea de abordare a sistemelor.
Rspuns: a,b,c,e
12. Reprezint modul unitar sau maniera comun n care analitii de sisteme,
programatorii i alte categorii de persoane implicate realizeaz procesul de analiz a
29
sistemului informaional-decizional existent, proiectarea i introducerea sistemului
informatic:
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.
Rspuns: a
13. Care din afirmaiile urmtoare sunt corecte:
a) Metoda top-down are ca obiectiv principal realizarea modularizrii 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 abordrii sistemice.
Rspuns: a
14. Nu sunt faze ale ciclului de via al dezvoltrii sistemelor:
a) microanaliza;
b) analiza;
c) colectarea;
d) proiectarea logic;
e) proiectarea fizic;
f) implementarea;
g) ntreinerea.
Rspuns: c

ntrebri
1. Enumerai principalele activiti din cadrul unei intreprinderi n vederea
identificrii entitilor bazei informaionale.
2. Definii tipurile de reele de calculatoare dup aria de ntindere geografic.
3. Definii tipurile de reele de calculatoare dup accesibilitate.
30
4. Prezentai tipurile de echipamente care pot fi utilizate n cadrul unui sistem
informatic.
5. Enumerai produsele software de baz care pot fi utilizate pentru realizarea unui
sistem informatic.
6. Definii ciclul de via a unui sistem informatic.
7. Enumerai etapele ciclului de via a unui sistem informatic n modelul cascad.
8. Enumerai metodologiile utilizate n funcie de modul de abordare i domeniul de
aplicabilitate
9. Enumerai cele 4 nivele care pot fi identificate n organigrama unei uniti
economice Productive.
31
Capitolul 2. Iniierea i planificarea realizrii unui sistem informatic

2.1. Identificarea, selecia, iniierea i planificarea proiectelor
Identificarea i selecia proiectelor de dezvoltare a sistemelor informatice
reprezint prima etap din ciclul de via a dezvoltrii sistemelor care, mpreun cu
iniierea i planificarea proiectelor, constituie microanaliza, component preluat din
managementul proiectelor. Evidenierea acestor activiti n cadrul modelului cascad de
derulare a fazelor sau etapelor ciclului de via a sistemului este reprezentat n figura 4.1
[1].
A.
identificarea
i selectarea
proiectului

B. iniierea i
planificarea
proiectului

C. analiza

D. proiectarea
logic

E. proiectarea
fizic

F. implementarea

G. ntreinerea



Fiecare etap sau faz de realizare a unui sistem informatic se descompune n
activiti. Astfel pentru identificarea i selecia proiectelor se parcurg activitile:
- identificarea potenialelor proiecte de dezvoltare;
- clasificarea i ierarhizarea lor;
- selecia proiectului.
microanaliza
Fazele ciclului de via al
dezvoltrii sistemului
Figura 2.1 Ciclul de via al dezvoltrii sistemelor [1]
32
Identificarea potenialelor proiecte de dezvoltare
Problema esenial a activitii de identificare a potenialelor proiecte de dezvoltare a
sistemului const n nominalizarea celor ce pot fi abilitai s fac propuneri pertinente.
Acetia pot fi: top-managerii, comitetul de iniiativ, departamentul utilizatorilor, grupul
de dezvoltare. Caracteristicile eseniale ale variantelor de proiecte propuse n cele patru
situaii sunt prezentate tabelul 2.1.
Tabel 2.1-variante de proiecte [1]
Propuneri Metoda de selecie
a proiectului
Caracteristicile proiectului
Top-managerii orientare puternic spre strategie;
cele mai mari dimensiuni ale proiectului;
cele mai de durat proiecte.



De sus n
jos
Comitetul de
iniiativ
orientare mixt (a diferiilor reprezentani);
vizeaz schimbrile organizaionale cele mai
mari;
analiz formal a costurilor i avantajelor
proiectelor;
proiecte mai mari i mai riscante.
Departamentul
utilizatorilor
limitat, neorientat strategic;
realizare mai rapid;
civa utilizatori reprezint niveluri ale
conducerii, precum i funciile ntreprinderii.





De jos n
sus
Grupul de
dezvoltare
integrare n sistemul existent;
puine ntrzieri n realizarea proiectului;
mai puin interesat de analizele cost avantaje.

Selecia proiectelor de dezvoltare a sistemelor informaionale
Datorit efectelor diferite i a amplitudinii lor, se recomand evidenierea distinct a
proiectelor pe termen lung i a celor pe termen scurt. Dintre ele se selecteaz cele ce ating
obiectivele organizaiei. De asemenea, se va urmri modul n care proiectele se aliniaz
dinamicii unitii.
Iniierea i planificarea proiectelor
Pentru realizarea acestei faze este nevoie de comunicarea efectiv dintre prile
implicate( analiti, clieni - manageri, utilizator).
33
Iniierea proiectului
Din momentul seleciei lui, proiectul trece n faza de iniiere, ceea ce presupune
desfurarea unei activiti laborioase, prestat de un responsabil, cunoscut n practic sub
numele de manager de proiect, care rspunde de [1]:
- Elaborarea unor studii de fezabilitate general;
- Elaborarea planurilor detaliate ale proiectelor;
- Gsirea celor mai buni membri ai echipei proiectului.
Managerul de proiect trebuie s dea dovad de multe caliti pentru a putea jongla cu
elemente cum sunt:
- Schimbrile tehnologice;
- Ciclul de via al sistemelor;
- Contractori i furnizori;
- Managementul resurselor umane;
- Metodologie i instrumente de lucru diferite;
- Restricii de timp i resurse;
- Documentare i comunicare;
- Ateptrile managerilor i clienilor.
Activitile efectuate n faza iniierii proiectului sunt:
1. stabilirea echipei de iniiere a proiectului;
2. stabilirea bunelor relaii cu beneficiarii;
3. stabilirea planului iniierii proiectului;
4. stabilirea procedurilor manageriale;
5. stabilirea cadrului de desfurare a proiectului.

Planificarea proiectului
Planificarea proiectului va cuprinde o evaluare a cerinelor informaionale ale
sistemului la nivelul ntregii organizaii.
Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i
a eforturilor necesare nfptuirii lor n cadrul fiecrui proiect.
34
Tipurile activitilor executate n cadrul planificrii proiectului cuprind [1]:
1. Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului;
2. Descompunerea proiectului n activiti uor executabile i controlabile;
3. Estimarea resurselor i crearea unui plan al resurselor;
4. Realizarea unei prime planificri calendaristice;
5. Realizarea unui plan al comunicrilor;
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 pn 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 informaiile obiective necesare
pentru a cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja
nceput mai poate fi continuat. Proporiile i durata studiilor de fezabilitate variaz, n
funcie de mrimea i natura sistemului implementat. n cazul sistemelor bazate pe
calculatoare mari, studiul are cu totul alte dimensiuni fa de varianta utilizrii
microcalculatoarelor [1].
Fezabilitatea proiectului poate fi studiat n orice faz a elaborrii lui, dar studiile,
de regul, se efectueaz n momente certe. Cnd 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 orict de subiectiv, ntruct
proiectul nu este reprezentat cu lux de amnunte. ns, ndat ce se obine o situaie mai
clar despre sistem, despre natura problemei de rezolvat, precum i despre doleanele
35
utilizatorilor, msurarea preliminar a fezabilitii poate fi determinat odat cu faza de
analiz a sistemului. Cnd proiectanii 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 proiectrii, implementrii i exploatrii. Este ultima posibilitate de
a renuna la sistem, naintea implementrii lui.
Pe parcurs, odat cu progresul nregistrat n dezvoltarea sistemului informatic, se
obin informaii din ce n ce mai certe, oferindu-se posibilitatea unor analize de
fezabilitate mult mai concludente, ceea ce atrage studierea fezabilitii n diverse faze ale
ciclului de via al sistemelor. De fiecare dat, studiile de fezabilitate trebuie s aib la
baz o foarte bun documentaie. Aceasta va conine [1]:
- Definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i
propune el s realizeze);
- Descrierea cerinelor sistemului;
- Descrierea soluiilor sistemului propus;
- Explicaia critic a motivrii 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. Documentaia planificrii poate fi alctuit 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 activitile planificate. Lungimea barelor este
proporional cu timpul alocat activitilor reprezentate. Se pot folosi diferite culori,
umbre sau forme pentru a scoate n relief anumite activiti. Ceea ce s-a planificat i
realizat, de asemenea, pot fi evideniate prin bare paralele de culori, forme sau umbre
36
diferite. Diagramele Gantt nu indic ordinea activitilor (precedena lor), ci indic data
nceperii i pe cea a finalizrii. Se recomand pentru descrierea proiectelor simple sau a
unor componente ale proiectelor mari, sau a activitilor prestate doar de o singur
persoan, precum i pentru monitorizarea modului n care se efectueaz activitile n
comparaie cu cele planificate (ca dat).

Evidena promovrii vnzrilor (EPV)

Aprilie
2005
Mai
2005
Iunie
2005
Iulie
2005
August
2005
Septembrie
2005
Nr.
Crt.
Nume
activitate

1. Colectarea
cerinelor

2. Proiectare
ecrane

3. Proiectare
rapoarte

4. Proiectare
baze de date

5. Documentaie
utilizator

6. Programare
7. Testare
8. Instalare
9. edina de
analiz


Proiect: EPV
Data:
Analist:
Critic: n lucru: Sintez:


Necritic: Punct de reper: Derulat:

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

Teste rezolvate
1. Propunerile pentru identificarea proiectelor de dezvoltare sunt fcute de:
a) top-manageri; b) personalul auxiliar;
c) muncitori; d) departamentul utilizatorilor.
Rspuns: a, d
37
2. Selecia proiectelor de dezvoltare a sistemelor informaionale, urmrete:
a) atingerea obiectivelor organizaiei;
b) bunul mers a informaiei;
c) creterea duratei de implementare.
Rspuns: a
3. Care nu sunt activitile efectuate n faza iniierii proiectului:
a) stabilirea echipei de iniiere a proiectului;
b) stabilirea bunelor relaii cu beneficiarii;
c) stabilirea planului iniierii proiectului;
d) stabilirea procedurilor manageriale;
e) stabilirea cerinelor sistemului.
Rspuns: e
4. Tipurile activitilor executate n cadrul planificrii proiectului cuprind:
a) Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului;
b) Descompunerea proiectului n activiti uor executabile i controlabile;
c) Crearea bazei de date;
d) Crearea unui buget preliminar;
e) Implementarea proiectului.
Rspuns: a, b, d
5. Urmtoarele afirmaii sunt corecte:
a) Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare
pentru a cunoate 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 ntreinere a sistemelor;
c) Diagrama Gantt este o modalitate de reprezentare grafic a proiectului.
Rspuns: a, c
6. Studiile de fezabilitate trebuie s conin:
a) Definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i
propune el s realizeze);
38
b) Descrierea cerinelor sistemului;
c) Explicaia critic a motivrii studiului ntreprins;
d) Cuantificarea tuturor costurilor materiale i beneficiilor aferente.
Rspuns: a, b, c, d
7. Diagramele Gantt se utilizeaz pentru:
a) reprezentarea ordinii activitilor desfurate pentru realizarea proiectului;
b) reprezentarea grafic a proiectului;
c) descrierea proiectelor simple sau a unor componente ale proiectelor mari;
d) monitorizarea stadiului realizrii activitilor planificate.
Rspuns: b, c, d
39
Capitolul 3
Analiza sistemului existent i definirea cerinelor noului sistem

3.1. Studiul sistemului informaional existent
Prin sistem existent se nelege realitatea obiectiv din organizaia pentru care
urmeaz a se realiza sistemul informatic solicitat printr-o comand numit cererea
beneficiarului.
Analiza sistemului existent i definirea cerinelor noului sistem este prima etap
din ciclul de via al dezvoltrii sistemelor informatice, etap prin care se determin
modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori
utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv
principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui
sistem informatic.
Studiul sistemului existent cuprinde un grup de activiti care urmresc
cunoaterea performantelor tehnico-funcionale ale sistemului informaional, att n
ansamblul su, ct i pentru elementele de structur ale acestuia, a cerinelor
informaionale ale conducerii, cunoaterea lipsurilor i restriciilor pe care le prezint
sistemul existent fa de aceste cerine. De modul de realizare a acestor activiti depinde
ntregul proces de realizare a sistemului informatic.
Studiul sistemului existent const n [2]:
- definirea caracteristicilor generale ale sistemului economic;
- studiul activitilor de baz desfurate n sistem;
- studiul sistemului de conducere;
- studiul sistemului informaional;
- identificarea metodelor i mijloacelor tehnice.
Definirea caracteristicilor generale ale sistemului economic implic :
- cunoaterea profilului, obiectivelor agentului economic;
- cunoaterea locului n sfera serviciilor si sfera produciei;
- cunoaterea relaiilor de cooperare cu ali ageni economici;
40
- cunoaterea specificului activitii de baz ( producie, servicii);
- cunoaterea nivelului tehnic;
- cunoaterea principalilor indicatori economici i evoluia lor;
- dezvoltarea, modernizarea etc.
Studiul activitilor desfurate n sistemul economic, modul de realizare a
funciunilor unitii economice se face prin:
1. Pe baza statutului de funcionare a societii se studiaz:
- activitile i sarcinile din cadrul acestor funciuni;
- atribuiile ce revin compartimentelor;
- modul de realizare a activitilor funcionale din cadrul unitii economice.
2. n cazul activitii de producie se prezint:
- fluxul de producie, amplasarea locurilor de munc, depozitelor etc.;
- tipurile de produse, structura lor, ciclurile de realizare;
- modul de organizare a produciei, stocarea produciei, transporturile interne,
controlul de calitate;
- resursele existente:
- capaciti;
- asigurarea tehnic / proiectarea de produse noi;
- norme tehnice;
- asigurarea cu materiale necesare;
- sistemul existent de programare a produciei.
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 funcionare a societii, tipuri de
decizii, modul de lucru a deciziilor.
Studiul sistemului informaional presupune:
41
- elaborarea schemei fluxului informaional global (cu punerea n eviden a
principalelor activiti i a legturilor statice i dinamice dintre acestea);
- estimarea cantitativ i calitativ a informaiilor de intrare-ieire, modul de
culegere i prelucrare;
- identificarea principalilor algoritmi, regulilor de calcul i a punctelor si
regulilor de control;
- cunoaterea principalelor restricii ale sistemului informaional;
- situaia raionalizrii fluxurilor i a documentelor din unitatea economica,
studii elaborate, stadiul lor de implementare;
- sistemul de codificare utilizat, restricii;
- performanele i limitele sistemului informaional existent.
Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea
datelor n cadrul sistemului informaional existent se face evideniind: mijloacele tehnice
existente n dotarea unitii economice ( modul de utilizare, cheltuielile de exploatare,
personalul implicat, performante); existena unor aplicaii proiectate i/sau implementate.

3.2. Determinarea cerinelor sistemului
Determinarea cerinelor sistemului este activitate esenial n aflarea situaiei
existente i a ceea ce se dorete n viitor. Rezultatul activitii de determinare a cerinelor
sistemului se concretizeaz n diferite forme ale informaiilor colectate, cum sunt copii ale
interviurilor, nsemnri efectuate n timpul observrii i analizei documentelor,
interpretri ale rspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale
posturilor de lucru .a., precum i rezultate ale prelucrrilor efectuate de calculator, cum
ar fi prototipurile [1].
Rezultatele prezentate dup aceast activitate pot fi rezumate astfel:
1. Informaii obinute n urma conversaiilor cu utilizatorii sau prin observarea
activitilor prestate de acetia: copii sau sinteze ale interviurilor, rspunsurile la
chestionare sau interpretri ale acestora, nsemnri i rezultate din observarea
activitilor, procese verbale ale edinelor ce au avut loc n acest scop;
42
2. Informaii 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
documentaia sistemului existent, rapoartele consultanilor;
3. Informaii obinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii
ale fiierelor sesiunilor grupului de sprijinire a sistemului, coninutul depozitelor i
rapoartele existente n CASE, ecrane i rapoarte rezultate din prototipurile
sistemului, .a.

3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului
Metodele utilizate frecvent n analiza sistemului existent sunt:
- Interviul;
- Chestionarul.
Interviul este o metod foarte rspndit pentru culegerea informaiilor din
sistemul informaional. Utilizatorii acestei metode sunt n general analitii care nu sunt
familiarizai cu unitatea studiat i cu problemele ei. Prezint avantajul c las foarte
mult libertate creativ analistului n construirea i desfurarea lui. n alegerea
persoanelor de intervievat trebuie avute n vedere urmtoarele constatri [10]:
- persoanele care ocup poziii medii n ierarhia structurii organizatorice
furnizeaz informaiile cele mai apropiate de realitate;
- colectarea de informaii corecte necesit intervievarea att a personalului de
conducere, ct i a celui de execuie;
- n prealabil trebuie verificat competena subiecilor intervievai;
- lipsa unei atitudini critice poate s denote reineri 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
ctre persoanele intervievate.
43
Chestionarul poate fi utilizat att de ctre analitii nceptori, ct i de ctre cei
avansai, familiarizai sau nu cu problemele informaionale-decizionale ale unitii. Prin
utilizarea lui dispare filtrul de informaii care este analistul iar cel care furnizeaz
informaii are posibilitatea s se concentreze mai bine asupra rspunsurilor. Utiliznd
aceast metod, particip un numr mare de furnizori de informaii. Limitele
chestionarului constau n faptul c este o metod de verificare a unor cunotine
prealabile, fapt ce implic cunoaterea prealabil a domeniului.
Aceast metod necesit timp relativ ndelungat pentru ntocmirea chestionarului
precum i de culegere i prelucrare a rspunsurilor. Chestionarul nu are o arie larg de
utilizare.

3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului
Ca efect al tendinelor de mrire a timpului de analiz a sistemelor existente, n
ultimii ani, s-a efectuat trecerea spre analiza mai puin pronunat a sistemelor ce urmeaz
a se realiza. Tehnicile moderne, JAD i prototipizarea, preiau tot mai puine 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 [1].
Joint Application Design(JAD)
Spre sfritul anilor 1970, specialitii n realizarea de sisteme de la IBM au
elaborat un nou proces de culegere a cerinelor informaionale ale sistemelor i de
revizuire a proiectelor sistemelor, numindu-se JAD.
Ideea principal a proiectrii JAD o constituie punerea laolalt a tuturor forelor
interesate n dezvoltarea sistemelor: utilizatori-cheie, managerii i analitii de sistem
implicai n analiza sistemului curent. Din acest punct de vedere JAD este similar
interviului la nivel de grup. Totui n sesiunea JAD se urmrete o anumit secven de
derulare a activitilor, pe baza unor roluri bine stabilite.

44
Prototipizarea i determinarea cerinelor sistemelor
Prototipizarea este un proces interactiv prin care analitii i utilizatorii pun n
discuie o versiune rudimentar a unui sistem informaional, care va fi ntr-o continu
schimbare, n funcie de reacia utilizatorilor. Prototipizarea renun la ciclul de via al
dezvoltrii sistemelor sau la creterea rolului su [1].
Pentru culegerea informaiilor despre cerinele utilizatorilor nc se apeleaz la
interviuri, dar prin prototipizare, operaiunea va fi mai simpl i va solicita un timp mai
scurt. Prototipul este vzut i testat de utilizator, avnd posibilitatea s precizeze ce ar mai
dori, dar i s-i genereze aceast form nou, cu ajutorul specialitilor.
Prototipizarea este facilitat de cteva limbaje sau produse program, inclusiv
instrumentele de tip CASE.
Prototipizarea este foarte util n determinarea cerinelor sistemului atunci cnd
[1]:
- cerinele utilizatorului nu sunt prea clar formulate sau bine nelese;
- unul sau mai muli utilizatori sau susintori sunt implicai n sistem;
- se utilizeaz anumite mijloace de lucru (formulare i rapoarte predefinite).
Prototipizarea genereaz i deficiene, cum ar fi:
- tendina de evitare a unui cadru formal de elaborare a documentaiei privind
cerinele sistemului, ceea ce va ngreuna n viitor orice control;
- fiind conceput de un numr mic de utilizatori va fi probabil respins de viitorii
utilizatori;
- fiind conceput izolat este puin probabil ca el s fie integrat n sistemul existent;
- nerespectndu-se etapele ciclului de via al dezvoltrii sistemelor pot fi omise
aspecte eseniale, cum ar fi securitatea, controlul datelor introduse i
standardizarea la nivel de sistem.
Paii prototipizrii sunt [1]:
- Identificarea cerinelor principale ale sistemului;
- Realizarea prototipului iniial;
- Proces iterativ de adaptare a sistemului la cerinele utilizatorului;
45
- Folosirea sistemului aprobat de utilizatori.
Dup determinarea cerinelor sistemului urmeaz structurarea acestora prin
utilizarea unor instrumente specifice de modelare logic.

3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor
Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate
apeleaz la operaiunea de modelare logic a datelor i prelucrrilor sub form de
diagrame, diferenele constnd doar n folosirea mai pronunat a diagramelor pentru
descrierea sistemului, ncadrndu-le n diagrame de context, diagrame ale fluxurilor de
date fizice i diagrame ale fluxului de date logice. Altele apeleaz la combinaii de
diagrame, tabele i forme descriptive [1].
Diagrama de context scoate n eviden aria de ntindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaiei i a celor externe, sub denumirea de
entiti externe sistemului analizat.

3.3.1. Diagramele fluxurilor de date (DFD)
Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie,
reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional
curent.
Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor i cerinele funcionale ale noului sistem.
Descrieri ale obiectelor DFD se regsesc n aa-zisele dicionare ale proiectelor sau
depozitele CASE (repository) [1].
Diagramele fluxului de date DFD au ca obiectiv urmrirea modului de transfer al
datelor ntre procesele de prelucrare a lor, astfel de diagrame se mai numesc i modele ale
proceselor de prelucrare, iar operaiunea se numete modelarea proceselor.
DFD reprezint doar una din tehnicile de analiz structurat.
46
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor
fluxurilor de date a cptat noi accepiuni 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 reprezentrile grafice, de exemplu
diagramele. n continuare vom folosi tehnica reprezentrii grafice a fluxului
informaional. Proiectarea fluxului informaional reprezint circulaia informaiei n
sistem, transformrile suferite, stocarea informaiei precum i scurgerile de informaie n
afara sistemului. Scopul diagramelor de date DFD pentru o anumit component
organizatoric sau funcional la care se refer (secie, birou, compartiment, ntreaga
unitate, o anumit activitate vnzri, cumprri, ncasri, pli, .a) este de a scoate n
relief, ntr-o manier ct mai sugestiv, urmtoarele aspecte [1]:
- sursa datelor de prelucrare;
- operaiunile de prelucrare prin care trec datele;
- destinaia datelor prelucrate;
- legtura existent ntre prelucrri i activitatea de stocare a datelor.
ntocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafic a transformrii datelor de intrare n date de ieire
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 numr(descriere a funciei procesului de prelucrare,
ncepnd cu un verb, urmat de o descriere a obiectului funciei de
prelucrare). n DFD fizic pentru sistemul existent, se va preciza
i locaia (compartiment / persoan) procesului.

47


flux de date: este constituit din datele transmise ntre dou
procese. Fluxul de date este etichetat printr-un substantiv ce
sugereaz informaia sau pachetul de informaii transmise.



entitate extern (terminator): surs / receptor de date. Poate
fi un alt sistem (organizaie, compartiment).



stoc de date: un depozit temporar sau permanent de date.
Poate fi:
- manual: registre, dosare, arhiv de documente
- pe suport magnetic: fiiere.


Convenii folosite n diagramele de reprezentare a fluxurilor de date DFD:
- procesele i stocurile de date sunt numerotate secvenial, pentru a putea fi
identificate. Numerele asociate proceselor nu semnific ordinea de execuie a
acestora;
- pentru a evita fluxurile de date ntretiate i aspectul de pienjeni al
diagramei, entitile externe i stocurile de date pot fi duplicate. O entitate
extern duplicat se reprezint prin trasarea unei linii oblice, iar un stoc
duplicat printr-o linie suplimentar vertical n partea stng a cutiei;
- pentru a face diagramele mai lizibile, entitile externe sunt plasate, pe ct
posibil, n jurul diagramei iar stocurile de date, n partea central a diagramei;
- fluxurile de date de la - ctre stocurile de date sunt unidirecionale (fie de
adugare, fie de consultare) i nu sunt etichetate.
3.3.2. Descompunerea funcional i rafinarea DFD
Dac sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil s
realizm de la nceput o DFD detaliat. Pentru a putea descrie n detaliu sistemele
complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o
descompunere funcional a sistemului, care este realizat prin rafinarea succesiv a
proceselor.
48
Primul nivel (nivelul 0) l constituie DIAGRAMA CONTEXTUAL, care
definete graniele ntre sistemul analizat si mediu.
Nivelele urmtoare se obin prin rafinarea proceselor complexe ntr-o diagram de
nivel inferior.
Pentru aplicaia DECONTRI au rezultat urmtoarele diagrame [1]:
































Figura 3.1. Diagrama contextual pentru aplicaia Decontri
Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicaia
49





























Definirea direciilor de perfecionare a actualului sistem
Pe baza activitilor de evaluare i analiz critic se identific neajunsurile
actualului sistem i se propun soluii de nlturare a acestora se formuleaz variante de
soluii, iar n cadrul acestora se definesc cerinele i restriciile de realizare a sistemului
informatic.
Definirea direciilor de perfecionare presupune:
1. specificarea obiectivelor i a performantelor sistemului informatic;
2. stabilirea domeniilor de probleme i a principalelor funciuni ale sistemului
informatic;
3. definirea cerinelor si restriciilor informaionale pe domenii de probleme i funciuni
care const n:
Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaia Decontri
50
- definirea principalelor intrri/ ieiri;
- definirea soluiei de organizare a datelor;
- definirea variantelor tehnologice de prelucrare;
- definirea restriciilor informaionale i de control.
4. formularea condiiilor pentru realizarea sistemului informatic, care const n:
- specificarea termenelor i duratelor solicitate;
- precizarea prioritilor n realizarea obiectivelor sistemului informatic;
- specificarea cerinelor speciale privind flexibilitatea, compatibilitatea cu alte
sisteme, gradul de generalizare al sistemului.
Pentru fiecare variant de soluie 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 curent
Indiferent de tipul sistemului analizat, manual sau informatizat, acesta va fi
nlocuit de un nou sistem. Orict 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
conin 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 neaprat 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 cruia se realizeaz:
- pune n eviden ce face sistemul, eliminnd detaliile referitoare la modul cum
funcioneaz sistemul n implementarea actual;
51
- pune n eviden funciunile de baz ale sistemului;
- permite identificarea i eliminarea problemelor legate de redundana datelor i
duplicarea proceselor de prelucrare;
- permite stabilirea cu o mai mare precizie a granielor 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 alctuit de la procesele frunz i va continua prin agregarea proceselor
ctre nivelurile superioare. Se parcurg urmtorii pai [1]:
1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin
gruparea ntr-un stoc logic de date a entitilor nrudite sau utilizate frecvent.
Dup identificarea stocurilor logice de date se construiesc:
- diagrama de coresponden ntre stocuri logice i entitile din modelul logic;
- diagrama de coresponden ntre stocuri fizice i stocuri logice de date.
2. nlturarea dependenelor fizice i temporale din denumirea proceselor i a fluxurilor
de date: din DFD la nivel fizic (se observ c nu exist referine fizice i temporale n
aplicaia decontri).
3. Derivarea proceselor logice:
- scoaterea n afara granielor 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 prelucrri asemntoare sau multiple
care se execut mpreun sau n secven;
- nlturarea proceselor care in de implementarea actual i a proceselor
redundante.
n cazul aplicaiei prezente:
52
- se combin procesele nregistrare ncasri n numerar i nregistrare ncasri
prin virament deoarece realizeaz prelucrri asemntoare;
- se nltur procesele redundante nregistrare ncasri n jurnal si nregistrare
plti n jurnal.
4. Derivarea fluxurilor logice care presupune nlocuirea numelui de document numai cu
fluxul de informaii utilizate efectiv de proces.
5. Gruparea proceselor elementare i transformarea diagramei fizice n diagram
logic, aplicnd cei 5 pai.

Relaia existent ntre DFD i modelul datelor
Dup cum reiese din prezentrile anterioare, fiecare sgeat 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. Cnd 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 operaiunea, dar foarte important este s prezentm
structura datelor pstrate. Firesc, i n cazul fluxului de date, i n cel al stocrii lor nu
trebuie uitat descrierea semnificaiei economice. Structura datelor trebuie s fie redus la
a treia form normalizat, iar coninutul locurilor de stocare a datelor s fie prezentat prin
reduceri la unul sau mai multe tabele relaionale n forma a treia normalizat [1].
n cazul aplicaiei DECONTRI, se obine nivelul elementar al DFD a sistemului
logic pentru Decontri cu beneficiarii reprezentat n figura 3.4. Nivelele superioare ale
DFD a sistemului logic sunt identice.





53
Tabel 3.1 aplicaia Decontri
Sursa Destinaia Nume flux Continutul fluxului
1.1. nregistrare
facturi
desfacere
D2 FACTURI
DESFACERE
desfaceri CODCLIENT, DENCLIENT,
ADRESAC, CONTC,
BANCA_C, DATAFACTD,
NRFACTD, TOTALFACTD
D2 FACTURI

DESFACERE
1.3. Analiza
situaie client
desfaceri CODCLIENT, DENCLIENT,
ADRESAC, CONTC, BANCA_C,
NRFACTD, TOTALFACTD


























3.3.4. Modelarea logicii proceselor
Dup ce au fost descrise procesele de conversie a datelor n informaii, prin
intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefeaz i logica
intern a proceselor, orict ar fi de detaliate, chiar i la nivelul proceselor primare, se
impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie
Figura 3.4. Diagrama fluxului de date
54
astfel descrise nct s poat fi convertite n programe prin intermediul limbajelor de
programare.
n faza de analiz, modelarea logicii proceselor se va derula ct mai detaliat i
complet posibil, dar operaiunea 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 obinute n urma modelrii proceselor sunt
descrieri i diagrame structurate care vor prezenta logica fiecrui proces, precum i
diagrame care vor evidenia dimensiunea temporal a sistemelor, cnd 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
urmtoarele elemente ale documentaiei [1]:
- reprezentarea n engleza structurat;
- reprezentarea logicii proceselor prin tabele de decizie;
- reprezentarea logicii proceselor prin arbori de decizie;
- tabelul sau diagrama strilor de tranziie.

Reprezentarea logicii proceselor prin engleza structurat
Engleza structurat este o form mult simplificat i modificat a limbii engleze,
folosit pentru descrierea coninutului casetelor care marcheaz procesele (prelucrrile)
din diagrama fluxului de date. Cuvintele folosite sunt n strns legtur cu logica folosit
n conceperea procedurilor componente ale sistemelor informatice [1]. 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 documentaie. Utilizarea englezei structurate pentru procesul
Analiza situaie client din decontri cu beneficiarii este reprezentat mai jos.

55
Analiza situaie client
WRITE CLIENTI,FACTURI_DESF, NCASRI
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;
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(NCASRI);
vb=0; vb1=0;
while (not eof (NCASRI) AND vb=0)
{
if (cod=NCASRI.client AND
FACTURI_DESF.nrfactd=NCASRI.nrfactd AND
FACTURI_DESF.datafactd =NCASRI.datafactd)
{ if (FACTURI_DESF.totalfactd !=NCASRI.sumaincasata)
{ sold = sold+ FACTURI_DESF.totalfactd -
NCASRI.sumaincasata}
vb1=1;
}
else if (vb1=1) vb=1
READ (NCASRI)
}
MOVE FIRST LINE NCASRI
READ (FACTURI_DESF)
56
}
CLOSE (FACTURI_DESF, NCASRI, CLIENTI)

3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)
n cadrul modelrii conceptuale a datelor se va renuna la abordarea proceselor i
se va trece la abordarea sistemelor prin prisma datelor. La fel ca i n cazul modelrii
proceselor i modelrii logicii proceselor elementele eseniale vor fi diagramele.
James Martin i Carma McClure, atunci cnd reliefeaz importana tehnicilor
structurate prin obiectivele ce i le propun, consider c o parte a acestora au legtur i
cu datele, i anume [1]:
- S se realizeze o administrare riguroas a datelor. Administrarea datelor se
refer la structurarea corect a datelor, la uniformitatea modalitilor 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 eseniale ale sistemelor: resursele.
- S se efectueze o analiz sntoas a datelor. Analizele datelor clarific
problemele de structurare a lor i conduc la structuri stabile ale acestora,
concretizate prin costuri reduse ale realizrii sistemelor. Dac baza de date a
unitii este deosebit de important, atunci pe analiza datelor trebuie s se pun
un accent aparte, ea fiind ntotdeauna realizat naintea proiectrii programelor.
Firesc, dac tim care sunt cerinele unui sistem (ieirile), imediat ne vom pune
ntrebarea din ce se obin acestea (intrrile) i apoi vom urmri cum se pot
obine ieirile (procesele).
Obiectivul principal al ingineriei informaiei este crearea unui set de metodologii
care s poat fi folosite n cele mai diverse medii de lucru, astfel nct 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 vzute dou
categorii mari de operaiuni:
- asigurarea datelor (creare, actualizare);
57
- utilizarea datelor (obinere de documente, de diverse rapoarte, analize What-
If, sprijin decizional, diferite cutri de informaii, control i auditare
ntreprindere).
Modelul conceptual al datelor nseamn o modalitate de reprezentare a datelor
organizaiei. Rolul su este de a scoate n relief toate regulile privind identitatea i
legturile existente ntre date.
Cea mai cunoscut form utilizat pentru modelarea datelor este diagrama entitate-
relaie (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, operaiunea are loc la nivel de ntreprindere, prin apelarea
la o categorie foarte larg de date neglijndu-se detaliile exagerate. Doar n etapele
urmtoare, n spe cnd se trece la definirea proiectului, are loc construirea unui model
anume entitate-relaie prin care s fie scoas n eviden aria de ntindere a proiectului. n
timpul structurrii cerinelor, un model entiatate-relaie reprezint cerinele conceptuale
de date pentru sistemul luat n discuie. Dup ce sunt descrise complet intrrile i ieirile
sistemului n cadrul proiectrii logice, modelul conceptual al datelor, redat sub forma
entitate-relaie, este rafinat nainte de a fi trecut ntr-un format logic (de regul, un model
relaional al datelor) din care se definesc bazele de date i are loc proiectarea fizic a
acestora.
Se consider c, n timpul modelrii conceptuale a datelor, se produc i se
analizeaz cel puin patru diagrame entitate-relaie [1]:
1. DER care s acopere datele necesare aplicaiei proiectului. Ea va permite stabilirea
necesarului de date ale aplicaiei proiectului, fr s se in seama de constrngerile
sau confuziile generate de detaliile care nu sunt nc necesare.
2. DER pentru aplicaia ce va fi nlocuit. Diferenele dintre aceste diagrame arat ce
schimbri trebuie ntreprinse pentru convertirea bazei de date n noua aplicaie. Nu se
aplic n cazul sistemelor complet noi.
58
3. DER care s scoat n relief ntreaga baz de date din care noua aplicaie i va extrage
datele. Ct timp mai multe aplicaii pot folosi aceeai baz de date, aceast diagram i
prima evideniaz modul n care noua aplicaie apeleaz la coninutul unor baze de
date mult mai extinse.
4. DER pentru ntreaga baz de date din care aplicaia curent i extrage datele necesare.
Ea este discutat doar pentru sistemele care exist i pentru care se urmrete
mbuntirea.
Metodele de determinare a cerinelor trebuie s fie orientate, prin ntrebrile puse,
prin anchetele efectuate, i asupra datelor, nu numai asupra proceselor i logicii lor. La
nceput, chiar fr utilizarea unei terminologii de specialitate, analistul va fi preocupat de
modul n care va afla ct mai multe informaii despre datele necesare viitorului sistem
pentru a funciona la parametrii proiectai. ntrebrile vor fi astfel formulate nct s se
realizeze o bun nelegere 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: cnd i cum sunt
prelucrate sau folosite datele, pentru a se realiza modelarea datelor.
Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere [1].
Un prim punct de vedere, formulat n literatur sub numele de metoda top-down,
va scoate n eviden regulile derulrii activitii firmei, printr-o nelegere foarte clar a
naturii afacerii, i nu se va opri asupra detaliilor privind modul n care ecranele, rapoartele
sau documentele sunt folosite n organizaie.
n afara metodei top-down, informaiile necesare construirii modelului datelor se
pot obine i prin urmrirea documentaiei 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
evideniate datele prelucrate n sistem i de aici va rezulta necesarul de date meninute n
baza de date a sistemului.


59
3.4.1. Modelul Entitate/Relaie (E/R)
Cercetrile efectuate pentru definirea unui model de date care s permit
reprezentarea ct mai fidel a realitii au condus la definirea conceptului de model
semantic nc din 1976 cnd Chen a prezentat modelul Entitate-Relatie (E/R), care
constituie astzi 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, fr a ine seama de anumite constrngeri 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
realitii avute n vedere, constituind astfel o etap intermediar n proiectarea unei baze
de date, fiind din acest punct de vedere asemntor pseudocodului utilizat n activitatea de
programare.
Modelul Entitate/Relaie (E/R) permite reprezentarea schematic a realitii avute
n vedere cu ajutorul unei diagrame E/R definit plecnd de la conceptele de baz: tip de
entitate, tip de relaie (legtur, corelaie), atribut.

Tipuri de entiti, entiti
Tipul de entitate reprezint o clas de obiecte sau un concept cu o existen de sine
stttoare, este identificat printr-un nume i este definit de un set de proprieti numite
atribute. O entitate este un obiect particular al clasei de obiecte, reprezint o instan a
tipului de entitate i este definit de valori corespunztoare ale atributelor ce definesc tipul
de entitate. Entitile 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 simit prezena la un moment dat. La rndul lor, obiectelor li se pot
asocia cel puin dou evenimente: apariia i dispariia lor. Exemple: ncheierea i
ncetarea contractului de munc; predarea produselor la secia expediie i desfacerea lor
la beneficiari .a. Evenimentelor le corespund asocieri ntre dou sau mai multe obiecte.
Exemplu: CLIENT COMAND PRODUS. Raportat la o anumit organizaie, o entitate
este o persoan, un loc, un obiect, eveniment sau concept din domeniul de activitate a
60
utilizatorului despre care organizaia dorete s pstreze anumite date. Se cuvine precizat
diferena dintre tipurile entitilor (entity types) i cazurile/instanele entitii (entity
instances) [1]. Tipul entitii, cunoscut i sub numele de clasa entitii, este o colecie de
entiti care au proprieti sau caracteristici comune. Referirea general la elementele ce
pot fi catalogate ca entiti se va realiza printr-un substantiv denumit cu litere majuscule,
plasate n interiorul dreptunghiului corespunztor entitii.
O instaniere a entitii sau instan, denumit n continuare, caz al entitii 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/instane ale acestei entiti 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 entiti care prezint interes pentru organizaie. La
rndul lor, i relaiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicaia DECONTRI i unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaClient
Ca i numele tipurilor entitilor, numele atributelor sunt substantive scrise cu
majuscule (eventual + minuscule), plasate n interiorul elipselor, legate de entitatea creia
i se asociaz. De multe ori ns, chiar i n cazul folosirii produselor CASE, pentru a nu se
ncrca o diagram entitate-relaie, se evit prezentarea atributelor. Operaiunea se face, n
schimb, n repository, depozitul de informaii despre proiect. Aici orice atribut se descrie
separat, ca orice obiect distinct.



61
Cheie candidat i cheie primar
Fiecare tip de entitate trebuie s aib un atribut sau un set de atribute prin care s
se efectueze diferenierea fiecrui caz de acelai tip.
Un set de atribute ale cror valori identific n mod unic instanele unui tip de
entitate, constituie o cheie candidat pentru acel tip de entitate. Avnd 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 [1].
n reprezentrile 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 relaie reprezint o asociere ntre dou sau mai multe tipuri de entiti i
definete legtura care exist ntre tipurile respective de entiti. Fiecare tip de relaie este
identificat printr-un nume care descrie funcia sa i poate conine atribute. O relaie sau o
instan a unui tip de relaie este o legtur ntre instane ale tipurilor de entiti asociate
n cadrul tipului de relaie corespunztor. Dac R este un tip de relaie definit pe tipurile
de entiti E
1
, E
2
,,E
n
, atunci R este funcional fa de Ei (1 i n) dac orice instan a
tipului de entitate Ei este determinat univoc de instane ale tipurilor de entiti E
1
,,E
i-
1
,E
i+1
,,E
n
prin relaia R. Un tip de relaie R definit pe tipurile de entiti E
1
, E
2
,,E
n
,
poate fi funcional sau nu fa de fiecare din tipurile de entiti E
i
(1 i n).
Un atribut definete o proprietate a unui tip de entitate sau a unui tip de relaie i
poate fi: atribut simplu sau elementar, atribut compus (format din mai multe componente,
fiecare avnd o existen independent), atribut derivat (valorile sale se obin plecnd de
la valorile altor atribute).
Pentru reprezentarea unor probleme complexe de tip baz de date, aprute
ncepnd din anii 80, modelul de date semantic a fost extins cu noi concepte semantice,
rezultnd astfel modelul entitate relaie extins EER. n acest sens la conceptele de baz au
fost adugate conceptele suplimentare de superclas, subclas i motenire.
62
O superclas reprezint un tip de entitate care conine 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 rndul su subclase,
astfel nct se pot construi ierarhii de clase. O subclas motenete toate atributele
superclasei, putnd 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 [COBS01], [DORO98] o serie
de simboluri reprezentate n figura 3.5.
63


























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 relaie>
Reprezentare tip de relaie cu numele <nume tip relaie>

Relaia R funcional fa de tipul de entitate E
Relaia R nefuncional fa de tipul de entitate E
E R
E R
Superclasa
Subclasa
Apartenena subclasei la superclas
<nume tip entitate>
<nume atribut>
Apartenena 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
64
Un exemplu de reprezentare a unui tip de entitate prin diagram este ilustrat n
figura 3.6.











Relaiile entitilor
O relaie este o asociere ntre cazurile/instanele uneia sau mai multor tipuri de
entiti care prezint interes pentru organizaie. Ele se reprezint printr-un romb ca n
exemplul din figura 3.7.





Cardinalitatea relaiilor
Presupunem c exist dou tipuri de entiti, A i B, ntre care exist o linie de
legtur pentru a marca relaia. Cardinalitatea unei relaii este dat de un numr al
cazurilor/instanelor entitii B care pot sau care ar putea s fie asociate cu fiecare caz al
entitii A. Cardinalitatea este sugerat prin 0 (zero), 1, M (multe), cu meniunea c ele
pot avea prezen obligatorie sau opional. Cardinalitatea se poate reprezenta n moduri
diferite, n funcie de notaia folosit. De exemplu, ea poate fi notat cu semne (0, 1, M,
N) sau prin simboluri (linie cu vrf simplu de sgeat pentru 1, linie cu vrf dublu de
sgeat pentru M. Alteori, 1 se reprezint prin linie simpl i M prin vrf de sgeat). n
multe materiale, inclusiv produse CASE, se folosete notaia model-date, cunoscut mai
PRODUSE FURNIZORI
Figura 3.7. Reprezentare relaie Oferte ntre entitile FURNIZORI, PRODUSE
Oferte

CLIENT
DenClient
AdresaClient
CodClient
Figura 3.6. Model de reprezentare a atributelor prin DER
65
mult sub numele laba-gtei, conform creia cardinalitatea se reprezint prin urmtoarele
simboluri [1]:









Entiti compuse sau asociative (gerundive)
Atributele pot fi asociate cu o relaie 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. Prezentm, mai jos, cteva dintre datele concrete [1]:
MATRICOLA
STUDENT
NUME CURS DATA
PROMOVRII
1111 Informatic Iulie 1999
1177 Informatic Septembrie 1999
1155 Informatic Septembrie 1999
1111 Drept comercial Ianuarie 2000
Din analiza cazurilor rezult c atributul DATA_PROMOVRII nu este o
proprietate a entitii STUDENT, ct timp examenele pot fi date la momente diferite. Dar
nu este nici o proprietate a entitii CURS, ct timp acelai curs poate fi susinut la date
diferite. n schimb, DATA_PROMOVRII este o proprietate a relaiei dintre STUDENT
i CURS. Atributul se asociaz relaiei i se prezint sub form de diagram, ca n fig. 3.8.












obligatoriu 1
opional 0 sau 1
n
obligatoriu multe (n, unde n ia valori de la 1 la M)
n
opional 1 sau multe (n, unde n ia valori de la 1 la M)

STUDENT
CURS
Data promovrii
Promovare
Figura 3.8. Asocierea unui atribut la o relaie [1]

66
De aici rezult un caz aparte de entitate, numit gerundiv sau compus sau
asociativ care, de fapt, este o relaie folosit de analist n model ca un tip de entitate. n
astfel de cazuri, se folosete un simbol special: dreptunghi cu romb n interior, n care se
scrie numele entitii (fig. 3.9) [1].















Scopul diagramelor entitate-relaie este de a surprinde cele mai complete sensuri
posibile ale datelor necesare sistemului informaional din organizaie.

Tipuri de relaii
Din cele prezentate mai sus, rezult c ntre entitile descrise, luate dou cte
dou, se pot identifica trei tipuri de relaii (legturi): unu-la-unu, unu-la-multe, multe-la-
multe. n diagrame, descrierea relaiilor se face de-a lungul liniilor care leag cele dou
entiti. Simbolul vrf-de-sgeat este cunoscut ca indicator al cardinalitii (cardinality
indicator). n cele ce urmeaz sunt prezentate exemple de tipuri de relaii [1].

1. Relaia unu-la-unu (1:1)




Figura 3.10. Descrierea relaiei 1:1

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


BIROU MANAGER
este condus de
conduce

STUDENT
Promovare CURS
Data promovrii
Figura 3.9. Redarea unei entiti gerundive (asociative) [1]
67
2. Relaia unu-la-multe (1:M)




Figura 3.11. Descrierea relaiei 1:M

Fiecare VNZARE implic unul sau mai multe ATRICOL(e)_VNDUT(e)
Fiecare ATRICOL_VNDUT face parte din numai o VNZARE

3. Relaia multe-la-multe






Figura 3.12. Descrierea relaiei M:N

Fiecare FURNIZOR livreaz unul sau mai multe PRODUS(e)
Fiecare PRODUS este livrat de unul sau mai muli FURNIZOR(i)

n anumite cazuri, ntre dou entiti pot exista mai multe relaii.
De exemplu, s-ar putea spune c FURNIZOR ofer PRODUS, dar i PRODUS
este cumprat de la FURNIZOR, ceea ce s-ar putea reprezenta ca n fig. 3.13.



4. Relaii opionale i obligatorii
Este posibil ca relaiile dintre entiti s nu fie prezente n toate situaiile. Spre
exemplu n cazul proiectelor la care lucreaz diverse persoane, o persoan poate s
lucreze la un singur proiect sau la cteva, sau la niciunul i, invers, un proiect poate fi
realizat de o persoan, de mai multe sau de nici una. n astfel de situaii, se apeleaz la
urmtoarea form de reprezentare (fig. 3.14).

implic
VNZARE
ARTICOL VNDUT
face parte din
livreaz
FURNIZOR
PRODUS
este livrat de
PRODUS FURNIZOR
ofer
este cumprat de la
Figura 3.13. Descrierea relaiilor multiple ntre dou entiti
68





Cercul suprapus pe latura entitii indic poziia 0 (valoarea minim poate fi i
zero), conferind relaiei caracterul opional.
Un alt aspect se refer la caracterul obligatoriu al relaiilor. S lum exemplul
vnzrilor. n relaia 1:M, dintre VNZARE i ARTICOL_VNDUT. Ar fi total eronat
ca o entitate s existe fr cealalt: nu poate fi o vnzare fr cel puin un articol vndut
i, invers, un articol nu poate fi vndut fr o vnzare. Simbolul folosit pt a marca relaiile
obligatorii este un cerc haurat (Figura 3.15).







5. Relaia unei entiti cu ea nsi
n practic, apar i situaii n care o entitate se afl n relaie cu ea nsi.
Spre exemplul n cadrul entitii ANGAJAT, unii dintre ei sunt coordonatori ai
activitii celorlali, situaii situaii care pot fi reprezentate printr-o diagram de forma
celei din fig.3.16.








Reprezentarea anterioar se citete astfel:
Un angajat poate fi coordonatorul unuia sau mai multor angajai
Oricare angajat ntotdeauna raporteaz altui angajat


PERSOANA PROIECT
este realizat de
lucreaz la
Figura 3.14. Exemplu de relaie opional
VNZARE ARTICOL
VNDUT
Figura 3.15. Exemplu de relaie obligatorie

coordonator al
ANGAJAT
raporteaz la
Figura 3.16. Redarea relaiei unei entiti cu ea nsi
69
6. Relaii alternative (sau/sau)
Uneori se ivesc situaii cnd relaiile posibile se redau alternativ: fie o variant este
de urmat, fie cealalt. De exemplu, o marf destinat vnzrii 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 legtur cu cele dou surse posibile,
PRODUCIA_ALTORA i PRODUCIA_PROPRIE, printr-un punct comun, aa cum
este prezentat n figura 3.17.












Citirea diagramei este:
O marf se poate asocia sau cu un productor din afar, sau cu producia unitii
Un productor din afar poate livra mai multe mrfuri
O linie proprie de producie poate livra mai multe mrfuri.

Dei diagramele entitate-relaie sunt bine cunoscute i utilizate n domeniul bazelor
de date, ele constituie unul din conceptele eseniale ale analizei i proiectrii structurate.
Scopul acestor diagrame este de a evidenia entitile de date (obiectele despre care
se solicit pstrarea datelor) i relaiile ce exist ntre ele.
De remarcat diferena dintre diagrama fluxului de date i diagrama entitate-relaie.
n timp ce diagrama fluxurilor de date indic att procesele de prelucrare, ct i entitile
de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER trateaz
doar entitile 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 entitii s fie redat printr-un substantiv
MARFA
PRODUCIA
PROPRIE
PRODUCIA
ALTORA
Figura 3.17. Exemplu de diagram pentru relaiile alternative
70
ct mai sugestiv (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE,
NCASRI). Dup ce se identific entitile se continu cu mperecherea lor, fiecare cu
fiecare, pentru a descrie relaiile dintre ele. Pentru aplicaia Decontri se obine astfel
diagrama din figura 3.18

Figura 3.18. DER pentru aplicaia Decontri [1]


Aplicaie practic
Folosind modelul entitate - relaie s se reprezinte diagrama E/R de ansamblu
pentru un sistem informatic simplificat al unei firme care desfoar activitate de comer
fiind avute n vedere subsistemele:
- aprovizionare (evidena furnizorilor);
- desfacere (situaia vnzrilor);
- urmrirea stocurilor.














FURNIZORI Oferte

PRODUSE
m n
Cod furnizor Cod produs
Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaiei de tip m-n Oferte
71












































PRODUSE Vnzri

CLIENTI
m n
Cod produs
Cod client
Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaiei de tip m-n Vnzri
Desfacere

PRODUSE

STOCURI
Intrri
Ieiri
1 n
1
n
Aprovizionare
Cod produs
Cod Produs+Depozit+Pre
Fig. 3.21. Subsistemul Urmrirea stocurilor.
Reprezentarea relaiilor de tip 1-n Intrri, Ieiri, pentru actualizarea stocurilor
PRODUSE
Cod produs
Denumire produs Descriere produs
Fig. 3.22. Reprezentarea entitii PRODUSE
Oferte
Cod produs
Unitate de msur Pre unitar produs
Fig. 3.23. Reprezentarea relaiei Oferte
Cod furnizor
72


















Teste rezolvate

1. Studiul sistemului existent const n:
a) studiul activitilor de baz desfurate de sistem;
b) identificarea metodelor si mijloacelor tehnice;
c) definirea caracteristicilor generale ale sistemului;
d) definirea direciilor de perfecionare ale actualului sistem;
e) studiul sistemului de conducere.
Rspuns: a, b, c, e

2. Activitatea de determinare a cerinelor sistemului se concretizeaz n diferite forme ale
informaiilor colectate, cum sunt:
a) copii ale interviurilor;
b) realizarea programului;
c) implementarea sistemului;
d) interpretri ale rspunsurilor la chestionare.
Rspuns: a, d

3. Definirea caracteristicilor generale ale sistemului economic implic:
a) cunoaterea profilului, obiectivelor agentului economic;
b) cunoaterea locului n sfera serviciilor i sfera produciei;

FURNIZORI
Cod furnizor
Denumire furnizor Adresa furnizor
Fig. 3.23. Reprezentarea entitii FURNIZORI
Localitate Strad Numr
Oferta
73
c) cunoaterea relaiilor de cooperare cu ali ageni economici;
d) cunoaterea specificului activitii de baz ( producie, servicii).
Rspuns: a, b, c, d
4. Studiul sistemului de conducere se refer la identificarea:
a) caracteristicilor rezultate din statutul de funcionare a societii, tipuri de decizii,
modul de luare a deciziilor;
b) principalilor algoritmi, reguli de calcul i de control;
c) mijloacelor tehnice existente n dotarea unitii economice;
d) modului de organizare a produciei.
Rspuns: a

5. Metodele tradiionale de determinare a cerinelor sistemelor sunt:
a) interviul;
b) prototipizarea;
c) Joint Application Design (JAD);
d) chestionarul.
Rspuns: a, d

6. Paii prototipizrii sunt:
a) Identificarea cerinelor principale ale sistemului;
b) Realizarea prototipului iniial;
c) Proces iterativ de adaptare a sistemului la cerinele utilizatorului;
d) Folosirea sistemului aprobat de utilizatori.
Rspuns: a, b, c, d

7. Scopul diagramelor de date DFD este de a scoate n relief, ntr-o manier ct mai
sugestiv, urmtoarele aspecte:
a) sursa datelor de prelucrare;
b) macheta datelor de prelucrare;
c) destinaia datelor prelucrate;
d) legtura existent ntre prelucrri i activitatea de stocare a datelor.
Rspuns: a, c, d

8. Identificai afirmaia fals:
a) Diagrama de context scoate n eviden aria de ntindere a sistemului analizat;
74
b) Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie,
reliefeaz funciile de prelucrare a datelor executate de ctre sistemul
informaional curent;
c) Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor i cerinele funcionale ale noului sistem;
d) Diagrama fluxului de date prezint modelarea conceptual a datelor.
Rspuns: d

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

10. Cte entiti externe conine diagrama de context pentru aplicaia Decontri:

a) patru entiti; b) cinci entiti; c) nici o entitate.
Rspuns: b

11 Raportul detaliat al cerinelor sistemului conine urmtoarele elemente:
a) refacerea analizelor pentru ntregul sistem;
b) descrierea i prezentarea unui exemplar al tuturor intrrilor n sistem, inclusiv
numele fiecrei intrri, sursa, cine l completeaz, ce date va conine i cum vor
fi culese datele;
75
c) o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte,
documente).
Rspuns: b, c

12. Principalele elemente ale documentaiei elaborate pentru modelarea logicii proceselor
sunt:
a) reprezentarea n engleza structurat;
b) reprezentarea logicii proceselor prin tabele de decizie;
c) reprezentarea prin diagrame entitate-relaie;
d) reprezentarea logicii proceselor prin arbori de decizie;
e) tabelul sau diagrama strilor de tranziie.
Rspuns: a, b, d, e

13. Cea mai cunoscut form utilizat pentru modelarea conceptual a datelor este:
a) diagrama entitate-relaie (DER);
b) diagrama fluxului de date (DFD);
c) diagrama strilor de tranziie.
Rspuns: a
14. n DER pentru fiecare entitate reprezentat se apeleaz la simbolul:
a) cerc;
b) sgeat;
c) romb;
d) dreptunghi.
Rspuns: d
15. Nu sunt tipuri de relaii:
a) relaia unu-la-unu; b) relaia unu-la-multe;
c) relaia absolut; d) relaia unei entiti cu ea nsi.
Rspuns: c
16. Care din afirmaiile urmtoare sunt adevrate:
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) Entitile sunt obiecte sau evenimente (fenomene sau procese economice, n
cazul nostru).
c) Un atribut este o proprietate sau o caracteristic a unei entiti care prezint
interes pentru organizaie.
Rspuns: a, b, c


76
ntrebri

1. Enumerai metode moderne de analiz i determinarea cerinelor sistemului.
2. Descriei tipurile de legturi care pot exista ntre dou mulimi de entiti.
3. Definii cheia unei relaii.
77
Capitolul 4
Proiectarea logic a sistemelor informatice

Dac n primele etape, au fost identificate i structurate cerinele sistemului, n faza
de proiectare logic se efectueaz deplasarea ateniei de la prezentarea a ceea ce exist i
ce se intenioneaz la descrierea a ceea ce va nsemna noul sistem i cum va funciona.
Prezentarea noului sistem const n prezentarea tuturor intrrilor sistemului, a ieirilor,
precum i a interfeelor i dialogurilor.

4.1. Proiectarea formularelor/formatelor i a rapoartelor
n cadrul etapei de analiz a sistemului informatic, intrrile i ieirile au fost
identificate i prezentate, exprimnd cerinele informaionale la nivelul fiecrui subsistem/
aplicaie informatic. n acel moment nu s-au prezentat toate detaliile privind
formularele/formatele, rapoartele i procesul de modelare a datelor, insistndu-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 regsi 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
conine unele date predefinite, crora 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
informaia.
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.



78
4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor)
Obiectivul prezentrii detaliate a ieirilor este i acela de a determina formatul i
coninutul tuturor rapoartelor imprimate i ale documentelor i ecranelor furnizate de
sistem.
Proiectarea ieirilor se va face astfel nct s serveasc pentru [2]:
- transmiterea rezultatelor prelucrrii pe calculator utilizatorului, ntr-o form pe
care acesta s o neleag i n care s-i regseasc cerinele sale;
- transmiterea proiectului situaiilor finale programatorului, fr ambiguiti,
pentru a-i permite acestuia trecerea la ntocmirea programelor necesare editrii
sau vizualizrii.
n proiectarea ieirilor, analistul trebuie s elaboreze un model demonstrativ al
raportului sau ecranului i s ntrebe utilizatorul dac informaiile din raport i formatul
acestuia sunt accesibile. Dac ieirile nu corespund cerinelor utilizatorului, analistul
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 situaiei de ieire,
cuprinznd:
- antet;
- titlu;
- date de identificare;
- cap de tabel;
- date elementare ce se imprima rnd de rnd;
- totalurile.
- detalii i indicaii tehnice de realizare care se refer la:
- volumul datelor de ieire;
- frecven;
- numr de copii i destinaia fiecreia;
- grad de precizie al calculelor;
- condiii speciale de editare;
79
- criterii de control, validare i interpretare a datelor de ieire.
Specificaiile de ieire vor cuprinde, pentru utilizator, macheta situaiei iar pentru
programator macheta situaiei i o serie de indicaii tehnice de realizare.
Pe baza specificaiilor de ieire se trece la proiectarea fizic prin care se alege
suportul informaiilor de ieire, se realizeaz definitivarea formei i formatului de editare
a situaiilor (aezarea n pagina / ecran, spaierea ntre coloane i rnduri, etc.) i se
definitiveaz procedurile de utilizare i interpretare a ieirilor.
Alegerea tipului de suport fizic de ieire (imprimanta, display, disc fix, floppy disc,
banda magnetic etc.) se face n funcie de: timpul de rspuns solicitat, amplasarea
utilizatorului fa de calculator, hard-ul i soft-ul existent, costul suportului, msura n
care rspunde necesitailor de redare a coninutului informaional al situaiei finale.
Cnd se pregtesc ieirile, este bine s se ia n calcul ce se urmrete prin ele, astfel
nct apelarea la categoriile de date de mai sus s se efectueze n cunotin de cauz.
n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s
inem seama de o serie de considerente practice cum ar fi [2]:
- Respectarea unor cerine ale factorilor de decizie privind macheta situaiei
finale;
- Restricii tehnice;
- Elemente de eficien;
- Lizibilitate spaiere;
- Utilizarea formularelor pretiprite;
- Utilizarea monitoarelor sau terminalelor video;
- Utilizarea generatoarelor de rapoarte.
Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale
O serie de cerine ale conducerii privind macheta situaiei finale oblig proiectantul
la o anumit structurare i machetare a situaiilor finale. Informaiile se pot mprii n
dou grupe prin prisma sistemelor informatice interne i externe. Informaiile interne
reprezint acele informaii culese, generate sau folosite n interiorul organizaiei.
80
Informaiile externe se refer la cele colectate sau create de la sau pentru parteneri strini
(facturi, rapoarte anuale, etc).
n funcie de informaiile care pot fi vzute din punct de vedere al echipei
manageriale distingem: informaii curente, de atenionare, indicatori de baz, etc.
Restricii tehnice
n proiectarea situaiilor finale intervin o serie de restricii datorate caracteristicilor
i performanelor tehnice ale echipamentelor periferice i anume: numrul maxim de
caractere pe linie; numrul maxim de linii pe pagina / ecran; facilitile 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 obinerii diverselor tipuri de situaii finale.
Elemente de eficien
n proiectarea situaiilor finale nu trebuie sa scape ateniei i aspectele de eficient
economic privind: reducerea timpului calculator consumat cu editarea propriu-zisa a
situaiilor; economie de hrtie de imprimant. Abilitatea i experiena proprie a
programatorilor joac n acest sens un rol important.
n vederea optimizrii obinerii situaiilor finale pe imprimant se pot folosi de la
caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeai pagin de
imprimant; editarea unei situaii imprimnd fa/verso pe aceeai coal;
Pentru a nu irosi timp cu editarea unor situaii finale voluminoase se recomand
mai nti 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 situaiilor finale. Programele care editeaz situaii finale voluminoase trebuie
prevzute cu posibilitatea de ntrerupere (respectiv de reluare a editrii n cazul unor
incidente ivite n timpul rulrii) sau editarea lor sub forma unui fiier ASCII sau text pe
hard disc sau floppy disc, urmnd imprimarea ulterioara a acestui fiier, total sau parial.
Lizibilitate spaiere
Parcurgerea unei situaii finale trebuie s fie ct mai uoara, citirea unei situaii
nu trebuie s dea natere la ambiguiti. Este necesar ca situaia sa fie autoexplicativ.
81
Pentru aceasta, antetul va conine informaii i coduri ce vor indica sursa de emitere a
raportului, exprimnd clar, sintetic, coninutul raportului i perioada la care se refer.
Capul de tabel, mpreuna cu titlul i antetul, se afieaz pe urmtoarele pagini
numai dac au intervenit schimbri n cadrul caracteristicilor de grupare fa de prima
pagin, altfel se imprim doar numerotarea coloanelor de tabel.
Informaiile importante pot fi subliniate. Totalurile se separ de informaiile
analitice. Informaiile care se repet pe linii succesive se imprim o singur dat.
Utilizarea formularelor pretiprite
Aceasta implica utilizarea unei hrtii de imprimanta ce cuprinde elemente fixe ale
situaiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
conduce la o cretere a vitezei de editare i o diminuare a uzurii imprimantelor, riboanelor
etc. Totodat situaiile obinute sunt mai estetice i sunt uor de parcurs de utilizatori.
Utilizarea monitoarelor sau terminalelor video
Prin intermediul unui soft adecvat, monitoarele sau terminalele video ofer
posibilitatea afirii situaiilor finale, att n regim alfanumeric, ct i n regim grafic,
alegerea modului de lucru fcndu-se prin intermediul unor comenzi sau comutatori.
Ecranul unui terminal video n regim alfanumeric este alctuit din linii i coloane
iar n regim grafic ecranul este privit ca o matrice de puncte denumite pixeli.
Reprezentarea informaiilor de ieire sub forma grafic reprezint un pas nainte
fa de editarea sub forma de text a rapoartelor. Aceast form de afiare se recomand
factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare
a informaiilor de ieire i volumul redus al rapoartelor.
Pe lng problemele legate de aezarea informaiilor pe ecran, la proiectarea
ecranelor de ieire se iau n considerare i facilitile oferite de monitoare sau terminalele
video i anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afiare
(normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonor
(normal, semnal sonor dup afiarea unui cmp etc.).


82
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, coninutul unui rnd de date (de detaliu),
gradele de total i maniera lor de afiare, la nceputul sau la sfritul grupului de date, al
paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane,
pagini, spaierea dintre linii, coloane, afiarea datelor privind momentul listrii, statistici
etc. Astfel de module specializate exist n pachete de programe pentru gestionarea
bazelor de date cum ar fi: ACCESS, dBASE, ORACLE, FOXPRO, PARADOX, etc.

4.1.2. Proiectarea codurilor
n proiectarea sistemului de coduri trebuie s avem n vedere dou aspecte
importante i anume [2]:
- influena tipului i structurii codului asupra performanelor sistemului
informatic;
- implicaiile utilizrii codurilor n operaiile de culegere a datelor i interpretarea
rezultatelor finale de ctre utilizatorii neinformaticieni.
Primul aspect ridic probleme de ordin tehnic n realizarea nomenclatorului de
coduri i are n vedere facilitarea operaiilor de prelucrare, ocuparea unui spaiu de
memorie intern i extern ct mai mic etc.
Celui de-al doilea aspect trebuie s i se acorde o atenie mai mare n vederea
uurrii activitilor de culegere, verificare a datelor i interpretarea rezultatelor din
situaiile finale. Avnd n vedere aceste considerente, se impune ca la proiectarea unui
sistem de coduri s se respecte o serie de cerine.
Activitile parcurse n realizarea unui sistem de coduri sunt:
- analiza elementelor ce urmeaz a fi codificate;
- precizarea i uniformizarea tehnologiei, a denumirilor;
- stabilirea caracteristicilor i a relaiilor dintre elementele de codificat;
83
- alegerea tipurilor de coduri; estimarea capacitii, lungimii i formatului
codurilor;
- atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de
coduri);
- ntreinerea nomenclatoarelor de coduri.
Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la
nivelul economiei naionale (CAEN, SIRUES, SIRUTA, CNP, etc).

4.1.3. Proiectarea intrrilor n sistemul informatic
Datele de intrare parcurg o succesiune de etape pn 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;
corecia datelor eronate etc.
La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele
activiti:
- alegerea suportului tehnic pentru culegerea datelor;
- proiectarea machetelor documentelor de intrare, stabilirea instruciunilor 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 funcie de cerinele
aplicaiei 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 prelucrrii ulterioare.
La proiectarea machetei documentelor de intrare (indiferent de metodele de
prelucrare a datelor folosite ulterior) sunt respectate cteva reguli care s nlesneasc
completarea i apoi utilizarea documentului att pentru prelucrarea automat a datelor ct
84
mai ales pentru necesitile curente ale salariailor societii economice. Nu este
recomandabil s dublm documentele primare, prin proiectarea unor documente destinate
exclusiv prelurii datelor pentru necesitile prelucrrii automate.
Macheta documentului primar trebuie s conin:
- antetulce reprezint denumirea unitii i/sau a serviciului care-l emite;
- denumirea documentului;
- coduri de identificare,
- data documentului;
- rubrici /casete/ rnduri pentru denumirea informaiilor cantitativ-valorice i
coduri;
- rubrici /casete /spaii pentru semnturi i tampile;
- text explicativ, eventual indicaii de completare i verificare.
n ordonarea informaiilor pe document, deci n rubricarea documentului se va ine
seama de cteva reguli: antetul se plaseaz n stnga sus; codurile i alte informaii de
identificare se plaseaz n dreapta sus; sensul natural de parcurgere este de sus n jos i de
la stnga la dreapta; zonele de document ce se completeaz de compartimente/ persoane
diferite se marcheaz / grupeaz distinct; mrimea i spaierea documentului, distana
dintre rnduri, dimensiunea rubricilor, depind de locul i modalitatea de completare
(manual, dactilo, automat) precum i de nivelul de calificare a personalului ce
completeaz documentul.
Aezarea 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 ngroate n denumirea rubricilor implicate n dialogul
operator-calculator.
Atunci cnd documentul exist ntr-o form pe hrtie, n varianta pe calculator se
va urmri pstrarea n mare msur a structurii existente, dar cu adaptri specifice noului
mediu.
85
Regulile de control i procedurile de validare a datelor de intrare trebuie s
cuprind [2]:
- reguli de verificare a volumului, secvenei 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), corelaii logice (ntre indicatorii nscrii n acelai document, sau
cu ali indicatori din baza de date), prezena unor informaii obligatorii
(apartenena codurilor la nomenclatoarele de coduri specifice aplicaiei
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 funcie de modul concret de desfurare a dialogului operator-
calculator. Acest dialog se poate desfura sub urmtoarele forme:
- ntrebare-rspuns cu defilarea liniilor ecranului;
- afiare pe ecran a machetei de introducere a datelor de intrare.
n prima variant, mai uor de realizat practic, operatorul introduce succesiv, ca
rspuns la ntrebrile afiate 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:
- afiarea la un moment dat a unui volum redus de informaii;
- afiarea la un moment dat a unei cereri de rspuns ce se refer la o singur
informaie;
- scurtarea rspunsului operatorului prin folosirea mnemonicelor i codificrilor;
- utilizarea unor formate clare i precise pentru afiare;
- evitarea cuvintelor i caracterelor dificil de citit sau neles;
- existenta unor rutine speciale de tipul HELP;
- preluarea asistat a unor coduri (ex. utilizare tehnici de tip Lookup wizard n
ACCESS)
86
n varianta a doua cursorul marcheaz de fiecare dat cmpul curent care se
introduce. Ecranul display-ului trebuie s reproduc integral sau simplificat macheta
documentului, respectnd aceeai ordine a rubricilor. Mesajele de eroare se pot afia ntr-
o zona prestabilita a ecranului, nsoit de avertizare sonora sau luminoasa.
Dac este cazul, pentru unele cmpuri (rubrici) de date se pot prelua valori
implicite, atunci cnd nu sunt completate. Aceste valori se preiau din nomenclatorul de
coduri, fiierele bazei de date sau tabele special memorate pentru valorile asumate prin
lipsa sau prin aplicarea unui algoritm. Pentru o mai uoar operare este necesar s folosim
toate facilitile de afiare 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 interfeelor i a dialogurilor
Interfaa cu utilizatorul reprezint o parte a aplicaiei software care permite
utilizatorilor s-si exprime inteniile de operare asupra calculatorului i s interpreteze
Figura 4.1. Formularul(macheta) de intrare pentru facturi
87
rezultatele aciunilor efectuate de main. Prin proiectarea dialogurilor i a interfeelor se
definesc modalitile prin care oamenii i calculatoarele schimb informaii [1].

Metode i echipamente folosite n dialogul om-main
Interfaa om main definete modalitatea prin care utilizatorul interacioneaz
cu un sistem informatic. Interfeele 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 msur s faciliteze o astfel de interaciune.

Metode de interaciune
Metodele cele mai utilizate sunt:
- interaciunea prin limbaj-comand (n acest tip de interaciune utilizatorul
transmite calculatorului comenzile sub forma unui ir de caractere);
- interaciunea prin meniuri(utilizatorul transmite comenzile sale calculatorului
prin intermediul unui sistem de meniuri i opiuni de meniu sau folosind
scurtturi sub form de combinaii de taste);
- interaciunea bazat pe obiecte icons(comunicarea se face prin intermediul
desenelor. Imaginile folosite funcioneaz ca butoanele, la apsarea lor se
activeaz o anumit funcie sau comand);
- interaciunea prin limbaj natural(comenzile se transmit folosind vocea i
sintetizatoarele de voce pentru redarea rezultatelor).

Echipamentelor necesare interaciunii cu sistemul
Cele 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
selecia;
88
- light pen stiloul optic, efectueaz selecia prin apsarea pe ecran;
- voice vocea constituie modalitatea de transmitere a textelor i comenzilor
ctre calculator.

Proiectarea dialogurilor
Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenele
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 condiiile
n care se pot afia informaiile sau se pot obine de la utilizator.
Pentru a obine rezultate bune trebuie s se in seama de regulile de baz la
conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uurina n lucru,
controlul, operaiunea invers (refacerea unui element ters), rezolvarea erorilor, etc.
O modalitate de prezentare a secvenei dialogurilor este cea care apeleaz la
tehnica diagramelor prin care se reprezint meniurile componente ale aplicaiei.






















Pentru proiectarea interfeelor 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 condiii optime mediile GUI (Graphical User Interface) trebuie s se
PO1
ADUGARE
PO2
MODIFICA
MENIU_PRINCIPAL
MO1
MENIU
INTEROGARE
MO2
PO4
I_DUP_AN
PO5
I DUP NUME
PROCES
MENIU
PO3
TERGERE
Figura 4.2. Exemplu de diagram de apelare a meniurilor
89
cunoasc aceste medii. n mediile grafice informaiile se plaseaz n ferestre. Acestea au
trsturi specifice ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu
sistem, etc.

4.3. Proiectarea logic a bazelor de date
Proiectarea logic a bazelor de date este n strns legtur cu modelarea
conceptual a datelor, aceasta nsemnnd 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 activiti ale proiectrii
logice: proiectarea formularelor i a rapoartelor i proiectarea dialogurilor i interfeelor.
Modelarea logic a datelor se realizeaz nu numai pe baza diagramei entitate-relaie, ci i
pe baza machetelor formularelor i a rapoartelor. Se efectueaz analiza datelor elementare
din intrrile i ieirile sistemului pentru a se desprinde legturile dintre ele.
Prin modelarea logic a datelor se urmrete:
- structurarea performant a datelor prin procesul de normalizare;
- obinerea unui model logic al datelor din care s se poat realiza proiectul bazei
de date fizice funcie de tipul de SGBD utilizat: relaional cel mai utilizat n
prezent, reea, ierarhic, sau orientate-obiect;
- realizarea unui model al datelor care s rspund cerinelor actuale de date
regsite n formulare i rapoarte. Modelarea logic este un proces ascendent
(bottom-up, de jos n sus) de obinere a relaiilor din formulare i rapoarte prin
transformarea modelului entitate-relaie ntr-o form relaional.
Modelarea logic a datelor descrie datele cu ajutorul unei notaii speciale, care
corespunde unui mod de organizare a acestora de ctre un sistem de gestiune a bazelor de
date. Procesul de modelare a datelor este complex. n fiecare etap a ciclului de via se
regsete cte o activitate specific datelor dup cum urmeaz [1]:
- Analiza Modelele conceptuale ale datelor, prezentarea DER;
- Proiectarea logic Modelul logic al datelor (relaional);
90
- Proiectarea fizic Proiectarea fizic a bazelor de date i a fiierelor
(organizarea fiierelor);
- Implementarea Descrierea fiierelor i a bazelor de date.
Dup cum prezint profesorul Oprea D. n Analiza i proiectarea sistemelor
informaionale economice n procesul de modelare logic exist patru pai eseniali:
1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare i
rapoarte) privind aplicaia, folosindu-se principiile normalizrii;
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-relaie), realizat fr s se in
cont de perspectiva utilizatorului, ntr-un set de relaii normalizate;
4. Compararea modelului logic consolidat al datelor cu modelul transformat al entitii-
relaie i realizarea, prin integrarea perspectivelor, a unui model logic final al datelor
aplicaiei.
Rezultatele obinute prin parcurgerea celor patru pai pot fi ilustrate prin
intermediul unor exemple oferite n literatura de specialitate de McFadden i Hoffer.
Primul pas al modelrii logice se poate explica prin dou rapoarte solicitate de
utilizatori, reprezentnd perspectiva utilitii sistemului din punctul lor de vedere:
- cel mai bun client al produsului X(ecran);
- situaia comenzilor n curs.
Ecranul Cel mai bun client al produsului X, prin percepia utilizatorului, are
urmtorul format:












Cel mai bun client al produsului
Introducei codul produsului: P1122
Data de nceput: 10/10/99
Data de sfrit: 31/12/99
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
COD CLIENT: 1111
NUME CLIENT: S.C. ALPHA S.R.L.
VOLUM: 1000
Figura 4.3 Model de ecran solicitat de utilizatori [1]
91

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

Raportul Situaia comenzilor n curs are urmtorul format:















Realizarea raportului este posibil prin folosirea urmtoarelor entiti:

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 relaiilor, rezultnd urmtoarele relaii:

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-relaie) din aplicaie fr s se in cont de punctul de vedere al utilizatorului, ntr-
Pagina 1
Situaia comenzilor n curs
31/03/1998

COD PRODUS
CANTITI_DE_LIVRAT
A1111 0
A2222 0
B1111 150
Y9999 100
Figura 4.4. Model de raport solicitat de utilizatori [1]
92
un set de relaii normalizate. Din analiza diagramei din figura 4.5 se desprind urmtoarele
relaii:
CLIENT(COD_CLIENT, NUME, ADRESA)
PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA)
COMANDA(NR_COMANDA, COD_CLIENT)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)

Pasul al patrulea compar modelul obinut din pasul doi cu cel din pasul trei i
integreaz perspectivele utilizatorilor n vederea obinerii 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 modelrii logice a datelor l constituie relaiile normalizate rezultate din
cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza n
actualizarea depozitului (repository) sau a dicionarului proiectului. Diferena major ntre
modelarea conceptual i cea logic este c dup modelarea logic a datelor cerinele
structurate de date se concretizeaz n relaii, i nu n entiti. Din cauza normalizrii nu
este necesar o coresponden unu-la-unu ntre entiti i relaii [1].











93












































NUME_CLIENT
COD_CLIENT
ADRESA
NR_FACTURA
CLIENT FACTURA
Facturare Lanseaz
COMANDA
Linie_comand
PRODUS
CANTITATE_
COMANDATA
COD_PRODUS DENUMIRE
NR_COMANDA
CANTITATE_LIV
Livrare
Figura 4.5. Diagrama entitate-relaie pentru gestiunea clienilor [1]
94
4.3.1. Normalizarea relaiilor - Forme normale
ntre atributele unei relaii sau ntre atribute din relaii diferite pot exista anumite
legturi logice (dependene), care influeneaz proprietile schemelor de relaie n raport
cu operaiile curente care intervin n timpul exploatrii bazei de date: adugare, tergere,
actualizare. Aceste legturi logice, cunoscute n literatura de specialitate sub denumirile
de dependenele funcionale, dependenele multivalorice i dependene de cuplare, au
implicaii majore asupra criteriilor de proiectare a schemelor relaionale. Alegerea unui
model conceptual convenabil pentru o baz de date relaional poate necesita realizarea
unor descompuneri pentru anumite scheme de relaie date, descompuneri care s izoleze
dependenele existente i prin aceasta s elimine anomaliile care se datoreaz acestor
dependene.
Dependene funcionale
Penru definirea acestui tip de dependene se consider schema de relaie
Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)
definit pentru urmrirea serviciilor prestate de o firm pentru diveri clieni.
Atributul Adresa este dependent de atributul Nume_client (presupunnd c fiecare
client are o singur adres, rezult c fiecare valoare a atributului Nume_client determin
n mod unic valoarea corespunztoare a atributului Adresa). Analiznd schema de relaie de
mai sus, se constat o redundan relativ la atributul Adresa a crei valoare este repetat
pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la
apariia urmtoarelor anomalii:
- Anomalia la adugare:
adresa unui client poate fi preluat numai dup ce pentru acesta se presteaz cel puin un
serviciu.
- Anomalia la tergere:
dac se terg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.
- Anomalia la actualizare:
datorit redundanei relativ la atributul Adresa, dac se schimb adresa unui client este
necesar parcurgerea ntregii relaii pentru a identifica i actualiza toate apariiile acestui
95
client, n caz contrar baza de date devine inconsistent (acelai client poate apare la adrese
diferite).
Aceste anomalii pot fi eliminate, dac schema de relaie Prestari_Servicii se
nlocuiete prin urmtoarele dou scheme de relaie:
Clienti(Cod, Nume_client, Adresa)
Servicii(Cod, Serviciu_prestat, Valoare).
Relaia Clienti conine codul, numele i adresa fiecrui client, fr nici un fel de
redundan, iar relaia Servicii conine serviciile prestate pentru fiecare client i valorile
acestor servicii. Un dezavantaj al descompunerii relaiei iniiale n cele dou relaii este
acela c pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu
este necesar efectuarea unei operaii de cuplare a relaiilor Clienti i Servicii.
Se consider o schem de relaie R i A,B dou atribute simple sau compuse ale
schemei de relaie R. Atributul A determin funcional atributul B sau B depinde funcional
de A, dac i numai dac oricrei valori a atributului A i corespunde o singur valoare a
atributului B (se noteaz A->B).
Dependena funcional A->B este total dac nu exist nici un subset C al atributului
A (CcA) astfel nct C->B i este parial n caz contrar.
n relaia Prestari_Servicii, una din dependenele funcionale care poate fi pus n
eviden este Nume_client->Adresa.
Deoarece ntr-o relaie orice cheie identific n mod unic fiecare tupl a relaiei,
deci determin n mod univoc valorile atributelor tuplei, rezult c n orice relaie
atributele sunt dependente funcional fa de cheile acesteia.
Se pot face, pn n acest moment, urmtoarele precizri:
Eliminarea dependenelor funcionale din schemele de relaie i a consecinelor
negative (redundana datelor; anomaliile de adugare, tergere, actualizare) se realizeaz
prin descompunerea schemei date ntr-o colecie de scheme mai simple n care sunt evitate
neajunsurile mai sus menionate. Reconstituirea relaiei iniiale se poate face prin operaia
de cuplare (uniune). Pentru ca descompunerea schemei de relaie s fie echivalent cu
relaia iniial, trebuie s fie ndeplinite condiiile:
96
- cuplare fr pierdere de informaie;
- conservarea dependenelor (dependenele funcionale din relaia iniial trebuie
s se regseasc n relaiile rezultate prin descompunere).
Formele normale sunt scheme de relaie echivalente obinute prin descompunerea
unor scheme de relaie n vederea eliminrii redundanei datelor i anomaliilor la
adugare, actualizare, tergere nregistrri n baza de date. Descompunerile schemelor de
relaii n scheme de relaii echivalente avnd n vedere dependenele funcionale 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 avnd n vedere dependenele
multivalorice, iar a cincea form normal (FN5) este definit avnd n vedere
dependenele de cuplare. ncepnd de la prima form normal i pn la forma normal FN5
se impun condiii din ce n ce mai restrictive asupra relaiilor. Astfel o relaie aflat pe un
anumit nivel de normalizare (FN5) satisface toate restriciile cerute de nivele inferioare de
normalizare (FN1, FN2, FN3, FNBC, FN4). n cele ce urmeaz sunt date definiiile
formelor normale avnd n vedere dependenele funcionale.
O relaie 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 relaie R este n a doua form normal (FN2) dac este n FN1 i orice atribut
neprim este total dependent fa de orice cheie a relaiei (atributele prime sunt atribute care
fac parte dintr-o cheie a relaiei i cele neprime sunt atributele care nu aparin nici unei chei
a relaiei).
O relaie R este n a treia form normal (FN3) dac este n FN2 i nici un atribut
neprim nu este funcional dependent fa de un alt atribut neprim al relaiei.
O relaie R se afl n forma normal Boyce-Codd (FNBC) dac singurele
dependene funcionale admise sunt cele n care o cheie determin un alt atribut (nici un
97
atribut prim sau neprim nu poate fi dependent funcional fa de un alt atribut dac acesta
nu este sau nu conine o cheie).
Dependene multivalorice
Pentru ilustrarea acestui tip de dependene se ia n considerare urmtoarea schem
de relaie:
Clase(Clasa, Discipline, Elevi)
ce conine clasele dintr-o instituie de nvmnt, iar pentru fiecare clas sunt nregistrate
disciplinele ce se predau i elevii nmatriculai n clasa respectiv. Se poate constata c
relaia Clase poate rezulta prin operaia de cuplare dup atributul Clasa a urmtoarelor
dou relaii:
CD(Clasa, Discipline)
CE(Clasa, Elevi)
n relaia Clase, presupunnd c pentru o clas dat, fiecare elev frecventeaz toate
disciplinele nregistrate pentru acea clas, exist dependenele multivalorice:
Clasa ->> Discipline
Clasa ->> Elevi.
Ca i n cazul dependenelor funcionale, existena dependenelor multivalorice
prezint aceleai neajunsuri privind redundana datelor i anomalii la efectuarea operaiilor
de adugare, actualizare i tergere nregistrri n baza de date.
O relaie R este n a patra form normal dac singurele dependene multivalorice
admise sunt cele determinate de un alt atribut care este o cheie sau care conine o cheie a
relaiei.
ntruct orice dependen funcional este un caz particular de dependen
multivaloric, rezult c orice relaie care se afl n forma normal FN4, se afl i n forma
normal FNBC. Transformarea unei relaii ntr-o colecie de relaii care s se afle n FN4
este similar cu trecerea n FNBC, ns trebuie avut n vedere att eliminarea
dependenelor funcionale ct i a dependenelor 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 fcut prin descompunerea unei relaii n altele
98
dou, urmrindu-se eliminarea dependenelor funcionale i multivalorice. O relaie aflat n
forma normal FN4 nu mai poate fi descompus n continuare pe baza acestei metode.
Exist situaii cnd relaii aflate n FN4 conin redundane i prezint anomalii la operaiile
de adugare, tergere i actualizare. Aceste anomalii sunt cauzate de existena
dependenelor de cuplare i pot fi eliminate prin descompunerea relaiei n 3 sau mai multe
relaii a cror cuplare are ca rezultat relaia iniial.
Dependene de cuplare
Se consider schema de relaie:
SDS (Specializari, Discipline, Studenti)
care conine disciplinele care se predau la diverse specializri i studenii care le
frecventeaz, cu precizarea c pot exista discipline opionale care nu sunt frecventate de
toi studenii de la specializarea respectiv. n aceste condiii n cadrul schemei de
relaie SDS nu au loc dependenele multivalorice:
Specializari ->> Discipline
Specializari->> Studenti
ceea ce nseamn c relaia SDS este n FN4. Dei este n FN4, relaia SDS conine mai
multe redundane care pot conduce la anomalii de actualizare. Pe de alt parte, relaia SDS
nu poate fi descompus n dou componente din a cror cuplare s rezulte relaia iniial cu
conservarea informaiei. Se constat ns c relaia SDS poate fi descompus n
urmtoarele 3 relaii:
SD(Specializari, Discipline)
SS(Specializari, Studenti)
DS(Discipline, Studenti)
i relaia SDS este rezultatul cuplrii relaiilor: SD, SS i DS fr pierdere de informaie.
SDS = SDSSDS.
n acest caz spunem c n relaia SDS exist o dependen de cuplare.
Dependenele multivalorice sunt cazuri particulare de dependene de cuplare.
A cincea form normal este o generalizare a formei normale patru, trecerea unei
relaii n FN5 presupunnd eliminarea dependenelor de cuplare existente n cadrul
99
relaiei, mpreun cu anomaliile pe care acestea le creeaz. n cadrul unei relaii pot exista
dependene de cuplare care nu conduc la redundan n memorarea datelor i nu produc
anomalii la operaiile efectuate asupra nregistrrilor bazei de date (acestea sunt
dependenele de cuplare implicate de o cheie a relaiei).
O relaie este n forma normal cinci (FN5) dac i numai dac toate dependenele
de cuplare existente n relaie sunt implicate de o cheie a acesteia. Relaia SDS se poate
descompune, cu conservarea coninutului de informaie, n cele 3 componente ale sale: SD,
SS i DS care sunt n FN5.
Avnd n vedere similaritatea ce exist ntre definiiile pentru FNBC, FN4 i FN5,
acestea pot fi unificate n urmtoarea definiie [DORO98]:
O relaie R este n FNBC, FN4, FN5 dac i numai dac singurele dependene
funcionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaiei R.
n concluzie, prin procesul de normalizare se realizeaz eliminarea din schemele de
relaie a dependenelor (funcionale, multivalorice i de cuplare) cu scopul de a obine o
schem relaional mai bun din punctul de vedere al redundanei datelor i al anomaliilor
ce pot apare la operaiile de adugare, tergere i actualizare nregistrri n baza de date.
Normalizarea unei scheme de relaie R nseamn nlocuirea acesteia cu o mulime de
proiecii R1,...,Rn astfel nct R s fie echivalent cu uniunea proieciilor R1,...,Rn. Dei
normalizarea este o operaie util n proiectarea bazelor de date, aceasta nu ofer
ntotdeauna reete pentru obinerea 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 obinut. n unele cazuri
normalizarea complet, pn la FN5, s-ar putea s fie dezavantajoas. Avnd n vedere
constatrile de mai sus se poate afirma c dei normalizarea nu reprezint o soluie
general valabil n orice situaie, totui dac pentru proiectarea bazei de date se
aplic corect o metodologie de proiectare descendent, modelul rezultat va fi de la sine
normalizat. Cercetrile n acest domeniu continu, fiind definite i alte forme normale
printre care FN6 pentru baze de date temporale. O baz de date temporal, pe lng datele
curente, conine i date istorice, iar factorul (atributul) timp are un rol esenial (exemple
100
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 operaii de descompunere a schemelor
de relaie i anume:
- descompunerea orizontal pentru separarea datelor curente de datele istorice;
- descompunerea vertical pentru separarea atributelor aceleiai entiti avnd n
vedere valorile lor raportate la atributul temporal.
n proiectarea unei baze de date nu este exclus nici operaia invers normalizrii
numit denormalizare [DATE04], prin care se urmrete nlocuirea unei colecii de
scheme de relaie cu o schem de relaie echivalent n vederea eliminrii necesitii
efecturii unor operaii de cuplare care pot fi costisitoare. Dac n cazul normalizrii
tendina este de a ajunge la nivele ct mai nalte (FN5), pentru denormalizare nu exist
criterii clare putnd fi avute n vedere doar aspecte legate de performanele anumitor
aplicaii.
Un alt principiu care se urmrete n proiectarea unei baze de date este principiul
proiectrii ortogonale conform cruia n cadrul unei baze de date dou scheme de relaie
reale (variabile de relaie de baz) nu trebuie s aib semnificaii suprapuse. n timp ce
prin normalizare se urmrete reducerea redundanei din cadrul unei scheme de relaie,
prin proiectarea ortogonal se urmrete reducerea redundanei dintre schemele de relaie.

4.3.2. Simplificarea structurii datelor prin normalizare
Problema de baz a proiectrii logice a bazelor de date este cum ar trebui
combinate datele elementare pentru a forma relaii(sau tipuri de nregistrri) care s
descrie entitile i relaiile dintre entiti. n limbajul bazelor de date, cuvntul relaie
nseamn un tabel de date, ceea ce duce la concluzia c bazele de date relaionale
(modelul relaional) sunt cldite pe un grup de tabele legate ntre ele [1].
Modelul relaional a fost dezvoltat de ctre Codd. Este un model conceptual de
organizare a datelor, destinat reprezentrii legturilor dintre date. El este bazat pe teoria
matematic a relaiilor i este definit cu o deosebit rigoare matematic [Popescu I.,
1996].
101
n cadrul modelului relaional datele sunt structurate sub forma de relaii (de aici i
denumirea). Cea mai directa i intuitiva modalitate de reprezentare a datelor n cadrul
acestui model este sub forma de tabele. Fiecrei relaii i se poate asocia un tabel care are
attea coloane cte mulimi leag relaia i are attea linii cte tuple conine relaia.
Prezentarea structurii relaionale a datelor impune definirea noiunilor de:
domeniu, relaie, atribut i schem a unei relaii. Conceptele utilizate pentru a descrie
formal, uzual sau fizic elementele de baz ale organizrii datelor sunt prezentate n tabelul
urmtor:
Formal Uzual Fizic
Relaie Tablou Fiier(tabel)
Tuplu Linie nregistrare
Atribut Coloan Cmp
Domeniu Tip de dat Tip de dat

Definirea domeniului
Un domeniu este o mulime de valori caracterizat printr-un nume. Un domeniu se
poate defini explicit prin enumerarea tuturor valorilor aparinnd acestuia sau definind o
proprietate distinctiv a domeniului valorilor, de cele mai multe ori limita superioar i
limita inferioar [6]. De exemplu:
D
1
: {F,M} -definire explicit
D
2
: {x| xN, x [0,100]} -definire implicit
D
3
: {s|s=ir de caractere} -definire implicit
Pentru un ansamblu de domenii D
1
,D
2
,,D
n
produsul cartezian al acestora
reprezint ansamblul tuplurilor (elemente ale unei relaii) <v
1
,v
2
,,v
k
> unde v
i
este un
element care aparine domeniului D
i
. De exemplu, tuplurile <Maria,F,50 >,<
Vasile,M,60> aparin produsului cartezian D
3
xD
1
xD
2
.


102
Definirea relaiei
O relaie R pe mulimile D1,D2,,Dn este o submulime a produsului cartezian
D1xD2xxDn, deci o mulime de tupluri [6].
Considernd c nu se cunosc dect dou persoane, relaia R se definete prin
tuplurile care descriu aceste persoane, i anume:
R: {<Maria,F,50>,<Vasile,M,60>}
O relaie poate fi reprezentat printr-un tabel bidimensional n care fiecare linie
corespunde unui tuplu i fiecare coloan corespunde unui domeniu.
R: D
3
D
1
D
2
Maria F 50
Vasile M 60

Reprezentarea tabelar este preferat adesea altor forme de reprezentare a relaiilor,
deoarece este uor de neles i de utilizat.
n prezentarea conceptului de relaie se poate recurge la analogii cu alte concepte
cum ar fi cel de fiier. Relaia poate avea semnificaia unui fiier, tuplul poate fi
considerat o nregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale
cmpurilor de nregistrare.

Definirea atributului
n timp ce tuplurile dintr-o relaie trebuie s fie unice, un domeniu poate apare de
mai multe ori n produsul cartezian pe baza cruia este definit relaia [Popescu I, 1996].
PERS D
3
D
1
D
2
D
3

Maria F 50 Vasile
Vasile M 60 Maria

Relaia PERS reprezint un subansamblu al produsului cartezian D
3
xD
1
xD
2
xD
3
.
Atributul reprezint coloana unei tabele de date, caracterizat printr-un nume. Numele
103
coloanei (atributului) exprim, de obicei, semnificaia valorilor din cadrul coloanei
respective.
Semnificaia valorilor din cadrul unui tuplu se stabilete n acest caz nu numai pe
baza domeniului de care aparin valorile ci i funcie de poziia ocupat n cadrul tuplului.
Dependena fa de ordinea datelor nseamn o reducere a flexibilitii organizrii datelor.
ntr-o organizare eficient, flexibil, ordinea liniilor i a coloanelor nu trebuie s prezinte
nici o importan. Pentru a diferenia coloanele care conin valori ale aceluiai domeniu, i
a elimina astfel dependena de poziie n cadrul tabelei se introduce tocmai conceptul de
atribut. Fiecare relaie are asociat un nume sau un identificator propriu.
Schema unei relaii este format din ansamblul elementelor definitorii sau din
nivelul relaiei urmat de lista atributelor specifice.
n mulimile matematice nu este permis ca un obiect s apar de mai multe ori. Ct
timp o relaie este o mulime de tupluri, teoretic nici o linie a unei relaii nu poate fi
duplicatul altei linii. Dup cum reiese din prezentrile anterioare, dac o coloan sau o
combinaie 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 entitilor definite se organizeaz ntr-o singur
tabel sau n mai multe i se urmrete descompunerea acestor tabele n altele, fr
pierdere de informaii n scopul eliminrii 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, nlturndu-se treptat o serie de neajunsuri i asigurnd faciliti sporite n
privina ncrcrii, actualizrii i exploatrii bazei de date. O relaie nenormalizat conine
unul sau mai multe grupuri care se repet.
104
Necesitatea normalizrii progresive este dat de faptul c anumite relaii pot genera
o serie de situaii nedorite, aa-numitele anomalii de actualizare, cum sunt: anomalia de
tergere, anomalia de adugare, anomalia de modificare [2].

4.3.3. Transformarea diagramelor entitate-relaie n relaii
Pentru a se putea compara rezultatele obinute n etapa de proiectare logic a
datelor, adic a relaiilor normalizate, cu diagrama entitate-relaie, rezultat al proiectrii
conceptuale, aceasta din urm trebuie s fie convertit n relaii, de asemenea,
normalizate.
ntregul proces se desfoar n patru pai, astfel: [1]
- Reprezentarea entitilor. Fiecare tip de entitate din diagrama entitate-relaie
este reprezentat ca o relaie n modulul relaional al datelor. Identificatorul
tipului de entitate devine cheie primar a relaiei, iar celelalte atribute ale
tipului entitii devin atribute non-cheie ale relaiei.
- Reprezentarea legturilor. Fiecare legtur din diagrama entitate-relaie trebuie
s fie reprezentat n modelul relaional al datelor. Reprezentarea legturii se
efectueaz n funcie de natura ei. De exemplu, uneori se poate constitui o
relaie prin includerea cheii primare a unei relaii ca o cheie strin n alt
relaie. Astfel, se poate crea o relaie separat pentru reprezentarea legturii.
- Normalizarea relaiilor. Relaiile create n paii 1 i 2 pot conine redundane
nedorite i vor constitui surse de nregistrare a anomaliilor n timpul
actualizrii. Normalizarea va conduce la o bun structurare a relaiilor.
- Fuziunea relaiilor. n timpul modelrii logice a datelor s-au creat diferite
relaii, att pe baza normalizrii ascendente a perspectivelor utilizatorilor, ct i
a transformrii uneia sau a mai multor diagrame entitate-relaie n seturi de
relaii. n structura acestor seturi de relaii pot exista unele relaii redundante,
cum ar fi existena a dou sau mai multe relaii care descriu acelai tip de
entitate, ce ar trebui s fuzioneze i s se renormalizeze pentru extragerea
eventualelor redundane.
105
Teste rezolvate

1. Afirmaiile urmtoare 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 regsi ntr-un flux al datelor generate de un proces al DFD.
Rspuns: b
2. Prezentarea informaiile 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.
Rspuns: a, c, d
3. Macheta imprimantei cuprinde:
a) antet;
b) titlu;
c) date elementare ce se imprima rnd de rnd;
d) totalurile.
Rspuns: a, b, c, d
4. Detaliile i indicaiile tehnice de realizare a machetei imprimantei se refer la:
a) volumul datelor de ieire;
b) intensitatea datelor;
c) contrast.
Rspuns: a
5. Alegerea tipului de suport fizic de ieire (imprimanta, display, etc.) se face n funcie
de:
a) sursa de energie; b) calitatea datelor; c) costul suportului.
Rspuns: c
6. n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s inem
seama de o serie de considerente practice cum ar fi:
a) Respectarea unor cerine ale factorilor de decizie privind macheta situaiei
finale;
b) Restricii tehnice;
c) Utilizarea formularelor pretiprite;
d) Utilizarea generatoarelor de rapoarte.
106
Rspuns: a, b, c, d
7. Activitile 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.
Rspuns: a, d
8. La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele activiti:
a) alegerea coleciilor de date;
b) proiectarea machetelor documentelor de intrare;
c) alegerea regulilor de control i validare a datelor;
d) proiectarea formularelor (videoformatului) de intrare.
Rspuns: b, c, d
9. Macheta documentului de intrare conine:
a) antetul documentului;
b) diagrama fluxului de date;
c) denumirea documentului.
Rspuns: a, c
10. Nu sunt metode de interaciune om main:
a) interaciunea permanent,
b) interaciunea prin meniuri,
c) interaciunea bazat pe obiecte icons,
d) interaciunea prin limbaj natural.
Rspuns: a
11. Echipamentele necesare interaciunii cu sistemul sunt:
a) eyescreen; b) keyboard; c) mouse.
Rspuns: b, c
12. Construirea prototipului secvenei de derulare a dialogurilor se poate face cu ajutorul:
a) instruciunilor repetitive; b) produselor CASE; c) mediile de dezvoltare grafic.
Rspuns: b, c


13. n procesul de modelare logic a datelor sunt pai eseniali:
107
a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare i
rapoarte) privind aplicaia, folosindu-se principiile normalizri;
b) Implementarea modelului logic al datelor.
c) Transformarea modelului conceptual al datelor (entitate-relaie), realizat fr s
se in cont de perspectiva utilizatorului, ntr-un set de relaii normalizate;
Rspuns: a, c
14. Nu sunt elemente de baz ale structurii relaionale a datelor:
a) Relaia;
b) Atributul;
c) Fiierul;
d) Domeniul;
e) Tuplul.
Rspuns: c
15. Paii parcuri n procesul de transformare a diagramelor entitate-relaie n relaii sunt:
a) Reprezentarea entitilor;
b) Reprezentarea legturilor;
c) Normalizarea relaiilor.
Rspuns: a, b, c
16. Modelul conceptual pune n eviden:
a) modul de stocare a datelor pe suportul de memorare;
b) reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i datelor
elementare ale unei organizaii;
c) structura global de organizare a datelor.
Rspuns: b), c)
17. Normalizarea unei relaii const n:
a) Descrierea relaiei n limbajul de descriere a datelor;
b) Identificarea dependenelor ntre atributele relaiei;
c) Descompunerea relaiei n relaii echivalente urmrind eliminarea redundanei
datelor i anomaliilor la efectuarea operaiilor de adaugare, actualizare i tergere
n baza de date.
Rspuns: c)
108
Capitolul 5
Proiectarea fizic a sistemelor informatice

Proiectarea fizic cunoscut i sub numele de proiectare de detaliu, urmeaz
proiectrii logice ntlnit i sub numele de proiectare general sau proiectare de
ansamblu. n timpul proiectrii 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 informaiile de natur s
sintetizeze cerinele utilizatorilor noului sistem, operaiune prestat de analitii de sistem,
iar n timpul proiectrii fizice se prezint punctele de vedere ale specialitilor, cum ar fi
cei din domeniul bazelor de date, securitii sistemelor, reelelor de calculatoare,
programrii, etc.
Proiectarea fizic implic parcurgerea urmtorilor pai [1]:
1. Proiectarea fizic a bazelor de date i a fiierelor. 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 strns concordan cu diagramele fluxurilor de date i cu
celelalte piese ale documentaiei realizate n etapele anterioare;
3. Proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care
utilizatorul poate s dispun de date i facilitile de prelucrare oferite de reele de
calculatoare.

5.1. Proiectarea fizic a bazelor de date i a fiierelor
Modelul conceptual surprinde structura global de organizare a datelor,
asigurndu-se independena total fa de orice sistem de gestiune a bazelor de date.
Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaie(DER),
motiv pentru care este cunoscut i sub numele de modelul entitate-relaie al datelor. El
scoate n eviden reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i
109
datelor elementare ale unei organizaii sau ale unei pri 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 ctre sistemele de gestiune a bazelor de date. n acest material s-a
ales modelul relaional. Conform cu acest model datele sunt reprezentate n baza de date
sub forma tabelelor sau relaiilor create din diagrama entitate-relaie obinut n etapa
anterioar.
O baz de date poate fi definit ca un ansamblu de date elementare sau structurate,
accesibile unei comuniti de utilizatori. Mai concret, la nivel fizic, o baz de date este un
ansamblu de fiiere intercorelate, care conine nucleul de date necesare unui sistem
informatic (aplicaie informatic). Un fiier este un ansamblu de nregistrri fizice,
omogene din punct de vedere al coninutului i al prelucrrii. O nregistrare fizic este
unitatea de transfer ntre memoria intern i cea extern a calculatorului. nregistrarea
fizic este format din una sau mai multe nregistrri logice. O nregistrare logic este
unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este format
dintr-un ansamblu de cmpuri, care descriu o anumit entitate.
Modul de stocare a datelor pe suportul fizic de memorare este funcie de sistemul
de gestiune a bazelor de date utilizat.
Proiectarea fizic a bazelor de date i a fiierelor 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 soluionrii optime a problemelor formulate n etapele anterioare
ale realizrii sistemului informatic.
5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:
Centralizarea datelor permite: suprimarea redundanei, asigurarea unicitii
nregistrrii i controlul centralizat (asupra datelor). n prelucrarea clasic n care fiierele
sunt dedicate aplicaiilor, aceleai date apar nregistrate n mai multe fiiere i n formate
110
diferite. Acest lucru implic o utilizare ineficient a spaiului de memorie extern,
actualizarea dificil a acestor date i lizibilitate redus ca urmare a formatelor diferite.
Independena ntre date i prelucrri. Baza de date, ca imagine a unei anumite
realiti, 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 legturi ntre entitile de date, care sunt indispensabile pentru
exploatarea eficient a sistemului informatic. Spre exemplu, n cadrul gestiunii
aprovizionrii, trebuie asociat un furnizor la lista de produse pe care le vinde i invers, un
produs la lista de furnizori, preciznd condiiile de vnzare pentru un furnizor i un
produs.
Integritatea datelor asigur fiabilitatea i coerena bazei de date (BD). Pentru
aceasta trebuie definite restricii de integritate cum ar fi:
- apartenena la o list de valori sau interval;
- apartenena 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 tranzacii; lista operaiilor realizate asupra bazei de
date dup ultimul punct de repriz.
Confidenialitatea datelor este asigurat prin proceduri de:
- identificare a utilizatorilor prin nume sau cod;
- autentificarea prin parole;
- autorizarea accesului difereniat prin drepturi de creare, consultare modificare
sau tergere pentru anumite segmente de date.
Partajarea datelor permite nlnuirea tranzaciilor solicitate simultan pe aceeai
nregistrare din baza de date, prin blocarea cererilor n ateptare i deservirea ulterioar a
acestora.
111
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
ntreinerea bazei de date, precum i accesul controlat la baza de date. Un SGBD ofer
urmtoarele faciliti pentru crearea i exploatarea bazelor de date:
- faciliti 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;
- faciliti 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 ctre utilizatori
neautorizai;
- sistem de integritate, menine concordana datelor stocate n baza de
date;
- sistem de control al concurenei, permite accesul partajat la baza de date;
- sistem de control al refacerii, permite recuperarea bazei de date n urma
unor defeciuni 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 regsesc
reunite n cadrul unui singur limbaj (spre exemplu limbajul SQL).

5.1.3. Administratorul bazei de date
Administratorul bazei de date referit prescurtat DBA (Data Base Administrator),
este o persoan sau un grup de persoane care coordoneaz i rspunde de ansamblul
112
activitilor privind baza de date, ncepnd din faza de proiectare i continund cu
celelalte etape pe ntreaga perioad de via a bazei de date. Astfel, n faza de proiectare a
bazei de date, administratorul stabilete SGBD-ul ce va fi utilizat, echipamentele
necesare, structurile de date plecnd de la necesitile de informaie ale tuturor
utilizatorilor bazei de date, drepturile de acces la date ale fiecrui utilizator. Rezultatul
fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema
general a bazei de date), modelului extern (subschema proprie fiecrui utilizator) i
stabilirea modalitilor 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 menine permanent legtura cu utilizatorii acesteia pentru rezolvarea
cerinelor utilizatorilor i impunerea unei discipline n vederea alinierii la standardele
existente. Administratorul va realiza, ori de cte ori se impune, reorganizarea structurii
fizice a datelor n vederea optimizrii parametrilor de funcionare a ntregului sistem i va
stabili 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 prevzute [DATE04] i alte mecanisme i anume: evidena de auditare, criptarea
datelor.
Evidena de auditare const dintr-un fiier n care sistemul nregistreaz automat
toate operaiile efectuate asupra datelor, fiier ce va putea fi consultat de ctre persoane
autorizate pentru a verifica efectuarea unor operaii neautorizate. O nregistrare din
evidena de auditare va conine urmtoarele informaii: textul surs al operaiei executate,
terminalul de la care a fost lansat operaia, utilizatorul care a lansat operaia, data i ora
operrii, obiectele bazei de date afectate, imaginile datelor afectate nainte de efectuarea
operaiei, imaginile datelor afectate dup efectuarea operaiei.
Pentru a preveni accesul unor intrui la baza de date, care ncearc s ocoleasc
sistemul, se utilizeaz criptarea datelor, mecanism ce const n stocarea i transmiterea
datelor pe cile de comunicaie sub form cifrat. Criptarea se realizeaz cu ajutorul unor
113
algoritmi de criptare printre care cel mai recent este standardul american de criptare
avansat AES (Advanced Encryption Standard).

5.1.4. Proiectarea securitii bazelor de date i a fiierelor
Securitatea este abordat din mai multe puncte de vedere, dar cea referitoare la
baze de date i la fiiere presupune luarea unor msuri pentru reconstituirea datelor
pierdute sau preluate eronat, precum i pentru accesul neautorizat sau incomodarea pn
la a face imposibil citirea datelor, prin criptare, atunci cnd ele sunt accesate ilegal.
Aadar dou aspecte vor fi relevante: reconstituirea datelor i criptarea lor [1].
Reconstituirea datelor este des asociat cu existena fiierelor de tip back-up, ns
n practic este posibil i reconstituirea fr apelarea la acest tip de fiiere. n vederea
controlrii corectitudinii datelor tranzacionate se apeleaz la fiiere cu rol special, care
conin un istoric, n ordine cronologic, al schimbrilor i accesrilor efectuate asupra
fiierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fiierele distruse, dar i la
verificarea corectitudinii operaiunilor de actualizare.
Securitatea prin criptografiere se refer la asigurarea transformrii datelor de
comunicat ntr-o form neinteligibil pentru toi ceilali receptori, exceptndu-l pe cel
autorizat. Criptarea a devenit una dintre cele mai puternice modaliti de asigurare a
securitii datelor. Ea poate fi realizat prin sistemul de operare sau prin SGBD, dar i
prin rutine create de ctre specialiti.
n cele ce urmeaz sunt prezentate criteriile avute n vedere n alegerea tipului de
SGBD [2].
a) Portabilitatea SGBD-ului. Prin aceasta nelegem 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 conin ct mai
puine elemente legate de echipament. Portabilitatea sistemului de gestiune privit
prin prisma portabilitaii datelor se refer la posibilitatea de a folosi o serie de date
114
utilizate n cadrul unui sistem informatic de ctre un alt sistem informatic, deci
posibilitatea integrrii fiierelor deja existente n cadrul unui alt sistem.
b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a
unitii centrale; costului de ntreinere i dezvoltare; resurselor hard imobilizate;
costului de adaptare i trecere pe un nou sistem de calcul; costul documentaiei etc.
c) Facilitile de implementare, ntreinere i exploatare a bazei de date. Acestea sunt
reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare i
regsire a datelor, care s permit un acces ct mai rapid la orice informaie; timpul
ct mai redus pentru actualizare, cutare i rspuns la cererile de informare;
editarea operativ a celor mai variate tipuri de situaii solicitate de ctre utilizator;
posibilitatea de inserie a unor programe de aplicaie, programe de validare de date,
de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafic a
ieirilor etc.
d) Posibilitatea gestionarii structurilor complexe de date.
e) Multitudinea metodelor de acces. In funcie de cerinele proprii aplicaiei, sistemul
va trebui s suporte interogri sau actualizri n timp real avnd proceduri de tip
conversaional.
f) Protecia i securitatea datelor din baz.
g) Specificul aplicaiei. Este cunoscut faptul c programele sunt orientate pe aplicaii,
cum ar fi: programarea produciei, aprovizionare-desfacere, optimizri, prognoze
etc.
Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari
cum ar fi: mentenana sistemului, facilitile ce le ofer administratorului bazei de date,
calitatea documentaiei oferite de furnizori, asisten n implementarea sistemului i n
pregtirea utilizatorilor etc. Toi aceti factori alturi de criteriile enunate pot s
influeneze succesul n implementarea SGBD-ului i eficiena economic pe ansamblul
sistemului informatic.
115
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 interogrilor bazei de date, precum i exemple practice sub SGBD ORACLE.
5.1.5. Limbajul SQL - Crearea, Administrarea i Interogarea bazelor de date
relaionale
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
rspndite limbaje pentru SGBD-urile relaionale. Limbajul SQL, ca limbaj de interogare
a bazelor de date relaionale, este construit pe baza a dou formalisme abstracte enunate
n cele ce urmeaz.
1. Algebra relaional prin care interogrile sunt exprimate prin aplicarea unor
operatori unari sau binari care constituie primitive ce acioneaz asupra relaiilor,
rezultatul interogrilor fiind tot relaii, ceea ce permite asocierea i imbricarea
acestor operatori pentru a forma interogri complexe. Operatorii algebrei
relaionale se mpart n dou grupe i anume:
- operaii pe mulimi (Reuniunea, Intersecia, Diferena, Produsul cartezian);
- operatori relaionali speciali (Selecia, Proiecia, Cuplarea (JOIN), Diviziunea).
2. Calculul relaional prin care interogrile descriu mulimea tuplelor rezultat prin
specificarea unui predicat (condiie) care trebuie satisfcut de aceste tuple.
ncepnd din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de
interogare ale bazelor de date relaionale fiind utilizat att n cadrul unor SGBD-uri
complexe cum ar fi SGBD ORACLE (liderul mondial n domeniul bazelor de date), ct i
n cadrul unor SGBD-uri de complexitate redus cum ar fi cele din familia xBase (Dbase
IV, FoxPro).
Standardul SQL utilizat pn la nceputul anului 2000 este cel realizat n 1992 i
cunoscut sub numele de SQL92 sau SQL2.
Noul standard SQL3 lansat n 1999 are n vedere o serie de extensii fa de SQL2
dup cum urmeaz:
116
- faciliti orientate obiect posibilitatea de definire de ctre utilizator a tipurilor
abstracte de date care s permit descrierea de metode, identitatea obiectelor,
subtipuri i motenire, polimorfism etc.;
- structuri de control pentru a conferi limbajului completitudine de calcul (IF,
FOR, WHILE, etc.) pentru a deveni un limbaj de sine stttor a crui putere de
expresie s nu mai fie limitat la nivelul limbajelor relaionale;
- faciliti pentru exprimarea prelucrrilor recursive;
- faciliti de comunicare n reea;
- faciliti de prelucrare distribuit (mecanisme pentru crearea, memorarea i
execuia procedurilor la nivelul serverelor de date stored procedures);
- faciliti multimedia;
- faciliti 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>
Adugarea relaiilor ntr-o baz de date comanda CREATE TABLE are sintaxa:
CREATE TABLE <nume relaie>[(<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 relaie poate fi creat i ca rezultat al unei operaii de interogare astfel:
CREATE TABLE <nume relaie> (<nume atribut> <tip dat>,) AS <subinterogare>
Adugarea/modificarea de atribute pentru o relaie existent se realizeaz cu
comanda:
ALTER TABLE <nume relaie> ADD|MODIFY (< nume atribut> <tip dat>,)
tergerea unei relaii se realizeaz cu comanda:
DROP TABLE <nume relaie>
117
Comenzi pentru optimizarea interogrilor
Una din principalele ci de optimizare a timpilor de interogare a unei baze de date
este indexarea. Un index poate fi privit ca o relaie cu dou atribute i anume:
- primul atribut conine valorile atributelor relaiei dup care se creaz indexul;
- al doilea atribut conine un pointer (adresa) la locaia tuplelor corespunztoare.
Crearea unui index se realizeaz cu comanda:
CREATE [UNIQUE] INDEX <nume index>
ON <nume relaie>(<nume atribut>[ASC|DESC],)
Dac pentru atributele utilizate n clauza WHERE a unor instruciuni SQL au fost
creai indeci, atunci acetia vor fi utilizai n vederea optimizrii 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 obinere a
rezultatului.
O alt tehnic de optimizare a interogrilor este tehnica clustering disponibil n
ORACLE i care const n gruparea tuplelor din mai multe relaii i stocarea lor n aceeai
zon pe disc.
Controlul datelor (comenzi DCL)
Vederi
O vedere este o relaie virtual, definit plecnd de la alte relaii din baza de date i
care nu conine date i deci nu ocup spaiu fizic pe disc. Vederile se definesc n dou
scopuri i anume:
- pentru a simplifica accesul utilizatorilor la date;
- pentru a asigura protecia i securitatea datelor fiecrui utilizator fiindu-i
permis acces la o poriune a bazei de date i putnd efectua doar anumite
operaii (conform drepturilor de acces specificate cu comenzile
GRANT/REVOKE).
118
Asupra unei vederi se pot efectua aceleai operaii ca i asupra unei relaii cu
deosebirea c vederile nu conin date i c orice modificri efectuate asupra datelor sunt
reflectate i n vederi. Astfel, asupra unei vederi se pot realiza operaiile:
- 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);
- adugare 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,Stocuri WHERE Produse.codp=Stocuri.Codp AND CodDep = D1
Interogarea vederii se va realiza cu comanda
SELECT * FROM StocuriD1
Utilizarea opiunii WITH CHECK OPTION asigur faptul c nici o tupl nu va fi
adaugat sau actualizat cu instruciunile INSERT, UPDATE, dac nu sunt respectate
condiiile specificate n clauza WHERE a instruciunii SELECT din definiia vederii.
Pentru acordarea sau retragerea drepturilor de acces la baza de date prin
intermediul vizualizrilor se vor folosi comenzi de forma:
GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
TO <nume utilizator>
sau
REVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
FROM <nume utilizator>
119
Asigurarea securitii datelor presupune definirea drepturilor de acces ale
utilizatorilor i protecia sistemului la accesul neautorizat. n acest sens asigurarea
securitii se realizeaz pe dou niveluri i anume:
- nivelul 1 acordarea dreptului de acces la sistem;
- nivelul 2 acordarea dreptului de acces la nivel de relaii.
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 relaie n sistemele multi-user trebuie
precizat utilizatorul care a creat relaia (proprietarul relaiei). Fiecare utilizator are
drepturi doar asupra propriilor relaii, iar drepturi asupra unor relaii create de ali
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 dicionarul de date i sunt gestionate de ctre 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 oricrei operaii asupra
oricrei relaii din baza de date;
- CONNECT confer utilizatorului dreptul de a a face interogri (SELECT) i
actualizri (INSERT, UPDATE, DELETE) asupra relaiilor create de ali
utilizatori, ns nu permite utilizatorului s creeze relaii (CREATE) sau s
tearg relaii create de ali utilizatori (DROP);
- RESOURCE confer utilizatorului drepturile ce rezult din autorizarea
CONNECT i n plus dreptul de a crea relaii (CREATE) i de a terge relaii ce
i aparin (DROP).
120
Unui utilizator i pot fi acordate mai multe tipuri de autorizri 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>
Unui utilizator cruia i s-a acordat un tip de autorizare i pot fi acordate i alte
tipuri de autorizare prin comenzi GRANT ulterioare.
Retragerea autorizrilor acordate unui utilizator se realizeaz cu comanda:
REVOKE <autorizare,> FROM <nume utilizator>
Nivelul 2 de securitate a datelor
Pentru acordarea respectiv retragerea drepturilor de acces la relaii se utilizeaz
comenzile GRANT respectiv REVOKE cu urmtoarea sintax:
GRANT ALL|<drept de acces>, ON <nume relaie>
TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]
respectiv
REVOKE ALL|<drept de acces>, ON <nume relaie>
FROM <nume utilizator>|PUBLIC
Privilegiile (drepturile de acces) pot fi acordate sau retrase de urmtoarele categorii
de utilizatori:
- utilizatorii cu nivel de autorizare DBA;
- proprietarii relaiilor;
- utilizatorii autorizai cu opiunea 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 rndul su
s acorde aceleai drepturi sau mai puine altor utilizatori.
n ORACLE pot fi acordate urmtoarele drepturi de access asupra relaiilor:
SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele i indeci.
121
Drepturile de acces pot fi acordate asupra ntregii relaii, sau doar asupra anumitor
atribute ale relaiei.
Exemple:
Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra
relaiei Persoane care aparine utilizatorului Vasilescu se realizeaz prin comanda:
GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu
Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra
relaiei Produse aparinnd 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 relaia Produse aparinnd utilizatorului Ionescu, utilizatorului Popescu cu condiia ca
acesta la rndul su s poat acorda oricrui alt utilizator aceleai drepturi sau mai puine,
se realizeaz cu comanda:
GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire)
TO Popescu WITH GRANT OPTION
Retragerea drepturilor de acces INSERT,DELETE asupra relaiei Persoane
aparinnd utilizatorului Vasilescu, utilizatorului Ionescu se realizeaz cu comanda:
REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu
Instruciuni pentru inserarea i actualizarea datelor n tabele
Inserarea datelor comanda INSERT are urmtoarea sintax:
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 completnd toate atributele)
INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,Ionescu,Ana)
(adaug o nregistrare n Persoane completnd numai atributele Nrcrt,Nume, Prenume)
122
Pentru a insera n tabela PersF(Nrcrt,Nume,Prenume) toate nregistrrile din tabela
Persoane pentru care Sexul=F se scrie comanda:
INSERT INTO PersF(Nrcrt,Nume,Prenume) SELECT Nrcrt,Nume,Prenume
FROM Persoane WHERE Sexul = F
Actualizarea datelor comanda UPDATE are sintaxa:
UPDATE <nume relaie>|<nume vedere>
SET <nume atribut> = <expresie>,[WHERE <condiie>]
Condiia din clauza WHERE definete tuplele care vor face obiectul actualizrii.
Clauza WHERE poate conine 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 preului cu 20% pentru produsele vndute cu factura 120).
Dac n comanda UPDATE clauza WHERE este omis, actualizarea se va efectua
asupra tuturor tuplelor relaiei.
tergerea datelor comanda DELETE are sintaxa:
DELETE FROM <nume relaie>|<nume vedere> [WHERE <condiie>]
unde <condiie> poate fi o condiie simpl, o expresie sau o subinterogare.
Exemple:
DELETE FROM Stocuri WHERE Cant = 0
(terge toate nregistrrile din tabela Stocuri pentru care cmpul Cant are valoarea 0).
DELETE Oferte
(terge toate nregistrrile din tabela Oferte).

123
Comenzi pentru gestiunea tranzaciilor
Tranzacia este o succesiune de instruciuni SQL grupate ntr-un bloc de
instruciuni utilizate pentru actualizarea i/sau interogarea datelor din baza de date. O
tranzacie se consider ncheiat dup realizarea tuturor operaiilor pe care le conine.
Operaiile coninute ntr-o tranzacie pot fi realizate efectiv n baza de date sau nu, fie
automat de ctre sistem dup fiecare operaie, fie printr-o comand explicit dat dup o
succesiune de operaii. Astfel salvarea automat de ctre sistem a modificrilor este
realizat prin comanda
SET AUTOCOMMIT ON
Dac iniial a fost specificat comanda SET AUTOCOMMIT OFF, salvarea
modificrilor efectuate asupra datelor se realizeaz prin comanda COMMIT, iar
abandonarea modificrilor se realizeaz prin comanda ROLLBACK.
Blocul de operaii ce definesc o tranzacie poate fi delimitat de instruciunile :
BEGIN TRANSACTION
END TRANSACTION

Problem rezolvat
Se lanseaz n execuie 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 instruciunea
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 nregistrri (figura 5.4).






124











































Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system
ORCL
Figura 5.2. Creare utilizator U1 i acordare privilegii CONNECT, RESOURCE
125





























Figura 5.3. Lansare SQL Plus ORACLE pentru utilizatorul U1
ORCL
Figura 5.4. Creare tabel Produse i inserare dou nregistrri
126
Limbajul SQL - Interogarea bazelor de date - Fraza SELECT
Interogarea bazelor de date n limbajul SQL se realizeaz cu ajutorul unei singure
instruciuni i anume instruciunea SELECT avnd urmtoarea sintax:
SELECT [DISTINCT] <lista atribute>|*
FROM <lista relaii>
[WHERE <condiie>]
[GROUP BY <lista atribute de grupare>]
[HAVING <condiie>]
[ORDER BY <atribut1 de ordonare> [ASC]|DESC,]
[UNION <fraz SELECT>]
<lista atribute> este o list ce conine nume de atribute (cmpuri) sau expresii construite
utiliznd atribute, separate prin caracterul , i care fac parte din relaiile (tabele, vederi)
enumerate n <lista relaii> din clauza FROM. Numele fiecrui atribut sau expresii din
<lista atribute> va fi afiat n capul de tabel ce reprezint rezultatul interogrii, fiecare
atribut sau expresie putnd 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 relaia rezultat nu pot aprea duplicate
(tuple identice).
Clauza WHERE precizeaz condiiile de interogare (condiii care trebuie s fie
satisfcute de tuplele interogate, condiii de cuplare relaii (JOIN, relaii ntre tabele). n
clauza WHERE pot fi utilizai operatori logici (AND, NOT, OR), predicate (IN, LIKE,
BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de
comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a
operaiilor, operatorilor, funcii i alte subinterogri SELECT, pentru construirea de
expresii pe care trebuie s le ndeplineasc tuplele ce constituie rezultatul interogrii.
Predicatul IN permite specificarea unei liste pentru domeniul de cutare pentru un atribut,
iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de cutare a
valorilor unui atribut, fiind echivalent cu o condiie de forma:
<atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>

127
Exemple:
Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)
Selectarea tuturor nregistrrilor din tabela Persoane pentru care primele 7
caractere din cmpul Adresa sunt Suceava sau Rdui se realizeaz cu comanda:
SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (Suceava,Rdui)
Interogarea de mai sus este echivalent cu interogarea:
SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = Suceava
OR SUBSTR(Adresa,1,7) = Rdui
Selectarea tuturor nregistrrilor din tabela Persoane pentru care data naterii 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 selecia irurilor de caractere care conin anumite
caractere specificate prin intermediul unei mti definite cu ajutorul unor caractere
speciale (%, _ n dBASE IV, FoxPro, ORACLE, sau *, ? n INFORMIX)
Exemple:
SELECT * FROM Persoane WHERE Nume LIKE %a
(selecteaz toate nregistrrile 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 nregistrrile 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 nregistrrile din tabela Persoane pentru
care prima liter din Nume este orice liter, a doua liter din Nume este litera o i
ncepnd din poziia a treia numele poate conine orice litere.)
128
Predicatele ALL, ANY, EXISTS se utilizeaz pentru interogri ce conin
subinterogri, n vederea verificrii anumitor condiii ce trebuie ndeplinite ntre
rezultatele interogrii i rezultatele subinterogrii.
Clauza GROUP BY realizeaz gruparea tuplelor unei relaii pe baza valorilor
unui atribut sau grup de atribute i genereaz o singur tupl pentru fiecare grup de tuple
avnd aceeai valoare pentru atributele care definesc grupul. Atributele care definesc
grupul trebuie obligatoriu s se regseasc n lista atributelor interogate <lista atribute>.
De asemenea asupra unor atribute pot fi aplicate funcii 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>) numrul nregistrrilor pe grupare dup <atribut>.
Observaie. <atribut> poate fi fie un atribut, fie o expresie definit utiliznd
atribute ale tabelei.
Clauza HAVING, opiune a clauzei GROUP BY, este o form special a clauzei
WHERE ntruct 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
(Calculeaz suma produselor Cant*Pret pentru toate tuplele avnd aceeai valoare n
cmpul CodDep i numrul nregistrrilor din fiecare grup definit de cmpul CodDep i
afiseaz rezultatele sub form de tabel avnd coloanele CodDep, Valoare, Contor)
SELECT CodDep,CodP,MAX(Pret) FROM Stocuri
GROUP BY CodP HAVING MAX(Pret) < 150000
129
(selecteaz pentru fiecare grup de nregistrri avnd aceeai valoare n cmpul CodP,
nregistrarea cu preul maxim mai mic dect 150000)
Clauza ORDER BY permite precizarea ordinii de afiare a datelor astfel:
ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC,
Exemplu:
SELECT * FROM Persoane ORDER BY Datan DESC,Nume
(afieaz toate nregistrrile din tabela Persoane n ordine descresctoare dup data
naterii i n cadrul aceleiai date a naterii cresctor dup Nume)
Clauza UNION permite obinerea rezultatului a dou sau mai multe interogri
printr-o singur instruciune 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
nregistrrile pentru care CodDep = Dep01, la care adaug tuplele
(CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care Cant
>= 100).
Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL.
Pentru a schimba ordinea de afiare a tuplelor extrase se poate utiliza clauza
ORDER BY aplicat doar relaiei finale i nu asupra fiecrei fraze SELECT.
Regsirea datelor din dou sau mai multe relaii
Interogarea datelor din dou sau mai multe tabele (relaii) presupune existena unor
cmpuri comune pentru realizarea operaiei de cuplare (operatorul JOIN). n fraza
SELECT operaia de cuplare este definit n clauza WHERE sub forma:
<nume tabela1>.<cheie1> = <nume tabela2>.<cheie2>
(unde <cheie1>, <cheie2> reprezint cmpurile ce identific nregistrrile corespondente
n cele dou tabele).
130
Pentru exemplificare pe lng tabela Stocuri mai considerm tabela Produse(CodP,
DenP, DesP).
SELECT Produse.CodP,DenP,UmP,Cant,Pret FROM Produse,Stocuri
WHERE 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 combinaiile posibile ntre tuplele
celor dou tabele (produsul cartezian).
Fiecrei tabele i se poate atribui un alias astfel nct fraza de mai sus este
echivalent cu fraza:
SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP =
B.CodP
n anumite situaii poate fi necesar corelarea (cuplarea) unei relaii (tabele) cu ea
nsi. Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de
mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm
urmtoarea interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP)
Pentru rezolvarea unor astfel de probleme s-au utilizat instruciuni SELECT
imbricate care vor fi prezentate n detaliu n cele ce urmeaz.
Instruciuni SELECT imbricate
Limbajul SQL ofer posibilitatea construirii unor interogri complexe prin
includerea n clauza WHERE a unei instruciuni SELECT, a altei instruciuni SELECT
(numit sub-interogare sau inner) astfel:
SELECT <lista atribute> FROM <lista relaii>
WHERE <condiie> (<sub-interogare>)
La rndul ei sub-interogarea poate conine n clauza WHERE o alt instruciune
SELECT obinnd astfel o interogare complex constituit din instruciuni SELECT
imbricate pe un numr oarecare de nivele. Instruciunea SELECT interioar genereaz
131
valori pentru condiia de cutare a instruciunii SELECT exterioare care o conine (numit
i outer). O sub-interogare poate returna o singur valoare, sau poate returna mai multe
valori.
n ce privete ordinea de evaluare a interogrilor pot exista :
- sub-interogri simple - n care interogarea interioar este evaluat prima,
independent de interogarea exterioar, iar rezultatul interogrii interioare este
utilizat de interogarea exterioar;
- sub-interogri corelate - n care interogarea exterioar transmite repetat cte o
valoare pentru interogarea interioar, care n baza valorii primite, parcurge
tuplele relaiei i transmite interogrii exterioare rezultatul obinut. Astfel de
interogri realizeaz corelarea unei relaii cu ea nsi i sunt cele mai
performante.
Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de
mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm
urmtoarea interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP)
Sub-interogri simple care returneaz o singur valoare - pot fi utilizate n
interogri imbricate avnd sintaxa:
SELECT <lista atribute> FROM <lista relaii>
WHERE <atribut> =
<
>
<=
>=
!=
(<sub-interogare>)
[ORDER BY <atribut[ASC]|DESC,]

132
Exemplu:
SELECT CodDep,CodP,Cant FROM Stocuri
WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep
(afieaz produsele pentru care exist stocuri peste medie, ordonate pe depozite).
Sub-interogari simple care returneaza mai multe valori pot fi utilizate n interogri
imbricate care utilizeaz n clauza WHERE condiii care genereaz o mulime de valori
folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.
Exemplu:
SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi
WHERE Numar IN (SELECT Numar FROM Beneficiari,Comenzi
WHERE Beneficiari.Nume=Ionescu AND Beneficiari.Cod_B=Comenzi.Cod_B))
Predicatul ANY poate fi utilizat n combinaie cu oricare din operatorii <, >, =, <=,
>=, != i permite verificarea dac valoarea unui atribut satisface condiia 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 <, >, <=, >= dect toate valorile generate de interogarea interioar (acest
predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal n care toate
interogrile 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 relaiei exist tuple care
satisfac condiia din interogarea interioar (deci EXISTS permite specificarea mai multor
atribute n interogarea interioar). Astfel spre exemplu instruciunea:
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.
133
Aplicaie practic
Se consider baza de date Furnizori_Clieni_Stocuri care conine urmtoarele
tabele (n ACCESS):
PRODUSE (catalog de produse)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codp Cod produs Number, Integer 4 Cheie primar
Denp Denumire produs Text 20
Desp Descriere produs Hyperlink Refer document
corespunztor

STOCURI (stocurile de produse pe depozite)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codp Cod produs Number, Integer
Lookup Wizard
4 Lookup Wizard cu
tabela PRODUSE
CodDep Cod depozit Text 2
Ump Unitate de
msur produs
Lookup Wizard 8 Creare i utilizare
list de valori
Cant Cantitate Number, Integer 4
Pret Pre unitar Number,
LongInteger
8

FURNIZORI (catalog de furnizori)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codf Cod furnizor Number, Integer 4 Cheie primar
Denf Denumire
furnizor
Text 30
Adresaf Adresa furnizor Text 25

CLIENTI (catalog de clieni)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codc Cod client Number, Integer 4 Cheie primar
Denc Denumire client Text 30
Adresac Adresa client Text 25

OFERTE (oferte de produse de la furnizori)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codf Cod furnizor Number, Integer
Lookup Wizard
4 Lookup Wizard cu
tabela FURNIZORI
Codp Cod produs Number, Integer
Lookup Wizard
4 Lookup Wizard cu
tabela PRODUSE
Ump Unitate de Lookup Wizard 8 Creare i utilizare
134
msur produs list de valori
Pret Pre unitar Number,
LongInteger
8
Datao Data ofertei Date 8
Oferta Oferta furnizor Hyperlink Refer document
corespunztor

VANZARI (vnzrile de produse pe clieni)
Cmp Semnificaie Tip dat Dimensiune Observaii
Codc Cod furnizor Number, Integer
Lookup Wizard
4 Lookup Wizard cu
tabela CLIENTI
Codp Cod produs Number, Integer
Lookup Wizard
4 Lookup Wizard cu
tabela
PRODU,03SE
Ump Unitate de
msur produs
Lookup Wizard 8 Creare i utilizare
list de valori
Cant Cantitate Number, Integer 4
Pret Pre unitar Number,
LongInteger
8

S se scrie comenzile SQL pentru realizarea interogrilor de mai jos:

a) Situaia stocurilor
b) Situaia ofertelor

c) Situaia vnzrilor

d) Lista produselor pentru care nu exist oferte

Cmp CodDep Codp Denp Ump Cant Pret Valoare
Tabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret
Cmp Codf Denf Adresaf Codp Denp Ump Pret Datao
Tabela Furnizori Furnizori Furnizori Produse Produse Oferte Oferte Oferte
Cmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare Datav
Tabela Clienti Clienti Clienti Produse Produse Vanzari Vanzari Vanzari Cant*Pret Vanzari
Cmp Codp Denp
Tabela Produse Produse
135
Lista produselor pentru care nu s-au fcut vnzri n perioada [Data1,Data2]



Rspuns:
a)
SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS Valoare
FROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp
b)
SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao
FROM Oferte, Produse,Furnizori
WHERE 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,Clienti
WHERE 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 procedurilor
Proiectantul de soft are ca principal misiune definirea i structurarea
componentelor care vor forma un tot unitar, astfel nct prin acestea s se obin un
proiect soft operaional. Proiectantul va grupa funciile ce trebuie s fie interconectate i
va descrie modalitile de realizare a legturilor. Dup proiectanii de soft vor interveni
programatorii, pentru transpunerea n realitate a proiectului. Ei vor controla intrrile,
prelucrrile i ieirile din sistem prin intermediul programelor.
Softul are dou componente de baz instruciunile i modulele. Instruciunile sunt
operaiuni elementare executate de calculator prin gruparea i selecia controlat a
acestora pentru atingerea obiectivelor funciilor de prelucrare orientate pe probleme.
Cmp Codp Denp
Tabela Produse Produse
136
Instruciunile constituie cel mai jos nivel al operaiunilor ce pot fi executate de ctre un
limbaj de programare. Blocurile de instruciuni sunt astfel grupate nct s constituie
anumite structuri executabile de calculator. De modul n care sunt grupate instruciunile
pentru a da natere unor structuri standard ale programelor, de relaiile dintre instruciuni,
de aranjamentul acestora depinde calitatea softului proiectat.
Modulul este o colecie sau o form grupat de instruciuni de programe surs.
Modulele se pot grupa pentru a forma programele.
Programul, n concepia diverilor autori, are semnificaii diferite. El este definit
ca:
- un set de instruciuni cu ajutorul crora se efectueaz prelucrri 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 execuiei pe
calculator, deci o reprezentare a acestora (algoritmi i date) innd cont de
restriciile impuse de calculator;
- o realizare a unei funcii f care, dat fiind o mulime de date x, specific
valoarea y=f(x);
Prin algoritm se nelege o metod de soluionare a unei clase de probleme,
reprezentat de o succesiune finit de operaii bine definite, numite instruciuni.
Prin prisma complexitii lor programele se pot clasifica n [1]:
- programe simple (1000 de linii)
- programe de complexitate medie(10 000 de linii)
- programe complexe (peste 100 000 de linii) au numeroase module cu legturi
complexe.
Pentru ca programele s fie caracterizate prin eficien, fiabilitate, flexibilitate,
inteligibilitate, n procesul elaborrii lor trebuie s se respecte anumite principii [1]:
- principiul conformrii, potrivit cruia programele trebuie s fie elaborate n
conformitate cu cerinele utilizatorului;
137
- principiul completitudinii const n realizarea descrierilor complete ale
obiectivelor programului pe toate nivelurile ierarhice de descompunere;
- principiul abstractizrii se refer la elaborarea funciei programului, innd cont
de elementele eseniale, fcndu-se abstracie de detaliile nesemnificative;
- principiul modularizrii 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 programrii clasice are la baz construirea monolitic a logicii
programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat
direct la nivelul operaiilor elementare pe care le implic executarea lucrrii care se
elaboreaz .
Programarea modular const n descompunerea programului, chiar din faza de
proiectare, n module uor de ntrebuinat. Fiecare modul este apoi analizat ca un program
distinct i rezolvat ca atare [1].
Metoda programrii structurate const n faptul c ofer o rezolvare standardizat
i structurat, n mod unitar, a programelor, reprezentnd o ridicare a activitii de
programare la nivelul activitii industriale, fundamentat pe o metodologie tiinific.
Programarea structurat este caracteristic dezvoltrii sistemelor pe baza diagramelor
fluxului de date i utilizeaz limbaje structurate. Ea presupune o separare ntre structurile
de date i codul funciilor care le prelucreaz.
Metoda programrii orientate-obiect - const n abordarea natural a lumii reale,
folosind componente modularizate i eliminnd restriciile impuse de mediul de
programare. Se definesc concepte noi de tip, clas, motenire, etc [Udric M., 2000].

138
5.2.1. Atributele modulelor
La nivelul softului proiectat, componenta de baz este modulul. El este o colecie
sau o form grupat de instruciuni ale programului surs. La rndul lor, modulele se pot
grupa pentru a forma programe.
Modulele programelor au urmtoarele caracteristici [1]:
- Un modul este format dintr-un grup de instruciuni care sunt contigue din punct
de vedere fizic i sunt executate ca o unitate distinct;
- Grupurile de instruciuni care formeaz un modul au nceputuri i sfrituri
bine definite;
- n majoritatea cazurilor, grupul de instruciuni are doar un punct de intrare i
unul de ieire;
- 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: funcia, logica i interfeele.
Funcia unui modul const n transformarea datelor prin procesul de execuie a
acestuia. Funcia este tratat n regimul cutiilor negre, ea fiind vzut 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 intrrile i ieirile modulului respectiv [1].
La nivelul softului, referirea la un modul este n acelai timp o referire la funcia
lui. La nivelul cel mai de sus, modulele au funcii orientate spre problema de rezolvat, n
timp ce modulele aflate pe nivelurile mai de jos au funcii orientate spre prelucrrile 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 funciei
ndeplinite.
La atribuirea numelui unui modul trebuie s se in cont de faptul c acesta trebuie
s surprind att funcia proprie, ct i pe cele ale subcomponentelor de ordin inferior. Se
recomand [1] evitarea conjunciilor din structura numelor, deoarece ele ar sugera
necesitatea folosirii mai multor module.
139
Logica modulului descrie prelucrrile care au loc n interiorul acestuia [1].
La nivelul programrii, preocuparea este, n esen, legat de logica modulului,
algoritmii de prelucrare, redai sub diverse forme scheme logice, pseudocod, tabele de
decizie, arbori de decizie sau combinaii ale acestora sunt concepui pentru prezentarea
modului de transformare a intrrilor n ieiri. Paii algoritmilor se vor transforma n
instruciuni ale limbajelor de programare.
Interfeele sunt conexiuni sau cuplaje ntre module. Interfeele modulelor sunt
utilizate pentru stabilirea cilor prin care s se transfere controlul de la un modul la altul
[1].
Conexiunile dintre module se nregistreaz pe dou planuri:
- al transferrii controlului de la un modul la altul;
- al transmiterii datelor de la un modul la altul.
n concluzie, se poate spune c eficiena proiectelor soft depinde n mare msur
de eficiena cu care se transfer controlul ntre module, precum i de metoda folosit
pentru transmiterea datelor ntre module.

5.2.2. Structurile de control ale programelor
Proiectul soft trebuie s fie vzut [1] din dou puncte de vedere: logic i fizic.
Din punct de vedere logic, modalitatea n care intr n funciune modulele este
redat prin structura ierarhic a lor.
Din punct de vedere fizic, dup ce s-a stabilit structura logic, se va pune problema
adaptrii prelucrrii lor pe calculator, moment n care se va avea n vedere structura
execuiei instruciunilor, adic a secvenelor dup care se declaneaz operaiunile 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: secvena, selecia, iteraia sau repetiia. Ele mai sunt cunoscute
i sub numele de structur secvenial, structur alternativ (simpl i generalizat i
140
structur repetitiv (condiionat anterior sau la nceput i condiionat posterior sau la
sfrit ).
Secvena asigur parcurgerea instruciunilor n ordinea n care apar. Selecia
definete alegerea unui grup de instruciuni din dou sau mai multe posibile. Iteraia ofer
posibilitatea execuiei repetate a unui grup de instruciuni.
n elaborarea programelor structurate este necesar s se respecte o serie de
restricii, i anume [1]:
- fiecare element (secvena, selecia, iteraia) are un punct de intrare;
- fiecare element are un punct de ieire unic;
- elementul de iteraie permite i o execuie cu factor de repetiie zero, adic
excluderea elementului respectiv din execuie.
Fiecare element din cele enunate (secvena, selecia, iteraia) care respect
restriciile de mai sus definete un bloc standard i sunt reprezentate n continuare [1].
Structura secvenial (liniar) se prezint astfel:












Selecia (structura de tip IF-THEN-ELSE) sau structura alternativ are urmtoarea
form de prezentare:








i1
i2
in
Figura 5.5. Structura secvenial
C
Bloc - 2
Bloc - 1
NU
DA
Figura 5.6. Structura alternativ
141



Dac se ndeplinete condiia C, se execut operaiile din Bloc-1, altfel se execut
operaiile din Bloc-2. Dup execuia blocului, se continu cu instruciunea urmtoare.
Structura alternativ generalizat (de tip CASE-OF) este o generalizare a
seleciei. Ea permite alegerea unei variante din mai multe posibile (figura 5.7).
















Iteraia sau structura repetitiv definete execuia repetat a unei operaii sau grup
de operaii, funcie de rezultatul evalurii unei condiii. Evaluarea condiiei se face fie
nainte, fie dup executarea operaiilor.
Structura repetitiv condiionat anterior (de tip WHILE-DO) este reprezentat n
figura 5.8















C
Bloc - n
Bloc - 2 Bloc - 1
Figura 5.7. Structura alternativ generalizat
C
Bloc - 1
DA
NU
Figura 5.8. Structura repetitiv condiionat anterior
142



Structura repetitiv condiionat posterior (de tip DO UNTIL) are forma din figura 5.9.




















O form particular de structur repetitiv condiionat posterior este structura
repetitiv cu numr definit de pai (de tip DO FOR). Numrul de repetiii este controlat
de o variabil, numit variabil de control. n reprezentarea grafic urmtoare, V este
variabila de control, Vi este valoarea iniial a variabilei de control, iar R este raia
(incrementul). O astfel de structur este redat n figura 5.10.

















C
Bloc - 1
DA
NU
Figura 5.9. Structura condiionat posterior
V>Vf
V=Vi+R
DA
NU
Bloc - 1
V=Vi
Figura 5.10. Structura repetitiv cu numr definit de pai
143



n literatura de specialitate, se consider c structura secvenial, structura
alternativ de tip IF-THEN-ELSE i structura repetitiv condiionat anterior sunt
suficiente pentru a defini structura de control a oricrui 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 cerine i
restricii impus de etapele parcurse anterior pentru realizarea sistemului informatic.
Urmnd principiile programrii structurate, realizarea programelor se face n urmtoarele
faze [2]: definirea problemei de programat; descompunerea problemei de programat;
realizarea modular a produselor program; testarea top-down a produselor program;
definirea programului testat i a documentaiei aferente; dezvoltarea versiunii calitative a
produsului program.
Specificaiile elaborate n etapele precedente permit definirea problemei de
programat prin care se formuleaz elementele specifice i se analizeaz relaiile dintre
aceste elemente, din punct de vedere dinamic sau static.
Descompunerea aplicaiei se poate face dup criteriul funcionalitii, motiv pentru
care elementele rezultate se mai numesc i module funcionale. Din punct de vedere al
fluxului datelor pot fi [2]:
- module de intrare, care manipuleaz datele de intrare;
- modulele de ieire, care furnizeaz rezultate ale prelucrrilor;
- module de prelucrare, care efectueaz diverse operaii asupra datelor.
144
Pe baza unor funciuni identificate sau a altor raiuni de programare, modulele pot
fi divizate n continuare. Scopul acestei structurri funcionale pn la nivel elementar
este de a identifica funciunile sistemului i de a le separa, eventual, n funciuni generale
i cu caracter specific aplicaiei.
Modulele funcionale pot fi descompuse apoi dup criteriul omogenitii, rezultnd
modulele operaionale.
Realizarea modular a produselor program presupune urmtoarele aciuni [2]:
- Examinarea modulelor i specificarea succesiunii operaiilor de prelucrare
descrise n acestea.
- Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere
ntreaga cazuistic a sistemului informaional i s testeze toate ramurile
programului.
- Precizarea elementelor de comunicaie ntre module, respectiv stabilirea
parametrilor de intrare/iesire n/din fiecare modul.
- elaborarea algoritmii de prelucrare specifici fiecrui modul i structura
programelor.
- transcrierea algoritmilor ntr-un limbaj de programare.
- scrierea codului surs i obinerea fiierelor executabile.
Prin compararea rezultatelor propuse a fi obinute cu cele efectiv furnizate de
aplicaia informatic, sunt verificate sintactic i funcional module din program. Dac se
realizeaz identitatea ntre cele doua categorii de rezultate, operaia de testare se consider
ncheiat.
O atenie deosebit trebuie acordat ntocmirii documentaiei programului cu
observaia c n acest sens este recomandat autodocumentarea la nivel de modul.

5.3. Proiectarea sistemelor distribuite
Un sistem de prelucrare distribuit a datelor presupune existena a dou sau mai
multor sisteme independente de prelucrare a datelor, numire noduri, interconectate ntr-o
configuraie de reea. Ele folosesc faciliti de comunicare pentru schimbul de informaii
145
i i coordoneaz activitile pentru realizarea unui anumit scop. Un sistem de prelucrare
distribuit a datelor permite realizarea activitii de prelucrare automat a datelor n
cadrul unei reele de calculatoare. ntr-un astfel de mediu, coopereaz trei componente
tehnologice distincte: prelucrarea datelor, comunicarea datelor i reeaua de calculatoare.
Scopul lor este de a colabora fiecare cu fiecare, astfel nct s se realizeze obiectivele
comune ale organizaiei [1].







Sistemele de prelucrare distribuit a datelor trebuie s permit:
- posibilitatea de prelucrare independent;
- o configuraie de reea;
- o posibilitate de transfer a datelor folosind faciliti 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
funcionale. Din punct de vedere financiar se urmrete maxim de profit cu minimum de
cheltuieli, iar din punct de vedere funcional se urmrete realizarea unui sistem
performant.
Costul sistemului se regsete n costurile iniiale pe procesoare, periferice
(imprimant, scanner, etc), cablri, soft-uri, i costuri funcionale (operaionale) cu
distribuirea datelor, cu personalul, ntreinerea sistemului, etc.
Performana sistemului este apreciat prin prisma productivitii i a eficienei lui.
Ea se determin n funcie de cerinele operaionale ale unui sistem de calcul. Se
consider c performana este o funcie a [1]:
- timpului de rspuns(intervalul de timp dintre momentul formulrii unei cereri
de la un terminal de comunicaie-date i obinerea rspunsului n acelai loc);
NOD
NOD
Legtur/canal
Figura 5.11. Model de baz al unui sistem de prelucrare distribuit a datelor.
146
- randamentului(cantitatea de date ce poate fi prelucrat de ctre un sistem de
calcul ntr-o perioad de timp);
- calitii 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 prelucrrii automate a datelor i a comunicaiilor din sistem.
Performanele sistemului sunt influenate de mai muli factori, cum ar fi timpul de
rspuns, randamentul, disponibilitatea, sigurana(securitatea sistemului).
La proiectarea sistemelor distribuite trebuie avute n vedere dou componente
majore:
- Proiectarea nodurilor;
- Proiectarea reelei de comunicaii.
Ordinea de proiectare nu este strict rmnnd la latitudinea echipei de proiectare.



















Modele de sisteme distribuite
Calculatoarele personale i staiile de lucru pot fi utilizate fie ca sisteme de-sine-
stttoare pentru execuia diferitelor aplicaii informatice, fie ntr-o configuraie de reea.
O reea local se bazeaz pe un set de calculatoare personale, fiecare cu propria memorie,
Sisteme PAD
Proiectare NODURI
Proiectare subsisteme
de COMUNICAII
Proiectare
INTERFEE
Figura 5.12. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor

147
astfel nct s poat folosi n comun toate echipamentele i software-ul din reea. Dintre
toate calculatoarele, exist unul sau unele mai puternice pe care se vor afla aplicaii
folosite n comun de celelalte calculatoare ale reelei. Cea mai utilizat arhitectur este
arhitectura client/server.

Arhitectura client/server
Modelul Client /Server ofer date distribuite, portabilitate ntre platforme i un
acces standardizat la resurse. Termenul de Client /Server provine de la metoda
tradiional de accesare a unui computer central numit server de ctre computere aflate la
distan sau clieni ntr-o infrastructur de reea.
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 informaie (baze de date), s efectueze
procesri asupra datelor, s controleze periferice sau s efectueze cereri adiionale altor
servere. Un client poate face cereri la multiple servere i un server poate deservi mai muli
clieni.

Surs de informaie (Baz de date)
Cerere Procesare (Logic i Aritmetic)
Client Server Dispozitive (Imprimant, periferice partajate)
Rezultatul Servicii(Cereri adiionale altor servere)
ndeplinirii cererii

Figura 5.13. O tranzacie Client /Server.

Se poate afirma c tehnologia client / server mparte o aplicaie n trei componente
de baz: un client, un server i o reea care conecteaz clientul la server. Att clientul ct
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. Cnd se alege un server pentru
148
mediul de lucru client / server trebuie avute n vedere: scalabilitatea posibilitatea de
cretere a capacitii serverului, n limite rezonabile; tolerana la erori posibilitatea de
recuperare a contextului calculatorului server dup producerea unei disfuncionaliti
hardware; service i asisten tehnic. Calculatoarele server au utilizri variate n
sistemele client / server (exist servere de fiiere care asigur spaiul de disc centralizat
care poate fi folosit conform necesitilor calculatoarelor client din reea; servere de
tiprire care colecteaz informaiile ce urmeaz a fi trimise ctre imprimant de ctre
calculatoarele client i le asigur tiprirea 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 aplicaii calculatoare server care ruleaz programe de aplicaii).
Sistemele client-server au aprut ca urmare a descentralizrii activitii din diverse
domenii, ceea ce presupune o repartizare a realizrii sarcinilor pe cele dou nivele: client,
server. De obicei clienii reprezint utilizatorii finali care vor comunica cu serverul bazei
de date n cadrul unei reele 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 zvoarelor, efectuarea operaiilor n memoria
secundar, securitatea, integritatea i recuperarea bazei de date, executarea
procedurilor stocate i optimizarea interogrilor. Clientul este responsabil de
administrarea tranzaciilor i realizarea interfeei cu limbajul de programare;
- arhitectura de tip server de pagini cea mai mare parte a prelucrrilor este
realizat de ctre client. Serverul este responsabil de memoria secundar i
furnizeaz paginile corespunztor cererilor formulate de client;
- arhitectura de tip server de baz de date cea mai mare parte din prelucrrile
bazei de date este efectuat de ctre server. Clientul transmite cererea
serverului, primete rezultatele i le transmite aplicaiei. Este modul utilizat
frecvent de ctre sistemele relaionale.
149
n fiecare dintre cele trei cazuri serverul se gsete pe aceeai main ca i baza de
date fizic. Clientul se poate afla pe aceeai main sau pe una diferit. n cazul bazelor
de date distribuite pe mai multe maini, clientul va comunica cu cte un server de pe
fiecare main. De asemenea mai muli clieni pot comunica concomitent cu acelai
server (accesul concurent).
Arhitectura tradiional a sistemelor client-server este o arhitectur pe dou nivele
(etaje), n care la primul nivel (clientul) se realizeaz interfaa cu utilizatorul i logica
principal a aplicaiei, iar la al doilea nivel (serverul) se realizeaz validarea datelor i
accesul la baza de date. Necesitatea rezolvrii unor probleme complexe care presupun
accesul la baza de date a unui numr 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 interfaa cu utilizatorul aplicaiei;
- nivelul server de aplicaie, la care se realizeaz logica aplicaiei i prelucrrii
datelor;
- nivelul server de baze de date, la care se realizeaz validarea datelor i accesul
la baza de date.
Un server de aplicaie poate servi mai muli clieni, fiind conectat fizic att la
nivelul client ct i la nivelul server de baze de date. Spre exemplu n mediul Web,
clientul poate fi un browser Web, iar serverul de aplicaie poate fi un server Web.

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;
Rspuns : a
2. Proiectarea fizic a sistemelor informatice implic:
a) proiectarea fizic a bazelor de date i a fiierelor.
b) proiectarea structurii sistemului i a programelor.
150
c) proiectarea documentaiei sistemului analizat.
d) proiectarea strategiilor de prelucrare distribuit.
Rspuns : a, b, d
3. Proiectarea fizic a bazelor de date i a fiierelor 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.
Rspuns : a
4. Sunt structuri de control fundamentale n realizarea programelor:
a) structura secvenial;
b) structur funcional;
c) structura alternativ;
d) structura organizaional:
e) structura repetitiv.
Rspuns : a, c, e
5. Structura repetitiv de baz condiionat anterior este:
a) de tip WHILE-DO;
b) de tip DO UNTIL;
c) de tip DO FOR.
Rspuns : a
6. Nu sunt metode de programare:
a) metoda programrii clasice;
b) metoda programrii structurate;
c) metoda programrii orientate-obiect;
d) metoda programrii iterative.
Rspuns : d
7. Un modul are componente de baz:
a) funcia;
b) schema;
c) logica;
d) interfeele.
Rspuns : a, c, d
8. Funcia unui modul const n:
a) transformarea datelor prin procesul de execuie a acestuia.
b) descrierea prelucrrilor care au loc n interiorul acestuia.
c) legtura cu alte module.
151
Rspuns : a
9. Realizarea modular a programelor corespunde principiilor:
a) programrii clasice;
b) programrii structurate;
c) bazelor de cunotine;
Rspuns : b
10. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor sunt:
a) proiectarea nodurilor;
b) proiectarea diagramelor;
c) proiectarea reelei de comunicaii.
Rspuns : a, c
11. Nu sunt componente de baz ale tehnologiei client/server:
a) clientul; b) administratorul de sistem;
c) serverul; d) reeaua care conecteaz clientul la server.
Rspuns : b
12. Care dintre urmtoarele instruciuni 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.
Rspuns : a
13. Care dintre urmtoarele instruciuni repetitive sunt condiionate posterior ?
a) FOR...NEXT ;
b) WHILE...WEND ;
c) DO WHILE...LOOP;
d) DO UNTIL...LOOP;
e) DO...LOOP WHILE.
Rspuns : e
14. 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.
Rspuns: a), b)
15. Sistemul de Gestiune a Bazelor de Date este:
a) un sistem de programe care permite definirea, crearea i ntreinerea bazei de date
precum i accesul controlat la baza de date;
b) un sistem de programe pentru interogarea bazei de date.
Rspuns: a)
152




ntrebri i rspunsuri

1. Enumerai arhitecturile de baz pentru un sistem client-server dup rolul pecare l
au componentele client i server;
Rspuns:
- arhitectura de tip server de obiecte;
- arhitectura de tip server de pagini;
- arhitectura de tip server de baz de date.

2. Enumerai cele 3 nivele ale noii arhitecturi client-server definite ca urmare a
utilizrii a unor platforme hard-soft diferite, precum i integrrii bazelor de date n
mediul Web:

Rspuns:
- nivelul client, la care se realizeaz interfaa cu utilizatorul aplicaiei;
- nivelul server de aplicaie, la care se realizeaz logica aplicaiei i prelucrrii
datelor;
- nivelul server de baze de date, la care se realizeaz validarea datelor i accesul
la baza de date.
153
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 pregtirea proiectrii unui
sistem, incluznd aici dicionarul datelor, fluxul de date, relaiile ntre entiti, un software
de tip CASE poate determina o cretere 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 facilitnd reprezentarea grafic n cadrul acestor etape.
Dei 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 faciliti. Un instrument CASE realizeaz n primul rnd
legtura ntre modelul utilizator i modelul logic ce formalizeaz modelul utilizator
folosind un mod de reprezentare comun att acestuia ct i proiectantului bazei de date.
Un instrument de tip CASE nu elimin ns posibilitatea ca modelul final obinut
s fie proiectat greit. n scopul evitrii acestei situaii este necesar o pregtire 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 aceleai
principii i au relativ aceleai faciliti. Dac ns utilizatorul este nou n domeniu,
trebuie luat n considerare timpul necesar realizrii unui model i timpul necesar
verificrii acestuia de ctre 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, cnd hardul sa extins prin seria PC-
urilor, iar reelele au devenit mai puternice, constituindu-se sistemele distribuite.
Obiectivul principal al CASE-ului l constituie punerea n practic a produselor-program
154
de proiectare i realizare a softului cu ajutorul calculatorului. Instrumentele oferite de
CASE sunt utilizabile din faza de definire a cerinelor pn la ntreinerea fizic a
produsului informatic. Totui, analiza i proiectarea, bazate pe conceptele i metodele
structurate, reprezint elementele forte ale instrumentelor CASE, iar n ultimii ani CASE
a acordat atenia cuvenit analizei, proiectrii i programrii orientate pe obiecte [1].
Majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea
testrii complete a lor, fiind nsoite de o documentaie destul de slab. Instrumentele
CASE implic utilizarea calculatorului ca un mijloc de susinere a activitilor de
planificare, definire, proiectare i realizare a softului. Ele se bazeaz pe logica structural,
pe descompunerea funcional i reprezentarea prin diagrame a fluxurilor de date ale
aplicaiilor.
Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a ncuraja
abordarea logicii structurate i pentru folosirea calculatorului ca un mod de tezaurizare a
lucrrilor i ca o planet de desen, pe care pot fi plasate reprezentrile structurate ale
sistemelor sau aplicaiilor. Pe msura evoluiei lor, sistemele CASE au devenit mult mai
complexe, permind ca procesele de proiectare i realizare a aplicaiilor s se desfoare
ntr-un mediu informatic interactiv, oferind utilizatorilor un ntreg arsenal de instrumente
i proceduri, prin care pot proiecta, realiza, testa, documenta, ntreine/actualiza i
exploata sistemul.
Utilizarea produselor de tip CASE a fost determinat de [1]:
- calitatea ndoielnic a aplicaiilor realizate n mod tradiional;
- frustrarea utilizatorilor n ncercarea lor de a participa la procesul de proiectare
i realizare a aplicaiilor, datorit nivelului ridicat de cunotine informatice
solicitate de metodele tradiionale;
- costuri deosebit de mari pe care le presupun ntreinerea i actualizarea softului
funcional;
- imposibilitatea rezolvrii tuturor cerinelor utilizatorilor;
- limitarea posibilitii de reprezentare grafic a schemelor de realizare a noilor
proiecte.
155
Folosirea sistemelor CASE este motivat i de urmtoarele avantaje:
- reducerea complexitii logicii de descriere a sistemului;
- posibilitatea de a alege dintre mai multe variante de proiectare;
- creterea vitezei de realizare a sistemelor;
- realizarea succesiv a componentelor unui sistem;
- creterea integrrii;
- consolidarea disciplinei de proiectare;
- oferirea unei interfee de proiectare;
- folosirea depozitelor modularizate;
- salvarea i refolosirea unor componente din diagramele realizate;
- simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor.
Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de
date, care fac posibil realizarea unui model al derulrii proceselor sistemului/aplicaiei
care se proiecteaz. A urmat folosirea dicionarului de date ca un depozit al tuturor datelor
privind sistemul sau aplicaia. Au aprut ecranele predefinite pentru a prezenta ce poate s
obin utilizatorul prin exploatarea sistemului. S-a apelat la facilitile grafice, care pot
folosi simbolurile logicii structurate i care permit proiectantului s realizeze o diagram
coerent a fluxurilor de date.

6.1. Funciile CASE
Primele sisteme CASE erau un set de aplicaii neintegrate, cu funcii distincte, fr
a fi interconectate. Aceste limite au fost eliminate, n cea mai mare parte, prin generaiile
actuale, care ncearc s realizeze o integrare complet i uoar a tuturor elementelor,
integrarea reprezentnd, de fapt, factorul cel mai important al metodologiei CASE.
CASE se bazeaz pe dou funcii fundamentale [1].
Prima funcie const n posibilitatea descompunerii de sus n jos (top-down) a
sistemului informatic n procese i module distincte, fiecare avnd definite
responsabilitile funcionale i/sau operaionale.
156
Cea de-a doua funcie se refer la faptul c sistemele informaionale pot fi
reprezentate ntr-o form grafic concis, folosind cteva simboluri de baz. Importana
acestor dou funcii rezid n posibilitatea utilizrii modularitii aplicaiilor, a
diagramelor, obinerea unei documentaii 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 documentaii, care
include i integreaz caracteristicile proceselor i paii de parcurs, pentru descrierea
modului de lucru; ofer un model al produsului final, ce poate fi folosit n realizarea
operaiilor de exploatare i ntreinere a sistemului/aplicaiei, i ofer o interfa pentru
pstrarea evoluiei proiectului.
Folosirea reprezentrilor grafice n logica CASE ofer posibilitatea descompunerii
aplicaiei n mai multe componente logice. Prin ataarea unei baze de date la elementele
grafice, se va obine un depozit ce va conine paii i funciile 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/aplicaiei. Modelarea
grafic n sistemele CASE prezint o interactivitate ridicat, permind construirea
diagramelor, deplasarea de la o diagram la alta, modificarea, extinderea, copierea,
evaluarea i descrierea elementelor unei aplicaii.
Modelele grafice permit conectarea fluxurilor logice ntre activitile i funciile
specifice aplicaiei, relaii care pot fi testate i validate n mod automat.

6.2. Trsturi definitorii ale CASE-ului
Evoluia instrumentelor CASE a determinat apariia I-CASE (Integrated CASE)
care se refer la toate aspectele integrrii, chiar dac sistemele sunt deschise sau nu.
Caracteristicile mediilor moderne de tip CASE [1]:
- un set de instrumente specifice pentru realizarea sistemelor;
- diversitatea modurilor de interaciune;
157
- semnificaia reprezentrilor grafice;
- elemente de tip verificare i validare (V&V);
- natura bidirecional, deplasri pe vertical n structura sistemului;
- deschidere pentru interconectarea instrumentelor CASE;
- sprijin pentru lucrul cu utilizatori multipli;
- descompunerea;
- performane 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 urmresc realizarea ciclului de via al unui sistem. La sfritul fiecrei
faze a ciclului de via, rezultatele obinute trebuie supuse unei analize i verificri, iar
utilizatorii trebuie informai asupra modului de gestionare a procedurilor de lucru. Ei sunt
cei care trebuie s dea avizul de continuare a parcurgerii fazelor urmtoare, pe baza a ceea
ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite n
proiectarea sistemului i a modelului proiectat pe msura desfurrii operaiunilor, din
faza de proiectare pn la predarea produsului final. CASE poate sprijini aceste proceduri
prin punerea la dispoziie a unei documentaii a modelului proiectat. Pe acest fond, pot fi
fcute evaluri, critici sau modificri asupra elementelor din modelul proiectat.
Rezultatele obinute n urma proiectrii unui anumit model de sistem constau n
documentaia oferit, care acoper ntregul ciclul de via al sistemului, cu toate operaiile
i procedurile pe care le presupune. n plus, CASE ofer posibilitatea de a analiza ieirile
obinute i de a le modifica pentru a reflecta schimbrile intervenite n sistem, modulele
definite i depozitul de date.

6.3. Tipuri de instrumente CASE (Conferina Naional de nvmnt Virtual, ediia a
III-a, 2005)
n literatura de specialitate, instrumentele CASE sunt clasificate i dup un alt
criteriu dect cel al activitilor din ciclul de via al sistemelor pe care le sprijin. Acest
158
criteriu se refer la metodologia pe care o ncorporeaz pentru realizarea sistemelor.
Astfel, se ntlnesc urmtoarele trei categorii:
- instrumente CASE bazate pe metodologia structurat;
- instrumente hibride, ce conin elemente specifice orientrii-obiect, dar care nu
permit realizarea sistemelor orientate-obiect;
- instrumente pur orientate-obiect.
n cele ce urmeaz se vor prezenta cteva 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. Avnd 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 documentaiei de realizare a sistemului informatic.
Repository este componenta central a arhitecturii Westmount I-CASE Yourdon.
Repository este implementat cu ajutorul unui SGBD relaional: 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 aplicaiei este strns legat de proiectarea bazei de date.
Pentru modelarea datelor se utilizeaz diagrama entitate asociere.
159
Programmer este mediul de programare care ofer suport pentru generarea
codului surs, compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod
translateaz specificaiile de proiectare n cod surs. Astfel, pe baza diagramei entitate
asociere se genereaz codul DDL (n SQL) ce definete structura fizic a bazei de date.
Codul poate fi completat pentru a defini restriciile 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
aplicaiei este generat n limbajul C mbogit cu instruciuni SQL pornind de la
specificaiile din schemele de structur.
Docwriter este componenta care permite generarea documentaiei pentru fiecare
etap de realizare a sistemului.
Utilizarea produsului Westmount I-CASEY Yourdon mbuntete productivitatea
realizrii sistemelor informatice i ofer garanii pentru calitatea sistemelor obinute.

B) Metodologia orientat-obiect
Expresia pur orientate-obiect" se refer la faptul c pe de o parte, instrumentele
CASE conin numai elemente specifice abordrii 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 convenionale, astfel:
- Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor;
- Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor;
- I-CASE orientat-obiect care acoper ntregul ciclu de via.
Tendina de utilizare mai accentuat a tehnologiilor informaionale orientate-obiect
a condus la apariia a numeroase produse CASE orientate-obiect sau la reorientarea
firmelor productoare de instrumente convenionale spre nglobarea n produsele lor a
elementelor specifice abordrii obiectuale.


160
6.4. Exemple de instrumente CASE
Un posibil dezavantaj al utilizrii 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 att timp ct modelul obinut este
correct i poate fi ntreinut cu uurin. 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 avnd la dispoziie modelul) i
capturarea metadatelor (posibilitatea de definire a datelor). Se va demonstra aceast
afirmaie exemplificnd cu ajutorul mai multor instrumente, dintre care cel mai
performant, conform opiniei generale, este AllFusion Erwin Data Modeler.
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 att modelarea logic ct
i modelarea fizic. Cteva dintre avantajele utilizrii acestui program:
- mediu de modelare simplu de utilizat;
- este posibil partajarea i reutilizarea modelelor odat create;
- utilizarea Erwin reduce timpul de proiectare datorit crerii automate a
modelului fizic;
- mbuntete exactitatea modelului datorit posibilitii de sincronizare a
modelului cu baza de date fizic;
- ERwin pune la dispoziia utilizatorului o facilitate important numit forward
engineering care permite conversia diagramei ER n cod SQL corespunztor
bazei de date modelate;
- reverse engineering facilitate care permite crearea unui model pe baza
schemei unei baze de date existente n prealabil.
161
Erwin Data Modeler permite utilizarea modelelor complexe prin mprirea lor n
submodele mai uor de gestionat. Modelele realizate pot fi vizualizate, modificate i
tiprite la imprimant n multiple moduri. RPTwin este o component nglobat n Erwin
care permite realizarea de rapoarte i conine un set de rapoarte predefinite i de asemenea
ofer posibilitatea realizrii 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 interfeei utilizator ERwin sunt plasate bara de meniuri i
bara de instrumente (toolbar) care permit selectarea unor opiuni din meniuri, respectiv
accesarea mai rapid a unora dintre aceste opiuni prin apsarea butoanelor
corespunztoare.
Fereastra de explorare a modelului (Model Explorer Pane) permite, prin
intermediul unor elemente grafice, construirea modelului prin inserarea de entiti,
domenii, relaii, reguli de validare, etc.
162
AllFusion Erwin Data Modeler suport trei tipuri de modele pentru proiectarea
bazelor de date:
Logic: Model conceptual (global) care include entiti, relaii i atribute, eseniale
obinerii unui model Entitate Relaie.
Fizic: Model detaliat care implic specificarea tabelelor, atributelor i a tipului de
date asociat.
Logic/Fizic: Un model care nglobeaz att modelul fizic ct i modelul logic.
Pentru a crea un model, se alege opiunea New din meniul File. Fereastra Create
Model este prezentat n figura 6.2.

Figura 6.2. Fereastra de creare a unui nou model
Aceast 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 apsarea butonului Browse File System i alegerea fiierului respectiv.
163
Formatul bazei de date se alege din seciunea 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
execut click dreapta pe numele modelului din fereastra Model Explorer i se alege
opiunea Properties. Redenumirea se realizeaz prin introducerea noului nume n cmpul
Name, figura 6.3.

Figura 6.3. Redenumirea modelului
Crearea modelului continu cu inserarea atributelor. Din fereastra Diagram
Windows se execut dublu click pe entitatea care se va popula cu atribute i se alege
opiunea New. Se va afia 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.
164
ERwin suport trei tipuri de relaii: cu identificare, fr identificare i many to
many. ERwin clasific entitatea copil ntr-o relaie cu identificare slab (weak). Pentru
adugarea unei relaii se execut click dreapta pe elementul Relationship din Model
Explorer i se alege opiunea New. Se va afia fereastra din figura 6.5.

Figura 6.5. Adugarea unei relaii noi
O relaie cu identificare semnific faptul c una dintre entitile relaiei este entitate
dependent, adic una dintre entiti este, pentru a se identifica, cel puin parial
dependent de cealalt entitate. Entitatea copil nu se poate identifica fr a se utiliza cel
puin cheia primar a entitii printe. ntr-o relaie fr identificare, entitatea copil nu are
nevoie pentru identificare de cheia primar a entitii printe. Entitatea copil trebuie s
conin ns obligatoriu cheia primar a entitii printe. O relaie de tip fr identificare
este simbolizat prin linie punctat.
Dup alegerea celor dou entiti aflate n relaie i apsarea butonului OK, noua
relaie este adugat i este figurat grafic printr-o linie (punctat sau continu,
corespunztoare tipului relaiei) ce unete cele dou entiti. O relaiei many to many este
simbolizat printr-o linie continu cu dou puncte negre la ambele capete. Dup crearea
relaiei, utilizatorul poate aduga o descriere a acesteia prin executarea unui click dreapta
pe relaie i accesarea opiunii Properties. n final, dup realizarea tuturor operaiilor se
obine un model fizic ce poate fi ulterior folosit pentru forward engineering, figura 6.6.
165
Erwin permite, prin intermediul opiunii Forward Engineering, convertirea
diagramei entitate relaie n cod SQL, generndu-se astfel schema bazei de date.
Scriptul SQL din figura 6.7 este obinut pentru modelul StocProd de gestionare a
depozitrii i vnzrii produselor n cazul unui hipermarket.

Figura 6.6. Model fizic al unei baze de date.

















Figura 6.7. Script SQL generat prin forward
166

Microsoft Visio 2007
Microsoft Visio permite crearea unui mare numr 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 avnd
capaciti avansate de Inginerie invers i un mai mare numr 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).
Fereastra Microsoft Visio Professional este prezentat n figura 6.8.

Figura 6.8. Interfaa Microsoft Visio 2007.
abloanele sunt grupate pe categorii i afiate n banda din partea stng a ferestrei
aplicaiei. Procesul de creare a modelului unei baze de date poate ncepe prin selectarea
ablonului corespunztor din categoria Database Model Diagram sau cu importarea unui
model deja creat n Erwin Data Modeler, figura 6.9.
Opiunea Reverse Engineering din meniul Database permite importul bazelor de
date Oracle, DB2, SQL, Access i generarea modelului Visio corespunztor. Un program
167
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 urmtoarelor
etape:
a) Crearea modelului ORM (Object Role Model) care permite crearea unui model
intuitiv al bazei de date (stabilirea entitilor, a atributelor acestora, evidenierea
relaiilor dintre entiti).
b) Generarea automat a modelului logic pe baza modelului ORM
c) Generarea modelului fizic pe baza modelului logic obinut anterior
Interfaa de creare a tabelelor (entitilor) este similar cu aceeai interfa din
programul Microsoft Access cu deosebirea c, n cazul Visio, tabelele pot fi portabile
independent de sistemul de gestionare a bazelor de date.
.
Figura 6.9. Opiunile 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
168
apariia unor erori care vor fi afiate n fereastra de afiare a rezultatelor. Cele mai
comune tipuri de erori pot aprea n urmtoarele dou situaii:
- dou sau mai multe relaii au acelai nume;
- coloanele cu aceeai denumire din tabele diferite sunt diferite din punct de
vedere al tipului datelor.
Pentru a genera baza de date se selecteaz din meniul Database opiunea Generate.
Se va lansa automat validarea modelului i se poate opta pentru generarea unui script
DDL ce conine comenzile SQL corespunztoare generrii fiecrei tabele i relaii din
baza de date. Este util selectarea opiunii Store current database image in model pentru
ca modificrile ulterioare aduse bazei de date s determine doar o adugare a acestora i
nu crearea de la zero a bazei de date modificate. n final Visio va genera entitile,
indecii i relaiile bazei de date. Rezultatul acestei cod va fi afiat n fereastra de afiare a
rezultatelor. Ca ultim etap, se recomand o verificare a codului respectiv, ntruct pot
aprea erori. Visio 2007 permite salvarea sub form de pagin Web a modelelor realizate.
Diagramele ER se pot salva n diverse formate grafice cu scopul utilizrii ulterioare n
documentaiile diverselor proiecte.
Toad data modeler
Toad Data Modeler export diagramele ER n format HTML, RTF sau n format
imagine (.jpg sau .bmp). Atuurile acestui program sunt urmtoarele:
- posibilitatea de a creea diagrame ER pentru diverse sisteme de gestionare a
bazelor de date;
- ingineria invers;
- adugarea de date suplimentare n diagramele ER pentru a mbunti
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 modificrilor cu ajutorul Version Manager-ului;
169
- 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
opiunea 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 nti 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 opiunea
Reference din meniul Tools i se selecteaz DAO 3.6 libraries for MS Access 2000 i se
lanseaz n execuie modulul din opiunea Run. Din meniul Model, opiunea Insert se
insereaz toate elementele grafice ale modelului: entiti, atribute i diverse tipuri de
relaii. Dac se dorete modificarea tipului unei relaii create n prealabil, se execut click
dreapta pe relaia respectiv i se alege opiunea Edit Relationship. Se va afia fereastra
din figura 6.10.

Figura 6.10. Modificarea unei relaii.
170
Este posibil astfel redenumirea relaiei, modificarea tipului acesteia, inserarea
unei scurte descrieri, etc. Pentru a obine o imagine de ansamblu asupra bazei de date, se
va accesa opiunea Project Explorer din meniul Model. Se va afia structurat lista cu
entitile existente, atributele, relaiile i indecii utilizai, figura 6.10. n final se valideaz
modelul i se remediaz eventualele erori selectnd opiunea 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 folosete diverse metode de
comunicaie printre care, atunci cnd este posibil i comunicaia nativ.
Opiunea 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.

Figura 6.10. Afiarea structurat a modelului. Fereastra Model Explorer
171

Figura 6.11. Opiunea Reverse Engineering.
Embarcadero ER/Studio
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 restricii de securitate referitoare la accesul la modelul respectiv. Nu este
permis accesul la un submodel fr ca, n prealabil, accesul la modelul principal s fie
permis. Opiunea New din meniul File determin activarea ferestrei din figura 6.12.

172

Figura 6.12. Opiunile disponibile pentru crearea unui nou model n ER/Studio
Dup 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 fiiere 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 opiuni se lanseaz un wizard care va
afia o list cu tipurile de baze de date compatibile i care vor fi ulterior transformate n
modele logice sau fizice. Obiectele asupra crora se poate aplica procesul inginerie
invers sunt: tabelele i vederile, tabelele definite de utilizator, procedurile i funciile
memorate. Se detecteaz de asemenea automat integritatea n cazul n care nu este
declarat explicit n baza de date. ER/Studio va mpri elementele capturate dintr-o baz
de date n dou categorii, corespunztoare modelului logic i modelului fizic. Prin
vizualizarea modelului logic, utilizatorul poate vizualiza proprietile asociate unei tabele,
cum ar fi atributele, relaiile i eventualele restricii. Programul nu elimin restriciile
legate de cheia strin declarate explicit ci va semnala o cheie strin prin afiarea
simbolului FK lng aceasta.
ER/Studio permite crearea diagramelor entitate relaie n totalitate pornind de la
zero sau obinerea acestora cu ajutorul facilitii inginerie invers. Produsul scaneaz
bazele de date i ajut utilizatorii n eliminarea redundanelor prin extragerea metadatelor.
173

Figura 6.13. Interfaa utilizator ER/Studio
Oracle Designer
Setul de instrumente Designer/2000 este parte integrant din portofoliul de
instrumente de dezvoltare oferit de Oracle i reprezint o soluie integrat pentru
dezvoltarea de sisteme client/server din generaia a doua sau de sisteme Intranet bazate pe
Web. Designer/2000 acoper toate fazele ciclului de dezvoltare a aplicaiilor software,
pornind de la modelarea sistemului informatic (business modelling) pn la exploatare.
Abordarea Designer/2000 bazat pe un Repository permite ca anumite componente sau
toate componentele s fie folosite pentru dezvoltarea rapid de aplicaii scalabile, multi-
platform, distribuite.
Oracle Designer ofer instrumente de modelare i de dezvoltare care permit
utilizatorilor s urmreasc anumite metode de proiectare. Astfel, Oracle Designer
174
permite utilizatorilor s utilizeze metodologia SLDC (System Development Life Cycle)
sau metode iterative gen SSADM (Structured System Analysis and Design Methodology).

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 relaie, a diagramelor ierarhiei funcionale 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 conine 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 informaiile
ce pot fi accesate de ctre ali utilizatori. Acest fapt permite proiectanilor s lucreze
simultan la aceeai aplicaie i toate modelele sunt imediat disponibile celorlaltor
utilizatori. Un alt avantaj al acestei centralizri este cel generat de faptul c toat
informaia este memorat unitar, micorndu-se riscul pierderii sau alterrii acesteia.
175
Depozitul care stocheaz toat informaia pentru instrumentul CASE furnizeaz un
volum mare de documentaie format din detalii referitoare la model (Diagrama ER, de
flux de date) i de comentarii memorate n aplicaii 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 funcii, proceduri sau
triggere. Modulele sunt incluse n alte module PL/SQL ca uniti de subprogram. Cnd
aceste module sunt generate pe baza depozitului, toate subprogramele sunt incluse pentru
a forma codul surs al modulului.
Un alt avantaj al instrumentelor CASE este faptul c scurteaz timpul necesar
obinerii unui model valid. Instrumentele CASE permit proiectarea sistemului i prin
utilizarea unor instrumente de modelare este posibil transformarea acestuia n elemente
palpabile (tabele, chei strine).
Deoarece informaia utilizat de instrumentul CASE este memorat centralizat
ntreinerea sistemului este mai facil.
Din punct de vedere al mentenabilitii, apar urmtoarele avantaje:
- modelele proiectate pot fi actualizate imediat;
- modificrile aplicate asupra modelului pot fi implementate n aplicaie cu
ajutorul instrumentelor specifice ceea ce reduce posibilitatea apariiei unor
erori;
- codul generat poate reflecta doar eventualele modificri aduse asupra tabelelor;
- codul generat este stocat modular astfel nct este posibil modificarea doar a
unui modul i regenerarea modulului modificat.
Teste rezolvate

15. Obiectivul principal al instrumentelor CASE este:
a) Punerea n practic a produselor-program de proiectare i realizare a softului cu
ajutorul calculatorului.
176
b) Simplificarea activitilor de proiectare i realizare a sistemelor/ aplicaiilor.
c) Folosirea depozitelor modularizate.
Rspuns: a
16. Avantajele sistemelor CASE sunt:
a) exploatarea sistemului;
b) creterea vitezei de realizare a sistemelor;
c) realizarea succesiv a componentelor unui sistem;
d) simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor.
Rspuns: b, c, d
17. Instrumentele CASE se bazeaz pe:
a) o funcie fundamental;
b) dou funcii fundamentale;
c) mai multe funcii fundamentale.
Rspuns: b
18. Caracteristicile mediilor moderne de tip CASE sunt:
a) integrarea;
b) aranjarea;
c) descompunerea;
d) exploatarea.
Rspuns: a, c
19. Domeniile ctre care se orienteaz Upper CASE-ul, sunt:
a) analiza cerinelor sistemului;
b) proiectarea i modelarea funcional i procedural;
c) modelarea datelor i proiectarea bazei de date;
d) generarea codurilor.
Rspuns: a, b, c, d
20. Nu sunt corecte urmtoarele afirmaii:
a) CASE reprezint Proiectarea Sistemelor Asistat de Calculator;
177
b) Instrumentele CASE implic utilizarea calculatorului ca un mijloc de susinere a
activitilor de planificare, definire, proiectare i realizare a softului.
c) CASE reprezint Proiectarea Sistemelor cu Ajutorul Calculatorului;
d) CASE reprezint Componente Asamblate ale Sistemelor Economice.
Rspuns: d

ntrebri i rspunsuri

1. Enumerai tipurile de instrumente CASE dup metodologia pe care o ncorporeaz
pentru realizarea sistemelor.
Rspuns:
- instrumente CASE bazate pe metodologia structurat;
- instrumente hibride, ce conin elemente specifice orientrii-obiect, dar care nu
permit realizarea sistemelor orientate-obiect;
- instrumente pur orientate-obiect.

2. Enumerai componentele produsului Westmount I-CASE Yourdon.
Rspuns:
Repository este componenta central a arhitecturii Westmount I-CASE Yourdon.
Repository este implementat cu ajutorul unui SGBD relaional: 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 aplicaiei este strns legat de proiectarea bazei de date. Pentru
modelarea datelor se utilizeaz diagrama entitate asociere.
178
Programmer este mediul de programare care ofer suport pentru generarea codului surs,
compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod genereaz codul
DDL (n SQL) ce definete structura fizic a bazei de date i codul aplicaiei n limbajul C
mbogit cu instruciuni SQL pornind de la specificaiile din schemele de structur.
Docwriter este componenta care permite generarea documentaiei 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:
Rspuns:
Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor;
Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor;
I-CASE orientat-obiect care acoper ntregul ciclu de via.
179
Capitolul 7
Tendine actuale i de perspectiv n evoluia sistemelor informatice

7.1. Concepia sistemic n economie
ncepnd din anii 80, n teoria general a sistemelor apare i se dezvolt o nou
concepie i anume concepia holonic asupra sistemelor. Aproximativ n aceeai perioad
se dezvolt sistemele inteligente, ca structur de baz n domeniul inteligenei artificiale.
Un sistem holonic este [TACU98], [BURA99] un sistem de referin deschis n
cadrul cruia funcioneaz alte sisteme autonome, fiind posibil desprinderea i
ataarea de sisteme autonome att n plan abstract ct i n plan real, iar optimizarea
vizeaz att sistemele componente ct 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, formnd astfel un nou sistem de referin, respectiv sistemul holonic care are
rolul de integrator i care optimizeaz funcionarea i rezultatele obinute de sistemele
ncorporate.
Arhitectura general a unui sistem holonic este reprezentat n figura 7.1
[TACU98], [BURA99].

















SI
S
1

S
2

S
n

.
.
.
INPUTS OUTPUTS
FEEDBACK
Fig 7.1. Arhitectura general a unui sistem holonic
180
Sistemul activitii umane este un tip particular de holon la care se raporteaz
optimizarea tuturor celorlalte sisteme holonice. Realizarea i funcionarea unui sistem
integrator este de neconceput fr utilizarea masiv a tehnologiei informatice.
Concepia holonic asupra sistemelor ofer noi perspective n cercetarea tiinific
i n procesul cunoaterii cu aplicabilitate n diverse domenii, inclusiv n economie, ns
rezultate spectaculoase sunt ateptate n domeniul inteligenei artificiale [TACU98],
[BURA99]. Avnd n vedere aceast concepie precum i impactul utilizrii tehnologiilor
informatice (mai recent a inteligenei artificiale) n management, n domeniul economic
este definit firma holonic [TACU98], [BURA99] i ntreprinderea inteligent
[ANDO01].
O firm holonic se obine prin integrarea a dou sau mai multor companii
autonome ntr-o reea, avnd n vedere cerinele prezente i viitoare impuse de clienii
comuni i standardul produselor/serviciilor realizate de fiecare firm autonom. Concepia
holonic asupra sistemelor poate fi avut n vedere i n cadrul altor organizaii, un
exemplu n acest sens fiind organizaiile administraiei publice locale la nivel teritorial
(consiliul judeean, prefectura, primriile din cadrul judeului).
Schimbrile tehnologice care au avut loc n ultimii ani au condus la o nou gndire
privind ntreprinderea i activitatea sa, cu implicaii majore la nivel organizaional i n
ceea ce privete managementul. Dezvoltarea i utilizarea sistemelor inteligente n cadrul
unei organizaii permite managerilor s foloseasc cunoaterea depozitat pentru
rezolvarea problemelor complexe din cadrul organizaiei i pentru luarea deciziilor
strategice.
Existena reelelor Internet, Intranet, Extranet i a altor reele de telecomunicaii
permite interconectivitatea global i deci manifestarea organizaiilor la nivel planetar. n
condiiile globalizrii, ntreprinderea modern trebuie s satisfac necesitile globale de
afaceri ntr-o societate informaional global astfel nct aplicaii din orice punct de pe
glob s poat accesa i prelucra datele i cunotinele necesare desfurrii activitii
muncitorului cunoaterii.
181
Utilizarea sistemelor inteligente care sunt permanente, nu fac grev, nu solicit
concediu, pot memora, consulta i prelucra volume considerabile de date i cunotine i
pot funciona 24 de ore din 24, asigur o independen a managementului de salariai i
pune la dispoziia managerilor toate cunotinele acumulate asistndu-i n soluionarea
problemelor complexe i luarea deciziilor. Sistemele inteligente ofer posibilitatea
exploatrii cunoaterii prin combinarea potenialului tehnologiei bazelor de date cu
tehnologia bazelor de cunotine i a sistemelor expert, remarcndu-se n acest sens
tehnologia bazelor de date inteligente [ANDO97].
Avnd n vedere aceste aspecte s-a definit ntreprinderea inteligent, ntreprinderea
expert, ntreprinderea bazat pe cunotine [ANDO01], ca fiind acea organizaie n care se
utilizeaz n mod curent sistemele inteligente pentru soluionarea tuturor problemelor
dificile, organizaia care lucreaz inteligent este organizaia care capteaz cunoaterea de
la experii umani, o depoziteaz ntr-o form acceptat de ctre calculator i o folosete cu
ajutorul unor programe specializate la soluionarea problemelor.
ntreprinderile viitorului denumite de McHugh & all [TACU98] firme virtuale, vor
fi propulsate spre succes de o viziune comun, iar managementul se va realiza att prin
procese i tehnici intuitive ct i prin metodele logice i raionale utilizate la ora actual.
Societatea modern este caracterizat de schimbri rapide i inovare permanent n
toate domeniile cunoaterii. nc din anii 70, n lucrarea ocul Viitorului, Alvin Toffler
atrgea atenia asupra accelerrii schimbrii n toate domeniile cunoaterii, schimbare
determinat n principal de revoluia informatic.
Perioada 1950-1990 definete Al Treilea Val al progresului i este perioada n
care are loc revoluia informatic prin utilizarea mainilor inteligente i n care accentul
este pus pe resursa individ, iar relaiile interorganizaionale au la baz deviza
cooperm. Dup 1990 are loc naterea i rspndirea celui de-Al Patru-lea Val
determinat de revoluia cunoaterii cu accent pe cunoaterea incontient deci
cunoaterea bazat pe intuiie, imaginaie i capacitatea creativ a individului. Este
perioada ce va fi caracterizat de realizarea i utilizarea de maini care gndesc
destinate pe domenii (ex. Economia), n care managementul este privit ca instituie
182
central cu difuzarea sa fr frontiere ntr-o societate informaional global i n care
cunoaterea este exploatat ca resurs economic sub deviza crem mpreun.
Datorit facilitilor de comunicare dincolo de granie, spaiu i timp oferite de
reeaua Internet, economia noului mileniu poate fi privit [DANA02] ca o scen
digital n care noile afaceri devin e-bussines (afaceri electronice), comerul devine e-
commerce (comer electronic), apar noi servicii electronice (e-services) i se nasc noi
comuniti de tip virtual (e-communities). n noua scen cu calculatoare interconectate n
reele Internet, Intranet i Extranet suntem inundai de informaie, dar flmnzi dup
cunotine [DANA02] (John Naisbitt Megatrends. Ten New Directions Transforming
Our Lives), viziunea lui Alvin Toffler n ocul viitorului fiind mult mai sumbr, el
avertiznd asupra iminenei unui nou potop, de aceast dat nu de ap, ci de informaii.
Apare deci i se dezvolt, n cadrul economiei digitale, o nou pia i anume piaa
digital sau piaa electronic n care trebuie acordat o importan tot mai mare noii
resurse strategice care este informaia, cunotina. Principalii actori (componente) ai
economiei digitale, n viziunea anumitor specialisti (Turban, s.a., 1999) [DANA02] sunt:
cumprtorii/consumatorii - milioane de internaui care navigheaz pe Web -
poteniali cumprtori ai bunurilor i serviciilor oferite sau promovate pe
Internet;
vnztorii - sute de mii de magazine digitale care i prezint milioane de
produse pe
Net;
produsele i serviciile digitale - digitalizarea software-ului, a muzicii, a crilor,
ziarelor i revistelor, a filmelor .a., digitalizarea a nenumrate alte produse i
servicii;
companiile creatoare ale infrastructurii digitale - mii de firme implicate n
asigurarea hardware-ului i software-ului necesar realizrii infrastructurii
specifice economiei digitale, care s permit dezvoltarea comerului electronic;
intermediarii (agenii)- un nou tip de actori care i ofer serviciile pe Web,
rolul lor diferind de cel al intermediarilor obinuii prin aceea c sunt implicai
183
n crearea i susinerea pieei on-line, ei ajutnd consumatorii i/sau
vnztorii n derularea tranzaciilor electronice;
serviciile de suport - sute de astfel de servicii sunt disponibile, pornind de la
cele care asigur securitatea pn la cele care furnizeaz cunotine;
creatorii de coninut - 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 pieei digitale / spaiului electronic (marketspace) n care au loc
tranzaciile.
Din prezentarea de mai sus se constat apariia unui nou tip de actor pe scena
digital i anume intermediarul sau agentul. Se impune astfel distribuirea inteligenei
artificiale n vederea realizrii sistemelor de ageni inteligeni sau sistemelor multiagent
care pot lua decizii ntr-o societate populat de ageni inteligeni artificiali sau umani care
au propriile lor scopuri.
Distribuirea inteligenei artificiale este justificat din urmtoarele motive:
n mod natural activitile i cunotinele sunt distribuite spaial;
extinderea cooperrii om-main prin rezolvarea distribuit a problemelor;
descompunerea sistemelor complexe i a bazelor de cunotine aferente n
subsisteme cooperative asigurnd astfel modularitate i flexibilitate sistemului
precum i timp de rspuns optim;
necesitatea integrrii aplicaiilor de inteligen artificial deja existente, att
ntre ele ct i cu componente de prelucrare clasic i sisteme de gestiune a
bazelor de date distribuite;
n modelarea comportamentului uman n cadrul aplicaiilor 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
184
modalitate de abordare n construcia sistemelor multi-agent. Programarea orientat pe
ageni introdus de Yoav Shoham odat cu definirea limbajului AGENT0, reprezint o
specializare a programrii orientate pe obiecte i n care coleciei de obiecte definite de
stri i care comunic ntre ele prin transmitere de mesaje i corespunde o mulime de
ageni caracterizai de stri mentale compuse din noiuni mentale (convingeri, intenii,
obligaii, angajamente, decizii, etc.).
Comunicarea ntre ageni 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 aprut la nceputul anului 1997 (ARPA a realizat i standardul MIF -
Module Interconnect Framework ce conine metodele standard de construire a
megaprogramelor multimodul). KQML folosete limbajul KIF (Knowledge Interchange
Format) pentru a descrie coninutul informaional al mesajului i este o reprezentare
ASCII a logicii cu predicate de ordinul nti, 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 comunicrii n Sistemele Multi Agent
cognitive.
Pentru realizarea activitilor dintr-un domeniu ntr-o manier inteligent, n cadrul
procesului decizional, decidentul este pus permanent n situaia de a evalua i alege ntre
dou sau mai multe alternative n cadrul unor activiti inteligente. Materia prim de baz
prelucrat n cadrul activitilor inteligente este cunoaterea, care reprezint conceptul
fundamental pentru dezvoltarea sistemelor inteligente. Reprezentarea i procesarea
datelor i cunoaterii reprezint obiectul apariiei i dezvoltrii a dou tehnologii de
importan major n informatic [ANDO01]:
Tehnologia bazelor de date;
Tehnologia sistemelor inteligente.
n timp ce tehnologia bazelor de date are n vedere memorarea, ntreinerea i
accesarea unor volume mari de date, tehnologia sistemelor inteligente este axat pe
185
rezolvarea unor probleme complexe n diverse domenii care necesit expertiz uman,
fiind ns restricionat de domenii bine delimitate i ineficient pentru procesri
numerice i gestiunea unor volume mari de date. Cele dou tehnologii la ora actual
distincte, tind s evolueze convergent n cadrul conceptului de sistem informaional
inteligent care presupune elaborarea unui model unificat date-cunotine. n acest sens,
sistemele de baze de date au n vedere exprimarea semanticii n schemele lor
conceptuale i capacitatea de infereniere (baze de date deductive), iar sistemele bazate
pe cunotine tind s rezolve probleme care reclam baze de cunotine (fapte i reguli)
din ce n ce mai mari. Pentru exploatarea maxim a celor dou resurse informaionale,
bazele de date i bazele de cunotine, nu este suficient doar cuplarea sistemelor de
gestiune a bazelor de date cu sistemele expert prin intermediul unor interfee n cadrul
aplicaiilor, fiind necesar proiectarea fiecreia din cele dou componente ca o extensie
natural a celeilalte astfel nct mpreun s conduc la realizarea unui sistem integrat.
n acest sens cercetrile sunt ndreptate n urmtoarele direcii:
dotarea SGBD cu instrumente suplimentare de structurare i manipulare
avnd n vedere semantica datelor (un pas important n aceast direcie l
constituie bazele de date deductive);
dotarea sistemelor expert cu instrumente care s permit accesarea i
manipularea eficient a informaiei stocate n bazele de date;
valorificarea informaiei 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 urmtoarele abordri principale:
sisteme expert bazate pe reguli, n care cunotinele sunt reprezentate prin reguli de
producie;
sisteme bazate pe reele neuronale, n care baza de cunotine este creat automat
de un algoritm de nvare plecnd de la o mulime de exemple de nvare, baza de
186
cunotine este implicit reprezentat de ponderile conexiunilor dintre neuroni i nu
exist o baz de cunotine explicit ca n abordarea bazat pe reguli;
sisteme multiagent care sunt sisteme distribuite formate dintr-o colecie de ageni
autonomi care interacioneaz ntr-un mediu comun.
Avantajele i dezavantajele fiecreia dintre abordri 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 reguli
Sistemele expert sunt sisteme informatice care stocheaz cunotinele dintr-un
domeniu bine precizat i au capacitatea de a realiza expertize de o calitate apropiat de a
celor realizate de experii umani. ntr-un sistem expert bazat pe reguli pot fi evideniate
urmtoarele componente:
o baz de cunotine explicit constituit din o baz de fapte i o baz de reguli;
motorul de inferene;
interfaa 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
conin motorul de inferene, sistemul de gestiune al bazei de cunotine, interfaa de
comunicaie cu utilizatorul, dar a cror baz de cunotine este vid. Generatoarele de
sisteme expert [PENT00], [MAPH92], [GURU87] sunt sisteme bazate pe reguli de
producie, capabile de a stoca diverse cunotine reprezentate prin reguli i de a deduce cu
ajutorul acestora i a valorilor unor fapte precizate de utilizator, noi cunotine.
7.2.2. Sisteme bazate pe reele neuronale (sisteme conexioniste)
Un sistem conexionist const dintr-o reea de elemente de tip neuron
interconectate, care realizeaz anumite funcii logice simple. ntr-un astfel de sistem
informaia este memorat difuz n toat reeaua, fiind reprezentat de ponderile
conexiunilor sinaptice dintre neuronii reelei. O caracteristic important a reelelor
neuronale este capacitatea de a nva din exemple i de a construi algoritmul de rezolvare
187
a unei probleme pornind de la mulimea de exemple de instruire i regula de modificare a
ponderilor interneuronale. Prelucrarea informaiei n sistemele neuronale const n
efectuarea unor calcule numerice (calcul matriceal) prin care n faza de nvare se
urmrete descoperirea relaiilor existente ntre intrrile i ieirile unui set de exemple de
instruire, relaii ce vor fi ulterior utilizate pentru prelucrarea unor seturi noi de date de
intrare n vederea clasificrii 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
fr a cunoate apriori regulile de aplicat, reguli ce vor fi deduse de sistem n faza de
instruire prin procesarea numeric a datelor. Instruirea reelei poate fi reactualizat prin
utilizarea unor noi seturi de date de instruire. Un inconvenient al acestor sisteme este
faptul c procesul de raionament nu poate fi explicat iar cunotinele nu sunt reprezentate
explicit. Pentru soluionarea unor probleme complexe , reelele neuronale pot fi
combinate, n cadrul unui sistem integrat, cu alte tehnologii printre care: baze de date,
sisteme expert, data mining, etc. n cadrul aplicaiilor de tip data mining, reelele
neuronale pot fi utilizate pentru identificarea corelaiilor din bazele de date n vederea
descoperirii unor "abloane" (patterns) semnificative n structura datelor i extragerea
informaiilor predictive ascunse din bazele mari de date. n ultimii ani, reelele neuronale
artificiale sunt utilizate cu succes pentru rezolvarea unor probleme complexe printre care:
procesarea limbajului natural, robotica, vederea artificial i procesarea semnalelor,
recunoaterea scrisului de mn, sisteme de sprijinire a deciziei.
7.2.3. Sisteme multi-agent. Definiie, clasificare, arhitecturi.
Un sistem multi-agent (SMA) este [SIMA98] un sistem distribuit format dintr-o
colecie de ageni autonomi care interacioneaz ntr-un mediu comun, fiecare agent
avnd cunotine, capaciti de aciune i scopuri proprii. Funcie de tipurile de ageni
utilizai se pot identifica dou categorii de sisteme multi-agent inteligente i anume:
SMA cu ageni cognitivi, numite i sisteme multi-agent cognitive;
SMA cu ageni reactivi, numite i sisteme multi-agent reactive.
188
Sistemele multi-agent cognitive urmresc s simuleze aspecte ale
comportamentului uman prin tratarea noiunilor de scop, cooperare, competiie,
organizare n structuri sociale i stabilirea relaiilor de dependen n aceste structuri,
capacitate de nvare i auto-perfecionare. Un sistem multi-agent cognitiv reprezint un
sistem particular bazat pe cunotine ce conine o reprezentare simbolic a cunotinelor
despre lumea n care evolueaz fiind capabil s ia decizii prin intermediul unui proces
inferenial de raionament. ns, spre deosebire de un sistem bazat pe cunotine clasic, n
cadrul unui sistem multi-agent, un agent reprezint simbolic lumea att prin convingeri,
care sunt preri despre lume, eventual incomplete sau eronate, ct i prin cunotine care
reprezint fapte adevrate despre acea lume. De asemenea, un agent trebuie s fie capabil
s raioneze att despre propriile lui convingeri i cunotine ct i despre cele ale
celorlali ageni cu care interacioneaz ntr-un anumit mediu. Abordarea cognitiv a
agenilor, ridic o serie de probleme critice n special referitor la complexitatea de calcul
i dificultatea algoritmilor necesari prelucrrilor simbolice.
Un sistem multi-agent reactiv este un sistem n care agenii sunt uniti simple de
prelucrare, capabile s reacioneze la schimbrile de mediu i s execute aciuni simple
corespunztor acestor schimbri. Un astfel de sistem este inspirat din organizarea i
activitatea comunitilor biologice de insecte. Astfel, o albin nu poate fi considerat
inteligent ns comportamentul stupului n ansamblu i modul de organizare a albinelor,
executnd aciuni comune i coordonate n vederea realizrii scopului, prezint elemente
de inteligen. Adepii sistemelor multi-agent reactive, criticnd abordarea cognitiv,
consider c inteligena este situat n lumea exterioar i nu la nivelul componentelor de
prelucrare individuale, respectiv agenii, comportarea inteligent fiind un rezultat al
interaciunii dintre ageni i mediu, iar inteligena este o proprietate a sistemului ca ntreg.
n acest sens, au fost propuse sisteme cu arhitecturi care modeleaz structura i
comportamentul colectivitilor de insecte, sisteme care ar putea fi realizate ntr-o
abordare subsimbolic utiliznd reele neuronale sau algoritmi genetici.
189
O alt direcie de cercetare o constituie abordarea mixt cognitiv-reactiv avnd n
vedere avantajele i dezavantajele fiecreia 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 conine o reprezentare explicit a convingerilor, dorinelor i inteniilor agentului.
Convingerile reprezint informaiile pe care un agent le are despre mediul n care
evolueaz sau despre ceilali ageni din sistem i acestea pot fi adevrate sau false.
Dorinele sunt lucrurile pe care agentul ar dori s le realizeze, ns nu trebuie neaprat s
acioneze pentru ndeplinirea tuturor dorinelor sale. Inteniile 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 numete 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.
O arhitectur reactiv este arhitectura unui sistem multi-agent n care nu se
folosete un model simbolic pentru reprezentarea cunotinelor i nu exist raionament
simbolic. ntr-o astfel de arhitectur, agenii sunt reprezentai prin uniti de prelucrare
simple iar inteligena sistemului este emergent din interaciunea unitilor de prelucrare
cu mediul.
7.2.4. Sisteme inteligente hibride
Pentru definirea conceptului de sistem inteligent hibrid, reamintim pentru nceput
c n domeniul inteligenei artificiale au aprut i se dezvolt o serie de tehnologii de vrf
enumerate n cele ce urmeaz:
sisteme expert bazate pe reprezentarea simbolic a cunotinelor (sisteme expert
bazate pe reguli);
reele neuronale artificiale (sisteme conexioniste);
sisteme fuzzy;
algoritmi genetici;
190
strategii de evoluie i programarea evolutiv (algoritmi evolutivi);
ageni inteligeni;
sisteme multiagent (inteligena artificial distribuit).
Sistemele inteligente n care sunt integrate cel puin dou din tehnologiile
menionate mai sus sunt cunoscute sub denumirea de sisteme inteligente hibride, iar
tehnologia utilizat n vederea integrrii este denumit tehnologia fuziunii. Fiecare din
tehnologiile dezvoltate n domeniul inteligenei artificiale prezint avantaje i dezavantaje
i nu pot fi utilizate singular pentru rezolvarea unor probleme complexe care se pun astzi
n tiin, tehnic, economie i societate. Aceast afirmaie este susinut i de faptul c n
procesarea uman a informaiei i cunoaterii sunt implicate diverse reprezentri
arhitecturale, creierul avnd pe de o parte o structur neuronal, iar pe de alt parte
capacitatea de a opera cu simboluri i de a efectua raionamente simbolice, de a prelucra
date imprecise sau incomplete.
Un domeniu de mare interes n care agenii se vor impune spectaculos este
Internet-ul, care permite astzi accesul direct a milioane de oameni pe autostrada
informaional ( Internet Society estimeaz c exist peste 30 de milioane de utilizatori
care acceseaz zilnic reeaua Internet), care pot fi att consumatori ct i poteniali
furnizori de informaie. Cutarea informaiei despre un anumit subiect necesit
identificarea i investigarea unui numr mare de documente de pe Web, operaii mari
consumatoare de timp i care pot fi realizate de ageni competeni numii ageni Internet.
Pentru a asigura accesul tuturor categoriilor de utilizatori, indiferent de calificare i
cunotinele de care dispun, la resursele informaionale imense de pe Internet, viitoarea
generaie de ageni Internet va fi o combinaie de modele cognitive i reactive, avnd ca
scop att satisfacerea necesitii de informare a utilizatorului ct i transparena total a
autostrzii informaionale.
Dei reeaua Internet reprezint un mare succes n unificarea resurselor
informaionale, structura sa actual n care pot fi identificate dou straturi i anume:
utilizatorii (consumatorii) de informaie i productorii (furnizorii) de informaie, nu este
adecvat pentru activitatea de informare care presupune prelucrarea complex a
191
informaiilor din multiple documente de pe Web independent de utilizator. Pentru
rezolvarea acestei probleme, una din cele mai promitoare propuneri este modelul n care
activitile desfurate pe Internet sunt mprite pe trei straturi, denumit [DANA02]
modelul celor 3 straturi i anume:
1. un strat pentru utilizatorii de informaie (clienii informaionali) definete cererea de
informaie;
2. un strat pentru furnizorii (productorii) de informaie definete oferta de informaie;
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
ci sau modaliti.
n cadrul acestui model, agenii au un rol important difereniat pe straturi dup cum
urmeaz:
sarcinile agenilor n cadrul primului strat sunt de a afla ce informaii caut
utilizatorii, dac au anumite preferine n legtur cu informaia de care au
nevoie, etc.;
n cadrul celui de-al doilea strat sarcinile agenilor sunt de a face un inventar al
serviciilor i informaiilor oferite de ctre furnizori, de a ine evidena noilor
informaii adugate n reea, etc.;
agenii din stratul de mijloc au rolul de intermediari informaionali ntre
utilizatorii informaionali (umani sau electronici) i furnizorii de informaii,
sarcina lor fiind de mediere ntre agenii celorlalte dou straturi.
Agenii utilizai ntr-un astfel de model vor trebui concepui n baza unor standarde
general acceptate, astfel nct s rspund i s reacioneze n acelai mod prin utilizarea
unui set standardizat de coduri suficient de flexibil pentru a permite construirea unor
ageni pentru sarcini neateptate sau imprevizibile n prezent.
Referitor la domeniile de utilizare a tehnologiei agenilor n viitor, cercettori n
domeniu cred [DANA02] c agenii autonomi vor deveni n urmtorii 10 ani parte
integrant a celor mai multe sisteme de afaceri. Astfel, cei de la IBM prevd o vast
utilizare a agenilor software n e-commerce: Crem o nou categorie economic (a new
192
economic species), parial asemntoare nou ca imagine, dar semnificativ diferit de
oameni, Agenii software vor deveni actori n economie, afirm Jeff Kephart,
managerul grupului care se ocup de fenomenul agenilor. (Scott,K., 2001).