Proiectarea Sistemelor Informatice

Nicolae Morariu
PROIECTAREA
SISTEMELOR
INFORMATICE
Lect. univ. dr.Nicolae Morariu
DISCIPLINĂ DE SPECIALITATE LA SPECIALIZAREA
CONTABILITATE ŞI INFORMATICĂ DE GESTIUNE
Contabilitate şi informatică de gestiune 1

Proiectarea sistemelor informatice
CUPRINS
Capitolul 1
Sisteme informatice………………………………………………………………..…….….. 3
1.1. Sistem, Sistem informaţional, Sistem informatic……………………………………. 3

1.1.1. Componentele sistemului informatic…………………………………………… 5
1.1.2. Clasificarea sistemelor informatice………………. …………………………… 6
1.1.3. Obiectivele sistemelor informatice....................................................................... 7
1.1.4. Ciclul de viaţă a unui sistem informatic.....…………………………………….. 7
1.1.5. Conţinutul bazei informaţionale a unei întreprinderi ………………………...… 9
1.1.6. Ciclul prelucrării datelor pentru sistemul informatic………………………….... 9
1.1.7. Sistemele informatice de gestiune ……………………...……………………… 10
1.2. Metodologii de realizare a sistemelor informatice…………….……...……………... 11
1.2.1. Conţinutul metodologiilor de realizare a sistemelor informatice...…….………. 11
1.2.2. Metode şi tehnici de realizare a sistemelor informatice ..……….……………... 12
1.3. Instrumente CASE........................................................................................................ 14
1.3.1. Funcţiile CASE ……………………………….................................................... 15
1.3.2. Trăsături definitorii ale CASE-ului....................................................................... 15
1.3.3. Exemple de instrumente CASE .........................……………..………………… 16
Capitolul 2
Iniţierea şi planificarea realizării unui sistem informatic...…………………….…………… 18
2.1. Identificarea, selecţia, iniţierea şi planificarea proiectelor..…………………………. 18

2.2. Analizele de fezabilitate……….…………. …………………………………….. ..... 20
2.3. Tehnici de reprezentare a planurilor şi programarea calendaristică............................. 21
Capitolul 3
Analiza sistemului existent şi definirea cerinţelor noului sistem........……………................ 23
3.1. Studiul sistemului informaţional existent………………...……………………….…. 23

3.2. Determinarea cerinţelor sistemului ……………..…………………………................ 24
3.2.1. Metodele tradiţionale utilizate în analiza şi determinarea cerinţelor 25
sistemului..
3.2.2. Metode moderne de analiză şi determinare a cerinţelor sistemului…………….. 25
3.3. Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor……... 26
3.3.1. Diagramele fluxurilor de date (DFD)……………..…………………………… 27
3.3.2. Descompunerea funcţională şi rafinarea DFD………………………………….. 28
3.3.3. Modelarea sistemului current………………………………………………….... 31
3.3.4. Modelarea logicii proceselor………………………………………………….... 33

Nicolae Morariu
3.4. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)........................ 35

3.4.1. Modelul Entitate/Relaţie (E/R)............................................................................. 43
3.5. Selectarea celei mai bune variante strategice de proiectare …………..…………….. 47
Capitolul 4
Proiectarea logică a sistemelor informatice.......................................................................................... 48
4.1. Proiectarea formularelor/formatelor şi a rapoartelor................................................................ 48

4.1.1. Proiectarea situaţiilor cu rezultate finale (rapoartelor)………………............................. 48
4.1.2. Proiectarea codurilor………… …………………….………………………….….……. 51
4.1.3. Proiectarea intrărilor în sistemul informatic....................................…….………….…... 52
4.2. Proiectarea interfeţelor şi a dialogurilor ………….………...…………..…………….…….. 54
4.3. Proiectarea logică a bazelor de date………………….……………………………………… 55
4.3.1. Normalizarea relaţiilor - Forme normale.............................................................. 59
4.3.2. Simplificarea structurii datelor prin normalizare……………………………….. 63
4.3.3. Transformarea diagramelor entitate-relaţie în relaţii…………………………… 65
Capitolul 5
Proiectarea fizică a sistemelor informatice…………….……….......................................................... 66
5.1. Proiectarea fizică a bazelor de date şi a fişierelor..................................................................... 66

5.1.1. Obiectivele fundamentale ale unei baze de date................................................... 67
5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)…..………………………….. 67
5.1.3. Administratorul bazei de date…………………………………………………... 68
5.1.4. Proiectarea securităţii bazelor de date şi a fişierelor……………………..…….. 69
5.1.5. Limbajul SQL – crearea, administrarea, interogarea bazelor de date 70
relaţionale.
5.2. Proiectarea programelor şi a procedurilor………………………………..….……….............. 81
5.2.1. Atributele modulelor......................................................................................................... 82
5.2.2. Structurile de control ale programelor.............................................................................. 83
5.2.3. Proiectarea şi realizarea 87
programelor...............................................................................
5.3. Proiectarea sistemelor 87
distribuite.............................................................................................
Teste 2006............................................................................................................................... 93
Bibliografie.............................................................................................................................. 107

CAPITOLUL 1. SISTEME INFORMATICE
1.1. Sistem, Sistem informaţional, Sistem informatic

Un sistem reprezintă un ansamblu de elemente (componente) interdependente
între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul
atingerii unui anumit obiectiv [4]. Conform teoriei sistemelor orice organism economic
este un sistem.
Organizaţie – o intreprindere, instituţie, societate comercială.
În orice organizaţie se disting 3 componente:
- sistemul de conducere sau de decizie;
- sistemul informaţional;
- sistemul operaţional.
Sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe
utilizate în cadrul organizaţiei precum şi datele care au stat la baza obţinerii lor,
procedurile şi tehnicile de obţinere a informaţiilor (plecând de la datele primare) şi de
difuzare a informaţiilor, precum şi personalul implicat în culegerea, transmiterea, stocarea
şi prelucrarea datelor.
Sistemul informaţional are două componente:
- componenta pentru stocarea (memorarea informaţiilor);
- componenta pentru prelucrarea informaţiilor.
Orice organizaţie interacţionează cu alte organizaţii externe ei primind informaţii
din exterior şi furnizând informaţii către lumea exterioară.
Funcţiile unui sistem informaţional sunt:
- să colecteze informaţii din sistemele operaţional şi decizional precum şi
informaţiile ce provin din mediul extern;
- să memoreze aceste informaţii precum şi informaţii rezultate din prelucrarea
lor;
- să asigure accesul la memorie în vederea comunicării informaţiilor stocate;
- să prelucreze informaţiile la cererea sistemului operaţional şi a sistemului de
conducere.
Noţiunea de sistem informatic este legată de informatizarea activităţii
organizaţiei, deci folosirea echipamentelor hardware şi a produselor software pentru
organizarea şi administrarea informaţiilor. Utilizarea calculatoarelor în cadrul sistemului
informaţional (SI) al unei organizaţii conduce la definirea componentei Sistem
Informaţional Automatizat (SIA) – care cuprinde numai lucrările realizate cu ajutorul
calculatoarelor. Relaţia SI – SIA este reprezentată în figura 1.1.

Nicolae Morariu
Sistem informatizat Procesor de informaţii Informaţie Reguli
Sistem
Reguli şi
Om Fişiere
manual proceduri
manuale
scrise
Programe şi
Sistem Fişiere
Calculator Structuri de
automatizat informatice date
Fig. 1.1. Relaţia SI – SIA (Sursa: [10])
Definiţie.
Un sistem informatic este un sistem utilizator-calculator integrat, care furnizează
informaţii pentru a sprijini activităţile de la nivel operaţional şi activităţile de
management într-o organizaţie, utilizând echipamente hardware şi produse software,
proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare,
control şi luarea deciziilor [10].
Elaborarea sistemelor informatice impune modelarea sistemului informaţional al
organizaţiei cu ajutorul unui formalism prin care să poată fi reprezentată cât mai sugestiv
şi fidel realitatea din cadrul sistemului informaţional.
Sistemele informatice complexe pot fi descompuse în subsisteme, care la rândul
lor pot fi descompuse în aplicaţii destinate unor categorii de utilizatori, aplicaţii care la
rândul lor pot fi constituite din unul sau mai multe programe scrise în diverse limbaje de
programare după cum este ilustrat în figura 1.2.
Sistem Informatic
Subsistem 1 Subsistem 2 Subsistem n

……
Aplicatia 2.1 Aplicatia 2.k

…
.
Program Program 2.k.s

2.k.1 …

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

Pentru organizaţii de complexitate mică, informatizarea poate însemna realizarea
unei singure aplicaţii informatice referită de asemenea ca sistem informatic.
Sistemele, subsistemele şi aplicaţiile informatice sunt produse informatice numite
şi produse software.
Un produs informatic este constituit din programe care accesează baza de date şi
din documentaţia necesară pentru utilizarea şi întreţinerea programelor. Acestea se
realizează în baza unor metodologii şi necesită parcurgerea unor etape începând cu
specificarea cerinţelor şi terminând cu implementarea, exploatarea şi întreţinerea lor.
Sistemul informatic economic este un ansamblu structurat de elemente
intercorelate funcţional pentru automatizarea procesului de obţinere a informaţiilor şi
pentru fundamentarea deciziilor. Sistemul informatic este inclus în sfera sistemului
informaţional atâta vreme cât în cadrul sistemului informaţional vor exista o serie de
activităţi care nu vor putea fi automatizate [2].
1.1.1. Componentele sistemului informatic

Un sistem informatic este compus din [2]:
- baza informaţională;
- baza tehnică;
- sistemul de programe;
- baza ştiinţifică şi metodologică;
- factorul uman (resursele umane);
- cadrul organizatoric.
Baza informaţională cuprinde:
- datele supuse prelucrării;
- fluxurile informaţionale;
- sistemele şi nomenclatoarele de coduri.
Baza tehnică este constituită din totalitatea mijloacelor tehnice de culegere, transmitere,
stocare şi prelucrare a datelor, locul central revenind calculatoarelor electronice.
Sistemul de programe cuprinde totalitatea programelor utilizate pentru funcţionarea
sistemului informatic în concordanţă cu funcţiunile şi obiectivele stabilite. Sunt avute în
vedere atât programele de bază (software de bază) cât şi programele aplicative (software
de aplicaţie).
Baza ştiinţifică şi metodologică este constituită din:
- algoritmi;
- formule;
- modele;
- tehnici de realizare a sistemelor informatice.
Resursele umane constau din:
- personalul de specialitate: analişti, programatori, ingineri de sistem, analişti-
programatori ajutori, operatori, etc.;
- beneficiarii sistemului.

Nicolae Morariu
Cadrul organizatoric este cel specificat în regulamentul de organizare şi funcţionare

(ROF) al unităţii în care va fi utilizat sistemul informatic.
La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere reţele,
echipamente, produse software de bază, produse software de aplicaţie.
Reţele
după aria de întindere geografică:
- Locale =LAN (Local Area Network) – la nivelul unei organizaţii;
- Metropolitane –MAN (Metropolitan Area Network) – la nivel de oraş, localitate;
- De mare întindere -WAN (World Area Network) (ex. Judeţ, Ţară).
după accesibilitate:
- Internet (reţeaua Web) – o colecţie mondială de reţele interconectate;
- Intranet – un sit Web sau un grup de sit-uri care aparţin unei organizaţii, accesibil numai
pentru membrii acesteia;
- Extranet – o reţea intranet care este parţial accesibilă utilizatorilor externi autorizaţi.
Echipamente
- Echipamente de calcul : calculatoare, staţii grafice, pentru servere de reţea, servere de
baze
de date, staţii de lucru (clienţi, utilizatori), UPS-uri.
- Echipamente de comunicaţie : router-e, hub-uri, modem-uri, switch-uri.
Produse software
Produse software de bază:
- Sisteme de operare pentru serverul de reţea (UNIX, Windows NT server, Windows
2000, Novell) şi pentru staţiile de lucru sau clienţi (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
aplicaţiilor din domeniul cadastrului (stocarea şi prelucrarea datelor spaţiale );
- Limbaje (medii) de programare – utilizate pentru realizare software de aplicaţie.
Produse software de aplicaţie – produse program ce constituie aplicaţiile şi
subsistemele sistemului informatic.
1.1.2. Clasificarea sistemelor informatice

Sistemele informatice se clasifică după mai multe criterii.
1. În funcţie de domeniul de utilizare, sistemele informatice pot fi pentru :
conducerea activităţilor economico-sociale
conducerea proceselor tehnologice
cercetare ştiinţifică şi proiectare tehnologică
activităţi speciale.
2. În funcţie de nivelul ierarhic ocupat de sistemul economic în structura
organizatorică a societăţii, conform căruia există sisteme informatice [2]:

pentru conducerea activităţii la nivelul unităţilor economice

pentru conducerea activităţii la nivelul organizaţiilor economico-sociale cu structură
de grup
sisteme informatice teritoriale
pentru conducerea ramurilor, subramurilor şi activităţilor la nivelul economiei
naţionale
sisteme informatice funcţionale generale .
3. În funcţie de elementul supus analizei [Oprea D., 1999]:
sisteme informatice orientate spre funcţii;
sisteme informatice orientate spre proces;
sisteme informatice orientate spre date;
sisteme informatice orientate spre obiecte;
sisteme informatice orientate spre cunoştinţe.
4. După modul de organizare a datelor [[1] D., 1999]:
sisteme bazate pe fişiere;
sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţionale, orientate-
obiect;
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 reţea locală, staţii de lucru):
sisteme informatice distribuite (date distribuite).
8. După gradul de automatizare a activităţilor de analiză şi proiectare a sistemelor
informatice [1]:
sisteme informatice dezvoltate pe baza analizei şi proiectării clasice;
sisteme informatice analizate cu instrumente automate şi proiectate clasic;
sisteme informatice bazate pe instrumente diverse de automatizare a analizei şi
proiectării;
sisteme informatice dezvoltate cu instrumente de tip CASE.

Nicolae Morariu
1.1.3. Obiectivele sistemelor informatice

Plecând de la ideea că sistemul informatic este subordonat procesului decizional, al
cărui rol este de a asigura funcţionarea normală şi optimă a întregii activităţi şi de a
reduce la minimum pierderile în caz de funcţionare anormală, rezultă că obiectivul
oricărui sistem informatic trebuie să fie subordonat obiectivului propriu-zis al unităţii
economico-sociale. În acest context, obiectivul principal urmărit prin introducerea unui
sistem informatic îl constituie asigurarea conducerii cu informaţii reale şi în timp util,
necesare fundamentării şi elaborării operative a deciziilor [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 realizării unui nou SI care să corespundă mai bine noilor cerinţe ale utilizatorilor
şi se încheie cu decizia de înlocuire a SI existent cu unul nou, mai performant. Ciclul de
viaţă se desfăşoară pe etape în cadrul fiecăreia fiind definite faze şi activităţi specifice
[4].
Încă de la început facem menţiunea că, indiferent de etapa istorică sau
metodologică, sistemele sunt abordate prin prisma ciclului lor de viaţă. Ele apar se
dezvoltă, descresc şi pier, sau printr-un nou ciclu, se perfecţionează, dând naştere unei
alte versiuni sau chiar unui nou sistem. Mutaţiile din domeniul tehnologiei informaţionale
şi al metodelor de abordare a sistemelor s-au reflectat şi în ciclul de viaţă al dezvoltării
sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de
parcurgere a lor. Spre exemplu, odată cu abordarea orientată-obiect a sistemelor, s-au
lansat şi noi modele ale ciclului de viaţă [4].
Prin parcurgerea materialelor de specialitate, se poate constata că numărul
fazelor/etapelor variază de la trei (de exemplu analiza, proiectarea, implementarea) la
peste douăzeci.
Există mai multe modele ale ciclului de viaţă, multe dintre ele cunoscând o evoluţie
în timp. Spre exemplu, modelul cascadă (figura 1.3) prevede parcurgerea mai multor
etape ale ciclului de viaţă care se derulează secvenţial fiind însă permisă la nevoie
revenirea la etapa parcursă anterior în vederea îndepărtării neajunsurilor identificate în
etapele superioare ale ciclului de viaţă [4].
Etape ale ciclului de viaţă a unui sistem informatic în modelul cascadă ([10])
1. Analiza şi definirea cerinţelor – sunt definite scopurile, serviciile şi
restricţiile pe care trebuie să le îndeplinească sistemul informatic, prezentate într-o
manieră încât să poată fi înţelese atât de către utilizatorii sistemului cât şi de personalul
de proiectare.
2. Proiectarea sistemului şi software-ului – satabilirea cerinţelor pentru
hardware şi software şi elaborarea arhitecturii generale a sistemului. Funcţiile sistemului
informaţional vor fi reprezentate astfel încât să poată fi tranformate în unul sau mai multe
programe executabile.
3. Implementarea şi testarea unităţilor de program – proiectarea software-ului
din etapa anterioară este transpusă într-o mulţime de programe sau module programşi
verificarea faptului că fiecare program sau modul satisface specificaţia sa.

4. Integrarea şi testarea sistemului – integrarea şi testarea programelor şi

modulelor program ca un sistem complet pentru a ne asigura că cerinţele informaţionale
sunt satisfăcute. După testare sistemul este livrat beneficiarului.
5. Exploatarea şi întreţinerea sistemului – este faza în care sistemul informatic
este efectiv utilizat de către beneficiar şi în care sunt descoperite şi rezolvate eventuale
erori de proiectare şi programare şi omisiuni în cerinţele informaţionale iniţiale.
Analiza şi
definirea
cerinţelor
Proiectarea
sistemului şi a
software-ului
Implementarea
şi testarea
unităţilor de
program
Integrarea şi
testarea
sistemului
Exploatarea şi
întreţinerea
sistemului
Fig. 1.3. Etapele ciclului de viaţă a unui sistem informatic în modelul cascadă ([10])

Nicolae Morariu
1.1.5. Conţinutul bazei informaţionale a unei întreprinderi

Prin analiza critică sunt identificate entităţile bazei informaţionale. În principal,
pentru o întreprindere acestea pot fi grupate după cum urmează:
pentru activitatea de aprovizionare: stocuri de materiale, intrări materiale, consumuri
de materiale, contracte cu furnizorii, programe de aprovizionare;
pentru activitatea de producţie: tehnologii şi reţete de fabricaţie, program de lucru,
norme de muncă şi consumuri de manopere;
pentru activitatea de desfacere: stocuri de produse, contracte cu clienţii, realizări
contracte;
pentru activitatea de marketing: evoluţia cererii şi a ofertei, dinamica preţurilor,
elasticitatea cererii şi a producţiei;
pentru activitatea financiar-contabilă: solduri şi rulaje contabile, calculaţia costurilor,
bugete de venituri şi cheltuieli, contabilitatea analitică şi sintetică;
pentru activitatea de personal: evidenţa personalului, salarizări, dotări social-culturale
şi gestiunea lor;
pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte tehnice,
investiţii, etc.
1.1.6. Ciclul prelucrării datelor pentru sistemul informatic

Operaţiunile care se execută asupra datelor, din momentul apariţiei lor, pentru a
genera informaţii semnificative şi relevante sunt referite la un loc prin noţiunea de ciclul
prelucrării datelor. Ciclul cuprinde cinci faze: culegerea datelor, pregătirea datelor,
prelucrarea datelor, întreţinerea fişierelor şi obţinerea informaţiilor de ieşire.
Faza de culegere a datelor cuprinde două activităţi fundamentale [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.
Pregătirea datelor constă într-un număr de operaţii executate asupra datelor pentru
a facilita prelucrarea lor ulterioară. Ele sunt [1]:
clasificarea datelor, care implică atribuirea de coduri de identificare (simbol cont, cod
secţie, etc.), astfel încât datele să fie incluse în submulţimile corespunzătoare;
gruparea datelor, adică acumularea intrărilor similare, pentru a fi prelucrate în grup;
verificarea datelor cuprinde o mare varietate de proceduri pentru controlul
corectitudinii datelor, înainte ca ele să fie prelucrate;
sortarea datelor, prin care grupurile de date sunt aranjate în loturi de înregistrări, după
criterii de ordonare numerică, alfabetică, alfanumerică sau de timp;
cuplarea a două sau mai multe loturi de înregistrări într-unul singur;
transmiterea datelor de la un punct la altul;
transcrierea datelor dintr-o formă în alta, astfel încât să se efectueze trecerea de la
scrierea de mână la cea tipizată sau de la documentele scrise la mediile specifice.

Pregătirea datelor este o activitate realizată în toate tipurile de sisteme

informaţionale, dar capătă o semnificaţie deosebită în sistemele de prelucrare automată a
datelor; partea informatizată a acestora fiind cunoscută ca sistem/subsistem informatic.
Culegerea
datelor
Pregătirea datelor
Prelucrarea datelor
Întreţinere
fişiere
Informaţii de
ieşire
Fig. 1.4 Ciclul prelucrării datelor [1]
Prelucrarea datelor, poate să includă activităţi, cum sunt [1]:

calculaţiile cuprind unele forme de tratare matematică a datelor;
compararea supune unei examinări simultane două sau mai multe tipuri de date între
care există o legătură logică (ex. soldul final şi cel final);
sintetizarea este o activitate importantă prin care se comasează informaţiile;
filtrarea este o altă operaţiune prin care se extrag datele ce vor fi supuse prelucrărilor
următoare;
restaurarea, prin care sunt aduse datele din memorie într-o formă accesibilă omului,
pentru prelucrarea umană în continuare, sau într-o formă prelucrabilă tot pe
calculator.
În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim:
memorarea (stocarea) datelor în vederea utilizării lor viitoare;
actualizarea datelor memorate astfel încât să surprindă cele mai recente evenimente;
indexarea datelor pentru a înlesni o uşoară regăsire a lor;
protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi tehnici
pentru prevenirea distrugerii lor sau a accesului neautorizat.
Ultima fază a ciclului de prelucrare a datelor este obţinerea informaţiilor de ieşire.
Informaţiile de ieşire pot fi regăsite în una din următoarele trei forme: documente,
rapoarte ori răspunsuri la întrebări. Termenul ieşiri le cuprinde pe toate [1].
De cele mai multe ori, datele nu parcurg toate activităţile, iar unele dintre ele pot
chiar să nu treacă prin cele cinci faze.

Nicolae Morariu
1.1.7. Sistemele informatice de gestiune

Sistemul informatic de gestiune implică următoarele patru componente
interdependente: domeniile de gestiune, datele, modelele, regulile de gestiune [4].
Sistemul informatic de gestiune asigură obţinerea informaţiei solicitate de
utilizator, folosind mijloacele tehnologiei informaţiei (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 contabilităţii care va fi ulterior prelucrată pentru obţinerea situaţiilor
specifice fiecărui utilizator [4].
Documente Situaţia
Consultare 1 costurilor pe
facturi Actualizare
ordin de plată comenzi
bon de
consum
Balanţa de
verificare
Consultare 2 Registrul jurnal
BD Casa
Banca
Fig. 1.5. Sistem informatic de gestiune integrat al contabilităţii [4]
Sistemul informatic de gestiune reuneşte subsisteme informatice specializate pe

domenii între care se manifestă interacţiuni specifice. Fiecare subsistem definit grupează
procese informaţionale omogene, specifice unei anumite arii de interes [4].
La nivelul fiecărui subsistem vor fi definite aplicaţii distincte corespunzătoare
acestor activităţi. La rândul lor aplicaţiile sunt formate din proceduri descompunându-se
în module reprezentând secvenţe de cod prin care se realizează o funcţie independentă din
cadrul procedurii.
Exemplu. O procedură pentru operaţia de actualizare se va descompune în următoarele
module:
1. modulul coordonator al funcţiei de actualizare;
2. modulul pentru realizarea funcţiei de adăugare de înregistrări;
3. modulul pentru funcţia de ştergere înregistrări;
4. modulul pentru funcţia de modificare a înregistrărilor din baza de date.
1.2. Metodologii de realizare a sistemelor informatice

Realizarea sistemelor informatice reprezintă o acţiune complexă, care îmbină un
număr mare de activităţi: analiză, proiectare, implementare, exploatare [2]. În plus,
reclamă resurse umane, materiale şi financiare însemnate, pe o perioadă considerabilă de

timp. Folosirea eficientă a acestor resurse, în scopul obţinerii unui sistem informatic
performant a impus ordonarea acestui proces complex, într-o succesiune bine stabilită de
etape şi subetape şi utilizarea unor metode şi tehnici adecvate. Acest lucru a dus deci, la
conturarea unor metodologii de realizare a sistemelor informatice.
Între diversele etape de realizare a sistemelor informatice există o legătură
indestructibilă, legătură reflectată şi de faptul că în mod logic şi practic calitatea realizării
unor activităţi din etapele şi fazele precedente influenţează în mod decisiv calitatea
activităţilor din etapa ce îi urmează [2].
1.2.1. Conţinutul metodologiilor de realizare a sistemelor informatice

Metodologiile de realizare a sistemelor informatice cuprind [2]:
modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaţiile
sistemului şi dinamismul său;
regulile de formalizare a datelor şi proceselor de prelucrare;
instrumentele pentru concepţia, realizarea şi elaborarea documentaţiei;
modalitatea de derulare a proiectului şi acţiunile specifice fiecărei etape (ciclul de
viată);
definirea modului de lucru, rolului analiştilor şi proiectanţilor şi a raportului dintre ei;
modalităţile de administrare a proiectului (planificare, programare, urmărire).
Totodată, metodologiile au rolul de a indica modul de desfăşurare a acestui proces,
stabilind [2]:
componentele procesului de realizare a sistemului informatic (etape, subetape,
activităţi, operaţii) şi conţinutul lor;
fluxul parcurgerii (executării) componentelor; metodele, tehnicile, procedeele,
instrumentele, normele si standardele utilizate.
În funcţie de modul de abordare şi domeniul de aplicabilitate, metodologiile
utilizate sunt:
metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE (Ministerul
industriei-Franta), IE (James Martin), SSADM (Marea Britanie);
metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael
Jackson);
metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S,
METHOD/ 1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin).
1.2.2. Metode şi tehnici de realizare a sistemelor 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 analiştii de sisteme, programatorii şi alte categorii de
persoane implicate, realizează procesul de analiză a sistemului informaţional-decizional
existent, proiectarea şi introducerea sistemului informatic. Deci, metoda are un caracter
general, în cadrul ei aplicându-se anumite tehnici de lucru [2].
Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă
felul în care se acţionează eficient şi rapid, în cadrul unei metode, pentru soluţionarea

Nicolae Morariu
diferitelor probleme ce apar în procesul de proiectare. Prin aceste tehnici se îmbină

armonios cunoştinţele despre metode cu măiestria personală a celor chemaţi să aplice
metodele si să utilizeze instrumentele adecvate [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 funcţie de situaţia reală la care se referă.
În abordările incipiente se lucra cu probleme izolate şi ulterior s-a efectuat trecerea
la abordarea sistemică (modulară), odată cu abordarea funcţională sau, mai bine zis, cu
analiza şi descompunerea funcţională (în fiecare modul există câte o funcţie) şi ulterior
abordarea orientată-obiect [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 unităţi componente prin
rafinări repetate, metoda de proiectare putând fi descrisă sub forma unei diagrame
ierarhice cu module de control pe nivele superioare şi cu module detaliate pe nivelele
inferioare. Structura organizatorică a unei unităţi economico-sociale numită organigrama
unităţii poate fi reprezentată printr-o astfel de diagramă ierarhică. Pentru unităţi
economice productive în organigramă se disting următoarele patru nivele de reprezentare
[10]:
- nivelul conducerii strategice, reprezentat de directorul general şi consiliul de
administraţie;
- nivelul conducerii tactice (directori pe funcţiuni);
- nivelul compartimentelor funcţionale (servicii şi posturi de lucru) şi de proiectare,
cercetare (laboratoare) care asigură conducerea operativă a sistemului prin şefii lor;
- nivelul compartimentelor de producţie (secţii, ateliere) care realizează funcţia de
producţie a sistemului economic.
În strategia bottom – up evolutivă, se porneşte de la o tratare minimală care se
extinde treptat pe măsura înaintării în realizarea sistemului.
În practică, de cele mai multe ori se utilizează o combinare a celor două strategii.
Metodele de abordare a sistemelor informatice ar putea fi grupate prin prisma celor
mai mulţi autori astfel [1]:
metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece
diagramele fluxurilor de date se întrebuinţează pentru descrierea proceselor;
metode orientate spre informaţie sau date, orientate-informaţii, apărute ca urmare a
popularizării puternice a ingineriei informaţiei a lui JAMES MARTIN, dar şi a
diagramelor entitate-relaţie ale lui CHEN [3];
metode orientate-obiect.
Caracteristici esenţiale ale principalelor metode
Informaţia este văzută de DeMarco în 1982, ca fiind posibil de abordat prin trei
perspective specifice sistemelor informaţionale sau prin trei dimensiuni: date, funcţii,
comportament.

Datele sunt surprinse din prisma structurii lor sub formă de atribute şi înseamnă de
fapt, ceea ce are stocat, şi reflectă structura statică [1].
Funcţiile scot în evidenţă în mod limitat ceea ce face sistemul. El poate fi văzut şi
ca un proces, întrucât elementele sistemului despre care se păstrează datele de rigoare
sunt supuse unor transformării funcţionale, prin intermediul proceselor [1].
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a
sistemului, influenţa evenimentele şi proprietăţilor sistemului, şi sugerează dinamica lui
[1].
Metoda descompunerii funcţionale (orientate funcţii) [1].
Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm
pe câţiva cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr,
Dahl, Marco&Gowan. Descompunerea funcţională este cea care anunţă apariţia
proiectării structurate şi analizei structurate. Fiecare funcţie este descompusă în
subfuncţii, până se obţin structuri uşor de transpus în instrucţiunile limbajelor de
programare.
Metodele fluxurilor de date (orientate-proces) [1].
Prin această metodă analiştii efectuează reprezentarea lumii reale prin simboluri
care reprezintă fluxul datelor, transformările datelor, stocarea datelor, entităţi externe, etc.
Metoda orientată spre procese are încă un mare grad de asemănare cu descompunerea
funcţională.
Metode orientate spre informaţii (orientate-date) [1]
Două realizări importante în domeniu au dat tonul unei orientări în abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P.
Chen (1976) şi ingineria informaţiei, în viziunea lui James Martin.
Metoda orientată-obiect [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 aceeaşi 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, când hardul sa extins prin seria PC-urilor, iar reţelele
au devenit mai puternice, constituindu-se sistemele distribuite. Obiectivul principal al
CASE-ului îl constituie punerea în practică a produselor-program de proiectare şi
realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE sunt
utilizabile din faza de definire a cerinţelor până la întreţinerea fizică a produsului
informatic. Totuşi, analiza şi proiectarea, bazate pe conceptele şi metodele structurate,
reprezintă elementele forte ale instrumentelor CASE, iar în ultimii ani CASE a acordat
atenţia cuvenită analizei, proiectării şi programării orientate pe obiecte [1].

Nicolae Morariu
Majoritatea produselor soft au fost construite în mod artizanal, fără posibilitatea

testării complete a lor, fiind însoţite de o documentaţie destul de slabă. Instrumentele
CASE implică utilizarea calculatorului ca un mijloc de susţinere a activităţilor de
planificare, definire, proiectare şi realizare a softului. Ele se bazează pe logica structurală,
pe descompunerea funcţională şi reprezentarea prin diagrame a fluxurilor de date ale
aplicaţiilor.
Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a încuraja
abordarea logicii structurate şi pentru folosirea calculatorului ca un mod de tezaurizare a
lucrărilor şi ca o planşetă de desen, pe care pot fi plasate reprezentările structurate ale
sistemelor sau aplicaţiilor. Pe măsura evoluţiei lor, sistemele CASE au devenit mult mai
complexe, permiţând ca procesele de proiectare şi realizare a aplicaţiilor să se desfăşoare
într-un mediu informatic interactiv, oferind utilizatorilor un întreg arsenal de instrumente
şi proceduri, prin care pot proiecta, realiza, testa, documenta, întreţine/actualiza şi
exploata sistemul.
Utilizarea produselor de tip CASE a fost determinată de [1]:
calitatea îndoielnică a aplicaţiilor realizate în mod tradiţional;
frustrarea utilizatorilor în încercarea lor de a participa la procesul de proiectare şi
realizare a aplicaţiilor, datorită nivelului ridicat de cunoştinţe informatice solicitate de
metodele tradiţionale;
costuri deosebit de mari pe care le presupun întreţinerea şi actualizarea softului
funcţional;
imposibilitatea rezolvării tuturor cerinţelor utilizatorilor;
limitarea posibilităţii de reprezentare grafică a schemelor de realizare a noilor
proiecte.
Folosirea sistemelor CASE este motivată şi de următoarele avantaje:
reducerea complexităţii logicii de descriere a sistemului;
posibilitatea de a alege dintre mai multe variante de proiectare;
creşterea vitezei de realizare a sistemelor;
realizarea succesivă a componentelor unui sistem;
creşterea integrării;
consolidarea disciplinei de proiectare;
oferirea unei interfeţe de proiectare;
folosirea depozitelor modularizate;
salvarea şi refolosirea unor componente din diagramele realizate;
simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.
Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de

date, care fac posibilă realizarea unui model al derulării proceselor sistemului/aplicaţiei
care se proiectează. A urmat folosirea dicţionarului de date ca un depozit al tuturor
datelor privind sistemul sau aplicaţia. Au apărut ecranele predefinite pentru a prezenta ce
poate să obţină utilizatorul prin exploatarea sistemului. S-a apelat la facilităţile grafice,
care pot folosi simbolurile logicii structurate şi care permit proiectantului să realizeze o
diagramă coerentă a fluxurilor de date [1].

1.3.1. Funcţiile CASE

Primele sisteme CASE erau un set de aplicaţii neintegrate, cu funcţii distincte, fără
a fi interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generaţiile
actuale, care încearcă să realizeze o integrare completă şi uşoară a tuturor elementelor,
integrarea reprezentând, de fapt, factorul cel mai important al metodologiei CASE [1].
CASE se bazează pe două funcţii fundamentale [1].
Prima funcţie constă în posibilitatea descompunerii de sus în jos (top-down) a
sistemului informatic în procese şi module distincte, fiecare având definite
responsabilităţile funcţionale şi/sau operaţionale.
Cea de-a doua funcţie se referă la faptul că sistemele informaţionale pot fi
reprezentate într-o formă grafică concisă, folosind câteva simboluri de bază. Importanţa
acestor două funcţii rezidă în posibilitatea utilizării modularităţii aplicaţiilor, a
diagramelor, obţinerea unei documentaţii privind realizarea, evaluarea arhitecturii şi
utilizarea sistemului.
Pentru definirea şi construirea sistemelor, produsele CASE presupun stabilirea şi
respectarea unei anumite discipline. Metodologia oferă o interfaţă între crearea şi
verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentaţii, care
include şi integrează caracteristicile proceselor şi paşii de parcurs, pentru descrierea
modului de lucru; oferă un model al produsului final, ce poate fi folosit în realizarea
operaţiilor de exploatare şi întreţinere a sistemului/aplicaţiei, şi oferă o interfaţă pentru
păstrarea evoluţiei proiectului.
Folosirea reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii
aplicaţiei în mai multe componente logice. Prin ataşarea unei baze de date la elementele
grafice, se va obţine un depozit ce va conţine paşii şi funcţiile reprezentate în diagramele
construite. Dacă aceste elemente sunt corect stabilite, ele vor sta la baza descrierii
proceselor, ce vor constitui procedurile de prelucrare ale sistemului/aplicaţiei. Modelarea
grafică în sistemele CASE prezintă o interactivitate ridicată, permiţând construirea
diagramelor, deplasarea de la o diagramă la alta, modificarea, extinderea, copierea,
evaluarea şi descrierea elementelor unei aplicaţii [1].
Modelele grafice permit conectarea fluxurilor logice între activităţile şi funcţiile
specifice aplicaţiei, relaţii care pot fi testate şi validate în mod automat.
1.3.2. Trăsături definitorii ale CASE-ului

Evoluţia CASE-ului, a determinat apariţia I-CASE-ului. Integrated CASE se referă
la toate aspectele integrării, 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 interacţiune;
semnificaţia reprezentărilor grafice;
elemente de tip verificare şi validare (V&V);
natura bidirecţională, deplasări pe verticală în structura sistemului;
deschidere pentru interconectarea instrumentelor CASE;
sprijin pentru lucrul cu utilizatori multipli;

Nicolae Morariu
descompunerea;
performanţe de deplasare, pe orizontală, de la un instrument la altul;
grade diferite de automatizare;
INTEGRAREA.
CASE-ul nu este un proces independent. El constituie un set integrat de
metodologii, care urmăresc realizarea ciclului de viaţă al unui sistem. La sfârşitul fiecărei
faze a ciclului de viaţă, rezultatele obţinute trebuie supuse unei analize şi verificări, iar
utilizatorii trebuie informaţi asupra modului de gestionare a procedurilor de lucru. Ei sunt
cei care trebuie să dea avizul de continuare a parcurgerii fazelor următoare, pe baza a
ceea ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite în
proiectarea sistemului şi a modelului proiectat pe măsura desfăşurării operaţiunilor, din
faza de proiectare până la predarea produsului final. CASE poate sprijini aceste proceduri
prin punerea la dispoziţie a unei documentaţii, critici sau modificări asupra elementelor
din modelul proiectat. Pe acest fond, pot fi făcute evaluări, critici sau modificări asupra
elementelor din modelul proiectat. Rezultatele obţinute în urma proiectării unui anumit
model de sistem constau în documentaţia oferită, care acoperă întregul ciclul de viaţă al
sistemului, cu toate operaţiile şi procedurile pe care le presupune. Datele din
documentaţia modelului sunt, de obicei, înlocuite cu cele reale şi se parcurg paşii de
implementare a sistemului pentru a obţine un model funcţional. În plus, CASE oferă
posibilitatea de a analiza ieşirile obţinute şi de a le modifica pentru a reflectă schimbările
intervenite în sistem, modulele definite şi depozitul de date [1].
1.3.3. Exemple de instrumente CASE (Conferinţa Naţională de Învăţământ Virtual,

ediţia a III-a, 2005)
În literatura de specialitate, instrumentele CASE sunt clasificate şi dup ă un alt
criteriu decât cel al activităţilor din ciclul de viaţă al sistemelor pe care le sprijin ă. Acest
criteriu se referă la metodologia pe care o încorporeaz ă pentru realizarea sistemelor.
Astfel, se întâlnesc următoarele trei categorii:
instrumente CASE bazate pe metodologia structurat ă;
instrumente hibride, ce conţin elemente specifice orient ării-obiect, dar care nu
permit realizarea sistemelor orientate-obiect;
instrumente pur orientate-obiect.
În cele ce urmează se vor prezenta câteva exemple de CASE folosite de cele mai utilizate
metodologii de analiză şi proiectare, respectiv metodologia structurat ă şi cea orientat ă pe
obiecte.
A) Metodologia structurată
Westmount I-CASE Yourdon oferă suport complet pentru realizarea sistemelor
informatice. Având la baza metoda structurată propusă de Yourdon, acest instrument
CASE integrat oferă posibilitatea lucrului în echipă, posibilitatea de generare şi reutilizare
a codului şi generarea automată a documentaţiei de realizare a sistemului informatic.
Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon.
Repository este implementat cu ajutorul unui SGBD relaţional: Informix, Ingres sau
Oracle.

Analyst, este componenta ce oferă suport pentru analiza structurată. Metoda este
implementată de Yourdon şi De Marco. Westmount I-CASE Yourdon oferă suport pentru
un set extins de instrumente şi anume editoare pentru diagrame de flux a datelor,
diagrame entitate asociere, diagrame de structură a datelor editoarele matriciale pentru
matricea listei de evenimente.
Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de
ansamblu). Editorul
Designer este componenta ce oferă suport pentru proiectarea de detaliu a sistemului
informatic.
Proiectarea de detaliu a aplicaţiei este strâns legată de proiectarea bazei de date. Pentru
modelarea datelor se utilizează diagrama entitate asociere.
Programmer este mediul de programare care oferă suport pentru generarea codului
sursă, compilare, lansare în execuţie şi testarea aplicaţiei. Generatorul de cod translatează
specificaţiile de proiectare în cod sursă. Astfel, pe baza diagramei entitate asociere se
generează codul DDL (în SQL) ce defineşte structura fizică a bazei de date. Codul poate
fi completat pentru a defini restricţiile de integritate şi modul fizic de stocare a bazei de
date. Este prezentată şi facilitatea de inginerie inversată care translatează definirile
asociate bazei de date existente într-o diagramă entitate asociere. Codului aplicaţiei este
generat în limbajul C îmbogăţit cu instrucţiuni SQL pornind de la specificaţiile din
schemele de structură.
Docwriter este componenta care permite generarea documentaţiei pentru fiecare etapă de
realizare a sistemului.
Utilizarea produsului Westmount I-CASEY Yourdon îmbunătăţeşte productivitatea
realizării sistemelor informatice şi oferă garanţii pentru calitatea sistemelor obţinute.
B) Metodologia orientată-obiect
Expresia „pur orientate-obiect" se refer ă la faptul c ă pe de o parte, instrumentele
CASE conţin numai elemente specifice abordării orientate-obiect a sistemelor, iar pe de
altă parte la faptul că se bazează pe metodele şi tehnicile de analiz ă şi proiectare
orientate-obiect.
Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de via ţă al
sistemelor, pot fi grupate ca şi cele convenţionale, astfel:
- Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor;
- Lower CASE orientat-obiect pentru generarea codului-surs ă al aplica ţiilor;
- I-CASE orientat-obiect care acoperă întregul ciclu de via ţă.
Deoarece tendinţa se îndreaptă tot mai mult spre tehnologiile informa ţionale orientate-
obiect, nici domeniul instrumentelor ce sprijin ă realizarea sistemelor nu poate s ă nu se
adapteze la această orientare, lucru ce a dus la apari ţia a numeroase produse CASE
orientate-obiect sau la reorientarea firmelor produc ătoare de instrumente conven ţionale
spre înglobarea în produsele lor a elementelor specifice abord ării obiectuale.

Nicolae Morariu
Designer/2000
Setul de instrumente Designer/2000 este parte integrantă din portofoliul de
instrumente de dezvoltare oferit de Oracle şi reprezintă o soluţie integrată pentru
dezvoltarea de sisteme client/server din generaţia a doua sau de sisteme Intranet bazate
pe Web. Designer/2000 acoperă toate fazele ciclului de dezvoltare a aplicaţiilor
software, pornind de la modelarea sistemului informatic (business modelling) până la
exploatare. Abordarea Designer/2000 bazată pe un Repository permite ca anumite
componente sau toate componentele să fie folosite pentru dezvoltarea rapidă de aplicaţii
scalabile, multi-platformă, distribuite.

Capitolul 2
Iniţierea şi planificarea realizării unui sistem informatic
În cadrul acestui capitol vor fi prezentate o serie de aspecte privind primele

activităţi desfăşurate în vederea realizării sistemelor informatice, activităţi definite în
literatura de specialitate sub numele de microanaliza sistemelor, componentă preluată din
managementul proiectelor şi care are în vedere modalităţile de identificare a proiectelor
de dezvoltare a sistemelor informaţionale, precum şi modul în care au loc iniţierea şi
planificarea acestora, în strânsă legătură cu planul strategic organizaţional.
2.1. Identificarea, selecţia, iniţierea şi planificarea proiectelor

Identificarea şi selecţia proiectelor de dezvoltare a sistemelor informaţionale
reprezintă prima etapă din ciclul de viaţă a dezvoltării sistemelor care, împreună cu
iniţierea şi planificarea proiectelor, constituie microanaliza, componentă preluată din
managementul proiectelor. Evidenţierea acestor activităţi în cadrul modelului cascadă de
derulare a fazelor sau etapelor ciclului de viaţă a sistemului este reprezentată în figura 4.1
[1].
A.
identificarea
şi selectarea
proiectului
microanali
B. iniţierea şi za Fazele ciclului de viaţă
planificarea al dezvoltării
proiectului sistemului
C. analiza
D. proiectarea
logică
E. proiectarea
fizică
F. implementarea
G. întreţinerea
Figura 2.1 Ciclul de viaţă al dezvoltării sistemelor [1]
Din modelul prezentat rezultă că orice etapă se descompune în activităţi, ceea ce

pentru identificarea şi selecţia proiectelor înseamnă [1]:

Nicolae Morariu
identificarea potenţialelor proiecte de dezvoltare;

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

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

Propuneri Metoda de selecţie Caracteristicile proiectului
a proiectului
Top-managerii  orientare puternică spre strategie;
 cele mai mari dimensiuni ale proiectului;
 cele mai de durată proiecte.
De sus în jos Comitetul de iniţiativă  orientare mixtă (a diferiţilor reprezentanţi);
 vizează schimbările organizaţionale cele mai mari;
 analiză formală a costurilor şi avantajelor proiectelor;
 proiecte mai mari şi mai riscante.
Departamentul  limitat, neorientat strategic;
utilizatorilor  realizare mai rapidă;
 câţiva utilizatori reprezintă niveluri ale conducerii,
precum şi funcţiile întreprinderii.
Grupul de dezvoltare  integrare în sistemul existent;
De jos în sus
 puţine întârzieri în realizarea proiectului;
 mai puţin interesat de analizele cost – avantaje.
Selecţia proiectelor de dezvoltare a sistemelor informaţionale

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

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

Iniţierea proiectului
Din momentul selecţiei lui, proiectul trece în faza de iniţiere, ceea ce presupune
desfăşurarea unei activităţi laborioase, prestată de un responsabil, cunoscut în practică
sub numele de manager de proiect, care răspunde de [1]:
Elaborarea unor studii de fezabilitate generală;
Elaborarea planurilor detaliate ale proiectelor;
Găsirea celor mai buni membri ai echipei proiectului.
Managerul de proiect trebuie să dea dovadă de multe calităţi pentru a putea jongla
cu elemente cum sunt:
Schimbările tehnologice;
Ciclul de viaţă al sistemelor;
Contractori şi furnizori;
Managementul resurselor umane;
Metodologie şi instrumente de lucru diferite;
Restricţii de timp şi resurse;
Documentare şi comunicare;
Aşteptările managerilor şi clienţilor.
Activităţile efectuate în faza iniţierii proiectului sunt:
1. stabilirea echipei de iniţiere a proiectului;
2. stabilirea bunelor relaţii cu beneficiarii;
3. stabilirea planului iniţierii proiectului;
4. stabilirea procedurilor manageriale;
5. stabilirea cadrului de desfăşurare a proiectului şi a manualului de operare al
acestuia.
Planificarea proiectului
Planificarea proiectului va cuprinde o evaluare a cerinţelor informaţionale ale
sistemului la nivelul întregii organizaţii.
Planificarea proiectului este procesul prin care are loc definirea clară a activităţilor
şi a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.
Tipurile activităţilor executate în cadrul planificării proiectului cuprind [1]:
1. Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului
2. Descompunerea proiectului în activităţi uşor executabile şi controlabile
3. Estimarea resurselor şi crearea unui plan al resurselor
4. Realizarea unei prime planificări calendaristice
5. Realizarea unui plan al comunicărilor
6. Determinarea standardelor şi procedurilor proiectului
7. Identificarea şi evaluarea riscului
8. Crearea unui buget preliminar
9. Întocmirea rapoartelor de activitate
10. Definitivarea planului de bază al proiectului

Nicolae Morariu
2.2. Analizele de fezabilitate

Elaborarea unui sistem informatic poate costa milioane de dolari şi se poate realiza
pe parcursul a trei până la şase ani pentru a fi complet. Din aceste motive, este normal ca
factorii de conducere să demareze proiectarea unui nou sistem după ce se efectuează
studii de fezabilitate.
Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare
pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja
început mai poate fi continuat. Proporţiile şi durata studiilor de fezabilitate variază, în
funcţie de mărimea şi natura sistemului implementat. În cazul sistemelor bazate pe
calculatoare mari, studiul are cu totul alte dimensiuni faţă de varianta utilizării
microcalculatoarelor [1].
Totuşi, fezabilitatea proiectului poate fi studiată în orice fază a elaborării lui, dar
studiile, de regulă, se efectuează în momente certe. Când este propus un proiect, se
efectuează un studiu preliminar de fezabilitate pentru a se stabili dacă proiectul atinge
obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de subiectivă,
întrucât proiectul nu este reprezentat cu lux de amănunte. Însă, îndată ce se obţine o
situaţie mai clară despre sistem, despre natura problemei de rezolvat, precum şi despre
doleanţele utilizatorilor, măsurarea preliminară a fezabilităţii poate fi determinată odată
cu faza de analiză a sistemului. Când proiectanţii oferă două sau trei variante de elaborare
a sistemului, numai studiile de fezabilitate 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 proiectării, implementării şi exploatării. Este ultima şansă a
unităţilor de a mai putea renunţa la sistem, înaintea implementării lui.
Pe parcurs, odată cu progresul înregistrat în dezvoltarea sistemului informatic, se
obţin informaţii din ce în ce mai certe, oferindu-se posibilitatea unor analize de
fezabilitate mult mai concludente, ceea ce atrage studierea fezabilităţii în diverse faze ale
ciclului de viaţă al sistemelor. De fiecare dată, studiile de fezabilitate trebuie să aibă la
bază o foarte bună documentaţie. Aceasta va conţine [1]:
Definirea problemei ( o scurtă descriere a proiectului şi explicarea a ceea ce-şi
propune el să realizeze);
Descrierea cerinţelor sistemului;
Descrierea soluţiilor sistemului propus;
Explicaţia critică a motivării studiului întreprins;
Cuantificarea tuturor costurilor materiale şi beneficiilor aferente;
O listă a costurilor şi beneficiilor necuantificabile.
2.3. Tehnici de reprezentare a planurilor şi programarea calendaristică

Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea
şi descrierea planurilor proiectelor.
Documentaţia planificării poate fi alcătuită din:
rapoarte grafice - cele mai folosite (fig. 2.2 )
rapoarte sub formă de text.
O diagrama Gantt este o modalitate de reprezentare grafică a proiectului. Cu
ajutorul barelor orizontale sunt prezentate activităţile planificate. Lungimea barelor este

proporţională cu timpul alocat activităţilor reprezentate. Se pot folosi diferite culori,

umbre sau forme pentru a scoate în relief anumite activităţi. Ceea ce s-a planificat şi
realizat, de asemenea, pot fi evidenţiate prin bare paralele de culori, forme sau umbre
diferite.
Diagramele Gantt nu indică ordinea activităţilor (precedenţa lor), ci indică data
începerii şi pe cea a finalizării.
Se recomandă pentru descrierea proiectelor simple sau a unor componente ale
proiectelor mari, sau a activităţilor prestate doar de o singură persoană, precum şi pentru
monitorizarea modului în care se efectuează activităţile în comparaţie cu cele planificate
(ca dată) .

Nicolae Morariu
Evidenţa promovării vânzărilor (EPV)
Nr. Nume activitate Aprilie Mai Iunie Iulie August Septem-

Crt. 2005 2005 2005 2005 2005 brie
2005
1. Colectarea
cerinţelor
2. Proiectare
ecrane
3. Proiectare
rapoarte
4. Proiectare baze
de date
5. Documentaţie
utilizator
6. Programare
7. Testare
8. Instalare
9. Şedinţa de
analiză
Proiect: EPV Critic: În lucru: Sinteză:

Data:
Analist:
Necritic: Punct de reper: Derulat:
Figura 2.2. Diagrama Gantt pentru descrierea planului proiectului [1]

Capitolul 3
Analiza sistemului existent şi definirea cerinţelor 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 funcţionează sistemul
informaţional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul system
.Astfel, sunt prezentate o serie de aspecte privind:
- determinarea cerinţelor sistemului;
- metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemulu
(interviul şi chestionarul);
- metode moderne de analiză şi determinare a cerinţelor sistemului (JAD,
prototipizarea);
- structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor
(diagramele fluxurilor de date DFD);
- modelarea conceptuală a datelor (diagramele entitate – relaţie, DER).
3.1. Studiul sistemului informaţional existent

Prin sistem existent se înţelege realitatea obiectivă din organizaţia pentru care
urmează a se realiza sistemul informatic solicitat printr-o comandă numită cererea
beneficiarului.
Analiza sistemului existent şi definirea cerinţelor noului sistem este prima etapă
din ciclul de viaţă al dezvoltării sistemelor informatice, etapă prin care se determină
modul în care funcţionează sistemul informaţional curent şi se evaluează ceea ce ar dori
utilizatorii să realizeze noul sistem. Studiul şi analiza sistemului existent are ca obiectiv
principal stabilirea cerinţelor informaţionale ale conducerii în vederea realizării unui
sistem informatic.
Studiul sistemului existent cuprinde un grup de activităţi care urmăresc
cunoaşterea performantelor tehnico-funcţionale ale sistemului informaţional, atât în
ansamblul său, cât şi pentru elementele de structura ale acestuia, a cerinţelor
informaţionale ale conducerii, cunoaşterea lipsurilor şi restricţiilor pe care le prezintă
sistemul existent faţă de aceste cerinţe. De modul de realizare a acestor activităţi depinde
întregul proces de realizare a sistemului informatic [2].
Studiul sistemului existent constă în [2]:
definirea caracteristicilor generale ale sistemului economic;
studiul activităţilor de bază desfăşurate în sistem;
studiul sistemului de conducere;
studiul sistemului informaţional;
identificarea metodelor şi mijloacelor tehnice.
Definirea caracteristicilor generale ale sistemului economic implică :
cunoaşterea profilului, obiectivelor agentului economic;
cunoaşterea locului în sfera serviciilor si sfera producţiei;
cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
cunoaşterea specificului activităţii de bază ( producţie, servicii);

Nicolae Morariu
cunoaşterea nivelului tehnic;

cunoaşterea principalilor indicatori economici şi evoluţia lor;
dezvoltarea, modernizarea etc.
Studiul activităţilor desfăşurate în sistemul economic, modul de realizare a
funcţiunilor unităţii economice se face prin [2]:
1. Pe baza statutului de funcţionare a societăţii se studiază:
activităţile şi sarcinile din cadrul acestor funcţiuni;
atribuţiile ce revin compartimentelor;
modul de realizare a activităţilor funcţionale din cadrul unităţii economice.
2, În cazul activităţii de producţie se prezintă:
fluxul de producţie, amplasarea locurilor de muncă, depozitelor etc.;
tipurile de produse, structura lor, ciclurile de realizare;
modul de organizare a producţiei, stocarea producţiei, transporturile interne,
controlul de calitate;
resursele existente:
capacităţi;
asigurarea tehnică / proiectarea de produse noi;
norme tehnice;
asigurarea cu materiale necesare;
sistemul existent de programare a producţiei.
Studiul sistemului de conducere se referă la [2]:
identificarea caracteristicilor sistemului de conducere existent;
sistemul de indicatori cantitativi şi valorici;
organizarea conducerii;
caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de decizii,
modul de lucru a deciziilor.
Studiul sistemului informaţional presupune [2]:
elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);
estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de
culegere şi prelucrare;
identificarea principalilor algoritmi, regulilor de calcul şi a punctelor si regulilor
de control;
cunoaşterea principalelor restricţii ale sistemului informaţional;
situaţia raţionalizării fluxurilor şi a documentelor din unitatea economica, studii
elaborate, stadiul lor de implementare;
sistemul de codificare utilizat, restricţii;
performanţele şi limitele sistemului informaţional existent.
Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea datelor în
cadrul sistemului informaţional existent se face evidenţiind: mijloacele tehnice existente
în dotarea unităţii economice ( modul de utilizare, cheltuielile de exploatare, personalul
implicat, performante); existenţa unor aplicaţii proiectate şi/sau implementate [2].

3.2. Determinarea cerinţelor sistemului

Determinarea cerinţelor sistemului este activitate esenţială în aflarea situaţiei
existente şi a ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor
sistemului se concretizează în diferite forme ale informaţiilor colectate, cum sunt copii
ale interviurilor, însemnări efectuate în timpul observării şi analizei documentelor,
interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale
posturilor de lucru ş.a., precum şi rezultate ale prelucrărilor efectuate de calculator, cum
ar fi prototipurile [1].
Rezultatele prezentate după această activitate pot fi rezumate astfel:
1. Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea
activităţilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la
chestionare sau interpretări ale acestora, însemnări şi rezultate din observarea
activităţilor, procese verbale ale şedinţelor ce au avut loc în acest scop;
2. Informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare
ale formularelor, rapoartelor şi machetelor de ecrane, manuale ale procedurilor,
descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme şi
documentaţia sistemului existent, rapoartele consultanţilor [1];
3. Informaţii obţinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii
ale fişierelor sesiunilor grupului de sprijinire a sistemului, conţinutul depozitelor
şi rapoartele existente în CASE, ecrane şi rapoarte rezultate din prototipurile
sistemului, ş.a [1].
3.2.1. Metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemului

Analiza sistemului informaţional-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 răspândită pentru culegerea informaţiilor din
sistemul informaţional. Utilizatorii acestei metode sunt în general analiştii care nu sunt
familiarizaţi cu unitatea studiată şi cu problemele ei. Prezintă avantajul că lasă foarte
multă libertate creativa analistului în construirea şi desfăşurarea lui [2]. În alegerea
persoanelor de intervievat trebuie avute în vedere următoarele constatări [10]:
- persoanele care ocupă poziţii medii în ierarhia structurii organizatorice furnizează
informaţiile cele mai apropiate de realitate;
- colectarea de informaţii corecte necesită intervievarea atât a personalului de
conducere, cât şi a celui de execuţie;
- în prealabil trebuie verificată competenţa subiecţilor intervievaţi;
- lipsa unei atitudini critice poate să denote reţineri în exprimarea ideilor.
Se vor efectua interviuri la nivelul conducerii şi interviuri la nivelul posturilor de lucru.
Rezultatul interviului este consemnat în raportul de interviu care trebuie semnat de către
persoanele intervievate.

Nicolae Morariu
Chestionarul poate fi utilizat atât de către analiştii începători, cât şi de către cei
avansaţi, familiarizaţi sau nu cu problemele informaţionale-decizionale ale unităţii. Prin
utilizarea lui dispare “filtrul de informaţii” care este analistul iar cel care furnizează
informaţii are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând
această metodă, participă un număr mare de “furnizori de informaţii”. Limitele
chestionarului constau în faptul că este o metodă de verificare a unor cunoştinţe
prealabile, fapt ce implică cunoaşterea prealabilă a domeniului.
Această metodă necesită timp relativ îndelungat pentru întocmirea chestionarului
precum şi de culegere şi prelucrare a răspunsurilor. Chestionarul nu are o arie largă de
utilizare [2].
3.2.2. Metode moderne de analiză şi determinare a cerinţelor sistemului

Ca efect al tendinţelor de mărire a timpului de analiză a sistemelor existente, în
ultimii ani, s-a efectuat trecerea spre analiza mai puţin pronunţată a sistemelor ce urmează
a se realiza. Tehnicile moderne, JAD şi prototipizarea, preiau tot mai puţine elemente din
sistemele existente, ca urmare a analizei efectuate. Altele mai radicale renunţă aproape
total la analiza sistemului existent, este cazul proceselor controlate prin RAD, care
apelează la JAD, prototipizare şi alte instrumente de tip CASE [1].
Joint Application Design(JAD)
Spre sfârşitul anilor 1970, specialiştii în realizarea de sisteme de la IBM au
elaborat un nou proces de culegere a cerinţelor informaţionale ale sistemelor şi de
revizuire a proiectelor sistemelor, numindu-se JAD [1].
Ideea principală a lui JAD o constituie punerea laolaltă a tuturor forţelor interesate
în dezvoltarea sistemelor: utilizatori-cheie, managerii şi analiştii de sistem implicaţi în
analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel
de grup. Totuşi în sesiunea JAD se urmăreşte o anumită secvenţă de derulare a
activităţilor, pe baza unor roluri bine stabilite.
Prototipizarea şi determinarea cerinţelor sistemelor
Prototipizarea este un proces interactiv prin care analiştii şi utilizatorii pun în
discuţie o versiune rudimentară a unui sistem informaţional, care va fi într-o continuă
schimbare, în funcţie de reacţia utilizatorilor. Prototipizarea renunţă la ciclul de viaţă al
dezvoltării sistemelor sau la creşterea rolului său [1].
Pentru culegerea informaţiilor despre cerinţele utilizatorilor încă se apelează la
interviuri, dar prin prototipizare, operaţiunea va fi mai simplă şi va solicita un timp mai
scurt. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze ce ar mai
dori, dar şi să-şi genereze această formă nouă, cu ajutorul specialiştilor [1].
Prototipizarea este facilitată de câteva limbaje sau produse program, inclusiv
instrumentele de tip CASE.
Prototipizarea este foarte utilă în determinarea cerinţelor sistemului când [1]:
cerinţele utilizatorului nu sunt prea clar formulate sau bine înţelese;
unul sau mai mulţi utilizatori sau susţinători sunt implicaţi în sistem;
anumite mijloace de lucru (formulare şi rapoarte predefinite).
Prototipizarea generează şi deficienţe, cum ar fi:

tendinţa de evitare a unui cadru formal de elaborare a documentaţiei privind cerinţele

sistemului, ceea ce va îngreuna în viitor orice control;
fiind conceput de un număr mic de utilizatori va fi probabil respins de viitorii
utilizatori;
fiind conceput izolat este puţin probabil ca el să fie integrat în sistemul existent;
nerespectându-se etapele ciclului de viaţă al dezvoltării sistemelor pot fi omise
aspecte esenţiale, cum ar fi securitatea, controlul datelor introduse şi standardizarea la
nivel de sistem.
Paşii prototipizării sunt [1]:
Identificarea cerinţelor principale ale sistemului;
Realizarea prototipului iniţial;
Proces iterativ de adaptare a sistemului la cerinţele utilizatorului;
Folosirea sistemului aprobat de utilizatori.
După determinarea cerinţelor sistemului urmează structurarea acestora prin

utilizarea unor instrumente specifice de modelare logică.
3.3. Structurarea cerinţelor sistemului - modelarea logică a datelor şi prelucrărilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate
apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de
diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru
descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de
date fizice şi diagrame ale fluxului de date logice. Altele apelează la combinaţii de
diagrame, tabele şi forme descriptive [1].
Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaţiei şi a celor externe, sub denumirea de
entităţi externe sistemului analizat.
3.3.1. Diagramele fluxurilor de date (DFD)

Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,
reliefează funcţiile de prelucrare a datelor executate de către sistemul informaţional
curent.
Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem.
Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor sau
depozitele CASE (repository) [1].
Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al
datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale
proceselor de prelucrare, iar operaţiunea se numeşte modelarea proceselor.
DFD reprezintă doar una din tehnicile de analiză structurată.

Nicolae Morariu
Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor

fluxurilor de date a căpătat noi accepţiuni prin încorporarea ei în instrumentele de analiză
şi proiectare cu ajutorul calculatorului, adică în instrumente CASE [1].
Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru

construirea DFD
Când analizăm sistemele folosim frecvent reprezentările grafice, de exemplu
diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului
informaţional. Proiectarea fluxului informaţional reprezintă circulaţia informaţiei în
sistem, transformările suferite de acesta, stocarea informaţiei precum şi scurgerile de
informaţie în afara sistemului.
Scopul diagramelor de date DFD pentru o anumită componentă organizatorică sau
funcţională la care se referă (secţie, birou, compartiment, întreaga unitate, o anumită
activitate – vânzări, cumpărări, încasări, plăţi, ş.a) este de a scoate în relief, într-o manieră
cât mai sugestivă, următoarele aspecte [1]:
sursa datelor de prelucrare;
operaţiunile de prelucrare prin care trec datele;
destinaţia datelor prelucrate;
legătura existentă între prelucrări şi activitatea de stocare a datelor.
Întocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafică a transformării datelor de intrare în date de ieşire
folosind un set de simboluri de reprezentare şi un set de reguli de completare şi validare.

Simboluri folosite în diagramele realizate cu SSADM
proces (transformare): Procesele sunt etichetate cu text ce sugerează

modul de transformare a datelor şi sunt identificate printr-un număr(descriere
a funcţiei procesului de prelucrare, începând cu un verb, urmat de o descriere
a obiectului funcţiei de prelucrare). În DFD fizică pentru sistemul existent, se
va preciza şi locaţia (compartiment / persoană) procesului.
flux de date: este constituit din datele transmise între două procese.
Fluxul de date este etichetat printr-un substantiv ce sugerează informaţia sau
pachetul de informaţii transmise.
entitate externă (terminator): sursă / receptor de date. Poate fi un alt

sistem (organizaţie, compartiment).
stoc de date: un depozit temporar sau permanent de date.

Poate fi:
manual: registre, dosare, arhivă de documente
pe suport magnetic: fişiere.
Convenţii folosite în diagramele de reprezentare a DFD:
procesele şi stocurile de date sunt numerotate secvenţial, pentru a putea fi

identificate. Numerele asociate proceselor nu semnifică ordinea de execuţie a
acestora;
pentru a evita fluxurile de date întretăiate şi aspectul de “păienjeniş” al
diagramei, entităţile externe şi stocurile de date pot fi duplicate. O entitate
externă duplicată se reprezintă prin trasarea unei linii oblice, iar un stoc
duplicat printr-o linie suplimentară verticală în partea stângă a cutiei;
pentru a face diagramele mai lizibile, entităţile externe sunt plasate, pe cât
posibil, în jurul diagramei iar stocurile de date, în partea centrală a diagramei;
fluxurile de date de la - către stocurile de date sunt unidirecţionale (fie de
adăugare, fie de consultare) si nu sunt etichetate.
3.3.2. Descompunerea funcţională şi rafinarea DFD

Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să
realizăm de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele
complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o

Nicolae Morariu
descompunere funcţională a sistemului, care este realizată prin rafinarea succesivă a

proceselor.
Primul nivel (nivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care
defineşte graniţele între sistemul analizat si mediu.
Nivelele următoare se obţin prin rafinarea proceselor complexe într-o diagramă de
nivel inferior.
În cazul aplicaţiei Decontări, au rezultat următoarele diagrame:
Figura 3.1. Diagrama contextuală pentru aplicaţia Decontări

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

Nicolae Morariu
Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaţia Decontări
Definirea direcţiilor de perfecţionare a actualului sistem

Pe baza activităţilor de evaluare şi analiză critică se identifică neajunsurile
actualului sistem şi se propun soluţii de înlăturare a acestora se formulează variante de
soluţii, iar în cadrul acestora se definesc cerinţele şi restricţiile de realizare a sistemului
informatic.
Definirea direcţiilor de perfecţionare presupune:
1. specificarea obiectivelor şi a performantelor sistemului informatic;
2. stabilirea domeniilor de probleme şi a principalelor funcţiuni ale sistemului
informatic;
3. definirea cerinţelor si restricţiilor informaţionale pe domenii de probleme şi funcţiuni
care constă în:
definirea principalelor intrări/ ieşiri;
definirea soluţiei de organizare a datelor;
definirea variantelor tehnologice de prelucrare;
definirea restricţiilor informaţionale şi de control.
4. formularea condiţiilor pentru realizarea sistemului informatic, care constă în:
specificarea termenelor şi duratelor solicitate;
precizarea priorităţilor în realizarea obiectivelor sistemului informatic;

specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu

alte sisteme, gradul de generalizare al sistemului.
Pentru fiecare variantă de soluţie informatică se procedează la:
evaluarea resurselor necesare (costurile de sistem);
evaluarea efectelor economice directe si indirecte;
calculul indicatorilor de eficientă economică.
3.3.3. Modelarea sistemului curent
Indiferent de tipul sistemului analizat, manual sau informatizat, o problemă este
comună: el va fi înlocuit de un nou sistem. Oricât de ineficient, vechiul sistem trebuie să
transfere celui nou o serie de elemente, cum sunt datele folosite, procedurile existente.
Deci sistemul fizic actual efectuează în parte sau în întregime ceea ce-şi propune să facă
noul sistem fizic, dar la alt nivel de performanţă. 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ă conţină una sau mai multe DFD, un model de date şi logica procesului de
prelucrare. Problema comună ar consta în identificarea unei căi 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 neapărat 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 căruia se realizează:
pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul cum
funcţionează sistemul în implementarea actuală;
pune în evidenţă funcţiunile de bază ale sistemului;
permite identificarea şi eliminarea problemelor legate de redundanţa datelor şi
duplicarea proceselor de prelucrare;
permite stabilirea cu o mai mare precizie a graniţelor sistemului prin eliminarea
proceselor manuale care nu pot fi automatizate complet.
Derivarea modelului logic al sistemului existent

Construirea modelului logic presupune transformarea diagramei de flux a datelor
fizice în diagrama de flux a datelor logice.
Procesul de derivare a diagramei logice va începe de la ultimul nivel de
descompunere alcătuit de la procesele “frunză” şi va continua prin agregarea proceselor
către nivelurile superioare.
Se parcurg următorii paşi:
1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin
gruparea într-un stoc logic de date a entităţilor înrudite sau utilizate frecvent.
După identificarea stocurilor logice de date se construiesc:
diagrama de corespondenţă între stocuri logice şi entităţile din modelul logic;
diagrama de corespondenţă între stocuri fizice şi stocuri logice de date.

Nicolae Morariu
2. Înlăturarea dependenţelor fizice şi temporale din denumirea proceselor şi a fluxurilor

de date: din DFD la nivel fizic (se observă că nu există referinţe fizice şi temporale în
aplicaţia decontări).
3. Derivarea proceselor logice:
scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi
automatizate (deciziile);
înlocuirea proceselor care nu realizează nici o transformare asupra fluxurilor de date
cu fluxurile propriu-zise;
combinarea proceselor care realizează prelucrări asemănătoare sau multiple care se
execută împreună sau în secvenţă;
înlăturarea proceselor care ţin de implementarea actuală şi a proceselor redundante.
În cazul aplicaţiei prezente:
se combină procesele “Înregistrare încasări în numerar” şi “Înregistrare încasări prin
virament” deoarece realizează prelucrări asemănătoare;
se înlătură procesele redundante “Înregistrare încasări în jurnal” si “Înregistrare plăti
în jurnal”.
4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu
fluxul de
informaţii utilizate efectiv de proces.
5. Gruparea proceselor elementare şi transformarea diagramei fizice în diagramă
logică, aplicând cei 5 paşi.
Relaţia existentă între DFD şi modelul datelor

După cum reiese din prezentările anterioare, fiecare săgeată din DFD reprezintă un
flux al datelor, în sensul unui traseu pe care structurile datelor elementare sau grupate se
vor deplasa în sistem. De exemplu, Facturi desfacere este o dată grupată. Când numele ei
se plasează pe un flux de prelucrare trebuie să vedem şi obligativitatea ca acel flux să fie
descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile
documentului. Similar va fi abordat şi simbolul pentru stocare. La prima vedere, el
reprezintă locul unde se realizează operaţiunea, dar foarte important este să prezentăm
structura datelor păstrate. Firesc, şi în cazul fluxului de date, şi în cel al stocării lor nu
trebuie uitată descrierea semnificaţiei economice. Structura datelor trebuie să fie redusă la
a treia formă normalizată, iar conţinutul locurilor de stocare a datelor să fie prezentat prin
reduceri la unul sau mai multe tabele relaţionale în forma a treia normalizată [1].
În cazul aplicaţiei decontări, se obţine următoarea DFD a sistemului logic.
Decontări cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele
superioare ale DFD a sistemului logic sunt identice.

Figura 3.4. Diagrama fluxului de date
Tabel 3.1 aplicaţia Decontări

Sursa Destinaţia Nume flux Continutul fluxului
1.1. ÎnregistrareD2 FACTURIdesfaceri CODCLIENT
facturi desfacere DESFACERE DENCLIENT
ADRESAC
CONTC
BANCA_C
DATAFACTD
NRFACTD
TOTALFACTD
D2 FACTURI1.3. Analiza situaţie client desfaceri CODCLIENT
DESFACERE DENCLIENT
ADRESAC
CONTC
BANCA_C
NRFACTD
TOTALFACTD

Nicolae Morariu
3.3.4. Modelarea logicii proceselor

După ce au fost descrise procesele de conversie a datelor în informaţii, prin
intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează şi logica
internă a proceselor, oricât ar fi de detaliate, chiar şi la nivelul proceselor primare, se
impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie
astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de
programare [1].
În faza de analiză modelarea logicii proceselor se va derula cât mai detaliat şi
complet posibil, dar operaţiunea nu va respecta structura sau sintaxa unui anumit limbaj
de programare: aceasta se va realiza într-o etapă ulterioară proiectarea. Modelarea logicii
proceselor ca şi diagramele fluxurilor de date face parte din etapa de analiză a sistemului.
În analiza structurată, rezultatele obţinute în urma modelării proceselor sunt
descrieri şi diagrame structurate care vor prezenta logica fiecărui proces, precum şi
diagrame care vor evidenţia dimensiunea temporală a sistemelor, când apar procesele sau
evenimentele şi modul în care aceste evenimente schimbă starea sistemului [1].
Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în
următoarele elemente ale documentaţiei [1]:
reprezentarea în engleza structurată;
reprezentarea logicii proceselor prin tabele de decizie;
reprezentarea logicii proceselor prin arbori de decizie;
tabelul sau diagrama stărilor de tranziţie.
Reprezentarea logicii proceselor prin engleza structurată

Engleza structurată este o formă mult simplificată şi modificată a limbii engleze,
folosită pentru descrierea conţinutului casetelor care marchează procesele (prelucrările)
din diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită
în conceperea procedurilor componente ale sistemelor informatice [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 documentaţie. Utilizarea englezei structurate pentru procesul
“Analiza situaţie client” din decontări cu beneficiarii este reprezentată mai jos.
Analiza situaţie client
WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI
READ (FACTURI_DESF)
cod = FACTURI_DESF.codclient;
den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac;
cont = FACTURI_DESF.contc;
banca = FACTURI_DESF.bancac;
while (not eof (FACTURI_DESF))
{

if (cod!=FACTURI_DESF.codclient)
{ CLIENTI.codclient = cod;
CLIENTI.denclient = den;
CLIENTI.adresac = adr;
CLIENTI.contc = cont;
CLIENTI.banca_c = banca;
CLIENTI.sold = sold;
cod = FACTURI_DESF.codclient;
den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac;
cont = FACTURI_DESF.contc;
banca = FACTURI_DESF.bancac;
}
else
{
READ(ÎNCASĂRI);
vb=0; vb1=0;
while (not eof (ÎNCASĂRI) AND vb=0)
{
if (cod=ÎNCASĂRI.client AND
FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd AND
FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd)
{ if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata)
{ sold = sold+ FACTURI_DESF.totalfactd -
ÎNCASĂRI.sumaincasata}
vb1=1;
}
else if (vb1=1) vb=1
READ (ÎNCASĂRI)
}
MOVE FIRST LINE ÎNCASĂRI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI)
3.4. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)

În cadrul modelării conceptuale a datelor se va renunţa la abordarea proceselor şi
se va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul modelării
proceselor şi modelării logicii proceselor elementele esenţiale vor fi diagramele.
James Martin şi Carma McClure, atunci când reliefează importanţa tehnicilor
structurate prin obiectivele ce şi le propun, consideră că o parte a acestora au legătură şi
cu datele, şi anume [1]:

Nicolae Morariu
Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se

referă la structurarea corectă a datelor, la uniformitatea modalităţilor de definire
şi proiectare a datelor la nivel de întreprindere şi nu a sistemului. Corect
efectuate, acestea accelerează procesele de analiză şi proiectare şi permit să se
utilizeze în comun componentele esenţiale ale sistemelor: resursele.
Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică
problemele de structurare a lor şi conduc la structuri stabile ale acestora,
concretizate prin costuri reduse ale realizării sistemelor. Dacă baza de date a
unităţii este deosebit de importantă, atunci pe analiza datelor trebuie să se pună
un accent aparte, ea fiind întotdeauna realizată înaintea proiectării programelor.
Firesc, dacă ştim care sunt cerinţele unui sistem (ieşirile), imediat ne vom pune
întrebarea din ce se obţin acestea (intrările) şi apoi vom urmări cum se pot obţine
ieşirile (procesele).
Obiectivul principal al ingineriei informaţiei este crearea unui set de metodologii
care să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască
modele ale datelor la 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 văzute două
categorii mari de operaţiuni:
asigurarea datelor (creare, actualizare);
utilizarea datelor (obţinere de documente, de diverse rapoarte, analize „What-If”,
sprijin decizional, diferite căutări de informaţii, control şi auditare întreprindere).
Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor
organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi
legăturile existente între date [1].
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-
relaţie (DER). O modalitate aproape identică este folosită şi în analiza şi proiectarea
orietată-obiect.
Modelarea datelor prin DER prezintă caracteristicile şi structura datelor
independent de modul în care acestea sunt memorate în calculator. Modelul se creează
iterativ. De cele mai multe ori, operaţiunea are loc la nivel de întreprindere, prin apelarea
la o categorie foarte largă de date neglijându-se detaliile exagerate. Doar în etapele
următoare, în speţă când se trece la definirea proiectului, are loc construirea unui model
anume entitate-relaţie prin care să fie scoasă în evidenţă aria de întindere a proiectului. În
timpul structurării cerinţelor, un model entiatate-relaţie reprezintă cerinţele conceptuale
de date pentru sistemul luat în discuţie. După ce sunt descrise complet intrările şi ieşirile
sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma
entitate-relaţie, este rafinat înainte de a fi trecut într-un format logic (de regulă, un model
relaţional al datelor) din care se definesc bazele de date şi are loc proiectarea fizică a
acestora [1].
DER joacă un rol deosebit de important în formarea profesională a veritabililor
analişti.
Se consideră că, în timpul modelării conceptuale a datelor, se produc şi se
analizează cel puţin patru diagrame entitate-relaţie [1]:

1. DER care să acopere datele necesare aplicaţiei proiectului. Ea va permite stabilirea

necesarului de date ale aplicaţiei proiectului, fără să se ţină seama de constrângerile
sau confuziile generate de detaliile care nu sunt încă necesare.
2. DER pentru aplicaţia ce va fi înlocuită. Diferenţele dintre aceste diagrame arată ce
schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicaţie. Nu se
aplică în cazul sistemelor complet noi.
3. DER care să scoată în relief întreaga bază de date din care noua aplicaţie îşi va
extrage datele. Cât timp mai multe aplicaţii pot folosi aceeaşi bază de date, această
diagramă şi prima evidenţiază modul în care noua aplicaţie apelează la conţinutul
unor baze de date mult mai extinse.
4. DER pentru întreaga bază de date din care aplicaţia curentă îşi extrage datele
necesare. Ea este discutată doar pentru sistemele care există şi pentru care se
urmăreşte îmbunătăţirea. Din nou, diferenţele dintre diagrama precedentă şi cea de
faţă vor indica modificările majore de efectuat pentru a se putea influenţa noua
aplicaţie.
Metodele de determinare a cerinţelor trebuie să fie orientate, prin întrebările puse,
prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor. La
început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de
modul în care va afla cât mai multe informaţii despre datele necesare viitorului sistem
pentru a funcţiona la parametrii proiectaţi. Întrebările vor fi astfel formulate încât să se
realizeze o bună înţelegere a regulilor după care vor fi folosite datele în noul sistem, ce
politici vor fi utilizate. Nu trebuie, încă, să se intre în detalii de genul: când şi cum sunt
prelucrate sau folosite datele, pentru a se realiza modelarea datelor [1].
Modelarea datelor se realizează printr-o combinaţie a punctelor de vedere.
Un prim punct de vedere, formulat în literatură sub numele de metoda top-down, va
scoate în evidenţă regulile derulării activităţii firmei, printr-o înţelegere foarte clară a
naturii afacerii, şi nu se va opri asupra detaliilor privind modul în care ecranele,
rapoartele sau documentele sunt folosite în organizaţie [1].
În afara metodei top-down, informaţiile necesare construirii modelului datelor se
pot obţine şi prin urmărirea documentaţiei firmei, ecrane, rapoarte, formulare, din
interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub numele
de metoda bottom-up [1].
Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi
evidenţiate datele prelucrate în sistem şi de aici va rezulta necesarul de date menţinute în
baza de date a sistemului.
Definirea conceptului de entitate

Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în cazul
nostru). Obiectele se caracterizează printr-o existenţă de-a lungul timpului, iar
evenimentele îşi fac simţită prezenţa la un moment dat [1].
La rândul lor, obiectelor li se pot asocia cel puţin două evenimente: apariţia şi
dispariţia lor. Exemple: încheierea şi încetarea contractului de muncă; predarea
produselor la secţia expediţie şi desfacerea lor la beneficiari ş.a.

Nicolae Morariu
La fel putem spune şi despre evenimente. Ele reprezintă asocieri între două sau mai
multe obiecte. Exemplu: CLIENT COMANDĂ PRODUS.
Entităţile conţin î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 organizaţia doreşte să păstreze anumite date. Se
cuvine precizată diferenţa dintre tipurile entităţilor (entity types) şi cazurile/instanţele
entităţii (entity instances) [1].
Tipul entităţii, cunoscut şi sub numele de clasa entităţii, este o colecţie de entităţi
care au proprietăţi sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume.
Cât timp numele reprezintă o clasă sau un set de cazuri, el este singular. Şi încă o
convenţie. Cum referirea generală la elementele ce pot fi catalogate ca entităţi se poate
face prin noţiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi
proiectării orientate obiect), referirea la acesta se va realiza printr-un substantiv la
singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător
entităţii.
O instanţiere a entităţii sau instanţă, denumită de noi în continuare, caz al entităţii
sau caz, este o manifestare singulară a unui tip de entitate. Un tip de entitate se descrie o
singură dată prin modelul datelor, în timp ce mai multe cazuri ale acelui tip de entitate pot
fi reprezentate prin datele stocate în bazele de date. De exemplu, există o singură entitate
CLIENT, dar ea poate să aibă sute sau mii de cazuri/instanţe ale acestei entităţi stocate în
baza de date.
Atribute
Fiecare tip de entitate are un set de atribute asociate lui.
Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă interes
pentru organizaţie. La rândul lor, şi relaţiile pot avea propriile lor atribute.
Exemplu de entitate pentru aplicaţia DECONTĂRI şi unele dintre atributele
posibile:
CLIENT : CodClient, DenClient, AdresaC
Ca şi numele tipurilor entităţilor, numele atributelor sunt substantive scrise cu
majuscule, plasate în interiorul elipselor, legate de entitatea căreia i se asociază. De multe
ori însă, chiar şi în cazul folosirii produselor CASE, pentru a nu se încărca o diagramă
entitate-relaţie, se evită prezentarea atributelor. Operaţiunea se face, în schimb, în
repository, depozitul de informaţii despre proiect. Aici orice atribut se descrie separat, ca
orice obiect distinct.
Unul dintre exemplele anterioare poate fi reprezentat în diagramă conform fig. 3.5.
DenClien
t
CodClient CLIENT AdresaC
Figura 3.5. Model de reprezentare a atributelor DER

Cheie candidat şi cheie primară

Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se
efectueze diferenţierea unui caz de acelaşi tip.
O cheie candidat aste un atribut sau o combinaţie de atribute prin care se poate
identifica în mod unic un caz (o instanţă) al tipului entităţii respective.
Sunt entităţi care pot avea două sau mai multe chei-candidat. În exemplul nostru,
pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunând că ele identifică în
mod unic un angajat). Atunci când 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 reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor
ce formează cheia primară, numele respective se subliniază (vezi CodClient din entitatea
CLIENT ).
Relaţiile entităţilor
Relaţiile reprezintă legăturile între componentele unei diagrame entitate-relaţie. O
relaţie este o asociere între cazurile/instanţele uneia sau mai multor tipuri de entităţi care
prezintă interes pentru organizaţie. Ele se pot simboliza printr-un romb. De regulă,
relaţiile sunt redate prin verbe.
Cardinalitatea relaţiilor
STUDENT Înscris CURS_CREDIT

pentru
Figura 3.6. Tip Relaţie

Presupunem că există două tipuri de entităţi, A şi B, între care există o linie de
legătură pentru a marca relaţia. Cardinalitatea unei relaţii este dată de un număr al
cazurilor/instanţelor entităţii B care pot sau care ar putea să fie asociate cu fiecare caz al
entităţii A. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”), cu menţiunea că ele
pot avea prezenţă obligatorie sau opţională. Trimiterea la cardinalitate se face în moduri
destul de diferite, în funcţie de notaţia folosită. Recomandăm citirea cu atenţie a
obligatoriu 1
diagramelor şi descifrarea elementelor strict necesare înţelegerii, îndeosebi pentru
opţional
reflectarea cardinalităţii. 0 sau 1 ea poate fi notată cu semne (0, 1, M, N) sau prin
De exemplu,
simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de săgeată pentru
obligatoriu
M. Alteori, 1nse reprezintă multe
prin linie (n, şi
simplă unde n iavârf
M prin valori de la 1 laÎnM)
de săgeată). multe materiale,
inclusiv produse CASE, se foloseşte notaţia model-date, cunoscută mai mult sub numele
opţional 1 sau multe (n, unde n ia valori de la 1 la M)
n
laba-gâştei, conform cârei cardinalitatea se reprezintă prin următoarele simboluri [1]:

Nicolae Morariu
Entităţi compuse sau asociative (gerundive)

Atributele pot fi asociate cu o relaţie multe-la-multe sau cu o entitate. Un exemplu,
din lumea cursurilor-credit, transferabile în cadrul unei perioade. Un student poate lua
mai multe cursuri dintr-o listă, dar finalizarea cu notă se poate efectua în momente (la
date) diferite. Prezentăm, mai jos, câteva dintre datele concrete [1]:
MATRICOLA STUDENT NUME CURS DATA PROMOVĂRII
1111 Informatică Iulie 1999
1177 Informatică Septembrie 1999
1155 Informatică Septembrie 1999
1111 Drept comercial Ianuarie 2000
Din analiza cazurilor rezultă că atributul DATA_PROMOVĂRII nu este o
proprietate a entităţii STUDENT, cât timp examenele pot fi date la momente diferite. Dar
nu este nici o proprietate a entităţii CURS, cât timp acelaşi curs poate fi susţinut la date
diferite. În schimb, DATA_PROMOVĂRII este o proprietate a relaţiei dintre STUDENT
şi CURS. Atributul se asociază relaţiei şi se prezintă sub formă de diagramă, ca în fig.
3.7.
DATA PROMOVĂRII
STUDENT Promovare CURS
Figura 3.7. Asocierea unui atribut la o relaţie [1]

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

Figura 3.8. Redarea unei entităţi gerundive (asociative) [1]
Nu trebuie confundată această situaţie cu relaţiile transformate în entităţi

nepurtătoare de informaţii, descrise anterior.
Scopul diagramelor entitate-relaţie este de a surprinde cele mai complete sensuri
posibile ale datelor necesare sistemului informaţional din organizaţie.
Tipuri de relaţii
Din cele prezentate mai sus, rezultă că între entităţile descrise, luate două câte
două, se pot identifica trei tipuri de relaţii: unu-la-unu, unu-la-multe, multe-la-multe. În
diagrame, descrierea relaţiilor se face de-a lungul liniilor care leagă cele două entităţi.
Simbolul vârf-de-săgeată este cunoscut ca indicator al cardinalităţii (cardinality
indicator).
În cele ce urmează sunt prezentate exemple de tipuri de relaţii [1].
1. Relaţia unu-la-unu (1:1)
BIROU este condus de MANAGER

conduce
Figura 3.9. Descrierea relaţiei 1:1
„Fiecare BIROU este condus de un, şi numai un, MANAGER”

„Fiecare MANAGER conduce un, şi numai un, BIROU”.
2. Relaţia unu-la-multe (1:M)
implică ARTICOL
VÂNZARE
face parte din VÂNDUT
Figura 3.10. Descrierea relaţiei 1:M
„Fiecare VÂNZARE implică unul sau mai multe ATRICOL(e)_VÂNDUT(e) “

„Fiecare ATRICOL_VÂNDUT face parte din numai o VÂNZARE”
3. Relaţia multe-la-multe
FURNIZOR livrează PRODUS

este livrat de
Figura 3.11. Descrierea relaţiei M:N
“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”

Nicolae Morariu
“Fiecare PRODUS este livrat de unul sau mai mulţi FURNIZOR(i)”

În anumite cazuri, între două entităţi pot exista mai multe relaţii.
De exemplu, s-ar putea spune că “FURNIZOR oferă PRODUS”, dar şi “PRODUS
este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. 3.12.
oferă
PRODUS FURNIZOR
este cumpărat de la
Figura 3. 12. Descrierea relaţiilor multiple între două entităţi
4. Relaţii opţionale şi obligatorii

Alteori, relaţiile dintre entităţi nu-şi fac simţită prezenţa în toate situaţiile. Chiar
cazul cu studiile la care lucrează diverse persoane este destul de elocvent; o persoană
poate să lucreze la un singur studiu sau la câteva, sau la niciunul şi, invers, un studiu
poate fi efectuat de o persoană, de mai multe sau de nici una. În astfel de situaţii, se
apelează la următoarea formă de reprezentare. (fig. 3.13)
PERSOANA lucrează la STUDIU

este realizat de
Figura 3.13. Exemplu de relaţie opţională
Cercul suprapus pe latura entităţii indică, de fapt, poziţia 0 (valoarea minimă poate
fi şi zero), conferind relaţiei caracterul opţional.
Un alt aspect se referă la caracterul obligatoriu al relaţiilor. Cu alte cuvinte, o
entitate poate exista fără cealaltă?
Să luăm exemplul vânzărilor. În relaţia 1:M, dintre VÂNZARE şi
ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o
vânzare fără cel puţin un articol vândut şi, invers, un articol nu poate fi vândut fără o
vânzare (operaţiunea nu ar avea sens). Simbolul folosit pt a marca relaţiile obligatorii este
acelaşi cerc, cu deosebirea că este haşurat.
VÂNZARE ARTICOL
VÂNDUT
Figura 3.14. Exemplu de relaţie obligatorie
5. Relaţia unei entităţi cu ea însăşi

În practică, apar şi situaţii în care o entitate este pusă în relaţie cu ea însăşi.

Ne oprim la exemplul entităţii ANGAJAT. Unii dintre ei dobândesc statutul de
coordonatori ai activităţii celorlalţi, situaţii în care se poate apela la o diagramă de genul
celei din fig.3.15.
coordonator al
ANGAJAT
raportează la
Figura 3.15. Redarea relaţiei unei entităţi cu ea însăşi
Reprezentarea anterioară se citeşte astfel:

“Un angajat poate fi coordonatorul unuia sau mai multor angajaţi”
“Oricare angajat întotdeauna raportează altui angajat”
6. Relaţii alternative (sau/sau)

Uneori se ivesc situaţii când relaţiile posibile se redau alternativ: fie o variantă este
de urmat, fie cealaltă. De exemplu, o marfă destinată vânzării poate fi realizată de
unitatea care o vinde sau poate fi procurată din afară. În ambele cazuri, obiectul
comercializat, MARFA, care este o entitate, va fi pusă în legătură cu cele două surse
posibile, PRODUCŢIA_ALTORA şi PRODUCŢIA_PROPRIE, printr-un punct comun,
dar nu cu linii de relaţii distincte, aşa cum este prezentat în figura 3.16.
PRODUCŢIA
ALTORA
MARFA
PRODUCŢIA
Figura 3.16. Exemplu de diagramă pentru relaţiile alternative
PROPRIE
Citirea diagramei este:
“O marfă se poate asocia sau cu un producător din afară, sau cu producţia unităţii”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producţie poate livra mai multe mărfuri”
Deşi diagramele entitate-relaţie se cunosc de către mulţi specialişti din lumea bazelor de
date, ele constituie unul din conceptele esenţiale ale analizei şi proiectării structurate şi,
ca atare, provin din acest domeniu [1].
După cum reiese şi din citirea cu atenţie a numelui diagramei, scopul ei este de a
evidenţia entităţile de date (obiectele despre care se solicită păstrarea datelor) şi relaţiile
ce există între ele.

Nicolae Morariu
De remarcat diferenţa dintre diagrama fluxului de date şi diagrama entitate-relaţie.

În timp ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât şi entităţile
de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează
doar entităţile de date. Din această cauză, DER poate fi considerată şi ca diagrama
modelului datelor sau diagrama conceptuală a datelor [1].
În sistemul analizat pentru descrierea DER se apelează la simbolul dreptunghi,
pentru fiecare entitate. Se recomandă ca numele entităţii să fie redat printr-un substantiv
la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, ÎNCASĂRI).
După ce se identifică entităţile se continuă cu împerecherea lor, fiecare cu fiecare,
pentru a descrie relaţiile dintre ele.
Figura 3.17. DER pentru aplicaţia Decontări

3.4.1. Modelul Entitate/Relaţie (E/R)

Cercetările efectuate pentru definirea unui model de date care să permită
reprezentarea cât mai fidelă a realităţii au condus la definirea conceptului de model
semantic încă din 1976 când Chen a prezentat modelul Entitate-Relatie (E/R), care
constituie astăzi o tehnică larg acceptată pentru proiectarea bazelor de date.
Modelul E/R permite proiectantului bazei de date să elaboreze un model
conceptual de nivel înalt, fără a ţine seama de anumite constrângeri impuse de utilizarea
unui anumit SGBD, de o anumită platformă hardware, sau de anumite considerente de
eficienţă privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidelă a
realităţii avute în vedere, constituind astfel o etapă intermediară în proiectarea unei baze
de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în activitatea
de programare.
Modelul Entitate/Relaţie (E/R) permite reprezentarea schematică a realităţii
avute în vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază:
tip de entitate, tip de relaţie (legătură, corelaţie), atribut.
Pentru reprezentarea unor probleme complexe de tip bază de date, apărute
începând din anii 80, modelul de date semantic a fost extins cu noi concepte semantice,
rezultând astfel modelul entitate relaţie extins EER. În acest sens la conceptele de bază au
fost adăugate conceptele suplimentare de superclasă, subclasă şi moştenire.
O superclasă reprezintă un tip de entitate care conţine subclase distincte
care trebuie să fie reprezentate în cadrul modelului, iar o subclasă este un membru
al unei superclase. O subclasă, fiind un tip de entitate distinct, poate avea la rândul
său subclase, astfel încât se pot construi ierarhii de clase. O subclasă moşteneşte
toate atributele superclasei, putând avea în plus şi alte atribute. În diagrama EER,
pentru subclase se vor reprezenta numai atributele specifice subclasei.
Pentru elaborarea unei diagrame EER, se utilizează [11], [13] o serie de
simboluri reprezentate în figura 3.18.

Nicolae Morariu
<nume tip Reprezentare tip entitate cu numele <nume tip entitate>

entitate>
<nume Reprezentare atribut cu numele <nume

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

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

atribut> atribut>
<atribut <atribut Reprezentare atribut compus <nume

1> 2> atribut>
format din componentele <atribut1>,
<atribut2>
<nume
atribut>
<nume tip
entitate> Apartenenţa atributului <nume atribut>
la tipul de entitate <nume tip entitate>
<nume
atribut>
<nume tip Reprezentare tip de relaţie cu numele <nume tip

relaţie> relaţie>
E R RELAŢIA R FUNCŢIONALĂ FAŢĂ DE TIPUL

DE ENTITATE E
E R RELAŢIA R NEFUNCŢIONALĂ FAŢĂ DE TIPUL

DE ENTITATE E
Superclasa
Contabilitate şi informatică de gestiune APARTENENŢA SUBCLASEI LA 53
SUPERCLASĂ
Subclasa
FIG. 3.18. SIMBOLURI UTILIZATE ÎN REPREZENTAREA UNEI

DIAGRAME EER
Problemă rezolvată
Folosind modelul entitate - relaţie să se reprezinte diagrama E/R pentru un

sistem informatic simplificat al unei firme care desfăşoară activitate de comerţ fiind
avute în vedere subsistemele;
- aprovizionare (evidenţa furnizorilor);
- desfacere (situaţia vânzărilor);
- urmărirea stocurilor.
Cod Cod produs

furnizor
m n
FURNIZORI Oferte PRODUSE
Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaţiei de tip m-n Oferte
Cod produs Cod client
m n
PRODUSE Vânzări CLIENTI
VANZARI
Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaţiei de tip m-n Vânzări
Cod produs Aprovizionare

Cod
Produs+Depozit+Preţ
1 Intrări n
PRODUSE STOCURI
1
Contabilitate şi informatică de gestiune Ieşiri n 54
Desfacere
Fig. 3.21. Subsistemul Urmărirea stocurilor.
Reprezentarea relaţiilor de tip 1-n Intrări, Ieşiri, pentru actualizarea stocurilor
Nicolae Morariu
Cod produs Denumire Descriere

produs produs
PRODUSE
Fig. 3.22. Reprezentarea entităţii PRODUSE
Stradă Număr
Localitate
Cod furnizor Denumire Adresa furnizor

furnizor
Oferta
PRODUSE
Fig. 3.23. Reprezentarea entităţii FURNIZORI
Cod produs Unitate de Preţ unitar

măsură produs
produs
Cod furnizor Oferte

Fig. 3.24. Reprezentarea relaţiei Oferte

3.5. Selectarea celei mai bune variante strategice de proiectare

Întregul efort depus până în momentul de faţă s-a concretizat într-o bogată
acumulare de informaţii despre cerinţele sistemului, structurate sub diverse forme,
precum şi despre modul în care am dori să fie conceput noul sistem sau ce corecţii să i se
aducă celui vechi.
Ne aflăm în aşa-zisa fază a strategiei proiectului.
În afara certitudinilor concretizate în specificaţiile elaborate până acum, asupra
variantei noului sistem planează şi o seamă de incertitudini, generate de nehotărârea sau,
încă, needificarea asupra formei finale dorite. Un cuvânt greu au utilizatorii şi finanţatorii
proiectului. Pentru a-i ajuta să ajungă la o concluzie finală comună, trebuie pornit de la
cerinţele structurate şi se vor prezenta câteva strategii concurente de proiectare, dintre
care doar una va fi continuată în pasul următor al ciclului de viaţă al sistemului, faza de
proiectare, în funcţie de performanţele ei şi de încadrarea în resursele disponibile [1].
Rezultatul final al studiului de identificare a cerinţelor de informaţii se
concretizează într-un raport detaliat al cerinţelor sistemului, în care vor fi prezentate
informaţiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie să fie produs de
către sistem. El va lăsa fazei de proiectare o imagine clară a modului în care se vor obţine
cerinţele sistemului.
Raportul conţine următoarele elemente [1]:
descrierea funcţiilor principale executate în noul sistem, inclusiv ce trebuie făcut şi de
cine, cum se realizează interfaţa funcţiilor cu întregul sistem şi cum funcţiile noi vor
afecta utilizatorii;
descrierea tuturor datelor necesare sistemului, inclusiv nume, mărimea, 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 arăta cum datele vor fi organizate în
înregistrări logice şi care este legătura dintre date;
descrierea modului de funcţionare a noului sistem şi a subsistemelor componente,
precum şi a modului în care vor fi atinse obiectivele de către întregul organism;
descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv
numele fiecărei intrări, sursa, cine îl completează, ce date va conţine şi cum vor fi
culese datele din el;
o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte,
documente);
descrierea unor norme interne de conduită privind raportările, programarea
activităţilor, securitatea şi protecţia, personalul implicat şi zona de acces pe categorii
ale acestuia;
prezentarea restricţiilor existente în sistem, cum ar fi statutele şi regulamentele de
organizare.

Nicolae Morariu
CAPITOLUL 4
PROIECTAREA LOGICĂ A SISTEMELOR INFORMATICE
În cadrul acestui capitol este realizată prezentarea noului sistem prin prezentarea
tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurilor. Având în
vedere intrările şi ieşirile sisemului este prezentată proiectarea logică a bazei de date,
activitate prin care se urmăreşte transformarea diagramelor entitate-relaţie în relaţii.
Dacă în primele etape, au fost identificate şi structurate cerinţele sistemului, în faza
de proiectare logică se efectuează deplasarea atenţiei de la prezentarea a ceea ce există şi
ce se intenţionează la descrierea a ceea ce va însemna noul sistem, cum va funcţiona.
Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrărilor
sistemului, a ieşirilor, precum şi a interfeţelor şi dialogurile. Ele se construiesc pe baza a
ceea ce s-a identificat în etapele anterioare, dar ţinându-se cont şi de cerinţele identificate
în timpul desfăşurării activităţilor din etapa de proiectare logică [1].
Toate intrările şi ieşirile sistemului, în faza de proiectare logică, vor fi prezentate ca
fluxuri ale datelor între un proces manual şi altul automat sau între o sursă/ destinaţie şi
un proces automat din diagramele fluxurilor de date. De regulă se poate proiecta câte un
formular sau raport pentru fiecare flux de date dintre utilizator şi sistem.
Documentaţia 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, intrările şi ieşirile au fost
identificate şi prezentate, exprimând cerinţele informaţionale la nivelul fiecărui
subsistem/ aplicaţie informatică. În acel moment nu s-au prezentat toate detaliile privind
formularele/formatele, rapoartele şi procesul de modelare a datelor, insistându-se mai
mult pe identificarea şi descrierea lor. Fiecare format/formular de intrare va fi asociat
unui flux al datelor de intrare într-un proces al DFD, iar rapoartele se pot regăsi într-un
flux al datelor generate de un proces al DFD.
Un formular/format poate fi un document primar sau o machetă de ecran care
conţine unele date predefinite, cărora li se adaugă altele ce urmează a fi completate în
rubrici speciale.
Un raport este un document economic în care sunt incluse doar date predefinite,
ceea ce înseamnă că poate fi numit şi document pasiv, folosit pentru a citi şi vizualiza
informaţia.
În faza de proiectatre logică se reprezintă doar o ciornă a formularelor/formatelor,
rapoartelor sau ecranelor, ele fiind privite doar ca structură şi machetă. Ceea ce ne
propunem în cadrul proiectării logice poate fi realizat cu ajutorul unui editor de texte sau
un produs program orientat spre grafică, sub forma unui prototip [1].

4.1.1. Proiectarea situaţiilor cu rezultate finale (rapoartelor)

Obiectivul prezentării detaliate a ieşirilor este şi acela de a determina formatul şi
conţinutul tuturor rapoartelor imprimate şi ale documentelor şi ecranelor furnizate de
sistem.
Proiectarea ieşirilor se va face astfel încât să servească pentru [2]:
transmiterea rezultatelor prelucrării pe calculator utilizatorului, într-o formă pe
care acesta să o înţeleagă şi în care să-şi regăsească cerinţele sale;
transmiterea proiectului situaţiilor finale programatorului, fără ambiguităţi,
pentru a-i permite acestuia trecerea la întocmirea programelor necesare editării
sau vizualizării.
În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al
raportului sau ecranului şi să întrebe utilizatorul dacă informaţiile din raport şi formatul
acestuia sunt accesibile. Dacă ieşirile 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 situaţiei de ieşire, cuprinzând:
antet;
titlu;
date de identificare;
cap de tabel;
date elementare ce se imprima rând de rând;
totalurile.
detalii şi indicaţii tehnice de realizare care se referă la:
volumul datelor de ieşire;
frecvenţă;
număr de copii şi destinaţia fiecăreia;
grad de precizie al calculelor;
condiţii speciale de editare;
criterii de control, validare şi interpretare a datelor de ieşire.
Specificaţiile de ieşire vor cuprinde, pentru utilizator, macheta situaţiei iar pentru
programator macheta situaţiei şi o serie de indicaţii tehnice de realizare.
Pe baza specificaţiilor de ieşire se trece la proiectarea fizică prin care se alege
suportul informaţiilor de ieşire, se realizează definitivarea formei şi formatului de editare
a situaţiilor (aşezarea în pagina / ecran, spaţierea între coloane şi rânduri, etc.) şi se
definitivează procedurile de utilizare şi interpretare a ieşirilor [2].
Alegerea tipului de suport fizic de ieşire (imprimanta, display, disc fix, floppy disc,
banda magnetica etc.) se face în funcţie de: timpul de răspuns solicitat, amplasarea
utilizatorului faţă de calculator, hard-ul şi soft-ul existent, costul suportului, măsura în
care răspunde necesitaţilor de redare a conţinutului informaţional al situaţiei finale [2].
Când se pregătesc ieşirile, este bine să se ia în calcul ce se urmăreşte prin ele, astfel
încât apelarea la categoriile de date de mai sus să se efectueze în cunoştinţă de cauză.

Nicolae Morariu
În definitivarea formei şi formatului de prezentare a situaţiilor finale trebuie să

ţinem seama de o serie de considerente practice cum ar fi [2]:
Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei

finale;
Restricţii tehnice;
Elemente de eficienţă;
Lizibilitate – spaţiere;
Utilizarea formularelor pretipărite;
Utilizarea monitoarelor sau terminalelor video;
Utilizarea generatoarelor de rapoarte.
Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei finale
O serie de cerinţe ale conducerii privind macheta situaţiei finale obligă proiectantul
la o anumită structurare şi machetare a situaţiilor finale. Informaţiile se pot împărţii în
două grupe prin prisma sistemelor informatice interne şi externe. Informaţiile interne
reprezintă acele informaţii culese, generate sau folosite în interiorul organizaţiei.
Informaţiile externe se referă la cele colectate sau create de la sau pentru parteneri străini
(facturi, rapoarte anuale, etc) [2].
În funcţie de informaţiile care pot fi văzute din punct de vedere al echipei
manageriale distingem: informaţii curente, de atenţionare, indicatori de bază, etc.
Restricţii tehnice
În proiectarea situaţiilor finale intervin o serie de restricţii datorate caracteristicilor
şi performanţelor tehnice ale echipamentelor periferice şi anume: numărul maxim de
caractere pe linie; numărul maxim de linii pe pagina / ecran; facilităţile de imprimare etc.
Pe piaţă se afla o gamă variată de echipamente de redare a rezultatelor. Există mai multe
tipuri de imprimante, console şi terminale video, ceea ce creează posibilitatea unei alegeri
adecvate a perifericelor destinate obţinerii diverselor tipuri de situaţii finale [2].
Elemente de eficienţă
În proiectarea situaţiilor finale nu trebuie sa scape atenţiei şi aspectele de eficientă
economică privind: reducerea timpului calculator consumat cu editarea propriu-zisa a
situaţiilor; economie de hârtie de imprimantă. Abilitatea şi experienţa proprie a
programatorilor joacă în acest sens un rol important.
În vederea optimizării obţinerii situaţiilor finale pe imprimantă se pot folosi de la
caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeaşi pagină de
imprimantă; editarea unei situaţii imprimând faţă/verso pe aceeaşi coală;
Pentru a nu irosi timp cu editarea unor situaţii finale voluminoase se recomandă
mai întâi rularea unor programe scurte care să verifice cheile de control aplicate. Numai
dacă aceste chei sunt corecte, eventual verificate şi de utilizator, se poate lansa editarea
analitica a situaţiilor finale. Programele care editează situaţii finale voluminoase trebuie
prevăzute cu posibilitatea de întrerupere (respectiv de reluare a editării în cazul unor
incidente ivite în timpul rulării) sau editarea lor sub forma unui fişier ASCII sau text pe
hard disc sau floppy disc, urmând imprimarea ulterioara a acestui fişier, total sau parţial
[2].

Lizibilitate – spaţiere
Parcurgerea unei situaţii finale trebuie să fie cât mai uşoara, “citirea” unei situaţii
nu trebuie să dea naştere la ambiguităţi. Este necesar ca situaţia sa fie autoexplicativă.
Pentru aceasta, antetul va conţine informaţii şi coduri ce vor indica sursa de emitere a
raportului, exprimând clar, sintetic, conţinutul raportului şi perioada la care se referă.
Capul de tabel, împreuna cu titlul şi antetul, se afişează pe următoarele pagini
numai dacă au intervenit schimbări în cadrul caracteristicilor de grupare faţă de prima
pagină, altfel se imprimă doar numerotarea coloanelor de tabel.
Informaţiile importante pot fi subliniate. Totalurile se separă de informaţiile
analitice. Informaţiile care se repetă pe linii succesive se imprimă o singură dată [2].
Utilizarea formularelor pretipărite
Aceasta implica utilizarea unei hârtii de imprimanta ce cuprinde elemente fixe ale
situaţiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
conduce la o creştere a vitezei de editare şi o diminuare a uzurii imprimantelor, riboanelor
etc. Totodată situaţiile obţinute sunt mai estetice şi sunt uşor de parcurs de utilizatori [2].
Utilizarea monitoarelor sau terminalelor video
Prin intermediul unui soft adecvat, monitoarele sau terminalele video oferă
posibilitatea afişării situaţiilor finale, atât în regim alfanumeric, cât şi în regim grafic,
alegerea modului de lucru făcându-se prin intermediul unor comenzi sau comutatori.
Ecranul unui terminal video în regim alfanumeric este alcătuit din linii şi coloane
iar în regim grafic ecranul este privit ca o matrice de puncte denumite “pixeli”.
Reprezentarea informaţiilor de ieşire sub forma grafică reprezintă un pas înainte
faţă de editarea sub forma de text a rapoartelor. Această formă de afişare se recomandă
factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare
a informaţiilor de ieşire şi volumul redus al rapoartelor.
Pe lângă problemele legate de aşezarea informaţiilor pe ecran, la proiectarea
ecranelor de ieşire se iau în considerare şi facilităţile oferite de monitoare sau terminalele
video şi anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afişare
(normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonoră
(normal, semnal sonor după afişarea unui câmp etc.) [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ă, conţinutul unui rând de date (de detaliu),
gradele de total şi maniera lor de afişare, la începutul sau la sfârşitul grupului de date, al
paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane,
pagini, spaţierea dintre linii, coloane, afişarea datelor privind momentul listării, statistici
etc.
Astfel de module specializate există în pachete de programe pentru gestionarea
bazelor de date cum ar fi: ACCESS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.

Nicolae Morariu
4.1.2. Proiectarea codurilor

În proiectarea sistemului de coduri trebuie să avem în vedere două aspecte
importante şi anume [2]:
influenţa tipului şi structurii codului asupra performanţelor sistemului informatic;
implicaţiile utilizării codurilor în operaţiile de culegere a datelor şi interpretarea
rezultatelor finale de către utilizatorii neinformaticieni.
Primul aspect ridică probleme de ordin tehnic în realizarea nomenclatorului de
coduri şi are în vedere facilitarea operaţiilor de prelucrare, ocuparea unui spaţiu de
memorie internă şi externă cât mai mic etc.
Celui de-al doilea aspect trebuie să i se acorde o atenţie mai mare în vederea
uşurării activităţilor de culegere, verificare a datelor şi interpretarea rezultatelor din
situaţiile finale. Având în vedere aceste considerente, se impune ca la proiectarea unui
sistem de coduri să se respecte o serie de cerinţe.
De exemplu, codul persoanei poate fi format din următoarele coduri elementare:
X X X XX XXX XXXX XX
Iniţiala Iniţiala Sex Ziua naşterii Luna naşterii Anul Grupa
nume prenume naşterii sanguină
Activităţile 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 relaţiilor dintre elementele de codificat;
alegerea tipurilor de coduri; estimarea capacităţii, lungimii şi formatului codurilor;
atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri);
întreţinerea nomenclatoarelor de coduri.
Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la
nivelul economiei naţionale (CAEN, SIRUES, SIRUTA, CNP, etc).
4.1.3. Proiectarea intrărilor în sistemul informatic
Datele de intrare parcurg o succesiune de etape până la utilizarea efectivă în
cadrul sistemului informatic. Aceste etape intermediare sunt: înregistrarea datelor pe
documentul de intrare; conversia datelor într-o formă acceptata de sistemul de calcul /
transpunere pe suportul tehnic; verificarea sintactică şi semantică a datelor de intrare;
corecţia datelor eronate etc.
La proiectarea intrărilor este necesar să se realizeze, în principal următoarele
activităţi:
alegerea suportului tehnic pentru culegerea datelor
proiectarea machetelor documentelor de intrare, stabilirea instrucţiunilor de culegere
stabilirea regulilor de control şi validare a datelor
proiectarea formularelor (videoformatului) de intrare.
Alegerea suportului tehnic al datelor de intrare se face în funcţie de cerinţele
aplicaţiei informatice. Datele introduse de la terminalul video fie intră imediat în circuitul
de prelucrare-actualizare a unei baze de date, fie sunt stocate pe un suport magnetic sau
sunt stocate în vederea prelucrării ulterioare. [2]

La proiectarea machetei documentelor de intrare (indiferent de metodele de

prelucrare a datelor folosite ulterior) sunt respectate câteva reguli care să înlesnească
completarea şi apoi utilizarea documentului atât pentru prelucrarea automată a datelor cât
mai ales pentru necesităţile curente ale salariaţilor societăţii economice. Nu este
recomandabil să dublăm documentele primare, prin proiectarea unor documente destinate
exclusiv preluării datelor pentru necesităţile prelucrării automate [2].
Macheta documentului primar trebuie să conţină:
antetul–ce reprezintă denumirea unităţii şi/sau a serviciului care-l emite;
denumirea documentului;
coduri de identificare,
data documentului;
rubrici /casete/ rânduri pentru denumirea informaţiilor cantitativ-valorice şi coduri;
rubrici /casete /spaţii pentru semnături şi ştampile;
text explicativ, eventual indicaţii de completare şi verificare.
În ordonarea informaţiilor pe document, deci în rubricarea documentului se va ţine
seama de câteva reguli: antetul se plasează în stânga sus; codurile şi alte informaţii de
identificare se plasează în dreapta sus; sensul natural de parcurgere este de sus în jos şi de
la stânga la dreapta; zonele de document ce se completează de compartimente/ persoane
diferite se marchează / grupează distinct; mărimea şi spaţierea documentului, distanţa
dintre rânduri, dimensiunea rubricilor, depind de locul şi modalitatea de completare
(manual, dactilo, automat) precum şi de nivelul de calificare a personalului ce
completează documentul.
Aşezarea rubricilor pe document trebuie să respecte ordinea firească de folosire a
documentului şi nu ordinea de utilizare a datelor în programe. Ordinea de culegere a
datelor este suficient a fi precizată prin numerotarea rubricilor sau simpla lor încadrare în
chenar sau utilizarea de litere îngroşate în denumirea rubricilor implicate în dialogul
operator-calculator.
Atunci când documentul există într-o formă pe hârtie, în varianta pe calculator se
va urmări păstrarea în mare măsură a structurii existente, dar cu adaptări specifice noului
mediu.
Regulile de control şi procedurile de validare a datelor de intrare trebuie să
cuprindă [2]:
reguli de verificare a volumului, secvenţei documentelor şi a cifrelor de control (dacă
este cazul) pe pachetele de documente primare;
reguli pentru controlul sintactic şi semantic a datelor din documentele primare.
Aceste reguli se referă la: încadrarea indicatorilor numerici (în limitele de
verosimilitate), corelaţii logice (între indicatorii înscrişi în acelaşi document, sau cu
alţi indicatori din baza de date), prezenţa unor informaţii obligatorii (apartenenţa
codurilor la nomenclatoarele de coduri specifice aplicaţiei informatice) etc. Aceste
reguli sunt necesare pentru scrierea programelor de verificare logică a datelor de
intrare.
Proiectarea formularelor(videoformatelor) de intrare pentru introducerea datelor
de intrare se face în funcţie de modul concret de desfăşurare a dialogului operator-
calculator. Acest dialog se poate desfăşura sub formă de [2]:

Nicolae Morariu
întrebare-răspuns cu defilarea liniilor ecranului;

afişare pe ecran a machetei de introducere a datelor de intrare.
În prima variantă, mai uşor de realizat practic, operatorul introduce succesiv, ca
răspuns la întrebările afişate pe ecran, date de intrare. La proiectarea formelor de intrare
este necesar ca proiectantul să aibă în vedere o serie de aspecte cum ar fi:
afişarea la un moment dat a unui volum redus de informaţii;
afişarea la un moment dat a unei cereri de răspuns ce se referă la o singură
informaţie;
scurtarea răspunsului operatorului prin folosirea mnemonicelor şi codificărilor;
utilizarea unor formate clare şi precise pentru afişare;
evitarea cuvintelor şi caracterelor dificil de citit sau înţeles;
existenta unor rutine speciale de tipul HELP;
preluarea asistată a unor coduri (ex. utilizare tehnici de tip Lookup wizard în
ACCESS)
In varianta a doua cursorul marchează de fiecare dată câmpul curent care se
introduce. Ecranul display-ului trebuie să reproducă integral sau simplificat macheta
documentului, respectând aceeaşi ordine a rubricilor. Mesajele de eroare se pot afişa într-
o zona prestabilita a ecranului, însoţită de avertizare sonora sau luminoasa.
Dacă este cazul, pentru unele câmpuri (rubrici) de date se pot prelua valori
implicite, atunci când nu sunt completate. Aceste valori se preiau din nomenclatorul de
coduri, fişierele bazei de date sau tabele special memorate pentru valorile asumate prin
lipsa sau prin aplicarea unui algoritm. Pentru o mai uşoară operare este necesar să folosim
toate facilităţile de afişare şi de combinare a culorilor oferite de terminalul video (figura
4.1).
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 interfeţelor şi a dialogurilor

Interfaţa cu utilizatorul - reprezintă o parte a aplicaţiei software care permite
utilizatorilor să-si exprime intenţiile de operare asupra calculatorului şi să interpreteze
rezultatele acţiunilor efectuate de maşină.
Prin proiectarea dialogurilor şi a interfeţelor se definesc modalităţile prin care
oamenii şi calculatoarele schimbă informaţii [1].
Metode şi echipamente folosite în dialogul om-maşină

Interfaţa om – maşină defineşte modalitatea prin care utilizatorul interacţionează cu
un sistem informatic. Interfeţele sunt destul de variate, conform descrierilor, însă toate
trebuie să dispună de un stil sau de o metodă prin care să se folosească anumite
echipamente în măsură să faciliteze o astfel de interacţiune [1].
Metode de interacţiune
Metodele cele mai utilizate sunt [1]:
interacţiunea prin limbaj-comandă (în acest tip de interacţiune utilizatorul transmite
calculatorului comenzile sub forma unui şir de caractere)
interacţiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin
intermediul unui sistem de meniuri şi opţiuni de meniu sau folosind scurtături sub
formă de combinaţii de taste).
interacţiunea bazată pe obiecte icons(comunicarea se face prin intermediul desenelor.
Imaginile folosite funcţionează ca butoanele, la apăsarea lor se activează o anumită
funcţie sau comandă)
interacţiunea prin limbaj natural(comenzile se transmit folosind vocea şi
sintetizatoarele de voce pentru redarea rezultatelor)
Echipamentelor necesare interacţiunii cu 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 selecţia.
Light Pen – Stiloul optic efectuează selecţia prin apăsarea pe ecran.
Voice – Vocea constituie modalitatea de transmitere a textelor şi comenzilor către
calculator.
Proiectarea dialogurilor
Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenţele
folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este
de a selecta cele mai potrivite metode şi echipamente, precum şi de a prezenta condiţiile
în care se pot afişa informaţiile sau se pot obţine de la utilizator.

Nicolae Morariu
Pentru a obţine rezultate bune trebuie să se ţină seama de regulile de bază la

conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uşurinţa în lucru,
controlul, operaţiunea inversă (refacerea unui element şters), rezolvarea erorilor, etc.
O modalitate de prezentare a secvenţei dialogurilor este cea care apelează la
tehnica diagramelor. Ea va face trimitere la meniurile componente ale aplicaţiei.
MO1
MENIU_PRINCIPAL
MO2
PO2 PO1
MENIU_INTERO
GARE
ADĂUGARE ŞTERGERE
PO4 PO3
PROCES
MENIU I_DUPĂ_AN I_DUPĂ_NUME
Figura 4.2. Structura unei diagrame de apelare a meniurilor [1].
Pentru proiectarea interfeţelor şi dialogurilor se poate apela la ajutorul oferit de

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

Proiectarea logică a bazelor de date este în strânsă legătură cu modelarea
conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor,
independent de tehnologiile specifice de prelucrare a bazelor de date, fără să se
înregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului
aspect i se va acorda atenţia 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 activităţi
ale proiectării logice: proiectarea formularelor şi a rapoartelor şi proiectarea dialogurilor

şi interfeţelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei

entitate-relaţie, ci şi pe baza machetelor formularelor şi a rapoartelor. Se efectuează
analiza datelor elementare din intrările şi ieşirile sistemului pentru a se desprinde
legăturile dintre ele.
Prin modelarea logică a datelor se urmăreşte:
structurarea performantă a datelor prin procesul de normalizare
obţinerea unui model logic al datelor din care să se poată realiza proiectul bazei de
date fizice, adică modelul relaţional – cel mai utilizat în prezent, deşi se pot obţine şi
modelele reţea, ierarhic sau orientate-obiect;
realizarea unui model al datelor care să răspundă cerinţelor actuale de date regăsite în
formulare şi rapoarte. Modelarea logică este un proces ascendent (bottom-up, de jos
în sus) de obţinere a relaţiilor din formulare şi rapoarte prin transformarea modelului
entitate-relaţie într-o formă relaţională.
Modelarea logică a datelor descrie datele cu ajutorul unei notaţii speciale, care
corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de
date.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viaţă se
regăseşte câte o activitate specifică datelor după cum urmează [1]:
Analiza – Modelele conceptuale ale datelor, prezentarea DER;
Proiectarea logică – Modelul logic al datelor(relaţional);
Proiectarea fizică – Proiectarea fizică a bazelor de date şi a fişierelor (organizarea
fişierelor);
Implementarea – Descrierea fişierelor şi a bazelor de date.
După cum prezintă profesorul Oprea D. În “Analiza şi proiectarea sistemelor
informaţionale economice” în procesul de modelare logică există patru paşi esenţiali:
1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare şi
rapoarte) privind aplicaţia, folosindu-se principiile normalizării;
2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor într-un model logic
consolidat (centralizat) al datelor, numit şi integrarea perspectivelor;
3. Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să se
ţină cont de perspectiva utilizatorului, într-un set de relaţii normalizate;
4. Compararea modelului logic consolidat al datelor cu modelul transformat al entităţii-
relaţie şi realizarea, prin integrarea perspectivelor, a unui model logic final al datelor
aplicaţiei.
Rezultatele obţinute prin parcurgerea celor patru paşi pot fi ilustrate prin
intermediul unor exemple oferite în literatura de specialitate de McFadden şi Hoffer [1].
Primul pas al modelării logice se poate explica prin două rapoarte solicitate de
utilizatori, reprezentând perspectiva utilităţii sistemului din punctul lor de vedere:
cel mai bun client al produsului X(ecran);
situaţia comenzilor în curs;
Ecranul “Cel mai bun client al produsului X”, prin percepţia utilizatorului, are
următorul format:
Cel mai bun client al produsului

Introduceţi codul produsului: P1122
Contabilitate şi informatică Data de început:
de gestiune 10/10/99 66
Data de sfârşit: 31/12/99
---------------- -------- -------
COD CLIENT: 1111
NUME CLIENT: S.C. ALPHA S.R.L.
VOLUM: 1000
Nicolae Morariu
Figura 4.3 Model de ecran solicitat de utilizatori [1]
Din analiza ecran ului se pot desprinde relaţiile:

CLIENT(COD_CLIENT, NUME)
COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)
PRODUS(COD_PRODUS)
LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA)
Raportul “Situaţia comenzilor în curs” are următorul format:
Pagina 1
Situaţia comenzilor în curs

31/03/1998
COD PRODUS
CANTITĂŢI_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 următoarelor entităţi:
PRODUS(COD_PRODUS)
COMANDA(NR_COMANDA, DATA_COMANDA)
LINIE_COMANDA(NR_COMANDA, COD_PRODUS,
CANTITATE_COMANDATA)
LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)
FACTURA(NR_FACTURA, DATA_FACTURA)

Pasul al doilea presupune comasarea perspectivelor utilizatorilor şi crearea unui set

integrat al relaţiilor, rezultând următoarele relaţii:
CLIENT(COD_CLIENT, NUME)
PRODUS(COD_PRODUS)
FACTURA(NR_FACTURA, DATA_FACTURA)
LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)
Pasul al treilea constă în transformarea modelului conceptual al datelor (diagrama-

entitate-relaţie) din aplicaţie fără să se ţină cont de punctul de vedere al utilizatorului,
într-un set de relaţii normalizate. Din analiza diagramei din figura 6.5 se desprind
următoarele relaţii:
COD_CLIENT NUME_CLIENT ADRESA NR_FACTURA
CLIENT FACTURA
Lansează Facturare
CANTITATE_LIV
COMANDA
NR_COMANDA Livrar
e
PRODUS
Contabilitate şi informatică de gestiune
Linie_comandă 68
COD_PRODUS DENUMIRE
CANTITATE_
COMANDATA
Nicolae Morariu
Figura 4.5. Diagrama entitate-relaţie pentru gestiunea clienţilor [1]
Din analiza diagramei se desprind următoarele relaţii:
CLIENT(COD_CLIENT, NUME, ADRESA)

PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA)
COMANDA(NR_COMANDA, COD_CLIENT)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)
Pasul al patrulea compară modelul obţinut din pasul doi cu cel din pasul trei şi
integrează perspectivele utilizatorilor în vederea obţinerii unui model logic final, după
cum urmează:
CLIENT(COD_CLIENT, NUME, ADRESA)
PRODUS(COD_PRODUS, DENUMIRE)
FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA)
LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)
Aşadar, rezultatul modelării logice a datelor îl constituie relaţiile normalizate

rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va
concretiza în actualizarea depozitului (repository) sau a dicţionarului proiectului.
Diferenţa majoră între modelarea conceptuală şi cea logică este că după modelarea logică
a datelor cerinţele structurate de date se concretizează în relaţii, şi nu în entităţi. Din

cauza normalizării nu este necesară o corespondenţă unu-la-unu între entităţi şi relaţii

[1].
4.3.1. Normalizarea relaţiilor - Forme normale

Între atributele unei relaţii sau între atribute din relaţii diferite pot exista anumite
legături logice (dependenţe), care influenţează proprietăţile schemelor de relaţie în raport
cu operaţiile curente care intervin în timpul exploatării bazei de date: adăugare, ştergere,
actualizare. Aceste legături logice, cunoscute în literatura de specialitate sub denumirile
de dependenţele funcţionale, dependenţele multivalorice şi dependenţe de cuplare, au
implicaţii majore asupra criteriilor de proiectare a schemelor relaţionale. Alegerea unui
model conceptual convenabil pentru o bază de date relaţională poate necesita realizarea
unor descompuneri pentru anumite scheme de relaţie date, descompuneri care să izoleze
dependenţele existente şi prin aceasta să elimine anomaliile care se datorează acestor
dependenţe.
Dependenţe funcţionale
Penru definirea acestui tip de dependenţe se consideră schema de relaţie
Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare)
definită pentru urmărirea serviciilor prestate de o firmă pentru diverşi clienţi.
Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare client are
o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină în mod
unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relaţie de mai
sus, se constată o redundanţă relativ la atributul Adresa a cărei valoare este repetată pentru
un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariţia
următoarelor anomalii:
- Anomalia la adăugare:
adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puţin un
serviciu.
- Anomalia la ştergere:
dacă se şterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.
- Anomalia la actualizare:
datorită redundanţei relativ la atributul Adresa, dacă se schimbă adresa unui client este
necesară parcurgerea întregii relaţii pentru a identifica şi actualiza toate apariţiile acestui
client, în caz contrar baza de date devine inconsistentă (acelaşi client poate apare la adrese
diferite).
Aceste anomalii pot fi eliminate, dacă schema de relaţie Prestari_Servicii se
înlocuieşte prin următoarele două scheme de relaţie:
Clienti(Cod, Nume_client,
Adresa)
Servicii(Cod, Serviciu_prestat,
Valoare).
Relaţia Clienti conţine codul, numele şi adresa fiecărui client, fără nici un fel de
redundanţă, iar relaţia Servicii conţine serviciile prestate pentru fiecare client şi valorile
acestor servicii. Un dezavantaj al descompunerii relaţiei iniţiale în cele două relaţii este

Nicolae Morariu
acela că pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu
este necesară efectuarea unei operaţii de cuplare a relaţiilor Clienti şi Servicii.
Se consideră o schemă de relaţie R şi A,B două atribute simple sau compuse ale schemei
de relaţie R. Atributul A determină funcţional atributul B sau B depinde funcţional de A,
dacă şi numai dacă oricărei valori a atributului A îi corespunde o singură valoare a
atributului B (se notează A->B).
Dependenţa funcţională A->B este totală dacă nu există nici un subset C al
atributului A (CcA) astfel încât C->B şi este parţială în caz contrar.
În relaţia Prestari_Servicii, una din dependenţele funcţionale care poate fi pusă în
evidenţă este Nume_client->Adresa.
Deoarece într-o relaţie orice cheie identifică în mod unic fiecare tuplă a relaţiei,
deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relaţie
atributele sunt dependente funcţional faţă de cheile acesteia.
Se pot face, până în acest moment, următoarele precizări:
Eliminarea dependenţelor funcţionale din schemele de relaţie şi a consecinţelor
negative (redundanţa datelor; anomaliile de adăugare, ştergere, actualizare) se realizează
prin descompunerea schemei date într-o colecţie de scheme mai simple în care sunt evitate
neajunsurile mai sus menţionate. Reconstituirea relaţiei iniţiale se poate face prin operaţia
de cuplare (uniune). Pentru ca descompunerea schemei de relaţie să fie echivalentă cu
relaţia iniţială, trebuie să fie îndeplinite condiţiile:
- cuplare fără pierdere de informaţie;
- conservarea dependenţelor (dependenţele funcţionale din relaţia iniţială trebuie să
se regăsească în relaţiile rezultate prin descompunere).
Formele normale sunt scheme de relaţie echivalente obţinute prin descompunerea
unor scheme de relaţie în vederea eliminării redundanţei datelor şi anomaliilor la
adăugare, actualizare, ştergere înregistrări în baza de date. Descompunerile schemelor de
relaţii în scheme de relaţii echivalente având în vedere dependenţele funcţionale conduc
la definirea primelor 4 nivele de forme normale şi anume: prima formă normală (FN1), a
doua formă normală (FN2), a treia formă normală (FN3) şi forma normală Boyce-
Codd (FNBC).
A patra formă normală (FN4) este definită având în vedere dependenţele
multivalorice, iar a cincea formă normală (FN5) este definită având în vedere
dependenţele de cuplare. Începând de la prima formă normală şi până la forma normală FN5
se impun condiţii din ce în ce mai restrictive asupra relaţiilor. Astfel o relaţie aflată pe un
anumit nivel de normalizare (FN5) satisface toate restricţiile cerute de nivele inferioare de
normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definiţiile
formelor normale având în vedere dependenţele funcţionale.
O relaţie R este în prima formă normală (FN1) dacă şi numai dacă toate
atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul
Adresa ar putea fi considerat un atribut neatomic dacă în cadrul adresei ne-ar interesa
localitatea, strada etc., caz în care trebuie descompus în atribute atomice.
O relaţie R este în a doua formă normală (FN2) dacă este în FN1 şi orice atribut
neprim este total dependent faţă de orice cheie a relaţiei (atributele prime sunt atribute care

fac parte dintr-o cheie a relaţiei şi cele neprime sunt atributele care nu aparţin nici unei chei
a relaţiei).
O relaţie R este în a treia formă normală (FN3) dacă este în FN2 şi nici un atribut
neprim nu este funcţional dependent faţă de un alt atribut neprim al relaţiei.
O relaţie R se află în forma normală Boyce-Codd (FNBC) dacă singurele
dependenţe funcţionale admise sunt cele în care o cheie determină un alt atribut (nici un
atribut prim sau neprim nu poate fi dependent funcţional faţă de un alt atribut dacă acesta
nu este sau nu conţine o cheie).
Dependenţe multivalorice
Pentru ilustrarea acestui tip de dependenţe se ia în considerare următoarea schemă
de relaţie:
Clase(Clasa, Discipline, Elevi)
ce conţine clasele dintr-o instituţie de învăţământ, iar pentru fiecare clasă sunt înregistrate
disciplinele ce se predau şi elevii înmatriculaţi în clasa respectivă. Se poate constata că
relaţia Clase poate rezulta prin operaţia de cuplare după atributul Clasa a următoarelor
două relaţii:
CD(Clasa, Discipline)
CE(Clasa, Elevi)
În relaţia Clase, presupunând că pentru o clasă dată, fiecare elev frecventează toate
disciplinele înregistrate pentru acea clasă, există dependenţele multivalorice:
Clasa ->> Discipline
Clasa ->> Elevi.
Ca şi în cazul dependenţelor funcţionale, existenţa dependenţelor multivalorice prezintă
aceleaşi neajunsuri privind redundanţa datelor şi anomalii la efectuarea operaţiilor de
adăugare, actualizare şi ştergere înregistrări în baza de date.
O relaţie R este în a patra formă normală dacă singurele dependenţe multivalorice
admise sunt cele determinate de un alt atribut care este o cheie sau care conţine o cheie a
relaţiei.
Întrucât orice dependenţă funcţională este un caz particular de dependenţă
multivalorică, rezultă că orice relaţie care se află în forma normală FN4, se află şi în forma
normală FNBC. Transformarea unei relaţii într-o colecţie de relaţii care să se afle în FN4
este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea
dependenţelor funcţionale cât şi a dependenţelor multivalorice.
În concluzie, putem afirma că în cazul formelor normale de la FN1 la FN4,
trecerea de la o formă normală la alta s-a făcut prin descompunerea unei relaţii în altele
două, urmărindu-se eliminarea dependenţelor funcţionale şi multivalorice. O relaţie aflată în
forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode.
Există situaţii când relaţii aflate în FN4 conţin redundanţe şi prezintă anomalii la operaţiile
de adăugare, ştergere şi actualizare. Aceste anomalii sunt cauzate de existenţa
dependenţelor de cuplare şi pot fi eliminate prin descompunerea relaţiei în 3 sau mai multe
relaţii a căror cuplare are ca rezultat relaţia iniţială.
Dependenţe de cuplare

Nicolae Morariu
Se consideră schema de relaţie:

SDS (Specializari, Discipline, Studenti)
care conţine disciplinele care se predau la diverse specializări şi studenţii care le
frecventează, cu precizarea că pot exista discipline opţionale care nu sunt frecventate de
toţi studenţii de la specializarea respectivă. În aceste condiţii în cadrul schemei de
relaţie SDS nu au loc dependenţele multivalorice:
Specializari ->> Discipline
Specializari->> Studenti
ceea ce înseamnă că relaţia SDS este în FN4. Deşi este în FN4, relaţia SDS conţine mai
multe redundanţe care pot conduce la anomalii de actualizare. Pe de altă parte, relaţia SDS
nu poate fi descompusă în două componente din a căror cuplare să rezulte relaţia iniţială cu
conservarea informaţiei. Se constată însă că relaţia SDS poate fi descompusă în
următoarele 3 relaţii:
SD(Specializari, Discipline)
SS(Specializari, Studenti)
DS(Discipline, Studenti)
şi relaţia SDS este rezultatul cuplării relaţiilor: SD, SS şi DS fără pierdere de informaţie.
SDS = SD►◄SS►◄DS.
În acest caz spunem că în relaţia SDS există o dependenţă de cuplare. Dependenţele
multivalorice sunt cazuri particulare de dependenţe de cuplare.
A cincea formă normală este o generalizare a formei normale patru, trecerea unei
relaţii în FN5 presupunând eliminarea dependenţelor de cuplare existente în cadrul
relaţiei, împreună cu anomaliile pe care acestea le creează. În cadrul unei relaţii pot exista
dependenţe de cuplare care nu conduc la redundanţă în memorarea datelor şi nu produc
anomalii la operaţiile efectuate asupra înregistrărilor bazei de date (acestea sunt dependenţele
de cuplare implicate de o cheie a relaţiei).
O relaţie este în forma normală cinci (FN5) dacă şi numai dacă toate
dependenţele de cuplare existente în relaţie sunt implicate de o cheie a acesteia. Relaţia
SDS se poate descompune, cu conservarea conţinutului de informaţie, în cele 3
componente ale sale: SD, SS şi DS care sunt în FN5.
Având în vedere similaritatea ce există între definiţiile pentru FNBC, FN4 şi FN5,
acestea pot fi unificate în următoarea definiţie [13]:
O relaţie R este în FNBC, FN4, FN5 dacă şi numai dacă singurele dependenţe
funcţionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaţiei R.
În concluzie, prin procesul de normalizare se realizează eliminarea din schemele
de relaţie a dependenţelor (funcţionale, multivalorice şi de cuplare) cu scopul de a obţine o
schemă relaţională mai bună din punctul de vedere al redundanţei datelor şi al anomaliilor
ce pot apare la operaţiile de adăugare, ştergere şi actualizare înregistrări în baza de date.
Normalizarea unei scheme de relaţie R înseamnă înlocuirea acesteia cu o mulţime de
proiecţii R1,...,Rn astfel încât R să fie echivalentă cu uniunea proiecţiilor R1,...,Rn. Deşi
normalizarea este o operaţie utilă în proiectarea bazelor de date, aceasta nu oferă
întotdeauna reţete pentru obţinerea celor mai bune modele şi de aceea este la latitudinea
proiectantului decizia de a aplica sau nu o anumită etapă de normalizare după o analiză
temeinică a avantajelor şi dezavantajelor modelului obţinut. În unele cazuri

normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere
constatările de mai sus se poate afirma că deşi normalizarea nu reprezintă o soluţie
general valabilă în orice situaţie, totuşi dacă pentru proiectarea bazei de date se
aplică corect o metodologie de proiectare descendentă, modelul rezultat va fi de la sine
normalizat. Cercetările în acest domeniu continuă, fiind definite şi alte forme normale printre
care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente,
conţine şi date istorice, iar factorul (atributul) timp are un rol esenţial (exemple concludente
de astfel de baze de date sunt depozitele de date). Astfel, în proiectarea unei baze de date
temporale trebuie avute în vedere şi alte operaţii de descompunere a schemelor de relaţie şi
anume:
- descompunerea orizontală – pentru separarea datelor curente de datele istorice;
- descompunerea verticală – pentru separarea atributelor aceleiaşi entităţi având în vedere
valorile lor raportate la atributul temporal.
În proiectarea unei baze de date nu este exclusă nici operaţia inversă normalizării
numită denormalizare [12], prin care se urmăreşte înlocuirea unei colecţii de scheme de
relaţie cu o schemă de relaţie echivalentă în vederea eliminării necesităţii efectuării unor
operaţii de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendinţa este de a
ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând
fi avute în vedere doar aspecte legate de performanţele anumitor aplicaţii.
Un alt principiu care se urmăreşte în proiectarea unei baze de date este principiul
proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relaţie
reale (variabile de relaţie de bază) nu trebuie să aibă semnificaţii suprapuse. În timp ce
prin normalizare se urmăreşte reducerea redundanţei din cadrul unei scheme de relaţie,
prin proiectarea ortogonală se urmăreşte reducerea redundanţei dintre schemele de relaţie.
4.3.2. Simplificarea structurii datelor prin normalizare

Problema de bază a proiectării logice a bazelor de date este cum ar trebui
combinate datele elementare pentru a forma relaţii(sau tipuri de înregistrări) care să
descrie entităţile şi relaţiile dintre entităţi. În limbajul bazelor de date, cuvântul relaţie
înseamnă un tabel de date, ceea ce duce la concluzia că bazele de date relaţionale
(modelul relaţional) sunt clădite pe un grup de tabele legate între ele [1].
Modelul relaţional a fost dezvoltat de către Codd. Este un model conceptual de
organizare a datelor, destinat reprezentării legăturilor dintre date. El este bazat pe teoria
matematică a relaţiilor şi este definit cu o deosebită rigoare matematică [Popescu I.,
1996].
În cadrul modelului relaţional datele sunt structurate sub forma de relaţii (de aici şi
denumirea). Cea mai directa şi intuitiva modalitate de reprezentare a datelor în cadrul
acestui model este sub forma de tabele. Fiecărei relaţii i se poate asocia un tabel care are
atâtea coloane câte mulţimi leagă relaţia şi are atâtea linii câte tuple conţine relaţia.
Prezentarea structurii relaţionale a datelor impune definirea noţiunilor de: domeniu,
relaţie, atribut şi schemă a unei relaţii. Conceptele utilizate pentru a descrie formal, uzual
sau fizic elementele de bază ale organizării datelor sunt prezentate în tabelul următor:
Formal Uzual Fizic

Nicolae Morariu
Relaţie Tablou Fişier(tabel)

Tuplu Linie Înregistrare
Atribut Coloană Câmp
Domeniu Tip de dată Tip de dată
Definirea domeniului
Un domeniu este o mulţime de valori caracterizată printr-un nume. Un domeniu se
poate defini explicit prin enumerarea tuturor valorilor aparţinând acestuia sau definind o
proprietate distinctivă a domeniului valorilor, de cele mai multe ori limita superioară şi
limita inferioară [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 D1,D2,…,Dn produsul cartezian al acestora
reprezintă ansamblul tuplurilor (elemente ale unei relaţii) <v 1,v2,…,vk> unde vi este un
element care aparţine domeniului Di. De exemplu, tuplurile <“Maria”,”F”,”50” >,<
“Vasile”,”M”,”60”> aparţin produsului cartezian D3xD1xD2.
Definirea relaţiei
O relaţie R pe mulţimile D1,D2,…,Dn este o submulţime a produsului cartezian
D1xD2x…xDn, deci o mulţime de tupluri [Popescu I, 1996].
Considerând că nu se cunosc decât două persoane, relaţia R se defineşte prin
tuplurile care descriu aceste persoane, şi anume:
R: {<“Maria”,”F”,”50”>,<“Vasile”,”M”,”60”>}
O relaţie poate fi reprezentată printr-un tabel bidimensional în care fiecare linie
corespunde unui tuplu şi fiecare coloană corespunde unui domeniu.
R: D3 D1 D2
“Maria” “F” 50
“Vasile” “M” 60
Reprezentarea tabelară este preferată adesea altor forme de reprezentare a relaţiilor,

deoarece este uşor de înţeles şi de utilizat.
În prezentarea conceptului de relaţie se poate recurge la analogii cu alte concepte
cum ar fi cel de fişier. Relaţia poate avea semnificaţia unui fişier, tuplul poate fi
considerat o înregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale
câmpurilor de înregistrare.
Definirea atributului
În timp ce tuplurile dintr-o relaţie trebuie să fie unice, un domeniu poate apare de
mai multe ori în produsul cartezian pe baza căruia este definită relaţia [Popescu I, 1996].

PERS D3 D1 D2 D3
“Maria” “F” 50 “Vasile”
“Vasile” “M” 60 “Maria”
Relaţia PERS reprezintă un subansamblu al produsului cartezian D 3xD1xD2xD3.

Atributul reprezintă coloana unei tabele de date, caracterizată printr-un nume. Numele
coloanei (atributului) exprimă, de obicei, semnificaţia valorilor din cadrul coloanei
respective.
Semnificaţia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe
baza domeniului de care aparţin valorile ci şi funcţie de poziţia ocupată în cadrul tuplului.
Dependenţa faţă de ordinea datelor înseamnă o reducere a flexibilităţii organizării datelor.
Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor nu trebuie să prezinte
nici o importanţă. Pentru a diferenţia coloanele care conţin valori ale aceluiaşi domeniu,
şi a elimina astfel dependenţa de poziţie în cadrul tabelei se introduce tocmai conceptul
de atribut. Fiecare relaţie are asociat un nume sau un identificator propriu.
Schema unei relaţii este formată din ansamblul elementelor definitorii sau din
nivelul relaţiei urmat de lista atributelor specifice.
În mulţimile matematice nu este permis ca un obiect să apară de mai multe ori. Cât
timp o relaţie este o mulţime de tupluri, teoretic nici o linie a unei relaţii nu poate fi
duplicatul altei linii. După cum reiese din prezentările anterioare, dacă o coloană sau o
combinaţie de coloane nu poate să identifice în mod unic o linie, atunci trebuie inventată
o coloană-cheie specială.
O tehnica de proiectare a modelului conceptual al bazei de date într-o abordare
bottom-up este tehnica celor cinci forme normale.
Conform acestei tehnici, atributele entităţilor definite se organizează într-o singură
tabelă sau în mai multe şi se urmăreşte descompunerea acestor tabele în altele, fără
pierdere de informaţii în scopul eliminării anomaliilor de ordin logic şi fizic. Acest lucru
se realizează prin parcurgerea a o serie de etape, de normalizare, prin care se trece de la o
forma normală la alta. Se apreciază posibilitatea existentei a cinci forme normale (FN).
Prin parcurgerea acestor etape, se ajunge în mod succesiv să se amelioreze structura bazei
de date, înlăturându-se treptat o serie de neajunsuri şi asigurând facilităţi sporite în
privinţa încărcării, actualizării şi exploatării bazei de date. O relaţie nenormalizată
conţine unul sau mai multe grupuri care se repetă.
Necesitatea normalizării progresive este dată de faptul că anumite relaţii pot genera
o serie de situaţii nedorite, aşa-numitele “anomalii de actualizare”, cum sunt: anomalia de
ştergere, anomalia de adăugare, anomalia de modificare [2].
4.3.3. Transformarea diagramelor entitate-relaţie în relaţii

Pentru a se putea compara rezultatele obţinute în etapa de proiectare logică a
datelor, adică a relaţiilor normalizate, cu diagrama entitate-relaţie, rezultat al proiectării
conceptuale, aceasta din urmă trebuie să fie convertită în relaţii, de asemenea,
normalizate.
Întregul proces se desfăşoară în patru paşi, astfel: [1]

Nicolae Morariu
Reprezentarea entităţilor. Fiecare tip de entitate din diagrama entitate-relaţie este

reprezentată ca o relaţie în modulul relaţional al datelor. Identificatorul tipului de
entitate devine cheie primară a relaţiei, iar celelalte atribute ale tipului entităţii devin
atribute non-cheie ale relaţiei.
Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relaţie trebuie să fie
reprezentată în modelul relaţional al datelor. Reprezentarea legăturii se efectuează în
funcţie de natura ei. De exemplu, uneori se poate constitui o relaţie prin includerea
cheii primare a unei relaţii ca o cheie străină în altă relaţie. Astfel, se poate crea o
relaţie separată pentru reprezentarea legăturii.
Normalizarea relaţiilor. Relaţiile create în paşii 1 şi 2 pot conţine redundanţe nedorite
şi vor constitui surse de înregistrare a anomaliilor în timpul actualizării. Normalizarea
va conduce la o bună structurare a relaţiilor.
Fuziunea relaţiilor. În timpul modelării logice a datelor s-au creat diferite relaţii, atât
pe baza normalizării ascendente a perspectivelor utilizatorilor, cât şi a transformării
uneia sau a mai multor diagrame entitate-relaţie în seturi de relaţii. În structura
acestor seturi de relaţii pot exista unele relaţii redundante, cum ar fi existenţa a două
sau mai multe relaţii care descriu acelaşi tip de entitate, ce ar trebui să fuzioneze şi să
se renormalizeze pentru extragerea eventualelor redundanţe.

CAPITOLUL 5
PROIECTAREA FIZICĂ A SISTEMELOR INFORMATICE
Proiectarea fizică cunoscută şi sub numele de proiectare de detaliu, urmează

proiectării logice. Proiectarea logică întâlnită şi sub numele de proiectare generală, o altă
variantă de definire a proiectării logice. De fapt, printr-o astfel de referire se scoate în
relief faptul că în timpul proiectării logice se prezintă o imagine de ansamblu (generală) a
sistemului, în timp ce proiectarea fizică înseamnă o abordare detaliată a sistemului. Cu
alte cuvinte, în etapa de proiectare logică se acumulează informaţiile de natură să
sintetizeze cerinţele utilizatorilor noului sistem, operaţiune prestată de analiştii de sistem,
iar în timpul proiectării fizice se prezintă punctele de vedere ale specialiştilor, cum ar fi
cei din domeniul bazelor de date, securităţii sistemelor, reţelelor de calculatoare,
programării, etc.
Proiectarea fizică implică parcurgerea următorilor paşi [1]:
1. Proiectarea fizică a bazelor de date şi a fişierelor. O astfel de activitate înseamnă
descrierea modului în care vor fi stocate datele şi cum se va asigura controlul lor
pentru a se oferi o securitate maximă;
2. Proiectarea structurii sistemului şi a programelor. Se descriu programele sau
modulele acestora care să fie în strânsă concordanţă cu diagramele fluxurilor de date
şi cu celelalte piese ale documentaţiei realizate în etapele anterioare;
3. Proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalităţile în care
utilizatorul poate să dispună de date şi facilităţile de prelucrare oferite de reţele de
calculatoare.
5.1. Proiectarea fizică a bazelor de date şi a fişierelor

Modelul conceptual surprinde structura globală de organizare a datelor,
asigurându-se independenţa totală faţă de orice sistem de gestiune a bazelor de date.
Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaţie(DER),
motiv pentru care este cunoscut şi sub numele de modelul entitate-relaţie al datelor. El
scoate în evidenţă reprezentarea logică, detaliată a entităţilor, asocierilor (legăturilor) şi
datelor elementare ale unei organizaţii sau ale unei părţi din ea. Modelul se realizează în
faza de analiză [1].
Modelul logic al datelor înseamnă descrierea datelor în concordanţă cu modelul de
organizare a acestora de către sistemele de gestiune a bazelor de date. În acest material s-
a ales modelul relaţional. Conform cu acest model datele sunt reprezentate în baza de date
sub forma tabelelor sau relaţiilor create din diagrama entitate-relaţie obţinută în etapa
anterioară.
O bază de date poate fi definită ca un ansamblu de date elementare sau structurate,
accesibile unei comunităţi de utilizatori. Mai concret, o bază de date este un ansamblu de
fişiere intercorelate, care conţine nucleul de date necesare unui sistem informatic
(aplicaţie informatică). Un fişier este un ansamblu de înregistrări fizice, omogene din

Nicolae Morariu
punct de vedere al conţinutului şi al prelucrării. O înregistrare fizică este unitatea de

transfer între memoria internă şi cea externă a calculatorului. Aceasta este formată din
una sau mai multe înregistrări logice. O înregistrare logică este unitatea de prelucrare din
punct de vedere al programului utilizator. Aceasta este formată dintr-un ansamblu de
câmpuri, care descriu o anumită entitate.
Modul de stocare a datelor pe suportul fizic de memorare este funcţie de sistemul
de gestiune a bazelor de date utilizat.
Proiectarea fizică a bazelor de date şi a fişierelor îşi propune să asigure trecerea de
la descrierea logică a datelor la una tehnică, de stocare a datelor. O problemă de
importanţă majoră în cadrul acestei etape o constituie alegerea Sistemului de Gestiune a
Bazelor de Date adecvat soluţionării optime a problemelor formulate în etapele anterioare
ale realizării sistemului informatic.
5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:

Centralizarea datelor permite: suprimarea redundanţei, asigurarea unicităţii
înregistrării şi controlul centralizat (asupra datelor). În prelucrarea clasică în care fişierele
sunt dedicate aplicaţiilor, aceleaşi date apar înregistrate în mai multe fişiere şi în formate
diferite. Acest lucru implică o utilizare ineficientă a spaţiului de memorie externă,
actualizarea dificilă a acestor date şi lizibilitate redusă ca urmare a formatelor diferite.
Independenţa între date şi prelucrări. Baza de date, ca imagine a unei anumite
realităţi, trebuie actualizată permanent. Acest lucru nu trebuie să afecteze programele de
prelucrare. Pentru aceasta trebuie ca fiecare program să aibă o viziune proprie asupra BD
Realizarea de legături între entităţile de date, care sunt indispensabile pentru
exploatarea eficientă a sistemului informatic. Spre exemplu, în cadrul gestiunii
aprovizionării, trebuie asociat un furnizor la lista de produse pe care le vinde şi invers, un
produs la lista de furnizori, precizând condiţiile de vânzare pentru un furnizor şi un
produs.
Integritatea datelor asigură fiabilitatea şi coerenţa bazei de date (BD). Pentru
aceasta trebuie definite restricţii de integritate cum ar fi:
apartenenţa la o listă de valori sau interval;
apartenenţa la un anumit format;
reguli de coerenţă cu alte date.
Securitatea datelor. Baza de date trebuie să fie protejată împotriva unei distrugeri
logice (anomalie de actualizare) sau fizice. Pentru aceasta există instrumente care permit:
crearea unor puncte de repriză; altfel spus, salvarea din timp în timp a unor copii
coerente ale bazei de date;
gestiunea unui jurnal de tranzacţii; lista operaţiilor realizate asupra bazei de date după
ultimul punct de repriză.
Confidenţialitatea datelor este asigurată prin proceduri de:
identificare a utilizatorilor prin nume sau cod;
autentificarea prin parole;
autorizarea accesului diferenţiat prin drepturi de creare, consultare modificare sau
ştergere pentru anumite segmente de date.

Partajarea datelor permite înlănţuirea tranzacţiilor solicitate simultan pe aceeaşi

înregistrare din baza de date, prin blocarea cererilor în aşteptare şi deservirea ulterioară a
acestora.
5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)

Sistemul de gestiune a bazelor de date referit prescurtat SGBD sau DBMS (Data
Base Management System) este un sistem de programe care permite definirea, crearea şi
întreţinerea bazei de date, precum şi accesul controlat la baza de date. Un SGBD oferă
următoarele facilităţi pentru crearea şi exploatarea bazelor de date:
- facilităţi de descriere a datelor, prin intermediul unui limbaj de descriere a datelor
DDL (Data Description Language) care permite utilizatorului să descrie structurile
de date ce vor fi memorate în baza de date;
- facilităţi de manipulare a datelor, prin intermediul unui limbaj de manipulare a
datelor DML (Data Manipulation Language) care permite utilizatorului să insereze,
actualizeze, şteargă, să prelucreze şi să extragă date din baza de date;
- controlul accesului la baza de date prin intermediul unui limbaj de control DCL (Data
Control Language) care asigură:
- sistem de securitate, previne accesarea bazei de date de către utilizatori
neautorizaţi;
- sistem de integritate, menţine concordanţa datelor stocate în baza de date;
- sistem de control al concurenţei, permite accesul partajat la baza de date;
- sistem de control al refacerii, permite recuperarea bazei de date în urma
unor
defecţiuni hard sau soft;
- mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei
de
date care îl interesează.
În majoritatea produselor comerciale de baze de date , cele trei limbaje se regăsesc
reunite în cadrul unui singur limbaj (spre exemplu limbajul SQL).
5.1.3. Administratorul bazei de date

Administratorul bazei de date referit prescurtat DBA (Data Base Administrator),
este o persoană sau un grup de persoane care coordonează şi răspunde de ansamblul
activităţilor privind baza de date, începând din faza de proiectare şi continuând cu
celelalte etape pe întreaga perioadă de viaţă a bazei de date. Astfel, în faza de proiectare a
bazei de date, administratorul stabileşte SGBD-ul ce va fi utilizat, echipamentele
necesare, structurile de date plecând de la necesităţile de informaţie ale tuturor
utilizatorilor bazei de date, drepturile de acces la date ale fiecărui utilizator. Rezultatul
fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema
generală a bazei de date), modelului extern (subschema proprie fiecărui utilizator) şi
stabilirea modalităţilor de reprezentare a structurilor de date la nivel fizic pe suporturile
de memorare externe utilizate. Drepturile de acces la baza de date pot fi definite [ORA92]
fie pentru fiecare utilizator în parte, fie pentru grupuri de utilizatori (denumite Role),
fiecare utilizator fiind apoi asignat unui grup. După proiectarea bazei de date,

Nicolae Morariu
administratorul va menţine permanent legătura cu utilizatorii acesteia pentru rezolvarea

cerinţelor utilizatorilor şi impunerea unei discipline în vederea alinierii la standardele
existente. Administratorul va realiza, ori de câte ori se impune, reorganizarea structurii
fizice a datelor în vederea optimizării parametrilor de funcţionare a întregului sistem şi va
stabili proceduri de arhivare a datelor şi proceduri de recuperare a bazei de date la avarii
şi defecte. Pentru a preveni accesul neautorizat la date, în cadrul sistemului de securitate
pot fi prevăzute [12] şi alte mecanisme şi anume: evidenţa de auditare, criptarea datelor.
Evidenţa de auditare constă dintr-un fişier în care sistemul înregistrează automat
toate operaţiile efectuate asupra datelor, fişier ce va putea fi consultat de către persoane
autorizate pentru a verifica efectuarea unor operaţii neautorizate. O înregistrare din
evidenţa de auditare va conţine următoarele informaţii: textul sursă al operaţiei
neautorizate, terminalul de la care a fost lansată operaţia, utilizatorul care a lansat
operaţia, data şi ora operării, obiectele bazei de date afectate, imaginile datelor afectate
înainte de efectuarea operaţiei, imaginile datelor afectate după efectuarea operaţiei.
Pentru a preveni accesul unor intruşi la baza de date, care încearcă să
ocolească sistemul, se utilizează criptarea datelor, mecanism ce constă în stocarea şi
transmiterea datelor pe căile de comunicaţie sub formă cifrată. Criptarea se
realizează cu ajutorul unor algoritmi de criptare printre care cel mai recent este
standardul american de criptare avansat AES (Advanced Encryption Standard).
5.1.4. Proiectarea securităţii bazelor de date şi a fişierelor
Securitatea este abordată din mai multe puncte de vedere, dar cea referitoare la
baze de date şi la fişiere presupune luarea unor măsuri pentru reconstituirea datelor
pierdute sau preluate eronat, precum şi pentru accesul neautorizat sau incomodarea până
la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal.
Aşadar două aspecte vor fi relevante: reconstituirea datelor şi criptarea lor [1].
Reconstituirea datelor este des asociată cu existenţa fişierelor de tip back-up, însă
în practică este posibilă şi reconstituirea fără apelarea la acest tip de fişiere. În vederea
controlării corectitudinii datelor tranzacţionate se apelează la fişiere cu rol special, care
conţin un istoric, în ordine cronologică, al schimbărilor şi accesărilor efectuate asupra
fişierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fişierele distruse, dar şi la
verificarea corectitudinii operaţiunilor de actualizare [1].
Securitatea prin criptografiere se referă la asigurarea transformării datelor de
comunicat într-o formă neinteligibilă pentru toţi ceilalţi receptori, exceptându-l pe cel
autorizat. Criptarea a devenit una dintre cele mai puternice modalităţi de asigurare a
securităţii datelor. Ea poate fi realizată prin sistemul de operare sau prin SGBD, dar şi
prin rutine create de către specialişti [1].
Având î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 înţelegem posibilitatea de a utiliza un
SGBD de pe un sistem de calcul pe un altul. Portabilitatea cuprinde două aspecte şi
anume: portabilitatea programelor propriu-zise şi portabilitatea datelor.
Pentru realizarea unor programe portabile este necesar ca: programele să conţină
cât mai puţine elemente legate de echipament;

Portabilitatea sistemului de gestiune privit prin prisma portabilitaţii datelor se

referă la posibilitatea de a folosi o serie de date utilizate în cadrul unui sistem informatic
de către un alt sistem informatic, deci posibilitatea integrării fişierelor deja existente în
cadrul unui alt sistem.
b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a
unităţii centrale; costului de întreţinere şi dezvoltare; resurselor hard imobilizate; costului
de adaptare şi trecere pe un nou sistem de calcul; costul documentaţiei etc.
c) Facilităţile de implementare, întreţinere şi exploatare a bazei de date. Acestea
sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare şi regăsire
a datelor, care să permită un acces cât mai rapid la orice informaţie; timpul cât mai redus
pentru actualizare, căutare şi răspuns la cererile de informare; editarea operativă a celor
mai variate tipuri de situaţii solicitate de către utilizator; posibilitatea de inserţie a unor
programe de aplicaţie, programe de validare de date, de actualizare, rutine statistice,
rutine de sortare, rutine de prezentare grafică a ieşirilor etc.
d) Posibilitatea gestionarii structurilor complexe de date.
e) Multitudinea metodelor de acces. In funcţie de cerinţele proprii aplicaţiei,
sistemul va trebui să suporte interogări sau actualizări în timp real având proceduri de tip
conversaţional.
f) Protecţia şi securitatea datelor din bază.
g) Specificul aplicaţiei. Este cunoscut faptul că programele sunt orientate pe
aplicaţii, cum ar fi: programarea producţiei, aprovizionare-desfacere, optimizări,
prognoze etc.
Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari
cum ar fi: mentenanţa sistemului, facilităţile ce le oferă administratorului bazei de date,
calitatea documentaţiei oferite de furnizori, asistenţă în implementarea sistemului şi în
pregătirea utilizatorilor etc.
Toţi aceşti factori alături de criteriile enunţate pot să influenţeze succesul în
implementarea SGBD-ului şi eficienţa economică pe ansamblul sistemului informatic.
În cele ce urmează se vor prezenta o serie de aspecte privind utilizarea limbajului
SQL pentru crearea bazei de date, definirea utilizatorilor şi acordarea drepturilor de acces,
definirea interogărilor bazei de date, precum şi exemple practice sub SGBD ORACLE.
5.1.5. Limbajul SQL - Crearea, Administrarea şi Interogarea bazelor de date

relaţionale
Limbajul SQL (Structured Query Language)– a fost realizat în cadrul firmei
IBM ca limbaj de interogare al SGBD System R şi ulterior a devenit unul din cele mai
răspândite limbaje pentru SGBD-urile relaţionale. Limbajul SQL, ca limbaj de interogare
a bazelor de date relaţionale, este construit pe baza a două formalisme abstracte enunţate
în cele ce urmează.
1. Algebra relaţională – prin care interogările sunt exprimate prin aplicarea unor
operatori unari sau binari care constituie primitive ce acţionează asupra relaţiilor,
rezultatul interogărilor fiind tot relaţii, ceea ce permite asocierea şi imbricarea acestor

Nicolae Morariu
operatori pentru a forma interogări complexe. Operatorii algebrei relaţionale se împart în

două grupe şi anume:
- operaţii pe mulţimi (Reuniunea, Intersecţia, Diferenţa, Produsul
cartezian);
- operatori relaţionali speciali (Selecţia, Proiecţia, Cuplarea (JOIN),
Diviziunea).
2. Calculul relaţional – prin care interogările descriu mulţimea tuplelor rezultat prin
specificarea unui predicat (condiţie) care trebuie satisfăcut de aceste tuple.
Începând din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de
interogare ale bazelor de date relaţionale fiind utilizat atât în cadrul unor SGBD-uri
complexe cum ar fi SGBD ORACLE (liderul mondial în domeniul bazelor de date), cât şi
în cadrul unor SGBD-uri de complexitate redusă cum ar fi cele din familia xBase (Dbase
IV, FoxPro).
Standardul SQL utilizat pînă la începutul anului 2000 este cel realizat în 1992 şi
cunoscut sub numele de SQL’92 sau SQL2.
Noul standard SQL3 lansat în 1999 are în vedere o serie de extensii faţă de SQL2
după cum urmează:
- facilităţi orientate obiect – posibilitatea de definire de către utilizator a tipurilor
abstracte de date care să permită descrierea de metode, identitatea obiectelor,
subtipuri şi moştenire, polimorfism etc.;
- structuri de control – pentru a conferi limbajului completitudine de calcul (IF, FOR,
WHILE, etc.) pentru a deveni un limbaj de sine stătător a cărui putere de expresie să
nu mai fie limitată la nivelul limbajelor relaţionale;
- facilităţi pentru exprimarea prelucrărilor recursive;
- facilităţi de comunicare în reţea;
- facilităţi de prelucrare distribuită (mecanisme pentru crearea, memorarea şi execuţia
procedurilor la nivelul serverelor de date –stored procedures);
- facilităţi multimedia;
- facilităţi pentru tratarea timpului în bazele de date.
Comenzi pentru crearea/actualizarea schemei bazei de date
Crearea unui utilizator se realizează cu comanda
CREATE USER <nume utilizator> IDENTIFIED BY <parola>
Adăugarea relaţiilor într-o bază de date –comanda CREATE TABLE are sintaxa:
CREATE TABLE <nume relaţie>[(<nume atribut> <tip dată>,…)]
Exemplu -crearea tabelei Persoane în SQL Oracle se realizează cu comanda:
CREATE TABLE Persoane (Nrcrt NUMBER UNIQUE NOT NULL,Nume
CHAR(15),Prenume CHAR(15),Datan DATE,Sexul CHAR,Adresa VARCHAR2(50));
O nouă relaţie poate fi creată şi ca rezultat al unei operaţii de interogare astfel:
CREATE TABLE <nume relaţie> (<nume atribut> <tip dată>,…) AS <subinterogare>
Adăugarea/modificarea de atribute pentru o relaţie existentă se realizează cu
comanda:
ALTER TABLE <nume relaţie> ADD|MODIFY (< nume atribut> <tip dată>,…)
Ştergerea unei relaţii se realizează cu comanda:
DROP TABLE <nume relaţie>

Comenzi pentru optimizarea interogărilor

Una din principalele căi de optimizare a timpilor de interogare a unei baze de
date este indexarea. Un index poate fi privit ca o relaţie cu două atribute şi anume:
- primul atribut conţine valorile atributelor relaţiei după care se crează indexul;
- al doilea atribut conţine un pointer (adresa) la locaţia tuplelor
corespunzătoare.
Crearea unui index se realizează cu comanda:
CREATE [UNIQUE] INDEX <nume index>
ON <nume relaţie>(<nume atribut>[ASC|DESC],…)
Dacă pentru atributele utilizate în clauza WHERE a unor instrucţiuni SQL au fost creaţi
indecşi, atunci aceştia vor fi utilizaţi în vederea optimizării timpului de prelucrare.
Decizia de utilizare sau nu a unui index este luată de limbajul SQL şi nu de utilizator.
Pentru aceasta fiecare model de limbaj SQL dispune de o componentă numită
optimizator, care examinează interogarea şi decide care este modul optim de obţinere a
rezultatului.
O altă tehnică de optimizare a interogărilor este tehnica “clustering” disponibilă
în ORACLE şi care constă în gruparea tuplelor din mai multe relaţii şi stocarea lor în
aceeaşi zonă pe disc.
Controlul datelor (comenzi DCL)
Vederi
O vedere este o relaţie virtuală, definită plecând de la alte relaţii din baza de date
şi care nu conţine date şi deci nu ocupă spaţiu fizic pe disc. Vederile se definesc în două
scopuri şi anume:
- pentru a simplifica accesul utilizatorilor la date;
- pentru a asigura protecţia şi securitatea datelor –fiecărui utilizator fiindu-i permis
acces la o porţiune a bazei de date şi putând efectua doar anumite operaţii (conform
drepturilor de acces specificate cu comenzile GRANT/REVOKE).
Asupra unei vederi se pot efectua aceleaşi operaţii ca şi asupra unei relaţii cu deosebirea
că vederile nu conţin date şi că orice modificări efectuate asupra datelor sunt reflectate şi
în vederi. Astfel, asupra unei vederi se pot realiza operaţiile:
- creare vedere (CREATE VIEW);
- creare sinonim pentru vedere (CREATE SYNONIM);
- ştergere vedere (DROP VIEW);
- interogare vedere (SELECT);
- actualizare date din vedere (UPDATE);
- ştergere date din vedere (DELETE);
- adăugare date (INSERT).
Crearea unei vederi – se realizează cu comanda CREATE VIEW care are sintaxa:
CREATE VIEW <nume vedere> [<lista atribute>]
AS <fraza SELECT> [WITH CHECK OPTION]
Exemplu:
CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare)
AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM
Produse,Stocuri

Nicolae Morariu
WHERE Produse.codp=Stocuri.Codp AND CodDep = ”D1”

Interogarea vederii se va realiza cu comanda
SELECT * FROM StocuriD1
Utilizarea opţiunii WITH CHECK OPTION asigură faptul că nici o tuplă nu va fi
adaugată sau actualizată cu instrucţiunile INSERT, UPDATE, dacă nu sunt respectate
condiţiile specificate în clauza WHERE a instrucţiunii SELECT din definiţia vederii.
Pentru acordarea sau retragerea drepturilor de acces la baza de date prin
intermediul vizualizărilor se vor folosi comenzi de forma:
GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
TO <nume utilizator>
sau
REVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere>
FROM <nume utilizator>
Asigurarea securităţii datelor presupune definirea drepturilor de acces ale
utilizatorilor şi protecţia sistemului la accesul neautorizat. În acest sens asigurarea
securităţii se realizează pe două niveluri şi anume:
- nivelul 1 – acordarea dreptului de acces la sistem;
- nivelul 2 – acordarea dreptului de acces la nivel de relaţii.
Pentru conectarea utilizatorilor la sistem în majoritatea versiunilor de SQL se
utilizează un nume de utilizator şi o parolă.
Referitor la drepturile de acces la nivel de relaţie în sistemele multi-user trebuie
precizat utilizatorul care a creat relaţia (proprietarul relaţiei). Fiecare utilizator are
drepturi doar asupra propriilor relaţii, iar drepturi asupra unor relaţii create de alţi
utilizatori pot fi acordate prin comanda GRANT şi pot fi retrase prin comanda REVOKE.
Datele privind definirea bazei de date, utilizatorii şi drepturile de acces sunt
stocate în dicţionarul de date şi sunt gestionate de către sistemul de gestiune a bazei de
date (SGBDR).
În cele ce urmează se va prezenta modul de realizare a celor două nivele de
securitate în cadrul sistemului ORACLE.
Nivelul 1 de securitate a datelor se realizează cu comanda:
GRANT <autorizare,…> TO <nume utilizator> [IDENTIFIED BY <parola>]
unde <autorizare> poate fi:
- DBA – conferă utilizatorului dreptul de efectuare a oricărei operaţii asupra
oricărei relaţii din baza de date;
- CONNECT – conferă utilizatorului dreptul de a a face interogări (SELECT) şi
actualizări (INSERT, UPDATE, DELETE) asupra relaţiilor create de alţi
utilizatori, însă nu permite utilizatorului să creeze relaţii (CREATE) sau să
şteargă relaţii create de alţi utilizatori (DROP);
- RESOURCE – conferă utilizatorului drepturile ce rezultă din autorizarea
CONNECT şi în plus dreptul de a crea relaţii (CREATE) şi de a şterge relaţii
ce îi aparţin (DROP).
Unui utilizator îi pot fi acordate mai multe tipuri de autorizări în cadrul unei singure
comenzi GRANT.

Parola stabilită pentru un utilizator poate fi modificată printr-o comandă GRANT

ulterioară spre exemplu astfel:
GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parolă>
Unui utilizator căruia i s-a acordat un tip de autorizare îi pot fi acordate şi alte tipuri de
autorizare prin comenzi GRANT ulterioare.
Retragerea autorizărilor acordate unui utilizator se realizează cu comanda:
REVOKE <autorizare,…> FROM <nume utilizator>
Nivelul 2 de securitate a datelor
Pentru acordarea respectiv retragerea drepturilor de acces la relaţii se utilizează
comenzile GRANT respectiv REVOKE cu următoarea sintaxă:
GRANT ALL|<drept de acces>,… ON <nume relaţie>
TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]
respectiv
REVOKE ALL|<drept de acces>,… ON <nume relaţie> FROM <nume utilizator>|
PUBLIC
Privilegiile (drepturile de acces) pot fi acordate sau retrase de următoarele categorii de
utilizatori:
- utilizatorii cu nivel de autorizare DBA;
- proprietarii relaţiilor;
- utilizatorii autorizaţi cu opţiunea WITH GRANT OPTION.
Prin specificarea PUBLIC acordarea respectiv retragerea drepturilor de acces se
aplică tuturor utilizatorilor.
Prin specificarea WITH GRANT OPTION, utilizatorul respectiv poate la rândul
său să acorde aceleaşi drepturi sau mai puţine altor utilizatori.
În ORACLE pot fi acordate următoarele drepturi de access asupra relaţiilor:
SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele şi indecşi.
Drepturile de acces pot fi acordate asupra întregii relaţii, sau doar asupra
anumitor atribute ale relaţiei.
Exemple:
Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra
relaţiei Persoane care aparţine utilizatorului Vasilescu se realizează prin comanda:
GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu
Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra
relaţiei Produse aparţinând utilizatorului Ionescu se realizează cu comanda:
GRANT SELECT,INSERT,UPDATE ON Ionescu.Produse TO PUBLIC
Acordarea privilegiilor SELECT,UPDATE numai asupra atributelor CodP, Denp
din relaţia Produse aparţinând utilizatorului Ionescu, utilizatorului Popescu cu condiţia ca
acesta la rândul său să poată acorda oricărui alt utilizator aceleaşi drepturi sau mai puţine,
se realizează cu comanda:
GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire)
TO Popescu WITH GRANT OPTION
Retragerea drepturilor de acces INSERT,DELETE asupra relaţiei Persoane
aparţinând utilizatorului Vasilescu, utilizatorului Ionescu se realizează cu comanda:
REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu

Nicolae Morariu
Instrucţiuni pentru inserarea şi actualizarea datelor în tabele

Inserarea datelor – comanda INSERT are următoarea 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 completând toate atributele)
INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,’Ionescu’,’Ana’)
(adaugă o înregistrare în Persoane completând numai atributele Nrcrt,Nume, Prenume)
Pentru a insera în tabela PersF(Nrcrt,Nume,Prenume) toate înregistrările din tabela
Persoane pentru care Sexul=’F’ se scrie comanda:
INSERT INTO PersF(Nrcrt,Nume,Prenume) SELECT Nrcrt,Nume,Prenume
FROM Persoane WHERE Sexul = ‘F’
Actualizarea datelor – comanda UPDATE are sintaxa:
UPDATE <nume relaţie>|<nume vedere>
SET <nume atribut> = <expresie>,…[WHERE <condiţie>]
Condiţia din clauza WHERE defineşte tuplele care vor face obiectul actualizării. Clauza
WHERE poate conţine şi o subinterogare.
Exemple:
UPDATE Persoane SET Nume = ‘Popescu’, Prenume = ‘Ana Maria’
WHERE Nume = ‘Ionescu’ AND Prenume = ‘Ana’
(actualizează numele şi prenumele persoanei Ionescu Ana cu valorile Popescu respectiv
Ana Maria).
UPDATE Vanzari SET Pret = Pret*1.2 WHERE CodP IN
(SELECT CodP FROM Facturi WHERE Numar = 120 AND
Vanzari.Codc=Facturi.Codc )
(realizează majorarea preţului cu 20% pentru produsele vândute cu factura 120).
Dacă în comanda UPDATE clauza WHERE este omisă, actualizarea se va efectua asupra
tuturor tuplelor relaţiei.
Ştergerea datelor – comanda DELETE are sintaxa:
DELETE FROM <nume relaţie>|<nume vedere> [WHERE <condiţie>]
unde <condiţie> poate fi o condiţie simplă, o expresie sau o subinterogare.
Exemple:
DELETE FROM Stocuri WHERE Cant = 0
(şterge toate înregistrările din tabela Stocuri pentru care câmpul Cant are valoarea 0).
DELETE Oferte
(şterge toate înregistrările din tabela Oferte).
Comenzi pentru gestiunea tranzacţiilor

Tranzacţia este o succesiune de instrucţiuni SQL grupate într-un bloc de
instrucţiuni utilizate pentru actualizarea şi/sau interogarea datelor din baza de date. O
tranzacţie se consideră încheiată după realizarea tuturor operaţiilor pe care le conţine.
Operaţiile conţinute într-o tranzacţie pot fi realizate efectiv în baza de date sau nu, fie

automat de către sistem după fiecare operaţie, fie printr-o comandă explicită dată după o
succesiune de operaţii. Astfel salvarea automată de către sistem a modificărilor este
realizată prin comanda
SET AUTOCOMMIT ON
Dacă iniţial a fost specificată comanda SET AUTOCOMMIT OFF, salvarea modificărilor
efectuate asupra datelor se realizează prin comanda COMMIT, iar abandonarea
modificărilor se realizează prin comanda ROLLBACK.
Blocul de operaţii ce definesc o tranzacţie poate fi delimitat de instrucţiunile :
BEGIN TRANSACTION
END TRANSACTION
Se lansează în execuţie SQL Plus Oracle sub utilizatorul system (figura 5.1).
În baza de date ORCL sub S.G.B.D. Oracle se crează utilizatorul U1 identificat prin
parola PW1 şi i se acordă privilegiile CONNECT, RESOURCE (figura 5.2).
Se închide sesiunea de lucru SQL Plus a utilizatorului system (cu instrucţiunea EXIT)
şi se deschide o nouă sesiune de lucru SQL Plus pentru utilizatorul U1 (figura 5.3).
Se crează tabela Produse şi se inserează două înregistrări (figura 5.4).
ORCL

Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system
Nicolae Morariu
Figura 5.2. Creare utilizator U1 şi acordare privilegii CONNECT, RESOURCE
ORC
L
Figura 5.3. Lansare SQL Plus ORACLE pentru utilizatorul U1

Figura 5.4. Creare tabelă Produse şi inserare două înregistrări
Limbajul SQL - Interogarea bazelor de date - Fraza SELECT

Interogarea bazelor de date în limbajul SQL se realizează cu ajutorul unei singure
instrucţiuni şi anume instrucţiunea SELECT având următoarea sintaxă:
SELECT [DISTINCT] <lista atribute>|*
FROM <lista relaţii>
[WHERE <condiţie>]
[GROUP BY <lista atribute de grupare>]

Nicolae Morariu
[HAVING <condiţie>]
[ORDER BY <atribut1 de ordonare> [ASC]|DESC,…]
[UNION <frază SELECT>]
<lista atribute> este o listă ce conţine nume de atribute (câmpuri) sau expresii
construite utilizând atribute, separate prin caracterul “,” şi care fac parte din relaţiile
(tabele, vederi) enumerate în <lista relaţii> din clauza FROM. Numele fiecărui atribut sau
expresii din <lista atribute> va fi afişat în capul de tabel ce reprezintă rezultatul
interogării, fiecare atribut sau expresie putând primi un alias folosind specificarea AS
<alias>.
Caracterul ‘*’ specifică faptul că se extrag toate atributele tabelei precizate în
clauza FROM.
Clauza DISTINCT precizează faptul că în relaţia rezultat nu pot apărea duplicate
(tuple identice).
Clauza WHERE precizează condiţiile de interogare (condiţii care trebuie să fie
satisfăcute de tuplele interogate, condiţii de cuplare relaţii (JOIN, relaţii între tabele). În
clauza WHERE pot fi utilizaţi operatori logici (AND, NOT, OR), predicate (IN, LIKE,
BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de
comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a
operaţiilor, operatorilor, funcţii şi alte subinterogări SELECT, pentru construirea de
expresii pe care trebuie să le îndeplinească tuplele ce constituie rezultatul interogării.
Predicatul IN permite specificarea unei liste pentru domeniul de căutare pentru un atribut,
iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de căutare a
valorilor unui atribut, fiind echivalent cu o condiţie de forma:
<atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>
Exemple:
Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa)
Selectarea tuturor înregistrărilor din tabela Persoane pentru care primele 7 caractere din
câmpul Adresa sunt ‘Suceava’ sau ‘Rădăuţi’ se realizează cu comanda:
SELECT * FROM Persoane
WHERE SUBSTR(Adresa,1,7) IN (‘Suceava’,‘Rădăuţi’)
Interogarea de mai sus este echivalentă cu interogarea:
SELECT * FROM Persoane
WHERE SUBSTR(Adresa,1,7) = ‘Suceava’ OR SUBSTR(Adresa,1,7) =
‘Rădăuţi’
Selectarea tuturor înregistrărilor din tabela Persoane pentru care data naşterii este
cuprinsă între 01/01/72 şi 01/01/82 se realizează astfel:
SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND
{01/01/82}
Interogarea de mai sus este echivalentă cu interogarea:
SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <=
{01/01/82}

Predicatul LIKE permite selecţia şirurilor de caractere care conţin anumite caractere
specificate prin intermediul unei măşti definite cu ajutorul unor caractere speciale (%, _
în dBASE IV, FoxPro, ORACLE, sau *, ? în INFORMIX)
Exemple:
SELECT * FROM Persoane WHERE Nume LIKE ‘%a’
(selectează toate înregistrările din tabela Persoane pentru care valorile atributului Nume
se termină cu litera ‘a’).
SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE ‘A%u’
(selectează valorile atributelor Nume, Prenume, Datan pentru toate înregistrările din
tabela Persoane pentru care prima literă din Nume este ‘A’ iar ultima literă este ‘u’).
SELECT Nume FROM Persoane WHERE Nume LIKE ‘_o%’
(selectează valorile atributului Nume pentru toate înregistrările din tabela Persoane pentru
care prima literă din Nume este orice literă, a doua literă din Nume este litera ‘o’ şi
începând din poziţia a treia numele poate conţine orice litere.)
Predicatele ALL, ANY, EXISTS se utilizează pentru interogări ce conţin subinterogări, în
vederea verificării anumitor condiţii ce trebuie îndeplinite între rezultatele interogării şi
rezultatele subinterogării.
Clauza GROUP BY – realizează gruparea tuplelor unei relaţii pe baza valorilor
unui atribut sau grup de atribute şi generează o singură tuplă pentru fiecare grup de tuple
având aceeaşi valoare pentru atributele care definesc grupul. Atributele care definesc
grupul trebuie obligatoriu să se regăsească în lista atributelor interogate <lista atribute>.
De asemenea asupra unor atribute pot fi aplicate funcţii agregat:
- AVG(<atribut>) – media valorilor atributului specificat ca parametru, pe
grup;
- SUM(<atribut>) – suma valorilor atributului specificat ca parametru, pe grup;
- MAX(<atribut>) – maximum valorilor atributului specificat ca parametru, pe
grup;
- MIN(<atribut>) – minimum valorilor atributului specificat ca parametru, pe
grup;
- COUNT(<atribut>) – numărul înregistrărilor pe grupare după <atribut>.
Observaţie. <atribut> poate fi fie un atribut, fie o expresie definită utilizând atribute ale
tabelei.
Clauza HAVING, opţiune a clauzei GROUP BY, este o formă specială a clauzei
WHERE întrucât se aplică unor grupuri de tuple (şi nu unor tuple) definite de clauza
GROUP BY.
Exemple:
Fie tabela Stocuri(CodDep,CodP,UmP,Cant,Pret)
SELECT CodDep,SUM(Cant*Pret) AS Valoare,COUNT(CodDep) AS Contor
FROM Stocuri GROUP BY CodDep
(Calculează suma produselor Cant*Pret pentru toate tuplele având aceeaşi valoare în
câmpul CodDep şi numărul înregistrărilor din fiecare grup definit de câmpul CodDep şi
afisează rezultatele sub formă de tabel având coloanele CodDep, Valoare, Contor)

Nicolae Morariu
SELECT CodDep,CodP,MAX(Pret) FROM Stocuri

GROUP BY CodP HAVING MAX(Pret) < 150000
(selectează pentru fiecare grupă de înregistrări având aceeaşi valoare în câmpul CodP,
înregistrarea cu preţul maxim mai mic decât 150000)
CLAUZA ORDER BY – PERMITE PRECIZAREA ORDINII DE AFIŞARE A
DATELOR ASTFEL:
ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC,
…
Exemplu:
SELECT * FROM Persoane ORDER BY Datan DESC,Nume
(afişează toate înregistrările din tabela Persoane în ordine descrescătoare după data
naşterii şi în cadrul aceleiaşi date a naşterii crescător după Nume)
Clauza UNION – permite obţinerea rezultatului a două sau mai multe interogări
printr-o singură instrucţiune SELECT.
Exemplu:
SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE CodDep = ‘Dep01’
UNION
SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE Cant >= 100
(selectează tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate
înregistrările pentru care CodDep = ‘Dep01’, la care adaugă tuplele
(CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate înregistrările pentru care Cant
>= 100).
Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL.
Pentru a schimba ordinea de afişare a tuplelor extrase se poate utiliza clauza ORDER BY
aplicată doar relaţiei finale şi nu asupra fiecărei fraze SELECT.
Regăsirea datelor din două sau mai multe relaţii
Interogarea datelor din două sau mai multe tabele (relaţii) presupune existenţa
unor câmpuri comune pentru realizarea operaţiei de cuplare (operatorul JOIN). În fraza
SELECT operaţia de cuplare este definită în clauza WHERE sub forma:
<nume tabela1>.<cheie1> = <nume tabela2>.<cheie2>
(unde <cheie1>, <cheie2> reprezintă câmpurile ce identifică înregistrările corespondente
în cele două tabele).
Pentru exemplificare pe lângă tabela Stocuri mai considerăm tabela Produse(CodP, DenP,
DesP).
SELECT Produse.CodP,DenP,UmP,Cant,Pret FROM Produse,Stocuri
WHERE Produse.CodP = Stocuri.CodP
(extrage toate tuplele (CodP,DenP,UmP,Cant,Pret) pentru care valoarea atributului CodP
din tabela Produse este egală cu valoarea atributului CodP din tabela Stocuri ).
În lipsa clauzei WHERE se vor extrage toate combinaţiile posibile între tuplele celor
două tabele (produsul cartezian).

Fiecărei tabele i se poate atribui un alias astfel încât fraza de mai sus este echivalentă cu
fraza:
SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP =
B.CodP
În anumite situaţii poate fi necesară corelarea (cuplarea) unei relaţii (tabele) cu ea
însăşi. Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de
mai multe ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm
următoarea interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP =
B.CodP)
Pentru rezolvarea unor astfel de probleme s-au utilizat instrucţiuni SELECT imbricate
care vor fi prezentate în detaliu în cele ce urmează.
Instrucţiuni SELECT imbricate
Limbajul SQL oferă posibilitatea construirii unor interogări complexe prin
includerea în clauza WHERE a unei instrucţiuni SELECT, a altei instrucţiuni SELECT
(numită sub-interogare sau ‘inner’) astfel:
SELECT <lista atribute> FROM <lista relaţii>
WHERE <condiţie> (<sub-interogare>)
La rândul ei sub-interogarea poate conţine în clauza WHERE o altă instrucţiune SELECT
obţinând astfel o interogare complexă constituită din instrucţiuni SELECT imbricate pe
un număr oarecare de nivele. Instrucţiunea SELECT interioară generează valori pentru
condiţia de căutare a instrucţiunii SELECT exterioare care o conţine (numită şi ‘outer’). O
sub-interogare poate returna o singură valoare, sau poate returna mai multe valori.
În ce priveşte ordinea de evaluare a interogărilor pot exista :
- sub-interogări simple - în care interogarea interioară este evaluată prima, independent
de interogarea exterioară, iar rezultatul interogării interioare este utilizat de
interogarea exterioară;
- sub-interogări corelate - în care interogarea exterioară transmite repetat câte o valoare
pentru interogarea interioară, care în baza valorii primite, parcurge tuplele relaţiei şi
transmite interogării exterioare rezultatul obţinut. Astfel de interogări realizează
corelarea unei relaţii cu ea însăşi şi sunt cele mai performante.
Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe
ori cu preţuri diferite şi ne interesează poziţiile cu preţul minim, formulăm următoarea
interogare:
SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A
WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP =
B.CodP)
Sub-interogări simple care returnează o singură valoare - pot fi utilizate în
interogări imbricate având sintaxa:
SELECT <lista atribute> FROM <lista relaţii>
WHERE <atribut> =
<
>

Nicolae Morariu
<=
>=
!=
(<sub-interogare>)
[ORDER BY <atribut[ASC]|DESC,…]
Exemplu:
SELECT CodDep,CodP,Cant FROM Stocuri
WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep
(afişează produsele pentru care există stocuri peste medie, ordonate pe depozite).
Sub-interogari simple care returneaza mai multe valori pot fi utilizate în
interogări imbricată care utilizează în clauza WHERE codiţii care generează o mulţime de
valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS.
Exemplu:
SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi WHERE
Numar IN
(SELECT Numar FROM Beneficiari,ComenziWHERE Beneficiari.Nume=’Ionescu’
AND
Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar))
Predicatul ANY poate fi utilizat în combinaţie cu oricare din operatorii <, >, =,
<=, >=, != şi permite verificarea dacă valoarea unui atribut satisface condiţia precizată
pentru orice valoare din lista rezultată din subinterogare.
SELECT CodP FROM Stocuri WHERE Cant > ANY
(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)
Predicatul ALL returnează toate tuplele pentru care valorile atributului din clauza
WHERE sunt <, >, <=, >= decât toate valorile generate de interogarea interioară (acest
predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal în care toate
interogările din listă sunt egale).
Exemplu:
SELECT * FROM Stocuri WHERE Cant < ALL
(SELECT Cant FROM Stocuri WHERE CodDep = “D1”)
Predicatul EXISTS verifică dacă pentru fiecare tuplă a relaţiei există tuple care
satisfac condiţia din interogarea interioară (deci EXISTS permite specificarea mai multor
atribute în interogarea interioară).
Astfel spre exemplu instrucţiunea:
SELECT * FROM Produse A WHERE NOT EXISTS
(SELECT * FROM Stocuri B WHERE B.CodP=A.CodP)
va returna o listă de produse care nu au nici o înregistrare în Stocuri.
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 încât prin acestea să se obţină un
proiect soft operaţional. Proiectantul va grupa funcţiile ce trebuie să fie interconectate şi
va descrie modalităţile de realizare a legăturilor. După proiectanţii de soft vor interveni

programatorii, pentru transpunerea în realitate a proiectului. Ei vor controla intrările,

prelucrările şi ieşirile din sistem prin intermediul programelor [1].
Softul are două componente de bază instrucţiunile şi modulele. Instrucţiunile sunt
operaţiuni elementare executate de calculator prin gruparea şi selecţia controlată a
acestora pentru atingerea obiectivelor funcţiilor de prelucrare orientate pe probleme.
Instrucţiunile constituie cel mai jos nivel al operaţiunilor ce pot fi executate de către un
limbaj de programare. Blocurile de instrucţiuni sunt astfel grupate încât să constituie
anumite structuri executabile de calculator. De modul în care sunt grupate instrucţiunile
pentru a da naştere unor structuri standard ale programelor, de relaţiile dintre instrucţiuni,
de aranjamentul acestora depinde calitatea softului proiectat [1].
Modulul – este o colecţie sau o formă grupată de instrucţiuni de programe sursă.
Modulele se pot grupa pentru a forma programele.
Programul, în concepţia diverşilor autori, are semnificaţii diferite. El este definit
ca:
un set de instrucţiuni cu ajutorul cărora se efectuează prelucrări specifice;
o entitate ce poate fi executată pe calculator;
un mijloc de comunicare cu calculatorul pentru rezolvarea unor probleme;
o descriere a unui algoritm şi a datelor asociate în vederea execuţiei pe calculator,
deci o reprezentare a acestora (algoritmi şi date) ţinând cont de restricţiile impuse de
calculator;
o realizare a unei funcţii f care, dată fiind o mulţime de date x, specifică valoarea
y=f(x);
Prin algoritm se înţelege o metodă de soluţionare a unei clase de probleme,
reprezentată de o succesiune finită de operaţii bine definite, numite instrucţiuni.
Prin prisma complexităţii lor programele se pot clasifica [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 legături
complexe.
Pentru ca programele să fie caracterizate prin eficienţă, fiabilitate, flexibilitate,
inteligibilitate, în procesul elaborării lor trebuie să se respecte anumite principii [1]:
principiul conformării, potrivit căruia programele trebuie să fie elaborate în
conformitate cu cerinţele utilizatorului;
principiul completitudinii constă în realizarea descrierilor complete ale obiectivelor
programului pe toate nivelurile ierarhice de descompunere;
principiul abstractizării se referă la elaborarea funcţiei programului, ţinând cont de
elementele esenţiale, făcându-se abstracţie de detaliile nesemnificative;
principiul modularizării constă în descompunerea programelor în subdiviziuni logice
(module), care vor fi analizate în procesul de concepere şi elaborare a programelor.
În timp s-au conturat mai multe metode de programare, deşi mai corect ar fi să se
numească tehnici de programare [1].
Metoda programării clasice are la bază construirea monolitică a logicii
programului, fără intenţii de structurare. Programul este privit în totalitatea lui şi analizat

Nicolae Morariu
direct la nivelul operaţiilor elementare pe care le implică executarea lucrării care se

elaborează .
Programarea modulară constă în descompunerea programului, chiar din faza de
proiectare, în module uşor de întrebuinţat. Fiecare modul este apoi analizat ca un program
distinct şi rezolvat ca atare [1].
Metoda programării structurate constă în faptul că oferă o rezolvare standardizată
şi structurată, în mod unitar, a programelor, reprezentând o ridicare a activităţii de
programare la nivelul activităţii industriale, fundamentată pe o metodologie ştiinţifică.
Programarea structurată este caracteristică dezvoltării sistemelor pe baza diagramelor
fluxului de date şi utilizează limbaje structurate. Ea presupune o separare între structurile
de date şi codul funcţiilor care le prelucrează.
Metoda programării orientate-obiect - constă în abordarea naturală a lumii reale,
folosind componente modularizate şi eliminând restricţiile impuse de mediul de
programare. Se definesc concepte noi de tip, clasă, moştenire, etc [Udrică M., 2000].
5.2.1. Atributele modulelor

La nivelul softului proiectat, componenta de bază este modulul. El este o colecţie
sau o formă grupată de instrucţiuni ale programului sursă. La rândul lor, modulele se pot
grupa pentru a forma programe.
Modulele programelor au următoarele caracteristici [1]:
Un modul este format dintr-un grup de instrucţiuni care sunt contigue din punct de
vedere fizic şi sunt executate ca o unitate distinctă;
Grupurile de instrucţiuni care formează un modul au începuturi şi sfârşituri bine
definite;
În majoritatea cazurilor, grupul de instrucţiuni are doar un punct de intrare şi unul de
ieşire;
Un modul poate fi un program sau un subprogram distinct compilat sau o procedură
internă a unui program.
Un modul are trei componente de bază: funcţia, logica şi interfeţele.
Funcţia unui modul constă în transformarea datelor prin procesul de execuţie a
acestuia. Funcţia este tratată în regimul cutiilor negre, ea fiind văzută la nivel de modul
doar prin ceea ce se percepe în exteriorul lui, nu privindu-i componentele interne sau,
altfel spus, rolul acestora. Interes prezintă doar intrările şi ieşirile modulului respectiv
[1].
La nivelul softului, referirea la un modul este în acelaşi timp o referire la funcţia
lui. La nivelul cel mai de sus, modulele au funcţii orientate spre problema de rezolvat, în
timp ce modulele aflate pe nivelurile mai de jos au funcţii orientate spre prelucrările pe
care le realizează [1].
În diagrama de structură, folosită pentru reprezentarea grafică a proiectelor soft, un
modul este reprezentat printr-o casetă (dreptunghi) ce poartă denumirea funcţiei
îndeplinite.
La atribuirea numelui unui modul trebuie să se ţină cont de faptul că acesta trebuie
să surprindă atât funcţia proprie, cât şi pe cele ale subcomponentelor de ordin inferior. Se

recomandă evitarea conjuncţiilor din structura numelor, deoarece ele ar sugera necesitatea
folosirii mai multor module [1].
Logica modulului descrie prelucrările care au loc în interiorul acestuia [1].
La nivelul programării, preocuparea este, în esenţă, legată de logica modulului,
algoritmii de prelucrare, redaţi sub diverse forme – scheme logice, pseudocod, tabele de
decizie, arbori de decizie sau combinaţii ale acestora – sunt concepuţi pentru prezentarea
modului de transformare a intrărilor în ieşiri. Paşii algoritmilor se vor transforma în
instrucţiuni ale limbajelor de programare [1].
Interfeţele sunt conexiuni sau cuplaje între module. Interfeţele modulelor sunt
utilizate pentru stabilirea căilor prin care să se transfere controlul de la un modul la altul
[1].
Conexiunile dintre module se înregistrează pe două planuri:
al transferării controlului de la un modul la altul;
al transmiterii datelor de la un modul la altul.
În concluzie, se poate spune că eficienţa proiectelor – soft depinde în mare măsură
de eficienţa cu care se transferă controlul între module, precum şi de metoda folosită
pentru transmiterea datelor între module.
5.2.2. Structurile de control ale programelor

Proiectul soft trebuie să fie văzut din două puncte de vedere: logic şi fizic.
Din punct de vedere logic, modalitatea în care intră în funcţiune modulele este
redată prin structura ierarhică a lor [1].
Din punct de vedere fizic, după ce s-a stabilit structura logică, se va pune problema
adaptării prelucrării lor pe calculator, moment în care se va avea în vedere structura
execuţiei instrucţiunilor, adică a secvenţelor după care se declanşează operaţiunile din
interiorul modulelor [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: secvenţa, selecţia, iteraţia sau repetiţia. Ele mai sunt cunoscute
şi sub numele de structură secvenţială, alternativă (simplă şi generalizată), repetitivă
(condiţionată anterior sau la început şi condiţionată posterior sau la sfârşit ).
Secvenţa asigură parcurgerea instrucţiunilor în ordinea în care apar. Selecţia
defineşte alegerea unui grup de instrucţiuni din două sau mai multe posibile. Iteraţia oferă
posibilitatea execuţiei repetate a unui grup de instrucţiuni [1].
În elaborarea programelor structurate este necesar să se respecte o serie de
restricţii, şi anume [1]:
fiecare element (secvenţa, selecţia, iteraţia) are un punct de intrare;
fiecare element are un punct de ieşire unic;
elementul de iteraţie permite şi o execuţie cu factor de repetiţie zero, adică excluderea
elementului respectiv din execuţie.
Fiecare element din cele enunţate (secvenţa, selecţia, iteraţia) care respectă
restricţiile de mai sus defineşte un bloc standard. Structura secvenţială (liniară) se
prezintă astfel [1]:

Nicolae Morariu
s1
s2
sn
Figura 5.1. Structura secvenţială [1]
Selecţia (structura de tip IF-THEN-ELSE) sau structura alternativă are următoarea

formă de prezentare [1]:
NU DA
C
Bloc - 2 Bloc - 1
Figura 5.2. Structura alternativă [1]
Dacă se îndeplineşte condiţia C, se execută operaţiile din Bloc-1, altfel se execută

operaţiile din Bloc-2; după execuţia blocului, se continuă cu instrucţiunea următoare.
Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecţiei.
Ea permite alegerea unei variante din mai multe posibile (figura 5.3).

Bloc - 1 Bloc - 2 Bloc - n
Figura 5.3. Structura alternativă generalizată [1]
Iteraţia sau structura repetitivă defineşte execuţia repetată a unei operaţii sau grup
de operaţii, funcţie de rezultatul evaluării unei condiţii. Evaluarea condiţiei se face fie
înainte, fie după executarea operaţiilor.
Structura repetitivă condiţionată anterior (de tip WHILE-DO) se reprezintă ca în

figura 5.4
Bloc -
1
C
DA
NU
Figura 5.4. Structura repetitivă condiţionată anterior [1]
Structura repetitivă condiţionată posterior (de tip DO UNTIL) are forma dinn
figura 5.5.

Nicolae Morariu
Bloc - 1
C
DA
NU
Figura 5.5. Structura condiţionată posterior [1]
O formă particulară de structură repetitivă condiţionată posterior este structura

repetitivă cu număr definit de paşi (de tip DO FOR). Numărul de repetiţii este controlat
de o variabilă, numită variabilă de control. În reprezentarea grafică următoare, V este
variabila de control, Vi este valoarea iniţială a variabilei de control, iar R este raţia
(incrementul). O astfel de structură este redată în figura 5.6.
V=Vi
Bloc - 1
V=Vi+
R
V>Vf
NU
DA

Figura 5.6. Structura repetitivă cu număr definit de paşi [1]
În literatura de specialitate, se consideră că structura secvenţială, structura

alternativă de tip IF-THEN-ELSE şi structura repetitivă condiţionată anterior sunt
suficiente pentru a defini structura de control a oricărui program. Din acest motiv, cele
trei structuri de control, enumerate mai sus, sunt numite structuri fundamentale sau
structuri de bază.
5.2.3. Proiectarea şi realizarea programelor

Ideea de bază în proiectarea programelor constă în faptul că acesta trebuie să
respecte întocmai structurile diagramelor fluxurilor de date, prin nivelurile arhitecturale
de tip program.
Pentru proiectarea programelor, programatorii vor respecta sistemul de cerinţe şi
restricţii impus de etapele parcurse anterior pentru realizarea sistemului informatic.
Urmând principiile programării structurate, realizarea programelor se face în următoarele
faze: definirea problemei de programat; descompunerea problemei de programat;
realizarea modulară a produselor program; testarea “top-down” a produselor program;
definirea programului testat şi a documentaţiei aferente; dezvoltarea versiunii calitative a
produsului program [2].
Specificaţiile elaborate în etapele precedente permit definirea problemei de
programat prin care se formulează elementele specifice şi se analizează relaţiile dintre
aceste elemente, din punct de vedere dinamic sau static.
Descompunerea aplicaţiei se poate face după criteriul funcţionalităţii, motiv pentru
care elementele rezultate se mai numesc şi module funcţionale. Din punct de vedere al
fluxului datelor pot fi [2]:
module de intrare, care manipulează datele de intrare;
modulele de ieşire, care furnizează rezultate ale prelucrărilor;
module de prelucrare, care efectuează diverse operaţii asupra datelor.
Pe baza unor funcţiuni identificate sau a altor raţiuni de programare, modulele pot
fi divizate în continuare. Scopul acestei structurări funcţionale până la nivel elementar
este de a identifica funcţiunile sistemului şi de a le separa, eventual, în funcţiuni generale
şi cu caracter specific aplicaţiei.
Modulele funcţionale pot fi descompuse apoi după criteriul omogenităţii, rezultând
modulele operaţionale.
Realizarea modulară a produselor program presupune următoarele acţiunile [2]:
Examinarea modulelor şi specificarea succesiunii operaţiilor de prelucrare descrise în
acestea.
Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere
întreaga cazuistică a sistemului informaţional şi să testeze toate ramurile programului.
Precizarea elementelor de comunicaţie între module, respectiv stabilirea parametrilor
de intrare/iesire în/din fiecare modul.
elaborarea algoritmii de prelucrare specifici fiecărui modul şi structura programelor.
transcrierea algoritmilor într-un limbaj de programare.
scrierea codului sursă şi obţinerea fişierelor executabile.

Nicolae Morariu
Prin compararea rezultatelor propuse a fi obţinute cu cele efectiv furnizate de

aplicaţia informatică, sunt verificate sintactic şi funcţional module din program. Dacă se
realizează identitatea între cele doua categorii de rezultate, operaţia de testare se
consideră încheiată.
O atenţie deosebită trebuie acordată întocmirii documentaţiei programului cu
observaţia că în acest sens este recomandată autodocumentarea la nivel de modul.
5.3. Proiectarea sistemelor distribuite

Un sistem de prelucrare distribuită a datelor presupune existenţa a două sau mai
multor sisteme independente de prelucrare a datelor, numire noduri, interconectate într-o
configuraţie de reţea. Ele folosesc facilităţi de comunicare pentru schimbul de informaţii
şi îşi coordonează activităţile pentru realizarea unui anumit scop. Cu alte cuvinte un
sistem de prelucrare distribuită a datelor permite realizarea activităţii de prelucrare
automată a datelor într-un mediu de reţea. Într-un astfel de mediu, cooperează trei
componente tehnologice distincte: prelucrarea datelor, comunicarea datelor şi reţeaua de
calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel încât să se realizeze
obiectivele comune ale organizaţiei [1].
Legătură/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 configuraţie de reţea;
o posibilitate de transfer a datelor folosind facilităţi de partajare a datelor;
un obiectiv comun de realizat.
La proiectarea unui sistem nou trebuie să se definească clar obiectivele pe
care trebuie să le îndeplinească noul sistem. Aceste obiective pot fi clasificate în
financiare şi funcţionale.
Din punct de vedere financiar se urmăreşte maxim de profit cu minimum de
cheltuieli. Din punct de vedere funcţional, scopul este să se realizeze un sistem care să
aibă cele mai bune rezultate [1].
Costul sistemului se regăseşte în costurile iniţiale pe procesoare,
perifericelor(imprimantă, scanner, etc), cablări, soft-uri, şi costuri funcţionale
(operaţionale) cu distribuirea datelor, cu personalul, întreţinerea sistemului, etc.
Performanţa sistemului este apreciată prin prisma productivităţii şi a
eficienţei lui. Ea se determină în funcţie de cerinţele operaţionale ale unui sistem de
calcul. Se consideră că performanţa este o funcţie a [1]:
timpului de răspuns(intervalul de timp dintre momentul formulării unei cereri de la
un terminal de comunicaţie-date şi obţinerea răspunsului în acelaşi loc);

randamentului(cantitatea de date ce poate fi prelucrată de către un sistem de calcul

într-o perioadă de timp);
calităţii serviciilor oferite utilizatorilor(siguranţă, fidelitate, integrare, control şi
acceptabilitate);
nivelul serviciilor.
Sistemul propus trebuie să fie fezabil, din punct de vedere tehnic, şi eficient, prin
prisma costurilor prelucrării automate a datelor şi a comunicaţiilor din sistem.
Performanţele sistemului sunt influenţate de mai mulţi factori, cum ar fi timpul de
răspuns, randamentul, disponibilitatea, siguranţa(securitatea sistemului).
La proiectarea sistemelor distribuite trebuie avute în vedere două componente
majore:
Proiectarea nodurilor;
Proiectarea reţelei de comunicaţii.
Ordinea de proiectare nu este strictă rămânând la latitudinea echipei de proiectare.
Trebuie să se ţină seama de posibilitatea proiectării, după ce anumite etape au fost
îndeplinite [1].
Sisteme PAD
Proiectare Proiectare
NODURI subsisteme de
COMUNICAŢII
Proiectare
INTERFEŢE
Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuită a
datelor [1]
Modele de sisteme distribuite

Calculatoarele personale şi staţiile de lucru pot fi utilizate fie ca sisteme de-sine-
stătătoare pentru execuţia diferitelor aplicaţii informatice, fie într-o configuraţie de reţea.
O reţea locală se bazează pe un set de calculatoare personale, fiecare cu propria memorie,
astfel încât să poată folosi în comun toate echipamentele şi software-ul din reţea. Dintre
toate calculatoarele, există unul sau unele mai puternice pe care se vor afla aplicaţii
folosite în comun de celelalte calculatoare ale reţelei. Cea mai utilizată arhitectură este
arhitectura client/server.
Arhitectura client/server

Nicolae Morariu
Modelul Client /Server oferă date distribuite, portabilitate între platforme şi un

acces standardizat la resurse. Termenul de Client /Server provine de la metoda
tradiţională de accesare a unui computer central numit server de către computere aflate la
distanţă sau clienţi într-o infrastructură de reţea.
Modelul Client /Server implică o entitate software (clientul) care efectuează cereri,
acestea fiind îndeplinite de o altă entitate software(serverul) . Clientul este cel care
transmite o cerere severului, acesta o interpretează şi apoi o efectuează. Pentru a putea
îndeplini cererea, serverul poate referi o sursă de informaţie (baze de date), să efectueze
procesări asupra datelor, să controleze periferice sau să efectueze cereri adiţionale altor
servere. Un client poate face cereri la multiple servere şi un server poate deservi mai
mulţi clienţi.
Sursă de informaţie (Bază de date)

Cerere Procesare (Logică şi Aritmetică)
Client Server Dispozitive (Imprimantă, periferice
partajate)
Rezultatul Servicii(Cereri adiţionale altor
servere)
îndeplinirii cererii
Figura 5.9. O tranzacţie Client /Server.

Se poate afirma că tehnologia client / server împarte o aplicaţie în trei componente
de bază: un client, un server şi o reţea care conectează clientul la server. Atât clientul cât
şi serverul sunt calculatoare cu grade variate de putere de calcul, ce colaborează la
îndeplinirea sarcinilor.
Calculatorul server este responsabil cu administrarea accesului la baza de date,
precum şi cu alte sarcini care-i revin direct serverului. Când se alege un server pentru
mediul de lucru client / server trebuie avute în vedere: scalabilitatea – posibilitatea de
creştere a capacităţii serverului, în limite rezonabile; toleranţa la erori – posibilitatea de
recuperare a contextului calculatorului server după producerea unei disfuncţionalităţi
hardware; service şi asistenţă tehnică. Calculatoarele server au utilizări variate în
sistemele client / server (există servere de fişiere care asigură spaţiul de disc centralizat
care poate fi folosit conform necesităţilor calculatoarelor client din reţea; servere de
tipărire – care colectează informaţiile ce urmează a fi trimise către imprimantă de către
calculatoarele client şi le asigură tipărirea într-o anumită ordine; servere de baze de date –
calculatoare care rulează un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL;
serverele de aplicaţii – calculatoare server care rulează programe mari de aplicaţii).
Sistemele client-server au apărut ca urmare a descentralizării activităţii din
diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două
nivele: client, server. De obicei clienţii reprezintă utilizatorii finali care vor
comunica cu serverul bazei de date în cadrul unei reţele de calculatoare. După rolul
pe care îl are fiecare din componentele client, server, se pot distinge trei arhitecturi
de bază pentru un sistem client-server (Loomis 1992) şi anume:

- arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele

două componente (server, client). Serverul este responsabil de administrarea
memoriei şi zăvoarelor, efectuarea operaţiilor în memoria secundară, securitatea,
integritatea şi recuperarea bazei de date, executarea procedurilor stocate şi
optimizarea interogărilor. Clientul este responsabil de administrarea tranzacţiilor şi
realizarea interfeţei cu limbajul de programare;
- arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este
realizată de către client. Serverul este responsabil de memoria secundară şi furnizează
paginile corespunzător cererilor formulate de client;
- arhitectura de tip server de bază de date – cea mai mare parte din prelucrările
bazei de date este efectuată de către server. Clientul transmite cererea serverului,
primeşte rezultatele şi le transmite aplicaţiei. Este modul utilizat frecvent de către
sistemele relaţionale.
În fiecare dintre cele trei cazuri serverul se găseşte pe aceeaşi maşină ca şi baza de
date fizică. Clientul se poate afla pe aceeaşi maşină sau pe una diferită. În cazul
bazelor de date distribuite pe mai multe maşini, clientul va comunica cu câte un
server de pe fiecare maşină. De asemenea mai mulţi clienţi pot comunica
concomitent cu acelaşi server (accesul concurent).
Arhitectura tradiţională a sistemelor client-server este o arhitectură pe două
nivele (etaje), în care la primul nivel (clientul) se realizează interfaţa cu utilizatorul şi
logica principală a aplicaţiei, iar la al doilea nivel (serverul) se realizează validarea
datelor şi accesul la baza de date. Necesitatea rezolvării unor probleme complexe care
presupun accesul la baza de date a unui număr mare de utilizatori, utilizarea unor
platforme hard-soft diferite, precum şi integrarea bazelor de date în mediul Web, au
impus definirea unei noi arhitecturi client-server în care sunt definite trei nivele şi anume:
- nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei;
- nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării datelor;
- nivelul server de baze de date, la care se realizează validarea datelor şi accesul la baza
de date.
Un server de aplicaţie poate servi mai mulţi clienţi, fiind conectat fizic atât la nivelul
client cât şi la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate
fi un browser Web, iar serverul de aplicaţie poate fi un server Web.
Se consideră baza de date FurnizoriClienţi care conţine următoarele tabele (în
ACCESS):
PRODUSE (catalog de produse)

Nicolae Morariu
Câmp Semnificaţie Tip dată Dimensiune Observaţii

Codp Cod produs Number, Integer 4 Cheie primară
Denp Denumire produs Text 20
Desp Descriere produs Hyperlink Referă document
corespunzător
STOCURI (stocurile de produse pe depozite)

Codp Cod produs Number, Integer 4 Lookup Wizard cu
Lookup Wizard tabela PRODUSE
CodDep Cod depozit Text 2
Ump Unitate de Lookup Wizard 8 Creare şi utilizare
măsură produs listă de valori
Cant Cantitate Number, Integer 4
Pret Preţ unitar Number, 8
LongInteger
FURNIZORI (catalog de furnizori)

Codf Cod furnizor Number, Integer 4 Cheie primară
Denf Denumire Text 30
furnizor
Adresaf Adresa furnizor Text 25
CLIENTI (catalog de clienţi)

Codc Cod client Number, Integer 4 Cheie primară
Denc Denumire client Text 30
Adresac Adresa client Text 25

OFERTE (oferte de produse de la furnizori)

Codf Cod furnizor Number, Integer 4 Lookup Wizard cu
Lookup Wizard tabela FURNIZORI
Lookup Wizard tabela PRODUSE
LongInteger
Datao Data ofertei Date 8
Oferta Oferta furnizor Hyperlink Referă document
corespunzător
VANZARI (vânzările de produse pe clienţi)

Codc Cod furnizor Number, Integer 4 Lookup Wizard cu
Lookup Wizard tabela CLIENTI
Lookup Wizard tabela
PRODU,03SE
Cant Cantitate Number, Integer 4
LongInteger
Să se scrie comenzile SQL pentru realizarea interogărilor de mai jos:

a) Situaţia stocurilor
Câmp CodDep Codp Denp Ump Cant Pret Valoare

Tabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret
b)Situaţia ofertelor
Câmp Codf Denf Adresaf Codp Denp Ump Pret Datao
Tabel Furnizori Furnizori Furnizori Produse Produse Oferte Oferte Oferte

Nicolae Morariu
a
c) Situaţia vânzărilor
Câmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare Datav
Tabel Clienti Clienti Clienti Produse Produse Vanzari Vanzari Vanzari Cant*Pret Vanzari
a
d) Lista produselor pentru care nu există oferte
Câmp Codp Denp

Tabela Produse Produse
e) Lista produselor pentru care nu s-au făcut vânzări în perioada [Data1,Data2]
Câmp Codp Denp

Tabela Produse Produse
Răspuns:
a)
SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS Valoare
FROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp
b)
SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao
FROM Oferte, Produse,Furnizori
WHERE Oferte.Codp = Produse.Codp AND Oferte.Codf = Furizori.Codf
c)
SELECT Vanzari.Codc, Denc, Adresac, Vanzari.Codp, Denp, Ump,Cant, Pret,
Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,Clienti
WHERE Vanzari.Codp = Produse.Codp AND Vanzari.Codc = Clienti.Codc
d)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Oferte WHERE Produse.Codp=Oferte.Codp)
e)
SELECT * FROM Produse WHERE NOT EXISTS
(SELECT * FROM Vanzari WHERE Produse.Codp=Vanzari.Codp
AND Datav BETWEEN Data1 AND Data2)
Teste 2006
1. Care definiţie este corectă:

a) Un sistem reprezintă un ansamblu de elemente (componente) interdependente,

între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite,
cu scopul atingerii unui anumit obiectiv;
b) Un sistem reprezintă un ansamblu de identificatori care au rolul sa rezolve
activităţi specifice.
Răspuns: a
2. Sistemul informaţional cuprinde:
a) Ansamblul informaţiilor interne şi externe, formale sau informale utilizate în
cadrul firmei precum şi datele care au stat la baza obţinerii lor;
b) Procedurile şi tehnicile de obţinere(pe baza datelor primare) şi de difuzare a
informaţiilor;
c) Platforma necesară prelucrării şi disipării informaţiilor;
d) Personalul specializat în culegerea, transmiterea, stocarea şi prelucrarea
datelor.
Răspuns: a,c,d
3. Un sistem informatic este:
a) un sistem destinat conducerii unei organizaţii:
b) un sistem utilizator-calculator integrat, care furnizează informaţii pentru a sprijini
activităţile de la nivel operaţional şi activităţile de management într-o organizaţie,
utilizând echipamente hardware şi produse software, proceduri manuale, o bază
de date şi
modele matematice pentru analiză, planificare, control şi luarea deciziilor:
c) un ansamblu structurat de elemente intercorelate funcţional pentru automatizarea
procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor.
Răspuns: b,c
4. Identificaţi afirmaţia falsă:
a) Sistemul informaţional este subordonat sistemului de conducere.
b) Sistemul informaţional face legătura între sistemul condus şi sistemul de
conducere.
c) Sistemul informatic este inclus în sistemul informaţional.
d) Sistemul condus este subordonat sistemului informaţional.
Răspuns: d
5. Sunt componente principale ale unui sistem informatic:
a) Baza informaţională;
b) Manager general;
c) Baza tehnică;
d) Baza ştiinţifică metodologică;
e) Sistemul de programe.

Nicolae Morariu
Răspuns: a,c,d,e
6. Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie:
a) asigurarea conducerii cu informaţii reale şi în timp util necesare fundamentării
şi elaborării operative a deciziilor;
b) asigurarea funcţionării normale si optime a activităţilor;
c) creşterea productivităţii muncii;
d) creşterea profitului;
e) îmbunătăţirea imaginii unităţii economice.
Răspuns: a
7. După domeniul de utilizare, sistemele informatice se clasifică în:
a) Sisteme informatice pentru conducerea activităţilor economico-sociale;
b) Sisteme informatice pentru conducerea proceselor tehnice;
c) Sisteme informatice şi expert;
d) Sisteme informatice pentru activităţi speciale.
Răspuns: a,b,d
8. Sistemele informatice economice pot fi împărţite după modul de organizare a datelor
în:
a) sisteme imagine;
b) sisteme bazate pe tehnica bazelor de date (ierarhice, reţea, relaţionale,
orienatate-obiect);
c) sisteme bazate pe algoritmi fundamentali;
d) sisteme bazate pe fişiere.
Răspuns: b,d
9. Ciclul prelucrării datelor pentru sistemul informatic cuprinde următoarele faze:
a) culegerea datelor;
b) pregătirea datelor;
c) prelucrarea datelor;
d) ştergerea datelor.
Răspuns: a,b,c
10. În faza de întreţinere a fişierelor există mai multe activităţi, dintre care amintim:
a) memorarea(stocarea) datelor în vederea utilizării lor viitoare;
b) actualizarea datelor memorate astfel încât să surprindă cele mai recente
evenimente;
c) crearea datelor;
d) indexarea datelor pentru a înlesni o uşoară regăsire a lor;
e) protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi
tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.

Răspuns: a,b,d,e
11. Metodologiile de realizare a sistemelor informatice cuprind:
a) reguli de formalizare a datelor;
b) instrumente pentru concepţia, realizarea şi elaborarea documentaţiei;
c) modalităţile de administrare a proiectului;
d) instrucţiuni pentru luarea deciziilor;
e) modalitatea de abordare a sistemelor.
Răspuns: a,b,c,e
12. Reprezintă modul unitar sau manieră comună în care analiştii de sisteme,
programatorii şi alte categorii de persoane implicate realizează procesul de analiza a
sistemului informaţional-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.
Răspuns: a
13. Care din afirmaţiile următoare sunt corecte:
a) Metoda top-down are ca obiectiv principal realizarea modularizării sistemului
de sus în jos.
b) Metoda top-down constă în agregarea modulelor de jos în sus.
c) Metoda top-down nu are la bază principiul abordării sistemice.
Răspuns: a
14. Nu sunt faze ale ciclului de viaţă al dezvoltării sistemelor:
a) microanaliza;
b) analiza;
c) colectarea;
d) proiectarea logică;
e) proiectarea fizică;
f) implementarea;
g) întreţinerea.
Răspuns: c
15. Propunerile pentru identificarea proiectelor de dezvoltare sunt făcute de:
a) top-managerii; b) personalul auxiliar;
c) muncitori; d) departamentul utilizatorilor.
Răspuns: a, d

Nicolae Morariu
16. Selecţia proiectelor de dezvoltare a sistemelor informaţionale, urmăreşte:

a) atingerea obiectivelor organizaţiei;
b) bunul mers a informaţiei;
c) creşterea duratei de implementare.
Răspuns: a
17. Care nu sunt activităţile efectuate în faza iniţierii proiectului:
a) stabilirea echipei de iniţiere a proiectului;
b) stabilirea bunelor relaţii cu beneficiarii;
c) stabilirea planului iniţierii proiectului;
d) stabilirea procedurilor manageriale;
e) stabilirea cerinţelor sistemului.
Răspuns: e
18. Tipurile activităţilor executate în cadrul planificării proiectului cuprind:
a) Descrierea ariei de întindere, a variantelor şi fezabilităţii proiectului;
b) Descompunerea proiectului în activităţi uşor executabile şi controlabile;
c) Crearea bazei de date;
d) Crearea unui buget preliminar;
e) Implementarea proiectului.
Răspuns: a, b, d
19. Următoarele afirmaţii sunt corecte:
a) Un studiu de fezabilitate are rolul de a asigura informaţiile obiective necesare
pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect
deja început mai poate fi continuat;
b) Studiul de fezabilitate face parte din etapa de întreţinere a sistemelor;
c) Diagrama Gantt este o modalitate de reprezentare grafică a proiectului.
Răspuns: a, c
20. Studiile de fezabilitate trebuie să conţină:
a) Definirea problemei (o scurtă descriere a proiectului şi explicarea a ceea ce-şi
propune el să realizeze);
b) Descrierea cerinţelor sistemului;
c) Explicaţia critică a motivării studiului întreprins;
d) Cuantificarea tuturor costurilor materiale şi beneficiilor aferente.
Răspuns: a, b, c, d
21. Diagramele Gantt se utilizează pentru:
a) reprezentarea ordinii activităţilor desfăşurate pentru realizarea proiectului;
b) reprezentarea grafică a proiectului;
c) descrierea proiectelor simple sau a unor componente ale proiectelor mari;

d) monitorizarea stadiului realizării activităţilor planificate.

Răspuns: b, c, d
22. Studiul sistemului existent constă în:
a) studiul activităţilor de bază desfăşurate de sistem;
b) identificarea metodelor si mijloacelor tehnice;
c) definirea caracteristicilor generale ale sistemului;
d) definirea direcţiilor de perfecţionare ale actualului sistem;
e) studiul sistemului de conducere.
Răspuns: a, b, c, e
23. Activitatea de determinare a cerinţelor sistemului se concretizează în diferite forme
ale informaţiilor colectate, cum sunt:
a) copii ale interviurilor;
b) realizarea programului;
c) implementarea sistemului;
d) interpretări ale răspunsurilor la chestionare.
Răspuns: a, d
24. Definirea caracteristicilor generale ale sistemului economic implică:
a) cunoaşterea profilului, obiectivelor agentului economic;
b) cunoaşterea locului în sfera serviciilor şi sfera producţiei;
c) cunoaşterea relaţiilor de cooperare cu alţi agenţi economici;
d) cunoaşterea specificului activităţii de bază ( producţie, servicii).
25. Studiul sistemului de conducere se referă la identificarea:
a) caracteristicilor rezultate din statutul de funcţionare a societăţii, tipuri de
decizii, modul de luare a deciziilor;
b) principalilor algoritmi, reguli de calcul şi de control;
c) mijloacelor tehnice existente în dotarea unităţii economice;
d) modului de organizare a producţiei.
Răspuns: a
26. Metodele tradiţionale de determinare a cerinţelor sistemelor sunt:

a) interviul;
b) prototipizarea;
c) Joint Application Design (JAD);
d) chestionarul.
Răspuns: a, d
27. Paşii prototipizării sunt:

Nicolae Morariu
a) Identificarea cerinţelor principale ale sistemului;

b) Realizarea prototipului iniţial;
c) Proces iterativ de adaptare a sistemului la cerinţele utilizatorului;
d) Folosirea sistemului aprobat de utilizatori.
28. Scopul diagramelor de date DFD este de a scoate în relief, într-o manieră cât mai
sugestivă, următoarele aspecte:
a) sursa datelor de prelucrare;
b) macheta datelor de prelucrare;
c) destinaţia datelor prelucrate;
d) legătura existentă între prelucrări şi activitatea de stocare a datelor.
Răspuns: a, c, d
29. Identificaţi afirmaţia falsă:
a) Diagrama de context scoate în evidenţă aria de întindere a sistemului analizat;
b) Diagrama fluxului de date ale nivelului logic curent, independentă de
tehnologie, reliefează funcţiile de prelucrare a datelor executate de către
sistemul informaţional curent;
c) Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem;
d) Diagrama fluxului de date prezintă modelarea conceptuală a datelor.
Răspuns: d
30. Simbolul folosit în diagramele DFD realizate cu SSADM (Structured Systems
Analysis and Design Methodology), pentru reprezentarea fluxului de date sunt:
a) săgeată;
b) elipsă;
c) cerc.
Răspuns: a
31. Câte entităţi externe conţine diagrama de context pentru aplicaţia Decontări:

patru entităţi; b) cinci entităţi; c) nici o entitate.

Răspuns: b
32 Raportul detaliat al cerinţelor sistemului conţine următoarele elemente:

a) refacerea analizelor pentru întregul sistem;
b) descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv
numele fiecărei intrări, sursa, cine îl completează, ce date va conţine şi cum
vor fi culese datele;
c) o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte,
documente).
Răspuns: b, c
33. Principalele elemente ale documentaţiei elaborate pentru modelarea logicii proceselor
sunt:
a) reprezentarea în engleza structurată;
b) reprezentarea logicii proceselor prin tabele de decizie;
c) reprezentarea prin diagrame entitate-relaţie;
d) reprezentarea logicii proceselor prin arbori de decizie;
e) tabelul sau diagrama stărilor de tranziţie.
Răspuns: a, b, d, e
34. Cea mai cunoscută formă utilizată pentru modelarea conceptuală a datelor este:
a) diagrama entitate-relaţie (DER);
b) diagrama fluxului de date (DFD);
c) diagrama stărilor de tranziţie.

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

Nicolae Morariu
a) cerc;
b) săgeată;
c) romb;
d) dreptunghi.
Răspuns: d
36. Nu sunt tipuri de relaţii:
a) relaţia unu-la-unu; b) relaţia unu-la-multe;
c) relaţia absolută; d) relaţia unei entităţi cu ea
însăşi.
Răspuns: c
37. Care din afirmaţiile următoare sunt adevărate:
a) O cheie-primară este o cheie-candidat care a fost selectată pentru a servi ca
identificator de cazuri în cadrul unui tip de entitate.
b) Entităţile sunt obiecte sau evenimente (fenomene sau procese economice, în
cazul nostru).
c) Un atribut este o proprietate sau o caracteristică a unei entităţi care prezintă
interes pentru organizaţie.
Răspuns: a, b, c
38. Afirmaţiile următoare nu sunt corecte:
a) Fiecare Format/formular de intrare va fi asociat unui flux al datelor de intrare
într-un proces al DFD;
b) Un proces al DFD va fi asociat cu o macheta de ecran;
c) Rapoartele se pot regăsi într-un flux al datelor generate de un proces al DFD.
Răspuns: b
39. Prezentarea informaţiile din formulare/formate şi rapoarte pot fi oferite:
a) sub formă de text;
b) sub formă de sfaturi;
c) sub formă de grafice;
d) sub formă de tabele.
Răspuns: a, c, d
40. Macheta imprimantei cuprinde:
a) antet;
b) titlu;
c) date elementare ce se imprima rând de rând;
d) totalurile.
41. Detaliile şi indicaţiile tehnice de realizare a machetei imprimantei se referă la:

a) volumul datelor de ieşire;

b) intensitatea datelor;
c) contrast.
Răspuns: a
42. Alegerea tipului de suport fizic de ieşire (imprimanta, display, etc.) se face în funcţie
de:
a) sursa de energie; b) calitatea datelor; c) costul suportului.
Răspuns: c
43. În definitivarea formei şi formatului de prezentare a situaţiilor finale trebuie să ţinem
seama de o serie de considerente practice cum ar fi:
a) Respectarea unor cerinţe ale factorilor de decizie privind macheta situaţiei
finale;
b) Restricţii tehnice;
c) Utilizarea formularelor pretipărite;
d) Utilizarea generatoarelor de rapoarte.
44. Activităţile parcurse la realizarea unui sistem de coduri sunt:
a) analiza elementelor care urmează a fi codificate;
b) analiza sistemului decizional;
c) uniformizarea datelor de intrare;
d) alegerea tipurilor de coduri.
Răspuns: a, d
45. La proiectarea intrărilor este necesar să se realizeze, în principal următoarele
activităţi:
a) alegerea colecţiilor de date;
b) proiectarea machetelor documentelor de intrare;
c) alegerea regulilor de control şi validare a datelor;
d) proiectarea formularelor (videoformatului) de intrare.
Răspuns: b, c, d
46. Macheta documentului de intrare conţine:
a) antetul documentului;
b) diagrama fluxului de date;
c) denumirea documentului.
Răspuns: a, c
47. Nu sunt metode de interacţiune om – maşină:

a) interacţiunea permanentă,

Nicolae Morariu
b) interacţiunea prin meniuri,

c) interacţiunea bazată pe obiecte icons,
d) interacţiunea prin limbaj natural.
Răspuns: a
48. Echipamentele necesare interacţiunii cu sistemul sunt:
a) eyescreen; b) keyboard; c) mouse.
Răspuns: b, c
49. Construirea prototipului secvenţei de derulare a dialogurilor se poate face cu ajutorul:
a) instrucţiunilor repetitive; b) produselor CASE; c) mediile de dezvoltare
grafică.
Răspuns: b, c
50. În procesul de modelare logică a datelor sunt paşi esenţiali:

a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare
şi rapoarte) privind aplicaţia, folosindu-se principiile normalizări;
b) Implementarea modelului logic al datelor.
c) Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără
să se ţină cont de perspectiva utilizatorului, într-un set de relaţii normalizate;
Răspuns: a, c
51. Nu sunt elemente de bază ale structurii relaţionale a datelor:
a) Relaţia;
b) Atributul;
c) Fişierul;
d) Domeniul;
e) Tuplul.
Răspuns: c
52. Paşii parcurşi în procesul de transformare a diagramelor entitate-relaţie în relaţii sunt:
a) Reprezentarea entităţilor;
b) Reprezentarea legăturilor;
c) Normalizarea relaţiilor.
Răspuns: a, b, 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;
Răspuns : a

54. Proiectarea fizică a sistemelor informatice implică:

a) proiectarea fizică a bazelor de date şi a fişierelor.
b) proiectarea structurii sistemului şi a programelor.
c) proiectarea documentaţiei sistemului analizat.
d) proiectarea strategiilor de prelucrare distribuită.
Răspuns : a, b, d
55. Proiectarea fizică a bazelor de date şi a fişierelor îşi propune să asigure:
a) trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor;
b) structura globală de organizare a datelor;
c) descrierea logică a datelor.
Răspuns : a
56. Sunt structuri de control fundamentale în realizarea programelor:
a) structura secvenţială;
b) structură funcţională;
c) structura alternativă;
d) structura organizaţională:
e) structura repetitivă.
Răspuns : a, c, e
57. Structura repetitivă condiţionată anterior este:
a) de tip WHILE-DO;
b) de tip DO UNTIL;
c) de tip DO FOR.
Răspuns : a
58. Nu sunt metode de programare:
a) metoda programării clasice;
b) metoda programării structurate;
c) metoda programării orientate-obiect;
d) metoda programării iterative.
Răspuns : d
59. Un modul are componente de bază:
a) funcţia;
b) schema;
c) logica;
d) interfeţele.
Răspuns : a, c, d
60. Funcţia unui modul constă în:
a) transformarea datelor prin procesul de execuţie a acestuia.

Nicolae Morariu
b) descrierea prelucrărilor care au loc în interiorul acestuia.

c) legătura cu alte module.
Răspuns : a
61. Realizarea modulară a programelor corespunde principiilor:
a) programării clasice;
b) programării structurate;
c) bazelor de cunoştinţe;
Răspuns : b
62. Principalele module de proiectare a sistemelor de prelucrare distribuită a datelor sunt:
a) proiectarea nodurilor;
b) proiectarea diagramelor;
c) proiectarea reţelei de comunicaţii.
Răspuns : a, c
63. Nu sunt componente de bază ale tehnologiei client/server:
a) clientul; b) administratorul de sistem;
c) serverul; d) reţeaua care conectează clientul la
server.
RĂSPUNS : B
64. Care dintre următoarele instrucţiuni nu sunt decizionale ?
a) WHILE ... WEND ;
b) IF...END IF;
c) IF...ELSE...END IF;
d) IF...THEN...ELSE IF... ... ...END IF ;
e) SELECT CASE...CASE... ... ...END SELECT.
Răspuns : a
65. Care dintre următoarele instrucţiuni repetitive sunt condiţionate posterior ?
a) FOR...NEXT ;
b) WHILE...WEND ;
c) DO WHILE...LOOP;
d) DO UNTIL...LOOP;
e) DO...LOOP WHILE.
Răspuns : e
66. Modelul conceptual pune în evidenţă:
a) modul de stocare a datelor pe suportul de memorare;
b) reprezentarea logică, detaliată a entităţilor, asocierilor (legăturilor) şi
datelor elementare
ale unei organizaţii;
c) structura globală de organizare a datelor.
Răspuns: b), c)
67. Normalizarea unei relaţii constă în:

a) Descrierea relaţiei în limbajul de descriere a datelor;

b) Identificarea dependenţelor între atributele relaţiei;
c) Descompunerea relaţiei în relaţii echivalente urmărind eliminarea redundanţei
datelor şi
anomaliilor la efectuarea operaţiilor de adaugare, actualizare şi ştergere în baza de
date.
Răspuns: c)
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.
Răspuns: a), b)
69. Sistemul de Gestiune a Bazelor de Date este:
a) un sistem de programe care permite definirea, crearea şi întreţinerea bazei de date
precum şi accesul controlat la baza de date;
b) un sistem de programe pentru interogarea bazei de date.
Răspuns: a)
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 activităţilor de proiectare şi realizare a sistemelor/ aplicaţiilor.
c) Aducerea în faţa analistului a problemelor supuse analizei.
d) Folosirea depozitelor modularizate.
Răspuns: a
71. Avantajele sistemelor CASE sunt:
a) exploatarea sistemului;
b) creşterea vitezei de realizare a sistemelor;
c) realizarea succesivă a componentelor unui sistem;
d) simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.
Răspuns: b, c, d
72. Instrumentele CASE se bazează pe:
a) o funcţie fundamentală;
b) două funcţii fundamentale;
c) mai multe funcţii fundamentale.
Răspuns: b
73. Caracteristicile mediilor moderne de tip CASE sunt:
a) integrarea;
b) aranjarea;
c) descompunerea;
d) exploatarea.

Nicolae Morariu
Răspuns: a, c
74. Domeniile către care se orientează Upper CASE-ul, sunt:
a) analiza cerinţelor sistemului;
b) proiectarea şi modelarea funcţională şi procedurală;
c) modelarea datelor şi proiectarea bazei de date;
d) generarea codurilor.
75. Nu sunt corecte următoarele afirmaţii:
a) CASE reprezintă Proiectarea Sistemelor Asistată de Calculator;
b) Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susţinere
a activităţilor de planificare, definire, proiectare şi realizare a softului.
c) CASE reprezintă Proiectarea Sistemelor cu Ajutorul Calculatorului;
d) CASE reprezintă Componente Asamblate ale Sistemelor Economice.
Răspuns: d
Întrebări
1. Enumeraţi principalele activităţi din cadrul unei intreprinderi în vederea identificării

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

informatic.
5. Enumeraţi produsele software de bază care pot fi utilizate pentru realizarea unui
sistem informatic.
6. Definiţi ciclul de viaţă a unui sistem informatic.
7. Enumeraţi etapele ciclului de viaţă a unui sistem informatic în modelul cascadă.
8. Enumeraţi metodologiile utilizate în funcţie de modul de abordare şi domeniul de

aplicabilitate
9. Enumeraţi cele 4 nivele care pot fi identificate în organigrama unei unităţi economice
Productive.

10. Descrieţi tipurile de legături care pot exista între două mulţimi de entităţi.
11. Definiţi cheia unei relaţii.
12. ENUMERAŢI METODE MODERNE DE ANALIZĂ ŞI DETERMINAREA

CERINŢELOR SISTEMULUI.
Răspuns:
- JAD (Joint Application Design);
- Prototipizarea.
13. ENUMERAŢI ARHITECTURILE DE BAZĂ PENTRU UN SISTEM CLIENT-
SERVER DUPĂ ROLUL PECARE ÎL AU
COMPONENTELE CLIENT ŞI SERVER;
RĂSPUNS:
- arhitectura de tip server de
obiecte;
- arhitectura de tip server de
pagini;
- arhitectura de tip server de bază
de date.
14. Enumeraţi cele 3 nivele ale noii arhitecturi client-server definite ca urmare a
utilizării a unor platforme hard-soft diferite, precum şi integrării bazelor de date în
mediul Web:
Răspuns:
- nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei;
- nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării datelor;
- nivelul server de baze de date, la care se realizează validarea datelor şi accesul la baza
de date.
15. Enumeraţi tipurile de instrumente CASE după metodologia pe care o încorporează

pentru
realizarea sistemelor.
Răspuns:
instrumente CASE bazate pe metodologia structurat ă;
instrumente hibride, ce conţin elemente specifice orient ării-obiect, dar care nu
permit realizarea sistemelor orientate-obiect;
instrumente pur orientate-obiect.
16. Enumeraţi componentele produsului Westmount I-CASE Yourdon.

Nicolae Morariu
Răspuns:
Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon.
Repository este implementat cu ajutorul unui SGBD relaţional: Informix, Ingres sau
Oracle.
Analyst, este componenta ce oferă suport pentru analiza structurată şi anume: editoare
pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structură a
datelor editoarele matriciale pentru matricea listei de evenimente.
Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de
ansamblu). Designer este componenta ce oferă suport pentru proiectarea de detaliu a
sistemului informatic.
Proiectarea de detaliu a aplicaţiei este strâns legată de proiectarea bazei de date. Pentru
modelarea datelor se utilizează diagrama entitate asociere.
Programmer este mediul de programare care oferă suport pentru generarea codului
sursă, compilare, lansare în execuţie şi testarea aplicaţiei. Generatorul de cod generează
codul DDL (în SQL) ce defineşte structura fizică a bazei de date şi codul aplicaţiei în
limbajul C îmbogăţit cu instrucţiuni SQL pornind de la specificaţiile din schemele de
structură.
Docwriter este componenta care permite generarea documentaţiei pentru fiecare etapă de
realizare a sistemului.
17. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de viaţă
al
sistemelor, pot fi grupate în instrumente:
Răspuns:
- Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor;
- Lower CASE orientat-obiect pentru generarea codului-surs ă al aplica ţiilor;
- I-CASE orientat-obiect care acoperă întregul ciclu de via ţă.

BIBLIOGRAFIE
[1] Oprea D. – Analiza şi proiectarea sistemelor informaţionale economice, Ed.

POLIROM, Iaşi, 1999
[2] Chindea M. E. – Proiectarea sistemelor informatice economice, Bucureşti, 1999
[3] Chen, P.P. – Entity-Relationship Approach to Systems Analysis and Design,
Amsterdam, North Holland, 1980
[4] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureşti
2000
[5] Vasilescu P., Dunca V. – Proiectarea sistemelor informatice, Ed. Tehnică,
Bucureşti, 1979
[6] Popescu I. – Baze de date relaţionale: proiectare şi implementare, Ed. Universităţii
din Bucureşti, Bucureşti, 1996
[7] Balan D., Balan G. – Sistemul informaţional în gestionarea întreprinderilor, Ed.
Junimea, Iaşi, 1998
[8] Roger J. - Utilizare ACCESS 95, Ed. Teora, Bucureşti, 1995
[9] Udrică M. – Modelarea orientată obiect, Ed. Cison, Bucureşti, 2000
[10] Brânzei R. – Sisteme informatice, Ed. Universităţii “Al. I. Cuza”, Iaşi, 1995
[11] Thomas Connolly, Carolyn Begg, Anne Strachan – Database Systems – A
Practical Approach to Design, Implementation and Management Second Edition
(trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Buc. 2001)
[12] C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson
Education, Inc. Adison Wesley Higher Education, 2004.
[13] Robert Dollinger-Baze de date şi gestiunea tranzacţiilor, ClujNapoca, 1998
[14] lector univ. Nicolae Morariu, lector univ. Valeriu Lupu, ing.ec. Ovidiu Hurjui, Baze
de date, ISBN 973-8293-83-9, Editura Univ. “Ştefan cel Mare” Suceava,117 p, Suceava,
2003.
[15] Nicolae Morariu, ”Baze de date. Îndrumar de laborator”, ISBN 973-666-159-8,
Editura Univ. “Ştefan cel Mare” Suceava, 88 p, Suceava, 2005.
[16] Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn
Maslen, Published by Oracle Corporation UK Ltd. 1992.

Proiectarea Sistemelor Informatice

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proiectarea Sistemelor Informatice

Încărcat de

Drepturi de autor:

Formate disponibile

Nicolae Morariu

Lect. univ. dr.Nicolae Morariu

DISCIPLINĂ DE SPECIALITATE LA SPECIALIZAREA

CONTABILITATE ŞI INFORMATICĂ DE GESTIUNE

Contabilitate şi informatică de gestiune 1

1.1. Sistem, Sistem informaţional, Sistem informatic……………………………………. 3

2.1. Identificarea, selecţia, iniţierea şi planificarea proiectelor..…………………………. 18

3.1. Studiul sistemului informaţional existent………………...……………………….…. 23

Contabilitate şi informatică de gestiune 2

3.4. Modelarea conceptuală a datelor (diagramele entitate – relaţie, DER)........................ 35

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

5.1. Proiectarea fizică a bazelor de date şi a fişierelor..................................................................... 66

Contabilitate şi informatică de gestiune 3

CAPITOLUL 1. SISTEME INFORMATICE

1.1. Sistem, Sistem informaţional, Sistem informatic

Contabilitate şi informatică de gestiune 4

Sistem informatizat Procesor de informaţii Informaţie Reguli

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

Subsistem 1 Subsistem 2 Subsistem n

Aplicatia 2.1 Aplicatia 2.k

Program Program 2.k.s

Contabilitate şi informatică de gestiune 5

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

1.1.1. Componentele sistemului informatic

Contabilitate şi informatică de gestiune 6

Cadrul organizatoric este cel specificat în regulamentul de organizare şi funcţionare

1.1.2. Clasificarea sistemelor informatice

Contabilitate şi informatică de gestiune 7

pentru conducerea activităţii la nivelul unităţilor economice

Contabilitate şi informatică de gestiune 8

1.1.3. Obiectivele sistemelor informatice

1.1.4. Ciclul de viaţă a unui sistem informatic

Contabilitate şi informatică de gestiune 9

4. Integrarea şi testarea sistemului – integrarea şi testarea programelor şi

Contabilitate şi informatică de gestiune 10

1.1.5. Conţinutul bazei informaţionale a unei întreprinderi

1.1.6. Ciclul prelucrării datelor pentru sistemul informatic

Contabilitate şi informatică de gestiune 11

Pregătirea datelor este o activitate realizată în toate tipurile de sisteme

Fig. 1.4 Ciclul prelucrării datelor [1]

Prelucrarea datelor, poate să includă activităţi, cum sunt [1]:

Contabilitate şi informatică de gestiune 12

1.1.7. Sistemele informatice de gestiune

Fig. 1.5. Sistem informatic de gestiune integrat al contabilităţii [4]

Sistemul informatic de gestiune reuneşte subsisteme informatice specializate pe

1.2. Metodologii de realizare a sistemelor informatice

Contabilitate şi informatică de gestiune 13

1.2.1. Conţinutul metodologiilor de realizare a sistemelor informatice

1.2.2. Metode şi tehnici de realizare a sistemelor informatice

Contabilitate şi informatică de gestiune 14

diferitelor probleme ce apar în procesul de proiectare. Prin aceste tehnici se îmbină

Contabilitate şi informatică de gestiune 15

1.3. INSTRUMENTE CASE

Contabilitate şi informatică de gestiune 16

Majoritatea produselor soft au fost construite în mod artizanal, fără posibilitatea

Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de

Contabilitate şi informatică de gestiune 17

1.3.1. Funcţiile CASE

1.3.2. Trăsături definitorii ale CASE-ului

Contabilitate şi informatică de gestiune 18

1.3.3. Exemple de instrumente CASE (Conferinţa Naţională de Învăţământ Virtual,

Contabilitate şi informatică de gestiune 19

Contabilitate şi informatică de gestiune 20

Contabilitate şi informatică de gestiune 21