SISTEME

INFORMATICE INTEGRATE


CURS 1. PROBLEMATICA SISTEMELOR INFORMATICE

1.3. Noţiunea 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.

Din cele mai vechi timpuri termenul sistem a cunoscut numeroase definiţii.
Ludwig von Bertalanffy1 a fost primul teoretician care a articulat principiile teoriei generale
a sistemelor în 1950. Conform definiţiei sale, un sistem este “un set de elemente care se află în
relaţii de interacţiune”
J. de Rosnay2, propune o altă definitie pentru notiunea de sistem: „Ansamblul de elemente
în interacţiune dinamică, organizat în funcţie de un scop“.
E. Morin3 propune şi el o definiţie: „Un sistem este o unitate globală organizată, de
interrelaţii între elemente, acţiuni sau indivizi“.

Având 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
abordării sistemice, J. De Rosnay propune trei activităţi importante [Amza, 2008]:
§ Analiza sistemului;
§ Modelarea sistemului;
§ Simularea.

Analiza sistemelor presupune parcurgerea următoarelor etape:

1) Formularea problemei. Este deosebit de important ca analistul să examineze critic
formularea problemei de către utilizator. Orice eroare minoră în formularea problemei, sau
orice înţelegere eronată, poate genera mari inconveniente prin amplificarea ei cu fiecare
etapă parcursă.
2) Formularea clară si precisă a obiectivelor ce trebuiesc realizate.
3) Analiza cerinţelor utilizatorului avand in vedere identificarea şi evaluarea necesităţilor lui
reale.
4) Precizarea criteriilor de măsurare a eficienţei sistemului.
5) Analiza funcţională ce se concretizează într-o listă amănunţită a funcţiunilor şi aprecierilor
care trebuie îndeplinite.
6) Identificarea restricţiilor şi evaluarea efectului lor asupra eficienţei sistemului.
 7) Identificarea soluţiilor posibile care satisfac restricţiile impuse.
8) Evaluarea soluţiilor si alegerea celei mai bune variante.
Modelarea sistemului constă în construirea unui model plecând de la datele furnizate de
analiza sistemului. Dupa construirea modelului, urmează implementarea, într-un limbaj de
programare, a diferitelor interacţiuni dintre elementele sistemului.
Simularea presupune analiza comportamentului sistemului.

1.4. Componentele sistemului informatic

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

1
L. von Bertalanffy, Theories des systemes, Ed. Dunod, 1973
2
J de Rosnay, Le Macroscope – vers une vision globale, Paris, Seuil, 1975
3
E. Morin, La Metode, Paris, 1991

2
 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 funcţie de domeniul de utilizare, sistemele informatice pot fi:
§ pentru conducerea activităţilor economico-sociale;
§ pentru conducerea proceselor tehnologice;
§ pentru cercetare ştiinţifică şi proiectare tehnologică;
§ pentru activităţi speciale.
2) În funcţie de nivelul ierarhic ocupat de sistemul economic în structura organizatorică a
societăţii:
§ pentru conducerea activităţii la nivelul unităţilor economice;
§ pentru conducerea activităţii la nivelul organizaţiilor economico-sociale cu structură de
grup;
§ sisteme informatice teritoriale;
§ pentru conducerea ramurilor, subramurilor şi activităţilor la nivelul economiei naţionale;
§ sisteme informatice funcţionale generale.
3) În funcţie de elementul supus analizei:
§ sisteme informatice orientate spre funcţii;
§ sisteme informatice orientate spre proces;
§ sisteme informatice orientate spre date;
§ sisteme informatice orientate spre obiecte;
§ sisteme informatice orientate spre cunoştinţe.
4) După modul de organizare a datelor:
§ sisteme bazate pe fişiere;
§ sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţionale, orientate-obiect;
§ sisteme mixte.
5) După metoda folosită în analiza şi proiectarea sistemelor:
§ sisteme dezvoltate după metoda sistemelor;

3
 § sisteme dezvoltate după metoda clasică a ciclului de viaţă;
§ sisteme dezvoltate după metoda structurată;
§ sisteme dezvoltate după metoda orientată-obiect;
§ sisteme dezvoltate după metoda rapidă;
§ 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 reţea locală, staţii de lucru);
§ sisteme informatice distribuite (date distribuite).
8) După gradul de automatizare a activităţilor de analiză şi proiectare a sistemelor informatice:
§ sisteme informatice dezvoltate pe baza analizei şi proiectării clasice;
§ sisteme informatice analizate cu instrumente automate şi proiectate clasic;
§ sisteme informatice bazate pe instrumente diverse de automatizare a analizei şi proiectării;
§ sisteme informatice dezvoltate cu instrumente de tip CASE4.

Să ne reamintim...
În funcţie de modul de organizare a datelor, sistemele informatice se pot clasifica astfel:
sisteme bazate pe fişiere; sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţionale,
orientate-obiect; sisteme mixte.

4
Computer Aided Systems Engineering

4
1.6. Conceptul de sistem informaţional
Conform teoriei sistemelor orice organism economic este un sistem.
Prin organizaţie inţelegem o intreprindere, instituţie, societate comercială.
Caracteristicile unui organism economic privit ca un sistem sunt urmatoarele [Stanciu, 1999]:
§ Orice organism economic interactionează cu mediul exterior prin intermediul diferitelor
fluxuri de intrare-iesire;
§ Organismele economice reprezintă conglomerate complexe de departamente si filiale care
se comportă la rândul 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 funcţional pentru automatizarea procesului de obţinere a informaţiilor şi pentru
fundamentarea deciziilor.
Pentru ca o organizatie să-si satisfacă necesarul de informatie, are nevoie de un sistem
informaţional. Sistemul informaţional 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 informaţional, presupunând partea automatizată a acestuia.

5
 Sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe utilizate în
cadrul organizaţiei, precum şi datele care au stat la baza obţinerii lor, procedurile de obţinere şi de
difuzare a informaţiilor, precum şi personalul implicat în culegerea, transmiterea, stocarea şi
prelucrarea datelor.
Sistemul informaţional are două componente:
§ componenta pentru stocarea (memorarea informaţiilor);
§ componenta pentru prelucrarea informaţiilor.
Funcţiile unui sistem informaţional sunt:
§ să colecteze informaţii din sistemele operaţional şi decizional precum şi informaţiile ce
provin din mediul extern;
§ să memoreze aceste informaţii precum şi informaţiile rezultate din prelucrarea lor;
§ să asigure accesul la memorie în vederea comunicării informaţiilor stocate;
§ să prelucreze informaţiile la cererea sistemelor operaţional şi decizional.
Sistemul operaţional este compus din ansamblul procedurilor si persoanelor care
îndeplinesc sarcinile ce se desfășoară într-o organizatie. În cadrul acestui sistem are loc
implementarea si ducerea la bun sfârsit a strategiilor organizatiei [Amza, 2008].
Sistemul informatic este inclus în cadrul sistemului informational şi are ca obiect de
activitate, in general, procesul de culegere, verificare, transmitere, stocare şi prelucrare automată a
datelor (datele sunt materia primă, iar informaţiile sunt produsul finit). Prin implementarea unor
modele matematice şi utilizarea tehnicii electronice de calcul, sistemul informatic imprimă valenţe
sporite sistemului informational sub aspect cantitativ şi calitativ. Astfel, asistăm la o creştere a
capacităţii de calcul sub aspectul volumului datelor prelucrate şi a operaţiilor efectuate, însoţită de
creşterea exactităţii informatiilor, sporirea operativităţii şi complexităţii 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 atenţie, 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 activităţi ce nu vor putea fi automatizate. Insă, dacă acceptam includerea in
sfera sistemului informatic a activităţii de conducere a proceselor tehnologice cu ajutorul
calculatoarelor de proces, putem asista la automatizarea completă a procesului decizional şi a

6
 reglării automate a procesului tehnologic. Într-o astfel de situaţie, sistemul informatic depășește
sfera sistemului informational.

1.7. Rezumat
• 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 informaţional cuprinde ansamblul informaţiilor interne şi externe utilizate în cadrul
organizaţiei, procedurile de obţinere şi de difuzare a informaţiilor 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
informaţional.

7
 CURS 2. DEZVOLTAREA SISTEMELOR INFORMATICE

Obiectivul principal al sistemelor informatice

Plecând de la ideea că sistemul informatic (SI) este subordonat procesului decizional, al cărui
rol este de a asigura funcţionarea normală şi optimă a întregii activităţi şi de a reduce la minimum
pierderile în caz de funcţionare anormală, rezultă că obiectivul oricărui sistem informatic trebuie să fie
subordonat obiectivului propriu-zis al unităţii economice.

În acest context, obiectivul principal urmărit prin introducerea unui sistem informatic, îl
constituie asigurarea, în timp util, a tuturor informaţiilor necesare în procesul conducerii, în scopul
fundamentării şi elaborării deciziilor cu privire la desfăşurarea cât mai eficientă a întregii activităţi din
unitatea economică.

Ciclul de viaţă a unui sistem informatic

Un sistem informatic are o existenţă limitată în timp, constituind ciclul său de viaţă, în cursul
căreia parcurge două stadii: dezvoltarea şi exploatarea curentă.
Mutaţiile din domeniul tehnologiei informaţionale, 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 următoarele două noţiuni: 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 intrării 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, depinzând de paradigma prin care vedem sistemul informaţional şi de modelul ales pentru
CVSI.
Ciclul de dezvoltare a sistemelor informatice (SI) cuprinde, la rândul său, trei etape: conceperea,
construirea şi introducerea în exploatare – numită, de asemenea, introducere în producţie [Zaharie,
2002].

1
 Fig. 2.1 – Etapele ciclului de dezvoltare a sistemelor informatice (Sursa: [Zaharie, 2002])

Conceperea

Conceperea porneşte de la cerinţele formulate de utilizator. Asfel, se pot distinge două categorii
de cerinţe: cele care precizează prelucrările sau serviciile pe care sistemul urmează să le asigure,
denumite funcţionale, şi cele privind performanţele şi caracteristicile de exploatare, denumite
nefuncţionale sau calitative.
Pentru a putea realiza sistemul dorit, este necesar ca cel care-l dezvoltă să înţeleagă aceste cerinţe
şi să evalueze posibilitatea de a le oferi un răspuns în limitele materiale, financiare şi, de timp, fixate de
către utilizator. Acest aspect constituie obiectul analizei. În cazul în care, sistemul este realizat chiar de
către utilizator, analiza este foarte scurtă şi relativ simplă. În celelalte cazuri, analiza presupune un efort
de informare şi evaluare considerabil, având în vedere că cel care dezvoltă sistemul trebuie să cunoască
şi să înţeleagă cerinţele formulate de utilizator.
După analiza cerinţelor, urmează ca dezvoltatorul să propună o soluţie informatică ce va fi
exploatabilă pe o anumită platformă, în spaţiul unei anumite arhitecturi aplicative. Acest aspect
constituie obiectul proiectării din care va rezulta multitudinea de elemente necesare pentru realizarea
efectivă a programelor ce compun respectivul software de aplicaţie. Proiectarea este cea care defineşte
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 prelucrărilor etc. Rezultatele conceperii, formează
specificaţiile după care se va construi sistemul [Zaharie, 2002].

2
 Construirea

Construirea porneşte de la specificaţiile rezultate în urma conceperii şi asigură redactarea

programelor de calculator până la forma finală, cea executabilă. Paşii urmaţi în acest scop sunt: scrierea
programelor într-un limbaj sursă de un anumit nivel, aducerea acestuia în formă executabilă prin
compilare sau interpretare şi testarea funcţionării sale pe platforma de calcul. Disfuncţionalităţile şi
erorile constatate sunt înlăturate prin modificarea adecvată a programelor sursă, după care noile
programe sunt aduse din nou în forma executabilă şi verificate şi acest ciclu se repetă până când se
ajunge la funcţionarea corectă dorită.
Orice sistem informatic de calitate, proiectat şi implementat profesional, trebuie să fie testat şi
validat înainte de a intra în faza de producţie. Clientul trebuie să fie sigur că sistemul a fost dezvoltat şi
integrat în conformitate cu specificaţiile proiectului. De asemenea clientul trebuie să se asigure că
funcţionalitatea proiectului este corectă şi fără erori. Testarea sistemului presupune trei etape [Zaharie,
2002]:
§ testarea unitară
§ testare de integrare
§ testare de sistem
Testarea unitară verifică funcţionarea separată a fiecărei unităţi de program.
Testarea de integrare vizează funcţionarea unităţilor de program în interacţiune.
Testarea de sistem verifică funcţionarea ansamblului, în calitate de software aplicativ, coerent
şi unitar.
Identificarea sursei erorilor şi disfuncţionalităţilor, precum şi înlăturarea 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
legături, formatul executabil final, livrabil, ce formează, alături de documentaţia de utilizare şi de
exploatare a sistemului, rezultatele acestei etape.

Introducerea în exploatare

Introducerea în exploatare asigură instalarea la utilizator a echipamentelor şi a reţelelor de

comunicaţie (dacă este cazul), încărcarea software-ului de aplicaţie în structurile adecvate, crearea şi
încărcarea iniţială a bazei sau bazelor de date, instruirea utilizatorilor, testarea sistemului în condiţiile
reale de utilizare şi efectuarea eventualelor corecţii necesare, lansarea efectivă în funcţiune [Zaharie,
2002].

3
 Mentenanţa sistemului
In termeni generali, mentenanţa reprezintă totalitatea acţiunilor efectuate pentru
menţinerea/restabilirea stării de funcţionare a produselor.
Mentenanţa poate fi caracterizată prin următoarele activităţi:
§ Mentenanţă corectivă (neplanificată): diagnosticarea şi corectarea erorilor;
§ Mentenanţă adaptivă: activitate care modifică software-ul pentru a interacţiona corect cu un
mediu în schimbare (hardware sau software);
§ Mentenaţă perfectivă: activităţi pentru adăugarea de noi capabilităţi, modificarea funcţionalităţii
existente şi aducerea de îmbunătăţiri generale;
§ Mentenanţă preventivă (planificată): activităţi care pregătesc produsul software pentru o mai
bună mentenabilitate sau fiabilitate în viitor, sau pentru a pune baza unor viitoare îmbunătăţiri.
Pe parcursul ciclului de viaţa a unui proiect, după fazele de analiză de proiect şi dezvoltare,
întretinerea sistemului are un rol foarte important. Pe măsură ce un proiect devine tot mai mare şi mai
complex, creşte cantitatea datelor gestionate şi infrastructura, necesitând un suport tehnic elaborat
pentru a ţine în funcţiune şi a întreţine componentele software şi hardware ale acestui sistem. In
majoritatea cazurilor un sistem informatic dezvoltat la cerere poate fi întreţinut 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 exploatării curente, apar momente care solicită intervenţii de
menţinere în funcţiune a sistemului.
Există o mulţime variată de motive pentru care apar defecte în dezvoltarea produselor software:
§ Lipsa comunicării sau comunicare slabă în cadrul proiectului;
§ Constrângeri de timp şi de buget, care duc la presiune şi la apariţia erorilor;
§ Cerinţe care nu au fost specificate suficient de clar;
§ Modificări în cerinţe si o slabă documentare a lor;
§ Presupuneri;
§ Pregătire insuficientă;
§ Erori de programare.
Rezolvarea acestora implică intervenţii ce pot include una sau mai multe dintre activităţile
derulate pentru creare: (re)definire de cerinţe, analiză, proiectare, construcţie, testare, introducere în
exploatare, aplicate, evident, doar pentru anumite porţiuni din acesta.
Pentru că schimbările sunt inevitabile, trebuie dezvoltate mecanisme pentru a identifica, evalua,
controla, efectua şi raporta modificările necesare. Aceste activităţi încep odată cu proiectul şi se încheie
doar când produsul este retras din funcţiune.

Tipuri de participanţi în dezvoltarea sistemelor informatice

În dezvoltarea sistemelor informatice, au fost identificaţi trei tipuri de participanţi generici
[Zaharie 2002]:

4
 § utilizatorul;
§ dezvoltatorul sau furnizorul software-ului aplicativ;
§ administratorul sistemului.
Utilizatorul reprezintă persoana, sau grupul de persoane, care foloseşte sistemul pentru a
îndeplini cerinţele informaţionale.
Interacţiunile dintre utilizator şi sistemul informatic sunt de trei tipuri:
§ intervenţii asupra informaţiilor stocate de sistem;
§ extragerea de informaţii din sistem;
§ declanşarea şi/sau executarea de operaţii comerciale.
Dezvoltatorul este termenul generic folosit pentru a desemna creatorul software-ului aplicativ
ce formează suportul sistemului informatic. În funcţie de poziţia acestuia faţă de organizaţie, se disting:
§ outsourcing: dezvoltatorul este o societate comercială specializată;
§ insourcing: dezvoltatorul este reprezentat de unul sau mai mulţi angajaţi ai departamentului
de informatică al organizaţiei;
§ selfsourcing: utilizatorul este şi dezvoltatorul sistemului.
"Outsourcing" este un termen de origine anglo-saxonă, deseori întâlnit în limba română ca
"externalizare".
Externalizarea reprezintă opţiunea, deseori strategică, pe care o are o companie de a-şi transfera
anumite procese, total sau partial, către furnizori de servicii specializati - BPO (Business Process
Outsourcing).
În procesul de externalizare se regăsesc doi subiecţi de bază:
§ clientul reprezentat prin întreprinderea beneficiară ce încredinţează un anumit serviciu,
lucrare sau activitate către 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 apelurilor clientilor dar si altele, cum
ar fi: trimiterea acestor bilete catre clienţi (mailing) etc. Beneficiile pe care le poate obtine o companie
in urma externalizării proceselor, ce reprezintă doar suport pentru procesul principal de productie, se
concretizează în cresterea productivităţii muncii si economii de resurse (timp si bani).
În procesul de dezvoltare a sistemelor informatice, externalizarea conceperii de solutii software
presupune [Zaharie 2002]:
§ Soluţii software de uz general;
§ Soluţii software pe măsură.
În primul caz, avem de-a face cu un produs deja disponibil, destinat, de la bun început cumpărării
şi utilizării de către cât mai mulţi clienţi. Acesta se adresează domeniilor comune oricăror afaceri, cum

5
ar fi: calculul salariilor, urmărirea stocurilor, contabilitatea financiară etc. Acestea sunt denumite
generic pachete de programe sau produse program de uz general.
Soluţia software pe măsură este concepută şi construită conform nevoilor şi condiţiilor specifice
organizaţiei. Are avantajul de a fi adaptată din start acesteia, dar costurile şi durata de obţinere vor fi
mai mari.
Insourcing-ul sau internalizarea are loc atunci când pentru realizarea unei activităţi se utilizează
numai resurse interne din întreprindere, fiind exclusă recurgerea la surse externe.
Dezvoltarea produsului software de către specialiştii IT ai organizaţiei, este posibilă cu condiţia
ca aceştia să posede competenţa tehnică necesară şi să existe resurse suficiente (timp, oameni şi
echipamente).
Selfsourcing-ul prezintă avantajul esenţial de a avea aceleaşi persoane atât în calitatea de
dezvoltator cât şi în aceea de utilizator.
Utilizatorul trebuie să aibă cunoştinţe suficiente de informatică pentru a concepe şi construi
sistemul cu o contribuţie minimă din specialisti IT. Referitor la aceştia, literatura de specialitate
foloseşte termenul de "knowledge workers". Un astfel de utilizator nu va dezvolta decât sisteme de mici
dimensiuni, care răspund numai lucrărilor şi sarcinilor sale curente sau a celor cu care interacţionează
în mod direct la locul de muncă.
Administratorul sistemului desemnează persoanele sau structurile care asigură condiţiile de
funcţionare curentă a sistemului şi gestionează măsurile de protecţie şi securitate a acestuia. În această
postură se pot afla:
§ utilizatorul;
§ angajaţi din departamentul de TI al organizaţiei;
§ societate specializată.

6
CURS 3. METODE DE PROIECTARE A SISTEMELOR INFORMATICE

Evolutia metodelor de proiectare

Realizarea unui sistem informatic, sau doar a unei aplicaţii, presupune
modelarea situaţiei reale şi utilizarea modelului creat, în realitatea cu care operează
calculatorul.

Modelarea este reprezentarea într-un mediu controlat, a proprietăţilor şi/sau

fenomenelor şi proceselor care caracterizează un obiect sau un sistem real. Cu alte cuvinte
în modelare nu există adevăr absolut; modelarea presupune abstracţie şi aducerea în atenţie
numai a unor aspecte ale realităţii studiate şi anume acele aspecte care prezintă interes
pentru modelator. Unul din mediile controlate în care se poate reproduce realitatea, deci
unul în care se pot face modele, este calculatorul. Pe calculator se realizează modele
informaţionale.

Modelul informaţional este o abstracţie a unei entităţi şi această abstracţie poate fi

făcută 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
entităţi 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 informaţional real, acela pe care vrea să-l modeleze, dar nu toate
viziunile sau concepţiile analiştilor ajung să fie considerate paradigme. Odata cu trecerea
timpului s-au conturat mai multe curente de gândire care au promovat si dezvoltat anumite
metode de proiectare, tocmai de aceea există mai multe clasificări ale metodelor de
proiectare.

La începuturile existenţei sistemelor informatice, atenţia analiştilor a fost

concentrată spre latura funcţională a activităţii umane studiate şi cum o funcţie a unui birou,
sau secţie, nu putea fi analizată şi nici prelucrată în bloc, ea a fost descompusă în activităţi
(rezultând aplicaţiile informatice), activităţile au fost descompuse în subactivităţi
(rezultând procedurile), care la rândul lor au fost descompuse în operaţii, cărora în
calculator le corespondeau modulele program. S-a dezvoltat în aceste condiţii o abordare
funcţională a sistemelor informaţionale, cunoscută sub numele de metoda descompunerii
funcţionale (metode orientate spre funcţii) [Oprea, 1999]. Descompunerea funcţională
este cea care anunţă apariţia proiectării structurate şi analizei structurate. Fiecare funcţie

1
este descompusă în subfuncţii, până se obţin structuri uşor de transpus în instrucţiunile
limbajelor de programare.

În informatica industrială funcţiei î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ă analiştii efectuează reprezentarea lumii reale
prin simboluri care reprezintă fluxul datelor, transformările datelor, stocarea datelor,
entităţi externe etc. Metoda orientată spre procese are încă un mare grad de asemănare cu
descompunerea funcţională.

Ulterior, locul fişierelor a fost luat de bazele de date şi corespunzător, locul

sistemelor de gestiune a fişierelor a fost luat de sistemele de gestiune a bazelor de date
(SGBD). Pe parcursul perfecţionării SGBD-urilor, s-a trecut la baze de date relaţionale,
creându-se impresia că elementul principal pe baza căruia trebuie perfecţionate SGBD-
urile îl reprezintă structura datelor. Avem astfel de a face cu o abordare orientată spre
date sau metode orientate spre informaţii (metode orientate-date) [Oprea, 1999]. Două
realizări importante în domeniu au dat tonul unei orientări în abordarea sistemelor:
modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen (1976) şi
ingineria informaţiei, în viziunea lui James Martin.

Când s-a pus problema aplicaţiilor în timp real, factorul cel mai important se părea
a fi evenimentul. A apărut 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 abordării
sistemelor informatice. Preocupările analiştilor-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 apărut 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 aceeaşi
structură şi un comportament similar.

2
Curentul de gândire francez a realizat o altă clasificare a metodelor de proiectare plecând
de la modalitătile în care este conceput sistemul: functional, sistemic, obiectual. Astfel, s-
a propus următoarea 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 câte 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 mentenanţa unui asemenea

sistem ridica numeroase probleme.
Exemple de astfel de metode:
§ SADT (Structured Analysis Design Technique);

§ JSD (Jackson Structured Design).

Metode sistemice
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
prelucrările sunt analizate si modelate independent.
Spre deosebire de metodele ierarhice, aceste metodele acordă prioritate datelor fată
de prelucrări si respectă cele trei niveluri de abstractizare introduse de arhitectura standard
ANSI-SPARC: conceptual, logic si fizic.

3
 Fig. 3.1 – Nivelurile de abstractizare a datelor si prelucrarilor (Sursa [Stanciu,
2000])

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 este gândit 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 lângă datele care descriu
entitatea sau obiectul respectiv, obiectul mai conţine si metodele de prelucrare a datelor,
acest lucru neputând fi realizat cu nici unul din conceptele specifice metodelor de
proiectare anterioare. Deci, obiectele aduc avantajul încapsulării, datele si prelucrările 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

4
 Avantajele metodelor orientate-obiect constau în posibilitatea reutilizării
componentelor de program, reducând la minim efortul de mentenanţă a unui sistem
informatic.
Dezavantajele acestor metode decurg din faptul că nu toate aspectele realităţii pot
fi modelate cu ajutorul conceptului de obiect.

Strategii de abordare a proiectării sistemelor informatice

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 întâi
definirea de ansamblu a proceselor si detalierea acestora ulterior.
Această abordare constă în a coborî, pe scara piramidei ierarhice până la bază,
realizând totodată şi o analiză. Această viziune consideră că un anumit domeniu este
compus din părţi corelate între ele şi cu legături cu exteriorul, fiind caracteristică pentru
toate sistemele informaţionale. Adepţii acestei abordări 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 următoarele [Amza,

2008]:
§ Va exista o viziune si o gândire unitară asupra modelului sistemului;
§ Va permite abordarea problemelor în totalitatea complexitatii lor luând î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;

5
 § 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 ascendentă (bottom – up) sau de jos în sus are ca punct de plecare
nivelul operaţional (aflat la baza piramidei ierarhice) şi, prin realizarea informatizării 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 informaţional-organizaţional, specific unui organism economic supus analizei.

Avantajele pe care le comporta o asemenea abordare sunt următoarele [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 decât un anumit subdomeniu al organizatiei care va fi expus
schimbului de informatii cu celelalte subdomenii;
§ 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 decât 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 gândire unitară asupra sistemului.

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

Metodologia elaborării sistemelor informatice

Dată fiind complexitatea sistemelor informatice, acestea nu se pot obţine dintr-o

dată şi nici nu se pot realiza după cum crede fiecare dezvoltator. În acest sens, experienţa
acumulată în procesul de elaborare a sistemelor informatice a fost materializată în
metodologii.
Metodologia elaborării sistemelor informatice a fost concepută iniţial ca un
ansamblu de principii şi indicaţii, tehnici şi metode grupate şi ordonate ca să ducă la
realizarea sistemului informatic. Cuvântul “metodă” folosit în această definiţie nu are
nimic de a face cu metoda-program asociată evenimentelor unui obiect şi nici cu metoda
de abordare a sistemelor informaţionale. Aici prin metodă se înţelege un set de reguli
aplicabile unui domeniu restrâns din cadrul unei metodologii.
In prezent metodologia este văzută 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 informaţiei, 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, activităţi, sarcini precum şi conţinutul lor;
§ fluxul realizării acestor etape sau procese, subetape şi activităţi;
§ 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;
§ modalităţile de conducere a proiectului (planificare, programare, urmărire) şi
modul de utilizare a resurselor financiare, umane şi materiale.

7
 Rezumat
• Modelul informaţional este o abstracţie a unei entităţi şi această abstracţie poate fi
făcută 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 entităţi 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ă.

CURS 4. METODE SISTEMICE DE PROIECTARE

4.1. Prezentarea metodei MERISE

Metoda MERISE (Méthode d'Étude et de Réalisation Informatique pour les Systèmes

d'Entreprises) a fost dezvoltată de Centrul Tehnic de Informatică din cadrul Ministerului de
Industrie Francez şi reprezintă un instrument tehnico-economic de proiectare a unui sistem
informatic.

Pe parcursul timpului au fost dezvoltate două variante ale metodei. Prima variantă, elaborată
la sfârşitul anilor ’70 se baza pe următoarele coordonate:
a) abordarea sistemică ce scoate în evidenţă relaţia existentă între sistemul
informaţional şi sistemul de conducere (decizional), pe de o parte, precum şi relaţia dintre
sistemul informaţional şi sistemul condus (operaţional), pe de altă parte. Astfel, sistemul
informaţional pune la dispoziţia sistemelor condus şi decizional toate informaţiile
necesare pentru a acţiona ş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 mentenanţa sistemelor informatice;
c) un ciclu de abstractizare corespunzător celor trei niveluri: conceptual, logic sau
organizaţional şi fizic;
d) separarea între modelul datelor şi modelul prelucrărilor.

Metoda MERISE vizează două obiective principale:

§ reprezintă o metodă de concepţie a sistemelor informatice;
§ propune o metodologie de dezvoltare a sistemelor informatice.

Fiind o metodă sistemică, aceasta separă studiul datelor de cel al prelucrărilor, conform
tabelului urmator:

1
 Niveluri Date Prelucrări
Model conceptual
Conceptual Model conceptual MCP
MCD
Logic Model logic (organizaţional) MLP
Model logic MLD
(Organizaţional) (MOP)
Fizic Model fizic MFD Model fizic MFP
Tabel 4.1 Nivelurile de abstractizare a datelor si prelucrarilor

Avantajele metodei MERISE ca metodă de concepţie a sistemelor informatice sunt:

§ apropierea de sistemul informatic şi de structura ideală a bazei de date;
§ descrierea sistemului pe trei niveluri;
§ utilizarea unui formalism1 de reprezentare precis, simplu şi riguros pentru descrierea
datelor. Acest formalism este reglementat pe plan internaţional de standardul ISO sub
numele de modelul ENTITATE-ASOCIERE;
§ descrierea amănunţită la nivel conceptual, permiţând realizarea unui SI independent de
organizarea firmei şi alegerea tehnicii de automatizare;
§ reprezentarea vizuală folosită în modelul conceptual facilitează stabilirea unui dialog între
toţi partenerii implicaţi în realizarea SI.

Varianta a doua a metodei MERISE surprinde evoluţiile tehnice şi organizaţionale ale anilor
’90 şi înlătură câteva carenţe ale modelului entitate-asociere utilizat în prima versiune. Astfel, se
introduc noţiunile de generalizare şi specializare pentru a explica conceptele de moştenire, regulile
de integritate şi noţiunea de identificator relativ (ce permite identificarea unei entităţi în raport cu
altă entitate).

În versiunea a doua a metodei MERISE modelul conceptual al prelucrărilor (MCP) conţine,

în plus :
§ diagramă a fluxului de date (DFD);
§ un model analitic conceptual al prelucrărilor care acţionează încă din faza de
concepţie;
§ noţiunea de ciclu de viaţă al unui obiect – surprinde toate etapele parcurse de un
obiect în cursul existenţei sale, în funcţie de evenimentele produse şi de evenimentele
care urmează a se produce.

La nivel organizaţional, sunt surprinse în structură toate resursele materiale şi umane

implicate în realizarea sistemelor informatice. La nivel logic, sunt definite interfeţele cu utilizatorii,

1
Formalism, în sensul de mai sus, înseamnă un set de definiţii şi reguli, combinat cu un set de tipuri de
diagrame şi/sau de tabele.

2
resursele logice ale prelucrărilor, precum şi depozitarea şi repartiţia datelor, nivelul fizic rămânând
neschimbat.
Pentru proiectarea unui sistem informatic utilizând 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 lăsat la
latitudinea dezvoltatorului.

4.2. Ciclurile de bază ale proiectării unui sistem informatic

Ciclurile de bază ale proiectării unui sistem informatic utilizând metoda MERISE sunt:
§ ciclul de viaţă;
§ ciclul de decizie;
§ ciclul de abstractizare.
Acestea se reprezintă într-un grafic tridimensional corespunzator Modelului tridimensional
al proiectării unui SI (vezi Fig.4.1).

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

Ciclul de viaţă

Ciclul de viaţă presupune parcurgerea succesivă a următoarelor etape:

§ realizarea schemei directoare şi studiul preliminar;
§ realizarea unui studiu detaliat;
§ realizarea sistemului informatic (studiu tehnic, codificare);
§ implementarea si exploatarea;
§ mentenanţa sistemului.
a) Realizarea schemei directoare şi studiul preliminar – presupune analiza sistemului
informatic existent, stabilirea cerintelor, a obiectivelor şi a planului strategic, definirea priorităţilor,
realizarea de scenarii globale alternative pentru fiecare domeniu investigat şi alegerea scenariului
optim. Deasemenea, organizaţia este împartită pe domenii sau pe departamente, iar pentru fiecare
departament este gândită o schemă a aplicaţiilor, care include şi politica de resurse umane,
produsele hardware şi software, precum şi o metodologie pentru implementarea unei îmbunătăţiri
viitoare a sistemului.
Studiul preliminar este realizat pentru fiecare domeniu şi descrie SI propus, impactul
acestuia asupra organizaţiei, costurile şi beneficiile. Studiul trebuie să fie în concordanţă cu planul
strategic stabilit anterior. Activităţile acestei etape sunt:
§ culegerea de informaţii despre activitatea organizaţiei;

4
 § realizarea diagramelor de flux care evidenţiază actorii participanţi şi schimburile de
informaţii dintre ei;
§ elaborarea primelor variante de MCD şi MOP şi analizarea punctelor lor slabe;
§ propuneri de îmbunătăţire a MCD şi MOP şi prezentarea unei soluţii;
§ evaluarea soluţiei propuse.

b) Studiul detaliat pleaca de la soluţia cadru definita pentru scenariul ales pe care o
dezvolta. Aceasta presupune specificarea detaliată a cerinţelor şi a arhitecturii noului sistem. În
acest sens, se vor avea în vedere toate aspectele ce vor fi automatizate, incluzând specificaţiile de
detaliu pentru modelul tehnic şi funcţional. Aceasta etapă asigura modelarea conceptuală si
organizatională a SI.
Activităţile acestei etape sunt:
§ la nivel general:
Ø realizarea MCD, MCP, MLD, MOP pentru soluţia aleasă;
Ø definirea mediului de dezvoltare;
Ø punerea în practică a studiului prealabil prin elaborarea planurilor de lucru;
Ø realizarea documentaţiei şi a planului de recepţie
§ la nivel detaliat:
Ø stabilirea fazelor de realizare;
Ø validarea datelor şi prelucrărilor (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.

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;
§ Procedurile preliminare de realizare a bazei de date;

5
 § 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 câteva 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.

e) Mentenanţa sistemului informatic constă în a asigura evolutia aplicatiilor operative în functie

de cerintele utilizatorilor, de cerintele mediului si de progresul tehnologic. Mentenanţa 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.
Mentenanţa implica patru etape esentiale [Amza 2008]:
§ Studiul de impact – presupune evaluarea amplorii adaptărilor si realizarea unei
actualizari a modelului de date si prelucrari;
§ Analiza adaptărilor si specificatiile acestora;
§ Realizarea adaptărilor;
§ Lansarea versiunii modificate în urma revizuirii.

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 funcţionalitatea SI;
§ Decizii financiare referitoare la costuri şi beneficii;
§ Decizii referitoare la identificarea principalilor actori ai sistemului informaţional şi
organizatoric;

6
 § Decizii ale utilizatorilor finali legate de interfaţa SI;
§ Decizii legate de modul de procesare a datelor;
§ Decizii de ordin tehnic legate de echipamentele hardware şi software.

Ciclul de abstractizare
Este constituit dintr-o înşiruire de raţionamente făcute în scopul realizării sistemului,
constituind faza esenţială a metodei MERISE.
Ciclul de abstractizare conţine 3 niveluri: conceptual, logic si fizic. Nivelurile de
abstractizare sunt împărţite în două mari categorii: niveluri de abstractizare care fac referire la date
şi niveluri de abstractizare care fac referire la prelucrări.

4.3. Rezumat

• Etapele proiectării unui sistem informatic, caracteristice metodei MERISE, sunt: studiul
prealabil si schema directoare, studiul de detaliu, studiul tehnic, realizarea,
implementarea și mentenanţa sistemului informatic;
• Ciclurile de baza ale proiectarii unui sistem informatic, prin metoda MERISE, sunt:
ciclul de viată, ciclul de decizie si ciclul de abstractizare.

7
 CURS 5. MODELUL CONCEPTUAL AL DATELOR. MODELUL
ENTITATE-ASOCIERE (E-A)

5.1 Entităţi si tipuri de entităţi

Modelul conceptual al datelor (MCD) reprezintă o modalitate de reprezentare a

datelor organizaţiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi
legăturile existente între date. MCD are următoarele 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ă 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 organizării datelor într-un format grafic care poartă denumirea de
diagrama entitate-asociere;
• verificarea validităţii modelării 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 toţi utilizatorii
potenţiali. Rezultatul final al activităţii 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 conţine erori datorate:
• spiritului de observare şi subiectivităţii observatorului;
• metodelor de observare folosite;
• tehnicilor, instrumentelor şi metodelor de modelare.

Pentru a se înlătura erorile de concepţie a modelului este bine ca la procesul de

observare să participe mai mulţi membri ai echipei, fiecare dintre aceştia realizând câte un
model. Modelele astfel realizate sunt supuse confruntării, 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.
Identificarea principalelor obiecte care stau la baza modelului conceptual al datelor,
din punct de vedere al metodei MERISE, se referă la noţiunile 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

1
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 atât entitatilor cât 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, 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ă aparţină spaţiului 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 entităţi;
• Să aibă o existenţă de sine stătătoare.
Deci, o entitate reprezinta "orice poate fi identificat în mod distinctiv". O entitate se
referă la un aspect al realităţii 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 relevanţei privind domeniul de interes
pentru care se defineşte modelul respectiv, astfel încât să asigure diferenţierea precisă a
entităţii respective faţă de restul universului. De exemplu, entitatea ANGAJAT reprezintă o
persoană angajată a instituţiei, care are o anumită funcţie, lucrează într-o anumită secţie şi
primeşte 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 instituţia respectivă
(cum sunt: Funcţia, Salariul).

2
 În bazele de date, entităţile similare care pot fi descrise prin aceleaşi atribute, se
grupează în mulţimi, fiecare entitate având valori particulare ale atributelor respective. Toate
entităţile similare, care pot fi descrise prin aceleaşi atribute, aparţin aceluiaşi tip de entitate
(clasa entitatii). Ansamblul tuturor entităţilor de acelaşi tip dintr-o bază de date constitue o
mulţime de entităţi. O mulţime de entităţi se descrie prin aceleaşi atribute prin care este
descrisă fiecare entitate componentă.
Numim realizare a unei entităţi mulţimea formată din câte o valoare pentru fiecare
atribut al entităţii. Valorile fiecărui atribut component a ceea ce numim generic entitate
alcătuiesc o realizare (instanţiere) a entităţii respective.
De exemplu, in Figura 5.1, luam in considerare entitatea STUDENT, descrisa prin
aributele: CNP, Nume, Prenume, DataNastere, Adresa. Dând valori acestor atribute obtinem
o realizare a entitatii STUDENT.

Figura 5.1
Să ne reamintim...
Entitatea reprezinta o abstractizare a proprietatilor si caracteristicilor unui obiect din cadrul
domeniului modelat.

5.2 Atributele unei entităţi

Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o proprietate
sau o caracteristică a unei entităţi care prezintă interes pentru organizaţie. 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 informaţiei, atributele pot fi:

3
 § elementare – reprezentarea datei este indivizibilă în raport cu informaţia 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: câmpul „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.
Să ne reamintim...

Dupa modul de stocare al valorii, atributele pot fi : simple si calculate.

Din punct de vedere al realităţii modelate, atributele pot fi:

§ opţionale – dacă atributul respectiv nu poate prezenta o valoare la un moment dat,
valoarea lui nefiind neaparat necesara (exemplu: „limbi străine 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 când valoarea pe care o poate lua un atribut, la un moment dat,
prezintă mai multe realizări concomitente pentru aceeaşi entitate (exemplu: limbi
străine cunoscute – o persoană poate cunoaşte engleză, franceză şi germană);
monovaloare – prezintă doar o singură valoare pentru atributul respectiv.
Să ne reamintim...
Din punct de vedere al realităţii modelate, atributele pot fi: opţionale si obligatorii.

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;

4
 § 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 câte 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 luând î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 îndeplineşte atributul respectiv în cadrul modelului,
atributele pot fi:
§ cheie primară (identificator) – reprezintă acel atribut, sau grup de atribute, care
reuşeşte, prin valorile pe care le ia, să identifice în mod unic o entitate din mulţimea
entităţilor care prezintă acelaşi comportament. Atributele care compun cheia primară
nu pot avea valori nule. O altă cerinţă esenţială este unicitatea.
§ cheie candidat – reprezintă acel atribut, care prin natura sa, poate juca 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ă, reţinută ca atare.
§ cheie externă – reprezintă un atribut, sau o mulţime de atribute, definite pe aceeaşi
mulţime de valori ca şi cheia primară, rolul său fiind acela de a putea stabili o asociere
(legătură) între două sau mai multe tipuri de entităţi, care, în realitatea modelată,
interacţionează î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 societăţi comerciale: codul unic de înregistrare (CUI), numărul
de înregistrare, codul IBAN. De aceea, atributul care joacă rolul de identificator (cheie
primară) trebuie să îndeplinească concomitent mai multe cerinţe:
a) nu trebuie să existe două valori identice în mulţimea 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ă condiţie;

5
 d) dimensiunea câmpului cheie primară trebuie să fie cât mai redusă (identificatorul
sa fie cat mai scurt). În exemplul de mai sus, numărul de înregistrare la Registrul Comerţului
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. Ţinând cont de aceste
cerinţe, 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 decât
anumite valori din multimea valorilor domeniului.
Domeniul de valori reprezintă mulţimea tuturor valorilor posibile pe care le poate lua un
atribut. Orice atribut trebuie sa aiba asociat un domeniu de valori. Atributele surprind partea
statică a unui tip de entitate, iar valorile atributelor reflectă partea dinamică a entităţii. De
exemplu: „vârsta” este atributul entităţii SALARIAT, iar valoarea acestui atribut se schimbă.
Există două modalităţi prin care se poate exprima domeniul de valori:
a) Exprimarea explicită – se enumeră valorile din domeniul respectiv. Exemplu:
vârsta∈{18,19,20,…, 65};
Exprimarea implicită – se precizează proprietăţile pe care le are domeniul. Exemplu:
vârsta∈{x, x∈N, 18≤x≤65}.

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.3. Rezumat
• 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.

6
• Atributul reprezintă o caracteristică unei entităţi.
• 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 cerinţe:
a) nu trebuie să existe două valori identice în mulţimea 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.
d) dimensiunea câmpului cheie primară trebuie să fie cât mai redusă (identificatorul sa fie
cat mai scurt).

7
CURS 6. ASOCIERI SI TIPURI DE ASOCIERI. DIAGRAMA ENTITATE-
ASOCIERE (E-A)

6.1. Tipuri de asocieri

Asocierea reprezintă legătura sau corespondenţa existentă între două sau mai
multe entităţi, în care fiecare joacă un anumit rol.
Rolul unei entităţi este un nume care desemnează modul de participare a
entităţii la o asociere. Identificarea asocierilor se realizează prin rolurile entităţilor
participante, deci, concret, cu ajutorul identificatorilor entităţilor participante.
Tipul asocierii reprezintă ansamblul legăturilor sau a corespondenţelor cu
aceeaşi semnificaţie, dintre două sau mai multe tipuri de entităţi.
Tipurile de entităţi (mulţimea entităţilor) care participă la un tip de asociere
formează colecţia acesteia. Numărul de tipuri de entităţi 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 entităţi, asocierile nu au existenţă de sine stătătoare, acestea depinzând
de existenţa entităţilor pe care le leagă. Existenţa unei asocieri poate fi mai scurtă decât a
entităţilor participante.
O asociere poate avea atribute proprii.
Pentru identificarea asocierilor, trebuie sa tinem cont de urmatoarele reguli:
§ o asociere nu poate exista decât o singură dată între aceleaşi entităti;
§ numele entităţilor, corespondenţelor, rolurilor, atributelor trebuie să fie
unice în cadrul modelului conceptual, iar apoi, în baza de date definită.

Î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 entităţi, proiectantul va identifica verbele care pun in legatura
respectivele entitati. Nu este obligatoriu ca numele dat unei asocieri să fie un verb, dar o

1
asociere reprezintă o interacţiune între tipurile de entităţi (şi mulţimile de entităţi
corespunzătoare), 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 realizările aceleiasi entitati: ANGAJAT (vezi Figura 6.2.). In acest caz, entitatea
ANGAJAT joacă dublu rol: „este condus” si „conduce”.

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.

2
 Figura 6.4.

6.2 Cardinalitatea asocierii

Cardinalitatea asocierii - exprimă modul de participare al entităţilor 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:
1) unu-la-unu (one-to-one/biunivocă). Fiind date două mulţimi de entităţi, A şi B,
spunem că cele 2 multimi sunt într-o relaţie unu-la-unu, dacă unei entităţi din
mulţimea A îi corespunde o singură entitate din mulţimea B, şi reciproc; se
notează cu 1:1 (vezi Figura 6.5, punctul a)).
2) unu-la-mulţi (one-to-many) - este asocierea în care unei entităţi din mulţimea
A îi corespund una sau mai multe entităţi în mulţimea B, dar unei entităţi din B
îi corespunde o singură entitate din mulţimea A; se notează cu 1:N (vezi Figura
6.5, punctul b)).
3) mulţi-la-mulţi (many-to-many) - este asocierea în care unei entităţi din
mulţimea A îi corespund una sau mai multe entităţi în mulţimea B, şi, de
asemenea, unei entităţi din B îi corespund una sau mai multe entităţi din
mulţimea A; se notează cu M:N (vezi Figura 6.5, punctul c)).

Figura 6.5. - Tipuri de asocieri între două mulţimi de entităţi

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

3
Vom descrie în exemplele următoare, modalitatea prin care se stabileste cardinalitatea unei
asocieri. Considerăm exemplul din Figura 6.1.:

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ă nicio 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:

Pentru fiecare grup de valori, respectiv (0, N) si (1,1), vom alege cardinalitatile maxime,
obtinand astfel valoarea (1,N).

4
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 entităţilor 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.

6.3 Reguli de modelare

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ă entităţii cu cardinalitate N (în cazul
nostru FACTURA), devenind atribut de legatura (cheie externa). Deci, CodClient se adaugă
la entitatea FACTURA.

Pentru exemplificarea unei asocieri de tipul N la N (mulţi la mulţi) vom folosi

asocierea de mai jos.
Vom considera câte o realizare pentru fiecare dintre cele doua entitati.

5
 Pentru entitatea Articol_papetărie (se consideră o realizare a entităţii):
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 clienţi) sau se poate factura de mai
multe ori, adica se poate regăsi în maxim N facturi. Se notează, langă entitatea Factura,
astfel:

Pentru entitatea Factura:

Factura cu numarul 652 din data de 23.07.2010, poate conţine, în cantităţi si la preţuri
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_papetărie, astfel:

6
 Pentru fiecare grup de valori, respectiv (1, N) si (0,N), alegem cardinalităţile
maxime, obţinând valoarea (N,N). Deci, am identificat cardinalitatea asocierii de tipul N
la N sau mulţi la mulţi, 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 mulţi la mulţi se realizează astfel: între
cele două entităţi se introduce, în mod artificial, o noua entitate care are, ca atribute de
pornire, identificatorii celor doua entităţi implicate iniţial în asociere.
Pe lângă aceste atribute, proiectantul sistemului va introduce şi atributele
multivaloare, deci cele care exprimă o cantitate, un preţ etc.

Procesul de modelare al asocierii mulţi la mulţi se reprezintă astfel:

Înainte de modelare:

Dupa modelare:

7
S-a introdus entitatea ConţinutFactura care are un identificator compus din identificatorii
celor 2 entităţi, 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ă entităţii cu cardinalitate N, devenind atribut de legatura (cheie
externa).

6.4 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 entitatilor
implicate într-o asociere.
• Modelarea unei asocieri de tipul one-to-many se realizeaza astfel: identificatorul
entitatii cu cardinalitate 1 se adaugă entităţii cu cardinalitate N, devenind atribut de
legatura (cheie externa).
• Modelarea unei asocieri de tipul many-to-many se realizează astfel: între cele două
entităţi se introduce, în mod artificial, o noua entitate care are, ca atribute de pornire,
identificatorii celor doua entităţi implicate iniţial în asociere.

8
 CURS 7. RESTRICŢII DE INTEGRITATE ALE MODELULUI
ENTITATE-ASOCIERE

7.1. Stabilirea restricţiilor de integritate (RI)

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 restricţii
de integritate (RI) şi se clasifică în [Amza,2008]:
§ restricţii la nivelul entităţii;
§ restricţii la nivelul identificatorului unei entitati;
§ restricţii cu privire la rolurile pe care o entitate le joaca în diferitele asocieri în care
se implica;
§ restricţii ale asocierilor.

7.1.1 Restricţii de integritate la nivelul entităţii

Restricţiile la nivelul entităţii se referă la regulile ce privesc coerenţa şi semantica

datelor stocate în cadrul respectivei entităţi.
Exemple de restricţii de integritate la nivelul entităţii:
§ eliminarea redundanţelor (repetărilor) şi a omonimelor în denumirea entităţilor,
atributelor, asocierilor (unicitatea numelui entităţii, atibutelor, asocierilor);
§ respectarea domeniului de valori;
§ respectarea corelaţiilor între valorile atributelor din entităţi diferite sau între cele
din entităţi şi din asocieri, cum ar fi: cantitate_facturată+10<=cantitate_stoc pentru
fiecare articol facturat.

7.1.2 Restricţii de integritate la nivelul identificatorului unei entitati

Restricţiile 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.1.3 Restricţii de integritate la nivelul rolului unei entitati

Restricţiile 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
 1) Incluziunea de roluri exprimă faptul că un rol al entităţii într-o asociere impune
un alt rol al său î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
I

Exemplu: Un client plăteşte numai dacă anterior a primit factura, dar nu toate facturile
primite se si plătesc.

Figura 7.1.

2) Excluziunea de roluri exprimă faptul că, în anumite situaţii, roluri ale aceleiaşi
entităţi 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 acelaşi timp, deci
cele două roluri ale entităţii FACTURA se exclud reciproc.

2
 Figura 7.2.

3) Egalitatea de roluri exprimă o restricţie de incluziune reciprocă între două roluri

ale aceleiaşi entităţi.

Simbol: r1 r2

Exemplu:

3
 Figura 7.3.

Să ne reamintim
Restricţiile 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.1.4 Restricţii ale asocierilor

Restricţiile asocierilor vizează atât asocierea cât si toate entitatile participante la

asociere. Acţionează asupra tuturor rolurilor dintr-o asociere.

Aceleaşi restricţii care se aplică rolurilor, le găsim şi în cazul asocierilor: restricţii 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 restricţii este prezentat în Figura 7.4.

4
 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 restricţii este prezentat în Figura 7.5.

Figura 7.5.

3) Restrictii de egalitate de asocieri

5
 Asocierea A1 stabilita între doua entitati impune existenta unei alte asocieri A2 în cadrul
modelului E-A.
Formalismul grafic pentru reprezentarea acestei restricţii este prezentat în Figura 7.6.

Figura 7.6.

Să ne reamintim
Restricţiile asocierilor vizează atât asocierea cât si toate entitatile participante la asociere.
Acţionează asupra tuturor rolurilor dintr-o asociere.
Aceleaşi restricţii care se aplică rolurilor, le găsim şi în cazul asocierilor: restricţii de
incluziune, excluziune şi egalitate de asocieri.

6
 7.2 Rezumat

• 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
restricţii de integritate (RI) şi se clasifică în:
Ø restricţii la nivelul entităţii;
Ø restricţii la nivelul identificatorului unei entitati;
Ø restricţii cu privire la rolurile pe care o entitate le joaca în diferitele asocieri
în care se implica;
Ø restricţii ale asocierilor.
• Restricţiile la nivelul entităţii se referă la regulile ce privesc coerenţa şi semantica
datelor stocate în cadrul respectivei entităţi.
• Restricţiile la nivelul identificatorului unei entitati se referă la faptul că valorile pe care
le poate lua un identificator, trebuie să fie unice şi nenule.
• Restricţiile 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
• Restricţiile asocierilor vizează atât asocierea cât si toate entitatile participante la
asociere. Acţionează asupra tuturor rolurilor dintr-o asociere.
• Aceleaşi restricţii care se aplică rolurilor, le găsim şi în cazul asocierilor: restricţii de
incluziune, excluziune şi egalitate de asocieri.

7
CURS 8. MODELUL RELAŢIONAL AL DATELOR (MODELUL LOGIC
AL DATELOR)

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

Trecerea de la MCD, care este un model universal, spre o soluţie informatică se
face gradat, luând în considerare un anumit tip de soluţie şi apoi, în cadrul tipului
respectiv, o soluţie direct implementabilă.
Expresia MCD, în termenii unui anumit tip de soluţie informatică, constituie
modelul relaţional (MRD) sau modelul logic al datelor (MLD).
Conceptele de bază ale MRD sunt:
Modelul relaţional are la bază conceptul de relaţie definit în teoria matematică a
mulţimilor ca fiind o submulţime a produsului cartezian al mai multor mulţimi, numite
domenii.
Domeniul reprezintă multimea tuturor valorilor posibile care definesc o anumită
proprietate a unui obiect.
Domeniul poate fi exprimat explicit (se enumeră valorile posibile D:{M, F}) sau
implicit (se precizează proprietăţile valorilor D:{x/x∈N}).
Atributul este o submulţime a unui domeniu, reprezentând multimea valorilor
existente la un moment dat în coloana pe care o desemnează în cadrul relaţiei. Fiecărui
atribut i se atribuie un nume. Numele exprimă rolul sau semnificaţia elementelor
domeniului respectiv.
Relaţiile se reprezintă grafic sub formă de tabele, în care se disting:
§ gradul relaţiei - numărul de atribute (coloane) utilizate;

§ cardinalitatea relaţiei - numărul de tupluri (linii în tabel).

Cardinalitatea unei relaţii este variabilă în timp datorită operaţiilor de actualizare

care pot adăuga sau şterge tupluri.
Tabelele trebuie să tină seama de următoarele restricţii:
§ Ordinea liniilor (tuplurilor) dintr-o tabelă nu este predefinită și nu sunt

admise duplicate;
§ Coloanele sunt identificate prin nume distincte ce reprezintă atributele

relaţiei;
§ În fiecare coloană toate valorile sunt de același fel;

§ Fiecare valoare este un număr sau un șir de caractere.

Schema tabelei este reprezentată prin numele tabelei, urmat între paranteze
rotunde de lista atributelor.

1
Exemplu: Fie tabela Angajat cu atributele: MARCA, NUME, PRENUME,
DATA_NAŞTERE.
Angajat (MARCA,NUME,PRENUME,DATA_NAŞTERE)

Figura 8.1. Tabela Angajat

Pentru o relaţie pot exista 3 tipuri de chei:

• cheie primară: cel mai mic ansamblu de atribute (eventual unul singur) care
permite identificarea fără univoc al fiecărui tuplu al unei relaţii; atributele care
compun cheia primară nu pot să ia valoarea NULL.
• cheie candidat: o altă posibilă cheie primară, care nu a fost însă reţinută ca atare.
• cheie externă: un ansamblu de atribute (eventual unul singur) care este cheie
primară într-o altă relaţie.
Restricţie de integritate referenţială (RIR): dacă între un atribut A şi o cheie
primară B există o RIR atunci A nu poate lua decât valori care există şi în B. Prin definiţie,
cheile externe sunt supuse RIR în raport cu cheile primare corespunzătoare.

Să ne reamintim...
Cheia primară reprezinta cel mai mic ansamblu de atribute (eventual unul singur) care
permite identificarea fără univoc al fiecărui tuplu al unei relaţii; atributele care compun
cheia primară nu pot să ia valoarea NULL.

8.2. Reguli de conversie de la MCD la MLD

2
Trecerea de la MCD la MLD ţine seama de două tipuri de reguli principale, reguli care se
referă la distribuţia datelor pe tipuri de entităţi, precum şi de cardinalităţile 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ă
acelaşi tip de entitate.
Regula 2. Fiecare atribut ce caracterizează o entitate în MCD se transformă, în MLD, într-
o coloană ce apartine tabelei corespunzătoare respectivei entităţi, iar fiecărei asocieri, din
MCD, îi corespunde o legătură în MLD.
Regula 3. Fiecare identificator al unei entităti 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.
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 entitaţi. În realitate, în practică, se ţine cont de ordinea de apariţie a fiecărui 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:

3
Aplicând această regulă, pentru acest MCD vom avea următorul MLD:
Angajat (Marca, Nume, Prenume, Adresa, CodAgenţie)
Agenţie (CodAgenţie, Adresa, Telefon)

Regula 8. În cazul în care două entităţi prezintă o asociere de tipul (N,M), entitatea nou
formată se transformă într-o tabelă având obligatoriu cheia primară constituită din
identificatorii entităţilor participante la asociere (cheile primare ale celor două tabele).
Totodată, atributele proprii ale asocierii devin câmpuri în tabela nou determinată.

Exemplu:

MLD se prezintă astfel:

Poliţă_asigurare (NrPoliţă, Data_început, Data_scadentă)

Risc (CodRisc, DenumireRisc, Franşiză)
Continut_poliţă (NrPoliţă,CodRisc)
Să ne reamintim...
Regulile de conversie de la MCD la MLD se referă la distribuţia datelor pe tipuri de
entităţi, precum şi de cardinalităţile prezentate de asocierile tipului de entitate.

8.3. Modelul fizic al datelor (MFD)

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 (fișierele) care le contin (nume, organizare, localizare etc.),
componentele fiecărui fișier (lungime, câmpuri etc.), căile de acces la componentele
tabelelor (indecși, relații, legături între tabele). De asemenea trebuie să se tină seama de

4
cerintele privind asigurarea protectiei datelor. Trecerea de la MLD la MFD se face utilizând
facilitătile ș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.
Având î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;
• Legăturile dintre tabele sunt asigurate prin corespondentele între cheile primare
și cheile externe.

In concluzie, modelul fizic al datelor se obţine prin reprezentarea MLD într-un

limbaj de descriere a datelor asociat strict unui SGBD. Practic, un SGBD va utiliza acest
MFD pentru operaţii de creare, actualizare, exploatare, listare, reorganizare, salvare,
restaurare, protecţie etc.
Deci MFD este asociat unui SGBD care are următoarele obiective referitoare la
date:
• neredundanţa datelor;
• coerenţa 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;

5
 • Legăturile dintre tabele sunt asigurate prin corespondentele între cheile primare
și cheile externe.

8.4. Rezumat
• Pentru o relaţie pot exista 3 tipuri de chei:
Ø cheie primară: cel mai mic ansamblu de atribute (eventual unul singur)
care permite identificarea fără univoc al fiecărui tuplu al unei relaţii;
atributele care compun cheia primară nu pot să ia valoarea NULL.
Ø cheie candidat: o altă posibilă cheie primară, care nu a fost însă reţinută
ca atare.
Ø cheie externă: un ansamblu de atribute (eventual unul singur) care este
cheie primară într-o altă relaţie.
• Restricţie de integritate referenţială (RIR): dacă între un atribut A şi o cheie
primară B există o RIR atunci A nu poate lua decât valori care există şi în B.
Prin definiţie, cheile externe sunt supuse RIR în raport cu cheile primare
corespunzătoare.
• 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.
• Regulile de conversie de la MCD la MLD se referă la distribuţia datelor pe tipuri
de entităţi, precum şi de cardinalităţile prezentate de asocierile tipului de entitate.

6
 CURS 9. MODELUL ENTITATE-ASOCIERE EXTINS

9.1. Generalizarea şi specializarea

În scopul extinderii capacităţii de modelare a cunoştinţelor din modelul EA, au
fost propuse mai multe modele semantice pentru date. În cele mai multe dintre acestea,
a fost urmărită includerea unor modalităţi de modelare care să permită ca în proiectarea
structurii conceptuale să se ţină seama la un anumit nivel superior de restricţiile
semantice. În acest context, a apărut 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 mulţimile entitate) poartă numele de
clase, ele putând 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.

Sunt considerate extensii ale modelului entitate-asociere următoarele concepte

[Amza, 2008]:
• specializarea
• generalizarea
• reprezentarea (modelarea) timpului.
Pentru explicarea conceptelor vom lua în considerare următorul exemplu:

1
 Figura 8.1 Exemplu de reprezentare a legăturilor 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.
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.

2
 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 următoarele concepte:
generalizarea, specializarea si reprezentarea (modelarea) timpului.

Generalizarea reprezintă procesul prin care un proiectant identifică un grup de

entităţi care au în structura lor aceleaşi atribute şi creează pe baza acestora o nouă
entitate numită superclasă (supertip) a entităţii 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 ramân 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,
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 continând
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 generalizării.

3
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 ramân specifice fiecarui tip.
Mostenirea atributelor.
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

In exemplul anterior (fig. 8.2.) PERSOANE este clasa rădăcină, sau clasa de
bază. Simbolul Ψ reprezintă direcţia asocierii IS-A.
Litera “d”, înscrisa în cercul care leaga subclasele de superclasa, indica o constrângere
de disjunctie impusa specializarii, prezentata in cele ce urmeaza.
Constrângeri 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).

4
 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.2. Reprezentarea timpului

Există situaţii în care domeniul de modelare necesită stocarea unor informaţii de
istoric sau de evoluţie. În general, modelele de date oferă o imagine statică asupra datelor
unui anumit domeniu.
În scopul modelării timpului este necesară introducerea unor entităţi specializate
care să stocheze informaţiile de istoric sau de evoluţie a unui anumit fenomen. Aceste
entităţi nu pot fi identificate decât analizând cerinţele utilizatorului respectivului sistem.
Pentru explicarea acestui concept, vom lua în considerare următorul exemplu:

Figura 8.3 Exemplu de modelare a unor informaţii de istoric

5
 Analizând exemplul putem observa că entitatea PROFESOR aşa cum este
modelată, nu oferă informaţii dinamice privitoare la istoric. Asfel, dacă se doreşte
urmărirea evoluţiei salariului şi al locurilor de muncă, este necesară modelarea timpului
cu introducerea unor entităţi cu caracter istoric.
Entităţile care realizează modelarea timpului, trebuie să conţină informaţiile
privitoare la timp (data, ziua, luna, anul, perioada de lucru etc.).
Din punct de vedere al reprezentării timpului într-o entitate, putem avea
reprezentari sincrone si reprezentări 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 situaţii, nu ne interesează cu exactitate momentul
producerii unui anumit eveniment, caz în care se poate recurge la o reprezentare sincronă.
De exemplu, reţeta unui anumit produs nu are nevoie de reprezentarea datei. Dacă se
doreşte însă o reprezentare a evoluţiei unei reţete în timp, atunci va trebui sa modelăm
timpul.
Este evidenta asemanarea dintre ierarhiile de tipuri de entitati din modelul E-A
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
Constrângerile 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.

9.3. Rezumat

• În modelul EAE, tipurile de entitate (sau mulţimile entitate) poartă numele de

clase, ele putând 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 următoarele concepte:
generalizarea, specializarea si reprezentarea (modelarea) timpului.

6
• 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
entităţi care au în structura lor aceleaşi atribute şi creează pe baza acestora o nouă
entitate numită superclasă (supertip) a entităţii 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).
• Constrângerile 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.

7
 Etapele proiectarii unui sistem informatic (SI)

Etapele proiectarii unui SI utilizand modelul entitate – asociere (E-A) sunt:

1) Identificarea entităților din textul problemei de rezolvat ;
2) Identificarea atributelor entitatilor ;
3) Identificarea identificatorilor entitatilor ;
4) Identificarea asocierilor dintre entitati ;
5) Stabilirea cardinalitatilor asocierilor ;
6) Reprezentarea grafica a entitatilor si intocmirea modelului conceptual al
datelor (MCD).

Identificarea entitatilor
O entitate este descrisa complet atunci cand sunt specificate aspectele :
- Tipul entitatii (clasa entitatii) – ex. : tipul de entitate „masina”
- Realizarea respectivei entitati
Prin realizarea unei entitati se intelege ansamblul valorilor luate la un moment dat
de atributele care descriu respectiva entitate.
Ex : Student (CNP, Nume, Prenume, DataNastere, Nationalitate)
Realizare 1(2822408163312, Stan, Ion, 24-08-1982, Romana)
Atributele unei entități
Pentru a fi descrisă, o entitate trebuie să poată fi identificată printr-un
ansamblu de caracteristici care îi sunt specifice. Aceste caracteristici poartă
denumirea de atribute.
Există mai multe criterii de clasificare a atributelor:
a) După compozabilitatea acestora :
• atribute simple
1
 • atribute compuse
Atributele simple sunt atributele care nu mai pot fi descompuse in alte
atribute. Ex.: atributele „preț”, „nume”, “u.m.”. In general sunt atributele care
exprimă valori.
Atributele compuse pot fi descompuse în mai multe subatribute. De ex.:
atributul „adresa” poate fi descompus in atribute simple: „strada” , „numar”, „cod
postal” etc.
Decizia cu privire la optarea pentru un atribut simplu sau compus, ii apartine
proiectantului in functie de cerintele domeniului de modelat.
b) Dupa modul de stocare al valorii:
• atribute simple (stocheaza valorile asa cum au fost introduse de
utilizator). Ex : „pret”, „cantitate”.
• atribute calculate (isi obtin valoarea prin aplicarea unei formule
asupra unor alte atribute, pentru care utilizatorul a specificat valoarea)
De ex. : atributul „valoare” = pret * cantitate
c) D.p.d.v. al stocabilitatii in baza de date, distingem:
• atribute stocate (valorile atributelor se pastreaza in baza de date)
• atribute nestocate (nu este necesar sa se pastreze valorile in baza de
date). Atributele nestocate si calculate sunt utilizate cand formula
este verificata. De ex. : in cazul TVA nu se poate recurge la un
atribut calculat sau nestocat, deoarece rezultatul
TVA=cantitate*pret*cotaTVA este rotunjit manual, iar valorile
trebuie stocate asa cum sunt mentionate in factura.
d) Dupa obligativitatea specificarii unei valori apartinand unui atribut:
• Atribute optionale
• Atribute obligatorii

2
 e) D.p.d.v. al valorilor pe care le poate lua un atribut:
• Atribute monovaloare – sunt atributele care pentru o anumita
realizare a unei entitati nu pot lua decat o valoare si numai una.
Ex : pentru Realizarea1 ce apartine entitatii Factura, atributele :
NumarFactura(nu poate avea decat valoarea 1), DataFactura,
CodPartener.
• Atribute multivaloare - sunt atributele care pentru o anumita
realizare a unei entitati pot lua mai multe valori.
Daca intr-o entitate exista mai multe atribute multivaloare, entitatea respectiva
trebuie descompusa in mai multe entitati care sa contina numai atribute
monovaloare.
Ex : in entitatea Factura apar 3 atribute multivaloare (Produs, Cantitate, Pret)
care sunt modelate apoi separat intr-o noua entitate ContinutFactura care tine
legatura cu entitatea Factura prin campul de legatura identificator.
Atribute cu rol de identificator :
• Atribute identificator
• Atribute nonidentificator
Un atribut identificator permite identificarea in mod unic a unei anumite realizari
apartinand unei entitati.
Ex : CNP pentru Angajat sau Numar Factura pentru Factura.
Un atribut identificator trebuie sa aiba intotdeauna valoarea cunoscuta si diferita de
NULL.
Criterii de alegere a identificatorului :
- Are intotdeauna o valoare cunoscuta
- Este usor de memorat pentru utilizator
- Trebuie sa fie cat mai scurt
- Se recomanda ca identificatorii sa fie de tip numeric.
3
Caracteristicile unui identificator :
Durabilitate
Stabilitate
Unicitate – valoarea identificatorului trebuie sa fie unica. O entitate nu poate avea
doua atribute cu acelasi nume.
Identificatorul poate fi format din mai multe atribute.
Dupa tipul datelor care sunt continute de un atribut putem avea :
- Atribute de tip text (datele care descriu o anumita entitate sunt de tip
text : nume, prenume, adresa, etc.). Ex : stocarea numerelor de telefon
de tip text.
- Atribute de tip numeric (atribute exprimate valoric sau cantitativ pentru
o anumita entitate : prêt, cantitate, valoare, Cota TVA, etc. ; deci acest
tip de atribut este utilizat in calcule aritmetice)
- Atribute de tip boolean ; valori posibile : Adevarat/Fals ; Da/Nu, 1/0.
- Atribute de tip data si ora
- Atribute binare : se stocheaza informatia care nu poate fi stocata cu
tipurile anterioare. Ex : imagine, clip video/audio.
Lungimea unui atribut
Pentru „nume” o dimensiune de 50 caractere este suficienta.