SISTEME INFORMA IONALE

Capitolul 1
Sisteme informatice.....

1.1. Sistem, Sistem informaional, Sistem informatic.

1.1.1. Componentele sistemului informatic
1.1.2. Clasificarea sistemelor informatice.
1.1.3. Obiectivele sistemelor informatice.......................................................................
1.1.4. Ciclul de via a unui sistem informatic.......
1.1.5. Coninutul bazei informaionale a unei ntreprinderi ...
1.1.6. Ciclul prelucrrii datelor pentru sistemul informatic....
1.1.7. Sistemele informatice de gestiune ...
1.2. Metodologii de realizare a sistemelor informatice.......
1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice.....
1.2.2. Metode i tehnici de realizare a sistemelor informatice ......
1.3. Instrumente CASE........................................................................................................
1.3.1. Funciile CASE ....................................................
1.3.2. Trsturi definitorii ale CASE-ului.......................................................................
1.3.3. Exemple de instrumente CASE ...........................

3
5
6
7
7
9
9
10
11
11
12
14
15
15
16

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

18

2.1. Identificarea, selecia, iniierea i planificarea proiectelor...

2.2. Analizele de fezabilitate.. .. .....
2.3. Tehnici de reprezentare a planurilor i programarea calendaristic.............................

18
20
21

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

23

3.1. Studiul sistemului informaional existent.....

3.2. Determinarea cerinelor sistemului ..................

23
24

3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor

sistemului..
3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului..
3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor...
3.3.1. Diagramele fluxurilor de date (DFD)..
3.3.2. Descompunerea funcional i rafinarea DFD..
3.3.3. Modelarea sistemului current....
3.3.4. Modelarea logicii proceselor....
3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)........................
3.4.1. Modelul Entitate/Relaie (E/R).............................................................................
3.5. Selectarea celei mai bune variante strategice de proiectare ....

25
25
26
27
28
31
33
35
43
47

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

48

4.1. Proiectarea formularelor/formatelor i a rapoartelor................................................................

4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor).............................
4.1.2. Proiectarea codurilor ....
4.1.3. Proiectarea intrrilor n sistemul informatic.........................................
4.2. Proiectarea interfeelor i a dialogurilor .........
4.3. Proiectarea logic a bazelor de date.

48
48
51
52
54
55

4.3.1. Normalizarea relaiilor - Forme normale..............................................................

4.3.2. Simplificarea structurii datelor prin normalizare..
4.3.3. Transformarea diagramelor entitate-relaie n relaii

59
63
65

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

66

5.1. Proiectarea fizic a bazelor de date i a fiierelor.....................................................................

66

5.1.1. Obiectivele fundamentale ale unei baze de date...................................................

5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)....
5.1.3. Administratorul bazei de date...
5.1.4. Proiectarea securitii bazelor de date i a fiierelor....
5.1.5. Limbajul SQL crearea, administrarea, interogarea bazelor de date
relaionale.

67
67
68
69
70

5.2. Proiectarea programelor i a procedurilor.................

5.2.1. Atributele modulelor.........................................................................................................

81
82

5.2.2. Structurile de control ale programelor..............................................................................

83

[Link] i realizarea programelor...............................................................................

87

Sisteme informatice
5.3. Proiectarea sistemelor distribuite.............................................................................................

Teste .........................................................................................................................

87

93

Bibliografie.............................................................................................................................. 107

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.
Organizaie 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;
- 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.

Sisteme informatice
Sistem informatizat

Procesor de informaii

Sistem
manual

Sistem
automatizat

Informaie

Om

Fiiere
manuale

Calculator

Fiiere
informatice

Reguli
Reguli i
proceduri
scrise
Programe i
Structuri
de
date

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].
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.
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.
Sistem Informatic

Subsistem 1

Subsistem 2

Aplicatia 2.1

Subsistem n

Aplicatia 2.k

Program
2.k.1

Program
2.k.s

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].

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, analitiprogramatori ajutori, operatori, etc.;
- beneficiarii sistemului.
Cadrul organizatoric este cel specificat n regulamentul de organizare i funcionare
(ROF) al unitii n care va fi utilizat sistemul informatic.

Sisteme informatice
La realizarea i utilizarea unui sistem informatic trebuie avute n vedere reele,
echipamente, produse software de baz, produse software de aplicaie.
Reele
- 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).
- 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.);
- Sisteme GIS (Geographical Information System) utilizate pentru realizarea
aplicaiilor din domeniul cadastrului (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. 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 nivelul ierarhic ocupat de sistemul economic n structura

organizatoric a societii, conform cruia 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 .

3. n funcie de elementul supus analizei [Oprea D., 1999]:

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.

4. Dup modul de organizare a datelor [[1] D., 1999]:

sisteme bazate pe fiiere;
sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, orientateobiect;
sisteme mixte.

5. Dup metoda folosit n analiza i proiectarea sistemelor [1]:

sisteme dezvoltate dup metoda sistemelor;
sisteme dezvoltate dup metoda clasic a ciclului de via;
sisteme dezvoltate dup metoda structurat;
sisteme dezvoltate dup metoda orientat-obiect;
sisteme dezvoltate dup metoda rapid(RAD);
sisteme dezvoltate dup metoda echipelor mixte(JAD);
sisteme dezvoltate dup metoda prototipurilor.

6. Dup gradul de centralizare [1]:

sisteme centralizate;
sisteme descentralizate;

7. Dup gradul de dispersie a resurselor sistemului informatic:

sisteme informatice locale (bazate pe reea local, staii de lucru):
sisteme informatice distribuite (date distribuite).

8. Dup gradul de automatizare a activitilor de analiz i proiectare a sistemelor

informatice [1]:
- 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.

Sisteme informatice
1.1.3. Obiectivele sistemelor informatice
Plecnd de la ideea c sistemul informatic este subordonat procesului decizional, al
crui rol este de a asigura funcionarea normal i optim a ntregii activiti i de a
reduce la minimum pierderile n caz de funcionare anormal, rezult c obiectivul
oricrui sistem informatic trebuie s fie subordonat obiectivului propriu-zis al unitii
economico-sociale. n acest context, 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].
1.1.4. 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
[4].
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 [4].
Etape ale ciclului de via a unui sistem informatic n modelul cascad ([10])
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 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.
3. Implementarea i testarea unitilor de program proiectarea software-ului
din etapa anterioar este transpus ntr-o mulime de programe sau module programi
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.
Analiza
definirea
cerinelor

Proiectarea
sistemului i a
software-ului

Implementarea
i
testarea
unitilor
de
program

Integrarea
testarea
sistemului

Exploatarea
ntreinerea
sistemului

Fig. 1.3. Etapele ciclului de via a unui sistem informatic n modelul cascad ([10])

Sisteme informatice
1.1.5. Coninutul bazei informaionale a unei ntreprinderi
Prin analiza critic sunt identificate entitile bazei informaionale. n principal,
pentru o ntreprindere acestea pot fi grupate dup cum urmeaz:
-

pentru activitatea de aprovizionare: stocuri de materiale, intrri materiale, consumuri

de materiale, contracte cu furnizorii, programe de aprovizionare;
pentru activitatea de producie: tehnologii i reete de fabricaie, program de lucru,
norme de munc i consumuri de manopere;
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.6. 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. Ciclul cuprinde cinci faze: culegerea datelor, pregtirea datelor,
prelucrarea datelor, ntreinerea fiierelor i obinerea informaiilor de ieire.
Faza de culegere a datelor cuprinde dou activiti fundamentale [1]:
-

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.

Pregtirea datelor const ntr-un numr de operaii executate asupra datelor pentru
a facilita prelucrarea lor ulterioar. Ele sunt [1]:
-

clasificarea datelor, care implic atribuirea de coduri de identificare (simbol cont, cod
secie, etc.), astfel nct datele s fie incluse n submulimile corespunztoare;
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.

10

Pregtirea datelor este o activitate realizat n toate tipurile de sisteme

informaionale, dar capt o semnificaie deosebit n sistemele de prelucrare automat a
datelor; partea informatizat a acestora fiind cunoscut ca sistem/subsistem informatic.
Culegerea
datelor

Pregtirea datelor

Prelucrarea datelor

ntreinere
fiiere
Informaii
ieire

de

Fig. 1.4 Ciclul prelucrrii datelor [1]

Prelucrarea datelor, poate s includ activiti, cum sunt [1]:
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;
- 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 ori rspunsuri la ntrebri. Termenul ieiri le cuprinde pe toate [1].
De cele mai multe ori, datele nu parcurg toate activitile, iar unele dintre ele pot
chiar s nu treac prin cele cinci faze.
-

11

Sisteme informatice
1.1.7. Sistemele informatice de gestiune
Sistemul informatic de gestiune implic urmtoarele patru componente
interdependente: domeniile de gestiune, datele, modelele, regulile de gestiune [4].
Sistemul informatic de gestiune asigur obinerea informaiei solicitate de
utilizator, folosind mijloacele tehnologiei informaiei (TI).
Sistemele informatice de gestiune sunt sisteme integrate. Se caracterizeaz printr-o
introducere unic a datelor, preluate din documentele primare care actualizeaz o baz de
date unic a contabilitii care va fi ulterior prelucrat pentru obinerea situaiilor
specifice fiecrui utilizator [4].
Documente
facturi
ordin de plat
bon
de
consum

Actualizare

Consultare 1

Situaia
costurilor pe
comenzi

Consultare 2

Balana
de
verificare
Registrul jurnal
Casa
Banca

BD

Fig. 1.5. Sistem informatic de gestiune integrat al contabilitii [4]

Sistemul informatic de gestiune reunete subsisteme informatice specializate pe
domenii ntre care se manifest interaciuni specifice. Fiecare subsistem definit grupeaz
procese informaionale omogene, specifice unei anumite arii de interes [4].
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.

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

12

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. Acest lucru a dus deci, 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 ce i urmeaz [2].
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;
- 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
existent, proiectarea i introducerea sistemului informatic. Deci, metoda are un caracter
general, n cadrul ei aplicndu-se anumite tehnici de lucru [2].
Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint
felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea

13

Sisteme informatice
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;
- 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.

14

Datele sunt surprinse din prisma structurii lor sub form de atribute i nseamn de
fapt, ceea ce are stocat, i reflect structura static [1].
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 [1].
Comportamentul este invocat pentru a reda o alt modalitate de percepie a
sistemului, influena evenimentele i proprietilor sistemului, i sugereaz dinamica lui
[1].
Metoda descompunerii funcionale (orientate funcii) [1].
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
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) [1].
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) [1]
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 [1]
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.

1.3. INSTRUMENTE CASE

Problema CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator sau
cu Ajutorul Calculatorului Computer Aided Systems 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 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].

15

Sisteme informatice
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.
- 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 [1].

16

1.3.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 [1].
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.
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 [1].
Modelele grafice permit conectarea fluxurilor logice ntre activitile i funciile
specifice aplicaiei, relaii care pot fi testate i validate n mod automat.
1.3.2. Trsturi definitorii ale CASE-ului
Evoluia CASE-ului, a determinat apariia I-CASE-ului. Integrated CASE se refer
la toate aspectele integrrii, chiar dac sistemele sunt deschise sau nu [1].
Caracteristicile mediilor moderne de tip CASE [1]:
- un set de instrumente specifice pentru realizarea sistemelor;
- diversitatea modurilor de interaciune;
- 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;

17

Sisteme informatice
-

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, critici sau modificri asupra elementelor
din modelul 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. Datele din
documentaia modelului sunt, de obicei, nlocuite cu cele reale i se parcurg paii de
implementare a sistemului pentru a obine un model funcional. n plus, CASE ofer
posibilitatea de a analiza ieirile obinute i de a le modifica pentru a reflect schimbrile
intervenite n sistem, modulele definite i depozitul de date [1].
1.3.3. Exemple 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
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.

18

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). Editorul
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.
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.
Deoarece tendina se ndreapt tot mai mult spre tehnologiile informaionale orientateobiect, nici domeniul instrumentelor ce sprijin realizarea sistemelor nu poate s nu se
adapteze la aceast orientare, lucru ce a dus 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.
Designer/2000
Setul de instrumente Designer/2000 este parte integrant din portofoliul de
instrumente de dezvoltare oferit de Oracle i reprezint o soluie integrat pentru

19

Sisteme informatice
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, multiplatform, distribuite.

20

Capitolul 2
Iniierea i planificarea realizrii unui sistem informatic
n cadrul acestui capitol vor fi prezentate o serie de aspecte privind primele
activiti desfurate n vederea realizrii sistemelor informatice, activiti definite n
literatura de specialitate sub numele de microanaliza sistemelor, component preluat din
managementul proiectelor i care are n vedere modalitile de identificare a proiectelor
de dezvoltare a sistemelor informaionale, precum i modul n care au loc iniierea i
planificarea acestora, n strns legtur cu planul strategic organizaional.
2.1. Identificarea, selecia, iniierea i planificarea proiectelor
Identificarea i selecia proiectelor de dezvoltare a sistemelor informaionale
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

microanali
B. iniierea i za

Fazele ciclului de via

al
dezvoltrii
sistemului

planificarea
proiectului
C. analiza
D. proiectarea
logic
E. proiectarea
fizic

F. implementarea
G. ntreinerea
Figura 2.1 Ciclul de via al dezvoltrii sistemelor [1]
Din modelul prezentat rezult c orice etap se descompune n activiti, ceea ce
pentru identificarea i selecia proiectelor nseamn [1]:

21

Sisteme informatice
-

identificarea potenialelor proiecte de dezvoltare;

clasificarea i ierarhizarea lor;
selecia.

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
orientare puternic spre strategie;
cele mai mari dimensiuni ale proiectului;
cele mai de durat proiecte.
orientare mixt (a diferiilor reprezentani);
vizeaz schimbrile organizaionale cele mai mari;
analiz formal a costurilor i avantajelor proiectelor;
proiecte mai mari i mai riscante.
limitat, neorientat strategic;
realizare mai rapid;
civa utilizatori reprezint niveluri ale conducerii,
precum i funciile ntreprinderii.

Top-managerii
De sus n jos

Comitetul de iniiativ

Departamentul
utilizatorilor

De jos n sus

integrare n sistemul existent;

puine ntrzieri n realizarea proiectului;
mai puin interesat de analizele cost avantaje.

Grupul de dezvoltare

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).

22

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 i a manualului de operare al
acestuia.
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.
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

23

Sisteme informatice
2.2. Analizele 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].
Totui, 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 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 o pot scoate n relief pe cea 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 ans a
unitilor de a mai putea 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

24

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
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) .

25

Sisteme informatice

Evidena promovrii vnzrilor (EPV)

Nr. Nume activitate Aprilie Mai 2005 Iunie
2005
2005
Crt.

1.
2.
3.
4.
5.
6.
7.
8.
9.

Iulie
2005

August
2005

Septembrie
2005

Colectarea
cerinelor
Proiectare
ecrane
Proiectare
rapoarte
Proiectare baze
de date
Documentaie
utilizator
Programare
Testare
Instalare
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]

26

Capitolul 3
Analiza sistemului existent i definirea cerinelor noului sistem
n cadrul acestui capitol este prezentat prima etap a ciclului de via al
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 system
.Astfel, sunt prezentate o serie de aspecte privind:
- determinarea cerinelor sistemului;
- metodele tradiionale utilizate n analiza i determinarea cerinelor sistemulu
(interviul i chestionarul);
- metode moderne de analiz i determinare a cerinelor sistemului (JAD,
prototipizarea);
- structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor
(diagramele fluxurilor de date DFD);
- modelarea conceptual a datelor (diagramele entitate relaie, DER).
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 structura 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 [2].
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;
- cunoaterea specificului activitii de baz ( producie, servicii);

27

Sisteme informatice
-

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 [2]:
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 [2]:
- 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 [2]:
- 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 [2].

28

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;
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 [1];
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 [1].
3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului
Analiza sistemului informaional-decizional fiind, n general, axat pe sistemul
obiect, metodele utilizate sunt n general comune cu cele ale analizei economice [2].
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 creativa analistului n construirea i desfurarea lui [2]. 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.

29

Sisteme informatice
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 [2].
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 [1].
Ideea principal a lui 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.
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 [1].
Prototipizarea este facilitat de cteva limbaje sau produse program, inclusiv
instrumentele de tip CASE.
Prototipizarea este foarte util n determinarea cerinelor sistemului cnd [1]:
- cerinele utilizatorului nu sunt prea clar formulate sau bine nelese;
- unul sau mai muli utilizatori sau susintori sunt implicai n sistem;
- anumite mijloace de lucru (formulare i rapoarte predefinite).
Prototipizarea genereaz i deficiene, cum ar fi:

30

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;
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.

31

Sisteme informatice
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 [1].
Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru
construirea DFD
Cnd analizm sistemele folosim 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 de acesta, 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.

32

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.
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 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) si 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

33

Sisteme informatice
descompunere funcional a sistemului, care este realizat prin rafinarea succesiv a
proceselor.
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.
n cazul aplicaiei Decontri, au rezultat urmtoarele diagrame:

Figura 3.1. Diagrama contextual pentru aplicaia Decontri

34

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

35

Sisteme informatice

Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaia Decontri

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

36

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, o problem este
comun: el 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. Tocmai 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. Problema comun ar consta n identificarea unei ci de realizare a modelului
logic al sistemului propus [1].
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. Deci, modelul logic propus
poate fi conceput pe baza modelului logic curent.
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;
- 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. 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.

37

Sisteme informatice
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:
- 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 urmtoarea DFD a sistemului logic.
Decontri cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele
superioare ale DFD a sistemului logic sunt identice.

38

Figura 3.4. Diagrama fluxului de date

Tabel 3.1 aplicaia Decontri
Sursa
Destinaia
Nume flux
1.1.
nregistrare D2
FACTURI desfaceri
facturi desfacere DESFACERE

D2
FACTURI 1.3. Analiza situaie client desfaceri
DESFACERE

39

Continutul fluxului
CODCLIENT
DENCLIENT
ADRESAC
CONTC
BANCA_C
DATAFACTD
NRFACTD
TOTALFACTD
CODCLIENT
DENCLIENT
ADRESAC
CONTC
BANCA_C
NRFACTD
TOTALFACTD

Sisteme informatice
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
astfel descrise nct s poat fi convertite n programe prin intermediul limbajelor de
programare [1].
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 proiectarea. Modelarea logicii
proceselor ca i diagramele fluxurilor de date face 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 [1].
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.
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))
{

40

if (cod!=FACTURI_DESF.codclient)
{ [Link] = cod;
[Link] = den;
[Link] = adr;
[Link] = cont;
CLIENTI.banca_c = banca;
[Link] = 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=[Link] AND
FACTURI_DESF.nrfactd=[Link] AND
FACTURI_DESF.datafactd =[Link])
{ if (FACTURI_DESF.totalfactd !=[Link])
{ sold = sold+ FACTURI_DESF.totalfactd [Link]}
vb1=1;
}
else if (vb1=1) vb=1
READ (NCASRI)
}
MOVE FIRST LINE NCASRI
READ (FACTURI_DESF)
}
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]:

41

Sisteme informatice
-

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 nivele 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);
- 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 [1].
Cea mai cunoscut form utilizat pentru modelarea datelor este diagrama entitaterelaie (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 [1].
DER joac un rol deosebit de important n formarea profesional a veritabililor
analiti.
Se consider c, n timpul modelrii conceptuale a datelor, se produc i se
analizeaz cel puin patru diagrame entitate-relaie [1]:

42

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.
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. Din nou, diferenele dintre diagrama precedent i cea de
fa vor indica modificrile majore de efectuat pentru a se putea influena noua
aplicaie.
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 [1].
Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere.
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 [1].
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 [1].
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.
Definirea conceptului 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 [1].
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.

43

Sisteme informatice
La fel putem spune i despre evenimente. Ele reprezint asocieri ntre dou sau mai
multe obiecte. Exemplu: CLIENT COMAND PRODUS.
Entitile conin n structura lor atributele prin care ele sunt descrise.
O entitate este o persoan, un loc, un obiect, eveniment sau concept din domeniul
de activitate a 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. Fiecrui tip de entitate i se atribuie un nume.
Ct timp numele reprezint o clas sau un set de cazuri, el este singular. i nc o
convenie. Cum referirea general la elementele ce pot fi catalogate ca entiti se poate
face prin noiunea de obiect (dei sensul lui poate fi altul n contextul analizei i
proiectrii orientate obiect), referirea la acesta se va realiza printr-un substantiv la
singular. Se vor folosi litere majuscule, plasate n interiorul dreptunghiului corespunztor
entitii.
O instaniere a entitii sau instan, denumit de noi 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, AdresaC
Ca i numele tipurilor entitilor, numele atributelor sunt substantive scrise cu
majuscule, 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.
Unul dintre exemplele anterioare poate fi reprezentat n diagram conform fig. 3.5.

DenClien
t
CLIENT

CodClient

Figura 3.5. Model de reprezentare a atributelor DER

44

AdresaC

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 unui caz de acelai tip.
O cheie candidat aste un atribut sau o combinaie de atribute prin care se poate
identifica n mod unic un caz (o instan) al tipului entitii respective.
Sunt entiti care pot avea dou sau mai multe chei-candidat. n exemplul nostru,
pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunnd c ele identific n
mod unic un angajat). Atunci cnd sunt mai multe chei-candidat, proiectantul trebuie s
decid care din ele va fi folosit 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 ).
Relaiile entitilor
Relaiile reprezint legturile ntre componentele unei diagrame entitate-relaie. O
relaie este o asociere ntre cazurile/instanele uneia sau mai multor tipuri de entiti care
prezint interes pentru organizaie. Ele se pot simboliza printr-un romb. De regul,
relaiile sunt redate prin verbe.
Cardinalitatea relaiilor

nscris
pentru

STUDENT

CURS_CREDIT

Figura 3.6. Tip Relaie

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. Trimiterea la cardinalitate se face n moduri
destul de diferite, n funcie de notaia folosit. Recomandm citirea cu atenie a
diagramelor i descifrarea
elementelor
strict necesare nelegerii, ndeosebi pentru
obligatoriu
1
reflectarea cardinalitii. De exemplu, ea poate fi notat cu semne (0, 1, M, N) sau prin
opional
sau
1
simboluri (linie cu vrf
simplu0de
sgeat
pentru 1, linie cu vrf dublu de sgeat pentru
M. Alteori, 1 se reprezint
prin linie
simpl
M prin
de sgeat).
multe materiale,
obligatoriu
multe
(n, i
unde
n iavrf
valori
de la 1 lanM)
inclusiv produse
n CASE, se folosete notaia model-date, cunoscut mai mult sub numele
laba-gtei, conform crei
cardinalitatea
se reprezint
urmtoarele
opional
1 sau multe
(n, unde nprin
ia valori
de la simboluri
1 la M) [1]:

45

Sisteme informatice

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 lua
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
1111
1177
1155
1111

NUME CURS
Informatic
Informatic
Informatic
Drept comercial

DATA PROMOVRII
Iulie 1999
Septembrie 1999
Septembrie 1999
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.7.
DATA PROMOVRII

STUDENT

Promovare

CURS

Figura 3.7. Asocierea unui atribut la o relaie [1]

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.8) [1].
DATA PROMOVRII

STUDENT

Promovare

46

CURS

Figura 3.8. Redarea unei entiti gerundive (asociative) [1]

Nu trebuie confundat aceast situaie cu relaiile transformate n entiti
nepurttoare de informaii, descrise anterior.
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: 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)

BIROU

este condus de

conduce

MANAGER

Figura 3.9. Descrierea relaiei 1:1

Fiecare BIROU este condus de un, i numai un, MANAGER
Fiecare MANAGER conduce un, i numai un, BIROU.
2. Relaia unu-la-multe (1:M)

VNZARE

implic
face parte din

ARTICOL
VNDUT

Figura 3.10. 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

FURNIZOR

livreaz
este livrat de

PRODUS

Figura 3.11. Descrierea relaiei M:N

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

47

Sisteme informatice
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.12.

ofer
PRODUS

FURNIZOR

este cumprat de la
Figura 3. 12. Descrierea relaiilor multiple ntre dou entiti
4.

Relaii opionale i obligatorii

Alteori, relaiile dintre entiti nu-i fac simit prezena n toate situaiile. Chiar
cazul cu studiile la care lucreaz diverse persoane este destul de elocvent; o persoan
poate s lucreze la un singur studiu sau la cteva, sau la niciunul i, invers, un studiu
poate fi efectuat de o persoan, de mai multe sau de nici una. n astfel de situaii, se
apeleaz la urmtoarea form de reprezentare. (fig. 3.13)

lucreaz la

PERSOANA

STUDIU
este realizat de

Figura 3.13. Exemplu de relaie opional

Cercul suprapus pe latura entitii indic, de fapt, poziia 0 (valoarea minim poate
fi i zero), conferind relaiei caracterul opional.
Un alt aspect se refer la caracterul obligatoriu al relaiilor. Cu alte cuvinte, o
entitate poate exista fr cealalt?
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 (operaiunea nu ar avea sens). Simbolul folosit pt a marca relaiile obligatorii este
acelai cerc, cu deosebirea c este haurat.

VNZARE

ARTICOL
VNDUT

Figura 3.14. Exemplu de relaie obligatorie

5.

Relaia unei entiti cu ea nsi

n practic, apar i situaii n care o entitate este pus n relaie cu ea nsi.

48

Ne oprim la exemplul entitii ANGAJAT. Unii dintre ei dobndesc statutul de

coordonatori ai activitii celorlali, situaii n care se poate apela la o diagram de genul
celei din fig.3.15.

ANGAJAT

coordonator al

raporteaz la

Figura 3.15. Redarea relaiei unei entiti cu ea nsi

Reprezentarea anterioar se citete astfel:
Un angajat poate fi coordonatorul unuia sau mai multor angajai
Oricare angajat ntotdeauna raporteaz altui angajat
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,
dar nu cu linii de relaii distincte, aa cum este prezentat n figura 3.16.

PRODUCIA
ALTORA
MARFA
PRODUCIA

Figura 3.16. Exemplu de diagram pentru relaiile alternative

PROPRIE
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 se cunosc de ctre muli specialiti din lumea bazelor de
date, ele constituie unul din conceptele eseniale ale analizei i proiectrii structurate i,
ca atare, provin din acest domeniu [1].
Dup cum reiese i din citirea cu atenie a numelui diagramei, scopul ei este de a
evidenia entitile de date (obiectele despre care se solicit pstrarea datelor) i relaiile
ce exist ntre ele.

49

Sisteme informatice
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 [1].
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
la singular (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.

Figura 3.17. DER pentru aplicaia Decontri

50

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.
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.
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 [11], [13] o serie de
simboluri reprezentate n figura 3.18.

51

Sisteme informatice

<nume
entitate>

Reprezentare tip entitate cu numele <nume tip entitate>

tip

<nume
atribut>

Reprezentare atribut cu numele <nume

atribut>
Reprezentare atribut cheie cu numele <nume atribut>

<nume
atribut>

Reprezentare atribut derivat cu numele <nume

atribut>

<nume
atribut>

<atribut
1>

<atribut
2>

<nume
atribut>

<nume
entitate>

tip

Reprezentare atribut compus

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

Apartenena atributului <nume atribut>

la tipul de entitate <nume tip entitate>

<nume
atribut>
Reprezentare tip de relaie cu numele <nume tip
relaie>

<nume
relaie>

tip

RELAIA R FUNCIONAL FA DE TIPUL

DE ENTITATE E

RELAIA R NEFUNCIONAL FA DE TIPUL

DE ENTITATE E

Superclas
a
Subclasa

52

APARTENENA SUBCLASEI LA
SUPERCLAS

FIG. 3.18. SIMBOLURI UTILIZATE N REPREZENTAREA UNEI

DIAGRAME EER

Problem rezolvat
Folosind modelul entitate - relaie s se reprezinte diagrama E/R 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.

Cod produs

Cod
furnizor

Oferte

FURNIZORI

PRODUSE

Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaiei de tip m-n Oferte

Cod client

Cod produs

PRODUSE

Vnzri
VANZARI

CLIENTI

Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaiei de tip m-n Vnzri

Aprovizionare

Cod produs
1

Intrri

Cod
Produs+Depozit+Pre
n

PRODUSE

STOCURI
1

53

Ieiri

Desfacere
Fig. 3.21. Subsistemul Urmrirea stocurilor.
Reprezentarea relaiilor de tip 1-n Intrri, Ieiri, pentru actualizarea stocurilor

Sisteme informatice

Cod produs

Descriere
produs

Denumire
produs

PRODUSE
Fig. 3.22. Reprezentarea entitii PRODUSE

Strad

Numr

Localitate

Cod furnizor

Adresa furnizor

Denumire
furnizor

Oferta

PRODUSE
Fig. 3.23. Reprezentarea entitii FURNIZORI

Cod produs

Unitate
msur
produs

de

Oferte

Cod furnizor
54

Fig. 3.24. Reprezentarea relaiei Oferte

Pre
produs

unitar

3.5. Selectarea celei mai bune variante strategice de proiectare

ntregul efort depus pn n momentul de fa s-a concretizat ntr-o bogat
acumulare de informaii despre cerinele sistemului, structurate sub diverse forme,
precum i despre modul n care am dori s fie conceput noul sistem sau ce corecii s i se
aduc celui vechi.
Ne aflm n aa-zisa faz a strategiei proiectului.
n afara certitudinilor concretizate n specificaiile elaborate pn acum, asupra
variantei noului sistem planeaz i o seam de incertitudini, generate de nehotrrea sau,
nc, needificarea asupra formei finale dorite. Un cuvnt greu au utilizatorii i finanatorii
proiectului. Pentru a-i ajuta s ajung la o concluzie final comun, trebuie pornit de la
cerinele structurate i se vor prezenta cteva strategii concurente de proiectare, dintre
care doar una va fi continuat n pasul urmtor al ciclului de via al sistemului, faza de
proiectare, n funcie de performanele ei i de ncadrarea n resursele disponibile [1].
Rezultatul final al studiului de identificare a cerinelor de informaii se
concretizeaz ntr-un raport detaliat al cerinelor sistemului, n care vor fi prezentate
informaiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie s fie produs de
ctre sistem. El va lsa fazei de proiectare o imagine clar a modului n care se vor obine
cerinele sistemului.
Raportul conine urmtoarele elemente [1]:
- descrierea funciilor principale executate n noul sistem, inclusiv ce trebuie fcut i de
cine, cum se realizeaz interfaa funciilor cu ntregul sistem i cum funciile noi vor
afecta utilizatorii;
- descrierea tuturor datelor necesare sistemului, inclusiv nume, mrimea, format, surs,
importan, precum i o list a regulilor pentru a se asigura securitatea i controlul
datelor;
- o structur preliminar a datelor, prin care se va arta cum datele vor fi organizate n
nregistrri logice i care este legtura dintre date;
- descrierea modului de funcionare a noului sistem i a subsistemelor componente,
precum i a modului n care vor fi atinse obiectivele de ctre ntregul organism;
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 din el;
- o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte,
documente);
- descrierea unor norme interne de conduit privind raportrile, programarea
activitilor, securitatea i protecia, personalul implicat i zona de acces pe categorii
ale acestuia;
- prezentarea restriciilor existente n sistem, cum ar fi statutele i regulamentele de
organizare.

55

Sisteme informatice
CAPITOLUL 4
PROIECTAREA LOGIC A SISTEMELOR INFORMATICE
n cadrul acestui capitol este realizat prezentarea noului sistem prin prezentarea
tuturor intrrilor sistemului, a ieirilor, precum i a interfeelor i dialogurilor. Avnd n
vedere intrrile i ieirile sisemului este prezentat proiectarea logic a bazei de date,
activitate prin care se urmrete transformarea diagramelor entitate-relaie n relaii.
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, cum va funciona.
Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrrilor
sistemului, a ieirilor, precum i a interfeelor i dialogurile. Ele se construiesc pe baza a
ceea ce s-a identificat n etapele anterioare, dar inndu-se cont i de cerinele identificate
n timpul desfurrii activitilor din etapa de proiectare logic [1].
Toate intrrile i ieirile sistemului, n faza de proiectare logic, vor fi prezentate ca
fluxuri ale datelor ntre un proces manual i altul automat sau ntre o surs/ destinaie i
un proces automat din diagramele fluxurilor de date. De regul se poate proiecta cte un
formular sau raport pentru fiecare flux de date dintre utilizator i sistem.
Documentaia realizat n cadrul acestei etape constituie proiectul tehnic de
ansamblu al sistemului.
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. Ceea ce ne
propunem n cadrul proiectrii logice poate fi realizat cu ajutorul unui editor de texte sau
un produs program orientat spre grafic, sub forma unui prototip [1].

56

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 sunt inacceptabile, analistul trebuie s le modifice
[1].
Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator
l constituie macheta imprimantei [2].
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;
- 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 [2].
Alegerea tipului de suport fizic de ieire (imprimanta, display, disc fix, floppy disc,
banda magnetica 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 [2].
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.

57

Sisteme informatice
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.
Informaiile externe se refer la cele colectate sau create de la sau pentru parteneri strini
(facturi, rapoarte anuale, etc) [2].
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 [2].
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
[2].

58

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.
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 [2].
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 [2].
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.) [2].
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.

59

Sisteme informatice
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.
De exemplu, codul persoanei poate fi format din urmtoarele coduri elementare:
X
Iniiala
nume

X
Iniiala
prenume

X
Sex

XX
Ziua naterii

XXX
Luna naterii

XXXX
Anul
naterii

XX
Grupa
sanguin

Activitile parcurse n realizarea unui sistem de coduri sunt: [2]

analiza elementelor ce urmeaz a fi codificate;
precizarea i uniformizarea tehnologiei, a denumirilor;
stabilirea caracteristicilor i a relaiilor dintre elementele de codificat;
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. [2]
-

60

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
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 [2].
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.
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 operatorcalculator. Acest dialog se poate desfura sub form de [2]:

61

Sisteme informatice
-

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)
In 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 ntro 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).
Figura 4.1. Formularul(macheta) de intrare pentru facturi
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

62

Interfaa cu utilizatorul - reprezint o parte a aplicaiei software care permite

utilizatorilor s-si exprime inteniile de operare asupra calculatorului i s interpreteze
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 [1].
Metode de interaciune
Metodele cele mai utilizate sunt [1]:
- 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 [1]:
keyboard tastatura este format dintr-un set de butoane (taste) Prin intermediul ei
se introduc date, comenzo.
- Mouse.
- Joystick.
- Touch Screen atingerea ecranului constituie modalitatea prin care are loc selecia.
- 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.

63

Sisteme informatice
O modalitate de prezentare a secvenei dialogurilor este cea care apeleaz la
tehnica diagramelor. Ea va face trimitere la meniurile componente ale aplicaiei.
MO1

MENIU_PRINCIPAL

MO2
PO2
ADUGARE

PO1
MENIU_INTERO
GARE

TERGERE

PROCES
MENIU

PO4

PO3

I_DUP_AN

I_DUP_NUME

Figura 4.2. Structura unei diagrame de apelare a meniurilor [1].

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 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, fr s se
nregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului
aspect i se va acorda atenia cuvenit abia acum, odat cu modelarea logic a datelor,
descriindu-se structurile datelor din baz.
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

64

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, adic modelul relaional cel mai utilizat n prezent, dei se pot obine i
modelele 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);
- 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 entitiirelaie 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 [1].
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
- - - - - - - - - - - -65
---- -------- ------COD CLIENT:
1111
NUME CLIENT:
S.C. ALPHA S.R.L.
VOLUM:
1000

Sisteme informatice

Figura 4.3 Model de ecran solicitat de utilizatori [1]

Din analiza ecran ului 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:

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]

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)

66

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 (diagramaentitate-relaie) din aplicaie fr s se in cont de punctul de vedere al utilizatorului,
ntr-un set de relaii normalizate. Din analiza diagramei din figura 6.5 se desprind
urmtoarele relaii:

COD_CLIENT

NUME_CLIENT

ADRESA

NR_FACTURA

FACTURA

CLIENT

Lanseaz

Facturare
CANTITATE_LIV

NR_COMANDA

COMANDA

Livrar
e
67

Linie_comand

PRODUS

Sisteme informatice

Figura 4.5. Diagrama entitate-relaie pentru gestiunea clienilor [1]

Din analiza diagramei 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)
Aadar, 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

68

cauza normalizrii nu este necesar o coresponden unu-la-unu ntre entiti i relaii

[1].
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
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

69

Sisteme informatice
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:
- 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 BoyceCodd (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

70

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

71

Sisteme informatice
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
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 [13]:
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

72

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 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 [12], 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].
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

73

Sisteme informatice
Relaie
Tuplu
Atribut
Domeniu

Fiier(tabel)
nregistrare
Cmp
Tip de dat

Tablou
Linie
Coloan
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 [Popescu I, 1996]. De exemplu:
D1: {F,M}
-definire explicit
D2: {x| x N, x [0,100]}
-definire implicit
D3: {s|s=ir de caractere}
-definire implicit
Pentru un ansamblu de domenii D 1,D2,,Dn produsul cartezian al acestora
reprezint ansamblul tuplurilor (elemente ale unei relaii) <v1,v2,,vk> unde vi este un
element care aparine domeniului Di. De exemplu, tuplurile <Maria,F,50 >,<
Vasile,M,60> aparin produsului cartezian D 3xD1xD2.

Definirea relaiei
O relaie R pe mulimile D1,D2,,Dn este o submulime a produsului cartezian
D1xD2xxDn, deci o mulime de tupluri [Popescu I, 1996].
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:

D3
Maria
Vasile

D1
F
M

D2
50
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].

74

PERS D3
Maria
Vasile

D1
F
M

D2
50
60

D3
Vasile
Maria

Relaia PERS reprezint un subansamblu al produsului cartezian D 3xD1xD2xD3.

Atributul reprezint coloana unei tabele de date, caracterizat printr-un nume. Numele
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.
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]

75

Sisteme informatice
-

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.

76

CAPITOLUL 5
PROIECTAREA FIZIC A SISTEMELOR INFORMATICE
Proiectarea fizic cunoscut i sub numele de proiectare de detaliu, urmeaz
proiectrii logice. Proiectarea logic ntlnit i sub numele de proiectare general, o alt
variant de definire a proiectrii logice. De fapt, printr-o astfel de referire se scoate n
relief faptul c 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
datelor elementare ale unei organizaii sau ale unei pri din ea. Modelul se realizeaz n
faza de analiz [1].
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 sa 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, 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

77

Sisteme informatice
punct de vedere al coninutului i al prelucrrii. O nregistrare fizic este unitatea de
transfer ntre memoria intern i cea extern a calculatorului. Aceasta 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
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.

78

Partajarea datelor permite nlnuirea tranzaciilor solicitate simultan pe aceeai

nregistrare din baza de date, prin blocarea cererilor n ateptare i deservirea ulterioar a
acestora.
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
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,

79

Sisteme informatice
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 [12] 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
neautorizate, 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 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 [1].
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 [1].
Avnd n vedere aspectele prezentate mai sus, criteriile avute n vedere n alegerea
unui anumit tip de SGBD sunt [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;

80

Portabilitatea sistemului de gestiune privit prin prisma portabilitaii datelor se

refer la posibilitatea de a folosi o serie de date 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.
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

81

Sisteme informatice
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:
- 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>

82

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).
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 [Link], Denp,Ump,Cant,Pret,Cant*Pret FROM
Produse,Stocuri

83

Sisteme informatice
WHERE [Link]=[Link] 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>
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).
Unui utilizator i pot fi acordate mai multe tipuri de autorizri n cadrul unei singure
comenzi GRANT.

84

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.
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 [Link] 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 [Link] 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 [Link](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 [Link] FROM Ionescu

85

Sisteme informatice
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)
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
[Link]=[Link] )
(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).
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

86

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).

ORCL

87
Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system

Sisteme informatice

Figura 5.2. Creare utilizator U1 i acordare privilegii CONNECT, RESOURCE

88

ORC
L

Figura 5.4. Creare tabel Produse i inserare dou nregistrri

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>]

89

Sisteme informatice
[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>
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}

90

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.)
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)

91

Sisteme informatice
SELECT CodDep,CodP,MAX(Pret) FROM Stocuri
GROUP BY CodP HAVING MAX(Pret) < 150000
(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
2>[ASC]|DESC,
Exemplu:
SELECT * FROM Persoane ORDER BY Datan DESC,Nume

atribut

(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).
Pentru exemplificare pe lng tabela Stocuri mai considerm tabela Produse(CodP, DenP,
DesP).
SELECT [Link],DenP,UmP,Cant,Pret FROM Produse,Stocuri
WHERE [Link] = [Link]
(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).

92

Fiecrei tabele i se poate atribui un alias astfel nct fraza de mai sus este echivalent cu
fraza:
SELECT [Link],DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE [Link] =
[Link]
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 [Link],[Link],[Link] FROM Stocuri A
WHERE [Link] = (SELECT MIN([Link]) FROM Stocuri B WHERE [Link] =
[Link])
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 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 [Link],[Link],[Link] FROM Stocuri A
WHERE [Link] = (SELECT MIN([Link]) FROM Stocuri B WHERE [Link] =
[Link])
Sub-interogri simple care returneaz o singur valoare - pot fi utilizate n
interogri imbricate avnd sintaxa:
SELECT <lista atribute> FROM <lista relaii>
WHERE <atribut> =
<
>

93

Sisteme informatice
<=
>=
!=
(<sub-interogare>)
[ORDER BY <atribut[ASC]|DESC,]
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 imbricat care utilizeaz n clauza WHERE codiii 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,ComenziWHERE [Link]=Ionescu
AND
Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar))
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 [Link]=[Link])
va returna o list de produse care nu au nici o nregistrare n Stocuri.
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

94

programatorii, pentru transpunerea n realitate a proiectului. Ei vor controla intrrile,

prelucrrile i ieirile din sistem prin intermediul programelor [1].
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.
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 [1].
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 [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;
- 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 de programare, dei mai corect ar fi s se
numeasc tehnici de programare [1].
Metoda programrii clasice are la baz construirea monolitic a logicii
programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat

95

Sisteme informatice
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].
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 [1].
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

96

recomand evitarea conjunciilor din structura numelor, deoarece ele ar sugera necesitatea
folosirii mai multor module [1].
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 [1].
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 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 [1].
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 [1].
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, alternativ (simpl i generalizat), 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 [1].
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. Structura secvenial (liniar) se
prezint astfel [1]:

97

Sisteme informatice

s1
s2
sn
Figura 5.1. Structura secvenial [1]
Selecia (structura de tip IF-THEN-ELSE) sau structura alternativ are urmtoarea
form de prezentare [1]:

NU

DA

C
Bloc - 2

Bloc

Figura 5.2. Structura alternativ [1]

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.3).

98

Bloc - 1

Bloc - n

Bloc - 2

Figura 5.3. Structura alternativ generalizat [1]

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) se reprezint ca n
figura 5.4

Bloc 1
C
N
U

D
A

Figura 5.4. Structura repetitiv condiionat anterior [1]

Structura repetitiv condiionat posterior (de tip DO UNTIL) are forma dinn
figura 5.5.

99

Sisteme informatice

Bloc - 1

DA
NU

Figura 5.5. Structura condiionat posterior [1]

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.6.

V=Vi

Bloc - 1

V=Vi+
R
V>Vf

NU
DA

100

Figura 5.6. Structura repetitiv cu numr definit de pai [1]

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 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: 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 [2].
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.
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 aciunile [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.

101

Sisteme informatice
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
i i coordoneaz activitile pentru realizarea unui anumit scop. Cu alte cuvinte un
sistem de prelucrare distribuit a datelor permite realizarea activitii de prelucrare
automat a datelor ntr-un mediu de reea. 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].

Legtur/canal
NOD

NOD

Figura 5.7. Model de baz al unui sistem de prelucrare distribuit a datelor.

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. Din punct de vedere funcional, scopul este s se realizeze un sistem care s
aib cele mai bune rezultate [1].
Costul sistemului se regsete n costurile iniiale pe procesoare,
perifericelor(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);
-

102

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.
Trebuie s se in seama de posibilitatea proiectrii, dup ce anumite etape au fost
ndeplinite [1].

Sisteme PAD

Proiectare
NODURI
Proiectare
INTERFEE

Proiectare
subsisteme
de
COMUNICAII

Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuit a

datelor [1]
Modele de sisteme distribuite
Calculatoarele personale i staiile de lucru pot fi utilizate fie ca sisteme de-sinestttoare 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,
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

103

Sisteme informatice
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.

Cerere
Client
partajate)

Surs de informaie (Baz de date)

Procesare (Logic i Aritmetic)
Server
Dispozitive (Imprimant, periferice

Rezultatul

Servicii(Cereri adiionale altor

servere)
ndeplinirii cererii
Figura 5.9. 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
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 mari 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:

104

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.
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.
Problem rezolvat
Se consider baza de date FurnizoriClieni care conine urmtoarele tabele (n
ACCESS):
PRODUSE (catalog de produse)

105

Sisteme informatice
Cmp

Semnificaie

Tip dat

Dimensiune

Observaii

Codp

Cod produs

Number, Integer

Cheie primar

Denp

Denumire produs

Text

20

Desp

Descriere produs

Hyperlink

Refer document
corespunztor

STOCURI (stocurile de produse pe depozite)

Cmp

Semnificaie

Dimensiune

Observaii

Cod produs

Tip dat
Number, Integer
Lookup Wizard

Codp

Lookup Wizard cu
tabela PRODUSE

CodDep

Cod depozit

Text

Ump

Unitate
de Lookup Wizard
msur produs

Cant

Cantitate

Number, Integer

Pret

Pre unitar

Number,
LongInteger

Creare i utilizare
list de valori

FURNIZORI (catalog de furnizori)

Cmp

Semnificaie

Tip dat

Dimensiune

Observaii

Codf

Cod furnizor

Number, Integer

Cheie primar

Denf

Denumire
furnizor

Text

30

Adresaf

Adresa furnizor

Text

25

CLIENTI (catalog de clieni)

106

Cmp

Semnificaie

Tip dat

Dimensiune

Observaii

Codc

Cod client

Number, Integer

Cheie primar

Denc

Denumire client

Text

30

Adresac

Adresa client

Text

25

OFERTE (oferte de produse de la furnizori)

Cmp

Semnificaie

Tip dat
Number, Integer
Lookup Wizard

Dimensiune

Observaii

Codf

Cod furnizor

Lookup Wizard cu
tabela FURNIZORI

Codp

Cod produs

Number, Integer
Lookup Wizard

Lookup Wizard cu
tabela PRODUSE

Ump

Unitate
de Lookup Wizard
msur produs

Creare i utilizare
list de valori

Pret

Pre unitar

Number,
LongInteger

Datao

Data ofertei

Date

Oferta

Oferta furnizor

Hyperlink

Refer document
corespunztor

VANZARI (vnzrile de produse pe clieni)

Cmp

Semnificaie

Tip dat
Number, Integer
Lookup Wizard

Dimensiune

Observaii

Codc

Cod furnizor

Lookup Wizard cu
tabela CLIENTI

Codp

Cod produs

Number, Integer
Lookup Wizard

Lookup Wizard cu
tabela
PRODU,03SE

Ump

Unitate
de Lookup Wizard
msur produs

Creare i utilizare
list de valori

Cant

Cantitate

Number, Integer

Pret

Pre unitar

Number,
LongInteger

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

107

Sisteme informatice
a) Situaia stocurilor
CodDep
Cmp
Stocuri
Tabela
b)Situaia ofertelor

Codp
Stocuri

Denp
Produse

Ump
Stocuri

Cant
Stocuri

Pret
Stocuri

Valoare
Cant*Pret

Denf
Adresaf
Codp
Denp
Ump
Pret
Cmp Codf
Tabela Furnizori Furnizori Furnizori Produse Produse Oferte Oferte
c) Situaia vnzrilor

Datao
Oferte

Denc
Adresac Codp
Denp
Ump
Cant
Pret
Valoare
Cmp Codc
Produse Produse Vanzari Vanzari Vanzari Cant*Pret
Tabela Clienti Clienti Clienti
d) Lista produselor pentru care nu exist oferte
Cmp
Tabela

Codp
Produse

Denp
Produse

e) Lista produselor pentru care nu s-au fcut vnzri n perioada [Data1,Data2]

Cmp
Tabela

Codp
Produse

Denp
Produse
Rspuns:

a)
SELECT CodDep, [Link], Denp, Ump, Cant, Pret, Cant*Pret AS Valoare
FROM Stocuri, Produse WHERE [Link] = [Link]
b)
SELECT [Link], Denf, Adresaf, [Link], Denp, Ump, Pret, Datao
FROM Oferte, Produse,Furnizori
WHERE [Link] = [Link] AND [Link] = [Link]
c)
SELECT [Link], Denc, Adresac, [Link], Denp, Ump,Cant, Pret,
Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,Clienti
WHERE [Link] = [Link] AND [Link] = [Link]
d)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Oferte WHERE [Link]=[Link])
e)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Vanzari WHERE [Link]=[Link]
AND Datav BETWEEN Data1 AND Data2)

108

Datav
Vanzari

Teste 2009
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 reprezint un ansamblu de identificatori care au rolul sa rezolve
activiti specifice.
Rspuns: a
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,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.
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;

109

Sisteme informatice
b)
c)
d)
e)

Manager general;
Baza tehnic;
Baza tiinific metodologic;
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. Sistemele informatice economice pot fi mprite dup modul de organizare a datelor
n:
a) sisteme imagine;
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;

110

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 manier comun n care analitii de sisteme,
programatorii i alte categorii de persoane implicate realizeaz procesul de analiza a
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

111

Sisteme informatice
15. Propunerile pentru identificarea proiectelor de dezvoltare sunt fcute de:
a) top-managerii;
b) personalul auxiliar;
c) muncitori;
d) departamentul utilizatorilor.
Rspuns: a, d
16. Selecia proiectelor de dezvoltare a sistemelor informaionale, urmrete:
a) atingerea obiectivelor organizaiei;
b) bunul mers a informaiei;
c) creterea duratei de implementare.
Rspuns: a
17. 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
18. 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
19. 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
20. Studiile de fezabilitate trebuie s conin:
a) Definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i
propune el s realizeze);
b) Descrierea cerinelor sistemului;
c) Explicaia critic a motivrii studiului ntreprins;
d) Cuantificarea tuturor costurilor materiale i beneficiilor aferente.
Rspuns: a, b, c, d

112

21. 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
22. 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
23. 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
24. Definirea caracteristicilor generale ale sistemului economic implic:
a) cunoaterea profilului, obiectivelor agentului economic;
b) cunoaterea locului n sfera serviciilor i sfera produciei;
c) cunoaterea relaiilor de cooperare cu ali ageni economici;
d) cunoaterea specificului activitii de baz ( producie, servicii).
Rspuns: a, b, c, d
25. 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
26. Metodele tradiionale de determinare a cerinelor sistemelor sunt:
a) interviul;
b) prototipizarea;

113

Sisteme informatice
c) Joint Application Design (JAD);
d) chestionarul.
Rspuns: a, d
27. 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
28. 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
29. Identificai afirmaia fals:
a) Diagrama de context scoate n eviden aria de ntindere a sistemului analizat;
b) Diagrama fluxului de date ale nivelului logic curent, independent de
tehnologie, reliefeaz 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
30. Simbolul folosit n diagramele DFD realizate cu SSADM (Structured Systems
Analysis and Design Methodology), pentru reprezentarea fluxului de date sunt:
a) sgeat;
b) elips;
c) cerc.
Rspuns: a
31. Cte entiti externe conine diagrama de context pentru aplicaia Decontri:

114

patru entiti;

b) cinci entiti;

c) nici o entitate.
Rspuns: b

32 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;
c) o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte,
documente).
Rspuns: b, c
33. 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
34. 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

35. n DER pentru fiecare entitate reprezentat se apeleaz la simbolul:

115

Sisteme informatice
a)
b)
c)
d)

cerc;
sgeat;
romb;
dreptunghi.
Rspuns: d

36. Nu sunt tipuri de relaii:

a) relaia unu-la-unu;
c) relaia absolut;
nsi.

b) relaia unu-la-multe;
d) relaia unei entiti cu ea
Rspuns: c

37. 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
38. 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
39. 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
40. Macheta imprimantei cuprinde:
a) antet;
b) titlu;
c) date elementare ce se imprima rnd de rnd;
d) totalurile.
Rspuns: a, b, c, d
41. Detaliile i indicaiile tehnice de realizare a machetei imprimantei se refer la:

116

a) volumul datelor de ieire;

b) intensitatea datelor;
c) contrast.
Rspuns: a
42. 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
43. 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.
Rspuns: a, b, c, d
44. 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
45. 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
46. Macheta documentului de intrare conine:
a) antetul documentului;
b) diagrama fluxului de date;
c) denumirea documentului.
Rspuns: a, c
47. Nu sunt metode de interaciune om main:
a) interaciunea permanent,

117

Sisteme informatice
b) interaciunea prin meniuri,
c) interaciunea bazat pe obiecte icons,
d) interaciunea prin limbaj natural.
Rspuns: a
48. Echipamentele necesare interaciunii cu sistemul sunt:
a) eyescreen;
b) keyboard;

c) mouse.

Rspuns: b, c
49. 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

50. n procesul de modelare logic a datelor sunt pai eseniali:

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
51. Nu sunt elemente de baz ale structurii relaionale a datelor:
a) Relaia;
b) Atributul;
c) Fiierul;
d) Domeniul;
e) Tuplul.
Rspuns: c
52. 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
53. 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

118

54. Proiectarea fizic a sistemelor informatice implic:

a) proiectarea fizic a bazelor de date i a fiierelor.
b) proiectarea structurii sistemului i a programelor.
c) proiectarea documentaiei sistemului analizat.
d) proiectarea strategiilor de prelucrare distribuit.
Rspuns : a, b, d
55. 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
56. 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
57. Structura repetitiv condiionat anterior este:
a) de tip WHILE-DO;
b) de tip DO UNTIL;
c) de tip DO FOR.
Rspuns : a
58. Nu sunt metode de programare:
a) metoda programrii clasice;
b) metoda programrii structurate;
c) metoda programrii orientate-obiect;
d) metoda programrii iterative.
Rspuns : d
59. Un modul are componente de baz:
a) funcia;
b) schema;
c) logica;
d) interfeele.
Rspuns : a, c, d
60. Funcia unui modul const n:
a) transformarea datelor prin procesul de execuie a acestuia.

119

Sisteme informatice
b) descrierea prelucrrilor care au loc n interiorul acestuia.
c) legtura cu alte module.
Rspuns : a
61. Realizarea modular a programelor corespunde principiilor:
a) programrii clasice;
b) programrii structurate;
c) bazelor de cunotine;
Rspuns : b
62. 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
63. 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
64. 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
65. 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
66. 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)
67. Normalizarea unei relaii const n:

120

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)
68. 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;
b) structura global de organizare a datelor.
Rspuns: a), b)
69. 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)
70. Obiectivul principal al instrumentelor CASE este:
a) Punerea n practic a produselor-program de proiectare i realizare a softului
cu ajutorul calculatorului.
b) Simplificarea activitilor de proiectare i realizare a sistemelor/ aplicaiilor.
c) Aducerea n faa analistului a problemelor supuse analizei.
d) Folosirea depozitelor modularizate.
Rspuns: a
71. 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
72. Instrumentele CASE se bazeaz pe:
a) o funcie fundamental;
b) dou funcii fundamentale;
c) mai multe funcii fundamentale.
Rspuns: b
73. Caracteristicile mediilor moderne de tip CASE sunt:
a) integrarea;
b) aranjarea;
c) descompunerea;
d) exploatarea.

121

Sisteme informatice
Rspuns: a, c
74. 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
75. Nu sunt corecte urmtoarele afirmaii:
a) CASE reprezint Proiectarea Sistemelor Asistat de Calculator;
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
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.
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.
10. Descriei tipurile de legturi care pot exista ntre dou mulimi de entiti.

122

11. Definii cheia unei relaii.

12. ENUMERAI METODE MODERNE DE ANALIZ I DETERMINAREA
CERINELOR SISTEMULUI.
Rspuns:

- JAD (Joint Application Design);

- Prototipizarea.
13. ENUMERAI ARHITECTURILE DE BAZ PENTRU UN SISTEM CLIENTSERVER 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.
14. 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.
15. 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.
16. 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.

123

Sisteme informatice
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.
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.
17. 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.

124

BIBLIOGRAFIE
[1] Oprea D. Analiza i proiectarea sistemelor informaionale economice, Ed.
POLIROM, Iai, 1999
[2] Chindea M. E. Proiectarea sistemelor informatice economice, Bucureti, 1999
[3] Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureti
2000
[4] Vasilescu P., Dunca V. Proiectarea sistemelor informatice, Ed. Tehnic,
Bucureti, 1979
[5] Popescu I. Baze de date relaionale: proiectare i implementare, Ed. Universitii
din Bucureti, Bucureti, 1996
[6] Balan D., Balan G. Sistemul informaional n gestionarea ntreprinderilor, Ed.
Junimea, Iai, 1998
[7] Roger J. - Utilizare ACCESS 95, Ed. Teora, Bucureti, 1995
[8] Udric M. Modelarea orientat obiect, Ed. Cison, Bucureti, 2000

[9] Brnzei R. Sisteme informatice, Ed. Universitii Al. I. Cuza, Iai, 1995
[10] Robert Dollinger-Baze de date i gestiunea tranzaciilor, ClujNapoca, 1998
[11] N. Morariu, V. Lupu, O. Hurjui, Baze de date, ISBN 973-8293-83-9, Editura Univ.
tefan cel Mare Suceava,117 p, Suceava, 2003.
[12] N. Morariu, Baze de date. ndrumar de laborator, ISBN 973-666-159-8, Editura
Univ. tefan cel Mare Suceava, 88 p, Suceava, 2005.
[13] M. Cristescu, Baze de date utilizate n mediul economic, Editura ALMA MATER,
Sibiu, 2007;
[14] M. Cristescu, Baze de date post-relationale, Editura Universit ii Lucian Blaga
din Sibiu, Sibiu, 2008.

125