Sunteți pe pagina 1din 114

Adina Crean

Proiectarea sistemelor
informatice de gestiune
- suport de curs -

EDITURA UNIVERSITII NICOLAE TITULESCU


BUCURETI

2014

Acest material este destinat uzului studenilor, forma de nvmnt la distan.


Coninutul cursului este proprietatea intelectual a autorului /autorilor; designul, machetarea
i transpunerea n format electronic aparin Departamentului de nvmnt la Distan al
Universitii Nicolae Titulescu din Bucureti.
Acest curs este destinat uzului individual. Este interzis multiplicarea, copierea sau
difuzarea coninutului sub orice form.
Acest manual a fost actualizat i aprobat n sedinta Departamentului de Administrarea
Afacerilor si Marketing din data de 15 septembrie 2014.

UNIVERSITATEA NICOLAE TITULESCU DIN BUCURETI


DEPARTAMENTUL PENTRU NVMNTUL LA DISTAN

Adina Crean

Proiectarea sistemelor informatice de


gestiune

Editura Universitii Nicolae Titulescu


Calea Vcreti, nr. 185, sector 4, Bucureti
Tel./fax: 0213309032/0213308606
Email: editura@univnt.ro

ISBN: 978-606-751-046-1

Introducere
Suportul de curs reprezint o sintez a coninutului disciplinei Sisteme informatice de
gestiune. El este destinat studenilor de la forma de nvmnt la distan (ID) i constituie
materialul bibliografic minim necesar pentru parcurgerea, nsuirea i evaluarea disciplinei
respective.
Suportul de curs este structurat conform standardelor i procedurilor de uz larg n
nvmntul universitar naional i internaional, care se adreseaz nvrii individuale, pe baze
interactive. Parcurgerea suportului de curs, pe baza prezentelor instruciuni, asigur reinerea
informaiilor de baz, nelegerea fenomenelor fundamentale i aplicarea cunotinelor dobndite la
rezolvarea unor probleme specializate.
Suportul de curs este structurat pe trei module iar modulele sunt structurate, la rndul lor, pe
uniti de nvare. Modulul reprezint o categorie de probleme distincte din materia disciplinei, care
formeaz un tot unitar din punct de vedere al specificului cunotinelor, al nsuirii unui anumit
aspect al fenomenologiei disciplinei precum i din perspectiva timpului necesar parcurgerii i
nsuirii fondului informaional respectiv. n acest sens, un modul conine una sau mai multe uniti
de nvare. Unitatea de nvare reprezint o parte omogen din componena modulului,
caracterizat de un volum strict limitat de cunotine, care pot s fie parcurse i nsuite printr-un
efort continuu de concentrare intelectual, care se refer la coninutul de idei al unitii de nvare.
Fiecare unitate de nvare are o structur proiectat din perspectiva exigenelor autoinstruirii, astfel
c folosirea suportului de curs se face pe baza unui program de autoinstruire.
Recomandm astfel, cteva regului de baz n procedura de realizare a programului de
autoinstruire pe baza acestui suport de curs:
1. Unitile de nvare se parcurg n ordinea n care sunt prezentate, chiar n cazul n care
studentul apreciaz c ar putea sri direct la o alt unitate de nvare (de exemplu n cazul n care
studentul se afl la a doua facultate sau n alte situaii echivalente). Criteriile i modalitatea de
nlnuire a unitilor de nvare sunt prezentate la fiecare unitate de nvare i ele trebuie
respectate ntocmai, sub sanciunea nerealizrii la parametri maximali a programului de autoinstruire;
2. Fiecare unitate de nvare conine teste destinate autoevalurii gradului i corectitudinii
nsuirii cunotinelor specifice unitii de nvare, nelegerii fenomenelor i proceselor descrise sau
prezentate n unitatea de nvare;
Fiecare test al unitii de nvare este prevzut cu un sistem de notare (puncte) care nsumeaz
un maximum de 100 puncte;
3. Ordinea logic a parcurgerii unitii de nvare este urmtoarea:
a) se citete scopul i obiectivele unitii de nvare;
b) se citesc termenii de referin (cuvintele-cheie);
c) se parcurge coninutul de idei al unitii de nvare;
d) se parcurge bibliografia recomandat;
e) se rspunde la ntrebrile de autocontrol, revznd, dac este necesar, coninutul de idei al
unitii de nvare;
f) se elaboreaz, pe o pagin, cte un eseu pentru fiecare dintre temele de reflecie propuse la
unitatea de nvare;
g) se efectueaz testele de autoevaluare dup procedura descris;
h) se rezolv exerciiile, problemele sau studiile de caz propuse pentru laboratorul sau
lucrrile practice propuse n unitatea de nvare.
Pentru creterea eficienei utilizrii suportului de curs i fixarea temeinic a cunotinelor
dobndite, fiecare unitate de invatare se ncheie cu: ntrebri de autocontrol, teme de reflecie, teme
pentru studii de caz i teste de autoevaluare.

Obiectivele cursului
Obiectul suportului de curs const n studiul conceptelor i instrumentelor specifice
proiectarii sistemelor informatice.
Obiectivele principale ale suportului de curs sunt:
nsuirea temeinic a noiunilor fundamentale privind proiectarea sistemelor
informatice;
formarea deprinderilor de a utiliza noiunile i cunotinele teoretice la
aplicarea practica pentru diferitele domenii in care este necesara proiectarea
unui sistem informatic;
dobndirea unei viziuni de ansamblu asupra teoriei i practicii sistemelor
informatice de gestiune.
Suportul de curs este structurat pe trei module, fiecare modul coninnd, n funcie de
problematica abordat, unitati de invatare specifice.

Competene conferite
Dup parcurgerea acestui curs, studentul va fi capabil s:
Cunoasca i sa neleaga din punct de vedere metodologic procesul de
proiectare i dezvoltare a unui sistem informatic de gestiune.
neleaga principalele aspecte legate de realizarea, exploatarea i mentenana
unui asemenea sistem.
Cunoasca diferitele metodologii de proiectare i dezvoltare a unui sistem
informatic de gestiune.
neleaga procesele care se deruleaz ntr-o banc sau ntr-o firm din
perspective analizrii i automatizrii acestora cu ajutorul tehnologiei
informaionale.
neleaga impactul i a beneficiile aduse de implementarea i utilizarea unui
sistem informatic.

Resurse i mijloace de lucru


Pentru parcurgerea acestui curs va fi nevoie de utilizarea pachetului software integrat
MICROSOFT OFFICE 2010.

Structura cursului
Suportul de curs este structurat pe patru module astfel:
Modulul I este un modul de prezentare a problematicii sistemelor informatice,
6

coninnd unitatile de invatare:


Unitatea 1. Problematica sistemelor informatice;
Unitatea 2. Dezvoltarea sistemelor informatice in afaceri.
Modulul II se refera la notiunile privind metodele de proiectare a sistemelor
informatice in afaceri, coninnd unitatile de invatare:
Unitatea 3. Metode de proiectare a sistemelor informatice in afaceri;
Unitatea 4. Metode sistemice de proiectare.
Modulul III se refera la notiunile privind Modelul conceptual al datelor (MCD),
Modelul logic al datelor (MLD), Modelul fizic al datelor (MFD), coninnd capitolele:
Unitatea 5. Modelul conceptual al datelor (MCD), Modelul E-A;
Unitatea 6. Asocieri si tipuri de asocieri. Diagrama E-A;
Unitatea 7. Restrictii de integritate ale modelului E-A;
Unitatea 8. Modelul logic al datelor (MLD), Modelul fizic al datelor (MFD).
Unitatea 9. Modelul entitate-asociere extins (EA-E).
Modulul IV contine studii de caz referitoare la proiectarea sistemelor informatice de
gestiune utilizand modelul E-A:
Unitatea 10. Studiul de caz - proiectarea unui sistem informatic pentru
monitorizarea consumului de materii prime
Unitatea 11. Studiul de caz - analiza si proiectarea unui sistem informatic de
gestiune a comenzilor pentru un magazin virtual

Discipline deservite
Pe baza cunotinelor dobndite n cadrul disciplinei curente studenii vor fi capabili s
urmeze cursurile de Sisteme informatice de gestiune, Sisteme informatice in
marketing, Comer electronic.

Durata medie de studiu individual


Timpul mediu necesar parcurgerii unei Uniti de nvare este 2-3 ore.

Evaluarea studenilor
Nota finala la disciplina Sisteme informatice de gestiune va fi stabilit prin :
- evaluarea final (examen scris de tip gril) cu ponderea de 70%;
- evaluri pe parcurs (teme de control n cadrul activitilor asistate) cu
ponderea de 30%.

Cuprins
Introducere____________________________________________________________________ 5
Obiectivele cursului _____________________________________________________________ 6
Competene conferite ___________________________________________________________ 6
Resurse i mijloace de lucru ______________________________________________________ 6
Structura cursului _______________________________________________________________ 6
Discipline deservite _____________________________________________________________ 7
Durata medie de studiu individual _________________________________________________ 7
Evaluarea studenilor____________________________________________________________ 7

UNITATEA DE NVARE 1. PROBLEMATICA SISTEMELOR INFORMATICE _____________ 12


1.1. Obiective _________________________________________________________________ 12
1.2. Competenele unitii de nvare _____________________________________________ 12
1.3. Noiunea de sistem ________________________________________________________ 13
1.4. Componentele sistemului informatic __________________________________________ 14
1.5. Clasificarea sistemelor informatice ____________________________________________ 15
1.6. Conceptul de sistem informaional ____________________________________________ 16
1.7. Rezumat _________________________________________________________________ 19
1.8. Test de autoevaluare a cunotinelor __________________________________________ 19
1.9. Tem de control ___________________________________________________________ 21
1.10. Bibliografie ______________________________________________________________ 21

UNITATEA DE NVARE 2. DEZVOLTAREA SISTEMELOR INFORMATICE ______________ 22


2.1. Obiective _________________________________________________________________ 22
2.2. Competenele unitii de nvare _____________________________________________ 22
2.3. Obiectivul principal al sistemelor informatice ___________________________________ 22
2.4. Ciclul de via a unui sistem informatic ________________________________________ 23
2.5. Tipuri de participani n dezvoltarea sistemelor informatice________________________ 27
2.6. Rezumat _________________________________________________________________ 29
2.7. Test de autoevaluare a cunotinelor __________________________________________ 29
2.8. Test de evaluare a cunotinelor ______________________________________________ 31
2.9. Tem de control ___________________________________________________________ 31
2.10. Bibliografie ______________________________________________________________ 31

UNITATEA DE NVARE 3. METODE DE PROIECTARE A SISTEMELOR INFORMATICE ____ 32


3.1. Obiective _________________________________________________________________ 32
3.2. Competenele unitii de nvare _____________________________________________ 32
3.3. Evolutia metodelor de proiectare _____________________________________________ 32

3.4. Strategii de abordare a proiectrii sistemelor informatice __________________________ 36


3.5. Metodologia elaborrii sistemelor informatice __________________________________ 38
3.6. Rezumat _________________________________________________________________ 39
3.7. Test de autoevaluare a cunotinelor __________________________________________ 40
3.8. Test de evaluare a cunotinelor ______________________________________________ 41
3.9. Bibliografie _______________________________________________________________ 42

UNITATEA DE NVARE 4. METODE SISTEMICE DE PROIECTARE ____________________ 43


4.1. Obiective _________________________________________________________________ 43
4.2. Competenele unitii de nvare _____________________________________________ 43
4.3. Prezentarea metodei MERISE _________________________________________________ 43
4.4. Ciclurile de baz ale proiectrii unui sistem informatic ____________________________ 45
4.5. Rezumat _________________________________________________________________ 50
4.6. Test de autoevaluare a cunotinelor __________________________________________ 50
4.7. Test de evaluare a cunotinelor ______________________________________________ 52
4.8. Bibliografie _______________________________________________________________ 52

UNITATEA DE NVARE 5. MODELUL CONCEPTUAL AL DATELOR. MODELUL ENTITATEASOCIERE (E-A) ____________________________________________________________ 53


5.1. Obiective _________________________________________________________________ 53
5.2. Competenele unitii de nvare _____________________________________________ 53
5.3. Entiti si tipuri de entiti ___________________________________________________ 53
5.4 Atributele unei entiti ______________________________________________________ 56
5.5. Rezumat _________________________________________________________________ 60
5.6. Test de autoevaluare a cunotinelor __________________________________________ 61
5.7. Test de evaluare a cunotinelor ______________________________________________ 62
5.8. Bibliografie _______________________________________________________________ 62

UNITATEA DE NVARE 6. ASOCIERI SI TIPURI DE ASOCIERI. DIAGRAMA ENTITATEASOCIERE (E-A) ____________________________________________________________ 63


6.1. Obiective _________________________________________________________________ 63
6.2. Competenele unitii de nvare _____________________________________________ 63
6.3. Tipuri de asocieri ___________________________________________________________ 63
6.4 Cardinalitatea asocierii ______________________________________________________ 65
6.5 Reguli de modelare _________________________________________________________ 68
6.6 Rezumat __________________________________________________________________ 70
6.7 Test de autoevaluare a cunotinelor ___________________________________________ 71
6.8 Test de evaluare a cunotinelor _______________________________________________ 72
6.9 Bibliografie ________________________________________________________________ 72

UNITATEA DE NVARE 7. RESTRICII DE INTEGRITATE ALE MODELULUI ENTITATEASOCIERE ________________________________________________________________ 74


7.1. Obiective _________________________________________________________________ 74
7.2. Competenele unitii de nvare _____________________________________________ 74
7.3. Stabilirea restriciilor de integritate (RI) ________________________________________ 74
7.4 Rezumat __________________________________________________________________ 79
7.5. Test de autoevaluare a cunotinelor __________________________________________ 80
7.6. Test de evaluare a cunotinelor ______________________________________________ 81
7.7 Tema de control ____________________________________________________________ 81
7.8. Bibliografie _______________________________________________________________ 81

UNITATEA DE NVARE 8. MODELUL RELAIONAL AL DATELOR (MODELUL LOGIC AL


DATELOR) ________________________________________________________________ 83
8.1. Obiective _________________________________________________________________ 83
8.2. Competenele unitii de nvare _____________________________________________ 83
8.3. Conceptele de baz ale modelului logic al datelor (MLD) ___________________________ 83
8.4 Reguli de conversie de la MCD la MLD __________________________________________ 85
8.5 Modelul fizic al datelor (MFD) _________________________________________________ 87
8.6 Rezumat __________________________________________________________________ 88
8.7. Test de autoevaluare a cunotinelor __________________________________________ 89
8.8. Bibliografie _______________________________________________________________ 90

UNITATEA DE NVARE 9. MODELUL ENTITATE-ASOCIERE EXTINS __________________ 91


9.1. Obiective _________________________________________________________________ 91
9.2. Competenele unitii de nvare _____________________________________________ 91
9.3. Generalizarea i specializarea ________________________________________________ 91
9.4. Reprezentarea timpului _____________________________________________________ 95
9.5. Rezumat _________________________________________________________________ 97
9.6. Test de autoevaluare a cunotinelor __________________________________________ 97
9.7. Test de evaluare a cunotinelor ______________________________________________ 98
9.8. Bibliografie _______________________________________________________________ 98

UNITATEA DE NVARE 10. STUDIU DE CAZ PROIECTAREA UNUI SISTEM INFORMATIC


PENTRU MONITORIZAREA CONSUMULUI DE MATERII PRIME ______________________ 100
10.1. Obiective _______________________________________________________________ 100
10.2. Competenele unitii de nvare ___________________________________________ 100
10.3. Descrierea problemei de modelat si a cerintelor sistemului informatic _____________ 101
10.4. Identificarea entitatilor din textul problemei de modelat si a atributelor care descriu
entitatile respective ___________________________________________________________ 102
10.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri. Modelarea asocierilor _ 102

10

10.6. Realizarea modelului conceptual al datelor (MCD) ______________________________ 104


10.7. Realizarea modelului relaional al datelor (MRD) _______________________________ 105
10.8. Rezumat _______________________________________________________________ 106
10.9. Test de autoevaluare a cunotinelor ________________________________________ 106
10.10. Tema de control ________________________________________________________ 107
10.11. Bibliografie ____________________________________________________________ 107

UNITATEA DE NVARE 11. STUDIU DE CAZ ANALIZA SI PROIECTAREA UNUI SISTEM


INFORMATIC DE GESTIUNE A COMENZILOR PENTRU UN MAGAZIN VIRTUAL _________ 108
11.1. Obiective _______________________________________________________________ 108
11.2. Competenele unitii de nvare ___________________________________________ 108
11.3. Descrierea problemei de modelat si a cerintelor sistemului informatic _____________ 109
11.4. Identificarea entitatilor din textul problemei de modelat si a atributelor care descriu
entitatile respective ___________________________________________________________ 109
11.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri. Modelarea asocierilor _ 110
11.6. Realizarea modelului conceptual al datelor (MCD) ______________________________ 112
11.7. Realizarea modelului relaional al datelor (MRD) _______________________________ 112
11.8. Rezumat _______________________________________________________________ 113
11.9. Test de autoevaluare a cunotinelor ________________________________________ 113
11.10. Tema de control ________________________________________________________ 114
11.11. Bibliografie ____________________________________________________________ 114

11

UNITATEA DE NVARE 1. PROBLEMATICA SISTEMELOR


INFORMATICE
Cuprins
1.1. Obiective
1.2. Competenele unitii de nvare
1.3. Noiunea de sistem
1.4. Componentele sistemului informatic
1.5. Clasificarea sistemelor informatice
1.6. Conceptul de sistem informaional
1.7. Rezumat
1.8. Test de autoevaluare a cunotinelor
1.9. Tem de control
1.10 Bibliografie

1.1. Obiective
Obiectivele primei unitati de nvare sunt:
nsuirea noiunii de sistem
nsuirea criteriilor de clasificare a sistemelor
nelegerea deosebirilor dintre sistemul informaional si sistemul informatic
nsuirea caracteristicilor unui sistem informatic

1.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Ce este un sistem?
Care sunt componentele sistemului informatic?
Cum se clasifica sistemele informatice?
Care este deosebirea dintre un sistem informational si un sistem informatic?

Durata de parcurgere a primei uniti de nvare este de 2 ore.

12

1.3. Noiunea de sistem


Un sistem reprezint un ansamblu de elemente interdependente care se
comporta si actioneaz ca un tot organizat n vederea realizarii unui anumit scop.
00:05

Din cele mai vechi timpuri termenul sistem a cunoscut numeroase definiii.
Ludwig von Bertalanffy 1 a fost primul teoretician care a articulat principiile
teoriei generale a sistemelor n 1950. Conform definiiei sale, un sistem este un set de
elemente care se afl n relaii de interaciune
J. de Rosnay2, propune o alt definitie pentru notiunea de sistem: Ansamblul
de elemente n interaciune dinamic, organizat n funcie de un scop.
E. Morin 3 propune i el o definiie: Un sistem este o unitate global
organizat, de interrelaii ntre elemente, aciuni sau indivizi.
Furnizati mai multe definiii pentru noiunea de sistem.
....................................................................................................................................
....................................................................................................................................
...................................................................................................................................
Avnd in vedere complexitatea deosebit a celor mai multe sisteme existente
n natur, economie etc., studierea sistemelor se face ntr-o manier aparte numit
abordare sistemic. Spre deosebire de abordare sistemic, abordarea cartezian const
n a repera i a izola fiecare subproblem pentru o prelucrare ulterioar. Prin aceasta
nu se va putea rezolva ns ansamblul problemei.
Abordarea sistemic propune o viziune unic i global a problemei de
rezolvat. Conform abordrii sistemice, J. De Rosnay propune trei activiti importante
[Amza, 2008]:
Analiza sistemului;
Modelarea sistemului;
Simularea.
Analiza sistemelor presupune parcurgerea urmtoarelor etape:
1) Formularea problemei. Este deosebit de important ca analistul s examineze
critic formularea problemei de ctre utilizator. Orice eroare minor n
formularea problemei, sau orice nelegere eronat, poate genera mari
inconveniente prin amplificarea ei cu fiecare etap parcurs.
2) Formularea clar si precis a obiectivelor ce trebuiesc realizate.
3) Analiza cerinelor utilizatorului avand in vedere identificarea i evaluarea
necesitilor lui reale.
4) Precizarea criteriilor de msurare a eficienei sistemului.
5) Analiza funcional ce se concretizeaz ntr-o list amnunit a funciunilor i
aprecierilor care trebuie ndeplinite.
6) Identificarea restriciilor i evaluarea efectului lor asupra eficienei sistemului.
7) Identificarea soluiilor posibile care satisfac restriciile impuse.
8) Evaluarea soluiilor si alegerea celei mai bune variante.

L. von Bertalanffy, Theories des systemes, Ed. Dunod, 1973


J de Rosnay, Le Macroscope vers une vision globale, Paris, Seuil, 1975
3
E. Morin, La Metode, Paris, 1991
2

13

Modelarea sistemului const n construirea unui model plecnd de la datele


furnizate de analiza sistemului. Dupa construirea modelului, urmeaz implementarea,
ntr-un limbaj de programare, a diferitelor interaciuni dintre elementele sistemului.
Simularea presupune analiza comportamentului sistemului.
Argumentai importana activitii de analiz a sistemului:
...........................................................................................................................
...........................................................................................................................
..........................................................................................................................

1.4. Componentele sistemului informatic


Un sistem informatic este compus din [Chindea, 1999]:
baza informaional;
baza tehnic;
sistemul de programe;
baza tiinific i metodologic;
factorul uman (resursele umane);
cadrul organizatoric.
Baza informaional cuprinde:
datele supuse prelucrrii;
fluxurile informaionale;
sistemele i nomenclatoarele de coduri.
Baza tehnic este constituit din totalitatea mijloacelor tehnice de culegere,
transmitere, stocare i prelucrare a datelor, locul central revenind calculatoarelor
electronice.

00:30

Sistemul de programe cuprinde totalitatea programelor utilizate pentru funcionarea


sistemului informatic n concordan cu funciunile i obiectivele stabilite. Sunt avute
n vedere att programele de baz (software de baz) ct i programele aplicative
(software de aplicaie).
Baza tiinific i metodologic este constituit din:
algoritmi;
formule;
modele;
tehnici de realizare a sistemelor informatice.
Resursele umane constau in:
personalul de specialitate: analiti, programatori, ingineri de sistem,
analiti-programatori ajutori, operatori etc.;
beneficiarii sistemului.
Cadrul organizatoric este cel specificat n regulamentul de organizare i funcionare
(ROF) al unitii n care va fi utilizat sistemul informatic.

14

S ne reamintim...
Baza tehnic este constituit din totalitatea mijloacelor tehnice de culegere,
transmitere, stocare i prelucrare a datelor, locul central revenind calculatoarelor
electronice.

1.5. Clasificarea sistemelor informatice


Sistemele informatice se clasific dup mai multe criterii [Oprea, 1999]:
1) n funcie de domeniul de utilizare, sistemele informatice pot fi:

pentru conducerea activitilor economico-sociale;

pentru conducerea proceselor tehnologice;

pentru cercetare tiinific i proiectare tehnologic;

pentru activiti speciale.

2) n funcie de nivelul ierarhic ocupat de sistemul economic n structura


organizatoric a societii:

00:45

pentru conducerea activitii la nivelul unitilor economice;

pentru conducerea activitii la nivelul organizaiilor economico-sociale cu


structur de grup;

sisteme informatice teritoriale;

pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei


naionale;

sisteme informatice funcionale generale.

3) n funcie de elementul supus analizei:

sisteme informatice orientate spre funcii;

sisteme informatice orientate spre proces;

sisteme informatice orientate spre date;

sisteme informatice orientate spre obiecte;

sisteme informatice orientate spre cunotine.

4) Dup modul de organizare a datelor:

sisteme bazate pe fiiere;

sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale,


orientate-obiect;

sisteme mixte.

5) Dup metoda folosit n analiza i proiectarea sistemelor:

sisteme dezvoltate dup metoda sistemelor;

sisteme dezvoltate dup metoda clasic a ciclului de via;

sisteme dezvoltate dup metoda structurat;


15

01:00

sisteme dezvoltate dup metoda orientat-obiect;

sisteme dezvoltate dup metoda rapid;

sisteme dezvoltate dup metoda echipelor mixte;

sisteme dezvoltate dup metoda prototipurilor.

6) Dup gradul de centralizare:

sisteme centralizate;

sisteme descentralizate.

7) Dup gradul de dispersie a resurselor sistemului informatic:

sisteme informatice locale (bazate pe reea local, staii de lucru);

sisteme informatice distribuite (date distribuite).

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


informatice:

sisteme informatice dezvoltate pe baza analizei i proiectrii clasice;

sisteme informatice analizate cu instrumente automate i proiectate clasic;

sisteme informatice bazate pe instrumente diverse de automatizare a analizei i


proiectrii;

sisteme informatice dezvoltate cu instrumente de tip CASE 4.

S ne reamintim...
n funcie de modul de organizare a datelor, sistemele informatice se pot clasifica
astfel:
sisteme bazate pe fiiere; sisteme bazate pe tehnica bazelor de date: ierarhice, reea,
relaionale, orientate-obiect; sisteme mixte.

n funcie de elementul supus analizei, sistemele informatice se pot clasifica astfel:


...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................

1.6. Conceptul de sistem informaional


Conform teoriei sistemelor orice organism economic este un sistem.
Prin organizaie inelegem o intreprindere, instituie, societate comercial.
Caracteristicile unui organism economic privit ca un sistem sunt urmatoarele [Stanciu,
1999]:

Orice organism economic interactioneaz cu mediul exterior prin intermediul

Computer Aided Systems Engineering

16

diferitelor fluxuri de intrare-iesire;

01:15

Organismele economice reprezint conglomerate complexe de departamente si


filiale care se comport la rndul lor ca niste subsisteme;

Totalitatea elementelor constitutive ale unui organism economic actioneaz n


mod constant si unitar n vederea ndeplinirii obiectivelor organizationale.

In orice organizatie se disting trei componente:

Sistemul de conducere sau de decizie (S.D)

Sistemul informational (S.I)

Sistemul condus sau operational (S.O)

Din perspectiva sistemic, structura unei organizatii este reprezentat astfel:


FI = flux de informatii
FD = flux de date
d = date
I = informatii
D = decizii

Fig. 1.1 - Structura unei organizatii


Sistemul informatic face legatura intre sistemul condus (SO) si sistemul de
conducere (SD), fiind subordonat acestuia. Deci, sistemul informatic este un ansamblu
structurat de elemente intercorelate funcional pentru automatizarea procesului de
obinere a informaiilor i pentru fundamentarea deciziilor.
Pentru ca o organizatie s-si satisfac necesarul de informatie, are nevoie de un
sistem informaional. Sistemul informaional este un ansamblu om-masina care in baza
unor cunostinte privitoare la domeniul de activitate al unei organizatii, achizitioneaza,
stocheaza, proceseaza si prezinta informatii la nivel intra si extra organizational.
Sistemul informatic este inclus n sfera sistemului informaional, presupunnd partea
automatizat a acestuia.
Sintetizai caracteristicile sistemului informatic:
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
Sistemul informaional cuprinde ansamblul informaiilor interne i externe
utilizate n cadrul organizaiei, precum i datele care au stat la baza obinerii lor,
procedurile de obinere i de difuzare a informaiilor, precum i personalul implicat n
17

culegerea, transmiterea, stocarea i prelucrarea datelor.


Sistemul informaional are dou componente:

componenta pentru stocarea (memorarea informaiilor);

componenta pentru prelucrarea informaiilor.

Funciile unui sistem informaional sunt:

s colecteze informaii din sistemele operaional i decizional precum i


informaiile ce provin din mediul extern;

s memoreze aceste informaii precum i informaiile rezultate din


prelucrarea lor;

s asigure accesul la memorie n vederea comunicrii informaiilor stocate;

s prelucreze informaiile la cererea sistemelor operaional i decizional.

Funciile unui sistem informaional sunt urmatoarele:


...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
Sistemul operaional este compus din ansamblul procedurilor si persoanelor
care ndeplinesc sarcinile ce se desfoar ntr-o organizatie. n cadrul acestui sistem
are loc implementarea si ducerea la bun sfrsit a strategiilor organizatiei [Amza, 2008].
Sistemul informatic este inclus n cadrul sistemului informational i are ca
01:30

obiect de activitate, in general, procesul de culegere, verificare, transmitere, stocare i


prelucrare automat a datelor (datele sunt materia prim, iar informaiile sunt produsul
finit). Prin implementarea unor modele matematice i utilizarea tehnicii electronice de
calcul, sistemul informatic imprim valene sporite sistemului informational sub aspect
cantitativ i calitativ. Astfel, asistm la o cretere a capacitii de calcul sub aspectul
volumului datelor prelucrate i a operaiilor efectuate, nsoit de creterea exactitii
informatiilor, sporirea operativitii i complexitii situatiilor de informare - raportare.
Toate aceste aspecte determin o apropiere mai mare a decidentului de fenomenele i
procesele economice pe care acesta le are in atenie, cu multitudinea aspectelor
economice pozitive ce deriv din acestea.
In ceea ce priveste raportul dintre sistemul informatic i sistemul informational,
se poate aprecia c sistemul informatic tinde spre a egala sistemul informational, ns
acest lucru nu va fi posibil datorit limitelor sistemului informatic. Tot timpul n cadrul
sferei sistemului informational vor exista o serie de activiti ce nu vor putea fi
automatizate. Ins, dac acceptam includerea in sfera sistemului informatic a activitii
de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, putem
18

asista la automatizarea complet a procesului decizional i a reglrii automate a


procesului tehnologic. ntr-o astfel de situaie, sistemul informatic depete sfera
sistemului informational.
ntre sistemul informational si sistemul informatic exista urmatoarea legatura:
...........................................................................................................................................
...........................................................................................................................................
..........................................................................................................................................

1.7. Rezumat

01:50

Un sistem reprezinta un ansamblu de elemente interdependente care se comporta


si actioneaza ca un tot organizat n vederea realizarii unui anumit scop;
In orice organizatie, care si desfasoara activitatea n domeniul economic, se
disting trei componente: sistemul decizional, sistemul informational, sistemul
operational;
Sistemul informaional cuprinde ansamblul informaiilor interne i externe
utilizate n cadrul organizaiei, procedurile de obinere i de difuzare a
informaiilor precum i personalul implicat n culegerea, transmiterea, stocarea i
prelucrarea datelor;
Sistemul informatic este inclus in cadrul sistemului informational i are ca obiect
de activitate, in general, procesul de culegere, verificare, transmitere, stocare i
prelucrare automat a datelor. Sistemul informatic reprezinta partea automatizata
a sistemului informaional.

1.8. Test de autoevaluare a cunotinelor


(timp necesar: 20 min.)
1. Care definiie este corect:
a) Un sistem reprezint un ansamblu de elemente interdependente, care se
comporta si actioneaz ca un tot organizat n scopul atingerii unui anumit
obiectiv;
b) Un sistem reprezint un ansamblu de elemente care au rolul sa rezolve
activiti specifice.
2. Sistemul informaional cuprinde:
a) Ansamblul informaiilor interne i externe utilizate n cadrul organizatiei;
b) Procedurile i tehnicile de obinere i de difuzare a informaiilor;
c) Platforma necesar prelucrrii i disiprii informaiilor;
d) Personalul specializat n culegerea, transmiterea, stocarea i prelucrarea
datelor.
3. Un sistem informatic este:
a) un sistem destinat conducerii unei organizaii;
b) un sistem ce face legatura intre sistemul condus si sistemul de conducere al
19

unei organizaii;
c) un ansamblu structurat de elemente intercorelate funcional pentru
automatizarea procesului de obinere a informaiilor i pentru
fundamentarea deciziilor.
4. Identificai afirmaia fals:
a) Sistemul informaional este subordonat sistemului de conducere.
b) Sistemul informaional face legtura ntre sistemul condus i sistemul de
conducere.
c) Sistemul informatic este inclus n sistemul informaional.
d) Sistemul condus este subordonat sistemului informaional.
5. Identificai componentele principale ale unui sistem informatic:
a) Baza informaional;
b) Manager general;
c) Factorul uman (resursele umane);
d) Sistemul de programe.
6. Identificai etapele ce nu se regsesc printre cele propuse de J.Rosnay n
abordarea sistemic:
a) Analiza sistemului;
b) Modelarea sistemului;
c) Testarea sistemului.
7. Sistemele informatice economice pot fi mprite, dup modul de organizare a
datelor, n:
a) sisteme informatice distribuite;
b) sisteme bazate pe tehnica bazelor de date (ierarhice, reea, relaionale,
orientate-obiect);
c) sisteme bazate pe algoritmi fundamentali;
d) sisteme centralizate.
8. Sistemul informaional reprezint:
a) Un ansamblu de componente interdependente;
b) Un ansamblul de elemente implicate n procesul de colectare, transmisie,
prelucrare de informatii;
c) Un sistem decizional;
d) Un sistem operational.
9. Dup domeniul de utilizare, sistemele informatice se clasific n:
a) Sisteme informatice pentru conducerea activitilor economico-sociale;
b) Sisteme informatice pentru conducerea ramurilor, subramurilor
activitilor la nivelul economiei naionale;
c) Sisteme informatice i expert;
d) Sisteme informatice pentru activiti speciale.

10. Sistemul care se ocup cu implementarea si ducerea la bun sfrsit a strategiei


organizatiei, este:
a) Sistemul decizional;
b) Sistemul operational;
20

c) Sistemul informational;
d) Niciuna dintre variantele de mai sus.
Rspunsuri:
1) a.
2) a, b, d.
3) b, c
4) d
5) a, c, d
6) c
7) b
8) b
9) a, d
10) b

1.9. Tem de control


Identificai i alte criterii de clasificare a sistemelor informatice i alctuii un
scurt referat.

1.10. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft Access,
Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.
21

UNITATEA DE NVARE 2. DEZVOLTAREA SISTEMELOR


INFORMATICE
Cuprins
2.1. Obiective
2.2. Competenele unitii de nvare
2.3. Obiectivul principal al sistemelor informatice
2.4. Ciclul de via a unui sistem informatic
2.5. Tipuri de participani n dezvoltarea sistemelor informatice
2.6. Rezumat
2.7. Test de autoevaluare a cunotinelor
2.8. Test de evaluare a cunotinelor
2.9. Bibliografie

2.1. Obiective
Obiectivele acestei unitati de nvare sunt:
nelegerea obiectivului principal urmrit prin dezvoltarea si implementarea
unui sistem informatic;
nsuirea etapelor necesare dezvoltrii unui sistem informatic;
nelegerea importanei rolului pe care l are fiecare participant n dezvoltarea
unui sistem informatic.

2.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundeti la intrebarile:
Care este obiectivul principal urmarit prin introducerea unui SI?
Care sunt etapele dezvoltarii unui SI?
Ce rol are fiecare participant la dezvoltarea unui SI?
Durata de parcurgere a acestei uniti de nvare este de 3 ore.

2.3. Obiectivul principal al sistemelor informatice

00:00

Plecnd de la ideea c sistemul informatic (SI) este subordonat procesului


decizional, al crui rol este de a asigura funcionarea normal i optim a ntregii
activiti i de a reduce la minimum pierderile n caz de funcionare anormal, rezult
c obiectivul oricrui sistem informatic trebuie s fie subordonat obiectivului propriuzis al unitii economice.
n acest context, obiectivul principal urmrit prin introducerea unui sistem
informatic, l constituie asigurarea, n timp util, a tuturor informaiilor necesare n
procesul conducerii, n scopul fundamentrii i elaborrii deciziilor cu privire la
desfurarea ct mai eficient a ntregii activiti din unitatea economic.
22

S ne reamintim...
Obiectivul principal al SI:
- asigurarea, n timp util, a tuturor informaiilor necesare n procesul conducerii, n
scopul fundamentrii i elaborrii deciziilor cu privire la desfurarea ct mai
eficient a ntregii activiti din unitatea economic.

2.4. Ciclul de via a unui sistem informatic

00:20

Un sistem informatic are o existen limitat n timp, constituind ciclul su de


via, n cursul creia parcurge dou stadii: dezvoltarea i exploatarea curent.
Mutaiile din domeniul tehnologiei informaionale, precum i din domeniul
metodelor de abordare a sistemelor, s-au reflectat i n ciclul de via al sistemelor
informatice, 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 [Stanciu, 2000].
n literatura de specialitate sunt des folosite urmtoarele dou noiuni: ciclul
de dezvoltare a sistemului informatic i ciclul de via a sistemului informatic.
Ciclul de via a sistemului informatic (CVSI) se extinde pe intervalul de
timp cuprins ntre decizia de elaborare a sistemului informatic i decizia de
abandonare sau de nlocuire cu alt sistem informatic.
Ciclul de dezvoltare a sistemului informatic (CDSI) se extinde de la decizia
de elaborare a sistemului informatic i se ncheie dup momentul intrrii sistemului n
exploatare. Ciclul de dezvoltare a SI este inclus n ciclul de via al SI. Exist mai
multe metodologii de etapizare ale ciclului de dezvoltare, depinznd de paradigma
prin care vedem sistemul informaional i de modelul ales pentru CVSI.
Ciclul de dezvoltare a sistemelor informatice de gestiune (SIG) cuprinde, la
rndul su, trei etape: conceperea, construirea i introducerea n exploatare numit,
de asemenea, introducere n producie [Zaharie, 2002].

Fig. 2.1 Etapele ciclului de dezvoltare a SIG (Sursa: [Zaharie, 2002])


23

Enumerai etapele ciclului de dezvoltare a unui sistem informatic:


..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................

2.4.1. Conceperea

00:45

Conceperea pornete de la cerinele formulate de utilizator. Asfel, se pot


distinge dou categorii de cerine: cele care precizeaz prelucrrile sau serviciile pe
care sistemul urmeaz s le asigure, denumite funcionale, i cele privind
performanele i caracteristicile de exploatare, denumite nefuncionale sau calitative.
Pentru a putea realiza sistemul dorit, este necesar ca cel care-l dezvolt s
neleag aceste cerine i s evalueze posibilitatea de a le oferi un rspuns n limitele
materiale, financiare i, de timp, fixate de ctre utilizator. Acest aspect constituie
obiectul analizei. n cazul n care, sistemul este realizat chiar de ctre utilizator,
analiza este foarte scurt i relativ simpl. n celelalte cazuri, analiza presupune un
efort de informare i evaluare considerabil, avnd n vedere c cel care dezvolt
sistemul trebuie s cunoasc i s neleag cerinele formulate de utilizator.
Dup analiza cerinelor, urmeaz ca dezvoltatorul s propun o soluie
informatic ce va fi exploatabil pe o anumit platform, n spaiul unei anumite
arhitecturi aplicative. Acest aspect constituie obiectul proiectrii din care va rezulta
multitudinea de elemente necesare pentru realizarea efectiv a programelor ce
compun respectivul software de aplicaie. Proiectarea este cea care definete datele
ce vor fi memorate i structura bazei de date, n care vor fi acestea stocate, formatele
ecranelor de introducere a datelor i a rapoartelor ce vor fi distribuite utilizatorilor,
procedurile de prelucrare i operare, maniera de distribuire a datelor i prelucrrilor
etc. Rezultatele conceperii, formeaz specificaiile dup care se va construi sistemul
[Zaharie, 2002].

Argumentai importana etapei de concepere in dezvoltarea sistemelor


informatice:
..........................................................................................................................................
..........................................................................................................................................
.........................................................................................................................................
.........................................................................................................................................
2.4.2. Construirea
Construirea pornete de la specificaiile rezultate n urma conceperii i asigur
redactarea programelor de calculator pn la forma final, cea executabil. Paii
urmai n acest scop sunt: scrierea programelor ntr-un limbaj surs de un anumit
24

01:00

nivel, aducerea acestuia n form executabil prin compilare sau interpretare i


testarea funcionrii sale pe platforma de calcul. Disfuncionalitile i erorile
constatate sunt nlturate prin modificarea adecvat a programelor surs, dup care
noile programe sunt aduse din nou n forma executabil i verificate i acest ciclu se
repet pn cnd se ajunge la funcionarea corect dorit.
Orice sistem informatic de calitate, proiectat i implementat profesional,
trebuie s fie testat i validat nainte de a intra n faza de producie. Clientul trebuie s
fie sigur c sistemul a fost dezvoltat i integrat n conformitate cu specificaiile
proiectului. De asemenea clientul trebuie s se asigure c funcionalitatea proiectului
este corect i fr erori. Testarea sistemului presupune trei etape [Zaharie, 2002]:
testarea unitar
testare de integrare
testare de sistem
Testarea unitar verific funcionarea separat a fiecrei uniti de program.
Testarea de integrare vizeaz funcionarea unitilor de program n
interaciune.
Testarea de sistem verific funcionarea ansamblului, n calitate de software
aplicativ, coerent i unitar.
Identificarea sursei erorilor i disfuncionalitilor, precum i nlturarea lor
presupune revenirea la oricare dintre nivelele de proiectare, inclusiv la programele
surs.
Dup ce programele surs au fost redactate i testate se genereaz, prin
compilare i editare de legturi, formatul executabil final, livrabil, ce formeaz,
alturi de documentaia de utilizare i de exploatare a sistemului, rezultatele acestei
etape.
Argumentai importana etapei de construire in dezvoltarea sistemelor
informatice:
..........................................................................................................................................
..........................................................................................................................................
.........................................................................................................................................
.........................................................................................................................................
2.4.3. Introducerea n exploatare
Introducerea n exploatare asigur instalarea la utilizator a echipamentelor i a
reelelor de comunicaie (dac este cazul), ncrcarea software-ului de aplicaie n
structurile adecvate, crearea i ncrcarea iniial a bazei sau bazelor de date,
instruirea utilizatorilor, testarea sistemului n condiiile reale de utilizare i efectuarea
eventualelor corecii necesare, lansarea efectiv n funciune [Zaharie, 2002].
2.4.4. Mentenana sistemului
In termeni generali, mentenana reprezint totalitatea aciunilor efectuate
25

01:30

pentru meninerea/restabilirea strii de funcionare a produselor.


Mentenana poate fi caracterizat prin urmtoarele activiti:
Mentenan corectiv (neplanificat): diagnosticarea i corectarea erorilor;
Mentenan adaptiv: activitate care modific software-ul pentru a
interaciona corect cu un mediu n schimbare (hardware sau software);
Mentena perfectiv: activiti pentru adugarea de noi capabiliti,
modificarea funcionalitii existente i aducerea de mbuntiri generale;
Mentenan preventiv (planificat): activiti care pregtesc produsul
software pentru o mai bun mentenabilitate sau fiabilitate n viitor, sau pentru
a pune baza unor viitoare mbuntiri.
Pe parcursul ciclului de viaa a unui proiect, dup fazele de analiz de proiect
i dezvoltare, ntretinerea sistemului are un rol foarte important. Pe msur ce un
proiect devine tot mai mare i mai complex, crete cantitatea datelor gestionate i
infrastructura, necesitnd un suport tehnic elaborat pentru a ine n funciune i a
ntreine componentele software i hardware ale acestui sistem. In majoritatea
cazurilor un sistem informatic dezvoltat la cerere poate fi ntreinut doar de compania
care l-a proiectat i dezvoltat, deci este foarte important s ofere aceste servicii
compania care dezvolt un produs informatic. Astfel, n cursul exploatrii curente,
apar momente care solicit intervenii de meninere n funciune a sistemului.
Exist o mulime variat de motive pentru care apar defecte n dezvoltarea
produselor software:
Lipsa comunicrii sau comunicare slab n cadrul proiectului;
Constrngeri de timp i de buget, care duc la presiune i la apariia erorilor;
Cerine care nu au fost specificate suficient de clar;
Modificri n cerine si o slab documentare a lor;
Presupuneri;
Pregtire insuficient;
Erori de programare.
Rezolvarea acestora implic intervenii ce pot include una sau mai multe
dintre activitile derulate pentru creare: (re)definire de cerine, analiz, proiectare,
construcie, testare, introducere n exploatare, aplicate, evident, doar pentru anumite
poriuni din acesta.
Pentru c schimbrile sunt inevitabile, trebuie dezvoltate mecanisme pentru a
identifica, evalua, controla, efectua i raporta modificrile necesare. Aceste activiti
ncep odat cu proiectul i se ncheie doar cnd produsul este retras din funciune.
Mentenana unui sistem informatic se caracterizeaz prin urmtoarele activiti:
...................

..........................................................................................................................................
........................................................................................................................................

26

S ne reamintim...
Ciclul de dezvoltare a sistemelor informatice de gestiune (SIG) cuprinde trei etape:
conceperea;
construirea;
introducerea n exploatare.

2.5. Tipuri de participani n dezvoltarea sistemelor informatice

02:00

n dezvoltarea sistemelor informatice, au fost identificai trei tipuri de


participani generici [Zaharie 2002]:

utilizatorul;

dezvoltatorul sau furnizorul software-ului aplicativ;

administratorul sistemului.
Utilizatorul reprezint persoana, sau grupul de persoane, care folosete
sistemul pentru a ndeplini cerinele informaionale.
Interaciunile dintre utilizator i sistemul informatic sunt de trei tipuri:

intervenii asupra informaiilor stocate de sistem;

extragerea de informaii din sistem;

declanarea i/sau executarea de operaii comerciale.


Dezvoltatorul este termenul generic folosit pentru a desemna creatorul
software-ului aplicativ ce formeaz suportul sistemului informatic. n funcie de
poziia acestuia fa de organizaie, se disting:

outsourcing: dezvoltatorul este o societate comercial specializat;

insourcing: dezvoltatorul este reprezentat de unul sau mai muli angajai


ai departamentului de informatic al organizaiei;

selfsourcing: utilizatorul este i dezvoltatorul sistemului.


"Outsourcing" este un termen de origine anglo-saxon, deseori ntlnit n
limba romn ca "externalizare".
Externalizarea reprezint opiunea, deseori strategic, pe care o are o
companie de a-i transfera anumite procese, total sau partial, ctre furnizori de
servicii specializati - BPO (Business Process Outsourcing).
n procesul de externalizare se regsesc doi subieci de baz:

clientul reprezentat prin ntreprinderea beneficiar ce ncredineaz un


anumit serviciu, lucrare sau activitate ctre externalizare;

furnizorul reprezentat prin ntreprinderea care urmeaz s presteze


serviciul sau s efectueze lucrarea, activitatea.
Pentru a externaliza cu succes anumite procese catre un furnizor extern, este
necesar ca intre companie si furnizorul de servicii s existe un parteneriat consolidat
de incredere si responsabilitate asumat.
De exemplu, o agentie de transport aerian poate externaliza tot procesul de
eliberare bilete (ticketing) care va presupune si call-center pentru managementul
27

02:25

apelurilor clientilor dar si altele, cum ar fi: trimiterea acestor bilete catre clieni
(mailing) etc. Beneficiile pe care le poate obtine o companie in urma externalizrii
proceselor, ce reprezint doar suport pentru procesul principal de productie, se
concretizeaz n cresterea productivitii muncii si economii de resurse (timp si bani).
n procesul de dezvoltare a sistemelor informatice, externalizarea conceperii
de solutii software presupune [Zaharie 2002]:

Soluii software de uz general;

Soluii software pe msur.


n primul caz, avem de-a face cu un produs deja disponibil, destinat, de la bun
nceput cumprrii i utilizrii de ctre ct mai muli clieni. Acesta se adreseaz
domeniilor comune oricror afaceri, cum ar fi: calculul salariilor, urmrirea
stocurilor, contabilitatea financiar etc. Acestea sunt denumite generic pachete de
programe sau produse program de uz general.
Soluia software pe msur este conceput i construit conform nevoilor i
condiiilor specifice organizaiei. Are avantajul de a fi adaptat din start acesteia, dar
costurile i durata de obinere vor fi mai mari.
Insourcing-ul sau internalizarea are loc atunci cnd pentru realizarea unei
activiti se utilizeaz numai resurse interne din ntreprindere, fiind exclus
recurgerea la surse externe.
Dezvoltarea produsului software de ctre specialitii IT ai organizaiei, este
posibil cu condiia ca acetia s posede competena tehnic necesar i s existe
resurse suficiente (timp, oameni i echipamente).
Selfsourcing-ul prezint avantajul esenial de a avea aceleai persoane att n
calitatea de dezvoltator ct i n aceea de utilizator.
Utilizatorul trebuie s aib cunotine suficiente de informatic pentru a
concepe i construi sistemul cu o contribuie minim din specialisti IT. Referitor la
acetia, literatura de specialitate folosete termenul de "knowledge workers". Un
astfel de utilizator nu va dezvolta dect sisteme de mici dimensiuni, care rspund
numai lucrrilor i sarcinilor sale curente sau a celor cu care interacioneaz n mod
direct la locul de munc.
Administratorul sistemului desemneaz persoanele sau structurile care
asigur condiiile de funcionare curent a sistemului i gestioneaz msurile de
protecie i securitate a acestuia. n aceast postur se pot afla:

utilizatorul;

angajai din departamentul de TI al organizaiei;

societate specializat.
n dezvoltarea sistemelor informatice, au fost identificai trei tipuri de
participani:
...................

......................................................................................................................................

28

2.6. Rezumat

02:50

Obiectivul principal urmrit prin introducerea unui sistem informatic l


constituie asigurarea n timp util a tuturor informaiilor necesare n procesul
conducerii, n scopul fundamentrii i elaborrii operative a deciziilor cu
privire la desfurarea ct mai eficient a ntregii activiti din unitatea
economic;
Etapele ciclului de dezvoltare a sistemelor informatice de gestiune sunt:
conceperea, construirea i introducerea n exploatare;
n dezvoltarea sistemelor informatice, au fost identificai trei tipuri de
participani: utilizatorul, dezvoltatorul sau furnizorul software-ului aplicativ si
administratorul sistemului;
n funcie de poziia fa de organizaie, dezvoltatorul software-ului aplicativ
poate fi: de tip outsourcing, de tip insourcing, de tip selfsourcing.

2.7. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Obiectivul principal urmrit prin introducerea unui sistem informatic l
constituie:
e) asigurarea, n timp util, a informaiilor necesare n procesul conducerii,
n scopul fundamentrii i elaborrii deciziilor;
f) creterea productivitii muncii;
g) creterea profitului;
h) mbuntirea imaginii unitii economice.
2. Etapele ciclului de dezvoltare a sistemelor informatice de gestiune sunt:
a) Conceperea, construirea i introducerea n exploatare;
b) Colectarea, construirea i introducerea n exploatare;
c) Colectarea, selectarea i introducerea n exploatare.
3. Identificai afirmaia fals:
d) Ciclul de dezvoltare a SI este inclus n ciclul de via al SI.
e) Ciclul de via al SI este inclus n ciclul dezvoltare a SI.
4. Testarea unitar presupune:
e) verificarea funcionrii separate a fiecrei uniti de program;
f) verificarea funcionrii unitilor de program n interaciune;
g) verificarea funcionrii ansamblului, n calitate de software aplicativ
coerent i unitar.
5. Testarea de integrare presupune:
a) verificarea funcionrii separate a fiecrei uniti de program;
b) verificarea funcionrii unitilor de program n interaciune;
29

c) verificarea funcionrii ansamblului, n calitate de software aplicativ


coerent i unitar.
6. Testarea de sistem presupune:
a) verificarea funcionrii separate a fiecrei uniti de program;
b) verificarea funcionrii unitilor de program n interaciune;
c) verificarea funcionrii ansamblului, n calitate de software aplicativ
coerent i unitar.
7.

Mentenana corectiv const n:


e) diagnosticarea i corectarea erorilor;
f) adugarea de noi capabiliti, modificarea funcionalitii existente i
aducerea de mbuntiri generale;
g) modificarea software-ul pentru a interaciona corect cu un mediu n
schimbare.

8. Procesul de outsourcing implic urmtorul fapt:


a) dezvoltatorul este o societate comercial specializat;
b) dezvoltatorul este reprezentat de unul sau mai muli angajai ai
departamentului de informatic al organizaiei;
c) utilizatorul este i dezvoltatorul sistemului.
9. Procesul de insourcing implic urmtorul fapt:
a) dezvoltatorul este o societate comercial specializat;
b) dezvoltatorul este reprezentat de unul sau mai muli angajai ai
departamentului de informatic al organizaiei;
c) utilizatorul este i dezvoltatorul sistemului.
10. Procesul de selfsourcing implic urmtorul fapt:
a) dezvoltatorul este o societate comercial specializat;
b) dezvoltatorul este reprezentat de unul sau mai muli angajai ai
departamentului de informatic al organizaiei;
c) utilizatorul este i dezvoltatorul sistemului.
Rspunsuri:
1) a.
2) a.
3) b.
4) a
5) b
6) c

30

7) a
8) a
9) b
10) c

2.8. Test de evaluare a cunotinelor


Descrieti etapele ciclului de dezvoltare a sistemelor informatice .

2.9. Tem de control


Realizai un referat cu titlul Tipuri de participani n dezvoltarea sistemelor
informatice .

2.10. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft Access,
Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des traitements,
langage SQL), Nouvelle dition, Ressources informatiques, Informatique Technique,
2009.

31

UNITATEA DE NVARE 3. METODE DE PROIECTARE A


SISTEMELOR INFORMATICE
Cuprins
3.1. Obiective
3.2. Competenele unitii de nvare
3.3. Evolutia metodelor de proiectare
3.4. Strategii de abordare a proiectrii sistemelor informatice
3.5. Metodologia elaborrii sistemelor informatice
3.6. Rezumat
3.7. Test de autoevaluare a cunotinelor
3.8. Test de evaluare a cunotinelor
3.9. Bibliografie

3.1. Obiective
Obiectivele acestei unitati de nvare sunt:
nsusirea noiunilor de modelare, respectiv model informaional
ntelegerea evolutiei metodelor de proiectare a sistemelor informatice
nsusirea strategiilor de abordare a proiectarii unui sistem informatic
ntelegerea importantei metodologiilor de elaborare a sistemelor
informatice
.

3.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Ce se intelege prin modelare?
Care sunt strategiile de abordare a proiectarii SI?
Care sunt procesele pe care trebuie sa le cuprinda orice metodologie de
elaborare a unui SI?
Durata de parcurgere a acestei uniti de nvare este de 3 ore.

3.3. Evolutia metodelor de proiectare

00:05

Realizarea unui sistem informatic, sau doar a unei aplicaii,


presupune modelarea situaiei reale i utilizarea modelului creat, n realitatea cu
care opereaz calculatorul.
Modelarea este reprezentarea ntr-un mediu controlat, a proprietilor
i/sau fenomenelor i proceselor care caracterizeaz un obiect sau un sistem real.
Cu alte cuvinte n modelare nu exist adevr absolut; modelarea presupune
abstracie i aducerea n atenie numai a unor aspecte ale realitii studiate i
anume acele aspecte care prezint interes pentru modelator. Unul din mediile
32

00:30

controlate n care se poate reproduce realitatea, deci unul n care se pot face
modele, este calculatorul. Pe calculator se realizeaz modele informaionale.
Modelul informaional este o abstracie a unei entiti i aceast abstracie
poate fi fcut fie pentru a crea un model general (de referin) care s fie apoi
folosit pentru a crea exemple concrete de sisteme informatice, fie pentru a crea
modelul informatic al unei entiti anume, deci un model de transpunere. n cele
ce urmeaz ne vom referi exclusiv la modele de transpunere. La crearea
modelului intervine viziunea analistului despre realitatea pe care o studiaz, adic
paradigma. Paradigma reprezint viziunea prin care analistul vede sistemul
informaional real, acela pe care vrea s-l modeleze, dar nu toate viziunile sau
concepiile analitilor ajung s fie considerate paradigme. Odata cu trecerea
timpului s-au conturat mai multe curente de gndire care au promovat si dezvoltat
anumite metode de proiectare, tocmai de aceea exist mai multe clasificri ale
metodelor de proiectare.
La nceputurile existenei sistemelor informatice, atenia analitilor a fost
concentrat spre latura funcional a activitii umane studiate i cum o funcie a
unui birou, sau secie, nu putea fi analizat i nici prelucrat n bloc, ea a fost
descompus n activiti (rezultnd aplicaiile informatice), activitile au fost
descompuse n subactiviti (rezultnd procedurile), care la rndul lor au fost
descompuse n operaii, crora n calculator le corespondeau modulele program.
S-a dezvoltat n aceste condiii o abordare funcional a sistemelor
informaionale, cunoscut sub numele de metoda descompunerii funcionale
(metode orientate spre funcii) [Oprea, 1999]. Descompunerea funcional este
cea care anun apariia proiectrii structurate i analizei structurate. Fiecare
funcie este descompus n subfuncii, pn se obin structuri uor de transpus n
instruciunile limbajelor de programare.
n informatica industrial funciei i corespunde procesul, ceea ce a dus la
abordarea orientat spre proces sau metoda fluxurilor de date (metode
orientate spre proces) [Oprea, 1999]. Prin aceast metod analitii efectueaz
reprezentarea lumii reale prin simboluri care reprezint fluxul datelor,
transformrile datelor, stocarea datelor, entiti externe etc. Metoda orientat spre
procese are nc un mare grad de asemnare cu descompunerea funcional.
Ulterior, locul fiierelor a fost luat de bazele de date i corespunztor,
locul sistemelor de gestiune a fiierelor a fost luat de sistemele de gestiune a
bazelor de date (SGBD). Pe parcursul perfecionrii SGBD-urilor, s-a trecut la
baze de date relaionale, crendu-se impresia c elementul principal pe baza
cruia trebuie perfecionate SGBD-urile l reprezint structura datelor. Avem
astfel de a face cu o abordare orientat spre date sau metode orientate spre
informaii (metode orientate-date) [Oprea, 1999]. Dou realizri importante n
domeniu au dat tonul unei orientri n abordarea sistemelor: modelarea datelor cu
ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976) i ingineria
informaiei, n viziunea lui James Martin.
33

Cnd s-a pus problema aplicaiilor n timp real, factorul cel mai important
se prea a fi evenimentul. A aprut astfel abordarea orientat spre evenimente.
Structurarea programelor a evoluat i ea odat cu metodele de analiz, dar
era din ce n ce mai greu de inut pasul cu metoda de analiz, mai exact cu
orientarea abordrii sistemelor informatice. Preocuprile analitilor-programatori
pentru a pune n concordan structura programelor cu metoda de analiz a
sugerat o nou abordare i anume legarea evenimentelor de obiect i a
programelor de evenimente. A aprut astfel abordarea orientat pe obiecte, sau
metoda orientat-obiect [Oprea, 1999].
Metodele orientate-obiect (OO) constituie o categorie particular a
metodelor de dezvoltare software, care privesc construirea sistemelor pentru care
clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a
obiectelor care au aceeai structur i un comportament similar.
Metoda descompunerii functionale presupune:
...................

...............................................................................................................................

01:00

Curentul de gndire francez a realizat o alt clasificare a metodelor de


proiectare plecnd de la modalittile n care este conceput sistemul: functional,
sistemic, obiectual. Astfel, s-a propus urmtoarea clasificare:
Metode ierarhice (generatia I a metodelor de proiectare);
Metode sistemice (generatia a II- a);
Metode orientate-obiect (generatia a III- a).
Metodele ierarhice au la baz descompunerea functional a unei
probleme ntr-o ierarhie de subprobleme care trebuiau rezolvate ori de cte ori
intervenea o schimbare a mediului de afaceri.
Avantajele unei asemenea metode sunt:
timpul redus de dezvoltare
complexitate scazuta a realizarii respectivelor functii.
Dezavantajele acestor metode constau n faptul ca mentenana unui
asemenea sistem ridica numeroase probleme.
Exemple de astfel de metode:
SADT (Structured Analysis Design Technique);
JSD (Jackson Structured Design).
Avantajele metodelor ierarhice sunt:
...................

..............................................................................................................................

34

3.3.1. Metode sistemice

01:20

Metodele reprezentative pentru abordarea sistemic sunt :


MERISE
AXIAL
Information engineering (IE)
Ceea ce este specific acestor metode este utilizarea teoriei sistemelor in
abordarea ntreprinderii.
Sistemul informatic este abordat sub dou aspecte complementare: datele
si prelucrrile sunt analizate si modelate independent.
Spre deosebire de metodele ierarhice, aceste metodele acord prioritate
datelor fat de prelucrri si respect cele trei niveluri de abstractizare introduse de
arhitectura standard ANSI-SPARC: conceptual, logic si fizic.

Fig. 3.1 Nivelurile de abstractizare a datelor si prelucrarilor (Sursa


[Stanciu, 2000])
Realizati un referat n care sa puneti n evident caracteristicile metodei de
proiectare MERISE.
...................................................................................................................
...................................................................................................................

3.3.2. Metode orientate-obiect


Conceptul de baza n jurul caruia s-a construit metodologia de proiectare
orientat obiect este obiectul. Aferent acestui concept au aparut metodele
orientate obiect. Caracteristic acestor metode este faptul c sistemul informatic
35

este gndit ca un ansamblu de obiecte autonome care se organizeaz si coopereaz


ntre ele.
Dac n cadrul metodelor sistemice totul se focaliza n jurul conceptului de
entitate, n cadrul metodelor orientate obiect n centrul atentiei se gaseste obiectul.
Un obiect constituie o abstractizare a unui concept similar din lumea real.
Avantajul obiectului fa de o entitate l constituie faptul c, pe lng datele care
descriu entitatea sau obiectul respectiv, obiectul mai conine si metodele de
prelucrare a datelor, acest lucru neputnd fi realizat cu nici unul din conceptele
specifice metodelor de proiectare anterioare. Deci, obiectele aduc avantajul
ncapsulrii, datele si prelucrrile fiind ncapsulate n cadrul obiectului.
Conceptele noi pe care aceste metode le introduc sunt: obiect, clas, instan,
stare, eveniment, mesaj, ncapsulare, mostenire, polimorfism.
Metodele reprezentative ale acestei abordari sunt :
UML (Unified Modeling Language)
OMT (Object-Modeling Technique)
BOOCH elaborat de Grady Booch
Avantajele metodelor orientate-obiect constau n posibilitatea reutilizrii
componentelor de program, reducnd la minim efortul de mentenan a unui
sistem informatic.
Dezavantajele acestor metode decurg din faptul c nu toate aspectele
realitii pot fi modelate cu ajutorul conceptului de obiect.
S ne reamintim...
Conceptul de baza n jurul caruia s-a construit metodologia de proiectare orientat
obiect este obiectul. Aferent acestui concept au aparut metodele orientate obiect.
Realizati un referat n care sa puneti n evident caracteristicile metodei de
proiectare UML.
...................................................................................................................
...................................................................................................................

3.4. Strategii de abordare a proiectrii sistemelor informatice

01:45

Dintr-un alt punct de vedere, exist trei strategii n ceea ce priveste


proiectarea unui sistem informatic:

Abordarea descendent (top down)

Abordarea ascendent (bottom up)

Abordarea mixt
Abordarea descendent (top down) sau de sus n jos, presupune mai
nti definirea de ansamblu a proceselor si detalierea acestora ulterior.
Aceast abordare const n a cobor, pe scara piramidei ierarhice pn la
baz, realiznd totodat i o analiz. Aceast viziune consider c un anumit
36

domeniu este compus din pri corelate ntre ele i cu legturi cu exteriorul, fiind
caracteristic pentru toate sistemele informaionale. Adepii acestei abordri
consider c este mai bine s se creeze i s se realizeze din start un sistem
informatic care s in cont de obiectivele planificate, ntr-o manier global.
Avantajele pe care le comporta o asemenea abordare sunt urmtoarele
[Amza, 2008]:
Va exista o viziune si o gndire unitar asupra modelului sistemului;
Va permite abordarea problemelor n totalitatea complexitatii lor lund
n calcul toate implicatiile pe care un anumit eveniment le poate produce
n domenii conexe cu domeniul n care a aparut respectivul eveniment;
Va permite evitarea unor procese de reproiectare a anumitor sub-parti
datorate unei abordari care nu a luat n calcul aspectele implicatiilor n
domeniile conexe.
Dezavantajele pe care le implica o asemenea abordare presupune printre
altele si aspectele [Amza, 2008]:
Demararea unei proiectari top down presupune desemnarea unei echipe
de specialisti care sa aiba o viziune globala asupra proceselor de afaceri;
Echipa de proiectanti trebuie sa aiba o experienta foarte mare si sa
cunoasca foarte bine teoria de proiectare a sistemelor informatice si a
metodei alese n particular;
Timpul de proiectare n cazul uneia asemenea abordari este mare;
Costurile implicate sunt foarte mari.
Abordarea descendent (top down) presupune:
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................

02:00

Abordarea ascendent (bottom up) sau de jos n sus are ca punct de


plecare nivelul operaional (aflat la baza piramidei ierarhice) i, prin realizarea
informatizrii la fiecare nivel n parte, se ajunge la un sistem informatic care poate
atinge nivelul superior al piramidei. n acest caz, n faza final, ajungem s avem
informatizarea complet a unui sistem informaional-organizaional, specific unui
organism economic supus analizei.
Avantajele pe care le comporta o asemenea abordare sunt urmtoarele
[Amza, 2008]:

Permite demararea simultan a procesului de proiectare a unui sistem


informatic din mai multe departamente;

Prezinta o probabilitate mai ridicata de a oferi raspuns exact


cerintelor utilizatorilor;

Presupune un timp de proiectare mult mai redus dat fiind faptul ca nu


adreseaza dect un anumit subdomeniu al organizatiei care va fi
expus schimbului de informatii cu celelalte subdomenii;
37

Specialistii implicati nu trebuie sa cunoasca neaparat activitatea pe


ansamblu a organizatiei ci doar aspectele necesare externalizarii
datelor si informatiilor subdomeniului implicat n colaborarea cu
celelalte subdomenii. Acest fapt poate conduce la desemnarea unor
echipe formate din mult mai putini specialisti cu cunostinte nu la fel
de vaste ca cei ceruti de o abordare de sus n jos;

Costurile implicate de o asemenea abordare sunt mult mai reduse


dect cele implicate de abordarea de sus n jos.
Dezavantajele pe care le implica o asemenea abordare presupune printre
altele si aspectele [Amza, 2008]:

Daca ulterior se va dori integrarea diferitelor abordari s-ar putea sa se


constate ca o buna parte dintre modelele elaborate separat nu
corespund cerintelor globale astfel ca vor trebui reproiectate.

Costurile n perspectiva integrarii s-ar putea sa le depaseasca pe cele


pe care le implica abordarea de sus n jos.

Nu exista o viziune si o gndire unitar asupra sistemului.

Realizati o analiz comparativ a celor doua tipuri de abordri, lund n


considerare avantajele si dezavantajele fiecreia:
...................................................................................................................................
...................................................................................................................................
.................................................................................................................................
Abordarea mixt
Aceasta abordare permite dezvoltarea unui sistem informatic prin alternarea
metodelor si instrumentelor, specifice celor doua strategii anterioare, n functie de
influenta si conditionarea a diversi factori externi. n cazul n care timpul de
furnizare al sistemului este mic, atunci este foarte probabil sa se recurga la o
abordare bottom-up. Daca timpul de dezvoltare este mediu se poate recurge la o
strategie mixta. Daca timpul depaseste 2-3 ani, atunci se poate alege o abordare
top-down [Amza, 2008].

3.5. Metodologia elaborrii sistemelor informatice


02:20

Dat fiind complexitatea sistemelor informatice, acestea nu se pot obine


dintr-o dat i nici nu se pot realiza dup cum crede fiecare dezvoltator. n acest
sens, experiena acumulat n procesul de elaborare a sistemelor informatice a fost
materializat n metodologii.
Metodologia elaborrii sistemelor informatice a fost conceput iniial ca
un ansamblu de principii i indicaii, tehnici i metode grupate i ordonate ca s
38

duc la realizarea sistemului informatic. Cuvntul metod folosit n aceast


definiie nu are nimic de a face cu metoda-program asociat evenimentelor unui
obiect i nici cu metoda de abordare a sistemelor informaionale. Aici prin metod
se nelege un set de reguli aplicabile unui domeniu restrns din cadrul unei
metodologii.
In prezent metodologia este vzut ca setul finit, particular, definitoriu al
unei metode (metod de abordare a sistemelor informatice), prin intermediul unui
sistem coerent de procese informatice, necesare pentru modelarea unui sistem
informatic.
Metodologiile evolueaz odat cu tehnologia informaiei, dar oricare ar fi
metodologia de realizare a sistemelor informatice, aceasta trebuie s cuprind:

etapele/procesele de realizare a unui sistem informatic, structurate n


subetape, activiti, sarcini precum i coninutul lor;

fluxul realizrii acestor etape sau procese, subetape i activiti;

modalitatea de derulare a ciclului de via a sistemului informatic;

modul de abordare a sistemului;

strategiile de lucru/metodele de realizare;

regulile de formalizare a componentelor sistemului informatic;

tehnicile, procedurile, instrumentele, normele i standardele utilizate;

modalitile de conducere a proiectului (planificare, programare,


urmrire) i modul de utilizare a resurselor financiare, umane i
materiale.
S ne reamintim...
Abordarea ascendent (bottom up) sau de jos n sus are ca punct de plecare
nivelul operaional (aflat la baza piramidei ierarhice) i, prin realizarea
informatizrii la fiecare nivel n parte, se ajunge la un sistem informatic care poate
atinge nivelul superior al piramidei..
Enumerai procesele pe care trebuie s le cuprind orice metodologie de
elaborare a unui sistem informatic
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................

3.6. Rezumat

02:50

Modelul informaional este o abstracie a unei entiti i aceast abstracie


poate fi fcut fie pentru a crea un model general (de referin) care s fie
apoi folosit pentru a crea exemple concrete de sisteme informatice, fie
pentru a crea modelul informatic al unei entiti anume, deci un model de
transpunere;
Metodele de proiectare au evoluat de-a lungul timpului astfel: metode de
proiectare ierarhice, metode de proiectare sistemice respectiv, metode de
proiectare orientate-obiect;
Proiectarea unui sistem informatic se poate face folosind una din
abordarile: top-down, bottom-up sau mixt.
39

3.7. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Care din afirmaiile urmtoare sunt corecte:
a) Metoda top-down are ca obiectiv principal realizarea modularizrii
sistemului de sus n jos.
b) Metoda top-down const n agregarea modulelor de jos n sus.
c) Metoda top-down nu are la baz principiul abordrii sistemice.
2. Strategiile de abordare a proiectarii unui sistem informatic sunt:
a) Top-down, bottom-up respectiv mixt;
b) Top-down, complex respectiv mixta;
c) Avansat, complex respectiv mixta;
d) Niciuna dintre variantele anterioare.
3. Identificai afirmaia fals:
a) O strategie top-down presupune un timp de proiectare si dezvoltare, mult
mai mare comparativ cu aplicarea unei strategii bottom-up.
b) O strategie bottom-up presupune un timp de proiectare si dezvoltare, mult
mai mare comparativ cu aplicarea unei strategii top-down.
4. Identificai afirmaia fals, n cazul metodelor de proiectare ierarhice:
a) datele sunt separate de prelucrari;
b) problema este spart n subprobleme;
c) au la baz descompunerea functional.
5. Metoda MERISE este o metoda de proiectare:
a) ierarhic;
b) sistemic;
c) orientat-obiect.
6. Separarea datelor de prelucrari a avut loc odata cu aparitia metodelor de
proiectare:
a) ierarhice;
b) sistemice;
c) orientate-obiect.
7. Metodele de proiectare sistemice trateaz modelul prelucrrilor din
perspectiva:
a) Extern, intern si mixt;
b) Conceptual, logic si fizic;
40

c) Conceptual.
8. Metoda UML este o metoda de proiectare:
a) ierarhic;
b) sistemic;
c) orientat-obiect.
9. Care din afirmaiile urmtoare sunt corecte, n cazul metodelor de proiectare
orientate obiect:
a) mentenana unui sistem informatic (proiectat prin metoda OO) ridic
numeroase probleme;
b) problema este spart n subprobleme;
c) au la baz descompunerea functional;
d) datele si prelucrrile sunt ncapsulate n obiect.
10. Identificai afirmaia fals, n cazul abordrii top-down:
a) Presupune mai nti definirea de ansamblu a proceselor si detalierea
acestora ulterior.
b) Timpul de proiectare n cazul uneia asemenea abordri este mare.
c) Costurile implicate sunt foarte mari.
d) Are ca punct de plecare nivelul operaional - aflat la baza piramidei
ierarhice - i, prin realizarea informatizrii la fiecare nivel n parte, se ajunge la
nivelul superior al piramidei.
Rspunsuri:
10)a.
11)a
12)a
13)a
14)b
15)b
16)b
17)c
18)d
19) d

3.8. Test de evaluare a cunotinelor


Ce metode de proiectare cunoasteti?
41

3.9. Bibliografie
I.

Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.

II. Bibliografie facultativ


1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

42

UNITATEA DE NVARE 4. METODE SISTEMICE DE PROIECTARE


Cuprins
4.1. Obiective
4.2. Competenele unitii de nvare
4.3. Prezentarea metodei MERISE
4.4 Ciclurile de baz ale proiectrii unui sistem informatic
4.5. Rezumat
4.6. Test de autoevaluare a cunotinelor
4.7. Test de evaluare a cunotinelor
4.8. Bibliografie

4.1. Obiective
ntelegerea etapelor preliminare ale metodei de proiectare MERISE
ntelegerea ciclurilor de baz n proiectarea unui sistem informatic

4.2. Competenele unitii de nvare


Dup parcurgerea unitii, vei fi n msur s rspundei la ntrebrile:
Care sunt etapele proiectrii unui SI caracteristice metodei MERISE ?
Care sunt ciclurile de baz ale proiectarii unui SI prin metoda MERISE?
Durata de parcurgere a acestei uniti de nvare este de 3 ore.

4.3. Prezentarea metodei MERISE

00:05

Metoda MERISE (Mthode d'tude et de Ralisation Informatique pour


les Systmes d'Entreprises) a fost dezvoltat de Centrul Tehnic de Informatic din
cadrul Ministerului de Industrie Francez i reprezint un instrument tehnicoeconomic de proiectare a unui sistem informatic.
Pe parcursul timpului au fost dezvoltate dou variante ale metodei. Prima
variant, elaborat la sfritul anilor 70 se baza pe urmtoarele coordonate:
a) abordarea sistemic ce scoate n eviden relaia existent ntre
sistemul informaional i sistemul de conducere (decizional), pe de o
parte, precum i relaia dintre sistemul informaional i sistemul condus
(operaional), pe de alt parte. Astfel, sistemul informaional pune la
dispoziia sistemelor condus i decizional toate informaiile necesare
pentru a aciona i a decide;
b) acoperirea ntregului ciclu de via a sistemului informatic (SI)
cuprinde schema directoare, studiul prealabil, studiul de detaliu,
studiul tehnic, realizarea, implementarea i mentenana sistemelor
43

informatice;
c) un ciclu de abstractizare corespunztor celor trei niveluri:
conceptual, logic sau organizaional i fizic;
d) separarea ntre modelul datelor i modelul prelucrrilor.
Metoda MERISE vizeaz dou obiective principale:

reprezint o metod de concepie a sistemelor informatice;

propune o metodologie de dezvoltare a sistemelor informatice.


Fiind o metod sistemic, aceasta separ studiul datelor de cel al
prelucrrilor, conform tabelului urmator (vezi Fig. 3.1 Unitatea de invatare
nr.3):
Niveluri
Conceptual

Date
Model conceptual
MCD

Logic
Model logic MLD
(Organizaional)
Fizic
Model fizic MFD

Prelucrri
Model conceptual MCP
Model logic (organizaional) MLP
(MOP)
Model fizic MFP

Tabel 4.1 Nivelurile de abstractizare a datelor si prelucrarilor

00:20

Avantajele metodei MERISE ca metod de concepie a sistemelor


informatice sunt:

apropierea de sistemul informatic i de structura ideal a bazei de date;

descrierea sistemului pe trei niveluri;

utilizarea unui formalism5 de reprezentare precis, simplu i riguros pentru


descrierea datelor. Acest formalism este reglementat pe plan internaional
de standardul ISO sub numele de modelul ENTITATE-ASOCIERE;

descrierea amnunit la nivel conceptual, permind realizarea unui SI


independent de organizarea firmei i alegerea tehnicii de automatizare;

reprezentarea vizual folosit n modelul conceptual faciliteaz stabilirea


unui dialog ntre toi partenerii implicai n realizarea SI.
Varianta a doua a metodei MERISE surprinde evoluiile tehnice i
organizaionale ale anilor 90 i nltur cteva carene ale modelului entitateasociere utilizat n prima versiune. Astfel, se introduc noiunile de generalizare i
specializare pentru a explica conceptele de motenire, regulile de integritate i
noiunea de identificator relativ (ce permite identificarea unei entiti n raport cu
alt entitate).
n versiunea a doua a metodei MERISE modelul conceptual al
prelucrrilor (MCP) conine, n plus :

Formalism, n sensul de mai sus, nseamn un set de definiii i reguli, combinat cu un set de tipuri
de diagrame i/sau de tabele.

44

diagram a fluxului de date (DFD);

un model analitic conceptual al prelucrrilor care acioneaz nc


din faza de concepie;

noiunea de ciclu de via al unui obiect surprinde toate etapele


parcurse de un obiect n cursul existenei sale, n funcie de
evenimentele produse i de evenimentele care urmeaz a se produce.
La nivel organizaional, sunt surprinse n structur toate resursele
materiale i umane implicate n realizarea sistemelor informatice. La nivel logic,
sunt definite interfeele cu utilizatorii, resursele logice ale prelucrrilor, precum i
depozitarea i repartiia datelor, nivelul fizic rmnnd neschimbat.
Pentru proiectarea unui sistem informatic utiliznd metoda MERISE,
trebuiesc parcurse urmatoarele etape:

Analiza prealabil si realizarea schemei directoare.

Analiza de detaliu.

Analiza tehnic.

Realizarea programelor.

Punerea n functiune si exploatarea.

Mentenanta.
Analiza prealabil, schema directoare, analiza de detaliu si analiza tehnic
acoper partea corespunzatoare conceperii sistemului din ciclul de viat.
Producerea programelor si punerea n functiune acopera partea corespunzatoare
ntre realizarea sistemului si lansare. Analiza tehnic poate face parte din etapa de
concepere sau din etapa de realizare, acest lucru fiind lsat la latitudinea
dezvoltatorului.

Identificai etapele de proiectare a unui sistem informatic utiliznd metoda


MERISE :
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

4.4. Ciclurile de baz ale proiectrii unui sistem informatic

00:45

Ciclurile de baz ale proiectrii unui sistem informatic utiliznd metoda


MERISE sunt:
ciclul de via;
ciclul de decizie;
ciclul de abstractizare.
Acestea se reprezint ntr-un grafic tridimensional corespunzator
Modelului tridimensional al proiectrii unui SI (vezi Fig.4.1).

45

Fig.4.1 Modelul tridimensional (Sursa:[Luca, 2006 ])


4.4.1 Ciclul de via

01:00

Ciclul de via presupune parcurgerea succesiv a urmtoarelor etape:


realizarea schemei directoare i studiul preliminar;
realizarea unui studiu detaliat;
realizarea sistemului informatic (studiu tehnic, codificare);
implementarea si exploatarea;
mentenana sistemului.

a) Realizarea schemei directoare i studiul preliminar presupune


analiza sistemului informatic existent, stabilirea cerintelor, a obiectivelor i a
planului strategic, definirea prioritilor, realizarea de scenarii globale alternative
pentru fiecare domeniu investigat i alegerea scenariului optim. Deasemenea,
organizaia este mpartit pe domenii sau pe departamente, iar pentru fiecare
departament este gndit o schem a aplicaiilor, care include i politica de
resurse umane, produsele hardware i software, precum i o metodologie pentru
implementarea unei mbuntiri viitoare a sistemului.
Studiul preliminar este realizat pentru fiecare domeniu i descrie SI
propus, impactul acestuia asupra organizaiei, costurile i beneficiile. Studiul
trebuie s fie n concordan cu planul strategic stabilit anterior. Activitile
acestei etape sunt:
culegerea de informaii despre activitatea organizaiei;
realizarea diagramelor de flux care evideniaz actorii participani i
46

schimburile de informaii dintre ei;


elaborarea primelor variante de MCD i MOP i analizarea punctelor lor
slabe;
propuneri de mbuntire a MCD i MOP i prezentarea unei soluii;
evaluarea soluiei propuse.

01:15

1:30

b) Studiul detaliat pleaca de la soluia cadru definita pentru scenariul ales


pe care o dezvolta. Aceasta presupune specificarea detaliat a cerinelor i a
arhitecturii noului sistem. n acest sens, se vor avea n vedere toate aspectele ce
vor fi automatizate, incluznd specificaiile de detaliu pentru modelul tehnic i
funcional. Aceasta etap asigura modelarea conceptual si organizational a SI.
Activitile acestei etape sunt:
la nivel general:
realizarea MCD, MCP, MLD, MOP pentru soluia aleas;
definirea mediului de dezvoltare;
punerea n practic a studiului prealabil prin elaborarea planurilor de
lucru;
realizarea documentaiei i a planului de recepie
la nivel detaliat:
stabilirea fazelor de realizare;
validarea datelor i prelucrrilor (optimizarea MLD i realizarea unei
prime variante a MFD);
evaluarea timpului de realizare a bazei de date;
un plan cu necesarul de echipamente i materiale.
Studiul detaliat cuprinde urmatoarele activitati:
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................
c) Realizarea sistemului informatic se execut n dou subetape:
i) studiul tehnic;
ii) realizarea programelor.
Studiul tehnic presupune descrierea logic a arhitecturii SI i descrierea
MFD (deci aceasta etap asigura modelarea logic si fizic a SI);
Realizarea programelor (codificarea) presupune scrierea efectiv a liniilor
de cod i testarea acestora.
d) Exploatarea cuprinde urmatoarele aspecte [Amza, 2008]:
Pregatirea lansarii
Proiectul de lansare este elaborat si efectueaza o suita de studii privitoare
la:
Etapele tranzitorii exploatarea sistemului trebuie facuta esalonat
deoarece noul sistem trebuie testat;
47

Procedurile preliminare de realizare a bazei de date;

Informarea si instruirea utilizatorilor;

Planul lansarii presupune realizarea unei planificari exacte a


succesiunii de punere n functiune a diferitelor module ale sistemului.
Implementarea
Procesul de implementare presupune:

Stabilirea micro-structurilor de implementare;

Conexiunile ntre departamente;

Locurile de munca;

Desemnarea utilizatorilor care vor opera date.


Lansarea propriu-zisa
Dupa o perioada de exploatare de cteva luni, interval n care au aparut
aproape toate situatiile posibile carora sistemul trebuie sa le faca fata putem
afirma ca acesta a fost lansat si implementat.

S ne reamintim...
Realizarea programelor (codificarea) presupune scrierea efectiv a liniilor de cod
i testarea acestora.
Exploatarea unui sistem informatic cuprinde urmatoarele aspecte:
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................

02:00

e) Mentenana sistemului informatic const n a asigura evolutia


aplicatiilor operative n functie de cerintele utilizatorilor, de cerintele mediului si
de progresul tehnologic. Mentenana are ca obiectiv adaptarea la evolutiile
mediului informational. Atunci cand acesta evolueaza foarte mult, se recomanda
un nou ciclu de via, ce presupune renuntarea utilizarii sistemului informatic. Nu
exista sisteme informatice fara ciclu de viata.
Mentenana implica patru etape esentiale [Amza 2008]:

Studiul de impact presupune evaluarea amplorii adaptrilor si


realizarea unei actualizari a modelului de date si prelucrari;

Analiza adaptrilor si specificatiile acestora;

Realizarea adaptrilor;

Lansarea versiunii modificate n urma revizuirii.

Identificati etapele ciclului de viata a unui sistem informatic proiectat cu


metoda MERISE:
...................................................................................................................................
...................................................................................................................................

48

Ciclul de decizie
Ciclul de decizie reprezinta totalitatea deciziilor luate n timpul ciclului de
viata al unui sistem informatic, decizii referitoare la proiectarea, realizarea i
exploatarea sistemului informatic.
Actorii care apar n procesul decizional sunt: managerii, utilizatorii i
dezvoltatorii sistemului informatic. Deoarece luarea deciziilor presupune
cooperarea dintre diferite compartimente, este important s se creeze mai multe
grupuri de lucru.
Deciziile care se iau n ciclul de decizie sunt legate de aspecte multiple, ca
de exemplu:
Decizii manageriale legate de funcionalitatea SI;
Decizii financiare referitoare la costuri i beneficii;
Decizii referitoare la identificarea principalilor actori ai sistemului
informaional i organizatoric;
Decizii ale utilizatorilor finali legate de interfaa SI;
Decizii legate de modul de procesare a datelor;
Decizii de ordin tehnic legate de echipamentele hardware i software.
Ciclul de abstractizare

2:20

Este constituit dintr-o niruire de raionamente fcute n scopul realizrii


sistemului, constituind faza esenial a metodei MERISE.
Ciclul de abstractizare conine 3 niveluri: conceptual, logic si fizic.
Nivelurile de abstractizare sunt mprite n dou mari categorii: niveluri de
abstractizare care fac referire la date i niveluri de abstractizare care fac referire la
prelucrri.

49

Identificai caracteristicile ciclului de abstractizare:


...................................................................................................................................
...................................................................................................................................
...................................................................................................................................

4.5. Rezumat

02:50

Etapele proiectrii unui sistem informatic, caracteristice metodei


MERISE, sunt: studiul prealabil si schema directoare, studiul de
detaliu, studiul tehnic, realizarea, implementarea i mentenana
sistemului informatic;
Ciclurile de baza ale proiectarii unui sistem informatic, prin metoda
MERISE, sunt: ciclul de viat, ciclul de decizie si ciclul de
abstractizare.

4.6. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Ciclurile de baza ale proiectarii unui SI utiliznd metoda MERISE sunt :
a) De viata, de proiectare, de abstractizare;
b) De viata, de implementare, de abstractizare;
c) De viata, de decizie, de abstractizare;
d) De viata, de realizare, de abstractizare.
2. Identificai afirmaia fals:
a) Ciclul de viata presupune parcurgerea succesiva a mai multor etape;
b) Exista sisteme informatice fara ciclu de viata;
c) Atunci cand mediul informational evolueaza foarte mult, se
recomanda un nou ciclu de via, ce presupune renuntarea utilizarii
sistemului informatic.
3. Implementarea reprezint:
a) un concept legat de calculatoare;
b) etapa de analiza a unui sistem informatic;
c) una dintre etapele ciclului de viata ale unui sistem informatic.
4. Mentenana reprezint:
a) un concept legat de calculatoare;
b) una dintre etapele ciclului de viata ale unui sistem informatic;
c) o etapa de evaluare a unui sistem informatic.
5. Metoda MERISE este o metoda de proiectare:
a) ierarhic;
b) sistemic;
50

c) orientat-obiect.
6. Metodele de proiectare sistemice trateaz modelul datelor din
perspectiva:
a) Conceptual, operational si decizional;
b) Conceptual, logic si fizic;
c) Conceptual, ierarhic si logic.
7. Care din afirmaiile urmtoare sunt corecte, n cazul realizarii studiului
detaliat:
a) Asigura modelarea conceptual si organizational a sistemului
informatic.
b) Asigura modelarea logic si fizic a sistemului informatic.
c) Asigura modelarea conceptual si fizic a sistemului informatic.
8. Care din afirmaiile urmtoare sunt corecte, n cazul realizarii studiului
tehnic:
a) Asigura modelarea conceptual si organizational a sistemului
informatic.
b) Asigura modelarea logic si fizic a sistemului informatic.
c) Asigura modelarea conceptual si fizic a sistemului informatic.
9. n cadrul metodei MERISE pentru descrierea datelor se utilizeaza:
a) Modelul Entitate-Asociere;
b) Modelul Entitate-Obiect;
c) Modelul Orientat-Obiect.
10. Identificai afirmaia fals, n cazul ciclului de abstractizare:
a) Ciclul de abstractizare conine 3 niveluri: conceptual, logic si fizic.
b) Ciclul de abstractizare conine 3 niveluri: conceptual, organizational
si fizic.
c) Ciclul de abstractizare conine 3 niveluri: conceptual, logic si
organizational.
Rspunsuri:
1) c
2) b
3) c
4) b
5) b
6) b
7) a

51

8) b
9) a
10) c

4.7. Test de evaluare a cunotinelor


Identificati etapele ciclului de viata a unui sistem informatic proiectat cu metoda
MERISE

4.8. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

52

UNITATEA DE NVARE 5. MODELUL CONCEPTUAL AL


DATELOR. MODELUL ENTITATE-ASOCIERE (E-A)
Cuprins
5.1. Obiective
5.2. Competenele unitii de nvare
5.3. Entiti si tipuri de entiti
5.4. Atributele unei entiti
5.5. Rezumat
5.6. Test de autoevaluare a cunotinelor
5.7. Test de evaluare a cunotinelor
5.8. Bibliografie

5.1. Obiective
ntelegerea notiunii de entitate, tip de entitate, atribut al entitatii,
respectiv identificator al unei entitati;
nsusirea notiunii de realizare a unei entitati.

5.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Ce este o entitate?
Care sunt conditiile pe care trebuie sa le ndeplineasca o entitate?
Ce este un atribut al unei entitati?
Ce este identificatorul unei entitati?
Ce este o asociere?
Ce este cardinalitatea unei asocieri?
Durata de parcurgere a acestei uniti de nvare este de 3 ore.

5.3. Entiti si tipuri de entiti

00:05

Modelul conceptual al datelor (MCD) reprezint o modalitate de


reprezentare a datelor organizaiei. Rolul su este de a scoate n relief toate
regulile privind identitatea i legturile existente ntre date. MCD are
urmtoarele obiective:
s serveasc drept suport de comunicare ntre utilizatori i
informaticieni;
s exprime modul n care datele din sistemul informatic reflect
realitatea (domeniul problemei).
Modelul conceptual al datelor reprezint o structur general i logic
53

a bazei de date. Aceast structur este independent de software-ul utilizat


sau de modalitatea de stocare a datelor.
Din acest punct de vedere, MCD presupune:
reprezentarea organizrii datelor ntr-un format grafic care poart
denumirea de diagrama entitate-asociere;
verificarea validitii modelrii datelor;
generarea unui model fizic al datelor care specific modul de
implementare a bazei de date.
MCD corespunde unei structuri generale a datelor acceptat de toi
utilizatorii poteniali. Rezultatul final al activitii de modelare la acest nivel
nu este o reprezentare a unui sistem informatic real, ci reprezint o viziune
abstract a acestuia, reprezentare ce poate lua fie o form grafic (de cele mai
multe ori), fie matematic, verbal sau mental.
MCD are o form abstract i formalizat i poate conine erori
datorate:
spiritului de observare i subiectivitii observatorului;
metodelor de observare folosite;
tehnicilor, instrumentelor i metodelor de modelare.
Pentru a se nltura erorile de concepie a modelului este bine ca la
procesul de observare s participe mai muli membri ai echipei, fiecare dintre
acetia realiznd cte un model. Modelele astfel realizate sunt supuse
confruntrii, care n urma unor analize pot duce la identificarea eventualelor
erori de reprezentare. De asemenea, este important ca modelele utilizate s
respecte normele i standardele recunoscute.

00:20

Identificarea principalelor obiecte care stau la baza modelului


conceptual al datelor, din punct de vedere al metodei MERISE, se refer la
noiunile de entitate i asociere.
Entitatea reprezinta o abstractizare a proprietatilor si caracteristicilor
unui obiect din cadrul domeniului modelat. Entitatile sunt asadar niste
reprezentari ale obiectelor si conceptelor din lumea reala. Exemple de
entitati: factura, banca, furnizor, beneficiar, produs, angajat, student,
disciplin de studiu, oras etc.
n general, n cadrul modelarii conceptuale se ncearca stabilirea unor
modele semantice care sa dea sens att entitatilor ct si regulilor ce iau
nastere ntre acestea. Modelul entitate asociere este un model semantic. n
cadrul lui se va ncerca identificarea entitatilor care prezinta interes pentru
domeniul modelat dar si a asocierilor care iau nastere ntre aceste entitati
[Amza, 2008].
Au fost propuse mai multe variante pentru identificarea entitatilor,
una dintre acestea fiind metoda (abordarea) gramaticala de identificare a
entitatilor. Abordarea gramaticala se bazeaza pe faptul ca, de obicei,
54

entitatile apar in textul problemei de modelat sub forma unor substantive.


Plecand de la acest aspect, abordarea gramaticala presupune identificarea
subiectelor si substantivelor din enuntul problemei de rezolvat. Dar, metoda
gramaticala de identificare a entitatilor nu este o metoda general valabila.
Utilizand aceasta metoda, exista pericolul de a identifica entitati false. De
exemplu, luam in considerare entitatile: angajat, inginer, sef_echipa.
Se constata ca inginer respectiv sef_echipa sunt valori ale atributului
functie din cadrul entitatii angajat.
Pentru a selecta corect entitatile, trebuie sa luam in considerare
caracteristicile unei entitati:
S aparin spaiului problemei de rezolvat (domeniului de
modelat);
S poat fi descris printr-o suit de caracteristici, numite
atribute;
S poat fi identificat n raport cu celelalte entiti;
S aib o existen de sine stttoare.

00:40

Deci, o entitate reprezinta "orice poate fi identificat n mod


distinctiv". O entitate se refer la un aspect al realitii obiective, care poate fi
deosebit de restul universului i poate reprezenta un obiect fizic, o activitate,
un concept etc.
Cu alte cuvinte, o entitate trebuie sa fie identificat in mod unic, in
cadrul modelului conceptual, prin intermediul unui nume (nu putem avea 2
entitati cu acelasi nume).
O entitate trebuie sa poata fi descris. Prin descriere, se intelege
specificarea unor caracteristici, care sa ofere informatii despre entitate si
totodata sa-i confere identificabilitatea in raport cu celelalte entitati. Orice
entitate este descris prin atributele sale. Atributele prin care este descris o
entitate se aleg pe baza criteriului relevanei privind domeniul de interes
pentru care se definete modelul respectiv, astfel nct s asigure
diferenierea precis a entitii respective fa de restul universului. De
exemplu, entitatea ANGAJAT reprezint o persoan angajat a instituiei,
care are o anumit funcie, lucreaz ntr-o anumit secie i primete un
anumit salariu. Aceast entitate fi descris prin mai multe atribute, dintre care
o parte sunt atribute de identificare a persoanei (cum sunt: Nume, Prenume,
DataNasterii, Adresa), iar alte atribute sunt atribute legate de activitatea
acesteia n instituia respectiv (cum sunt: Funcia, Salariul).
n bazele de date, entitile similare care pot fi descrise prin aceleai
atribute, se grupeaz n mulimi, fiecare entitate avnd valori particulare ale
atributelor respective. Toate entitile similare, care pot fi descrise prin
aceleai atribute, aparin aceluiai tip de entitate (clasa entitatii). Ansamblul
tuturor entitilor de acelai tip dintr-o baz de date constitue o mulime de
entiti. O mulime de entiti se descrie prin aceleai atribute prin care este
55

00:50

descris fiecare entitate component.


Numim realizare a unei entiti mulimea format din cte o valoare
pentru fiecare atribut al entitii. Valorile fiecrui atribut component a ceea
ce numim generic entitate alctuiesc o realizare (instaniere) a entitii
respective.
De exemplu, in Figura 5.1, luam in considerare entitatea STUDENT,
descrisa prin aributele: CNP, Nume, Prenume, DataNastere, Adresa. Dnd
valori acestor atribute obtinem o realizare a entitatii STUDENT.

Figura 5.1
Identificai principalele criterii pe baza crora se pot distinge entitile
adevrate dintre cele false ?
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
S ne reamintim...
Entitatea reprezinta o abstractizare a proprietatilor si caracteristicilor unui obiect
din cadrul domeniului modelat.

5.4 Atributele unei entiti

01:10

Fiecare tip de entitate are un set de atribute asociate lui. Un atribut


este o proprietate sau o caracteristic a unei entiti care prezint interes
pentru organizaie. Atributele sunt percepute, din punct de vedere informatic,
ca variabile ale datelor, caracterizate prin natura valorilor pe care le pot lua
acestea la un moment dat. Fiecare atribut are asociat un domeniu de valori.
Domeniul de valori al unui atribut poate sa impuna restrictii cu privire la
valorile valide pe care le poate lua un atribut.
Clasificarea atributelor
Exista mai multe criterii de clasificare a atributelor astfel:
Din punct de vedere al modului de reprezentare a informaiei, atributele pot
fi:
elementare reprezentarea datei este indivizibil n raport cu
56

informaia pe care o reprezint (nu mai pot fi descompuse in alte


atribute). Aceste atribute se mai numesc i atribute atomice;
compuse se pot descompune n mai multe atribute elementare
(exemplu: adresa).
Dupa modul de stocare al valorii:
simple - stocheaza n ele valorile asa cum au fost introduse de
utilizator;
calculate - si obtin valoarea prin aplicarea unei formule asupra
unor alte atribute, pentru care utilizatorul a specificat valoarea
(exemplu: cmpul pret respectiv cantitate, ale unei facturi sunt
atribute simple, n timp ce valoarea = pret * cantitate
reprezinta un atribut calculat). n cele mai multe cazuri, atributele
calculate nu se stocheaz deoarece valoarea lor poate fi dedus cu
ajutorul unor formule.
Dai exemple i de alte atribute calculate pentru entitatea FACTURA.
................................................................................................................................
................................................................................................................................
.................................................................................................................................
S ne reamintim...
Dupa modul de stocare al valorii, atributele pot fi : simple si calculate.

01:30

Din punct de vedere al realitii modelate, atributele pot fi:


opionale dac atributul respectiv nu poate prezenta o valoare la un
moment dat, valoarea lui nefiind neaparat necesara (exemplu: limbi
strine cunoscute);
obligatorii trebuie s prezinte neaparat o valoare. In aceasta situatie,
utilizatorul nu va putea continua prelucrarile pana cand nu se
furnizeaza respectiva valoare.
Din punct de vedere al valorilor pe care le pot lua la un moment dat,
atributele pot fi:
multivaloare atunci cnd valoarea pe care o poate lua un atribut, la
un moment dat, prezint mai multe realizri concomitente pentru
aceeai entitate (exemplu: limbi strine cunoscute o persoan poate
cunoate englez, francez i german);
monovaloare prezint doar o singur valoare pentru atributul
respectiv.

57

Dai exemple de alte atribute multivaloare pentru entitatea FACTURA.


................................................................................................................................
...................................................................................................................................
.................................................................................................................................
S ne reamintim...
Din punct de vedere al realitii modelate, atributele pot fi: opionale si
obligatorii.

02:00

Dupa tipul datelor care sunt continute de un atribut, atributele pot fi:
atribute de tip text sunt folosite cand datele care descriu o anumita
entitate sunt de tip text (exemplu: nume, prenume, denumire, adresa);
atribute de tip numeric sunt utilizate pentru a stoca n ele
caracteristici ce pot fi exprimate valoric sau cantitativ pentru o
anumita entitate (exemplu: pret, cantitate, valoare, valoare TVA, cota
de TVA);
atribute de tip boolean sunt atribute ale caror valori pot lua una din
doua stari posibile: Da/Nu; Adevarat/Fals; 1/0;
atribute de tip data si ora sunt atribute destinate in special stocarii
unor valori cu privire la data sau timp;
atribute binare - sunt acele atribute n care se stocheaza informatia ce
nu poate fi stocata cu nici unul dintre tipurile anterioare (exemplu: o
imagine, un clip audio sau video).
Observatie: se recomanda sa se aleaga un atribut numeric ori de cte ori acel
atribut este utilizat n efectuarea unor calcule aritmetice sau comparative. De
exemplu, constituie o greseala stocarea numerelor de telefon sub forma
numerica, acesta nefiind supus niciodata unor operatii aritmetice. De aceea,
tipul atributului ales trebuie sa fie de tip text (prin alegerea unui atribut de tip
numeric, se vor pierde zerourile situate la nceputul numarului de telefon).
De asemenea, trebuie sa se stabileasca pentru fiecare atribut, lungimea
acestuia. Lungimea unui atribut depinde in principal de tipul atributului.
Astfel, lungimea unui atribut de tip text trebuie stabilita lund n considerare
valorile posibile pe care le poate lua respectivul atribut. De exemplu, pentru
atributul nume este suficienta o dimensiune de 50 caractere.
Din punct de vedere al rolului pe care l ndeplinete atributul respectiv n
cadrul modelului, atributele pot fi:
cheie primar (identificator) reprezint acel atribut, sau grup de
atribute, care reuete, prin valorile pe care le ia, s identifice n mod
unic o entitate din mulimea entitilor care prezint acelai
comportament. Atributele care compun cheia primar nu pot avea
valori nule. O alt cerin esenial este unicitatea.
cheie candidat reprezint acel atribut, care prin natura sa, poate juca
58

02:20

rolul de cheie primar sau de identificator n cadrul unui tip de


entitate. Altfel spus, reprezint o posibil cheie primar, care nu a
fost, ns, reinut ca atare.
cheie extern reprezint un atribut, sau o mulime de atribute,
definite pe aceeai mulime de valori ca i cheia primar, rolul su
fiind acela de a putea stabili o asociere (legtur) ntre dou sau mai
multe tipuri de entiti, care, n realitatea modelat, interacioneaz
ntre ele. Altfel spus, orice cheie extern este cheie primar pentru o
alt entitate.

Identificatorul unei entitati este atributul (sau grupul de atribute) a carui


realizare (valoare) caracterizeaza in mod unic o realizare a entitatii.
n realitate, pot exista mai multe atribute care pot juca rolul de identificator
pentru un tip de entitate. De exemplu, pentru societi comerciale: codul unic
de nregistrare (CUI), numrul de nregistrare, codul IBAN. De aceea,
atributul care joac rolul de identificator (cheie primar) trebuie s
ndeplineasc concomitent mai multe cerine:
a) nu trebuie s existe dou valori identice n mulimea valorilor pe
care le poate lua acel atribut;
b) cheia primar nu poate avea valoarea NULL. Valoarea NULL nu
este valoarea zero, ci arat c pentru atributul respectiv nu s-a introdus nici o
valoare;
c) valoarea pe care o poate lua o cheie primar nu trebuie s se
modifice. n exemplul de mai sus codul IBAN nu respect aceast condiie;
d) dimensiunea cmpului cheie primar trebuie s fie ct mai redus
(identificatorul sa fie cat mai scurt). n exemplul de mai sus, numrul de
nregistrare la Registrul Comerului are 13 caractere, iar CUI este format din
7 caractere.
n cazul n care identificatorul este compus din mai multe atribute atunci
aceste caracteristici sunt cerute tuturor atributelor care fac parte din
respectivul identificator. innd cont de aceste cerine, se alege acel atribut,
sau grup de atribute, care s joace rolul de identificator al unui tip de entitate
(cheia primar). In reprezentarea grafic, de regul, identificatorul se
subliniaz cu o linie continu.
Un alt criteriu de clasificare a atributelor il reprezint domeniul de valori.
Din punct de vedere al domeniului de valori, atributele pot fi:
atribute cu domeniul de valori continuu - sunt acele atribute numerice
care iau valori n limitele unui interval.
atribute cu domeniul de valori discret - sunt acele atribute care nu pot
lua dect anumite valori din multimea valorilor domeniului.
Domeniul de valori reprezint mulimea tuturor valorilor posibile pe care le
poate lua un atribut. Orice atribut trebuie sa aiba asociat un domeniu de
59

02:40

valori. Atributele surprind partea static a unui tip de entitate, iar valorile
atributelor reflect partea dinamic a entitii. De exemplu: vrsta este
atributul entitii SALARIAT, iar valoarea acestui atribut se schimb.
Exist dou modaliti prin care se poate exprima domeniul de valori:
a) Exprimarea explicit se enumer valorile din domeniul respectiv.
Exemplu: vrsta{18,19,20,, 65};
Exprimarea implicit se precizeaz proprietile pe care le are
domeniul. Exemplu: vrsta{x, xN, 18x65}.
Dai exemple de entiti cu identificatori compui din mai multe atribute.
................................................................................................................................
...................................................................................................................................
.................................................................................................................................

S ne reamintim...
Identificatorul unei entitati este atributul (sau grupul de atribute) a carui
realizare (valoare) caracterizeaza in mod unic o realizare a entitatii.
Cheia primar (identificatorul) nu poate avea valoarea NULL.

5.5. Rezumat

02:50

Prin entitate ntelegem o abstractizare a proprietatilor si caracteristicilor


unui obiect din cadrul domeniului modelat. Entitatile sunt reprezentari ale
obiectelor si conceptelor din lumea reala.
Conditiile pe care trebuie sa le ndeplineasca o entitate sunt:
sa aiba existenta de sine statatoare;
sa fie identificabila n raport cu alte entitati;
sa poata fi descrisa prin atribute;
sa apartina domeniului modelat.
Atributul reprezint o caracteristic unei entiti.
Un identificator reprezint un atribut, sau un grup de atribute, pe baza
caruia poate fi identificat, n mod unic, orice realizare a entitatii
respective.
Identificatorul (cheia primar) trebuie s ndeplineasc concomitent mai
multe cerine:
a) nu trebuie s existe dou valori identice n mulimea valorilor
pe care le poate lua acel atribut;
b) cheia primar nu poate avea valoarea NULL. Valoarea
NULL nu este valoarea zero, ci arat c pentru atributul
respectiv nu s-a introdus nicio valoare;
c) valoarea pe care o poate lua o cheie primar nu trebuie s se
modifice.
60

d) dimensiunea cmpului cheie primar trebuie s fie ct mai redus


(identificatorul sa fie cat mai scurt).

5.6. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Dupa modul de stocare al valorii, atributele pot fi:
a) elementare i compuse;
b) simple i calculate;
c) opionale i obligatorii.
2.Din punct de vedere al valorilor pe care le pot lua la un moment dat,
atributele pot fi:
a) elementare i compuse;
b) opionale i obligatorii;
c) monovaloare i multivaloare.
3. Din punct de vedere al rolului pe care l ndeplinete atributul respectiv
n cadrul modelului, atributele pot fi:
a) cheie primar, cheie candidat, cheie extern;
b) cheie primar, cheie secundar, cheie decizional;
c) cheie primar, cheie intern, cheie extern.
4. Identificatorul entitatii Factura este:
a) numr_factura;
b) data_factura;
c) numar_factura i data_factura.
5. Identificai afirmaia fals:
a) Cheia primar poate avea valoarea NULL.
b) Valoarea pe care o poate lua o cheie primar nu trebuie s se
modifice.
c) Dimensiunea cmpului cheie primar trebuie s fie ct mai
redus.
Rspunsuri:
1) b
2) c
3) a
4) c
5) a

61

5.7. Test de evaluare a cunotinelor


Cum pot fi atributele din punct de vedere al rolului pe care l ndeplinesc acestea
n cadrul modelului?
Care sunt cerintele pe care trebuie sa le ndeplineasc un atribut cu rol de
identificator ?
Dai exemple de entiti si de realizri ale entitilor respective.

5.8. Bibliografie
I. Bibliografie obligatorie
9. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
10. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
11. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
12. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
13. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
14. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice,
Ed. Dual Tech, Bucuresti, 2002
15. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
16. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

62

UNITATEA DE NVARE 6. ASOCIERI SI TIPURI DE ASOCIERI.


DIAGRAMA ENTITATE-ASOCIERE (E-A)
Cuprins
6.1. Obiective
6.2. Competenele unitii de nvare
6.3. Tipuri de asocieri
6.4. Cardinalitatea asocierii
6.5. Reguli de modelare
6.6. Rezumat
6.7. Test de autoevaluare a cunotinelor
6.8. Test de evaluare a cunotinelor
6.9. Bibliografie

6.1. Obiective
nsusirea notiunii de asociere, tipuri de asocieri, rolurile asocierii,
cardinalitatea asocierii;
ntelegerea metodei de proiectare a diagramei E-A.

6.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Ce este o asociere?
Ce este cardinalitatea unei asocieri?
Care sunt regulile de modelare?
Care sunt regulile de modelare pentru construirea diagramei E-A?

Durata de parcurgere a acestei uniti de nvare este de 3 ore.

6.3. Tipuri de asocieri

00:05

Asocierea reprezint legtura sau corespondena existent ntre dou sau


mai multe entiti, n care fiecare joac un anumit rol.
Rolul unei entiti este un nume care desemneaz modul de participare a
entitii la o asociere. Identificarea asocierilor se realizeaz prin rolurile
entitilor participante, deci, concret, cu ajutorul identificatorilor entitilor
participante.
Tipul asocierii reprezint ansamblul legturilor sau a corespondenelor cu
63

aceeai semnificaie, dintre dou sau mai multe tipuri de entiti.


Tipurile de entiti (mulimea entitilor) care particip la un tip de
asociere formeaz colecia acesteia. Numrul de tipuri de entiti care particip la
un tip de asociere formeaz gradul sau dimensiunea asocierii.
Din punct de vedere al gradului unei asocieri, distingem:
unar (reflexiv sau ciclic) 1 entitate;
binar 2 entitati;
ternar 3 entitati;
complex 4 sau mai multe entitati.
Spre deosebire de entiti, asocierile nu au existen de sine stttoare, acestea
depinznd de existena entitilor pe care le leag. Existena unei asocieri poate fi mai
scurt dect a entitilor participante.
O asociere poate avea atribute proprii.
Pentru identificarea asocierilor, trebuie sa tinem cont de urmatoarele reguli:
o asociere nu poate exista dect o singur dat ntre aceleai entitti;
numele entitilor, corespondenelor, rolurilor, atributelor trebuie s fie
unice n cadrul modelului conceptual, iar apoi, n baza de date definit.

00:15

n modelul Entitate-Asociere (E-A), conform metodei gramaticale, orice


entitate semnific un substantiv, n timp ce o asociere semnific un verb. Deci pentru
gasirea asocierilor ntre tipurile de entiti, proiectantul va identifica verbele care pun
in legatura respectivele entitati. Nu este obligatoriu ca numele dat unei asocieri s fie
un verb, dar o asociere reprezint o interaciune ntre tipurile de entiti (i mulimile
de entiti corespunztoare), care poate fi exprimat printr-un verb.
De exemplu, n diagrama E-A din Figura 6.1, asocierea FACTURA-CLIENT
poate fi exprimat prin verbul se trimite.

Figura 6.1.
Un exemplu tipic de asociere unar sau reflexiv sau ciclic, este asocierea
stabilit intre realizrile aceleiasi entitati: ANGAJAT (vezi Figura 6.2.). In acest caz,
entitatea ANGAJAT joac dublu rol: este condus si conduce.

64

Figura 6.2.
In Figura 6.3. este prezentata schema unei asocieri binare. Rolul entitatii
FACTURA este de document emis, iar cel al entitatii FURNIZOR este de emitent.

Figura 6.3.
In Figura 6.4. este prezentata schema unei asocieri ternare.

Figura 6.4.
Dai exemple de alte asocieri unare, binare i ternare.
.....................................................................................................................................
....................................................................................................................................

6.4 Cardinalitatea asocierii

00:45

Cardinalitatea asocierii - exprim modul de participare al entitilor la


asociere. Putem vorbi despre o cardinalitate minim (0 sau 1) si una maxim (1 sau n).
Deci, cardinalitatea reprezinta numarul minim, respectiv maxim de realizari al
entitatilor implicate intr-o asociere. Valorile uzuale sunt: 0,1; 1,1; 0,n; 1,n.
Cardinalitatea unei asocieri poate fi de tipul:
65

1) unu-la-unu (one-to-one/biunivoc). Fiind date dou mulimi de entiti, A


i B, spunem c cele 2 multimi sunt ntr-o relaie unu-la-unu, dac unei
entiti din mulimea A i corespunde o singur entitate din mulimea B, i
reciproc; se noteaz cu 1:1 (vezi Figura 6.5, punctul a)).
2) unu-la-muli (one-to-many) - este asocierea n care unei entiti din
mulimea A i corespund una sau mai multe entiti n mulimea B, dar
unei entiti din B i corespunde o singur entitate din mulimea A; se
noteaz cu 1:N (vezi Figura 6.5, punctul b)).
3) muli-la-muli (many-to-many) - este asocierea n care unei entiti din
mulimea A i corespund una sau mai multe entiti n mulimea B, i, de
asemenea, unei entiti din B i corespund una sau mai multe entiti din
mulimea A; se noteaz cu M:N (vezi Figura 6.5, punctul c)).

Figura 6.5. - Tipuri de asocieri ntre dou mulimi de entiti


(a) Asociere 1:1; (b) Asociere 1:N; (c) Asociere M:N.

Cardinalitatea unei asocieri poate fi de tipul:


..........................................................................................................................................
.....................................................................................................................................
.....................................................................................................................................
Vom descrie n exemplele urmtoare, modalitatea prin care se stabileste cardinalitatea
unei asocieri. Considerm exemplul din Figura 6.1.:
01:05

66

Pentru entitatea FACTURA:


Identificatorul entitatii este format din 2 atribute: NrFactura si DataFactura.
Vom avea n vedere faptul c ntocmirea unei facturi trebuie s vizeze un
singur client.
Astfel, Factura cu numarul 1125 din data de 20.09.2010 se trimite unui singur
client (minim 1 client si maxim 1 client). Deci, cardinalitatea minim este 1 si
cardinalitatea maxim este 1; se noteaza langa entitatea CLIENT astfel:

Pentru entitatea CLIENT:


Identificatorul entitatii este CodClient.
Astfel, clientul cu codul 145 poate sa primeasc minim 0 facturi (este posibil
ca, ntr-o anumit perioad, s nu i se trimit nici o factur) si maxim n (este posibil s
i se trimit mai multe facturi). Deci, cardinalitatea minim este 0 si cardinalitatea
maxim este N; se noteaza langa entitatea FACTURA astfel:

01:15

Pentru fiecare grup de valori, respectiv (0, N) si (1,1), vom alege cardinalitatile
maxime, obtinand astfel valoarea (1,N).
In acest mod, am identificat cardinalitatea asocierii de tipul 1 la N sau unu la multi,
reprezentata astfel:

S ne reamintim...
Cardinalitatea asocierii - exprim modul de participare al entitilor la asociere.
Putem vorbi despre o cardinalitate minim (0 sau 1) si una maxim (1 sau n).
Valorile uzuale sunt: 0,1; 1,1; 0,n; 1,n.
Stabilii cardinalitatea asocierii : CLIENT comand PRODUS.
.....................................................................................................................................
....................................................................................................................................

67

6.5 Reguli de modelare


01:45

Consideram exemplul anterior:

In acest caz, am identificat cardinalitatea asocierii de tipul 1 la N sau unu la multi


(one-to-many).
Deci, in acest caz, am aplicat regula de modelare pentru o asociere de tipul unu la
multi, enuntata astfel:
Modelarea unei asocieri de tipul unu la multi se realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 (n cazul nostru CLIENT) se adaug entitii cu cardinalitate
N (n cazul nostru FACTURA), devenind atribut de legatura (cheie externa). Deci,
CodClient se adaug la entitatea FACTURA.
Modelati asocierea urmatoare: CLIENT emite COMANDA

Pentru exemplificarea unei asocieri de tipul N la N (muli la muli) vom folosi


asocierea de mai jos.
Vom considera cte o realizare pentru fiecare dintre cele doua entitati.

Pentru entitatea Articol_papetrie (se consider o realizare a entitii):


Un articol de papetarie cu codul 65 poate fi cuprins in minim 0 facturi (se poate
ntampla ca un anumit produs s nu mai fie comandat de clieni) sau se poate factura
de mai multe ori, adica se poate regsi n maxim N facturi. Se noteaz, lang entitatea
Factura, astfel:

68

02:15

Pentru entitatea Factura:


Factura cu numarul 652 din data de 23.07.2010, poate conine, n cantiti si la preuri
diferite, minim 1 articol de papetarie si maxim N (poate contine mai multe produse ce
urmeaza a fi livrate unui client). Se noteaz, lang entitatea Articol_papetrie, astfel:

Pentru fiecare grup de valori, respectiv (1, N) si (0,N), alegem cardinalitile maxime,
obinnd valoarea (N,N). Deci, am identificat cardinalitatea asocierii de tipul N la N
sau muli la muli, reprezentat astfel:

Pe baza exemplului anterior, putem enunta urmatoarea regula de modelare pentru o


asociere de tipul multi la multi (many to-many):
Modelarea unei asocieri de tipul N la N sau muli la muli se realizeaz astfel:
ntre cele dou entiti se introduce, n mod artificial, o noua entitate care are, ca
atribute de pornire, identificatorii celor doua entiti implicate iniial n asociere.
Pe lng aceste atribute, proiectantul sistemului va introduce i atributele
multivaloare, deci cele care exprim o cantitate, un pre etc.
Procesul de modelare al asocierii muli la muli se reprezint astfel:

69

nainte de modelare:

Dupa modelare:

02:40

S-a introdus entitatea ConinutFactura care are un identificator compus din


identificatorii celor 2 entiti, respectiv CodArticol si NrFactur, DataFactur. Aceasta
entitate a preluat si atributele multivaloare de la entitatea Factura, respectiv, Cantitate
si Pre.
S ne reamintim...
Modelarea unei asocieri de tipul unu la multi se realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 se adaug entitii cu cardinalitate N, devenind atribut de
legatura (cheie externa).
Modelarea unei asocieri de tipul N la N sau muli la muli se realizeaz astfel:

6.6 Rezumat

O asociere reprezint o expresie a modului n care una sau mai multe entitati
interactioneaz ntre ele, sau cu ele nsele.
Cardinalitatea reprezint numarul minim, respectiv maxim, de realizari al
70


02:50

entitatilor implicate ntr-o asociere.


Modelarea unei asocieri de tipul one-to-many se realizeaza astfel:
identificatorul entitatii cu cardinalitate 1 se adaug entitii cu cardinalitate N,
devenind atribut de legatura (cheie externa).
Modelarea unei asocieri de tipul many-to-many se realizeaz astfel: ntre cele
dou entiti se introduce, n mod artificial, o noua entitate care are, ca atribute
de pornire, identificatorii celor doua entiti implicate iniial n asociere.

6.7 Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Considernd entitile si asocierile din figura urmtoare, cardinalitatea
asocierii este:

CLIENT

trimite

COMANDA

a) 1:1;
b) 1:N;
c) M:N.
2. Considernd entitile si asocierile din figura urmtoare, cardinalitatea
asocierii este:

COMANDA

cuprinde

PRODUS

a) 1:1;
b) 1:N;
c) M:N.
3. Considernd entitile si asocierile din figura urmtoare, cardinalitatea
asocierii este:

CLIENT

deschide

a) 1:1;
b) 1:N;
c) M:N.

71

CONT

4.

Se consider entitile din figura de mai jos. Entitatea CLIENT are ca


identificator CodClient, iar entitatea AGENIE are ca identificator CodAgenie.
n urma modelrii asocierii se obine:

se nregistreaz

CLIENT

AGENIE

a) CodClient se adaug entitii AGENIE;


b) CodAgenie se adaug entitii CLIENT;
c) Rezult o nou entitate care are ca identificator atributele CodClient i
CodAgenie.
5. Urmtoarea afirmaie este corect:
a) Factura cu numrul 145 din data de 23.05.2010 reprezint o entitate oarecare.
b) Factura cu numrul 145 din data de 23.05.2010 reprezint o realizare a entitii
FACTURA.
c) Factura cu numrul 145 din data de 23.05.2010 reprezint un atribut complex.
Rspunsuri:
1.
2.
3.
4.
5.

b
c
b
a
b

6.8 Test de evaluare a cunotinelor


Cum se realizeaza modelarea unei asocieri de tipul many-to-many?

6.9 Bibliografie
I. Bibliografie obligatorie
1) Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2) Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti, 2013
3) Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft Access,
Editura InfoMega, Bucureti, 2012
4) Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5) Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
72

Bucureti 2000
6) Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7) Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8) Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

73

UNITATEA DE NVARE 7. RESTRICII DE INTEGRITATE ALE


MODELULUI ENTITATE-ASOCIERE
Cuprins
7.1. Obiective
7.2. Competenele unitii de nvare
7.3. Stabilirea restriciilor de integritate (RI)
7.4. Rezumat
7.5. Test de autoevaluare a cunotinelor
7.6. Test de evaluare a cunotinelor
7.7. Tema de cotrol
7.8. Bibliografie

7.1. Obiective
n aceast unitate de nvare se vor prezenta restriciile de integritate ale modelului
Entitate-Asociere.

7.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Care sunt restriciile de integritate ale modelului E-A?
Durata de parcurgere a acestei uniti de nvare este de 2 ore.

7.3. Stabilirea restriciilor de integritate (RI)

00:05

La realizarea modelului conceptual al datelor (MCD) este necesar s se in


seama de regulile pe care datele trebuie s le respecte permanent. Aceste reguli se
numesc restricii de integritate (RI) i se clasific n [Amza,2008]:
restricii la nivelul entitii;
restricii la nivelul identificatorului unei entitati;
restricii cu privire la rolurile pe care o entitate le joaca n diferitele
asocieri n care se implica;
restricii ale asocierilor.
7.3.1 Restricii de integritate la nivelul entitii
Restriciile la nivelul entitii se refer la regulile ce privesc coerena i
semantica datelor stocate n cadrul respectivei entiti.
Exemple de restricii de integritate la nivelul entitii:
eliminarea redundanelor (repetrilor) i a omonimelor n denumirea
74

entitilor, atributelor, asocierilor (unicitatea numelui entitii, atibutelor,


asocierilor);
respectarea domeniului de valori;
respectarea corelaiilor ntre valorile atributelor din entiti diferite sau
ntre
cele
din
entiti
i
din
asocieri,
cum
ar
fi:
cantitate_facturat+10<=cantitate_stoc pentru fiecare articol facturat.
7.3.2 Restricii de integritate la nivelul identificatorului unei entitati
Restriciile la nivelul identificatorului unei entitati se refer la faptul c
valorile pe care le poate lua un identificator, trebuie s fie unice i nenule.
7.3.3 Restricii de integritate la nivelul rolului unei entitati

00:20

Restriciile cu privire la rolurile asumate de o entitate n diferitele asocieri


n care este implicat, sunt de 3 tipuri:
1) Incluziunea de roluri
2) Excluziunea de roluri
3) Egalitatea de roluri
1) Incluziunea de roluri exprim faptul c un rol al entitii ntr-o asociere
impune un alt rol al su ntr-o a doua asociere.
Altfel spus, dac o entitate E1 joac rolul r1 n asocierea A1, atunci va trebui
sa joace si rolul r2 n asocierea A2.
Simbol:

r1

r2

Exemplu: Un client pltete numai dac anterior a primit factura, dar nu toate
facturile primite se si pltesc.

Figura 7.1.
75

2) Excluziunea de roluri exprim faptul c, n anumite situaii, roluri ale


aceleiai entiti se exclud reciproc.
Altfel spus, o entitate E1 care joac rolul r1 n asocierea A1 nu poate juca
rolul r2 n asocierea A2.
Simbol:

r1

r2

Exemplu: O factur nu poate fi emis de furnizor i trimis clientului n acelai


timp, deci cele dou roluri ale entitii FACTURA se exclud reciproc.

00:40

Figura 7.2.
Excluziunea de roluri exprim faptul c :
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
3) Egalitatea de roluri exprim o restricie de incluziune reciproc ntre
dou roluri ale aceleiai entiti.

Simbol:

r1

r2
=

76

Exemplu:

Figura 7.3.
Furnizai i alte exemple n care s evideniai restriciile cu privire la rolurile
asumate de o entitate n diferite asocieri:
.........................................................................................................................................
.........................................................................................................................................
........................................................................................................................................
S ne reamintim...
Restriciile cu privire la rolurile asumate de o entitate n diferitele asocieri n care
este implicat, sunt de 3 tipuri:
1) Incluziunea de roluri
2) Excluziunea de roluri
3) Egalitatea de roluri
7.3.4 Restricii ale asocierilor

01:10

Restriciile asocierilor vizeaz att asocierea ct si toate entitatile


participante la asociere. Acioneaz asupra tuturor rolurilor dintr-o asociere.
Aceleai restricii care se aplic rolurilor, le gsim i n cazul asocierilor:
restricii de incluziune, excluziune i egalitate de asocieri.
1)

Restrictii de incluziune de asocieri

Asocierea A1 stabilita ntre doua entitati determina existenta unei alte asocieri
A2 n cadrul modelului E-A.
Formalismul grafic pentru reprezentarea acestei restricii este prezentat n Figura
7.4.

77

Figura 7.4.

2) Restrictii de excluziune de asocieri


Asocierea A1 stabilita ntre doua entitati interzice existenta unei alte asocieri A2
n cadrul modelului E-A.
Formalismul grafic pentru reprezentarea acestei restricii este prezentat n Figura
7.5.

01:25

Figura 7.5.
3) Restrictii de egalitate de asocieri
Asocierea A1 stabilita ntre doua entitati impune existenta unei alte asocieri A2
n cadrul modelului E-A.
78

Formalismul grafic pentru reprezentarea acestei restricii este prezentat n Figura


7.6.

Figura 7.6.
S ne reamintim...
Restriciile asocierilor vizeaz att asocierea ct si toate entitatile participante la
asociere. Acioneaz asupra tuturor rolurilor dintr-o asociere.
Aceleai restricii care se aplic rolurilor, le gsim i n cazul asocierilor: restricii de
incluziune, excluziune i egalitate de asocieri.
Dai exemple n care s evideniai restricii ale asocierilor, indicnd rolul pe care
l are fiecare entitate n asocierea respectiv:
...
...
...

7.4 Rezumat

01:50

La realizarea modelului conceptual al datelor (MCD) trebuie s se in


seama de regulile pe care datele trebuie s le respecte permanent. Aceste
reguli se numesc restricii de integritate (RI) i se clasific n:
restricii la nivelul entitii;
restricii la nivelul identificatorului unei entitati;
restricii cu privire la rolurile pe care o entitate le joaca n diferitele
asocieri n care se implica;
restricii ale asocierilor.
Restriciile la nivelul entitii se refer la regulile ce privesc coerena i
79

semantica datelor stocate n cadrul respectivei entiti.


Restriciile la nivelul identificatorului unei entitati se refer la faptul c valorile
pe care le poate lua un identificator, trebuie s fie unice i nenule.
Restriciile cu privire la rolurile asumate de o entitate n diferitele asocieri n
care este implicat, sunt de 3 tipuri:
Incluziunea de roluri
Excluziunea de roluri
Egalitatea de roluri
Restriciile asocierilor vizeaz att asocierea ct si toate entitatile participante
la asociere. Acioneaz asupra tuturor rolurilor dintr-o asociere.
Aceleai restricii care se aplic rolurilor, le gsim i n cazul asocierilor:
restricii de incluziune, excluziune i egalitate de asocieri.

7.5. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1. Considerm entitile si asocierile din figura urmtoare. Se cunosc
identificatorii celor dou entitti, i anume: CodClient pentru entitatea CLIENT
i NrComanda pentru entitatea COMANDA precum urmtoarele dou reguli de
gestiune: o comanda vine de la un singur client si un client poate s trimit una
sau mai multe comenzi. Ca urmare a modelrii asocierii rezult decizia:

CLIENT

trimite

COMANDA

a) CodClient se adaug entitatii COMANDA;


b) NrComanda se adaug entitatii CLIENT;
c) Se introduce o entitate suplimentar.
2. Se consider entitile din figura urmtoare. Identificatorii celor dou entitti
sunt: NrComanda pentru entitatea COMANDA si CodProdus pentru entitatea
PRODUS. Ca urmare a modelrii asocierii rezult decizia:
COMANDA

cuprinde

PRODUS

a) CodProdus se adaug entitatii COMANDA;


b) NrComanda se adaug entitatii PRODUS;
c) Se introduce o entitate suplimentar ce are ca atribute CodProdus si
NrComanda.
3. Restriciile cu privire la rolurile asumate de o entitate n diferitele asocieri n
care este implicat, sunt:
a) Incluziunea, excluziunea i egalitatea de roluri;
80

b) Restricii la nivelul identificatorului unei entiti;


c) Incluziunea, excluziunea i egalitatea de asocieri.
4. Restriciile asocierilor sunt:
a) Incluziunea, excluziunea i egalitatea de asocieri;
b) Restricii la nivelul identificatorului unei entiti;
c) Restricii la nivelul entitii.
Rspunsuri:
1. a
2. c
3. a
4. a

7.6. Test de evaluare a cunotinelor


De cate tipuri sunt restriciile cu privire la rolurile asumate de o entitate n diferitele
asocieri n care este implicat?
Dati exemple de astfel de restrictii.

7.7 Tema de control


ntocmii un scurt referat n care s evideniai restriciile la nivelul rolului unei entitati
si restriciile asocierilor, indicnd rolul pe care l are fiecare entitate n asocierea
respectiv.

7.8. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft Access,
Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
81

Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des traitements,
langage SQL), Nouvelle dition, Ressources informatiques, Informatique Technique,
2009.

82

UNITATEA DE NVARE 8. MODELUL RELAIONAL AL DATELOR


(MODELUL LOGIC AL DATELOR)
Cuprins
8.1. Obiective
8.2. Competenele unitii de nvare
8.3. Conceptele de baz ale modelului logic al datelor (MLD)
8.4. Reguli de conversie de la MCD la MLD
8.5. Modelul fizic al datelor (MFD)
8.6. Rezumat
8.7. Test de autoevaluare a cunotinelor
8.8 Bibliografie

8.1. Obiective
Aceast unitate de nvare are obiectivele urmatoare:
nsuirea conceptelor utilizate de MLD;
nsuirea regulilor de conversie de la MCD la MLD.

8.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Care sunt conceptele utilizate de modelul logic al datelor?
Care sunt regulile de conversie din modelul conceptual al datelor n modelul
logic al datelor?
Ce presupune modelul fizic al datelor?
Durata de parcurgere a acestei uniti de nvare este de 2 ore.

8.3. Conceptele de baz ale modelului logic al datelor (MLD)

00:05

Trecerea de la MCD, care este un model universal, spre o soluie informatic


se face gradat, lund n considerare un anumit tip de soluie i apoi, n cadrul tipului
respectiv, o soluie direct implementabil.
Expresia MCD, n termenii unui anumit tip de soluie informatic, constituie
modelul relaional (MRD) sau modelul logic al datelor (MLD).
Conceptele de baz ale MRD sunt:
Modelul relaional are la baz conceptul de relaie definit n teoria
matematic a mulimilor ca fiind o submulime a produsului cartezian al mai multor
mulimi, numite domenii.
Domeniul reprezint multimea tuturor valorilor posibile care definesc o
anumit proprietate a unui obiect.
83

Domeniul poate fi exprimat explicit (se enumer valorile posibile D:{M, F})
sau implicit (se precizeaz proprietile valorilor D:{x/xN}).
Atributul este o submulime a unui domeniu, reprezentnd multimea
valorilor existente la un moment dat n coloana pe care o desemneaz n cadrul
relaiei. Fiecrui atribut i se atribuie un nume. Numele exprim rolul sau
semnificaia elementelor domeniului respectiv.
Relaiile se reprezint grafic sub form de tabele, n care se disting:
gradul relaiei - numrul de atribute (coloane) utilizate;
cardinalitatea relaiei - numrul de tupluri (linii n tabel).
Cardinalitatea unei relaii este variabil n timp datorit operaiilor de
actualizare care pot aduga sau terge tupluri.
Tabelele trebuie s tin seama de urmtoarele restricii:
Ordinea liniilor (tuplurilor) dintr-o tabel nu este predefinit i nu sunt
admise duplicate;
Coloanele sunt identificate prin nume distincte ce reprezint atributele
relaiei;
n fiecare coloan toate valorile sunt de acelai fel;
Fiecare valoare este un numr sau un ir de caractere.
Schema tabelei este reprezentat prin numele tabelei, urmat ntre paranteze
rotunde de lista atributelor.
Exemplu: Fie tabela Angajat cu atributele: MARCA, NUME, PRENUME,
DATA_NATERE.
Angajat (MARCA,NUME,PRENUME,DATA_NATERE)

00:15

Figura 8.1. Tabela Angajat


Pentru o relaie pot exista 3 tipuri de chei:
cheie primar: cel mai mic ansamblu de atribute (eventual unul singur) care
permite identificarea fr univoc al fiecrui tuplu al unei relaii; atributele
84

care compun cheia primar nu pot s ia valoarea NULL.


cheie candidat: o alt posibil cheie primar, care nu a fost ns reinut ca
atare.
cheie extern: un ansamblu de atribute (eventual unul singur) care este cheie
primar ntr-o alt relaie.

Restricie de integritate referenial (RIR): dac ntre un atribut A i o


cheie primar B exist o RIR atunci A nu poate lua dect valori care exist i n B.
Prin definiie, cheile externe sunt supuse RIR n raport cu cheile primare
corespunztoare.
Identificai conceptele de baz ale modelului relaional al datelor.
...........................................................................................................................................
...........................................................................................................................................
...........................................................................................................................................
S ne reamintim...
Cheia primar reprezinta cel mai mic ansamblu de atribute (eventual unul singur)
care permite identificarea fr univoc al fiecrui tuplu al unei relaii; atributele care
compun cheia primar nu pot s ia valoarea NULL.

8.4 Reguli de conversie de la MCD la MLD


00:30

Trecerea de la MCD la MLD ine seama de dou tipuri de reguli principale, reguli
care se refer la distribuia datelor pe tipuri de entiti, precum i de cardinalitile
prezentate de asocierile tipului de entitate. Aceste elemente metodologice poart
denumirea de reguli de conversie (reguli de transformare).
Regula 1. Fiecare entitate din MCD se transform, n MLD, ntr-o tabel, cu un nume
distinct. Tabela este perceput ca o asociere ntre mai multe atribute care
caracterizeaz acelai tip de entitate.
Regula 2. Fiecare atribut ce caracterizeaz o entitate n MCD se transform, n MLD,
ntr-o coloan ce apartine tabelei corespunztoare respectivei entiti, iar fiecrei
asocieri, din MCD, i corespunde o legtur n MLD.
Regula 3. Fiecare identificator al unei entitti din MCD se va transforma, n MLD, n
cheia primar a tabelei respective. Cheile primare se simbolizeaz n MLD prin
subliniere cu o linie continu.
Regula 4. Fiecare regula de domeniu din MCD privitoare la un anumit atribut a unei
entitati se tranforma ntr-o restrictie de integritate referential la nivelul tabelei
corespunzatoare n MLD.
85

Regula 5. Fiecarui atribut rezultat n MCD, ca urmare a modelarii unei asocieri


(atribute importate din alte entitati) i va corespunde n MLD o cheie externa. Cheile
externe se simbolizeaz n MLD prin subliniere cu o linie punctat.
Regula 6. n cazul n care dou tipuri de entitate prezint pentru o asociere
cardinalitatea (1,1), n mod normal fiecare entitate poate primi drept cheie extern,
cheia primar a celeilalte entitai. n realitate, n practic, se ine cont de ordinea de
apariie a fiecrui tip de entitate.
Regula 7. n cazul n care dou tipuri de entitate au o asociere de tipul (1,N), cheia
primar a tabelei care prezint la asociere cardinalitatea maxim 1 va deveni cheie
extern n tabela care prezint la asociere cardinalitatea maxim N.
Exemplu:

Aplicnd aceast regul, pentru acest MCD vom avea urmtorul MLD:
Angajat (Marca, Nume, Prenume, Adresa, CodAgenie)
Agenie (CodAgenie, Adresa, Telefon)
Regula 8. n cazul n care dou entiti prezint o asociere de tipul (N,M), entitatea
nou format se transform ntr-o tabel avnd obligatoriu cheia primar constituit
din identificatorii entitilor participante la asociere (cheile primare ale celor dou
tabele). Totodat, atributele proprii ale asocierii devin cmpuri n tabela nou
determinat.
Exemplu:
00:50

MLD se prezint astfel:


86

Poli_asigurare (NrPoli, Data_nceput, Data_scadent)


Risc (CodRisc, DenumireRisc, Franiz)
Continut_poli (NrPoli,CodRisc)

Identificai regulile de conversie de la MCD la MLD.


........................................................................................................................................
........................................................................................................................................
........................................................................................................................................
S ne reamintim...
Regulile de conversie de la MCD la MLD se refer la distribuia datelor pe tipuri de
entiti, precum i de cardinalitile prezentate de asocierile tipului de entitate.

8.5 Modelul fizic al datelor (MFD)

01:20

Proiectarea unei baze de date presupune realizarea modelelor conceptual, logic


i fizic, prin trecerea de la MCD la MLD, apoi, de la MLD la MFD.
Modelul fizic este cel ce corespunde structurii n care sunt stocate datele. Sunt
specificate tabelele (fiierele) care le contin (nume, organizare, localizare etc.),
componentele fiecrui fiier (lungime, cmpuri etc.), cile de acces la componentele
tabelelor (indeci, relaii, legturi ntre tabele). De asemenea trebuie s se tin seama
de cerintele privind asigurarea protectiei datelor. Trecerea de la MLD la MFD se face
utiliznd facilittile i instrumentele oferite de SGBD-ul ales.
Astfel, modelarea fizic impune analizarea urmatoarelor aspecte [Amza 2008]:
a) Alegerea SGBD-ului pe care se va realiza implementarea;
b) Alegerea instrumentelor de dezvoltare (limbaje de programare);
c) Alegerea sistemelor de operare si a platformelor pe care va rula aplicatia;
d) Proiectarea machetelor de preluare si validare a datelor;
e) Descrierea fizica a tabelelor, a restrictiilor de integritate referentiala legate de
aceste tabele;
f) Stabilirea cheilor primare si a legaturilor dintre tabele;
g) Implementarea fizica a procedeelor de prelucrare a datelor;
h) Implementarea aspectelor legate de securitatea datelor.
Avnd n vedere c, SGBD Access implementeaz n totalitate teoria modelului
relational, trecerea de la MLD la MFD se face astfel:

Relatiile se transpun n tabele;


87

Legturile dintre tabele sunt asigurate prin corespondentele ntre cheile


primare i cheile externe.

Identificai etapele principale n proiectarea unei baze de date.


......................................................................................................................................
......................................................................................................................................
......................................................................................................................................

01:40

In concluzie, modelul fizic al datelor se obine prin reprezentarea MLD ntrun limbaj de descriere a datelor asociat strict unui SGBD. Practic, un SGBD va
utiliza acest MFD pentru operaii de creare, actualizare, exploatare, listare,
reorganizare, salvare, restaurare, protecie etc.
Deci MFD este asociat unui SGBD care are urmtoarele obiective
referitoare la date:
neredundana datelor;
coerena datelor;
partajarea datelor;
securitatea datelor.
S ne reamintim...
Pentru un SGBD Access care implementeaz n totalitate teoria modelului
relational, trecerea de la MRD la MFD se face astfel:
Relatiile se transpun n tabele;
Legturile dintre tabele sunt asigurate prin corespondentele ntre cheile
primare i cheile externe.

8.6 Rezumat

01:50

Pentru o relaie pot exista 3 tipuri de chei:


cheie primar: cel mai mic ansamblu de atribute (eventual unul
singur) care permite identificarea fr univoc al fiecrui tuplu al unei
relaii; atributele care compun cheia primar nu pot s ia valoarea
NULL.
cheie candidat: o alt posibil cheie primar, care nu a fost ns
reinut ca atare.
cheie extern: un ansamblu de atribute (eventual unul singur) care
este cheie primar ntr-o alt relaie.
Restricie de integritate referenial (RIR): dac ntre un atribut A i o
cheie primar B exist o RIR atunci A nu poate lua dect valori care exist
i n B. Prin definiie, cheile externe sunt supuse RIR n raport cu cheile
primare corespunztoare.
Proiectarea unei baze de date presupune realizarea modelelor conceptual,
logic i fizic, prin trecerea de la MCD la MLD, apoi, de la MLD la MFD;
Regulile de conversie MCD-MLD se aplica doar dupa ce a fost obtinut
MCD-ul n scopul obtinerii MLD.
88

Regulile de conversie de la MCD la MLD se refer la distribuia datelor pe


tipuri de entiti, precum i de cardinalitile prezentate de asocierile tipului
de entitate.

8.7. Test de autoevaluare a cunotinelor


(timp necesar : 10 minute)
1. Trecerea de la MCD la MLD presupune c fiecarei entitti din MCD, i
corespunde, n MLD, urmtorul concept:
a) tabel;
b) coloan;
c) cheie extern.
2. Trecerea de la MCD la MLD presupune c fiecrui atribut din MCD, i
corespunde, n MLD, urmtorul concept:
a) tabel;
b) coloan;
c) cheie extern.
3. Trecerea de la MCD la MLD presupune c fiecrui identificator din MCD, i
corespunde, n MLD, urmtorul concept:
a) tabel;
b) cheie extern;
c) cheie primar.
4. n MLD, o linie dintr-o tabel se numete:
a) cheie extern;
b) cheie primar;
c) tuplu.
5. n MLD, o tabel se mai numete:
a) relaie;
b) legtur;
c) tuplu.
6. Urmtoarea afirmaie este corect:
a) La trecerea de la MCD la MLD, unei asocieri i corespunde o relatie.
b) La trecerea de la MCD la MLD, unei asocieri i corespunde o legtur.
c) La trecerea de la MCD la MLD, unei asocieri i corespunde o coloan.
Rspunsuri:
1. a
2. b

89

3. c
4. c
5. a
6. b

8.8. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft Access,
Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

90

UNITATEA DE NVARE 9. MODELUL ENTITATE-ASOCIERE EXTINS


Cuprins
9.1. Obiective
9.2. Competenele unitii de nvare
9.3. Generalizarea i specializarea
9.4. Reprezentarea timpului
9.5. Rezumat
9.6. Test de autoevaluare a cunotinelor
9.7. Test de evaluare a cunotinelor
9.8. Bibliografie

9.1. Obiective
n aceast unitate de nvare se vor prezenta conceptele de baza ale modelului
entitate-asociere extins.

9.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s rspundei la ntrebrile:
Care sunt conceptele de baza ale modelului entitate-asociere extins?
Ce reprezinta generalizarea?
Ce reprezinta specializarea?
Durata de parcurgere a acestei uniti de nvare este de 3 ore.

9.3. Generalizarea i specializarea

00:05

n scopul extinderii capacitii de modelare a cunotinelor din modelul EA,


au fost propuse mai multe modele semantice pentru date. n cele mai multe dintre
acestea, a fost urmrit includerea unor modaliti de modelare care s permit ca n
proiectarea structurii conceptuale s se in seama la un anumit nivel superior de
restriciile semantice. n acest context, a aprut modelul entitate asociere extins
(EAE), care dezvolt modelul EA original prin folosirea unor proceduri mai
avansate de modelare conceptual, proceduri aplicate de modelele semantice de
date.
n modelul EAE, tipurile de entitate (sau mulimile entitate) poart numele
de clase, ele putnd forma superclase (supertipuri) i subclase (subtipuri), legate
printr-o asociere IS-A. O asociere IS-A este un concept n care o subclas este un tip
specializat a unei superclase, iar o superclas este un tip mai generalizat al unei
subclase.

91

Cum sunt denumite tipurile de entitati din cadrul modelului EAE?


.
.
.

00:25

Sunt considerate extensii ale modelului entitate-asociere urmtoarele


concepte [Amza, 2008]:
specializarea
generalizarea
reprezentarea (modelarea) timpului.
Pentru explicarea conceptelor vom lua n considerare urmtorul exemplu:

Figura 8.1 Exemplu de reprezentare a legturilor dintre superclase i subclase


Analizand exemplul anterior, putem enunta urmatoarea definitie pentru specializare.
Specializarea este un proces de abstractizare a datelor prin care, pornind de la un tip
de entitate dat, se definesc unul sau mai multe subtipuri, diferentiate ntre ele n
functie de rolul specific pe care l au n modelul de date.
92

01:00

In exemplul anterior, pornind de la tipul de entitate PERSOANE se definesc


prin specializare subtipurile: STUDENT, PROFESOR, PENSIONAR, pentru a
diferentia functiile pe care persoanele le pot avea (Fig. 8.1).
Subtipurile de entitati mostenesc atribute ale tipului initial si fiecare dintre
ele are atribute suplimentare, specifice rolului lor.
De exemplu, atributele: (Marca, CNP, Nume, Prenume, Initiale,
Data_nastere, Adresa) ale tipului de entitate PERSOANE sunt mostenite de fiecare
din subtipurile acestuia. Atributul Stadiu_persoane nu este mostenit, deoarece
specializarea subtipurilor s-a efectuat dupa acest atribut.
Ca atribute specifice, subtipul STUDENT are atributele: (Facultatea,
Situatie_curs, Nr_cursuri, Anul_absolvirii, Media_generala), care reprezinta
atributele specifice stadiului de student, subtipul PROFESOR are atributele:
(Data_start_angajare,
Data_end_angajare,
Functia,
Titlul,
Departament,
Salariu_baza), care reprezinta atributele specifice stadiului de profesor, fiind o
precizare a domeniului n care lucreaza persoana respectiva, iar subtipul
PENSIONAR are atributele:
(Data_pensionarii, Cuantum_pensie, Nr_talon,
Motiv_pensionare, Vechime_munca), reprezentand atributele specifice stadiului de
pensionar.
S ne reamintim...
Sunt considerate extensii ale modelului entitate-asociere urmtoarele concepte:
generalizarea, specializarea si reprezentarea (modelarea) timpului.

Specializarea reprezinta :

Generalizarea reprezint procesul prin care un proiectant identific un


grup de entiti care au n structura lor aceleai atribute i creeaz pe baza acestora
o nou entitate numit superclas (supertip) a entitii de baz.
Altfel spus, generalizarea este procesul de abstractizare invers specializarii, prin
care se creaza un supertip de entitate pornind de la mai multe tipuri de entitati.
Pentru definirea unei generalizari, se identifica atributele comune ale mai
multor tipuri de entitati, atribute ce vor caracteriza supertipul de entitate, iar
atributele care difera de acestea ramn specifice fiecarui tip.
In exemplul anterior (fig. 8.1.), fiind date tipurile de entitati:
STUDENT(Marca, CNP, Nume, Prenume, Initiale, Data_nastere, Adresa,
Facultatea, Situatie_curs, Nr_cursuri, Anul_absolvirii, Media_generala);
PROFESOR(Marca, CNP, Nume, Prenume, Initiale, Data_nastere, Adresa,
93

Data_start_angajare,
Data_end_angajare,
Functia,
Titlul,
Departament,
Salariu_baza);
PENSIONAR(Marca, CNP, Nume, Prenume, Initiale, Data_nastere, Adresa,
Data_pensionarii, Cuantum_pensie, Nr_talon, Motiv_pensionare, Vechime_munca);
se poate defini un supertip al acestor tipuri: PERSOANE(Marca, CNP, Nume,
Prenume, Initiale, Data_nastere, Adresa, Stadiu_persoane).
Acest tip va cuprinde toate atributele comune, iar tipurile initiale,
STUDENT, PROFESOR si PENSIONAR, devin subtipuri ale tipului PERSOANE,
fiecare continnd atributele specifice.
Rezultatul obtinut prin generalizare este ca si n cazul specializarii, o ierarhie
de tipuri de entitati, ceea ce difera este modul n care se definesc nivelurile ierarhiei.
Specializarea, la randul ei, este procesul invers generalizrii.
Generalizarea reprezinta :

S ne reamintim...
Pentru definirea unei generalizari, se identifica atributele comune ale mai
multor tipuri de entitati, atribute ce vor caracteriza supertipul de entitate, iar
atributele care difera de acestea ramn specifice fiecarui tip.
Mostenirea atributelor.

01:30

Proprietatea principala a ierarhiilor de tipuri de entitati create prin


specializare sau generalizare reprezinta mostenirea atributelor: atributele tipurilor
de entitati de nivel ridicat (supertipuri) sunt mostenite de tipurile de entitati de nivel
scazut (subtipuri).
Mostenirea dintre un subtip de entitati si supertipul acestuia se reprezinta n
diagrama E-A extinsa printr-o legatura (link) ntre subtip si supertipul de entitate
corespunzator pe care este plasat un semicerc orientat catre subtip (fig. 8.2).

Figura 8.2. Reprezentarea mostenirii atributelor


94

In exemplul anterior (fig. 8.2.) PERSOANE este clasa rdcin, sau clasa de
baz. Simbolul reprezint direcia asocierii IS-A.
Litera d, nscrisa n cercul care leaga subclasele de superclasa, indica o
constrngere de disjunctie impusa specializarii, prezentata in cele ce urmeaza.
Mostenirea atributelor se caracterizeaza prin:

Constrngeri impuse specializarii si generalizarii


Restrictii ce trebuie impuse n cazul specializarii sau al generalizarii
Prima conditie se numeste regula disjunctiei. Aceasta regula specifica daca
subclasele unei clase sunt disjuncte, adica daca un membru al superclasei apartine cel
mult uneia dintre subclase. O specializare disjuncta se reprezinta cu un d nscris n
cercul care leaga subclasele de superclase.
n exemplul nostru, subclasele STUDENT, PROFESOR si PENSIONAR care sunt subclasele clasei PERSOANE - sunt disjuncte (fig. 8.2).
Daca subclasele nu sunt disjuncte, adica daca un membru al superclasei poate
sa apartina la mai multe subclase, atunci subclasele respective se numesc non
disjuncte si se noteaza cu o n cercul care leaga subclasele de superclase.
A doua conditie (a specializarii) este regula participarii, care poate fi totala
sau partiala. Participarea este totala daca toti membrii superclasei sunt si membri ai
subclaselor. Pentru reprezentarea participarii totale, arcul de la superclasa, situat la
cercul dintre superclasa si subclasa, se dubleaza.
n cazul participarii partiale nu toti membrii superclasei apartin unei subclase.
Acest tip de participare se reprezinta cu linie simpla ntre superclasa si cerc.
Cele doua reguli se aplica distinct la procesele de specializare, sau
generalizare. De aceea putem avea, de exemplu, patru tipuri de specializari: disjuncta
totala, disjuncta partiala, non disjuncta totala, sau non disjuncta partiala.

9.4. Reprezentarea timpului

02:00

Exist situaii n care domeniul de modelare necesit stocarea unor informaii


de istoric sau de evoluie. n general, modelele de date ofer o imagine static asupra
datelor unui anumit domeniu.
n scopul modelrii timpului este necesar introducerea unor entiti
specializate care s stocheze informaiile de istoric sau de evoluie a unui anumit
fenomen. Aceste entiti nu pot fi identificate dect analiznd cerinele utilizatorului
respectivului sistem.
Pentru explicarea acestui concept, vom lua n considerare urmtorul exemplu:
95

Figura 8.3 Exemplu de modelare a unor informaii de istoric

02:20

Analiznd exemplul putem observa c entitatea PROFESOR aa cum este


modelat, nu ofer informaii dinamice privitoare la istoric. Asfel, dac se dorete
urmrirea evoluiei salariului i al locurilor de munc, este necesar modelarea
timpului cu introducerea unor entiti cu caracter istoric.
Entitile care realizeaz modelarea timpului, trebuie s conin informaiile
privitoare la timp (data, ziua, luna, anul, perioada de lucru etc.).
Din punct de vedere al reprezentrii timpului ntr-o entitate, putem avea
reprezentari sincrone si reprezentri diacronice [Amza, 2008]. De exemplu, pentru
ntocmirea unei facturi vom avea o reprezentare diacronic deoarece ne intereseaz
data la care s-a ntocmit factura. n unele situaii, nu ne intereseaz cu exactitate
momentul producerii unui anumit eveniment, caz n care se poate recurge la o
reprezentare sincron. De exemplu, reeta unui anumit produs nu are nevoie de
reprezentarea datei. Dac se dorete ns o reprezentare a evoluiei unei reete n
timp, atunci va trebui sa modelm timpul.
Este evidenta asemanarea dintre ierarhiile de tipuri de entitati din modelul EA extins si ierarhiile de clase din modelul orientat-obiect, dar modelul E-A extins
este un model de date mult mai general (de nivel nalt), care poate fi transpus n
diferite modele de date specializate, inclusiv modelul orientat-obiect. Aceste
transpuneri se fac n functie de suportul oferit de modelul specializat respectiv pentru
reprezentarea entitatilor, asocierilor, mostenirilor etc.
Sa ne reamintim...
Constrngerile impuse specializarii si generalizarii sunt urmatoarele:
regula disjunctiei - specifica daca subclasele unei clase sunt disjuncte, adica
daca un membru al superclasei apartine cel mult uneia dintre subclase.
regula participarii, care poate fi totala sau partiala. Participarea este totala
daca toti membrii superclasei sunt si membri ai subclaselor.
96

Furnizai i alte exemple n care s evideniai restriciile impuse specializarii si


generalizarii::
.......................

9.5. Rezumat

02:45

n modelul EAE, tipurile de entitate (sau mulimile entitate) poart numele de


clase, ele putnd forma superclase (supertipuri) i subclase (subtipuri), legate
printr-o asociere IS-A.
O asociere IS-A este un concept n care o subclas (subtip) este un tip
specializat a unei superclase (supertip), iar o superclas este un tip mai
generalizat al unei subclase.
Sunt considerate extensii ale modelului entitate-asociere urmtoarele
concepte: generalizarea, specializarea si reprezentarea (modelarea) timpului.
Specializarea este un proces de abstractizare a datelor prin care, pornind de la
un tip de entitate dat, se definesc unul sau mai multe subtipuri, diferentiate
ntre ele n functie de rolul specific pe care l au n modelul de date.
Generalizarea reprezint procesul prin care un proiectant identific un grup
de entiti care au n structura lor aceleai atribute i creeaz pe baza acestora
o nou entitate numit superclas (supertip) a entitii de baz.
Proprietatea principala a ierarhiilor de tipuri de entitati create prin
specializare sau generalizare reprezinta mostenirea atributelor: atributele
tipurilor de entitati de nivel ridicat (supertipuri) sunt mostenite de tipurile de
entitati de nivel scazut (subtipuri).
Constrngerile impuse specializarii si generalizarii sunt urmatoarele: regula
disjunctiei (specifica daca subclasele unei clase sunt disjuncte, adica daca un
membru al superclasei apartine cel mult uneia dintre subclase) si regula
participarii, care poate fi totala sau partiala. Participarea este totala daca toti
membrii superclasei sunt si membri ai subclaselor.

9.6. Test de autoevaluare a cunotinelor


(timp necesar : 20 minute)
1.
2.
3.
4.
5.
6.

Ce reprezinta o asociere de tip IS-A ?


Cum definim specializarea?
Ce reprezinta generalizarea?
Care sunt extensiile modelului entitate-asociere?
Cum explicati proprietatea de mostenire a atributelor?
Care sunt restrictiile ce trebuie impuse n cazul specializarii sau al
generalizarii?

Rspunsuri:
1. O asociere IS-A este un concept n care o subclas este un tip specializat a
97

unei superclase, iar o superclas este un tip mai generalizat al unei subclase.
2. Specializarea este un proces de abstractizare a datelor prin care, pornind de la
un tip de entitate dat, se definesc unul sau mai multe subtipuri, diferentiate
ntre ele n functie de rolul specific pe care l au n modelul de date.
3. Generalizarea reprezint procesul prin care un proiectant identific un grup de
entiti care au n structura lor aceleai atribute i creeaz pe baza acestora o
nou entitate numit superclas (supertip) a entitii de baz.
4. Sunt considerate extensii ale modelului entitate-asociere urmtoarele
concepte: generalizarea, specializarea si reprezentarea (modelarea) timpului.
5. Prin proprietatea de mostenire a atributelor: atributele tipurilor de entitati de
nivel ridicat (supertipuri) sunt mostenite de tipurile de entitati de nivel scazut
(subtipuri).
6. Restrictiile impuse specializarii si generalizarii sunt urmatoarele: regula
disjunctiei (specifica daca subclasele unei clase sunt disjuncte, adica daca un
membru al superclasei apartine cel mult uneia dintre subclase) si regula
participarii, care poate fi totala sau partiala. Participarea este totala daca toti
membrii superclasei sunt si membri ai subclaselor.

9.7. Test de evaluare a cunotinelor


Care sunt restrictiile impuse specializarii? Exemplificati prin exemple.

9.8. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria,
Bucureti, 2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice,
Ed. Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.

98

II. Bibliografie facultativ


1.

Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des


traitements, langage SQL), Nouvelle dition, Ressources informatiques,
Informatique Technique, 2009.

99

UNITATEA DE NVARE 10. STUDIU DE CAZ PROIECTAREA


UNUI SISTEM INFORMATIC PENTRU MONITORIZAREA
CONSUMULUI DE MATERII PRIME
Cuprins
10.1. Obiective
10.2. Competenele unitii de nvare
10.3. Descrierea problemei de modelat si a cerintelor sistemului informatic
10.4. Identificarea entitatilor din textul problemei de modelat
10.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri. Modelarea asocierilor
10.6. Realizarea modelului conceptual al datelor (MCD)
10.7. Realizarea modelului relational al datelor (MRD)
10.8. Rezumat
10.9. Test de evaluare a cunotinelor
10.10. Teme de control
10.11. Bibliografie

10.1. Obiective
n aceast unitate de nvare sa va prezenta un studiu de caz in care se va
analiza si proiecta un sistem informatic pentru monitorizarea consumurilor de materii
prime la o firma de productie.

10.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s:
1. nelegei cum se realizeaza analiza funcional a unui sistem informatic
conform cerintelor care trebuiesc ndeplinite de sistem.
2. nelegei cum se identifica restriciile i cum se analizeaza efectul acestora
asupra eficienei sistemului.
3. nelegei cum se realizeaza modelarea unui sistem informatic plecnd de la
datele furnizate de analiza sistemului.

Durata medie de parcurgere a uniti de nvare este de 2 ore.

100

10.3. Descrierea problemei de modelat si a cerintelor sistemului


informatic

00:05

O firma de productie doreste sa implementeze un sistem informatic de


monitorizare a consumurilor de materii prime. Proiectantului sistemului informatic i se
furnizeaza urmatoarea descriere nsotita de macheta documentului Bon de consum:
Pentru obtinerea unui produs finit trebuie sa se consume mai multe materii
prime. Consumul acestor materii prime se face de-a lungul ntregului proces de
productie.
O materie prima anume se stocheaza numai ntr-o singura gestiune. Eliberarea
unei materii prime dintr-o gestiune se face numai prin intermediul unui bon de consum.
Un bon de consum poate sa contina mai multe materii prime dar toate din aceeasi
gestiune. De fiecare gestiune raspunde un gestionar. ntr-un proces de productie pot fi
eliberate oricte bonuri de consum.
Macheta documentului Bon de consum este redata n continuare:

Figura 10.1 - Macheta documentului Bon de consum


Cerinte:
Sa se identifice entitatile.
Sa se identifice atributele entitatilor.
Sa se stabileasca identificatorii entitatilor.
Sa se identifice asocierile dintre entitati.
Sa se stabileasca cardinalitatea asocierilor.
Sa se modeleze asocierile identificate.
Sa se ntocmeasca modelul conceptual al datelor (MCD).
101

Sa se realizeze conversia MCD in MRD (modelul relational al datelor).

10.4. Identificarea entitatilor din textul problemei de modelat si a


atributelor care descriu entitatile respective
In urma analizei textului problemei de modelat, se pot identifica urmatoarele entitati:
1)
2)
3)
4)

00:20

MATERII_PRIME
GESTIUNE
BON_CONSUM
CONTINUTBON_CONSUM (provine in urma modelarii unei asocieri de tip N
la N)

Aceste entitati vor fi descrise prin urmatoarele atribute:


1) MATERII_PRIME(CodMateriiPrime, DenumireMateriiPrime, UM, PretUnitar,
CantitateStoc, CodGestiune)
2) GESTIUNE(CodGestiune, DenumireGestiune, NumeGestionar, PrenumeGestionar,
CNPGestionar)
3) BON_CONSUM(NrBon_consum, DataBon_consum, CodGestiune, Cantitate)
4) CONTINUTBON_CONSUM(NrBon_consum, CodMateriiPrime, Cantitate)

Sa ne reamintim...
Identificatorul unei entitati se subliniaza cu o linie continua.
Atributele multivaloare, n cazul nostru Cantitate, se trec in entitatea nou
formata, n cazul nostru CONTINUTBON_CONSUM.

10.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri.


Modelarea asocierilor
1)

102

Max(1,1)=1
Max(1,N)=N
Deci cardinalitatea asocierii este de tip unu la multi (one-to-many).
Aplicam regula de modelare pentru cardinalitatea de tip unu la multi.
Modelarea unei asocieri de tip unu la multi: identificatorul entitatii cu cardinalitate 1
(CodGestiune) se adauga la entitatea cu cardinalitate N (BON_CONSUM).
Deci: CodGestiune se adauga la entitatea BON_CONSUM
Sa ne reamintim...
Regula de modelare pentru cardinalitatea de tip unu la multi
Modelarea unei asocieri de tip unu la multise realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 se adauga la entitatea cu cardinalitate N.
2)

00:45
Max(1,1)=1
Max(1,N)=N
Deci cardinalitatea asocierii este tot de tip unu la multi (one-to-many).
Aplicand regula de modelare pentru cardinalitatea de tip unu la multi, obtinem:
Identificatorul entitatii cu cardinalitate 1 (CodGestiune) se adauga la entitatea cu
cardinalitate N (MATERII_PRIME).
Deci: CodGestiune se adauga la entitatea MATERII_PRIME
3)

103

Max(1,N)=N
Max(1,N)=N
Deci cardinalitatea asocierii este de tip N la N sau muli la muli (many-to-many).
Aplicam regula de modelare pentru cardinalitatea de tip multi la multi.
Modelare : se introduce n mod artificial o noua entitate care are un identificator
compus din identificatorii celor doua entiti implicate iniial n asociere.
Observatie: In entitatea nou formata, proiectantul sistemului informatic mai adauga si
atributele multivaloare.
Sa ne reamintim...
Regula de modelare pentru cardinalitatea de tip multi la multi
Modelarea unei asocieri de tipul N la N sau muli la muli se realizeaz astfel: ntre
cele dou entiti se introduce, n mod artificial, o noua entitate care are, ca atribute de
pornire, identificatorii celor doua entiti implicate iniial n asociere.
Pe lng aceste atribute, proiectantul sistemului va introduce i atributele multivaloare,
deci cele care exprim o cantitate, un pre etc.
3)

01:15

10.6. Realizarea modelului conceptual al datelor (MCD)

104

Sa ne reamintim...
n cazul n care dou entiti prezint o asociere de tipul (N,M), entitatea nou format
se transform ntr-o tabel avnd obligatoriu cheia primar constituit din
identificatorii entitilor participante la asociere (cheile primare ale celor dou tabele).
Totodat, atributele proprii ale asocierii devin cmpuri n tabela nou determinat.

10.7. Realizarea modelului relaional al datelor (MRD)


Aplicam regulile de conversie de la MCD la MRD si obtinem:
1) MATERII_PRIME(CodMateriiPrime, CodGestiune , DenumireMateriiPrime, UM,
PretUnitar, CantitateStoc)

01:40

2) GESTIUNE(CodGestiune, DenumireGestiune, NumeGestionar, PrenumeGestionar,


CNPGestionar)
3) BON_CONSUM(NrBon_consum, DataBon_consum, CodGestiune)
4) CONTINUTBON_CONSUM(NrBon_consum, CodMateriiPrime, Cantitate)
Sa ne reamintim...
Reguli de conversie (reguli de transformare) de la MCD la MLD (MRD)

Fiecare entitate din MCD se transform, n MLD, ntr-o tabel, cu un nume


distinct. Tabela este perceput ca o asociere ntre mai multe atribute care
caracterizeaz acelai tip de entitate.

Fiecare atribut ce caracterizeaz o entitate n MCD se transform, n MLD,


ntr-o coloan ce apartine tabelei corespunztoare respectivei entiti, iar
105

fiecrei asocieri, din MCD, i corespunde o legtur n MLD.

Fiecare identificator al unei entitti din MCD se va transforma, n MLD, n


cheia primar a tabelei respective. Cheile primare se simbolizeaz n MLD
prin subliniere cu o linie continu.

Fiecare regula de domeniu din MCD privitoare la un anumit atribut a unei


entitati se tranforma ntr-o restrictie de integritate referential la nivelul
tabelei corespunzatoare n MLD.

Fiecarui atribut rezultat n MCD, ca urmare a modelarii unei asocieri (atribute


importate din alte entitati) i va corespunde n MLD o cheie externa. Cheile
externe se simbolizeaz n MLD prin subliniere cu o linie punctat.

10.8. Rezumat

01:50

Etapele proiectarii unui sistem informatic sunt urmatoarele:


Identificarea entitatilor din textul problemei de modelat;
Identificarea atributelor entitatilor ; pentru fiecare atribut identificat trebuie
stabilit: tipul atributului, lungimea, domeniul de valori, daca este un atribut
simplu sau compus, daca este un atribut monovaloare sau multivaloare;
Stabilirea identificatorilor entitatilor ;
Identificarea asocierilor dintre entitati ;
Stabilirea cardinalitatii asocierilor si modelarea asocierilor identificate ;
Realizarea modelului conceptual al datelor (MCD) ;
Realizarea conversiei MCD in MRD (modelul relational al datelor);
Realizarea modelului fizic al datelor (implementare in Microsoft Access).

10.9. Test de autoevaluare a cunotinelor


(timp necesar: 7 min.)
1. Enuntati regula de modelare pentru cardinalitatea de tip unu la multi (one-tomany).
2. Enuntati regula de modelare pentru cardinalitatea de tip multi la multi (manyto-many).
Rspunsuri
2. Modelarea unei asocieri de tip unu la multise realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 se adauga la entitatea cu cardinalitate N.
3. Modelarea unei asocieri de tipul N la M sau muli la muli se realizeaz astfel:
ntre cele dou entiti se introduce, n mod artificial, o noua entitate care are,
ca atribute de pornire, identificatorii celor doua entiti implicate iniial n
asociere.

106

10.10. Tema de control


Respectand etapele prezentate in aceasta unitate de invatare, proiectai un sistem
informatic care s rspunda cerintelor urmatoarei probleme:
Descrierea procesului de deschidere a unui cont de card ntr-o banca este
urmatoarea:
Clientul se prezinta la ghiseul bancii unde solicita sa i se deschida un cont de
card. Functionarul de la ghiseu pune la dispozitia clientului un formular n care sunt
completate urmatoarele date: nume, prenume, CNP, serie act de identitate, numar act
de identitate, adresa de domiciliu, telefon, e-mail, tipul contului (de debit/de credit)
care se deschide. Formularul completat de catre client este avizat de functionarul de la
ghiseu si n cazul n care se doreste un card de credit se solicita suplimentar adeverinta
de salariu a clientului. Din aceasta adeverinta, functionarul preia urmatoarele
informatii pe care le introduce n sistem: unitatea la care lucreaza clientul, codul fiscal
al unitatii, salariul brut, adresa unitatii la care lucreaza. Dupa ce aceste date sunt
completate clientului i se elibereaza cardul si codul pin. Daca un client are mai multe
locuri de munca vor fi introduse datele pentru toate aceste locuri de munca.

10.11. Bibliografie
I. Bibliografie obligatorie
1. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
2. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
3. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
4. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
5. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
6. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice,
Ed. Dual Tech, Bucuresti, 2002
7. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
8. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1. Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques, Informatique
Technique, 2009.

107

UNITATEA DE NVARE 11. STUDIU DE CAZ ANALIZA SI


PROIECTAREA UNUI SISTEM INFORMATIC DE GESTIUNE A
COMENZILOR PENTRU UN MAGAZIN VIRTUAL
Cuprins
11.1. Obiective
11.2. Competenele unitii de nvare
11.3. Descrierea problemei de modelat si a cerintelor sistemului informatic
11.4. Identificarea entitatilor din textul problemei de modelat
11.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri. Modelarea asocierilor
11.6. Realizarea modelului conceptual al datelor (MCD)
11.7. Realizarea modelului relational al datelor (MRD)
11.8. Rezumat
11.9. Test de evaluare a cunotinelor
11.10. Teme de control
11.11. Bibliografie

11.1. Obiective
n aceast unitate de nvare sa va prezenta un studiu de caz in care se va
analiza si proiecta un sistem informatic de gestiune a comenzilor pentru un magazin
online.

11.2. Competenele unitii de nvare


Dup parcurgerea unitii vei fi n msur s:
1.

nelegei cum se realizeaza analiza funcional a unui sistem informatic


conform cerintelor care trebuiesc ndeplinite de sistem.

2.

nelegei cum se identifica restriciile i cum se analizeaza efectul acestora


asupra eficienei sistemului.

3.

nelegei cum se realizeaza modelarea unui sistem informatic plecnd de la


datele furnizate de analiza sistemului.

Durata medie de parcurgere a uniti de nvare este de 2 ore.

108

11.3. Descrierea problemei de modelat si a cerintelor sistemului


informatic
Descrierea procesului de comandare a unui produs de catre un client pe un site
web este urmatoarea:
00:05

Clientul se conecteaza pe site-ul web al firmei si navigheaza printre produsele


expuse.
Fiecare produs expus spre vnzare prezinta pe site urmatoarele informatii:
denumirea produsului, descrierea produsului, imaginea produsului, pretul produsului si
disponibilitatea sa pe stoc.
Clientul selecteaza produsul prin intermediul site-ului si l adauga ntr-un cos de
cumparaturi specificnd cantitatea de produs comandata.
Clientul nchide comanda furniznd site-ului web urmatoarele informatii:
numele, prenumele, adresa de livrare, adresa de e-mail, telefonul de contact.
Cerinte:
Sa se identifice entitatile.
Sa se identifice atributele entitatilor.
Sa se stabileasca identificatorii entitatilor.
Sa se identifice asocierile dintre entitati.
Sa se stabileasca cardinalitatea asocierilor.
Sa se modeleze asocierile identificate.
Sa se ntocmeasca modelul conceptual al datelor (MCD).
Sa se realizeze conversia MCD in MRD (modelul relational al datelor).

11.4. Identificarea entitatilor din textul problemei de modelat si a


atributelor care descriu entitatile respective
In urma analizei textului problemei de modelat, se pot identifica urmatoarele entitati:
1)
2)
3)
4)

CLIENT
PRODUS
COS_CUMPARATURI
CONTINUT_COS (provine in urma modelarii unei asocieri de tip N la N)

Aceste entitati vor fi descrise prin urmatoarele atribute:


1) CLIENT(CodClient, Nume, Prenume, Adresa_livrare, Telefon, Email)
2) PRODUS(CodProdus, Denumire, Descriere, Imagine, Pret_unitar, Cantitate_stoc)
3) COS_CUMPARATURI(CodCos, Cantitate_cumparata, Data_cumpararii,
109

CodClient)
4) CONTINUT_COS(CodCos, CodProdus, Cantitate_cumparata)
Sa ne reamintim...
Identificatorul unei entitati se subliniaza cu o linie continua.
Atributele multivaloare, n cazul nostru Cantitate_cumparata, se trec in
entitatea nou formata, n cazul nostru CONTINUT_COS.

11.5. Identificarea asocierilor. Stabilirea cardinalitii unei asocieri.


Modelarea asocierilor
1)

00:30
Max(1,1)=1
Max(1,N)=N
Deci cardinalitatea asocierii este de tip unu la multi (one-to-many).
Aplicam regula de modelare pentru cardinalitatea de tip unu la multi.
1) Modelarea unei asocieri de tip unu la multi se realizeaza astfel: identificatorul
entitatii de cardinalitate 1 (CodClient) se adauga la entitatea de cardinalitate N
(COS_CUMPARATURI).
Deci: CodClient se adauga la entitatea COS_CUMPARATURI
Sa ne reamintim...
Regula de modelare pentru cardinalitatea de tip unu la multi
Modelarea unei asocieri de tip unu la multise realizeaza astfel: identificatorul entitatii
de cardinalitate 1 se adauga la entitatea de cardinalitate N.
2)

110

Max(1,N)=N
Max(1,N)=N
Deci cardinalitatea asocierii este de tip N la N sau muli la muli (many-to-many).
Aplicam regula de modelare pentru cardinalitatea de tip multi la multi.
Modelare : se introduce n mod artificial o noua entitate care are un identificator
compus din identificatorii celor doua entiti implicate iniial n asociere.
Observatie: In entitatea nou formata, proiectantul sistemului informatic mai adauga si
atributele multivaloare; in cazul nostru: Cantitate_cumparata.
Sa ne reamintim...
Regula de modelare pentru cardinalitatea de tip multi la multi
Modelarea unei asocieri de tipul N la N sau muli la muli se realizeaz astfel: ntre cele
dou entiti se introduce, n mod artificial, o noua entitate care are, ca atribute de
pornire, identificatorii celor doua entiti implicate iniial n asociere.
Pe lng aceste atribute, proiectantul sistemului va introduce i atributele multivaloare,
deci cele care exprim o cantitate, un pre etc.

01:15

111

11.6. Realizarea modelului conceptual al datelor (MCD)

Sa ne reamintim...
n cazul n care dou entiti prezint o asociere de tipul (N,M), entitatea nou format
se transform ntr-o tabel avnd obligatoriu cheia primar constituit din identificatorii
entitilor participante la asociere (cheile primare ale celor dou tabele). Totodat,
atributele proprii ale asocierii devin cmpuri n tabela nou determinat.

11.7. Realizarea modelului relaional al datelor (MRD)


Aplicam regulile de conversie de la MCD la MRD si obtinem:
01:30

1) CLIENT(CodClient, Nume, Prenume, Adresa_livrare, Telefon, Email)


2) PRODUS(CodProdus, Denumire, Descriere, Imagine, Pret_unitar, Cantitate_stoc)
3) COS_CUMPARATURI(CodCos, Data_cumpararii, CodClient)
4) CONTINUT_COS(CodCos, CodProdus, Cantitate_cumparata)
Sa ne reamintim...
Reguli de conversie (reguli de transformare) de la MCD la MLD (MRD)

Fiecare entitate din MCD se transform, n MLD, ntr-o tabel, cu un nume


distinct. Tabela este perceput ca o asociere ntre mai multe atribute care
caracterizeaz acelai tip de entitate.

Fiecare atribut ce caracterizeaz o entitate n MCD se transform, n MLD,


ntr-o coloan ce apartine tabelei corespunztoare respectivei entiti, iar
112

fiecrei asocieri, din MCD, i corespunde o legtur n MLD.

Fiecare identificator al unei entitti din MCD se va transforma, n MLD, n


cheia primar a tabelei respective. Cheile primare se simbolizeaz n MLD
prin subliniere cu o linie continu.

Fiecare regula de domeniu din MCD privitoare la un anumit atribut a unei


entitati se tranforma ntr-o restrictie de integritate referential la nivelul
tabelei corespunzatoare n MLD.

Fiecarui atribut rezultat n MCD, ca urmare a modelarii unei asocieri (atribute


importate din alte entitati) i va corespunde n MLD o cheie externa. Cheile
externe se simbolizeaz n MLD prin subliniere cu o linie punctat.

11.8. Rezumat

01:50

Etapele proiectarii unui sistem informatic sunt urmatoarele:


Identificarea entitatilor din textul problemei de modelat;
Identificarea atributelor entitatilor ; pentru fiecare atribut identificat trebuie
stabilit: tipul atributului, lungimea, domeniul de valori, daca este un atribut
simplu sau compus, daca este un atribut monovaloare sau multivaloare;
Stabilirea identificatorilor entitatilor ;
Identificarea asocierilor dintre entitati ;
Stabilirea cardinalitatii asocierilor si modelarea asocierilor identificate ;
Realizarea modelului conceptual al datelor (MCD) ;
Realizarea conversiei MCD in MRD (modelul relational al datelor);
Realizarea modelului fizic al datelor (implementare in Microsoft Access).

11.9. Test de autoevaluare a cunotinelor


(timp necesar: 7 min.)
3. Enuntati regula de modelare pentru cardinalitatea de tip unu la multi (one-tomany).
4. Enuntati regula de modelare pentru cardinalitatea de tip multi la multi (many-tomany).
Rspunsuri
4. Modelarea unei asocieri de tip unu la multise realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 se adauga la entitatea cu cardinalitate N.
5. Modelarea unei asocieri de tipul N la M sau muli la muli se realizeaz astfel:
ntre cele dou entiti se introduce, n mod artificial, o noua entitate care are,
ca atribute de pornire, identificatorii celor doua entiti implicate iniial n
asociere.

113

11.10. Tema de control


Respectand etapele prezentate, proiectai un sistem informatic care sa raspunda
cerintelor urmatoarei probleme:
Descrierea procesului de rezervare a camerelor de catre un client, la o unitate
hoteliera, este urmatoarea:
Pentru rezervarea unei camere de hotel, clientul trebuie sa furnizeze urmatoarele
informatii: numele, prenumele, adresa de e-mail, telefonul de contact, numarul de zile
pentru care face rezervarea, numarul de persoane si, eventual, anumite caracteristici ale
camerei, cum ar fi: etaj, vedere, numar de locuri.
Procesul de rezervare trebuie sa indeplineasca urmatoarele cerinte: un client poate
face mai multe rezervari in timpul anului; o camera este destinata, din momentul
rezervarii, unui anumit client; fiecare camera este identificata printr-un numar si o
categorie; fiecarei categorii de camere ii corespunde un anumit pret.

11.11. Bibliografie
II. Bibliografie obligatorie
9. Cretan A. Analiza si proiectarea sistemelor informatice. Editura Pro
Universitaria, Bucureti, 2013
10. Oancea B., Cretan A. - Baze de date, Editura Pro Universitaria, Bucureti,
2013
11. Olteanu C., Baze de date n Marketing. Aplicaii practice Microsoft
Access, Editura InfoMega, Bucureti, 2012
12. Amza C.P. - Proiectarea sistemelor informatice financiar-bancare si de
gestiune. Editura Cartea Studenteasc. Bucureti. 2008.
13. Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison,
Bucureti 2000
14. Zaharie D., Rosca I. - Proiectarea obiectuala a sistemelor informatice, Ed.
Dual Tech, Bucuresti, 2002
15. Cozgarea G., Zaharie D. - Utilizarea proiectarii orientate obiect in
informatica de gestiune, A.S.E. 2004
16. Morariu N. - Proiectarea sistemelor informatice. Suceava, 2005.
II. Bibliografie facultativ
1.
Baptiste J.L., Merise - Guide pratique (modlisation des donnes et des
traitements, langage SQL), Nouvelle dition, Ressources informatiques, Informatique
Technique, 2009.

114