Universitatea „Danubius” din Galaţi

SISTEME INFORMATICE DE GESTIUNE

Note de curs

Prof. dr. ing. Viorel Ariton

2016
Cuprins

1 Introducere..........................................................................................................................4
1.1 Sistem informaţional şi Sistem Informatic (SI)...........................................................4
1.1.1 Particularităţi ale introducerii unui Sistem Informatic..........................................4
1.1.2 Schema bloc a Sistemului Informatic...................................................................6
1.2 Tipuri de Sisteme Informatice......................................................................................7
1.2.1 Sisteme de prelucrare a tranzacţiilor.....................................................................7
1.2.2 Sisteme de conducere............................................................................................7
1.2.3 Sisteme de asistare a deciziilor.............................................................................8
1.2.4 Sisteme bazate pe cunoştinţe................................................................................8
1.2.5 De la MPR la ERP şi BPR....................................................................................8
1.3 Funcţiile unui Sistem Informatic..................................................................................9
2 Abordări în Sisteme Informatice cu Baze de Date............................................................10
2.1 Cadrul general şi specific al sistemelor cu Baze de Date...........................................10
2.1.1 Principii generale la realizarea unui Sistem Informatic......................................10
2.1.2 Principii de realizare şi utilizare a Bazelor de Date............................................11
2.1.3 Costurile erorilor nedepistate în faza de analiză şi proiectare............................14
2.2 Etape în ciclul de viaţă ale Sistemului Informatic.....................................................14
2.3 Modele de realizare a Sistemelor Informatice...........................................................16
2.3.1 Modelul cascadă..................................................................................................16
2.3.2 Modelul în “V”...................................................................................................17
2.3.3 Modelul incremental...........................................................................................18
2.3.4 Modelul spirală...................................................................................................18
2.3.5 Modelul tridimensional.......................................................................................19
2.3.6 Standardul ISO/ IEC...........................................................................................19
3 Analiza de sistem..............................................................................................................20
3.1.1 Strategii de analiză ale Sistemului Informatic....................................................20
3.1.2 Elemente analizate în sistemul ţintă....................................................................21
3.1.3 Etape în analiza de sistem...................................................................................22
3.2 Tehnici de reprezentare grafică a Sistemelor Informatice.........................................25
3.2.1 Diagrame globale (scheme bloc)........................................................................25
3.2.2 Flux pe orizontală...............................................................................................26
3.3 Modelul Conceptual al Datelor..................................................................................26
3.3.1 Entitate................................................................................................................27
3.3.2 Atribut.................................................................................................................27
3.3.3 Relaţie.................................................................................................................28
3.3.4 Restricţii ale unei relaţii......................................................................................29
3.4 Realizarea MCD.........................................................................................................29
3.4.1 Dependenţe funcţionale ţi tranzitive...................................................................29
3.4.2 Reguli de structurare a MCD..............................................................................30
3.5 Limbajul Unificat de Modelare (UML).....................................................................31
3.5.1 Noţiuni şi notaţii pentru entităţi..........................................................................31
3.5.2 Noţiuni şi notaţii pentru relaţii............................................................................32
3.5.3 Un exemplu de MCD ilustrat prin diagrama UML.............................................33
4 Proiectarea Bazei de Date relaţionale...............................................................................34
4.1 Reguli de Gestiune.....................................................................................................34
4.1.1 Tipuri de reguli de gestiune................................................................................35
4.1.2 Definirea şi stabilirea regulilor de gestiune........................................................35
4.1.3 Exemple de Reguli de Gestiune..........................................................................36
2
 4.2 Niveluri de integritate ale bazei de date.....................................................................37
4.2.1 Integritatea entităţii.............................................................................................37
4.2.2 Integritatea domeniului.......................................................................................38
4.2.3 Integritatea referenţială.......................................................................................38
4.2.4 Integritatea definită de utilizator.........................................................................39
4.3 Normalizarea Bazei de Date.......................................................................................39
4.3.1 Forma Normală 1 (FN1).....................................................................................41
4.3.2 Forma Normală 2 (FN2).....................................................................................42
4.3.3 Forma Normală 3 (FN3).....................................................................................43
4.3.4 Paşi în normalizarea bazei de date şi normalizare avansată...............................44
4.4 Proiectarea de detaliu.................................................................................................45
4.5 Management de proiect..............................................................................................46
4.5.1 Scopuri şi metode în managementul de proiect..................................................46
4.5.2 Estimarea realizării priectului.............................................................................48
4.5.3 Fazele managementului de proiect......................................................................49
4.5.4 Costurile managementului de proiect.................................................................49
5 De planificarea resurselor (ERP) la productica lină (Lean Manufacturing).....................50
5.1 Sisteme informatice utilizate în procesele de afaceri.................................................50
5.1.1 Sisteme informatice de marketing (SIMK).........................................................51
5.1.2 Sisteme informatice de producţie (SIQ).............................................................54
5.2 Integrarea sistemelor informatice prin ERP...............................................................56
5.2.1 În ce mod este util un sistem ERP......................................................................57
5.2.2 Consolidarea afacerii prin ERP...........................................................................58
5.2.3 Alegerea ERP......................................................................................................59
5.3 Sisteme de execuţie şi fabricare.................................................................................59
5.4 De la ERP la Lean Manufacturing.............................................................................60
5.4.1 Concepte ale Producticii line (Lean Manufacturing)..........................................61
5.4.2 Cei 5S..................................................................................................................62
5.4.3 Kanban................................................................................................................62
5.4.4 Kaizens................................................................................................................62
5.4.5 Harta fluxului de valoare (VSM)........................................................................62
5.5 Implementarea Lean...................................................................................................63
5.6 Sistemele ERP sprijină implementarea conceptelor Lean..........................................64
Bibliografie...............................................................................................................................67

3
1 Introducere
Un sistem este un ansamblu de părţi componente cu legături reciproce, care se referă la
o zonă a lumii reale şi descrie o structură de modelare a acesteia.
Un model este o imagine conceptuală a unor obiecte din realitate, care ilustrează
proprietăţile şi comportarea lor, precum şi interacţiunile dintre ele, în scopul cunoaşterii sau
controlului realităţii vizate. Modelul poate fi abstract (de exemplu un model matematic sau o
schemă grafică) sau poate fi material (de exemplu o machetă la scară). În general, orice model
care se va implementarea pe un sistem de calcul trebuie să aibă o reprezentare matematică
distinctă şi se bazează pe o simulare pe calculator a sistemului ţintă (real).
Abordarea oricărui sistem (ca model) începe cu identificarea părţilor sale (dacă acestea
sunt evidente) sau cu divizarea artificială a părţilor, după care se identifică legăturile dintre
ele. Discriminarea părţilor componente se face prin analiză – pentru fiecare component
rezultând o serie de caracteristici şi moduri de comportare, adică fiecare component este
modelat separat. Pentru ca sistemul realizat să ilustreze cât mai fidel realitatea, se recompun
părţile prin sinteză adică se refac legăturile dintre componente, spre a obţine comportarea de
ansamblu ce se doreşte modelată.
Atât analiza cât şi sinteza sistemului se realizează urmărind o metodologie specifică
domeniului ştiinţific vizat, a zonei ţintă şi contextul în de lucru, precum şi a scopului
modelării (cunoaştere, control, simulare, etc.). Pentru verificarea concordanţei modelului cu
realitatea vizată, se elaborează sau se folosesc metode de evaluare a comportării întregului,
atât pentru verificarea performanţele dorite în scop cât şi pentru utilizarea eficientă a
modelului în scopul propus. Cel mai adesea, un sistem se bazează pe un formalism, adică pe o
exprimare simbolică a obiectelor (ca proprietăţi) şi a relaţiilor între ele (ca interacţiuni), cum
este de exemplu exprimarea prin formule matematice a fenomenelor fizice sau economice.

1.1 Sistem informaţional şi Sistem Informatic (SI)

Un sistem informaţional este ansamblul mărimilor cantitative şi a raporturilor
calitative între obiecte dintr-o zonă a lumii reale. În general, un sistem informaţional priveşte
documentele (şi informaţiile conţinute de acestea) care se vehiculează în activitatea umană din
zona reală de interes.
Un sistem informatic (prescurtat în continuare SI) este format din totalitatea resurse
fizice (echipamente de calcul, de stocare, de prezentare şi de transfer date) împreună cu
resurse logice (programe şi date propriu-zise) care aplicate peste un sistem informaţional cresc
eficienţa manipulării informaţiilor şi a funcţionării acestuia.

1.1.1 Particularităţi ale introducerii unui Sistem Informatic

SI poate fi privit ca o automatizare a sistemului informaţional al organizaţiei,
suprapunându-se peste acesta din urmă şi nu înlocuindu-l în totalitate. Sunt rare cazurile în
care SI asigură şi comunicaţiile prin voce şi imagine (de exemplu prin video-teleconferinţă)
practicate în organizaţii.
Cum datele sunt informaţii într-o reprezentare adecvată prelucrării şi stocării lor prin
mijloace informatice, este evident că SI se bazează pe conversia tuturor informaţiilor de
interes în date, cu structurarea, stocarea şi prelucrarea acestora pentru o utilitate anume a
omului. Programele care asigură manipularea datelor vor viza acţiuni de prelucrare, de
transfer şi de prezentare a rezultatelor spre acea utilitate.
Ca idee generală, scopul unui SI este creşterea eficienţei în prelucrarea şi comunicarea
informaţiilor. Astfel, omul este degrevat de acţiuni de rutină (în care omul poate greşi) dar în
plus se obţin prelucrarea rapidă, prezentarea intuitivă şi completă a rezultatelor, transferul
rapid şi sigur al informaţiilor. Trebuie remarcat că sistemele informatice actuale permit
prelucrarea datelor pe un nivel calitativ superior, prin asistarea utilizatorului uman în luarea
deciziilor, prin în prognoze şi chiar prin expertiza asupra unor probleme complexe (similar
activităţilor unor experţi umani). Eficienţa unui SI este reflectată în reducerea costurilor, în
creşterea preciziei şi a vitezei de răspuns în rezolvarea diverselor probleme. SI contribuie însă
şi la creşterea productivităţii prin reducerea resurselor implicate în diverse procese, prin
conducerea efectivă, cu precizie şi promptitudine a proceselor, precum şi la asistarea omului
pentru luarea unor decizii dificile.
În timp ce până nu demult calculatorul era considerat un instrument de plus valoare,
astăzi acesta este utilizat pentru administrarea şi chiar generarea de cunoştinţe. Un SI adecvat
şi folosit corespunzător este atât de eficient încât el poate contribui indirect la îmbunătăţirea
organizării muncii, a calităţii informaţiilor şi produselor, la decizii optime şi la comunicaţie
fără restricţii.
Un SI aduce însă şi probleme organizaţiei şi persoanelor care îl utilizează: Aceste
probleme pot fi legate de:
 Calitate – atunci când soluţia informatică la problemele organizaţiei este de calitate
slabă, ducând la pierderi şi nu la câştiguri prin utilizarea sa. Acelaşi rezultat se obţine şi
la folosirea incorectă a unui SI (calitatea slabă a pregătirii utilizatorilor) prin lipsa de
competenţă a utilizatorilor, prin furnizarea de date incorecte sau perimate, prin
neglijarea sau utilizarea ne-corespunzătoare a rezultatelor.
 Productivitate – atunci când costurile sau durata de realizare a SI sunt prea mari.
Trebuie ţinut cont de faptul că pe lângă costurile vizibile sunt şi costuri ascunse – legate
de refacerea soluţiei pe durata realizării sistemului, de pregătirea personalului sau de
dotări auxiliare necesare funcţionării sistemului.
 Întreţinere – atunci când sistemul realizat nu este actualizat la condiţiile curente (ca
date şi prelucrări) sau când echipamentele nu sunt verificate periodic şi aduse în
parametrii de bună funcţionare. Întreţinerea implică la rândul ei costuri permanente care
trebuie luate în considerare corespunzător dimensiunilor sistemului.
 Fiabilitatea – ca siguranţă în funcţionare a sistemului, referitor la rata mică de defectare
a echipamentelor şi programelor, la toleranţa la defecte (capacitatea de revenire în
funcţionare după un defect, cu pierderi de date şi timp de prelucrare convenabile), la
siguranţa datelor şi programelor (ca modalitate şi loc de păstrare a suporturilor cu date
şi programe pentru a fi ferite de distrugere – prin neglijenţă, rea voinţă sau calamităţi).
Asigurarea fiabilităţii sistemului implică costuri pentru: echipamente şi programe de
calitate, suporturi de memorare dublate, spaţii de depozitare speciale pentru suporturile
de date.
 Securitate – ca mijloace de prevenire şi împiedicare a accesului neautorizat la sistem şi
date, a fraudei informatice sau acţiunilor rău-voitoare asupra sistemului. Costurile
privesc sisteme performante antivirus, antifraudă, şi antiefracţie, care trebuie în plus
actualizate permanent.
 Factor uman – ca impact psihologic şi mod de acceptare a SI de către utilizatorii umani.
Prin introducerea unui sisteme informatic personalul uman se poate simţi urmărit şi
verificat în acţiunile sale, poate fi frustrat de inutilitatea cunoştinţelor şi aportului său
faţă de cel al mijloacelor de informatizare, astfel că de aici pot apare incidente de
muncă sau utilizarea necorespunzătoare a sistemului.
Asemenea situaţii duc la compromiterea SI – chiar dacă acesta este realizat corect. O a
treia situaţie de compromitere a sistemului informatic apare atunci când el este realizat după
cerinţele beneficiarului, dar acesta din urmă ori nu cunoaşte bine domeniul ţintă, ori nu are
soluţii adecvate la problemele sale, ori de-a dreptul nu ştie ce vrea.
Aspectele prezentate mai sus nu sunt argumente împotriva introducerii unui SI ci
reprezintă situaţii ce trebuie rezolvate atât de proiectant cât şi de organizaţia beneficiară,
pentru a asigura un SI de calitate, care să atingă scopurile vizate.
Neglijarea aspectelor de mai sus duce la lucrări de calitate proastă, cheltuieli
suplimentare şi chiar compromiterea sistemului informatic; poate apare astfel falsa părere că
SI este inutil, ceea ce va bloca progresul şi va provoca chiar eliminarea din competiţia globală
a organizaţiei respective.
Pe de altă parte, este la fel de falsă părerea că o problemă oarecare a unei organizaţii se
poate rezolva prin introducerea unui SI fără a se cunoaşte în prealabil soluţia şi a se adapta
această soluţie la specificul organizaţiei. Dacă nu se cunoaşte bine problema şi nu se dispune
de o soluţie adecvată (elaborată local sau în exterior de specialişti avizaţi) problema nu va
putea fi rezolvată şi din nou, pe nedrept, se ajunge la compromiterea sistemului informatic. În
asemenea situaţii se consideră că a fost aplicată „metoda” denumită pe scurt GIGO (garbage
in garbage out – adică, în traducere liberă, gunoi se prelucrează gunoi se obţine) – evident o
exprimare în glumă a unei situaţii defectuoase, exprimare ce exploatează acronimele atât de
des folosite în mediul informatic.

1.1.2 Schema bloc a Sistemului Informatic

Structura de principiu a unui SI este cea din Figura 1-1., în care:
- Ieşiri sunt de fapt rezultatele vizate.
- Intrări sunt toate informaţiile preluate din mediu necesare obţinerii ieşirilor.
- Prelucrările sunt operaţiunile prin care intrările devin ieşiri.
- Controlul sistemului asigură funcţionarea coerentă a sistemului prin comenzi adecvate.
Contur

Anticipare Retroacţiune
Control
Comandă Comandă

Comandă

Intrări Prelucrare Ieşiri

Figura 1-1 Structura bloc de principiu a unui SI.

Facilităţile de retroacţiune şi de anticipare sunt adăugate unui SI modern pentru a

depista abaterile ieşirilor de la performanţele vizate (prin retroacţiune) şi a prezice intrări utile
la paşi ulteriori (prin anticipare). Retroacţiunea (denumită uzual şi reacţie iar în engleză feed-
back) dă caracterul cibernetic al sistemului informatic, mai precis caracterul de adaptabilitate
(specific fiinţelor vii), care este foarte necesar pentru flexibilitatea în funcţionare a sistemului
într-un context dinamic (adică un context ce se modifică în timp). Anticiparea (în engleză
feed-forward), este o facilitate care permite asistarea deciziilor complexe în conducerea
sistemului real (pe baza sistemului informatic care, eventual, îl simulează pe cel real). Astfel,
sistemele informatice moderne nu sunt numai un ajutor pasiv (de evidenţă a unor fapte
trecute) ci şi un sprijin activ în conducerea eficientă a sistemului ţintă – peste care s-a aplicat
SI. Evident, aceste facilităţi nu se întâlnesc la sistemul informaţional - care este în sine pasiv,
doar omul fiind cel care-l animă, omul fiind factorul activ. Cunoştinţele „active” ale omului
sunt înglobate sistemului informatic, astfel că aceste din urmă se poate „comporta” ca un
expert în domeniul ţintă, spre a creşte eficienţa de manipulare a informaţiilor pentru
utilizatorul uman.
Conceptul de sistem este o abstracţie legată de o zonă din lumea reală; graniţa dintre
sistemul propriu-zis şi mediul înconjurător este stabilită arbitrar, dar este foarte importantă
pentru analiza şi realizarea sistemului informatic. Această graniţă – denumită Contur (v.
§3.1.2) se stabileşte de la primele faze de analiză ale sistemului vizat.
 1.2 Tipuri de Sisteme Informatice
S-a arătat mai sus că SI are ca rol creşterea eficienţei manipulării informaţiilor – dintr-
un sistem informaţional. Fiindcă, în general, sistemul informaţional este deja existent (şi
trebuie doar eficientizat prin informatizare) Sistemele Informatice se mai numesc şi Sisteme
de Informatizare, subliniind prin această titulatură aportul activ de adaptare a vechiului sistem
la cel nou - folosind mijloace de calcul electronic. Informatizarea este aşadar, acţiunea de
adaptare şi transpunere a Sistemului Informaţional în SI.
O operaţiune elementară prin care se face acces la date în scopul modificării lor se
numeşte tranzacţie. Există două categorii de tranzacţii:
 Tranzacţii externe - ce privesc proceselor economice şi operaţiuni efectuate cu
exteriorul firmei (aprovizionare, încasări, plăţi). Intrările pot fi preluate de pe
documentele scrise, local sau prin Internet (de la distanţă – prin EDI - Electronical Data
Interchange).
 Tranzacţii interne - unde datele sunt preluate în SI pornind de la rezultate parţiale
obţinute în interiorul sistemului
Există mai multe categorii de Sisteme Informatice, după o clasificare ce ţine cont de
locul şi modul de utilizare a Sistemului Informatic, aşa cum se prezintă în continuare.

1.2.1 Sisteme de prelucrare a tranzacţiilor

Sistemele de prelucrare a tranzacţiilor (TPS Tranzaction Processing Systems) - execută
operaţii de rutină zilnice asupra înregistrărilor unei baze de date şi nu duc neapărat la
prelucrări într-un scop de eficientizare a utilizării datelor. TPS se utilizează mai ales în
gestiunea (evidenţa) resurselor unei organizaţii (fie aceste resurse, materiale, produse,
persoane, sau activităţi). Toate organizaţiile prezintă cinci categorii de TPS utilizate manual
sau cu ajutorul unor mijloace automatizate:
1) Sisteme de marketing – au ca funcţii de bază controlul şi evidenţa cererii şi ofertei,
prospectarea pieţei, stabilirea şi alocarea preţurilor, gestiunea de mărfuri produse.
Aplicaţii uzuale: sunt sisteme de informare şi vânzare, sisteme de prospectare a pieţei şi
sisteme de preţuri.
2) Sisteme de conducere a producţiei – au ca funcţii de bază planificarea, aprovizionarea şi
desfacerea, transportul şi recepţia de marfă, controlul proceselor (în domeniul
ingineresc) operaţiuni de întreţinere a echipamentelor. Aplicaţii uzuale sunt: sisteme de
planificare a resurselor materiale, sisteme de control a achiziţiei şi desfacerii de produse,
sisteme de conducere a proceselor şi sisteme de control a calităţii.
3) Sisteme financiare – au ca funcţii de bază controlul bugetului, al taxelor (schimb de
bani), al contabilităţii costurilor şi controlul financiar. Aplicaţii uzuale sunt: sisteme
contabile, sisteme de planificare şi bilanţ al bugetului şi sisteme de gestiune financiară.
4) Sisteme de personal – au ca funcţii de bază evidenţa salariilor, evidenţa şi formarea
profesională. Aplicaţii uzuale sunt: calculul salariilor, evidenţa şi urmărirea personalului,
sisteme de urmărire a beneficiilor, sisteme de urmărire a carierei, sisteme de calificare a
personalului şi educaţie asistată de calculator (local şi la distanţă).
5) Sisteme de evidenţă în educaţie şi cultură – au ca funcţii de bază controlul examenelor
de admitere, evidenţa notelor şi a situaţiilor şcolare, evidenţa lucrărilor de administrare
în cercetare, evidenţa şi prezentarea cursurilor şi urmărirea materialelor bibliografice. Au
ca aplicaţii de bază sisteme de informare în biblioteci, evidenţa situaţiei şcolare, evidenţa
activităţii de cercetare, sisteme de educaţie asincronă (pe calculator).

1.2.2 Sisteme de conducere

Sistemele informatice de conducere (MIS - Management Information Systems) sunt
utile activităţilor de conducere ale firmei şi au următoarele funcţii:
 Asistă conducerea în luarea deciziilor pe baza evaluării sintetice a informaţiilor multiple
preluate din sistemul real.
  Asigură implementarea unor mecanisme şi metode pentru organizarea muncii.
 Asigură planificarea producţiei şi resurselor ţinând cont de restricţiile exterioare şi
interioare.
Caracteristici:
- sunt orientate spre raportare şi mai rar către control;
- asigură controlul operaţiilor zilnice;
- se bazează pe fluxul de informaţii din întreaga întreprindere (atât fluxuri materiale
cât şi financiare);
- au reale capacităţi analitice;
- privesc spre trecut şi spre prezent, nu spre viitor;
- sunt relaţii inflexibile fiind specifice firmei respective;
- au o orientare spre interesul firmei şi nu spre exterior;
- informaţiile trebuie să sosească în mod ordonat şi stabil;
- necesită perioade lungi de analiză şi proiectare.

1.2.3 Sisteme de asistare a deciziilor

Sistemele de asistare a deciziilor (DSS – Decision Support Systems) completează MIS
cu mijloace de predicţie şi sugerare a măsurilor de luat în viitor şi sunt prevăzute cu modele
de predicţie şi modele de conducere pentru a furniza sugestii conducătorilor.
Cerinţe şi moduri de utilizare:
- trebuie să fie flexibile (adaptate uşor) şi cu timp mic de răspuns;
- lucrează sub iniţiativa şi controlul omului;
- trebuie să necesite pregătire profesională de specialitate;
- trebuie să asiste probleme şi decizii nestructurate (fără un model cunoscut anterior);
- trebuie să permită decizii pentru conducerea de nivel înalt.
DSS se bazează pe MIS, sistemul este interactiv şi conţine cunoştinţe generale de
conducere dar şi speciale.

1.2.4 Sisteme bazate pe cunoştinţe

Sistemele sunt bazate pe cunoştinţe (KBS Knowledge Based Systems) sau sisteme
expert sunt sisteme ce au înglobate tehnici de inteligenţă artificială. Sunt utile pentru asistarea
deciziilor, pentru predicţii sau pentru conducere empirică a unei activităţi economice.
Expertul într-un domeniu este o persoană ultracalificată prin educaţie şi experienţă care nu
poate formula pe loc o explicaţie a deciziei sale. Totuşi, cunoştinţele sale pot fi înglobate într-
un KBS şi apoi utilizate de oricine în domeniul dat. KBS poate fi de două tipuri: sisteme
simbolice - care emulează sistemele umane de raţionament (emit judecăţi) şi sisteme
subsimbolice – care emulează recunoaşterea şi raţionamentul aproximativ, folosind reţele
neuronale artificiale, logică Fuzzy şi algoritmi genetici.

1.2.5 De la MPR la ERP şi BPR

În evoluţia lor istorică, SI aplicate în economie au parcurs mai multe etape:
 în anii 1960 funcţionau sisteme de evidenţă de inventar;
 în anii 1970 au apărut sisteme de planificare a necesarului de materiale MRP
(Manufacturing Requirement Planning) care extrag din planul de producţie necesarul de
componente şi subansamble ce trebuie aprovizionalte;
 în anii 1980 au apărut sisteme MRP II (Manufacturing Resource Planning) care adăugaul
a sisteme MRP facilităţi de planificare şi management distribuit al a producţiei;
 în anii 1990 sistemele MRP II au fost extinse în evidenţe financiare, de resurse umane şi
conducere a proiectelor (project management);
 în anii 2000 au apărut sisteme integrate de rezolvare corelată a problemelor întreprinderii,
denumite ERP (Enterprise Resource Planning).
 Sistemele ERP constau dintr-un set de aplicaţii care rezolvă atât probleme financiare,
probleme de planificare a producţiei, probleme de resurse umane şi plăţi.
Tendinţa de dezvoltare a sistemelor de gestiune şi control al resurselor se îndreaptă către
sisteme IPR (Intelligent Resource Planning) al firmei BAAN, şi spre sisteme de tip BPR
(Business Process Reengineering) – care oferă soluţii de restructurare a resurselor umane şi de
reorganizare a producţiei pentru maximizarea profitului. Sistemele de control al activităţilor
economice sunt completate cu sisteme de comunicaţie şi transfer financiar electronice,
cunoscute drept EDI (Electronic Data Interchange), care fac legătura firmei cu banca,
transportatori, autorităţi vânzători.

1.3 Funcţiile unui Sistem Informatic

În general un Sistem Informatic trebuie să îndeplinească o serie de funcţii standard,
după cum urmează:
1) Colectarea datelor – constă în preluarea datelor necesare funcţionării Sistemului
Informatic; datele sunt:
 Colectate de pe documente scrise (prin intermediul operatorilor umani);
 Achiziţionate din mediu prin senzori .
În această etapă datele sunt denumite date primare şi ele trebuie validate (verificate dacă
sunt conform realităţii şi formatului specific de intrare). După culegere şi validare,
datele sunt stocate pe suport extern. Urmează selectarea datelor pentru prelucrări. Dacă
este necesar, se face codificarea datelor (ca prelucrare preliminară utilizării lor în
continuare).
2) Codificarea datelor – reprezintă ataşarea unei valori numerice (un cod) către o un nume
de produs pentru a fi identificat. În realizarea sa un cod prezintă o serie simboluri (de
obicei cifre) împărţite pe ranguri şi grupuri de ranguri, fiecare indicând clase utilizate
într-o codificare arborescentă a obiectelor din mulţimea de referinţă.
3) Conversia datelor – constă în transformarea datelor dintr-un tip de date în altul mai
adecvat prelucrării sau interpretării lor.
4) Transmiterea datelor. Uneori, este necesară transmiterea la distanţă a datelor prin reţele
de calculatoare. Transmiterea trebuie sa se facă: exact, rapid şi confidenţial; între doi
parteneri ocazionali trebuie sa aibă loc autentificarea fiecăruia (adică fiecare de partea sa
să aibă confirmarea ca celalalt nu este cel care pretinde că este şi nu un impostor).
5) Funcţia de arhivare. Pentru volume mari de date, care trebuie păstrate mai mult timp
(pentru utilizare ulterioară sau pentru recuperarea datelor corecte în caz că apar erori la
cele curente) este necesară stocarea datelor într-un format special – comprimat şi
organizat pentru păstrarea şi recuperarea rapidă). Acţiunea de selecţie a datelor recent
modificate, cu comprimarea şi structurarea lor pentru păstrare îndelungată se numeşte
arhivare; ea trebuie să se realizeze periodic, pentru a deţine o arhivă actualizată şi utilă
în refacerea eventuală a datelor pierdute accidental. Arhivarea se numeşte şi “salvare”
(Back Up) iar refacerea datelor prin extragerea lor din arhivă cu reîncărcarea lor pentru
utilizare se numeşte “restaurare” (Restore).
6) Funcţia de control-verificare - este funcţia de depistare a unor eventuale situaţii eronate
rezultate din analiza datelor.
7) Funcţia de prelucrare – asigură transferul datelor dar şi operaţiuni precum: sortarea,
regăsirea, clasificarea datelor.
8) Funcţia de raportare şi prezentare - constă în afişarea unor rezultate pe hârtie (rapoarte)
sau pe ecran. Prezentarea este un aspect foarte important în utilizarea şi interpretarea
datelor, în plus permiţând utilizarea comodă a aplicaţiei. Modalitatea de prezentare
uzuală este Interfaţa Utilizator Grafica (GUI – Graphical User Interface) folosind
elemente precum casete, butoane grafice, liste, etc.
2 Abordări în Sisteme Informatice cu Baze de Date
Pentru rezolvarea corectă şi completă a problemelor vizate de un SI este necesară
respectarea unor principii şi adoptarea unor modele care permit parcurgerea sistematică a
activităţilor implicate în realizarea respectivului sistem. Chiar dacă modelele diferă (mai mult
sau mai puţin) de la o abordare la alta, toate îşi propun o cale optimă de urmat în soluţionarea
problemelor.
Pe de altă parte, specificul sistemelor cu Baze de Date induce o serie de restricţii şi
aduce totodată metode de lucru de care trebuie să se ţină cont în proiectarea şi realizarea
sistemului.

2.1 Cadrul general şi specific al sistemelor cu Baze de Date

Principiile prezentate în continuare se referă la cadrul general al Sistemelor Informatice
şi la cadrul particular al sistemelor cu Baze de Date. Cele două categorii de principii trebui
respectate simultan pentru obţinerea rapidă a unui SI de calitate şi care să poată fi refăcut cu
uşurinţă în viitor.

2.1.1 Principii generale la realizarea unui Sistem Informatic

Prin însăşi menirea sa, SI manipulează informaţii dintr-un domeniu anume (informaţii
care există indiferent că sunt sau nu prelucrate automat) în ajutorul omului ca utilizator final
al informaţiilor, serviciilor sau produselor pentru care se foloseşte sistemul. Cerinţele generale
impuse utilizării unui SI privesc trei aspecte de bază:
 Eficienţa – adică obţinerea unor avantaje (materiale, de timp sau de organizare) legate
de domeniul automatizat;
 Utilizarea facilă – adică interacţiunea comodă dintre om şi SI (privitor la modul de
înţelegere a modului de lucru şi la operarea la sistem);
 Scalabilitatea – adică posibilitatea de a creşte sau micşora dimensiunea sistemului fără
modificări majore ale acestuia.
Legat de activităţile de proiectare şi implementare, trebuie remarcat că o latură a
eficienţei Sistemului Informatic se referă la modul cum se asigura re-utilizarea părţilor deja
realizate la alte sisteme similare sau la dezvoltarea aceluiaşi sistem.
Principiile comun acceptate în realizarea unui SI sunt:
a) Abordarea globală a problemelor de rezolvat, pentru a se obţine o privire de ansamblu
atât a sistemului ţintă cât şi a sistemelor cu care el interacţionează. Se pot extrage astfel
chestiunile prioritare care trebuie rezolvate prin SI şi se poate face o eşalonare a
dezvoltării de viitor a acestuia.
b) Utilizarea unei metodologii unitare, prin care se tratează toate problemele ce pot apare
la proiectarea dar şi la implementarea sistemului informatic, spre a elimina erori şi
neconcordanţe de concepţie şi execuţie. Metodologiile clasice utilizate structurează
informaţiile în abordarea diagramă entitate-relaţie (spre exemplu metoda MERISE) sau
în abordare obiectuală (de exemplu OMT - Object Modelling Technique). Metodologia
modernă, folosită astăzi pe scară largă, este UML (Unified Modelling Language), care
integrează cele două abordări şi oferă un formalism şi o sistematizare eficientă a
informaţiilor, a prelucrărilor lor şi a planificării etapelor de proiectare, pentru realizarea
unui SI de orice tip şi de orice dimensiune.
c) Structurarea sistemului informatic cât mai independent de structura organizatorică a
firmei asigură funcţionarea sistemului informatic şi în cazul modificărilor organizatorice
în cadrul firmei.
d) Participarea nemijlocită a viitorului beneficiar la activitatea de analiză, proiectare şi
implementare a sistemului informatic ajută la depistarea tuturor problemelor
beneficiarului şi la rezolvarea acestora.
 e) Respectarea cadrului legislativ este o cerinţă majoră. SI de gestiune trebuie să respecte
reglementările în vigoare pentru prelucrări, tipărire de documente şi formate ale
rapoartelor finale.
f) Realizarea sistemului informatic trebuie sa se facă în concordanţă cu resursele
disponibile la utilizator.
g) Reutilizarea unor părţi ale sistemului (vechi) existent sau ale unor componente realizate
deja pentru sistemul existent sau pentru alte sisteme asemănătoare.
h) Schimbarea (în sensul dezvoltării) sistemului trebuie să se facă cu prevederea acestei
situaţii încă din etapa de proiectare. Compromisurile (inerente schimbării) trebuie
explicitate şi documentate.

Respectând aceste principii, se poate trece la analiza şi proiectarea Sistemului

Informatic – din care rezultă un plan de acţiuni şi resurse necesare, după care se trece la
implementarea sistemului – adică la punerea în operă a planului.
Un model este o structură de cunoştinţe care priveşte o secţiune a realităţii, adică o
reprezentare coerentă cu scopul sau utilitatea propuse. Scopul poate fi un produs fizic iar
utilitatea poate fi un serviciu. În cazul Sistemelor Informatice, totdeauna se urmăreşte
realizarea unui serviciu, chiar dacă acesta poate fi pus în slujba realizării unui produs,
deoarece SI priveşte culegerea, prelucrarea şi transmiterea informaţiilor – care nu sunt obiecte
fizice ci valori, concepte, cunoştinţe sau comenzi.
O metodologie este o cale optimă de urmat către obţinerea unui scop, şi cuprinde
acţiunile desfăşurate în paşi (în succesiune, cu ramificaţii şi repetiţii); calea „optimă” este
calea cea mai eficientă din punctul de vedere al consumul de resurse (materiale, financiare,
umane, timp) şi se obţine după acumularea de experienţă şi chiar de expertiză în domeniul dat.
Trebuie remarcat că există diverse căi prin care se poate realiza ceva, dar este calea optimă
este cea de cost minim; de aceea, în competiţia continuă din lumea modernă nu va reuşi decât
cel care adoptă şi respectă metodologiile cele mai noi, verificate.
În contextul Sistemelor Informatice, metodologiile sunt specifice domeniului în care se
doreşte automatizarea prelucrării informaţiilor, dar deja se conturează o abordare uniformă şi
chiar o standardizare a fazelor de analiză şi proiectare, privind modul în care acestea sunt
modelate şi conduse.

2.1.2 Principii de realizare şi utilizare a Bazelor de Date

Aceste principii sunt cunoscute şi ca „Regulile lui Codd” privitoare la Teoria
Relaţională a Bazelor de Date, care au fost elaborate de E.F. Codd, după cercetările sale în
domeniul bazelor de date. Aceste principii pornesc de la ideea că bază de date relaţională este
nu doar o colecţie de tabele cu legături între ele, ci se conformează algebrei relaţionale din
domeniul matematicii. Produsul software cu care se realizează sistemul de baze de date
(cunoscute şi sub numele de SGBD – Sistem de Gestiune a Bazelor de Date) trebuie să
asigure respectarea acestor principii, adică să se conformeze lor şi chiar să asiste omul în
realizarea corectă a Bazei de Date.

Cele 12 reguli sunt prezentate scurt mai jos.

I. Datele sunt structurate în tabele
- Un tabel (denumit şi relaţie sau entitate) este o grupare logică de date prezentată în
forma tabelară - pe linii şi coloane. Ex.: tabelul Student ce (cu studenţii unei
facultăţi) se referă la entitatea „student” folosită la urmărirea situaţiei şcolare a
studenţilor, când se doreşte automatizarea evidenţei la secretariatul facultăţii.
- O linie (denumită şi articol sau înregistrare) descrie un obiect (persoană, loc sau lucru);
fiecare linie conţine informaţii asupra unui singur subiect din tabel. Ex.: linia care
descrie un anume student (fie acesta Popescu M. Ion, cu numărul de legitimaţie 732).
 - O coloană (denumită şi câmp) descrie o singură caracteristică privitoare la un obiect,
adică descrie o proprietate generică a entităţii pe care o reprezintă tabelul. Ex.: coloana
Nume care conţine numele de familie a studentului.
- Fiecare valoare este apare la intersecţia dintre linie şi coloană. Ex.: valoarea Popescu
în coloana Nume, sau valoarea 732 în coloana Numar_Legitimatie, pe aceeaşi
linie.
- Data este atomică, adică nu există mai mult de o valoare asociată cu intersecţia dintre o
linie şi o coloană. Ex.: în coloana Nume a tabelului Student apare doar valoarea
Popescu (nu şi prenumele sau iniţiala tatălui).
- Nu există ordine între tabele – în sensul de succesiune sau ierarhie fixă, şi un tabel ce
stochează date nu va conţine pe un altul.
- Relaţia între tabele este logică, adică nu există o relaţie fizică (fixă) înscrisă în
program.
II. Datele sunt accesibile din punct de vedere logic în Baza de Date relaţională
- informaţia nu este referită (adresată) prin locaţia fizică (de pe suportul de memorare).
Ex.: un anume student nu se poate indica prin “al 3-lea rând” în tabelul Student.
- Orice informaţie trebuie să fie accesibilă logic indicând 1) un tabel 2) o cheie unică de
identificare (cheie primară) 3) o coloană. Ex.: un „obiect” student se poate accesa prin
indicarea tabelului Student, a cheii Numar_Legitimatie a şi coloanei din care
se doreşte informaţia – de exemplu Nume.
III. Valorile lipsă (vide) sunt tratate uniform ca „necunoscute”
- Valoare lipsă (denumită şi NULL) este interpretate întotdeauna valoare necunoscută;
aceasta fie nu a fost introdusă fie nu este într-adevăr cunoscută.
- Şirul vid la şiruri de caractere (indicat prin “” – adică „nici o literă”) şi 0 (zero) la
numere nu înseamnă valoare “necunoscută” ci pot fi doar valori de iniţializare. Ex.:
dacă un student nu are trecută în tabel nota de la bacalureat nu înseamnă că acesta nu l-
a absolvit (altfel nu ar fi admis) ci înseamnă, că pentru moment, nota nu a fost
introdusă.
- Dacă nu sunt manipulate corect, valorile vide pot provoca anomalii în baza da date. Ex.
valoare vidă la Numar_Legitimatie pentru un student anume va face imposibilă
găsirea sa în tabelul Fisa_Student – unde are toate datele situaţiei şcolare.
IV. O bază de date este auto-descriptivă
- Baza de date relaţională conţine atât informaţii utilizator – date despre obiecte din
lumea reală aflate în tabele) dar şi informaţii despre ea însăşi – date ce descriu structura
obiectelor din baza de date (de exemplu capul de tabel, structura unei machete, etc.).
- Datele ce descriu obiectele din baza de date sunt denumite meta-date şi sunt stocate în
„tabele sistem” care sunt este accesate în acelaşi mod ca şi tabelele utilizator.
- Colecţia de tabele sistem este denumită şi catalog sistem sau dicţionar de date
V. Comunicarea cu SGBD se face într-un limbaj unic pentru date şi meta-date
- Limbajul general acceptat actualmente este SQL (pronunţat „sequel” în engleză).
- Limbajul trebuie să suporte operaţii relaţionale legate de: actualizarea/modificarea
datelor (de ex. operaţiile SELECT, INSERT, UPDATE, DELETE), definirea datelor
(de ex. CREATE, ALTER, DROP) şi administrare (de ex. GRANT, REVOKE,
BACKUP, RESTORE).
VI. O bază de date oferă alternative în consultarea informaţiilor
- Datele din baza de date pot fi consultate direct în tabelele sursă – aşa cum sunt ele
stocate pe suport extern, sau pot fi vizualizate în „tabele virtuale” (denumite „views” în
engleză şi denumite vizualizări în continuare) – care de exemplu rezultă în urma unor
interogări.
- O vizualizare permite consultarea datelor din unul sau mai multe tabele (sau din alte
tabele virtuale) prin combinarea dorită a liniilor şi coloanelor în tabelul virtual rezultat.
- O vizualizare este definită de utilizator (indicând sursele de date, precum şi structura de
linii şi coloane); tabelul rezultat nu dublează informaţia din tabelele sursă ci este doar o
afişare a lor în forma dorită; tabelul rezultat poate fi utilizat apoi ca sursă de date.
- O vizualizare poate conţine şi date agregate care nu se regăsesc în tabelele sursă ci
provin ca rezultat prin prelucrări efectuate asupra datelor sursă. De exemplu, din notele
individuale ale studenţilor (aflate în tabelele sursă) tabelul rezultat „vizualizează”
media notelor obţinute la o disciplină (ca date noi).
VII. Baza de date permite operaţii relaţionale
- Liniile sunt considerate elementele iar tabelul mulţimea care le conţine.
- Asupra liniilor se pot aplica operaţii relaţionale (SELECT, INSERT, UPDATE,
DELETE) şi operaţii pe mulţimi (reuniune, intersecţie, diviziune, diferenţă)
- Operaţiile relaţionale şi pe mulţimi operează pe relaţii (tabele) producând alte relaţii.
- O bază de date care permite doar operaţii pe fiecare linie (prin „navigare” în tabele) nu
este considerată o bază de date “relaţională”.
VIII. Independenţa fizică a datelor
- Aplicaţiile care accesează informaţii într-o bază de date relaţională nu trebuie să fie
afectate de schimbări în modul de stocare fizică a informaţiilor (de ex. schimbarea
poziţiilor coloanelor în tabel sau a adreselor datelor pe disc).
- Aplicaţia care accesează informaţia într-o bază de date relaţională „ştie” doar
caracteristicile generale ale informaţiei (tipul de dată şi lungimea) dar nu trebuie să ştie
cum este informaţia accesată sau stocată fizic.
IX. Independenţa logică a datelor
- Interdependenţa logică înseamnă că relaţiile dintre tabele se pot schimba fără să
afecteze funcţionarea aplicaţiilor şi a interogărilor.
- Structura de obiecte de lucru (adică tabele, interogări, machete, etc.) din baza de date
sau structura tabelelor şi relaţiilor (logice) între ele se poate modifica fără să fie
necesară refacerea bazei de date sau a aplicaţiei care o foloseşte.
X. Integritatea datelor este o funcţie a DBMS
- Pentru a fi considerată relaţională, integritatea datelor trebuie asigurată de însăşi baza
de date (de fapt de SGBD) şi nu de programul de aplicaţie.
- Integritatea datelor constă în menţinerea consistenţei şi preciziei informaţiei în baza de
date. Există trei tipuri de integritate a datelor: integritatea entităţii, de domeniu şi
referenţială (v.§4.2.3)
- În baza de date, asigurarea integrităţii se poate face procedural – prin mici programe
(proceduri) care forţează condiţiile de integritate, sau se poate face declarativ – prin
declararea explicită a condiţiilor de integritate la crearea liniilor şi coloanelor.
XI. Baza de date permite distribuirea operaţiilor
- Datele dintr-o bază de date relaţională trebuie să poate fi stocate centralizat (pe un
singur calculator) sau distribuit (pe mai multe calculatoare interconectate – în reţea).
- Utilizatorii pot combina date provenite din tabele din acelaşi tip de bază de date aflate
pe diferite calculatoare (servere) sau din alte tipuri de baze de date relaţionale.
- Integritatea datelor trebuie asigurată indiferent de numărul de copii ale datelor şi
indiferent unde acestea sunt stocate.
XII. Accesul direct la date să nu poată afecta integritatea datelor
- Accesul la date se poate prin căile oferite de baza de date dar şi prin căi „directe” – de
ex. prin intermediul unui program scris în limbajul C şi care „citeşte” informaţia din
tabele.
- Accesul direct trebuie să nu afecteze integritatea datelor amintită mai sus, mai precis
SGBD trebuie să împiedice ca intervenţia prin limbajul maşinii să afecteze integritatea
datelor.
2.1.3 Costurile erorilor nedepistate în faza de analiză şi proiectare
Analiza şi proiectarea sistemului informatic sunt etape foarte importante în realizarea
unui SI, iar folosirea unei metodologii adecvate este esenţială în reuşita acesteia. Sunt dese
cazurile în care realizarea Sistemului Informatic se lasă pe seama unor persoane care au
experienţă în domeniul hardware sau chiar software dar care nu cunosc sau nu aplică o
metodologie adecvată în acest demers; rezultatul muncii lor – făcute după impresii şi judecăţi
ad-hoc, va fi ori un sistem prost sau inutilizabil ori va duce la costuri foarte ridicate datorită
multelor erori care vor fi depistate la implementare sau chiar la utilizarea sistemului.

Costuri
x100

x10

Proiectare Implementare Exploatare

Figura 2-1 Costuri implicate de rezolvarea unei probleme în cele trei etape principale în
realizarea unui sistem informatic.

Costurile de rezolvare ale unei probleme legate de funcţionarea sau utilizarea sistemului
cresc cu câte un ordin de mărime (de 10 ori) de la etapa de proiectare la cea de implementare
şi apoi la cea de exploatare a sistemului (v. Figura 2-1). Cu cât se rezolvă mai multor
probleme la etapa de (analiză) şi proiectare, cu atât mai puţine situaţii neaşteptate apar şi vor
trebui rezolvate la implementarea sau la exploatarea sistemului, când este deja târziu şi
costisitor a se renunţa la echipamente, bani şi muncă investite dar nefolositoare.
Succesul soluţiei adoptate şi a investiţiei este asigurat doar de folosirea corectă (adică
respectarea) unei metodologii adecvate problemei de rezolvat. De aceea, astăzi, se cheltuiesc
mulţi bani pentru achiziţionarea unui sistem de proiectare asistată de calculator (CAD) sau un
sistem pentru analiza şi proiectarea software asistată (CASE) care permit dezvoltarea corectă
şi în timp scurt, cu investiţie, erori şi eforturi minime în rezolvarea cu succes a problemelor ce
apar la realizarea unui SI. Dacă nu se cunoaşte sau nu se caută o metodologie corectă, este
mai bine a se apela la firme specializate, care pot dovedi că au avut succes în realizarea
sistemelor informatice la alţi beneficiari.
Un SI în sine nu este o soluţie şi nu rezolvă problemele de gestiune, de organizare sau
de conducere ale unui organizaţii decât dacă soluţiile (dar mai ales metodele de soluţionare)
sunt corect analizate, elaborate şi testate. Problemele sunt efectiv rezolvate ca principiu de om
(de expert sau de beneficiar) în faza de analiză competentă a domeniului, după care
implementarea vine doar să pună în operă soluţiile adoptate. Durata prea mare de dezvoltare
(de creare sau de refacere) a unui SI precum şi adaptarea la noi situaţii pe o durată prea
îndelungată duc la cheltuieli mari şi la rezultate slabe.

2.2 Etape în ciclul de viaţă ale Sistemului Informatic

Pe parcursul realizării şi utilizării Sistemului Informatic, apar diferite etape ca durata şi
rol, care trebuie abordate în mod specific şi cu personal specializat, care se finalizează cu
documente specifice, cu produse software şi hardware pentru rezolvarea problemei date. Se
vorbeşte de „ciclul de viaţă” al Sistemului Informatic, pentru că succesiunea de etape se
repetă într-un ciclu prin care se obţine şi apoi se rafinează soluţia problemei. Etapele ciclului
de viaţă sunt:
1) Definirea cerinţelor utilizatorului – priveşte extragerea prin interviu sau expertiză la faţa
locului a problemelor de rezolvat cu viitorul SI. Documentul întocmit este „Studiul de
necesitate” şi este elaborat de o echipă care, eventual, va fi şi beneficiara sistemului
informatic. Echipa de lucru este condusă de o persoana care, în mod normal, face parte
din conducerea firmei beneficiare, pentru a avea responsabilitate şi putere de decizie în
diversele chestiuni ce pot apare.
2) Analiza de sistem detaliază scopurile vizate, datele şi prelucrările necesare precum şi
resursele necesare: programe, echipamente, resurse umane, finanţe. Persoanele implicate
în această etapă trebuie să cunoască bine problemele dar şi soluţiile lor, fiind specialişti
în domeniul ţintă dar având şi cunoştinţe de proiectare, de informatică şi cunoştinţe de
management al proiectelor. În această etapă se elaborează „Specificaţiile de proiectare”,
care prevăd estimativ resursele hardware, software şi auxiliare necesare. Conform
acestor cerinţe, se elaborează o structură a sistemului care poate să realizeze funcţiile
dorite şi se indică modalităţile de testare care pot atesta atingerea scopurilor. urmărind o
metodă anume. Pentru a realiza cu succes şi eficienţă această etapă este necesară
adoptarea şi respectarea unei o metodologii - adică a unei abordări ştiinţifice şi
sistematice verificate. Astăzi, pentru această etapă se pot folosi instrumente CASE
(Computer Aided Software Engineering) care asistă analistul de sistem în definirea
structurilor şi funcţiilor pe module, în proiectarea lor, iar apoi poate genera aplicaţia
(codul programului) şi chiar întocmi în linii mari documentaţia de proiectare.
3) Proiectarea logică – priveşte etapa de concepţie a structurilor şi a elementelor ce
compun SI, care vor constitui ulterior baza pentru realizarea sistemului. Sunt implicaţi
analişti programatori şi specialişti care stabilesc cadrul în care se va realiza şi va
funcţiona SI: resurse fizice existente, aplicaţii existente şi necesare, modul de realizare a
aplicaţiilor şi structurii de echipamente; în această etapă se stabileşte şi modul general de
desfăşurare a acţiunile de implementare. Documentul elaborat este „Proiectul de
ansamblu”.
4) Proiectarea fizică - în cadrul căreia se detaliază toate datele şi procedurile implicate în
rezolvarea problemei date, precum şi modalitatea de realizare şi instalare a structurii de
echipament. Pe partea de programe se realizează structura modulară şi funcţiunile
modulelor, pe partea de echipament se realizează schema de amplasare a echipamentelor
cu instrucţiuni de instalare, iar pe partea de lucrări se face planificarea în detaliu a
operaţiunilor de execuţie. Documentul elaborat este „Proiectul de detaliu” şi
„Specificaţii de programare”.
5) Implementarea Sistemului Informatic - cuprinde multitudinea de operaţiuni de
programare (codificare), precum şi instalarea echipamentelor şi programelor necesare
funcţionării sistemului. Documentele realizate în această etapă sunt „Programe sursă
documentate” şi „Documentaţia de funcţionare”.
6) Testarea individuală a modulelor – constă în verificarea funcţionării modulelor şi a
interacţiunii lor cu module vecine. Este posibil ca anumite module să nu execute funcţiile
dorite, şi atunci se reiau pentru acestea (sau chiar pentru întreg ansamblul) etapele 4, 5,
6, până la obţinerea rezultatului dorit. Documentele întocmite sunt „Foi de test” – prin
care se constată conformitatea (sau nu) a funcţionării modulelor cu specificaţiile de
programare şi se indică tipul şi locul erorii.
7) Integrarea componentelor şi testarea finală a Sistemului Informatic – constă în
asamblarea tuturor componentelor fizice (echipamente) şi logice (date şi programe), care
vor funcţiona împreună pentru realizarea scopului propus, după care se face testarea
ansamblului spre a se verifica atingerea acestui scop. Testarea finala «de punere în
funcţiune» durează cel puţin 3 zile; testarea sa de către personalul de exploatare indică
dacă sistemul este realizat în conformitate cu cerinţele beneficiarului, dacă este sigur şi
dacă este uşor utilizabil (dacă sunt probleme de operare). Uneori există şi o etapă de
 testare a comunicaţiei pentru cazul în care beneficiarul este distant. Documentul întocmit
la finalul etapei este „Procesul verbal de dare în exploatare”, semnat de către realizatori
şi de către beneficiar.
8) Exploatarea şi întreţinerea Sistemului Informatic. Exploatarea implică utilizarea de
personal pregătit special, deci presupune şcolarizarea personalului utilizator. Întreţinerea
constă în rezolvarea incidentelor de proastă funcţionare sau de nefuncţionare ale SI,
pentru care soluţionarea constă în menţinerea copiilor de rezervă pentru date şi
programe, configurare sau chiar reinstalare periodică a aplicaţiilor, precum şi controlul şi
menţinerea în stare bună de funcţionare a echipamentelor fizice.
9) Dezvoltarea Sistemului Informatic – constă în adăugarea sau modificarea unor module
pentru a satisface mai bine cerinţele impuse sau pentru a rezolva noi cerinţe. În scopul
dezvoltării facile atât a modulelor software cât şi hardware, este necesară realizarea unei
documentaţii amănunţite privind structura şi funcţionarea SI; această documentaţie
trebuie realizată cel târziu în faza de testare finală, înainte de darea în exploatare şi
trebuie sa conţină funcţiile şi modul de realizare a modulelor, manualul de utilizare şi
ajutor pe loc (help). De obicei, dezvoltarea se realizează de o alta echipa decât cea care a
creat SI, de aceea documentaţia trebuie să fie atât de amănunţită încât să nu pună
probleme de înţelegere sau de modificare a programelor. Astăzi, mediile de proiectare
(CASE Computer Aided Software Engineering) şi cele de programare oferă şi facilitatea
documentării automate, venind în ajutorul proiectantului şi programatorului.
Realizarea unui sistem cu baze de date respectă (în general) o metodologie care este
specifică tipului de SGBD utilizat la implementarea sistemului. Se deosebesc două familii
mari de abordări care s-au impus actual în lume: abordarea relaţională şi abordarea obiectuală.
Astfel, de la etapa de analiză şi până la etapa de model fizic se vor folosi terminologii şi
simboluri specifice uneia din abordări, orientate spre diagrama Entitate-Relaţie sau pe
descrierea obiectuală a domeniului. În cele ce urmează se va prezenta doar prima abordare, în
care simbolistica de reprezentare a diagramei Entitate-Relaţie va fi cea clasică (v. Figura 3–
15) sau UML (v. Figura 3–19)

2.3 Modele de realizare a Sistemelor Informatice

În evoluţia lor, metodele de analiză şi proiectare a Sistemelor Informatice au cunoscut
trei generaţii:
 Modele ierarhice - care se bazează pe descompunerea ierarhică a acţiunilor mari în
subacţiuni.
 Modele sistemice – care vizează module cu acţiuni specifice ce rezultă de obicei dintr-
o metodă sau printr-un instrument care asistă proiectantul.
 Modele obiectuale – care discriminează în lumea reală obiecte generice ca sunt
implementate apoi ca obiecte software.
În continuare se face o succintă trecere în revistă a modelelor cunoscute în proiectarea şi
realizarea Sistemelor Informatice, la unele dintre acestea indicând etapele din ciclul de viaţă
cu numerele de ordine care apar la §2.1.1., chiar dacă apar diferenţe faţă de structura generală
indicată la acel paragraf.

2.3.1 Modelul cascadă

Prezintă o curgere logică a etapelor din ciclul de viaţă a (indicată prin săgeata ) cu
revenire în cazul invalidării unor chestiuni specifice etapei, care trebuie revăzute (săgeata ).
 Analiz. sist. inf. 1-2

Planif. lucrărilor 3

Proiectarea generală 3

Proiectare de detaliu

Programare 5, 6

Integrare, testare 7

Exploatare, dezv. 8 ,9

Figura 2-2 Modelul cascadă de realizare a Sistemului Informatic.

2.3.2 Modelul în “V”

Acest model este o variantă a modelului cascadă în care locul central este ocupat de
programare (codificare). Acest model este folosit uzual la sisteme orientate obiect.

1 9

2 8

3 7

4 8

Codificare şi Testare componente

Figura 2-3 Modelul în „V” de realizare a Sistemului Informatic.

2.3.3 Modelul incremental
Este un model în care o componentă sau un grup de componente este realizat
independent de celelalte adăugându-se sistemului unul câte unul până la obţinerea
ansamblului. Acesta este un mod de lucru eficient, abordat în echipă şi coordonat de un
conducător de echipă de proiect. Se aplică începând de la etapa 5 până la etapa 8.
Componentele pot fi reutilizate în alte proiecte.
Analiză de sistem

Proiectarea Arhitecturi

Realizare Componen

Proiectare

Testare Predare Planificare

Implementar
Integrare

Figura 2-4 Modelul incremental în realizarea Sistemului Informatic.

2.3.4 Modelul spirală

Acţiunile se succed una după alta, iar spirala indică curgerea timpului şi totodată etapele
conceptuale (spre centru) şi cele de implementare (spre periferie).

Dare în exploatare
Analiză
sistem

Analiză
Integrare sistem Proiectar

Integrare Proiectar
Startare Proiect

TestarePlan activităţi

Implementare
Testare Plan activităţi

Implementare

Figura 2-5 Modelul în spirală de realizare a Sistemului Informatic.

Diferitele etape au corespondenţă şi schimb de informaţii între ele (atunci când se află în
acelaşi cadran). Modelul cuprinde o strategie de management de proiect bazată pe natura
iterativă a procesului de realizare a Sistemului Informatic.

2.3.5 Modelul tridimensional

Acest model este utilizat în metoda MERISE şi indică trei direcţii implicate în
dezvoltarea Sistemului Informatic: Abstractizarea – dimensiunea de conceptualizare, Decizia
– dimensiune de acţiune umană, Ciclul de viaţă – dimensiune de dezvoltare.
Prescurtările ce apar în Figura 2-6 se referă la:
 Nivelul conceptual - priveşte abordarea abstractă a datelor şi prelucrărilor adică modelul
conceptual al datelor (MCD) şi al prelucrărilor (MCP)
 Nivelul logic - priveşte abordarea din punct de vedere relaţional, uşor de implementat ca
date şi prelucrări prin modelul logic al datelor MLD şi modelul logic al prelucrărilor MLP
 Nivelul fizic - priveşte realizarea efectivă a fişierelor cu date şi cu prelucrări – MFD
modelul fizic al datelor şi MFP – modelul fizic al prelucrărilor.
 Deciziile pot fi:
- generale – se referă la modul de lucru pe ansamblu
- tehnice – vizează suportul hardware de prelucrare şi comunicaţie
- organizaţionale - legate de modul cum se pune în operă sistemul.
 Ciclul de viaţă - priveşte etapele 1 la 11 din §2.1.1.

Abstractizare

MFD+MFP Nivel fizic

MLD+MLP Nivel logic

MFD+MFP Nivel conceptual

Decizii tehnice
Decizii organizatorice
Decizii generale

Decizie
Ciclu de viaţă

Figura 2-6 Modelul tridimensional în realizarea Sistemului Informatic.

2.3.6 Standardul ISO/ IEC

Institutul mondial de standarde ISO – International Standards Organization, şi IEC –
International Electrotehnical Comision au elaborat şi promovează prin standardul ISO / IEC –
12207 o modalitate unitară de abordare a sistemelor informatice. Astfel, standardul stabileşte
un cadru comun pt. procesele ciclului de viaţă fără a impune un model anume. Cadrul se
referă la 5 procese primare, 8 procese ajutătoare şi 4 procese organizatorice. Fiecare proces
prezintă un set de activităţi şi activităţile ei conţin seturi de task-uri (sarcini).

A. Procese primare
1. procesul de achiziţie – cuprinde activităţi derulate de furnizorul sistemului informatic în
pentru analiza şi soluţionarea problemei de rezolvat;
2. procesul de furnizare – cuprinde activităţi de predare parţială şi finală a produselor
informatice;
3. procesul de dezvoltare – activităţi derulate pentru crearea şi adăugarea de facilităţi de
prelucrare şi prezentare a informaţiei (adică noi interogări, module program, etc.);
4. procesul de exploatare – cuprinde activităţi realizate de organizatorul desemnat să
folosească sistemele informatice (utilizatorul / beneficiarul prelucrează informaţiile de
interes);
5. Procesul de întreţinere – cuprinde activităţi realizate de organizatorul desemnat să
întreţină în funcţie sistemelor informatice;
Procesele primare vizează acţiuni în realizarea sistemelor informatice prin prisma
actorilor. În cazul în care beneficiarul sistemului este şi cel care îl exploatează şi îl întreţine
actorul de o parte se reduce la beneficiar şi actorul de furnizare este cealaltă parte.

B. Procese ajutătoare – care sprijină alte procese, contribuind la calitatea software.

1. procesul de documentare – activităţi de înregistrare a informaţiei şi prelucrărilor;
2. procesul de gestiune a configuraţiei cuprinde derularea activităţilor de conducere şi se
adresează procedurilor administrative şi tehnice pe parcursul proiectului software (se
stabilesc proceduri de control pentru stocarea, manipularea şi livrarea componentelor
software, stabilind modificările şi versiunile succesive);
3. procesul de asigurare a calităţii se referă la modul de abordare a informaţiei; activitate ce
asigură îndeplinirea condiţiilor de calitate şi care se bazează în general şi pe următoarele
procese ajutătoare;
4. procesul de testare cuprinde activitatea realizată de beneficiar şi furnizor pt. verificarea
produselor pornind de la cerinţe stabilite anterior;
5. procesul de validare – acţiuni realizate de beneficiari pt. verificarea şi confirmarea
respectării cerinţelor pt. utilizarea sistemului;
6. procesul de analiză comună – activităţi de evaluare a stării sistemului informatic atât de
către furnizor cât şi de beneficiar;
7. procesul de auditare – activităţi desfăşurate pt. determinarea gradului de îndeplinire a
cerinţelor, procedurilor contractuale, fazelor de realizare a sistemului informatic;
8. procesul de depanare – remediere a defecţiunilor.

C. Procese organizatorice
1. procese de management – ca activitate de bază pentru conducerea proiectului;
2. proiectul de infrastructură – activitate pentru stabilirea, realizarea şi întreţinerea
infrastructurii, adică a necesarului de hardware, software, tehnici, metode, standarde şi
facilităţi de dezvoltare;
3. îmbunătăţirea procesului – pentru a măsura, controla şi îmbunătăţi un proces oarecare;
4. formarea personalului ca activitate de pregătire profesională.

3 Analiza de sistem
Activitatea de analiză de sistem are ca scop cunoaşterea completă şi corectă a
problemelor de rezolvat în domeniul vizat şi elaborarea unei soluţii de principiu corecte şi
fezabile (adică realistă şi realizabilă în limita resurselor disponibile). Activitatea de analiză
constă în discriminarea elementelor ce apar în lumea reală şi legăturilor dintre ele aşa cum
apar în domeniul ales, precum şi stabilirea ansamblului de activităţi care trebuie desfăşurate în
scopul realizării sistemului propus.

3.1.1 Strategii de analiză ale Sistemului Informatic

În analiza sistemului ţintă se deosebesc trei strategii de principiu: strategia descendentă
(TOP-DOWN), strategia ascendentă (BOTTOM-UP) şi strategia mixtă (cele două mixate).
Strategia descendentă priveşte proiectarea şi realizarea sistemului informatic pornind
de la general spre particular. Se analizează la început ansamblul şi apoi se trece la detalii, prin
divizarea logică a ansamblului. Metoda are avantajul scalabilităţii, adică proprietatea de a
putea extinde sau dezvolta sistemul sau de a-l reduce şi diviza fără modificări esenţiale (de
concepţie sau de implementare). În cazul unui sistem de gestiune se face analiza de ansamblu
a întregii activităţi a firmei şi se delimitează domeniile de acţiuni specifice, după care se trece
la detalierea acţiunilor din fiecare domeniu. Strategia TOP-DOWN se foloseşte pentru sisteme
informatice complexe cu arie largă de cuprindere sau care vizează soluţii globale. Pe măsura
dezvoltării componentelor din arhitectura generală a sistemului se testează acestea individual
cât şi în legătură cu celelalte componente. Metoda este utilă în faza de analiză chiar dacă
există un singur domeniu ţintă. Dezavantajul metodei provine din faptul că pentru o nouă
problemă de rezolvat, analiza şi implementarea trebuie refăcute - fiind specifice, iar blocurile
obţinute prin detaliere trebuie realizate din nou.
Strategia ascendentă priveşte elaborarea soluţiei pornind de la particular spre general.
Se analizează de la început, în detaliu, acţiuni şi resurse necesare, după care se realizează
“componente” (adică module de prelucrare) specifice. Se pot obţine soluţii noi cu
aplicabilitate generală din soluţii cunoscute dar aplicabile la cazuri particulare. În SI de
gestiune se abordează domeniile specifice de gestiune fără a exista o soluţie cadru generală
dar care se poate obţine ulterior prin punerea în acord a acestora. Un mare avantaj al acestei
strategii este adus de reutilizarea componentelor (în diverse alte sisteme – similare sau
diferite), unde acestea se asamblează după problema de rezolvat. Dezavantajul major este
adus de dificultatea analizei unei noi probleme şi abordarea rezolvării pornind exclusive de la
componentele (existente sau nou create).
Strategia mixtă reprezintă o combinaţie între primele două strategii, în general
abordându-se analiza şi proiectarea sistemului prin metoda TOP-DOWN, iar realizarea
acestuia prin metoda BOTTOM-UP.
Pe parcursul realizării şi utilizării sistemului informatic, diferite etape ca durată în timp
prezintă caracteristici ce trebuiesc evaluate şi abordate specific de către echipa de
implementare şi/sau conducere.

3.1.2 Elemente analizate în sistemul ţintă

O primă fază în analiza sistemului ţintă constă în stabilirea conturului domeniului ce
urmează a fi informatizat.
Contur

Producţie

Departament

Aprovizionare

Conducere
Transport

Figura 3-1 Separarea zonei de interes de celelalte zone, prin contur.

În exemplul din
Figura 3-1 se indică separarea Departamentului Aprovizionare de restul firmei, cu care
acesta are legături dar de care se deosebeşte prin funcţiunile specifice şi prin prelucrările care
se doresc automatizate.
 După cum s-a arătat la §1.1.2 şi în Figura 1-1, blocurile de principiu ale viitorului SI
sunt Intrări, Ieşiri, Prelucrări şi Control. Dacă blocul de Control nu apare explicit în structura
sistemului, el trebuie realizat de către personalul utilizator. Prin control se urmăreşte
ritmicitatea şi precizia prelucrărilor sau se intervine în situaţii în care ieşirile nu sunt conform
specificaţiilor de la proiectarea sistemului.
Intrările reprezintă ansamblul datelor încărcate manual sau automat în sistem. Acestea
intervin prin tranzacţii externe şi tranzacţii interne.
Tranzacţiile externe redau dinamica aplicaţiilor şi proceselor economice şi financiare
din cadrul firmei. Ele provin din exteriorul sistemului informatic şi reprezintă date privind
aprovizionarea cu materii prime, date de încasări şi plăţi, etc. Pot fi date consemnate pe
documente (facturi), date din mediul economic-financiar (legate de prevederi legale de genul
ordin de plată şi cotă TVA), date din sistemele informaţionale (altele decât domeniul vizat al
sistemului informatic al firmei), cât şi date din sisteme informatice exterioare firmei. Intrările
pot fi preluate fizic de la periferice utilizate de către om (tastatură) şi de la dispozitive pentru
cartele magnetice. Datele pot fi introduse şi de la distanţă prin Internet cu ajutorul
formularelor WEB sau EDI (Electronic Data Interchange).
Cu ajutorul tranzacţiilor interne datele sunt preluate din SI ca rezultate ale altor
prelucrări. Exemple pot fi valoarea totală a produselor sau valoarea produselor cu TVA.
Prelucrările privesc operaţii de calcul dar şi operaţii de tipul căutare, sortare, extragere
a unor informaţii, filtrare după criterii stabilite, comasare de informaţii şi operaţii logice. În
general prelucrările vizează crearea iniţială şi actualizarea bazei de date, exploatarea,
reorganizarea, salvarea şi restaurarea bazei de date (BACK-UP, RESTORE). Salvarea
înseamnă înscrierea periodică pe suportul magnetic a informaţiilor din baza de date la
momentul curent. Restaurarea se face prin reîncărcarea în baza de date după un eveniment sau
se face ca o operaţie periodică în cazul sistemelor distribuite.
Ieşirile privesc rezultatele prelucrărilor şi pot fi ieşiri în urma operaţiilor de transfer a
datelor care nu şi-au modificat valoarea (numărul şi data facturii, denumirea produsului) şi
ieşiri obţinute în urma unor operaţii conform unor algoritmi. Pentru cele două categorii
testarea rezultatelor este specifică, în al doilea caz fiind necesare intrări şi rezultate de test
cunoscute pentru a putea depista corectitudinea prelucrărilor. Ieşirile pot fi indicatori sintetici
reprezentând valori unice (scalare) şi indicatori analitici ce apar sub forma unor tabele.
Rapoartele conţin indicatori sintetici şi analitici prezentaţi într-un document unitar şi o formă
impusă de lege (stat de plată, balanţă sintetică), conţinând date de stare ale domeniului
informatizat (starea patrimoniului, starea vânzărilor, etc.). Rapoartele statistice conţin
indicatori sintetici utili luării deciziilor de către conducerea firmei. Rapoartele previzionale
oferă sugestii pentru decizii viitoare pe baza prelucrării suplimentare a datelor din trecut.
După destinaţie rapoartele pot fi de uz intern sau de uz general, iar după frecvenţă rapoartele
pot fi zilnice, lunare sau trimestriale. Ele pot conţine grafice pentru evaluarea calitativă a unor
evoluţii utile în luarea deciziilor.

3.1.3 Etape în analiza de sistem

Realizarea unui SI poate avea loc în două situaţii de fapt: 1) ca adăugire pentru un
sistem informatic deja existent şi 2) ca sistem nou. În primul caz, analiza de sistem se bazează
pe elemente arhitecturale (de structură a sistemului), pe date şi programe existente la care
trebuie adăugate noi date şi programe compatibile cu cele vechi, pe când în al doilea caz
analiza de sistem porneşte de la zero şi se bazează pe documente (hârtii scrise) care se
întocmesc şi se prelucrează manual de către lucrătorii din domeniul analizat. În acest ultim
caz este necesară cunoaşterea structurii organizaţiei, a rolului fiecărui element în activităţile
vizate şi a restricţiilor de lucru specifice. Acţiunea de cunoaştere a situaţiei concrete are loc
prin interviuri cu personale beneficiare (manageri şi lucrători) şi apoi prin reunirea
cunoştinţelor într-un model care permite o reprezentare precisă (pe ansamblu şi apoi în
detaliu) a operaţiunilor şi informaţiilor culese.
 În cadrul analizei intervin în principal două categorii de persoane: analişti şi beneficiari;
analistul conduce interviurile făcute beneficiarilor şi extrage cunoştinţele care apoi vor fi
codificate (adică primesc notaţii precise) şi formalizate (adică relaţiile între ele sunt exprimate
prin formule sau proceduri precise), pentru a fi apoi înglobate în SI. Analiştii sunt persoane
care de obicei sunt experţi în domeniul vizat şi în plus au cunoştinţe în informatică şi în teoria
sistemelor; ei sunt cei care doresc să cunoască în amănunt problemele de rezolvat şi de aceea
intervievează viitorii beneficiari ai Sistemului Informatic. Beneficiarii sunt lucrători în locul şi
în domeniul vizate, dar şi conducători ale organizaţiei la diferite niveluri.
Desfăşurarea cu succes a analizei este în responsabilitatea analistului; acesta este uneori
chiar o persoană care lucrează în domeniul şi locul vizate (economist, contabil, inginer, etc.).
Există diverse abordări privind desfăşurarea analizei de sistem; mai jos se prezintă o abordare
procedurală sistematică propusă în [3].
3.1.3.1 Înţelegerea cerinţelor beneficiarului
Se inventariază chestiunile de rezolvat şi „aşteptările” pe care beneficiarul le are de la SI
viitor. În demersul de înţelegere a cerinţelor trebuie implicat şi beneficiarul nu numai
analistul, fiindcă deseori beneficiarul nu formulează complet şi corect cerinţele – datorită
faptului că unele detalii le omite considerându-le subînţelese, nu le dă atenţie sau nu le ştie. În
[4] se fac următoarele recomandări pentru o analiză de succes:
 Formulaţi clar obiectivele urmărite.
 Stabiliţi unde trebuie să faceţi compromisuri la obiective în conflict.
 Stabiliţi priorităţi şi schimbaţi priorităţi atunci când se impun.
 Realizaţi un model al sistemului (grafic şi procedural), indicând efecte colaterale şi
schimbări pe termen lung.
 Stabiliţi de ce date aveţi nevoie şi care este volumul lor.
 Nu abstractizaţi excesiv şi nu reduceţi totul la o idee, un caz sau fapt.
 Ţineţi cont de părerea celor care vă atrag atenţia asupra unor „greşeli”.
 Aplicaţi metode cunoscute când vă sunt folositoare dar evitaţi-le când vă încurcă.
 Studiaţi istoricul desfăşurării analizei şi „lecţiile” căpătate.
 Gândiţi termeni de sistem (prin elemente şi legături) nu doar în termeni de cerinţe.
3.1.3.2 Clasificarea cerinţelor
Este fundamental să se realizeze o clasificare a cerinţelor prin prisma specificului lor,
pentru a fi caracterizate şi detaliate uşor. În general, categoriile după care se face clasificarea
sunt:
 Obiecte şi proprietăţi – se deosebesc diverse obiecte lumea reală, se împart în
categorii şi se exprimă caracteristici generice pentru fiecare categorie de obiecte (adică
proprietăţile ale acestora). Categoria de obiecte va deveni un tabel, un obiect anume
devine o linie din tabel, o proprietate devine o coloană în tabel, o anume proprietate a
unui obiect devine o valoare.
 Obiective operaţionale – exprimă scopurile urmărite prin introducerea SI precum şi
modurile în care se pot atinge. Ele se referă la „ce se doreşte” şi „cum se poate
obţine”.
 Reguli de lucru (denumite şi „reguli de gestiune”) – sunt condiţii şi restricţii impuse
proprietăţilor (privind limitele valorilor, cazuri speciale ale lor în relaţiile între
obiecte), sau impuse prelucrărilor (ordinea lor, evenimente care le declanşează). O
regulă se exprimă prin cuvinte ca „... trebuie ...”, „... se va face... ”, „... respectă
strict...”.
 Preferinţe – sunt condiţii recomandate proprietăţilor obiectelor sau acţiunilor, care se
exprimă prin cuvinte ca „... se recomandă ...”, „... pe cât posibil... ”, „... este indicat
ca...”.
3.1.3.3 Corelarea cerinţelor
Cerinţele formulate nu sunt nici sentinţe nici cugetări disparate. Înţelegerea corectă a
cerinţelor impune combinarea lor în contextul comun al obiectivelor SI; din această
combinare rezultă noi legături (relaţii) între obiecte şi acţiuni dar pot rezulta chiar schimbări
de principiu în realizarea SI.
3.1.3.4 Stabilirea de priorităţi între cerinţe
Unele cerinţe sunt vitale funcţionării SI sau siguranţei mediului şi personalului, altele
sunt minore. Priorităţile stabilite între cerinţe se poate face pe o scară de valori după care să
fie tratate; în cazul în care unele cerinţe minore complică sistemul, se renunţă la ele sau se
prevăd pentru dezvoltări viitoare. Alegerea priorităţilor trebuie să ţină cont şi de găsirea
soluţiei optime, deci cerinţele care duc la un optim de funcţionare sau utilizare a SI nu sunt
minore.
3.1.3.5 Reprezentarea şi formalizarea obiectelor şi interacţiunilor
După ce s-au stabilit cu precizie obiective, cerinţe, obiecte şi interacţiuni este utilă o
reprezentare grafică a ansamblului acestora. O imagine este adesea intuitivă şi mult mai
explicită ca o descriere text a unui fapt sau unei situaţii.
În analiza sistemului informaţional ţintă se vor discrimina:
 fluxuri (de materiale, de energii, de informaţii), cum sunt: produse în stoc, facturi,
bonuri de livrare, etc.;
 entităţi ale lumii exterioare: clienţi, furnizori;
 structuri organizatorice;
 legi, reglementări: contracte, reguli contabile;
Reprezentarea grafică a părţilor şi întregului sistem ţintă ajută la înţelegerea şi la
corectarea modului de abordare a SI, dar operaţiunile care le va executa acesta pot fi transpuse
în programe numai dacă se cunosc cu precizie şi sunt formalizate
Datele cu care lucrează sistemul informaţional se constituie într-un model al datelor ce
formalizează structura şi legăturile dintre date (adică produce o structură conceptuală
exprimată prin simboluri). Formalizarea prelucrărilor produce un model al prelucrărilor (o
schemă de acţiune). Activitatea de formalizare face parte din analiza sistemului informaţional:
Exemple: date formalizabile - informaţii asupra unor clienţi; date neformalizabile - date
meteorologice, date imprecise sau incerte. Prelucrări formalizabile - editarea unei facturi,
calcule matematice; prelucrări neformalizabile - soluţii cu calcule în volum foarte mare sau
necunoscut.
3.1.3.6 Stabilirea metodologiei urmărite la realizarea SI
Analiza de sistem necesită o metodă generală de abordare pentru că apar probleme din
caracteristicile foarte variate ale informaţiilor (unele modele sunt adecvate, altele nu). Fiindcă
apar dificultăţi şi datorită persoanelor implicate în proiect (proiectanţi, analişti) trebuiesc
abordate şi din punct de vedere organizaţional conducerea şi implementarea proiectului cu o
metodă anume.
Exemple de situaţii care au apărut ca urmare a lipsei de metodă:
- programele nu realizează ce s-a dorit;
- programele nu pot fi modificate (dezvoltate) pentru noi cerinţe;
- studiile sunt corecte şi logice pe hârtie şi nu pot fi aplicate în practică;
- programele dau rezultate corecte dar în timp prea lung;
- informatizarea perturbă activitatea umană;
Întrebări la care se răspunde pentru a găsi o metodă:
1. cum se poate realiza un caiet de sarcini (specificaţii) care să descrie exact scopul
informatizării, ce metodă de analiză este adecvată?
2. Cum se poate realiza un sistem de programe conform caietului de sarcini? – ce metodă de
implementare se va folosi?
 De obicei, metoda după care se realizează analiza de sistem face parte din metodologia
generală adoptată pentru realizarea SI. De aceea, chiar în faza de analiză se fac mai multe
treceri prin etapele indicate mai sus, spre a rafina cunoştinţele şi a găsi cea mai bună cale de a
realiza cu succes Sistemul Informatic vizat.

3.2 Tehnici de reprezentare grafică a Sistemelor Informatice

După realizarea analizei sistemului ţintă este necesară o reprezentare grafică, intuitivă,
care are următoarele scopuri:
- o inventariere preliminară a acţiunilor şi datelor;
- o reprezentare a legăturilor dintre ele într-un mod vizibil şi inventiv;
- obţinerea unei viziuni de ansamblu asupra sistemului.

3.2.1 Diagrame globale (scheme bloc)

Schema bloc se bazează pe setul de simboluri din Figura 3-2, şi indică la nivel
conceptual, succesiunea de operaţiuni şi obiectele asupra cărora se acţionează.

Fişier Blo
Document c de
prelucrare Succesiune

Figura 3-2 Simboluri grafice pentru ilustrarea Sistemului Informatic ca schemă bloc.

În exemplul din Figura 3-3 se prezintă o aplicaţie de gestiune a stocurilor pentru o

magazie, pe baza Notelor de Intrare Recepţie (NIR), a Bunurilor de Consum (BC) şi a
Contractelor de Aprovizionare (CTA).

NIR Gestoc
Stocuri

Situaţia Stocurilor
BC Comandă

Procesare Comenzi

CTA Furnizori

Fişiere Furnizori

Figura 3-3 Modelul unui Sistemului Informatic de gestiune a stocurilor

3.2.2 Flux pe orizontală
Este o formă de prezentare în care se folosesc următoarele convenţii de reprezentare:
- fiecare document se găseşte pe o linie de nivel orizontală;
- fiecărui document i se trec cronologic toate operaţiile suportate din momentul intrării în SI
până în momentul arhivării sau distrugerii;
- se reprezintă schematic operaţiile şi influenţele unor documente asupra altora fiind
acordată atenţie eliminării unor documente şi eventual schimbării traseelor informaţiilor în
momentul utilizării SI.
Diagrama este de fapt un tabel ce conţine drept coloane: Nr. curent, Nume document,
Periodicitate de completare, Forma, Observaţii (lămuritoare la scopul şi utilitatea
documentului). În cadrul tabelului se trec documentele şi operaţiunile şi diagrama însoţitoare
dă imaginea de ansamblu a acestora. Simbolurile utilizate sunt ilustrate în Figura 3-4.
Diagramele întocmite ilustrează structurile de prelucrare specifice sistemului informatic
şi sunt utile în proiectarea bazelor de date şi a modulelor program (sau a interogărilor) ce
reprezintă de fapt prelucrările dorite.

Document Afişare
Factura (pe ecran
de intrare
sau hârtie)

Trnsfer Cod Punere în

Transport aşteptare

Manipulare Punere în
circulaţie

Arhivare Verificare

Figura 3-4 Simboluri în reprezentarea de fluxuri pe orizontală.

3.3 Modelul Conceptual al Datelor

Modelul conceptual al datelor (MCD) se referă la identificarea entităţilor tip şi
atributelor generice ale acestora ca şi concepte prin care se poate modela o zonă a realităţii
umane.
Urmare a acestui model, se poate constitui modelul logic al datelor (MLD) – util în faza
de proiectare a aplicaţiei apoi modelul fizic al datelor (MFD) – care reprezintă tabelele cu
structuraşi datele specifice aplicaţiei ce utilizează mediul SGBD.
Procesul de realizare a MCD se bazează pe strategia descendentă (top-down) şi are drept
scop descrierea conceptuală a datelor folosite în cadrul organizaţiei – fără a da atenţie
detaliilor de implementare, apoi descrierea conceptuală a prelucrărilor – în termeni generici
de tipul „achiziţie”, „plată”. Aceste descrieri conceptuale se vor detalia ca obiecte sau tabele,
respectiv ca funcţii cu restricţii şi cerinţe specifice de prelucrare.
În principal, modelul conceptual al datelor priveşte identificarea de:
 Entităţi (persoane, locuri, lucruri) cu care are de a face organizaţia;
 Atribute – ca informaţii specifice care caracterizează sau descriu entităţile;
  Relaţii – ca legături ce există între entităţi în realitate, şi care trebuie luate în
considerare în contextul scopului urmărit.
Spre exemplu, la o firmă vânzătoare de automobile, entităţi vor fi maşinile – cu
proprietăţi ca marcă, tip, culoare, facilităţi, apoi clienţii – cu caracteristici ca nume, prenume,
adresă, preferinţe; legătura dintre cele două entităţi o reprezintă chiar comanda/achiziţia de
către client a unui (sau mai multor) automobil(e).
În continuare se prezinta conceptele Entitate, atribut, relaţie şi restricţii

3.3.1 Entitate
Entitatea este un obiect concret sau un concept abstract din zona realităţii care se doreşte
modelată şi gestionată prin SI. Orice entitate este asociată unui tabel.
În principiu o entitate reprezintă o categorie de obiecte sau de documente din realitate,
însă în realizarea Sistemului Informatic, o entitate poate fi şi o interacţiune între două obiecte
concrete din realitate. Astfel, o firmă comercială operează cu entităţi cum sunt PRODUS şi
FIRMA – ca obiecte concrete din realitate dar şi cu entitatea FACTURA – care reprezintă de
fapt interacţiuni cu firme furnizor şi client, adică relaţia firmei în cauză cu aceste două
categorii de firme. După cum se constată din acest exemplu, entitatea reprezintă obiectul
generic şi de aceea se recomandă ca numele entităţii să indice numele obiectului la singular.
O entitate poate fi:
 independentă sau tare – dacă nu se bazează pe o altă entitate pentru a fi identificată
(referită);
 dependentă – în caz contrar.
O instanţiere a unei entităţi este un obiect concret din categoria pe care o reprezintă
entitatea, adică este o linie din tabelul asociat entităţii.
Aşa cum s-a arătat mai sus, există mai multe tipuri de entităţi:
 entităţi tip – care sunt utilizate să reprezinte efectiv categorii de obiecte din lumea
reală, cum sunt PRODUS, COMERCIANT;
 entităţi subtip – care provin din ierarhii de generalizare, cum sunt FURNIZOR şi
CLIENT, ca entităţi fii ale entităţii părinte COMERCIANT;
 entităţi asociative – care sunt utilizate la asocierea altor două sau mai multe entităţi,
cum este entitatea FACTURA;

3.3.2 Atribut
Un atribut indică o proprietate a unei entităţi (adică a categoriei de obiecte), ce indică o
caracteristică prin care obiectele din acea categorie se deosebesc unele de altele. De exemplu,
pentru entitatea produs atributul DENUMIRE indică produsul, atributul PRET indică costul
unitar, al unui anume produs, etc. Fiecare atribut ia o valoare anume, într-un domeniu de
valori bine specificat: DENUMIRE este un şir de caractere, PRET este un număr.
Atributele pot fi clasificate în două categorii:
 Atribut identificator (de referire), denumite şi cheie – prin care se identifică un obiect
din tabel; asemenea atribute sunt numele obiectelor, sau codurile de identificare:
numărul de legitimaţie pentru persoane, codul de produs, etc.
 Atribut descriptiv (de informaţie) – prin care se indică o proprietate a obiectului,
proprietate care se poate regăsi şi la alte obiecte din tabel.
Atributul cheie care identifică unic un obiect din tabel – cum este de exemplu un cod de
identificare produs, se numeşte cheie primară.
Atunci când într-un tabel apare un atribut cheie primară din alt tabel, ele este denumit
cheie externă sau cheie străină.
O cheie compusă este aceea formată din două sau mai multe atribute cheie – necesară în
cazul când celelalte atribute nu depind doar de una din chei. De exemplu, identificarea unei
facturi se poate face unic prin codul de COMERCIANT şi DATA emiterii facturii (deci prin
două atribute).
3.3.3 Relaţie
Sensul general al relaţiei, în contextul bazelor de date relaţionale, este acela de legătură
între obiecte:
 de acelaşi tip – care formează împreună o colecţie (ca tabel) şi indică o entitate,
 tipuri diferite – care interacţionează în contextul real ce se doreşte informatizat (ca
asociere).
În continuare, se va considera conceptul de relaţie în a doua accepţie, adică relaţia este
asocierea între entităţi. Concret, relaţia între două entităţi se realizează pe baza unui câmp
comun (un atribut ce apare în ambele tabele), de obicei un câmp cheie al unui tabel apare
drept cheie externă în celălalt tabel. De exemplu, în tabelul FACTURI apare codul de
COMERCIANT spre a indica sursa sau destinaţia facturii; acest cod împreună cu data facturii
vor reprezenta cheia unei facturi instanţiate (concrete). Relaţia se exprimă printr-un verb care
exprimă interacţiunea dintre cele două entităţi în realitate.
Relaţiile se clasifică după criterii de grad, conectivitate, cardinalitate, tip şi existenţă:
 Gradul unei relaţii este numărul de entităţi asociate în relaţie. O relaţie n-ară este o
relaţie generală de grad n; cazuri particulare sunt relaţii binare (2-are), ternare (3-
are), etc. Gradul cel mai uzual în relaţie este 2, relaţiile ternare sau n-are fiind
descompuse în relaţii binare succesive între entităţi. Există însă şi relaţii unare, adică
relaţii recursive aplicate doar unei singure entităţi; de exemplu, relaţia „este şef al”
peste entitatea ANGAJAT este aplicată unor angajaţi subordonaţi unui angajat –
şeful acestora.
 Conectivitatea unei relaţii caracterizează numărul de obiecte efective ale unei entităţi
care intră în relaţie cu un singur obiect al unei alte entităţi - luate ca referinţă.
Conectivitatea nu se caracterizează numeric ci calitativ, prin valori „unu” şi „mulţi”.
 Cardinalitatea unei relaţii este de fapt conectivitatea minimă şi maximă a unei relaţii,
adică numărul minim de obiecte şi numărul maxim de obiecte ce se intră în relaţie cu
un obiect ale entităţii referinţă.
O relaţie unu-la-unu (1:1) este aceea în care un obiect ale entităţii de referinţă este în
relaţie cu cel mult un obiect ale celeilalte entităţi. De exemplu, un ANGAJAT al unei firme
face parte dintr-un (singur) anume DEPARTAMENT.
O relaţie unu-la-mulţi (1:N) este aceea în care un obiect ale entităţii de referinţă este în
relaţie mai multe obiecte ale celeilalte entităţi. De exemplu, un DEPARTAMENT al unei
firme are ca salariat mai mult de un ANGAJAT.
O relaţie mulţi-la-mulţi (M:N) este o relaţie nespecifică, adică aceea în care un obiect
ale entităţii de referinţă este în relaţie nici unul, unul sau mai multe obiecte ale celeilalte
entităţi. De exemplu relaţia ANGAJAT „lucrează la” PROIECT: există angajaţi care nu sunt
implicaţi în proiecte (de exemplu portarul) iar un angajat poate lucra la unul sau mai multe
proiecte.
Pentru indicarea specifică a relaţiei se foloseşte exprimarea generală:
(Numar_minim : Numar_maxim)
de obiecte aflate în relaţie cu un obiect din entitatea referinţă, adică primul număr indică
minimul de obiecte iar al doilea maximul de obiecte din a doua entitate ce intră în acea relaţie.
În acest caz, relaţia (M:N) se va apare ca (0:N). În situaţia în care relaţia încă este de forma
(M:N), atunci tabelele trebuie despicate spre a obţine relaţii unu-la-mulţi (1:N).
 Direcţia relaţiei indică cine este sursa şi cine este destinaţia relaţiei, atunci când verbul
indică o entitate părinte şi o entitate fiu. Direcţia este determinată de conectivitatea
relaţiei: în relaţii unu-la-unu direcţia este dinspre entitatea independentă către cea
dependentă; dacă cele două entităţi sunt independente direcţia este arbitrară. În
relaţia unu-la-mulţi entitatea care intervine cu 1 este părinte; în relaţia mulţi-la-mulţi
direcţia este arbitrară.
 Tipul relaţiei: relaţie identificatoare – cea care indică o entitate fiu (dependentă), iar
non-identificatoare – cea între entităţi independente.
3.3.4 Restricţii ale unei relaţii
Restricţia de existenţă a relaţiei – indică dacă pentru un obiect din entitatea referinţă
există cel puţin un obiect din entitatea aflată în relaţie cu ea, mai precis indică dacă relaţia este
obligatori pentru toate obiectele celor două entităţi sau nu. Cardinalitatea minimă indică
„existenţa” prin valoare diferită de 0 ca obligativitate, iar prin 0 ca relaţie opţională (vezi
exemplul cu ANGAJAT şi PROIECT de mai sus).
Restricţiile de participare specifice unei relaţii pot fi determinate considerând o entitate
drept referinţă (în relaţia analizată) şi evaluând apoi numărul de obiecte ale celeilalte entităţi
ce intră în relaţie cu un obiect a entităţii de referinţă.
1. Restricţia de participare indică la obligativitatea relaţiei: dacă un obiect al entităţii de
referinţă este în relaţie cu cel puţin un obiect al celeilalte entităţi atunci participarea
este totală (linie dublă) şi cardinalitatea minimă diferită de 0. Altfel participarea este
parţială - linie simplă.
2. Cardinalitatea relaţiei indică numărul de obiecte instanţiate aflate în relaţia între cele
două entităţi: cardinalitatea minimă şi maximă corespunzătoare arată în ce măsură o
entitate (ca mulţime) este legată de cealaltă entitate.
Cardinalitatea rezultă din reguli de gestiune şi este utilă spre a evalua câte linii se vor
afişa la o interogare ce conţine relaţii între două tabele – relativ la liniile cu valori de atribute
care se repetă.

3.4 Realizarea MCD

Modelul conceptual al datelor (MCD) se referă la identificarea conceptuală a entităţilor
tip şi atributelor generice ale acestora prin care se poate modela o zonă a realităţii umane.
Acest model (uzual fiind entitate - relaţie) este necesar la constituirea modelului logic al
datelor (MLD) şi modelului fizic al datelor (MFD) adică la constituirea tabelelor şi ulterior la
încărcarea şi utilizarea lor printr-un mediu SGBD relaţional.

3.4.1 Dependenţe funcţionale ţi tranzitive

O dependenţă funcţională se referă la faptul atributele entităţilor depind unele de altele,
astfel cum depind în fapt în situaţia reală pe care o reprezintă baza de date. Trebuie reamintit,
din nou, că „relaţie” înseamnă atât tabel cât şi legătură între tabele – conform abordării
relaţionale a bazelor de date, tocmai pentru că acestea se pot generaliza prin termenul de
relaţie. Rezultă deci că într-o relaţie câmpurile sunt într-o dependenţă în care un câmp
(atribut) este determinant şi altul determinat v.
Figura 3-5.
De exemplu, câmpul Nume în tabelul Student este dependent de câmpul NrLeg
pentru că de fapt numărul de legitimaţie identifică un student în registrele de evidenţă ale
organizaţiei şi prin acesta se poate apoi obţine numele studentului; acesta este un exemplu de
dependenţă funcţională în cadrul aceluiaşi tabel. Un exemplu de dependenţă funcţională între
câmpuri ale două tabele diferite este următorul: Nota, obţinută de un student la o disciplină
anume, înscrisă în tabelul FişaStudent este dependentă de acea disciplină, deci de codul
ei înscris în tabelul Disciplina.
R

A. Atribut (câmp) B. Atribut (câmp)

Determinant Determinat
(cheie) (dependent)

Figura 3-5 Câmpuri în dependenţă funcţională.

 Dependenţa funcţională poate fi definită în general astfel: atributul B în relaţia R este
dependent funcţional de atributul A al relaţiei R dacă pentru orice situaţie concretă (instanţă)
în care atributele A şi B apar în tabelele din baza de date valoarea lui A indică una şi numai
valoare a lui B (v. şi
Figura 3-5).
Cheia primară se poate defini în termeni de dependenţă funcţională: o cheie primară
este unul (sau mai multe) atribut(e) cu proprietăţile 1) toate atributele care nu sunt parte a
cheii sunt dependente funcţional de atributul cheie, 2) dacă cheia primară este compusă din
mai multe atribute nici un subset al acesteia nu are proprietate 1).
Prin conceptul de dependenţa funcţională se pot caracteriza asocieri sau relaţii între
atribute, aşa cum se prezintă în Figura 3-6. Relaţiile între entităţi pot fi acum înţelese mai
bine prin prisma dependenţelor funcţionale: de fapt două entităţi sunt în relaţie pentru că
atributul cheie al unei entităţi este în relaţie cu atribute (eventual cheie) ale celeilalte entităţi.

1:1 Asocierea 1:1 indică o dependenţă

A B funcţională în care doar o instanţă B
depinde de una A
1:N Asocierea 1:N indică o dependenţă
A B funcţională în care mai multe instanţe B
depind de una A
0:1 Asocierea 0:1 indică o dependenţă
A B funcţională în care există instanţe B care
nu depind de A

Figura 3-6 Asocieri de atribute exprimate ca dependenţe funcţionale.

Dependenţele funcţionale se identifică iniţial între atribute şi stabilesc modul în care
aceste atribute se vor structura pe entităţi. Există un set de reguli prin care plasarea atributelor
la entităţi să permită realizarea unei baze de date consistente (fără confuzii şi fără eventuale
asocieri eronate).
Între atribute ale relaţiilor pot apare însă şi aşa-numite dependenţe tranzitive, care
trebuie cunoscute şi specificate ca atare. O dependenţă tranzitivă apare atunci când un atribut
non-cheie este dependent de un al atribut non-cheie, ultimul fiind însă dependent de cheia
primară.

3.4.2 Reguli de structurare a MCD

În realizarea MCD se respectă următoarele reguli:
- Regula de unicitate a numelor aplicabilă oricărei categorii de obiecte (entitate tip, atribut,
relaţie) – prin care un nume o dată folosit nu se mai repetă.
- Regula unicităţii atributelor (neredundanţei) – un atribut nu trebuie să se găsească în 2
entităţi. Această regulă se va respecta aplicând matricea dependenţelor funcţionale .
- Regula de unicitate a relaţiilor – pentru fiecare asociere nu poate să existe decât o singură
realizare a fiecărei entităţi în acea relaţie. Ca urmare, se elimină relaţiile M:N şi, de obicei,
se înlocuiesc cu relaţii 1:N.
- Regula proprietăţilor şi determinantului unei proprietăţi: dacă un atribut depinde de mai
mulţi determinanţi (aceştia reprezentând identificatori ai mai multor entităţi) atunci el ar
trebui să definească tipul de relaţie între aceste entităţi.
- Atribute derivabile sunt acele atribute obţinute prin calcul din alte atribute (existente în
entităţi, tabel) şi ca atare atributul nu trebuie să constituie un câmp din structura tabelului
ci un câmp adăugat, calculat (rezultat al unei interogări cu agregare pe orizontală).
- Atribute decompozabile - anumite atribute (ex. Nume = Nume & Prenume & Iniţiala
tatălui sau Adresa = Strada & Bloc & Localitate) nu trebuie păstrate în forma lor uzuală ci
trebuie divizate în mai multe atribute independente.

3.5 Limbajul Unificat de Modelare (UML)

Până în anii 1990, se considera că activitatea de analiză şi proiectare este specifică
tipului de aplicaţie vizat – de exemplu aplicaţie de rezolvare a unei probleme economice
(realizată cu baze de date) sau aplicaţie de rezolvare a unei probleme de automatizare
(realizate cu programe în limbaj de nivel mediu sau jos). După apariţia programării orientate
obiect (OOP) s-au dezvoltate metode de analiză specifice acestei abordări, cum sunt
- OMT (Object Modeling Technique) – iniţiată de James Rumbaugh,
- OOD (Object Oriented Design) – iniţiată de Greedy Booch,
- OOSE (Object-Oriented Software Engineering) – iniţiată de Ivar Jacobson.
În deceniul 1990, s-a constatat că metodele de analiză şi proiectare orientate obiect au
un grad de generalitate foarte mare şi pot fi folosite în diverse domenii şi în abordări care nu
erau orientate obiect. Mai mult cele trei metode amintite aveau diferenţe de nuanţă sau se
completau în multe privinţe, dar lumea era divizată între cele trei metode de abordare. Această
situaţie de conflict a fost rezolvată după 1997, când se înfiinţează consorţiul OMG (Object
Management Group) cu obiectiv principal promovarea abordării orientate obiect în cadrul
ingineriei software într-o abordare unificată.
Limbajul UML a apărut prin reunirea celor trei autori de metode amintite mai sus şi
stabilirea unei abordări comune, care să preia părţi bune din toate abordările. Astfel UML
(Unified Modelling Langoage).a devenit nu doar un limbaj unificat dar şi universal, util în
descrierea situaţiilor reale din orice domeniu.

Limbajul UML constă din setul de concepte şi notaţii privind structura şi funcţionarea
unui sistem din lumea reală, spre a fi modelat şi reprezentat grafic în mod intuitiv şi lucrativ –
adică uşor de înţeles şi de transpus într-un sistem informatic. Descrierea sistemului din lumea
reală se face printr-o serie de diagrame care se referă la:
- activităţi,
- cazuri de utilizare,
- clase,
- colaborare,
- componente,
- exploatare,
- obiecte,
- secvenţă,
- stări.
Aceste diagrame pot fi împărţite în 3 categorii: diagrame statice – care descriu structura
şi responsabilităţile sistemului informatic (diagramele de cazuri de utilizare, clase, obiecte),
diagrame dinamice – care descriu comportamentul şi interacţiunile care au loc între diverse
entităţi în cadrul sistemului informatic (diagrame de activităţi, colaborare, secvenţă, stări,
cazuri de utilizare) şi diagrame arhitecturale – care descriu componentele executabile ale
sistemului şi determină locaţiile fizice de execuţie şi nodurile de stocare a datelor (diagrame
de componente, de exploatare).

3.5.1 Noţiuni şi notaţii pentru entităţi

Vocabularul UML conţine noţiuni care referă obiecte şi relaţii între acestea, pe care le
reprezintă grafic şi le combină în diagrame corespunzătoare structurilor sau acţiunilor vizate.
Cele trei noţiuni importante, în contextul realizării aplicaţiilor cu baze de date, sunt (termeni
sunt daţi întâi în engleză pentru a fi recunoscuţi uşor în literatura în domeniu):
a. Things – entităţi sau repere
 b. Relationships – relaţii
c. Diagrams – diagrame
Entităţile sunt, evident, noţiunile cele mai importante în abordarea noastră, şi de aceea
se vor prezenta scurt câteva categorii şi apoi reprezentarea grafică în Figura 3-7:
i) Structurale (structural things)
ii) Comportamentale (behavioral things)
iii) De grupare (grouping things)
iv) De adnotare (annotational things).

Entităţi structurale sunt cele care pot asimilate cu obiecte din lumea reală şi corespund
entităţilor din abordarea „clasică” a DER. Totuşi, o diferenţă esenţială este aceea că entitatea
în accepţia UML este o clasă – aşa cum este ea înţeleasă în abordarea obiectuală. Astfel,
entitatea / clasa va fi descrisă nu doar prin structurile de date (valori) proprii – denumite
atribute, ci şi prin acţiunile pe care ea le poate efectua (prelucrări) – denumite metode.

Clasă (class)

Ispelling Nume clasă (Ex: Fereastra)

Atribute (Ex:
origin
size)
Operaţii sau Metode (Ex:
open()
close()
move()
display()
rface) – reprezintă descrierea completă a comportării vizibile extern a unei clase sau component (ataşată de acea clasă sau d

Figura 3-7 Reprezentarea UML a clasei (entitate structurală).

În Figura 3-1 se prezintă succint noţiunile şi reprezentarea UML a clasei, pe un exemplu

foarte la îndemână oricărei persoane ce lucrează cu calculatorul: fereastra (window) uzuală
afişată pe ecran, în care se prezintă informaţii specifice unei aplicaţii actuale.

3.5.2 Noţiuni şi notaţii pentru relaţii

Notaţiile pentru relaţii între entităţi sunt specifice categoriei relaţiei, aşa cum se prezintă
în continuare şi se reprezintă grafic în Figura 318:

 Dependenţă (dependency) – unul depinde de altul semantic;

 Asociere (association) – conexiune între obiecte: agregare (romb simplu - open),
compoziţie (romb umplut), cu multiplicitate (câte obiecte de un fel – cel apropiat, pot fi
legate de unul de felul celălalt);
 Generalizare / specializare sau moştenire (tată - fiu) – săgeată deschisă
  Realizare – relaţii între clasificatori: când un clasificator specifică un contract către altul
care garantează acesta.

Dependenţă 0..1 Asociere simplă

0..1 Agregare * Compoziţie

Generalizare Realizare

Figura 3-8 Reprezentarea UML a relaţiilor între entităţi.

Cardinalităţile de participare în relaţie a entităţilor (în UML denumite multiplicităţi) se
reprezintă oarecum similar cu cele din DER, cu următoarele deosebirile (vezi Figura 3-8):
separatorul dintre cardinalitatea minimă şi maximă este ‘..’ şi nu ‘:’, iar multiplul N („mulţi”)
este reprezentat prin ‘*’. Se face observaţia că relaţia „mulţi la mulţi” (N:M) se reprezintă
simplu ca un singur asterics ‘*’.

3.5.3 Un exemplu de MCD ilustrat prin diagrama UML

Urmare a aplicării regulilor MCD şi folosind simbolistica UML se obţine o diagramă ca
în Figura 3-9 pentru exemplul evidenţei situaţiei studenţilor într-o universitate.

* 1..1
«deţine»
Student FisaStudent Disciplina
*
NrLeg Nume Prenume Localitate * Cod
Cod 1..1
NrLeg «referă» Nume
* NotaEx Marca
NotaLab NrOreCurs
*
0..*
«sef de grupa» «se informează de la»
«predă»

*
*
Angajat
PersTESA Profesor
1..1 1..1 Functia Adresa Vechime
Marca
Marca Meseria Postul LocMunca
«este un» 1..1 1..1 Marca
«este un» Nume
Prenume
Titlu

Figura 3-9 Diagrama de clase UML pentru evidenţa activităţii într-o universitate.

S-a introdus o entitate FişaStudent, care este în relaţii cu entităţile Student şi Disciplina.
Noua entitate a fost necesară pentru a se elimina relaţia directă cu cardinalităţi N:M dintre
entităţile Student şi Disciplina. Se poate emite o regulă generală de „spargere” a relaţiilor
N:M făcând observaţia că asemenea relaţii „produc date”, deci reprezintă de fapt interacţiuni
cu anume rezultate între entităţile relaţionate. Astfel, interacţiunea Student-Disciplina produce
notele obţinute de student la disciplinele urmate, note care trebuie „salvate” într-un tabel
pentru că nu sunt câmpuri calculate (atribute derivate) ci sunt date primare. Relaţia „urmează”
s-a transformat în entitatea FişaStudent şi în două relaţii noi; se observă că această nouă
entitate are un câmp cheie compus, format din cheile externe NrLeg (cheie în tabel Student) şi
Cod (cheie în tabel Disciplina).
Entităţile vor fi reprezentate în baza de date relaţionale ca tabele, însă aceste tabele au o
structură „plată” („flat tables”), în sensul că toate atributele se înşiruie drept coloane
independente (fără subcoloane) şi în ordine aleatoare (ordinea nu trebuie să fie importantă).
În Figura 3-9 se prezintă o diagramă de clase UML adecvată exemplului de evidenţă a
situaţiei şcolare a studenţilor, care a fost completată cu elemente ce ţin şi de structurile interne
de personal ale universităţii. Analiza şi înţelegerea diagramei este un exerciţiu util şi uşor.

4 Proiectarea Bazei de Date relaţionale

Obiectivele unui proiectări de calitate a bazei de date relaţionale se referă la
corectitudinea sa şi la construirea eficientă (cu consum minim de timp şi resurse). Aceste
obiective sunt:
 Baza de date să ofere informaţii conform cerinţelor deja definite ale beneficiarului dar
şi informaţii ad-hoc (care sunt cerute pe loc chiar după darea în exploatare a
aplicaţiei).
 Tabelele să fie construite corect şi eficient, fiecare reprezentând o singură categorie de
obiecte, să fie compuse fiecare din câmpuri distincte (ne-repetate) iar datele în tabele
să nu fie redundante (acelaşi coloane să u se repete în două sau mai multe tabele);
fiecare obiect dintr-un tabel să fie identificat unic prin intermediul unei valori dintr-
unul sau mai multe câmpuri (cheie primară).
 Baza de date să asigure integritatea datelor la nivel de câmp, tabel şi relaţie. Aceste
nivele de integritate garantează că structurile de date şi valorile lor vor fi corecte şi
precise în oricare din situaţiile de utilizare a bazei de date şi a aplicaţiei.
 Baza de date să satisfacă regulile de gestiune relevante ale organizaţiei. Regulile de
gestiune sunt de fapt restricţii uzuale asupra datelor şi asupra utilizării lor, impuse de
însuşi domeniul în care se aplică baza de date sau de uzanţe ale organizaţiei.
 Baza de date să permită dezvoltarea ulterioară, adică să permită creşterea volumului de
informaţie şi de prelucrare pe măsură ce activitatea organizaţiei se extinde.
Beneficiile unei proiectări de calitate sunt:
 Structura bazei de date se poate modifica şi întreţine uşor; modificări asupra unui
câmp nu necesită (nu provoacă) modificări asupra altor câmpuri sau tabele.
 Datele se modifică uşor, iar valorile noi nu produc efecte nedorite în baza de date.
Modificarea unui valori se face o singură dată, şi nu în mai multe locuri (tabele).
 Informaţia se regăseşte uşor iar interogarea bazei de date se face uşor pentru că
tabelele sunt construite bine şi relaţiile între tabele sunt corecte.
 Aplicaţiile pentru utilizator se construiesc uşor, pentru că apar puţine probleme de
manipulare a datelor atunci când ele sunt bine structurate în tabele cu relaţii între ele.
Proiectarea bazei de date urmărind o metodologie corectă conduce la dezvoltarea aplicaţiilor
de baze de date cu costuri reduse şi permite o utilizare comodă şi eficientă a bazei
de date.

4.1 Reguli de Gestiune

Producere, transferul şi manipularea datelor în cadrul unei organizaţii sunt supuse
anumitor reguli, cerinţe şi restricţii care trebuie respectare şi în cadrul modelului conceptual al
datelor. Proiectarea bazei de date va fi condiţionată de aceste reguli privind tipurile şi
domeniile de valori admise pentru atribute, privind gradul de participare a entităţilor în relaţii,
dar şi privind integritatea datelor în baza de date (v. §4.2). De exemplu, în cazul evidenţei
situaţiei studenţilor, într-un an de studii se poate face înscrierea unui student la mai multe
discipline facultative dar numai la o singură disciplină opţională. O altă regulă poate fi aceea
că un student absolvă anul de studii doar dacă examenele susţinute şi absolvite însumează
numărul de credite impus.
O regulă de gestiune (business rule) este o propoziţie ce exprimă o restricţie impusă
bazei de date, impunând condiţii în specificarea atributelor şi relaţiilor entităţilor. Regula de
gestiune provine din modul cum sunt privite informaţiile de către organizaţie, prin prisma
aspectelor legale, a aspectelor de fezabilitate (adică de conformitate cu realitatea) şi de
eficienţă a prelucrărilor.
Orice activitate prezintă reguli specifice atât asupra naturii şi condiţiilor impuse
informaţiilor, datorate precedenţelor de timp (de exemplu data emiterii unei facturi trebuie să
fie ulterioară celei a comenzii), datorate legilor în vigoare sau uzanţelor din domeniu, datorate
unor utilizării aceloraşi informaţii în mai multe domenii sau mai multe aplicaţii.

4.1.1 Tipuri de reguli de gestiune

O primă clasificare a regulilor de gestiune se face după elementul afectat:
 reguli specifice atributelor – care impun restricţii asupra tipului de date şi formatului
în care se vor înscrie valorile în câmpul din tabel; de exemplu, data calendaristică se
scrie cu specificarea în clar a lunii (10 Aprilie 2005), sau numele de familie a clientului
se înscrie cu majuscule.
 Reguli specifice relaţiilor – care impun restricţii asupra legăturilor între entităţi; de
exemplu, în legătura dintre entitatea Student şi entitatea Grupa apare regula: ”O grupă
are cel puţin 25 de studenţi dar nu mai mult de 30”.
O altă clasificare a regulilor de gestiune se poate face prin prisma orientării în SI:
 reguli orientate spre baza de date – care afectează proiectarea logică a SI prin
constrângeri legate de modificarea caracteristicilor sau relaţiilor entităţilor; de
exemplu, se admit clienţi cumpărători de automobile doar persoane cu cetăţenie
română şi cu domiciliul în România (ca urmare se limitează valorile posibile la
„proprietăţile” cetăţenie şi adresă).
 reguli orientate spre aplicaţie – care afectează proiectarea fizică a aplicaţiei; de
exemplu, pentru clienţi „fideli” se face automat o reducere de 10%, care afectează
valoarea produsului cumpărat dar noua valoare nu poate fi inclusă în proiectarea logică
pentru că ea se obţine în urma unui calcul.

4.1.2 Definirea şi stabilirea regulilor de gestiune

Pentru a obţine un set coerent şi complet de reguli de gestiune trebuie să se cunoască
atât modul de lucru comun cu datele al utilizatorilor din domeniu cât şi viziunea managerului
asupra acestor date. Multe din regulile de gestiune provin din experienţa de lucru a
persoanelor amintite dar pot să provină şi din experienţa analistului de sistem sau chiar a
analistului-programator implicata în acel domeniu.
Definirea regulii de gestiune constă în exprimarea concisă şi clară a condiţiei care
trebuie respectată în proiectarea sau utilizarea bazei de date, iar stabilirea regulii se face
printr-un proces de intervievare a utilizatorilor şi managerilor, pentru a indica în ce context şi
la ce moment se aplică o regulă sau alta, ce avantaje şi ce dezavantaje prezintă.
Se recomandă ca întâi să se definească şi stabilească reguli de gestiune pentru câmpuri
apoi pentru relaţii, pentru a nu se face salturi şi reveniri înainte şi înapoi la diferite tipuri de
reguli de gestiune în procesul de stabilire a lor şi a nu provoca confuzii. O cale sistematică de
definire şi stabilire a regulilor de gestiune este prezentată mai jos, ca paşi de urmat de către
analistul de sistem în faza de proiectare a bazei de date.
1. Se selectează un tabel. Fiecare tabel trebuie analizat în parte (nu contează ordinea în care
se parcurg), la fiecare analizând subiectul tabelului prin următoarele întrebări: (a) Cum
foloseşte organizaţia informaţia legată de subiect? (b) Ce relaţii există între tabelul curent
 şi celelalte tabele? Aceste întrebări ajută la clarificarea imaginii asupra subiectului
tabelului şi la pregătirea pentru paşii următori.
2. Se revizuieşte fiecare câmp şi se determină dacă necesită restricţii. Pentru fiecare câmp
se specifică tipul de dată, domeniul de valori, constrângerile ce decurg din întrebările (a)
şi (b) de la pasul 1 pentru acest câmp, la culegerea, reprezentarea stocarea şi verificarea
datelor.
3. Se definesc regulile de gestiune necesare pentru câmpul curent. Se formulează scurt şi
complet fiecare regulă de gestiune care corespunde unei anume restricţii impuse
câmpului ca proprietate a entităţii sau valori pe care le poate lua.
4. Se stabilesc ce alte elemente se modifică prin regula definită. Fiindcă o restricţiile
impuse unui câmp pot condiţiona şi alte câmpuri (din acelaşi tabel sau din alte tabele) se
identifică elementele afectate şi cum; uzual, se afectează valorile elementelor, spre
exemplu:„nu permit lipsă valoare (vid sau Null, de ex. pentru Nr. Legitimaţie student)”,
„nu permit modificare” (decât cu autorizare), „valoarea se regăseşte identic în alt tabel”
(de ex. Nr. Legitimaţie din tabelul FişaStudent se regăseşte în tabelul Student).
5. Se determină acţiunile prin care regula poate fi încălcată. Restricţia impusă de regulă se
testează pentru fiecare din acţiunile: inserare a unei noi linii (articol) sau unui nou câmp,
ştergerea unui articol sau a unei valori de câmp, modificarea o valoare de câmp. După ce
s-a determinat care din acţiuni va încălca regula se va nota situaţia spre a se folosi în
pasul următor.
6. Se înscrie regula în Lista de Reguli de Gestiune. Înscrierea regulilor de gestiune se face
indicând: (i) Propoziţia - ca text scurt şi complet, (ii) restricţia – ca explicaţie scurtă a
modului cum se aplică constrângerea la tabel(e) şi câmp(uri) locale şi vecine, (iii) Tipul –
indică orientarea restricţiei spre baza de date sau spre aplicaţie, (iv) Categoria – se referă
la câmp sau relaţie, (v) Test – indică ce acţiuni (inserare, ştergere, modificare) vor testa
restricţia impusă, (vi) Structuri afectate – numele tabelelor sau relaţiilor afectate, (vii)
Elemente de câmp afectate în propriul tabel sau alte tabele, (viii) Caracteristici ale
relaţiilor afectate, (ix) Măsuri luate – ca modificări ale câmpurilor sau relaţiilor în DER
efectuate pentru a asigura respectarea regulii (de exemplu „enforce referential integrity”
în SGBD – Access).
Documentarea corectă şi completă a regulilor de gestiune este esenţială pentru
proiectarea eficientă a bazei e date, asigurând o metodă standard de înregistrare a lor, de
revizuire (depanare) şi de aplicare la proiectarea bazei de date. Este indicat să se revadă Lista
cu Reguli de Gestiune după crearea acesteia, pentru că fiecare regulă contribuie la integritatea
datelor şi impun constrângeri specifice organizaţiei; dacă este necesar se adaugă noi reguli de
gestiune sau altele se înlătură –fiindcă nu aduc rezultatele scontate sau chiar încurcă aplicaţia
(caz analizat foarte atent).

4.1.3 Exemple de Reguli de Gestiune

Mai jos se dau două exemple de reguli de gestiune pentru cazul evidenţei situaţiei
şcolare a studenţilor (v. diagrama UML din Figura 3-9):
1. O disciplină poate fi urmată de studenţi doar dacă există numărul (minim) de studenţi
ce poate alcătui o grupă (adică 25 studenţi). Regula se aplică explicit la cursuri
facultative (adică acestea nu se pot organiza fără un număr de minim de 25 studenţi în
audienţă), dar se aplică implicit la cursurile obligatorii (adică este evident că disciplina
se predă la cel puţin o grupă). În virtutea acestei reguli, în relaţia între tabelele
Student şi Disciplina apar cardinalităţile: N:M care indică faptul că „un student
urmează cel puţin N discipline (cele obligatorii) şi maxim M discipline (M>N, adică în
plus şi cele facultative)”, respectiv N:M „o disciplină este urmată de cel puţin N
studenţi (o grupă – cel puţin 25)” şi de maxim M studenţi (din multe alte grupe)”.
2. Unele discipline facultative sunt predate de profesori invitaţi. Această regulă indică
faptul că un profesor este titular al uneia sau mai multor discipline, dar există discipline
care să nu fie alocate unui anume profesor (de ex. unele discipline facultative); pentru
 acestea se aduc profesori invitaţi din afara universităţii – din alte universităţi sau din
mediul de afaceri. În virtutea acestei reguli, în relaţia între tabelele Disciplina şi
Profesor apar cardinalităţile: 0:N care indică faptul că: „o disciplină poate să nu fie
predată de nici un profesor (dacă este facultativă şi titularul nu este din universitate) şi
poate fi predată de maxim N profesori (la diferite secţii)”, respectiv 1:N „un profesor
predă cel puţin o disciplină dar poate preda şi mai multe”.

4.2 Niveluri de integritate ale bazei de date

Integritatea datelor în baza de date este un termen generic care se referă la consistenţa,
precizia şi corectitudinea informaţiilor stocate în baza de date. Integritatea datelor nu se referă
la siguranţa fizică, la toleranţa la erori sau la salvarea corectă informaţiei (backups) ci priveşte
modul cum sunt stocate şi manipulate datele în tabele aşa încât să nu apară situaţii anormale
(de exemplu lipsa de corespondenţă a liniilor din două tabele aflate în relaţie).
Există patru tipuri de integritate a informaţiei:
1. Integritate a entităţii – aplicată la nivel de articol (linie) în tabel;
2. Integritate a domeniului – aplicată la nivel de câmp (coloană) în tabel;
3. Integritate referenţială – aplicată la nivel de tabele aflate în relaţie;
4. Integritate definită de utilizator – aplicată la nivel reguli de gestiune asupra datelor din
tabele;
Integritatea informaţiei presupune o proiectare corectă şi apoi mecanisme de verificare a
(respectării) integrităţii ce pot fi implementate în chiar SGBD (ca produs de baze de date
relaţionale) în server-ul de baze de date, sau în aplicaţia de baze de date externă acesteia (ca
de exemplu în cazul accesului prin Internet la o bază de date unde integritatea este
implementată prin programe de acces la formularul transmis la utilizator). În cazul unui
Server SQL, acesta permite ca regulile de integritate a informaţiilor să fie definite central în
baza de date, deci independente de aplicaţiile care folosesc această bază de date
Când integritatea informaţiilor este implementată direct în SGBD sau în serverul de
baze de date, proiectantul aplicaţiei nu trebuie să se mai preocupe de asigurarea integrităţii ci
cel mult va trebui să activeze mecanismele care verifică şi forţează respectarea integrităţii
informaţiilor.
Probleme care pot apare atunci când se încearcă implementarea integrităţii informaţiilor
în aplicaţie (deci codarea lor în program) sunt: 1) efort de programare suplimentar, 2)
inconsistenţa programului şi potenţiale erori în acesta, 3) dificultăţi la modificarea
programului, 4) o securitate mai slabă a aplicaţiei – fiindcă mecanismele de verificare a
integrităţii ar putea fie ocolite.

4.2.1 Integritatea entităţii

Integritatea entităţii asigură ca fiecare obiect instanţiat din tabel să fie identificat unic,
adică un obiect din lumea reală să apară pe o singură linie deci să nu apară în duplicat. De
exemplu, doi studenţi în tabelul Student să poată fi unic indentificaţi prin intermediul
numărului de legitimaţie (NrLeg).
Atât SGBD cât şi un Server SQL nu permit duplicarea obiectelor (liniilor) dacă este
activată (forţată) integritatea entităţii. În acest fel nu este importantă ordinea în care sunt
memorate datele în tabel – deci ordinea liniilor, de fapt a obiectelor înscrise, poate fi oricare.
Este evident că aceasta oferă un mare avantaj la utilizarea unui tabel în baza de date fiindcă
culegerea datelor despre obiectele din tabel se poate face la întâmplare (de exemplu studenţii
pot fi înscrişi în tabel în orice ordine – aşa cum s-au prezentat ei la secretariatul facultăţii, nu
în ordine alfabetică).
Independenţa de modul fizic de stocare a datelor este obţinută prin aceea că fiecare
obiect (linie) în tabel poate fi adresat (referit) printr-o valoare unică denumită “cheie” (cheie
primară), care nu permite două valori identice în tabel (de exemplu doi studenţi cu acelaşi
număr de legitimaţie, chiar dacă sunt fraţi gemeni şi se numesc la fel ...) şi nici lipsa valorii
(valoare vidă).
Un tabel poate conţine doar o singură cheie primară, chiar dacă aceasta este un singur
câmp (de exemplu numărul de legitimaţie în tabel Student) sau este formată din două
câmpuri (de exemplu numărul de legitimaţie şi codul disciplinei la care a susţinut examen în
tabel FişaStudent); în acest ultim caz, numărul de legitimaţie şi codul disciplinei
reprezintă chei primare în tabelele de unde provin (Student, respectiv Disciplina) sar e
numesc chei externe (sau străine) în tabelul FişaStudent.

4.2.2 Integritatea domeniului

Integritatea domeniului cere valorile unui câmp (unei coloane) din tabel să aibă doar un
set de valori anume pentru a fi valid. Cu alte cuvinte, integritatea domeniului, defineşte ce
valori sunt permise a fi introduse într-o coloană dată, restricţionând tipul de dată, formatul sau
domeniul posibil de valori. Integritatea domeniului mai este cunoscută şi ca integritate a
atributului, iar verificare sa este „forţată” prin intermediul SGBD sau serverului de baze de
date.
De exemplu, integritatea domeniului pentru coloana Vârsta studentului în tabel
Student permite doar valori în domeniul 16-120 ani (pentru tineri supradotaţi, respectiv
pentru pensionari longevivi); un Matusalem nu s-ar putea înscrie chiar dacă la vârsta de 600
ani este capabil a învăţa.
Verificare integrităţii domeniului poate fi forţată prin constrângere de valoare implicită
(DEFAULT) – prin se care automat pune o valoare în coloană (de ex. 19 în coloana Vârsta –
considerând şcoala începută la 6 ani şi urmată 12 clase), sau poate fi forţată prin constrângeri
de cheie străină (FOREIGN KEY) sau de verificare (CHECK) – prin care se folosesc domenii
de valori din alte tabele, de unde provin de fapt mărimile.

4.2.3 Integritatea referenţială

Integritatea referenţială asigură sincronizarea tabelelor aflate în relaţie. Forţarea
integrităţii referenţiale asigură menţinerea aceloraşi valori în coloanele comune a două tabele
aflate în relaţie. De exemplu, SGBD nu va permite să se înscrie în tabelul FişaStudent un
număr de legitimaţie care nu se va regăsi şi în Student (fiindcă are fi o eroare – nu este un
student real). Dacă nu a fi asigurată integritatea referenţială nu s-ar putea obţine răspunsuri
consistente (cu înţeles) atunci când se va dori, de exemplu, afişarea situaţiei notelor obţinute
de studenţi cu numele şi prenumele lor.
4.2.3.1 Tabel „părinte” şi tabel „fiu”
După cum se constată şi din exemplul de mai sus, integritatea referenţială se referă la
cazuri când apare o combinaţie de chei străine sau cheie primară şi o cheie străină. Se
consideră că o cheie străină este o coloană sau combinaţie de coloane într-un tabel derivat
(denumit “fiu”) care ia valorile dintr-o cheie primară a unui alt tabel (denumit “părinte”).
Înregistrările care din tabelul „fiu” (de exemplu FişaStudent) care nu au corespondent în
tabelul „părinte” (de exemplu Student) se numesc „orfane”; deci integritatea referenţială
împiedică apariţia de înregistrări orfane la interogări care folosesc cele două tabele în relaţie.
Pentru ca integritatea referenţială să fie menţinută, cheia străină din tabelul “fiu” poate
accepta doar valori care există în cheia primară a tabelului “părinte”
Există trei moduri de abordare pentru a implementa integritatea referenţială: 1)
restricţionare – a dreptului de modificare a informaţiei în tabele fiu sau părinte; 2) cascadare –
extindere a activităţii de modificare a informaţiei la tabelul „înrudit” (părinte sau fiu); 3)
anulare – punerea pe valoare vidă (NULL) a valorilor cheii străine în tabelul fiu.
4.2.3.2 Cazuri de încălcare a integrităţii referenţiale
Actualizarea (UPDATE) valorilor în câmpuri cheie poate produce “orfani”, adică atunci
când se modifică fie cheia primară a tabelului părinte fie cheia străină a tabelului fiu (vezi
exemplul de mai sus cu tabele Student şi FişaStudent). Pentru a menţine integritatea
referenţială, actualizarea ce poate cauza erori este blocată (nu este permisă) de către SGBD.
Această situaţie apare atunci când o cheie străină face referire la o cheie primară. Ca
alternativă, actualizarea poate fi cascadată de la “părinte” la “fiu” (adică modificarea este
continuată automat la tabelul fiu dacă s-a modificat cheia primară la părinte).
Ştergerea (DELETE) de linii din tabele aflate în relaţie părinte-fiu poate ataca
integritatea referenţială. Dacă se şterge un „student” (linia sa) în tabel Student, atunci în
tabelul FişaStudent vor rămâne linii orfane. Menţinerea integrităţii referenţiale se face
prin blocarea ştergerii sau prin cascadare.
Inserarea (INSERT) de noi valori de în câmpul cheie poate, de asemenea, ataca
integritatea referenţială. De exemplu articole (linii) noi inserate în tabelul părinte produce
articole (linii) orfane în tabelul fiu. Menţinerea integrităţii referenţiale se face prin blocarea
inserării când în tabelul fiu se introduce o nouă linie (aceasta nu este permisă); se remarcă
faptul că la inserare nu se poate menţine integritatea referenţială prin cascadare (aşa ca la
actualizare sau ştergere).

4.2.4 Integritatea definită de utilizator

Integritatea definită de utilizator se referă la regulile de gestiune specifice domeniului
rezolvat, care nu sunt acoperite de alte categorii de integritate amintite. Implementarea acestui
tip de integritate se face uzual prin activarea unor proceduri predefinite, create specific regulii
de gestiune care se doreşte rezolvată.
În acest context se amintesc modalităţi de implementare a asigurării integrităţii
informaţiei, care se aplică şi celorlalte categorii de integritate:
 Integritatea Declarativă – se obţine prin declararea unei constrângeri asupra unei
anumite coloane dintr-un tabel; constrângerea constă într-o restricţia asupra valorilor
din acea coloană şi/sau din mai multe coloane cu date înrudinte (vezi exemple mai sus).
Acest tip de asigurare a integrităţii intră în funcţie automat la cele trei: entitate,
domeniu şi referinţială, la care provoacă de fapt o blocare a acţiunii care încalcă
integritatea datelor.
 Integritatea Procedurală – forţează controlul integrităţii prin proceduri de vizualizare
sau activare şi se aplică doar la integrităţi: de domeniului şi referenţială. Acest tip de
asigurare a integrităţii este mai complexă, şi necesită efort de programare pentru că
presupune o intervenţie cu consultarea eventuală a utilizatorului.

4.3 Normalizarea Bazei de Date

O bază de date este compusă din relaţii (tabele) ce reprezintă colecţii de obiecte din
lumea reală. Fiecare obiect instanţiat (concret) se numeşte articol. Obiectele au proprietăţi
generice (atribute) reprezentate prin coloanele din tabel, pentru fiecare articol o proprietate
luând o valoare specifică. În bazele de date relaţionale tabelele sunt bidimensionale – adică
coloanele nu pot avea subcoloane şi nu se pot repeta ca semnificaţii. În acest sens, tabelele,
articolele şi atributele trebuie să respectă regulile:
1. Fiecare articol (linie din tabel) reprezintă un singur obiect din realitate – obiectul nu se
repetă pe mai multe linii.
2. Tabelul este omogen privind coloane sale, adică pe o coloana toate valorile sunt de
acelaşi tip (numeric, text, etc.).
3. Fiecare articol (linie) este identificat unic printr-o cheie dedicată.
4. Fiecare coloana are un nume şi semnificaţie distincte. Nu există două coloane care să
aibă aceeaşi semnificaţie într-un tabel.
5. Datele pe liniile şi coloane se pot succeda în ordine arbitrară (adică ordinea obiectelor
sau a rubricilor în tabel nu afectează semnificaţia datelor din tabel).
Nerespectarea regulilor de mai sus duc la anomalii (situaţii anormale), care pot fi
eliminate prin procesul de normalizare a bazei de date. Aceste anomalii sunt:
 1. Anomalie de actualizare (Update) – datorată redundanţei datelor, adică apariţiei unei
valori de mai multe ori pe aceeaşi coloană. Aceasta poate duce la ineficienţa bazei de
date.
2. Anomalie de inserare – datorată lipsei de date, adică trebuie completate toate datele
obligatorii pentru un obiect anume pentru a nu avea valori vide (necompletate) la vre-
un câmp cheie. Acest fel de anomalie poate sa afecteze în mod serios baza de date.
3. Anomalie de ştergere – conduce la pierderea unor informaţii prin ştergerea unor
articole (obiecte) care deţin anumite proprietăţi ce nu se regăsesc la alte articole.
Aceasta poate duce la pierderea de date vitale.
4. Anomalie de inconsistenţă – care apare atunci când la aceleaşi atribute avem domenii
diferite.
La proiectarea bazei de date se stabileşte structura de date care va fi utilizată; fiindcă
această structură trebuie să satisfacă regulile amintite (ce provin din regulile lui Codd) şi cu
siguranţă la prima vedere structura de date nu va fi în forma perfectă, sunt necesari mai mulşi
paşi de proiectare prin care să se aducă structura de date la forma normală. Chiar astfel sunt
denumite stările succesive prin care structura de date poate fi adaptată spre a elimina
anomaliile prezentate mai sus.
În exemplele ce urmează, se consideră ca problemă de rezolvat gestionarea situaţiei
şcolare a studenţilor dintr-o facultate de Ştiinţe Economice. Tabelul cu date care se va realiza
la primul pas arată ca cel din Figura 4-1, care se presupune că va fi folosit pentru a urmări
situaţia şcolară a studenţilor (de aceea denumit SituatiaStudent).
Fiecare student este indicat prin Număr Legitimaţie (câmp NRLEG) cu nume
(NUMESTUD) şi specializarea (cîmp SPECIALIZARE), apoi Cod disciplina (COD), numele
disciplinei( NUMEDISC), numele profesorului titular NUMEPROF, cu titlul didactic
(TITLU) şi cu nota obţinută la examen (NOTA).
Tabelul din Figura 4-1 reprezintă date nenormalizate; astfel, el conţine grupuri de date
care se repetă: COD, NUMEDISC, NUMEPROF, TITLU, NOTA.
Dacă s-ar imagina lucrul uzual la secretariat cu „fişele” studenţilor, acestea vor conţine
fiecare aceste repetiţii – pentru fiecare student se înscriu în fişă (din cataloage) datele pentru
fiecare disciplină. Pentru o bază de date relaţională, acest lucru duce la mari deficienţe în
utilizarea ei – pentru că structura de tabel relaţional nu permite subcoloane - este un tabel
plat, bidimensional; datele despre studenţi din Figura 4-1 pot fi văzute ca un set de coloane
specifice studentului, care au subcoloane indicând datele despre disciplinele pe care le
urmează (nume disciplină, cine o predă, nota, etc.) – deci un tabel tridimensional (datele
despre discipline apar pe adâncime).

SituatieStudent
NRLEG NUMESTUD SPECIALIZARE COD NUMEDISC NUMEPROF TITLU NOTA
1833 Sandu F. Finante Banci 100 Baze Info. Mircea D. Conf. 8
200 Algebra Stan C. Conf. 7
300 LMP Mircea D. Conf. 7
2844 Bran B. ECTS 100 Baze Info. Mircea D. Conf. 9
400 PSI Mircea D. Conf. 5
3245 Costin D. Finante Banci 450 Mat. Econ. Stan C. Conf. 6
300 LMP Mircea D. Conf. 8
325 Microecon. Ivan R. Prof. 6
1935 Gaiu G. Finante Banci 400 PSI Mircea D. Conf. 7
450 Mat. Econ. Stan C. Conf. 7
300 LMP Mircea D. Conf. 5
200 Algebra Stan C. Conf. 7
Figura 4-1. Baza de date cu situaţia şcolară a studenţilor.
 Structura tabelului se poate descrie (în modul uzual din limbajul SQL) astfel:
SituatieStudent(NRLEG, NUMESTUD, SPECIALIZARE, {COD, NUMEDISC,
NUMEPROF, TITLU, NOTA})
unde grupul repetat este indicat între acolade.
Dacă se stabileşte drept cheie primară câmpul NRLEG, atunci tabelul permite şi
încărcarea datelor pentru studenţi cu nume identice – şi în acest caz fiind posibilă identificarea
lor unică (fără confuzii). Câmpul NRLEG este de fapt un câmp de codificare a articolelor din
tabel, codificare care are chiar rolul de identifica unic un obiect, chiar daca el are proprietăţi
similare cu un altul (în cazul nostru numele).
Anomaliile care apar sunt următoarele:
 Nu se ştie câte discipline urmează un student, deci nu se ştie de câte ori se vor repeta
linii pentru el, fiindcă la secţii diferite se predau numere diferite de discipline. Se
observă din Figura 4-1 ca studentul 3245 are trei subiecte in timp ce 1935 are patru.
 Structura de date pe coloane nu este omogenă – de ex. pe coloana NUMESTUD există
linii cu date şi alte linii fără date (vide).
 Liniile nu pot fi citite în orice ordine – că este pericolul să nu ştim la care din studenţi
se referă datele despre o disciplină.
 Există atribute non-cheie (de exemplu numele Disciplinei sau numele Profesorului)
care nu sunt dependente complet de câmpul cheie (numărul legitimaţiei studentului -
NRLEG).
 Unele atribute non-cheie depind direct de alte atribute non-cheie – de exemplu nume
Disciplină depinde complet de cod disciplină COD.
 Anomalie de inserare: dacă se introduce o nouă disciplină (de exemplu opţională) este
obligatoriu să fie şi un student amator să o urmeze pentru a fi posibil să apară în tabel;
în lipsa unui student amator nu avem cum să ştim că ea există şi este oferită de
programă.
 Anomalie de ştergere: dacă studentul 3245 se retrage, dispare şi NUMEDISC 325 din
tabel şi se pierde urma acesteia (ca şi cum nu ar mai fi în programă).
 Anomalii de inconsistenţă: câmpuri cheie (adică în coloana NRLEG) există valori vide
(lipsă numere de legitimaţie) şi nu se ştie cărui student aparţine de fapt linia
respectivă.
Primul pas în eliminarea situaţiilor anomale este sa aducem tabelul (datele) în Forma
Normală 1 (FN1 – iar în engleză 1NF, 1st Normal Form).

4.3.1 Forma Normală 1 (FN1)

Pentru a aduce structura de date la FN1, trebuie eliminate grupurile care se repetă, astfel
că obţinem tabelul din Figura 4-2

SituatieStudent
NRLEG NUMESTUD SPECIALIZARE COD NUMEDISC NUMEPROF TITLU NOTA
1833 Sandu F. Finante Banci 100 Baze Info. Mircea D. Conf. 8
1833 Sandu F. Finante Banci 200 Algebra Stan C. Conf. 7
2844 Bran B. ECTS 100 Baze Info. Mircea D. Conf. 9
3245 Costin D. Finante Banci 325 Microecon. Ivan R. Prof. 6
2844 Bran B. ECTS 400 PSI Mircea D. Conf. 5
3245 Costin D. Finante Banci 450 Mat. Econ. Stan C. Conf. 6
3245 Costin D. Finante Banci 300 LMP Mircea D. Conf. 8
1833 Sandu F. Finante Banci 300 LMP Mircea D. Conf. 7
1935 Gaiu G. Finante Banci 400 PSI Mircea D. Conf. 7
1935 Gaiu G. Finante Banci 450 Mat. Econ. Stan C. Conf. 7
1935 Gaiu G. Finante Banci 300 LMP Mircea D. Conf. 5
1935 Gaiu G. Finante Banci 200 Algebra Stan C. Conf. 7
 Figura 4-2 Baza de date în forma normală 1 (FN1).

De data aceasta liniile pot fi scrise în orice ordine, dar există date redundante (adică ce
apar de mai multe ori) şi se consumă ineficient memorie de stocare a lor. În plus, dacă se face
o modificare la numele unui student (de exemplu o studentă căsătorită), trebuie actualizate
(modificate) mai multe linii, care trebuie căutate prin tot tabelul, pentru că liniile nu mai apar
grupate pentru fiecare student.
Din cele 4 articole acum avem 12 articole, transformând tabelul dintr-o structură
tridimensională în una bidimensională.
Pentru a fi siguri ca orice articol este identificat unic (pentru a se conforma regulii 3)
trebuie să modificăm cheia, prin adăugarea la cheia originală NRLEG a câmpului COD –
împreună reuşind să identifice unic o linie. Astfel, tabelul poate fi descris ca:

SituatieStudent(NRLEG, COD, NUMESTUD, SPECIALIZARE, NUMEDISC,

NUMEPROF, TITLU, NOTA)

Astfel, nu mai apar grupuri repetate de coloane.

Totuşi, s-au menţinut anomaliile:
 Anomalie de actualizare: daca se modifică titlul disciplinei 100 (în Informatică I)
atunci toate liniile care conţin această disciplină trebuie căutate şi modificate. Pot fi
peste 1000 de astfel de linii într-un tabel real.
 Anomalie de Inserare: cheia primară este NRLEG, COD, deci nu putem adaugă o
nouă disciplină fără să fie şi un student care să o urmeze.
 Anomalie de Ştergere: dacă studentul 3245 se retrage, NUMEDISC 325 dispare cu
desăvârşire şi se pierde orice informaţie despre această disciplină (cine o predă).
Aceste anomalii sunt datorate situaţiei de dependenţă parţială care s-a menţinut pentru
atributele non-cheie ce nu sunt dependente in totalitate de cheia primară: NUMESTUD şi
SPECIALIZARE depind de NRLEG, NUMEDISC, NUMEPROF şi TITLU depind de COD
şi doar NOTA depinde complet de ambele (deci de cheia primară stabilită).
În exemplul nostru relaţia este în FN1 şi deţine dependentele parţiale, aşa că normalizarea
continuă cu a doua forma normala (FN2).

4.3.2 Forma Normală 2 (FN2)

Transformarea la FN2 implică obţinerea câte unei noi relaţii pentru fiecare dependenţă
parţială, adică pentru fiecare dependenţă se realizează un tabel separat. Vom avea o relaţie
SituatieStudent cu cheia originală şi atributul NOTA, o relaţie Student pentru atributele
NUMESTUD şi SPECIALIZARE cu o cheie primară NRLEG, şi o relaţie Curs pentru detalii
ale cursului: COD, NUMEDISC, NUMEPROF si TITLU.
Descrierile relaţiilor sunt aşadar:

SituatieStudent(NRLEG,COD,NOTA)
Student(NRLEG,NUMESTUD,SPECIALIZARE)
Disciplina(COD,NUMEDISC,NUMEPROF,TITLU)

În această nouă situaţie:

 NRLEG şi COD formează încă cheia primară pentru relaţia SituatieStudent şi atributul
NOTA este dependent în de întreaga cheie.
 NUMESTUD şi SPECIALIZARE în FN1 sunt dependente de complet de cheia NRLEG,
deci se poate forma noua relaţie Student.
 NUMEDISC şi NUMEPROF de asemenea FN1 sunt dependente de cheia COD şi
formează o nouă relaţie Curs.
Se observă că SituatieStudent conţine acum chei externe (sau străine) adică chei ale
obiectelor din alte tabele. Aceste chei au rolul de a asocia relaţiile (adică tabelele). Acum se
 poate înţelege de ce se foloseşte cuvântul relaţie şi pentru tabel şi pentru legătura între tabele:
tabelul SituatieStudent este de fapt o relaţie între tabelele Student şi Disciplina, având drept
cheie primară perechea de chei din cele două tabele (fiecare specifică tabelului din care
provine).
Anomalia de inserare a fost rezolvată şi putem adăuga discipline noi fără probleme
(indiferent dacă sunt sau nu între studenţii existenţi amatori să le urmeze). Anomalia de
ştergere a fost şi ea rezolvată, astfel că putem să ştergem în sfârşit un student (care, de
exemplu, se retrage) fără să pierdem informaţii de care avem nevoie. Anomalia de actualizare
fost de asemenea rezolvată în câteva cazuri, astfel dacă vrem să schimbăm titlul unei
Discipline se face o singură modificare în tabelul Disciplina.
Mai există şi alte anomalii? Dacă se examinează relaţia Disciplina se va constata că
TITLU depinde de NUMEPROF: Mircea D. are încă gradul de Conf. dar va deveni Prof. şi
aceasta înseamnă că atributul TITLU din Disciplina nu este dependent direct de cheia primară
COD (al Disciplinei).
Mai sunt alte câteva probleme cu relaţia Disciplina:
 Nu putem adăuga un nou NUMEPROF decât doar dacă acel profesor are ataşată o
disciplină - anomalie de inserare.
 Dacă un profesor schimbă TITLU trebuie să găsim fiecare instanţă (apariţie) a acelui
NUMEPROF în Disciplina şi să facem modificarea - anomalie de actualizare.
 Dacă ştergem gradul se va pierde informaţia asupra celui care predă (un asistent nu
predă Disciplina) - anomalie de ştergere.
Aceste anomalii există din cauză că gradul profesorului nu este dependent direct de
disciplina predată ci indirect sau tranzitiv prin intermediul câmpului NUMEPROF. A treia
formă normală elimină aceste dependenţe tranzitive şi indirecte.

4.3.3 Forma Normală 3 (FN3)

La transformarea datelor pentru a satisface FN3 se extrage într-o relaţie separată, orice
atribut care prezintă dependenţe tranzitive. Aceasta înseamnă obţinerea unei noi relaţii
(derivate), în cazul nostru relaţia Profesor, cu atributele NUMEPROF şi TITLU.

SituatieStudent Student
NRLEG COD NOTA NRLEG NUMESTUD SPECIALIZARE
1833 100 8 1833 Sandu F. Finante Banci
1833 200 7 2844 Bran B. ECTS
2844 100 9 3245 Costin D. Finante Banci
3245 325 6 1935 Gaiu G. Finante Banci
2844 400 5
3245 450 6 Profesor
3245 300 8 NUMEPROF TITLU
1833 300 7 Mircea D. Conf.
1935 400 7 Stan C. Conf.
1935 450 7 Ivan R. Prof.
1935 300 5
1935 200 7
Disciplina
COD DISCIPLINA NUMEPROF
100 Baze Info. Mircea D.
200 Algebra Stan C.
325 Microecon. Ivan R.
400 PSI Mircea D.
450 Mat. Econ. Stan C.
300 LMP Mircea D.
 Figura 4-3 Baza de date normalizată

Descrierea relaţiilor va fi aşadar:

SituatieStudent(NRLEG,COD,NOTA)
Student(NRLEG,NUMESTUD,SPECIALIZARE)
Disciplina(COD,NUMEDISC,NUMEPROF)
Profesor(NUMEPROF,TITLU)

4.3.4 Paşi în normalizarea bazei de date şi normalizare avansată

Pe scurt, procesul de normalizare constă în eliminarea datelor redundante din tabele
prin operaţia de proiecţie relaţională (PROJECTION). Date redundante sunt cele care se
repetă sau nu reflectă au specificul entităţii vizate, iar operaţia de proiecţie relaţională constă
în descompunerea („despicarea”) unui tabel cu mai multe coloane în alte două (sau mai multe)
tabele, în fiecare din acestea transferându-se un anumit număr de coloane din tabelul original.
Scopul principal al normalizării este de a obţine un (singur) câmp de identificare (cheie
primară) – plasată în prima coloană, iar restul de câmpuri (coloane spre stânga) să fie
funcţional dependente de prima. Pentru a fi corectă, descompunerea tabelului original trebuie
să se facă fără pierderi de date (câmpuri), adică să se poată obţine tabelul original prin
operaţia relaţională de reunire (JOIN)
Paşii normalizării, începând cu baza de date ne-normalizată, sunt:
1. Eliminarea grupurilor de câmpuri care se repetă - FN1
a. Identificarea câmpurilor care se repetă.
b. Obţinerea de câmpuri atomice (singulare semantic).
c. Stabilirea câmpurilor cu rol de cheie compusă (la această fază sigur mai multe câmpuri
împreună vor juca rolul de cheie primară).
2. Rezolvarea dependenţelor parţiale - FN2.
a. Identificarea tuturor determinanţilor alţii decât cheia compusă şi a câmpurilor
dependente.
b. Crearea şi denumirea unui nou tabel pentru fiecare determinant, care devine câmp
cheie primară.
c. Includerea câmpurilor dependente din tabelul original în tabelul creat la pct. b.
d. Ştergerea tuturor câmpurilor de la pct.c. din tabelul original, cu excepţia câmpului
determinant care devine cheie externă.
e. Re-denumirea tabelului original pentru a fi corect semantic.
3. Rezolvarea dependenţelor indirecte - FN3, practic prin repetarea punctelor a-e de la
FN2, cu excepţia faptului că acum cheia primară va fi un singur câmp (nu mai multe).

Formele normale conţin obligatoriu pe cele precedente, adică FN2 conţine pe FN1 iar
FN3 pe FN1 şi FN2.
În practică, se consideră că este suficientă normalizarea după primele trei forme FN1,
FN2 şi FN3. Formele normale se pot obţine rapid şi comod folosind DER realizată în faza de
modelare conceptuală (v.§3.4), unde se identifică corect entităţile (categoriile de obiectele) şi
relaţiile între acestea. Apoi se stabileşte pe rând care relaţie reprezintă de fapt „interacţiune”
cu producere de date (v. cazul reprezentat în Error! Reference source not found., privind
interacţiunea Student-Disciplină) care se devine un nou tabel ce are câmpul cheie primară
compus din chei externe provenite din tabelele în interacţiune.
Formele normale se obţin prin modificarea („despicarea”) tabelelor bazei de date
folosind DER şi obţinând după fiecare pas de normalizare o nouă DER.
 4.4 Proiectarea de detaliu
După realizarea diagramei Sistemului Informatic – într-una din variantele prezentate
mai sus, există premizele pentru proiectarea funcţională, adică descrierea în amănunt a
structurilor de date şi a prelucrărilor vizate.
În continuare se desfăşoară următoarele activităţi:
1. se revăd cerinţele de funcţionare formulate la nivelul fiecărei componente (se
reajustează structura şi concepţia sistemului);
2. se proiectează ieşirile (conţinut, format, periodicitatea, termene, volum, destinaţie);
3. se specifică algoritmic prelucrările pentru fiecare procedură în parte;
4. se proiectează intrările (corespunzător ieşirilor impuse);
5. se proiectează structura fişierelor sau a bazei de date;
6. se proiectează sistemul de codificare (codificarea fiind necesară pentru ataşarea unei
chei unice fiecărui reper şi pentru utilizarea în a cheilor comun la mai multe fişiere);
7. se proiectează circuitul informaţional;
8. se proiectează procedurile de interfaţă cu utilizatorul (mod manual de lucru sau
automat, interfaţă grafică sau text);
9. se elaborează grafice de realizare a fiecărei componente precizând cerinţele şi
condiţiile tehnice ale acesteia;
Documentaţia realizată în această fază se numeşte „Proiect Tehnic” sau „Specificaţie de
Programare”.
O metodă de proiectare (conceptuală, logică şi fizică) des utilizată în România este
metoda MERISE - de provienţă franceză, dar care respectă principalii paşi din l
Etapele de principiu care trebuie parcurse pentru realizarea Sistemului Informatic sunt
(conform metodei MERISE):
 Modele Conceptuale ale Datelor şi Prelucrărilor (MCD şi MCP) – care descriu pentru
fiecare din acestea ideile de principiu pentru organizarea lor;
 Modele Logice ale Datelor şi Prelucrărilor (MLD şi MLP) – care descriu structura de
amănunt şi legăturile între aceste structuri şi privesc proiectarea software (şi hardware
implicat);
 Modele Fizice ale Datelor şi Prelucrărilor (MFD şi programe) – care sunt efectiv
implementări ale structurilor de date (fişiere) şi prelucrărilor (module program sau
interogări formulate prin intermediul grilelor de proiectare interogări) şi privesc
punerea în operă concretă şi materială a Sistemului Informatic.
Aceste modele coboară în ordine de la nivelul conceptual la cel de implementare (de la
cel mai abstract la cel mai concret).
Pentru realizarea efectivă a Sistemului Informatic este necesar să se analizeze cerinţele
şi de aici să se extragă Modelul Conceptual al Comunicaţiilor MCC (din care va rezulta de
fapt distribuirea spaţială a datelor) şi Modelul Organizaţional al Prelucrărilor (MOP) care
descrie restricţiile induse de mediu (organizatoric, spaţial şi temporal).

Stocarea structurilor de date se face, actual, în două moduri: în fişiere şi în baze de date.
Modul de organizare specifică a datelor în cele două moduri, cu avantaje şi dezavantaje sunt
prezentate mai jos:
 Organizare ca fişier în aplicaţii: datele sunt memorate în fişiere cu structuri specificate
chiar în aplicaţii, astfel că orice operaţie efectuată asupra datelor necesită proceduri speciale,
dedicate. Avantaje: atât aplicaţia cât şi fişierul de date pot fi optimizate. Dezavantaje: orice
modificare în structura datelor implică modificarea aplicaţiei.
 Organizare în baze de date. În acest caz, structurile de date sunt definite generic (de
obicei în tabele) astfel că aplicaţiile apelează datele prin intermediul unor programe
specializate. Aplicaţiile sunt realizate ca prelucrări executate:
- pe lot (batch) - în care întreaga înşiruire de comenzi formează un lot şi este preluată şi
executată în bloc;
- prin interpretoare - în care fiecare comandă este executată separat şi apoi se trece la
următoarea.
Sistemele de gestiune a bazelor de date (SGBD) prezintă ambele moduri de lucru utile
în următoarele situaţii:
- în cazul lot se pot executa programe de sine stătătoare pe care le vor utiliza nespecialişti;
- în cazul interpretor prelucrările sunt lansate de personal specializat sau în momentele de
depanare şi testare, astfel că se poate interveni la orice moment în modificarea comenzilor.

Folosirea SGBD prezintă avantaje şi dezavantaje:

Avantaje: independenţa datelor de programe, structura datelor se poate modifica oricând (se
adaugă o nouă coloană în tabel) fără a modifica interogările (Query), se asigură portabilitatea
datelor şi programelor (datele se pot duce pe alt sistem fără a modifica nimic din modul de
lucru), prelucrările se pot executa şi memora pt. a fi reutilizate ori de câte ori este nevoie.
Dezavantaje: spaţiu mare de memorie ocupat (pe disc şi în memorie); necesitatea utilizării în
fundal a unui SGBD ca schelet obligatoriu de lucru, adică (în general) nu se poate obţine un
program executabil care să fie preluat şi memorat pe alt sistem independent de SGBD – de
aici rezultă costuri mai mari implicate de cumpărarea încă unei licenţe SGBD.
Pentru că în lucrarea de faţă se utilizează mediul de baze de date MS Access în scopul
experimentării şi verificării acţiunilor de proiectare şi pentru că prelucrările vizate sunt în
principal interogări relativ simple (ce nu necesită flux de operaţiuni şi nici modele complexe
de prelucrare), se vor discuta în continuare în special probleme legate de proiectarea
structurilor de date – care de fapt sunt şi problemele esenţiale la proiectarea sistemelor de
gestiune, atunci când se utilizează mediile moderne de baze de date.

4.5 Management de proiect

Se consideră că termenul de proiect poate fi folosit în cazul unei serii de activităţi care
vizează un obiectiv complex ce iese din rutina obişnuită – adică nu se repetă des şi are un
pronunţat caracter specific, indus de problema de rezolvat.
Realizarea unui SI presupune coordonarea mai multor echipe de oameni şi planificarea
multor resurse – materiale, financiare şi umane, în vederea atingerii unui scop individualizat
ce vizează o problemă specifică a organizaţiei beneficiare. Această problemă priveşte
informaţii şi cunoştinţe necesare organizaţiei care vor fi prelucrate cu sisteme electronice de
calcul, care o dată instalate vor fi doar exploatate, adică nu mai apar probleme de natura
proiectării şi implementării; prin aceste caracteristici, realizarea unui SI constituie un proiect
al organizaţiei beneficiare.
Managementul de proiect reprezintă planificarea, organizarea şi administrarea
(managementul) sarcinilor şi resurselor pentru a îndeplini un obiectiv definit, de obicei cu
constrângeri de timp, cost şi calitate.
Managerii oricărei activităţi pot folosi conceptele şi uneltele managementul de proiect
pentru a gestiona propria muncă. Dacă un proiect implică mai mult decât câteva sarcini sau
dacă câteva resurse trebuie să fie urmărite, practicile managementului de proiect pot fi
folositoare.

4.5.1 Scopuri şi metode în managementul de proiect

Scopul managementului de proiect este de a atinge un obiectiv specific în timp şi buget
dat şi asigurând totodată o calitate ridicată. Un obiectiv poate fi simplu – precum planificarea
proiectării şi producţiei unei oferte de vânzări pentru o firmă, sau poate fi complex – de
exemplu proiectarea şi realizarea sistemului integrat de informatizare a unui complex
siderurgic. În fiecare caz, proiectul trebuie împărţit în activităţi şi sarcini ce pot fi gestionate
uşor; sarcinile sunt blocurile elementare ale managementului de proiect. Pentru a îndeplini
aceste sarcini, resurse precum oameni şi echipamente trebuie repartizate.
 Managementul de proiect poate răspunde la diverse planificări, resurse şi întrebări,
 Cât timp va lua acest proiect?
 Dacă o sarcină este întârziată va fi întârzia tot proiectul?
 Ce sarcini sunt critice pentru a respecta planificarea?
 Există suficiente resurse disponibile pentru a completa proiectul conform planificării?
 Care sunt costurile acestui proiect?
În continuare se face o trecere în revistă a câtorva din cele mai semnificative realizări în
tehnicile de dezvoltare a managementului de proiect. Fiecare din aceste realizări a influenţat
dezvoltarea managementului de proiect software.
4.5.1.1 Metoda drumui critic (Critical Path Method - CPM)
Procesul de computerizare a managementului de proiect a început în anii 1950.
Corporaţia Du Pont, într-un efort de a îmbunătăţi tehnicile de planificare a proiectului, a
dezvoltat un sistem de planificare numit Metoda Drumului Critic (Critical Path Method) sau
planificare CPM. CPM este un model matematic ce calculează durata totală a proiectului pe
baza duratei fiecărei sarcini individuale şi a dependenţelor, identificând ce sarcini sunt critice.
Acest model este metoda fundamentală pentru planificare folosită astăzi în managementul de
proiect şi a fost dezvoltate aplicaţii software folosind această tehnică.
4.5.1.2 Diagrama Gantt
Într-o evoluţie separată a sistemelor de management de proiect, Henry L. Gantt a
dezvoltat un sistem de diagrame grafice pentru a descrie activităţile într-o perioadă de timp.
La început numite diagrame cu bare, aceste diagrame au fost redenumite diagrame Gantt după
numele inventatorului sistemului. Diagramele Gantt implementate în programele pentru
calculator pot fi folosite pentru a construi un proiect, a urmări sau a pentru a crea rapoarte ale
unui proiect.
Presupunem diagrama Gantt din Figura 44, unde se regăsesc activităţi specifice
proiectării software cu numele lor în engleză:
A. Proiectarea structurii programului.
B. Programare meniuri şi controale (butoane, acţiuni).
C. Programare module pentru afişare rapoarte.
D. Construirea structurii de fişiere.
E. Programare module de introducere date.
F. Crearea datelor de test.
G. Desfăşurare teste.

Figura 4-4 Diagrama Gant în dezvoltarea software.

Diagrama din Figura 44 reprezintă desfăşurearea activităţilor dar nu detaliază care sunt
dependenţele între ele:
 A înainte de B,C sau D
 D în acelaşi timp cu B şi C
  B înainte E
 E înainte F
 Toate înainte H
 G în acelaşi timp cu F
Activităţile specificate în diagrama Gant se pot desfăşura în serie sau în paralel, după
cum sunt chiar ilustrate prin barele din Figura 44.
4.5.1.3 Tehnica PERT
PERT (Program Evaluation Review Technique) a fost dezvoltată în 1958 de Marina
Militară a Statelor Unite ale Americii şi de către Booze, Allen, şi Hamilton, o firmă de
consultanţă. Metoda a fost folosită în multe proiecte complexe ce necesitau un management şi
o planificare atente. În dezvoltarea sistemului de arme Polaris, Marina Americană avea nevoie
de o metodă pentru a planifica evoluţia proiectului şi o cale de a evalua efectul schimbărilor în
planificare. Tehnica a avut succes şi Marina Americană a terminat proiectul Polaris cu doi ani
înaintea datei programate, timp în care alte proiecte se derulau depăşind bugetele alocate şi
având întârzieri faţă de datele planificate.
Deşi cea mai bună abordare a managementului de proiect este de a împărţi proiectul în
piese mici, gestionabile, există pericolul de a pierde din vedere proiectul ca întreg în timpul
conducerii sarcinilor mai mici. Activităţile proiectului sunt de obicei interdependente. Totuşi,
interdependenţa sarcinilor nu este evidentă în diagrama cu bare. Sarcinile critice, cele care
trebuie îndeplinite într-o anumită ordine, de asemenea nu sunt evidente. Un manager de
proiect doreşte să îndeplinească următoarele: să indice activităţile individuale şi timpul
necesar pentru fiecare, să arate relaţiile dintre activităţi, să identifice ordinea corectă, să dea
estimările de timp, să izoleze ariile unde e posibil să apară probleme sau întârzieri (şi să indice
acele arii ce au nevoie de monitorizare şi supraveghere) şi să dispună de mijloace de a urmări
evoluţia proiectului. Poate fi necesar să cunoască, de exemplu, ce efect are întârzierea unei
activităţi în cadrul întregului proiect sau ce activitate are cea mai mică toleranţă la întârziere.
Diagrame PERT construite corect pot oferi aceste informaţii în timp ce diagramele cu bare de
abia sugerează interdependenţa sarcinilor.
Proiectele conţin evenimente şi activităţi. Diagrama PERT foloseşte noduri şi căi (arce)
pentru a reprezenta relaţiile dintre activităţile proiectului. Nodurile reprezintă evenimente şi
căile arată activităţile sau sarcinile ce sunt necesare pentru a trece de la un eveniment la altul.
Timpul necesar pentru a îndeplini fiecare activitate este indicat pe cale. Într-un proiect mare,
reţeaua de linii şi noduri poate fi foarte mare.
Diagrama PERT este foarte valoroasă în etapa proiectare şi planificare a unui proiect.
Când reţeaua este terminată, se studiază pentru a determina drumul critic (drumul de la
început până la sfârşit) pe care timpul total necesar e mai mare decât pe orice alt drum. Dacă
activităţile dea lungul acestui drum nu sunt terminate la timp, întregul proiect va întârzia. De
aici atenţia ar trebui îndreptată spre aceste activităţi. Diagrama PERT arată, de asemenea,
interdependenţele dintre sarcini şi ajută să se răspundă la trei tipuri de întrebări (ce ţin de
management):
1. Ce alte activităţi trebuie să preceadă sau să fie terminate înainte de iniţierea unei
activităţi specifice?
2. Ce alte activităţi pot fi îndeplinite în timp ce se desfăşoară o altă activitate specifică?
3. Ce activităţi nu pot fi începute decât după completarea unei activităţi specifice?
Pentru a dezvolta o reţea PERT pentru un proiect de SI trebuie identificate mai întâi
sarcinile şi timpul asociat cu fiecare activitate. Timpul necesar pentru fiecare activitate este
durata. Apoi trebuie identificată secvenţa de activităţi şi notate locurile în care sarcini
specifice trebuie să preceadă alte sarcini şi unde anumite activităţi pot apărea simultan cu
altele.

4.5.2 Estimarea realizării priectului

Estimarea timpului de dezvoltare a unui sistem e o provocare pe care analiştii sistemelor
de informaţie trebuie să o rezolve cu succes. Perspectiva managementului corporativ general
este că grupurile de sisteme de informaţie nu vor fi văzute ca o parte integrantă a activităţii
comerciale pe care o sprijină până când pot livra sisteme la timp şi încadrându-se în buget.
Aceasta înseamnă estimarea cu acurateţe şi apoi îndeplinirea acestor estimări combinat cu un
management profesional de proiect.

4.5.3 Fazele managementului de proiect

Managementul de proiect implică în general trei faze:
4.5.3.1 Crearea proiectului
Aceasta este cea mai importantă fază a managementului de proiect. Include definirea
sarcinilor şi durata fiecărei, stabilirea relaţiilor dintre sarcini şi, dacă utilizarea resurselor
poate fi urmărită, stabilirea resurselor pentru fiecare sarcină. Toate fazele următoare ale
proiectului sunt bazate direct pe informaţia oferită când proiectul este creat.
4.5.3.2 Gestionarea proiectului
Această fază a managementului de proiect este un proces continuu ce începe în
momentul creării proiectului şi se sfârşeşte când proiectul este terminat. Gestionarea
proiectului include urmărirea şi ajustarea proiectului pentru a reflecta schimbările ce pot apare
pe măsură ce proiectul avansează.
4.5.3.3 Realizarea rapoartelor despre proiect
În această fază este prezentată informaţia despre proiect. Unul din cele mai importante
beneficii ale utilizării de programe (software) pentru managementul de proiect este
posibilitatea de a crea rapid şi uşor rapoarte atractive şi informative.

4.5.4 Costurile managementului de proiect

Următorii factori sunt luaţi de obicei în considerare la estimarea proiectelor de
dezvoltare a unui sistem:
4.5.4.1 Costul personalului
Acesta nu include doar costul personalului pentru dezvoltareci şi costul personalului de
întreţinere precum dactilografe, etc.
4.5.4.2 Costuri de subcontractare externă
De exemplu costurile asociate cu subcontractarea pentru dezvoltarea a unei firme cu
experienţă în fabricarea de electronice.
4.5.4.3 Costurile timpului calculator
Acesta este un cost foarte ridicat ce include timpul pentru activităţile de dezvoltare cum
ar fi integrarea, testarea şi sprijinirea activităţilor de genul planificării proiectului şi
documentare.
4.5.4.4 Costuri de introducere a datelor
Acestea includ activităţi precum introducerea de date d test şi secretarele ce introduc
documentaţia.
4.5.4.5 Costuri ale facilităţilor fizice
Acestea includ spaţiul pentru birouri, mobila, sistemele de securitate, aer condiţionat,
etc.
4.5.4.6 Costuri ale consumabilelor
Consumabilele sunt îndeobşte considerate hârtia pentru imprimantă, toner de imprimare,
discuri, etc.
4.5.4.7 Costuri de deplasare şi subzistenţă
Pentru documentare, pentru interviuri şi în diverse acţiuni de preluarea materiale sau
documente se fac deplasări ale personalului în diferite locuri.

5 De planificarea resurselor (ERP) la productica lină

(Lean Manufacturing)
Planificarea resurselor companiei (Enterprise Resource Planning - ERP) este o metodă
sistematică peste un sistem informatic de control, echilibrare şi optimizare dinamică a
resurselor unei companii. Când este utilizată eficient, aceasta poate ajută o companie să obţină
rezultate de nivel mondial în dezvoltare, profitabilitate şi îmbunătăţirea produselor şi
serviciilor. Aplicarea ERP priveşte paradigma prin care fiecare afacere este unică şi ca atare
trebuie condusă într-un mod specific dar totodată într-un mod similar celor ce funcţionează
spre optim.
Se poate verifica această paradigmă răspunzând la câteva întrebări - puse din punctul
de vedere al managerului: Clienţii îşi doresc produse şi servicii superioare la preţuri mai mici?
Doresc ei o livrare rapidă? Concurenţa reuşeşte să copieze repede tehnicile tale de succes şi
evite mai bine greşelile pe care le faci? Foloseşti credite şi debite în contabilitate? Eşti sigur
că ai găsit cel mai bun mod de operare? Ar putea unul din cele peste 350 de sisteme ERP de
pe piaţa actuală să te ajute să devii puţin mai bun, mai rapid, mai ieftin?
De obicei, unicitatea afacerii este dată de felul în care se urmăresc, se administrează şi
se comunică problemele companiei
 cele interne - privitoare la informaţiile financiare, de planificare a producţiei şi
datele despre vânzări;
 cele externe – cotele de vânzări, ordinele de plată şi ordinele de transport.
Majoritatea companiilor dezvoltă metode unice de urmărire, administrare şi
comunicare, aceasta nu pentru că au un plan dînainte gândit pentru a deveni lider la nivel
mondial, ci datorită unui proces evolutiv adeseori iniţiat de către persoane ce au lucrat în
companie (şi poate au şi părăsit-o între timp). Totuşi, doar unele companii dezvoltă sisteme
eficiente de planificare a resurselor, acestea dezvoltate (de obicei) datorită unei politici de
cercetare aplicată serios şi eficient de către conducerea companiei, în efortul de eficientizare a
proceselor afacerii şi de obţinere de avantaje asupra concurenţei.
Cererea de sisteme ERP este din ce în ce mai mare, astfel că trei din cele mai mari
patru companii producătoare de software din lume produc şi vând sisteme ERP. Scopurile
ERP sunt creşterea satisfacţiei angajatului în realizarea sarcinilor sale, obţinută prîntr-o
planificare mai bună a fluxului de muncă precum şi a comunicării, ca un rezultat de re-
engineering a afacerii şi a proceselor de fabricaţie. Selectarea un sistem ERP se face de obicei
scopul îmbunătăţirea proceslor afacerii, a creşterii venitului, a reducerii costurilor şi a
îmbunătăţirea timpului de lansare pe piaţa (time-to-market). Se obţine totodată, creşterea
calităţii, creşterea nivelului de servire a clienţilor, îmbunătăţirea procesului de producţie,
depăşirea situaţiilor de lipsă de informaţie, eliminarea costului de menţinere a sistemelor mai
vechi şi îmbunătăţirea flexibilităţii afacerii.

5.1 Sisteme informatice utilizate în procesele de afaceri

Companiile moderne utilizează diverse tipuri de sisteme informatice pentru a mări
eficienţa activităţilor, pentru a rezolva diferitele probleme legate de operaţiunile de afaceri şi
chiar pentru a găsi noi oportunităţi de afaceri. Există o varietate de tipuri de sisteme
informatice (de procesare a tranzacţiilor, de raportare a situaţiilor, de suport al deciziilor, etc)
care facilitează desfăşurarea activităţilor din compartimentele firmelor (de producţie, de
marketing, de resurse umane, financiare, de contabilitate, etc).
Utilizatorii sistemelor informatice trebuie să cunoască modul în care acestea sprijină o
funcţiune a firmei (de ex: contabilitatea) sau o activitate (de ex: bancară). Astăzi, sunt
necesare cunoştinţe clare de sisteme informatice pentru profesioniştii din mediul de afaceri.
De exemplu, o persoană care ocupă un post de marketing într-o bancă trebuie să deţină
cunoştinţe de bază despre modul în care sistemele informatice de marketing facilitează
activităţile de marketing bancar. O persoană care doreşte să ocupe un post de contabil trebuie
să aibă cunoştinţe despre produsele software utilizate în activitatea contabilă.

Sisteme informatice utilizate în afaceri

Producţie Marketing Financiar Contabilitate Resurse

- producţie - publicitate - previziune - conturi - analiza

asistată şi reclamă a debitoare recompens
de - managemen financiară şi e personal
calculator t ul de - managemen creditoare - inventarul
- controlu produs t ul - contabilitat abilităţilor
l - previzionare creditelor ea angajaţilor
utilajelo a vânzărilor - managemen costurilor - previzionare
r - automatizar t ul - contabilitat a necesarului
- planificarea e a forţei de lichidităţilor ea de persoane
necesarului vânzare - analiza salariilor - analiza
de materiale - managemen necesarului - contabilitat dezvoltări
şi m.p. t ul de finanţat e a m.fixe şi i
- planificarea vânzărilor - analiza activelor resurselor
achiziţiilor performanţel circulare umane
Fig.5-1 Tipologia sistemelor informatice utilizate în afaceri

În mediul de afaceri, sistemele informatice utilizate în operaţiunile de afaceri (de

marketing, de producţie, financiar, etc) sunt integrate într-o reţea care formează un sistem
informatic multifuncţional unitar care este subordonat sistemului informatic managerial.
Organizaţiile utilizează acest sistem multifuncţional ca pe o modalitate strategică de a
distribui resursele informaţionale între departamente (compartimente) şi pentru a îmbunătăţi
eficienţa afacerilor, ajutându-le în atingerea obiectivelor strategice.

5.1.1 Sisteme informatice de marketing (SIMK)

Funcţiunea de marketing a unei firme se ocupă cu planificarea, promovarea şi
vânzarea produselor existente pe pieţele interne şi externe, dar şi cu dezvoltarea de noi pieţe şi
noi produse pentru a servi cât mai bine clienţii actuali şi pe cei potenţiali. Firmele performante
utilizează computere pentru a eficientiza activităţile de marketing în contextul schimbărilor
rapide de mediu în care acestea operează.
Sistemele informatice strategice, tactice şi operaţionale reprezintă un suport pentru
managerii de marketing în planificarea produselor, a deciziilor de preţ, în alegerea strategiilor
de promovare şi publicitate, în alegerea canalelor de distribuţie adecvate.
Sistemele informatice de evaluare şi control a activităţii de marketing furnizează
rapoarte managerilor de marketing privind eficienţa activităţilor desfăşurate, precum şi
informaţii privind diferenţele între rezultatele obţinute şi obiectivele de marketing planificate.
 Cele mai importante tipuri de sisteme informatice suport ale activităţii de marketing,
aşa cum au fost sintetic reprezentate şi în figura nr. 2, sunt:
 Sisteme informatice de management al vânzărilor (SIMV);
 Sisteme informatice de automatizare a forţei de vânzare (SIAFV);
 Sisteme informatice pentru promovare şi publicitate (SIPP);
 Sisteme informatice de management al produselor (SIMP);
 Sisteme informatice de previzionare a vânzărilor (SIPV);
 Sisteme informatice de cercetare a pieţei (SICP);
 Sisteme informatice de management al marketingului (SIMMK).

Sisteme informatice de planificare a marketing-mix

Produs Preţ

Distribuţie Promovare
Manageri de Pieţe ţintă
marketing

Sisteme informatice de evaluare si control al activităţii de marketing

Evaluarea componentelor mix-ului de marketing

Fig. 5-2 Sisteme informatice de marketing

Sisteme informatice de management al vânzărilor (SIMV)

Managerii de vânzări au ca principală sarcină planificarea necesarului de angajaţi
pentru forţa de vânzare, recrutarea lor şi monitorizarea atentă a activităţilor acestora.
Subsistemul informatic de management a vânzărilor (SIMV) fumizează rapoarte care
analizează vânzările pe grupe de produse, agenţi de vânzare, zone arondate acestora, tip de
clienţi, etc. Aceste rapoarte ajută managerii de vânzări să dezvolte programe care au drept
scop creşterea volumului vânzărilor.
Un subsistem informatic de management a vânzărilor (SIMV) facilitează structurarea
forţei de vânzare a unei firme prin programe informatice care determină:
 segmentarea clienţilor, în funcţie de volumul vânzărilor previzionate;
 frecvenţele de contactare a clienţilor;
 volumul de muncă necesar pentru îndeplinirea obiectivelor (numărul de clienţi vizaţi
din fiecare segment se înmulţeşte cu frecvenţele de contactare corespunzătoare);
 numărul mediu de vizite de vânzări pe care le poate face într-o perioadă de timp un
agent de vânzări;
 numărul de agenţi de vânzări necesari (determinat prin împărţirea numărului total de
vizite necesare la numărul mediu de vizite pe care le poate face un agent de vânzări
într-o anumită perioadă de timp);

Sisteme informatice de automatizare a forţei de vânzare (SIAFV)

Noile tehnologii ale informaţiei oferă numeroase posibilităţi de automatizare a forţei
de vânzare. În firmele performante, membrii echipelor de vânzare sunt dotaţi cu laptop-uri
(calculatoare portabile) conectate la serverul departamentului de vânzări; prin intermediul
mesageriei electronice pot transmite factorilor de decizie informaţii statistice referitoare la
vânzări precum şi liste de prospecţi, oferte ale concurenţilor, etc.
Vom prezenta în continuare un exemplu concret de automatizare a forţei de vânzare la
compania Shell. Compania a creat un pachet de programe destinate laptop-urilor membrilor
forţei de vânzare. Aplicaţiile e-mail le-au permis agenţilor de vânzări să primească şi să
trimită mesaje cu o mai mare rapiditate. Diferite formulare precum planurile de vânzări şi
rapoartele privitoare la vizitele comerciale pot fi completate rapid şi expediate în format
electronic. Pachetul de programe destinat forţei de vânzare include şi o agendă pentru
întâlnirile de afaceri, un program de calcul tabelar şi un pachet software de grafică, necesar
prezentărilor făcute clienţilor.
Numeroase firme care şi-au automatizat forţa de vânzare afirmă că au obţinut creşteri
spectaculoase ale eficienţei acţiunilor agenţilor de vânzări.

Sisteme informatice pentru promovare şi publicitate (SIPP)

Acest subsistem informatic integrează o bază de date clienţi şi permite identificarea
unei clientele-ţinta vizată de o campanie de promovare şi publicitate. De asemenea, are ca
funcţie de bază asistarea deciziilor privind planificarea, derularea şi testarea unei campanii de
publicitate sau promovare a vânzărilor.
Dacă o firmă se poate implica în producţia unor materiale publicitare sau chiar în
crearea de clipuri publicitare, programele informatice recomandate sunt:
• aplicaţii software pentru conceperea materialelor grafice (de genul Abobe Illustrator,
Corel Draw, etc);
• aplicaţii software pentru prelucrarea imaginilor (Adobe PhotoShop, Corel Photo-Paint);
• aplicaţii pentru procesarea video (Video Blaster, Adobe Premiere, etc).

Sisteme informatice de management al produselor (SIMP)

Managerii de produs au nevoie de informaţii pentru a planifica, evalua şi controla
performanţele aduse de liniile de produse, gamele de produse respectiv mărcile de produse
aferente acestora. Responsabilitatea unui manager de produs este defalcată în şase sarcini ,
care pot fi îndeplinite eficient cu sprijinul unui sistem informatic de management a
produselor:
• elaborarea unei strategii pe termen lung pentru produsele firmei;
• pregătirea planurilor de marketing anuale;
• colaborarea cu departamentul de publicitate în vederea creării de reclame şi campanii
promoţionale;
• stimularea susţinerii produsului de către distribuitori şi forţa de vânzare;
• strângerea conţinuă de informaţii privitoare la acţiunile clienţilor faţă de produsele
firmei şi observarea cauzelor care determină nemulţumirile clienţilor;
• întreţinerea acţiunilor de îmbunătăţire a produsului pentru a-l face să satisfacă deplin
doleanţele şi exigenţele clienţilor.
Când managerul de produs acţionează pictograma unui proiect de dezvoltare a unui
produs, el poate parcurge toată informaţia legată de aceasta doar printr-un simplu clik de
mouse; poate parcurge de asemenea analizele financiare şi rezultatele unei cercetări de piaţă;
poate vizualiza liste de activităţi curente; poate afla dacă produsul intră într-o primă testare pe
un grup sau o echipă de cercetare testează un nou tip de produs; un forum de discuţii
electronice poate include o dezbatere a strategiei de reclamă, etc.
Analiza deciziilor de preţ reprezintă o funcţie importantă a acestui sistem informatic.
Modelele utilizate pot fi folosite pentru a evalua performanţele produselor curente şi
perspectivele de succes a produselor ce vor fi create.

 K. Bertrand - ,,Sales Management Software Tackles Toughest Customers", Busines Marketing, 1998;
 M. Băduţ – „Informatica în management“, Ed. Albastră, 2003.
 Ph. Kotler – „Managementul marketingului“, Ed. Teora, 1999
 Bill Gates – „Afaceri cu viteza gândului“, Ed. Amalteea, 2000
 Sisteme informatice de previzionare a vânzărilor (SIPV)
Previziunile vânzărilor pot fi grupate în două categorii: previziuni pe termen scurt şi
previziuni pe termen mediu şi lung. Previziunile pe termen scurt se referă la perioade mai
mici de un an, iar cele pe termen mediu şi lung la perioade de peste un an.
Pe piaţa produselor software sunt numeroase programe care facilitează previzionarea
vânzărilor folosind diferite modele statistico-matematice cu ajutorul cărora se poate realiza
previziunea vânzărilor de mărfuri. Un exemplu de funcţie de previzionare este Linear Trend,
furnizat de Software Microsoft Excel. Managerii de marketing utilizează sisteme suport
pentru a colecta datele referitoare la vânzările curente şi a planifica campanii de promovare
pentru a obţine creşterea vânzărilor.

Sisteme informatice de cercetare a pieţei (SICP)

Cercetările de piaţă furnizează informaţii necesare managerilor pentru a lua cele mai
eficiente decizii în elaborarea mix-ului de marketing. Sisteme informatice de cercetare a pieţei
ajută managerii de marketing în realizarea diverselor proiecte de cercetări de marketing, la
care alături de specialiştii în domeniu se pot alătura angajaţi din alte departamente, formând o
echipă condusă de un manager de proiect.
Sistemele informatice de cercetare a pieţei colectează, analizează şi distribuie o
cantitate enormă de informaţii privitoare la o mare varietate de variabile ale pieţei care sunt
supuse permanentelor schimbări. Sistemele informatice de cercetare a pieţei includ informaţii
referitoare la clienţi, prospecţi, concurenţi. Tendinţele pieţei sunt de asemenea analizate.
Informaţiile pot fi achiziţionate fie din surse externe, fie prin tehnici de tele-marketing
moderne, utilizând tehnologia informaţiei.
Pachetele de programe (software) pentru analiza statistică a datelor ajută managerii în
utilizarea efectivă a datelor provenite din cercetări în elaborarea strategiilor de marketing.

Sisteme informatice de management al marketingului (SIMMK)

Managerii din sfera marketingului utilizează sistemele informatizate în dezvoltarea
planurilor de marketing previzionând vânzările aşteptate, profitul aşteptat şi obiectivele de
creştere. Aceste sisteme furnizează de asemenea feed-back şi reflectă diferenţele între
rezultatele obţinute şi obiectivele planificate. Sistemele suport ale deciziilor de marketing
(SSDM) şi sistemele expert şi cele bazate pe inteligenţă artificială sunt utilizate pentru a
investiga efectele planurilor de marketing alternative.
În „Managementul marketingului“, Ph. Kotler prezintă un astfel de model
informatizat, denumit Brandaid. Acesta este un model flexibil de marketing-mix axat pe
bunurile de larg consum, ale cărui elemente sunt: producătorul, concurenţii, detailiştii,
consumatorii şi mediul. Modelul are o serie de submodele referitoare la publicitate, stabilirea
preţului şi concurenţi.
Modelul alege din numeroase mix-uri de marketing pe cel care este mai avantajos din
toate punctele de vedere. Obţinerea rapidă a datelor de marketing ajută managerii de
marketing să răspundă rapid schimbărilor intervenite pe piaţă şi să dezvolte strategii de
marketing în timp util, înaintea concurenţilor.

5.1.2 Sisteme informatice de producţie (SIQ)

Sistemele informatice de producţie sunt un suport al operaţiunilor de producţie care
includ activităţile care se ocupă de planificarea, realizarea şi controlul proceselor de producţie.
Sistemele informatice de planificare, procesare a tranzacţiilor şi control a producţiei
sunt necesare tuturor firmelor care îşi planifică, monitorizează şi controlează achiziţiile de
materii prime, stocurile şi fluxurile de producţie.
 Sisteme informatice de producţie integrate (SIQI)
Sistemele informatice de producţie integrate evidenţiază că scopul utilizării
computerelor în automatizarea unei firme trebuie să aibă drept consecinţe:
€ integrarea proceselor de producţie utilizând computere şi reţele de telecomunicaţii;
€ simplificarea şi regândirea proceselor de producţie, a design-ului produselor şi
adaptarea acestora standardelor de calitate certificate;
€ automatizarea proceselor de producţie cu ajutorul roboţilor şi computerelor.
Calculatoarele ajută inginerii să proiecteze produse inovative, utilizând sisteme
informatice de proiectare, sau managerii departamentului de producţie să planifice procesele
de producţie. De asemenea, computerele joacă un rol foarte important în planificarea
necesarului de materii prime şi materiale şi corelarea acesteia cu programul de producţie.
Dintre beneficiile aduse de implementarea sistemele informatice de producţie integrate
putem menţiona:
€ creşterea eficienţei prin simplificarea sarcinilor de muncă şi automatizare, o
planificare mai bună a programului de producţie;
€ productivitate crescută, un mai bun control al calităţii, rezultat din observarea
conţinuă a producţiei şi a feed-back-ului primit şi controlul echipamentelor şi roboţilor
industriali;
€ reducerea investiţiilor pentru stocarea produselor finite, utilizarea tehnicilor „just-
în-time“ (JIT) (tehnică de control menită să diminueze volumul stocurilor pe care o firmă
trebuie să le păstreze);
€ îmbunătăţirea service-ului acordat clienţilor, reducerea drastică a situaţiilor de
rupturi de stoc şi producerea unor bunuri de calitate superioară care să corespundă cerinţelor
din ce în ce mai mari ale consumatorilor.

Sisteme informatice de control a proceselor de producţie (SICPQ)

Prin implementarea unor Sisteme informatice de control a proceselor de producţie se
asigură controlul proceselor de producţie. Astfel de sisteme informatizate sunt dotate cu
tehnologii care detectează anumite fenomene fizice, cum ar fi temperatura sau schimbările de
presiune care au loc în procesele de producţie.
Măsurarea acestor fenomene trebuie efectuată în mod conţinuu pentru a se elimina
riscurile producerii accidentelor de muncă. Informaţiile referitoare la aceste fenomene sunt
convertite în formă digitală şi transmise prin reţea la un server.
Pachetele soft de control al proceselor utilizează modele matematice pentru a analiza
datele furnizate de procesele de producţie şi a le compara cu standardele şi previziunile făcute.
Sistemele informatizate de control a proceselor transmit mesaje şi prezintă stadiul de realizare
a proceselor. Astfel, un operator poate lua măsurile adecvate pentru a controla procesul
analizat. De asemenea, sisteme informatice de control a proceselor de producţie pot furniza
rapoarte la cerere sau periodice referitoare la performanţele proceselor de producţie.

Sisteme informatice de control a utilajelor de producţie (SICUQ)

Aceste sisteme utilizează computerele pentru a controla acţiunile utilajelor şi
echipamentelor de producţie. Controlul utilajelor într-o întreprindere industrială este absolut
necesar. Soft-urile utilizate în acest sens transformă date de tip geometric din proiectările
efectuate de ingineri în coduri numerice ale comenzilor care acţionează utilajele şi le
controlează. Acest control al utilajelor poate implica utilizarea unor microcomputere,
denumite contoare logice programabile, care sunt conectate la utilajele industriale şi le
transmit sarcini de lucru.
Sisteme informatice de control a utilajelor de producţie înlocuiesc astfel munca unor
oameni care ar trebui să lucreze cu utilaje şi eficientizează operaţiunile de producţie. Riscul
producerii unor accidente de muncă prin manipularea utilajelor industriale este de asemenea
diminuat.
 Sisteme informatice de producţie conectate la roboţi industriali (SIQRI)
Un moment important în dezvoltarea producţiei asistate de calculator l-a constituit
apariţia maşinilor inteligente şi a roboţilor. Acestea îşi coordonează propriile activităţi cu
ajutorul unor microcomputere incorporate. Robotica are la bază tehnologia construirii şi
utilizării maşinilor industriale (roboţilor) cu ajutorul inteligenţei artificiale; aceşti roboţi sunt
dotaţi cu unele capabilităţi specific umane, controlate de computere (dexteritate, mişcare,
viziune, etc). Robotica constituie un domeniu de cercetare pentru inteligenţa artificială.
Roboţii industriali sunt utilizaţi pentru a reduce costurile de producţie şi a creşte
productivitatea muncii. Roboţii sunt coordonaţi de computere. Sarcinile sunt preluate de
senzori vizuali ori senzitivi, informaţiile fiind apoi procesate de microcomputerele incorporate
şi transpuse apoi în mişcări ale roboţilor.
Dezvoltarea acestui domeniu va conduce la apariţia unor roboţi mai inteligenţi, mai
flexibili şi dotaţi cu unele capabilităţi specific umane îmbunătăţite.

Sisteme informatice de proiectare asistată de calculator (SIPAC)

Inginerii utilizează Sisteme informatice de proiectare asistată de calculator (în engleză
CAD „Computer Aided Design“) pentru a simula şi a evalua diferite modele de produs
proiectate.
Produsele sunt proiectate în conformitate cu specificaţiile de produs realizate în
colaborare cu angajaţi ai departamentului de marketing şi ai departamentului de cercetare-
dezvoltare. În acest sens, se utilizează din ce în ce mai mult tehnici de tipul muncii în echipă,
care facilitează comunicarea şi colaborarea între membrii echipei de proiect.
Folosind sisteme CAD se realizaează corect şi eficient proiectarea proceselor de
producţie necesare realizării unui anumeprodus, astfel că schimbarea fluxurilor de producţie
se face rapid şi fără erori care să ducă la costuri inutile..
Pachetele de software de proiectare (ex: Autocad) şi staţiile de lucru coordonate de
ingineri reprezintă resursele hardware, software şi brainware care fac posibilă proiectarea
eficientă a produselor ce urmează a fi lansate pe piaţă. Inginerii utilizează computere
performante şi soft-uri de grafică avansate pentru a proiecta şi testa modele de produs.
Cu ajutorul programelor informatice se creează modele de produs. Rezultatele sunt
grafice 2D sau 3D care pot fi rotite pentru a putea fi vizualizate părţile componente ale
produsului proiectat. Unele componente pot fi mărite în ferestre deschise separat. Aceste
grafice pot fi convertite în modele matematice programate care constituie baza specificaţiilor
de produs.
În concluzie, firmele mileniului trei nu pot realiza produse competitive şi de calitate
superioară fără a-şi implementa sisteme informatice, suport al activităţii de producţie.

5.2 Integrarea sistemelor informatice prin ERP

Tradiţional, succesul unei companii este indicat de gradul în care aceasta creşte prin
fuziune şi achiziţii, precum şi prin pozitia puternică ce o ocupă la masa negocierilor. Astăzi,
succesul unei companii este adus de eficienţa economică a acesteia, iar indicatorii care
ilustrază aceast succes se referă în principal la chestiui legate de piaţă şi de tehnologie. Figura
prezentată mai jos înfăţişează punctul de tranziţie de la piaţa axată pe tehnologie către cea
axată pe produs şi client.
În cartea sa ‘The Innovator’s Dilemma’ (Dilema inovatorului), CM Christensen
explică că noile tehnologii îşi au punctul de pornire în partea stanga jos, oferind mai puţin
decât ceea ce cer clienţii. Drept rezultat, clienţii vor o tehnologie mai bună cu mai multe
aspecte, indiferent de cost. Tranziţia apare în momentul în care tehnologia este destul de bună
pentru satisfacerea nevoilor de bază. Un alt grup de clienţi au apărut pe piaţa cu o categorie
nouă de cerinţe, care vor mai multe facilităţi, eficienţă, stabilitate şi preţuri mici.
Performanţa
 Nivelul de
performanţă
cerut de Calitate in exces.
utilizatorii Nevoi Majoritatea clientilor sunt
medii neindeplinite neinteresati in aceasta regiune

Tehnologia este indeajuns de buna

Experienta utilizatorilor dominanta

Timp

Tehnologie înaltă
Consumatorii doresc Mărfuri de consum
mai multă tehnologie, Consumatorii doresc comoditate,
performanţă mai mare incredere, costuri mici

Punctul de tranziţie
unde tehnologia asigură
nevoile de bază

Fig. 5-3 Niveluri de performanţă evaluate în raport cu cerinţele consumatorilor

Cum va afecta acest curent următoarele achiziţii ERP? Produsele software vor fi
privite dintr-o perspectiva complet nouă. Primele implementări ERP ale unei întreprinderi s-
au bazat pe beneficii clare concretizate în reducerea perioadelor de timp, a inventarului,
utilizarea mijloacelor de care dispun şi îmbunătăţirea serviciilor acordate clienţilor. Procesul
de selecţie era axat pe identificarea aspectelor unice ale unei companii prin definirea
proceselor şi a cerinţelor funcţionale ale tranzacţiilor comerciale. Factorii principali în
selectarea sistemului au constat în tehnologia de bază (sistemele de operare şi bazele de date)
precum şi pe funcţionalitate.
Convergenţa tehnologiei a rupt legatura dintre aplicarea softului şi tehnologia care îl
pune în mişcare. Tendinţă prezentă din domeniul industrial oferă arhitectura orientată pe
servicii (Service Oriented Architecture - SOA) ca fiind salvarea acestei mişcări către
societatea axată pe multitehnologie. Totuşi, s-ar părea că în zilele noastre nimeni nu mai este
interesat asupra caracteristicilor noi ale produselor.

5.2.1 În ce mod este util un sistem ERP

Eficienţa firmei în economia globală este determinată de modul cum decuge
managementul riscului şi cum se lasează următorul produs pe piaţă. Beneficiile oferite de
produse provenind de la diverşi producători sunt atât de similare încât doar perioada mai
lungă de viaţă a produsului reprezintă o diferenţiere reală. Performanţa de longevitate a
produsului implică cele mai mari costuri ale unei întreprinderi. Acesta reprezintă costul
schimbării sistemelor, iar în noul sistem, tehnologia nu conteaza, dar stabilitatea da.
Fiecare companie trebuie să se gândească la o schimbare de sistem pentru a preveni
momentul în care vor ajunge într-o situaţie în care nu vor mai prezenta un pericol pentru
celelalte firme. Exemplul este similar cu cel al unei masini vechi. La un moment dat este mult
mai profitabil să cumperi o maşină noua decât să investeşti într-o maşină veche care necesită
reparaţii.
Provocarea majoră astăzi este instruirea proprie în domeniul selectării categoriei de
produse de care compania are nevoie. A compara două produse care nu fac parte din aceeasi
categorie, înseamnă a compara motocicletă cu un automobil - singura asemănare fiind aceea
ca ele servesc scopului de transport. În momentul în care testezi o maşină, important este
sentimentul pe care îl ai când te afli la volan, fără a mai ţine cont de componente sau a face
inventarul pieselor.
Factorii de eficienţă sunt de fapt trăsături de utilitate ce îmbunătăţesc experienţa
utilizatorilor. Aşa cum se va prezenta mai jos la filosofia Lean, “mai puţin” înseamnă de fapt
“mai mult” – în termeni de calitate şi durabilitate. Funcţionalitatea suplimentară pe care
furnizorii de software o adaugă sistemelor pentru a servi mai multor pieţe şi domenii, a creat
complexitate şi lipsă de eficienţă în viaţa de zi cu zi a utilizatorului. Clasificarea scenariilor
folosite în ziua de azi se face pe baza următorilor factori:
 Eficacitate – pentru a se acorda prioritate muncii pe baza obiectivelor organizaţiei
 Informaţie –informaţile corespunzătoare şi în formatul corespunzător se obţin uşor,
astfel că se poate întreprinde acţiunea adecvată.
 Eficienţă – se ştie exact ce trebuie făcut pentru a duce treaba la bun sfârşit.
 Feedback – se asigură reacţie din partea utilizatorului către sistem.
Cel mai mare factor de risc este reprezentat de viabilitatea produsului datorită costului
mare implicat de schimbarea sistemelor şi de tendinţa industriei de a urmări consolidarea
afacerii. Alegând un produs stabil din categoria respectivă sau segmentul respectiv de piaţă
este o acţiune critică pentru longevitatea investiţiei. Acest lucru nu înseamnă că alegerile
făcute trebuie să se limiteze doar la SAP, Oracle, sau alt actor important din acest domeniu.
Elementele cheie ale unui produs sau ale unei activităţi comerciale care înregistrează succes
pe viitoarea piaţa ERP, sunt:
● Un produs complet – o tehnologie şi un grad de funcţionalitate cât mai bun pentru
simplificarea finalizării a lucrării;
● Calitate – Produsul şi standardele de calitate ale proceselor stabilesc la rândul lor un
nivel mai înalt de încredere.
● Stabilitate - Industria încearcă să creeze un mediu de dezvoltare, colaborare şi
sprijinire a comunităţii.

5.2.2 Consolidarea afacerii prin ERP

Sunt 5 motive majore pentru care companiile recurg la sisteme ERPşi care duc la
consolidarea afacerii.
Informaţii financiare complete. Deoarece managerii încearcă să înţeleagă pe de-a
întreagul performanţa companiei, vor descoperi diferite versiuni despre acelaşi adevăr.
Finanţele au propriul set de venituri, vânzările au altă versiune şi diferitele module ale afacerii
pot avea propriile versiuni asupra cotei cu care au contribuit la venituri. ERP creează o
versiune unică a adevărului, care nu poate fi pusa sub semnul întrebării deoarece toţi folosesc
acelaşi sistem.
Informaţii complete asupra comenzii clientului. Sistemele ERP pot deveni locul
unde se află comanda clientului din momentul în care reprezentantul serviciului cu clienţii
primeşte comanda, până la încărcarea mărfii pe mijlocul de transport iar serviciul financiar
trimit o factură. Având toate aceste informaţii pe un singur sistem software – şi nu împărţite
între multe sisteme diferite care nu pot comunica unul cu celalalt, companiile pot urmări
comenzile mult mai uşor şi pot coordona fabricaţia, inventarierea şi expedierea între diferitele
locaţii, în acelaşi timp.
Standardizarea şi urgentarea proceselor de fabricaţie. Companiile producătoare –
în special cele cu un apetit mare pentru fuziuni şi achiziţii – adesea, descoperă că numeroase
unităţi de afaceri dintr-o companie contribuie la realizarea aceluiaşi buget largit folosind
diferite metode şi diferite sisteme de calcul. Sistemele ERP vin cu metode standard pentru
automatizarea unor paşi din procesul de producţie. Standardizând aceste procese şi folosind
un sistem de calcul unic şi integrat, se poate economisi timp, creşte productivitatea şi se reduc
cheltuielile.
Reducerea inventarului. ERP ajută fluxul de producţie să decurgă mai fluent şi
îmbunataţeşte vizibilitatea procesului de realizare a comenzilor în cadrul companiei. Acesta
poate conduce la reducerea inventarului de materiale folosite pentru a realiza produsele şi
poate ajută operatorii să planifice mai bine livrările către clienţi, să reducă inventarul de
bunuri finite de la depozit şi docuri. Pentru ca, într-adevăr, să se îmbunătăţească fluxul de
aprovizionare, este nevoie de un program pentru lanţul de aprovizionare (SCM supplz chain
management) la care ERP poate fi de ajutor.
Standardizarea informaţiilor privind resursele umane. În special în companiile cu
unităţi multiple de afaceri, este posibil ca resursele umane să nu aibă o metodă simplă şi
unitară pentru a găsi angajaţii şi a comunica cu ei despre iniţiative şi servicii. ERP poate
rezolva acest lucru, pentru că pachetele ERP nu sunt decât reprezentări generice ale
modalităţilor în care o companie tipică face afaceri. În timp ce majoritatea pachetelor sunt
atotcuprinzatoare în mod exhaustiv, fiecare tip de industrie are specificul său care o face
unică. Majoritatea sistemelor ERP au fost realizate pentru a fi folosite de către companii de
producţie, care fac bunuri ce pot fi numărate, ceea ce lasă pe dinafară pe toţi producătorii de
petrol, benzina etc. şi companii cu utilităţi care masoară producţia în flux (deci altfel decăt
piese separate). Fiecare din aceste industrii discută cu vânzătorii de ERP pentru a modifica
esenţa programelor ERP conform cu nevoile lor.

5.2.3 Alegerea ERP

Un sistem ERP reprezintă o investiţie majoră. Este o unealtă costisitoare având costuri
iniţiale mari şi costuri de folosire mici. Cu cât este utilizată mai bine, cu atât îşi va returna mai
bine investiţia. Din păcate, majoritatea companiilor nu folosesc toate resursele sistemelor ERP
pe care le au. Ele sunt pline de date şi goale ca informaţie. Un sistem ERP necesită o
implicare pe termen lung a resurselor necesare, nu doar costuri de început pentru care se alocă
buget iniţial, iar rezultatele vor aparea în timp. Dar experienţa a arătat că investiţia se va
amortiza. Producţia în masă a lăsat loc pentru personalizarea în masă. Pieţele locale sunt
servite de economia globală, iar noile sisteme, deşi nu este o soluţie rapidă, totuşi reprezintă
răspunsul pentru oportunităţile pe termen lung într-o lume a competiţiilor în creştere.

5.3 Sisteme de execuţie şi fabricare

Sistemele software de execuţie au diferite scopuri, forme şi înţelesuri pentru fiecare
caz în parte. Un sistem de execuţie folosit într-o locaţie de fabricare a echipamentelor
electronice este similar doar în ceea ce priveşte conceptul cu cel folosit într-o fabrică din
industria alimentară sau la la un producător de produse chimice sau farmaceutice.
Un sistem de execuţie şi fabricare este un set de programe şi sisteme care contribuie la
controlul activităţii din uzină, inclusiv la ciclul de viaţă a produselor şi a calculatoarelor de
proces, pentru controlul direct al echipamentului de producţie şi fabricaţie. Setul de programe
se constiutie în sisteme de prelucrare a informaţiei care colectează informaţii referitoare la
funcţionarea echipamentelor şi generează rapoarte.
O alta definiţie este dată de Dicţionarul de Informatică Gartner, în care sistemele de
execuţie şi fabricare sunt definite ca „sisteme computerizate care dau o formă metodelor de
producţie şi procedurilor din cadrul procesului de fabricare, asigurând instrumente on-line
necesare pentru executarea comenzilor de lucru. Aceste definiţii lungi arată că este dificil să
simplifici o gama întreagă de aplicaţii folosite la nivelul uzinei. De la sistemele electronice de
conducere a producţiei la achiziţia de date referitoare la activitatea din uzină, funcţiile
sistemelor de execuţie şi fabricare conduc operaţiunile de la intrarea în producţie până la
livrarea produsului finit.
Deşi există anumite diferenţe între sistemele de execuţie şi fabricare, se poate
menţiona şi existenţa unor elemente comune, şi anume a celor care fac referire la scopul
functional, cum ar fi managementul calităţii, managementul documentelor, etc. Componentele
acestor sisteme pot fi împărţite în două categorii:
■ funcţiile cheie (principale), asociate direct cu conducerea proceselor de producţie;
■ funcţiile de sprijin, care sunt periferice managementului proceselor centrale şi sunt
percepute doar ca opţiuni.
 Funcţiile cheie sunt îndeplinite prin intermediul unor module ca managementul
comenzilor (care poate cumula şi conduce comenzile de lucru primite conform sistemului de
planificare) sau prin interfate ale sistemelor de planificare (care definesc şi indică exact modul
în care se realizează schimbul de informaţii. Astfel, modulul de „Management al centrelor de
lucru” poate implementa un plan de producţie, fiind de asemenea direct răspunzator de
configurarea logică a fiecarui punct de lucru. Modulul „Managementul şi monitorizarea
inventarului” dezvoltă, stochează şi întreţine detaliile pe loturi şi pe unitate. Modulul
„Managementul mişcării materialelor” planifică logic şi administreaza mişcarea materialelor,
operaţiune făcuta fie manual fie automat.
În continuare se prezintă o listă a punctelor cheie care stau la baza acestor sisteme şi
care demonstrează de asemenea şi suprapunerea ce poate aparea între aplicaţiile întreprinderii:
► Sistem de management al întreţinerii computerizate (Computer Management
Mainteinance System - CMMS) se ocupă de întreţinerea echipamentului de producţie şi de
problemele apărute în reparaţii, inclusiv activităţile de mentenanţă predictivă şi preventivă.
► Sistemele referitoare la timp şi prezenţă a personalului, care includ de obicei
informaţii legate de forţa de muncă şi de angajaţi.
► Sistemele de management al depozitelor (Warehouse Management Systems -
WMS) sunt folosite în principal pentru monitorizarea şi controlarea activităţilor legate de
inventar.
► Controlul statistic al proceselor (Statistic Process Control - SPC) reprezintă un
control al calităţii care se axează mai mult pe monitorizarea conţinuă decât pe inspecţia
produselor finite.
► Sistemele de management al calităţii (Quality Management Systems - QMS) se pot
afla în legatura cu standardele de calitate SPC sau ISO 9000, fiind componente frecvente ale
proceselor de producţie.
► Managementul documentelor se ocupă de datele nestructurate care pot fi folosite
pentru crearea desenelor tehnice sau informaţilor de proces.
Toate sistemele de automatizare a uzinelor au dezvoltat o forma de software care să
vină în sprijinul integrării. Sistemele tradiţionale de planificare a resurselor întreprinderii nu
pot face faţă într-un mediu în care colectarea datelor se face rapid şi într-un volum mare, nu
pot realiza coordonarea echipamentului automatizat al uzinei. Companiile care intră în această
categorie pot fi candidate pentru Sistemele de execuţie şi fabricare, din moment ce acestea
vor furniza utilizatorilor o vizibilitate mai bună şi un acces mai rapid la operaţiunile uzinei.

5.4 De la ERP la Lean Manufacturing

Lean reprezintă o adaptare la curentul lansat de către Toyota Production Systems.
Văzută de către unii ca model al eficienţei şi productivităţii, Toyota a înregistrat un succes
remarcabil concentrându-se doar asupra unui domeniu. ERP (Planificarea Resurselor
Întreprinderii) este de fapt un concept simplu dar dificil de pus în practică datorită
schimbărilor implicate, şi anume schimbarea percepţiei.
Pentru a intra în rândul companiilor care au implementat această modalitate de lucru, o
companie trebuie să analizeze în detaliu procesele şi modalităţile de lucru, să identifice acele
lucruri prin care clientului i se acordă o anumită importanţă şi să le elimine pe cele care oferă
o imagine negativă asupra clienţilor. Scopul principal al filosofiei Lean este încercarea
conţinuă de a elimina pierderile. Filosofia Lean se poate extinde şi peste domeniul uzinei în
sine. Activităţile indirecte cum ar fi logistica, administrativul, proiectarea şi depozitarea,
precum şi unele activităţi neproductive, pot beneficia într-o mai mare măsură de gândirea
Lean.
Eliminarea pierderilor şi urmărirea unei îmbunătăţiri conţinue reprezintă obiectivele
cheie ale gândirii Lean. Primul pas pe care îl face o companie este acela de a-şi lua un
angajament ferm. Proiectele Lean reuşesc adesea fără a beneficia de un angajament la nivel
înalt. Următorul pas constă în identificarea proceselor şi componentelor valoare şi non-
valoare, concentrându-se mai mult pe prima categorie de componente şi eliminând a doua
categorie de componente.
Lean nu reprezintă un aranjament care se face peste noapte. Este un proces conţinuu.
De altfel, acest lucru rezultă şi din definiţia dată acestei metode. Lean reprezintă un proces de
îmbunătăţire a evoluţiei afacerilor, prin punerea accentului asupra calităţii, costului, livrării
produsului sau serviciului, precum şi a oamenilor. Elimină pierderile şi face posibil procesul
de îmbunătăţire conţinuă.
O altă definiţie denumeşte Lean ca scopul final al filosofiei de fabricare, ce reduce
perioada existentă dintre plasarea comenzii şi expedierea produsului către client, prin
eliminarea pierderilor. Lean manufacturing reprezintă o iniţiativă luată în domeniul afacerilor
de a reduce pierderile în procesul de fabricare a produselor.
Lean Manufacturing reprezintă o filosofie de producţie ce determină reducerea
duratei calculate de la comanda dată de client până la expedierea produsului, prin eliminarea
pierderilor. Abordarea Lean reprezintă un proces de gândire în cinci paşi, propus de James
Womack şi Dean Jones în lucrarea lor Lean Thinking pentru ghidarea managerilor în demersul
lor de introducere a principiilor Lean în producţie.
Implementarea cu succes a filosofiei Lean a reprezentat şi reprezintă ţinta celor mai
multe companii în ultimii ani. Care este motivul pentru care metoda Lean este aşa populară?
Lean asigură ceea ce multe companii solicită în ziua de azi, când competiţia pe piata este în
continuă creştere. În ziua de azi cerintele cheie ale pietei sunt imbunatirea calităţii, reducerea
costului, creşterea profitului, îmbunătăţirea productivităţii şi asigurarea de servicii mai bune
clienţilor.
Trebuie evidenţiat şi modul în care ERP contribuie la implementarea Lean. Odată cu
dezvoltarea conceptelor Lean, susţinătorii Lean au recunoscut că ERP şi Lean pot conlucra
bine împreună, susţinandu-şi una alteia obiectivele (vezi mai jos).
Lean insistă pe anumite puncte cheie şi idei principale care stau la baza implementării
Lean. Cele cinci principii Lean referitoare la definirea valorii şi specificatiilor, harta fluxului
de valoare, fluxul neîntrerupt, atragerea clienţilor şi atingerea perfecţiunii sunt sprijinite de
către controlul informaţiei şi metodele managementului care au drept rezultat final şi
urmăresc livrarea către client.

5.4.1 Concepte ale Producticii line (Lean Manufacturing)

Companii renumite ca Toyota, Dell Computer, şi Pratt & Whitney au reusit să reducă
drastic perioada de livrare, precum şi nivelul inventarului, îmbunătăţind modalitatea de a
răspunde cerinţelor clientului şi circuitului capitalului. După cum a fost deja demonstrat în
mii de organizaţii, în diferite ramuri ale industriei, Lean Enterprise reprezintă unul dintre cele
mai promovate şi mai competitive modele de afaceri din ziua de azi. Studiile publicate pe
acest subiect furnizeaza exemple despre cum au fost reduse pierderile şi costurile asociate
acestora.
Aceste concepte Lean nu sunt foarte complexe, putând fi uşor asimilate de către
oameni cu diferite nivele de cultura. Mijloacele Lean conţin cei 5S, harta fluxului de valoare
(Value Stream Mapping - VSM), precum şi alte concepte şi alţi termeni cum ar fi Kaizens şi
kanbans. Întrebarea principală este de ce există aşa multe firme care nu reuşesc să
implementeze filosofia Lean. Dacă rezultatele sunt aşa de evidente şi există atâtea povestiri de
succes, de ce există atât de multe firme care întâmpină probleme?
Veriga lipsă în procesul de implementare Lean este legatura dintre scopurile filosofiei
şi proiectele care trebuie implementate cu succes pentru a se ajunge la rezultatele dorite.
Companiile care doresc să implementeze filosofia Lean trebuie să facă o planificare
corespunzătoare şi detaliată a acţiunilor ce se doresc a fi întreprinse. Una dintre deficienţe este
că, de cele mai multe ori, abordarea de început este greşită şi nu se bazează pe nici o
planificare strategică. Dacă primul efort de a implementa filosofia nu înregistrează succes,
există şansa ca nici cel de al doilea să nu aibă un rezultat pozitiv. În cele mai multe cazuri,
implementarea Lean începe cu o abordare mai mult tactică decât strategică. Acesta este un
factor cheie în ceea ce priveşte procentul eşecurilor înregistrate în implementarea Lean. Cele
mai multe dintre abordările Lean sunt în mare parte concentrate pe procesul de fabricaţie şi
pe procese specifice operaţionale. Multe organizaţii se bazează pe cuvântul cheie „cum” şi cu
aplicarea unor tehnici specifice (cum ar fi cei 5S) sau poate „cu ce” (identificarea atelierelor
de lucru kaizen). Alţii se pot concentra pe cuvântul „cine” şi să asigure pregătirea indivizilor
sau a echipelor selectate, precum şi pe cuvântul „unde”, începând construirea fluxului de
valoare.

5.4.2 Cei 5S
Multe dintre companii încep implementarea tehnicii denumite Cei 5S. Cifra 5 şi litera
S provin de la cele cinci cuvinte de origine japoneză: seiri, seiton, seiso, seiketsu şi shitsuke.
Cuvintele echivalente se traduc prin sortare, stabilizare, strălucire, standardizare şi sprijin. În
cazul acesta se pune accentul pe îmbunătăţirea eficienţei şi a siguranţei. Rezultatele acestei
metode sunt imediate şi sunt vizibile, iar atelierele de lucru sunt într-adevăr mai bine
organizate. Uneltele şi materialele sunt depozitate în locaţii bine definite, fiind mai uşor de
găsit şi mai accesibile pentru uz imediat. Supraveghetorii descoperă că prin folosirea acestei
metode este mult mai simplu să identifici problemele cum ar fi ineficienţa, inventarul crescut
în exces sau echipamentele rătăcite prin diverse locaţii.

5.4.3 Kanban
În limba japoneză, cuvântul Kanban înseamnă dispozitiv de semnalizare. În limbajul
Lean, sensul se reduce la producerea semnalului şi mişcarea produsului. Kanban-ul poate fi
un semnal electronic, un card sau o zonă predefinită de menţinere a inventarului. Kanban-ul
este un dispozitiv de semnalizare care oferă autorizare şi instrucţiuni pentru producerea şi/sau
transportul pieselor într-un sistem de tip pull. În lumea ideala Kanban, produsul este împins
către client, prin uzină. Kanban-ul poate fi considerat un compromis acceptabil: pemiterea
mutării de loturi mici, controlabile într-un mediu de tip pull. Folosirea Kanban-ului a condus
la reducerea drastică a inventarului. Folosirea Kanban-ului fără alte îmbunătăţiri coordonate
poate conduce la degradarea utilizarii echipamentului, chiar şi creşterea numărului de
transporturi întârziate.

5.4.4 Kaizens
Cunoscute şi sub denumirea de grupuri de lucru kaizen, acesta poate fi punctul de
început comun pentru implementarea filosofiei Lean în companiile producătoare din Statele
Unite ale Americii. Kaizen este un cuvânt japonez care tradus în limba engleza ar însemna
„continuous improvement”, iar în limba română îmbunătăţire continuă. Această abordare
reprezintă o modalitate de lucru în cadrul căreia echipa identifică şi implementează o
îmbunătăţire în cadrul unui proces. Aceasta pare o idee foarte bună, care poate genera
beneficii imediate şi măsurabile.

5.4.5 Harta fluxului de valoare (VSM)

Trebuie menţionat faptul ca harta fluxului de valoare este o unealtă adaugată recent la
gama de mijloace Lean. Harta fluxului de valoare reprezintă toate activităţile şi evenimentele
(cu valoare şi fără valoare) prin care trece orice produs în drumul sau de la producător la
client. Într-o unitate de fabricare, lucurul acesta înseamnă că aceste activităţi includ expediere,
aşteptare (pe inventar, în aşteptare în ciclul de producţie), împachetare, inspecţie, reprelucrare
şi prelucrare manuală şi automată. VSM reprezintă circuitul produsului, precum şi al
informaţiei. Una dintre problemele ridicate de către acest proces constă în faptul ca implica
indivizi asupra cărora va avea impact mult mai târziu. O altă slăbiciune constă în
imposibilitatea de a capta natura dinamică a procesului.
Multe dintre companiile care încearcă să implementeze filosofia Lean, încep cu o
instruire privind abordarea specifică a acestui proces. Instruirea poate include nu numai cei
5S, Kaizens, Kanban şi Harta fluxului de valoare. Pregătirea este strategia preferată a
consultanţilor şi asigură în felul acesta posibilitatea unei revizuiri zilnice, fără a implica vreun
risc. Dacă pregătirea nu este coordonată corespunzător şi cu grijă, există riscul de a acumula
cunoştinţe care nu pot fi aplicate unui proiect cu efect imediat. Dacă pregătirea nu este
efectuată pe un grup care este clar împuternicit să emită soluţii pentru acel domeniu specific,
pregătirea nu va avea ca rezultat efecte pozitive asupra afacerii.

5.5 Implementarea Lean

Există mai multe modalităţi de abordare a implementării Lean:
 Organizaţiile pot alege să folosească la început o tehnică de abordare Lean,
aplicând metoda 5S la o secţiune mai vastă a afacerilor sau identificând o zonă a
problemelor specifice pentru un eveniment kaizen ca o încercare de a
implementa Lean de unul singur.
 Instituţiile care oferă pregătire şi autorizare în domeniul Lean, susţin că
organizaţiile trebuie să înveţe totul despre Lean înainte de a începe, pregătirea
(trainingul) fiind cea mai bună modalitate în acest sens.
 Consultanţii din diferite domenii sfătuiesc companiile să înceapă cu crearea unei
situaţii prezente a fluxului de valoare pe o anumită gamă de produse.
Fiecare dintre abordările menţionate mai sus este eficientă într-o anumită măsură.
Conform studiilor efectuate, mai puţin de 20% dintre iniţiativele Lean au înregistrat succes în
implementare, atingând scopul dorit. Deşi este confirmată existenţa a multor experţi Lean şi a
multor cărţi şi studii efectuate în acest domeniu, multe companii nu reuşesc să implementeze
cu succes această unealtă a managementului.

Factori de KPI Raportarea

Influenţa Influenţa Influenţe de
control factorilor de
strategică externă reglementare
şi influenţă influenţa

Sistemul de valori al activităţilor comerciale

Zonele de supraveghere a proceselor de management
Conducere Planificare Monitorizare Supraveghere
performantă financiară

Domeniile de proces axate pe client

Marketing Vânzări Livrare Servicii

Domeniile de proces axate pe produs

R&D Management Montare/ Management
furnizor Producţie inventar

Domeniile de intervenţie
Infrastructura Resurse Sprijin Tehnologie &
umane financiar Reţele

Elemente de Opţiuni mijloace Resurse Finanţe/ Utilităţi

sprijin fixe Capital

Fig. 5-4 Diagrama sistemului de valori al activităţilor comerciale

63
 Unul dintre factorii care conduc la eşecul implementării este lipsa de date de intrare,
rezultând o rezistenţă la schimbare. Oamenii pot reprezenta o problemă sau chiar soluţia în
funcţie de gradul de implicare la demararea şi la planificarea unui proiect.
Diagrama sistemului de valori al activităţilor comerciale (Fig. 5-4) prezintă întreaga
activitate comercială într-un singur model, aplicându-se tuturor organizaţiilor. Aceasta oferă
un ghid de îndrumare a organizaţiilor pentru vizualizarea şi confirmarea traiectoriei valorii
prin activitatea comercială pentru produse, servicii şi informaţii.
Instrumente ca Diagrama sistemului de valori al activităţilor comerciale ne ajută să ne
cream o privire de ansamblu asupra valorii, inregistrand succes doar dacă face parte dintr-o
strategie bine pusă la punct în momentul începerii implementării Lean. Conform unui studiu
recent făcut de Aberdeen Group, s-a demonstrat ca 66% din companiile cele mai renumite au
crezut în faptul că reducerea costurilor în procesul de fabricaţie şi distribuţie sunt elemente
cheie în implementarea Lean. Celelalte acţiuni sunt operaţionale, culturale şi concentrate pe
calitate. Cele şapte principii ale modalităţii de rezolvare a problemelor în mod creativ sunt
urmeaza:
● Unicitate. Din moment ce există o slabă posibilitate de a găsi două acţiuni identice,
trebuie să adoptăm o abordare unică în scopul rezolvării problemelor.
● Scop. Nici o situaţie sau problemă nu este aşa cum a fost descrisă iniţial. Dacă
problemele sunt privite dintr-o perspectivă mai largă, atunci se vor găsi mai multe soluţii.
● Sisteme. Toate organizaţiile reprezintă de fapt nişte sisteme bazate pe mai multe
aspecte ce sunt în strânsa legatură.
● Colectarea limitata a informaţilor. Modalitatea tradiţională de a rezolva
problemele este de a aduna cât mai multe date, de a studia informaţiile şi de a face
recomandări.
● Angajatul proiectant. Acest principiu îi determină pe oameni să muncească punând
accentul pe schimbare ca impuls provenit dinspre interior (de la ei înşişi) mai mult decât
dinspre exterior (de la alţii). Oamenii sunt reticenţi la schimbare mai ales dacă u sunt implicaţi
personal în implementarea schimbării.
Dacă se începe implementarea Lean de la un nivel tactic, după cum procedează mare
parte din companii, se ajunge la rezultate limitate, obţinute pe termen scurt. Dacă se privesc
afacerile ca un sistem de valori pentru clienţi, companiile îşi pot orienta priorităţile strategice
Lean către ţinte orientate spre dezvoltare continuă şi nu către reducerea costurilor.
Revoluţia Lean nu este complexă. Pentru a reuşi în implementarea Lean, trebuie să se
adopte o atitudine îndreptată către o continuă dezvoltare şi să se recunoască faptul că
reducerea costurilor este mai mult un efect auxiliar decât o strategie cheie pentru Lean.

5.6 Sistemele ERP sprijină implementarea conceptelor Lean

Planificarea resurselor întreprinderii reprezintă un termen rezultat din planificarea
resurselor producţiei care urmăreşte de fapt planificarea materialelor necesare. Sistemele ERP
se ocupă în principal de fabricare, logistică, distribuţie, inventar, expediere, facturare şi
contabilitate în cadrul unei companii.
ERP poate ajută la controlarea mai multor activităţi, cum ar fi vânzarile, livrarea,
facturarea, producţia, managementul inventarului, managementul calităţii şi managementul
resurselor umane.
Vasta definiţie data de Lean noţiunii de pierdere – orice lucru sau activitate care nu îşi
aduce contribuţia la valoare - oferă sistemelor întreprinderilor mai multe oportunităţi de a
contribui la urmărirea scopului stabilit. Este foarte greu să iei măsuri sau să îmbunătăţeşti ceva
asupra căruia nu ai cunoştinţe.
Sistemele ERP reprezintă sistemul nervos central al organizaţiilor. Aceste sisteme
asigură definiţiile, datele necesare şi înregistrările activitatăţilor organizaţiilor, asigurând în
acelaşi timp măsurarea sistemelor pentru a localiza oportunităţile.
 Cele mai multe sisteme ERP asigură de asemenea posibilitatea de a modela şi testa
alternativele – aşa numitele scenarii „ce ar fi dacă”? - care ne ajută să ne concentrăm
eforturile asupra activităţilor cu perioada cea mai mare de recuperare a activităţilor. Procesele
şi procedurile se regăsesc în sistemele ERP. Documentaţia existentă permite organizaţiilor
să perceapă clar ceea ce se întâmplă în ziua de azi şi să asigure mecanismele necesare pentru
implementarea procedurilor noi şi eficiente.
Modul logic de organizare şi optimizare a subsistemelor poate ajuta la reducerea
inventarului, poate îmbunătăţi şi face mai eficient transportul şi facilităţile de depozitare,
ajustarea corespunzatoare a activităţilor în timp, pentru evitarea pierderilor şi reducerea
timpului neproductiv.
Sistemele întreprinderii reprezintă de asemenea legăturile locale stabilite cu partenerii,
permiţând astfel eliminarea pierderilor şi a întârzierilor în lanţul aprovizionării. Facilităţile,
clienţii şi distribuitorii pot contribui la dezvoltarea previziunilor şi la coordonarea activităţilor
pentru asigurarea unor servicii îmbunătăţite pe parcursul colaborării. Prin integrarea optimă în
sistemele furnizorilor, se pot evita întârzierile şi confuziile, toate contribuind la reducerea
pirderilor în întregul lanţ al aprovizionării.
Logica optimizată a distribuţiei şi transportului pot ajuta în a face disponibile toate
facilităţile prezente şi în dezvoltarea planurilor îmbunătăţite de reconfigurare a acestor
facilităţi. Planificarea lanţului de aprovizionare şi sistemele de management pot asigura
existenţa unui inventar corect, menţinut la locul corespunzător şi la momentul potrivit.
Sistemele de management al transportului selectează modalităţile cele mai eficiente din punct
de vedere al costului, urmărind obiectivele livrării.
Privite în ansamblu, sistemele de planificare a resurselor întreprinderii (ERP),
managementul relaţiilor cu clienţii (Customer Relationship Management - CRM),
managementul relaţiilor cu furnizorii (Supplier Relationship Management - SRM),
managementul lanţului de aprovizionare (Supplier Chain Management - SCM), asigură surse
de informaţii utile pentru organizarea strategiilor Lean, mecanisme pentru implementarea
unor procese noi, mult mai eficiente, precum şi, pe ansamblu, un sistem de evaluare care
poate indica progresul înregistrat.
Lean nu este un proiect pus în practică o singură dată, şi nici nu poate fi considerat
vreodată complet. La implementarea proiectului Lean este normal să se stabilească ţintele
iniţiale. Odată atinse, aceste scopuri nu trebuie considerate ca fiind finale, iar procesul trebuie
privit ca fiind unul conţinuu. Întotdeauna mai există ceva în plus de făcut, sunt necesare mai
multe îmbunătăţiri pentru a atinge o eficienţă sporită şi pentru a elimina pierderile.
Sistemele întreprinderii conţin definirea şi documentarea necesară proceselor şi
procedurilor. În momentul în care au fost aduse îmbunătăţiri şi schimbările au fost deja
implementate în cursul normal al sistemului, aceste definiţii ajută la întărirea şi perpetuarea
îmbunătăţirilor. După atingerea obiectivelor iniţiale, sistemele captează încă o dată datele de
intrare necesare pentru runda următoare de îmbunătăţiri. Definiţiile din sistem identifică
activităţile curente şi oferă posibilitatea de a începe identificarea şi eliminarea pierderilor.
Cele mai multe sisteme ale întreprinderilor din ziua de azi oferă beneficiile Inteligenţei
Afacerilor (BI), acestea putând fi folosite drept standard sau factor opţional. Inteligenţa
Afacerilor, denumită şi Managementul Performanţei Afacerilor (Business Performance
Management - BPM) sau Managementul Performanţei Operaţiunilor (Operations
Performance Management - OPM) adună informaţiile de la nivelul întregii întreprinderi (de la
ERP, CRM, Sistemele de achizitii, sistemele lanţului de aprovizionare, etc.) într-un punct
comun analitic central.
Instrumentele din cadrul aplicaţiilor Inteligenţei Afacerilor monitorizează indicatorii
cheie şi alertează imediat managementul în cazul unor schimbări (bune sau rele). În felul
acesta problemele apărute sunt aduse la cunoştinţa managementului, acestea putând fi
abordate încă din faza incipientă, înainte de a se amplifica pierderile. Aceste avertizări pot
evidenţia şi care sunt zonele care necesită îmbunătăţiri.
Mai mult, Inteligenţa Afacerilor asigură instrumente de analiză interactive ce pot fi
folosite pentru o analiză mai aprofundată a datelor şi a posibilităţilor de eliminare a
pierderilor. Inteligenţa Afacerilor asigură informaţii grafice, inclusiv combinaţii ale datelor
care nu sunt disponibile în aplicaţiile individuale. Cateodată, aceasta privire de ansamblu
poate asigura o bună cunoaştere a modului în care diferite porţiuni ale afacerilor unei firme
interacţioneaza şi se influenţeaza una pe cealaltă. O îmbunătăţire adusă în cadrul unui
departament atrage după sine îmbunătăţiri suplimentare în altă zonă.
Bibliografie

1. Ariton V., Fundamente ale tehnologiei informaţiei şi comunicaţiilor, Ed. Didactică şi

Pedagogică, 2004.
2. Batini, C., Ceri, S., Navathe, S., B., Conceptual Database Design, Benjamin/Cummings.
1992.
3. Băduţ M. „Informatica în management“, Editura Albastră, Cluj, 2003
4. Conoly T., Begg C., Baze de date. Proiectare, implementare, gestionare., Editura Teora,
2001.
5. Dawson, Ross, “The Seven MegaTrends of Professional Services”, http://www.cio.com,
2005
6. Davidescu N.et al., Sisteme informatice financiar-bancare, Editura All 1998/1999.
7. Florescu V. – Grupul BDASEIG, Baze de date. Fundamente teoretice şi practice, Editura
InfoMega, 2002.
8. Florescu V., Stanciu V., Cozgarea G., Cozgarea A., Baze de Date, Ed. Economică, 1999.
9. Fotache M., Baze de date relaţionale. Organizare, interogare, normalizare, Editura
Junimea, 1997.
10. Fowler M., Scott K., UML Destilled, Second Edition. A Brief User Guide to the Standard
Object Modeling Language. AddisonWesleyLongmanInc., 1999.
11. Hawryszkiewycz I.T., Introduction to System Analysis and Design, Prentice Hall, 1994.
12. Hawryszkiewycz, I.T., Relational Database Design. An Introduction, Prentice Hall Inc.
1990.
13. Jacobson, I, Booch G., Rumbaugh J., The Unified Software Development Process,
Addison-Wesley, 1999.
14. Jeffrey H. A., Prescott M. B., McFadden F.R., Modern Database Management, Sixth
Edition, Prentice Hall, 2002.
15. Kendall K. E., Kendall J.E., Systems Analysis and Design, Prentice Hall, 4th Edition,
1999.
16. Lungu I., Bordea C., Bădescu G., Ioniţă C., Baze de date: organizare, proiectare
şi implementare, Editura ALL, 1996.
17. Lungu I., et al., Sisteme Informatice, Editura Economică, 2003.
18. Panţîru M., Proiectarea sistemelor informatice economice – note de curs, Ed. Fundaţiei
Chemarea, 1995, Iaşi
19. Popovici D. M., Popovici I. M., Rican I. G., Proiectare şi implementare software, Editura
Teora, 1998
20. Sabău G., Avram V., Sisteme informatice şi baze de date, Ed. Oscar Print, 1998
21. Silberschatz, A., KorthH.F, Sudarshan, S., Database System Concepts, Fourth Edition,
McGRAW-HILL. 2001.
22. Stanciu V. Sisteme informatice de gestiune, Editura Tribuna Economică, Bucureşti, 1999.
23. Stanciu V., Proiectarea sistemelor Informatice de Gestiune, Ed. CISON, 2000
24. Teorey, Toby J., Database Modeling & Design, Third Edition, Morgan Kaufmann, 1999.
25. Turbide, Dave A., ‘Five Ways Erp Can Help You Implement Lean’,
http://www.c.tehnologyevaluation.org, 2005
26. Zaharie D. et al., Proiectarea sistemelor informatice de gestiune, Ed. Economică,
Bucureşti, 2002.